Download presentation

Presentation is loading. Please wait.

Published byHester Jefferson Modified about 1 year ago

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

Similar presentations

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google