Leakage- Resilient Cryptography: Recent Advances

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?