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

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)

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.

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

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.

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

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.

Full Leakage

Private Communication (Encryption)

Partial Leakage No Leakage

Non-interactive:

Timeline:

Partial Leakage

Interactive:

Timeline: No Leakage

Protocol Run

(pkAlice, skAlice )

Prior to Communication After Communication

Prior to Communication After Communication

pkAlice

(pkAlice, skAlice )

Enc(m; pkAlice)

pkAlice

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

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

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!!!

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

Identification Schemes

(pkBob, skBob ) pkBob

Prover Bob Verifier Alice

accept

Learning Stage

(pkBob, skBob ) pkBobpkBob

Impersonation Stagereject!

Leakage-Resilient Identification

Learning Stage

(pkBob, skBob ) pkBobpkBob

Impersonation Stagereject!

Bob’s key can leak !!! Pre-impersonation leakage: all in learning

stage Anytime leakage: can happen anywhere

skBob

Note: allow adaptive leakage!





Roadmap

PK = (G, g1, g2, z = g1x1 · g2

x2), SK = (x1, x2) Bob → Alice: R = g1

r1 · 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 · g2

s2 · z c

Key Properties: Many possible SK’s (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

Okamoto’s ID Scheme

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 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’ = (x1’, x2’) Doubles leakage for “anytime leakage” case

If SK’ SK, solve discrete log Pre-imper. leakage |SK|/2, anytime leakage |

SK|/4

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?

Relative Leakage-Resilience





Roadmap

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??

Direct Products: Naive Attempt

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

Direct Products: Problem 1

• Invisible Key Updates!• store SigKey “offline”• periodically refresh SK = (sk1,…,skN)• public key VerKey does not change !• secure as long as < L leakage between refreshes• approaches “continuous leakage”, but without assuming “only computation leaks information”

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 = g1

r1 · g2r2 independent from z = g1

x1 · g2x2

Have verifier send (i1,…,ik) in the second

flow, together with challenge c


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


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 Nlog || to klog ||

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 (sk’i1,

…,sk’ik)

(ski1,…,skik) has entropy likelyj s.t. sk’ijsk’ij

Two different secret keys break DL

Direct Products: Our Solution





Roadmap

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] s[i] = (RO(i) pki)X

Compressing Communication

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





Roadmap

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

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]





Roadmap

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!

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.





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])

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

Documents

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