Download presentation

Presentation is loading. Please wait.

Published byHope Beere Modified over 2 years ago

1
Leakage- Resilient Cryptography: Recent Advances Research Exam May 20, 2010 Petros Mol 1

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 2 hidden visible

3
> 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,… Cryptography in the ideal world 3

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

5
Cryptography in the real world 5 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 6 Primitives vulnerable to such attacks –All primitives actually implemented on a physical device

7
Side-Channel Attacks …from Side Channel Attacks Database 7 The decade 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 8 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 standard DRAM cells refresh interval: ~ms in practice cells retain content for much longer ~ 30 o C : complete loss only after tens of seconds 9 At low temperatures (-50 o C) contents might be retained for minutes or hours [HSH +, USENIX Security 08]

10
10 Memory (cold-boot) attacks - bits decay to known ground states following predictable patterns 5 sec 30 sec5 min1 min

11
A (very partial) list of attacks Type of AttackProtocol/software attacked Timing RSA, El Gamal, DSA, AES, DES, RC5 Power AnalysisRSA, DES, AES Fault Induction RSA, ECC, DES, RC5, Blowsh, identification schemes Memory Attacks AES, DES, RSA, FileVault, TrueCrypt, BitLocker 11

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 12 Timing & Power analysis Fault Induction Cold boot attacks

13
Ad-hoc: target specific side channel attacks 13 HW/Implementation-level countermeasures 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 1 st const. Side-chan. attack 1 Side-chan. attack 1 fix 2 nd const. Side-chan. attack 2 Side-chan. attack 2 fix n th const. fix

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

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

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

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

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

20
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, M i encoded in f) ** For stateless primitives S i might simply the secret key**

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

22
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
23 ModelDomainRange Additional restrictions Practical Scenario continuous leakage accessed state unbound. bounded per invocation (round) leakage from computation Memory Leakage entire skbounded cold-boot attacks Auxiliary Input entire skunbound. comp/ly hard to find sk, given f(sk) both (Partial) Taxonomy of Derived Models Each model might or might not be appropriate depending on the actual practical setting

24
continuous leakage –fails to capture memory attacks –proofs rely on the fact that parts of the key dont 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 24 Leakage Models: Comparison/Discussion

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

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

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

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

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

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

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

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

33
33 Leakage-resilient Stream Cipher K 2i, K 2i+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) Update rule:

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

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

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

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

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

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

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

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

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

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

44
LRC: Primitives (overview) 44 Continuous Leakage I II LR- Stream Cipher Simplified LR- SC LR st/ful sig/res CPA-PKE, IBE CPA / CCA-PKE, generic constructions improved leakage CPA/CCA SKE sign/res gen. const. CPA PKE LR PKE (gen. mod)

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

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

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

48
How LRC changed the picture ? 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 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

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

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

51
Look to the future 51 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 [Goldwasser, Kalai, Peikert, Vaikuntanathan 10: Robustness of LWE rob/ness of assumptions vs rob/ness of costructions Allowing (restricted) access to the leakage oracle after the creation of the challenge. - How does this affect security guarantees?

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google