[CB19] Hardware Wallet Security
0 likes116 views
The document discusses hardware wallet security, highlighting vulnerabilities and potential attacks from various types of attackers, including those with physical access. It emphasizes that software cannot be fully trusted due to a large attack surface, and even minor bugs can lead to significant security breaches. The conclusion warns that both hardware and software require careful consideration and challenges the effectiveness of existing security measures.
[CB19] Hardware Wallet Security
- 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
- 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!
- 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 • ...
- 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!
- 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