1. CRYPTOGRAPHY AGAINST CONTINUOUS MEMORY ATTACKS Yevgeniy Dodis, Kristiyan Haralambiev, Adriana Lopez-Alt and Daniel Wichs MIT/MSR Reading Group NYU

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

3. 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. sk f f(sk)

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

5. 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 RestrictedMemory

6. Continuous Leakage + Memory Attacks? Question: Can we get the best of both worlds? Continuous Leakage Resilience (CLR)

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

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

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

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

11. 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)=1 Rerand …

12. 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 2 nd bit of sk ? What’s the 3 rd bit of SHA-1(sk) ? Security

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

14. 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* =

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

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

17. 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) good bad All possible sk Valid for pk

18. 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. good bad Leakage Indistinguishable Re-randomizable Relation (LIRR) Only “one-time memory attack”.

19. 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”.

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

21. Constructing LIRR  Let E 1, E 2 be two PKE and ¦ be a NIZK argument-system.  The LIRR scheme samples:  pk = (CRS, pk 1, pk 2, c 1 ) where c 1 = Enc pk1 (m;r) for rand m.  Secret-keys have form sk = (c 2, ¼ ). Valid sk: ¼ proves that “(c 1, c 2 ) encrypt same message”. Good sk: (c 1, c 2 ) 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 = (sk 1, sk 2 )

22. Constructing LIRR  Re-randomization.  Hardness of Good Keys.  Hardness of Bad Keys.  L-Leakage-Indistinguishability.

23. Constructing LIRR (Hardness)  Claim: The “hardness of good/bad keys” holds if E 1 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 c 1 (break one-wayness of E 1 ). pk = (CRS, pk 1, pk 2, c 1 ) sk = (c 2, ¼ ). samG = (m, r), samB = TD, dk = (sk 1, sk 2 )  Valid sk: ¼ proves that “(c 1, c 2 ) encrypt same message”.  Good sk: (c 1, c 2 ) actually encrypt same message.

24. Constructing LIRR  Re-randomization.  Hardness of Good Keys.  Hardness of Bad Keys.  L-Leakage-Indistinguishability.

25. Constructing LIRR (Re-randomization)  To re-randomize sk = (c 2, ¼ ) need to:  Re-randomize the ciphertext c 2. (same message, fresh rand.)  Update the NIZK proof ¼ (new statement, fresh rand). pk = (CRS, pk 1, pk 2, c 1 ) sk = (c 2, ¼ ).

26. Constructing LIRR (Re-randomization) Assume E 1, E 2, ¦ 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 “(c 1, c 2 ) encrypt the same message” is homomorphic.  Notice (c 1, c 2 + Enc(0;r)) = (c 1, c 2 ) + (Enc(0;0), Enc(0;r) ). pk = (CRS, pk 1, pk 2, c 1 ) sk = (c 2, ¼ ).

27. Constructing LIRR  Re-randomization. (If E 1, E 2, ¦ are “homomorphic”)  Hardness of Good Keys.  Hardness of Bad Keys.  L-Leakage-Indistinguishability.

28.  To get leakage indistinguishability, need “something” from E 2.  Given L bits of leakage on ctext c, can’t produce related ctext c’.  Adversary gets pk. Chooses m 0, m 1.  Challenger chooses b à {0,1}. Sets c = Enc(m b ). 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, pk 1, pk 2, c 1 ) sk = (c 2, ¼ ).

29. Constructing LIRR  Re-randomization. (If E 1, E 2, ¦ are “homomorphic”)  Hardness of Good Keys.  Hardness of Bad Keys.  L-Leakage-Indistinguishability. (If E 2 is L-LoC-NM)

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

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

32. Homomorphic Encryption  For E 1, use ElGamal (generalized to K-linear).  For E 2, use “Cramer-Shoup-Lite” Encryption (generalized).  Full Cramer-Shoup: CCA-2 secure. Not homomorphic. Enc(m;r) = (g r, h r, (f 0 ) r m, (f 1 ) r (f 2 ) r a ) where a = H(g r, h r )  Cramer-Shoup-Lite: Only CCA-1 secure. Is homomorphic. Enc(m;r) = (g r, h r, (f 0 ) r m, (f 1 ) 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) = (g r, h r, (f 0 ) r m, (f 1 ) r, (f 2 ) r, (f 3 ) r, …).

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

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

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

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

37. Thank you! ePrint Report 2010/196

38. Homomorphic Encryption  For E 1, use ElGamal (generalized to K-linear).  For E 2, use (generalization) of “Cramer-Shoup-Lite”.  CS-Lite is CCA-1 but not CCA-2 secure. It is homomorphic.  In general, CCA-1 security does not imply L-LoC-NM.  But “proof strategy” for CCA-1 generalizes to L-LoC-NM. Based on “1-universal hash proof system” (HPS). Used by [NS09] for leakage-resilient PKE. CS-Lite uses 2 copies of HPS. Use more copies for bigger L.  Can leak L/|c| = 1- ² fraction of ciphertext.

39. CS-Lite L-LoC-NM secure  Use 3 properties of CS-Lite.  “malformed ciphertexts” statistically hide the message (without sk).  Can’t distinguish malformed from normal ciphertext (even with sk).  To produce a malformed ciphertext, must know > L bits about sk.  Make challenge-ciphertext malformed.  Message is hidden, unless decryption queries give info about sk.  Only decryption of malformed ciphertexts reveals info about sk.  Argue that decryption query is normal.  To produce malformed ctxt, need > L bits of info about sk.  Only learn L bits from leakage queries on challenge ciphertext.

