330 likes | 345 Views
This research explores a private resource pairing solution to overcome confidentiality issues in resource possession and requests. It discusses the limitations of existing solutions and proposes a more efficient and robust approach. The paper also addresses behavioral models and provides techniques for proving requestor need-to-know and resource possession.
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