In the time when software is so complex and rapidly changing so, the users cannot trust their own computers and smartphones to protect their secrets from attackers, more and more solutions rely on hardware to be the last measure of protection. As a result, there are a number of manufacturers developing hardware wallets which are meant to protect cryptocurrency private keys. This talk presents a wide range of attacks, which can be successfully applied to most popular hardware wallets on the market, from app isolation bypass to fault injection attacks on the microcontroller. Additionally the talk presents secure design requirements and countermeasures making life of an attacker much more difficult, which are applicable to all kings of secure hardware devices.

1. 1
Hardware Wallet Security
Sergei Volokitin

2. 2
What is a hardware wallet?
• Secure device with:
• Connection to PC/smartphone/network
• Trusted screen
• Trusted controls
• Protected firmware
• Tamper resistant

3. 3
What is a hardware wallet?

4. 4
Who is your attacker?
• Somebody who controls your computer
• Malware
• Another user
• Somebody who has physical access to the device
• Flatmate
• Evil maid
• Thief
• Somebody who had access to the device before you got it:
• Courier
• Evil maid government
• Previous owner

5. 5
Security features
• Secrets never leave the device
• Small API
• Protected memory
• There is no easy way to access keys
• Protected firmware
• The authenticity of firmware is verified on boot and updates
Generated
Stored
Used
Wiped

6. 6
Software attacks – Leger Nano S

7. 7
Software attacks

8. 8
Software attacks

9. 9
Software attacks
• MPU isolates memory
• Application has
• ~16 KB of Flash
• ~1 KB of RAM
• Over 100 syscalls

10. 10
Vulnerabilities
• x4 vulnerabilities in the system calls
• partial memory disclosure of the following app
• partial memory disclosure due to null pointer dereferencing
• memory oracle on all the system memory
• Vulnerability in memory protection of debug app
• Vulnerability in device wipe process
• Vulnerability allowing supply chain attack

11. 11
Vulnerabilities
• x4 vulnerabilities in the system calls
• partial memory disclosure of the following app
• partial memory disclosure due to null pointer dereferencing
• memory oracle on all the system memory
• Vulnerability in memory protection of debug app
• Vulnerability in device wipe process
• Vulnerability allowing supply chain attack

12. 13
Debug app installation flag
• There are per application flags you can set, such as:
• Application with debug flag can read ~16kB of flash belonging to another
app!

13. 14
Debug app installation flag
U2F App Flash
BTC App Flash
System Flash
Debug App Flash

14. 15
Debug app installation flag
U2F App Flash
BTC App Flash
System Flash
Debug App Flash

15. 16
Debug app installation flag
BTC App Flash
System Flash
Debug App Flash

16. 17
Debug app installation flag
System Flash
Debug App Flash

17. 18
Flash state after device wipe

18. 19
Secrets in Flash memory
• The keys should not be stored in flash if possible

19. 21
Conclusions
• Software cannot be trusted
• Large attack surface difficult to protect
• Even small bugs, combined, can lead to an attack
The end?

20. 22
No software bug no exploit?

21. 23
Features
• STM32
• Flash on the chip
• Large attack surface (22 input commands without auth)
• Built-in 4 digit PIN security lock
• Open Source (bootloader and firmware)
• Built-in onboarding (seed generation and recovery)
• USB connectivity
• Super secure boot with three signatures and five keys!

22. 24
Using HW wallet

23. 25
Hardware architecture
• STM32F205
• 1MB of internal flash
• There is secure boot

24. 26
Why bother with a hardware attack?
• Popular open source project
• SW is tested and patched over time
• General purpose MCU is used to keep the secrets

25. 27
What is FI and how can it help?
• Corrupt data (0x00, 0xFF, 0x??)
• Corrupt instructions
• Skip instructions
• ...

26. 28
Cracking the case

27. 29
Can we glitch it?

28. 30
No code execution, no easy trigger
• The power comes from USB and is quite noisy
• No modifications to the device were made
• When a command is sent a similar pattern is observed
CMD
RESP
GLITCH!

29. 31
Characterization results

30. 32
DEMO

31. 33

32. 34
Glitching the screen output

33. 35
Glitching the screen output

34. 36
Getting full access to the device
GLITCH!

35. 37
SW Design leading to exploitable FI
• The glitch of the if statement is possible but does not change the flash
• fsm_msgResetDevice command once glitched only changes the PIN in RAM
• fsm_msgChangePin compares against the PIN in RAM and saves a new one to FLASH
KeepKey
RAM
PIN
FLASH
PIN
fsm_msgResetDevice
fsm_msgChangePin

36. 38
The attack:
1. Steal Find a device
2. Glitch the lifecycle check
3. Set a new PIN on the device, keep the seed
4. Unlock the device using the new pin
...
5. Get full access to the coins on the device
Getting full access to the device
GLITCH!

37. 39
Getting full access to the device #2
GLITCH!
1.
fsm_ResetDevice()
GLITCH!
GLITCH!
PIN RAM
2.
3.
PIN FLASH
fsm_msgChangePin(PIN RAM)
GLITCH!GLITCH!
GLITCH!
Profit!
4.
…
5.

38. 40
Results
Success rate ~1.2%
Attempt rate 0.3 att/sec
On average it takes 5 minutes to glitch the PIN

39. 41
Conclusions
• Software cannot be trusted
• Large attack surface is difficult to protect
• Even small bugs, combined, can lead to an attack
• Hardware cannot be trusted
• Non-secure hardware is easily glitchable
• Simple FI counter measures are not sufficient against
EMFI

40. 42
The end?

41. 43
Challenge your security
Sergei Volokitin
Security Analyst
📩 sergei@riscure.com