Post on 31-Dec-2015
description
Privacy-Preserving Privacy-Preserving Transaction EscrowTransaction 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 • Research queries
Computer network monitoring • Intrusion detection
Law enforcement• Airline passenger databases (CAPPS II, JetBlue debacle, etc.)
Research question: Can we enable (some) data monitoringwhile protecting (some) data privacy?
Approaches To Privacy Protection
DB
DB
#QO@
?
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
Access Control DB
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
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?
DB
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…
Our Goal: Protect Data After Collection
… 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 will 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
Related Problems
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
Problems with Public-Key Escrow
Public-key escrow schemes provideeither 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.
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
Verifiable Transaction Escrow
User
transaction(e.g., money transfer
to Caymans)
Escrowed data
Escrow
Signed receipt
Proof of possessionof correct receipt
User proves that the escrow was formed correctly
Escrow agencyEscrow
User’s data are revealed only if user is subpoenaed
Data access
Transaction counterparty (e.g., bank)
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!
Escrows Must be Tagged
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
“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
?
Category-Preserving Privacy
From two escrows e and e’ data collection agencylearns 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
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
Efficiency and “Good Enough” Privacy
User
transaction(e.g., money transfer
to Caymans)
Escrowed data
Tagged escrow
Signed receipt
ZK proof of possessionof correct receipt
Escrow agencyTagged escrow
Efficient subpoena &automatic revelation
Data access
Transaction counterparty (e.g., bank)
Cryptographic Toolkit
User
transaction(e.g., money transfer
to Caymans)
Escrowed data
Tagged escrow
Signed receipt
ZK proof of possessionof correct receipt
Escrow agencyTagged 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
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
helpthe malicious escrow agency• Escrow submission and receipt verification protocols are
unlinkable
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 escrowrcpt = SigEA(e)
Escrow agency Anonymous tag (t) Transaction ciphertext (c) Private signature (s)
Counterparty
Agency’s view:e=(t,c,s), rcptcounterparty
’s view:(e, rcpt) (m, U, type)
(e, rcpt)(m, U, type)
Tagged escrow (e)
Verifiability with Unlinkable Signatures
User
transaction(e.g., money transfer
to Caymans)
Escrowed data
Tagged escrowrcpt = SigEA(e)
Escrow agency Anonymous tag (t) Transaction ciphertext (c) Private signature (s)
Tagged escrow (e)
Counterparty
U sends (m, U, type) +ZK proof ofpossession of (e, rcpt) such that1. e is a correct escrow of (m, U, type)2. rcpt = SigEA(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
Automatic Selective Revelation
Escrow database
User
Correctnessverified
Decryption key is recovered when pattern is matched from t related escrows
A share of the decryption key
Same anonymous tag forall related escrows
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