This document discusses fault injection attacks on secure boot implementations in embedded systems. It begins by explaining how secure boot works, using a hardware root of trust to verify that only authorized code is executed. It then introduces different methods of fault injection, such as voltage manipulation and electromagnetic interference, that can corrupt code verification and execution. Examples are given of how faults could bypass signature checks or modify execution. Countermeasures at both the software and hardware level are outlined to make systems more robust against fault injection. The document concludes that while hardware roots of trust increase security, physical attacks still remain a threat, and both hardware and software countermeasures are needed to protect against fault injection in secure embedded systems.

1. Session ID:
Session Classification:
Jasper van Woudenberg
Riscure
HTA-T17
Advanced
EmbeddedSystems UnderFire
Fault Injection on SecureBoot

2. ► Many more mod chips available 1 search away
Example: Xbox 360 glitch chip

3. Embedded devices and attacker goals

4. How are devices protected?
► Protect input
►Only authorized code
► Protect output

5. Hardware root of trust

6. Ensuring authorized code
►App
►OS
►Flash
►ROM loader

7. ► CPU starts executing ROM
► Immutable, programmed during manufacturing
► Trust starts here (root)
► ROM loads patches
► Verifies digital signature!
► ROM loads OS
► Verifies digital signature!
► OS includes Card manager
► Any applets that are installed are first digitally verified
► Result: all code on platform verified
Example typical JavaCard smart card

8. ► (simplified)
► Primary Boot Loader in ROM
► Device Boot Loader (flash)
► Secondary Boot Loader (flash)
► Realtime Executive (flash)
► Hboot (flash)
► Linux / Android (flash)
► http://tjworld.net/wiki/Android/HTC/Vision/BootProcess
Example HTCVision

9. ►
► CPU loads UEFI firmware
► (verification?)
► Driver and Boot application signature
verification
► Using (forbidden) signature database, (updated
by KEK (updated by PK))
► (Measure components into TPM)
► When Secure boot enabled, require signed
UEFI OS
► OS verifies drivers, boots
► (many applications also digitally signed)
Example PC with UEFI secure boot

10. Model appropriate?
► Protect input
►Only authorized code
► Protect output

11. Fault injection

12. ► Spike/dip supply voltage
► Long: reset (boring)
► Short: corruption (interesting)
Voltage FI
Threshold of
read value A power dip at the moment of
reading a memory cell

13. ► Introduce malformed clock
► Spikes or dips cause temporary extra cycle
► Instruction / data corruption
Clock FI

14. ► EM:
► Introduce a current intro a
circuit
► Affect RNG
EM injection

15. ► Photons are absorbed by electrons in silicon
► Absorbed photons increase electron energy
► Increasing the semiconductor conductivity
► Can produce temporary faults
Optical injection

16. ► Data corruption
► Changing verification key
► Address line pulling
► Execute / verify different memory
► Instruction skipping
► Flip branches
► http://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-
was-hacked/
► http://www.free60.org/Reset_Glitch_Hack
Fault injection effects

17. Address line attack
►Execute
►Check sig
►Execute

18. ► Vi pin.c
Branching example (C)

19. Branching example (x86)

20. ►
► Successful fault requires many
parameters to be tuned correctly
► Know (or guess) from design,
source, experience
► Temporary fault allows reset &
retry
► Scan over parameter ranges
Finding injection parameters

21. Parameters vs faults

22. ► Root of trust depends on binary decision
►
physical access could circumvent signature verification
► Depending on technology, can be
► Highly repeatable
► Cheaply exploitable
FI as threat to hardware root of trust

23. Countermeasures

24. ► Multiple checking sensitive results
► Branchless algorithms
► Random wait loops
► Usually risk based because of (computational) cost
Countermeasuressoftware

25. ► Active and passive shielding
► Supply voltage monitoring, buffering
► Temperature sensors
► Internal clock (unstable)
► Optical sensors on die
► Image: flylogic.net
Countermeasureshardware

26. ► Main CPU instructs crypto core
to execute crypto n times
► Checks result is the same
► Fault crypto core in same way -
> difficult
► Fault crypto core AND attack
result check on main CPU ->
two locations!
Multiarea checks

27. ► Success rate exponentially decreases with attempts, e.g.
► Forcing an attacker to require multiple faults makes
attacking exponentially harder
►

28. Future / wrapup

29. Model appropriate?
► Protect input
►Only authorized code
► Protect output
Code
►Protect authorized code

30. ► Logical: 1992 (introduction
GSM SIM cards)
► Physical: 1994
► SCA: 1997
► FI: 1999 (power)
Attack timeline
► Logical: forever
► SCA: 2004 (payment
terminals)
► Physical: 2006 (STBs,
Riscure)
► FI: 2008 (PCB address line
manipulation)

31. ► Physical/SCA/FI attacks about 9 years later on embedded
than on smart cards
► Logical attacks are getting harder..
► .. FI is becoming relevant (and systems are being broken)
Attacker economics

32. ► Improved logical (software) security, combined with attacker
economics leads to hardware attacks
► As seen in the smart card industry
► As we are seeing in the embedded market (STB, mobile)
► (as we will see in the PC market?)
► Hardware root of trust creates protection against simple
injection of unauthorized code
► Not physical attacks!
Conclusions

33. ► The security of a hardware root of trust depends on the
countermeasures implemented
► Secure systems use both hardware and software
countermeasures
► We discussed FI, also consider SCA, logical, physical
Conclusions

34. Chip(set) manufacturers:
► Build chips with hardware
root of trust an
countermeasures
► Test and improve!
What next?

35. Device developers:
► If you are not implementing software verification, go do that
first
► Choose hardware with a hardware root of trust, and
hardware countermeasures
► Enable software and hardware countermeasures in your
system
► Test and improve!
What next?

36. Questions?