physical security: status and outlook · status and outlook stefan tillich ecrypt ii: crypto for...

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