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 • 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
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
Some State-of-the-Art (I) • Practical attack capabilities • Non-profiled SCA • Profiled SCA • Algebraic attacks • Fault attacks 6
Some State-of-the-Art (II) • Evaluation framework • Secure logic styles • Leakage-resilient crypto • Protecting software • Protecting processors 7
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
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
Statistical View • SCA as detecting dependence between two random variables • Leakage models (X) • E.g. HW(Sbox(x i k)) • Actual measurements (Y) 10
Basic Question • Does the leakage model allow a “meaningful” partitioning of the practical leakages? Correct key hypothesis Wrong key hypothesis 11
12 Correlation: Distinguishers MIA: DoM:
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
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
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
Algebraic Attacks • Optimization problem solver: Can use template probabilities directly • Avoids problem of wrong guesses • Requires more time 16
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
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
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
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
Evaluation Framework • Applied to evaluate different classes of countermeasures • Masking • Shuffling (in software implementations) 21
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
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
(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
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
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
Secure Logic Cost • Security improvements often bought at a relatively high price • Increased development cost / area / power consumption • Decreased speed 27
Leakage-Resilient Crypto • Idea: Account for physical leakage in cryptographic construction • Goal: Provable physical security against broad classes of adversaries 28
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
Leakage-Resilient Crypto • Not all assumptions correspond with engineering experience • Relatively high implementation cost • -> Still a gap between theoretic proofs and practice 30
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
Construction/leakage resilience 32 • Fresh re-keying
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
μ P with Prot. Execution Unit • Secure zone • Similar to FU • Secure logic • Rest of μ P • Largely unchanged • Ordinary CMOS • Protected by mask 34
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