1 / 23

Privacy-Preserving Transaction Escrow

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

Télécharger la présentation

Privacy-Preserving Transaction Escrow

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Privacy-Preserving Transaction Escrow Stas Jarecki Pat Lincoln Vitaly Shmatikov UC Irvine SRI International

  2. 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?

  3. 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@

  4. 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

  5. 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?

  6. 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?

  7. 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

  8. 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

  9. 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.

  10. 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

  11. 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)

  12. 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!

  13. 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

  14. “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 ?

  15. 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

  16. 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

  17. 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)

  18. 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)

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

More Related