At RSA Conference 2010 Riscure's Marc Witteman presented an essential overview of fault injection attacks theory and showed a number of practical attacks at hardware using FI.

1. Title of Presentation
Marc Witteman
Riscure
Session ID: RR-201
Session Classification: Advanced
How multi-fault injection
breaks the security
of smart cards

2. Imagine you could turn your
BART EZ Rider fare card
into a military CAC card…
2

3. Objectives
• Get an overview of fault injection threats
• Learn about countermeasures
• Discover the possibilities of next generation
fault injection methods
3

4. Agenda
Countermeasures
Method improvements
Attacks in practice
4
Fault Injection
Wrap-up

5. Fault injection
5

6. Fault Attack channels
• Voltage glitching
• Clock glitching
• Optical glitching
6

7. Fault attack scenarios
Some example attack scenarios
• Verification bypass
• Code dump
• Differential Fault Analysis
7

8. Tools
Tools used for fault injection
• Hardware for glitch control
• Flash bulbs and lasers
• Software for experiment control
8

9. Countermeasures
9

10. Countermeasures
• Double checking
• Signature verification
• Traps
• Randomization
• Shields and sensors
10

11. Double checking
11
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
if(array_compare(pin,buffer,4) != 0) {
auth = FALSE; // PIN not ok at second check
return 0x6986; }
else { // PIN ok
… }
} else { // PIN not ok at first check
… }

12. Double checking
12
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
if(array_compare(pin,buffer,4) != 0) {
auth = FALSE; // PIN not ok at second check
return 0x6986; }
else { // PIN ok
… }
} else { // PIN not ok at first check
… }
Second check detects fault
Glitch forces acceptance of false PIN

