Presentation is loading. Please wait.

Presentation is loading. Please wait.

Public Key Cryptography in the Bounded Retrieval Model Based on joint works with Joël Alwen, Moni Naor, Gil Segev, Shabsi Walfish and Daniel Wichs Crypto.

Similar presentations


Presentation on theme: "Public Key Cryptography in the Bounded Retrieval Model Based on joint works with Joël Alwen, Moni Naor, Gil Segev, Shabsi Walfish and Daniel Wichs Crypto."— Presentation transcript:

1 Public Key Cryptography in the Bounded Retrieval Model Based on joint works with Joël Alwen, Moni Naor, Gil Segev, Shabsi Walfish and Daniel Wichs Crypto  Clouds Speaker: Yevgeniy Dodis (NYU)

2 Leakage Attacks  Standard Crypto Assumption: keys stored secretly.  Reality: information leaks  Timing attacks, Power consumption attacks, Freezing attacks, Hackers, Malware, Viruses…  Usual Crypto Response: not our problem.  Better Crypto Response: provably secure primitives that allow leakage.  Assume leakage arbitrary but incomplete.

3 Modeling Incomplete Leakage  Adversary can learn any efficiently computable function f : {0,1}*  {0,1} L of the secret key. L = Leakage Bound.  Relative leakage […, AGV09, DKL09, NS09, KV09]. Key size dependent on security parameter (e.g bits). Leakage L is dependent on key size (e.g. 50% of key size). Goal: Allow for large percentage of leakage. Problem: in reality, leakage may be large in absolute terms (e.g. L can be on scale of Kbs, Mbs or even Gbs) For example: hackers/malware/virus attacks. Many side-channel attacks.  More robust model: Bounded Retrieval Model

4 Modeling Incomplete Leakage  Adversary can learn any efficiently computable function f : {0,1}*  {0,1} L of the secret key. L = Leakage Bound. k = Security Parameter  Relative leakage […, AGV09, DKL09, NS09, KV09].  Bounded retrieval model (BRM) [Dzi06,CLW06,DP07,ADW09] Key size |SK| depends on security parameter k AND leakage bound L. (Note: must be more than L) Other efficiency parameters only depend on k. E.g., public key, communication, computation, read-locality. Goal: flexibly accommodate ANY leakage bound L ONLY by increasing |SK| and without impacting other parameters. OK for many applications since storage is extremely cheap.

5 Only Computation Leaks Information  Incomparable model of leakage [MR04, DP08, P09].  Each OP leaks a shrinking function of accessed data.  Positive: Allows for potentially unbounded overall amount of leakage L.  Doesn’t necessitate increasing secret-key size above L.  Negative:  Does not capture cold-boot attacks, malware, viruses.  Seems to require state and/or key evolution.  This talk: BRM

6 Crypto Primitives with Leakage  Inherent limitations to leakage-resilient non-interactive primitives.  Encryption Schemes: Leakage can only occur before and not after the adversary sees the ciphertext.  Existentially Unforgeable Signatures: Leakage must be smaller than size of a single signature. Opposite goal for standard signatures, incompatible with BRM.  Can have qualitatively stronger security w./interaction: (Encryption, Authentication, Authen. Key Agreement).  Leakage before and after, but not during, protocol execution.  Perfect forward secrecy: can learn secret keys entirely after the protocol execution.

7 Full Leakage Private Communication (Encryption) Partial LeakageNo Leakage Non-interactive: Timeline: Partial Leakage Interactive: Timeline: No Leakage Protocol Run (pk Alice, sk Alice ) Prior to CommunicationAfter Communication Prior to CommunicationAfter Communication pk Alice (pk Alice, sk Alice ) Enc(m; pk Alice ) pk Alice

8 Recent History  Relative Leakage.  Symmetric-Key Authenticated Encryption [DKL09]  Public-Key Encryption [AGV09, NS09, KV09]  Problems: 1) non-BRM, 2) no leakage after ciphertext.  Bounded Retrieval Model [Dzi06,CLW06].  Symmetric-Key Identification [Dzi06]  Symmetric-Key Authenticated Key Agreement [Dzi06,CDD + 07]  Secret Sharing [DP07]  Main Problem: Key distribution (i.e., symmetric-key).  Magnified in the BRM model

9 Our Results  Efficient (and only) constructions of many public-key primitives in the BRM:  [ADW09]: ID and “Signature” schemes, Interactive Encryption, Authentication and Authenticated Key Agreement (AKA). Based on Okamoto ID/Sigs. |SK| = (1+  ) · L Forward security.  [ADNSWW09]: Encryption schemes, IBE. Based on Gentry IBE. |SK| ≈ 2 · L No forward security  (necessary).

