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/661 Thanks! 1 00:00:14,580 --> 00:00:17,039 OK, so our next 2 00:00:17,040 --> 00:00:19,259 speaker for the day has 3 00:00:19,260 --> 00:00:21,719 just finished his PhD 4 00:00:21,720 --> 00:00:24,149 on security of yeah, 5 00:00:24,150 --> 00:00:25,739 I think that deserves a round of applause 6 00:00:28,740 --> 00:00:30,919 on the topic of security of a WPA 7 00:00:30,920 --> 00:00:33,509 atlas and ask for 8 00:00:33,510 --> 00:00:36,029 he's now doing his postdoc and focusing 9 00:00:36,030 --> 00:00:37,469 on wireless security. 10 00:00:37,470 --> 00:00:39,899 So, um, and the next talk, 11 00:00:39,900 --> 00:00:42,149 the title is predicting and abusing WPA 12 00:00:42,150 --> 00:00:43,739 to eight to 11 a group. 13 00:00:43,740 --> 00:00:45,719 Kids, please give a big round of applause 14 00:00:45,720 --> 00:00:46,919 to Matthew Bahnhof. 15 00:00:54,670 --> 00:00:57,429 OK, thank you for the nice introduction. 16 00:00:57,430 --> 00:00:59,349 So I am indeed a multivolume and I'm 17 00:00:59,350 --> 00:01:01,509 going to present predicting on abusing 18 00:01:01,510 --> 00:01:03,759 WPA to ingroup group Kice or 19 00:01:03,760 --> 00:01:06,069 more officially entered into that 20 00:01:06,070 --> 00:01:07,779 11 group. 21 00:01:07,780 --> 00:01:09,849 So first, a quick introduction 22 00:01:09,850 --> 00:01:11,649 to Wi-Fi security. 23 00:01:11,650 --> 00:01:14,319 What was the state of Wi-Fi security 24 00:01:14,320 --> 00:01:16,329 before I did this research? 25 00:01:16,330 --> 00:01:18,399 Well, essentially, Wi-Fi 26 00:01:18,400 --> 00:01:20,349 security has been thoroughly 27 00:01:20,350 --> 00:01:22,509 investigated. There have been a 28 00:01:22,510 --> 00:01:23,889 lot of results. 29 00:01:24,970 --> 00:01:26,979 For example, we know at the very first 30 00:01:26,980 --> 00:01:29,469 security algorithm of Wi-Fi wired 31 00:01:29,470 --> 00:01:32,039 and encrypted privacy, 32 00:01:32,040 --> 00:01:33,429 it was Web. 33 00:01:33,430 --> 00:01:36,129 It was horribly flawed. 34 00:01:36,130 --> 00:01:38,169 You probably all noticed that you can 35 00:01:38,170 --> 00:01:40,359 crack a whip network 36 00:01:40,360 --> 00:01:42,669 within mere minutes. 37 00:01:42,670 --> 00:01:44,769 In fact, if you download the latest tool 38 00:01:44,770 --> 00:01:47,139 suite of earthquake, Anji 39 00:01:47,140 --> 00:01:49,179 aren't there is enough traffic on the 40 00:01:49,180 --> 00:01:51,369 network. You can really 41 00:01:51,370 --> 00:01:54,069 obtain the preset key of the network 42 00:01:54,070 --> 00:01:56,679 within only a few minutes and 43 00:01:56,680 --> 00:01:59,319 sometimes, if you're lucky, even seconds. 44 00:01:59,320 --> 00:02:01,689 So the first 45 00:02:01,690 --> 00:02:03,099 attempt by the L.A. 46 00:02:03,100 --> 00:02:04,809 and Teutul 11 group to introduce a 47 00:02:04,810 --> 00:02:07,119 security protocol, it didn't 48 00:02:07,120 --> 00:02:08,800 really went that well. 49 00:02:10,570 --> 00:02:12,429 We also have other attacks recently 50 00:02:12,430 --> 00:02:14,229 against wireless networks and in 51 00:02:14,230 --> 00:02:16,329 particular against WPA. 52 00:02:16,330 --> 00:02:19,029 To one example, 53 00:02:19,030 --> 00:02:21,189 which is quite recent is that 54 00:02:21,190 --> 00:02:24,039 some vendors or some ISPs, 55 00:02:24,040 --> 00:02:26,199 when they hand out their router, 56 00:02:26,200 --> 00:02:28,779 they initialize it with default 57 00:02:28,780 --> 00:02:30,999 passwords, with a default passphrase 58 00:02:31,000 --> 00:02:33,429 on it. Turns out that these are rather 59 00:02:33,430 --> 00:02:36,579 predictable and particular 60 00:02:36,580 --> 00:02:38,849 this default password, which 61 00:02:38,850 --> 00:02:40,689 should be shown somewhere here on the 62 00:02:40,690 --> 00:02:42,579 back of your router or in the car to 63 00:02:42,580 --> 00:02:44,769 receive what it it was derived from 64 00:02:44,770 --> 00:02:46,119 the Mac address. 65 00:02:46,120 --> 00:02:48,159 So if you want to attack one of these 66 00:02:48,160 --> 00:02:50,169 networks, you simply have to sniff the 67 00:02:50,170 --> 00:02:52,209 network, determine the Mac address, and 68 00:02:52,210 --> 00:02:54,699 from that you could derive the 69 00:02:54,700 --> 00:02:56,889 shared key depreciate key 70 00:02:56,890 --> 00:02:57,890 of the network. 71 00:02:59,020 --> 00:03:00,849 And similar to this, you also have 72 00:03:00,850 --> 00:03:02,919 dictionary attacks against the WPA 73 00:03:02,920 --> 00:03:04,119 to handshake. 74 00:03:04,120 --> 00:03:06,459 So these are all known 75 00:03:06,460 --> 00:03:08,919 attacks. And the way that this dictionary 76 00:03:08,920 --> 00:03:11,499 attack work works is essentially 77 00:03:11,500 --> 00:03:13,929 you can force a client to disconnect 78 00:03:13,930 --> 00:03:15,579 from the network and then it will 79 00:03:15,580 --> 00:03:17,289 reconnect with the network. 80 00:03:17,290 --> 00:03:18,999 And if it reconnects, it, of course 81 00:03:19,000 --> 00:03:21,129 performs a fresh handshake with 82 00:03:21,130 --> 00:03:23,499 the access point to negotiate 83 00:03:23,500 --> 00:03:24,789 session keys. 84 00:03:24,790 --> 00:03:26,979 Now, the bad part about this 85 00:03:26,980 --> 00:03:29,169 handshake is that as an attacker, you can 86 00:03:29,170 --> 00:03:31,839 capture the four messages that are 87 00:03:31,840 --> 00:03:33,999 exchanged in this handshake and 88 00:03:34,000 --> 00:03:36,159 then you can perform offline guessing 89 00:03:36,160 --> 00:03:39,189 attacks at the passwords of 90 00:03:39,190 --> 00:03:40,959 your network. 91 00:03:40,960 --> 00:03:42,459 Now, if the handshake would have been 92 00:03:42,460 --> 00:03:44,449 better designed, this kind of dictionary 93 00:03:44,450 --> 00:03:46,929 attacks would not have been possible. 94 00:03:46,930 --> 00:03:48,789 Unfortunately, the way the handshake was 95 00:03:48,790 --> 00:03:50,949 designed, you can make a capture 96 00:03:50,950 --> 00:03:52,119 of the handshake. 97 00:03:52,120 --> 00:03:54,309 You can process this offline on this 98 00:03:54,310 --> 00:03:56,319 kind of dictionary. Attacks are 99 00:03:56,320 --> 00:03:57,969 unfortunately possible. 100 00:03:59,260 --> 00:04:01,449 Um, I think a few years ago, there 101 00:04:01,450 --> 00:04:03,789 was also a tech which shows that 102 00:04:03,790 --> 00:04:05,559 using a bit of social engineering as 103 00:04:05,560 --> 00:04:07,809 well, you can even attack WPA to 104 00:04:07,810 --> 00:04:09,699 enterprise networks. 105 00:04:09,700 --> 00:04:11,649 And these are networks where you have to 106 00:04:11,650 --> 00:04:13,989 type in your username and password. 107 00:04:13,990 --> 00:04:16,208 So think of Airdrome or your company 108 00:04:16,209 --> 00:04:18,789 network or also 109 00:04:18,790 --> 00:04:19,929 the CCC network. 110 00:04:19,930 --> 00:04:21,759 You also have one of these enterprise 111 00:04:21,760 --> 00:04:23,529 networks as well. 112 00:04:23,530 --> 00:04:25,719 And the idea behind this attack, I'm 113 00:04:25,720 --> 00:04:27,729 not going to go into detail here because 114 00:04:27,730 --> 00:04:28,959 these are known. 115 00:04:28,960 --> 00:04:30,639 But one of the parts that they use is 116 00:04:30,640 --> 00:04:32,829 they broadcast a network with the same 117 00:04:32,830 --> 00:04:35,079 side name as the Target network, 118 00:04:35,080 --> 00:04:37,359 but they include a small space bar behind 119 00:04:37,360 --> 00:04:38,079 the name. 120 00:04:38,080 --> 00:04:40,179 And if you then look at the 121 00:04:40,180 --> 00:04:42,309 network name in your operating 122 00:04:42,310 --> 00:04:44,529 system, you won't notice that the network 123 00:04:44,530 --> 00:04:46,329 is, for example, Airdrome and then a 124 00:04:46,330 --> 00:04:47,889 space bar after it. 125 00:04:47,890 --> 00:04:49,539 So it's essentially a completely new 126 00:04:49,540 --> 00:04:51,099 network. And if you connect to a 127 00:04:51,100 --> 00:04:53,199 completely new network, 128 00:04:53,200 --> 00:04:55,119 it's your operating operating system 129 00:04:55,120 --> 00:04:57,879 won't really complain because 130 00:04:57,880 --> 00:05:00,009 otherwise it would say, OK, 131 00:05:00,010 --> 00:05:01,629 previously you connected to it. 132 00:05:01,630 --> 00:05:03,579 Now it suddenly uses a different cert. 133 00:05:03,580 --> 00:05:05,799 This is bad, but because the space 134 00:05:05,800 --> 00:05:08,109 was after after that, as I said, 135 00:05:08,110 --> 00:05:09,609 your operating system will think, oh, 136 00:05:09,610 --> 00:05:12,279 it's a new network, everything is fine. 137 00:05:12,280 --> 00:05:13,689 But as I mentioned, I'm not going into 138 00:05:13,690 --> 00:05:15,789 detail, just mentioning 139 00:05:15,790 --> 00:05:16,989 it as related to work. 140 00:05:16,990 --> 00:05:19,359 In the sense lately 141 00:05:19,360 --> 00:05:20,889 there have also been a few more 142 00:05:20,890 --> 00:05:22,999 theoretical attacks against WPA 143 00:05:23,000 --> 00:05:24,519 type. 144 00:05:24,520 --> 00:05:26,739 They are similar in spirit to the text 145 00:05:26,740 --> 00:05:29,349 on the Web, except cracking WPT 146 00:05:29,350 --> 00:05:31,869 takeup is much, much more difficult, 147 00:05:31,870 --> 00:05:33,159 even though there are also other 148 00:05:33,160 --> 00:05:35,289 weaknesses. And so 149 00:05:35,290 --> 00:05:37,089 you should not use it. 150 00:05:37,090 --> 00:05:38,829 But you are theoretical attacks that 151 00:05:38,830 --> 00:05:40,899 allow you to recover the session keys as 152 00:05:40,900 --> 00:05:42,579 well, though they are very hard to 153 00:05:42,580 --> 00:05:44,529 execute and practice. 154 00:05:44,530 --> 00:05:47,049 So why am I telling you all this? 155 00:05:47,050 --> 00:05:49,419 Well, if you look at all this previous 156 00:05:49,420 --> 00:05:51,759 research about the security of wireless 157 00:05:51,760 --> 00:05:52,899 networks. 158 00:05:52,900 --> 00:05:54,609 We can see that a lot of this work is 159 00:05:54,610 --> 00:05:56,949 focused on the security of the preset 160 00:05:56,950 --> 00:05:59,649 keys or of the negotiated 161 00:05:59,650 --> 00:06:01,779 session keys, so that has 162 00:06:01,780 --> 00:06:04,059 received a very large amount 163 00:06:04,060 --> 00:06:06,189 of attention from the research community 164 00:06:06,190 --> 00:06:08,259 and also from hackers. 165 00:06:08,260 --> 00:06:10,389 However, the keys that are used to 166 00:06:10,390 --> 00:06:12,609 protect broadcast traffic, so 167 00:06:12,610 --> 00:06:15,129 the group keys, they are not 168 00:06:15,130 --> 00:06:16,389 widely used. 169 00:06:18,220 --> 00:06:20,740 So here is something strange with slight. 170 00:06:23,670 --> 00:06:26,609 For some reason, one slight is 171 00:06:26,610 --> 00:06:28,709 missing, but anyway, so 172 00:06:28,710 --> 00:06:31,259 this group case, they are used to encrypt 173 00:06:31,260 --> 00:06:33,479 broadcast on multicast 174 00:06:33,480 --> 00:06:35,729 traffic and that is in contrast 175 00:06:35,730 --> 00:06:36,619 with session. 176 00:06:36,620 --> 00:06:38,729 So, for example, if you see here 177 00:06:38,730 --> 00:06:40,979 your access, point it as a group 178 00:06:40,980 --> 00:06:42,959 on it also has a session key for every 179 00:06:42,960 --> 00:06:45,089 client that is connected to 180 00:06:45,090 --> 00:06:46,199 the network. 181 00:06:46,200 --> 00:06:48,509 And so what we noticed 182 00:06:48,510 --> 00:06:50,729 is that the security of this 183 00:06:50,730 --> 00:06:52,859 negotiated session is properly 184 00:06:52,860 --> 00:06:55,079 studied, but the security of the group 185 00:06:55,080 --> 00:06:57,269 is not studied. So what I did 186 00:06:57,270 --> 00:06:59,639 during my research is that 187 00:06:59,640 --> 00:07:01,919 I investigated 188 00:07:01,920 --> 00:07:03,899 how these group keys are managed during 189 00:07:03,900 --> 00:07:05,729 their full lifetime. 190 00:07:05,730 --> 00:07:07,949 So what do I mean with the lifetime 191 00:07:07,950 --> 00:07:09,059 of a group? 192 00:07:09,060 --> 00:07:11,109 Well, we have our access point here. 193 00:07:11,110 --> 00:07:13,199 And when you start your access points 194 00:07:13,200 --> 00:07:15,359 or when you start your router, the 195 00:07:15,360 --> 00:07:17,249 first thing that happens is that it 196 00:07:17,250 --> 00:07:19,499 generates a fresh and random 197 00:07:19,500 --> 00:07:20,459 group. 198 00:07:20,460 --> 00:07:22,799 And here we notice that the random number 199 00:07:22,800 --> 00:07:25,139 generator, so the orangy 200 00:07:25,140 --> 00:07:28,229 that is used to generate this group 201 00:07:28,230 --> 00:07:29,429 is flawed. 202 00:07:29,430 --> 00:07:31,659 So the standard suggests 203 00:07:31,660 --> 00:07:33,929 a random number generator as a reference 204 00:07:33,930 --> 00:07:35,009 implementation. 205 00:07:35,010 --> 00:07:37,079 And we will see in practice that certain 206 00:07:37,080 --> 00:07:39,389 vendors also implement a random 207 00:07:39,390 --> 00:07:41,489 number generator. That is predictable 208 00:07:41,490 --> 00:07:43,139 and this will allow us to predict the 209 00:07:43,140 --> 00:07:44,140 group. 210 00:07:44,820 --> 00:07:46,919 So that's essentially the first stage of 211 00:07:46,920 --> 00:07:48,569 the lifetime of the group when it is 212 00:07:48,570 --> 00:07:50,039 generated. 213 00:07:50,040 --> 00:07:52,499 The second part is when a client 214 00:07:52,500 --> 00:07:54,629 connects to the network, when it connects 215 00:07:54,630 --> 00:07:56,729 to the network, it performs this four 216 00:07:56,730 --> 00:07:57,689 way handshake. 217 00:07:57,690 --> 00:07:59,489 It negotiates the session keys. 218 00:07:59,490 --> 00:08:01,259 These are sometimes also called the 219 00:08:01,260 --> 00:08:02,260 Paradise Keys. 220 00:08:03,360 --> 00:08:05,639 And during this handshake, the 221 00:08:05,640 --> 00:08:07,769 group is also transported to 222 00:08:07,770 --> 00:08:09,869 the client because, of course, it 223 00:08:09,870 --> 00:08:11,879 needs to know the group key to be able to 224 00:08:11,880 --> 00:08:14,129 decrypt broadcast on multicast 225 00:08:14,130 --> 00:08:15,599 traffic. 226 00:08:15,600 --> 00:08:18,059 What we found here is that 227 00:08:18,060 --> 00:08:20,099 we can manipulate, manipulate this 228 00:08:20,100 --> 00:08:22,529 handshake as a man in the middle attacker 229 00:08:22,530 --> 00:08:24,719 and we can then use, uh, 230 00:08:24,720 --> 00:08:26,819 we can then force you Shites of 231 00:08:26,820 --> 00:08:28,979 our C4, meaning the 232 00:08:28,980 --> 00:08:30,809 group key, when it is being transmitted 233 00:08:30,810 --> 00:08:32,819 from the access point to the client is 234 00:08:32,820 --> 00:08:33,298 encrypted. 235 00:08:33,299 --> 00:08:35,759 Using our C4 on our C4 236 00:08:35,760 --> 00:08:37,168 is an insecure cipher. 237 00:08:37,169 --> 00:08:39,658 You should not use it on in this context. 238 00:08:39,659 --> 00:08:41,668 We will see that we also currently it's a 239 00:08:41,669 --> 00:08:43,259 theoretical attack, but we do have an 240 00:08:43,260 --> 00:08:45,329 attack against the way our C4 is used 241 00:08:45,330 --> 00:08:46,830 in this situation. 242 00:08:48,840 --> 00:08:50,699 Now, also, one of the more interesting 243 00:08:50,700 --> 00:08:52,859 parts is also let's say that 244 00:08:52,860 --> 00:08:55,289 we now as an attacker have the group. 245 00:08:55,290 --> 00:08:57,209 What can we do with the group? 246 00:08:57,210 --> 00:08:59,489 Because, of course, if we know that key, 247 00:08:59,490 --> 00:09:01,649 we can decrypt broadcast on 248 00:09:01,650 --> 00:09:02,549 multicast frames. 249 00:09:02,550 --> 00:09:04,349 We can inject broadcast on multicast 250 00:09:04,350 --> 00:09:06,829 frames, but can we do even more? 251 00:09:06,830 --> 00:09:09,269 And we're going to show that 252 00:09:09,270 --> 00:09:11,369 using some clever tricks, we 253 00:09:11,370 --> 00:09:13,739 can use the group to inject unicast 254 00:09:13,740 --> 00:09:15,569 IP traffic. So not just broadcast 255 00:09:15,570 --> 00:09:17,909 traffic, but also unicast traffic. 256 00:09:17,910 --> 00:09:20,309 And we will even show how we can 257 00:09:20,310 --> 00:09:22,409 decrypt nearly all Internet 258 00:09:22,410 --> 00:09:24,509 traffic of the network. 259 00:09:27,790 --> 00:09:29,349 And then at the last part of the 260 00:09:29,350 --> 00:09:31,419 presentation, I'm going 261 00:09:31,420 --> 00:09:33,849 to propose a new idea 262 00:09:33,850 --> 00:09:35,949 on how to better generate 263 00:09:35,950 --> 00:09:38,439 random numbers if you have a Wi-Fi 264 00:09:38,440 --> 00:09:39,849 device. 265 00:09:39,850 --> 00:09:41,529 But the main part of the presentation 266 00:09:41,530 --> 00:09:43,839 will be these first three steps 267 00:09:43,840 --> 00:09:46,059 on a particular predicting the 268 00:09:46,060 --> 00:09:48,249 RNC and then using it to 269 00:09:48,250 --> 00:09:50,070 decrypt traffic on Internet traffic. 270 00:09:51,280 --> 00:09:53,319 So before I get to the main content of 271 00:09:53,320 --> 00:09:55,359 the presentation, I'm going to give a 272 00:09:55,360 --> 00:09:57,639 little bit more background on how this 273 00:09:57,640 --> 00:09:59,469 group keys are used. 274 00:09:59,470 --> 00:10:01,569 So let's say we are in the following 275 00:10:01,570 --> 00:10:02,559 situation. 276 00:10:02,560 --> 00:10:04,629 We have our access point here, which 277 00:10:04,630 --> 00:10:06,729 has the group key of the network 278 00:10:06,730 --> 00:10:08,919 and which has the two session keys of 279 00:10:08,920 --> 00:10:11,349 the two connected clients here. 280 00:10:11,350 --> 00:10:13,809 And let's assume that in this situation, 281 00:10:13,810 --> 00:10:15,729 Client A wants to send a broadcast 282 00:10:15,730 --> 00:10:18,399 network over the complete network. 283 00:10:18,400 --> 00:10:20,589 Now, if Client A which 284 00:10:20,590 --> 00:10:22,869 sends this broadcast frame 285 00:10:22,870 --> 00:10:25,509 itself, then there is a problem 286 00:10:25,510 --> 00:10:28,089 because there are certain situations 287 00:10:28,090 --> 00:10:30,189 where clients are out 288 00:10:30,190 --> 00:10:31,719 out of reach of each other. 289 00:10:31,720 --> 00:10:33,819 So that's the hidden terminal problem of 290 00:10:33,820 --> 00:10:35,889 Client A would broadcast the message 291 00:10:35,890 --> 00:10:38,049 Client B would not receive it. 292 00:10:38,050 --> 00:10:40,119 So this was, of course, anticipated by 293 00:10:40,120 --> 00:10:42,579 the designers of the Wi-Fi protocol. 294 00:10:42,580 --> 00:10:44,799 So instead, what happens if 295 00:10:44,800 --> 00:10:47,049 if the client wants to send to broadcast 296 00:10:47,050 --> 00:10:49,389 free at first, sends it to 297 00:10:49,390 --> 00:10:51,489 the access point and 298 00:10:52,540 --> 00:10:54,819 it will essentially sent this frame, 299 00:10:54,820 --> 00:10:56,709 which as the immediate receiver to access 300 00:10:56,710 --> 00:10:59,199 points. However, the final destination 301 00:10:59,200 --> 00:11:00,639 is the broadcast Mac address 302 00:11:01,750 --> 00:11:03,339 because the immediate receiver is the 303 00:11:03,340 --> 00:11:04,239 access point. 304 00:11:04,240 --> 00:11:06,039 It will be encrypted using the session 305 00:11:06,040 --> 00:11:07,040 keys. 306 00:11:08,200 --> 00:11:10,059 And when the access point receives this 307 00:11:10,060 --> 00:11:11,889 frame, it will also use a set of keys to 308 00:11:11,890 --> 00:11:12,909 decrypt this frame. 309 00:11:12,910 --> 00:11:15,009 But then it will see. OK, 310 00:11:15,010 --> 00:11:16,839 the final destination is actually the 311 00:11:16,840 --> 00:11:18,909 broadcast Mac address, meaning I will 312 00:11:18,910 --> 00:11:21,639 have to forward it to all clients. 313 00:11:21,640 --> 00:11:23,739 And of course all clients are in range of 314 00:11:23,740 --> 00:11:25,959 the access point. So in this case, all 315 00:11:25,960 --> 00:11:27,849 stations will receive it. 316 00:11:27,850 --> 00:11:30,619 And when the access point sends 317 00:11:30,620 --> 00:11:32,919 the broadcast from the immediate receiver 318 00:11:32,920 --> 00:11:35,199 on the final destination are both 319 00:11:35,200 --> 00:11:37,239 the broadcast Mac address, meaning in 320 00:11:37,240 --> 00:11:39,489 this case the group is used 321 00:11:39,490 --> 00:11:41,379 to encrypt on sentence frame. 322 00:11:41,380 --> 00:11:43,509 So the important takeaway message here 323 00:11:43,510 --> 00:11:45,719 is that only the access point 324 00:11:45,720 --> 00:11:47,949 normally it will sends real group 325 00:11:47,950 --> 00:11:50,139 frames because the client will 326 00:11:50,140 --> 00:11:52,599 first forward it to the access points 327 00:11:52,600 --> 00:11:53,860 as a unicast frame. 328 00:11:55,150 --> 00:11:57,579 So that's for a quick 329 00:11:57,580 --> 00:11:58,580 introduction. 330 00:11:59,740 --> 00:12:01,479 So as I mentioned, the talk will mainly 331 00:12:01,480 --> 00:12:03,669 be about predicting the orangy 332 00:12:03,670 --> 00:12:05,739 and then decrypting all traffic. 333 00:12:05,740 --> 00:12:07,809 So let's start with 334 00:12:07,810 --> 00:12:09,579 predicting the orangy. 335 00:12:09,580 --> 00:12:12,269 So the first question is, OK, 336 00:12:12,270 --> 00:12:14,049 this is the Wi-Fi standard. 337 00:12:14,050 --> 00:12:16,359 Specify some methods on how to best 338 00:12:16,360 --> 00:12:18,649 generate these groupies. 339 00:12:18,650 --> 00:12:20,859 And it turns out that, yes, 340 00:12:20,860 --> 00:12:23,349 they do specify a method 341 00:12:23,350 --> 00:12:25,299 on in particular, they have a certain 342 00:12:25,300 --> 00:12:27,679 procedure for generating a group 343 00:12:27,680 --> 00:12:29,769 that will be used on the 344 00:12:29,770 --> 00:12:30,159 crypto. 345 00:12:30,160 --> 00:12:32,859 People call this the key hierarchy 346 00:12:32,860 --> 00:12:34,419 that is being used. 347 00:12:34,420 --> 00:12:36,849 So it's actually fairly 348 00:12:36,850 --> 00:12:38,409 straightforward. 349 00:12:38,410 --> 00:12:40,659 When your access point starts up, 350 00:12:40,660 --> 00:12:42,699 it will generate a public account or 351 00:12:42,700 --> 00:12:44,949 value. So a random counter does not start 352 00:12:44,950 --> 00:12:47,529 at zero. It can start at any value 353 00:12:47,530 --> 00:12:49,809 you want, but it's public. 354 00:12:49,810 --> 00:12:51,939 So an attacker or outsiders are 355 00:12:51,940 --> 00:12:55,329 allowed to know this variable. 356 00:12:55,330 --> 00:12:57,189 Apart from it. It also generates a 357 00:12:57,190 --> 00:12:59,319 private master key on 358 00:12:59,320 --> 00:13:00,969 this has to stay secret. 359 00:13:00,970 --> 00:13:03,429 Otherwise all your security guarantees 360 00:13:03,430 --> 00:13:04,430 are gone. 361 00:13:05,800 --> 00:13:07,869 So once you have generated 362 00:13:07,870 --> 00:13:09,939 these two fields, we simply 363 00:13:09,940 --> 00:13:12,099 take a hash of both of them on 364 00:13:12,100 --> 00:13:14,049 the output of that hash is the current 365 00:13:14,050 --> 00:13:16,299 group and the current 366 00:13:16,300 --> 00:13:18,609 group is also called to Group Temporal 367 00:13:18,610 --> 00:13:20,649 Key. And the reason they call it temporal 368 00:13:20,650 --> 00:13:22,869 is because you can refresh it every hour 369 00:13:22,870 --> 00:13:24,970 or every day or every ten minutes. 370 00:13:26,050 --> 00:13:27,819 And that's also the advantage of this 371 00:13:27,820 --> 00:13:29,409 construction, because if you want to 372 00:13:29,410 --> 00:13:31,809 generate a grouping, it's very simple. 373 00:13:31,810 --> 00:13:33,879 You simply increase the public counter 374 00:13:33,880 --> 00:13:36,159 by one. You recalculate this 375 00:13:36,160 --> 00:13:38,349 hash value and then you get 376 00:13:38,350 --> 00:13:39,729 a new group. 377 00:13:39,730 --> 00:13:41,889 So this design seems 378 00:13:41,890 --> 00:13:44,049 very nice because if you want to generate 379 00:13:44,050 --> 00:13:46,059 a new group, you simply increase this 380 00:13:46,060 --> 00:13:48,159 public counter by one and you calculate a 381 00:13:48,160 --> 00:13:49,160 new hash. 382 00:13:50,170 --> 00:13:52,569 Unfortunately, this design is actually 383 00:13:52,570 --> 00:13:53,570 quite bad. 384 00:13:54,640 --> 00:13:55,689 Why is that? 385 00:13:55,690 --> 00:13:57,759 That is because these two values 386 00:13:57,760 --> 00:13:59,859 are only randomly sampled 387 00:13:59,860 --> 00:14:02,409 when your device boots and new entropy 388 00:14:02,410 --> 00:14:04,509 is never introduced into 389 00:14:04,510 --> 00:14:05,499 the system. 390 00:14:05,500 --> 00:14:08,309 So if for some reason and a decorator 391 00:14:08,310 --> 00:14:10,509 compromises the scheme and knows 392 00:14:10,510 --> 00:14:12,639 it, he can predict all future keys. 393 00:14:12,640 --> 00:14:14,889 Or in our case, if the random number 394 00:14:14,890 --> 00:14:17,349 generator is bad, we can probably 395 00:14:17,350 --> 00:14:19,119 predict all future keys that are 396 00:14:19,120 --> 00:14:20,120 generated. 397 00:14:20,980 --> 00:14:23,619 So this is a bad design 398 00:14:23,620 --> 00:14:25,299 and should be avoided. 399 00:14:25,300 --> 00:14:26,679 Unfortunately, a. 400 00:14:26,680 --> 00:14:28,749 It is officially specified this way 401 00:14:28,750 --> 00:14:30,940 and the standard so in principle, 402 00:14:32,230 --> 00:14:34,149 well, the standard recommends everyone to 403 00:14:34,150 --> 00:14:36,429 use this key hierarchy, this procedure. 404 00:14:37,540 --> 00:14:39,819 So, OK, now we know that if we can 405 00:14:39,820 --> 00:14:41,889 predict these two values, 406 00:14:41,890 --> 00:14:43,689 we can derive our group. 407 00:14:43,690 --> 00:14:45,789 So the next question is, how are 408 00:14:45,790 --> 00:14:48,109 these random numbers generated? 409 00:14:48,110 --> 00:14:50,379 And again, the Wi-Fi standard 410 00:14:50,380 --> 00:14:52,479 provides us with an answer because 411 00:14:52,480 --> 00:14:54,549 it suggests an example, 412 00:14:54,550 --> 00:14:56,439 random number generator. 413 00:14:56,440 --> 00:14:58,689 And if you read the standard, it 414 00:14:58,690 --> 00:15:00,639 actually sounds quite promising because 415 00:15:00,640 --> 00:15:03,099 it says the orangy 416 00:15:03,100 --> 00:15:05,289 that we use should generate 417 00:15:05,290 --> 00:15:07,479 a cryptographic quality randomness. 418 00:15:07,480 --> 00:15:09,849 And to show you the quotes 419 00:15:09,850 --> 00:15:10,850 and detail, 420 00:15:12,610 --> 00:15:14,799 a station must be able to generate 421 00:15:14,800 --> 00:15:17,169 cryptographic quality random numbers. 422 00:15:17,170 --> 00:15:19,029 And you can look at the appendix at 423 00:15:19,030 --> 00:15:21,339 Section five to see how 424 00:15:21,340 --> 00:15:22,509 you can achieve this. 425 00:15:22,510 --> 00:15:25,329 So this sounds very promising 426 00:15:25,330 --> 00:15:27,489 until you actually go to 427 00:15:27,490 --> 00:15:29,739 the appendix and there it says, 428 00:15:29,740 --> 00:15:31,749 well, wait a minute, what we're going to 429 00:15:31,750 --> 00:15:34,089 so show is just an example 430 00:15:34,090 --> 00:15:35,019 solution. 431 00:15:35,020 --> 00:15:37,319 Ideally, you should extend 432 00:15:37,320 --> 00:15:38,320 it yourself. 433 00:15:39,520 --> 00:15:42,039 And of course, that's not really 434 00:15:42,040 --> 00:15:44,469 that this is a strange situation because 435 00:15:44,470 --> 00:15:46,959 the standard itself, it says this arangi 436 00:15:46,960 --> 00:15:48,699 and the appendix is secure. 437 00:15:48,700 --> 00:15:50,499 But if you actually read the appendix, it 438 00:15:50,500 --> 00:15:52,989 says this is just an example solution. 439 00:15:52,990 --> 00:15:55,239 It may not be that secure after all. 440 00:15:55,240 --> 00:15:57,279 So we have an inconsistency in the 441 00:15:57,280 --> 00:15:58,419 standard here. 442 00:15:58,420 --> 00:16:00,699 And just to come back to 443 00:16:00,700 --> 00:16:03,579 the text that is shown in the appendix, 444 00:16:03,580 --> 00:16:05,979 it says that, OK, you probably 445 00:16:05,980 --> 00:16:07,929 should combine it with other 446 00:16:07,930 --> 00:16:09,999 recommendations on how to generate random 447 00:16:10,000 --> 00:16:13,299 numbers. This is expository only. 448 00:16:13,300 --> 00:16:15,769 Again, you should probably improve 449 00:16:15,770 --> 00:16:18,159 this, which is very strange 450 00:16:18,160 --> 00:16:19,929 to see this kind of language in a 451 00:16:19,930 --> 00:16:21,189 standard. 452 00:16:21,190 --> 00:16:24,009 So we basically have an inconsistent, 453 00:16:24,010 --> 00:16:26,079 inconsistent description here. 454 00:16:26,080 --> 00:16:27,080 It says that 455 00:16:28,780 --> 00:16:30,309 it should be secure. Then it says it's 456 00:16:30,310 --> 00:16:32,259 not really secure. So the question is, 457 00:16:32,260 --> 00:16:34,539 how secure really is this random 458 00:16:34,540 --> 00:16:35,889 number generator on? 459 00:16:35,890 --> 00:16:37,989 The next question is how many platforms 460 00:16:37,990 --> 00:16:39,099 implement that? 461 00:16:39,100 --> 00:16:41,229 So let's look in detail at how 462 00:16:41,230 --> 00:16:43,119 the random number generator is 463 00:16:43,120 --> 00:16:44,120 implemented. 464 00:16:44,920 --> 00:16:47,499 And here we see that the standard 465 00:16:48,760 --> 00:16:50,979 basically defines a 466 00:16:50,980 --> 00:16:53,799 function, which is the orangy. 467 00:16:53,800 --> 00:16:55,959 And first of all, it's a statelets 468 00:16:55,960 --> 00:16:57,669 function. I'll come back in a minute. 469 00:16:57,670 --> 00:16:59,739 Why that? It's a bad idea. 470 00:16:59,740 --> 00:17:01,989 But first and for all, it has a very 471 00:17:01,990 --> 00:17:04,179 vague description, even if they 472 00:17:04,180 --> 00:17:05,949 only meant that this to be like an 473 00:17:05,950 --> 00:17:08,139 example solution to get people on 474 00:17:08,140 --> 00:17:10,328 the way. Because if you look at the code, 475 00:17:10,329 --> 00:17:12,429 there is a main Y loop here, 476 00:17:12,430 --> 00:17:14,529 a main loop, and it simply says, 477 00:17:14,530 --> 00:17:17,139 repeat this algorithm until it's 478 00:17:17,140 --> 00:17:18,140 random enough. 479 00:17:22,660 --> 00:17:24,879 They don't specify what this means. 480 00:17:24,880 --> 00:17:27,279 So that's very strange 481 00:17:27,280 --> 00:17:28,299 and suspicious, 482 00:17:29,650 --> 00:17:31,749 a bit suspicious as well as also at the 483 00:17:31,750 --> 00:17:33,399 end of the algorithm, at the end of the 484 00:17:33,400 --> 00:17:34,400 loop. 485 00:17:34,900 --> 00:17:36,729 So during certain parts of the loop, they 486 00:17:36,730 --> 00:17:38,889 say if the time is set to as if 487 00:17:38,890 --> 00:17:40,929 the time is not available, you can simply 488 00:17:40,930 --> 00:17:41,930 set it to zero. 489 00:17:43,900 --> 00:17:46,539 So this this line might not 490 00:17:46,540 --> 00:17:48,609 be that bad if they include something 491 00:17:48,610 --> 00:17:50,889 like if you set the time to zero, maybe 492 00:17:50,890 --> 00:17:52,629 you should include should do more 493 00:17:52,630 --> 00:17:53,979 iterations of the main loop. 494 00:17:53,980 --> 00:17:56,019 But they simply say, oh, well, if it's 495 00:17:56,020 --> 00:17:57,839 not available, you know, just skip it. 496 00:17:58,990 --> 00:17:59,990 So. 497 00:18:00,500 --> 00:18:02,659 Like I mentioned, the standard is 498 00:18:02,660 --> 00:18:04,849 a bit hard to interpret because 499 00:18:04,850 --> 00:18:07,219 they say it's an example solution, 500 00:18:07,220 --> 00:18:10,069 but in other parts they say it's 501 00:18:10,070 --> 00:18:11,140 supposed to be good. 502 00:18:12,230 --> 00:18:14,359 But even if they only meant it 503 00:18:14,360 --> 00:18:16,639 as an example for 504 00:18:16,640 --> 00:18:18,559 the vendors, this description is still 505 00:18:18,560 --> 00:18:19,730 just too vague. 506 00:18:21,500 --> 00:18:23,809 Now, to come back to this status part 507 00:18:23,810 --> 00:18:26,179 here, the random 508 00:18:26,180 --> 00:18:28,459 number generator is executed on the math, 509 00:18:28,460 --> 00:18:30,679 on only when this function is being 510 00:18:30,680 --> 00:18:31,909 called as random. 511 00:18:31,910 --> 00:18:33,439 This collected. 512 00:18:33,440 --> 00:18:35,959 Again, this is a very strange design, 513 00:18:35,960 --> 00:18:38,089 because if you have a proper orangy, for 514 00:18:38,090 --> 00:18:40,339 example, the one in OpenBSD or 515 00:18:40,340 --> 00:18:42,499 the one in Linux or the one in 516 00:18:42,500 --> 00:18:45,079 any decent design, basically 517 00:18:45,080 --> 00:18:47,599 there entropy is constantly collected 518 00:18:47,600 --> 00:18:48,349 in the background. 519 00:18:48,350 --> 00:18:50,419 For example, you have your timing of 520 00:18:50,420 --> 00:18:52,609 interrupts, timing of packets, 521 00:18:52,610 --> 00:18:54,799 you have clocks. Q and so on are 522 00:18:54,800 --> 00:18:56,719 normally all this randomness and 523 00:18:56,720 --> 00:18:59,419 collected in a so-called entropy pool. 524 00:18:59,420 --> 00:19:01,039 And then if you need randomness, you can 525 00:19:01,040 --> 00:19:03,659 extract a random number from this entropy 526 00:19:03,660 --> 00:19:05,989 pool, for example, using a hash or any 527 00:19:05,990 --> 00:19:07,639 other construct. 528 00:19:07,640 --> 00:19:08,929 But the fact that this function is 529 00:19:08,930 --> 00:19:11,209 executed on demand 530 00:19:11,210 --> 00:19:13,579 is also a very bad sign. 531 00:19:13,580 --> 00:19:15,859 So all that is 532 00:19:15,860 --> 00:19:17,629 not that promising. 533 00:19:17,630 --> 00:19:19,999 And if we then look at 534 00:19:20,000 --> 00:19:22,429 the actual events where it extract 535 00:19:22,430 --> 00:19:24,589 randomness from, we can see that is 536 00:19:24,590 --> 00:19:26,689 mainly based on the timestamp 537 00:19:26,690 --> 00:19:29,029 of that frames are arrived and 538 00:19:29,030 --> 00:19:31,549 also on Clock Jetter. 539 00:19:31,550 --> 00:19:34,159 So let's look at these two sources 540 00:19:34,160 --> 00:19:35,089 in detail. 541 00:19:35,090 --> 00:19:36,980 We have our frame arrival times. 542 00:19:38,000 --> 00:19:39,889 So if you're Rotaru would be connected to 543 00:19:39,890 --> 00:19:42,169 an Internet cable and there would be 544 00:19:42,170 --> 00:19:43,789 a sufficient amount of traffic, then you 545 00:19:43,790 --> 00:19:45,559 could simply collect this based on 546 00:19:45,560 --> 00:19:46,879 Internet traffic. 547 00:19:46,880 --> 00:19:49,039 However, you don't 548 00:19:49,040 --> 00:19:50,899 always have the guarantee that there is 549 00:19:50,900 --> 00:19:52,669 sufficient traffic available. 550 00:19:52,670 --> 00:19:53,670 And 551 00:19:55,370 --> 00:19:57,439 the standardization committee, the people 552 00:19:57,440 --> 00:19:59,599 realize this like there may not be 553 00:19:59,600 --> 00:20:01,519 that much traffic available. 554 00:20:01,520 --> 00:20:03,589 So what they said this now, if 555 00:20:03,590 --> 00:20:05,779 there is not that much traffic, simply 556 00:20:05,780 --> 00:20:08,179 wait until a client wants to connect 557 00:20:08,180 --> 00:20:09,829 and then send a few messages of the 558 00:20:09,830 --> 00:20:11,749 handshake. Then about the handshake, 559 00:20:11,750 --> 00:20:13,609 restart the handshake, then abort the 560 00:20:13,610 --> 00:20:15,799 handshake, restart the handshake until 561 00:20:15,800 --> 00:20:17,980 you captured enough frames. 562 00:20:19,820 --> 00:20:22,009 So this, first of all, would be very 563 00:20:22,010 --> 00:20:23,449 time consuming. 564 00:20:23,450 --> 00:20:25,609 The second bigger problem is if you 565 00:20:25,610 --> 00:20:27,409 are a client and you are constantly 566 00:20:27,410 --> 00:20:29,299 trying to connect with a network, but it 567 00:20:29,300 --> 00:20:31,369 fails a few times, then your device 568 00:20:31,370 --> 00:20:33,319 will simply blacklist the access point 569 00:20:33,320 --> 00:20:34,320 and this will not work. 570 00:20:35,510 --> 00:20:37,219 So the fact that they even simply 571 00:20:37,220 --> 00:20:39,529 suggested using this is my 572 00:20:39,530 --> 00:20:40,640 opinion, absurd. 573 00:20:42,470 --> 00:20:44,749 So the second source is the 574 00:20:44,750 --> 00:20:46,109 clock Getaround Dreft. 575 00:20:47,210 --> 00:20:48,409 So if you have a clock and an 576 00:20:48,410 --> 00:20:50,119 implementation, it is never completely 577 00:20:50,120 --> 00:20:52,339 accurate. There is also a small 578 00:20:52,340 --> 00:20:54,199 amount that you can't predict as an 579 00:20:54,200 --> 00:20:55,369 attacker. 580 00:20:55,370 --> 00:20:57,019 The problem here is that they don't 581 00:20:57,020 --> 00:20:59,089 specify a minimum resolution 582 00:20:59,090 --> 00:21:01,189 that the clock should have so a 583 00:21:01,190 --> 00:21:03,289 vendor can use any clock at 584 00:21:03,290 --> 00:21:04,909 once, even one with a very low 585 00:21:04,910 --> 00:21:07,009 resolution, meaning only a very 586 00:21:07,010 --> 00:21:09,319 low amount of entropy is 587 00:21:09,320 --> 00:21:11,389 collected. And of course, that's quite 588 00:21:11,390 --> 00:21:13,549 bad. So after I saw 589 00:21:13,550 --> 00:21:15,889 this, I thought to myself, OK, 590 00:21:15,890 --> 00:21:18,799 this is just basically 591 00:21:18,800 --> 00:21:20,959 a big mistake of the standardization 592 00:21:20,960 --> 00:21:23,419 people. Surely everyone realized 593 00:21:23,420 --> 00:21:24,319 that this was bad. 594 00:21:24,320 --> 00:21:25,999 Aren't they implemented something big, 595 00:21:26,000 --> 00:21:27,000 something better? 596 00:21:28,040 --> 00:21:30,319 But when I actually looked at codes, 597 00:21:31,910 --> 00:21:33,829 so, yeah, this is really like, what the 598 00:21:33,830 --> 00:21:34,830 hell are they doing? 599 00:21:35,900 --> 00:21:38,239 So if you look at vendors, 600 00:21:38,240 --> 00:21:40,609 we have, for example, mediatheque, 601 00:21:40,610 --> 00:21:43,669 it was used to be called also Rawling. 602 00:21:43,670 --> 00:21:45,709 They implement this random number 603 00:21:45,710 --> 00:21:47,789 generator almost 604 00:21:47,790 --> 00:21:50,269 as specified with a few changes. 605 00:21:50,270 --> 00:21:52,399 And those changes actually 606 00:21:52,400 --> 00:21:53,720 weaken it a bit more. 607 00:21:56,810 --> 00:21:58,579 They also did one good part, by the way. 608 00:21:58,580 --> 00:22:00,559 I'll come back to that in the minutes. 609 00:22:00,560 --> 00:22:01,940 Then there's also Broadcom. 610 00:22:02,990 --> 00:22:04,759 The random number generator debuts 611 00:22:04,760 --> 00:22:06,829 depends on the operating system 612 00:22:06,830 --> 00:22:08,199 that is being used. 613 00:22:08,200 --> 00:22:11,269 And then there is also open firmware, 614 00:22:11,270 --> 00:22:12,769 which is a good example of an embedded 615 00:22:12,770 --> 00:22:15,019 system on there as host APD, which 616 00:22:15,020 --> 00:22:16,939 is the open source implementation of 617 00:22:16,940 --> 00:22:18,349 Linux. 618 00:22:18,350 --> 00:22:20,569 And you can see they do it properly. 619 00:22:23,240 --> 00:22:25,369 So we did a very rough estimate of 620 00:22:25,370 --> 00:22:27,589 how many networks are 621 00:22:27,590 --> 00:22:29,779 run using this mediatheque or 622 00:22:29,780 --> 00:22:31,879 Broadcom implementation. 623 00:22:31,880 --> 00:22:34,339 So this was just using a very quick 624 00:22:34,340 --> 00:22:37,009 word drive around my city. 625 00:22:37,010 --> 00:22:39,439 And I determined whether the VISUS 626 00:22:39,440 --> 00:22:41,719 using mediatheque or Broadcom based 627 00:22:41,720 --> 00:22:44,269 on the fingerprint of the beacon. 628 00:22:44,270 --> 00:22:45,589 How that works is explained in a 629 00:22:45,590 --> 00:22:46,729 different paper. 630 00:22:46,730 --> 00:22:49,039 But essentially I did a very, 631 00:22:49,040 --> 00:22:50,269 very rough estimate. 632 00:22:50,270 --> 00:22:52,489 And they at most, 633 00:22:52,490 --> 00:22:54,709 let's say 25 percent 634 00:22:54,710 --> 00:22:57,259 of networks could be vulnerable to this. 635 00:22:57,260 --> 00:22:59,569 I would say maybe five or 10 percent 636 00:22:59,570 --> 00:23:01,779 could. Attacked using attacks 637 00:23:01,780 --> 00:23:03,369 similar to the one we're going to present 638 00:23:04,600 --> 00:23:06,849 just to show that these are 639 00:23:06,850 --> 00:23:08,679 a bit popular and you might be able to 640 00:23:08,680 --> 00:23:10,599 use this and practice. 641 00:23:12,540 --> 00:23:14,669 But anyway, let's look at the first 642 00:23:14,670 --> 00:23:17,729 implementation, the one of mediatheque. 643 00:23:17,730 --> 00:23:19,859 So what did they do? 644 00:23:19,860 --> 00:23:22,259 Well, first of all, they implemented 645 00:23:22,260 --> 00:23:24,329 the key hierarchy sort of 646 00:23:24,330 --> 00:23:26,669 procedure on how to generate these GIs 647 00:23:26,670 --> 00:23:29,279 as proposed by the standards. 648 00:23:29,280 --> 00:23:31,139 So just to recap, this is this 649 00:23:31,140 --> 00:23:32,969 construction where you generate two 650 00:23:32,970 --> 00:23:35,339 variables, one which is secret, 651 00:23:35,340 --> 00:23:37,439 the other which can be public, 652 00:23:37,440 --> 00:23:39,629 then a hash is taken and the output is 653 00:23:39,630 --> 00:23:40,630 shown. 654 00:23:41,520 --> 00:23:43,679 They do improve this 655 00:23:43,680 --> 00:23:45,209 slightly, actually. 656 00:23:45,210 --> 00:23:47,759 So they do one thing that is good, 657 00:23:47,760 --> 00:23:49,769 namely, instead of when they want to 658 00:23:49,770 --> 00:23:52,079 generate a new group, instead of 659 00:23:52,080 --> 00:23:54,509 simply increasing the counter by one, 660 00:23:54,510 --> 00:23:56,549 they actually constantly generate a 661 00:23:56,550 --> 00:23:58,469 completely new random value for the 662 00:23:58,470 --> 00:24:00,509 counter. And that's that's actually a 663 00:24:00,510 --> 00:24:02,399 very good decision because then you are 664 00:24:02,400 --> 00:24:04,649 introducing new entropy every time 665 00:24:04,650 --> 00:24:06,599 you generate a group. 666 00:24:06,600 --> 00:24:08,879 However, this group, Moustaki, that 667 00:24:08,880 --> 00:24:11,909 one is only sampled at time. 668 00:24:11,910 --> 00:24:13,989 Um, OK, 669 00:24:15,330 --> 00:24:17,399 so we now know how their 670 00:24:17,400 --> 00:24:19,349 construction works. 671 00:24:19,350 --> 00:24:21,149 Now the question is, how do they 672 00:24:21,150 --> 00:24:23,339 implement this random number generator 673 00:24:23,340 --> 00:24:25,829 and can we then try to attack it? 674 00:24:25,830 --> 00:24:28,019 Well, this is the bad part of their 675 00:24:28,020 --> 00:24:30,359 design. They only use clock 676 00:24:30,360 --> 00:24:32,609 jitter to extract 677 00:24:32,610 --> 00:24:34,739 randomness, to collect entropy. 678 00:24:34,740 --> 00:24:36,599 And particular, it uses the so-called 679 00:24:36,600 --> 00:24:38,669 Jeffy's counter of the Linux 680 00:24:38,670 --> 00:24:40,739 kernel. So the Jeffy's counter 681 00:24:40,740 --> 00:24:43,079 is something that is increased every 682 00:24:43,080 --> 00:24:45,839 tick, but not every processor tick, 683 00:24:45,840 --> 00:24:47,339 but every logical tick. 684 00:24:47,340 --> 00:24:50,189 And I'll come back to that in a minute. 685 00:24:50,190 --> 00:24:51,190 So. 686 00:24:51,680 --> 00:24:54,829 This orangy is likely quite bad. 687 00:24:54,830 --> 00:24:57,109 This is good for us because at least for 688 00:24:57,110 --> 00:24:59,179 us as attackers, because we 689 00:24:59,180 --> 00:25:01,729 simply have to protect the group, Masaaki 690 00:25:01,730 --> 00:25:03,739 and this public counter, which is also 691 00:25:03,740 --> 00:25:05,839 count denounce the group 692 00:25:05,840 --> 00:25:07,069 Nons. 693 00:25:07,070 --> 00:25:09,139 And if we can predict both of them, 694 00:25:09,140 --> 00:25:11,140 we can derive the group key. 695 00:25:12,500 --> 00:25:14,659 So let's try to attack this 696 00:25:14,660 --> 00:25:15,649 orangy. 697 00:25:15,650 --> 00:25:18,259 As I mentioned, it uses this Jeffy's 698 00:25:18,260 --> 00:25:19,909 as the counter. 699 00:25:19,910 --> 00:25:22,279 The problem is these Jeffy's have at best 700 00:25:22,280 --> 00:25:24,709 millisecond accuracy, which is 701 00:25:24,710 --> 00:25:25,730 rather low. 702 00:25:27,110 --> 00:25:28,579 In fact, it's really low. 703 00:25:29,870 --> 00:25:32,089 So this means in practice that the 704 00:25:32,090 --> 00:25:34,399 JMC so this secret 705 00:25:34,400 --> 00:25:36,529 key which is generated at but 706 00:25:37,610 --> 00:25:40,219 generally it always uses the same 707 00:25:40,220 --> 00:25:42,229 Jeffy's value. So to claim the same 708 00:25:42,230 --> 00:25:43,159 values. 709 00:25:43,160 --> 00:25:45,529 So that means in practice for 710 00:25:45,530 --> 00:25:47,869 gym K, there are say around 711 00:25:47,870 --> 00:25:50,599 200 to 300 possible values, 712 00:25:50,600 --> 00:25:51,760 at least if you have it. 713 00:25:52,790 --> 00:25:54,649 I tested this on my device on for a 714 00:25:54,650 --> 00:25:57,199 specific device, on specific firmware 715 00:25:57,200 --> 00:25:58,639 version. 716 00:25:58,640 --> 00:25:59,839 Then you have a limited set of 717 00:25:59,840 --> 00:26:00,949 possibilities. 718 00:26:00,950 --> 00:26:02,329 Of course, if you run a different 719 00:26:02,330 --> 00:26:05,179 firmware version, then 720 00:26:05,180 --> 00:26:07,069 some other things might happen during the 721 00:26:07,070 --> 00:26:09,139 boot process influencing the 722 00:26:09,140 --> 00:26:11,929 time when these jiefu chip values 723 00:26:11,930 --> 00:26:13,099 are collected. 724 00:26:13,100 --> 00:26:14,689 But if you know the implementation, your 725 00:26:14,690 --> 00:26:16,879 attacker attacking you have a very 726 00:26:16,880 --> 00:26:19,160 limited set of values. 727 00:26:20,450 --> 00:26:22,219 Then the second part is we have to 728 00:26:22,220 --> 00:26:23,990 predict Jennens value 729 00:26:26,300 --> 00:26:27,799 on most routers. 730 00:26:27,800 --> 00:26:29,979 It is the group we 731 00:26:29,980 --> 00:26:32,089 regenerate at every hour, meaning this 732 00:26:32,090 --> 00:26:34,219 Jennens value is also sampled every 733 00:26:34,220 --> 00:26:36,769 hour. So in order to predict this value, 734 00:26:36,770 --> 00:26:38,989 we need to know the uptime of the router 735 00:26:38,990 --> 00:26:41,239 to predict the range of possible Jeffy's 736 00:26:41,240 --> 00:26:42,560 values that we're used 737 00:26:44,060 --> 00:26:45,049 to. How do we do? 738 00:26:45,050 --> 00:26:46,789 How do we determine the uptime of the 739 00:26:46,790 --> 00:26:48,439 router? Well, it's quite simple. 740 00:26:48,440 --> 00:26:50,599 The uptime is lit and the beacons 741 00:26:50,600 --> 00:26:52,249 of most routers. 742 00:26:52,250 --> 00:26:54,769 So we simply have to sniff beacons 743 00:26:54,770 --> 00:26:56,569 that we can estimate the uptime of the 744 00:26:56,570 --> 00:26:58,819 router and then we can estimate the time 745 00:26:58,820 --> 00:27:01,410 of when this jennens was generated. 746 00:27:02,660 --> 00:27:04,789 So basically, what do we have to do 747 00:27:04,790 --> 00:27:06,589 for a successful attack? 748 00:27:06,590 --> 00:27:08,689 We need to capture one encrypted 749 00:27:08,690 --> 00:27:10,520 broadcast or multicast message. 750 00:27:11,570 --> 00:27:13,699 We have to capture also a few beacons 751 00:27:13,700 --> 00:27:16,219 to estimate the uptime and then we can 752 00:27:16,220 --> 00:27:18,619 do a search through a hole 753 00:27:18,620 --> 00:27:20,000 through the whole key space. 754 00:27:21,470 --> 00:27:23,809 We tried this against our own 755 00:27:23,810 --> 00:27:25,939 router. So that's this 756 00:27:25,940 --> 00:27:27,919 one here. 757 00:27:27,920 --> 00:27:30,739 We noticed well, we implemented 758 00:27:30,740 --> 00:27:33,109 a program on the GPU in particular 759 00:27:33,110 --> 00:27:35,239 on open call to make sure we 760 00:27:35,240 --> 00:27:37,429 can do this in a timely manner. 761 00:27:37,430 --> 00:27:39,649 And we found that using 762 00:27:39,650 --> 00:27:42,049 the GPU in my laptop, which is just 763 00:27:42,050 --> 00:27:44,629 standard GPU, you can even 764 00:27:44,630 --> 00:27:46,699 get better use or even multiple 765 00:27:46,700 --> 00:27:50,029 ones. But even just on my normal laptop, 766 00:27:50,030 --> 00:27:52,249 I can crack the case within three to four 767 00:27:52,250 --> 00:27:54,319 minutes. And this. 768 00:28:01,460 --> 00:28:03,559 Thank you. So this is assuming 769 00:28:03,560 --> 00:28:05,689 the roads are also as uptime of one 770 00:28:05,690 --> 00:28:07,939 year, if the uptime is 771 00:28:07,940 --> 00:28:09,979 around one year, then there is also a lot 772 00:28:09,980 --> 00:28:12,409 of klukowski, meaning predicting the gene 773 00:28:12,410 --> 00:28:13,309 is harder. 774 00:28:13,310 --> 00:28:15,409 So if I'm going to demo the attack 775 00:28:15,410 --> 00:28:17,599 in a few minutes, then 776 00:28:17,600 --> 00:28:19,879 I know that the uptime was very low, 777 00:28:19,880 --> 00:28:22,069 meaning I can reduce this number even 778 00:28:22,070 --> 00:28:24,259 further because there hasn't been 779 00:28:24,260 --> 00:28:26,359 that much klukowski meaning predicting it 780 00:28:26,360 --> 00:28:27,469 will be easier. 781 00:28:27,470 --> 00:28:29,749 So it is in a sense, is also 782 00:28:29,750 --> 00:28:31,669 a worst case estimates. 783 00:28:31,670 --> 00:28:33,619 However, I do have to note that this is 784 00:28:33,620 --> 00:28:35,749 only if you are attacking one specific 785 00:28:35,750 --> 00:28:37,879 device, if you know which device you are 786 00:28:37,880 --> 00:28:39,979 attacking, let's say you don't know the 787 00:28:39,980 --> 00:28:42,079 exact firmware that is running, then you 788 00:28:42,080 --> 00:28:44,599 have to perform a bigger search. 789 00:28:45,710 --> 00:28:47,479 So the end result here is that you get 790 00:28:47,480 --> 00:28:49,999 both the master key and the current 791 00:28:50,000 --> 00:28:51,199 group. 792 00:28:51,200 --> 00:28:53,359 So I planned a demo 793 00:28:53,360 --> 00:28:56,029 here. Now, wi fi demos are always 794 00:28:56,030 --> 00:28:58,399 very risky, especially 795 00:28:58,400 --> 00:28:59,720 in a situation like this. 796 00:29:00,950 --> 00:29:03,109 So fingers crossed. 797 00:29:03,110 --> 00:29:05,599 So let me first 798 00:29:05,600 --> 00:29:07,969 try to mirror the screen. 799 00:29:07,970 --> 00:29:10,259 That's what we don't already fail here. 800 00:29:10,260 --> 00:29:11,260 OK. 801 00:29:14,260 --> 00:29:16,479 So here 802 00:29:16,480 --> 00:29:18,629 I have a Wi-Fi device that is running and 803 00:29:18,630 --> 00:29:20,859 the monitor remote, and they 804 00:29:20,860 --> 00:29:23,529 have a script that will capture 805 00:29:23,530 --> 00:29:25,599 the frames sent by my 806 00:29:25,600 --> 00:29:27,759 router. So I already put 807 00:29:27,760 --> 00:29:28,659 it in monitor mode. 808 00:29:28,660 --> 00:29:30,939 So that is simply this script just 809 00:29:30,940 --> 00:29:33,129 executes some commands to put 810 00:29:33,130 --> 00:29:34,599 it and monitor remote. 811 00:29:34,600 --> 00:29:36,639 And I'm now going to capture packets that 812 00:29:36,640 --> 00:29:38,080 are sent by my router. 813 00:29:39,580 --> 00:29:41,409 And they made a Python script for that. 814 00:29:43,500 --> 00:29:45,869 So let's execute that and 815 00:29:45,870 --> 00:29:47,910 capture packets from my router. 816 00:29:51,070 --> 00:29:52,509 As you can see, it's now trying to 817 00:29:52,510 --> 00:29:54,729 capture packet's, but nothing is received 818 00:29:54,730 --> 00:29:56,979 yet that is normal because the router 819 00:29:56,980 --> 00:29:58,569 is not yet started. 820 00:29:58,570 --> 00:30:01,209 So let's put it on. 821 00:30:01,210 --> 00:30:02,919 This was planned, by the way, to show you 822 00:30:02,920 --> 00:30:03,920 it's real. 823 00:30:05,260 --> 00:30:07,329 So now the router is booting up in 824 00:30:07,330 --> 00:30:08,319 a few seconds. 825 00:30:08,320 --> 00:30:10,389 It should be receiving a 826 00:30:10,390 --> 00:30:12,759 beacon from which it can derive 827 00:30:12,760 --> 00:30:14,979 the uptime of the router. 828 00:30:14,980 --> 00:30:16,179 You can see. There we go. 829 00:30:16,180 --> 00:30:18,309 We got a beacon and now it's waiting 830 00:30:18,310 --> 00:30:21,339 for an encrypted broadcast packet. 831 00:30:21,340 --> 00:30:23,439 Now, this is one small 832 00:30:23,440 --> 00:30:24,849 limitation of the attack 833 00:30:26,260 --> 00:30:27,260 up. 834 00:30:27,670 --> 00:30:29,979 As you can see, it was waiting until my 835 00:30:29,980 --> 00:30:32,049 laptop connected to this network 836 00:30:32,050 --> 00:30:34,269 because if no one is connected to 837 00:30:34,270 --> 00:30:36,459 the network, then there is, 838 00:30:36,460 --> 00:30:38,139 of course, no traffic. 839 00:30:38,140 --> 00:30:40,449 So there must be at least one client or 840 00:30:40,450 --> 00:30:42,579 for some reason, the router has to send 841 00:30:42,580 --> 00:30:44,679 one broadcast frame that 842 00:30:44,680 --> 00:30:46,809 is encrypted using the broadcast scheme 843 00:30:46,810 --> 00:30:48,879 because otherwise there is nothing 844 00:30:48,880 --> 00:30:50,579 to crack. We don't have any data. 845 00:30:51,580 --> 00:30:53,859 So in this case, we captured 846 00:30:53,860 --> 00:30:55,989 this frame. So let's 847 00:30:55,990 --> 00:30:57,760 try to open this capture file 848 00:30:58,960 --> 00:31:01,299 so you can see here we captured 849 00:31:01,300 --> 00:31:03,489 a lot of beacon frames and this 850 00:31:03,490 --> 00:31:05,440 beacon frame has a field here, 851 00:31:07,360 --> 00:31:09,549 which is called the timestamp 852 00:31:09,550 --> 00:31:09,699 on. 853 00:31:09,700 --> 00:31:11,619 From this, we can determine the uptime. 854 00:31:11,620 --> 00:31:13,779 So here you can see it here it's very 855 00:31:13,780 --> 00:31:15,939 close to 856 00:31:15,940 --> 00:31:17,109 zero. 857 00:31:17,110 --> 00:31:19,239 And every time it increases on from this, 858 00:31:19,240 --> 00:31:20,679 we can determine the uptime of the 859 00:31:20,680 --> 00:31:21,680 router. 860 00:31:22,370 --> 00:31:24,469 There you go on 861 00:31:24,470 --> 00:31:26,269 that, the very end of this capture, we 862 00:31:26,270 --> 00:31:28,849 have this broadcast packet, 863 00:31:28,850 --> 00:31:31,579 which we want to decrypt, 864 00:31:31,580 --> 00:31:33,559 so let's try that. 865 00:31:33,560 --> 00:31:35,749 So as I mentioned, this works on 866 00:31:35,750 --> 00:31:36,649 the GPU. 867 00:31:36,650 --> 00:31:38,929 So first I have to type Opteron 868 00:31:38,930 --> 00:31:41,239 to enable my Jeep while 869 00:31:41,240 --> 00:31:43,219 executing the next commands. 870 00:31:43,220 --> 00:31:45,649 So I simply have a script here. 871 00:31:45,650 --> 00:31:47,239 I'm attacking the mediatheque 872 00:31:47,240 --> 00:31:49,339 implementation and I'm using 873 00:31:49,340 --> 00:31:50,960 the capture I just made. 874 00:31:53,160 --> 00:31:55,289 So now it's part of this 875 00:31:55,290 --> 00:31:57,749 file here, at least all the networks 876 00:31:57,750 --> 00:32:00,179 that we captured in this case because 877 00:32:00,180 --> 00:32:01,829 we are in a crowded room, I made sure 878 00:32:01,830 --> 00:32:03,899 that I only capture frames 879 00:32:03,900 --> 00:32:05,099 from my network 880 00:32:06,540 --> 00:32:08,609 to try to make sure that the demo indeed 881 00:32:08,610 --> 00:32:10,889 works. And you can see now it's 882 00:32:10,890 --> 00:32:13,109 trying to predict the group master 883 00:32:13,110 --> 00:32:15,419 key under this estimate that the 884 00:32:15,420 --> 00:32:17,519 values that were used there, where 885 00:32:17,520 --> 00:32:19,919 around this number on the Jeffy's values 886 00:32:19,920 --> 00:32:22,039 that were used for the Junon 887 00:32:23,160 --> 00:32:25,259 that's estimated around this value. 888 00:32:25,260 --> 00:32:27,299 Now, you may be wondering, why is this 889 00:32:27,300 --> 00:32:29,429 Jeffy's value so high? 890 00:32:29,430 --> 00:32:31,829 Doesn't it start at zero? 891 00:32:31,830 --> 00:32:33,719 This is actually very interesting. 892 00:32:33,720 --> 00:32:35,129 In my opinion. 893 00:32:35,130 --> 00:32:37,259 The Linux kernel starts at the 894 00:32:37,260 --> 00:32:39,569 value of minus five minutes. 895 00:32:39,570 --> 00:32:40,919 Why do they do that? 896 00:32:40,920 --> 00:32:42,149 Well, that's because if you are a 897 00:32:42,150 --> 00:32:44,219 developer on, there somehow 898 00:32:44,220 --> 00:32:46,289 is a book in your driver that after 899 00:32:46,290 --> 00:32:48,299 five minutes when you're gifty, values 900 00:32:48,300 --> 00:32:50,609 overflows. There is a problem that the 901 00:32:50,610 --> 00:32:52,409 developers would very quickly detect 902 00:32:52,410 --> 00:32:54,329 issues. If you were, Jeffy's value would 903 00:32:54,330 --> 00:32:55,609 overflow. 904 00:32:55,610 --> 00:32:57,419 This is just to explain why this number 905 00:32:57,420 --> 00:32:59,549 is so high, even though we just booted 906 00:32:59,550 --> 00:33:00,550 the router. 907 00:33:01,620 --> 00:33:03,209 And anyway, you can see that we 908 00:33:03,210 --> 00:33:05,399 successfully found the group 909 00:33:05,400 --> 00:33:07,559 key here and even 910 00:33:07,560 --> 00:33:10,019 decrypted the packets for us. 911 00:33:10,020 --> 00:33:12,299 So that worked and 912 00:33:12,300 --> 00:33:14,339 it wrote the single decrypted packets to 913 00:33:14,340 --> 00:33:16,439 a file as well. So let's 914 00:33:16,440 --> 00:33:18,479 open that as well so you can see that 915 00:33:18,480 --> 00:33:19,480 that indeed works. 916 00:33:21,070 --> 00:33:23,099 Here, that's the wrong file. 917 00:33:24,910 --> 00:33:27,039 Decrypts, that's unair, you can see the 918 00:33:27,040 --> 00:33:29,239 decrypted broadcast, it was on 919 00:33:29,240 --> 00:33:30,240 our packet, 920 00:33:31,330 --> 00:33:32,829 on the air, you can see the decrypts 921 00:33:32,830 --> 00:33:35,619 packet so we can correctly predicted 922 00:33:35,620 --> 00:33:36,609 the group key, aren't we? 923 00:33:36,610 --> 00:33:38,740 Were able to decrypt this packet. 924 00:33:50,110 --> 00:33:52,239 So let's now try to switch back 925 00:33:52,240 --> 00:33:53,460 to the presentation. 926 00:33:57,230 --> 00:33:59,029 O kay. 927 00:34:01,640 --> 00:34:03,709 I will have to go through these slides 928 00:34:03,710 --> 00:34:04,760 again, probably. 929 00:34:06,560 --> 00:34:08,959 Oh, OK, so 930 00:34:08,960 --> 00:34:11,388 that was the demo the Democrats 931 00:34:11,389 --> 00:34:12,499 have praised us. 932 00:34:12,500 --> 00:34:13,520 Thank God it worked. 933 00:34:15,270 --> 00:34:16,270 So 934 00:34:17,510 --> 00:34:19,638 now let's come back to the other vendor, 935 00:34:19,639 --> 00:34:21,888 the Broadcom vendor. 936 00:34:21,889 --> 00:34:24,408 So, as I mentioned, this depends 937 00:34:24,409 --> 00:34:25,908 on the operating system that they are 938 00:34:25,909 --> 00:34:27,169 using. 939 00:34:27,170 --> 00:34:30,049 In particular, if they are using Linux, 940 00:34:30,050 --> 00:34:32,658 then they implement the Gruchy hierarchy 941 00:34:32,659 --> 00:34:35,839 as specified in the standards, 942 00:34:35,840 --> 00:34:37,399 but they simply reads random. 943 00:34:37,400 --> 00:34:39,979 This from def you random. 944 00:34:39,980 --> 00:34:42,979 So that is much better than 945 00:34:42,980 --> 00:34:44,779 the random number generator proposed in 946 00:34:44,780 --> 00:34:45,738 the standard. 947 00:34:45,739 --> 00:34:48,138 However, a few years ago there was a 948 00:34:48,139 --> 00:34:50,388 paper called Minding Your PS 949 00:34:50,389 --> 00:34:52,879 and Qs by Heininger at all, 950 00:34:52,880 --> 00:34:55,399 and they showed that on 951 00:34:55,400 --> 00:34:57,589 specifically on embedded devices 952 00:34:57,590 --> 00:35:00,099 and on are older Linux kernels 953 00:35:00,100 --> 00:35:01,909 that if you ran them, might be 954 00:35:01,910 --> 00:35:02,959 predictable. 955 00:35:02,960 --> 00:35:05,829 So this means that on certain devices 956 00:35:05,830 --> 00:35:07,909 are few random is predictable, and in 957 00:35:07,910 --> 00:35:09,619 turn all the group keys might be 958 00:35:09,620 --> 00:35:10,620 predictable as well. 959 00:35:11,720 --> 00:35:13,819 Now, if you run a new Linux kernel, 960 00:35:13,820 --> 00:35:16,019 this should no longer be an issue, 961 00:35:16,020 --> 00:35:18,259 however, because a lot of routers use 962 00:35:18,260 --> 00:35:19,729 an old kernel. 963 00:35:19,730 --> 00:35:21,139 This might be an issue. 964 00:35:21,140 --> 00:35:22,129 I haven't tested this. 965 00:35:22,130 --> 00:35:24,199 This is simply based on their 966 00:35:24,200 --> 00:35:26,299 paper that therefore random is not 967 00:35:26,300 --> 00:35:28,609 ideal and for all the kernels, 968 00:35:28,610 --> 00:35:29,610 essentially. 969 00:35:30,320 --> 00:35:31,579 So that's for Linux. 970 00:35:31,580 --> 00:35:33,799 This Broadcom implementation also runs 971 00:35:33,800 --> 00:35:36,079 on Vieques, works on the 972 00:35:36,080 --> 00:35:38,269 coast. So for those of you who don't 973 00:35:38,270 --> 00:35:40,609 know what these operating systems are, 974 00:35:40,610 --> 00:35:42,169 Vieques works on the East Coast. 975 00:35:42,170 --> 00:35:44,239 They are both essentially real time 976 00:35:44,240 --> 00:35:46,249 operating systems. 977 00:35:46,250 --> 00:35:48,649 Vieques works is proprietary. 978 00:35:48,650 --> 00:35:50,569 It's used a lot in aerospace. 979 00:35:50,570 --> 00:35:52,339 So it's used in the Mars lander. 980 00:35:52,340 --> 00:35:54,379 It's used by SpaceX. 981 00:35:54,380 --> 00:35:56,899 It's also used in drones. 982 00:35:56,900 --> 00:35:58,999 And of course, it's also used on certain 983 00:35:59,000 --> 00:36:01,189 routers and access points. 984 00:36:01,190 --> 00:36:02,899 Then there's also Eco's, which is 985 00:36:02,900 --> 00:36:03,919 essentially similar. 986 00:36:03,920 --> 00:36:06,649 It's also a real time operating system, 987 00:36:06,650 --> 00:36:08,719 except it's open source and 988 00:36:08,720 --> 00:36:10,639 it is again used in aerospace and it's 989 00:36:10,640 --> 00:36:12,799 also used by the military 990 00:36:12,800 --> 00:36:14,779 in certain situations. 991 00:36:14,780 --> 00:36:16,759 But of course, we focus on when she was 992 00:36:16,760 --> 00:36:18,889 in the router and when it's used as 993 00:36:18,890 --> 00:36:19,890 an access point. 994 00:36:21,020 --> 00:36:23,239 So we see that in this case, 995 00:36:23,240 --> 00:36:25,519 Broadcom again implements 996 00:36:25,520 --> 00:36:27,589 the ADA on a two Gruchy 997 00:36:29,870 --> 00:36:32,020 and four random numbers. 998 00:36:33,050 --> 00:36:35,149 It has it simply takes 999 00:36:35,150 --> 00:36:37,219 the modified hash of the current time 1000 00:36:37,220 --> 00:36:38,409 and microseconds. 1001 00:36:39,500 --> 00:36:41,809 So, again, that's not ideal 1002 00:36:41,810 --> 00:36:42,810 at all. 1003 00:36:44,240 --> 00:36:46,399 There is also another 1004 00:36:46,400 --> 00:36:48,589 disadvantage of their implementation 1005 00:36:48,590 --> 00:36:51,019 on their use. This public countered 1006 00:36:51,020 --> 00:36:53,089 in the handshake and the four 1007 00:36:53,090 --> 00:36:54,619 way handshake that you use to connect to 1008 00:36:54,620 --> 00:36:55,589 the network. 1009 00:36:55,590 --> 00:36:57,559 Now, this is perfectly allowed. 1010 00:36:57,560 --> 00:36:59,300 There is nothing wrong with that, 1011 00:37:00,500 --> 00:37:02,059 but it does make it easy for us as 1012 00:37:02,060 --> 00:37:04,310 attackers because we can. 1013 00:37:05,710 --> 00:37:07,809 Collect the value that was used here in 1014 00:37:07,810 --> 00:37:09,579 the handshake, answer the one that was 1015 00:37:09,580 --> 00:37:11,409 used while generating the group will be 1016 00:37:11,410 --> 00:37:13,659 only a few numbers away from this value 1017 00:37:13,660 --> 00:37:15,039 that was leaked. 1018 00:37:15,040 --> 00:37:16,509 So really, the only thing we have to 1019 00:37:16,510 --> 00:37:18,789 predict here is the group 1020 00:37:18,790 --> 00:37:20,559 Master Key. 1021 00:37:20,560 --> 00:37:22,749 And if we have the group master key, we 1022 00:37:22,750 --> 00:37:25,539 can then again predict the group. 1023 00:37:25,540 --> 00:37:28,089 So one popular router 1024 00:37:28,090 --> 00:37:30,429 which is vulnerable to this is 1025 00:37:30,430 --> 00:37:33,009 the team 1026 00:37:33,010 --> 00:37:34,010 54. 1027 00:37:34,930 --> 00:37:37,179 At least. If you have one that uses 1028 00:37:37,180 --> 00:37:39,279 version five or higher, then 1029 00:37:39,280 --> 00:37:41,469 it uses the word kernel. 1030 00:37:41,470 --> 00:37:43,619 So if you have a router which is version 1031 00:37:43,620 --> 00:37:46,389 four or lower, it runs on the next 1032 00:37:46,390 --> 00:37:48,459 on. Of course, if you run, we are 1033 00:37:48,460 --> 00:37:50,139 added to you on this. 1034 00:37:50,140 --> 00:37:51,309 You're also fine. 1035 00:37:52,420 --> 00:37:54,549 But if you have a version 1036 00:37:54,550 --> 00:37:56,619 five of this device or higher, then 1037 00:37:56,620 --> 00:37:57,639 you might be vulnerable. 1038 00:37:59,170 --> 00:38:01,329 Unfortunately, I only had 1039 00:38:01,330 --> 00:38:03,789 older versions of this router at home, 1040 00:38:03,790 --> 00:38:06,489 so I simply assimilated this attack 1041 00:38:06,490 --> 00:38:09,219 again, using open codes 1042 00:38:09,220 --> 00:38:11,619 and even with simply quite modest 1043 00:38:11,620 --> 00:38:13,149 assumptions. 1044 00:38:13,150 --> 00:38:15,279 I predict that you need around four 1045 00:38:15,280 --> 00:38:17,439 to five minutes on my CPU 1046 00:38:17,440 --> 00:38:18,999 to crack it. 1047 00:38:19,000 --> 00:38:20,379 Let's say that for some reason my 1048 00:38:20,380 --> 00:38:22,179 simulation is not perfect. 1049 00:38:22,180 --> 00:38:24,519 Then you can use a more powerful GPU 1050 00:38:24,520 --> 00:38:25,699 to still predict. 1051 00:38:26,980 --> 00:38:29,259 But again, taking the life of the current 1052 00:38:29,260 --> 00:38:31,359 time and microseconds, it's simply 1053 00:38:31,360 --> 00:38:33,429 not sufficient to collect 1054 00:38:33,430 --> 00:38:34,810 enough randomness. 1055 00:38:35,980 --> 00:38:38,619 So that concludes both 1056 00:38:38,620 --> 00:38:40,239 these implementations. 1057 00:38:40,240 --> 00:38:42,789 Then we also have two other examples. 1058 00:38:42,790 --> 00:38:44,889 The first is called open. 1059 00:38:44,890 --> 00:38:46,809 Fermor are the as is 1060 00:38:48,310 --> 00:38:50,559 so open firmware, 1061 00:38:50,560 --> 00:38:52,869 essentially, it's simple. 1062 00:38:52,870 --> 00:38:55,479 It's a simple open source bio system. 1063 00:38:55,480 --> 00:38:57,609 And what was really surprising to me 1064 00:38:57,610 --> 00:38:59,889 is that during the bias, these 1065 00:38:59,890 --> 00:39:02,199 people have very basic 1066 00:39:02,200 --> 00:39:04,269 support for Wi-Fi functionality. 1067 00:39:04,270 --> 00:39:06,249 At least as a client, you can even 1068 00:39:06,250 --> 00:39:08,679 collect connect through a WPA to 1069 00:39:08,680 --> 00:39:10,279 secure network. 1070 00:39:10,280 --> 00:39:12,219 Now, for me, that was very surprising to 1071 00:39:12,220 --> 00:39:14,590 see that BIOS supports Wi-Fi, 1072 00:39:15,910 --> 00:39:16,910 but they do. 1073 00:39:19,030 --> 00:39:20,859 Now, I do have to say that they only 1074 00:39:20,860 --> 00:39:22,719 implement Clayne functionality so they 1075 00:39:22,720 --> 00:39:24,879 don't implement access point for 1076 00:39:24,880 --> 00:39:27,009 functionality, so 1077 00:39:27,010 --> 00:39:29,469 they don't actually generate a group. 1078 00:39:29,470 --> 00:39:31,329 However, they do use a random number 1079 00:39:31,330 --> 00:39:33,549 generator to generate other values 1080 00:39:33,550 --> 00:39:36,159 that are used during the Wi-Fi handshake 1081 00:39:36,160 --> 00:39:38,439 aren't very, very simple 1082 00:39:39,790 --> 00:39:40,779 methodology. 1083 00:39:40,780 --> 00:39:42,939 They simply take the amount of text that 1084 00:39:42,940 --> 00:39:44,559 have occurred since Boutte's. 1085 00:39:44,560 --> 00:39:46,779 They run that to a linear 1086 00:39:46,780 --> 00:39:48,909 differential generator, which is 1087 00:39:48,910 --> 00:39:50,979 simply a deterministic function 1088 00:39:50,980 --> 00:39:52,509 and that's used as the random number 1089 00:39:52,510 --> 00:39:54,069 generator. 1090 00:39:54,070 --> 00:39:56,199 The output of this is hashed 1091 00:39:56,200 --> 00:39:59,259 to gather sufficiently long outputs, 1092 00:39:59,260 --> 00:40:01,599 but still this is very easy to 1093 00:40:01,600 --> 00:40:02,589 predict. 1094 00:40:02,590 --> 00:40:04,839 And we included this because 1095 00:40:04,840 --> 00:40:07,209 this is a very good example of 1096 00:40:07,210 --> 00:40:08,859 an implementation that is running on an 1097 00:40:08,860 --> 00:40:11,169 embedded system where there is no kernel 1098 00:40:11,170 --> 00:40:13,329 available to provide you with random 1099 00:40:13,330 --> 00:40:15,399 numbers. So in this case, we are in the 1100 00:40:15,400 --> 00:40:17,499 bias. There is no kernel, there is no 1101 00:40:17,500 --> 00:40:19,449 libraries we can use to generate random 1102 00:40:19,450 --> 00:40:21,099 numbers. And we see that in that 1103 00:40:21,100 --> 00:40:23,289 situation, very bad solutions 1104 00:40:23,290 --> 00:40:25,389 are used on at the end of 1105 00:40:25,390 --> 00:40:27,309 them. At the end of the presentation, I 1106 00:40:27,310 --> 00:40:29,619 will show a way where even 1107 00:40:29,620 --> 00:40:32,319 in these scenarios, an embedded system, 1108 00:40:32,320 --> 00:40:34,359 we can still try to come up with good 1109 00:40:34,360 --> 00:40:37,059 ways to generate random numbers. 1110 00:40:37,060 --> 00:40:39,279 So as a last example, we have 1111 00:40:39,280 --> 00:40:41,349 a host, Abdeh, which is 1112 00:40:41,350 --> 00:40:44,349 essentially the most used 1113 00:40:44,350 --> 00:40:46,429 access point on Linux, for example, 1114 00:40:46,430 --> 00:40:47,829 it is used by Android. 1115 00:40:47,830 --> 00:40:50,379 If you set up a hotspot 1116 00:40:50,380 --> 00:40:52,839 and they have a very good implementation, 1117 00:40:52,840 --> 00:40:54,939 they implement the either on a 2.0 11 1118 00:40:54,940 --> 00:40:56,289 group key. 1119 00:40:56,290 --> 00:40:58,449 They extended it to include entropy 1120 00:40:58,450 --> 00:41:01,629 every time a new group is generated. 1121 00:41:01,630 --> 00:41:03,039 So that's very good. 1122 00:41:03,040 --> 00:41:05,169 Even better than that, they read from 1123 00:41:05,170 --> 00:41:07,389 Def Random ombuds and 1124 00:41:07,390 --> 00:41:08,859 for some reason there is not enough 1125 00:41:08,860 --> 00:41:10,089 entropy available. 1126 00:41:10,090 --> 00:41:11,799 It will simply wait until the first 1127 00:41:11,800 --> 00:41:13,779 client connect and then it will try to 1128 00:41:13,780 --> 00:41:15,969 read again from the referendum. 1129 00:41:15,970 --> 00:41:18,219 And if there still isn't 1130 00:41:18,220 --> 00:41:20,679 enough entropy available, it will simply 1131 00:41:20,680 --> 00:41:22,269 reject connections. 1132 00:41:22,270 --> 00:41:24,519 So in other words, if you 1133 00:41:24,520 --> 00:41:26,679 host Abdeh, everything should 1134 00:41:26,680 --> 00:41:27,680 be fine. 1135 00:41:30,220 --> 00:41:32,289 Of course, if the colonel and 1136 00:41:32,290 --> 00:41:33,489 everything works properly, 1137 00:41:35,380 --> 00:41:37,929 so that concludes how we can generate 1138 00:41:37,930 --> 00:41:39,549 and predict this group. 1139 00:41:40,780 --> 00:41:43,029 We will now explain how we can. 1140 00:41:43,030 --> 00:41:44,619 So this is the second main part of the 1141 00:41:44,620 --> 00:41:46,779 presentation, how we can exploit 1142 00:41:46,780 --> 00:41:49,539 this group to inject on decrypt traffic. 1143 00:41:49,540 --> 00:41:51,639 So let's start with a simple case. 1144 00:41:51,640 --> 00:41:53,709 We want to inject a unicast IP 1145 00:41:53,710 --> 00:41:55,779 packet and we 1146 00:41:55,780 --> 00:41:57,309 want to send it towards a client. 1147 00:41:59,020 --> 00:42:00,020 So. 1148 00:42:00,470 --> 00:42:02,539 Your initial idea may be OK, you 1149 00:42:02,540 --> 00:42:05,299 have your IP packets right here, 1150 00:42:05,300 --> 00:42:08,449 you simply put that into a broadcast 1151 00:42:08,450 --> 00:42:09,529 wi fi frame. 1152 00:42:09,530 --> 00:42:11,689 So here we have the Wi-Fi header, of 1153 00:42:11,690 --> 00:42:13,519 course, very simplified. 1154 00:42:13,520 --> 00:42:15,319 Basically, we are flex in the header, 1155 00:42:15,320 --> 00:42:17,719 which says that this broadcast broadcast 1156 00:42:17,720 --> 00:42:19,789 frame is sent towards clients of 1157 00:42:19,790 --> 00:42:20,779 our network. 1158 00:42:20,780 --> 00:42:22,939 And the receiver is the broadcast Mac 1159 00:42:22,940 --> 00:42:24,979 address because the receiver is the 1160 00:42:24,980 --> 00:42:27,859 broadcast Mac address this IP packets 1161 00:42:27,860 --> 00:42:30,379 and everything is encrypted, unprotected 1162 00:42:30,380 --> 00:42:31,380 using the group. 1163 00:42:32,180 --> 00:42:34,379 However, this will not work. 1164 00:42:34,380 --> 00:42:35,809 And why is that? 1165 00:42:35,810 --> 00:42:38,209 Well, the client notices that 1166 00:42:38,210 --> 00:42:40,489 this unicast IP packet 1167 00:42:40,490 --> 00:42:43,099 is received on a group addressed 1168 00:42:43,100 --> 00:42:45,859 Wi-Fi frame, and 1169 00:42:45,860 --> 00:42:48,019 this is the so-called whole 1170 00:42:48,020 --> 00:42:50,539 one hundred and ninety six check 1171 00:42:50,540 --> 00:42:52,609 and basically says you 1172 00:42:52,610 --> 00:42:54,829 should reject packets that are sent 1173 00:42:54,830 --> 00:42:57,199 on that group, addressed then Linklater, 1174 00:42:57,200 --> 00:42:59,749 but are sent to a unicast IP address. 1175 00:42:59,750 --> 00:43:01,639 In other words, this technique will not 1176 00:43:01,640 --> 00:43:02,599 work. 1177 00:43:02,600 --> 00:43:04,759 So how can we try 1178 00:43:04,760 --> 00:43:06,739 to bypass this technique? 1179 00:43:06,740 --> 00:43:08,839 Well, the realization we have 1180 00:43:08,840 --> 00:43:11,389 to make is that this check occurs 1181 00:43:11,390 --> 00:43:13,699 when a link layer packet is being passed 1182 00:43:13,700 --> 00:43:15,709 on to the network layer where we have 1183 00:43:15,710 --> 00:43:17,919 these unicast IP addresses 1184 00:43:17,920 --> 00:43:20,269 on an access point only works 1185 00:43:20,270 --> 00:43:21,469 at the link layer. 1186 00:43:21,470 --> 00:43:23,389 So if you can somehow abuse the access 1187 00:43:23,390 --> 00:43:25,189 points, then we might be able to bypass 1188 00:43:25,190 --> 00:43:26,269 this check. 1189 00:43:26,270 --> 00:43:28,849 So let me simply explain the technique 1190 00:43:28,850 --> 00:43:30,379 that we're going to use. 1191 00:43:30,380 --> 00:43:32,329 So we have our network here with the 1192 00:43:32,330 --> 00:43:34,459 victim, with the attacker, which wants 1193 00:43:34,460 --> 00:43:37,759 to send a packet to the client. 1194 00:43:37,760 --> 00:43:40,129 But what the attacker will do at 1195 00:43:40,130 --> 00:43:42,229 will first send this IP 1196 00:43:42,230 --> 00:43:44,629 packet towards the access point. 1197 00:43:44,630 --> 00:43:47,029 So, again, we have our IP 1198 00:43:47,030 --> 00:43:48,829 packet here. 1199 00:43:48,830 --> 00:43:51,139 Now we add a bit more complicated Wi-Fi 1200 00:43:51,140 --> 00:43:53,479 header, which says this group from 1201 00:43:53,480 --> 00:43:55,159 this broadcast frame is sent to the 1202 00:43:55,160 --> 00:43:56,179 access points. 1203 00:43:56,180 --> 00:43:58,309 The immediate receiver is, in this 1204 00:43:58,310 --> 00:44:00,859 case, the broadcast Mac address. 1205 00:44:00,860 --> 00:44:02,839 However, the final destination of the 1206 00:44:02,840 --> 00:44:04,609 frame is the victim. 1207 00:44:04,610 --> 00:44:06,409 So what will happen if the access points 1208 00:44:06,410 --> 00:44:08,059 receives this frame? 1209 00:44:08,060 --> 00:44:10,219 Well, it will notice the frame 1210 00:44:10,220 --> 00:44:12,139 is indeed destined for me. 1211 00:44:12,140 --> 00:44:14,029 I will use the group key to decrypt it 1212 00:44:14,030 --> 00:44:15,979 because I did receive it on the broadcast 1213 00:44:15,980 --> 00:44:18,109 Mac address. Everything is fine 1214 00:44:18,110 --> 00:44:20,029 and then it will notice while it's still 1215 00:44:20,030 --> 00:44:21,409 operating at the link layer. 1216 00:44:21,410 --> 00:44:23,839 Oh, but the final destination 1217 00:44:23,840 --> 00:44:24,959 is actually the victim. 1218 00:44:24,960 --> 00:44:27,019 So I have to forward this packet to the 1219 00:44:27,020 --> 00:44:29,119 victim. And the access point of 1220 00:44:29,120 --> 00:44:31,129 course has the section keys to pairwise 1221 00:44:31,130 --> 00:44:32,689 keys of the client. 1222 00:44:32,690 --> 00:44:35,179 So it will simply take this IP packet, 1223 00:44:35,180 --> 00:44:37,459 it will encrypted using the session keys 1224 00:44:37,460 --> 00:44:39,799 for us and then it will simply 1225 00:44:39,800 --> 00:44:42,169 send it to the victim for us. 1226 00:44:42,170 --> 00:44:44,089 And now when the victim received this 1227 00:44:44,090 --> 00:44:46,579 packet, everything seems OK. 1228 00:44:46,580 --> 00:44:48,799 We have our unicast receiver addresses, 1229 00:44:48,800 --> 00:44:50,299 unicast IP address. 1230 00:44:50,300 --> 00:44:52,519 It is properly encrypted, so everything 1231 00:44:52,520 --> 00:44:54,530 is OK and the attack works. 1232 00:44:56,460 --> 00:44:58,919 The second part is that we want to also 1233 00:44:58,920 --> 00:45:01,079 decrypt packets of the idea behind 1234 00:45:01,080 --> 00:45:02,619 this is very simple. 1235 00:45:02,620 --> 00:45:04,709 It's also very simple to explain we 1236 00:45:04,710 --> 00:45:06,839 simply are poisoned the router on 1237 00:45:06,840 --> 00:45:08,819 the client so that the IP address of the 1238 00:45:08,820 --> 00:45:11,099 gateway on the IP address of the client 1239 00:45:11,100 --> 00:45:13,259 or the broadcast Mac address 1240 00:45:13,260 --> 00:45:15,389 and then both the roads are on, 1241 00:45:15,390 --> 00:45:17,759 the client will send unicast IP 1242 00:45:17,760 --> 00:45:20,129 traffic through a broadcast Mac address 1243 00:45:20,130 --> 00:45:21,689 on the table, encrypted using the group 1244 00:45:21,690 --> 00:45:23,909 free Gruchy, which we have 1245 00:45:23,910 --> 00:45:26,309 so we can decrypt this packets 1246 00:45:26,310 --> 00:45:28,109 and then forward them to assure that 1247 00:45:28,110 --> 00:45:30,269 connectivity stays on, 1248 00:45:30,270 --> 00:45:32,819 that the client doesn't notice anything. 1249 00:45:32,820 --> 00:45:34,919 So that's actually quite simple. 1250 00:45:34,920 --> 00:45:36,539 How we can we prevent this? 1251 00:45:36,540 --> 00:45:38,279 Well, the first thing is that if the 1252 00:45:38,280 --> 00:45:41,399 access point receives a broadcast stream, 1253 00:45:41,400 --> 00:45:43,589 but with a unicast final destination, 1254 00:45:43,590 --> 00:45:46,199 it should not forward this 1255 00:45:46,200 --> 00:45:47,789 on an even better countermeasure. 1256 00:45:47,790 --> 00:45:49,949 Is that in an infrastructure 1257 00:45:49,950 --> 00:45:52,379 network, so not necessarily 1258 00:45:52,380 --> 00:45:53,819 in a mesh network, but in an 1259 00:45:53,820 --> 00:45:55,889 infrastructure network where you have an 1260 00:45:55,890 --> 00:45:58,799 access point, the access points 1261 00:45:58,800 --> 00:46:00,989 simply ignore frames 1262 00:46:00,990 --> 00:46:02,669 that are received on a broadcast MAC 1263 00:46:02,670 --> 00:46:04,859 address, and then these issues 1264 00:46:04,860 --> 00:46:05,999 would be avoided. 1265 00:46:07,850 --> 00:46:09,919 So I would say that was the most 1266 00:46:09,920 --> 00:46:11,380 fun part of the research, 1267 00:46:12,500 --> 00:46:14,839 we're now going to look at a theoretical 1268 00:46:14,840 --> 00:46:17,389 attack against a handshake 1269 00:46:17,390 --> 00:46:19,879 that is being used where we can force 1270 00:46:19,880 --> 00:46:21,829 usage of our C4. 1271 00:46:23,930 --> 00:46:26,449 So, OK, let's first quickly explain 1272 00:46:26,450 --> 00:46:28,759 how the handshake works. 1273 00:46:28,760 --> 00:46:30,499 So we have our client here, which 1274 00:46:30,500 --> 00:46:31,819 sometimes is also called to the 1275 00:46:31,820 --> 00:46:34,039 supplicant during the handshake, aren't 1276 00:46:34,040 --> 00:46:35,749 we have our access point? 1277 00:46:35,750 --> 00:46:37,939 So the beginning is very simple. 1278 00:46:37,940 --> 00:46:39,469 Your access point is constantly 1279 00:46:39,470 --> 00:46:41,449 transmitting beacons. 1280 00:46:41,450 --> 00:46:44,149 Those beacons contains the futures, 1281 00:46:44,150 --> 00:46:46,339 the futures of the access point, 1282 00:46:46,340 --> 00:46:48,489 for example, whether it supports 1283 00:46:48,490 --> 00:46:50,659 either 802 dot 11 1284 00:46:50,660 --> 00:46:53,089 or whether it supports AC, and 1285 00:46:53,090 --> 00:46:55,189 it also includes the support of 1286 00:46:55,190 --> 00:46:57,289 the ciphers of the network and 1287 00:46:57,290 --> 00:46:59,419 practice. This basically means whether it 1288 00:46:59,420 --> 00:47:01,789 supports WPT Chip or 1289 00:47:01,790 --> 00:47:04,159 a CAMPI, 1290 00:47:04,160 --> 00:47:06,379 then the client will select a dirty 1291 00:47:06,380 --> 00:47:08,539 cop or a yes no will 1292 00:47:08,540 --> 00:47:10,489 send an association request to the 1293 00:47:10,490 --> 00:47:11,929 network on this. 1294 00:47:11,930 --> 00:47:13,819 Becket's here basically tells the 1295 00:47:13,820 --> 00:47:15,949 network, I want to join on 1296 00:47:15,950 --> 00:47:18,739 this is the cipher I want to use 1297 00:47:18,740 --> 00:47:20,839 and reply to that the access points 1298 00:47:20,840 --> 00:47:23,209 generates generates around them nonce. 1299 00:47:23,210 --> 00:47:25,189 The client will also generate a random 1300 00:47:25,190 --> 00:47:27,439 NUNC. So these random 1301 00:47:27,440 --> 00:47:29,389 nonsense are used to prevent replay 1302 00:47:29,390 --> 00:47:31,519 attacks. Ontari used to assure that 1303 00:47:31,520 --> 00:47:34,639 fresh session keys are negotiated. 1304 00:47:34,640 --> 00:47:36,319 So here we have the access point, 1305 00:47:36,320 --> 00:47:38,749 non-store to einen and we have the supply 1306 00:47:38,750 --> 00:47:40,809 Norns also the client. 1307 00:47:40,810 --> 00:47:43,039 So it's the same as the client, which 1308 00:47:43,040 --> 00:47:44,629 is of the essence. 1309 00:47:44,630 --> 00:47:46,759 Once they both have received this as 1310 00:47:46,760 --> 00:47:48,919 nonsense, they can receive, they can 1311 00:47:48,920 --> 00:47:51,289 arrive the session keys 1312 00:47:51,290 --> 00:47:53,359 on. After this first stage of the 1313 00:47:53,360 --> 00:47:55,489 handshake, we are essentially going to 1314 00:47:55,490 --> 00:47:57,769 confirm that everything 1315 00:47:57,770 --> 00:48:00,229 was OK, that there was no attacker 1316 00:48:00,230 --> 00:48:02,419 on the access point is going 1317 00:48:02,420 --> 00:48:04,489 to accept the Gruchy, 1318 00:48:04,490 --> 00:48:06,949 the group temporal key in the message 1319 00:48:06,950 --> 00:48:09,219 of the handshake and 1320 00:48:09,220 --> 00:48:11,269 message. Three, it also includes an 1321 00:48:11,270 --> 00:48:13,489 authenticated cipher list of 1322 00:48:13,490 --> 00:48:15,169 the cipher that the access point 1323 00:48:15,170 --> 00:48:16,069 supports. 1324 00:48:16,070 --> 00:48:18,679 So this is to prevent downgrade attacks 1325 00:48:18,680 --> 00:48:20,179 that say that we have a man in the middle 1326 00:48:20,180 --> 00:48:22,369 attacker, which here says, OK, I 1327 00:48:22,370 --> 00:48:24,649 only support the old TCP 1328 00:48:24,650 --> 00:48:26,899 cipher, then the client 1329 00:48:26,900 --> 00:48:28,619 would connect using takeup. 1330 00:48:28,620 --> 00:48:30,739 However, at this stage, 1331 00:48:30,740 --> 00:48:32,839 the real access points, which 1332 00:48:32,840 --> 00:48:35,059 sent a message which includes 1333 00:48:35,060 --> 00:48:37,219 the real cipher list, which is 1334 00:48:37,220 --> 00:48:39,289 authenticated using the passwords 1335 00:48:39,290 --> 00:48:41,389 of the network, essentially meaning an 1336 00:48:41,390 --> 00:48:44,569 attacker cannot modify the spigot, 1337 00:48:44,570 --> 00:48:47,059 the client would notice after receiving 1338 00:48:47,060 --> 00:48:49,519 message if there was a possible downgrade 1339 00:48:49,520 --> 00:48:51,679 attack because this authenticated 1340 00:48:51,680 --> 00:48:53,779 cipher list might not match the 1341 00:48:53,780 --> 00:48:56,089 ones that was received in unprotected 1342 00:48:56,090 --> 00:48:57,439 beacon's. 1343 00:48:57,440 --> 00:48:59,539 So the problem with this 1344 00:48:59,540 --> 00:49:01,609 design is that the group key 1345 00:49:01,610 --> 00:49:04,039 here is transmitted aren't encrypted 1346 00:49:05,060 --> 00:49:07,489 before the client can prevent 1347 00:49:07,490 --> 00:49:09,829 or detect downgrade attacks. 1348 00:49:09,830 --> 00:49:12,059 So what can an attacker do here? 1349 00:49:12,060 --> 00:49:14,179 An attacker can put up 1350 00:49:14,180 --> 00:49:15,799 a rogue access points. 1351 00:49:15,800 --> 00:49:18,049 It can modify the beacon messages and 1352 00:49:18,050 --> 00:49:20,119 say, hey, I only include I 1353 00:49:20,120 --> 00:49:22,669 only support Kipe, 1354 00:49:22,670 --> 00:49:24,589 which means that the client will connect 1355 00:49:24,590 --> 00:49:27,199 using takeup arms 1356 00:49:27,200 --> 00:49:30,199 in case that the session cipher 1357 00:49:30,200 --> 00:49:32,449 takeup. Then there's group here 1358 00:49:32,450 --> 00:49:34,579 when it is transmitted to the client 1359 00:49:34,580 --> 00:49:36,949 is encrypted, unprotected, using 1360 00:49:36,950 --> 00:49:39,169 for if a 1361 00:49:39,170 --> 00:49:40,759 yes would have been used, then we also 1362 00:49:40,760 --> 00:49:42,589 would use a yes to protect a group and 1363 00:49:42,590 --> 00:49:44,239 everything would be fine. 1364 00:49:44,240 --> 00:49:46,939 However, in this case we are using 1365 00:49:46,940 --> 00:49:49,939 our C4 if we can, if we are performing 1366 00:49:49,940 --> 00:49:52,009 this attack on our C4 is 1367 00:49:52,010 --> 00:49:54,139 of course quite 1368 00:49:54,140 --> 00:49:55,140 bad. 1369 00:49:57,080 --> 00:49:59,569 So for the crypto people around here, 1370 00:49:59,570 --> 00:50:01,639 I'm very quickly going to explain 1371 00:50:01,640 --> 00:50:02,689 how our C4 is used. 1372 00:50:02,690 --> 00:50:04,159 You basically have 16 bytes 1373 00:50:04,160 --> 00:50:06,229 initialization factor, which is public. 1374 00:50:06,230 --> 00:50:08,389 You have a 16 byte secret key on the 1375 00:50:08,390 --> 00:50:10,579 first. Two hundred and fifty stream bytes 1376 00:50:10,580 --> 00:50:11,580 are dropped. 1377 00:50:12,350 --> 00:50:13,669 This is actually a very strange 1378 00:50:13,670 --> 00:50:15,769 construction if you're a bit used to ask 1379 00:50:15,770 --> 00:50:16,770 for. 1380 00:50:17,420 --> 00:50:19,999 I'm simply going to intuitively explain 1381 00:50:20,000 --> 00:50:22,129 the problem with RC four in this case 1382 00:50:22,130 --> 00:50:24,649 and also the problem with RC four 1383 00:50:24,650 --> 00:50:26,059 in general. 1384 00:50:26,060 --> 00:50:28,189 Here you see a graph 1385 00:50:28,190 --> 00:50:30,439 which kind of illustrates the behavior 1386 00:50:30,440 --> 00:50:32,899 of our C4 in this case. 1387 00:50:32,900 --> 00:50:34,969 So normally, if 1388 00:50:34,970 --> 00:50:37,159 you make these kinds of graphs for 1389 00:50:37,160 --> 00:50:39,289 a secure cipher, for example, for a 1390 00:50:39,290 --> 00:50:41,629 yes, this would be completely 1391 00:50:41,630 --> 00:50:42,630 white. 1392 00:50:43,700 --> 00:50:46,069 So what does this graph illustrate? 1393 00:50:46,070 --> 00:50:48,229 Well, see, for example, here you are 1394 00:50:48,230 --> 00:50:50,539 at keester position, say, 1395 00:50:50,540 --> 00:50:51,689 300. 1396 00:50:51,690 --> 00:50:53,959 If we then go look at 1397 00:50:53,960 --> 00:50:56,479 XStream value, let's say around 90, 1398 00:50:56,480 --> 00:50:58,949 we can see that there is a blue dot here. 1399 00:50:58,950 --> 00:51:00,799 What does that mean? 1400 00:51:00,800 --> 00:51:03,049 That means that 1401 00:51:03,050 --> 00:51:05,749 the key stream by acquisition 300 1402 00:51:05,750 --> 00:51:07,839 is. Slightly less likely 1403 00:51:07,840 --> 00:51:09,999 than uniform to contain the value 1404 00:51:10,000 --> 00:51:12,249 90, normally, this 1405 00:51:12,250 --> 00:51:13,869 should be uniformly around them. 1406 00:51:13,870 --> 00:51:15,490 Normally, if you have a proper 1407 00:51:16,990 --> 00:51:19,479 cipher, every key stream 1408 00:51:19,480 --> 00:51:21,729 should occur as 1409 00:51:21,730 --> 00:51:23,319 often as all the others. 1410 00:51:23,320 --> 00:51:25,179 However, you can see here and the colors 1411 00:51:25,180 --> 00:51:27,609 that these blue keys invites at certain 1412 00:51:27,610 --> 00:51:29,799 values occur less often on 1413 00:51:29,800 --> 00:51:32,289 these red ones occur more often 1414 00:51:32,290 --> 00:51:33,290 than others. 1415 00:51:34,380 --> 00:51:36,249 This graph depends on the specific 1416 00:51:36,250 --> 00:51:38,469 analyzation vector that is being used. 1417 00:51:38,470 --> 00:51:40,779 So the only thing I would take 1418 00:51:40,780 --> 00:51:42,909 away from this slide is that if 1419 00:51:42,910 --> 00:51:45,219 you use RC for some key stream, values 1420 00:51:45,220 --> 00:51:47,439 occur more often than others, although 1421 00:51:47,440 --> 00:51:49,599 we can abuse that in an attack. 1422 00:51:49,600 --> 00:51:51,909 So if we were to perform 1423 00:51:51,910 --> 00:51:54,129 similar attacks against the ones that 1424 00:51:54,130 --> 00:51:56,709 were executed against 1425 00:51:56,710 --> 00:51:58,869 SSL on HTTPS and the few 1426 00:51:58,870 --> 00:52:00,969 recent years, then we 1427 00:52:00,970 --> 00:52:02,649 can see it's still a theoretical attack 1428 00:52:02,650 --> 00:52:04,629 because it would take around 50 years to 1429 00:52:04,630 --> 00:52:06,129 execute. 1430 00:52:06,130 --> 00:52:08,379 The reason is because we need to collect 1431 00:52:08,380 --> 00:52:10,599 a lot of encrypted traffic to perform our 1432 00:52:10,600 --> 00:52:12,729 cryptanalysis aunt in a case 1433 00:52:12,730 --> 00:52:14,919 of wi fi. This is very time consuming 1434 00:52:14,920 --> 00:52:15,920 to do. 1435 00:52:16,540 --> 00:52:18,929 However, attacks only get better. 1436 00:52:18,930 --> 00:52:21,069 In fact, a few weeks ago I 1437 00:52:21,070 --> 00:52:22,869 found a trick to execute these 1438 00:52:22,870 --> 00:52:25,269 handshake's more frequently, meaning 1439 00:52:25,270 --> 00:52:27,249 this time would be, I think, at least 1440 00:52:27,250 --> 00:52:29,499 divided by two or three. 1441 00:52:29,500 --> 00:52:31,419 So let's say that someone would put more 1442 00:52:31,420 --> 00:52:32,349 time in this. 1443 00:52:32,350 --> 00:52:34,569 We could probably lower this value 1444 00:52:34,570 --> 00:52:35,860 more and more every year. 1445 00:52:36,880 --> 00:52:38,919 So the takeaway messages from a 1446 00:52:38,920 --> 00:52:41,289 cryptographic standpoint, our C4 1447 00:52:41,290 --> 00:52:43,689 is broken and you should simply not 1448 00:52:43,690 --> 00:52:44,719 use it anymore. 1449 00:52:46,030 --> 00:52:47,889 So the counter measure is if you have a 1450 00:52:47,890 --> 00:52:50,229 network at home, simply disable 1451 00:52:50,230 --> 00:52:51,819 WPA to keep. 1452 00:52:51,820 --> 00:52:54,039 So if you have a network network, 1453 00:52:54,040 --> 00:52:56,379 not only should you select that, it 1454 00:52:56,380 --> 00:52:58,329 has to use WPA too. 1455 00:52:58,330 --> 00:53:00,519 You have to explicitly configure 1456 00:53:00,520 --> 00:53:03,229 it to only use A-s 1457 00:53:03,230 --> 00:53:06,069 on. In that case, you are safe against 1458 00:53:06,070 --> 00:53:07,139 this specific attack. 1459 00:53:08,560 --> 00:53:10,809 So finally, the last part 1460 00:53:10,810 --> 00:53:13,179 of the presentation is just a very 1461 00:53:13,180 --> 00:53:15,289 short, short suggestion on 1462 00:53:15,290 --> 00:53:17,409 that, how we can we improve 1463 00:53:17,410 --> 00:53:19,480 the random number generator and 1464 00:53:20,530 --> 00:53:22,179 we want to make sure that the improvement 1465 00:53:22,180 --> 00:53:24,249 that we suggest even works 1466 00:53:24,250 --> 00:53:26,379 on embedded systems where there is no 1467 00:53:26,380 --> 00:53:28,449 kernel available 1468 00:53:28,450 --> 00:53:30,879 on the is very little chance 1469 00:53:30,880 --> 00:53:32,679 of collecting randomness. 1470 00:53:32,680 --> 00:53:35,019 Well, our observation is essentially, 1471 00:53:35,020 --> 00:53:37,329 well, OK, we have a Wi-Fi chip 1472 00:53:37,330 --> 00:53:39,519 on this Wi-Fi chip can monitor 1473 00:53:39,520 --> 00:53:41,469 all the Wi-Fi signals around. 1474 00:53:41,470 --> 00:53:43,719 So why not simply extract randomness 1475 00:53:43,720 --> 00:53:45,969 from all the Wi-Fi frames that we 1476 00:53:45,970 --> 00:53:47,559 receive, not our words. 1477 00:53:47,560 --> 00:53:49,539 Why not collect randomness from 1478 00:53:49,540 --> 00:53:51,750 background noise and. 1479 00:53:53,030 --> 00:53:55,129 We actually found one device, 1480 00:53:55,130 --> 00:53:57,199 it is this one, this has 1481 00:53:57,200 --> 00:53:59,979 a so-called spectral scan feature, 1482 00:53:59,980 --> 00:54:02,059 and this means that this 1483 00:54:02,060 --> 00:54:04,219 chip is able to collect a lot of 1484 00:54:04,220 --> 00:54:06,469 samples of the current 1485 00:54:06,470 --> 00:54:08,479 Wi-Fi background noise, even if there is 1486 00:54:08,480 --> 00:54:10,919 no traffic or nothing is going on 1487 00:54:10,920 --> 00:54:13,579 and we can generate a very large amount 1488 00:54:13,580 --> 00:54:15,769 of samples every second. 1489 00:54:15,770 --> 00:54:17,989 The current downside is that 1490 00:54:17,990 --> 00:54:19,780 this is a bit energy. 1491 00:54:21,980 --> 00:54:23,449 This takes a lot of energy. 1492 00:54:23,450 --> 00:54:26,329 So you can run this very long. 1493 00:54:26,330 --> 00:54:28,549 But we did implement this idea to 1494 00:54:28,550 --> 00:54:31,189 extract randomness from 1495 00:54:31,190 --> 00:54:33,289 the noise of the Wi-Fi 1496 00:54:33,290 --> 00:54:35,389 channel, and we did a 1497 00:54:35,390 --> 00:54:37,579 few statistical tests on this 1498 00:54:37,580 --> 00:54:40,189 and our results were promising. 1499 00:54:40,190 --> 00:54:42,079 It shows that we can indeed extract 1500 00:54:42,080 --> 00:54:44,719 randomness from background noise. 1501 00:54:44,720 --> 00:54:46,579 Now, this is just a proposal. 1502 00:54:46,580 --> 00:54:48,859 Some more research here is needed. 1503 00:54:48,860 --> 00:54:51,439 But I do think that Wi-Fi vendors 1504 00:54:51,440 --> 00:54:53,510 should provide the features that 1505 00:54:54,740 --> 00:54:57,139 common Wi-Fi chips exports 1506 00:54:57,140 --> 00:54:58,849 some of this randomness which can then 1507 00:54:58,850 --> 00:55:01,009 directly be used or it can be used by 1508 00:55:01,010 --> 00:55:03,589 the kernel to strengthen the current 1509 00:55:03,590 --> 00:55:04,679 pool of randomness. 1510 00:55:05,690 --> 00:55:08,029 So that concludes 1511 00:55:08,030 --> 00:55:08,989 my talk. 1512 00:55:08,990 --> 00:55:11,359 There are a few important lessons 1513 00:55:11,360 --> 00:55:12,889 to take away here. 1514 00:55:12,890 --> 00:55:14,779 The first is if you have a random number 1515 00:55:14,780 --> 00:55:17,089 generator, always check the quality 1516 00:55:17,090 --> 00:55:19,249 of the output on, especially 1517 00:55:19,250 --> 00:55:21,079 if you put in the standards. 1518 00:55:21,080 --> 00:55:23,389 Don't put a very bad example 1519 00:55:23,390 --> 00:55:25,699 algorithms which are really 1520 00:55:25,700 --> 00:55:28,369 bad. If you design a specification, 1521 00:55:28,370 --> 00:55:30,319 what you put in there should be good and 1522 00:55:30,320 --> 00:55:31,669 it should work. 1523 00:55:31,670 --> 00:55:33,709 Otherwise, just reference an external 1524 00:55:33,710 --> 00:55:36,109 source where it is explained 1525 00:55:36,110 --> 00:55:38,269 better and to 1526 00:55:38,270 --> 00:55:40,609 protect to defend against the attack, 1527 00:55:40,610 --> 00:55:42,259 where we decrypt all traffic of a 1528 00:55:42,260 --> 00:55:43,369 network. 1529 00:55:43,370 --> 00:55:45,679 Like I mentioned, the access point should 1530 00:55:45,680 --> 00:55:47,779 ignore any frames that are 1531 00:55:47,780 --> 00:55:50,839 received on broadcast mac address 1532 00:55:50,840 --> 00:55:53,659 or which should simply not 1533 00:55:53,660 --> 00:55:55,789 forward unicast frames that are 1534 00:55:55,790 --> 00:55:58,159 sent on a broadcast Mac address. 1535 00:55:58,160 --> 00:56:00,739 Finally, regarding the protocol 1536 00:56:00,740 --> 00:56:02,779 that is used in the handshake, you should 1537 00:56:02,780 --> 00:56:05,209 try to avoid sending sensitive data 1538 00:56:05,210 --> 00:56:06,739 before trying to protect 1539 00:56:07,760 --> 00:56:09,679 downgrade attacks. 1540 00:56:09,680 --> 00:56:12,289 So that concludes my presentations. 1541 00:56:12,290 --> 00:56:14,389 If there are any questions, feel free 1542 00:56:14,390 --> 00:56:15,390 to ask. 1543 00:56:30,120 --> 00:56:32,399 Thank you, Marty. We have a few minutes 1544 00:56:32,400 --> 00:56:34,469 left for questions, so if you have any 1545 00:56:34,470 --> 00:56:36,449 questions, please line up next to the 1546 00:56:36,450 --> 00:56:37,450 microphones 1547 00:56:38,550 --> 00:56:39,539 and ask your questions. 1548 00:56:39,540 --> 00:56:42,119 Make good use of our time 1549 00:56:42,120 --> 00:56:43,499 if we have any questions from the 1550 00:56:43,500 --> 00:56:45,239 Internet. Yes, please. 1551 00:56:45,240 --> 00:56:46,629 Yes, two questions from the Internet. 1552 00:56:46,630 --> 00:56:49,819 The first one, uh, would you consider 1553 00:56:49,820 --> 00:56:52,019 WPA two with appreciate 1554 00:56:52,020 --> 00:56:53,639 Kenya still safe? 1555 00:56:55,650 --> 00:56:58,079 Um, if the 1556 00:56:58,080 --> 00:57:01,589 key is good on unpredictable, 1557 00:57:01,590 --> 00:57:03,269 then this type of dictionary attacks, 1558 00:57:03,270 --> 00:57:05,149 they are no longer possible. 1559 00:57:05,150 --> 00:57:06,919 However, you still have the issue of the 1560 00:57:06,920 --> 00:57:09,239 group. And in fact, this group, 1561 00:57:09,240 --> 00:57:10,859 which is Batley generated. 1562 00:57:10,860 --> 00:57:12,989 This applies to both enterprise 1563 00:57:12,990 --> 00:57:15,209 networks and networks that use 1564 00:57:15,210 --> 00:57:16,210 appreciate. 1565 00:57:18,900 --> 00:57:20,489 Currently, I believe that 1566 00:57:21,570 --> 00:57:23,729 the handshake that is used in wi fi can 1567 00:57:23,730 --> 00:57:26,309 be improved. So if you use appreciate 1568 00:57:26,310 --> 00:57:28,439 key, I don't consider 1569 00:57:28,440 --> 00:57:30,869 it as strong as an enterprise 1570 00:57:30,870 --> 00:57:32,339 network where you have proper 1571 00:57:32,340 --> 00:57:33,539 credentials. 1572 00:57:33,540 --> 00:57:35,699 So I would say that an enterprise network 1573 00:57:35,700 --> 00:57:38,669 is more secure in most cases. 1574 00:57:38,670 --> 00:57:41,039 However, as a general user, if you have a 1575 00:57:41,040 --> 00:57:43,139 complex, pre shared key, then 1576 00:57:43,140 --> 00:57:44,140 you're still good. 1577 00:57:45,290 --> 00:57:46,340 OK, let's hear from you 1578 00:57:48,380 --> 00:57:50,519 for the spoofing, did you consider 1579 00:57:50,520 --> 00:57:53,329 Gratitudes our offer on the networks 1580 00:57:53,330 --> 00:57:54,589 because you already have access to the 1581 00:57:54,590 --> 00:57:55,590 broadcast? So, 1582 00:57:57,560 --> 00:57:59,059 um. 1583 00:57:59,060 --> 00:58:00,589 Well, I think that's what we used to 1584 00:58:00,590 --> 00:58:02,749 poison the interests of the 1585 00:58:02,750 --> 00:58:05,059 clients. So we send a broadcast 1586 00:58:05,060 --> 00:58:07,129 our packet to poison the 1587 00:58:07,130 --> 00:58:09,109 client on the router, if that explains 1588 00:58:09,110 --> 00:58:10,999 your question. Yeah, but you can you can 1589 00:58:11,000 --> 00:58:12,979 explain the clans in the network. 1590 00:58:12,980 --> 00:58:15,080 You send gratuitous art. 1591 00:58:16,130 --> 00:58:18,219 So you basically broadcast 1592 00:58:18,220 --> 00:58:20,989 to our injury to anybody on the network, 1593 00:58:20,990 --> 00:58:23,119 just not one single client. 1594 00:58:23,120 --> 00:58:25,129 We've the well, you can send it to any 1595 00:58:25,130 --> 00:58:26,449 client you want. 1596 00:58:26,450 --> 00:58:28,609 You can say, I want to inject traffic 1597 00:58:28,610 --> 00:58:30,679 of this client or you can maybe 1598 00:58:30,680 --> 00:58:32,869 try to send it to all clients. 1599 00:58:32,870 --> 00:58:34,819 I haven't looked at that much in detail. 1600 00:58:34,820 --> 00:58:36,379 I just said, if you want to attack one 1601 00:58:36,380 --> 00:58:38,419 client that works, if you want to take 1602 00:58:38,420 --> 00:58:39,739 another client, you can just do the same 1603 00:58:39,740 --> 00:58:41,779 attack. OK, thanks. 1604 00:58:41,780 --> 00:58:42,780 Yes, 1605 00:58:44,410 --> 00:58:46,639 we regarding your problem, 1606 00:58:47,690 --> 00:58:50,119 I have access points and the broadcast 1607 00:58:50,120 --> 00:58:52,789 packets. So that's a unique aspect. 1608 00:58:52,790 --> 00:58:54,679 Is it the demand and the standard to do 1609 00:58:54,680 --> 00:58:57,199 it this way, or have you checked 1610 00:58:57,200 --> 00:58:59,509 if all implementation do it this way 1611 00:58:59,510 --> 00:59:01,150 or only son? 1612 00:59:02,750 --> 00:59:04,519 That's a good question. 1613 00:59:04,520 --> 00:59:07,129 I don't know exactly what the standard 1614 00:59:07,130 --> 00:59:08,239 says. 1615 00:59:08,240 --> 00:59:10,309 What I do know is that not 1616 00:59:10,310 --> 00:59:12,829 even all implementations implement this 1617 00:59:12,830 --> 00:59:14,929 whole 1996 1618 00:59:14,930 --> 00:59:17,449 attack. So there you can even directly 1619 00:59:17,450 --> 00:59:19,519 send frames to the client without needing 1620 00:59:19,520 --> 00:59:21,649 to abuse the access point. 1621 00:59:21,650 --> 00:59:23,419 So I don't think that this idea of 1622 00:59:23,420 --> 00:59:25,309 forwarding packets is explicitly 1623 00:59:25,310 --> 00:59:26,569 mentioned in the standard. 1624 00:59:26,570 --> 00:59:28,849 I think they just haven't 1625 00:59:28,850 --> 00:59:30,259 thought about that. 1626 00:59:30,260 --> 00:59:32,239 But I would guess that most 1627 00:59:32,240 --> 00:59:34,009 implementations would be vulnerable to 1628 00:59:34,010 --> 00:59:36,079 this forwarding trick through the access 1629 00:59:36,080 --> 00:59:37,119 point. 1630 00:59:37,120 --> 00:59:39,619 I mean, I would be surprised if certain 1631 00:59:39,620 --> 00:59:41,599 vendors thought about protecting against 1632 00:59:41,600 --> 00:59:43,129 that. It could be, but I think the 1633 00:59:43,130 --> 00:59:44,130 chances are low. 1634 00:59:46,150 --> 00:59:48,369 OK, let's talk a last 1635 00:59:48,370 --> 00:59:51,069 question. Sorry, no, no. 1636 00:59:51,070 --> 00:59:53,289 OK, then I think we're done again. 1637 00:59:53,290 --> 00:59:55,090 Big round of applause for a great the.