[CB19] Hardware Wallet Security
•
0 likes•98 views
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.
More Related Content
What's hot
What's hot (20)
Similar to [CB19] Hardware Wallet Security
Similar to [CB19] Hardware Wallet Security (20)
More from CODE BLUE
More from CODE BLUE (20)
Recently uploaded
Recently uploaded (16)
[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