Handcuffing Big Brother: Abuse-Resilient Transaction Escrow

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