Handcuffing Big Brother:Handcuffing Big Brother:Abuse-Resilient Abuse-Resilient Transaction EscrowTransaction Escrow
Stanisław Jarecki UC Irvine
Vitaly Shmatikov SRI International
Eurocrypt 2004
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 monitoringwhile protecting (some) data privacy ?
Our Goal: Protect Data After It Is Collected
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 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 data
– E.g., money launderers try to avoid detection
Disallowed queries are infeasible
Data query attempt
Data Collection Agency Collected Data
X
…1 0 1 0 00 1 0 0 11 1 1 1 01 0 0 1 01 0 0 1 10 1 1 0 0…
Allowed queries are easy
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
Verifiable Transaction Escrow
User
transaction(money transfer
to Barbados)
Escrowed data
Escrow
Signed receipt
ZK proof of possessionof correct receipt
User proves that the escrow was formed correctly
Escrow agencyEscrow
Efficient subpoena:User’s data revealed if user is subpoenaed
Data access
Transaction counterparty (e.g. bank)
Existing Approaches to Data Collection
Aldrich Ames
Trusting data collection agency• Government agency insiders can search
internal databases at whim• Visa knows all your transactions
Traditional key escrow approach:Trusting third-party escrow 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
Problems with Existing Escrow Schemes
Public-key based escrow schemes provideeither privacy, or efficiency, but not both
PKEA = Public Key of the Escrow Agency
1. Escrowed data consists only of ciphertexts: EPKEA{“U”,m} Full privacy Very inefficient subpoena
Escrow agency must test each ciphertext (by threshold decryption!!)
2. 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…
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.
Proposed privacy measure:
“Category-Preserving” Privacy
From 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
Proposed Compromise betweenSubpoena Efficiency and User Privacy
?
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
Category-Preserving Privacy: Weaker than Perfect, but Possibly Good Enough
Category-preserving privacy =From (e,e’) escrow agency learns only whether category(e) = category(e’)
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.”)
Another Data Collection Capability:Automatic Selective Revelation
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.
Tagged Escrows:Efficient and Category-Preserving Private
User
transaction(money transfer
to Barbados)
Escrowed data
Tagged escrow
Signed receipt
ZK proof of possessionof correct receipt
Escrow agencyTagged escrow
Efficient subpoena &automatic revelation
Data access
Deterministic Tags Need Private Keys
Efficient subpoena requires deterministic tagging
Public-key deterministic tagging functions failIf escrow is tagged with Tag = FPKEA (U,type), where
F is a publicly computable deterministic function, thenprivacy is still compromised:
Agency can identify U’s escrows by re-computing FPKEA(U,type)
Need private tagging function instead
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
Verifiability of the Entire Escrow
User
transaction(e.g., money transfer
to Barbados)
Escrowed data
Tagged escrow
Signed receipt
ZK proof of possessionof correct receipt
Anonymous tag Encrypted transaction Private signature
Escrow agencyTagged escrow
Verifiable random function
Anonymous and private signature, verifiable by interaction with the signer
Verifiable anonymous encryption
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)
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 helpthe malicious escrow agency• Escrow submission and receipt verification protocols are
unlinkable
Naive Verifiability Violates Privacy
User
transaction(e.g., money transfer
to Barbados)
Escrowed data
Tagged escrowrcpt = SigEA(e)
Escrow agency Anonymous tag (t) Transaction ciphertext (c) Private signature (s)
Tagged escrow (e)
Counterparty
Agency’s view:e=(t,c,s), rcptCounterpart
y’s view:(e, rcpt) (m, U, type)
Even a single malicious counterparty allows malicious agency to link tag t with category (U,type)
(e, rcpt)(m, U, type)
Verifiability with Unlinkable Signatures
User
transaction(e.g., money transfer
to Barbados)
Escrowed data
Tagged escrowrcpt = SigEA(e)
Escrow agency Anonymous tag (t) Transaction ciphertext (c) Private signature (s)
Tagged escrow (e)
Counterparty
Unlinkable Signatures [Camenish Lysyanskaya]: signature scheme with ZK proof of signature possession[CL]: signature on a commitmentHere: signature on a ciphertext
U sends (m, U, type)+ ZK proof ofpossession of (e, rcpt) s.t.1. e is a correct escrow of (m, U, type)2. rcpt = SigEA(e)
Counterparty’s view: (m,U,type)
Agency’s view: (e, rcpt)
Automatic Selective Revelation
Escrow database
Individual
Correctnessverified
Decryption key is recovered when pattern matched from t related escrows
A share of the decryption key
Same anonymous tag forall related escrows
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
Forcing Consistency of Key Pieces
same category implies- same tag- same encryption key - consistent key pieces
tag
key split
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
“Appendices”
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
Contrast with “Private Computation”
B (CIA)
2-Party Private Computation [PC] (example):A (FBI)
In: DataA In: DataB
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
Private Computation of Set Intersection
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