0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/147 Thanks! 1 00:00:10,580 --> 00:00:11,580 Please welcome 2 00:00:14,510 --> 00:00:17,329 Pavel Rusnak, which 3 00:00:17,330 --> 00:00:19,449 is currently developing. 4 00:00:20,610 --> 00:00:23,149 So if a colleague of his, he himself 5 00:00:23,150 --> 00:00:25,729 is a co-founder 6 00:00:25,730 --> 00:00:27,919 of Sperm Labs and the Fab 7 00:00:27,920 --> 00:00:30,499 Lab in Prague, 8 00:00:30,500 --> 00:00:32,569 his colleague, 9 00:00:32,570 --> 00:00:34,729 I think, is the one who who 10 00:00:34,730 --> 00:00:37,039 invented share 11 00:00:37,040 --> 00:00:39,139 the bitcoin mining pools, bitcoin 12 00:00:39,140 --> 00:00:40,129 mining. 13 00:00:40,130 --> 00:00:42,229 And today they will 14 00:00:42,230 --> 00:00:43,880 show us a secure 15 00:00:45,020 --> 00:00:47,149 device for storing or actually 16 00:00:47,150 --> 00:00:48,680 authenticating bitcoin 17 00:00:50,090 --> 00:00:52,340 transactions called Trezor. 18 00:01:00,700 --> 00:01:02,889 So thank you for the introduction, 19 00:01:02,890 --> 00:01:05,889 and I will try to reintroduce 20 00:01:05,890 --> 00:01:08,379 our team again, so 21 00:01:09,520 --> 00:01:11,349 you might recognize the guy on the left 22 00:01:11,350 --> 00:01:12,489 who was mentioned. 23 00:01:12,490 --> 00:01:14,799 It's marked by Latinos, also known 24 00:01:14,800 --> 00:01:17,799 as slash inventor of 25 00:01:17,800 --> 00:01:19,899 pool of mining pool 26 00:01:19,900 --> 00:01:22,179 concept and also operator 27 00:01:22,180 --> 00:01:24,849 of the first mining pool, 28 00:01:24,850 --> 00:01:27,039 which is still one of the biggest 29 00:01:27,040 --> 00:01:29,589 with around 10 percent of 30 00:01:29,590 --> 00:01:31,390 hash rate on the Bitcoin network. 31 00:01:32,770 --> 00:01:35,169 He also invented the stratum 32 00:01:35,170 --> 00:01:37,389 protocol, which is currently used in the 33 00:01:37,390 --> 00:01:39,819 miners pools and in 34 00:01:39,820 --> 00:01:42,459 bitcoin client, and 35 00:01:42,460 --> 00:01:45,149 the guy on the left is me popular snack. 36 00:01:45,150 --> 00:01:47,619 And I'm responsible for some smaller 37 00:01:47,620 --> 00:01:50,049 bitcoin projects like, for example, 38 00:01:50,050 --> 00:01:53,209 quantum dot org and 39 00:01:53,210 --> 00:01:55,389 put together the 40 00:01:55,390 --> 00:01:57,459 form of if Alana, who is 41 00:01:57,460 --> 00:01:59,739 sadly not in the photo 42 00:01:59,740 --> 00:02:02,319 company called Satoshi Labs. 43 00:02:02,320 --> 00:02:04,419 And we tried to 44 00:02:04,420 --> 00:02:06,009 have something like an umbrella 45 00:02:06,010 --> 00:02:08,258 organization for this bitcoin 46 00:02:08,259 --> 00:02:09,259 related project. 47 00:02:11,770 --> 00:02:14,229 One of the most important problems 48 00:02:14,230 --> 00:02:16,509 in the Bitcoin mass adoption 49 00:02:16,510 --> 00:02:18,879 is security and safety 50 00:02:18,880 --> 00:02:21,039 of bitcoin private keys 51 00:02:21,040 --> 00:02:22,029 by security. 52 00:02:22,030 --> 00:02:24,279 I mean, the security of the end users 53 00:02:24,280 --> 00:02:26,469 computer because we have 54 00:02:26,470 --> 00:02:29,049 compromised computers with viruses 55 00:02:29,050 --> 00:02:32,229 and malware and keyloggers. 56 00:02:32,230 --> 00:02:34,749 We also have, for example, 57 00:02:34,750 --> 00:02:36,909 in an internet cafe, our computers we 58 00:02:36,910 --> 00:02:38,229 don't trust. 59 00:02:38,230 --> 00:02:40,299 And what's not very common nowadays but 60 00:02:40,300 --> 00:02:43,299 may be common in future are clients 61 00:02:43,300 --> 00:02:45,669 which look like the regular clients, 62 00:02:45,670 --> 00:02:47,769 but they do something they are not 63 00:02:47,770 --> 00:02:49,389 supposed to do. 64 00:02:49,390 --> 00:02:51,489 And by safety of bitcoin 65 00:02:51,490 --> 00:02:53,619 private keys, we 66 00:02:53,620 --> 00:02:56,439 mean the data 67 00:02:56,440 --> 00:02:59,169 are more particularly wallet loss 68 00:02:59,170 --> 00:03:01,509 during various disasters, 69 00:03:01,510 --> 00:03:03,759 hardware failures and they, for 70 00:03:03,760 --> 00:03:06,429 instance, of operating system and 71 00:03:06,430 --> 00:03:08,529 also failing to do proper 72 00:03:08,530 --> 00:03:10,809 backups, which is 73 00:03:10,810 --> 00:03:13,239 very easy, for example, in bitcoin. 74 00:03:13,240 --> 00:03:15,579 There are not a lot of users are aware 75 00:03:15,580 --> 00:03:17,889 that you have to back up your 76 00:03:17,890 --> 00:03:20,319 wallet regularly, 77 00:03:20,320 --> 00:03:21,879 otherwise you will lose your bitcoins. 78 00:03:23,530 --> 00:03:26,349 And solution to this, 79 00:03:26,350 --> 00:03:28,060 we think, is hardware wallets, 80 00:03:30,070 --> 00:03:31,419 hardware, wallet ideas. 81 00:03:31,420 --> 00:03:33,639 This idea is not 82 00:03:33,640 --> 00:03:34,779 new. 83 00:03:34,780 --> 00:03:37,029 First, I encountered this idea 84 00:03:37,030 --> 00:03:39,099 during a bitcoin conference in Prague in 85 00:03:39,100 --> 00:03:41,169 2011, when 86 00:03:41,170 --> 00:03:43,389 the Clemmens cap introduced 87 00:03:43,390 --> 00:03:45,789 us to this project of hardware 88 00:03:45,790 --> 00:03:46,779 wallet. 89 00:03:46,780 --> 00:03:49,149 Sadly, he didn't 90 00:03:49,150 --> 00:03:52,269 pursue with his students 91 00:03:52,270 --> 00:03:55,029 this this idea of Arduino based 92 00:03:55,030 --> 00:03:56,589 how to develop further. 93 00:03:56,590 --> 00:03:58,749 And after a Bitcoin 94 00:03:58,750 --> 00:04:01,449 Conference 2012 in London, 95 00:04:01,450 --> 00:04:04,239 we decided we flush to 96 00:04:04,240 --> 00:04:06,849 create a project that is now 97 00:04:06,850 --> 00:04:08,349 now known as Trezor 98 00:04:09,820 --> 00:04:12,399 to actually bring this hardware 99 00:04:12,400 --> 00:04:15,069 wallet idea to life. 100 00:04:15,070 --> 00:04:17,949 We decided to follow the 101 00:04:17,950 --> 00:04:19,629 Keep It Simple principle. 102 00:04:19,630 --> 00:04:22,088 So we are building a USB-C gadget, 103 00:04:22,089 --> 00:04:24,279 more particularly a human interface 104 00:04:24,280 --> 00:04:25,569 device. 105 00:04:25,570 --> 00:04:27,819 It has an OLED display 106 00:04:27,820 --> 00:04:30,669 and OK cancel buttons, 107 00:04:30,670 --> 00:04:32,919 which require a physical interaction 108 00:04:32,920 --> 00:04:34,989 with user to confirm or discard 109 00:04:34,990 --> 00:04:36,429 transaction. 110 00:04:36,430 --> 00:04:37,899 And we don't have batteries 111 00:04:39,610 --> 00:04:41,799 because we use just power from 112 00:04:41,800 --> 00:04:43,989 the user's be and 113 00:04:43,990 --> 00:04:45,909 we don't have radio like Bluetooth or 114 00:04:45,910 --> 00:04:48,369 wireless because we aim to 115 00:04:48,370 --> 00:04:50,889 focus on the security of bitcoin 116 00:04:50,890 --> 00:04:53,169 transaction, not not the mobility, 117 00:04:53,170 --> 00:04:54,730 which is quite good nowadays. 118 00:04:56,280 --> 00:04:58,229 What's inside of treasure? 119 00:04:58,230 --> 00:05:00,329 We have our views arm cortex 120 00:05:00,330 --> 00:05:02,429 and Free Micron controller, 121 00:05:02,430 --> 00:05:04,769 more particularly ASTM 42 122 00:05:04,770 --> 00:05:07,079 f 205 123 00:05:07,080 --> 00:05:10,109 clocked at 120 megahertz. 124 00:05:10,110 --> 00:05:12,989 It has half a megabyte of flesh 125 00:05:12,990 --> 00:05:15,359 for our code, one hundred 126 00:05:15,360 --> 00:05:17,729 twenty eight 127 00:05:17,730 --> 00:05:20,429 kilobytes of RAM and 128 00:05:20,430 --> 00:05:22,169 how the random generator, which I will 129 00:05:22,170 --> 00:05:23,610 talk a little bit 130 00:05:25,740 --> 00:05:28,349 later. And it has OLED 131 00:05:28,350 --> 00:05:29,350 display, 132 00:05:30,570 --> 00:05:32,819 which is more or less one one one 133 00:05:32,820 --> 00:05:33,820 inch wide. 134 00:05:35,220 --> 00:05:37,709 During the development, we also created 135 00:05:37,710 --> 00:05:39,869 a Raspberry Pi shield, which 136 00:05:39,870 --> 00:05:42,629 uses the same display. 137 00:05:42,630 --> 00:05:45,029 Sadly, Raspberry Pi that can't 138 00:05:45,030 --> 00:05:47,219 act as a USB client 139 00:05:47,220 --> 00:05:48,509 device. 140 00:05:48,510 --> 00:05:50,609 Just she was B host, so we 141 00:05:50,610 --> 00:05:52,869 had to put an extra USB 142 00:05:52,870 --> 00:05:54,959 B to serial converter 143 00:05:54,960 --> 00:05:57,419 chip on board, and 144 00:05:57,420 --> 00:05:59,639 this shield was used 145 00:05:59,640 --> 00:06:01,859 as a prototyping platform during 146 00:06:01,860 --> 00:06:04,169 a development phase because that allowed 147 00:06:04,170 --> 00:06:06,269 us to use Python instead of C and 148 00:06:06,270 --> 00:06:07,270 to quickly, 149 00:06:08,670 --> 00:06:11,159 quickly try some stuff before 150 00:06:11,160 --> 00:06:13,359 implementing the implant it 151 00:06:13,360 --> 00:06:16,049 in much loved ever see. 152 00:06:16,050 --> 00:06:18,179 And the good thing is 153 00:06:18,180 --> 00:06:20,339 that this Raspberry Pi, the shield 154 00:06:20,340 --> 00:06:22,709 follows the same logic as the real 155 00:06:22,710 --> 00:06:24,929 Trezor device, so client has 156 00:06:24,930 --> 00:06:26,819 no way to determine if there is a real 157 00:06:26,820 --> 00:06:28,949 device or a Raspberry Pi shield on 158 00:06:28,950 --> 00:06:29,950 the other side. 159 00:06:31,080 --> 00:06:33,059 So let me give you an overview of how 160 00:06:33,060 --> 00:06:34,060 Trezor works. 161 00:06:35,160 --> 00:06:37,229 First, we have to generate the 162 00:06:37,230 --> 00:06:39,359 initial entropy and we 163 00:06:39,360 --> 00:06:41,789 want to allow its easy backup. 164 00:06:41,790 --> 00:06:44,189 Then we use this entropy to derive 165 00:06:44,190 --> 00:06:46,379 master private key and master public 166 00:06:46,380 --> 00:06:47,380 key. 167 00:06:47,790 --> 00:06:50,069 I call them generators because 168 00:06:50,070 --> 00:06:52,169 with these master keys, you are able 169 00:06:52,170 --> 00:06:54,569 to generate basically an infinite 170 00:06:54,570 --> 00:06:57,629 number of private keys and 171 00:06:57,630 --> 00:06:59,879 corresponding public keys and addresses. 172 00:07:01,020 --> 00:07:03,119 And if you send this master public key 173 00:07:03,120 --> 00:07:05,399 to computer, it 174 00:07:05,400 --> 00:07:07,399 immediately knows which addresses are 175 00:07:07,400 --> 00:07:08,910 there available to be spent. 176 00:07:10,410 --> 00:07:12,479 And because of 177 00:07:12,480 --> 00:07:14,619 that, a computer can then prepare 178 00:07:14,620 --> 00:07:16,739 transactions and send them to 179 00:07:16,740 --> 00:07:17,789 Trezor. 180 00:07:17,790 --> 00:07:20,049 But these transactions are 181 00:07:21,230 --> 00:07:23,309 are not having signatures because 182 00:07:23,310 --> 00:07:25,589 computer doesn't know the private keys. 183 00:07:25,590 --> 00:07:28,259 It just feels fill in, 184 00:07:28,260 --> 00:07:31,229 fills in the gaps with key indices, 185 00:07:31,230 --> 00:07:33,539 and then Trezor can use master 186 00:07:33,540 --> 00:07:36,119 private key to generate 187 00:07:36,120 --> 00:07:38,309 these private needed private 188 00:07:38,310 --> 00:07:40,559 keys from these indices. 189 00:07:40,560 --> 00:07:42,869 If the user confirms the transaction, 190 00:07:42,870 --> 00:07:44,999 then it's signed 191 00:07:45,000 --> 00:07:47,189 using these keys sent back to computer 192 00:07:47,190 --> 00:07:49,199 and it can broadcast it to the network or 193 00:07:49,200 --> 00:07:51,209 like it would normally do. 194 00:07:51,210 --> 00:07:53,639 The main idea behind this 195 00:07:53,640 --> 00:07:55,499 is that private keys never leave the 196 00:07:55,500 --> 00:07:57,959 device because they are generated inside 197 00:07:57,960 --> 00:07:59,069 of the device. 198 00:07:59,070 --> 00:08:01,139 And even during the signature, there 199 00:08:01,140 --> 00:08:02,039 is no reason to buy. 200 00:08:02,040 --> 00:08:03,040 They should go out. 201 00:08:04,650 --> 00:08:06,959 So how do we generate entropy? 202 00:08:06,960 --> 00:08:09,360 We use hardware random generator 203 00:08:10,510 --> 00:08:12,629 two to create the internal 204 00:08:12,630 --> 00:08:14,939 entropy a, we can 205 00:08:14,940 --> 00:08:17,159 request the external entropy from 206 00:08:17,160 --> 00:08:20,279 from a computer, and then we 207 00:08:20,280 --> 00:08:22,289 use both entropy to generate final 208 00:08:22,290 --> 00:08:24,419 entropy. And 209 00:08:24,420 --> 00:08:26,579 if we commit to 210 00:08:26,580 --> 00:08:28,769 entropy a before 211 00:08:28,770 --> 00:08:31,079 receiving entropy b, we can prove 212 00:08:31,080 --> 00:08:33,269 that the external entropy was used, 213 00:08:33,270 --> 00:08:34,798 for example, with this very simple 214 00:08:34,799 --> 00:08:36,209 scheme. 215 00:08:36,210 --> 00:08:38,548 More complex schemes were suggested 216 00:08:38,549 --> 00:08:41,219 by Timo Hanka and Ilya Gerhart 217 00:08:41,220 --> 00:08:43,949 variable, for example, by 218 00:08:43,950 --> 00:08:46,889 publishing half of the final entropy. 219 00:08:46,890 --> 00:08:49,319 You could say for 90 percent 220 00:08:49,320 --> 00:08:51,509 that external entropy was used, and 221 00:08:51,510 --> 00:08:53,610 you can increase this percentage by 222 00:08:54,990 --> 00:08:58,319 revealing more and more bits from 223 00:08:58,320 --> 00:09:00,479 from this final entropy. 224 00:09:00,480 --> 00:09:01,769 So we have this 225 00:09:02,820 --> 00:09:05,219 entropy, which is basically 100 226 00:09:05,220 --> 00:09:07,979 to twenty eight or 256 227 00:09:07,980 --> 00:09:10,769 bits, and we want to somehow 228 00:09:10,770 --> 00:09:13,049 make them available for pickup. 229 00:09:13,050 --> 00:09:15,149 So we use something that's 230 00:09:15,150 --> 00:09:16,350 called the mnemonic code, 231 00:09:17,700 --> 00:09:19,829 which is heavily inspired 232 00:09:19,830 --> 00:09:22,079 by what Thomas did in 233 00:09:22,080 --> 00:09:23,759 his Electrum client. 234 00:09:23,760 --> 00:09:26,129 The idea is simple we split these 235 00:09:26,130 --> 00:09:28,469 bits into a chunk of 236 00:09:28,470 --> 00:09:29,519 of the bits. 237 00:09:29,520 --> 00:09:32,789 We have a short list of 248 238 00:09:32,790 --> 00:09:35,189 words. We interpret each. 239 00:09:35,190 --> 00:09:37,349 This chunk as an integer between zero 240 00:09:37,350 --> 00:09:40,139 and 247 and use 241 00:09:40,140 --> 00:09:42,329 the the 242 00:09:42,330 --> 00:09:44,429 vault from vault waste to 243 00:09:45,510 --> 00:09:46,849 to create a sentence. 244 00:09:48,820 --> 00:09:50,909 We could use entropy directly 245 00:09:50,910 --> 00:09:53,099 to generate the master private key, 246 00:09:53,100 --> 00:09:55,379 but we decided to do something more. 247 00:09:55,380 --> 00:09:57,479 Likes and standardize it 248 00:09:57,480 --> 00:09:59,659 as a mnemonic code for 249 00:09:59,660 --> 00:10:00,660 thirty nine. 250 00:10:02,190 --> 00:10:04,739 So what we do is we use 251 00:10:04,740 --> 00:10:06,809 B-BBEE ADF to to generate master 252 00:10:06,810 --> 00:10:07,810 private key. 253 00:10:09,120 --> 00:10:10,869 It's a constructed use. 254 00:10:10,870 --> 00:10:12,989 So the random function H 255 00:10:12,990 --> 00:10:15,210 MC Sha 512. 256 00:10:16,320 --> 00:10:18,419 We use password as a password of using 257 00:10:18,420 --> 00:10:20,639 mnemonic sentence and we solved 258 00:10:20,640 --> 00:10:22,979 it with string mnemonic 259 00:10:22,980 --> 00:10:25,919 concatenated user secret 260 00:10:25,920 --> 00:10:28,049 and that allows us to create 261 00:10:28,050 --> 00:10:31,089 something like password protected 262 00:10:31,090 --> 00:10:32,279 monarchs. 263 00:10:32,280 --> 00:10:34,379 So the idea is you write down 264 00:10:34,380 --> 00:10:36,449 this twelve or twenty five 265 00:10:36,450 --> 00:10:38,699 words on the paper put 266 00:10:38,700 --> 00:10:40,769 it in a safe 267 00:10:40,770 --> 00:10:43,139 and if even if 268 00:10:43,140 --> 00:10:45,239 someone steals this paper, 269 00:10:45,240 --> 00:10:47,609 he doesn't have your massive 270 00:10:47,610 --> 00:10:50,099 private key because he has to provide 271 00:10:50,100 --> 00:10:52,079 this user secret. 272 00:10:52,080 --> 00:10:54,439 If it was used and also 273 00:10:54,440 --> 00:10:57,809 a nice side effect, is that it provides 274 00:10:57,810 --> 00:11:00,419 plausible deniability because if you 275 00:11:00,420 --> 00:11:02,759 if you give some different user secrets 276 00:11:02,760 --> 00:11:04,889 to an attacker, he would obtain 277 00:11:04,890 --> 00:11:06,949 a different master private key and 278 00:11:06,950 --> 00:11:09,149 a completely different set of addresses. 279 00:11:09,150 --> 00:11:11,249 And if you are clever enough to 280 00:11:11,250 --> 00:11:13,319 send some small amounts of bitcoins to 281 00:11:13,320 --> 00:11:15,569 these fake addresses, he can never know 282 00:11:15,570 --> 00:11:17,879 that you gave him a right or 283 00:11:17,880 --> 00:11:19,950 wrong user secret. 284 00:11:22,260 --> 00:11:24,359 We use 496 iteration 285 00:11:24,360 --> 00:11:26,639 and desire to kill these 286 00:11:26,640 --> 00:11:29,309 five hundred twelve bits. 287 00:11:29,310 --> 00:11:31,409 That's because there is 288 00:11:31,410 --> 00:11:34,169 another standard called hierarchical 289 00:11:34,170 --> 00:11:35,309 deterministic wallets, 290 00:11:36,480 --> 00:11:39,029 which use exactly 512 291 00:11:39,030 --> 00:11:41,489 bits for its master node. 292 00:11:41,490 --> 00:11:44,009 And the idea is that 293 00:11:44,010 --> 00:11:46,349 using that construct, uh, 294 00:11:46,350 --> 00:11:48,739 you could create basically 295 00:11:48,740 --> 00:11:51,599 a tree of, uh, 296 00:11:51,600 --> 00:11:53,909 of addresses, and each level 297 00:11:53,910 --> 00:11:56,249 can can be some 298 00:11:56,250 --> 00:11:58,739 logical way how to add 299 00:11:58,740 --> 00:12:00,689 how to do this addresses into logical 300 00:12:00,690 --> 00:12:03,179 groups. So, for example, 301 00:12:03,180 --> 00:12:05,309 uh, the first level would 302 00:12:05,310 --> 00:12:07,529 be what your wallet's second 303 00:12:07,530 --> 00:12:09,839 level would be or different wallet chains 304 00:12:09,840 --> 00:12:12,209 like, for example, main addresses 305 00:12:12,210 --> 00:12:14,309 and change addresses. 306 00:12:14,310 --> 00:12:16,799 And the third level would be actual 307 00:12:16,800 --> 00:12:18,989 addresses of that kind, 308 00:12:18,990 --> 00:12:21,089 and the function that 309 00:12:21,090 --> 00:12:22,090 generates 310 00:12:23,600 --> 00:12:25,769 a level one from level zero 311 00:12:25,770 --> 00:12:26,770 is called 312 00:12:28,230 --> 00:12:30,389 child key derivation function. 313 00:12:30,390 --> 00:12:32,519 And it takes data 314 00:12:32,520 --> 00:12:34,619 from parent node 315 00:12:34,620 --> 00:12:36,479 and index. 316 00:12:37,530 --> 00:12:38,639 Index zero one. 317 00:12:39,900 --> 00:12:42,599 To create different, different 318 00:12:42,600 --> 00:12:44,609 child of that particular node. 319 00:12:44,610 --> 00:12:46,409 And then you can descend deeper and 320 00:12:46,410 --> 00:12:48,599 deeper in the tree and you 321 00:12:48,600 --> 00:12:50,759 have some logical structure in your 322 00:12:50,760 --> 00:12:53,070 addresses. So it's not like it's flat. 323 00:12:56,000 --> 00:12:58,199 The derivation function 324 00:12:58,200 --> 00:13:00,269 that uses also HMX are 325 00:13:00,270 --> 00:13:02,669 512, and 326 00:13:02,670 --> 00:13:04,739 it was designed by Peter 327 00:13:04,740 --> 00:13:05,740 Sipamla. 328 00:13:06,570 --> 00:13:09,149 And it's standardized as B-52, 329 00:13:09,150 --> 00:13:11,009 and because it's very abstract concept, 330 00:13:11,010 --> 00:13:13,739 it provides lots of possibilities. 331 00:13:13,740 --> 00:13:16,139 The first one I described on the previous 332 00:13:16,140 --> 00:13:18,329 slide, but you can, for example, 333 00:13:18,330 --> 00:13:21,059 have first level as a representation 334 00:13:21,060 --> 00:13:22,889 of different coin types like, for 335 00:13:22,890 --> 00:13:23,990 example, the 336 00:13:25,230 --> 00:13:27,449 first node would be bitcoin 337 00:13:27,450 --> 00:13:29,059 addresses, second node light code 338 00:13:29,060 --> 00:13:30,359 addresses and so on. 339 00:13:30,360 --> 00:13:31,769 And then it would follow these logical 340 00:13:31,770 --> 00:13:33,059 structure deeper. 341 00:13:33,060 --> 00:13:34,060 Or you have some 342 00:13:35,130 --> 00:13:37,319 even more complex setup. 343 00:13:37,320 --> 00:13:39,419 Imagine there is a company that 344 00:13:39,420 --> 00:13:41,639 has headquarters and 345 00:13:41,640 --> 00:13:43,739 local branches around the world, 346 00:13:43,740 --> 00:13:46,379 and this key 347 00:13:46,380 --> 00:13:48,779 that happens to be a headquarter 348 00:13:48,780 --> 00:13:50,969 key can derive 349 00:13:50,970 --> 00:13:53,039 all oral keys 350 00:13:53,040 --> 00:13:54,809 in all branches or around the world. 351 00:13:54,810 --> 00:13:56,519 But if you are a director of a local 352 00:13:56,520 --> 00:13:58,559 branch, you have access access. 353 00:13:58,560 --> 00:14:01,229 Just to address this 354 00:14:01,230 --> 00:14:03,779 only happened that that 355 00:14:03,780 --> 00:14:06,479 happened in your in your branch. 356 00:14:06,480 --> 00:14:07,769 What's even cooler? 357 00:14:07,770 --> 00:14:09,899 We can push this concept 358 00:14:09,900 --> 00:14:12,149 even further and 359 00:14:12,150 --> 00:14:14,429 use first the 360 00:14:14,430 --> 00:14:16,469 first node in level one for a 361 00:14:16,470 --> 00:14:19,049 cryptocurrency second 362 00:14:20,290 --> 00:14:23,279 second node in level one for generating 363 00:14:23,280 --> 00:14:24,450 SSL keys, 364 00:14:25,650 --> 00:14:27,749 another node for generating full disk 365 00:14:27,750 --> 00:14:29,849 encryption keys, and 366 00:14:29,850 --> 00:14:31,979 Lex Node for generating challenge 367 00:14:31,980 --> 00:14:34,049 response keys, which can 368 00:14:34,050 --> 00:14:36,179 happen in if you have some 369 00:14:36,180 --> 00:14:38,519 intelligent door to your house, 370 00:14:38,520 --> 00:14:41,099 or maybe even to start your car. 371 00:14:41,100 --> 00:14:43,409 And that's very cool, because suddenly 372 00:14:43,410 --> 00:14:45,509 your wallet's token happens to be 373 00:14:45,510 --> 00:14:46,409 identity token. 374 00:14:46,410 --> 00:14:48,809 You can do pretty much everything you 375 00:14:48,810 --> 00:14:49,980 do. You can. 376 00:14:51,720 --> 00:14:54,089 Another problem we found 377 00:14:54,090 --> 00:14:56,399 or tackled 378 00:14:56,400 --> 00:14:58,379 is that SDK 379 00:15:00,000 --> 00:15:02,309 signatures require 380 00:15:02,310 --> 00:15:03,239 random nonce. 381 00:15:03,240 --> 00:15:04,679 During signing for bitcoin. 382 00:15:04,680 --> 00:15:07,139 It's 256 bits, 383 00:15:07,140 --> 00:15:09,599 and if you use the same nonce twice 384 00:15:09,600 --> 00:15:11,159 for sending different messages, 385 00:15:12,180 --> 00:15:14,369 you using the same particular key, 386 00:15:14,370 --> 00:15:16,349 you would basically be risky. 387 00:15:16,350 --> 00:15:19,199 This was demonstrated on 02:33 388 00:15:19,200 --> 00:15:21,599 failure for all the talk about console 389 00:15:21,600 --> 00:15:24,929 hacking, how they got the place free 390 00:15:24,930 --> 00:15:25,930 private key. 391 00:15:26,940 --> 00:15:29,339 And sadly, it was also 392 00:15:29,340 --> 00:15:32,009 exploded in August 2013, 393 00:15:32,010 --> 00:15:34,449 where there was Android, the Java 394 00:15:34,450 --> 00:15:36,599 random number generator vulnerability in 395 00:15:36,600 --> 00:15:38,699 secure random class, which 396 00:15:38,700 --> 00:15:40,979 didn't use enough entropy to generate 397 00:15:40,980 --> 00:15:42,689 this nonsense. 398 00:15:42,690 --> 00:15:45,119 And more than 59 bitcoins 399 00:15:45,120 --> 00:15:46,349 were stolen. 400 00:15:46,350 --> 00:15:48,449 What's what was 401 00:15:48,450 --> 00:15:50,549 even worse was that all 402 00:15:50,550 --> 00:15:52,799 of all Android clients were 403 00:15:52,800 --> 00:15:55,159 affected because the bug was 404 00:15:55,160 --> 00:15:56,459 in a shared library. 405 00:15:56,460 --> 00:15:58,679 Be below the application 406 00:15:58,680 --> 00:16:01,259 code and also 407 00:16:01,260 --> 00:16:02,260 it. 408 00:16:02,760 --> 00:16:05,849 Even if you imported your own private key 409 00:16:05,850 --> 00:16:07,289 into Android. 410 00:16:07,290 --> 00:16:09,149 Already, you were not safe because the 411 00:16:09,150 --> 00:16:11,369 problem was during generating 412 00:16:11,370 --> 00:16:13,319 launches for signatures, not during 413 00:16:13,320 --> 00:16:14,970 generating the private keys. 414 00:16:16,110 --> 00:16:18,359 So coincidentally, 415 00:16:18,360 --> 00:16:21,359 in August same year, 416 00:16:21,360 --> 00:16:23,999 out of six six nine seven nine was 417 00:16:24,000 --> 00:16:26,489 released with implementation 418 00:16:26,490 --> 00:16:28,829 in Java, and Go later 419 00:16:28,830 --> 00:16:31,199 reported this idea to buy 420 00:16:31,200 --> 00:16:33,509 the Python SDK. 421 00:16:33,510 --> 00:16:36,059 This slush and it was merged in 422 00:16:36,060 --> 00:16:38,039 0.9 release. 423 00:16:38,040 --> 00:16:40,379 And the idea is you don't use 424 00:16:40,380 --> 00:16:42,449 random nonce for signature, 425 00:16:42,450 --> 00:16:44,370 but you generate 426 00:16:45,390 --> 00:16:48,149 these bits with 427 00:16:48,150 --> 00:16:49,150 each mark 428 00:16:50,670 --> 00:16:52,799 deterministic random generator, 429 00:16:52,800 --> 00:16:54,449 which is seeded with private key and the 430 00:16:54,450 --> 00:16:56,549 message so it can cannot 431 00:16:56,550 --> 00:16:59,039 happen that you sign 432 00:16:59,040 --> 00:17:01,439 off two different messages with the same 433 00:17:01,440 --> 00:17:03,509 particular key using the 434 00:17:03,510 --> 00:17:04,510 same nonce. 435 00:17:05,250 --> 00:17:07,559 And it was great news for us because 436 00:17:07,560 --> 00:17:09,449 that avoided the problem. 437 00:17:09,450 --> 00:17:11,729 It enabled us to do unique tests 438 00:17:11,730 --> 00:17:14,279 which weren't possible before, and now 439 00:17:14,280 --> 00:17:15,989 suddenly we could. 440 00:17:15,990 --> 00:17:18,118 We could see the Treasury doing 441 00:17:18,119 --> 00:17:20,429 the correct thing for 442 00:17:20,430 --> 00:17:21,598 during signing. 443 00:17:21,599 --> 00:17:23,039 And also what was important 444 00:17:24,150 --> 00:17:26,699 that allowed us to prove the Trezor 445 00:17:26,700 --> 00:17:29,309 doesn't leak massive private key in nonce 446 00:17:29,310 --> 00:17:31,439 because you could create such a scheme 447 00:17:31,440 --> 00:17:32,440 that would do that. 448 00:17:34,140 --> 00:17:36,279 And let me tell you something about 449 00:17:36,280 --> 00:17:38,489 integration in order to be 450 00:17:38,490 --> 00:17:41,219 Treasury possible, we need to 451 00:17:41,220 --> 00:17:43,289 integrate it into existing 452 00:17:43,290 --> 00:17:44,579 disciplines. 453 00:17:44,580 --> 00:17:46,689 So the work is being done in 454 00:17:46,690 --> 00:17:49,499 the multi bit by multiple guys 455 00:17:49,500 --> 00:17:51,729 and this will be the uses 456 00:17:51,730 --> 00:17:54,179 for Bitcoin, Jay and Treasury 457 00:17:54,180 --> 00:17:56,489 Library and 458 00:17:56,490 --> 00:17:58,649 Electrum and Armory clients, 459 00:17:58,650 --> 00:18:00,809 which are written in Python, which 460 00:18:00,810 --> 00:18:03,569 we are really fond of with 461 00:18:03,570 --> 00:18:04,570 America. 462 00:18:06,440 --> 00:18:08,769 And sadly, bitcoin 463 00:18:08,770 --> 00:18:10,979 security is pretty 464 00:18:10,980 --> 00:18:13,559 complex codebase, and we 465 00:18:13,560 --> 00:18:15,959 currently have no 466 00:18:15,960 --> 00:18:18,059 immediate goal to to 467 00:18:18,060 --> 00:18:20,519 implement Trezor support into it. 468 00:18:20,520 --> 00:18:22,619 And also upstream is probably 469 00:18:22,620 --> 00:18:24,689 not very hesitant to 470 00:18:24,690 --> 00:18:25,939 uh. 471 00:18:25,940 --> 00:18:28,019 It's a little bit hesitant to to 472 00:18:28,020 --> 00:18:30,269 do such big changes in their code base. 473 00:18:31,470 --> 00:18:33,299 The good thing about mobile clients, 474 00:18:33,300 --> 00:18:35,849 particularly in Android, is that 475 00:18:35,850 --> 00:18:38,279 most of new Android phones have 476 00:18:38,280 --> 00:18:40,739 USB OTG, which 477 00:18:40,740 --> 00:18:43,169 allows them to communicate with 478 00:18:43,170 --> 00:18:44,729 USB devices. 479 00:18:44,730 --> 00:18:46,979 And because multi it is written in Java, 480 00:18:46,980 --> 00:18:49,109 they can pretty reuse most 481 00:18:49,110 --> 00:18:52,349 of the code base that 482 00:18:52,350 --> 00:18:54,479 that is that was written for multi 483 00:18:54,480 --> 00:18:55,379 bit. 484 00:18:55,380 --> 00:18:56,999 And also, what we are working right now 485 00:18:57,000 --> 00:18:59,429 is a native 486 00:18:59,430 --> 00:19:01,889 browser plugin which will create 487 00:19:01,890 --> 00:19:04,259 a bridge between Lovullo 488 00:19:04,260 --> 00:19:06,479 value be communication if Trezor 489 00:19:06,480 --> 00:19:07,769 to JavaScript. 490 00:19:07,770 --> 00:19:10,229 So web wallets can actually use 491 00:19:11,610 --> 00:19:14,160 Trezor via JavaScript bindings. 492 00:19:16,860 --> 00:19:18,719 And that would allow you to finally 493 00:19:18,720 --> 00:19:20,909 create a safe 494 00:19:20,910 --> 00:19:23,189 level as because there would be no 495 00:19:23,190 --> 00:19:25,619 private keys stored on the server. 496 00:19:27,390 --> 00:19:29,939 So I think that's it. 497 00:19:29,940 --> 00:19:32,009 If you want to contact us, there 498 00:19:32,010 --> 00:19:34,859 is this email. 499 00:19:34,860 --> 00:19:37,289 Please put for a DC free in a subject. 500 00:19:37,290 --> 00:19:40,829 So I know it's came from this conference. 501 00:19:40,830 --> 00:19:43,409 Most of the source code is 502 00:19:43,410 --> 00:19:45,689 published on GitHub. 503 00:19:45,690 --> 00:19:47,130 We will release. 504 00:19:48,870 --> 00:19:51,539 We will release a few of our source code 505 00:19:51,540 --> 00:19:53,189 in January. 506 00:19:53,190 --> 00:19:55,529 Then we will ship. 507 00:19:55,530 --> 00:19:58,290 We will ship most of the preorders. 508 00:19:59,700 --> 00:20:02,039 And if there are any questions, 509 00:20:02,040 --> 00:20:04,379 I'm willing to 510 00:20:04,380 --> 00:20:05,429 answer them right now. 511 00:20:17,410 --> 00:20:19,539 I can show them if 512 00:20:19,540 --> 00:20:20,850 they want, if they want. 513 00:20:23,860 --> 00:20:25,480 I think one minute is OK, but. 514 00:20:26,570 --> 00:20:27,570 OK, then. 515 00:20:38,740 --> 00:20:41,469 So I can show you, uh, 516 00:20:41,470 --> 00:20:43,929 before you line up in a microphone, 517 00:20:43,930 --> 00:20:46,239 I can show you some early prototype from 518 00:20:46,240 --> 00:20:47,240 from September. 519 00:20:49,150 --> 00:20:51,459 So it looks like it is, uh, 520 00:20:51,460 --> 00:20:53,859 it's a metallic version, which 521 00:20:53,860 --> 00:20:55,209 is more or less final. 522 00:20:55,210 --> 00:20:57,519 We will be doing some, uh, 523 00:20:57,520 --> 00:20:59,469 polishing touches to the version that 524 00:20:59,470 --> 00:21:02,350 will be shipped in January and. 525 00:21:05,990 --> 00:21:07,880 OK. I don't know if you see it. 526 00:21:09,200 --> 00:21:11,299 And it just just the demo 527 00:21:11,300 --> 00:21:12,889 screen, because that's if you femur back 528 00:21:12,890 --> 00:21:14,709 from September. 529 00:21:14,710 --> 00:21:17,029 So there is there is some 530 00:21:17,030 --> 00:21:19,129 demo demo transaction and I can 531 00:21:19,130 --> 00:21:21,289 either confirm it or cancel it. 532 00:21:21,290 --> 00:21:23,779 And if I confirm it, then it's just 533 00:21:23,780 --> 00:21:25,849 some animation doing the signing. 534 00:21:25,850 --> 00:21:27,829 And so that's how it looks. 535 00:21:36,610 --> 00:21:39,609 I anyone 536 00:21:39,610 --> 00:21:40,610 is. 537 00:21:41,850 --> 00:21:43,499 Thank you very much. 538 00:21:43,500 --> 00:21:45,509 If you have any questions you already 539 00:21:45,510 --> 00:21:47,579 know the drill, please line up 540 00:21:47,580 --> 00:21:48,660 behind the microphones 541 00:21:50,190 --> 00:21:52,319 so you have 542 00:21:52,320 --> 00:21:53,429 a question number three. 543 00:21:53,430 --> 00:21:55,229 Please go right ahead. 544 00:21:55,230 --> 00:21:57,029 Yes, I was wondering if your your 545 00:21:57,030 --> 00:21:59,099 hardware wallet supports 546 00:21:59,100 --> 00:22:01,409 other types of complex transactions, 547 00:22:01,410 --> 00:22:04,169 like in out of him transactions 548 00:22:04,170 --> 00:22:05,429 and such. 549 00:22:05,430 --> 00:22:08,279 In the first funeral we be releasing 550 00:22:08,280 --> 00:22:10,409 in January, there won't be such 551 00:22:10,410 --> 00:22:12,599 a feature. But because we have a future 552 00:22:12,600 --> 00:22:14,909 update possibility, we 553 00:22:14,910 --> 00:22:16,199 definitely want to include 554 00:22:16,200 --> 00:22:18,249 multi-signature in the next version of 555 00:22:18,250 --> 00:22:20,909 firmware and probably some more complex, 556 00:22:20,910 --> 00:22:22,719 complex transaction types. 557 00:22:22,720 --> 00:22:23,720 If. 558 00:22:30,250 --> 00:22:32,289 Are there any questions from IOC? 559 00:22:32,290 --> 00:22:33,369 Yes, one, please. 560 00:22:34,820 --> 00:22:37,689 Um, it's look look like 561 00:22:37,690 --> 00:22:40,029 the person perfect solution 562 00:22:40,030 --> 00:22:43,219 for Ethereum usage. 563 00:22:43,220 --> 00:22:46,389 Um, do you think maybe 564 00:22:46,390 --> 00:22:48,729 bitcoin ATM machines 565 00:22:48,730 --> 00:22:49,819 are, uh, 566 00:22:51,160 --> 00:22:52,160 popular? 567 00:22:52,870 --> 00:22:54,939 Integrate it 568 00:22:54,940 --> 00:22:57,279 with some popular ATM machines 569 00:22:57,280 --> 00:22:58,959 in the future? 570 00:22:58,960 --> 00:22:59,969 I think it should. 571 00:22:59,970 --> 00:23:01,839 It should be possible to integrate it 572 00:23:01,840 --> 00:23:04,509 with ATM in the future there. 573 00:23:04,510 --> 00:23:06,969 Well, ATM is more or less 574 00:23:06,970 --> 00:23:09,069 common computer nowadays, so I 575 00:23:09,070 --> 00:23:11,139 see no reason why we we shouldn't 576 00:23:11,140 --> 00:23:12,849 go that way. 577 00:23:12,850 --> 00:23:14,949 But if 578 00:23:14,950 --> 00:23:16,419 because we don't have any Bluetooth or 579 00:23:16,420 --> 00:23:18,999 radio, uh, the first 580 00:23:19,000 --> 00:23:21,069 version would have to support USB, 581 00:23:21,070 --> 00:23:23,049 but maybe in the future there will be 582 00:23:23,050 --> 00:23:24,250 some, some other ways. 583 00:23:28,020 --> 00:23:30,329 Number one, please tell me 584 00:23:30,330 --> 00:23:32,529 what happens with a bitcoin 585 00:23:32,530 --> 00:23:34,619 stored on the device when 586 00:23:34,620 --> 00:23:35,620 it breaks, 587 00:23:37,200 --> 00:23:39,389 then you able to recover your 588 00:23:39,390 --> 00:23:41,639 paper wallet with this 12 or 589 00:23:41,640 --> 00:23:42,989 twenty four words. 590 00:23:42,990 --> 00:23:45,209 And using this backup, 591 00:23:45,210 --> 00:23:47,459 you can recover it into other Trezor 592 00:23:47,460 --> 00:23:50,099 device or just use software 593 00:23:50,100 --> 00:23:52,709 that's compatible with Bip 49 594 00:23:52,710 --> 00:23:54,869 and send your bitcoins to 595 00:23:54,870 --> 00:23:57,059 other other address. 596 00:23:57,060 --> 00:23:59,129 So that's the main purpose of 597 00:23:59,130 --> 00:24:00,480 this paper. One of the backups? 598 00:24:03,790 --> 00:24:06,279 Next question from number four, please. 599 00:24:06,280 --> 00:24:07,939 Hi, thank you for your talk. 600 00:24:07,940 --> 00:24:09,609 It's very interesting. 601 00:24:09,610 --> 00:24:11,849 Thanks. I saw on the website 602 00:24:11,850 --> 00:24:13,779 the preorders are closed. 603 00:24:13,780 --> 00:24:15,189 Do you have an idea when you will be 604 00:24:15,190 --> 00:24:16,190 taking orders again? 605 00:24:17,320 --> 00:24:19,539 We will be shipping 606 00:24:19,540 --> 00:24:21,969 Trezor to preorder people in 607 00:24:21,970 --> 00:24:24,159 January. And after all these preorders 608 00:24:24,160 --> 00:24:26,349 are shipped, we will reopen Trezor 609 00:24:26,350 --> 00:24:27,730 for regular sale 610 00:24:29,020 --> 00:24:30,819 in February. 611 00:24:30,820 --> 00:24:32,109 Well, after we are done. 612 00:24:32,110 --> 00:24:34,389 So most probably in February, right? 613 00:24:34,390 --> 00:24:35,390 Thank you. 614 00:24:36,490 --> 00:24:37,719 Number one, please. 615 00:24:37,720 --> 00:24:38,289 Are you thinking 616 00:24:38,290 --> 00:24:39,759 about another version where you have 617 00:24:39,760 --> 00:24:41,529 maybe a power supply within the device 618 00:24:41,530 --> 00:24:42,639 and then you could transfer the 619 00:24:42,640 --> 00:24:44,889 transactions via Bluetooth or something, 620 00:24:44,890 --> 00:24:47,169 which would be more convenient, maybe for 621 00:24:47,170 --> 00:24:48,170 later users? 622 00:24:49,150 --> 00:24:51,729 The problem is, if we want to have radio 623 00:24:51,730 --> 00:24:53,709 in Trezor, we would need to have a 624 00:24:53,710 --> 00:24:55,719 battery and other stuff. 625 00:24:55,720 --> 00:24:57,939 And it's it looks simple, 626 00:24:57,940 --> 00:25:00,279 but it's adding more and more complexity. 627 00:25:00,280 --> 00:25:02,469 I'm not saying we are not going to go 628 00:25:02,470 --> 00:25:04,959 this way, but the first version, 629 00:25:04,960 --> 00:25:07,149 of course, I suppose version is, yeah, we 630 00:25:07,150 --> 00:25:09,789 will see how her market will 631 00:25:09,790 --> 00:25:10,719 responds. 632 00:25:10,720 --> 00:25:12,939 It's still a new, it's still a new 633 00:25:12,940 --> 00:25:14,919 area for us and for everybody. 634 00:25:14,920 --> 00:25:16,869 So maybe it will be needed. 635 00:25:16,870 --> 00:25:17,919 Maybe it won't. 636 00:25:17,920 --> 00:25:19,269 We'll see. It would be nice, but the 637 00:25:19,270 --> 00:25:21,099 first version is already very well. 638 00:25:21,100 --> 00:25:22,689 Thank you. Lots of luck for that. 639 00:25:22,690 --> 00:25:23,690 Thank you. 640 00:25:25,110 --> 00:25:26,669 Another question from number four, 641 00:25:26,670 --> 00:25:27,389 please. 642 00:25:27,390 --> 00:25:29,249 Yes. So you talked about update 643 00:25:29,250 --> 00:25:30,209 functionality. 644 00:25:30,210 --> 00:25:32,309 How do you prevent any kind 645 00:25:32,310 --> 00:25:34,139 of update functionality from compromising 646 00:25:34,140 --> 00:25:36,089 the device? Obviously, when you plug it 647 00:25:36,090 --> 00:25:38,549 in an untrusted system like 648 00:25:38,550 --> 00:25:40,769 web shop, like an 649 00:25:40,770 --> 00:25:42,869 internet cafe or the aforementioned 650 00:25:42,870 --> 00:25:44,159 ATM machine? 651 00:25:44,160 --> 00:25:45,539 All right. What? 652 00:25:45,540 --> 00:25:48,629 We have a bootloader that contains 653 00:25:48,630 --> 00:25:51,209 our public keys 654 00:25:51,210 --> 00:25:53,429 and all of our freeware 655 00:25:53,430 --> 00:25:55,559 is signed by us. 656 00:25:55,560 --> 00:25:57,909 And if the signature 657 00:25:57,910 --> 00:26:00,089 is incorrect, then Trezor will print that 658 00:26:00,090 --> 00:26:02,219 you are running an official FINRA so 659 00:26:02,220 --> 00:26:04,199 you can build your own forever, but you 660 00:26:04,200 --> 00:26:06,419 will have to confirm 661 00:26:06,420 --> 00:26:08,220 this warning in order to run it. 662 00:26:10,140 --> 00:26:11,140 Thank you. 663 00:26:13,120 --> 00:26:15,189 Many of you are trying to find seats for 664 00:26:15,190 --> 00:26:17,259 the next talk, but please, I 665 00:26:17,260 --> 00:26:19,239 know it's hard. Try not to queue up to 666 00:26:19,240 --> 00:26:20,240 walkways 667 00:26:22,180 --> 00:26:24,459 any more questions from 668 00:26:24,460 --> 00:26:25,460 IOC. Maybe. 669 00:26:26,740 --> 00:26:27,740 OK. 670 00:26:30,930 --> 00:26:32,519 Then thank you for the talk. 671 00:26:32,520 --> 00:26:33,659 Thank you for this lovely.