Handcuffing Big Brother:Abuse-Resilient Transaction EscrowStanisaw Jarecki UC Irvine Vitaly ShmatikovSRI International

Eurocrypt 2004

Data Collection Poses a Threat to PrivacyData 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 monitoringwhile protecting (some) data privacy ?

Our Goal: Protect Data After It Is CollectedDisallowed queries are infeasibleResearch questions:What query patterns can be efficiently supported?How private can the inaccessible data remain?Data query attemptData Collection AgencyCollected DataXAllowed queries are easy1 0 1 0 00 1 0 0 11 1 1 1 01 0 0 1 01 0 0 1 10 1 1 0 0

Related Work stronger than Privacy-Preserving Data MiningWe want to have provable data privacy harder than Search on Encrypted DataIn our threat model, data creators are not trusted to input correct dataE.g., money launderers try to avoid detection

Disallowed queries are infeasibleData query attemptData Collection AgencyCollected DataX1 0 1 0 00 1 0 0 11 1 1 1 01 0 0 1 01 0 0 1 10 1 1 0 0Allowed queries are easy

Basic Data Collection Capability: Need to Support Efficient SubpoenaData Collection with support for efficient subpoena:

1. By default, all data are inaccessible to the agencyData are secretData creators are anonymous2. If some data creator (user) U is subpoenaed, all his data are revealed to the agencyAgency needs to escrow everyones dataOnce U is subpoenaed, agency must be able to efficiently identify all escrows related to U, and efficiently open themEveryone elses data remain inaccessible

Verifiable Transaction EscrowUser transaction(money transfer to Barbados)Transaction counterparty (e.g. bank)

Existing Approaches to Data CollectionTrusting data collection agencyGovernment agency insiders can search internal databases at whimVisa knows all your transactions

Traditional key escrow approach:Trusting third-party escrow agentsEscrows are encrypted under agencys public key, whose secret part is shared among N escrow agentsThreshold trust model: data remain private as long as half of the agents are honestAldrich Ames

Problems with Existing Escrow SchemesPublic-key based escrow schemes provideeither privacy, or efficiency, but not both

PKEA = Public Key of the Escrow AgencyEscrowed data consists only of ciphertexts: EPKEA{U,m} Full privacy Very inefficient subpoenaEscrow agency must test each ciphertext (by threshold decryption!!) Escrowed data tagged with users identity: (U, EPKEA{m}) Subpoena is efficient Privacy is compromisedAgency learns who makes transactions when, how many, how often,whether transactions of U and U are correlated, etc

Efficient SubpoenaRequires Deterministic TagsSubpoena = John Does 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) categoryThis takes at best 1 crypto op. per escrow itemInefficient 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.

Proposed Compromise betweenSubpoena Efficiency and User PrivacyProposed privacy measure:Category-Preserving PrivacyFrom two escrows e = Escrow { U, m, type }, e = Escrow { U, m, type }

U : user identitym : transaction descriptiontype : 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?

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

Another Data Collection Capability:Automatic Selective RevelationIf tag is a deterministic function of (user,type) category:Automatic revelation is feasible: agency looks only at entries with same tagIf 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.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 monthAll such escrows have category (User_XXX , money transf. to Barb.)

Tagged Escrows:Efficient and Category-Preserving PrivateUser transaction(money transfer to Barbados)ZK proof of possessionof correct receiptEscrow agencyTagged escrow

Deterministic Tags Need Private KeysEfficient subpoena requires deterministic taggingPublic-key deterministic tagging functions failIf escrow is tagged with Tag = FPKEA (U,type), whereF is a publicly computable deterministic function, thenprivacy is still compromised: Agency can identify Us escrows by re-computing FPKEA(U,type)

Need private tagging function instead

Implementing Tags with VRFsUs tags should be computable only by UEvery user U needs a secret key kUse a pseudorandom function [PRF]: Tag = Fk (type) Values of Fk look independent from inputs and users identityPRFs maintain category-preserving privacy

