slide1
Download
Skip this Video
Download Presentation
Privacy-Preserving Transaction Escrow

Loading in 2 Seconds...

play fullscreen
1 / 23

Privacy-Preserving Transaction Escrow - PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on

Privacy-Preserving Transaction Escrow. Stas Jarecki Pat Lincoln Vitaly Shmatikov UC Irvine SRI International. Data Collection is a Threat to Privacy. Financial transaction records Detection of fraud and money laundering Medical research databases

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Privacy-Preserving Transaction Escrow' - malcolm-kirby


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Privacy-Preserving Transaction Escrow

Stas Jarecki Pat Lincoln Vitaly Shmatikov

UC Irvine SRI International

data collection is a threat to privacy
Data Collection is a Threat to Privacy
  • Financial transaction records
    • Detection of fraud and money laundering
  • Medical research databases
    • Research queries
  • Computer network monitoring
    • Intrusion detection
  • Law enforcement
    • Airline passenger databases

(CAPPS II, JetBlue debacle, etc.)

Research question:

Can we enable (some) data monitoring

while protecting (some) data privacy?

approaches to privacy protection
Approaches To Privacy Protection
  • Access control
    • Only trusted parties may initiate queries
    • Disallow intruder from asking questions
  • Protected execution environments
    • Required trusted computing platform
    • Limit extraction of data
    • Introduce random variations
  • Encrypted databases
    • Rely on cryptographic techniques
    • Even raw data do not leak information

DB

DB

?

#[email protected]

access control

DB

Access Control
  • Only allow trusted people to initiate queries
    • In some medical databases, only 1 trusted individual is authorized to perform queries
      • Reviews suggested queries and their results for privacy implications
      • Maintains per-user and global history of queries and responses
  • How to separate “good” and “bad” queries

in an untrusted computing environment?

    • Government agency insiders can search internal

databases at whim

      • IRS employees can snoop on their neighbors’ returns
    • Purpose of a query may be hard to determine
      • Visa knows all your credit card transactions
      • HMO knows your entire medical history

Aldrich Ames

protected execution

DB

Protected Execution
  • Restrict queries
  • Use digital rights management or data labeling
  • Randomize individual values preserving global statistical properties
  • Suppress and generalize for k-anonymity

… none of these help against the attacker who

has access to the underlying database

This requires trusted computing platform

    • How to specify and enforce data access policies?
our goal protect data after collection
Our Goal: Protect Data After Collection

Collected data

Data collection agency

1 0 1 0 0

0 1 0 0 1

1 1 1 1 0

1 0 0 1 0

1 0 0 1 1

0 1 1 0 0

Data query attempt

Allowed queries are easy

Disallowed queries are infeasible

X

Research questions:

  • What query patterns can be efficiently supported?
  • How private can the “inaccessible” data remain?
related problems
Related Problems
  • … stronger than privacy-preserving data mining

We want to have provable data privacy

  • … harder than search on encrypted data

In our threat model, data “creators” are not trusted to input correct data

      • E.g., money launderers will try to avoid detection

Collected data

Data collection agency

1 0 1 0 0

0 1 0 0 1

1 1 1 1 0

1 0 0 1 0

1 0 0 1 1

0 1 1 0 0

Data query attempt

Allowed queries are easy

Disallowed queries are infeasible

X

basic problem efficient subpoena
Basic Problem: Efficient Subpoena
  • By default, all data should remain inaccessible to the agency
    • Data values are secret
    • Data creators are anonymous
  • When some data creator U is subpoenaed, all his data should be revealed to the agency
    • Agency needs to escrow everyone’s data
    • Once U is subpoenaed, agency must be able to efficiently identify all escrows related to U and efficiently open them
    • Everyone else’s data should remain inaccessible
problems with public key escrow
Problems with Public-Key Escrow

Public-key escrow schemes provide

either privacy, or efficiency, but not both

  • Escrows are ciphertexts only: EPK{“U”,m}
    • Full privacy
    • Very inefficient subpoena
      • If the decryption key is threshold-shared between several trustees, escrow agency must test each ciphertext by threshold decryption!!
  • Escrows tagged by creator’s identity: “U”, EPK{m}
    • Subpoena is efficient
    • Privacy is compromised
      • Escrow agency learns who makes transactions, when, how often, whether transactions of U and U’ are correlated, etc.
our transaction escrow scheme
Our Transaction Escrow Scheme
  • Transactions are escrowed in a way that makes

information available only for controlled use

    • Efficient subpoena procedures (unlike public-key escrow)
    • Assured privacy and anonymity for personal data
    • Investigative pattern matching: escrows are opened automatically when they match some pattern (and only then!)
  • No trusted parties
    • Secure against malicious escrow agent
    • Corrupt transaction participants cannot break privacy and

anonymity of transactions between honest parties

  • Provable security
    • Reduction to Decisional Diffie-Hellman in Random Oracle Model
verifiable transaction escrow

Escrow agency

Escrow

Signed receipt

Data access

Proof of possession

of correct receipt

Escrow

User proves that the escrow was formed correctly

User’s data are revealed only if user is subpoenaed

Escrowed data

Verifiable Transaction Escrow

User

transaction

(e.g., money transfer

to Caymans)

Transaction counterparty (e.g., bank)

escrows must be tagged
Escrows Must be Tagged

Subpoena: “John Doe’s wire transfers to Caymans”

