Bitcoin hardware wallets security

Download Bitcoin hardware wallets security

Post on 14-Jul-2015

1.694 views

Category:

Engineering

3 download

Embed Size (px)

TRANSCRIPT

  • 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

  • Whats 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, lets 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 doesnt 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

    doesnt 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 cant hodl by design, fail gracefully (passphrases on microcontrollers based hardware

    wallets)

  • LEDGER

    Questions ? nicolas@ledger.fr