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