0:00:05.279,0:00:18.529
35c3 preroll music
0:00:18.529,0:00:25.840
Herald: Give a warm welcome applause for[br]Stephan Verbücheln. He is a ...
0:00:25.840,0:00:33.370
applause[br]He is a cryptologist and also security
0:00:33.370,0:00:40.299
analyst, and he will tell us about wallet[br]security. So I'm impressed.
0:00:40.299,0:00:45.699
Stephan: Hello, can everybody hear me? Ok.[br]So I'm Stephan and I will talk about
0:00:45.699,0:00:51.840
wallet security. First I will give a[br]little bit of background what I worked on.
0:00:51.840,0:00:56.219
So I am a Diplominformatiker which is like[br]the old master's degree that they had in
0:00:56.219,0:01:01.600
Germany, and I work as a security[br]consultant in Switzerland. And I've done
0:01:01.600,0:01:07.940
more research related to blockchains and[br]bitcoin, which were related to zero-
0:01:07.940,0:01:13.520
knowledge proofs, and Zerocoin which is[br]the predecessor of predecessor of Zcash.
0:01:13.520,0:01:18.979
Some people might have heard of Zcash.[br]I did research on ECDSA with regards to
0:01:18.979,0:01:26.029
bitcoin. This is also what[br]this talk will be about.
0:01:26.029,0:01:27.539
For a few months, I also worked
0:01:27.539,0:01:35.210
on my own blockchain project,[br]which failed. (laughs)
0:01:35.210,0:01:37.460
Later, I worked as a consultant
0:01:37.460,0:01:43.659
for another blockchain project which was[br]released last month. And I also did wallet
0:01:43.659,0:01:48.340
security reviews for several customers who[br]wanted to use their own wallets or wanted
0:01:48.340,0:01:52.519
to use a wallet and[br]wanted to have a review.
0:01:52.519,0:01:56.289
So this talk will have 5 points.
0:01:56.289,0:02:00.170
So first we will have a little recap of[br]bitcoin and ECDSA, a little bit of
0:02:00.170,0:02:03.909
background that will help us to[br]understand what the next things is about.
0:02:03.909,0:02:07.430
Then we will talk about wallets.[br]What is a wallet?
0:02:07.430,0:02:12.410
Then we will see a list of common attacks[br]that have been found in the last years
0:02:12.410,0:02:16.460
and then we will talk about a[br]more sophisticated attack
0:02:16.460,0:02:22.660
and then we will come to some[br]conclusions about wallet security.
0:02:22.660,0:02:27.319
So first I think everybody now[br]has heard of bitcoin. Regarding this talk
0:02:27.319,0:02:33.506
I will always talk in terms of bitcoin,[br]but the same applies to any cryptocurrency
0:02:33.506,0:02:37.040
But to make things simpler we will[br]use bitcoin as an example. So we
0:02:37.040,0:02:41.150
have fixed parameters that we work with.
0:02:41.150,0:02:44.810
So bitcoin basically is... what we need[br]to know is the public ledger for
0:02:44.810,0:02:49.210
transactions.[br]Users have public and private keys.
0:02:49.210,0:02:53.700
They use the private keys to sign[br]transactions, and the transactions are
0:02:53.700,0:03:00.389
published in a blockchain so that[br]everybody can verify the transactions.
0:03:00.389,0:03:04.090
It works like this:[br]We have Alice, Bob and Carol,
0:03:04.090,0:03:07.380
and if Alice wants to send a bitcoin
0:03:07.380,0:03:12.739
to Bob, then Alice creates the transaction,[br]signs it, and broadcast it.
0:03:12.739,0:03:14.779
Miners will collect it.
0:03:14.779,0:03:17.970
Miners will put them into the block.
0:03:17.970,0:03:23.670
And Bob waits until the transaction[br]appears and the blockchain.
0:03:23.670,0:03:28.160
So the creation of the transaction[br]consists of the following steps:
0:03:28.160,0:03:32.040
Alice first creates the transaction[br]where it says I will send one bitcoin
0:03:32.040,0:03:37.689
to Bob. Then she adds Bob's address[br]where the bitcoin is going to be
0:03:37.689,0:03:41.590
sent to and then she signes it with a[br]private key. So what's important for us
0:03:41.590,0:03:46.430
now is basically 2 things: The private[br]keys and public keys. they are used for
0:03:46.430,0:03:53.810
signatures, and all the signatures are[br]published in the blockchain.
0:03:53.810,0:03:58.664
So the signature algorithm that's used in[br]bitcoin and in most other blockchains
0:03:58.664,0:04:00.940
is ECDSA.
0:04:00.940,0:04:06.189
I think most people have heard about it[br]but will give a quick recap on what it is
0:04:06.189,0:04:11.959
and how it works. So the abbreviation[br]stands for Elliptic-Curve Digital
0:04:11.959,0:04:20.690
Signature Algorithm and it's related to[br]many other well-known algorithms. I think
0:04:20.690,0:04:24.870
everybody has heard about the Diffie-[br]Hellman key exchange. This was pretty much
0:04:24.870,0:04:31.590
the first public key private key[br]algorithm. It was based on discrete
0:04:31.590,0:04:39.280
logarithm modulo a number p. And then Mr.[br]El-Gamal, who is also the inventor of SSL,
0:04:39.280,0:04:44.639
he created the first signature scheme[br]based on Diffie-Hellman. And then Mr.
0:04:44.639,0:04:50.720
Schnorr, Professor Schnorr from Frankfurt,[br]he made the signature scheme more
0:04:50.720,0:04:59.080
efficient. And then the American[br]government took the Schnorr signature and
0:04:59.080,0:05:06.090
created the Digital Signature Algorithm,[br]which is a standardized version of the
0:05:06.090,0:05:15.650
Schnorr signature, which also standardizes[br]to use SHA as a hash function. And ECDSA
0:05:15.650,0:05:23.050
is the same algorithm as DSA, but built on[br]elliptic curves instead of discrete
0:05:23.050,0:05:28.509
logarithm with numbers. So what's an[br]elliptic curve? Oh, no first: Why do we
0:05:28.509,0:05:33.130
use elliptic curves in the first place?[br]The problem with the old algorithms, most
0:05:33.130,0:05:38.760
importantly RSA and DH, Diffie-Hellman,[br]and also DSA, which is related to Diffie-
0:05:38.760,0:05:42.350
Hellman, they have, unfortunately, they[br]have no future, because the keys are
0:05:42.350,0:05:48.290
pretty big. The algorithm gets fit gets[br]pretty inefficient. And now if you
0:05:48.290,0:05:54.989
increase the key size you don't gain much[br]more security. If you want to have a key.
0:05:54.989,0:06:01.331
So, if you have a 2000 bit RSA key and a[br]4000 bit RSA key then the 4000 bit key is
0:06:01.331,0:06:07.069
not twice as secure, but only a little bit[br]more secure. And if you really would like
0:06:07.069,0:06:11.840
to have a twice as secure key for RSA for[br]example, or for Diffie-Hellman, you would
0:06:11.840,0:06:21.270
need 15000 bits, and that's very[br]inefficient. So, elliptic curves are quite
0:06:21.270,0:06:29.190
a solution that's used nowadays in order[br]to get a more efficient algorithm. So
0:06:29.190,0:06:35.420
what's an elliptic curve? Elliptic curves[br]are curves that are defined by an equation
0:06:35.420,0:06:44.840
y² = x³ + ax + b. And the element[br]that we are talking about in the algorithm
0:06:44.840,0:06:53.610
are points on that curve, so we can see[br]the curve on these pictures and the curve
0:06:53.610,0:07:01.460
has the property that, if you draw a[br]straight crossing the curve, the straight
0:07:01.460,0:07:11.650
will like intersect the curve only at a[br]maximum of three points. And based on that
0:07:11.650,0:07:18.130
we define operations. So we can, for[br]example, define additional points: So if
0:07:18.130,0:07:24.069
you see on the left picture the points P[br]and Q, if you want to define an addition
0:07:24.069,0:07:33.070
of the two points then we say P + Q + R is[br]neutral because those are all points on
0:07:33.070,0:07:44.199
the straight line. So we define P + Q to[br]be -R, and -R is the point opposite to R.
0:07:44.199,0:07:57.399
And in the second picture we see, if we[br]want to add a point to itself, then we
0:07:57.399,0:08:03.319
draw the tangential to the point and the[br]tangential will cross the curve at another
0:08:03.319,0:08:10.560
point and the inverse of that point will[br]be used as a result. So we have, if we
0:08:10.560,0:08:20.750
want to add Q to Q, we say 2Q to this, the[br]result is -P. And with that we have a way
0:08:20.750,0:08:29.620
to add points to themselves and we can[br]scale this up. We can also add Q to Q and
0:08:29.620,0:08:39.020
Q again, so three times Q, four times Q[br]... and this operation has a nice
0:08:39.020,0:08:46.710
property, because multiplying a point with[br]a number is easy, but the inverse
0:08:46.710,0:08:51.380
operation is hard to compute. So this is[br]the operation where the whole algorithm is
0:08:51.380,0:09:00.820
based on. So how are signatures with ECDSA[br]generated? So first we have a point G
0:09:00.820,0:09:05.890
which is a fixed point that's already, for[br]example with bitcoin, it's already defined
0:09:05.890,0:09:12.350
to be a certain point. The point has the[br]order n, which means that if you add the
0:09:12.350,0:09:18.020
point to itself n times you will go back[br]to the same point. And we also have a hash
0:09:18.020,0:09:25.280
function h, in the case of bitcoin[br]SHA-256, and we have a private key d which
0:09:25.280,0:09:29.511
is a number, so all lowercase letters here[br]are numbers, and we have a public key
0:09:29.511,0:09:39.420
which is the point Q that you get when you[br]multiply the point G by the number d. So,
0:09:39.420,0:09:48.030
to generate the signature you have to pick[br]a random number k. This is also
0:09:48.030,0:09:53.290
highlighted as red. We will see later that[br]it is important to keep the red numbers,
0:09:53.290,0:09:59.920
so the nonce and the key secret. You[br]compute a point R by multiplying the
0:09:59.920,0:10:08.220
generator point with k. Then you take the[br]x coordinate and then you compute the
0:10:08.220,0:10:12.610
formula in the first line. It is not[br]really important how the formula works for
0:10:12.610,0:10:18.520
us. It's more important which values have[br]to be kept secret and which values are
0:10:18.520,0:10:24.590
published later. And then you return r and[br]s. So r and s is a signature for the
0:10:24.590,0:10:31.540
message m. And to verify it you compute[br]the following formula. It's not important
0:10:31.540,0:10:36.751
to see immediately that it works but this[br]is how the algorithm is defined. What's
0:10:36.751,0:10:44.910
important to know is that for verifying[br]you don't need to know the secret k and
0:10:44.910,0:10:53.410
you also don't need to know the private[br]key of course but you use a public key Q.
0:10:53.410,0:10:59.320
So this algorithm has the property that[br]was already published with the first paper
0:10:59.320,0:11:06.460
where the algorithm was defined. The nonce[br]k which is highlighted as red and needs to
0:11:06.460,0:11:12.550
be kept secret, because if you know the[br]nonce k you can use the parameters that
0:11:12.550,0:11:21.361
you get in the signature to compute the[br]private key. And so stealing the nonce k
0:11:21.361,0:11:26.630
for one signature is equivalent to[br]stealing the secret key. That's common
0:11:26.630,0:11:32.830
knowledge. But it will be important later[br]on. So now we will talk about what the
0:11:32.830,0:11:37.950
wallet is. So we have seen Bitcoin[br]basically in bitcoin you have a private
0:11:37.950,0:11:44.640
key and a public key and the private key[br]is used to spend Bitcoins. So if someone
0:11:44.640,0:11:49.530
gets access to your private key he will be[br]able to spend your bitcoins. So you want
0:11:49.530,0:11:52.990
to protect your private key and the[br]software that you use to manage your
0:11:52.990,0:11:58.440
private keys is called wallets. So there[br]are different types of wallets that you
0:11:58.440,0:12:05.010
can distinguish. So the simplest type is[br]software wallets. You just have the
0:12:05.010,0:12:09.320
software that generates your keys and[br]stores your keys in a file, potentially
0:12:09.320,0:12:14.450
protected with a password. A software[br]wallet is easy to use. It can be used on a
0:12:14.450,0:12:19.550
desktop, on a laptop, on the phone, on the[br]server - if you have an online shop. It's
0:12:19.550,0:12:26.150
flexible: You can modify it, you can[br]update it. But it has the problem that the
0:12:26.150,0:12:30.290
keys are on a machine where a lot of[br]things are working. So if you have for
0:12:30.290,0:12:37.010
example malware on the machine it can be[br]stolen. Then you have hardware wallets.
0:12:37.010,0:12:40.020
Yesterday there was another talk about[br]hardware wallets. So hardware wallets are
0:12:40.020,0:12:47.080
dedicated devices for example USB devices[br]or an offline laptop that are used to
0:12:47.080,0:12:54.140
manage your keys. So the advantage of it[br]is that you don't have the keys on a host
0:12:54.140,0:12:57.640
where malware, for example, could steal[br]the keys. You have them on a separate
0:12:57.640,0:13:04.640
device. One problem with hardware wallets[br]is if you have a small device with only
0:13:04.640,0:13:08.460
two buttons you need to make sure that you[br]are actually signing what you think you
0:13:08.460,0:13:14.350
are signing, but that's another problem[br]and the new wallets all have quite large
0:13:14.350,0:13:19.340
displays where they show the transaction[br]that they are signing so this is quite a
0:13:19.340,0:13:26.520
solved problem. There's actually a third[br]type of wallet which I put together as a
0:13:26.520,0:13:32.010
paper wallet. So you can print out your[br]key on paper put it in a safe and nobody
0:13:32.010,0:13:37.060
will be able to steal it. But of course[br]you will not be able to use it until you
0:13:37.060,0:13:41.760
enter your paper wallet - your key from[br]your paper wallet - into a computer
0:13:41.760,0:13:48.130
because you don't want to do the[br]computations by hand. So hardware wallets
0:13:48.130,0:13:53.210
have another... So there's another[br]distinction that you can do different from
0:13:53.210,0:13:57.640
hardware wallets and software wallets. You[br]can use crypto hardware for example every
0:13:57.640,0:14:02.790
smartphone nowadays, for example the[br]iPhone, has a little chip that's used to
0:14:02.790,0:14:12.680
manage keys. So I titled this as Hardware[br]Key Storage. So you can have a chip that
0:14:12.680,0:14:19.331
generates keys or you import keys and the[br]chip does not allow you to export keys, so
0:14:19.331,0:14:28.660
you can be sure that the key will never[br]lose the device - never leave the device and all
0:14:28.660,0:14:32.480
the signatures are performed inside the[br]module. So you really don't need to see
0:14:32.480,0:14:37.870
the key. You only need to ask the module[br]to sign something for you. This kind of
0:14:37.870,0:14:43.640
hardware key storages are quite advanced[br]nowadays. They were used in chip cards for
0:14:43.640,0:14:47.320
decades. They are used in the iPhone. They[br]are one of the reason why the FBI can't
0:14:47.320,0:14:59.320
break the iPhone but there is one note to[br]make. It's important to have access
0:14:59.320,0:15:04.360
control to this hardware key store because[br]for example if you have a jailbreaked
0:15:04.360,0:15:09.040
iPhone then your jailbreaked iPhone can[br]always pretend to be the app that's
0:15:09.040,0:15:15.330
privileged to use the key. So root access[br]always allows you to use the key. That was
0:15:15.330,0:15:21.450
also exploited in the talk yesterday for[br]the ledger wallet. Once you control the
0:15:21.450,0:15:27.690
main CPU and once you boot your own[br]firmware you can use your own firmware to
0:15:27.690,0:15:37.710
access the keys. You cannot read them but[br]you can use them. And there are some more downsides.
0:15:37.710,0:15:41.960
If you have a bug in your[br]hardware key module you cannot fix it.
0:15:41.960,0:15:48.480
There was a famous case last year. My work[br]laptop was actually affected. There was an
0:15:48.480,0:15:52.990
Infineon chip, i think, where they had a[br]bad random number generator and it turned
0:15:52.990,0:15:58.290
out that chip was used in many products.[br]It was used in the Yubikey device I thing
0:15:58.290,0:16:04.610
and it was also used in many HP laptops.[br]It was also used for disk encryption by
0:16:04.610,0:16:11.160
windows and the second downside is that[br]the implementation cannot be validated by
0:16:11.160,0:16:17.450
the user. If you have your own computer[br]where you have some understanding what's
0:16:17.450,0:16:20.500
running what's not running you can always[br]look at the source code, compile it
0:16:20.500,0:16:24.580
yourself and you have some idea what the[br]wallet is doing. If you have just a little
0:16:24.580,0:16:29.660
token that you plug in by USB then you[br]don't actually know what it is doing. And
0:16:29.660,0:16:37.080
that will be important later on for our[br]tech. So some examples in servers you have
0:16:37.080,0:16:46.070
HSMs. They are sometimes not really used to[br]like protect keys but also to increase
0:16:46.070,0:16:51.230
performance. If a server does a lot of[br]encryption it's better to have a hardware
0:16:51.230,0:16:56.440
module but those hardware modules[br]typically also store keys and then you
0:16:56.440,0:17:04.660
have TPM chips in business laptops and you[br]have smartphones like the iPhone. Yes. So
0:17:04.660,0:17:09.320
what are common problems and attacks that[br]we've seen with wallets so far in the last
0:17:09.320,0:17:15.450
years. So the most obvious attack is keys[br]are stolen via network. Someone has a
0:17:15.450,0:17:20.160
software wallet on its Windows machine[br]installed some malware by accident by
0:17:20.160,0:17:33.220
clicking on some e-mail link and the[br]malware can steal the keys. So another
0:17:33.220,0:17:39.830
kind of attack is if you have unsecure[br]storage for example if you have a phone
0:17:39.830,0:17:45.280
where you store your bitcoins and it's[br]stolen and the phone is not encrypted and
0:17:45.280,0:17:52.060
the wallet is not encrypted. People can[br]steal the keys and steal your bitcoins and
0:17:52.060,0:17:55.930
then you have a third kind of attack.[br]Where you have bad random numbers or
0:17:55.930,0:17:58.910
predictable random numbers. That happened[br]a lot with bad wallets that were
0:17:58.910,0:18:03.010
implemented in JavaScript and then if you[br]have a bad browser that is generating bad
0:18:03.010,0:18:10.020
random numbers, the attacker can guess[br]your random numbers and this means that
0:18:10.020,0:18:16.470
they can guess your keys or they can guess[br]your nonce k which is equivalent as we
0:18:16.470,0:18:21.820
have seen. And one more interesting thing[br]is that is not only important that you
0:18:21.820,0:18:27.780
keep your nonce k secret it's also[br]important that you use it only once. So if
0:18:27.780,0:18:34.720
you use it twice, the attacker can also[br]compute your private key even without
0:18:34.720,0:18:40.280
knowing k. And one problem with bitcoin is[br]all the signatures are published on the
0:18:40.280,0:18:45.440
blockchain. So attackers can just scan the[br]blockchain and see if the number k is
0:18:45.440,0:18:49.220
appearing for two times and then steal the[br]bitcoins. That happens a lot. So if this
0:18:49.220,0:18:54.390
happens to you the bitcoins will probably[br]be stolen in one hour because somebody is
0:18:54.390,0:18:59.270
always scanning the block chain and in the[br]early days of bitcoin this attack also
0:18:59.270,0:19:10.650
happened a lot. But now we want to talk[br]about a more sophisticated kind of attack
0:19:10.650,0:19:14.760
which is the backdoor in a random number[br]generator which is not just bad random
0:19:14.760,0:19:18.900
numbers but intentionally when random numbers can be predicted by an
0:19:18.900,0:19:23.970
attacker. One famous example for[br]backdoored random number generator was the
0:19:23.970,0:19:30.240
Dual_EC_DRBG when it was standardized by[br]the - so that's the standard by the US
0:19:30.240,0:19:35.780
government for random bit generator. And[br]there were some parameters in this
0:19:35.780,0:19:41.870
algorithm that were selected by the US[br]government but they couldn't explain why
0:19:41.870,0:19:46.110
they selected them. And there was no need[br]for selecting them in a cryptographic
0:19:46.110,0:19:53.600
point of view. So there was suspicion that[br]they were selected in a certain way in
0:19:53.600,0:20:00.890
order to predict random numbers. And later[br]when Edward Snowden had his files released
0:20:00.890,0:20:09.200
there was some documentation that they[br]actually did this. So what could an
0:20:09.200,0:20:16.420
attacker do with a backdoored random[br]number generator. So every time the user
0:20:16.420,0:20:21.410
generates a signature it needs to generate[br]an nonce k. And if this nonce k is
0:20:21.410,0:20:30.310
generated by the backdoored random number[br]generator then the attacker can later on -
0:20:30.310,0:20:39.380
so the attacker wants to make the wallet[br]of the victim to generate random number ks
0:20:39.380,0:20:45.050
and a nonce k in a bad way. And the[br]attacker then later on scans all the
0:20:45.050,0:20:48.600
transactions on the blockchain in order to[br]find the victim's transactions and the
0:20:48.600,0:20:53.150
victim's signatures and then uses his[br]backdoor knowledge in order to compute the
0:20:53.150,0:21:00.260
secret key. And then after he has a secret[br]key he can steal the bitcoins. So we will
0:21:00.260,0:21:05.400
talk about something that's called[br]Kleptograms. Kleptograms were first
0:21:05.400,0:21:14.780
introduced by Adam young and Moti Yung in[br]1997. Back then it was based on the
0:21:14.780,0:21:21.120
classical DSA but it's very similar to the[br]elliptic curve DSA. Because we have some
0:21:21.120,0:21:27.490
more formulas now I will have a little[br]description so all lowercase letters are
0:21:27.490,0:21:34.350
numbers, all capital letters a points on[br]the elliptic curve, all Greek letters
0:21:34.350,0:21:40.930
are constants and this function R is a[br]random number generator but this is not
0:21:40.930,0:21:43.820
the backdoored random number generator,[br]but the real random number generator that
0:21:43.820,0:21:50.890
we assume is strong. So it has some[br]properties for example that it's not
0:21:50.890,0:21:55.650
possible to efficiently distinguish[br]between the numbers generated by this
0:21:55.650,0:22:02.560
random number generator and actual random[br]numbers. So if you want to do - if you
0:22:02.560,0:22:09.380
want to generate two numbers k1 and k2[br]which are used as nonces in this ECDSA
0:22:09.380,0:22:15.850
signatures and we later want that the[br]attacker can use these signatures to
0:22:15.850,0:22:22.800
compute the private key then we can do a[br]simple thing. The first random number we
0:22:22.800,0:22:29.760
can just pick randomly. So we have the[br]random number k1 and we can store k1 and
0:22:29.760,0:22:37.930
we can output k1 to the wallet and the[br]wallet will use k1 and R1 which is the
0:22:37.930,0:22:47.510
point which is - Yes the point that is[br]generated if you multiply the point G with
0:22:47.510,0:22:56.150
k1. k1 and R1 are used for the signature[br]and R1 will be published on the blockchain
0:22:56.150,0:23:04.160
with the signature and then the second[br]round we'll compute k2 as a random number
0:23:04.160,0:23:11.380
derived from R1 and here we don't pick a[br]new random number but we just use the
0:23:11.380,0:23:20.160
pseudo random number generator. And then[br]we output k2 and R2 which is the point for
0:23:20.160,0:23:30.670
k2 for the second signature. So what can[br]we do now? So this the second round again.
0:23:30.670,0:23:37.490
So if the attacker now wants to know k2 it[br]can just scan the blockchain for all
0:23:37.490,0:23:43.050
values of R1 which are all published on[br]the blockchain and then compute k2 by
0:23:43.050,0:23:49.380
using the random number generator on R1[br]and then use it to compute the private
0:23:49.380,0:23:53.740
key. But there's two problems with this.[br]Anyone can use the random number generator
0:23:53.740,0:23:58.790
so anyone can compute this. So the[br]question is whether we can hide this attack.
0:24:02.288,0:24:08.350
So in order to hide the attack the[br]attacker generates his own private key and
0:24:08.350,0:24:15.440
public key. The random number generator is[br]the same as before. And now we generate k1
0:24:15.440,0:24:22.210
and k2 again, but in a slightly different[br]way. For k1 it's the same, k1 is just
0:24:22.210,0:24:32.840
generated as a random number and it is[br]stored and used for the signature and then
0:24:32.840,0:24:40.380
in a second round we pick a random bit t[br]and then we compute the value Z by using
0:24:40.380,0:24:44.770
the formula that you see in the second[br]line it is not important to understand the
0:24:44.770,0:24:49.780
details of the formula but you need to see[br]- the important thing is that the public
0:24:49.780,0:24:59.840
key of the attacker A is used in this[br]formula. And then the second nonce k2 is
0:24:59.840,0:25:07.030
computed using the random number generator[br]on this value Z. And then this value k2 is
0:25:07.030,0:25:13.860
used for the second signature. So what[br]happens now is that because - this is the
0:25:13.860,0:25:22.710
second round again. So what happens now is[br]that the attacker can extract a second
0:25:22.710,0:25:31.180
value by doing the following computations[br]using his private key A. There are two
0:25:31.180,0:25:36.870
cases. So there are two candidates for k2.[br]And it's not clear which one is the right
0:25:36.870,0:25:42.260
one but it's only like one bit difference[br]so you can try both and one of them will
0:25:42.260,0:25:47.260
be the right one. And because no one else[br]has the private key A no one else can do
0:25:47.260,0:25:53.490
this computation. And because you have the[br]random number generator R, you know that
0:25:53.490,0:26:06.260
the value - the value for k2 is[br]undistinguishable from real random numbers
0:26:06.260,0:26:11.730
because we assume that the random number[br]generator is strong. So how do we use this
0:26:11.730,0:26:17.930
attack on wallets? So the attacker can do[br]the following: The attacker can use a
0:26:17.930,0:26:23.191
popular wallet and backdoor it or can[br]create his own wallet and spread it on the
0:26:23.191,0:26:28.370
Internet and wait for people to use it. So[br]then after that the attacker needs some
0:26:28.370,0:26:34.150
patience. The attacker needs to wait until[br]the victim creates some transactions using
0:26:34.150,0:26:40.920
the wallet and doing that. The[br]victims will publish the transactions on
0:26:40.920,0:26:45.480
the blockchain, so all the values that the[br]attacker later wants to have, are published
0:26:45.480,0:26:51.309
on the block chain and after a while the[br]attacker can just scan the whole
0:26:51.309,0:26:57.990
blockchain for signatures that are[br]generated by the same key. And then do the
0:26:57.990,0:27:04.900
computation that we've seen in order to[br]derive private keys. So there's one more
0:27:04.900,0:27:09.830
footnote to this. The harvest does not[br]have to actually be after the patient's
0:27:09.830,0:27:18.360
phase because even after the attacker[br]steals bitcoins, no one can detect the
0:27:18.360,0:27:33.740
secret in the transaction so it will not -[br]like it - it will not disclose the attack.
0:27:33.740,0:27:40.070
So some properties of the attack are some[br]limitations. The attack can only be used
0:27:40.070,0:27:46.800
if the user uses the same key twice to[br]sign transactions. But that's the
0:27:46.800,0:27:52.980
usual typical use in bitcoin you always[br]use your key several times. Sometimes even
0:27:52.980,0:27:58.950
you even use the same key in the same[br]transaction twice. So in some cases even
0:27:58.950,0:28:11.570
one transaction can be enough to leak the[br]private key. And there is another footnote
0:28:11.570,0:28:16.590
because there is some standard which is[br]called BIP32 which is the standard for
0:28:16.590,0:28:24.610
deriving many keys in bitcoin from one[br]seed. And it means that the attacker
0:28:24.610,0:28:29.750
manages to get one of your private keys it[br]might be possible for the attacker to
0:28:29.750,0:28:37.210
compute more private keys without doing[br]more attacks. This attack is independent
0:28:37.210,0:28:41.270
from how Bitcoin in general works it's[br]independent from the consensus algorithm
0:28:41.270,0:28:45.690
it's independent from mining. It also[br]applies to other blockchains that use
0:28:45.690,0:28:52.100
similar signature schemes some use[br]different curves. Some use EdDSA but the
0:28:52.100,0:28:59.080
attack works for them as well. And the[br]backdoor also works with other protocols
0:28:59.080,0:29:02.620
that don't have anything to do with[br]cryptocurrency but in cryptocurrency it's
0:29:02.620,0:29:07.720
easier because the parameters: the curve[br]and the point and everything is already
0:29:07.720,0:29:13.200
defined by the protocol. You cannot use a[br]different curve in Bitcoin. So the
0:29:13.200,0:29:17.679
attacker always knows which curve you are[br]using so the attacker always knows which
0:29:17.679,0:29:27.800
curve it has to use to hide the secret. So[br]what are the conclusions? What does it
0:29:27.800,0:29:32.820
mean for users? So it means that keys can[br]be leaked through the transactions. You don't
0:29:32.820,0:29:35.550
need a side channel. You don't need a[br]second connection you don't need
0:29:35.550,0:29:41.110
additional data and it cannot be detected[br]even if you're looking at the transactions
0:29:41.110,0:29:46.610
because the random number generator is[br]used is indistinguishable from normal
0:29:46.610,0:29:53.350
random numbers. So what does it mean for[br]the user to do? It means that the user
0:29:53.350,0:29:57.520
should be careful not using untrusted[br]wallets. Even if you use them offline they
0:29:57.520,0:30:04.950
could still leak your keys and that means[br]for some applications transparency might
0:30:04.950,0:30:10.040
be more important than tampering[br]resistance. For example it means that it
0:30:10.040,0:30:14.840
might be worth to have a software wallet[br]that you know what it's doing. In contrast
0:30:14.840,0:30:20.700
to a hardware wallet which might protect[br]the key from theft but you don't really
0:30:20.700,0:30:26.530
know what it's doing when it's generating[br]a signature.
0:30:26.530,0:30:29.270
Yeah, that's it.
0:30:29.270,0:30:32.600
applaus
0:30:32.600,0:30:46.301
Herald: So any questions? And so there are[br]two microphones. Number 2, Number 1. If
0:30:46.301,0:30:53.050
any questions please go to the[br]microphones. And if you leave the room
0:30:53.050,0:30:58.160
don't do it in front of the camera, that's[br]the stream. If there is any question from
0:30:58.160,0:31:03.280
the Internet make a sign. I see, [br]microphone 2 your question.
0:31:03.280,0:31:08.630
Microphone 2: Hi. You said that you could[br]derive additional private keys if one of
0:31:08.630,0:31:14.740
the keys leaks in BIP32. It's my[br]understanding that that is not possible
0:31:14.740,0:31:20.380
unless that's the master private key. And[br]you know the derivation scheme. So could
0:31:20.380,0:31:23.990
you elaborate what you meant.[br]Stephan: No I was just talking about
0:31:23.990,0:31:29.180
derived keys in general. Yeah it is not[br]that simple. So that's also why I didn't
0:31:29.180,0:31:33.330
put it on the slides. It depends on the[br]scheme that you use for deriving the keys.
0:31:33.330,0:31:34.520
That's true.[br]Microphone 2: All right. Thanks.
0:31:34.520,0:31:38.070
Stephan: But depending on the scheme you[br]need to keep in mind that one key or one
0:31:38.070,0:31:42.990
secret might be information that you used[br]to derive other secrets. Yes.
0:31:42.990,0:31:49.340
Herald: Okay. Microphone 1.[br]Microphone 1: I would just like to maybe
0:31:49.340,0:31:54.570
have a piece of practical advice from you.[br]So given this consideration that you
0:31:54.570,0:31:58.330
really need to know a bit of the code that[br]is running on resource on the wallet.
0:31:58.330,0:32:00.150
Stephan: Okay. I think speak up a little[br]bit.
0:32:00.150,0:32:02.110
Microphone 1: Yes. Do you hear me better[br]now?
0:32:02.110,0:32:04.130
Stephan: Yes.[br]Microphone 1: Okay. So do you think that
0:32:04.130,0:32:09.890
would be a good alternative to have softer[br]wallets running air gapped but softer
0:32:09.890,0:32:13.170
wallets instead of harder wallets because[br]they're easier to audit or to see the
0:32:13.170,0:32:16.450
source code.[br]Stephan: Yeah. The point is that it's
0:32:16.450,0:32:19.851
better to have a wallet that you control[br]that you know what it's doing. Because
0:32:19.851,0:32:23.460
this if you even if you have a air gap you[br]will at some point you will put the
0:32:23.460,0:32:27.980
transactions from the wallet to the[br]network. And if the secret is inside the
0:32:27.980,0:32:33.929
transaction then the air gap will not help[br]you. That's the point. Yes.
0:32:33.929,0:32:37.450
Herald: And microphone 2 you have another[br]question. Okay. Microphone 1.
0:32:37.450,0:32:42.840
Microphone 1: So if you if I understood[br]you correctly this makes the strong
0:32:42.840,0:32:49.120
assumption that you seed the random number[br]generator on the second step with the
0:32:49.120,0:32:51.880
point generated from the first step. Is[br]this correct?
0:32:51.880,0:32:55.320
Stephan: Yes.[br]Microphone 1: And this is something which
0:32:55.320,0:33:00.750
is like pinstriped from the Bitcoin[br]protocol or because I don't see any point
0:33:00.750,0:33:05.130
in seeding it like this you could seed it[br]also differently.
0:33:05.130,0:33:13.580
Stephan: No the normal - there are[br]different ways to generate the nonce k. So
0:33:13.580,0:33:20.250
the original way that's part of the ECDSA[br]government standard is to generate a
0:33:20.250,0:33:24.059
random number. So every time you would[br]generate a random number. But this
0:33:24.059,0:33:28.170
malicious wallet is breaking the protocol[br]it's not using the random number it's
0:33:28.170,0:33:34.231
generating a number in a different way.[br]And then there the additional ideas for
0:33:34.231,0:33:39.890
example this RFC6979 that you also have on[br]the slide now. That's a scheme that
0:33:39.890,0:33:45.980
generates deterministic nonces from the[br]private key and the message you can
0:33:45.980,0:33:52.040
generate a deterministic nonce. So this[br]way you avoid bad random numbers but the
0:33:52.040,0:33:56.880
malicious wallet it can always break the[br]protocol, it does not follow the protocol
0:33:56.880,0:34:03.970
and it would use a different number. Yes.[br]Herald: Do you have a second question at
0:34:03.970,0:34:12.060
microphone 2, you?[br]Microphone 2: Sorry if this is a stupid
0:34:12.060,0:34:16.960
question but could you maybe just[br]summarize the attack vector which you have
0:34:16.960,0:34:25.669
on people who use wallets in general? So[br]like what is the attack vector. Which
0:34:25.669,0:34:30.659
permissions do you need to have in order -[br]yeah and which permissions would you gain using your attack
0:34:30.659,0:34:35.550
Stephan: The attacker in this case is the[br]author of your wallet.
0:34:35.550,0:34:39.310
Microphone 2: Okay.[br]Stephan: So if the attacker has not
0:34:39.310,0:34:44.490
touched your wallet the source code or the[br]firmware or the crypto chip that's used by
0:34:44.490,0:34:49.740
the wallet manufacturer then you are safe.[br]Microphone 2: Okay thanks.
0:34:49.740,0:34:55.310
Herald: Are there any question from the[br]internet?
0:34:55.310,0:34:59.530
No. Yeah. Then a big applause for Stephan.
0:34:59.530,0:35:06.950
applause
0:35:06.950,0:35:09.234
Herald: And keep your keys.
0:35:09.234,0:35:34.000
subtitles created by c3subtitles.de[br]in the year 2020. Join, and help us!