Eloi Sanfelix - Hardware security: Side Channel Attacks [RootedCON 2011]

Hardware Security: Side Channel Attacks

Eloi Sanfelix

eloi@riscure.com

Introduction: Secure hardware and attacks

Side Channel Analysis

Conclusion

Protecting your device

Tips for developers

Perturbation attacks

Agenda

Introduction: Secure hardware and attacks

Side Channel Analysis

Conclusion

Protecting your device

Tips for developers

Perturbation Attacks

Agenda

Secure Devices

MainCPU

CryptoCPU

Secure Storage

Tamper-proof enclosure

Example: smart cards

ISO 7816Image source: dhgate.com

Secure device attack types

Invasive Logical

Side Channel

Agenda

Introduction: Secure hardware and attacks

Conclusion

Protecting your device

Tips for developers

Perturbation Attacks

Side Channel Analysis

Side Channels IRL

8

30/7/90 31/7/90 1/8/90 2/8/900

5

10

15

20

25

Iraq invades Kuwait...

A different threat model

But we also need to

• Beware of leakage

• Protect run-time integrity

Common paradigm

• Do not trust input

• Preserve confidentiality and

integrity in output

Local: at input / output Pervasive: throughout code

Code

▼

Code

10

Side channel attacks

• Passive (SCA): Read ‘hidden’ signals

– timing

– power consumption

– electromagnetic emission

• Active (FI): Signal injection

– power glitches

– electromagnetic pulses

SCA Measurement setup

12

Smart card power reader

Power / EM traces

• Signal leakage from busses, registers, ALUs, etc

PIN verification attempts

'Simple' Power Analysis

• Analyse few traces (vs statistical analysis)

• Example: COMP128-1 crypto algorithm

• C code: x = table_512[k+d]

k+d < 256

k+d ≥ 256

Data influence

• Example trace of software DES on smart card

• Leaks hamming weight of data

noiseProfit! (data)

Statistical data detection

• Where is data processed in presence of noise?

Statistical data detection

• Where is data processed in presence of noise?

• Collect many traces with different data (n > 1000)

• Use known uniformly random input/output data

• We focus on one bit of one variable in the process

00

00

11

11

Group by known data Average trace

Subtract

Differential trace

Differential trace

• Input: n traces with known variable (e.g. input or output)

• Output: 1 trace with indication where bit causes trace differences

But…you promised keys !?

• Keys are used in small chunks• Mixed with input data

Use hypothesis testing!

0 1 0 1

1 1 1 0

1 0 1 1

0 1 1 0

H0 H1 H2 H3

Hypothesis incorrect

• Group traces according to hypothesis

• If the actual data does not match the hypothesis:

– We group the wrong traces

– Statistically, the averages will be similar

• Result: noise

01

01

10

01

Group by wrong data Average trace

Subtract

Hypothesis correct

• Group traces according to hypothesis

• If the actual data does match the hypothesis:

– Only differences in measurement caused by different data

between averages

• Result: peaks!

00

00

11

11

Group by right data Average trace

Subtract

Tricky...

DPA on (3)DES

K1

K2

K15

K16

?!

Use hypothesis testing

• Hypothesis testing; each 6-bit subkey value leads to different hypothesis for the sbox output

TracesH0 H1 ... H63

Sbox output

n

0 1 ... 1

1 1 ... 0

1 0 ... 1

0 1 ... 0

Calculate differential traces

H0 H1 H56 H63Sbox output

n

64 differential traces

0 1 1 1

1 1 1 0

1 0 1 1

0 1 0 0

Find best candidate

64 differential traces

Repeat for other sboxes and

rounds for full key

DEMOs

Reality check

• Smart card manufacturers know about DPA

• Often difficult finding correct filtering and alignment

– Advanced preprocessing necessary

• Countermeasures in hard- and software

• On embedded systems, not so much...

Agenda

Side Channel Analysis

Conclusion

Protecting your device

Tips for developers

Perturbation attacks

Introduction: Secure hardware and attacks

Fault Injection

• Chip/Hardware operating conditions

– Temperature

– Frequency

– Power supply (input voltage)

– Localized energy increase (Laser, EM, others?)

• Fault injection modifies operating conditions

– Bring chip outside normal situation to make it fail

Fault Injection Setup

Voltage glitching

1

A power dip at the moment of reading a memory cell

0

Fault Injection Effects

Laser/voltageglitch

Data/Memory manipulation

Fault Injection Effects

Laser/voltageglitch

Program flow manipulation

Differential Fault Analysis

Correct result

Faulty result

Correct result

Faulty result

Correct result

Faulty result

Correct result

Faulty result

DFA

RSA and RSA-CRT

• RSA works with modular exponentiations

• RSA-CRT splits big exponentiation in two smaller ones

dp = d mod (p-1)

dq = d mod (q-1)

K = p-1 mod q

Sp = Mdp mod p

Sq = Mdq mod q

S = ( ( (Sq - Sp)*K ) mod q ) * p + Sp

S = Md (mod n)

Bellcore attack on RSA-CRT

• Suppose single fault into one exponentiation

• Now, subtract S’ from S

• Now take gcd(s-s’,n)

– gcd(x*p,p*q) = p

– Compute q=n/p and you’re done!

• An attack variant exists that only requires S’ and M

S’ = ( ( (S’q - Sp)*K ) mod q ) * p + Sp

S - S’ = (((Sq - Sp)*K) mod q)*p - (((S’q - Sp)*K) mod q)*p= (x1-x2)*p mod N

Demo: Bellcore’s attack

Agenda

Side Channel Analysis

Conclusion

Perturbation Attacks

Protecting your device

Tips for developers

Introduction: Secure hardware and attacks

SCA Countermeasures

• Application level

– NEVER brew your own crypto

– Introduce random delays between critical functions

– Avoid branches related to secret data

– See helpful patterns in reference [1]

• Operating System level

– Masking and hiding countermeasures. See e.g. [2],[3]

• Have your systems tested

– Side channel vulnerabilities can be very subtle!

Fault Injection countermeasures

• Double check critical results

– Encrypt-Decrypt-Compare

– Two comparisons in authentication checks

– Add a random wait between the two checks

• Protect code flow integrity

– Introduce ‘shadow program counters’

• Never output wrong results

– Most DFA attacks are based on this!

• See more at [1]

Side Channel Analysis

Perturbation Attacks

Introduction: Secure hardware and attacks

Protecting your device

Tips for developers

Conclusion

Agenda

Conclusion

• Devices under attacker’s control

– Physical threats need to be considered

– Complete protection very difficult

– Countermeasures based on increasing attack effort

• Side channel problems are difficult to spot

– Compiler and hardware behavior could break your code!

– Impossible to know without testing

Thank you!!

eloi@riscure.com

References

[1] Secure Application Programming in the Presence of Side

Channel Attacks – Download link

[2] Power Analysis Attacks – http://www.dpabook.org

[3] Cryptography Research Inc. – DPA Countermeasures

[4] Riscure – Publications

[5] E. Bhiam, A.Shamir – Differential Fault Analysis of Secret Key

Cryptosystems