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