Handcuffing Big Brother: Abuse-Resilient Transaction Escrow

1. Handcuffing Big Brother:Abuse-Resilient Transaction Escrow Stanisław Jarecki UC Irvine Vitaly Shmatikov SRI International Eurocrypt 2004

2. Data Collection Poses a Threat to Privacy Data Collection Examples: • Financial transaction records (Detection of fraud and money laundering) • Medical research databases (Research queries) • Computer network monitoring (Intrusion detection) • Law enforcement (Searching for criminal profiles cf. CAPS II, JetBlue debacle) Crypto Research Question: Can we enable (some) data monitoring while protecting (some) data privacy ?

3. Our Goal: Protect Data After It Is Collected 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?

4. Related Work… • … 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 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

5. Basic Data Collection Capability: Need to Support Efficient Subpoena Data Collection with support for efficient subpoena: 1. By default, all data are inaccessible to the agency • Data are secret • Data “creators” are anonymous 2. If some data creator (“user”) U is subpoenaed, all his data are 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 remain inaccessible

6. Escrow Escrow agency Signed receipt Data access ZK proof of possession of correct receipt Escrow User proves that the escrow was formed correctly Efficient subpoena: User’s data revealed if user is subpoenaed Escrowed data Verifiable Transaction Escrow User transaction (money transfer to Barbados) Transaction counterparty (e.g. bank)

7. Existing Approaches to Data Collection • Trusting data collection agency • Government agency insiders can search internal databases at whim • Visa knows all your transactions • Traditional key escrowapproach: Trusting third-partyescrow agents • Escrows are encrypted under agency’s public key, whose secret part is shared among N escrow agents • Threshold trust model: data remain private as long as half of the agents are honest Aldrich Ames

8. Problems with Existing Escrow Schemes Public-key based escrow schemes provide either privacy, or efficiency,but not both PKEA = Public Key of the Escrow Agency • Escrowed data consists only of ciphertexts: EPKEA{“U”,m} • Full privacy • Very inefficient subpoena Escrow agency must test each ciphertext (by threshold decryption!!) • Escrowed data tagged with user’s identity: (“U”, EPKEA{m}) • Subpoena is efficient • Privacy is compromised Agency learns who makes transactions when, how many, how often, whether transactions of U and U’ are correlated, etc…

9. Efficient SubpoenaRequires Deterministic Tags Subpoena = “John Doe’s money transfers to Barbados” user U type of transaction 1. If tags are computed non-deterministically: (as in [BDOP ’04]) Tag = FPKEA($) (U, type) • There might be an efficient procedure Test(Tag,trapdoor(PKAE,U,type) ) which identifies tags corresponding to the (U,type) “category” • This takes at best 1 crypto op. per escrow item • Inefficient for large data sets (10M items = 1 day per PC) 2. If tags are computed deterministically: Tag = F (U, type) • Identification of subpoenaed escrows takes O(1) crypto op.

10. Proposed Compromise betweenSubpoena Efficiency and User Privacy Proposed privacy measure: “Category-Preserving” Privacy From two escrows e = Escrow { U, m, type },e’ = Escrow { U’, m’, type’ } U : user identity m : transaction description type : e.g. “money transfer to Barbados” the escrow agency learns only whether category(e) = category(e’) i.e., whether (U,type) = (U’,type’) • Escrow agency does not learn what these categories are • This is what deterministic Tag = F (U,type) always reveals ?

11. Category-preserving privacy = From (e,e’) escrow agency learns only whether category(e) = category(e’) Category-Preserving Privacy: Weaker than Perfect, but Possibly Good Enough • Weaker than perfect privacy: Agency learns of existence of correlated categories, e.g. • All escrows have the same category => Only one user active • Two categories always arrive together => They are “synchronized” • Can be good enough for massive data collection • With high transactions rates: • correlations will be hard to find • knowledge that some correlated categories exist seems harmless

12. Another Data Collection Capability:Automatic Selective Revelation • Automatically open escrows that match some user-related condition [ escrows that do not match remain (category-preserving)private] • Reveal transactions of a person who made more than t = 5 money transfers to Barbados in the last month • All such escrows have category (User_XXX , ”money transf. to Barb.”) • If tag is a deterministic function of (user,type) category: • Automatic revelation is feasible: agency looks only at entries with same tag • If tag is computed non-deterministically: • Automatic revelation is infeasible: at least 1 crypto op. per each t - element subset of escrows  O(|D|t) crypto ops.

13. Signed receipt Data access Tagged escrow Efficient subpoena & automatic revelation Escrowed data Tagged Escrows:Efficient and Category-Preserving Private Escrow agency User Tagged escrow transaction (money transfer to Barbados) ZK proof of possession of correct receipt

14. Deterministic Tags Need Private Keys • Efficient subpoena requires deterministic tagging • Public-key deterministic tagging functions fail If escrow is tagged with Tag = FPKEA (U,type), where F is a publicly computable deterministic function, then • privacy is still compromised: Agency can identify U’s escrows by re-computing FPKEA(U,type) • Need private tagging function instead

