eloi sanfelix - hardware security: side channel attacks [rootedcon 2011]
Post on 21-Oct-2014
3.524 views
DESCRIPTION
TRANSCRIPT
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!!
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