CRYPTOGRAPHY AGAINST CONTINUOUS MEMORY

ATTACKSYevgeniy Dodis, Kristiyan

Haralambiev, Adriana Lopez-Alt and Daniel Wichs

MIT/MSR Reading Group

NYU

Motivation: Leakage-Resilient Crypto

Security proofs in crypto require an adversarial attack model. e.g. adversary sees public-keys but not secret-keys.

Reality: schemes broken using attacks outside of model. Side-channels: timing, power consumption, heat,

acoustics, radiation. The cold-boot attack. Hackers, Malware, Viruses.

Usual Crypto Response: Not our problem. Blame the Engineers…

Leakage-Resilient Crypto: Let’s try to help. Primitives that provably allow some leakage of secret key.

Modeling Leakage

During an attack, adversary can query “leakage-oracle” with “leakage-functions” f : {0,1}* ! {0,1}. Learns f(sk).

Need to restrict leakage so adv. does not learn sk in full. Bound number of queries during various stages of

attack. Restrict type of allowed leakage-functions.

skf

f(sk)

Modeling Leakage

Type: Restricted functions vs. Memory Attacks. Restricted leakage functions f.

Individual bits, AC0 circuits... [Riv97, ISW03, FRR+10, …] “Only computation leaks information” [MR04, DP08]

Memory Attacks [AGV09]: All efficient functions f are legal.

Amount: One-Time vs. Continuous. One-time: Total number of leakage queries is bounded by

L. Continuous:

The secret key of the scheme gets updated periodically. Number of queries is bounded by L in each “period” but not

overall.

Prior Work

OCLI Stream Cipher OCLI Signatures [DP08, Pie09, KKPR10]

General Computation [ISW03, FRRTV10, JRV10].

?All-Or-Nothing-

Transform (AONT)[Riv97, Boy99, CDH+00, DSS01, KZ03]

PKE [AGV09, NS09, ADNS+10, DHLW10]

Signatures [ADW09, KV09, DHLW10]

ID/AKA [ADW09, DHLW10]

Other: [Dzi06, CLW06, ADW09, DKL09, ADNS+10, DGK+10, GKPV10]

Continuous

One time

Restricted Memory

Continuous Leakage + Memory Attacks?

Question: Can we get the best of both worlds?

Continuous Leakage Resilience (CLR)

Secret key can be updated using only local randomness. Public-key stays the same. Other users do not need to know about updates.

Number of leakage queries bounded by L in between updates. No bound on number of queries over the lifetime of the

system.

No restriction on the type of leakage (memory attacks). Adversary cannot predict randomness for future updates. (No leakage during the update).

Efficiency does not degrade with the number of updates.

Model of CLR Security

Initial Steps Towards CLR

[ADW09]: Construct CLR signatures but updates require an “external master key” that never leaks.

[BKKV10]: Construct CLR signatures, but… Requires a non-standard and non-black-box

assumption. Uses PCP theorem, so not practical. (Main results to follow. Stay tuned…)

Our Results

Build the first CLR schemes under standard assumptions (K-Linear in bilinear groups). Signatures, ID schemes, Authenticated-Key-

Agreement

In each period, leak up to ½ of the secret key.

All schemes are efficient/practical.

Main technical result: CLR One-Way Relation.

Main Technical Problem:CLR One-Way Relation

pk

sk

R(pk, sk)=1

(pk, sk) Ã KeyGen()

• KeyGen() generates (pk, sk) pairs. • Relation R tests if (pk, sk) are valid.

Basic One-Wayness: Given pk, can’t find sk* s.t. R(pk, sk*) = 1.

Main Technical Problem:CLR One-Way Relation

pk

sk

• KeyGen() generates (pk, sk) pairs. • Relation R tests if (pk, sk) are valid.• Rerand(sk) refreshes the secret key.• Can refresh arbitrarily many times.

Rerand(sk)

R(pk, sk)=1Rerand Rerand Rerand

…

Main Technical Problem:CLR One-Way Relation

pk

sk Adversary gets pk.

Can ask for up to L bits of information about sk.What’s the 2nd bit of

sk ?What’s the 3rd bit of

SHA-1(sk) ?

Security

Main Technical Problem:CLR One-Way Relation

pk

sk Adversary gets pk.

Can ask for up to L bits of information about sk.

Key is refreshed.

Security

Main Technical Problem:CLR One-Way Relation

pk

