physical security status and outlook
play

Physical Security: Status and Outlook ECRYPT II: Crypto for 2020 - PowerPoint PPT Presentation

Physical Security: Status and Outlook ECRYPT II: Crypto for 2020 January 22-24, Tenerife, Spain Stefan Tillich 2 C P C Ideal World 3 C, C,err C P Real World Implementation Attacks First publication ~ 16 years ago


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

  2. 2 C P C Ideal World

  3. 3 C, C’,err C P Real World

  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. 12 Correlation: Distinguishers MIA: DoM:

  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, only- computation 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 32 • Fresh re-keying

  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

Recommend


More recommend