40.  Use “Cramer-Shoup-Lite” encryption:  Let g, h be generators of a group G of prime-order p.  sk = ((x 0, y 0 ), (x 1, y 1 ), …, (x n, y n ))  pk = (f 0 = g x0 h y0, f 1 = g x1 h y1, …, f n = g xn h yn )  Enc(m) = ( g r, h r, (f 0 ) r m, (f 1 ) r, …, (f n ) r )  To decrypt: (g r ) xi (h r ) yi = (f i ) r  Theorem: The “Cramer-Shoup-Lite” encryption scheme is L-LoC-NM where L ¼ n log(p). It is homomorphic. Constructing LIRR (Leakage Ind.)

41. Constructing LIRR (Re-randomization)  If E 1, E 2, ¦ are homomorphic, then can re-randomize sk.  To Re-randomize sk = (c 2, ¼ ) :  Choose c 2 ’ = Enc pk2 (0; r 2 ’). Let c 2 * = c 2 + c 2 ’.  Let ¼ ’ be proof that (0, c 2 ’) encrypt same msg. 0 = Enc pk1 (0; 0).  So ¼ * = ¼ + ¼ ’ proves (c 1, c 2 *) encrypt the same message. Since (c 1, c 2 *) = (c 1, c 2 ) + (0, c 2 ’)  And (c 2 *, ¼ * ) is a perfectly re-randomized key. pk = (CRS, pk 1, pk 2, c 1 ) sk = (c 2, ¼ ).

42. Constructing CLR-OWR from Components  Constructed L-CLR-OWR from an L-LIRR.  Constructed L-LIRR from PKE E 1, E 2, NIZK ¦ such that:  E 1 is “one-way secure” and homomorphic.  E 1 is L-LoC NM and homomorphic.  ¦ is a homomorphic NIZK for the homomorphic language: “(c 1, c 2 ) encrypt the same message”  Left to do: instantiate PKE E 1, E 2, NIZK ¦.

43. Outline of CLR-OWR Construction  1. Reduce to “one-time memory attacks” on LIRR.  2. Build LIRR from simpler generic components.  3. Instantiate the components.

44. Constructing LIRR (Re-randomization)  To re-randomize sk = (c 2, ¼ ) need to:  Re-randomize the ciphertext c 2. (same message, fresh rand.)  Update the NIZK proof ¼ (new statement, fresh rand).  Possible if E 1, E 2, ¦ are homomorphic over some groups.  Hom. Encryption: Enc(m; r) + Enc(m’; r’) = Enc(m + m’; r + r’).  New notion of “homomorphic NIZK”  Influenced by re-randomizable and malleable NIZKs [BCC+09].  Can be instantiated using Groth-Sahai NIZKS.  For some very specific “homomorphic” languages over groups.  Requires the use of “K-linear assumption” in bilinear groups. pk = (CRS, pk 1, pk 2, c 1 ) sk = (c 2, ¼ ).

45. 2. Constructing LIRR (Re-randomization)  To re-randomize sk = (c 2, ¼ ) need to:  Re-randomize the ciphertext c 2. (same message, fresh rand.)  Update the NIZK proof ¼ (new statement, fresh rand).  Need: E 1, E 2, ¦ are homomorphic over some groups.  Hom. Encryption: Enc(m; r) + Enc(m’; r’) = Enc(m + m’; r + r’).  Hom. Relation: (x, w) 2 R, (x’, w’) 2 R ) (x + x’, w + w’) 2 R.  Hom. NIZK: ¼, ¼ ’ proofs for x, x’ ) ¼ + ¼ ’ is a proof for x+x’. pk = (CRS, pk 1, pk 2, c 1 ) sk = (c 2, ¼ ). samG = (m, r), samB = TD, dk = (sk 1, sk 2 )  Valid sk: ¼ proves that “(c 1, c 2 ) encrypt same message”.  Good sk: (c 1, c 2 ) actually encrypt same message.

46. 2. Constructing LIRR (Rerandomization)  To Re-randomize sk = (c 2, ¼ ) :  Choose c 2 ’ = Enc pk2 (0; r 2 ’). Let c 2 * = c 2 + c 2 ’.  Let ¼ ’ be proof that (0, c 2 ’) encrypt same msg. 0 = Enc pk1 (0; 0).  So ¼ + ¼ ’ is a proof that (c 1, c 2 *) encrypt the same message. Since (c 1, c 2 *) = (c 1, c 2 ) + (0, c 2 ’)  And (c 2 + c 2 ’, ¼ + ¼ ’) is a (perfectly) re-randomized key. pk = (CRS, pk 1, pk 2, c 1 ) sk = (c 2, ¼ ). samG = (m, r), samB = TD, dk = (sk 1, sk 2 )  Valid sk: ¼ proves that “(c 1, c 2 ) encrypt same message”.  Good sk: (c 1, c 2 ) actually encrypt same message.

47. Prior Work on Leakage-Resilience  Memory Attacks [AGV09] : PKE: [AGV09, NS09, ADNS+10, DHLW10] Signatures: [ADW09, KV09, DHLW10] ID/AKA: [ADW09, DHLW10]  Extensions of Memory Attacks: Bounded Retrieval Model: [Dzi06, CLW06, ADW09, ADNS+10] Aux. Input : [DKL09, DGK+10] Noisy/Graceful: [NS09, GKPV10]  Continuous Leakage:  Only Computation Leaks Information: [MR04, DP08] Stream Cipher [DP08, Pie09] Signatures [KKPR10], Other [MR04, JRV10].  Other Restrictions: [FRRTV10, ISW03].