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

physical security status and outlook
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

Physical Security: Status and Outlook

Stefan Tillich

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

slide-2
SLIDE 2

2

P C C

Ideal World

slide-3
SLIDE 3

3

P C C, C’,err

Real World

slide-4
SLIDE 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

slide-5
SLIDE 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

slide-6
SLIDE 6

Some State-of-the-Art (I)

  • Practical attack capabilities
  • Non-profiled SCA
  • Profiled SCA
  • Algebraic attacks
  • Fault attacks

6

slide-7
SLIDE 7

Some State-of-the-Art (II)

  • Evaluation framework
  • Secure logic styles
  • Leakage-resilient crypto
  • Protecting software
  • Protecting processors

7

slide-8
SLIDE 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

slide-9
SLIDE 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

slide-10
SLIDE 10

Statistical View

  • SCA as detecting dependence between two

random variables

  • Leakage models (X)
  • E.g. HW(Sbox(xi  k))
  • Actual measurements (Y)

10

slide-11
SLIDE 11

Basic Question

  • Does the leakage model allow a

“meaningful” partitioning of the practical leakages?

11

Correct key hypothesis Wrong key hypothesis

slide-12
SLIDE 12

12

Distinguishers

DoM: Correlation: MIA:

slide-13
SLIDE 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

slide-14
SLIDE 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

slide-15
SLIDE 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

slide-16
SLIDE 16

Algebraic Attacks

  • Optimization problem solver: Can use

template probabilities directly

  • Avoids problem of wrong guesses
  • Requires more time

16

slide-17
SLIDE 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

slide-18
SLIDE 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

slide-19
SLIDE 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

slide-20
SLIDE 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

slide-21
SLIDE 21

Evaluation Framework

  • Applied to evaluate different classes of

countermeasures

  • Masking
  • Shuffling (in software implementations)

21

slide-22
SLIDE 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

slide-23
SLIDE 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

slide-24
SLIDE 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

slide-25
SLIDE 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

slide-26
SLIDE 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

slide-27
SLIDE 27

Secure Logic Cost

  • Security improvements often bought at a

relatively high price

  • Increased development cost / area / power

consumption

  • Decreased speed

27

slide-28
SLIDE 28

Leakage-Resilient Crypto

  • Idea: Account for physical leakage in

cryptographic construction

  • Goal: Provable physical security against

broad classes of adversaries

28

slide-29
SLIDE 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

slide-30
SLIDE 30

Leakage-Resilient Crypto

  • Not all assumptions correspond with

engineering experience

  • Relatively high implementation cost
  • -> Still a gap between theoretic proofs and

practice

30

slide-31
SLIDE 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
  • riginal running time
  • Self-modifying code for offloading overhead

to precomputation

31

slide-32
SLIDE 32

Construction/leakage resilience

  • Fresh re-keying

32

slide-33
SLIDE 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

slide-34
SLIDE 34
  • Secure zone
  • Similar to FU
  • Secure logic
  • Rest of μP
  • Largely unchanged
  • Ordinary CMOS
  • Protected by mask

34

μP with Prot. Execution Unit

slide-35
SLIDE 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