Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Bitcoin hardware wallets security


Published on

A deep dive into Bitcoin hardware wallets security. Illustrating weaknesses of hardware wallets based on regular (not secure) microcontrollers such as the Trezor.

Published in: Engineering

Bitcoin hardware wallets security

  1. 1. LEDGER Bitcoin wallets security Erring on the hardware side
  2. 2. About the speaker Nicolas Bacca, CTO of Ledger (previously BTChip), designing hardware wallets (Ledger Wallet, USB smartcard being the first) 15 years smartcard / embedded security industry experience Engineer by day, reverse engineer by night Jailbreaking things since 2002
  3. 3. Risks, threats and mitigations Theft => encrypted USB drives, BIP 38 Bad crypto Programming errors => audits ... Brittle RNGs => RFC 6979 Malware => multi signature, BIP 70 Dumb (sweeping private keys) Smart Adapting to your environment Abusing crypto
  4. 4. What’s needed Protection against physical theft Protection against malware Protection of the private keys, critical asset Validation of what is getting signed, in a trusted environment Protection against bad cryptography Trustworthy RNG Side channel resistant implementation
  5. 5. Hardware Wallet Physical device offering those guarantees Or isolated enclave offering those guarantees Attacks on hardware wallets Programming error (resulting in code execution) Non invasive (SPA / DPA) Slightly invasive (glitching) Destructive (chip reverse engineering)
  6. 6. #TLDR protection profile Hardware Wallet should not leak secrets on the go with a not too intrusive attack An attacker that did his homework previously should not be able to run a SPA / glitching attack in a shop Hardware Wallet should take some time to leak secrets when borrowed, preferably only using a highly intrusive method Value of acceptable time may vary, let’s say 1 day
  7. 7. Sample programming error Textbook stack overflow, leading to arbitrary code execution, in TREZOR 1.2.0 mcu/commit/524f2a957afb66e6a869384aceaca1cb7f9cba60 Reported, fixed quickly, no harm done Future mitigation with stack protection at compiler level
  8. 8. Simple Power Analysis (SPA) Based on direct mapping between CPU instructions + operand and current consumption Non invasive, non detectable Easy, low cost, and fast (once calibrated) Basically allows to read the code flow on oscilloscope
  9. 9. SPA apllied to Bitcoin ECC Scalar multiplication (also consider Modular inversion, Montgomery mult) Input: scalar k, P point k = {kn-1...k0}, kn-1 == 1 Output: R=k.P R = ϑ for i = n-1 to 0 R = R² if ki == 1 R = R+P end s = kinv (h + r.d) => d = (s.k - h) . rinv 1 0 1 1 ….
  10. 10. Differential Power Analysis (DPA) Non invasive, non detectable attack Direct mapping between CPU instruction + operand and current consumption Not so easy, middle cost, longer time to set up Retrieve secret value through mathematical analysis of multiple high precision oscilloscope acquisitions
  11. 11. Differential Power Analysis (DPA) Need to be able to fix all input value except one in attacked code In theory, ECDSA signature no really DPA vulnerable due to random k BUT: RFC 6979 make ECDSA DPA vulnerable at two levels: we control all in first step of RFC, except x which is the secret key K = HMAC_K(V || 0x00 || int2bytes(x) || bits2bytes(h1)) s = kinv (h + r.d) : kinv is not known but always fixed for the same input Lack of real world attacks on this, anyone interested ?
  12. 12. Fault Injections Vulnerabilities Invasive, hard to detect attack, unless hardware helps Hard, high cost for bus/memory modifications Hard, low/middle cost for clock/Vcc glitching on non secure chips Retrieve secret value through mathematical analysis of multiple correct and incorrect computation (or fail chain) Main type of attack: C Safe Error M Safe Error Differential Fault Analysis (DFA)
  13. 13. A fail chain (and how to avoid it) Read The Fine Chip Datasheets Use your Open Source libraries with a large amount of salt The “many eyes” paradigm doesn’t scale well for complex (OpenSSL) or boring (X-Win) security issues Read them more
  14. 14. A fail chain (and how to avoid it) STM32 flash memory interface
  15. 15. A fail chain (and how to avoid it) Typical implementation in libopencm3 (along with a warning. in the source code.)
  16. 16. A fail chain (and how to avoid it) Consequence : free lunch if a flash operation fails and no status check (glitch it in the most unsubtle way possible, keep running happily)
  17. 17. A fail chain (and how to avoid it) Read The Fine Chip Datasheets (think I mentioned that already) Design your code with glitching in mind Isolate critical operations and recheck them Use appropriate Hamming distance for your critical constants (no, 0 for False, everything else for True doesn’t cut it) Use appropriate hardware (if it can run with arbitrary clock and voltage, or offers JTAG+lolfuse, good luck)
  18. 18. Sampling security in 2 minutes PIN/passwords with limited attempts implementations are nice to check and allow trivial attacks. Timing attacks when comparing (SPA) memcmp fail Easy glitching attacks (Fault injection) increase attempts after check fail insecure check fail
  19. 19. sector erase sector erase sector write sector erase ... Gentle trigger event from HW
  20. 20. sector erase starts chip reset sequence ... chip reset sequence ... sectore erase starts Minimal chip voltage reached, chip reset is triggered by HW.
  21. 21. Why smartcards help Designed to prevent trivial clock / voltage glitching Hardware validation of code paths Usually come with cryptographic libraries that are SPA/DPA/DFA resistant Including patent licensing … Small attack surface, being a dedicated hardware component
  22. 22. Quick word about other enclaves Pioneered by Hal Finney for Bitcoin Security to be probed (vendor dependant, RAM isolation can be tricky,…) Open source can happen See Open TEE Jailowning could be the new Jailbreaking Commercial approach, see Rivetz talk
  23. 23. Conclusion More eyes and hands needed Consider hardware & software together Break more hardware ! Failsafes If the hardware can’t hodl by design, fail gracefully (passphrases on microcontrollers based hardware wallets)
  24. 24. LEDGER Questions ?