Transaction escrow

1
Handcuffing Big BrotherAbuse-Resilient
Transaction Escrow
Stanislaw 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
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

• 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

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 everyones data
• Once U is subpoenaed, agency must be able to
  efficiently identify all escrows related to U,
  and efficiently open them
• Everyone elses data remain inaccessible

6
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 escrow approach
• Trusting third-party escrow agents
• Escrows are encrypted under agencys 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
  EPKEAU,m
• Full privacy
• Very inefficient subpoena
• Escrow agency must test each ciphertext (by
  threshold decryption!!)
• Escrowed data tagged with users identity (U,
  EPKEAm)
• 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 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)
  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 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 gt Only
  one user active
• Two categories always arrive together gt 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 CapabilityAutomatic
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(Dt) crypto ops.

13
Tagged EscrowsEfficient 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 Us escrows by re-computing
  FPKEA(U,type)
• Need private tagging function instead

15
Implementing Tags with VRFs

• Us 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
  users 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
Verifiability of the Entire Escrow
User
? Anonymous tag ? Encrypted transaction ? Private
signature
Verifiable random function
Verifiable anonymous encryption
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
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
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
Automatic Selective Revelation
Escrow database
Correctness verified ?
Individual
22
Forcing Consistency of Key Pieces
same category implies - same tag - same
encryption key - consistent key pieces
tag
key
split

• 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 kf(0)
• Attach f (fresh_random_point) as a piece of key
  kf(0) to each escrow
• Verifiability of each escrow via VRF properties
• Automatic revelation
• t escrows ? t shares ? interpolate kf(0) ? All
  t escrows decrypted

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, Eurocrypt04Randomized
PK-based Tagging

• BDOP04 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 SWP00, BDOP04, G04
• 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, its 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