15. Implementing Tags with VRFs • U’s tags should be computable only by U • Every user U needs a secret key k • Use a pseudorandom function [PRF]: Tag = Fk (type) • Values of Fk look independent from inputs and user’s identity • PRFs maintain category-preserving privacy • To prevent cheating, U must prove that Tag is correct • Use a verifiable pseudorandom function [VRF] • Each user U has a public key which allows verification that U computed Tag = Fk (type) correctly • VRFs are easy to implement with DDH + ROM • PK = g k mod p, Fk(x) = (H(x)) k mod p • Verifiability of (PK, x, Fk(x)) triple: ZK proof of discrete-log equality

16. Tagged escrow Escrow agency Signed receipt ZK proof of possession of correct receipt Tagged escrow Escrowed data Verifiability of the Entire Escrow User  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 Barbados)

17. Escrow Verifiability in Subpoena • Escrow = (tag [t], ciphertext [c], signature [s]) = (Fk(type), Enck(m), Sigk(t,c)) • Subpoena protocol on input (U,type): • U computes tag tU = Fk (type), and proves correctness • If agency finds escrow (tU,c,s), U dis/proves signature s on (tU,c) • If escrow is correct, U decrypts c, and proves correctness • If U ever refuses/fails, U is “held in contempt” • If users’ keys are escrowed by escrow trustees • Escrow trustees compute all the above using secret-sharing of k • All procedures involve threshold exponentiations (easy)

18. Security Properties • Subjects of monitoring cannot cheat • Subpoena/Revelation of correct escrows cannot be avoided • Honest transaction counterparty verifies that user submitted a correct escrow to the agency • 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

19. rcpt = SigEA(e) (e, rcpt) (m, U, type) Agency’s view: e=(t,c,s), rcpt Counterparty’s view: (e, rcpt) (m, U, type) Even a single maliciouscounterparty allows malicious agency to link tag t with category (U,type) 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 Barbados) Tagged escrow Escrowed data Counterparty

20. Agency’s view: (e, rcpt) rcpt = SigEA(e) • U sends (m, U, type) • + ZK proof of • possession of (e, rcpt) • s.t. • 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 Barbados) Tagged escrow Unlinkable Signatures [Camenish Lysyanskaya]: signature scheme with ZK proof of signature possession [CL]: signature on a commitment Here: signature on a ciphertext Escrowed data Counterparty

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

22. Forcing Consistency of Key Pieces • Use VRF to generate a consistent secret-sharing • Use VRF to pick a (t-1)-degree secret-sharing polynomial f(x) = Fk (category) • Encrypt the transaction using key k’=f(0) • Attach f (fresh_random_point) as a piece of key k’=f(0) to each escrow • Verifiability of each escrow via VRF properties • Automatic revelation: • t escrows  t shares  interpolate k’=f(0)  All t escrows decrypted same category implies - same tag - same encryption key - consistent key pieces tag key split

23. Summary & Some 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 which sum to $10,000) • Relaxing PKI assumptions • Is transaction escrow without users’ private keys possible? • Other privacy measures • Support for other data collection functionalities

24. “Appendices”

25. Comparison to [BDOP, Eurocrypt’04]:Randomized PK-based Tagging • BDOP’04 allow search on public-key encrypted data • Treat category c as a keyword and tag escrows with Tag = F (PKA, c) where c = (U,type) and F is a randomized function (encryption-like) • Subpoena: • Key-Escrow Agents compute a trapdoor tc from (shared) SKA for the subpoenaed c=(User,type) category • For each tagged escrow item, Agent runs test(Tag,tc) which reveals if Tag  F (PKA, c) • Properties: • Full Privacy (F encrypts category c) • Inefficient for Very Large Data Sets: Needs one crypto op. per each escrow entry • Insecure against cheating Users: [BDOP] does not support verifiability in creation of the encrypted data

26. Contrast with “Private Computation” 2-Party Private Computation [PC] (example): B (CIA) A (FBI) In: DataA In: DataB Private Computation of Set Intersection Out: DataA U DataB PC Goal: Stop info leakage between two data owners • A learns nothing about DataB except DataA U DataB • B learns nothing about DataA except DataA U DataB • Of course, A knows all of DataA and B knows all of DataB … • Our Goal: Restrict access of A to DataA itself

27. Other Related Work • Search on encrypted data [SWP’00, BDOP’04, G’04] • User (email sender) has no incentive to cheat • We need verifiability if U escrows its transaction data correctly • Different efficiency requirements • Untraceable electronic cash [Chaum, Fiat, Naor ’88, …] • Not a general encryption, no subpoena support • In e-cash, user is non-anonymous for a bank, anonymous in transaction • Here, user is anonymous for Escrow Agency, non-anonymous in transaction • Private Information Retrieval [Chor et al. ’98, …] • Keeps the query secret from the database owner • In our case, owner knows the query, it’s the data that is “secret” • Anonymous credentials [Camenisch, Lysyanskaya ’01] • We use unlinkable CL signatures/credentials to disable cooperation between malicious escrow agent and malicious transaction counterparty