< Return to Video

35C3 - Wallet Security

  • 0:05 - 0:19
    35c3 preroll music
  • 0:19 - 0:26
    Herald: Give a warm welcome applause for
    Stephan Verbücheln. He is a ...
  • 0:26 - 0:33
    applause
    He is a cryptologist and also security
  • 0:33 - 0:40
    analyst, and he will tell us about wallet
    security. So I'm impressed.
  • 0:40 - 0:46
    Stephan: Hello, can everybody hear me? Ok.
    So I'm Stephan and I will talk about
  • 0:46 - 0:52
    wallet security. First I will give a
    little bit of background what I worked on.
  • 0:52 - 0:56
    So I am a Diplominformatiker which is like
    the old master's degree that they had in
  • 0:56 - 1:02
    Germany, and I work as a security
    consultant in Switzerland. And I've done
  • 1:02 - 1:08
    more research related to blockchains and
    bitcoin, which were related to zero-
  • 1:08 - 1:14
    knowledge proofs, and Zerocoin which is
    the predecessor of predecessor of Zcash.
  • 1:14 - 1:19
    Some people might have heard of Zcash.
    I did research on ECDSA with regards to
  • 1:19 - 1:26
    bitcoin. This is also what
    this talk will be about.
  • 1:26 - 1:28
    For a few months, I also worked
  • 1:28 - 1:35
    on my own blockchain project,
    which failed. (laughs)
  • 1:35 - 1:37
    Later, I worked as a consultant
  • 1:37 - 1:44
    for another blockchain project which was
    released last month. And I also did wallet
  • 1:44 - 1:48
    security reviews for several customers who
    wanted to use their own wallets or wanted
  • 1:48 - 1:53
    to use a wallet and
    wanted to have a review.
  • 1:53 - 1:56
    So this talk will have 5 points.
  • 1:56 - 2:00
    So first we will have a little recap of
    bitcoin and ECDSA, a little bit of
  • 2:00 - 2:04
    background that will help us to
    understand what the next things is about.
  • 2:04 - 2:07
    Then we will talk about wallets.
    What is a wallet?
  • 2:07 - 2:12
    Then we will see a list of common attacks
    that have been found in the last years
  • 2:12 - 2:16
    and then we will talk about a
    more sophisticated attack
  • 2:16 - 2:23
    and then we will come to some
    conclusions about wallet security.
  • 2:23 - 2:27
    So first I think everybody now
    has heard of bitcoin. Regarding this talk
  • 2:27 - 2:34
    I will always talk in terms of bitcoin,
    but the same applies to any cryptocurrency
  • 2:34 - 2:37
    But to make things simpler we will
    use bitcoin as an example. So we
  • 2:37 - 2:41
    have fixed parameters that we work with.
  • 2:41 - 2:45
    So bitcoin basically is... what we need
    to know is the public ledger for
  • 2:45 - 2:49
    transactions.
    Users have public and private keys.
  • 2:49 - 2:54
    They use the private keys to sign
    transactions, and the transactions are
  • 2:54 - 3:00
    published in a blockchain so that
    everybody can verify the transactions.
  • 3:00 - 3:04
    It works like this:
    We have Alice, Bob and Carol,
  • 3:04 - 3:07
    and if Alice wants to send a bitcoin
  • 3:07 - 3:13
    to Bob, then Alice creates the transaction,
    signs it, and broadcast it.
  • 3:13 - 3:15
    Miners will collect it.
  • 3:15 - 3:18
    Miners will put them into the block.
  • 3:18 - 3:24
    And Bob waits until the transaction
    appears and the blockchain.
  • 3:24 - 3:28
    So the creation of the transaction
    consists of the following steps:
  • 3:28 - 3:32
    Alice first creates the transaction
    where it says I will send one bitcoin
  • 3:32 - 3:38
    to Bob. Then she adds Bob's address
    where the bitcoin is going to be
  • 3:38 - 3:42
    sent to and then she signes it with a
    private key. So what's important for us
  • 3:42 - 3:46
    now is basically 2 things: The private
    keys and public keys. they are used for
  • 3:46 - 3:54
    signatures, and all the signatures are
    published in the blockchain.
  • 3:54 - 3:59
    So the signature algorithm that's used in
    bitcoin and in most other blockchains
  • 3:59 - 4:01
    is ECDSA.
  • 4:01 - 4:06
    I think most people have heard about it
    but will give a quick recap on what it is
  • 4:06 - 4:12
    and how it works. So the abbreviation
    stands for Elliptic-Curve Digital
  • 4:12 - 4:21
    Signature Algorithm and it's related to
    many other well-known algorithms. I think
  • 4:21 - 4:25
    everybody has heard about the Diffie-
    Hellman key exchange. This was pretty much
  • 4:25 - 4:32
    the first public key private key
    algorithm. It was based on discrete
  • 4:32 - 4:39
    logarithm modulo a number p. And then Mr.
    El-Gamal, who is also the inventor of SSL,
  • 4:39 - 4:45
    he created the first signature scheme
    based on Diffie-Hellman. And then Mr.
  • 4:45 - 4:51
    Schnorr, Professor Schnorr from Frankfurt,
    he made the signature scheme more
  • 4:51 - 4:59
    efficient. And then the American
    government took the Schnorr signature and
  • 4:59 - 5:06
    created the Digital Signature Algorithm,
    which is a standardized version of the
  • 5:06 - 5:16
    Schnorr signature, which also standardizes
    to use SHA as a hash function. And ECDSA
  • 5:16 - 5:23
    is the same algorithm as DSA, but built on
    elliptic curves instead of discrete
  • 5:23 - 5:29
    logarithm with numbers. So what's an
    elliptic curve? Oh, no first: Why do we
  • 5:29 - 5:33
    use elliptic curves in the first place?
    The problem with the old algorithms, most
  • 5:33 - 5:39
    importantly RSA and DH, Diffie-Hellman,
    and also DSA, which is related to Diffie-
  • 5:39 - 5:42
    Hellman, they have, unfortunately, they
    have no future, because the keys are
  • 5:42 - 5:48
    pretty big. The algorithm gets fit gets
    pretty inefficient. And now if you
  • 5:48 - 5:55
    increase the key size you don't gain much
    more security. If you want to have a key.
  • 5:55 - 6:01
    So, if you have a 2000 bit RSA key and a
    4000 bit RSA key then the 4000 bit key is
  • 6:01 - 6:07
    not twice as secure, but only a little bit
    more secure. And if you really would like
  • 6:07 - 6:12
    to have a twice as secure key for RSA for
    example, or for Diffie-Hellman, you would
  • 6:12 - 6:21
    need 15000 bits, and that's very
    inefficient. So, elliptic curves are quite
  • 6:21 - 6:29
    a solution that's used nowadays in order
    to get a more efficient algorithm. So
  • 6:29 - 6:35
    what's an elliptic curve? Elliptic curves
    are curves that are defined by an equation
  • 6:35 - 6:45
    y² = x³ + ax + b. And the element
    that we are talking about in the algorithm
  • 6:45 - 6:54
    are points on that curve, so we can see
    the curve on these pictures and the curve
  • 6:54 - 7:01
    has the property that, if you draw a
    straight crossing the curve, the straight
  • 7:01 - 7:12
    will like intersect the curve only at a
    maximum of three points. And based on that
  • 7:12 - 7:18
    we define operations. So we can, for
    example, define additional points: So if
  • 7:18 - 7:24
    you see on the left picture the points P
    and Q, if you want to define an addition
  • 7:24 - 7:33
    of the two points then we say P + Q + R is
    neutral because those are all points on
  • 7:33 - 7:44
    the straight line. So we define P + Q to
    be -R, and -R is the point opposite to R.
  • 7:44 - 7:57
    And in the second picture we see, if we
    want to add a point to itself, then we
  • 7:57 - 8:03
    draw the tangential to the point and the
    tangential will cross the curve at another
  • 8:03 - 8:11
    point and the inverse of that point will
    be used as a result. So we have, if we
  • 8:11 - 8:21
    want to add Q to Q, we say 2Q to this, the
    result is -P. And with that we have a way
  • 8:21 - 8:30
    to add points to themselves and we can
    scale this up. We can also add Q to Q and
  • 8:30 - 8:39
    Q again, so three times Q, four times Q
    ... and this operation has a nice
  • 8:39 - 8:47
    property, because multiplying a point with
    a number is easy, but the inverse
  • 8:47 - 8:51
    operation is hard to compute. So this is
    the operation where the whole algorithm is
  • 8:51 - 9:01
    based on. So how are signatures with ECDSA
    generated? So first we have a point G
  • 9:01 - 9:06
    which is a fixed point that's already, for
    example with bitcoin, it's already defined
  • 9:06 - 9:12
    to be a certain point. The point has the
    order n, which means that if you add the
  • 9:12 - 9:18
    point to itself n times you will go back
    to the same point. And we also have a hash
  • 9:18 - 9:25
    function h, in the case of bitcoin
    SHA-256, and we have a private key d which
  • 9:25 - 9:30
    is a number, so all lowercase letters here
    are numbers, and we have a public key
  • 9:30 - 9:39
    which is the point Q that you get when you
    multiply the point G by the number d. So,
  • 9:39 - 9:48
    to generate the signature you have to pick
    a random number k. This is also
  • 9:48 - 9:53
    highlighted as red. We will see later that
    it is important to keep the red numbers,
  • 9:53 - 10:00
    so the nonce and the key secret. You
    compute a point R by multiplying the
  • 10:00 - 10:08
    generator point with k. Then you take the
    x coordinate and then you compute the
  • 10:08 - 10:13
    formula in the first line. It is not
    really important how the formula works for
  • 10:13 - 10:19
    us. It's more important which values have
    to be kept secret and which values are
  • 10:19 - 10:25
    published later. And then you return r and
    s. So r and s is a signature for the
  • 10:25 - 10:32
    message m. And to verify it you compute
    the following formula. It's not important
  • 10:32 - 10:37
    to see immediately that it works but this
    is how the algorithm is defined. What's
  • 10:37 - 10:45
    important to know is that for verifying
    you don't need to know the secret k and
  • 10:45 - 10:53
    you also don't need to know the private
    key of course but you use a public key Q.
  • 10:53 - 10:59
    So this algorithm has the property that
    was already published with the first paper
  • 10:59 - 11:06
    where the algorithm was defined. The nonce
    k which is highlighted as red and needs to
  • 11:06 - 11:13
    be kept secret, because if you know the
    nonce k you can use the parameters that
  • 11:13 - 11:21
    you get in the signature to compute the
    private key. And so stealing the nonce k
  • 11:21 - 11:27
    for one signature is equivalent to
    stealing the secret key. That's common
  • 11:27 - 11:33
    knowledge. But it will be important later
    on. So now we will talk about what the
  • 11:33 - 11:38
    wallet is. So we have seen Bitcoin
    basically in bitcoin you have a private
  • 11:38 - 11:45
    key and a public key and the private key
    is used to spend Bitcoins. So if someone
  • 11:45 - 11:50
    gets access to your private key he will be
    able to spend your bitcoins. So you want
  • 11:50 - 11:53
    to protect your private key and the
    software that you use to manage your
  • 11:53 - 11:58
    private keys is called wallets. So there
    are different types of wallets that you
  • 11:58 - 12:05
    can distinguish. So the simplest type is
    software wallets. You just have the
  • 12:05 - 12:09
    software that generates your keys and
    stores your keys in a file, potentially
  • 12:09 - 12:14
    protected with a password. A software
    wallet is easy to use. It can be used on a
  • 12:14 - 12:20
    desktop, on a laptop, on the phone, on the
    server - if you have an online shop. It's
  • 12:20 - 12:26
    flexible: You can modify it, you can
    update it. But it has the problem that the
  • 12:26 - 12:30
    keys are on a machine where a lot of
    things are working. So if you have for
  • 12:30 - 12:37
    example malware on the machine it can be
    stolen. Then you have hardware wallets.
  • 12:37 - 12:40
    Yesterday there was another talk about
    hardware wallets. So hardware wallets are
  • 12:40 - 12:47
    dedicated devices for example USB devices
    or an offline laptop that are used to
  • 12:47 - 12:54
    manage your keys. So the advantage of it
    is that you don't have the keys on a host
  • 12:54 - 12:58
    where malware, for example, could steal
    the keys. You have them on a separate
  • 12:58 - 13:05
    device. One problem with hardware wallets
    is if you have a small device with only
  • 13:05 - 13:08
    two buttons you need to make sure that you
    are actually signing what you think you
  • 13:08 - 13:14
    are signing, but that's another problem
    and the new wallets all have quite large
  • 13:14 - 13:19
    displays where they show the transaction
    that they are signing so this is quite a
  • 13:19 - 13:27
    solved problem. There's actually a third
    type of wallet which I put together as a
  • 13:27 - 13:32
    paper wallet. So you can print out your
    key on paper put it in a safe and nobody
  • 13:32 - 13:37
    will be able to steal it. But of course
    you will not be able to use it until you
  • 13:37 - 13:42
    enter your paper wallet - your key from
    your paper wallet - into a computer
  • 13:42 - 13:48
    because you don't want to do the
    computations by hand. So hardware wallets
  • 13:48 - 13:53
    have another... So there's another
    distinction that you can do different from
  • 13:53 - 13:58
    hardware wallets and software wallets. You
    can use crypto hardware for example every
  • 13:58 - 14:03
    smartphone nowadays, for example the
    iPhone, has a little chip that's used to
  • 14:03 - 14:13
    manage keys. So I titled this as Hardware
    Key Storage. So you can have a chip that
  • 14:13 - 14:19
    generates keys or you import keys and the
    chip does not allow you to export keys, so
  • 14:19 - 14:29
    you can be sure that the key will never
    lose the device - never leave the device and all
  • 14:29 - 14:32
    the signatures are performed inside the
    module. So you really don't need to see
  • 14:32 - 14:38
    the key. You only need to ask the module
    to sign something for you. This kind of
  • 14:38 - 14:44
    hardware key storages are quite advanced
    nowadays. They were used in chip cards for
  • 14:44 - 14:47
    decades. They are used in the iPhone. They
    are one of the reason why the FBI can't
  • 14:47 - 14:59
    break the iPhone but there is one note to
    make. It's important to have access
  • 14:59 - 15:04
    control to this hardware key store because
    for example if you have a jailbreaked
  • 15:04 - 15:09
    iPhone then your jailbreaked iPhone can
    always pretend to be the app that's
  • 15:09 - 15:15
    privileged to use the key. So root access
    always allows you to use the key. That was
  • 15:15 - 15:21
    also exploited in the talk yesterday for
    the ledger wallet. Once you control the
  • 15:21 - 15:28
    main CPU and once you boot your own
    firmware you can use your own firmware to
  • 15:28 - 15:38
    access the keys. You cannot read them but
    you can use them. And there are some more downsides.
  • 15:38 - 15:42
    If you have a bug in your
    hardware key module you cannot fix it.
  • 15:42 - 15:48
    There was a famous case last year. My work
    laptop was actually affected. There was an
  • 15:48 - 15:53
    Infineon chip, i think, where they had a
    bad random number generator and it turned
  • 15:53 - 15:58
    out that chip was used in many products.
    It was used in the Yubikey device I thing
  • 15:58 - 16:05
    and it was also used in many HP laptops.
    It was also used for disk encryption by
  • 16:05 - 16:11
    windows and the second downside is that
    the implementation cannot be validated by
  • 16:11 - 16:17
    the user. If you have your own computer
    where you have some understanding what's
  • 16:17 - 16:20
    running what's not running you can always
    look at the source code, compile it
  • 16:20 - 16:25
    yourself and you have some idea what the
    wallet is doing. If you have just a little
  • 16:25 - 16:30
    token that you plug in by USB then you
    don't actually know what it is doing. And
  • 16:30 - 16:37
    that will be important later on for our
    tech. So some examples in servers you have
  • 16:37 - 16:46
    HSMs. They are sometimes not really used to
    like protect keys but also to increase
  • 16:46 - 16:51
    performance. If a server does a lot of
    encryption it's better to have a hardware
  • 16:51 - 16:56
    module but those hardware modules
    typically also store keys and then you
  • 16:56 - 17:05
    have TPM chips in business laptops and you
    have smartphones like the iPhone. Yes. So
  • 17:05 - 17:09
    what are common problems and attacks that
    we've seen with wallets so far in the last
  • 17:09 - 17:15
    years. So the most obvious attack is keys
    are stolen via network. Someone has a
  • 17:15 - 17:20
    software wallet on its Windows machine
    installed some malware by accident by
  • 17:20 - 17:33
    clicking on some e-mail link and the
    malware can steal the keys. So another
  • 17:33 - 17:40
    kind of attack is if you have unsecure
    storage for example if you have a phone
  • 17:40 - 17:45
    where you store your bitcoins and it's
    stolen and the phone is not encrypted and
  • 17:45 - 17:52
    the wallet is not encrypted. People can
    steal the keys and steal your bitcoins and
  • 17:52 - 17:56
    then you have a third kind of attack.
    Where you have bad random numbers or
  • 17:56 - 17:59
    predictable random numbers. That happened
    a lot with bad wallets that were
  • 17:59 - 18:03
    implemented in JavaScript and then if you
    have a bad browser that is generating bad
  • 18:03 - 18:10
    random numbers, the attacker can guess
    your random numbers and this means that
  • 18:10 - 18:16
    they can guess your keys or they can guess
    your nonce k which is equivalent as we
  • 18:16 - 18:22
    have seen. And one more interesting thing
    is that is not only important that you
  • 18:22 - 18:28
    keep your nonce k secret it's also
    important that you use it only once. So if
  • 18:28 - 18:35
    you use it twice, the attacker can also
    compute your private key even without
  • 18:35 - 18:40
    knowing k. And one problem with bitcoin is
    all the signatures are published on the
  • 18:40 - 18:45
    blockchain. So attackers can just scan the
    blockchain and see if the number k is
  • 18:45 - 18:49
    appearing for two times and then steal the
    bitcoins. That happens a lot. So if this
  • 18:49 - 18:54
    happens to you the bitcoins will probably
    be stolen in one hour because somebody is
  • 18:54 - 18:59
    always scanning the block chain and in the
    early days of bitcoin this attack also
  • 18:59 - 19:11
    happened a lot. But now we want to talk
    about a more sophisticated kind of attack
  • 19:11 - 19:15
    which is the backdoor in a random number
    generator which is not just bad random
  • 19:15 - 19:19
    numbers but intentionally when random numbers can be predicted by an
  • 19:19 - 19:24
    attacker. One famous example for
    backdoored random number generator was the
  • 19:24 - 19:30
    Dual_EC_DRBG when it was standardized by
    the - so that's the standard by the US
  • 19:30 - 19:36
    government for random bit generator. And
    there were some parameters in this
  • 19:36 - 19:42
    algorithm that were selected by the US
    government but they couldn't explain why
  • 19:42 - 19:46
    they selected them. And there was no need
    for selecting them in a cryptographic
  • 19:46 - 19:54
    point of view. So there was suspicion that
    they were selected in a certain way in
  • 19:54 - 20:01
    order to predict random numbers. And later
    when Edward Snowden had his files released
  • 20:01 - 20:09
    there was some documentation that they
    actually did this. So what could an
  • 20:09 - 20:16
    attacker do with a backdoored random
    number generator. So every time the user
  • 20:16 - 20:21
    generates a signature it needs to generate
    an nonce k. And if this nonce k is
  • 20:21 - 20:30
    generated by the backdoored random number
    generator then the attacker can later on -
  • 20:30 - 20:39
    so the attacker wants to make the wallet
    of the victim to generate random number ks
  • 20:39 - 20:45
    and a nonce k in a bad way. And the
    attacker then later on scans all the
  • 20:45 - 20:49
    transactions on the blockchain in order to
    find the victim's transactions and the
  • 20:49 - 20:53
    victim's signatures and then uses his
    backdoor knowledge in order to compute the
  • 20:53 - 21:00
    secret key. And then after he has a secret
    key he can steal the bitcoins. So we will
  • 21:00 - 21:05
    talk about something that's called
    Kleptograms. Kleptograms were first
  • 21:05 - 21:15
    introduced by Adam young and Moti Yung in
    1997. Back then it was based on the
  • 21:15 - 21:21
    classical DSA but it's very similar to the
    elliptic curve DSA. Because we have some
  • 21:21 - 21:27
    more formulas now I will have a little
    description so all lowercase letters are
  • 21:27 - 21:34
    numbers, all capital letters a points on
    the elliptic curve, all Greek letters
  • 21:34 - 21:41
    are constants and this function R is a
    random number generator but this is not
  • 21:41 - 21:44
    the backdoored random number generator,
    but the real random number generator that
  • 21:44 - 21:51
    we assume is strong. So it has some
    properties for example that it's not
  • 21:51 - 21:56
    possible to efficiently distinguish
    between the numbers generated by this
  • 21:56 - 22:03
    random number generator and actual random
    numbers. So if you want to do - if you
  • 22:03 - 22:09
    want to generate two numbers k1 and k2
    which are used as nonces in this ECDSA
  • 22:09 - 22:16
    signatures and we later want that the
    attacker can use these signatures to
  • 22:16 - 22:23
    compute the private key then we can do a
    simple thing. The first random number we
  • 22:23 - 22:30
    can just pick randomly. So we have the
    random number k1 and we can store k1 and
  • 22:30 - 22:38
    we can output k1 to the wallet and the
    wallet will use k1 and R1 which is the
  • 22:38 - 22:48
    point which is - Yes the point that is
    generated if you multiply the point G with
  • 22:48 - 22:56
    k1. k1 and R1 are used for the signature
    and R1 will be published on the blockchain
  • 22:56 - 23:04
    with the signature and then the second
    round we'll compute k2 as a random number
  • 23:04 - 23:11
    derived from R1 and here we don't pick a
    new random number but we just use the
  • 23:11 - 23:20
    pseudo random number generator. And then
    we output k2 and R2 which is the point for
  • 23:20 - 23:31
    k2 for the second signature. So what can
    we do now? So this the second round again.
  • 23:31 - 23:37
    So if the attacker now wants to know k2 it
    can just scan the blockchain for all
  • 23:37 - 23:43
    values of R1 which are all published on
    the blockchain and then compute k2 by
  • 23:43 - 23:49
    using the random number generator on R1
    and then use it to compute the private
  • 23:49 - 23:54
    key. But there's two problems with this.
    Anyone can use the random number generator
  • 23:54 - 23:59
    so anyone can compute this. So the
    question is whether we can hide this attack.
  • 24:02 - 24:08
    So in order to hide the attack the
    attacker generates his own private key and
  • 24:08 - 24:15
    public key. The random number generator is
    the same as before. And now we generate k1
  • 24:15 - 24:22
    and k2 again, but in a slightly different
    way. For k1 it's the same, k1 is just
  • 24:22 - 24:33
    generated as a random number and it is
    stored and used for the signature and then
  • 24:33 - 24:40
    in a second round we pick a random bit t
    and then we compute the value Z by using
  • 24:40 - 24:45
    the formula that you see in the second
    line it is not important to understand the
  • 24:45 - 24:50
    details of the formula but you need to see
    - the important thing is that the public
  • 24:50 - 25:00
    key of the attacker A is used in this
    formula. And then the second nonce k2 is
  • 25:00 - 25:07
    computed using the random number generator
    on this value Z. And then this value k2 is
  • 25:07 - 25:14
    used for the second signature. So what
    happens now is that because - this is the
  • 25:14 - 25:23
    second round again. So what happens now is
    that the attacker can extract a second
  • 25:23 - 25:31
    value by doing the following computations
    using his private key A. There are two
  • 25:31 - 25:37
    cases. So there are two candidates for k2.
    And it's not clear which one is the right
  • 25:37 - 25:42
    one but it's only like one bit difference
    so you can try both and one of them will
  • 25:42 - 25:47
    be the right one. And because no one else
    has the private key A no one else can do
  • 25:47 - 25:53
    this computation. And because you have the
    random number generator R, you know that
  • 25:53 - 26:06
    the value - the value for k2 is
    undistinguishable from real random numbers
  • 26:06 - 26:12
    because we assume that the random number
    generator is strong. So how do we use this
  • 26:12 - 26:18
    attack on wallets? So the attacker can do
    the following: The attacker can use a
  • 26:18 - 26:23
    popular wallet and backdoor it or can
    create his own wallet and spread it on the
  • 26:23 - 26:28
    Internet and wait for people to use it. So
    then after that the attacker needs some
  • 26:28 - 26:34
    patience. The attacker needs to wait until
    the victim creates some transactions using
  • 26:34 - 26:41
    the wallet and doing that. The
    victims will publish the transactions on
  • 26:41 - 26:45
    the blockchain, so all the values that the
    attacker later wants to have, are published
  • 26:45 - 26:51
    on the block chain and after a while the
    attacker can just scan the whole
  • 26:51 - 26:58
    blockchain for signatures that are
    generated by the same key. And then do the
  • 26:58 - 27:05
    computation that we've seen in order to
    derive private keys. So there's one more
  • 27:05 - 27:10
    footnote to this. The harvest does not
    have to actually be after the patient's
  • 27:10 - 27:18
    phase because even after the attacker
    steals bitcoins, no one can detect the
  • 27:18 - 27:34
    secret in the transaction so it will not -
    like it - it will not disclose the attack.
  • 27:34 - 27:40
    So some properties of the attack are some
    limitations. The attack can only be used
  • 27:40 - 27:47
    if the user uses the same key twice to
    sign transactions. But that's the
  • 27:47 - 27:53
    usual typical use in bitcoin you always
    use your key several times. Sometimes even
  • 27:53 - 27:59
    you even use the same key in the same
    transaction twice. So in some cases even
  • 27:59 - 28:12
    one transaction can be enough to leak the
    private key. And there is another footnote
  • 28:12 - 28:17
    because there is some standard which is
    called BIP32 which is the standard for
  • 28:17 - 28:25
    deriving many keys in bitcoin from one
    seed. And it means that the attacker
  • 28:25 - 28:30
    manages to get one of your private keys it
    might be possible for the attacker to
  • 28:30 - 28:37
    compute more private keys without doing
    more attacks. This attack is independent
  • 28:37 - 28:41
    from how Bitcoin in general works it's
    independent from the consensus algorithm
  • 28:41 - 28:46
    it's independent from mining. It also
    applies to other blockchains that use
  • 28:46 - 28:52
    similar signature schemes some use
    different curves. Some use EdDSA but the
  • 28:52 - 28:59
    attack works for them as well. And the
    backdoor also works with other protocols
  • 28:59 - 29:03
    that don't have anything to do with
    cryptocurrency but in cryptocurrency it's
  • 29:03 - 29:08
    easier because the parameters: the curve
    and the point and everything is already
  • 29:08 - 29:13
    defined by the protocol. You cannot use a
    different curve in Bitcoin. So the
  • 29:13 - 29:18
    attacker always knows which curve you are
    using so the attacker always knows which
  • 29:18 - 29:28
    curve it has to use to hide the secret. So
    what are the conclusions? What does it
  • 29:28 - 29:33
    mean for users? So it means that keys can
    be leaked through the transactions. You don't
  • 29:33 - 29:36
    need a side channel. You don't need a
    second connection you don't need
  • 29:36 - 29:41
    additional data and it cannot be detected
    even if you're looking at the transactions
  • 29:41 - 29:47
    because the random number generator is
    used is indistinguishable from normal
  • 29:47 - 29:53
    random numbers. So what does it mean for
    the user to do? It means that the user
  • 29:53 - 29:58
    should be careful not using untrusted
    wallets. Even if you use them offline they
  • 29:58 - 30:05
    could still leak your keys and that means
    for some applications transparency might
  • 30:05 - 30:10
    be more important than tampering
    resistance. For example it means that it
  • 30:10 - 30:15
    might be worth to have a software wallet
    that you know what it's doing. In contrast
  • 30:15 - 30:21
    to a hardware wallet which might protect
    the key from theft but you don't really
  • 30:21 - 30:27
    know what it's doing when it's generating
    a signature.
  • 30:27 - 30:29
    Yeah, that's it.
  • 30:29 - 30:33
    applaus
  • 30:33 - 30:46
    Herald: So any questions? And so there are
    two microphones. Number 2, Number 1. If
  • 30:46 - 30:53
    any questions please go to the
    microphones. And if you leave the room
  • 30:53 - 30:58
    don't do it in front of the camera, that's
    the stream. If there is any question from
  • 30:58 - 31:03
    the Internet make a sign. I see,
    microphone 2 your question.
  • 31:03 - 31:09
    Microphone 2: Hi. You said that you could
    derive additional private keys if one of
  • 31:09 - 31:15
    the keys leaks in BIP32. It's my
    understanding that that is not possible
  • 31:15 - 31:20
    unless that's the master private key. And
    you know the derivation scheme. So could
  • 31:20 - 31:24
    you elaborate what you meant.
    Stephan: No I was just talking about
  • 31:24 - 31:29
    derived keys in general. Yeah it is not
    that simple. So that's also why I didn't
  • 31:29 - 31:33
    put it on the slides. It depends on the
    scheme that you use for deriving the keys.
  • 31:33 - 31:35
    That's true.
    Microphone 2: All right. Thanks.
  • 31:35 - 31:38
    Stephan: But depending on the scheme you
    need to keep in mind that one key or one
  • 31:38 - 31:43
    secret might be information that you used
    to derive other secrets. Yes.
  • 31:43 - 31:49
    Herald: Okay. Microphone 1.
    Microphone 1: I would just like to maybe
  • 31:49 - 31:55
    have a piece of practical advice from you.
    So given this consideration that you
  • 31:55 - 31:58
    really need to know a bit of the code that
    is running on resource on the wallet.
  • 31:58 - 32:00
    Stephan: Okay. I think speak up a little
    bit.
  • 32:00 - 32:02
    Microphone 1: Yes. Do you hear me better
    now?
  • 32:02 - 32:04
    Stephan: Yes.
    Microphone 1: Okay. So do you think that
  • 32:04 - 32:10
    would be a good alternative to have softer
    wallets running air gapped but softer
  • 32:10 - 32:13
    wallets instead of harder wallets because
    they're easier to audit or to see the
  • 32:13 - 32:16
    source code.
    Stephan: Yeah. The point is that it's
  • 32:16 - 32:20
    better to have a wallet that you control
    that you know what it's doing. Because
  • 32:20 - 32:23
    this if you even if you have a air gap you
    will at some point you will put the
  • 32:23 - 32:28
    transactions from the wallet to the
    network. And if the secret is inside the
  • 32:28 - 32:34
    transaction then the air gap will not help
    you. That's the point. Yes.
  • 32:34 - 32:37
    Herald: And microphone 2 you have another
    question. Okay. Microphone 1.
  • 32:37 - 32:43
    Microphone 1: So if you if I understood
    you correctly this makes the strong
  • 32:43 - 32:49
    assumption that you seed the random number
    generator on the second step with the
  • 32:49 - 32:52
    point generated from the first step. Is
    this correct?
  • 32:52 - 32:55
    Stephan: Yes.
    Microphone 1: And this is something which
  • 32:55 - 33:01
    is like pinstriped from the Bitcoin
    protocol or because I don't see any point
  • 33:01 - 33:05
    in seeding it like this you could seed it
    also differently.
  • 33:05 - 33:14
    Stephan: No the normal - there are
    different ways to generate the nonce k. So
  • 33:14 - 33:20
    the original way that's part of the ECDSA
    government standard is to generate a
  • 33:20 - 33:24
    random number. So every time you would
    generate a random number. But this
  • 33:24 - 33:28
    malicious wallet is breaking the protocol
    it's not using the random number it's
  • 33:28 - 33:34
    generating a number in a different way.
    And then there the additional ideas for
  • 33:34 - 33:40
    example this RFC6979 that you also have on
    the slide now. That's a scheme that
  • 33:40 - 33:46
    generates deterministic nonces from the
    private key and the message you can
  • 33:46 - 33:52
    generate a deterministic nonce. So this
    way you avoid bad random numbers but the
  • 33:52 - 33:57
    malicious wallet it can always break the
    protocol, it does not follow the protocol
  • 33:57 - 34:04
    and it would use a different number. Yes.
    Herald: Do you have a second question at
  • 34:04 - 34:12
    microphone 2, you?
    Microphone 2: Sorry if this is a stupid
  • 34:12 - 34:17
    question but could you maybe just
    summarize the attack vector which you have
  • 34:17 - 34:26
    on people who use wallets in general? So
    like what is the attack vector. Which
  • 34:26 - 34:31
    permissions do you need to have in order -
    yeah and which permissions would you gain using your attack
  • 34:31 - 34:36
    Stephan: The attacker in this case is the
    author of your wallet.
  • 34:36 - 34:39
    Microphone 2: Okay.
    Stephan: So if the attacker has not
  • 34:39 - 34:44
    touched your wallet the source code or the
    firmware or the crypto chip that's used by
  • 34:44 - 34:50
    the wallet manufacturer then you are safe.
    Microphone 2: Okay thanks.
  • 34:50 - 34:55
    Herald: Are there any question from the
    internet?
  • 34:55 - 35:00
    No. Yeah. Then a big applause for Stephan.
  • 35:00 - 35:07
    applause
  • 35:07 - 35:09
    Herald: And keep your keys.
  • 35:09 - 35:34
    subtitles created by c3subtitles.de
    in the year 2020. Join, and help us!
Title:
35C3 - Wallet Security
Description:

more » « less
Video Language:
English
Duration:
35:34

English subtitles

Revisions