Public Key Cryptography in the Bounded Retrieval Model - PowerPoint PPT Presentation

About This Presentation
Title:

Public Key Cryptography in the Bounded Retrieval Model

Description:

Key size dependent on security parameter (e.g. 1024 bits) ... Other efficiency parameters only depend on k. ... bound L. Security parameter k. Secret key size: ... – PowerPoint PPT presentation

Number of Views:54
Avg rating:3.0/5.0
Slides: 36
Provided by: DanW73
Category:

less

Transcript and Presenter's Notes

Title: Public Key Cryptography in the Bounded Retrieval Model


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,1L 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,1L of the secret key.
    L Leakage Bound. k Security
    Parameter
  • Relative leakage , AGV09, DKL09, NS09, KV09.
  • Bounded retrieval model (BRM) Dzi06,CLW06,DP07,AD
    W09
  • 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.
  • Doesnt 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
Private Communication (Encryption)
(pkAlice, skAlice )
pkAlice
Non-interactive
Enc(m pkAlice)
Prior to Communication
After Communication
Partial Leakage
No Leakage
Timeline
(pkAlice, skAlice )
pkAlice
Interactive
Protocol Run
Prior to Communication
After Communication
Full Leakage
Partial Leakage
No Leakage
Timeline
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,CDD07
  • 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
Efficiency of Our Results
  • 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

11
Roadmap
  • 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

12
Identification Schemes
accept
pkBob
(pkBob, skBob )
Prover Bob
Verifier Alice
Learning Stage
Impersonation Stage
reject!
pkBob
pkBob
(pkBob, skBob )
13
Leakage-Resilient Identification
  • Bobs key can leak !!!
  • Pre-impersonation leakage all in learning stage
  • Anytime leakage can happen anywhere

Learning Stage
Impersonation Stage
reject!
pkBob
pkBob
(pkBob, skBob )
skBob
14
Roadmap
  • 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

15
Okamotos ID Scheme
  • PK (G, g1, g2, z g1x1 g2x2), SK (x1, x2)
  • Bob ? Alice R g1r1 g2r2 for random r1, r2
  • Alice ? Bob random c
  • Bob ? Alice s1 r1 - c x1 and s2 r2 - c
    x2
  • Alice accept iff R g1s1 g2s2 z c
  • Key Properties
  • Many possible SKs (x1, x2) for fixed PK z
  • Security proof extracts a valid secret key (x1,
    x2)
  • WI proof perfectly hides which (x1, x2) is used
  • DL?? given one secret key, hard to find another

16
Relative Leakage-Resilience
  • Run Eve with known secret key SK (x1, x2)
  • Simulate leakage oracle honestly with (x1, x2)
  • WI ? even computat. unbounded Eve does not know
    which SK was used in learning stage
  • Eves leakage L lt SK/2 ? SK still has
    min-entropy
  • Rewind Eve (with a new c) during impersonation
    stage to extract a valid SK (x1, x2)
  • Doubles leakage for anytime leakage case
  • If SK ? SK, solve discrete log
  • Pre-imper. leakage SK/2, anytime leakage SK/4

17
Relative Leakage-Resilience
  • By using 1 / ? generators, can tolerate Llearn
    2Limper (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?

18
Roadmap
  • 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

19
Direct Products Naive Attempt
  • Take any relative-leakage resilient ID scheme X
  • Choose N independent copies (pki, ski) of X.
  • N proportional to the leakage parameter L
  • Set SK (sk1,,skN). To run a new ID protocol
  • Verifier chooses k random indices (i1,,ik)
  • Run X on the selected k instances
  • Accept iff all accept
  • Good communication/computation complexity k
  • Is this a proper (secure/efficient) BRM scheme??

20
Direct Products Problem 1
  • Public key is long PK (pk1,,pkN).
  • BRM only allows SK to be long!
  • Solution use signatures to authenticate pki.
  • Generate master signing key (SigKey,VerKey)
  • Set PK VerKey (note PK is short)
  • Compute certificate si Sig((i, pki), SigKey)
  • Store SK (sk1,,skN) and Help (s1,,sN).
  • Erase SigKey (important!)
  • Include certificates (si1,,sik) with proof
  • Invisible Key Updates!
  • store SigKey offline
  • periodically refresh SK (sk1,,skN)
  • public key VerKey does not change !
  • secure as long as lt L leakage between refreshes
  • approaches continuous leakage, but without
  • assuming only computation leaks information

21
Direct Products Problem 2
  • Add an extra round to send indices (i1,,ik)
  • 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 g1r1 g2r2 independent from z g1x1
    g2x2
  • Have verifier send (i1,,ik) in the second flow,
    together with challenge c

22
Direct Products Problem 3
  • Seems very hard to prove security generically
  • Hope. Start with l-leakage resilient scheme X ?
    get L-resilient scheme X, where L Nl
  • 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 l. Illegal
    query!
  • In fact, can come up with (artificial)
    counter-examples

23
Direct Products Our Solution
  • 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 (x1,,xN) ? ?N has enough min-entropy
  • Then Y Enc(X) j has enough min-entropy
  • Corollary Apply to direct product code
  • Enc(x1,,xN)i1,,ik (xi1,, xik)
  • IJK06 direct product code is approxim.
    list-decodable
  • Thus, condense entropy from N?log ? to k?log
    ?

24
Direct Products Our Solution
  • Seems very hard to prove security generically
  • But works for the special case of Okamoto!
  • Leakage L ? SK (sk1,,skN) has entropy
  • Entropy Lemma ? (ski1,,skik) has entropy
  • Basic Okamoto recovers secret key sk ?
    k-direct product recovers all k keys
    (ski1,,skik)
  • (ski1,,skik) has entropy ? likely??j s.t.
    skij?skij
  • Two different secret keys ? break DL

25
Roadmap
  • 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

26
Compressing Communication
  • 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
    (pki1,,pkik) ?
  • Can aggregate to single pk, but how to
    authenticate?
  • Related to aggregate signatures, but harder
  • Solution use variant of BLS signatures by SW08
  • si (RO(i) ? pki)X

27
Parameters of BRM ID Schemes
  • 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.

28
Roadmap
  • 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

29
Leakage-Resilient Signatures
  • Standard security Existential Unforgeability
  • Requires that leakage L lt 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

30
From ID to Signatures
  • 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

31
Roadmap
  • 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

32
Signatures ? Interactive Primitives
  • 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

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
Roadmap
  • 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
  • Come to Daniels 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
Conclusions Open Problems
  • 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,

36
Roadmap
  • 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

37
Roadmap
  • 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

38
Roadmap
  • 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
Write a Comment
User Comments (0)
About PowerShow.com