Cryptocurrencies Hardware Wallets
33C3 Bitcoin Assembly
@btchip
Why ? Cryptocurrencies come with built-in bug bounties
#SFYL
CO 2.0
(Etienne Daho, theoretical singer, so it makesa good joke, at least in french)
An already well developed ecosystem
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
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)
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
Being easy to recover
Hierarchical Deterministic wallet concept (BIP 32) : derive keys from a seed + index
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/
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.
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
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
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
Improving on isolation, using ARM capabilities
Native application 1
Native application 2
Native application 3
MicrokernelUserseed
MMU lock
User modeSupervisor mode
System call
UI application