user U type of transaction

  • Nondeterministic tags: tag=FPK($) (U, type)
    • There might be an efficient procedure which identifies tags corresponding to a given (U, type) “category”
    • This takes at best 1 crypto op per each escrow
    • Inefficient for large data sets (10 million escrows = 1 day on PC)
  • Deterministic tags: tag=F(U, type)
    • Identification of subpoenaed escrows takes O(1) crypto ops regardless of the size of the database!
deterministic tags require private keys
Deterministic Tags Require Private Keys
  • Efficient subpoena requires deterministic tagging
  • Public-key deterministic tagging functions are vulnerable to guessing attacks
    • If escrow is tagged with Tag=Fpk(U, type) where F is a publicly computable deterministic function, then

privacy is still compromised

since agency can identify U’s escrows by re-computing Fpk(U,type)

  • Need a private tagging function instead
    • Only the creator can compute the tag, using his private key
    • The tagging function needs to be verifiable so that the creator can prove that he has computed the tag correctly
good enough privacy
“Good Enough” Privacy

New notion: “category-preserving” privacy

  • From two escrows e=Escrow{u, m, type}

e’=Escrow{u’, m’, type’}

agency learns only whether (u, type) = (u’, type’)

    • u is creator’s identity, m is transaction description,

type is classification, e.g., “this is money transfer to Caymans”

  • Agency does not learn what these categories are
    • The agency can tell that two transactions were performed by the same person, but cannot tell who that person is
    • The agency can tell that two escrows describe transactions of the same type, but cannot determine what that type is

?

category preserving privacy
Category-Preserving Privacy

From two escrows e and e’ data collection agency

learns only whether category(e) = category(e’)

  • Weaker than perfect: agency learns that correlated categories exist (but not what they are)
    • If all escrows have the same category, then only one user is active
    • If two categories always arrive together, they are “synchronized”
  • Good enough for massive data collection
    • With high transaction rates, correlations will be hard to find
    • Knowledge that some correlated categories exist seems harmless
automatic selective revelation
Automatic Selective Revelation

Useful capability: automatic selective revelation

    • Reveal all transactions of any person who made more than

t=5 wire transfers to the Caymans in the last month

    • Escrows that do not match the condition must remain private
  • With nondeterministic tags, this is infeasible
    • O(|D|t) crypto ops (at least 1 crypto op per each subset of size t)
  • With deterministic tags, this is easy
    • Agency only needs to look at escrows with the same tag
efficiency and good enough privacy

Signed receipt

ZK proof of possession

of correct receipt

Efficiency and “Good Enough” Privacy

Escrow agency

User

Tagged escrow

transaction

(e.g., money transfer

to Caymans)

Data access

Tagged escrow

Efficient subpoena &

automatic revelation

Escrowed data

Transaction counterparty (e.g., bank)

cryptographic toolkit

Signed receipt

ZK proof of possession

of correct receipt

Cryptographic Toolkit

Escrow agency

User

Tagged escrow

 Anonymous tag

 Encrypted transaction

 Private signature

Verifiable anonymous encryption

Verifiable random function

Anonymous and private signature, verifiable by interaction with the signer

transaction

(e.g., money transfer

to Caymans)

Tagged escrow

Escrowed data

Transaction counterparty (e.g., bank)

security properties
Security Properties
  • Subjects of monitoring cannot cheat
    • Subpoena and revelation of correct escrows cannot be avoided
  • Malicious insiders of escrow agency are powerless
    • Category-preserving privacy protects data from agency insiders
    • Cannot frame individuals by inserting bogus records
  • Malicious transaction counterparties cannot help

the malicious escrow agency

    • Escrow submission and receipt verification protocols are unlinkable
naive verifiability violates privacy

rcpt = SigEA(e)

(e, rcpt)

(m, U, type)

Agency’s view:

e=(t,c,s), rcpt

counterparty’s view:

(e, rcpt) (m, U, type)

Malicious counterparty links tag t with category (U,type) and breaks privacy of U’s transactions of this type with honest counterparties

Naive Verifiability Violates Privacy

Tagged escrow (e)

User

Escrow agency

 Anonymous tag (t)

 Transaction ciphertext (c)

 Private signature (s)

transaction

(e.g., money transfer

to Caymans)

Tagged escrow

Escrowed data

Counterparty

verifiability with unlinkable signatures

Agency’s view: (e, rcpt)

rcpt = SigEA(e)

  • U sends (m, U, type) +
  • ZK proof of
  • possession of (e, rcpt)
  • such that
  • e is a correct escrow
  • of (m, U, type)
  • rcpt = SigEA(e)

Counterparty’s view: (m,U,type)

Verifiability with Unlinkable Signatures

Tagged escrow (e)

User

Escrow agency

 Anonymous tag (t)

 Transaction ciphertext (c)

 Private signature (s)

transaction

(e.g., money transfer

to Caymans)

Tagged escrow

Unlinkable signatures [Camenisch Lysyanskaya] give us a signature scheme with ZK proof of signature possession

Escrowed data

Counterparty

automatic selective revelation1

A share of the decryption key

Decryption key is recovered when pattern is matched from t related escrows

Same anonymous tag for

all related escrows

Automatic Selective Revelation

Escrow database

Correctness

verified 

User

summary and open questions
Summary And Open Questions
  • Broader class of patterns for selective revelation
    • Dynamically evolving patterns
    • Patterns not specific to an individual user
  • Cumulative revelation criteria
    • Reveal cumulative transactions once their total value reaches a threshold (e.g., all transactions whose sum exceeds $10,000)
  • Relaxing PKI assumptions
    • Is transaction escrow without users’ private keys possible?
  • Other notions of privacy
  • Support for other data collection functionalities
ad