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. 1024 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