physical security: status and outlook · status and outlook stefan tillich ecrypt ii: crypto for...
TRANSCRIPT
Physical Security:Status and Outlook
Stefan Tillich
ECRYPT II: Crypto for 2020January 22-24, Tenerife, Spain
2
P
CC
Ideal World
3
P
CC, C’,err
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(xi k))
• Actual measurements (Y)
10
Basic Question
• Does the leakage model allow a “meaningful” partitioning of the practical leakages?
11
Correct key hypothesis Wrong key hypothesis
12
DistinguishersDoM: Correlation:
MIA:
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
• Fresh re-keying
32
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
• Secure zone• Similar to FU• Secure logic
• Rest of μP• Largely unchanged• Ordinary CMOS• Protected by mask
34
μP with Prot. Execution Unit
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