Physical Security: Status and Outlook

Transcription

1 Physical Security: Status and Outlook ECRYPT II: Crypto for 2020 January 22-24, Tenerife, Spain Stefan Tillich

2 Ideal World P C 2

3 Real World P C, C,errC 3

4 Implementation Attacks First publication ~ 16 years ago Exploitation of various physical effects Developing/improving attacks: passive/active, (non/semi-)invasive Countermeasures on various levels: cell, architecture, protocol/construction Evaluation of attack & countermeasure effectiveness 4

5 Countermeasures Hiding E.g. Noise increase, signal reduction, shuffling / dummy ops, some secure logic styles Masking E.g. First-order/higher-order masking, blinding, some secure logic styles Protocol/Construction E.g. Re-keying, Leakage-resilient crypto 5

6 Some State-of-the-Art (I) Practical attack capabilities Non-profiled SCA Profiled SCA Algebraic attacks Fault attacks 6

7 Some State-of-the-Art (II) Evaluation framework Secure logic styles Leakage-resilient crypto Protecting software Protecting processors 7

8 Practical Capabilities Collection and processing of > 1 billion samples Josh Jaffe, CHES 2010 Reverse engineering of security chips with low/medium cost E.g. Chris Tarnovsky (Flylogic) 8

9 Non-Profiled SCA DoM, correlation common distinguishers Require reasonable good leakage models Mutual Information Analysis as toolbox 1) Estimate pdf of key-dependent models 2) Test correspondence to actual traces MIA generalized easily for higher-order attacks 9

10 Statistical View SCA as detecting dependence between two random variables Leakage models (X) E.g. HW(Sbox(x i k)) Actual measurements (Y) 10

11 Basic Question Does the leakage model allow a meaningful partitioning of the practical leakages? Correct key hypothesis Wrong key hypothesis 11

12 Distinguishers DoM: Correlation: MIA: 12

13 Distinguishers Methods for comparing pdfs without explicit pdf estimation E.g. Kolmogorov-Smirnov test, Cramér-von- Mises test For all attacks: The leakage model may not be totally wrong Different resilience handling non-perfect models 13

14 Profiled SCA Templates as most powerful SCA attacks Suitable for estimating worst-case attack scenario Various techniques Multi-variate Gaussian templates PCA as pre-processing tool Use of stochastic models T-test templates 14

15 Algebraic Attacks Express input-output relation as Boolean equations with many unknown variables (incl. key) SAT solvers: Use side-channel leakage to assign values to some of the variables Problems to cope with wrong guesses 15

16 Algebraic Attacks Optimization problem solver: Can use template probabilities directly Avoids problem of wrong guesses Requires more time 16

17 Fault Attacks Countermeasures normally based on some form of redundancy Redundant data or computation Recent proposals for combined countermeasures (i.e. also vs. SCA) Protecting generic exponentiation 17

18 Fault-Sensitivity Analysis Targeting not the fault per se but the exact conditions producing the fault In some implementations, these conditions are key dependent 18

19 Infective Computation Most fault attacks depend on learning faulty ciphertexts Faults in infective computation will garble the ciphertext Can be safely returned without final checks Attacker doesn t learn useful information 19

20 Evaluation Framework Proposed by Standaert et al. in 2009 Combination of (1) information theoretic (IT) and (2) security metrics (1) How much information about the key leaks (independent of any adversary)? (2) How effective can different adversaries exploit the leakage? 20

21 Evaluation Framework Applied to evaluate different classes of countermeasures Masking Shuffling (in software implementations) 21

22 Some lessons learned IT metric allows to capture security against worst-case attacker Standard attacks in practice not enough to assess SCA resistance of a device Higher-order masking requires a certain amount of noise to be effective Simplified shuffling (random start index) can be more vulnerable 22

23 Secure Logic Styles Goal: Prevent the leakage at the cell level Research started about a decade ago Many different logic styles proposed Some revisions trying to fix shortcomings of proposed logic styles 23

24 (Some) Secure Logic Styles SABL, CRSABL WDDL, (DWDDL), Separated DDL, Double WDDL, Double WDDL(ASIC) (MCML), DyCML, LSCML, IFLSCML, DDSLL, TPDyCML GF RSL, DRSL (MCMOS), MDPL, imdpl SecLib TDPL DSDRL SAL Asynchronous logic 24

25 Secure Logic Evaluation Leakage depends on both cell structure and interconnect Evaluation with simulation often insufficient Need to capture low-level effects, e.g. glitches, early evaluation, memory effect Practical evaluation in ASICs costly 25

26 Secure Logic Implementation EDA tools often do not directly support some of the required functions/constraints e.g. balancing of wire capacitances Usually, extra steps are added to the standard EDA flow e.g. cell substitution, netlist duplication Tools often need to be tricked into doing the necessary steps e.g. fat wire routing 26

27 Secure Logic Cost Security improvements often bought at a relatively high price Increased development cost / area / power consumption Decreased speed 27

28 Leakage-Resilient Crypto Idea: Account for physical leakage in cryptographic construction Goal: Provable physical security against broad classes of adversaries 28

29 Leakage-Resilient Crypto Impossible to prove security against unrestricted physical adversary -> Determine meaningful physical limits for adversary Constructions with various assumptions E.g. λ-bit leakage/iteration, onlycomputation leaks 29

30 Leakage-Resilient Crypto Not all assumptions correspond with engineering experience Relatively high implementation cost -> Still a gap between theoretic proofs and practice 30

31 Protected Software Combination of countermeasures First-order masking & shuffling can be attacked Higher-order masking & strong shuffling (random permutation) seems more secure Execution overhead at least several times the original running time Self-modifying code for offloading overhead to precomputation 31

32 Construction/leakage resilience Fresh re-keying 32

33 Protecting Processors Non-deterministic execution E.g. NONDET processor (hiding in time) Protected execution unit E.g. Power-Trust processor (masking, leveraging secure logic) 33

34 μp with Prot. Execution Unit Secure zone Similar to FU Secure logic Rest of μp Largely unchanged Ordinary CMOS Protected by mask 34

35 Outlook Integrated countermeasures for SCA and fault attacks (More) practical leakage-resilient crypto Leveraging new architectures to implement countermeasures Move to more system-wide view of physical protection 35