LEDGER

Bitcoin wallets security Erring on the hardware side

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

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

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

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)

#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

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

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

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 ….

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

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 ?

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)

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

A fail chain (and how to avoid it)

STM32 flash memory interface

A fail chain (and how to avoid it)

Typical implementation in libopencm3 (along with a warning.

in the source code.)

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)

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)

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

sector

erase

sector

erase

sector

write

sector erase ...

Gentle trigger event from HW

sector

erase

starts

chip reset sequence ...

chip reset sequence ...

sectore erase

starts

Minimal chip voltage reached,

chip reset is triggered by HW.

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

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

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)

LEDGER

Questions ? nicolas@ledger.fr