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

1. LEDGER
Bitcoin wallets security
Erring on the hardware side

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. 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. 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. 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. #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. Sample programming error
Textbook stack overflow, leading to arbitrary code
execution, in TREZOR 1.2.0
https://github.com/trezor/trezor-
mcu/commit/524f2a957afb66e6a869384aceaca1cb7f9cba60
Reported, fixed quickly, no harm done
Future mitigation with stack protection at compiler level

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. 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. 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. 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. 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. 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. A fail chain (and how to avoid it)
STM32 flash memory interface

15. A fail chain (and how to avoid it)
Typical implementation in libopencm3 (along with a warning.
in the source code.)

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. 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. 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. sector
erase
sector
erase
sector
write
sector erase ...
Gentle trigger event from HW

20. sector
erase
starts
chip reset sequence ...
chip reset sequence ...
sectore erase
starts
Minimal chip voltage reached,
chip reset is triggered by HW.

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. Quick word about other enclaves
Pioneered by Hal Finney for Bitcoin
https://bitcointalk.org/index.php?topic=154290.0
Security to be probed (vendor dependant, RAM isolation
can be tricky,…)
Open source can happen
See Open TEE https://github.com/OP-TEE
Jailowning could be the new Jailbreaking
Commercial approach, see Rivetz talk

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. LEDGER
Questions ?
nicolas@ledger.fr