Sebastian Faust Aarhus University, Denmark Lea eakag age-Res Resilie ilient nt Crypt ptogra graphy phy -- -- for r symmetric mmetric pr prim imit itives ives 1
How to construct cryptodevices? cryptographic device very secure well-defined mathematical object often proof-driven security analysis Leakage Resilient Crypto CRYPTO Extend concept of proof- driven security analysis to implementation-level much less secure! many ways of implementing: details matter! security analysis by experiments, rarely proofs 2
The approach of provable security 1. Define model & security notion Example: Digital signatures key K signature message 3
The approach of provable security 1. Define model & security notion Example: Digital signatures Forgery for new key K message repeat Scheme is secure: no adversary can output a valid forgery! 4
The approach of provable security 1. Define model & security notion 2. Design cryptoscheme Usually described in mathematical language 5
The approach of provable security 1. Define model & security notion 2. Design cryptoscheme Usually described in mathematical language 3. Prove security Reduce security of complex scheme to simple assumption, e.g., Number theory: studied intensively in math One-wayness of function: major breakthrough in complexity Shows security not only against one specific attack, but any efficient (PPT) attack within the model (if assumption holds) 6
Time to relax? Security proof implies… secure against all known attacks secure against all attacks that may be discovered in future Provably secure systems get broken in practice! Underlying assumptions are false? Not for standard assumptions Bugs in proofs? Only rarely! So what‟s wrong? 7
Model Reality Models make idealized assumptions Hash functions behave as random oracles Black-box computation
Black-box model vs. Reality Security model: Black box Reality: Attacking mathematical algorithm Attacking the implementation K X Y X Y input output K key implement Implementations leak partial Controls inputs/outputs information about internals But: Internal computation and key Leakage: e.g., power consumption, completely hidden running time, electromagnetic radiation… 9
Physical devices are not black boxes 1. Proofs in black-box model less meaningful 2. Even worse: Side-channel attacks exploit leakage and break real-world implementations Important question: what are these classes? Goal of leakage resilient crypto Weaken black-box assumption and incorporate broad classes of leakage into model Develop new cryptoalgorithms with built-in resistance against leakage and prove security 10
Leakage Resilient Cryptography Hot topic… Digital signatures: [AWD09, KV09, FKPR10, DHLW10, BKKV10, BSW11 ,…] Public key encryption: [AGV09, NS09, DHLW10, BKKV10, BSW11 ,…] Identity based encryption: [DHLW10, CDRW10, LRW11 ,…] Multiparty Computation: [ISW03, FRRTV10, GR10, JV10 …] Most of this talk Zero Knowledge: [GJS11] But surprisingly little is known about symmetric primitives… Pseudorandom Generators: [DP08, Pie09, YSPY10] Pseudorandom Functions & Permutations: [DP10, FPS11] 11
Defining leakage K X Y Modeled by a leakage function f Adversary obtains leakage f(K) Arbitrary leakage function? No… e.g.: f(K) = K means no security Some restrictions are necessary Does this make sense in practice? Arbitrary efficient adversary 12
Defining leakage K X Y Modeled by a leakage function f Adversary obtains leakage f(K) Arbitrary leakage function? No… e.g.: f(K) = K means no security Some restrictions are necessary Does this make sense in practice? In many cases yes… Power consumption modeled by f(K)= Hamming weight of wires in circuit Running time of device 13
What are possible restrictions? One attempt: consider specific leakage function But we do not want to protect only against specific attacks (such as: Hamming weight, timing) Leakage Resilient Crypto: consider broad classes of leakage functions! 14
A broad class of leakage functions K L is class of poly-time computable Y X input shrinking functions f є L L = { f : {0,1} m -> {0,1} n }, with n < m f( K ) Observation: f is poly-time can simulate all intermediate values & leak about them Many realistic leakages: HW, running time exploit only poly-log amount of information Problem: total leakage << length of the key Reality: Many observations are possible (many attacks exploit a large number of observations) 15
Continuous Leakage Model Many adaptive observations: K K … X 1 X q Y 1 Y q f 1 f q f 1 ( K ) f q ( K ) 16
Continuous Leakage Model Many adaptive observations: K K … X 1 X q Y 1 Y q f 1 f q f 1 ( K ) f q ( K ) Bounded per observation to n bits But: total leakage >> |K| Models, e.g., DPA where we need many power samples to recover the key 17
Rest of this talk 1. Leakage Resilient Stream Cipher 2. Leakage Resilient PRFs 3. Leakage Resilient Circuits 18
Leakage Resilient Stream Cipher First construction: Dziembowski-Pietrzak-08 Simpler construction: Pietrzak-09 stream ciphers ≈ pseudorandom generators Pseudorandomness: no efficient (PPT) adversary short key can distinguish X from random long pseudo ? random K stream X 19
Stream ciphers in practice SC K X 1 X 2 stream X is time generated in X 3 rounds from K (one block per X 4 round ) . . . 20
Standard Security Notion Given previous blocks, next block should look random SC K . . . X 1 X 2 X i-1 X i Adversary knows Should look random How to extend to leakage setting? 21
Standard Security Notion Given previous blocks, next block should look random SC K f 1 ( K ) f 2 ( K ) f i-1 ( K ) . . . X 1 X 2 X i-1 X i Adversary knows also leakage Should look random Poly-time computable bounded- output leakage function 22
Standard Security Notion Given previous blocks, next block should look random SC K f 1 ( K ) f 2 ( K ) f i-1 ( K ) . . . X 1 X 2 X i-1 X i Adversary knows also leakage Should look random Some problems? 1. adversary can learn entire key K bit-by-bit 2. given leakage f i-1 (K), the block X i is not pseudorandom anymore f i-1 (K) can leak some bits about X i 23
Key evolution In each round key K i is used to compute new state K i+1 SC K 1 K 2 K 3 . . . X 1 X 2 X 3 - Requirement: Key evolution must be deterministic! Otherwise it cannot be used for encryption! 24
Key evolution In each round key K i is used to compute new state K i+1 SC K 1 K 2 K 3 . . . f 1 ( K 1 ) f 2 ( K 2 ) X 1 X 2 X 3 - Requirement: Key evolution must be deterministic! Otherwise it cannot be used for encryption! - Also key update leaks! Is key evolution sufficient? 25
Is key evolution sufficient? Learning key bit-by-bit does not work anymore SC K 1 K 2 K 3 . . . Can X 2 be pseudorandom given leakage f 1 (K 1 )? No! f 1 ( K 1 ) X 1 X 2 Key evolution deterministic: f 1 computes K 2 and leaks bits of X 2 Even worse: pre-computation attack Leakage function f 1 …f i-1 leak from future state K i may reveal entire K i even with one bit of leakage 26
How to avoid this attack? Pre-computation attack relevant in practice? No! It‟s a problem of the model… Use restriction introduced by Micali-Reyzin-04: “only computation leaks information” or in other words: “untouched memory cells do not leak information” 27
Only computation leaks state 28
Only computation leaks state: divided into parts R L 29
Only computation leaks state: divided into parts R L if used in current computation if not accessed: f(L) leaks to adversary does not leak Restriction can be relaxed in many cases… 30
Independent leakages state: divided into parts R L if used in current computation if not accessed: f(L) leaks to adversary f(R) leaks (independently of L) How can we use this to avoid pre-computation? 31
The stream cipher – high-level view Divide memory into three parts: L,X,R L X R holds pseudorandom output of the cipher 32
The stream cipher – high-level view Divide memory into three parts: L,X,R L X R holds secret state 33
The stream cipher – high-level view Divide memory into three parts: L,X,R L 1 X 1 R 1 SC unmodified L 2 := L 1 X 2 R 2 34
The stream cipher – high-level view Divide memory into three parts: L,X,R L 1 X 1 R 1 SC unmodified L 2 := L 1 X 2 R 2 35
The stream cipher – high-level view Divide memory into three parts: L,X,R L 1 X 1 R 1 SC unmodified L 2 := L 1 X 2 R 2 Recall: leakage is polynomial-time computable function, i.e., we can also leak from (X 2 ,R 2 ) 36
The stream cipher – high-level view Divide memory into three parts: L,X,R L 1 X 1 R 1 SC unmodified L 2 X 2 R 2 SC unmodified L 3 X 3 R 3 SC unmodified L 4 X 4 R 4 Alternation prevents pre-computation attack E.g.: f 1 cannot leak about state (L 3 ,X 3 ,R 3 ) 37
The stream cipher – high-level view Divide memory into three parts: L,X,R L 1 X 1 R 1 SC unmodified L 2 X 2 R 2 SC unmodified L 3 X 3 R 3 SC unmodified L 4 X 4 R 4 What can we prove? X i is pseudorandom given X 1 ,… X i-1 and leakages f 1 (X 1 ,R 1 )… f i-2 (X i-2 ,L i-2 ) 38
Recommend
More recommend