Adversary gets pk. Can ask for up to L

bits of information about sk.

Key is refreshed. Wins if R(pk, sk*)

= 1.

Security

sk* =

Difficulty of Constructing CLR-OWR

In a reduction, need to know many valid secret-keys in full.

Nevertheless, need to solve some hard problem given a valid forgery by the adversary.

Hope: forgery of different type then secret-keys we know.

Adversary gets unbounded amount of information in total. Why can’t it “learn” the type?

Outline of Construction

1. General strategy to handle continuous leakage. Reduce “continuous leakage” to “one-time leakage”.

2. Construction from (special) PKE/NIZK.

3. Instantiate components based on DDH/K-Linear.

Strategy for CLR-OWR

For each public-key pk: Valid: { sk : R(pk, sk) = 1}. Good ½ Valid Bad = Valid \ Good

Can sample pk along with: samG : Samples sk 2 Good. samB : Samples sk 2 Bad. dk : isGood(sk, dk) = 0/1.

Re-randomize inside Good. Given pk, samG, sk 2 Good :

Rerand(sk) ¼ Sample(samG)

goodbad

All possible sk

Valid for pk

Strategy for CLR-OWR

Security Hardness of Good Keys:

Given pk, samB, find sk* s.t. isGood(sk*, dk) = 1.

Hardness of Bad Keys: Given pk, samG, find sk* s.t. isGood(sk*, dk)

= 0. L-Leakage-Indistinguishability:

Adv. gets pk, samG, samB. Challenger randomly chooses {good, bad}

key sk. Adv. gets L bits of leakage on sk. Wins if produces sk* in the same category as

sk.

goodbad

Leakage Indistinguishable Re-randomizable Relation (LIRR)

Only “one-time memory attack”.

1. LIRR ) CLR-OWR

Claim: An L-LIRR is a L-CLR-OWR Proof:

Adversary only sees random good keys. Forgery must be a good key by “hardness of bad keys”.

One-by-one, switch good keys for bad keys. Pr[forged key is good] does not decrease by “L-Leakage-

Ind.”. Adversary only sees bad keys. Yet forgery is good.

Contradicts “hardness of good keys”.

Outline of Construction

1. General strategy to handle continuous leakage. Reduce “continuous leakage” to “one-time leakage”.

2. Construction from (special) PKE/NIZK.

3. Instantiate components based on DDH/K-Linear.

Constructing LIRR

Let E1, E2 be two PKE and ¦ be a NIZK argument-system.

The LIRR scheme samples: pk = (CRS, pk1, pk2, c1) where c1 = Encpk1(m;r) for rand m. Secret-keys have form sk = (c2, ¼).

Valid sk: ¼ proves that “(c1, c2) encrypt same message”. Good sk: (c1, c2) actually encrypt the same message.

Sample good keys with samG = (m , r). Sample bad keys with samB = TD (simulation trap-door). Distinguish good/bad with dk = (sk1, sk2)

Constructing LIRR

Re-randomization.

Hardness of Good Keys. Hardness of Bad Keys. L-Leakage-Indistinguishability.

Constructing LIRR (Hardness)

Claim: The “hardness of good/bad keys” holds if E1 is “one-way secure” (weaker than semantic-sec) and ¦ is sound.

Proof: Given samG = (m , r), producing a bad key, requires

proving an invalid statement (break soundness). Given samB = TD, producing a good key inverts c1

(break one-wayness of E1).

pk = (CRS, pk1, pk2, c1) sk = (c2, ¼).

samG = (m , r) , samB = TD , dk = (sk1, sk2)

Valid sk: ¼ proves that “(c1, c2) encrypt same message”. Good sk: (c1, c2) actually encrypt same message.

Constructing LIRR

Re-randomization.

Hardness of Good Keys. Hardness of Bad Keys. L-Leakage-Indistinguishability.

Constructing LIRR (Re-randomization)

To re-randomize sk = (c2, ¼) need to: Re-randomize the ciphertext c2. (same message,

fresh rand.) Update the NIZK proof ¼ (new statement, fresh

rand).

pk = (CRS, pk1, pk2, c1) sk = (c2, ¼).

Constructing LIRR (Re-randomization)

Assume E1, E2, ¦ are homomorphic over some groups.

Hom. Encryption: Enc(m; r) + Enc(m’; r’) = Enc(m + m’; r + r’).

Hom. Language: x 2 L, x’ 2 L ) x + x’ 2 L.