13. Verify signatures
13
short sign_and_verify(byte* buffer) {
sign( buffer, signature );
if (verify( buffer, signature) {
auth = TRUE; // signature verification success
send( signature ); } // send signature
return 0x9000; } // report success
else {
auth = FALSE; // signature verification fail
return 0x6986; } // no signature transmission

14. Verify signatures
14
short sign_and_verify(byte* buffer) {
sign( buffer, signature );
if (verify( buffer, signature) {
auth = TRUE; // signature verification success
send( signature ); } // send signature
return 0x9000; } // report success
else {
auth = FALSE; // signature verification fail
return 0x6986; } // no signature transmission
Glitch corrupts signature
Verify detects
corrupted signature

15. Traps
15
byte result = SOME_VALUE;
byte resultChecksum = ~SOME_VALUE; // create checksum
…
if ((result ^ resultChecksum) != 0xFF)
fail(); // verify checksum

16. Traps
16
byte result = SOME_VALUE;
byte resultChecksum = ~SOME_VALUE; // create checksum
…
if ((result ^ resultChecksum) != 0xFF)
fail(); // verify checksum
Glitch corrupts value
Trap may mute or kill card

17. Randomization
17
short pin_check(byte* buffer) {
// get random number in range 0..255
int rnd = get_random( 256 );
while (rnd > 0) rnd--; // random delay
if(pin_ctr > 0) {
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {
…
Randomness introduced by
• Random delays (software loop)
• Cycle stealing (CPU skips clock cycle)
• Drifting clock

18. Randomization
18
short pin_check(byte* buffer) {
// get random number in range 0..255
int rnd = get_random( 256 );
while (rnd > 0) rnd--; // random delay
if(pin_ctr > 0) {
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {
…
Randomness introduced by
• Random delays (software loop)
• Cycle stealing (CPU skips clock cycle)
• Drifting clock
Random delay stops
time-based glitches

19. Shields and Sensors
19
• Shields block optical glitches
• Sensors detect glitches

20. Method improvements
20

21. Limitations of common equipment
• Standard signal generators lack flexibility
• Laser cutters are coarse
• Diode lasers are divergent and weak
• Process control inefficient
21
???

22. Improvements in design
• Flexible glitch control hardware
• Smart triggering
• Effective diode lasers
• Efficient control software
22

23. Glitch control hardware requirements and design
23
Multi channel
• Clock,
• VCC (supply voltage)
• Optical
Precise
• low latency
• short pulses
• exact timing
Adaptive
• configure remotely
• diverse triggers
• Monitor side channel
ControlUSB
Trigger in
LaserContact
smart card
LCD
Display
Trigger out
Smart card RST
Smart card I/O
Smart card VCC
Smart card CLK
Glitch
circuit
with smart
card
Glitch generatorCPU+ memory
Switch
Power monitor
mode
CLK
VCC
vcc/clk/laser

24. Glitch control hardware implementation
General-purpose high speed FPGA board mounted on top of
dedicated PCB with analog and digital drivers and interfaces
24

25. Smart triggering, what for?
Variable delays stop time based glitch triggers
25
Instruction to hit

26. Smart triggering concept
26
• Real time comparison
of signal arrays
• Use Sum of Absolute Differences

27. Smart triggering result
Trigger moment is now fixed to device behavior
27
Instruction to hit

28. Smart triggering on noisy signals?
• Noise hides useful signals
28

29. Spectrum of noisy signals
• Spectrum reveals signals obscured by noise
• High frequencies include distinguishing features
29

30. Frequency conversion of noisy signals
• High frequencies are difficult to sample
• Pattern matching easiest on DC components
• Frequency mixing and demodulation makes high
frequent features detectable
30

31. Feature recognition in noisy signals
• Filtering produces detectable signal
31

32. Smart triggering architecture and implementation
FPGA board combined with dedicated electronics
32
Control
Filter
Reference signal (2x)
Acquisition SAD processor (2×)
USB
Trigger in
Filter in
Filter out Signal in
Trigger out (2×)
SAD out

33. Diode laser requirements
Lasers must support
• fast switching
• power control
• multiple colors
33
33
Source: Sergei Skorobogatov

34. Diode laser system requirements
System requirements
• Camera view
• Motorized XY stage
Optics requirements
• Correct beam divergence
• Small spot size (~1 µm)
Remote controllable parameters
• XY position
• Glitch timing & amplitude
34

35. Fault Injection Software
Fault injection process requirements
• Configurable and repeatable
• Automated execution and logging
35

36. Attacks in practice
36

37. Attacks in practice
• Backside attacks
• Virtual imaging
• Real time multi glitching
37

38. Backside attacks (1)
38

39. Backside attacks (2)
39

40. Side channel observation after fault injection
Behavior shifted in time
40

41. Virtual imaging
41

42. Multi glitch timing
Diode lasers can switch at high frequency
42

43. Real time multi glitch process
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
random_delay();
if(pin_ctr <= 0) suicide();
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
random_delay();
if(array_compare(pin,buffer,4) != 0) suicide();
else { … } // PIN ok
} else { … } // PIN not ok at first check
Find end with smart triggering
43

44. Real time multi glitch process
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
random_delay();
if(pin_ctr <= 0) suicide();
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
random_delay();
if(array_compare(pin,buffer,4) != 0) suicide();
else { … } // PIN ok
} else { … } // PIN not ok at first check
Glitch condition
44

45. Real time multi glitch process
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
random_delay();
if(pin_ctr <= 0) suicide();
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
random_delay();
if(array_compare(pin,buffer,4) != 0) suicide();
else { … } // PIN ok
} else { … } // PIN not ok at first check
Find begin with smart triggering
and force power down
45

46. Real time multi glitch process
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
random_delay();
if(pin_ctr <= 0) suicide();
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
random_delay();
if(array_compare(pin,buffer,4) != 0) suicide();
else { … } // PIN ok
} else { … } // PIN not ok at first check
Glitch condition
46

47. Real time multi glitch process
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
random_delay();
if(pin_ctr <= 0) suicide();
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
random_delay();
if(array_compare(pin,buffer,4) != 0) suicide();
else { … } // PIN ok
} else { … } // PIN not ok at first check
Find end with smart triggering
47

48. Real time multi glitch process
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
random_delay();
if(pin_ctr <= 0) suicide();
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
random_delay();
if(array_compare(pin,buffer,4) != 0) suicide();
else { … } // PIN ok
} else { … } // PIN not ok at first check
Glitch condition
48

49. Real time multi glitch process
short pin_check(byte* buffer) {
if(pin_ctr > 0) {
random_delay();
if(pin_ctr <= 0) suicide();
pin_ctr--;
if(array_compare(pin,buffer,4) == 0) {// PIN ok at first check
random_delay();
if(array_compare(pin,buffer,4) != 0) suicide();
else { … } // PIN ok
} else { … } // PIN not ok at first check
Find begin with smart triggering
and force power down
49

50. Real time multi glitch user experience
50

51. Wrap-up
51

52. Multi glitch practical limitations
• Evaluation of many parameters is time consuming
(timing, amplitude, xy position, etc)
• Sensors and traps slow down analysis
careful tuning of equipment needed
• Navigation without design is cumbersome
crypto core is needle in hay-stack
52

53. Impact
• So can I turn my BART card into a CAC card?
• No, for dictating instructions and operands, you
would need multiple controlled beams (32)
• But, an attacker wouldn’t even want that:
just shake out the keys and clone a victim
53

54. Analysis & Mitigation
• How do I know if my smart card is vulnerable?
– Risk analysis
– Source code review
– Security testing
• How can I protect my smart cards?
– Use newest and certified chips
– Harden your code (OS & application)
http://www.riscure.com/fileadmin/images/Docs/Paper_Side_Channel_Patterns.pdf
54

55. Future research
Automation
• Can we further automate the analysis and
reduce user intervention?
• Can we reverse engineer code by analyzing
fault impact?
Multi beam attacks
• Can we by-pass multiple defenses if separate
laser beams are used?
• Can we push specific values on a data bus?
55

56. Summary and conclusion
• Fault injection is most significant threat for smart
cards
• Diode laser systems generate fast and precise
pulses that modify CPU instructions
• Sophisticated new fault injection equipment
defeats countermeasures
• Best defense by mix of strong hardware and
software countermeasures
56

57. 57
Questions & Discussion
Marc Witteman
Chief Technology Officer
witteman@riscure.com
Riscure B.V.
Frontier Building
Delftechpark 49
2628 XJ Delft
The Netherlands
Phone: +31 (0)15 251 4090
www.riscure.com
Thank you
57