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
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
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
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
►
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
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?