10  Leakage bound L. Security parameter k.  Secret key size: O(L), in some cases L(1+   )  Public key size: constant # of group elements  Communication: ID/Sig/AKA: constant # of group elements Enc/IBE: O(k) group elements  Data Accessed: O(k) group elements  Computation: O(k) exponentiations  Relative Leakage: all O(k) become O(1).  Solves open problem of [AGV09] for ID/Sigs Efficiency of Our Results Same as standard constructions!!!

11  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

12 Identification Schemes (pk Bob, sk Bob ) pk Bob Prover BobVerifier Alice accept Learning Stage (pk Bob, sk Bob ) pk Bob Impersonation Stage reject!

13 Leakage-Resilient Identification Learning Stage (pk Bob, sk Bob ) pk Bob Impersonation Stage reject!  Bob’s key can leak !!!  Pre-impersonation leakage: all in learning stage  Anytime leakage: can happen anywhere sk Bob Note: allow adaptive leakage!

14  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

15  PK = (G, g 1, g 2, z = g 1 x 1 · g 2 x 2 ), SK = (x 1, x 2 )  Bob → Alice: R = g 1 r 1 · g 2 r 2 for random r 1, r 2  Alice → Bob : random c  Bob → Alice: s 1 = r 1 − c · x 1 and s 2 = r 2 − c · x 2  Alice: accept iff R = g 1 s 1 · g 2 s 2 · z c  Key Properties:  Many possible SK’s (x 1, x 2 ) for fixed PK z  Security proof extracts a valid secret key (x 1 ’, x 2 ’)  WI: proof perfectly hides which (x 1, x 2 ) is used  DL  given one secret key, hard to find another Okamoto’s ID Scheme

16  Run Eve with known secret key SK = (x 1, x 2 )  Simulate leakage oracle honestly with (x 1, x 2 )  WI  even computat. unbounded Eve does not know which SK was used in learning stage  Eve’s leakage L < |SK|/2  SK still has min-entropy  Rewind Eve (with a new c’) during impersonation stage to extract a valid SK’ = (x 1 ’, x 2 ’)  Doubles leakage for “anytime leakage” case  If SK’  SK, solve discrete log  Pre-imper. leakage |SK|/2, anytime leakage |SK|/4 Relative Leakage-Resilience

17  By using ~ 1 /  generators, can tolerate L learn + 2L imper = (1 −  ) · |SK| :  Pre-impersonation leakage L = (1 −  ) · |SK|  Anytime leakage L = (½ −  ) · |SK|  Efficiency proportional to 1 /   Already solves open problem of [AGV09]  Independently discovered by [Katz09]  Can we extend to BRM? Relative Leakage-Resilience

18  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

19  Take any relative-leakage resilient ID scheme X  Choose N independent copies (pk i, sk i ) of X.  N proportional to the leakage parameter L  Set SK = (sk 1,…,sk N ). To run a new ID protocol:  Verifier chooses k random indices (i 1,…,i k )  Run X on the selected k instances  Accept iff all accept  Good: communication/computation complexity ~ k  Is this a proper (secure/efficient) BRM scheme?? Direct Products: Naive Attempt

20  Public key is long: PK = (pk 1,…,pk N ).  BRM only allows SK to be long!  Solution: use signatures to authenticate pk i.  Generate “master” signing key (SigKey,VerKey)  Set PK = VerKey (note: PK is short)  Compute certificate s i = Sig((i, pk i ), SigKey)  Store SK = (sk 1,…,sk N ) and Help =(s 1,…,s N ).  Erase SigKey (important!)  Include certificates (s i 1,…,s i k ) with proof Direct Products: Problem 1 Invisible Key Updates! store SigKey “offline” periodically refresh SK = (sk 1,…,sk N ) public key VerKey does not change ! secure as long as < L leakage between refreshes approaches “continuous leakage”, but without assuming “only computation leaks information”

21  Add an extra round to send indices (i 1,…,i k )  Destroys “  -protocol structure” of Okamoto  Bad for getting signatures via Fiat-Shamir  Solution: many  -protocols have first flow independent from public key  E.g., R = g 1 r 1 · g 2 r 2 independent from z = g 1 x 1 · g 2 x 2  Have verifier send (i 1,…,i k ) in the second flow, together with challenge c Direct Products: Problem 2

22  Seems very hard to prove security generically  Hope. Start with ℓ -leakage resilient scheme X  get L-resilient scheme X’, where L ~ N ℓ  Natural reduction: generate (N-1) keys honestly and set SK = {sk, honest keys}  Simulate leakage f(SK) by hardwiring known keys  But the output length is still L » ℓ. Illegal query!  In fact, can come up with (artificial) counter-examples Direct Products: Problem 3

