1 / 37

Cryptography against continuous memory attacks

Cryptography against continuous memory attacks. NYU. Yevgeniy Dodis , Kristiyan Haralambiev , Adriana Lopez-Alt and Daniel Wichs. MIT/MSR Reading Group. Motivation: Leakage-Resilient Crypto. Security proofs in crypto require an adversarial attack model .

sarai
Download Presentation

Cryptography against continuous memory attacks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cryptography against continuous memory attacks NYU YevgeniyDodis, KristiyanHaralambiev, Adriana Lopez-Alt and Daniel Wichs MIT/MSR Reading Group

  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 functionsfare 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 Continuous One time Restricted Memory

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

  7. Model of CLR Security • Secret key can be updated using onlylocal randomness. • Public-key stays the same. • Other users do not need to know about updates. • Number of leakage queries bounded by Lin 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.

  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 sk • KeyGen()generates (pk, sk) pairs. • Relation R tests if (pk, sk) are valid. (pk, sk) ÃKeyGen() pk R(pk, sk)=1 Basic One-Wayness: Given pk, can’t find sk* s.t. R(pk,sk*) = 1.

  11. Main Technical Problem:CLR One-Way Relation sk Rerand(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. pk R(pk,sk)=1 Rerand Rerand Rerand …

  12. Main Technical Problem:CLR One-Way Relation sk Security • Adversary gets pk. • Can ask for up to L bits of information about sk. What’s the2ndbit of sk? pk What’s the 3rdbit of SHA-1(sk)?

  13. Main Technical Problem:CLR One-Way Relation sk Security • Adversary gets pk. • Can ask for up to L bits of information about sk. • Key is refreshed. pk

  14. Main Technical Problem:CLR One-Way Relation Security • Adversary gets pk. • Can ask for up to L bits of information about sk. • Key is refreshed. • Wins if R(pk, sk*) = 1. pk 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 All possible sk • For each public-key pk: • Valid: { sk : R(pk, sk) = 1}. • Good½Valid • Bad = Valid\Good • Can sample pkalongwith: • samG: Samples sk2Good. • samB : Samples sk2Bad. • dk : isGood(sk, dk) = 0/1. • Re-randomize inside Good. • Given pk, samG, sk 2Good: Rerand(sk) ¼Sample(samG) bad Valid for pk good

  18. Strategy for CLR-OWR Leakage Indistinguishable Re-randomizable Relation (LIRR) • Security • HardnessofGood Keys: • Given pk, samB, find sk*s.t. isGood(sk*, dk) = 1. • Hardnessof 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. Only “one-time memory attack”. bad good

  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 isgood] 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 E1, E2be two PKE and ¦ be a NIZK argument-system. • The LIRR scheme samples: • pk = (CRS, pk1, pk2, c1) where c1 = Encpk1(m;r) for randm. • 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). • Samplebadkeys with samB = TD (simulation trap-door). • Distinguish good/bad withdk = (sk1, sk2)

  22. Constructing LIRR • Re-randomization. • Hardnessof Good Keys. • Hardnessof Bad Keys. • L-Leakage-Indistinguishability.

  23. Constructing LIRR (Hardness) 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. • 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).

  24. Constructing LIRR • Re-randomization. • Hardnessof Good Keys. • Hardnessof Bad Keys. • L-Leakage-Indistinguishability.

  25. Constructing LIRR (Re-randomization) pk = (CRS, pk1, pk2, c1)sk = (c2, ¼). • To re-randomize sk = (c2, ¼) need to: • Re-randomize the ciphertext c2. (same message, fresh rand.) • Update the NIZK proof ¼(new statement, fresh rand).

  26. Constructing LIRR (Re-randomization) pk = (CRS, pk1, pk2, c1)sk = (c2, ¼). 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) ).

  27. Constructing LIRR • Re-randomization. (IfE1, E2, ¦ are “homomorphic”) • Hardnessof Good Keys. • Hardnessof Bad Keys. • L-Leakage-Indistinguishability.

  28. Constructing LIRR (Leakage Ind.) pk = (CRS, pk1, pk2, c1)sk = (c2, ¼). • To get leakage indistinguishability, need “something” from E2. • Given L bits of leakage on ctextc, can’t produce related ctextc’. • Adversary gets pk. Chooses m0, m1. • Challenger chooses b à {0,1}. Sets c = Enc(mb). • Adversary gets L bits of leakage on ciphertextc. • Adversary makes 1 decryption query on anyc*. 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?

  29. Constructing LIRR • Re-randomization. (IfE1, E2, ¦ are “homomorphic”) • Hardnessof Good Keys. • Hardnessof Bad Keys. • L-Leakage-Indistinguishability. (If E2 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 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, …).

  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

More Related