1
00:00:05,279 --> 00:00:18,529
35c3 preroll music
2
00:00:18,529 --> 00:00:25,840
Herald: Give a warm welcome applause for
Stephan Verbücheln. He is a ...
3
00:00:25,840 --> 00:00:33,370
applause
He is a cryptologist and also security
4
00:00:33,370 --> 00:00:40,299
analyst, and he will tell us about wallet
security. So I'm impressed.
5
00:00:40,299 --> 00:00:45,699
Stephan: Hello, can everybody hear me? Ok.
So I'm Stephan and I will talk about
6
00:00:45,699 --> 00:00:51,840
wallet security. First I will give a
little bit of background what I worked on.
7
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
8
00:00:56,219 --> 00:01:01,600
Germany, and I work as a security
consultant in Switzerland. And I've done
9
00:01:01,600 --> 00:01:07,940
more research related to blockchains and
bitcoin, which were related to zero-
10
00:01:07,940 --> 00:01:13,520
knowledge proofs, and Zerocoin which is
the predecessor of predecessor of Zcash.
11
00:01:13,520 --> 00:01:18,979
Some people might have heard of Zcash.
I did research on ECDSA with regards to
12
00:01:18,979 --> 00:01:26,029
bitcoin. This is also what
this talk will be about.
13
00:01:26,029 --> 00:01:27,539
For a few months, I also worked
14
00:01:27,539 --> 00:01:35,210
on my own blockchain project,
which failed. (laughs)
15
00:01:35,210 --> 00:01:37,460
Later, I worked as a consultant
16
00:01:37,460 --> 00:01:43,659
for another blockchain project which was
released last month. And I also did wallet
17
00:01:43,659 --> 00:01:48,340
security reviews for several customers who
wanted to use their own wallets or wanted
18
00:01:48,340 --> 00:01:52,519
to use a wallet and
wanted to have a review.
19
00:01:52,519 --> 00:01:56,289
So this talk will have 5 points.
20
00:01:56,289 --> 00:02:00,170
So first we will have a little recap of
bitcoin and ECDSA, a little bit of
21
00:02:00,170 --> 00:02:03,909
background that will help us to
understand what the next things is about.
22
00:02:03,909 --> 00:02:07,430
Then we will talk about wallets.
What is a wallet?
23
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
24
00:02:12,410 --> 00:02:16,460
and then we will talk about a
more sophisticated attack
25
00:02:16,460 --> 00:02:22,660
and then we will come to some
conclusions about wallet security.
26
00:02:22,660 --> 00:02:27,319
So first I think everybody now
has heard of bitcoin. Regarding this talk
27
00:02:27,319 --> 00:02:33,506
I will always talk in terms of bitcoin,
but the same applies to any cryptocurrency
28
00:02:33,506 --> 00:02:37,040
But to make things simpler we will
use bitcoin as an example. So we
29
00:02:37,040 --> 00:02:41,150
have fixed parameters that we work with.
30
00:02:41,150 --> 00:02:44,810
So bitcoin basically is... what we need
to know is the public ledger for
31
00:02:44,810 --> 00:02:49,210
transactions.
Users have public and private keys.
32
00:02:49,210 --> 00:02:53,700
They use the private keys to sign
transactions, and the transactions are
33
00:02:53,700 --> 00:03:00,389
published in a blockchain so that
everybody can verify the transactions.
34
00:03:00,389 --> 00:03:04,090
It works like this:
We have Alice, Bob and Carol,
35
00:03:04,090 --> 00:03:07,380
and if Alice wants to send a bitcoin
36
00:03:07,380 --> 00:03:12,739
to Bob, then Alice creates the transaction,
signs it, and broadcast it.
37
00:03:12,739 --> 00:03:14,779
Miners will collect it.
38
00:03:14,779 --> 00:03:17,970
Miners will put them into the block.
39
00:03:17,970 --> 00:03:23,670
And Bob waits until the transaction
appears and the blockchain.
40
00:03:23,670 --> 00:03:28,160
So the creation of the transaction
consists of the following steps:
41
00:03:28,160 --> 00:03:32,040
Alice first creates the transaction
where it says I will send one bitcoin
42
00:03:32,040 --> 00:03:37,689
to Bob. Then she adds Bob's address
where the bitcoin is going to be
43
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
44
00:03:41,590 --> 00:03:46,430
now is basically 2 things: The private
keys and public keys. they are used for
45
00:03:46,430 --> 00:03:53,810
signatures, and all the signatures are
published in the blockchain.
46
00:03:53,810 --> 00:03:58,664
So the signature algorithm that's used in
bitcoin and in most other blockchains
47
00:03:58,664 --> 00:04:00,940
is ECDSA.
48
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
49
00:04:06,189 --> 00:04:11,959
and how it works. So the abbreviation
stands for Elliptic-Curve Digital
50
00:04:11,959 --> 00:04:20,690
Signature Algorithm and it's related to
many other well-known algorithms. I think
51
00:04:20,690 --> 00:04:24,870
everybody has heard about the Diffie-
Hellman key exchange. This was pretty much
52
00:04:24,870 --> 00:04:31,590
the first public key private key
algorithm. It was based on discrete
53
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,
54
00:04:39,280 --> 00:04:44,639
he created the first signature scheme
based on Diffie-Hellman. And then Mr.
55
00:04:44,639 --> 00:04:50,720
Schnorr, Professor Schnorr from Frankfurt,
he made the signature scheme more
56
00:04:50,720 --> 00:04:59,080
efficient. And then the American
government took the Schnorr signature and
57
00:04:59,080 --> 00:05:06,090
created the Digital Signature Algorithm,
which is a standardized version of the
58
00:05:06,090 --> 00:05:15,650
Schnorr signature, which also standardizes
to use SHA as a hash function. And ECDSA
59
00:05:15,650 --> 00:05:23,050
is the same algorithm as DSA, but built on
elliptic curves instead of discrete
60
00:05:23,050 --> 00:05:28,509
logarithm with numbers. So what's an
elliptic curve? Oh, no first: Why do we
61
00:05:28,509 --> 00:05:33,130
use elliptic curves in the first place?
The problem with the old algorithms, most
62
00:05:33,130 --> 00:05:38,760
importantly RSA and DH, Diffie-Hellman,
and also DSA, which is related to Diffie-
63
00:05:38,760 --> 00:05:42,350
Hellman, they have, unfortunately, they
have no future, because the keys are
64
00:05:42,350 --> 00:05:48,290
pretty big. The algorithm gets fit gets
pretty inefficient. And now if you
65
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.
66
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
67
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
68
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
69
00:06:11,840 --> 00:06:21,270
need 15000 bits, and that's very
inefficient. So, elliptic curves are quite
70
00:06:21,270 --> 00:06:29,190
a solution that's used nowadays in order
to get a more efficient algorithm. So
71
00:06:29,190 --> 00:06:35,420
what's an elliptic curve? Elliptic curves
are curves that are defined by an equation
72
00:06:35,420 --> 00:06:44,840
y² = x³ + ax + b. And the element
that we are talking about in the algorithm
73
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
74
00:06:53,610 --> 00:07:01,460
has the property that, if you draw a
straight crossing the curve, the straight
75
00:07:01,460 --> 00:07:11,650
will like intersect the curve only at a
maximum of three points. And based on that
76
00:07:11,650 --> 00:07:18,130
we define operations. So we can, for
example, define additional points: So if
77
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
78
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
79
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.
80
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
81
00:07:57,399 --> 00:08:03,319
draw the tangential to the point and the
tangential will cross the curve at another
82
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
83
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
84
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
85
00:08:29,620 --> 00:08:39,020
Q again, so three times Q, four times Q
... and this operation has a nice
86
00:08:39,020 --> 00:08:46,710
property, because multiplying a point with
a number is easy, but the inverse
87
00:08:46,710 --> 00:08:51,380
operation is hard to compute. So this is
the operation where the whole algorithm is
88
00:08:51,380 --> 00:09:00,820
based on. So how are signatures with ECDSA
generated? So first we have a point G
89
00:09:00,820 --> 00:09:05,890
which is a fixed point that's already, for
example with bitcoin, it's already defined
90
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
91
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
92
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
93
00:09:25,280 --> 00:09:29,511
is a number, so all lowercase letters here
are numbers, and we have a public key
94
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,
95
00:09:39,420 --> 00:09:48,030
to generate the signature you have to pick
a random number k. This is also
96
00:09:48,030 --> 00:09:53,290
highlighted as red. We will see later that
it is important to keep the red numbers,
97
00:09:53,290 --> 00:09:59,920
so the nonce and the key secret. You
compute a point R by multiplying the
98
00:09:59,920 --> 00:10:08,220
generator point with k. Then you take the
x coordinate and then you compute the
99
00:10:08,220 --> 00:10:12,610
formula in the first line. It is not
really important how the formula works for
100
00:10:12,610 --> 00:10:18,520
us. It's more important which values have
to be kept secret and which values are
101
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
102
00:10:24,590 --> 00:10:31,540
message m. And to verify it you compute
the following formula. It's not important
103
00:10:31,540 --> 00:10:36,751
to see immediately that it works but this
is how the algorithm is defined. What's
104
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
105
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.
106
00:10:53,410 --> 00:10:59,320
So this algorithm has the property that
was already published with the first paper
107
00:10:59,320 --> 00:11:06,460
where the algorithm was defined. The nonce
k which is highlighted as red and needs to
108
00:11:06,460 --> 00:11:12,550
be kept secret, because if you know the
nonce k you can use the parameters that
109
00:11:12,550 --> 00:11:21,361
you get in the signature to compute the
private key. And so stealing the nonce k
110
00:11:21,361 --> 00:11:26,630
for one signature is equivalent to
stealing the secret key. That's common
111
00:11:26,630 --> 00:11:32,830
knowledge. But it will be important later
on. So now we will talk about what the
112
00:11:32,830 --> 00:11:37,950
wallet is. So we have seen Bitcoin
basically in bitcoin you have a private
113
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
114
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
115
00:11:49,530 --> 00:11:52,990
to protect your private key and the
software that you use to manage your
116
00:11:52,990 --> 00:11:58,440
private keys is called wallets. So there
are different types of wallets that you
117
00:11:58,440 --> 00:12:05,010
can distinguish. So the simplest type is
software wallets. You just have the
118
00:12:05,010 --> 00:12:09,320
software that generates your keys and
stores your keys in a file, potentially
119
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
120
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
121
00:12:19,550 --> 00:12:26,150
flexible: You can modify it, you can
update it. But it has the problem that the
122
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
123
00:12:30,290 --> 00:12:37,010
example malware on the machine it can be
stolen. Then you have hardware wallets.
124
00:12:37,010 --> 00:12:40,020
Yesterday there was another talk about
hardware wallets. So hardware wallets are
125
00:12:40,020 --> 00:12:47,080
dedicated devices for example USB devices
or an offline laptop that are used to
126
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
127
00:12:54,140 --> 00:12:57,640
where malware, for example, could steal
the keys. You have them on a separate
128
00:12:57,640 --> 00:13:04,640
device. One problem with hardware wallets
is if you have a small device with only
129
00:13:04,640 --> 00:13:08,460
two buttons you need to make sure that you
are actually signing what you think you
130
00:13:08,460 --> 00:13:14,350
are signing, but that's another problem
and the new wallets all have quite large
131
00:13:14,350 --> 00:13:19,340
displays where they show the transaction
that they are signing so this is quite a
132
00:13:19,340 --> 00:13:26,520
solved problem. There's actually a third
type of wallet which I put together as a
133
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
134
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
135
00:13:37,060 --> 00:13:41,760
enter your paper wallet - your key from
your paper wallet - into a computer
136
00:13:41,760 --> 00:13:48,130
because you don't want to do the
computations by hand. So hardware wallets
137
00:13:48,130 --> 00:13:53,210
have another... So there's another
distinction that you can do different from
138
00:13:53,210 --> 00:13:57,640
hardware wallets and software wallets. You
can use crypto hardware for example every
139
00:13:57,640 --> 00:14:02,790
smartphone nowadays, for example the
iPhone, has a little chip that's used to
140
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
141
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
142
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
143
00:14:28,660 --> 00:14:32,480
the signatures are performed inside the
module. So you really don't need to see
144
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
145
00:14:37,870 --> 00:14:43,640
hardware key storages are quite advanced
nowadays. They were used in chip cards for
146
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
147
00:14:47,320 --> 00:14:59,320
break the iPhone but there is one note to
make. It's important to have access
148
00:14:59,320 --> 00:15:04,360
control to this hardware key store because
for example if you have a jailbreaked
149
00:15:04,360 --> 00:15:09,040
iPhone then your jailbreaked iPhone can
always pretend to be the app that's
150
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
151
00:15:15,330 --> 00:15:21,450
also exploited in the talk yesterday for
the ledger wallet. Once you control the
152
00:15:21,450 --> 00:15:27,690
main CPU and once you boot your own
firmware you can use your own firmware to
153
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.
154
00:15:37,710 --> 00:15:41,960
If you have a bug in your
hardware key module you cannot fix it.
155
00:15:41,960 --> 00:15:48,480
There was a famous case last year. My work
laptop was actually affected. There was an
156
00:15:48,480 --> 00:15:52,990
Infineon chip, i think, where they had a
bad random number generator and it turned
157
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
158
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
159
00:16:04,610 --> 00:16:11,160
windows and the second downside is that
the implementation cannot be validated by
160
00:16:11,160 --> 00:16:17,450
the user. If you have your own computer
where you have some understanding what's
161
00:16:17,450 --> 00:16:20,500
running what's not running you can always
look at the source code, compile it
162
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
163
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
164
00:16:29,660 --> 00:16:37,080
that will be important later on for our
tech. So some examples in servers you have
165
00:16:37,080 --> 00:16:46,070
HSMs. They are sometimes not really used to
like protect keys but also to increase
166
00:16:46,070 --> 00:16:51,230
performance. If a server does a lot of
encryption it's better to have a hardware
167
00:16:51,230 --> 00:16:56,440
module but those hardware modules
typically also store keys and then you
168
00:16:56,440 --> 00:17:04,660
have TPM chips in business laptops and you
have smartphones like the iPhone. Yes. So
169
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
170
00:17:09,320 --> 00:17:15,450
years. So the most obvious attack is keys
are stolen via network. Someone has a
171
00:17:15,450 --> 00:17:20,160
software wallet on its Windows machine
installed some malware by accident by
172
00:17:20,160 --> 00:17:33,220
clicking on some e-mail link and the
malware can steal the keys. So another
173
00:17:33,220 --> 00:17:39,830
kind of attack is if you have unsecure
storage for example if you have a phone
174
00:17:39,830 --> 00:17:45,280
where you store your bitcoins and it's
stolen and the phone is not encrypted and
175
00:17:45,280 --> 00:17:52,060
the wallet is not encrypted. People can
steal the keys and steal your bitcoins and
176
00:17:52,060 --> 00:17:55,930
then you have a third kind of attack.
Where you have bad random numbers or
177
00:17:55,930 --> 00:17:58,910
predictable random numbers. That happened
a lot with bad wallets that were
178
00:17:58,910 --> 00:18:03,010
implemented in JavaScript and then if you
have a bad browser that is generating bad
179
00:18:03,010 --> 00:18:10,020
random numbers, the attacker can guess
your random numbers and this means that
180
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
181
00:18:16,470 --> 00:18:21,820
have seen. And one more interesting thing
is that is not only important that you
182
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
183
00:18:27,780 --> 00:18:34,720
you use it twice, the attacker can also
compute your private key even without
184
00:18:34,720 --> 00:18:40,280
knowing k. And one problem with bitcoin is
all the signatures are published on the
185
00:18:40,280 --> 00:18:45,440
blockchain. So attackers can just scan the
blockchain and see if the number k is
186
00:18:45,440 --> 00:18:49,220
appearing for two times and then steal the
bitcoins. That happens a lot. So if this
187
00:18:49,220 --> 00:18:54,390
happens to you the bitcoins will probably
be stolen in one hour because somebody is
188
00:18:54,390 --> 00:18:59,270
always scanning the block chain and in the
early days of bitcoin this attack also
189
00:18:59,270 --> 00:19:10,650
happened a lot. But now we want to talk
about a more sophisticated kind of attack
190
00:19:10,650 --> 00:19:14,760
which is the backdoor in a random number
generator which is not just bad random
191
00:19:14,760 --> 00:19:18,900
numbers but intentionally when random numbers can be predicted by an
192
00:19:18,900 --> 00:19:23,970
attacker. One famous example for
backdoored random number generator was the
193
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
194
00:19:30,240 --> 00:19:35,780
government for random bit generator. And
there were some parameters in this
195
00:19:35,780 --> 00:19:41,870
algorithm that were selected by the US
government but they couldn't explain why
196
00:19:41,870 --> 00:19:46,110
they selected them. And there was no need
for selecting them in a cryptographic
197
00:19:46,110 --> 00:19:53,600
point of view. So there was suspicion that
they were selected in a certain way in
198
00:19:53,600 --> 00:20:00,890
order to predict random numbers. And later
when Edward Snowden had his files released
199
00:20:00,890 --> 00:20:09,200
there was some documentation that they
actually did this. So what could an
200
00:20:09,200 --> 00:20:16,420
attacker do with a backdoored random
number generator. So every time the user
201
00:20:16,420 --> 00:20:21,410
generates a signature it needs to generate
an nonce k. And if this nonce k is
202
00:20:21,410 --> 00:20:30,310
generated by the backdoored random number
generator then the attacker can later on -
203
00:20:30,310 --> 00:20:39,380
so the attacker wants to make the wallet
of the victim to generate random number ks
204
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
205
00:20:45,050 --> 00:20:48,600
transactions on the blockchain in order to
find the victim's transactions and the
206
00:20:48,600 --> 00:20:53,150
victim's signatures and then uses his
backdoor knowledge in order to compute the
207
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
208
00:21:00,260 --> 00:21:05,400
talk about something that's called
Kleptograms. Kleptograms were first
209
00:21:05,400 --> 00:21:14,780
introduced by Adam young and Moti Yung in
1997. Back then it was based on the
210
00:21:14,780 --> 00:21:21,120
classical DSA but it's very similar to the
elliptic curve DSA. Because we have some
211
00:21:21,120 --> 00:21:27,490
more formulas now I will have a little
description so all lowercase letters are
212
00:21:27,490 --> 00:21:34,350
numbers, all capital letters a points on
the elliptic curve, all Greek letters
213
00:21:34,350 --> 00:21:40,930
are constants and this function R is a
random number generator but this is not
214
00:21:40,930 --> 00:21:43,820
the backdoored random number generator,
but the real random number generator that
215
00:21:43,820 --> 00:21:50,890
we assume is strong. So it has some
properties for example that it's not
216
00:21:50,890 --> 00:21:55,650
possible to efficiently distinguish
between the numbers generated by this
217
00:21:55,650 --> 00:22:02,560
random number generator and actual random
numbers. So if you want to do - if you
218
00:22:02,560 --> 00:22:09,380
want to generate two numbers k1 and k2
which are used as nonces in this ECDSA
219
00:22:09,380 --> 00:22:15,850
signatures and we later want that the
attacker can use these signatures to
220
00:22:15,850 --> 00:22:22,800
compute the private key then we can do a
simple thing. The first random number we
221
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
222
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
223
00:22:37,930 --> 00:22:47,510
point which is - Yes the point that is
generated if you multiply the point G with
224
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
225
00:22:56,150 --> 00:23:04,160
with the signature and then the second
round we'll compute k2 as a random number
226
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
227
00:23:11,380 --> 00:23:20,160
pseudo random number generator. And then
we output k2 and R2 which is the point for
228
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.
229
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
230
00:23:37,490 --> 00:23:43,050
values of R1 which are all published on
the blockchain and then compute k2 by
231
00:23:43,050 --> 00:23:49,380
using the random number generator on R1
and then use it to compute the private
232
00:23:49,380 --> 00:23:53,740
key. But there's two problems with this.
Anyone can use the random number generator
233
00:23:53,740 --> 00:23:58,790
so anyone can compute this. So the
question is whether we can hide this attack.
234
00:24:02,288 --> 00:24:08,350
So in order to hide the attack the
attacker generates his own private key and
235
00:24:08,350 --> 00:24:15,440
public key. The random number generator is
the same as before. And now we generate k1
236
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
237
00:24:22,210 --> 00:24:32,840
generated as a random number and it is
stored and used for the signature and then
238
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
239
00:24:40,380 --> 00:24:44,770
the formula that you see in the second
line it is not important to understand the
240
00:24:44,770 --> 00:24:49,780
details of the formula but you need to see
- the important thing is that the public
241
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
242
00:24:59,840 --> 00:25:07,030
computed using the random number generator
on this value Z. And then this value k2 is
243
00:25:07,030 --> 00:25:13,860
used for the second signature. So what
happens now is that because - this is the
244
00:25:13,860 --> 00:25:22,710
second round again. So what happens now is
that the attacker can extract a second
245
00:25:22,710 --> 00:25:31,180
value by doing the following computations
using his private key A. There are two
246
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
247
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
248
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
249
00:25:47,260 --> 00:25:53,490
this computation. And because you have the
random number generator R, you know that
250
00:25:53,490 --> 00:26:06,260
the value - the value for k2 is
undistinguishable from real random numbers
251
00:26:06,260 --> 00:26:11,730
because we assume that the random number
generator is strong. So how do we use this
252
00:26:11,730 --> 00:26:17,930
attack on wallets? So the attacker can do
the following: The attacker can use a
253
00:26:17,930 --> 00:26:23,191
popular wallet and backdoor it or can
create his own wallet and spread it on the
254
00:26:23,191 --> 00:26:28,370
Internet and wait for people to use it. So
then after that the attacker needs some
255
00:26:28,370 --> 00:26:34,150
patience. The attacker needs to wait until
the victim creates some transactions using
256
00:26:34,150 --> 00:26:40,920
the wallet and doing that. The
victims will publish the transactions on
257
00:26:40,920 --> 00:26:45,480
the blockchain, so all the values that the
attacker later wants to have, are published
258
00:26:45,480 --> 00:26:51,309
on the block chain and after a while the
attacker can just scan the whole
259
00:26:51,309 --> 00:26:57,990
blockchain for signatures that are
generated by the same key. And then do the
260
00:26:57,990 --> 00:27:04,900
computation that we've seen in order to
derive private keys. So there's one more
261
00:27:04,900 --> 00:27:09,830
footnote to this. The harvest does not
have to actually be after the patient's
262
00:27:09,830 --> 00:27:18,360
phase because even after the attacker
steals bitcoins, no one can detect the
263
00:27:18,360 --> 00:27:33,740
secret in the transaction so it will not -
like it - it will not disclose the attack.
264
00:27:33,740 --> 00:27:40,070
So some properties of the attack are some
limitations. The attack can only be used
265
00:27:40,070 --> 00:27:46,800
if the user uses the same key twice to
sign transactions. But that's the
266
00:27:46,800 --> 00:27:52,980
usual typical use in bitcoin you always
use your key several times. Sometimes even
267
00:27:52,980 --> 00:27:58,950
you even use the same key in the same
transaction twice. So in some cases even
268
00:27:58,950 --> 00:28:11,570
one transaction can be enough to leak the
private key. And there is another footnote
269
00:28:11,570 --> 00:28:16,590
because there is some standard which is
called BIP32 which is the standard for
270
00:28:16,590 --> 00:28:24,610
deriving many keys in bitcoin from one
seed. And it means that the attacker
271
00:28:24,610 --> 00:28:29,750
manages to get one of your private keys it
might be possible for the attacker to
272
00:28:29,750 --> 00:28:37,210
compute more private keys without doing
more attacks. This attack is independent
273
00:28:37,210 --> 00:28:41,270
from how Bitcoin in general works it's
independent from the consensus algorithm
274
00:28:41,270 --> 00:28:45,690
it's independent from mining. It also
applies to other blockchains that use
275
00:28:45,690 --> 00:28:52,100
similar signature schemes some use
different curves. Some use EdDSA but the
276
00:28:52,100 --> 00:28:59,080
attack works for them as well. And the
backdoor also works with other protocols
277
00:28:59,080 --> 00:29:02,620
that don't have anything to do with
cryptocurrency but in cryptocurrency it's
278
00:29:02,620 --> 00:29:07,720
easier because the parameters: the curve
and the point and everything is already
279
00:29:07,720 --> 00:29:13,200
defined by the protocol. You cannot use a
different curve in Bitcoin. So the
280
00:29:13,200 --> 00:29:17,679
attacker always knows which curve you are
using so the attacker always knows which
281
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
282
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
283
00:29:32,820 --> 00:29:35,550
need a side channel. You don't need a
second connection you don't need
284
00:29:35,550 --> 00:29:41,110
additional data and it cannot be detected
even if you're looking at the transactions
285
00:29:41,110 --> 00:29:46,610
because the random number generator is
used is indistinguishable from normal
286
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
287
00:29:53,350 --> 00:29:57,520
should be careful not using untrusted
wallets. Even if you use them offline they
288
00:29:57,520 --> 00:30:04,950
could still leak your keys and that means
for some applications transparency might
289
00:30:04,950 --> 00:30:10,040
be more important than tampering
resistance. For example it means that it
290
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
291
00:30:14,840 --> 00:30:20,700
to a hardware wallet which might protect
the key from theft but you don't really
292
00:30:20,700 --> 00:30:26,530
know what it's doing when it's generating
a signature.
293
00:30:26,530 --> 00:30:29,270
Yeah, that's it.
294
00:30:29,270 --> 00:30:32,600
applaus
295
00:30:32,600 --> 00:30:46,301
Herald: So any questions? And so there are
two microphones. Number 2, Number 1. If
296
00:30:46,301 --> 00:30:53,050
any questions please go to the
microphones. And if you leave the room
297
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
298
00:30:58,160 --> 00:31:03,280
the Internet make a sign. I see,
microphone 2 your question.
299
00:31:03,280 --> 00:31:08,630
Microphone 2: Hi. You said that you could
derive additional private keys if one of
300
00:31:08,630 --> 00:31:14,740
the keys leaks in BIP32. It's my
understanding that that is not possible
301
00:31:14,740 --> 00:31:20,380
unless that's the master private key. And
you know the derivation scheme. So could
302
00:31:20,380 --> 00:31:23,990
you elaborate what you meant.
Stephan: No I was just talking about
303
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
304
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.
305
00:31:33,330 --> 00:31:34,520
That's true.
Microphone 2: All right. Thanks.
306
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
307
00:31:38,070 --> 00:31:42,990
secret might be information that you used
to derive other secrets. Yes.
308
00:31:42,990 --> 00:31:49,340
Herald: Okay. Microphone 1.
Microphone 1: I would just like to maybe
309
00:31:49,340 --> 00:31:54,570
have a piece of practical advice from you.
So given this consideration that you
310
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.
311
00:31:58,330 --> 00:32:00,150
Stephan: Okay. I think speak up a little
bit.
312
00:32:00,150 --> 00:32:02,110
Microphone 1: Yes. Do you hear me better
now?
313
00:32:02,110 --> 00:32:04,130
Stephan: Yes.
Microphone 1: Okay. So do you think that
314
00:32:04,130 --> 00:32:09,890
would be a good alternative to have softer
wallets running air gapped but softer
315
00:32:09,890 --> 00:32:13,170
wallets instead of harder wallets because
they're easier to audit or to see the
316
00:32:13,170 --> 00:32:16,450
source code.
Stephan: Yeah. The point is that it's
317
00:32:16,450 --> 00:32:19,851
better to have a wallet that you control
that you know what it's doing. Because
318
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
319
00:32:23,460 --> 00:32:27,980
transactions from the wallet to the
network. And if the secret is inside the
320
00:32:27,980 --> 00:32:33,929
transaction then the air gap will not help
you. That's the point. Yes.
321
00:32:33,929 --> 00:32:37,450
Herald: And microphone 2 you have another
question. Okay. Microphone 1.
322
00:32:37,450 --> 00:32:42,840
Microphone 1: So if you if I understood
you correctly this makes the strong
323
00:32:42,840 --> 00:32:49,120
assumption that you seed the random number
generator on the second step with the
324
00:32:49,120 --> 00:32:51,880
point generated from the first step. Is
this correct?
325
00:32:51,880 --> 00:32:55,320
Stephan: Yes.
Microphone 1: And this is something which
326
00:32:55,320 --> 00:33:00,750
is like pinstriped from the Bitcoin
protocol or because I don't see any point
327
00:33:00,750 --> 00:33:05,130
in seeding it like this you could seed it
also differently.
328
00:33:05,130 --> 00:33:13,580
Stephan: No the normal - there are
different ways to generate the nonce k. So
329
00:33:13,580 --> 00:33:20,250
the original way that's part of the ECDSA
government standard is to generate a
330
00:33:20,250 --> 00:33:24,059
random number. So every time you would
generate a random number. But this
331
00:33:24,059 --> 00:33:28,170
malicious wallet is breaking the protocol
it's not using the random number it's
332
00:33:28,170 --> 00:33:34,231
generating a number in a different way.
And then there the additional ideas for
333
00:33:34,231 --> 00:33:39,890
example this RFC6979 that you also have on
the slide now. That's a scheme that
334
00:33:39,890 --> 00:33:45,980
generates deterministic nonces from the
private key and the message you can
335
00:33:45,980 --> 00:33:52,040
generate a deterministic nonce. So this
way you avoid bad random numbers but the
336
00:33:52,040 --> 00:33:56,880
malicious wallet it can always break the
protocol, it does not follow the protocol
337
00:33:56,880 --> 00:34:03,970
and it would use a different number. Yes.
Herald: Do you have a second question at
338
00:34:03,970 --> 00:34:12,060
microphone 2, you?
Microphone 2: Sorry if this is a stupid
339
00:34:12,060 --> 00:34:16,960
question but could you maybe just
summarize the attack vector which you have
340
00:34:16,960 --> 00:34:25,669
on people who use wallets in general? So
like what is the attack vector. Which
341
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
342
00:34:30,659 --> 00:34:35,550
Stephan: The attacker in this case is the
author of your wallet.
343
00:34:35,550 --> 00:34:39,310
Microphone 2: Okay.
Stephan: So if the attacker has not
344
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
345
00:34:44,490 --> 00:34:49,740
the wallet manufacturer then you are safe.
Microphone 2: Okay thanks.
346
00:34:49,740 --> 00:34:55,310
Herald: Are there any question from the
internet?
347
00:34:55,310 --> 00:34:59,530
No. Yeah. Then a big applause for Stephan.
348
00:34:59,530 --> 00:35:06,950
applause
349
00:35:06,950 --> 00:35:09,234
Herald: And keep your keys.
350
00:35:09,234 --> 00:35:34,000
subtitles created by c3subtitles.de
in the year 2020. Join, and help us!