1 private resource pairing joseph calandrino department of computer science university of virginia...

1

Private Resource Pairing

Joseph CalandrinoDepartment of Computer Science

University of Virginia

August 10, 2005

2

Motivating Scenario

• Emergency Room– Incapacitated unidentified tourist arrives at ER– Perfect biometric exists– Treatment is history-dependent

3

Private Resource Pairing

• Resource Possession – Confidential

• Resource Requests – Confidential

• Third Parties – Undesirable

• Can We Overcome This?

4

Related Work

Private Matching• Alice and Bob possess separate databases• Alice wishes to determine intersection• Neither wishes to reveal non-matches

Alice Bob

Red

Orange

Yellow

Green

Blue

Purple

Blue

White

Yellow

5

Related Work

Private Matching (AgES Protocol – Simplified)• Alice and Bob agree on commutative encryption

(EA(EB(X)) = (EB(EA(X))) and hash functions

• Generate secret encryption keys, A and B *• Generate hashes; encrypt hashes

R h(‘R’) EA(h(‘R’))

O h(‘O’) EA(h(‘O’))

Y h(‘Y’) EA(h(‘Y’))

G h(‘G’) EA(h(‘G’))

B h(‘B’) EA(h(‘B’))

P h(‘P’) EB(h(‘P’))

B h(‘B’) EB(h(‘B’))

W h(‘W’) EB(h(‘W’))

Y h(‘Y’) EB(h(‘Y’))

Alice Bob

*Alice and Bob must generate new encryption keys each time they enter the private matching protocol

6

Related Work

Private Matching (AgES Protocol – Simplified)• Reorder encryptions lexicographically and

exchange encryptions (Alice also saves hers)

R EA(h(‘R’))

O EA(h(‘O’))

Y EA(h(‘Y’))

G EA(h(‘G’))

B EA(h(‘B’))

P

B

W

Y

Alice BobEB(h(‘P’))

EB(h(‘B’))

EB(h(‘W’))

EB(h(‘Y’))

EA(h(‘R’))

EA(h(‘O’))

EA(h(‘Y’))

EA(h(‘G’))

EA(h(‘B’))

Alice’sBob’s

7

Related Work

Private Matching (AgES Protocol – Simplified)• Reorder encryptions lexicographically and

exchange encryptions (Alice also saves hers)• Re-encrypt encryptions (Bob saves originals)

R EA(h(‘R’))

O EA(h(‘O’))

Y EA(h(‘Y’))

G EA(h(‘G’))

B EA(h(‘B’))

P

B

W

Y

Alice BobEA(EB(h(‘P’)))

EA(EB(h(‘B’)))

EA(EB(h(‘W’)))

EA(EB(h(‘Y’)))

EA(h(‘R’)) EB(EA(h(‘R’)))

EA(h(‘O’)) EB(EA(h(‘O’)))

EA(h(‘Y’)) EB(EA(h(‘Y’)))

EA(h(‘G’)) EB(EA(h(‘G’)))

EA(h(‘B’)) EB(EA(h(‘B’)))

Bob’s Alice’s

8

Related Work

Private Matching (AgES Protocol – Simplified)

• Bob returns the pairs; Alice matches on EA(h(X)) to get (X, EB(EA(h(X))) = (X, EA(EB(h(X)))

• Alice finds matches for B and Y, the intersection

R EA(EB(h(‘R’)))

O EA(EB(h(‘O’)))

Y EA(EB(h(‘Y’)))

G EA(EB(h(‘G’)))

B EA(EB(h(‘B’)))

P

B

W

Y

Alice BobEA(EB(h(‘P’)))

EA(EB(h(‘B’)))

EA(EB(h(‘W’)))

EA(EB(h(‘Y’)))

Bob’s

9

Related Work

• Private Matching– Limited data ownership and need to know technique– More efficient/robust private pairing solution possible

• Private Information Retrieval• Audit Logs• Searching on Encrypted Data –

Requestors reveal searches to provider

10

Behavioral Models

• Semi-Honest (Honest But Curious) Behavior– Parties do not lie– Parties do attempt to derive additional

information if possible– Costs of lying may outweigh benefits

• Malicious Behavior– Potentially dishonest parties– More realistic

11

Private Resource Pairing…

Basic Idea:• Setup:

1. Participants agree on a commutative encryption scheme and a hash function

2. Providers generate random encryption keys3. Providers publish lexicographically-

reordered encrypted hashes of their resource metadata to potential requestors or host servers– Providers publish signatures for servers

…under a Semi-Honest Behavior Model

12


Basic Idea:• Search and Acquisition:

1. Requestor generates new encryption/decryption key pair*2. Requestor gives encrypted hash of desired metadata to

provider3. Provider re-encrypts using its key and returns4. Requestor decrypts re-encryption5. Requestor matches result against published values

– For host servers, requestors acquire values and verify signatures

6. If match found, requestor asks provider for resources related to metadata


*Requestors must generate new keys for each search

13


Assumptions:• Requestor identity alone yields no private data• Providers publish data all at once, or

publication order is irrelevant• In the case of host servers:

– Requestors download all or no data from a server– Servers are unable to collude

• Metadata is not fuzzy


14


• Shortcomings of Semi-Honest Solution:– No enforcement of requestor need to know– No proof providers hold resources tied to published

metadata

• Malicious Model Must Address These Issues


15


Proving Requestor Need to Know:• Requestor Uses Two Tickets

– First:• To receive re-encryption• Contains only encrypted metadata

– Second:• To access metadata-related resources• Contains plaintext metadata

…under a Malicious Behavior Model

16


Proving Requestor Need to Know:• Tickets Supplier Must Distribute Tickets

– Requestor must trust supplier with search metadata– Supplier can issue scope-limited tickets– Providers must be able to verify supplier

trustworthiness– Suppliers should be unable to initiate searches– Assume suppliers and requestors cannot collude


17


Proving Resource Possession:• Identity-Based Signatures

– Verification key is identity– Master secret required to generate signing keys

• Key Privacy in Public Key Cryptosystems– An adversary possessing a piece of ciphertext can gain no

more than a negligible advantage in determining which public key out of a given set produced the ciphertext

– RSA lacks this: C = Me mod n. If nAlice = 6, nBob = 10, C = 7, an adversary knows that Bob’s public key encrypted C


18


Proving Resource Possession:• Two Cases:

– Metadata Implies an Owner• Everyone knows the “owner” of resources related to

every piece of metadata• Example: Biometrics

– Metadata Implies No Clear Owner• Metadata can imply many owners, or others are

unable to accurately guess owners from metadata• Example: Keywords


19


Proving Resource Possession:• Metadata Implies an Owner

– System Privacy• A set of instantiations of an identity-based signature

scheme exist with different master secrets• Adversary chooses an identity• Random instantiation produces the identity’s signature of a

nonce (unknown to adversary)• The adversary receives the signature• System privacy exists if the adversary can gain no more

than a negligible advantage in determining signing instantiation given some parameters


20



– Owner (or Delegated Owner) Setup:• Owners agree on signature scheme

– Identity-based scheme

– System privacy

• Owners independently generate master secrets• Owners publish verification parameters


21



– Providers Acquire Proof:1. Provider offers metadata, encrypted and

unencrypted, to owner

2. Owner checks that encryption represents metadata– Private matching

3. Owners signs encryption using private key associated with the provider’s ID and return result

4. Provider checks signature

5. Provider publishes data


22



– Requestor Verifies Proof:1. Requestor downloads owner parameters

2. Requestor checks signatures (using provider ID as key) for a signature of the encrypted hash of desired metadata


23



– If Owner Master Secret Compromised:• Owner needs new master secret• Only affects owner’s resources• How do we update signatures?


24


Proving Resource Possession:• Metadata Does Not Imply an Owner

– Use Universal Resource Owner• Can be centralized or distributed• Providers must trust owner• Requestors need not reveal anything to universal owner• Problems exist: key revocation, master secret compromise


25

Evaluation

Private Resource Pairing vs. Private Matching• Private Resource Pairing: Semi-Honest Model

– No known comparable protocol for malicious pairing protocol

• Private Matching: AgES– Requestor served as querying party with a single-entry DB– Additional step for requestor to ask for resources

• Ignored:– Server signature verification (implementation dependent)– Time to agree on hash/encryption function (same for both)

26

Theoretical Evaluation

Computational Cost (in Units of Cost)

27

Theoretical Evaluation

Communication Cost (in Units of Cost)

28

Performance Evaluation

• Implementation– Java-Based Implementation– Hash Function: SHA-1– Commutative Encryption Function:

Pohlig-Hellman with Common Modulus– Sort: Modified MergeSort (nlogn performance)– Number of Provider Metadata Items: 20

29

Performance Evaluation

AgESPrivate

Resource Pairing

Setup

Provider 0 ms 1177 ms

Requestor 0 ms 0 ms

Total 0 ms 1177 ms

Search and Acquisition

Provider 1194 ms 17 ms

Requestor 1218 ms 867 ms

Total 2412 ms 884 ms

Performance Comparison

30

Evaluation

Private Resource Pairing vs. Private Matching– Decrease in requestor computation time: 28.8%– Decrease in provider computation time: 98.6%– Pairing scales better than AgES– Potential AgES improvements:

• Avoid changing keys• Avoid re-encryption

31

Conclusion

• Summary• Future Work

– Time-Scoped Searching– System Privacy– Classification Levels– Untrusted Servers– Fuzzy Metadata– Many more…

32

Thank You

In Particular:• Alfred Weaver• David Evans• Brent Waters

33

Questions?

1 private resource pairing joseph calandrino department of computer science university of virginia...

Documents

encryptions bob

resource metadata

encrypted data requestors

exchange encryptions

new encryption keys

potential requestors

new keys

commutative encryption