330 likes | 428 Views
Private Resource Pairing. Joseph Calandrino Department of Computer Science University of Virginia August 10, 2005. Motivating Scenario. Emergency Room Incapacitated unidentified tourist arrives at ER Perfect biometric exists Treatment is history-dependent. Private Resource Pairing.
E N D
Private Resource Pairing Joseph Calandrino Department of Computer Science University of Virginia August 10, 2005
Motivating Scenario • Emergency Room • Incapacitated unidentified tourist arrives at ER • Perfect biometric exists • Treatment is history-dependent
Private Resource Pairing • Resource Possession – Confidential • Resource Requests – Confidential • Third Parties – Undesirable • Can We Overcome This?
Related Work Private Matching • Alice and Bob possess separate databases • Alice wishes to determine intersection • Neither wishes to reveal non-matches Alice Bob
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 Alice Bob *Alice and Bob must generate new encryption keys each time they enter the private matching protocol
Related Work Private Matching (AgES Protocol – Simplified) • Reorder encryptions lexicographically and exchange encryptions (Alice also saves hers) Bob’s Alice Bob Alice’s
Related Work Private Matching (AgES Protocol – Simplified) • Reorder encryptions lexicographically and exchange encryptions (Alice also saves hers) • Re-encrypt encryptions (Bob saves originals) Bob’s Alice Bob Alice’s
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 Bob’s Alice Bob
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
Behavioral Models • Semi-Honest (Honest But Curious) Behavior • Parties do not lie • Parties do attempt to derive additionalinformation if possible • Costs of lying may outweigh benefits • Malicious Behavior • Potentially dishonest parties • More realistic
Private Resource Pairing… …under a Semi-Honest Behavior Model Basic Idea: • Setup: • Participants agree on a commutative encryption scheme and a hash function • Providers generate random encryption keys • Providers publish lexicographically-reordered encrypted hashes of their resource metadata to potential requestors or host servers • Providers publish signatures for servers
Private Resource Pairing… …under a Semi-Honest Behavior Model Basic Idea: • Search and Acquisition: • Requestor generates new encryption/decryption key pair* • Requestor gives encrypted hash of desired metadata to provider • Provider re-encrypts using its key and returns • Requestor decrypts re-encryption • Requestor matches result against published values • For host servers, requestors acquire values and verify signatures • If match found, requestor asks provider for resources related to metadata *Requestors must generate new keys for each search
Private Resource Pairing… …under a Semi-Honest Behavior Model 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
Private Resource Pairing… …under a Semi-Honest Behavior Model • 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
Private Resource Pairing… …under a Malicious Behavior Model 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
Private Resource Pairing… …under a Malicious Behavior Model 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
Private Resource Pairing… …under a Malicious Behavior Model 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
Private Resource Pairing… …under a Malicious Behavior Model Proving Resource Possession: • Two Cases: • Metadata Implies an Owner • Everyone knows the “owner” of resources related toevery piece of metadata • Example: Biometrics • Metadata Implies No Clear Owner • Metadata can imply many owners, or others areunable to accurately guess owners from metadata • Example: Keywords
Private Resource Pairing… …under a Malicious Behavior Model 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
Private Resource Pairing… …under a Malicious Behavior Model Proving Resource Possession: • Metadata Implies an Owner • Owner (or Delegated Owner) Setup: • Owners agree on signature scheme • Identity-based scheme • System privacy • Owners independently generate master secrets • Owners publish verification parameters
Private Resource Pairing… …under a Malicious Behavior Model Proving Resource Possession: • Metadata Implies an Owner • Providers Acquire Proof: • Provider offers metadata, encrypted andunencrypted, to owner • Owner checks that encryption represents metadata • Private matching • Owners signs encryption using private key associated with the provider’s ID and return result • Provider checks signature • Provider publishes data
Private Resource Pairing… …under a Malicious Behavior Model Proving Resource Possession: • Metadata Implies an Owner • Requestor Verifies Proof: • Requestor downloads owner parameters • Requestor checks signatures (using provider ID as key) for a signature of the encrypted hash of desired metadata
Private Resource Pairing… …under a Malicious Behavior Model Proving Resource Possession: • Metadata Implies an Owner • If Owner Master Secret Compromised: • Owner needs new master secret • Only affects owner’s resources • How do we update signatures?
Private Resource Pairing… …under a Malicious Behavior Model 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
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)
Theoretical Evaluation Computational Cost (in Units of Cost)
Theoretical Evaluation Communication Cost (in Units of Cost)
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
Performance Evaluation Performance Comparison
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
Conclusion • Summary • Future Work • Time-Scoped Searching • System Privacy • Classification Levels • Untrusted Servers • Fuzzy Metadata • Many more…
Thank You In Particular: • Alfred Weaver • David Evans • Brent Waters