ABSTRACT: Studying and breaking secure hardware is not something that only state-sponsored attackers or highly-funded research groups can perform. Tools are becoming more accessible and you can start learning hardware security at home. Hardware hacking is perceived as black magic or something not important: let's change this misconception, learn about new classes of attacks and how to design secure hardware. BIO: Federico is passionate about IT security and a CTF player with team Tasteless. He is from Trentino, an alumnus of UniTN and EIT Digital, and currently works as Site Reliability Engineer at Google in Munich. Sometimes you can find him playing badly on the ukulele, trying to pronounce Streichholzschachtel, or baking sourdough bread.

1. Exploring Hardware Security
Federico Scrinzi
Speck & Tech - October 2019
@foxTN

2. $ whoami
Hello! I'm Federico :)
Past:
FBK, Spaziodati, Riscure
Now:
Senior SRE at Google
- Authorization systems / BeyondCorp
- CI and other devtools
Interested in infosec
CTF player with Tasteless
Practicing German, Yoga, Ukulele, ...
Note: opinions are my own, not of my current or previous employers. This is not a sponsored talk.

3. Why this talk?
Hardware security is
perceived as black magic!

4. Why should I care
about hardware?
I'm a software
person! Source: WIkipedia

5. Software relies on
guarantees given by
the hardware

7. By knowing the
limitations of the
hardware you can
build better products

8. Why do we need secure hardware?
So many use cases:
● Smart cards (e.g. credit cards, bus tickets/subscriptions)
● Pay-TV systems
● Gaming consoles
● IoT sensors
● Cryptocurrency wallets
● Security keys (e.g. U2F)
● ...

9. Why do we need secure hardware?
Many of these devices:
● contain secrets that would be interesting to extract
● might have protections to restrict their use case
...and they are computers on a small scale essentially
How can their security properties get broken?

10. Be creative with the attack surface
It's not only finding bugs in the firmware or design flaws in the production (e.g.
accessible pins, debug modes, etc..)
If we have physical access to the target we can do much more!
● What if we measure power / heat / electromagnetic emissions?
● How does a CPU react to a strong light source / laser?
What if we cut the power at a given time? Or give a different clock? Or put the
device in the oven?

11. Side channel attacks
The main idea is to measure side effects of the hardware to extract secrets
Power consumption is the most common side channel
but there are also temperature, sound, electromagnetic emissions, etc...
Source: P. Kocher et al. "Introduction to differential power analysis"c

12. Fault injection / glitching
Trigger unexpected behavior by putting the hardware in non-standard conditions
● Voltage glitching:
● Clock glitching:
● but also lasers, ovens, and more esoteric stuff
This allows to generate bugs even if the software is perfect!
int debug = 0;
if (debug) {
printf(secret_key); ← how can we execute this?
}

13. But c'mon, these attacks are impractical
● The equipment must cost a lot of money!
● They must require some state agency level lab!
● I will never be able to do that! It's too complicated!
● It must be just theoretical stuff that will never work in practice!

14. But c'mon, these attacks are impractical
● The equipment must cost a lot of money!
○ noopwafel@ and Albert at 35c3: side channel attacks with 5€ of
equipment
○ chip.fail at BHUSA'19: glitching equipment for 5$
● They must require some state agency level lab!
○ You can get a Chipwhisperer for 250$ and some basic electronic supply
and do security research at home
● I will never be able to do that! It's too complicated!
○ Check LiveOverflow videos on the topic
● It must be just theoretical stuff that will never work in
practice!
○ Many recent attacks: Nintendo Switch, various security keys, Wacom
tablets, etc...

15. Demo: ChipWhisperer
https://newae.com/tools/chipwhisperer/
About 250$ for the Chipwhisperer Lite. It looks like a Nano version will be cheaper.
Made by Colin O'Flynn (kudos to him for providing the hardware for tonight)
● Open Source toolchain
● Essentially a FPGA (Spartan 6 LX9) and an ADC
● Can do power analysis, voltage and clock glitching

16. Demo 1: timing
uint8_t passbad = 0;
for (uint8_t i = 0; i < sizeof(correct_passwd); i++){
if (correct_passwd[i] != passwd[i]){
passbad = 1;
break;
}
}
if (passbad) {
puts("PASSWORD FAILn");
} else {
puts("Access granted, Welcome!n")
}

17. DEMO

18. Power traces
"XXXXX" "SXXXX"
S

19. S p e c kS p e c
"SpecX" "Speck"

20. Demo 2: Clock glitching
int passok = 1;
for (cnt = 0; cnt < 5; cnt++){
if (inp[cnt] != passwd[cnt]){
passok = 0;
}
}
if (!passok){
puts("Deniedn");
} else {
puts("Welcomen");
}

21. Clock?
Digital hardware usually needs some kind of reliable clock
Source: Chipwhisperer documentation

22. Clock glitching!
If the clock is "wrong" we can trigger undefined behavior
There is not enough time to execute #1. The instruction might be skipped!
Source: Chipwhisperer documentation

23. DEMO

24. Attack plan
1. Try every possible clock delay / time offset combination in given ranges
2. Send "x" as password and perform the attack
3. .... wait ...
4. At some point the CPU might misbehave and skip instructions!

25. Profit!

26. Tying this back to software
With these techniques we treat hardware as a black box and study how it interacts
with the external world.
Why not doing the same for heavily obfuscated software? (e.g.: DRM, malware, ...)
DES entropy and randomness
Source: F. Scrinzi - "Behavioral analysis of obfuscated code"
AES-128 - Autocorrelation

27. Countermeasures
● Spurious logic / capacitors to flatten power consumption
● Random jitters
● Voltage sensors
● Own clock generators
● Tamper-resistant enclosures
● Hardened software
○ Use 10101010 for True and 01010101 for False values
○ Extra integrity checks
○ Sensitive code in the "else" branch
○ ...

28. Summary:
● When dealing with hardware we have to think differently
● Hardware-related attacks are cheap and easy
● There are many tools out there that you can play with
● Countermeasures can substantially raise the attack cost
Thanks for listening :)
Kudos to Colin O'Flynn, chip.fail crew, noopwafel, Riscure folks, and everyone
out there that enables hardware security research