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

Physical Security: Status and Outlook

Stefan Tillich

ECRYPT II: Crypto for 2020 January 22-24, Tenerife, Spain

2

P C C

Ideal World

3

P C C, 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

Distinguishers

DoM: 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
• riginal 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