23  Seems very hard to prove security generically  But works for the special case of Okamoto!  Entropy-Preservation Lemma. Assume:  Enc:  N   M is “good” approxim. list-decodable code  X = (x 1,…,x N )   N has “enough” min-entropy Then Y = Enc(X)[ j ] has “enough” min-entropy  Corollary: Apply to direct product code  Enc(x 1,…,x N )[i 1,…,i k ] = (x i 1,…, x i k )  [IJK06]: direct product code is approxim. list-decodable  Thus, “condense” entropy from N  log |  | to k  log |  | Direct Products: Our Solution

24  Seems very hard to prove security generically  But works for the special case of Okamoto!  Leakage L  SK = (sk 1,…,sk N ) has entropy  Entropy Lemma  (sk i 1,…,sk i k ) has entropy  Basic Okamoto recovers secret key sk’  k- direct product recovers all k keys ( sk ’ i 1,…, sk ’ i k )  (sk i 1,…,sk i k ) has entropy  likely  j s.t. sk ’ i j  sk ’ i j  Two different secret keys  break DL Direct Products: Our Solution

25  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

26  Communication O(k) more than basic Okamoto  Can we “aggregate” k protocols into 1?  Yes, can use entropy lemma again, by “concatenating” the Direct Product and the Reed-Solomon codes  The “aggregate” secret key sk * still has min-entropy  But still need to send k public keys (pk i 1,…,pk i k )   Can aggregate to single pk *, but how to authenticate?  Related to aggregate signatures, but harder…  Solution: use variant of BLS signatures by [SW08]  s[i] = (RO(i)  pk i ) X Compressing Communication

27  Pre-impersonation leakage L.  Secret key length |SK| = L · (1+  )  Everything else independent of L.  In particular,  Standard Model: O(k) communication.  RO Model: O(1) communication. Parameters of BRM ID Schemes

28  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

29  Standard security: Existential Unforgeability  Requires that leakage L < signature size  Forces large signature, incompatible with BRM  Might be too strong for many applications  More suitable notion: Entropic Unforgeability  Cannot forge signature if message has entropy k  Makes sense in the BRM model ! (call BRM-sig)  Enough for many applications  E.g., interactive encryption, authentication, AKA Leakage-Resilient Signatures

30  Apply Fiat-Shamir to any leakage-resilient, 3- round (public-coin) ID scheme:  Resulting signature scheme is:  Leakage-resilient (in RO model), for the same L  Anytime leakage  Existentially Unforgeable  Pre-imperson. leakage  Entropically Unforgeable  Scheme 1  Existent. Unforg. Sig. with L  |SK|/2  Scheme 1  Entropically Unforg. Sig. with L  |SK|  Scheme 3  BRM Signature with L  |SK| From ID to Signatures Same sig size as standard sigs!!!Solves open problem of [AGV09]

31  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

32  Example: Interactive Encryption  Sender → Receiver: random r  Receiver → Sender: BRM-Sig(r, enc. key pk)  Sender → Receiver: Enc(m, pk)  Receiver: Decrypt m, erase sk.  Similar trick for interactive authentication, AKA  Punchline: Interactive BRM authentication, encryption, authenticated key agreement with constant communication and forward secrecy Signatures  Interactive Primitives Message has entropy! Forward secrecy!

33 What does it mean? For example…  An efficient interactive encryption protocol with short public key and 10 GB secret key.  All other efficiency parameters “short” as well  A virus must download at least 5 GB of information to break privacy of messages sent  All messages transmitted prior to infection remain secure, even if virus learns the entire 10 GB key.  Major advantage over encryption [AGV09,NS09,KV09,ADNSWW09].  Almost as efficient as standard protocols.

34  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap Come to Daniel’s talk [ADNSWW09]. First (non-interactive) BRM encryption & IBE Tools: Gentry IBE (standard model). Entropy-preservation lemma again! Id-based Hash Proof Systems (generalizing [NS09])

35  Efficient (and only) constructions of many public-key primitives in the BRM  Encryption, Authentication, IBE, AKA, Sigs  BRM more flexible than relative leakage  Only |SK| depends on L, and storage is cheap  Future Directions:  Leakage of intermediate results “during protocol”  Continuous leakage (ala “invisible updates”)  More BRM tools: improved “entropy-preservation” lemma, leakage amplification, … Conclusions + Open Problems

36  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

37  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

38  Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap


Download ppt "Public Key Cryptography in the Bounded Retrieval Model Based on joint works with Joël Alwen, Moni Naor, Gil Segev, Shabsi Walfish and Daniel Wichs Crypto."

Similar presentations


Ads by Google