Hom. NIZK for Hom. Language. If ¼, ¼’ are proofs of x, x’ then ¼ + ¼’ is a proof of x+x’. Notion of re-randomizable/malleable NIZKS defined in [BCC+09].

Language “(c1, c2) encrypt the same message” is homomorphic. Notice (c1 , c2 + Enc(0;r)) = (c1, c2) + (Enc(0;0), Enc(0;r) ).

pk = (CRS, pk1, pk2, c1) sk = (c2, ¼).

Constructing LIRR

Re-randomization. (If E1, E2, ¦ are “homomorphic”)

Hardness of Good Keys. Hardness of Bad Keys. L-Leakage-Indistinguishability.

To get leakage indistinguishability, need “something” from E2.

Given L bits of leakage on ctext c, can’t produce related ctext c’. Adversary gets pk. Chooses m0, m1. Challenger chooses b à {0,1}. Sets c = Enc(mb).

Adversary gets L bits of leakage on ciphertext c. Adversary makes 1 decryption query on any c*. Wins if guesses

b. Call this L-“Leakage-of-Ciphertext Non-Malleability” (L-LoC-NM).

Notice: Non-malleable Enc ) |m|-LoC-NM ) CPA. But we need L-LoC-NM + Homomorphic encryption! Is it possible?

Constructing LIRR (Leakage Ind.)

pk = (CRS, pk1, pk2, c1) sk = (c2, ¼).

Constructing LIRR

Re-randomization. (If E1, E2, ¦ are “homomorphic”)

Hardness of Good Keys. Hardness of Bad Keys. L-Leakage-Indistinguishability. (If E2 is

L-LoC-NM)

Outline of Construction

1. General strategy to handle continuous leakage. Reduce “continuous leakage” to “one-time leakage”.

2. Construction from (special) PKE/NIZK.

3. Instantiate components based on DDH/K-Linear.

Homomorphic NIZKs

Groth-Sahai NIZKs are homomorphic for “systems of equations” over prime-order groups (with a pairing).

Secure under K-linear assumption for any K¸ 1. 1-linear = DDH. Can only hold for “asymmetric

pairings” (two base groups are different). 2-linear is a standard assumption for symmetric

and asymmetric pairings. K-linear assumption gets weaker as K grows.

Homomorphic Encryption

For E1, use ElGamal (generalized to K-linear).

For E2, use “Cramer-Shoup-Lite” Encryption (generalized). Full Cramer-Shoup: CCA-2 secure. Not homomorphic.

Enc(m;r) = (gr , hr, (f0)r m, (f1)r (f2)r a ) where a = H(gr , hr)

Cramer-Shoup-Lite: Only CCA-1 secure. Is homomorphic.Enc(m;r) = (gr , hr, (f0)r m, (f1)r )

In general, CCA-1 security does not imply L-LoC-NM. But proof technique extends to show L-LoC-NM for L ¼

¼|c|. Can generalize scheme to get L-LoC-NM for L ¼ (1-²)|c|.

Enc(m;r) = (gr , hr, (f0)r m, (f1)r , (f2)r, (f3)r, …).

Summary of CLR-OWR

Construct L-CLR-OWR based on the K-linear assumption.

Relative leakage L/|sk| > 1/(K+1).

1/2 for DDH , 1/3 for 2-linear.

“Practical Efficiency”: Constant number of group elements, group

operations.

Applications

Build CLR signatures, ID schemes, Authenticated-Key-Agreement (AKA) generically from CLR-OWR, using prior techniques [ADW09, KV09, DHLW10]. Preserve leakage L and “relative leakage” L/|sk|. Can even preserve efficiency!

Extensions

Leakage-of-Randomness of Computation: So far, only assumed that sk leaks. For signatures (and ID/AKA) need to hide “local

randomness”. Can be done. Standard model for ID. RO model for Sigs/AKA.

Bounded-Retrieval Model (BRM): Allow “huge” amount of leakage, by increasing secret-

key size. Does not effect efficiency (pk size, signature size,

computation).

(More extensions in the paper.)

Follow-up Results of [BKKV10]

Show how to do CLR Public-Key Encryption, IBE. Under 2-linear assumption. Leads to alternate construction of signatures

(worse leakage).

Show all CLR OWR/Signature/Encryption schemes also allow small (logarithmic) leakage of the update process.

Thank you!

ePrint Report 2010/196