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!