Privacy-Preserving
Download
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

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

?

#QO@


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