To prevent cheating, U must prove that Tag is correctUse 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 pVerifiability of (PK, x, Fk(x)) triple: ZK proof of discrete-log equality

Verifiability of the Entire EscrowUsertransaction(e.g., money transfer to Barbados) Anonymous tag Encrypted transaction Private signatureVerifiable random functionAnonymous and private signature, verifiable by interaction with the signerVerifiable anonymous encryption

Escrow Verifiability in SubpoenaEscrow = (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 correctnessIf agency finds escrow (tU,c,s), U dis/proves signature s on (tU,c)If escrow is correct, U decrypts c, and proves correctnessIf U ever refuses/fails, U is held in contempt

If users keys are escrowed by escrow trusteesEscrow trustees compute all the above using secret-sharing of kAll procedures involve threshold exponentiations (easy)

Security PropertiesSubjects of monitoring cannot cheatSubpoena/Revelation of correct escrows cannot be avoidedHonest transaction counterparty verifies that user submitted a correct escrow to the agencyMalicious insiders of escrow agency are powerlessCategory-preserving privacy protects data from agency insidersCannot frame individuals by inserting bogus records Malicious transaction counterparties cannot helpthe malicious escrow agencyEscrow submission and receipt verification protocols are unlinkable

Naive Verifiability Violates PrivacyUsertransaction(e.g., money transfer to Barbados)Escrowed dataTagged escrowEscrow agency Anonymous tag (t) Transaction ciphertext (c) Private signature (s)Tagged escrow (e) Counterparty

Verifiability with Unlinkable SignaturesUsertransaction(e.g., money transfer to Barbados)Escrowed dataTagged escrowEscrow agency Anonymous tag (t) Transaction ciphertext (c) Private signature (s)Tagged escrow (e) CounterpartyUnlinkable Signatures [Camenish Lysyanskaya]: signature scheme with ZK proof of signature possession[CL]: signature on a commitmentHere: signature on a ciphertext

Automatic Selective RevelationEscrow databaseIndividualCorrectnessverified

Forcing Consistency of Key PiecesUse VRF to generate a consistent secret-sharingUse VRF to pick a (t-1)-degree secret-sharing polynomialf(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 escrowVerifiability of each escrow via VRF propertiesAutomatic revelation:t escrows t shares interpolate k=f(0) All t escrows decryptedsame category implies- same tag- same encryption key - consistent key piecestagkeysplit

Summary & Some Open QuestionsBroader class of patterns for selective revelationDynamically evolving patternsPatterns not specific to an individual userCumulative revelation criteriaReveal cumulative transactions once their total value reaches a threshold (e.g. all transactions which sum to $10,000)Relaxing PKI assumptionsIs transaction escrow without users private keys possible?Other privacy measuresSupport for other data collection functionalities

Appendices

Comparison to [BDOP, Eurocrypt04]:Randomized PK-based TaggingBDOP04 allow search on public-key encrypted dataTreat 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) categoryFor 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

Contrast with Private Computation2-Party Private Computation [PC] (example):B (CIA)A (FBI)In: DataAIn: DataBOut: DataA U DataBPC Goal: Stop info leakage between two data ownersA learns nothing about DataB except DataA U DataBB 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 itselfPrivate Computation of Set Intersection

Other Related WorkSearch on encrypted data [SWP00, BDOP04, G04]User (email sender) has no incentive to cheatWe need verifiability if U escrows its transaction data correctlyDifferent efficiency requirementsUntraceable electronic cash [Chaum, Fiat, Naor 88, ]Not a general encryption, no subpoena supportIn e-cash, user is non-anonymous for a bank, anonymous in transactionHere, user is anonymous for Escrow Agency, non-anonymous in transactionPrivate Information Retrieval [Chor et al. 98, ]Keeps the query secret from the database ownerIn our case, owner knows the query, its the data that is secretAnonymous credentials [Camenisch, Lysyanskaya 01]We use unlinkable CL signatures/credentials to disable cooperation between malicious escrow agent and malicious transaction counterparty