Cryptocurrencies Hardware Wallets - 33C3 Bitcoin Assembly

1. Cryptocurrencies Hardware Wallets
33C3 Bitcoin Assembly
@btchip

2. Why ? Cryptocurrencies come with built-in bug bounties
#SFYL
CO 2.0
(Etienne Daho, theoretical
singer, so it makes
a good joke, at least in
french)

3. An already well developed ecosystem

4. Owning cryptocurrencies == owning private keys (on secp256k1)
Owning private keys is a complicated problem
Many possible attacks
Online : plain old scam, exchange security problem, outdated security (hello SMS
2FA)
Software : non creative (sweeping keys) or more creative malware, bad crypto,
phishing

5. Need for a new device class
Protect private keys (basic functionality)
Protect against creative malware
Easy to install, easy to use, easy to recover, as plug & play as possible
Easy to audit (don’t trust, verify)
Easy to tinker (cryptocurrencies are a continuous R&D effort)

6. Typical operation
0 Initialize the Hardware Wallet (once, or recovering)
1 Send the public data to sign (Bitcoin transaction, Ethereum contract data)
2 Verify what’s going to be signed on the device
3 User confirmation that cannot be faked by malware
4 Signing operation happens on device
5 Public data returned to the host (computer / phone)
6 Public data broadcasted to the blockchain by the host

7. Being easy to recover
Hierarchical Deterministic wallet concept (BIP 32) : derive keys from a seed + index

8. Being easy to recover
Optionally BIP 39 and BIP 44 on top of it : encode the seed into mnemonic words
https://iancoleman.github.io/bip39/

9. Providing good crypto
Limit dependencies on randomness as much as possible
- Hierarchical Deterministic wallets
- Deterministic signing (RFC 6979), avoids ECDSA nonce reuse by design
Limit side channel attacks
- Constant time signing (https://github.com/bitcoin-core/secp256k1)
- For more complex DPA, YMMV. Still a lot of specialized work per chip.

10. Why not a vanilla smartcard ?
Protect private keys // yes
Protect against creative malware // not really, see PIN MITM
Easy to install, easy to use, as plug & play as possible // not really, see CCID
Easy to audit // absolutely not
Easy to tinker // no, Java Card being the most open environment available
Still possible to do stuff : see Fidesmo, Bitcoin Wallet implementation
https://github.com/ledgerhq/ledger-javacard

11. Different vendors, different implementation strategies
Fully Open Source approach
+ Open MCU
+ Fully auditable firmware
- Distribution and attestation issues
- Physical attacks
Secure chip based approach
+ Proved model for distribution and attestation
+ Designed to protect against physical attacks
- Not fully open, striving to reduce the TCB
- Involving specialized hardware

12. Ledger platform architecture
Trusted / Secure component
(Secure Element or enclave)
with limited I/O options
Non trusted component
with more I/O options
Screen
Direct control from the Trusted component, proxied
Pairing at boot
time
User app 1
User app 2
Button
Sensor
USB

13. Improving on isolation, using ARM capabilities
Native application 1
Native application 2
Native application 3
Microkernel
User
seed
MMU lock
User modeSupervisor mode
System call
UI application