1 / 50

Leakage- Resilient Cryptography: Recent Advances

Leakage- Resilient Cryptography: Recent Advances. Petros Mol. Research Exam. May 20, 2010. Cryptography in the ideal world. KeyGen() sk $ SK pk  f return pk Encrypt(m) r c  … return c Decrypt($%^#) m  f ( $%^#) return m. Primitives as mathematical objects.

dwightb
Download Presentation

Leakage- Resilient Cryptography: Recent Advances

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. Leakage- Resilient Cryptography: Recent Advances Petros Mol Research Exam May 20, 2010

  2. Cryptography in the ideal world KeyGen() sk$ SK pk  f return pk Encrypt(m) r c  … return c Decrypt($%^#) m  f ($%^#) return m • Primitives as mathematical objects • Restricted interaction between primitive and user/attacker • Secret information completely hidden from the adversary hidden visible

  3. Cryptography in the ideal world • > 30 years of extensive research • Primitives and notions for all tastes… • CPA/CCA encryption, UFCMA signature schemes • Collision resistant hash functions • NIZK protocols with honest but curious verifiers etc. • fully homomorphic encryption • … and from many hardness assumptions • Number theoretic: Factoring, DLP, DDH,QR,... • Lattice based: GapSVP, uSVP,…

  4. Ideal world: State of the art (comp/nal) hardness assumptions primitives reductions • Provable Security: Any (efficient) adversary that “breaks” primitive Π, implies an efficient algorithm against a problem considered to be hard Unless a major algorithmic breakthrough happens, things look good

  5. Cryptography in the real world • Protocols are executed in actual physical devices • Adversary can attack the implementation of a protocol • Interaction between adversary and primitive much less restricted • secret information no longer perfectly hidden from the adversary

  6. Real World situation • Systems vulnerable to such attacks • Smart cards • General/specific purpose hardware • Software implementations • Primitives vulnerable to such attacks • All primitives actually implemented on a physical device

  7. Side-Channel Attacks definition: an attack based on extra information gained by the physical implementation of a protocol …from Side Channel Attacks Database • The decade 1999-2008 • over 600 publications • over 50 patents • 19 PhD theses

  8. Side-Channel Attacks (from computation) • Timing Attacks: secret key information leaked as a result of of measuring execution time • Power Analysis: • power consumption measurements reveal • sequence of instructions executed • Fault Induction: • secret information revealed as a result of • execution of erroneous operation

  9. Cold-boot (memory) attacks [HSH+, USENIX Security 08] • standard DRAM cells refresh interval: ~ms • in practice cells retain content for much longer • ~ 30o C : complete loss only after tens of seconds At low temperatures (-50o C) contents might be retained for minutes or hours

  10. Memory (cold-boot) attacks • - bits decay to known “ground states” following predictable patterns 5 sec 30 sec 1 min 5 min

  11. A (very partial) list of attacks

  12. HW/Implementation-level countermeasures • “Obfuscate” computation by decreasing the Signal-to-Noise Ratio • Perform random operations • Randomize the execution sequence • Decorrelate input from intermediate values • Consistency checks • Run (parts of the) algorithm twice and check if results coincide • Reduce information leaked about the key • Encrypt key in memory • Avoid storing redundant info about the key Timing & Power analysis Fault Induction Cold boot attacks

  13. HW/Implementation-level countermeasures • Ad-hoc: target specific side channel attacks • Expensive: • hardware level masking very costly • train programmers to write and maintain code that minimizes leakage • incur significant slowdowns in the running time • Insufficient: Can only decrease the efficiency of the attack but not completely eliminate it

  14. Design process in practice 1st const. 2nd const. nth const. fix fix . . . fix Side-chan. attack 2 Side-chan. attack 1

  15. Idealizing the Real world assumptions primitives Q: Can we construct primitives that are provable securein the presence of side-channel information ? reductions

  16. Rest of talk •  Leakage Resilient Cryptography • Modeling Leakage Formally • Continuous Leakage • Bounded (Memory) Leakage • Auxiliary Input • Security Definitions / Overview of techniques • Example 1: LR stream cipher • Example 2: LR password authentication •  Conclusions • Has the picture changed ? • Future Directions

  17. Leakage-Resilient Cryptography (LRC) • Approach: It is impossible to • prevent side-channel attacks • predict all possible ways side-channel information can be collected by an attacker • Face the truth: Devices are not black-boxes • No restriction on how the adversary obtains side-channel information • only on whatinformation he can obtain. • Ultimate Goal: Develop Cryptography that is secure against wide classes of leakage

  18. Modeling Side-Channel information [Micali, Reyzin 04: Physically Observable Cryptography] separation of functionality and implementation Physically implemented primitive Π Abstract functionality Associated leakage A: implementation independent L: HW / implementation specific Π= (A, L)

  19. Modeling Side-Channel information leakage oracle • Adversary has access to a leakage oracle that models all sources of side channel information

  20. Micali- Reyzin model (somewhat relaxed) at i-th execution round Randomness (environmental noise) Adversarially chosen (measurement) Secret (internal) state of the protocol Compactly (randomized f, Mi encoded in f) ** For stateless primitives Si might simply the secret key**

  21. Modeling Leakage for Cryptography Universal Requirement 1 [MR04, Axiom 5] Leaked information is efficiently computable Universal Requirement 2 Given it shouldn’t be trivial to recover Si [MR04, Fundamental Physical Assumption] physical implementations of primitives s.t. leakage does not reveal the entire secret state

  22. (Partial) Taxonomy of Derived Models • Type (family) of f • restricted • arbitrary This talk • Domain (effective input) of f • entire secret state • active state [MR04, Axiom 1] Only Computation leaks Information • Range of f ( ) • bounded : • unbounded :

  23. (Partial) Taxonomy of Derived Models Each model might or might not be appropriate depending on the actual practical setting

  24. Leakage Models: Comparison/Discussion • continuous leakage • fails to capture memory attacks • proofs rely on the fact that parts of the key don’t participate in the computation • bounded (memory) leakage • captures scenarios where attacker has one-shot • are not very realistic in settings where many computations take place • auxiliary input • somehow combines best of both worlds • requires exponential hardness of the leakage function  hard to interpret what that means in practice

  25. Outline • Leakage Resilient Cryptography • Modeling Leakage Formally • Continuous Leakage • Bounded (Memory) Leakage • Auxiliary Input • Security Definitions / Overview of techniques • Example 1: LR stream cipher • Example 2: LR password authentication • Conclusions • Has the picture changed ? • Future Directions

  26. New Security Definitions Pseudorandom Functions (PRFs) (without leakage) • Security of PRFs: Given pairs (for x’s of his choice) no efficient adversary can tell which world he interacts with. REAL IDEAL

  27. New Security Definitions Pseudorandom Functions (PRFs) (with leakage) • Trivial Attack (single query, 1 bit of leakage) Adversary encodes x in f If output “REAL” else “IDEAL” REAL IDEAL

  28. Security in the presence of leakage Weak PRFs • Security of weak PRFs: Given pairs (for random x’s) no efficient adversary can tell which world he interacts with. REAL IDEAL Q: Can we prove leakage resilience of wPRFs? A:Yes (but security degrades exponentially in the leakage)

  29. Weak PRFs are leakage resilient. [Pietrzak 09: A Leakage-Resilient Mode of Operation] • Define • F: ε-wPRF: for all PPT adversaries A Theorem (informal) [Pietrzak 09] Assume such that . If ε-wPRF for uniform keys, then δ-wPRF for keys K drawn according to , where

  30. Towards constructing a LR- stream cipher • Why ``only computation leaks information” ? • Π: stateful primitive • State update (round i): • Upper bound on |Si| : M Leakage function takes the whole state as input Attack (1 bit of leakage per round) At round i: adversary queries leakage function After M queries, adversary gets SM scheme completely broken!!

  31. Stream Cipher in the continuous leakage model F: weak PRF State Update uses part of the state Computation

  32. Leakage-resilient Stream Cipher Update rule: • K2i , K2i+1 evolve “independently” • Intuition: If F is instantiated with a weak PRF and K, X have high min-entropy, then the output F(K,X) has high (pseudo-)entropy, even given the leakage f(K ,X)

  33. Outline • Leakage Resilient Cryptography • Modeling Leakage Formally • Continuous Leakage • Bounded (Memory) Leakage • Auxiliary Input • Security Definitions / Overview of techniques • Example 1: LR stream cipher • Example 2: LR password authentication • Conclusions • Has the picture changed ? • Future Directions

  34. Bounded leakage model (toy example) Password Authentication (w/o leakage) client secure channel server (g, y=g(x)) (sk=x) insecure storage secure storage Problem: Client wants to authenticate itself to the server • Solution: Use One-Way Functions (OWF) . g is OWF • easy to compute • hard to invert • for all efficient A

  35. Password Authentication (with leakage) client secure channel server (g, y=g(x)) (sk=x) f(x) insecure storage Problem: Attacker gets in addition l bits of leakage • Solution: Use l-Leakage-Resilient-OWF . g is l-LR-OWF • - … hard to invert. For all efficient A leakage

  36. Password Authentication (with leakage) • Observation:OWFs imply l-LR-OWFs with exponential (in l) loss in security Proof Idea Inverter (I) with Leakage Advantage: ε Inverter Input: (g,y=g(x)) x’

  37. Password Authentication (with leakage) client secure channel server Q: Can we avoid this exponential loss in security? (g, y=g(x)) (sk=x) f(x) insecure storage Using OWF g, the authentication protocol can resist l bits of leakage assuming g is - - hard to invert.

  38. Password Authentication (with leakage) Workaround: Second Preimage Resistant Functions • is SPRF if: • easy to compute • given x, h hard to find such that h(x’)=h(x) Known constructions of SPRFs from number-theoretic assumptions

  39. Password Authentication (with leakage) • [Theorem (informal)]: If SPRF with then h is l-LR-OWF with Proof Idea Inverter (I) with Leakage Advantage: ε A Input: (x, h) Output: x’ if x’

  40. Password Authentication (with leakage) Inverter (I) with Leakage Advantage: ε A Input: (x, h) Output: x’ if x’ But and Even given y= h(x) AND leakage = f(x) there exist on average preimages for y

  41. Security definitions for PKE • Standard ind/lity under chosen plaintext attacks (IND-CPA) 1.(sk,pk)  KeyGen 2.(m0,m1,state)  A1(pk) 3.c* Enc(pk,mb) 4.b’ A2(c*,state) 5.if (b’=b) return 1, else return 0

  42. Security definitions for PKE • ind/lity under chosen plaintext attacks with leakage (l-leakage-CPA) 1.(sk,pk)  KeyGen 2.(m0,m1,state)  A1(pk,f(sk,pk)) 3.c* Enc(pk,mb) 4.b’ A2(c*,state) 5.if (b’=b) return 1, else return 0 Adversary can query any (PT) leakage function f No leakage allowed after the creation of the challenge c*

  43. LRC: Primitives (overview) LR PKE (gen. mod) LR- Stream Cipher Simplified LR- SC Continuous Leakage LR st/ful sig/res 2008 2009 2010 I I I CPA/CCA SKE sign/res gen. const. CPA-PKE, IBE Bounded Leakage & Auxiliary Input CPA PKE CPA / CCA-PKE, generic constructions improved leakage

  44. Outline • Leakage Resilient Cryptography • Modeling Leakage Formally • Continuous Leakage • Bounded (Memory) Leakage • Auxiliary Input • Security Definitions / Overview of techniques • Example 1: LR stream cipher • Example 2: LR password authentication • Conclusions • Has the picture changed ? • Future Directions

  45. LRC in designing process 1st const. 2nd const. nth const. fix fix . . . fix Before Side-chan. attack 2 Side-chan. attack 1 • Consider classes of leakage functions that are as rich as possible (and for which there is a proof) • Construct primitives that are provably leakage resilient with respect to • Design hardware/ Write code whose leakage is faithfully modeled by Now

  46. LRC in designing process 1st const. 2nd const. nth const. fix fix . . . fix Before Side-chan. attack 2 Side-chan. attack 1 • Consider classes of leakage functions that are as rich as possible (and for which there is a proof) • Construct primitives that are provably leakage resilient with respect to • Design hardware/ Write code whose leakage is faithfully modeled by Now

  47. How LRC changed the picture ? • Cons • Modeling gaps (more on that in the next slide) • constructions and models more tailored to proof techniques rather than to practical needs. • some models unintuitive and hard to interpret in practice. • Performance implications: • for same level of security size of secret keys might get much longer  more storage, slower operations Pros • Brought Side-Channel attacks (closer) to theoreticians’ attention and improved their understanding on the subject. • Set basis for formal treatment of a serious practical problem • Can potentially bring Cryptography closer to hardware designers : clearer engineering goals (though not easy ones)

  48. More on Modeling Gaps • What does it mean in practice for a smart card, to leak at most k bits per encryption? • Modeling leakage as an uninvertible function makes proofs go through but doesn’t make engineers’ life any easier. • Adversary has no access to leakage oracle once given the challenge. Does this make sense? • (byproduct of considering arbitraryleakage functions)

  49. Outline • Leakage Resilient Cryptography • Modeling Leakage Formally • Continuous Leakage • Bounded (Memory) Leakage • Auxiliary Input • Security Definitions / Overview of techniques • Example 1: LR stream cipher • Example 2: LR password authentication • Conclusions • Has the picture changed ? • Future Directions

  50. Look to the future • Construct more Leakage Resilient primitives • … that resist more leakage • … from more hardness assumptions • Flexible LR constructions: • Design independent of leakage • Security degrades with leakage but in the absence of leakage primitive as secure as a leakage-free ones rob/ness of assumptions vs rob/ness of costructions [Goldwasser, Kalai, Peikert, Vaikuntanathan 10: Robustness of LWE • Allowing (restricted) access to the leakage oracle after the creation of the challenge. • - How does this affect security guarantees?

More Related