120 likes | 249 Views
This work presents a novel approach to keyword search over encrypted data, ensuring that untrusted proxies cannot extract sensitive information beyond what is necessary. We propose a Public-Key Encryption with Keyword Search (PEKS) scheme that allows the verification of keywords while maintaining privacy. Our schemes address the risks of information leakage through tokens. We explore use cases, such as secure email filtering and payment gateways, where sensitive keywords must remain confidential. Our findings bridge the gap between encryption methods and practical applications requiring predicate privacy.
E N D
Searching on Encrypted Data Without Revealing the Search Predicate Ananth Raghunathan Stanford University (joint work with Dan Boneh & Gil Segev)
Public-Key Encryption public key secret key c m m Bob Alice Learns nothing! ≈ (to ) More precisely:
Public-Key Encryption with Keyword Search Payment Routing Gateway Scenario 1: Payment Gateway
Public-Key Encryption with Keyword Search Assistant Email routing proxy Urgent! Later Scenario 2: Email forwarding
Requirements An encryption scheme that allow untrusted proxies to test for keywords (“tokens”) • Without a token, the proxy learns nothing. • With a token, the proxy learns whether message contains the keyword or not and nothing else. • (Implied) Tokens generated by secret key holder.
PEKS definition (Boneh et al. ‘04) secret key public key “BoA” • PEKS(pk,w) is publicly computable • Generating Tokw requires the secret key • Given TokBoA and PEKS(pk, w), the gateway can check if keyword w=“BoA” or not (algorithm Test) Payment Routing Gateway TokBoA PEKS (pk, “BoA”) TokWF TokChase TokBoA
Security: Overview Informally: the attacker is given tokens of his choice and should not be able to Test for w for which he does not have a token. (to ) Payment Routing Gateway PEKS (pk, “BoA”) Yes for “BoA” TokWF TokChase TokBoA
Security: Overview Informally: the attacker is given tokens of his choice and should not be able to Test for w for which he does not have a token. (to ) Payment Routing Gateway PEKS (pk, “JP Morgan”) TokWF TokChase TokBoA
Predicate privacy • Previous research did not consider information leaked by Tok • Several schemes even explicitly leak w in Tokw • Motivation 1: Payment gateway • Routing information might be sensitive • Transactions tagged with “suspected fraudulent” or other attributes that affect routing but shouldn’t be revealed to a gateway • Motivation 2: Encrypted email filter • Keywords are sensitive: “Urgent” keywords might leak information about personal life or medical data • Can we model a realistic notion of predicate privacy? • Can we construct schemes that satisfy predicate privacy?
Our work Email example: Proxy encrypts PEKS(pk, “Doctor’s appointment”) and sees whether Tok outputs Y or N • Model predicate privacy (“Tokwleaks no more information than necessary”) • Closely related to program obfuscation • If attacker can guess w then he can check quickly:Compute PEKS(pk,w) and test if Tokoutputs “yes” or “no” • Our definition: If the keyword w “cannot be guessed” by the attacker, then Tokw≈ Tokrandom • Constructions: First PEKS schemes with predicate privacy • We give a general approach to add predicate privacy to existing schemes
More expressive predicates In PEKS, p(id) checks if id = w or not and sk corresponds to Tok • A different formulation • Encrypt a tuple (id,m) • Secret key skp • Decryption algorithm given Enc(id,m) and skp recover m only if p(id)=1 • [Boneh et al. ‘04]: Equality predicate (point function) • [Boneh-Waters ‘07]: Conjunctive, subset, and range queries • [Katz-Sahai-Waters ‘08, Agrawal-Freeman-Vaikuntanathan ‘11]: Inner product, polynomial equations, and disjunctions • [Shen-Shi-Waters ‘09]: Inner product (but symmetric-key setting) • [Shi-Waters ‘08, Okamoto-Takashima ‘09, Lewko et al. ‘10]: Hierarchical inner product systems
Thank you!Any questions? ananthr@stanford.edu