Cryptocurrency hardware wallets provide a secure way to store private keys by protecting them in a dedicated device. They address risks of online attacks, malware, and phishing by requiring confirmation on the hardware device. A new class of devices was needed that makes private key storage easy to use, recoverable, auditable, and adaptable while protecting against creative malware and side channel attacks through techniques like deterministic signing, constant time crypto, and isolation between trusted and non-trusted components. Popular implementations take different approaches by being fully open source versus using a secure element, but aim to balance security, auditability and ease of use.

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