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

2. Data Collection is a Threat to Privacy u Financial transaction records Detection of fraud and money laundering u Medical research databases Research queries u Computer network monitoring Intrusion detection u 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 DB #QO@ ? u Access control Only trusted parties may initiate queries Disallow intruder from asking questions u Protected execution environments Required trusted computing platform Limit extraction of data Introduce random variations u Encrypted databases Rely on cryptographic techniques Even raw data do not leak information

4. Access Control DB u 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 u 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. Protected Execution u Restrict queries u Use digital rights management or data labeling u Randomize individual values preserving global statistical properties u 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? DB

6. Disallowed queries are infeasible Research questions: - What query patterns can be efficiently supported? - How private can the “inaccessible” data remain? Data query attempt Data collection agency Collected data X Allowed queries are easy … 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 … Our Goal: Protect Data After Collection

7. u … stronger than privacy-preserving data mining We want to have provable data privacy u … 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 Disallowed queries are infeasible Data query attempt Data collection agency Collected data X … 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 … Allowed queries are easy Related Problems

8. Basic Problem: Efficient Subpoena u By default, all data should remain inaccessible to the agency Data values are secret Data creators are anonymous u 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 u Escrows are ciphertexts only: E PK {“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!! u Escrows tagged by creator’s identity: “U”, E PK {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 u 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!) u No trusted parties Secure against malicious escrow agent Corrupt transaction participants cannot break privacy and anonymity of transactions between honest parties u Provable security Reduction to Decisional Diffie-Hellman in Random Oracle Model

11. Verifiable Transaction Escrow User transaction (e.g., money transfer to Caymans) Escrowed data Escrow Signed receipt Proof of possession of correct receipt User proves that the escrow was formed correctly Escrow agency Escrow User’s data are revealed only if user is subpoenaed Data access Transaction counterparty (e.g., bank)

12. Subpoena: “John Doe’s wire transfers to Caymans” user U type of transaction u Nondeterministic tags: tag=F PK ($) (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) u Deterministic tags: tag=F(U, type) Identification of subpoenaed escrows takes O(1) crypto ops regardless of the size of the database! Escrows Must be Tagged

13. Deterministic Tags Require Private Keys u Efficient subpoena requires deterministic tagging u Public-key deterministic tagging functions are vulnerable to guessing attacks If escrow is tagged with Tag=F pk (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 F pk (U,type) u 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 u 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” u 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’) u 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” u 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) u With deterministic tags, this is easy Agency only needs to look at escrows with the same tag

17. Efficiency and “Good Enough” Privacy User transaction (e.g., money transfer to Caymans) Escrowed data Tagged escrow Signed receipt ZK proof of possession of correct receipt Escrow agency Tagged escrow Efficient subpoena & automatic revelation Data access Transaction counterparty (e.g., bank)

18. Cryptographic Toolkit User transaction (e.g., money transfer to Caymans) Escrowed data Tagged escrow Signed receipt ZK proof of possession of correct receipt Escrow agency Tagged escrow Transaction counterparty (e.g., bank)  Anonymous tag  Encrypted transaction  Private signature Verifiable random function Anonymous and private signature, verifiable by interaction with the signer Verifiable anonymous encryption

19. Security Properties u Subjects of monitoring cannot cheat Subpoena and revelation of correct escrows cannot be avoided u Malicious insiders of escrow agency are powerless Category-preserving privacy protects data from agency insiders Cannot frame individuals by inserting bogus records u Malicious transaction counterparties cannot help the malicious escrow agency Escrow submission and receipt verification protocols are unlinkable

20. 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 User transaction (e.g., money transfer to Caymans) Escrowed data Tagged escrow rcpt = Sig EA (e) Escrow agency  Anonymous tag (t)  Transaction ciphertext (c)  Private signature (s) Counterparty Agency’s view: e=(t,c,s), rcpt counterparty’s view: (e, rcpt) (m, U, type) (e, rcpt) (m, U, type) Tagged escrow (e)

21. Verifiability with Unlinkable Signatures User transaction (e.g., money transfer to Caymans) Escrowed data Tagged escrow rcpt = Sig EA (e) Escrow agency  Anonymous tag (t)  Transaction ciphertext (c)  Private signature (s) Tagged escrow (e) Counterparty U sends (m, U, type) + ZK proof of possession of (e, rcpt) such that 1.e is a correct escrow of (m, U, type) 2.rcpt = Sig EA (e) Counterparty’s view: (m,U,type) Agency’s view: (e, rcpt) Unlinkable signatures [Camenisch Lysyanskaya] give us a signature scheme with ZK proof of signature possession

22. Automatic Selective Revelation Escrow database User Correctness verified  Decryption key is recovered when pattern is matched from t related escrows A share of the decryption key Same anonymous tag for all related escrows

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