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/702 Thanks! 1 00:00:14,630 --> 00:00:16,699 We are here for the Talk Wheel 2 00:00:16,700 --> 00:00:19,789 of Fortune, analyzing 3 00:00:19,790 --> 00:00:21,919 embedded OS, no generators 4 00:00:21,920 --> 00:00:24,139 with your sweatsuits and 5 00:00:24,140 --> 00:00:26,329 Alere Aliabadi, short 6 00:00:26,330 --> 00:00:27,109 introduction there. 7 00:00:27,110 --> 00:00:29,269 Both researchers, they 8 00:00:29,270 --> 00:00:31,399 work with distributed and embedded 9 00:00:31,400 --> 00:00:33,799 systems groups at the University 10 00:00:33,800 --> 00:00:34,800 of Twin to. 11 00:00:37,860 --> 00:00:40,049 Your sweatsuits is hardening systems 12 00:00:40,050 --> 00:00:42,189 and hands on teacher for 13 00:00:42,190 --> 00:00:43,190 offensive security, 14 00:00:44,520 --> 00:00:46,589 Alea comes 15 00:00:46,590 --> 00:00:47,590 as a 16 00:00:48,930 --> 00:00:51,329 researcher from what we need in bomb 17 00:00:51,330 --> 00:00:54,070 has a chair at system security. 18 00:00:55,740 --> 00:00:57,809 Before that, he was head 19 00:00:57,810 --> 00:01:00,419 of Vulnerability Analysis and Penetration 20 00:01:00,420 --> 00:01:02,579 Testing Group at the Sharif University 21 00:01:02,580 --> 00:01:04,290 of Technology in Tehran, Iran. 22 00:01:06,000 --> 00:01:08,189 Starting with that, I'll just give 23 00:01:08,190 --> 00:01:10,259 over to both of them and we'll have 24 00:01:10,260 --> 00:01:12,209 a great talk and question the answers 25 00:01:12,210 --> 00:01:13,210 later. 26 00:01:14,430 --> 00:01:15,430 Yes, thank you. 27 00:01:29,150 --> 00:01:30,150 Thanks. 28 00:01:31,550 --> 00:01:33,979 All right, welcome, everybody, 29 00:01:33,980 --> 00:01:35,899 to our Talk Wheel of Fortune, analyzing 30 00:01:35,900 --> 00:01:37,760 embittered oys random number generators 31 00:01:39,380 --> 00:01:40,599 to start with yours. 32 00:01:40,600 --> 00:01:41,959 You want to introduce yourself? 33 00:01:41,960 --> 00:01:43,819 I'm yours, Wetzel's, as I already was 34 00:01:43,820 --> 00:01:45,469 introduced. And I'm a researcher at the 35 00:01:45,470 --> 00:01:47,479 Distributed and Embedded System Security 36 00:01:47,480 --> 00:01:48,689 Group. And 20. 37 00:01:48,690 --> 00:01:49,690 This is. 38 00:01:50,320 --> 00:01:52,609 Yeah, I am a 39 00:01:52,610 --> 00:01:55,039 student at distributed an embassy, 40 00:01:55,040 --> 00:01:56,869 some security group of University of 41 00:01:56,870 --> 00:01:58,959 Toronto and visiting researcher at JFC 42 00:01:58,960 --> 00:02:00,559 Central Committee of the local university 43 00:02:00,560 --> 00:02:01,879 Baucom in Germany. 44 00:02:01,880 --> 00:02:04,159 So we start with the introduction 45 00:02:04,160 --> 00:02:05,959 to the EU's random number generator 46 00:02:05,960 --> 00:02:08,149 today, and then we overview 47 00:02:08,150 --> 00:02:09,259 some of the challenges 48 00:02:10,550 --> 00:02:12,659 for generally and for 49 00:02:12,660 --> 00:02:14,389 a specifically for a random number or a 50 00:02:14,390 --> 00:02:15,949 random number generators. 51 00:02:15,950 --> 00:02:17,959 We will have some case studies which 52 00:02:17,960 --> 00:02:19,339 showing these challenges, how it's 53 00:02:19,340 --> 00:02:21,469 affecting already existing 54 00:02:21,470 --> 00:02:23,539 embittered oysters or real time operating 55 00:02:23,540 --> 00:02:25,669 systems. And, well, this 56 00:02:25,670 --> 00:02:27,619 work is actually an ongoing research is 57 00:02:27,620 --> 00:02:29,809 part of your thesis, 58 00:02:29,810 --> 00:02:30,709 which I am supervising. 59 00:02:30,710 --> 00:02:31,710 And 60 00:02:32,780 --> 00:02:33,229 yeah. 61 00:02:33,230 --> 00:02:35,869 So so 62 00:02:35,870 --> 00:02:37,009 first of all, let me say, some are 63 00:02:37,010 --> 00:02:39,079 actually now everywhere from 64 00:02:39,080 --> 00:02:40,460 consumer electronics, 65 00:02:42,080 --> 00:02:44,029 medical devices, critical 66 00:02:44,030 --> 00:02:46,279 infrastructures, military 67 00:02:46,280 --> 00:02:47,629 equipment or aviation. 68 00:02:47,630 --> 00:02:49,849 So actually, you see them everywhere. 69 00:02:49,850 --> 00:02:52,459 And beside that, there is a drive 70 00:02:52,460 --> 00:02:54,559 for connecting essentially the systems 71 00:02:54,560 --> 00:02:55,849 as an Internet of Things, 72 00:02:56,990 --> 00:02:58,249 wireless originary. 73 00:02:58,250 --> 00:03:00,319 These devices was not designed to be 74 00:03:00,320 --> 00:03:01,369 connected to the Internet. 75 00:03:01,370 --> 00:03:03,619 But but now there is a gap which 76 00:03:03,620 --> 00:03:05,809 vendors have to have to fix. 77 00:03:05,810 --> 00:03:08,089 Right. And well, this can cause 78 00:03:08,090 --> 00:03:10,879 problems. As you can see, for example, 79 00:03:10,880 --> 00:03:13,039 for the random number generators, which 80 00:03:13,040 --> 00:03:15,139 specifically work, you can see 81 00:03:15,140 --> 00:03:16,429 there are problems. 82 00:03:16,430 --> 00:03:18,619 For example, millions of devices use 83 00:03:18,620 --> 00:03:20,299 the same high school association and 84 00:03:20,300 --> 00:03:22,789 Triscuit, which made some noises 85 00:03:22,790 --> 00:03:23,790 in the media. 86 00:03:24,950 --> 00:03:27,029 So do 87 00:03:27,030 --> 00:03:28,300 a random number generators. 88 00:03:30,520 --> 00:03:33,549 Well, what is randomness, 89 00:03:33,550 --> 00:03:34,869 I don't want to talk about the 90 00:03:34,870 --> 00:03:36,969 philosophical talk of randomness 91 00:03:36,970 --> 00:03:39,109 here, but well, it's generally 92 00:03:39,110 --> 00:03:41,529 in extreme of if you cannot predict the 93 00:03:41,530 --> 00:03:43,959 next bit with a probability 94 00:03:43,960 --> 00:03:46,029 of more than 50 percent, then let's 95 00:03:46,030 --> 00:03:47,139 call it random. 96 00:03:47,140 --> 00:03:49,659 And another side of it is like entropy, 97 00:03:50,770 --> 00:03:51,849 which is very interesting is a 98 00:03:51,850 --> 00:03:53,439 measurement of information, 99 00:03:53,440 --> 00:03:55,779 unpredictability and how 100 00:03:55,780 --> 00:03:57,819 how unpredictable our information and 101 00:03:57,820 --> 00:04:00,069 usually high entropy means very random 102 00:04:00,070 --> 00:04:01,989 or high randomness. 103 00:04:01,990 --> 00:04:04,179 And of course, why is these things 104 00:04:04,180 --> 00:04:05,889 are important? Because actually random, 105 00:04:05,890 --> 00:04:08,379 random, random numbers are actually 106 00:04:08,380 --> 00:04:11,139 a fundamental part of other 107 00:04:11,140 --> 00:04:13,209 security systems we have. 108 00:04:13,210 --> 00:04:14,979 So, for example, if use it for 109 00:04:14,980 --> 00:04:17,528 cryptography stuff, so for keys, answers 110 00:04:17,529 --> 00:04:19,869 or exploit mitigations, which maybe 111 00:04:19,870 --> 00:04:21,699 you never heard about it, but actually we 112 00:04:21,700 --> 00:04:23,529 are using them for exploding situations 113 00:04:23,530 --> 00:04:24,880 such as HLR or 114 00:04:26,650 --> 00:04:27,999 smashing protections. 115 00:04:28,000 --> 00:04:29,979 So randomness is actually critical for 116 00:04:29,980 --> 00:04:32,289 other other underlying system 117 00:04:32,290 --> 00:04:34,299 which builds up on them. 118 00:04:34,300 --> 00:04:36,729 So that's why they are critical. 119 00:04:36,730 --> 00:04:38,769 So how we can generate random numbers. 120 00:04:38,770 --> 00:04:42,279 So physically, like true random number 121 00:04:42,280 --> 00:04:44,439 generators are like radioactive 122 00:04:44,440 --> 00:04:47,199 radioactive decays or Noisettes. 123 00:04:47,200 --> 00:04:49,269 You can implement it 124 00:04:49,270 --> 00:04:51,099 in two ways as external devices such as 125 00:04:51,100 --> 00:04:53,399 2pm Orishas or 126 00:04:53,400 --> 00:04:55,729 as integrated device within, for example, 127 00:04:55,730 --> 00:04:58,149 into Ivy Bridge, CPU's or Certina 128 00:04:58,150 --> 00:04:59,379 smartcards. 129 00:04:59,380 --> 00:05:01,119 But there are some downsides for, for 130 00:05:01,120 --> 00:05:03,819 example, your expensive or do some 131 00:05:03,820 --> 00:05:06,159 portability issues when the cavender try 132 00:05:06,160 --> 00:05:08,560 to move to the next architecture. 133 00:05:10,310 --> 00:05:12,379 So that's why, because you 134 00:05:12,380 --> 00:05:14,209 can't use those expensive hardwares you 135 00:05:14,210 --> 00:05:16,459 are using, software is a random number. 136 00:05:16,460 --> 00:05:18,859 Generators are like deterministic 137 00:05:18,860 --> 00:05:21,049 algorithms, which you stretch 138 00:05:21,050 --> 00:05:22,760 into sequence of random looking bits. 139 00:05:24,110 --> 00:05:25,519 But the problem is that not all of these 140 00:05:25,520 --> 00:05:28,189 random number generators are designed to 141 00:05:28,190 --> 00:05:29,599 be used for security purposes. 142 00:05:29,600 --> 00:05:31,879 For example, RAND, which we are 143 00:05:31,880 --> 00:05:34,189 going to show it will be used 144 00:05:34,190 --> 00:05:36,229 later by some people. 145 00:05:36,230 --> 00:05:37,759 It's not designed for security purposes, 146 00:05:37,760 --> 00:05:39,619 but some people anyway. 147 00:05:39,620 --> 00:05:42,439 Uh, so 148 00:05:42,440 --> 00:05:44,719 because of that, we have 149 00:05:44,720 --> 00:05:46,939 secure random number generators 150 00:05:46,940 --> 00:05:49,219 and those are usually 151 00:05:49,220 --> 00:05:51,109 they have like three features or 152 00:05:51,110 --> 00:05:53,359 properties, first of all, is that 153 00:05:53,360 --> 00:05:55,639 the output must be indistinguishable from 154 00:05:55,640 --> 00:05:57,799 the uniform and there 155 00:05:57,800 --> 00:05:59,749 must have forward security, which means 156 00:05:59,750 --> 00:06:02,039 that in case the internal internal 157 00:06:02,040 --> 00:06:03,619 state of the of the system is 158 00:06:03,620 --> 00:06:05,689 compromised, still the past 159 00:06:05,690 --> 00:06:07,819 outputs must still appear random. 160 00:06:07,820 --> 00:06:10,219 And again for port security 161 00:06:10,220 --> 00:06:12,229 as a feature, which is that if internal 162 00:06:12,230 --> 00:06:14,479 state is compromised again, the future 163 00:06:14,480 --> 00:06:16,789 output still must appear 164 00:06:16,790 --> 00:06:18,759 appear random, provided that the 165 00:06:18,760 --> 00:06:20,869 preceding is either sufficient or 166 00:06:20,870 --> 00:06:22,160 good quality entropy. 167 00:06:23,990 --> 00:06:26,639 So because of that, designing 168 00:06:26,640 --> 00:06:28,639 random number generators are not easy. 169 00:06:28,640 --> 00:06:30,169 So because of that you have, for example, 170 00:06:30,170 --> 00:06:32,509 some certain standards for it, like 171 00:06:32,510 --> 00:06:34,350 NYST SB 890, 172 00:06:35,570 --> 00:06:37,339 which has some some access to possibly a 173 00:06:37,340 --> 00:06:38,419 source of student trappy. 174 00:06:38,420 --> 00:06:39,919 But the problem is that these are 175 00:06:39,920 --> 00:06:41,899 standard leave some heart problems, for 176 00:06:41,900 --> 00:06:44,149 example, initial seed entropy 177 00:06:44,150 --> 00:06:46,369 or resitting control or 178 00:06:46,370 --> 00:06:48,439 how how is the quality of 179 00:06:48,440 --> 00:06:51,529 the source of the entropy 180 00:06:51,530 --> 00:06:53,719 is so because of that? 181 00:06:53,720 --> 00:06:55,489 Well, some but some other people think 182 00:06:55,490 --> 00:06:57,229 about it and design something else, such 183 00:06:57,230 --> 00:06:58,370 as your or for Tunner, 184 00:06:59,450 --> 00:07:01,909 which already implemented in some advice. 185 00:07:01,910 --> 00:07:04,279 Or is it such as OSX or free BSD 186 00:07:04,280 --> 00:07:05,280 or Aiwass. 187 00:07:06,670 --> 00:07:08,829 So the problem 188 00:07:08,830 --> 00:07:10,839 here is actually a chicken and egg 189 00:07:10,840 --> 00:07:13,119 problem because, well, 190 00:07:13,120 --> 00:07:15,219 to generate random numbers, you need 191 00:07:15,220 --> 00:07:16,899 some kind of sort of entropy or 192 00:07:16,900 --> 00:07:19,119 randomness. But this randomness, again, 193 00:07:19,120 --> 00:07:21,249 needs another source of randomness. 194 00:07:21,250 --> 00:07:23,109 So ideally, you want to use the physical 195 00:07:23,110 --> 00:07:25,269 phenomena such as 196 00:07:25,270 --> 00:07:27,639 like if we consider quantum randomness 197 00:07:27,640 --> 00:07:29,649 is like radioactive decay, shock noises 198 00:07:29,650 --> 00:07:31,539 or non quantum randomness, such as 199 00:07:31,540 --> 00:07:33,579 termite noises, atmospheric noises and 200 00:07:33,580 --> 00:07:35,410 sensory values. Well, this is so 201 00:07:36,730 --> 00:07:39,219 let's say, not always available. 202 00:07:39,220 --> 00:07:40,809 So practically now. 203 00:07:40,810 --> 00:07:42,399 And for example, General-Purpose 204 00:07:42,400 --> 00:07:44,139 Computer, as you can see, that you can 205 00:07:44,140 --> 00:07:46,599 use unpredictable system events. 206 00:07:46,600 --> 00:07:48,819 One good source is the user user 207 00:07:48,820 --> 00:07:51,159 itself. So keystroke timing, mouse 208 00:07:51,160 --> 00:07:53,169 movement or disk access can be used in 209 00:07:53,170 --> 00:07:55,539 general purpose computers as a sort of 210 00:07:55,540 --> 00:07:57,219 source of entropy. 211 00:07:57,220 --> 00:07:59,859 And therefore, actually 212 00:07:59,860 --> 00:08:02,259 we believe that randomness 213 00:08:02,260 --> 00:08:04,419 or randomness should be 214 00:08:04,420 --> 00:08:07,119 provided as a system service 215 00:08:07,120 --> 00:08:09,399 because it's hard and hard to implement 216 00:08:09,400 --> 00:08:11,469 it. And well, of course, people make 217 00:08:11,470 --> 00:08:13,179 mistakes later if we don't. 218 00:08:13,180 --> 00:08:15,159 So actually, many authors actually 219 00:08:15,160 --> 00:08:17,169 already provide such randomness as a 220 00:08:17,170 --> 00:08:18,639 system service, for example. 221 00:08:18,640 --> 00:08:21,139 Do you do you random 222 00:08:21,140 --> 00:08:23,469 in a Unix like system or create 223 00:08:23,470 --> 00:08:26,139 an random API on windows? 224 00:08:26,140 --> 00:08:28,209 And another important thing is that, 225 00:08:28,210 --> 00:08:30,579 again, all of our lots of other security 226 00:08:30,580 --> 00:08:32,019 products are built upon them. 227 00:08:32,020 --> 00:08:34,629 So, for example, 228 00:08:34,630 --> 00:08:36,129 open SSL, for example, assuming that 229 00:08:36,130 --> 00:08:38,199 there is a secure service for our 230 00:08:38,200 --> 00:08:40,329 operating system as a random number 231 00:08:40,330 --> 00:08:42,428 generators and again based on open source 232 00:08:42,429 --> 00:08:44,349 said you have like open access to an open 233 00:08:44,350 --> 00:08:44,859 VPN. 234 00:08:44,860 --> 00:08:46,140 So it's very, very important. 235 00:08:47,720 --> 00:08:49,539 So now I think you're starting. 236 00:08:49,540 --> 00:08:51,439 All right, so we've taken a look at the 237 00:08:51,440 --> 00:08:53,569 general background of random 238 00:08:53,570 --> 00:08:55,039 number generators, and now we'll take a 239 00:08:55,040 --> 00:08:56,569 look at why it's so difficult to get 240 00:08:56,570 --> 00:08:59,509 these right in in the embedded world. 241 00:08:59,510 --> 00:09:01,399 So the common advice when you need random 242 00:09:01,400 --> 00:09:03,559 numbers in the general-purpose world 243 00:09:03,560 --> 00:09:05,839 is just used a few random and draw 244 00:09:05,840 --> 00:09:06,769 from there. 245 00:09:06,770 --> 00:09:08,449 But it's not as easy in the embedded 246 00:09:08,450 --> 00:09:10,369 world because of various design issues, 247 00:09:10,370 --> 00:09:12,739 which mean that operating system, 248 00:09:12,740 --> 00:09:14,479 random number generators and the embedded 249 00:09:14,480 --> 00:09:16,969 world are often absent or broken, 250 00:09:16,970 --> 00:09:19,879 as we'll explore in this dark. 251 00:09:19,880 --> 00:09:21,979 So the three main areas of 252 00:09:21,980 --> 00:09:24,199 constraints are polyculture, 253 00:09:24,200 --> 00:09:26,239 resource constraints and low entropy 254 00:09:26,240 --> 00:09:27,859 environments, which we'll all discuss 255 00:09:27,860 --> 00:09:29,989 into detail and how these relate to 256 00:09:29,990 --> 00:09:32,519 particular implementation difficulties. 257 00:09:33,530 --> 00:09:35,719 So the first of all is that 258 00:09:35,720 --> 00:09:36,859 in the embedded world, you have a 259 00:09:36,860 --> 00:09:39,019 polyculture of operating systems. 260 00:09:39,020 --> 00:09:40,399 Which areas into general-purpose? 261 00:09:40,400 --> 00:09:42,139 Well, you've got Linux, you've got 262 00:09:42,140 --> 00:09:44,209 Windows, you've got your Mac OS X and 263 00:09:44,210 --> 00:09:45,709 the embedded world. 264 00:09:45,710 --> 00:09:47,719 You have various kinds of different 265 00:09:47,720 --> 00:09:49,729 operating systems ranging from high 266 00:09:49,730 --> 00:09:52,099 capability micro kernels to 267 00:09:52,100 --> 00:09:54,379 very small monolithic systems, 268 00:09:54,380 --> 00:09:56,299 all with different constraints and 269 00:09:56,300 --> 00:09:58,129 different kind of capabilities, engaging, 270 00:09:58,130 --> 00:09:59,149 catering to different systems. 271 00:09:59,150 --> 00:10:01,039 So if you design a general operating 272 00:10:01,040 --> 00:10:03,439 system, a random number generator design, 273 00:10:03,440 --> 00:10:05,569 it's very hard to have this standardized 274 00:10:05,570 --> 00:10:07,459 all across the board because of this 275 00:10:07,460 --> 00:10:08,659 variety. 276 00:10:08,660 --> 00:10:10,519 And the same, of course, applies to to 277 00:10:10,520 --> 00:10:12,469 the hardware spectrum because you have a 278 00:10:12,470 --> 00:10:14,509 wide range of microcontrollers and 279 00:10:14,510 --> 00:10:16,129 microprocessors, all with different 280 00:10:16,130 --> 00:10:17,209 capabilities. 281 00:10:17,210 --> 00:10:19,279 And it's not uncommon to see older or 282 00:10:19,280 --> 00:10:21,409 functionally stripped down versions in a 283 00:10:21,410 --> 00:10:23,149 newly filtered devices. 284 00:10:23,150 --> 00:10:25,309 So if you design 285 00:10:25,310 --> 00:10:27,229 a random number generator based on the 286 00:10:27,230 --> 00:10:29,389 assumption that you have some source of 287 00:10:29,390 --> 00:10:31,579 hardware, a random number generator 288 00:10:31,580 --> 00:10:33,769 or physical, a physical source 289 00:10:33,770 --> 00:10:35,659 of entropy, then this means that your 290 00:10:35,660 --> 00:10:37,309 operating system cannot be deployed 291 00:10:37,310 --> 00:10:38,839 across a wide range of chips. 292 00:10:38,840 --> 00:10:41,179 So that's that's definitely a major 293 00:10:41,180 --> 00:10:42,869 design issue there. 294 00:10:42,870 --> 00:10:45,169 And of course, embedded devices 295 00:10:45,170 --> 00:10:46,879 are designed to have a small footprint 296 00:10:46,880 --> 00:10:48,259 and to be resource efficient. 297 00:10:48,260 --> 00:10:49,789 And this translates to various 298 00:10:49,790 --> 00:10:51,739 limitations when designing random number 299 00:10:51,740 --> 00:10:52,669 generators. 300 00:10:52,670 --> 00:10:55,099 So, for example, limitations with regards 301 00:10:55,100 --> 00:10:57,229 to CPU speed translate to 302 00:10:57,230 --> 00:10:59,989 lightweight cryptography requirements. 303 00:10:59,990 --> 00:11:02,089 Power consumption limitations, especially 304 00:11:02,090 --> 00:11:04,189 for battery operated devices, mean 305 00:11:04,190 --> 00:11:06,289 you need to have a simple design to have 306 00:11:06,290 --> 00:11:07,459 limited entropy. 307 00:11:07,460 --> 00:11:09,619 Falling activity and memory 308 00:11:09,620 --> 00:11:11,659 limitations mean you need small entropy 309 00:11:11,660 --> 00:11:13,549 and internal state in the random number 310 00:11:13,550 --> 00:11:15,499 generator in order to implement it in 311 00:11:15,500 --> 00:11:18,309 these strange devices. 312 00:11:18,310 --> 00:11:20,889 And of course, there's the issue of 313 00:11:20,890 --> 00:11:23,169 the embedded world just generally giving, 314 00:11:23,170 --> 00:11:24,399 being very boring. 315 00:11:24,400 --> 00:11:26,139 There is little activity going on and 316 00:11:26,140 --> 00:11:28,179 what activity is going on is usually very 317 00:11:28,180 --> 00:11:29,469 predictable. 318 00:11:29,470 --> 00:11:31,869 And there is a limitation with regard to 319 00:11:31,870 --> 00:11:32,859 to common entropy. 320 00:11:32,860 --> 00:11:34,749 Sources like like Ali discussed and the 321 00:11:34,750 --> 00:11:35,799 general purpose world. 322 00:11:35,800 --> 00:11:38,379 You often use desk activity, timings, 323 00:11:38,380 --> 00:11:40,539 keyboard events, mouse 324 00:11:40,540 --> 00:11:42,579 events. But in the embedded world, you 325 00:11:42,580 --> 00:11:44,589 often have to deal with diskless, nodes. 326 00:11:44,590 --> 00:11:46,509 You don't have peripherals, you don't 327 00:11:46,510 --> 00:11:48,049 have a user, and you don't have hardware, 328 00:11:48,050 --> 00:11:49,569 random number generators. 329 00:11:49,570 --> 00:11:51,939 And even commonly available sources like 330 00:11:51,940 --> 00:11:54,039 Interop request timings are often not 331 00:11:54,040 --> 00:11:56,110 that good because they're too periodic. 332 00:11:57,390 --> 00:11:59,699 And these conditions are usually worse 333 00:11:59,700 --> 00:12:01,019 during good time because you have 334 00:12:01,020 --> 00:12:02,819 predictable boot sequences, there's 335 00:12:02,820 --> 00:12:05,279 little activity going on at boot 336 00:12:05,280 --> 00:12:07,019 and so mantlepiece sources you might want 337 00:12:07,020 --> 00:12:08,969 to rely on are simply not available yet 338 00:12:08,970 --> 00:12:10,439 because they have to be initialized by 339 00:12:10,440 --> 00:12:13,079 the system after the boot sequence. 340 00:12:13,080 --> 00:12:15,329 Yet none blocking interfaces to a random 341 00:12:15,330 --> 00:12:17,219 number generator such as the Daphnia 342 00:12:17,220 --> 00:12:19,439 random interface allow from drawing from 343 00:12:19,440 --> 00:12:21,179 the random number generator, even when 344 00:12:21,180 --> 00:12:22,769 insufficient entropy is actually 345 00:12:22,770 --> 00:12:24,419 available in the system. 346 00:12:24,420 --> 00:12:25,979 And this results in something called the 347 00:12:25,980 --> 00:12:27,259 boot time entropy hole. 348 00:12:28,890 --> 00:12:31,199 So this is particularly bad because 349 00:12:31,200 --> 00:12:33,239 a lot of embedded devices often generate 350 00:12:33,240 --> 00:12:35,549 cryptographic keys on the first system. 351 00:12:35,550 --> 00:12:37,949 So this means that if you have a system 352 00:12:37,950 --> 00:12:40,079 with general low entropy conditions and 353 00:12:40,080 --> 00:12:42,179 an initial state predetermined in the 354 00:12:42,180 --> 00:12:44,309 factory combined with these these 355 00:12:44,310 --> 00:12:46,379 low voltage conditions 356 00:12:46,380 --> 00:12:48,449 and then generating a key, this 357 00:12:48,450 --> 00:12:51,359 results in very, 358 00:12:51,360 --> 00:12:53,589 very serious cryptographic issues. 359 00:12:53,590 --> 00:12:55,799 A common solution you encounter to deal 360 00:12:55,800 --> 00:12:57,719 with with bootcamps. Entropy in the 361 00:12:57,720 --> 00:12:59,519 general-purpose world is using so-called 362 00:12:59,520 --> 00:13:01,769 sealed files, which is basically file 363 00:13:01,770 --> 00:13:04,019 with collected randomness, which is drawn 364 00:13:04,020 --> 00:13:06,659 from by the random number generator 365 00:13:06,660 --> 00:13:07,799 put into the system. 366 00:13:07,800 --> 00:13:10,049 And when that the system shuts down, 367 00:13:10,050 --> 00:13:11,529 it writes to the file again. 368 00:13:11,530 --> 00:13:12,959 But in the embedded world, it's kind of 369 00:13:12,960 --> 00:13:15,299 hard to generally deploy a solution 370 00:13:15,300 --> 00:13:16,679 because how are you going to deal with 371 00:13:16,680 --> 00:13:17,819 diskless notes? 372 00:13:17,820 --> 00:13:19,499 How are you going to draw your entropy 373 00:13:19,500 --> 00:13:21,719 before a file system is mounted, which is 374 00:13:21,720 --> 00:13:22,799 often required? 375 00:13:22,800 --> 00:13:24,899 And still, this doesn't solve the first 376 00:13:24,900 --> 00:13:25,900 good problem. 377 00:13:27,200 --> 00:13:29,389 So some common embedded work arounds 378 00:13:29,390 --> 00:13:31,639 you encounter is including an initial 379 00:13:31,640 --> 00:13:33,799 seed file in the firmware, and this 380 00:13:33,800 --> 00:13:35,899 initial seed file obviously better 381 00:13:35,900 --> 00:13:38,149 be unique and unpredictable firmware 382 00:13:38,150 --> 00:13:41,209 image as it doesn't do you much good 383 00:13:41,210 --> 00:13:43,459 or using personalization data such 384 00:13:43,460 --> 00:13:45,889 as the Mac address or serial number 385 00:13:45,890 --> 00:13:48,019 of rider and using 386 00:13:48,020 --> 00:13:50,029 it as seed entropy, which is also a very 387 00:13:50,030 --> 00:13:52,099 bad idea shown in the research 388 00:13:52,100 --> 00:13:54,199 mentioned on the bottom or using 389 00:13:54,200 --> 00:13:56,659 other dubious sources of entropy such as 390 00:13:56,660 --> 00:13:58,789 Gloc timings, process IDs, foreign 391 00:13:58,790 --> 00:14:00,859 Mac addresses, etc., etc., or 392 00:14:00,860 --> 00:14:03,109 simply including hardcoded regenerated 393 00:14:03,110 --> 00:14:05,389 keys, which is also a bad idea as shown 394 00:14:05,390 --> 00:14:07,219 in the little black box project. 395 00:14:08,990 --> 00:14:11,089 So now that we have an idea 396 00:14:11,090 --> 00:14:13,849 of why it's hard to to to get embedded 397 00:14:13,850 --> 00:14:15,229 operating system, random number 398 00:14:15,230 --> 00:14:16,129 generators, right. 399 00:14:16,130 --> 00:14:17,599 We're going to look at a couple of case 400 00:14:17,600 --> 00:14:20,179 studies of operating systems fielded in 401 00:14:20,180 --> 00:14:23,479 various embedded into the corporate 402 00:14:23,480 --> 00:14:25,669 various embedded systems and how 403 00:14:25,670 --> 00:14:26,840 they get this wrong. 404 00:14:27,920 --> 00:14:30,739 So the first system we'll look at is QNX, 405 00:14:30,740 --> 00:14:32,839 which is a Unix like Botox compliant 406 00:14:32,840 --> 00:14:34,729 Real-Time Operating System, initially 407 00:14:34,730 --> 00:14:37,039 released in 1982 and later acquired 408 00:14:37,040 --> 00:14:38,689 by by BlackBerry. 409 00:14:38,690 --> 00:14:40,519 It's basically the underlying operating 410 00:14:40,520 --> 00:14:42,259 system for BlackBerry OS. 411 00:14:42,260 --> 00:14:44,299 It's used a lot in automotive systems as 412 00:14:44,300 --> 00:14:46,339 well, particularly the entertainment 413 00:14:46,340 --> 00:14:47,509 systems. 414 00:14:47,510 --> 00:14:49,729 You also encountered in carrier grade 415 00:14:49,730 --> 00:14:52,069 routers, military radios and some nuclear 416 00:14:52,070 --> 00:14:53,070 power plants. 417 00:14:54,230 --> 00:14:56,569 And it provides a custom def random 418 00:14:56,570 --> 00:14:58,309 implementation, which is always non 419 00:14:58,310 --> 00:14:59,719 blocking. So you don't have this this 420 00:14:59,720 --> 00:15:01,399 blocking, non blocking distinctions you 421 00:15:01,400 --> 00:15:03,529 have in most Unix systems. 422 00:15:03,530 --> 00:15:05,329 And it's implemented as a userspace 423 00:15:05,330 --> 00:15:07,429 process addressed by external resource 424 00:15:07,430 --> 00:15:07,979 manager. 425 00:15:07,980 --> 00:15:10,489 Because Kernel, 426 00:15:10,490 --> 00:15:12,439 an interesting thing to note is that the 427 00:15:12,440 --> 00:15:14,089 random number generator has always 428 00:15:14,090 --> 00:15:16,279 started after bood by a startup 429 00:15:16,280 --> 00:15:16,789 script. 430 00:15:16,790 --> 00:15:18,529 So that's that's the thing to keep in 431 00:15:18,530 --> 00:15:19,530 mind. 432 00:15:21,240 --> 00:15:23,159 And we reverse engineered the 433 00:15:23,160 --> 00:15:24,539 implementation of the random number 434 00:15:24,540 --> 00:15:26,309 generator, and it turned out to be based 435 00:15:26,310 --> 00:15:28,709 on Yaro by Bruce Schneier and John 436 00:15:28,710 --> 00:15:30,779 Ferguson, but it turned out 437 00:15:30,780 --> 00:15:33,479 to be based on an older 438 00:15:33,480 --> 00:15:35,609 draft implementation of Yaro, another 439 00:15:35,610 --> 00:15:37,709 reference, 01 60 document, 440 00:15:37,710 --> 00:15:39,899 which was which accompanied the 441 00:15:39,900 --> 00:15:41,069 paper release. 442 00:15:41,070 --> 00:15:43,079 So it only as a single entry people and 443 00:15:43,080 --> 00:15:45,419 no fast and slow pulls and no blocks 444 00:15:45,420 --> 00:15:46,829 before is applied to appear in gene 445 00:15:46,830 --> 00:15:47,999 output at all. 446 00:15:48,000 --> 00:15:49,919 It's directly drawn from the internal 447 00:15:49,920 --> 00:15:51,029 state. 448 00:15:51,030 --> 00:15:53,309 So and given zero in turn, 449 00:15:53,310 --> 00:15:55,409 diverges from this older implementation 450 00:15:55,410 --> 00:15:57,599 as well, by mixing Beerenberg output back 451 00:15:57,600 --> 00:15:59,519 into the entropy people and having some 452 00:15:59,520 --> 00:16:01,649 reseat control divergences, which 453 00:16:01,650 --> 00:16:03,440 we'll discuss later on. 454 00:16:05,510 --> 00:16:07,879 So this is the design of 455 00:16:07,880 --> 00:16:10,289 QNX, Yaro, which is relatively simple, 456 00:16:10,290 --> 00:16:12,019 you have your Budiman entropy. 457 00:16:12,020 --> 00:16:13,879 If you run from entropy and it's drawn 458 00:16:13,880 --> 00:16:16,249 into an actual people, and then you have 459 00:16:16,250 --> 00:16:18,259 the output function which draws from the 460 00:16:18,260 --> 00:16:20,449 people and also sits back into 461 00:16:20,450 --> 00:16:21,500 the induced state. 462 00:16:23,050 --> 00:16:25,149 We first tested the randomness, quality 463 00:16:25,150 --> 00:16:27,339 of the device output, using 464 00:16:27,340 --> 00:16:29,619 the dye harder and the statistical test 465 00:16:29,620 --> 00:16:31,689 suite tools it passed both 466 00:16:31,690 --> 00:16:33,639 of these test to, but this only tells us 467 00:16:33,640 --> 00:16:35,109 something about the quality of the 468 00:16:35,110 --> 00:16:36,489 Beerenberg output. 469 00:16:36,490 --> 00:16:38,319 The source entropy can still be heavily 470 00:16:38,320 --> 00:16:41,419 biased, as we'll see later on. 471 00:16:41,420 --> 00:16:43,579 After reverse engineering the boot 472 00:16:43,580 --> 00:16:45,739 time gathering routines, we 473 00:16:45,740 --> 00:16:47,809 found that it draws from four sources 474 00:16:47,810 --> 00:16:49,459 only and these are static and non 475 00:16:49,460 --> 00:16:50,809 configurable. 476 00:16:50,810 --> 00:16:52,069 That's the system time. 477 00:16:52,070 --> 00:16:53,929 The clock cycle counts the currently 478 00:16:53,930 --> 00:16:55,639 active process IDs and the currently 479 00:16:55,640 --> 00:16:57,079 active device names. 480 00:16:57,080 --> 00:16:58,729 And they concatenate days and they pull 481 00:16:58,730 --> 00:17:01,219 it. Rudisha one hash function and the 482 00:17:01,220 --> 00:17:03,529 resulting digest is used to initialize 483 00:17:03,530 --> 00:17:04,670 the QNX zero initial. 484 00:17:06,900 --> 00:17:08,789 So we decided to because this sounded 485 00:17:08,790 --> 00:17:11,519 kind of dodgy, we decided to evaluate 486 00:17:11,520 --> 00:17:13,199 the Butan entropy, because if this is 487 00:17:13,200 --> 00:17:15,299 very biased, it might be feasible for 488 00:17:15,300 --> 00:17:17,879 an attacker to replicate the Berrington 489 00:17:17,880 --> 00:17:19,709 internal state after a reasonable number 490 00:17:19,710 --> 00:17:20,848 of guesses. 491 00:17:20,849 --> 00:17:22,679 So our quality measure is the main 492 00:17:22,680 --> 00:17:24,868 entropy, which basically means how likely 493 00:17:24,869 --> 00:17:26,848 you are to guess a particular value on 494 00:17:26,849 --> 00:17:29,159 the first try and 256 495 00:17:29,160 --> 00:17:31,469 bits of uniformly random data after 496 00:17:31,470 --> 00:17:34,019 56 bits of entropy. 497 00:17:34,020 --> 00:17:36,059 We use the next entropy source testing 498 00:17:36,060 --> 00:17:39,029 tool to evaluate this this data. 499 00:17:39,030 --> 00:17:40,849 And we collected 50 bood runs by 500 00:17:40,850 --> 00:17:42,949 instrumenting the random number 501 00:17:42,950 --> 00:17:44,929 generator and logging the raw data that 502 00:17:44,930 --> 00:17:46,969 was collected during Butan and the 503 00:17:46,970 --> 00:17:48,979 average MIN entropy is zero point zero 504 00:17:48,980 --> 00:17:51,079 two seven six, which 505 00:17:51,080 --> 00:17:52,639 isn't good at all because that means it 506 00:17:52,640 --> 00:17:54,849 has far less than one bit of entropy 507 00:17:54,850 --> 00:17:56,629 for eight bits of raw data. 508 00:17:56,630 --> 00:17:58,579 As you can see in the visualization on 509 00:17:58,580 --> 00:18:00,619 the right were the dark spots are low 510 00:18:00,620 --> 00:18:02,719 entropy spots with a particularly low 511 00:18:02,720 --> 00:18:04,939 entropy spot at the bottom 512 00:18:04,940 --> 00:18:05,389 left. 513 00:18:05,390 --> 00:18:06,440 At the top left, I mean. 514 00:18:08,100 --> 00:18:10,319 So we also have evaluated 515 00:18:10,320 --> 00:18:12,779 the crossbow entropy, because 516 00:18:12,780 --> 00:18:15,059 even if a system has relatively 517 00:18:15,060 --> 00:18:17,129 good entropy quality during 518 00:18:17,130 --> 00:18:19,889 a single Buderim, if it's consistent 519 00:18:19,890 --> 00:18:21,959 among various bood runs, this is also 520 00:18:21,960 --> 00:18:23,249 behavior you don't want. 521 00:18:23,250 --> 00:18:25,469 And it turned out that apart from 522 00:18:25,470 --> 00:18:28,229 having less than stellar 523 00:18:28,230 --> 00:18:30,419 single bood entropy gathering, it 524 00:18:30,420 --> 00:18:32,579 also had a very consistent, predictable 525 00:18:32,580 --> 00:18:34,919 pattern across 50 bood visualizations, 526 00:18:34,920 --> 00:18:37,019 as you can see on the right. 527 00:18:37,020 --> 00:18:38,759 And you need to consider that this is 528 00:18:38,760 --> 00:18:40,979 operating systems like these are deployed 529 00:18:40,980 --> 00:18:42,059 in firmware images. 530 00:18:42,060 --> 00:18:44,279 So processes always spawn in the same 531 00:18:44,280 --> 00:18:45,779 order and there's the same number of 532 00:18:45,780 --> 00:18:46,979 processes. 533 00:18:46,980 --> 00:18:48,779 So all these process ideas that are fed 534 00:18:48,780 --> 00:18:50,999 into the boot time and trappy are 535 00:18:51,000 --> 00:18:53,129 usually static and the same goes for the 536 00:18:53,130 --> 00:18:54,809 device names. And really the only 537 00:18:54,810 --> 00:18:56,699 randomness here comes from the clock time 538 00:18:56,700 --> 00:18:57,839 and the clock cycles. 539 00:18:57,840 --> 00:18:59,819 And even there, there is less variation 540 00:18:59,820 --> 00:19:01,289 than you would want because of the real 541 00:19:01,290 --> 00:19:02,540 time nature of the system. 542 00:19:04,200 --> 00:19:06,209 So this is what the after reverse 543 00:19:06,210 --> 00:19:07,959 engineering, the runtime and entropy 544 00:19:07,960 --> 00:19:10,259 collection engine looks like 545 00:19:10,260 --> 00:19:11,849 on the left. You got your high 546 00:19:11,850 --> 00:19:14,069 performance, got measurements on the top. 547 00:19:14,070 --> 00:19:15,749 You have system information, which is 548 00:19:15,750 --> 00:19:17,879 basically process ID, threat ideas, 549 00:19:17,880 --> 00:19:19,769 flags, all these kind of process 550 00:19:19,770 --> 00:19:22,949 variables which are fed into the 551 00:19:22,950 --> 00:19:24,659 through a Channel one into the Yaro input 552 00:19:24,660 --> 00:19:25,649 function. 553 00:19:25,650 --> 00:19:27,299 And in the bottom left you have your 554 00:19:27,300 --> 00:19:29,009 interrupt the timing source. 555 00:19:29,010 --> 00:19:30,299 In the bottom right there is an 556 00:19:30,300 --> 00:19:32,459 undocumented function, which is 557 00:19:32,460 --> 00:19:34,859 a callback option to a library, possibly 558 00:19:34,860 --> 00:19:36,839 for two random number generator support. 559 00:19:36,840 --> 00:19:38,519 But there is nothing in the documentation 560 00:19:38,520 --> 00:19:40,349 there and it's not clear from the code 561 00:19:40,350 --> 00:19:41,350 either. So. 562 00:19:42,700 --> 00:19:45,689 So some thoughts on this random entropy. 563 00:19:45,690 --> 00:19:47,639 The system information polling has some 564 00:19:47,640 --> 00:19:49,589 problems because there's lots of static 565 00:19:49,590 --> 00:19:52,259 information. Things like user ID, flags 566 00:19:52,260 --> 00:19:54,779 and priority are not likely to vary 567 00:19:54,780 --> 00:19:56,909 at all between different runs and 568 00:19:56,910 --> 00:19:59,189 stack. And programs will only vary if 569 00:19:59,190 --> 00:20:00,689 you enable address space layered 570 00:20:00,690 --> 00:20:02,759 randomization, which is disabled by 571 00:20:02,760 --> 00:20:05,189 by default and time or program 572 00:20:05,190 --> 00:20:06,989 state based randomness is really the only 573 00:20:06,990 --> 00:20:08,309 randomness you're going to get from this 574 00:20:08,310 --> 00:20:10,239 source when it comes to the Interop 575 00:20:10,240 --> 00:20:12,329 timings. One of the big problems is 576 00:20:12,330 --> 00:20:14,219 that it really puts the burden on the 577 00:20:14,220 --> 00:20:16,139 developer because the developer has to 578 00:20:16,140 --> 00:20:18,209 select, which interrupts to draw the 579 00:20:18,210 --> 00:20:19,259 entropy from. 580 00:20:19,260 --> 00:20:20,969 So that means that they have to decide 581 00:20:20,970 --> 00:20:23,099 are these quality sources, 582 00:20:23,100 --> 00:20:25,049 are they not triggered to periodically, 583 00:20:25,050 --> 00:20:26,399 etc., etc.. 584 00:20:26,400 --> 00:20:28,559 But this doesn't really matter, because 585 00:20:28,560 --> 00:20:30,779 in almost all QNX versions, there 586 00:20:30,780 --> 00:20:32,399 is no reseat control. 587 00:20:32,400 --> 00:20:33,839 They actually, after reversing the 588 00:20:33,840 --> 00:20:35,609 binary, they implemented the functions, 589 00:20:35,610 --> 00:20:37,829 but it never actually them, which 590 00:20:37,830 --> 00:20:40,079 means that runtime entropy is accumulated 591 00:20:40,080 --> 00:20:41,879 but never actually makes back into the 592 00:20:41,880 --> 00:20:44,009 state. And booting entropy is the only 593 00:20:44,010 --> 00:20:46,379 entropy you'll find in the entropy 594 00:20:46,380 --> 00:20:48,119 of a QNX Yaru implementation. 595 00:20:48,120 --> 00:20:50,159 And this is very dangerous, especially if 596 00:20:50,160 --> 00:20:52,679 you consider the quality of Buthayna 597 00:20:52,680 --> 00:20:54,749 entropy. We earlier saw 598 00:20:54,750 --> 00:20:57,089 in the latest version QNX six 599 00:20:57,090 --> 00:20:59,189 point six. This is there 600 00:20:59,190 --> 00:21:01,259 was an attempt to fix this by integrating 601 00:21:01,260 --> 00:21:03,719 some form of reseating into functions 602 00:21:03,720 --> 00:21:05,999 called during initialization and output. 603 00:21:06,000 --> 00:21:07,709 So whenever they appear in G output, it 604 00:21:07,710 --> 00:21:09,989 recedes from part of the pool. 605 00:21:09,990 --> 00:21:11,999 But an issue is that no entropy 606 00:21:12,000 --> 00:21:14,009 estimation is actually done. 607 00:21:14,010 --> 00:21:15,899 And this is what Yaro was initially 608 00:21:15,900 --> 00:21:18,119 designed to do, to do entropy estimation 609 00:21:18,120 --> 00:21:19,379 on your entropy pools. 610 00:21:19,380 --> 00:21:21,359 So you only received when you have proper 611 00:21:21,360 --> 00:21:23,069 entropy quality in these pools. 612 00:21:23,070 --> 00:21:24,419 But this isn't what it does. 613 00:21:24,420 --> 00:21:26,069 It just receives all the time. 614 00:21:27,120 --> 00:21:28,949 Luckily, we disclosed some of these 615 00:21:28,950 --> 00:21:31,019 issues to BlackBerry and based on our 616 00:21:31,020 --> 00:21:33,179 suggestions, they drafted a new Fortuna 617 00:21:33,180 --> 00:21:35,699 based Beerenberg for the successor 618 00:21:35,700 --> 00:21:36,599 of Yaro. 619 00:21:36,600 --> 00:21:37,799 For those who don't know. 620 00:21:37,800 --> 00:21:40,049 And it's available in batches for QNX six 621 00:21:40,050 --> 00:21:41,729 point six. And it will be the default 622 00:21:41,730 --> 00:21:43,949 random number generator for the upcoming 623 00:21:43,950 --> 00:21:45,779 QNX seven, which should be released, I 624 00:21:45,780 --> 00:21:47,800 think in January or something like that. 625 00:21:48,930 --> 00:21:51,029 So this brings us to the next operating 626 00:21:51,030 --> 00:21:53,069 system, which we can mention because it 627 00:21:53,070 --> 00:21:54,390 was studied under NDA. 628 00:21:56,080 --> 00:21:58,559 It's compliant Real-Time operating system 629 00:21:58,560 --> 00:22:00,629 used in highly sensitive systems such 630 00:22:00,630 --> 00:22:02,729 as the Joint Strike Fighter, the JTR 631 00:22:02,730 --> 00:22:04,469 US military radio system and the 632 00:22:04,470 --> 00:22:06,659 International Space Station. 633 00:22:06,660 --> 00:22:08,819 And it has a random number 634 00:22:08,820 --> 00:22:11,069 generator available via a random 635 00:22:11,070 --> 00:22:12,479 interface. 636 00:22:12,480 --> 00:22:14,249 And it has two associated functions 637 00:22:14,250 --> 00:22:15,869 called your random read, which fills a 638 00:22:15,870 --> 00:22:17,939 buffer with an bytes 639 00:22:17,940 --> 00:22:20,249 from its random function and your random 640 00:22:20,250 --> 00:22:22,589 right, which receives the Berenger using 641 00:22:22,590 --> 00:22:24,869 only the first D word from from 642 00:22:24,870 --> 00:22:25,919 the buffer you provided. 643 00:22:25,920 --> 00:22:27,749 So that that gives you an idea of the 644 00:22:27,750 --> 00:22:28,750 quality of this thing. 645 00:22:30,660 --> 00:22:32,999 So we reverse engineer this as well and 646 00:22:33,000 --> 00:22:34,379 took a look at what the underlying 647 00:22:34,380 --> 00:22:35,639 Berenger actually was. 648 00:22:35,640 --> 00:22:37,529 And it turned out to be the Gillette CB 649 00:22:37,530 --> 00:22:39,269 is the random function with custom 650 00:22:39,270 --> 00:22:40,619 constants. 651 00:22:40,620 --> 00:22:42,929 And as the documentation clearly 652 00:22:42,930 --> 00:22:44,849 states, this is not a secure random 653 00:22:44,850 --> 00:22:46,919 number generator. So I don't know 654 00:22:46,920 --> 00:22:49,079 why they implemented it there, but 655 00:22:49,080 --> 00:22:50,080 it's there. 656 00:22:51,150 --> 00:22:53,249 That's not the worst thing, because 657 00:22:53,250 --> 00:22:55,139 we also discovered a local reseeded 658 00:22:55,140 --> 00:22:57,149 attack because the Dafu random device is 659 00:22:57,150 --> 00:22:59,249 ruled rideable, which means that anyone 660 00:22:59,250 --> 00:23:02,189 in the system can force appearing reseat 661 00:23:02,190 --> 00:23:04,079 regardless of their privileges. 662 00:23:04,080 --> 00:23:06,359 So a very low privileged user 663 00:23:06,360 --> 00:23:08,699 can simply ride the seat due to random 664 00:23:08,700 --> 00:23:10,769 number generator and then all across 665 00:23:10,770 --> 00:23:12,759 the board control the pure output. 666 00:23:12,760 --> 00:23:14,089 So, yeah, that's nice. 667 00:23:22,730 --> 00:23:24,979 But even if that even if that wasn't 668 00:23:24,980 --> 00:23:27,349 enough, we also discovered 669 00:23:27,350 --> 00:23:28,969 a known seed attack, because if you 670 00:23:28,970 --> 00:23:30,709 reverse engineer the initialization 671 00:23:30,710 --> 00:23:32,839 routines, you see that there is no 672 00:23:32,840 --> 00:23:33,769 seeding at all. 673 00:23:33,770 --> 00:23:36,409 There's just a static 32 bit 674 00:23:36,410 --> 00:23:38,479 seed, which is the same across 675 00:23:38,480 --> 00:23:40,459 all these operating system deployments. 676 00:23:40,460 --> 00:23:42,229 It doesn't vary from Fermor. 677 00:23:42,230 --> 00:23:44,389 It's just the same sequence over 678 00:23:44,390 --> 00:23:45,769 and over again. And there's no actual 679 00:23:45,770 --> 00:23:47,179 entropy in the system at all. 680 00:23:51,200 --> 00:23:53,309 So an attacker who knows the beer 681 00:23:53,310 --> 00:23:55,519 and also knows because 682 00:23:55,520 --> 00:23:57,649 beer and GS are deterministic functions. 683 00:23:57,650 --> 00:23:59,449 They also know all corresponding beer, 684 00:23:59,450 --> 00:24:01,039 the output consumed by crypto 685 00:24:01,040 --> 00:24:02,179 applications. 686 00:24:02,180 --> 00:24:04,069 So she can see on the slide here, the 687 00:24:04,070 --> 00:24:06,409 S.A.G. generator simply draws 688 00:24:06,410 --> 00:24:08,419 from the same output we saw earlier 689 00:24:08,420 --> 00:24:10,999 produced by this known seed. 690 00:24:11,000 --> 00:24:13,349 So consider a remote attacker, 691 00:24:13,350 --> 00:24:15,439 no no local attacker who 692 00:24:15,440 --> 00:24:17,569 has a publicly generated on this target 693 00:24:17,570 --> 00:24:18,889 operating system. 694 00:24:18,890 --> 00:24:21,349 And they know the initial period and 695 00:24:21,350 --> 00:24:22,849 they simply cloned a random number 696 00:24:22,850 --> 00:24:25,219 generator, seek the appropriate state 697 00:24:25,220 --> 00:24:27,319 offset, read from the random number 698 00:24:27,320 --> 00:24:29,179 generator, generate a corresponding 699 00:24:29,180 --> 00:24:30,469 public and private keeper. 700 00:24:30,470 --> 00:24:32,329 And if it matches the target publicly, 701 00:24:32,330 --> 00:24:34,369 well, obviously also the private key 702 00:24:34,370 --> 00:24:36,529 matches. And if it doesn't, it it reads 703 00:24:36,530 --> 00:24:38,689 to the next state 704 00:24:38,690 --> 00:24:40,639 offset. And because the state offsets are 705 00:24:40,640 --> 00:24:42,529 determined by how many bytes have been 706 00:24:42,530 --> 00:24:44,659 read from the random device, 707 00:24:44,660 --> 00:24:46,999 this is bounded by a very reasonable 708 00:24:47,000 --> 00:24:48,709 brute force, upper bound because I don't 709 00:24:48,710 --> 00:24:50,359 think more than four gigabytes will have 710 00:24:50,360 --> 00:24:51,559 been read from the random number 711 00:24:51,560 --> 00:24:53,929 generator before generating your keys. 712 00:24:53,930 --> 00:24:56,479 So we can even compute a lot of this 713 00:24:56,480 --> 00:24:58,189 and we can do a live demo. 714 00:24:58,190 --> 00:25:00,529 But this is a screenshot of an attack 715 00:25:00,530 --> 00:25:02,869 on the day of the device 716 00:25:02,870 --> 00:25:04,939 itself, where we will recover the 717 00:25:04,940 --> 00:25:07,519 private key corresponding to the S.H. 718 00:25:07,520 --> 00:25:10,039 Osaki within a couple of Driss. 719 00:25:10,040 --> 00:25:12,259 And yeah, 720 00:25:12,260 --> 00:25:14,449 that's basically it for this operating 721 00:25:14,450 --> 00:25:15,609 system. You're right. 722 00:25:16,730 --> 00:25:17,730 Yeah. 723 00:25:25,680 --> 00:25:27,729 And the funny thing is, I don't think 724 00:25:27,730 --> 00:25:29,969 even they are going to patch it, 725 00:25:29,970 --> 00:25:32,039 but so 726 00:25:32,040 --> 00:25:34,199 the last case I saw, these vehicles works 727 00:25:34,200 --> 00:25:35,309 six point nine. 728 00:25:35,310 --> 00:25:36,929 It's a real time operating system, 729 00:25:36,930 --> 00:25:39,209 initially released in 1987, 730 00:25:39,210 --> 00:25:41,429 is actually using, for example, Mars, 731 00:25:41,430 --> 00:25:43,679 Curiosity Rover, Apache helicopters 732 00:25:43,680 --> 00:25:45,899 or like 47 B drones or 733 00:25:45,900 --> 00:25:48,119 lots of telecommunication equipment. 734 00:25:50,040 --> 00:25:52,139 Well, about weeks 735 00:25:52,140 --> 00:25:54,669 works, actually. It doesn't provide any 736 00:25:54,670 --> 00:25:56,039 secure run up numbers. 737 00:25:56,040 --> 00:25:57,749 And actually, you can see in libraries 738 00:25:57,750 --> 00:25:59,549 such as open, as I said, well, first of 739 00:25:59,550 --> 00:26:01,799 all, there is no reference for it either. 740 00:26:03,510 --> 00:26:05,669 And, well, it will have 741 00:26:05,670 --> 00:26:07,289 predictable consequences, too. 742 00:26:07,290 --> 00:26:08,999 So as you can, if you're searching the 743 00:26:09,000 --> 00:26:10,619 Internet for the developers who are 744 00:26:10,620 --> 00:26:12,779 asking questions about this stuff about 745 00:26:12,780 --> 00:26:14,609 the Explorer, you can see that well, 746 00:26:14,610 --> 00:26:16,409 somebody comes and say, hey, I 747 00:26:16,410 --> 00:26:18,689 incremented use the RAND 748 00:26:18,690 --> 00:26:20,999 function as seeding 749 00:26:21,000 --> 00:26:23,189 source for, I don't know, the 750 00:26:23,190 --> 00:26:24,190 openness, it said. 751 00:26:25,230 --> 00:26:27,389 Which, as you remember, we initially 752 00:26:27,390 --> 00:26:29,609 said that it's not secure, 753 00:26:29,610 --> 00:26:31,829 it's not it shouldn't be used 754 00:26:31,830 --> 00:26:33,719 for security purposes and. 755 00:26:33,720 --> 00:26:34,720 Well, yeah, 756 00:26:36,270 --> 00:26:38,879 well, and if you are thinking that 757 00:26:38,880 --> 00:26:40,619 this three operating system where at 758 00:26:40,620 --> 00:26:42,449 least the first two, which had a problem 759 00:26:42,450 --> 00:26:44,669 and you were laughing a lot about it, is 760 00:26:44,670 --> 00:26:46,559 the divorce actually is not actually in 761 00:26:46,560 --> 00:26:48,839 the Midwest and real time operating 762 00:26:48,840 --> 00:26:51,299 systems, actually, majority of them 763 00:26:51,300 --> 00:26:54,179 do not support any sexual random numbers. 764 00:26:54,180 --> 00:26:56,399 And and vice work 765 00:26:56,400 --> 00:26:58,529 is far from the only one with 766 00:26:58,530 --> 00:27:00,039 these problems. But we'll be exploring 767 00:27:00,040 --> 00:27:01,379 one of the biggest one. And we expect 768 00:27:01,380 --> 00:27:03,089 that they provide something which they 769 00:27:03,090 --> 00:27:04,199 don't. 770 00:27:04,200 --> 00:27:05,709 And you want to take it. 771 00:27:05,710 --> 00:27:06,779 Yeah. 772 00:27:06,780 --> 00:27:08,579 Yeah. So what are the takeaways from 773 00:27:08,580 --> 00:27:10,949 this? Well, the first one is that the 774 00:27:10,950 --> 00:27:12,419 world is harsh because there are 775 00:27:12,420 --> 00:27:14,519 constraints everywhere and low 776 00:27:14,520 --> 00:27:16,349 entropy issues are very serious. 777 00:27:16,350 --> 00:27:18,419 And it's hard to deal with these in 778 00:27:18,420 --> 00:27:20,399 an operating system that seeks deployment 779 00:27:20,400 --> 00:27:22,079 across various kinds of chips with 780 00:27:22,080 --> 00:27:24,089 different capabilities. 781 00:27:24,090 --> 00:27:26,249 CSP orangy design is not a joke. 782 00:27:26,250 --> 00:27:28,019 Secure randomness should be provided as 783 00:27:28,020 --> 00:27:29,819 an operating system service whenever 784 00:27:29,820 --> 00:27:31,139 possible. 785 00:27:31,140 --> 00:27:33,269 Please don't put the burden on developers 786 00:27:33,270 --> 00:27:35,619 because they will screw up across 787 00:27:35,620 --> 00:27:38,169 these issues from the mailing list 788 00:27:38,170 --> 00:27:40,589 I've shown and more scrutiny 789 00:27:40,590 --> 00:27:42,929 is required because the advice just used 790 00:27:42,930 --> 00:27:44,459 a few random shooting, not land a 791 00:27:44,460 --> 00:27:46,799 developer into trouble as it would 792 00:27:46,800 --> 00:27:49,469 with these previous operating systems. 793 00:27:49,470 --> 00:27:51,029 And too much of the embedded security 794 00:27:51,030 --> 00:27:52,889 world is still unexplored terrain. 795 00:27:52,890 --> 00:27:55,349 So we need more offensive research 796 00:27:55,350 --> 00:27:57,479 into these embedded operating systems 797 00:27:57,480 --> 00:27:59,579 to get them almost up to speed with 798 00:27:59,580 --> 00:28:00,580 a general purpose. Well. 799 00:28:01,970 --> 00:28:03,829 So if you're looking for more technical 800 00:28:03,830 --> 00:28:05,929 details on embedded security, I recommend 801 00:28:05,930 --> 00:28:08,899 or talk at Nic's Enigma in 2017 802 00:28:08,900 --> 00:28:10,849 and if you've got any questions, you can 803 00:28:10,850 --> 00:28:11,850 ask them now. 804 00:28:26,540 --> 00:28:28,339 OK, thanks a lot, first, 805 00:28:29,750 --> 00:28:31,909 for questions and answers, please use 806 00:28:31,910 --> 00:28:34,219 the microphones, just line 807 00:28:34,220 --> 00:28:36,409 up behind the microphones and I'll pick 808 00:28:36,410 --> 00:28:37,910 you for your questions. 809 00:28:42,450 --> 00:28:43,799 I'll start with you. 810 00:28:43,800 --> 00:28:45,989 So this is not a question, this is a nice 811 00:28:45,990 --> 00:28:48,330 story that might be replicated, 812 00:28:49,590 --> 00:28:51,809 but only questions at 813 00:28:51,810 --> 00:28:54,059 the moment would be all this is 814 00:28:54,060 --> 00:28:56,199 about randomness. 815 00:28:56,200 --> 00:28:57,459 This is about right. 816 00:28:57,460 --> 00:28:59,939 Because I talked to 817 00:28:59,940 --> 00:29:02,099 an HP lab engineer from 818 00:29:02,100 --> 00:29:04,169 Bristol and he told me the following 819 00:29:04,170 --> 00:29:06,479 story because they had so much 820 00:29:06,480 --> 00:29:08,399 bandwidth on the Internet. 821 00:29:08,400 --> 00:29:10,739 They then decided, well, let's see 822 00:29:10,740 --> 00:29:13,349 what happens if we send a random 823 00:29:13,350 --> 00:29:15,779 bitstream to death row in a foreign 824 00:29:15,780 --> 00:29:17,039 country. 825 00:29:17,040 --> 00:29:19,169 It just took two weeks for 826 00:29:19,170 --> 00:29:21,329 the GC HQ 827 00:29:21,330 --> 00:29:23,639 to knock on the door and ask them 828 00:29:23,640 --> 00:29:25,829 what the heck they are doing there. 829 00:29:25,830 --> 00:29:27,869 And the random number generator they used 830 00:29:27,870 --> 00:29:30,269 was was a noise diet. 831 00:29:30,270 --> 00:29:31,439 OK, thank you. 832 00:29:33,390 --> 00:29:35,399 Question from the Internet is a radio 833 00:29:35,400 --> 00:29:37,229 noise from a software defined radio a 834 00:29:37,230 --> 00:29:38,579 good source of entropy for a random 835 00:29:38,580 --> 00:29:40,169 number generator? 836 00:29:40,170 --> 00:29:42,299 I'm sorry, Karoubi question. 837 00:29:42,300 --> 00:29:44,669 Uh, is radio a noise 838 00:29:44,670 --> 00:29:45,929 that you get from a software defined 839 00:29:45,930 --> 00:29:47,429 radio chip? Would that be a good source 840 00:29:47,430 --> 00:29:49,009 of entropy? 841 00:29:49,010 --> 00:29:50,429 I as a known quantity, yeah. 842 00:29:50,430 --> 00:29:52,589 I mean, I guess it depends on your 843 00:29:52,590 --> 00:29:54,959 threat model because, um, 844 00:29:54,960 --> 00:29:57,419 is it possible that the attacker controls 845 00:29:57,420 --> 00:29:59,879 radio signals around the device 846 00:29:59,880 --> 00:30:02,289 that that draws solemnly from 847 00:30:02,290 --> 00:30:04,439 the the chip 848 00:30:04,440 --> 00:30:06,359 in a specific frequency range? 849 00:30:06,360 --> 00:30:08,309 Yes. Yeah. I mean, if we can control a 850 00:30:08,310 --> 00:30:10,469 specific frequency, then, 851 00:30:10,470 --> 00:30:11,489 well, it's not. 852 00:30:11,490 --> 00:30:12,989 And it's really dependent on the. 853 00:30:12,990 --> 00:30:14,939 Yeah, it could be good, but it really 854 00:30:14,940 --> 00:30:16,229 depends on your threat model. 855 00:30:16,230 --> 00:30:17,819 Is it a remote attack or you're dealing 856 00:30:17,820 --> 00:30:19,949 with an attacker with physical access, 857 00:30:19,950 --> 00:30:21,009 et cetera, et cetera. 858 00:30:26,220 --> 00:30:27,930 One of the slides you mentioned 859 00:30:29,160 --> 00:30:30,769 a little bit closer to the microphone. 860 00:30:30,770 --> 00:30:32,849 One of the slides you mentioned 861 00:30:32,850 --> 00:30:36,179 only boot into a low entropy attack. 862 00:30:36,180 --> 00:30:37,439 Do you have any best practice 863 00:30:37,440 --> 00:30:40,679 recommendations for application? 864 00:30:40,680 --> 00:30:42,899 Because on Lennix, 865 00:30:42,900 --> 00:30:45,329 they have random blocks, for example, 866 00:30:45,330 --> 00:30:47,429 on the BSD, that random does 867 00:30:47,430 --> 00:30:49,679 not block unless it hasn't been seeded 868 00:30:49,680 --> 00:30:51,899 yet and obviously sets it 869 00:30:51,900 --> 00:30:53,849 in the bootloader stage before. 870 00:30:53,850 --> 00:30:55,700 Even the kind of main function answer 871 00:30:56,810 --> 00:30:59,099 is because developers 872 00:30:59,100 --> 00:31:01,949 have to know every operating system. 873 00:31:01,950 --> 00:31:04,139 Well, the problem with the blocking 874 00:31:04,140 --> 00:31:05,609 thing is and this came up in 875 00:31:05,610 --> 00:31:07,889 communications with BlackBerry as well, 876 00:31:07,890 --> 00:31:10,229 is that if you say I only provide 877 00:31:10,230 --> 00:31:12,389 randomness when I have 878 00:31:12,390 --> 00:31:14,129 sufficient entropy in the pool, and I'm 879 00:31:14,130 --> 00:31:16,379 sure that this is high quality, this 880 00:31:16,380 --> 00:31:17,999 is not as easy to do in the embedded 881 00:31:18,000 --> 00:31:19,859 world, because that means that, for 882 00:31:19,860 --> 00:31:21,989 example, if you need some sort of secure 883 00:31:21,990 --> 00:31:24,089 randomness during boot and you don't 884 00:31:24,090 --> 00:31:25,859 have enough entropy, then good times get 885 00:31:25,860 --> 00:31:27,989 really slow, and especially if you have 886 00:31:27,990 --> 00:31:30,749 devices under real time constraints. 887 00:31:30,750 --> 00:31:32,909 This is an engineering hurdle right 888 00:31:32,910 --> 00:31:35,519 there. So I'd say 889 00:31:35,520 --> 00:31:37,259 a paper was published, I think at the 890 00:31:37,260 --> 00:31:39,869 Security and Privacy 2013. 891 00:31:39,870 --> 00:31:41,579 I think it was called something like 892 00:31:41,580 --> 00:31:44,009 Welcome to the Tropics or something 893 00:31:44,010 --> 00:31:44,909 like that. 894 00:31:44,910 --> 00:31:47,069 And there were some good best practices. 895 00:31:47,070 --> 00:31:48,979 Recommendations for the embattled world 896 00:31:48,980 --> 00:31:51,209 are mainly in the form of seed files. 897 00:31:51,210 --> 00:31:53,309 But as we mentioned already, if you have 898 00:31:53,310 --> 00:31:55,319 diskless nodes there, it's kind of an 899 00:31:55,320 --> 00:31:58,259 open problem to design a real good 900 00:31:58,260 --> 00:32:00,149 embedded open source, random number 901 00:32:00,150 --> 00:32:02,279 generator for all across 902 00:32:02,280 --> 00:32:03,280 the board. 903 00:32:06,660 --> 00:32:08,939 Uh, second microphone back there, please. 904 00:32:08,940 --> 00:32:10,169 Uh, thank you. 905 00:32:10,170 --> 00:32:12,059 You mentioned the NDA you have with the 906 00:32:12,060 --> 00:32:14,069 vendor. What is the nature of your 907 00:32:14,070 --> 00:32:15,179 relationship with this vendor? 908 00:32:15,180 --> 00:32:16,649 How did you end up with an NDA, with 909 00:32:16,650 --> 00:32:19,019 them? And how 910 00:32:19,020 --> 00:32:21,089 do you ensure they are not going to fix? 911 00:32:28,670 --> 00:32:30,879 I can just I can just tell you that 912 00:32:30,880 --> 00:32:33,189 it took one year for us to 913 00:32:33,190 --> 00:32:35,259 get to us because they're providing. 914 00:32:35,260 --> 00:32:37,419 Well, they claim security, job security. 915 00:32:37,420 --> 00:32:40,029 So that's how it is, 916 00:32:40,030 --> 00:32:41,949 to be honest, in lots of real time 917 00:32:41,950 --> 00:32:43,929 operating systems, they are living in 918 00:32:43,930 --> 00:32:44,930 1998. 919 00:32:46,060 --> 00:32:48,219 So it's an academic effort, not 920 00:32:48,220 --> 00:32:49,749 a consulting assignment. 921 00:32:49,750 --> 00:32:51,279 OK, thank you. 922 00:32:51,280 --> 00:32:53,679 OK, then you please. 923 00:32:53,680 --> 00:32:54,789 Thanks for good talk. 924 00:32:55,840 --> 00:32:57,420 First question, um, 925 00:32:58,480 --> 00:32:59,709 are the eight 926 00:33:01,060 --> 00:33:04,329 relies on you to fight 927 00:33:04,330 --> 00:33:06,969 random before 928 00:33:06,970 --> 00:33:08,349 for initializing Colonel. 929 00:33:08,350 --> 00:33:10,689 Address randomization, layout 930 00:33:10,690 --> 00:33:11,690 randomization. 931 00:33:13,270 --> 00:33:15,669 Do you think that relying 932 00:33:15,670 --> 00:33:17,769 on bootloader is better 933 00:33:17,770 --> 00:33:19,869 for operating system than trying 934 00:33:19,870 --> 00:33:21,939 to solve random problem with 935 00:33:21,940 --> 00:33:22,940 ugly means? 936 00:33:24,580 --> 00:33:27,579 I mean, don't take into 937 00:33:27,580 --> 00:33:30,549 don't take a random number generating 938 00:33:30,550 --> 00:33:32,919 the responsibility of their operating 939 00:33:32,920 --> 00:33:35,709 system, but put it to bootloader. 940 00:33:35,710 --> 00:33:38,589 Yeah, I mean, I guess that depends on, 941 00:33:38,590 --> 00:33:39,519 uh. 942 00:33:39,520 --> 00:33:41,959 Well, on your design model, for example, 943 00:33:41,960 --> 00:33:44,259 um, that would require you 944 00:33:44,260 --> 00:33:46,719 to, to have a bootloader 945 00:33:46,720 --> 00:33:48,879 that standardized all across the board 946 00:33:48,880 --> 00:33:49,809 where you want to deploy it. 947 00:33:49,810 --> 00:33:51,909 For example, if there is no bootloader 948 00:33:51,910 --> 00:33:53,679 that's suitable for the kind of embedded 949 00:33:53,680 --> 00:33:55,329 systems you want, but you do want an 950 00:33:55,330 --> 00:33:57,279 operating system and it doesn't have a 951 00:33:57,280 --> 00:33:59,409 random number generator, then 952 00:33:59,410 --> 00:34:01,149 you're left without a random number 953 00:34:01,150 --> 00:34:03,249 generator. So it's one of the biggest 954 00:34:03,250 --> 00:34:04,899 problems. And this is where it is. 955 00:34:04,900 --> 00:34:06,969 Polyculture argument comes in is 956 00:34:06,970 --> 00:34:08,499 that in the general-purpose world, you 957 00:34:08,500 --> 00:34:10,959 can make some assumptions about hardware, 958 00:34:10,960 --> 00:34:12,939 roughly looks like this roughly as these 959 00:34:12,940 --> 00:34:15,189 capabilities software the same, 960 00:34:15,190 --> 00:34:16,658 but the number in the embedded world, 961 00:34:16,659 --> 00:34:18,789 there is so much diversity 962 00:34:18,790 --> 00:34:20,380 that it's probably better to 963 00:34:21,850 --> 00:34:24,249 optionally include functionality 964 00:34:24,250 --> 00:34:26,529 all across the, uh, the software stack 965 00:34:26,530 --> 00:34:28,629 in this case than to simply say, 966 00:34:28,630 --> 00:34:30,279 oh, we simply assume it's there in the 967 00:34:30,280 --> 00:34:32,019 bootloader. And then it turns out that 968 00:34:32,020 --> 00:34:34,149 it's not there in the bootloader 969 00:34:34,150 --> 00:34:35,679 or thinks another idea. 970 00:34:36,790 --> 00:34:39,218 Can we rely on the manufacturer, 971 00:34:39,219 --> 00:34:41,289 which makes a small 972 00:34:41,290 --> 00:34:43,719 device without a random number of sources 973 00:34:44,949 --> 00:34:45,949 to put 974 00:34:47,020 --> 00:34:49,119 to feed the device by random 975 00:34:49,120 --> 00:34:52,059 input during the manufacturing? 976 00:34:52,060 --> 00:34:54,399 I mean, attach the device 977 00:34:54,400 --> 00:34:56,738 before selling it to some random, 978 00:34:56,739 --> 00:34:58,869 expensive random number generator, 979 00:34:58,870 --> 00:35:01,059 uh, get the random input and then 980 00:35:01,060 --> 00:35:01,839 go. 981 00:35:01,840 --> 00:35:03,849 Yeah, it's one of the things I mentioned 982 00:35:03,850 --> 00:35:05,919 that's essentially a seed file and it's 983 00:35:05,920 --> 00:35:07,479 one of the things I mentioned in the 984 00:35:07,480 --> 00:35:09,729 slides. If you include a seed 985 00:35:09,730 --> 00:35:11,439 file with your firmware image and you 986 00:35:11,440 --> 00:35:13,779 make sure it's random them firmware 987 00:35:13,780 --> 00:35:15,969 image, then that might be 988 00:35:15,970 --> 00:35:17,169 a workaround. 989 00:35:17,170 --> 00:35:19,359 But that depends on how well the vendor 990 00:35:19,360 --> 00:35:21,099 understands what they're doing, because a 991 00:35:21,100 --> 00:35:22,569 case in point would be the Western 992 00:35:22,570 --> 00:35:25,179 digital self encrypting drives thing 993 00:35:25,180 --> 00:35:27,039 where they actually generated keys based 994 00:35:27,040 --> 00:35:29,739 on the Lipsey Rand function. 995 00:35:29,740 --> 00:35:31,839 So we export. 996 00:35:31,840 --> 00:35:33,069 Yeah, that kind of stuff. 997 00:35:33,070 --> 00:35:35,109 So it could be a solution. 998 00:35:35,110 --> 00:35:37,389 But yeah, that depends on the vendor 999 00:35:37,390 --> 00:35:38,079 whether they do it. 1000 00:35:38,080 --> 00:35:39,249 Well, thanks. 1001 00:35:39,250 --> 00:35:40,959 You think you OK? 1002 00:35:40,960 --> 00:35:43,300 We have time for one short last question. 1003 00:35:45,430 --> 00:35:47,679 OK, you have three pretty bad examples 1004 00:35:47,680 --> 00:35:50,649 here. Do you have a broader field, 1005 00:35:50,650 --> 00:35:51,999 broader view of the field? 1006 00:35:52,000 --> 00:35:54,189 Are there is it a general problem 1007 00:35:54,190 --> 00:35:56,199 that they are all this bad or did you 1008 00:35:56,200 --> 00:35:58,119 just pick the three worst ones that you 1009 00:35:58,120 --> 00:35:59,679 stumbled upon? 1010 00:35:59,680 --> 00:36:01,929 Are there some operating systems 1011 00:36:01,930 --> 00:36:04,209 that do it right, whatever it might 1012 00:36:04,210 --> 00:36:05,769 be for this? No, actually, these are the 1013 00:36:05,770 --> 00:36:06,770 best. The best. 1014 00:36:17,630 --> 00:36:19,069 OK, thank you very much. 1015 00:36:19,070 --> 00:36:21,049 A warm round of applause for them again, 1016 00:36:21,050 --> 00:36:22,050 please.