1 00:00:00,000 --> 00:00:16,620 *34c3 intro* 2 00:00:16,620 --> 00:00:23,720 Herald: I'm really happy to be able to introduce our next speaker. Mathy is a 3 00:00:23,720 --> 00:00:30,180 postdoc in Network Security and Applied Crypto. He took part in discovering and 4 00:00:30,180 --> 00:00:35,860 implementing quite some attacks in this field and especially in the wireless 5 00:00:35,860 --> 00:00:43,490 sector. And today he will show us, that all our Wi-Fi devices are vulnerable. 6 00:00:43,490 --> 00:00:49,120 Especially the ones with Linux and Android. So, I don't want to go into the 7 00:00:49,120 --> 00:00:53,140 technical details, because he would do this and I think if you're interested in 8 00:00:53,140 --> 00:00:57,960 even learning more about it, he even linked the research paper as well as the scripts 9 00:00:57,960 --> 00:01:04,190 and a website for this attack in the Fahrplan. So for now, give a big round of 10 00:01:04,190 --> 00:01:06,699 applause for Mathy Vanhoef! 11 00:01:06,699 --> 00:01:11,510 *applause* 12 00:01:11,510 --> 00:01:15,960 Mathy Vanhoef: Ok, thank you for the introduction and thank you all for 13 00:01:15,960 --> 00:01:19,921 attending the talk, even though it's already a bit late in the evening. Thank 14 00:01:19,921 --> 00:01:25,480 you CCC for allowing me to speak here. So today I'm going to talk about my research 15 00:01:25,480 --> 00:01:30,750 on WPA2 and you probably have already heard about this under the name of KRACK 16 00:01:30,750 --> 00:01:37,770 attacks. Now, the history of this research is quite interesting, because during my PhD, 17 00:01:37,770 --> 00:01:44,490 I was already researching the security of wireless networks and during my PhD 18 00:01:44,490 --> 00:01:50,840 defense last year, when I was finishing up on writing my thesis, one of the jury 19 00:01:50,840 --> 00:01:57,230 members in my PhD asked: "Hey, you're recommending WPA2 with AES in your thesis, 20 00:01:57,230 --> 00:02:03,390 but are you sure that's really a secure solution?" And last year my answer was: 21 00:02:03,390 --> 00:02:08,229 "Yeah, I mean it seems secure. It has been around for more than a decade and if we 22 00:02:08,229 --> 00:02:11,920 ignore some brute-force attacks against the password, if you select a secure 23 00:02:11,920 --> 00:02:16,910 password, then there are no real weaknesses that are known. On top of that, there are 24 00:02:16,910 --> 00:02:21,190 also mathematical proofs that state that if you have the 4-way handshake on the 25 00:02:21,190 --> 00:02:27,490 encryption algorithm, that it's supposed to be secure. Unfortunately, a year later I 26 00:02:27,490 --> 00:02:32,800 was staring at some OpenBSD code. In particular, I was looking at this function 27 00:02:32,800 --> 00:02:39,440 called ic_set_key. The details aren't important here yet, but this key installs 28 00:02:39,440 --> 00:02:44,470 the encryption key for use by the driver, so frames get encrypted and I was 29 00:02:44,470 --> 00:02:48,240 wondering, what would happen if this function is called 30 00:02:48,240 --> 00:02:53,459 twice. And I was thinking, like, will it reinstall the key and what will happen 31 00:02:53,459 --> 00:02:58,380 when you reinstall the key? And it turns out that answering this question led to 32 00:02:58,380 --> 00:03:06,540 the attack I found and as you know by now, this uncovered the flaw in WPA2. So in a 33 00:03:06,540 --> 00:03:13,589 sense, this talk is all about how I gave the wrong answer during my PhD defense. To 34 00:03:13,589 --> 00:03:19,590 explain the attack, I will illustrate it against the 4-way handshake. After that I 35 00:03:19,590 --> 00:03:24,470 will discuss the impact of the attack in practice, then I will go over some 36 00:03:24,470 --> 00:03:28,720 common misconceptions that have been floating around the internet and finally I 37 00:03:28,720 --> 00:03:31,940 will discuss some lessons that we can learn from this 38 00:03:31,940 --> 00:03:37,819 research and from our findings. Let's get started with explaining the attack against 39 00:03:37,819 --> 00:03:42,290 the 4-way handshake and the first question I have to answer here is: what 40 00:03:42,290 --> 00:03:48,740 exactly is this 4-way handshake? And the 4-way handshake is executed whenever 41 00:03:48,740 --> 00:03:53,349 you connect to a protected Wi-Fi network. It's used when you connect to your home 42 00:03:53,349 --> 00:03:57,290 Wi-Fi network where you just have a pre- shared password, but it's also used in 43 00:03:57,290 --> 00:04:02,489 enterprise network-networks where you for example have a username and a password to 44 00:04:02,489 --> 00:04:06,239 log in. The purpose of this handshake is to verify 45 00:04:06,239 --> 00:04:10,800 that you possess the correct credentials in order to connect to the network and at 46 00:04:10,800 --> 00:04:15,250 the same time, this 4-way handshake negotiates a fresh session key that will 47 00:04:15,250 --> 00:04:19,979 be used to encrypt data frames. This session key is called the PTK, the 48 00:04:19,979 --> 00:04:27,610 pairwise temporal key. And as I mentioned, this handshake seemed to be really secure 49 00:04:27,610 --> 00:04:33,769 because for over a decade, no attacks have been found against it, assuming that a 50 00:04:33,769 --> 00:04:40,020 secure password is being used, and on top of that, the 4-way handshake was 51 00:04:40,020 --> 00:04:43,729 formally proven to be secure and the encryption algorithm that is used after 52 00:04:43,729 --> 00:04:48,659 the 4-way handshake, which generally is AES CCMP, that was also formally 53 00:04:48,659 --> 00:04:53,550 proven to be secure. Yet somehow we did find an attack even 54 00:04:53,550 --> 00:04:57,199 though we have all these formal proofs, even though this protocol has been around 55 00:04:57,199 --> 00:05:01,230 for that long. So what went wrong? 56 00:05:01,230 --> 00:05:08,050 To explain this, I'm going to explain how the 4-way handshake works, using this 57 00:05:08,050 --> 00:05:12,550 specific example. So let's say, we have the client on the right here that wants to 58 00:05:12,550 --> 00:05:17,710 connect to the access point on the left. Now, in order to start the 4-way 59 00:05:17,710 --> 00:05:22,020 handshake, there first needs to be some preshared secrets between the client on 60 00:05:22,020 --> 00:05:26,749 the access point and if you have a network at home, this preshared secret is basically 61 00:05:26,749 --> 00:05:30,750 the password of the network. But if you have an enterprise or a more professional 62 00:05:30,750 --> 00:05:35,649 network, then - where you for example have to log in using a username and a password - 63 00:05:35,649 --> 00:05:41,789 then first 802.1x authentication algorithm is executed, which in practice is commonly 64 00:05:41,789 --> 00:05:47,079 some form of RADIUS authentication. The details of that are not important. 65 00:05:47,079 --> 00:05:51,180 What's important here is the result. Namely, after this authentication phase 66 00:05:51,180 --> 00:05:55,509 there is a shared secret between the client and the access point. 67 00:05:55,509 --> 00:06:01,460 And once we have this shared secret, we can execute the 4-way handshake. What 68 00:06:01,460 --> 00:06:06,879 the first two messages in the 4-way handshake do, is they transport a random 69 00:06:06,879 --> 00:06:11,099 number between both devices. So in particular, the access point will 70 00:06:11,099 --> 00:06:15,569 generate a random number called the access point nonce, the ANonce, and it will 71 00:06:15,569 --> 00:06:20,379 transport that to the client. Then in reaction to that, the client will 72 00:06:20,379 --> 00:06:24,150 generate its own random number called the supplicant nonce - and supplicant is 73 00:06:24,150 --> 00:06:29,119 basically a synonym for client - and it will send that random number, the SNonce, 74 00:06:29,119 --> 00:06:36,550 to the access point in the second message of the handshake. Once both devices have 75 00:06:36,550 --> 00:06:41,690 each other's random number, then we can derive this unique per session key. 76 00:06:41,690 --> 00:06:46,860 How that key is derived, is fairly simple: we take the preshared key, that is known 77 00:06:46,860 --> 00:06:51,669 between these two devices, we combine that with both of these random numbers and the 78 00:06:51,669 --> 00:06:56,849 result is the PTK, this fresh encryption key, that will later be used to encrypt 79 00:06:56,849 --> 00:07:02,930 data frames. Now, I want to clarify one thing, and you 80 00:07:02,930 --> 00:07:07,849 might have heard about this research under the name 'key reinstallation attacks: 81 00:07:07,849 --> 00:07:13,610 forcing nonce reuse in WPA2'. I want to highlight here that the nonce 82 00:07:13,610 --> 00:07:17,990 reuse does not refer to the nonce reuse about the ANonce or SNonce during the 83 00:07:17,990 --> 00:07:22,479 4-way handshake. So here we're going [to] assume, that these ANonce and SNonce, that 84 00:07:22,479 --> 00:07:27,249 they are random and not predictable. The nonce reuse refers to nonce reuse that 85 00:07:27,249 --> 00:07:34,000 will happen during the encryption algorithm, which I will explain in a bit. 86 00:07:34,000 --> 00:07:40,249 That's it for the first stage of the 4-way handshake. The second stage of the 4-way 87 00:07:40,249 --> 00:07:47,429 handshake, a bit simplified, it basically confirms that both parties negotiate at 88 00:07:47,429 --> 00:07:51,999 the same PTK, the same encryption key. And in particular, the access point will send 89 00:07:51,999 --> 00:07:56,909 Message 3 to the client. The client will verify the authenticity of that frame and 90 00:07:56,909 --> 00:08:04,309 if everything looks ok, the client will reply using Msg4 to the access point. 91 00:08:04,309 --> 00:08:08,739 Once these four messages have been exchanged, both the client on the access 92 00:08:08,739 --> 00:08:15,569 point will install the PTK for use by the driver, so now data frames can be exchanged 93 00:08:15,569 --> 00:08:22,139 and these data frames will be encrypted. Ok, so now we covered the 4-way 94 00:08:22,139 --> 00:08:29,010 handshake, we know the highlight of how it works. Now the final thing I need to 95 00:08:29,010 --> 00:08:34,639 explain, before we can get to the details of the attack, is: How does encryption work 96 00:08:34,639 --> 00:08:40,059 in a Wi-Fi network? And to explain this, let's take the example here, where we want 97 00:08:40,059 --> 00:08:44,510 to send some plain text data from, e.g., from the client to the access 98 00:08:44,510 --> 00:08:49,399 point. Then the first thing that will happen, is that we will take the PTK and 99 00:08:49,399 --> 00:08:53,309 the fresh session key, that the 4-way handshake just negotiated and we will 100 00:08:53,309 --> 00:08:59,940 combine that with a packet number. And here, this packet number is called a nonce. 101 00:08:59,940 --> 00:09:04,750 The packet number is incremented by 1 for every frame, that is transmitted and the ID 102 00:09:04,750 --> 00:09:09,579 here is, that by combining the session key with the packet number we get a unique per 103 00:09:09,579 --> 00:09:15,930 packet key for every packet that we want to transmit. 104 00:09:15,930 --> 00:09:20,329 The way the encryption now works is fairly simple, we feed this per packet key as 105 00:09:20,329 --> 00:09:25,911 input to a stream cipher. We get us output some key stream, we simply XOR that key 106 00:09:25,911 --> 00:09:31,610 stream with the plaintext and the result is the encrypted data, the ciphertext. 107 00:09:31,610 --> 00:09:36,620 Now we prepense a plaintext header with some metadata and also the packet number, 108 00:09:36,620 --> 00:09:40,479 the nonce value, that we used, so the receiver will be able to decrypt the 109 00:09:40,479 --> 00:09:46,120 packet. Essentially, this is just a stream cipher, where a nonce is used to always 110 00:09:46,120 --> 00:09:52,899 derive a unique per packet key. Now there's one essential requirements in this 111 00:09:52,899 --> 00:09:58,000 encryption key. That is, that under a particular session 112 00:09:58,000 --> 00:10:04,300 key, a nonce value should only be used once, because if you ever reuse a nonce value, 113 00:10:04,300 --> 00:10:08,299 you will generate the same per packet key. You will generate the same key stream and 114 00:10:08,299 --> 00:10:12,080 this will allow you to decrypt packets, that are sent and depending on the 115 00:10:12,080 --> 00:10:19,359 specific stream cipher that is being used, it will also allow you to forge frames. 116 00:10:19,359 --> 00:10:20,549 *clears his throat* 117 00:10:20,549 --> 00:10:28,040 Now the question here is: Is this nonce value indeed only used once? And we already 118 00:10:28,040 --> 00:10:32,350 know, that it is incremented by one for every packet that is transmitted, so the 119 00:10:32,350 --> 00:10:37,070 only question that remains is: To what value is this packet number initialized? 120 00:10:37,070 --> 00:10:44,050 And the answer is quite simple: when the PTK is installed, this transmit nonce is 121 00:10:44,050 --> 00:10:49,279 initialized to 0. At first sight, this makes a lot of sense. 122 00:10:49,279 --> 00:10:53,550 I mean, you initiate that number to 0, you increment it by one for every packet, 123 00:10:53,550 --> 00:11:00,700 so surely this nonce is a specific nonce value, is only used once. 124 00:11:00,700 --> 00:11:06,959 Unfortunately, this is not the case. And the reason this nonce value or a particular 125 00:11:06,959 --> 00:11:11,930 nonce value is sometimes used more than once, is because we can force 126 00:11:11,930 --> 00:11:17,540 reinstallations of the PTK and those reinstallations will again reset the nonce 127 00:11:17,540 --> 00:11:23,980 to 0 and then nonce value will be reused. So, how can we force these key 128 00:11:23,980 --> 00:11:29,339 reinstallations as an attacker? Let's again take the example where we have 129 00:11:29,339 --> 00:11:34,660 a client on the left, that wants to connect to the access point on the right and in 130 00:11:34,660 --> 00:11:38,970 this case, we also have an attacker that sits in the middle and this attacker will 131 00:11:38,970 --> 00:11:45,410 assume a so-called channel-based man-in- the-middle position and in this-man-in-the- 132 00:11:45,410 --> 00:11:50,800 middle position, the adversary isn't yet able to decrypt any packets. This man-in- 133 00:11:50,800 --> 00:11:56,020 the-middle position is purely there, so we can reliably block packets from arriving 134 00:11:56,020 --> 00:12:01,909 and we can reorder the packet and so on. We are not breaking encryption yet. And the 135 00:12:01,909 --> 00:12:06,690 way we obtain this man-in-the-middle position is, we simply take all the frames 136 00:12:06,690 --> 00:12:11,250 that the access point which, e.g., is on Channel 6, we take all the frames 137 00:12:11,250 --> 00:12:16,250 that it is broadcasting and as an attacker, we capture them and we rebroadcast them, we 138 00:12:16,250 --> 00:12:21,220 retransmit them on a different channel, e.g. Channel 1. So we are effectively 139 00:12:21,220 --> 00:12:26,829 cloning the real access point on a rogue channel and then we force the victim into 140 00:12:26,829 --> 00:12:31,069 connecting to this rogue access point on this different channel. 141 00:12:31,069 --> 00:12:36,020 So let's assume now that the attacker obtains this position, this man-in-the- 142 00:12:36,020 --> 00:12:42,620 middle position and the first stage of the 4-way handshake, we don't modify any 143 00:12:42,620 --> 00:12:48,579 frames at all. So e.g. if the client is using 802.1x authentication, we 144 00:12:48,579 --> 00:12:52,800 simply forward all the frames between these two different channels and we do the 145 00:12:52,800 --> 00:12:56,600 same thing with the first three messages of the 4-way handshake, we simply 146 00:12:56,600 --> 00:13:03,970 forward them unmodified. Where the attack starts, is if the client sends Msg4 147 00:13:03,970 --> 00:13:08,990 of the 4-way handshake. Instead of forwarding this message to the access 148 00:13:08,990 --> 00:13:14,329 point, we don't forward it, which in our situation is equivalent to blocking the 149 00:13:14,329 --> 00:13:20,860 message from arriving at the access point. Now what's interesting in this situation, 150 00:13:20,860 --> 00:13:26,670 is that from the perspective of the client, the handshake now successfully completed. 151 00:13:26,670 --> 00:13:32,040 After all, it received Msg3, it replied using Msg4 and it thinks that 152 00:13:32,040 --> 00:13:35,860 the handshake is done, meaning it now installs the encryption key and installs 153 00:13:35,860 --> 00:13:44,439 the PTK for use. So, let's make some space here - the client thinks, that the handshake 154 00:13:44,439 --> 00:13:48,660 was completed, it has installed the key, but the access point hasn't received 155 00:13:48,660 --> 00:13:55,339 Msg4 yet and the access point will try to recover from this situation and it 156 00:13:55,339 --> 00:14:02,269 will do that by retransmitting a new Msg3. And as the - as we, as the 157 00:14:02,269 --> 00:14:06,620 attacker, will forward this message to the client, the client will accept this 158 00:14:06,620 --> 00:14:11,579 retransmitted Msg3 and then the Wi-Fi standard says, that if you receive a 159 00:14:11,579 --> 00:14:16,940 retransmitted Msg3, you will reply using a new Msg4. After that you will 160 00:14:16,940 --> 00:14:23,449 also install the encryption key again. Now, one remark that I want to make here, is 161 00:14:23,449 --> 00:14:30,519 that, when we receive the retransmitted Msg3, we reply using a new Msg4, 162 00:14:30,519 --> 00:14:36,149 however, this Msg4 will be already encrypted at the link layer and the reason 163 00:14:36,149 --> 00:14:40,980 it's already encrypted, is because these handshake messages are normal data frames 164 00:14:40,980 --> 00:14:45,879 and well, we already installed the encryption key to encrypt data frames. So 165 00:14:45,879 --> 00:14:51,610 nearly all implementations we tested, will send Msg4, the retransmitted Msg4, 166 00:14:51,610 --> 00:14:56,709 in an encrypted fashion. Now, I want to remark here, that the Wi-Fi standard 167 00:14:56,709 --> 00:15:02,649 actually demands that Msg4, if it is retransmitted, should be sent in plain text, 168 00:15:02,649 --> 00:15:07,020 so according to the specification, this shouldn't happen. But nearly all 169 00:15:07,020 --> 00:15:12,999 implementations we tested, sent a retransmitted Msg3 using encryption, 170 00:15:12,999 --> 00:15:17,730 and we will abuse this observation later. So as I mentioned, after the client 171 00:15:17,730 --> 00:15:22,339 receives a retransmitted Msg3, it'll reply using Msg4, it will again 172 00:15:22,339 --> 00:15:27,499 install the encryption key, and as a result of that, this transmit nonce will be 173 00:15:27,499 --> 00:15:34,160 reset, which means, that if the client now sends another data frame, it will again 174 00:15:34,160 --> 00:15:41,569 use this nonce value of 1 to encrypt the frame, meaning we have nonce reuse, and we 175 00:15:41,569 --> 00:15:46,220 have key stream reuse, meaning we can now try to abuse this to decrypt the data 176 00:15:46,220 --> 00:15:51,879 frame. Now, how are we precisely going to abuse 177 00:15:51,879 --> 00:15:57,740 this, because we do somehow need to recover the key stream that was used? And 178 00:15:57,740 --> 00:16:03,309 we go back to our observation, that we have a Msg4 here, that is initially sent in 179 00:16:03,309 --> 00:16:08,180 plain text, and a retransmission of Msg4 is later sent in an encrypted 180 00:16:08,180 --> 00:16:12,161 fashion. Now, there is a small difference between these two messages, but 181 00:16:12,161 --> 00:16:15,600 essentially we have a message sent in plaintext, and we have a message sent 182 00:16:15,600 --> 00:16:20,820 encrypted, and all we need to do, is we need to XOR these two messages and we have 183 00:16:20,820 --> 00:16:24,350 the key stream corresponding to the nonce value of 1. 184 00:16:24,350 --> 00:16:28,680 This data frame here at the bottom, it also uses nonce value of 1, meaning it 185 00:16:28,680 --> 00:16:33,130 uses the exact same key stream, so we XOR this packet with the key stream and there 186 00:16:33,130 --> 00:16:41,659 you go: We decrypted the packets and we have now defeated WPA2. So... 187 00:16:41,659 --> 00:16:50,530 *Applause* Thank you. So, that describes the attack 188 00:16:50,530 --> 00:16:56,129 against the 4-way handshake. And the 4-way handshake is not the only Wi-Fi 189 00:16:56,129 --> 00:17:00,310 handshake that is vulnerable. There are also other handshakes which can be 190 00:17:00,310 --> 00:17:05,140 attacked in a similar manner, but I'm not going to explain all of them in detail. If 191 00:17:05,140 --> 00:17:09,650 you want all the nitty-gritty details, I'm going to refer you to our academic paper. 192 00:17:09,650 --> 00:17:14,260 Here, I'm just going to discuss more the high-level concepts and the ideas behind 193 00:17:14,260 --> 00:17:18,880 the attack. So, e.g., one handshake that is also vulnerable, is the group key 194 00:17:18,880 --> 00:17:23,260 handshake, and that handshake is used to transport the group key from the access 195 00:17:23,260 --> 00:17:27,398 point to the client. And that key is used to encrypt broadcast and multicast 196 00:17:27,398 --> 00:17:33,570 traffic. Then we also have the FT handshake. The FT handshake is used, when 197 00:17:33,570 --> 00:17:38,460 you roam from one access point to another access point of the same Wi-Fi network. 198 00:17:38,460 --> 00:17:42,730 It's used so you can quickly switch from one access point to another without 199 00:17:42,730 --> 00:17:47,450 a long timeout. And finally, another handshake that's also vulnerable is the 200 00:17:47,450 --> 00:17:51,990 PeerKey handshake, and that's used when two clients want to communicate directly 201 00:17:51,990 --> 00:17:59,510 with one another. Okay, so I'm now going to discuss in a bit more detail, what the 202 00:17:59,510 --> 00:18:05,500 practical impact of our attacks are. And I'm first going to start with the general 203 00:18:05,500 --> 00:18:11,770 impact that a key reinstallation attack has. So, let's assume we have a device 204 00:18:11,770 --> 00:18:15,690 that's vulnerable. This device can either be a client device, e.g. it can be 205 00:18:15,690 --> 00:18:20,370 a smartphone, or a laptop, or these days it can even be a toaster. They have Wi-Fi 206 00:18:20,370 --> 00:18:26,970 as well. Or it can also be an access point. So if a client or access point is 207 00:18:26,970 --> 00:18:32,520 vulnerable to our key reinstallation attack, the first thing that generally 208 00:18:32,520 --> 00:18:38,930 always happens, if this device ever sends encrypted data frames, we can force it to 209 00:18:38,930 --> 00:18:44,929 reuse the nonce, which in turn we can use to decrypt frames. But that's not the only 210 00:18:44,929 --> 00:18:50,529 thing we can do when a device is vulnerable. Another thing we can do, is we can replay 211 00:18:50,529 --> 00:18:57,530 encrypted frames sent towards this device. Now, why is that the case? That's because 212 00:18:57,530 --> 00:19:02,500 if a key is reinstalled, not only is this transmit nonce reset to 0, but another 213 00:19:02,500 --> 00:19:08,380 parameter, which is called the replay counter, it is also reset to 0. And this 214 00:19:08,380 --> 00:19:12,490 replay counter, as the name implies, it's used to detect retransmissions, or 215 00:19:12,490 --> 00:19:18,690 it's used to detect malicious replays. If this counter is reset, we can also replay 216 00:19:18,690 --> 00:19:24,510 frames towards a vulnerable device. So, that's the general impact of a key 217 00:19:24,510 --> 00:19:33,110 reinstallation attack, but there are a lot of other factors which also influence the 218 00:19:33,110 --> 00:19:41,250 exact impact of the attack, and one of the things that probably has the biggest 219 00:19:41,250 --> 00:19:48,100 influence, is the encryptions cipher that is being used. So, e.g., these days 220 00:19:48,100 --> 00:19:52,350 it is quite common that Wi-Fi networks use AES CCMP. It's the most widely used 221 00:19:52,350 --> 00:19:58,659 encryption algorithm in Wi-Fi networks. Against this algorithm, the impact in a 222 00:19:58,659 --> 00:20:04,070 sense stays limited to only decrypting and replaying frames. It's not possible to 223 00:20:04,070 --> 00:20:10,230 abuse our key reinstallation attack to now forge frames. And really, we got lucky 224 00:20:10,230 --> 00:20:16,690 here, because this is the most widely used cipher, and against this cipher we cannot 225 00:20:16,690 --> 00:20:22,260 start to forge frames. Because, if we would have been using the older encryption 226 00:20:22,260 --> 00:20:28,130 algorithm, which is WPA TKIP, against that algorithm, we would be able to recover the 227 00:20:28,130 --> 00:20:32,200 Message Integrity Check key, which is basically just a fancy word for the 228 00:20:32,200 --> 00:20:37,179 authentication key. And once we have that authentication key, we would be able to 229 00:20:37,179 --> 00:20:44,880 forge frames that appear to be sent by the device under attack. Interestingly, lately 230 00:20:44,880 --> 00:20:50,100 there's also been a new encryption algorithm that is being introduced, and 231 00:20:50,100 --> 00:20:53,850 that algorithm is called GCMP. It's fairly new, so only a 232 00:20:53,850 --> 00:20:59,169 few devices currently support it, and currently it is being rolled out under the 233 00:20:59,169 --> 00:21:06,190 name of WiGig. Against this algorithm, the impact of a key reinstallation attack is 234 00:21:06,190 --> 00:21:14,000 really the worst, because here we can again recover the authentication key, but 235 00:21:14,000 --> 00:21:18,520 when we use GCMP, the same authentication key is used in both communication 236 00:21:18,520 --> 00:21:23,490 directions. So against GCMP, we would be able to forge frames that are sent from 237 00:21:23,490 --> 00:21:27,580 the client to the access point and also forge frames that appear to be sent 238 00:21:27,580 --> 00:21:32,630 from the access point to the client, while for the WPA-TKIP algorithm, we would only 239 00:21:32,630 --> 00:21:37,509 be able to forge frames, that appear to be sent by the device that is under attack. 240 00:21:37,509 --> 00:21:42,630 So, my opinion - this is a bit surprising, because GCMP is the latest encryption 241 00:21:42,630 --> 00:21:46,880 algorithm that is defined in the Wi-Fi standard, yet the impact against it would 242 00:21:46,880 --> 00:21:51,950 be the highest. So, this is also why I think we got lucky here, because if we 243 00:21:51,950 --> 00:21:55,490 would have found the attack, say maybe five or ten years later, and everyone 244 00:21:55,490 --> 00:22:01,710 would be using this algorithm, the impact would have been a lot worse. Another thing 245 00:22:01,710 --> 00:22:06,280 that influences the impact of the attack is, which specific handshake we are 246 00:22:06,280 --> 00:22:11,169 attacking. For example, if we attack the group key handshake, then the only thing 247 00:22:11,169 --> 00:22:14,159 we can do is, we can only replay, broadcast or 248 00:22:14,159 --> 00:22:20,390 multicast frames. Now, why is that the case? Why can't we decrypt broadcast or 249 00:22:20,390 --> 00:22:26,390 multicast frames, if a key reinstallation occurs? And the reason is, that if we 250 00:22:26,390 --> 00:22:30,150 attack the group key handshake, we are attacking the client, and the client is 251 00:22:30,150 --> 00:22:35,380 never sending actual encrypted broadcast frames, so will never reuse the transmit 252 00:22:35,380 --> 00:22:40,050 nonce when it encrypts frames, because it's never encrypting frames. Now, why is 253 00:22:40,050 --> 00:22:44,519 it, that the client never sends real encrypted broadcast frames? Well, the 254 00:22:44,519 --> 00:22:49,100 reason is quite simple. Let's say, we have the network layout shown here and the 255 00:22:49,100 --> 00:22:54,229 client on the left wants to send a broadcast frames to all the other clients. 256 00:22:54,229 --> 00:22:58,419 Now, what happens here, is that this client will send the data frame it wants to 257 00:22:58,419 --> 00:23:03,690 broadcast as a Unicast frame to the access point only, meaning it won't encrypt it 258 00:23:03,690 --> 00:23:09,980 yet under the group key. It's the access points that will broadcast this frame to 259 00:23:09,980 --> 00:23:14,149 all connected clients, and only the access point will then encrypt it using the group 260 00:23:14,149 --> 00:23:16,350 key, and this is to assure that all clients 261 00:23:16,350 --> 00:23:20,690 within range of the access point will receive this broadcast message. Now, for 262 00:23:20,690 --> 00:23:24,659 us, this means that only the access point is transmitting real encrypted broadcast 263 00:23:24,659 --> 00:23:28,940 frames, and in the group key handshake we cannot attack the access point. We are 264 00:23:28,940 --> 00:23:33,059 only attacking the client, meaning in practice, we can only replay broadcast 265 00:23:33,059 --> 00:23:37,560 frames to the client, at least if we are targeting the group key handshake. So, 266 00:23:37,560 --> 00:23:42,980 really, the impact is limited in practice if we attack this handshake, because 267 00:23:42,980 --> 00:23:47,769 generally, replaying broadcast data doesn't have a high impact. Though, I do want to 268 00:23:47,769 --> 00:23:53,250 note, that some home automation systems use broadcast traffic to, e.g., send 269 00:23:53,250 --> 00:23:59,250 commands to turn the device on or off, e.g. to turn your fridge on, or to turn 270 00:23:59,250 --> 00:24:03,970 lights on or off, so although the impact of replaying broadcast frame is 271 00:24:03,970 --> 00:24:08,120 low, there are situations in practice, where it does have some impact, but it 272 00:24:08,120 --> 00:24:13,090 really depends on your network setup and the devices that you use. So, the other 273 00:24:13,090 --> 00:24:17,129 handshake that is vulnerable, is the 4- way handshake, but we already discussed 274 00:24:17,129 --> 00:24:21,809 that. Against a 4-way handshake we can attack the clients and the impact, is that 275 00:24:21,809 --> 00:24:25,610 we can replay and decrypt frames, and depending on the encryption algorithm 276 00:24:25,610 --> 00:24:31,690 being used, we can possibly forge frames as well. The situation is a lot more 277 00:24:31,690 --> 00:24:36,080 interesting for the FT handshake, though. And remember, this handshake is used, when 278 00:24:36,080 --> 00:24:40,959 you roam from one access point to another of the same network. Against the FT 279 00:24:40,959 --> 00:24:45,669 handshake, it's not the clients that we can attack, but here we can attack the 280 00:24:45,669 --> 00:24:51,450 access point. And on top of that, when attacking the FT handshake, we no longer 281 00:24:51,450 --> 00:24:56,679 need this man-in-the-middle position. Now, why is that the case? Well, let's again 282 00:24:56,679 --> 00:25:01,370 explain this using our common example, where a client wants to connect and where 283 00:25:01,370 --> 00:25:08,330 it is executing the FT handshake. And at a high level, the FT handshake is the same 284 00:25:08,330 --> 00:25:11,520 as the 4-way handshake, meaning you also have four frames that are 285 00:25:11,520 --> 00:25:16,730 transmitted, but the big difference here is, that with the FT handshake it's the 286 00:25:16,730 --> 00:25:21,220 client that sends the first message in the handshake, while for the 4-way 287 00:25:21,220 --> 00:25:26,250 handshake it was the access point that sends the first message. So, the handshake 288 00:25:26,250 --> 00:25:29,860 is practically the same as the 4-way handshake, meaning, initially we have two 289 00:25:29,860 --> 00:25:34,190 messages that transport these random numbers, these nonces, between both 290 00:25:34,190 --> 00:25:40,770 devices. Then, both these endpoints can generate the fresh encryption key. Then 291 00:25:40,770 --> 00:25:46,090 the last two frames, they are again used to confirm that both parties negotiated 292 00:25:46,090 --> 00:25:51,210 the same encryption key. Now, I want to go in a bit more detail here on this last 293 00:25:51,210 --> 00:25:56,600 phase, and what happens here, is that the third frame of the handshake is now sent 294 00:25:56,600 --> 00:26:01,970 from the client to the access point and that is a reassociation request. And after 295 00:26:01,970 --> 00:26:06,779 the access point receives this frame, it will reply using a reassociation response 296 00:26:06,779 --> 00:26:12,799 frame and it will install the encryption key. Once it has installed the encryption 297 00:26:12,799 --> 00:26:18,590 key, it can of course start sending encrypted data frames. So, let's again 298 00:26:18,590 --> 00:26:23,820 make some room here. What we can now do as an attacker, is we can take this 299 00:26:23,820 --> 00:26:28,840 reassociation request that the client previously transmitted, and we can simply 300 00:26:28,840 --> 00:26:36,450 replay it. That's because in the FT handshake, there is no replay protection 301 00:26:36,450 --> 00:26:41,730 against messages of the handshake. So we can just take that frame, we can send it 302 00:26:41,730 --> 00:26:45,380 again to the access point. The access point will receive it, it will accept it, 303 00:26:45,380 --> 00:26:51,490 and it will reply using a reassociation response. Now, so far this is not a 304 00:26:51,490 --> 00:26:57,440 problem. The problem here is, that again the access point will reinstall the 305 00:26:57,440 --> 00:27:01,269 encryption key, and here it goes wrong because we are reinstalling this 306 00:27:01,269 --> 00:27:05,889 encryption key. The transmit nonce is again reset to 0, meaning if we now send 307 00:27:05,889 --> 00:27:11,930 the data frame again, the nonce value of 1 is used to encrypt these data frames, 308 00:27:11,930 --> 00:27:14,950 meaning the same key stream is used, meaning we can start applying the same 309 00:27:14,950 --> 00:27:19,029 tricks to first derive some known key stream and to then abuse that to attack 310 00:27:19,029 --> 00:27:24,250 the handshake. So, I want to highlight here a few things. And the first is, the 311 00:27:24,250 --> 00:27:27,740 reason why we don't need a man-in-the- middle position, is because handshake 312 00:27:27,740 --> 00:27:30,170 messages in the FT handshake, they are not protected 313 00:27:30,170 --> 00:27:34,720 against replays, while in the 4-way handshake, every handshake messages 314 00:27:34,720 --> 00:27:40,330 contains a sequence counter, where the receiver uses the sequence counter to 315 00:27:40,330 --> 00:27:44,450 detect replays, but for the FT handshake that's not the case, so we can just take 316 00:27:44,450 --> 00:27:48,090 these messages, we can replay them, and we don't need a man-in-the-middle position to 317 00:27:48,090 --> 00:27:55,351 block packets and to trigger retransmissions. Ok, so that's the 318 00:27:55,351 --> 00:28:01,630 explanation for the FT handshake. Another factor that can influence the impacts of 319 00:28:01,630 --> 00:28:06,660 our attack in practice, is which operating system and which device precisely we are 320 00:28:06,660 --> 00:28:12,120 attacking. And in particular, we see that iOS and Windows, they are not vulnerable 321 00:28:12,120 --> 00:28:17,970 against attacks against a 4-way handshake. And why is that the case? Well, 322 00:28:17,970 --> 00:28:22,360 that's because these two devices don't really follow the standard, and they don't 323 00:28:22,360 --> 00:28:26,659 accept retransmissions of Msg3, meaning we cannot abuse these 324 00:28:26,659 --> 00:28:33,180 retransmissions of Msg3 to trigger these key reinstallations. 325 00:28:33,180 --> 00:28:36,380 Now, I want to make two remarks here. And the first one is, that 326 00:28:36,380 --> 00:28:41,550 against these devices we can still attack the group key handshake. And particularly 327 00:28:41,550 --> 00:28:46,860 when looking at iOS, if we look at iOS version 11, it does implement the standard 328 00:28:46,860 --> 00:28:50,679 properly and it does accept retransmissions of Msg3, meaning that 329 00:28:50,679 --> 00:28:58,580 one is vulnerable to attacks against the 4-way handshake. Now, Linux is not much 330 00:28:58,580 --> 00:29:04,460 better, because if we look at the Wi-Fi client that is used on Linux, and for example on 331 00:29:04,460 --> 00:29:11,750 Android, it's called wpa_supplicant, and against wpa_supplicant 2.4 and higher, we 332 00:29:11,750 --> 00:29:17,919 notice that, if we try to perform a key reinstallation attack, it won't reinstall 333 00:29:17,919 --> 00:29:22,990 the secret key that was negotiated, but no, instead it will suddenly install an 334 00:29:22,990 --> 00:29:27,870 all-zero encryption key, and then it of course becomes very trivial to start 335 00:29:27,870 --> 00:29:36,919 decrypting data that this device is transmitting. Now, why does this happen? 336 00:29:36,919 --> 00:29:42,659 I can actually sort of understand why this went wrong. So, I'm going to explain what 337 00:29:42,659 --> 00:29:48,990 the implementation does wrong, to... why it installs this all-zero key. And to explain 338 00:29:48,990 --> 00:29:52,460 this, I'm going to assume that we have an Android device that is connecting to an 339 00:29:52,460 --> 00:29:56,660 access point. And we're going to zoom in a bit on the implementation of the Android. 340 00:29:56,660 --> 00:30:01,080 And we're going to look at two entities. We're first going to look at wpa_supplicant, 341 00:30:01,080 --> 00:30:05,330 which is represented by the handshake icon here, and we're also going 342 00:30:05,330 --> 00:30:10,429 to look at another entity, namely the Linux kernel. It's the Linux kernel that 343 00:30:10,429 --> 00:30:15,239 will be responsible for encrypting data frames, and wpa_ supplicant will be 344 00:30:15,239 --> 00:30:20,889 responsible for executing the 4-way handshake. And of course we assume, that we as an 345 00:30:20,889 --> 00:30:27,410 attacker are nearby, and we again have this man-in-the-middle position. So, what 346 00:30:27,410 --> 00:30:31,149 does an attacker have to do to cause this installation of an all-zero encryption 347 00:30:31,149 --> 00:30:36,780 key? Well, again, we simply let the first phase of the 4-way handshake execute 348 00:30:36,780 --> 00:30:42,460 normally, and when the access point sends Msg3 of the 4-way handshake, we 349 00:30:42,460 --> 00:30:48,679 forward that to the Android. Android will reply using Msg4. And we will 350 00:30:48,679 --> 00:30:53,510 again block Msg4 from arriving at the access point. 351 00:30:53,510 --> 00:30:58,090 Now, completely similar to the case with the 4-way handshake, the client thinks that 352 00:30:58,090 --> 00:31:02,019 the handshake now successfully completed, meaning it will install the encryption 353 00:31:02,019 --> 00:31:07,600 key. How it will install the encryption key is as follows: It commands the Linux 354 00:31:07,600 --> 00:31:15,059 kernel into installing the encryption key in the driver. And the driver itself will 355 00:31:15,059 --> 00:31:19,080 make a copy of the encryption key. And it will store it locally. And the driver can 356 00:31:19,080 --> 00:31:24,280 then encrypt frames. Now this means that wpa_supplicant, which is just a user land 357 00:31:24,280 --> 00:31:28,139 program, no longer needs to store the encryption key, meaning it will clear it 358 00:31:28,139 --> 00:31:34,270 from memory. What will happen now, if we continue with the attack, is that the 359 00:31:34,270 --> 00:31:38,969 access point will retransmit Msg3, because it did not receive Msg4. The 360 00:31:38,969 --> 00:31:42,790 client will again happily accept this retransmitted Msg3 and reply using 361 00:31:42,790 --> 00:31:48,289 Msg4. And again it will instruct the Linux kernel saying "Hey, please install 362 00:31:48,289 --> 00:31:52,389 this encryption key that is located at this address in the memory." But of 363 00:31:52,389 --> 00:31:56,789 course, that memory is now all zeros, because that key has just been cleared 364 00:31:56,789 --> 00:31:59,720 from memory. So, now it's basically commanding the Linux 365 00:31:59,720 --> 00:32:04,139 kernel into installing an all-zero encryption key. And the Linux kernel and 366 00:32:04,139 --> 00:32:09,080 driver will happily obey this command and they will install an all-zero encryption 367 00:32:09,080 --> 00:32:13,690 key, meaning at this point, all the data that the client is sending, is encrypted 368 00:32:13,690 --> 00:32:18,370 using a known key, so we can easily decrypt all the traffic, and of course we 369 00:32:18,370 --> 00:32:23,470 can also send any traffic we want to the client. Basically, we are now a rogue 370 00:32:23,470 --> 00:32:28,529 access point and we can manipulate the traffic of the client as we wish. 371 00:32:28,529 --> 00:32:37,699 *Applause* MV: Thank you. So, after this you might be 372 00:32:37,699 --> 00:32:42,940 wondering, "Well, gee, is my device vulnerable?" And you can test your own 373 00:32:42,940 --> 00:32:50,039 device using the following script. It's on github. I have tested the script on Kali 374 00:32:50,039 --> 00:32:54,870 Linux, on Arch Linux, and also on Ubuntu, so I could recommend using one of these 375 00:32:54,870 --> 00:33:00,270 distributions, and I also recommend to use a Wi-Fi dongle that we or someone else has 376 00:33:00,270 --> 00:33:05,409 tested ourselves, because we noticed that if you use our testing scripts with some 377 00:33:05,409 --> 00:33:08,960 older Wi-Fi devices, then there are some bugs in 378 00:33:08,960 --> 00:33:16,279 these Wi-Fi devices which cause our scripts to fail. And one way to also 379 00:33:16,279 --> 00:33:20,010 prevent our scripts to fail, is to disable hardware encryption. Now, how you should do 380 00:33:20,010 --> 00:33:25,409 that is also explained on this page. Using these scripts, you can test both your 381 00:33:25,409 --> 00:33:29,140 client devices, you can test against attacks against the 4-way handshake, 382 00:33:29,140 --> 00:33:33,799 the group key handshake, and there's also a script to test the access point, whether 383 00:33:33,799 --> 00:33:40,519 it's vulnerable against attacks against the FT handshake. Now, if you're going to 384 00:33:40,519 --> 00:33:45,500 try to see which devices are vulnerable, you are most likely going to see that 385 00:33:45,500 --> 00:33:52,559 quite some clients are still vulnerable to our attacks. Luckily, we can modify the 386 00:33:52,559 --> 00:33:58,129 access point to prevent attacks against the client. In particular, we can make 387 00:33:58,129 --> 00:34:02,620 additional modifications to the access point, such that the access points never 388 00:34:02,620 --> 00:34:07,149 retransmits Msg3 of the 4-way handshake, and that it also never 389 00:34:07,149 --> 00:34:11,640 retransmits the first message of the group key handshake. And if we do that, then 390 00:34:11,640 --> 00:34:17,060 clients that are connected to such a modified access points, they are no longer 391 00:34:17,060 --> 00:34:19,130 vulnerable against most attacks. There are 392 00:34:19,130 --> 00:34:24,660 still some edge cases where the device is vulnerable, but these have a very low 393 00:34:24,660 --> 00:34:29,909 impact. So, if we modify an access point in this way, then connected clients are no 394 00:34:29,909 --> 00:34:34,719 longer vulnerable. One downside here is, that because we are no longer 395 00:34:34,719 --> 00:34:40,530 retransmitting certain messages, it could be that especially in a noisy environment, 396 00:34:40,530 --> 00:34:44,520 because we don't retransmit these messages anymore, that the handshake may fail 397 00:34:44,520 --> 00:34:50,500 because the reliability is now less. Now, one thing I also want to remark here, 398 00:34:50,500 --> 00:34:57,310 that... if you have a router, which is vulnerable against our attack and a 399 00:34:57,310 --> 00:35:02,090 vendor says "Hey, we patched our router, so we patched our access point to defend 400 00:35:02,090 --> 00:35:07,400 against attacks," then this does not mean that this access point implements these 401 00:35:07,400 --> 00:35:10,780 countermeasures. Because these countermeasures, they are additional 402 00:35:10,780 --> 00:35:15,920 modifications on top of the normal patches to defend against the attack. So, 403 00:35:15,920 --> 00:35:21,130 only if a vendor explicitly says that "Our patches of the access point also prevent 404 00:35:21,130 --> 00:35:26,320 attacks against clients," then, only if they explicitly say that, are attacks 405 00:35:26,320 --> 00:35:32,640 against the client also prevented. Ok, so now I want to cover some misconceptions 406 00:35:32,640 --> 00:35:39,810 that have been floating around the internet. And the first one is, that some 407 00:35:39,810 --> 00:35:43,490 people claim, if you only patch the clients, or if you only patch the access 408 00:35:43,490 --> 00:35:46,980 point, then you're fine. But that's not the case. Because if you only patch the 409 00:35:46,980 --> 00:35:51,420 client and the access point is vulnerable, then we can still attack the access point. 410 00:35:51,420 --> 00:35:54,810 If the access point only contains these normal patches, the normal patches to 411 00:35:54,810 --> 00:36:00,021 defend against attacks, then connected clients are also still vulnerable. So, as 412 00:36:00,021 --> 00:36:05,660 I mentioned, connected clients are only defended, if the access point contains 413 00:36:05,660 --> 00:36:11,530 really extra modifications on top of the default patches. Now, another common 414 00:36:11,530 --> 00:36:17,081 misconception is, that some people might say "But, yeah, it's a cool attack, but 415 00:36:17,081 --> 00:36:22,490 you have to be close to the network in order to pull off these attacks." 416 00:36:22,490 --> 00:36:26,920 Unfortunately, that's not the case because we can use special antenna. And this 417 00:36:26,920 --> 00:36:30,171 special antenna, they can be made really cheap out of, e.g. just a 418 00:36:30,171 --> 00:36:36,040 tin can, and with this special antenna, we can manipulate Wi-Fi traffic from up to, 419 00:36:36,040 --> 00:36:41,450 say, 2 miles. And there are even leaked NSA documents, where the NSA is able to 420 00:36:41,450 --> 00:36:47,440 exploit a Wi-Fi network using other attacks from up to 8 miles away. Now, 421 00:36:47,440 --> 00:36:51,010 that's of course with a clear line of sight, but still this shows that you don't 422 00:36:51,010 --> 00:36:54,620 have to be physically close to the network. You can still be relatively far 423 00:36:54,620 --> 00:37:02,370 away. Another strange remark that I sometimes hear, is that you need to be 424 00:37:02,370 --> 00:37:06,630 connected to the network in order to pull off these attacks, which would basically 425 00:37:06,630 --> 00:37:10,440 mean, you need to know the password of the network to carry out the attacks. But 426 00:37:10,440 --> 00:37:14,540 that's not the case. As I mentioned, during the attacks, you only need to be 427 00:37:14,540 --> 00:37:19,740 close enough. You need to be able to manipulate some encrypted packets. But you 428 00:37:19,740 --> 00:37:23,740 don't need to know anything about the network. You simply need to know the 429 00:37:23,740 --> 00:37:27,210 network is there and there's a vulnerable client and access point and then you can 430 00:37:27,210 --> 00:37:34,450 start attacking them. One remark that I can understand, is that some people 431 00:37:34,450 --> 00:37:39,430 say that "Yeah, Ok, you can attack these handshakes, and you can decrypt data that 432 00:37:39,430 --> 00:37:43,630 is sent right after these handshakes, but generally right after you connect to an 433 00:37:43,630 --> 00:37:48,690 Wi-Fi network, you're not really sending interesting data, because at that point 434 00:37:48,690 --> 00:37:53,520 your device is sending e.g. ARP requests, or it's sending DHCP requests, 435 00:37:53,520 --> 00:37:59,770 or is just creating TCP connections. But no useful information is transmitted at 436 00:37:59,770 --> 00:38:06,260 this time." Unfortunately, at least for a defender, this is again not true. Because, 437 00:38:06,260 --> 00:38:10,090 what we can do as an attacker is, we can first let the client connect *blackout* out 438 00:38:10,090 --> 00:38:14,041 manipulating any traffic. The client, the victim, will then, e.g. start 439 00:38:14,041 --> 00:38:20,120 browsing the internet, start opening TCP connections, and in the middle 440 00:38:20,120 --> 00:38:24,070 of that, while the victim is e.g. surfing the internet, we can 441 00:38:24,070 --> 00:38:28,090 deauthenticate the client from the network, and all operating system will 442 00:38:28,090 --> 00:38:32,020 then immediately execute a new 4-way handshake. And once that 4-way 443 00:38:32,020 --> 00:38:37,500 handshake is then completed, it will send all the buffered TCP packets again 444 00:38:37,500 --> 00:38:41,280 to the access point and also in a reverse direction. So, basically, what we as an 445 00:38:41,280 --> 00:38:45,170 attacker can do, we can wait until we expect the victim to send interesting 446 00:38:45,170 --> 00:38:49,190 information. Then we deauthenticate the victim. It will execute a new handshake. 447 00:38:49,190 --> 00:38:56,010 And then we can decrypt the data that will be transmitted right after that handshake. 448 00:38:56,010 --> 00:38:59,520 Another thing that makes the attack possibly hard, is that obtaining this 449 00:38:59,520 --> 00:39:03,500 channel based man-in-the-middle is difficult. For example, you might be 450 00:39:03,500 --> 00:39:07,760 thinking that in order to force the clients to connect to the rogue access 451 00:39:07,760 --> 00:39:13,150 point, you need a stronger signal strength than a real access point. But again, 452 00:39:13,150 --> 00:39:17,870 that's not the case. And the reason this is not the case, is because we can use 453 00:39:17,870 --> 00:39:23,350 special Wi-Fi packets and so-called channel switch announcements, which 454 00:39:23,350 --> 00:39:28,680 command the client into switching to a different Wi-Fi channel, and effectively 455 00:39:28,680 --> 00:39:32,400 *blackout* to a rogue access point. So we don't need a high signal strength, we can simply 456 00:39:32,400 --> 00:39:36,520 command a victim into saying "Hey, switch to this channel and connect to our access 457 00:39:36,520 --> 00:39:40,820 point." And these frames are not authenticated, so we can just forge them 458 00:39:40,820 --> 00:39:47,780 as an attacker. Another thing you might say, that the complexity of the attack is 459 00:39:47,780 --> 00:39:52,871 hard, meaning it requires some expertise to implement this. And this is true. You 460 00:39:52,871 --> 00:39:59,110 do need to know a bit about Wi-Fi in order to make a proof of concept reliable, but 461 00:39:59,110 --> 00:40:03,480 as usual you only need to write this attack once, and then people can use your 462 00:40:03,480 --> 00:40:07,880 script in order to attack others. And this is similar to, e.g., memory 463 00:40:07,880 --> 00:40:13,350 corruption attacks, such as buffer overflows or stack overflows. Writing the 464 00:40:13,350 --> 00:40:17,040 proof of concept may be hard, but if you then give it to someone else, or if you 465 00:40:17,040 --> 00:40:22,000 put it in Metasploit or some other tool, all the user has to do, is basically start 466 00:40:22,000 --> 00:40:29,270 the script, and you can start attacking people. One other misconception that I 467 00:40:29,270 --> 00:40:35,630 sometimes encounter, is that people say "If you use AES-CCMP, this mitigates the 468 00:40:35,630 --> 00:40:41,840 attack." Again, unfortunately, this is not true, because the only advantage of using 469 00:40:41,840 --> 00:40:47,260 AES-CCMP is that the attacker can no longer forge frames. 470 00:40:47,260 --> 00:40:52,680 The attacker is still able to decrypt and replay frames. And finally, the last 471 00:40:52,680 --> 00:40:57,800 misconception is, that some people say that enterprise networks aren't vulnerable, 472 00:40:57,800 --> 00:41:02,830 because they e.g. don't execute the 4-way handshake. But again, 473 00:41:02,830 --> 00:41:07,450 unfortunately, that's wrong, because even these networks use the 4-way handshake 474 00:41:07,450 --> 00:41:13,610 and they can be attacked as well. So, then you have some people that say "OK, WPA2 is 475 00:41:13,610 --> 00:41:19,880 now completely broken. It's the end of the world and we're all doomed." Let's not get 476 00:41:19,880 --> 00:41:25,530 carried away, though. We can patch these vulnerabilities in a backwards compatible 477 00:41:25,530 --> 00:41:30,190 way. And as I illustrated here in my talk, the impact also really depends on the 478 00:41:30,190 --> 00:41:34,530 devices that you are using and your own network setup. So, sometimes the impact is 479 00:41:34,530 --> 00:41:38,150 actually really low, but of course sometimes the impact can be very high, 480 00:41:38,150 --> 00:41:43,250 e.g. if you have a Linux device, then attacker can do what he or she wishes, 481 00:41:43,250 --> 00:41:49,660 essentially. Now, for the last part of the talk, I'm going to discuss some lessons 482 00:41:49,660 --> 00:41:56,150 that we can learn from this attack and also the research. I think one of the most 483 00:41:56,150 --> 00:42:01,320 important and interesting observations - it's also the reason why I really like 484 00:42:01,320 --> 00:42:06,500 this attack myself - is that the 4-way handshake was proven to be secure. The 485 00:42:06,500 --> 00:42:11,270 encryption protocol, and in particular AES, has also been proven as secure. 486 00:42:11,270 --> 00:42:18,560 However, if we combine these two things, then suddenly we lose all security. And 487 00:42:18,560 --> 00:42:27,400 this is quite unfortunate. And what this teaches us, is that even though individual 488 00:42:27,400 --> 00:42:33,080 parts of a system were really investigated and perhaps formally analyzed, we also 489 00:42:33,080 --> 00:42:37,560 need to analyze the combination of these different entities and models, and we also 490 00:42:37,560 --> 00:42:43,540 need to prove that these combinations are secure as well. And another way to look at 491 00:42:43,540 --> 00:42:50,830 this, is that in the proof of the 4-way handshake, the authors, they modeled the 492 00:42:50,830 --> 00:42:56,780 handshake in a rather abstract way. And their proofs, specifically, they did not 493 00:42:56,780 --> 00:43:00,780 model retransmissions of handshake messages. And that's one of the things we 494 00:43:00,780 --> 00:43:06,310 abuse. So, on one hand we need to assure that we also look 495 00:43:06,310 --> 00:43:11,140 at the combinations of these different entities, but we also need to assure that 496 00:43:11,140 --> 00:43:17,080 the abstract models that we use reflect reality. Another thing that we can learn, 497 00:43:17,080 --> 00:43:21,690 is that we should keep the protocols and also the implementations simple. 498 00:43:21,690 --> 00:43:28,490 E.g., if we look at wpa_supplicant 2.6, when we were studying this version 499 00:43:28,490 --> 00:43:34,600 ourself, we thought it wasn't vulnerable to key reinstallation attacks. However, 500 00:43:34,600 --> 00:43:40,550 when we were notifying companies of the vulnerabilities, another researcher found 501 00:43:40,550 --> 00:43:46,800 an attack against this version which did work. The reason we missed this attack 502 00:43:46,800 --> 00:43:52,780 against version 2.6, is because wpa_supplicant uses a fairly complex 503 00:43:52,780 --> 00:43:57,600 implementation of the 4-way handshake and the state machine is fairly complex to 504 00:43:57,600 --> 00:44:02,690 reason about. And there are two ways to combat this. The first is to keep the 505 00:44:02,690 --> 00:44:07,210 protocol simple. The second way to combat this, is to formally verify 506 00:44:07,210 --> 00:44:12,630 implementations. Now of course, we cannot formally verify all the code, but what we 507 00:44:12,630 --> 00:44:17,410 can do is, really, these cryptographic protocols which play a very important 508 00:44:17,410 --> 00:44:23,950 role, at least we should pay enough attention to that. What's also 509 00:44:23,950 --> 00:44:29,330 interesting, is that I encountered a document of the CIA which also agrees, that 510 00:44:29,330 --> 00:44:34,220 complex implementations or protocols are bad. Specifically, they have a document, 511 00:44:34,220 --> 00:44:39,770 where the CIA advises people how to properly implement backdoors, essentially, 512 00:44:39,770 --> 00:44:44,760 and they're saying that "Yeah, if you want to send data back to us, of course, use 513 00:44:44,760 --> 00:44:48,970 encryption, but in that encryption algorithm, don't enable re-key 514 00:44:48,970 --> 00:44:53,451 functionality, because that enables additional features of the encryption 515 00:44:53,451 --> 00:44:58,860 algorithm. And these additional features, they cause unnecessary complexity and that 516 00:44:58,860 --> 00:45:05,031 generally leads to bugs." Another thing that we can learn, is that the standard 517 00:45:05,031 --> 00:45:10,560 needs to be specified rigorously and as precisely as possible. Because the 518 00:45:10,560 --> 00:45:17,500 original WPA2 standard, it was a bit fake. It didn't really define a state machine. 519 00:45:17,500 --> 00:45:23,720 Well, the state machine that it defined says, what an implementation - sorry - 520 00:45:23,720 --> 00:45:30,360 should do if it receives a message, but - let's go back to the slides - but it 521 00:45:30,360 --> 00:45:35,270 doesn't define what an implementation should do when it receives an unexpected 522 00:45:35,270 --> 00:45:41,550 message. So, it doesn't define the order, in which messages should be accepted. Now, 523 00:45:41,550 --> 00:45:46,760 there is an amendment of the Wi-Fi standard which better defines how and when 524 00:45:46,760 --> 00:45:52,820 to handle messages, but even that standard is a bit fake. And I want to remark here 525 00:45:52,820 --> 00:45:58,430 that because the original WPA2 standard was a bit fake, I can forgive iOS and 526 00:45:58,430 --> 00:46:02,250 Windows for deviating a bit from the standard. Because the standard was 527 00:46:02,250 --> 00:46:08,750 difficult to interpret correctly. Now, on a bit of a related note, I want to briefly 528 00:46:08,750 --> 00:46:13,760 mention a workshop that we are organizing, which is exactly about how to implement 529 00:46:13,760 --> 00:46:18,951 these security protocols properly, how to e.g. fuzz security protocols, how 530 00:46:18,951 --> 00:46:23,620 to prove that they are correct, how to make sure that we specify them rigorously. 531 00:46:23,620 --> 00:46:30,070 So, if you are working in this field, do consider submitting to this. Now, the last 532 00:46:30,070 --> 00:46:35,500 thing that I want to mention on what we can learn from this research, is how we 533 00:46:35,500 --> 00:46:42,520 can coordinate the disclosure of a vulnerability like this. Because this is 534 00:46:42,520 --> 00:46:45,730 not an ordinary vulnerability, that is, just affects one 535 00:46:45,730 --> 00:46:52,450 vendor, it really affects possibly every Wi-Fi device that is around. So, how on 536 00:46:52,450 --> 00:46:56,880 earth are you going to start notifying companies? Who are you going to notify? 537 00:46:56,880 --> 00:47:02,360 What would be the deadlines, and so on? Well, I'm going to discuss a bit about the 538 00:47:02,360 --> 00:47:07,750 strategy that we used, and what we used first is... we first wanted to determine, 539 00:47:07,750 --> 00:47:12,470 you know, is this really a widespread issue? We wanted to be sure of that before 540 00:47:12,470 --> 00:47:18,620 we started to notify a lot of companies. And the way we tackled that problem is, we 541 00:47:18,620 --> 00:47:25,040 first contacted a few selected vendors and we told them that "Hey, we possibly found 542 00:47:25,040 --> 00:47:30,630 this flaw in the WPA2 protocol, but we weren't able to test your devices, but you 543 00:47:30,630 --> 00:47:36,210 should check this out." And quite quickly we got a few responses from vendors, saying 544 00:47:36,210 --> 00:47:41,960 that "Yes, we looked at your attack and indeed, some of our devices are 545 00:47:41,960 --> 00:47:45,270 vulnerable," and this really confirmed to us, that a device 546 00:47:45,270 --> 00:47:49,500 that we didn't test ourself was vulnerable to the attack that we found. 547 00:47:49,500 --> 00:47:52,870 So, it confirmed that the issue is widespread, and we also got a bit of 548 00:47:52,870 --> 00:47:57,160 feedback on the report that we sent towards them on the description of our 549 00:47:57,160 --> 00:48:02,550 attack. So, at this point we were convinced ourselves, that this really was a 550 00:48:02,550 --> 00:48:07,870 flaw in the standard and that a lot of companies will be affected. Then the next 551 00:48:07,870 --> 00:48:12,620 question we had is, "Okay, who are we now all going to notify?" We of course 552 00:48:12,620 --> 00:48:16,240 notified the big names and the big companies, but who else do we have to 553 00:48:16,240 --> 00:48:22,810 notify? And at this point, our tactic was to rely on a CERT team, specifically a 554 00:48:22,810 --> 00:48:28,680 CERT from the US and they did all the coordination for us. 555 00:48:28,680 --> 00:48:33,760 But one other thing that you can do is, that if you're not sure who all is 556 00:48:33,760 --> 00:48:38,690 affected or what, who all the vendors are, then you can just ask a vendor that you 557 00:48:38,690 --> 00:48:42,760 contacted already for other vendors, that also might be affected 558 00:48:42,760 --> 00:48:48,790 by the bug that you found, e.g. Now one thing that is more difficult here, 559 00:48:48,790 --> 00:48:55,580 is that on one hand you want to notify as much vendors as possibly, on the other hand 560 00:48:55,580 --> 00:49:01,260 you also can't notify everyone because if you are going to notify everyone, then the 561 00:49:01,260 --> 00:49:10,450 chance of the details leaking, they become close to one. Another difficult thing to 562 00:49:10,450 --> 00:49:15,580 decide is, how long should you give time to companies in order to patch this. And again, 563 00:49:15,580 --> 00:49:23,110 here you're mixed between two decisions: on one hand you can give give them a long 564 00:49:23,110 --> 00:49:27,950 period to patch everything, but then again, the risk of this details leasing... err, 565 00:49:27,950 --> 00:49:33,300 leaking increase. On the other hand, if the embargo period is too short, people won't 566 00:49:33,300 --> 00:49:36,950 have time to patch it. So this is quite a hard decision. In the end, 567 00:49:36,950 --> 00:49:42,310 what we did is - and which I would again do in the future - is, it's hard to 568 00:49:42,310 --> 00:49:47,490 pick a deadline, but still do pick a deadline to avoid any uncertainty and so 569 00:49:47,490 --> 00:49:54,300 that people know, what to expect. And finally, I want to thank CERT and ICASI 570 00:49:54,300 --> 00:49:59,960 for helping with the coordination and you also want to thank Cisco for some of the 571 00:49:59,960 --> 00:50:05,700 advice that they give. So, with that I can conclude the talk, so 572 00:50:05,700 --> 00:50:11,980 what we discussed, is a flaw and the WPA2 standard itself and the most surprising 573 00:50:11,980 --> 00:50:17,770 thing about this research is, that WPA2 was proven to be correct, yet we still found 574 00:50:17,770 --> 00:50:23,041 his attack after more than a decade. And more than that, not only is this just a 575 00:50:23,041 --> 00:50:27,880 theoretical attack, the attack has actual impact and practice. 576 00:50:27,880 --> 00:50:32,740 And finally, in order to defend against this, you should update all your clients 577 00:50:32,740 --> 00:50:38,220 and also check if your access points are affected. So with that, thank you for your 578 00:50:38,220 --> 00:50:41,360 attention and if there are any questions, feel free to ask. 579 00:50:41,360 --> 00:50:50,510 *applause* 580 00:50:50,510 --> 00:50:52,650 Herald: So, do we have any questions? 581 00:50:52,650 --> 00:50:57,760 There is mics everywhere, so please come in front. And I think, we already have the 582 00:50:57,760 --> 00:51:01,770 first question directly here in front on mic number 1. 583 00:51:01,770 --> 00:51:11,540 Mic1: You mentioned, that GCMP is most vulnerable. Do you know if there's any 584 00:51:11,540 --> 00:51:18,300 standardization going on, about switching to nonce misuse resistant scheme like 585 00:51:18,300 --> 00:51:28,100 AES-GCM, Synthetic Initialization Vector? MV: Yes, so there have been 586 00:51:28,100 --> 00:51:33,710 some proposals in order to make the encryption algorithm defend against nonce 587 00:51:33,710 --> 00:51:40,020 reuse. Now the impression I have, that this is still a bit of ongoing research. So 588 00:51:40,020 --> 00:51:45,450 there are proposals, where you have an algorithm that you can use, but I'm not 589 00:51:45,450 --> 00:51:50,640 aware of actual encryption protocols, e.g. TLS or Wi-Fi, that are using them. 590 00:51:50,640 --> 00:51:54,790 But they exist, but I... they're not yet being really used. 591 00:51:54,790 --> 00:52:02,920 Mic1: It is standardisation going on in CFRG, so Crypto Forum Research Group in 592 00:52:02,920 --> 00:52:10,600 IETF standardization, but I was asking about Wi-Fi standardization, if they are planning 593 00:52:10,600 --> 00:52:20,230 to use this? And [a] related question would be, if you would use in AES-GCM instead of 594 00:52:20,230 --> 00:52:30,500 the deterministic initialization vector, there's a random IV possible, if you use 595 00:52:30,500 --> 00:52:38,850 96 bit, then the impact wouldn't be bounded. 596 00:52:38,850 --> 00:52:45,030 MV: So to answer the first question: I'm not aware of the Wi-Fi standard 597 00:52:45,030 --> 00:52:51,730 from really modifying the standard to use a nonce misuse resistant encryption 598 00:52:51,730 --> 00:52:57,340 cipher. They are modifying the standard to defend against key reinstallation attacks, 599 00:52:57,340 --> 00:53:00,820 but I think they're not yet going to incorporate a nonce misuse resistant 600 00:53:00,820 --> 00:53:05,430 encryption cipher, because they still have the impression that they're going to wait 601 00:53:05,430 --> 00:53:11,760 probably a while and once that technology is more mature they're going to use that. 602 00:53:11,760 --> 00:53:15,900 If I understood your second question, you also have encryption algorithms, where you 603 00:53:15,900 --> 00:53:20,550 don't have deterministic nonce, but you have a nonce, which for every encryption 604 00:53:20,550 --> 00:53:27,560 operation e.g. is random. Mic1: Actually in the GCM standard there 605 00:53:27,560 --> 00:53:32,470 are two possibilities: one deterministic, MV: Yeah. 606 00:53:32,470 --> 00:53:38,270 Mic1: and the second random. MV: So the risk of using a random 607 00:53:38,270 --> 00:53:43,130 initialization vector is, that you may have a bad random generator, 608 00:53:43,130 --> 00:53:52,010 that it can go wrong there. On that, that you still have nonce reuse, so even with a 609 00:53:52,010 --> 00:53:56,680 randomly generated nonce it can also go bad, but then there are different 610 00:53:56,680 --> 00:54:02,050 attacks. And I think, there has been a paper that analyzes a certain TLS 611 00:54:02,050 --> 00:54:07,210 libraries, where they do find attacks, where in that case the GCM algorithm can still 612 00:54:07,210 --> 00:54:11,930 be attacked, not through key reinstallation attacks, but because there is, because 613 00:54:11,930 --> 00:54:15,780 basically the nonce isn't really random, e.g. sometimes a bad implementation 614 00:54:15,780 --> 00:54:21,070 always uses the same random nonce. Person X: Um, direct answer... 615 00:54:21,070 --> 00:54:22,610 Herald: Err, sorry,... X: Direct answer to his question number 616 00:54:22,610 --> 00:54:30,590 one: because he asked, whether there's right now an approach to modify the 617 00:54:30,590 --> 00:54:38,340 standard towards being resistant against this attack, right now there is no IEEE 618 00:54:38,340 --> 00:54:46,170 task group working on an amendment which will fix this. 619 00:54:46,170 --> 00:54:50,910 MV: Well, there is... they are working to prevent the key reinstallation attack. 620 00:54:50,910 --> 00:54:54,320 X: Well, there is no official active task group right now. 621 00:54:54,320 --> 00:54:57,030 MV: Okay that could be, but there are still people working on that. 622 00:54:57,030 --> 00:54:58,980 X: Yeah, they're working on that, but no 623 00:54:58,980 --> 00:55:00,600 task group, right? MV: Ok. Thank you. 624 00:55:00,600 --> 00:55:03,400 Herald: Okay thank you. Here in number 3. 625 00:55:03,400 --> 00:55:07,510 Mic3: Yes, thanks for your amazing talk. 626 00:55:07,510 --> 00:55:11,320 Just for my personal understanding: could you briefly go back to 627 00:55:11,320 --> 00:55:17,370 the slide with the 4-way handshake, like, right in the beginning? 628 00:55:17,370 --> 00:55:21,010 MV: Yup, so the attack or the handshake itself? 629 00:55:21,010 --> 00:55:28,770 Mic3: Yeah, yeah the attack. MV: So let's go to this slide. 630 00:55:28,770 --> 00:55:37,270 Mic3: Yeah so all you get from this, is the keystream that is used to encrypt 631 00:55:37,270 --> 00:55:41,880 the the Msg4, right, that's all you get? 632 00:55:41,880 --> 00:55:45,550 MV: Yes, but you can already use that to start decrypting frames and what you can 633 00:55:45,550 --> 00:55:51,480 do as an attacker, you have several options. The first thing you can do is, you can keep 634 00:55:51,480 --> 00:55:54,960 triggering new handshakes by deauthenticating the client, so you can 635 00:55:54,960 --> 00:56:02,940 always decrypt one packet at a time. What you can also do is, you can wait with 636 00:56:02,940 --> 00:56:09,090 sending this retransmitted Msg3 to the clients, because sometimes you know 637 00:56:09,090 --> 00:56:12,090 the encrypted data that is sent. So you know that a packet is an ARP request, you 638 00:56:12,090 --> 00:56:16,650 know that the HTTP requests. You can capture quite some packets where you know the 639 00:56:16,650 --> 00:56:22,370 content, to derive some known key stream and once you have that, you can forward 640 00:56:22,370 --> 00:56:27,780 Msg3 to trigger a key reinstallation and then you have collected 641 00:56:27,780 --> 00:56:33,830 quite some key stream to be able to decrypt several packets at a time. So you 642 00:56:33,830 --> 00:56:38,910 can use tactics like that, you can rely on the packet length to basically determine, 643 00:56:38,910 --> 00:56:43,770 what the type of packet is, where you have known plaintext and you can use that to 644 00:56:43,770 --> 00:56:47,780 derive new key stream and there are a lot of ways to play around with that. 645 00:56:47,780 --> 00:56:51,680 Mic3: Yeah but, all you get here is the - because the key stream that you get is 646 00:56:51,680 --> 00:56:59,630 already being used immediately, because it's being used to encrypt Msg4. 647 00:56:59,630 --> 00:57:02,940 MV: Well, we know the content of Msg4 648 00:57:02,940 --> 00:57:08,550 and we abuse, that Msg4 is encrypted to derive known key stream and 649 00:57:08,550 --> 00:57:14,130 we can then use that to encrypt data frames, which we do not know and... we 650 00:57:14,130 --> 00:57:15,740 should discuss this offline. Mic3: Yeah. 651 00:57:15,740 --> 00:57:19,850 Herald: Perhaps this is for later discussion with more in detail. Now we 652 00:57:19,850 --> 00:57:24,750 switch to number two... number four, I think it is. Yeah, thanks. 653 00:57:24,750 --> 00:57:30,940 Mic4: Yes. Great find really and an awesome talk. Could you maybe elaborate a 654 00:57:30,940 --> 00:57:38,100 bit on how to still use the advantage of formal verification in the sense of, let's 655 00:57:38,100 --> 00:57:44,330 say, the flaws that it has, it gives a very false sense of security in your sense, how 656 00:57:44,330 --> 00:57:48,990 can you still benefit from formal verification? 657 00:57:48,990 --> 00:57:55,540 MV: Well, I think the attitude we should adopt is, that formal verification of code 658 00:57:55,540 --> 00:58:01,670 or of algorithms increases the amount of trust we can put into a program or into a 659 00:58:01,670 --> 00:58:07,450 protocol, but it's not just because it's formally verified that it's secure. 660 00:58:07,450 --> 00:58:12,270 Perhaps one of the attitudes that people had was: 'oh it's firmly verified, it must 661 00:58:12,270 --> 00:58:17,840 be fine'. We should abandon that attitude and instead we should say: "Ok, it's 662 00:58:17,840 --> 00:58:21,750 formally verified but, you know, let's check if the model they used reflects 663 00:58:21,750 --> 00:58:28,480 reality. Let's see if the proof is correct" and so on. So, we should still employ a 664 00:58:28,480 --> 00:58:33,470 formal verification but we should just treat it as additional evidence, that 665 00:58:33,470 --> 00:58:41,540 something looks secure. Herald: Ok, there's another question on mic 2 666 00:58:41,540 --> 00:58:47,250 Mic2: The first part is on the slide you're currently on. As far as I 667 00:58:47,250 --> 00:58:52,880 understood it in the talk, the retransmission of Msg4 is not 668 00:58:52,880 --> 00:58:56,860 supposed to be encrypted by the standard. MV: Correct. 669 00:58:56,860 --> 00:59:02,240 Mic2: So if you follow the standards, you shouldn't have a problem here. 670 00:59:02,240 --> 00:59:05,630 MV: No, then you still have a problem, because what you can then you do, is just 671 00:59:05,630 --> 00:59:10,000 wait for a data packet where you know that contents of, e.g.it can be an ARP 672 00:59:10,000 --> 00:59:14,660 request, you can derive most fields of that, it can be a DHCP request, it can be 673 00:59:14,660 --> 00:59:22,101 be a TCP SYN packet, or it can be some plain text HTML frames. E.g. there 674 00:59:22,101 --> 00:59:28,770 has been work to fingerprint the length of HTTP requests, to be able to determine 675 00:59:28,770 --> 00:59:32,440 which page you are visiting, so purely based on the length, we can determine the 676 00:59:32,440 --> 00:59:37,260 contents of the website you are looking for. We can then derive known plaintext 677 00:59:37,260 --> 00:59:44,020 and basically there are a lot of ways to predict the content of a frame, to then 678 00:59:44,020 --> 00:59:51,750 derive known keystream and to then trigger a key reinstallation attack to then abuse this. 679 00:59:51,750 --> 00:59:55,190 Herald: Ok we have time for one last question. Mic number 1? 680 00:59:55,190 --> 01:00:04,730 Mic1: Um, so as far as I understood your research, and so we, if we have like 11W 681 01:00:04,730 --> 01:00:11,240 deployed in the network, we are still vulnerable to the attack, because as 11W 682 01:00:11,240 --> 01:00:19,590 specifies the encryption, I'm supposed by this amendment, is also done by the 683 01:00:19,590 --> 01:00:28,020 encryption use on the network like before, so 11W is not really a way to secure 684 01:00:28,020 --> 01:00:33,690 the network? MV: Well, if I got it right, 11W is, one of 685 01:00:33,690 --> 01:00:36,380 the things it does, is protect the management's frames, if I'm correct? 686 01:00:36,380 --> 01:00:39,122 Mic1: Yes. MV: Yes. 687 01:00:39,122 --> 01:00:44,620 MV: So using that does not defend against these attacks. 688 01:00:44,620 --> 01:00:50,710 Herald: Ok, I think there's still quite details, where people are curious about, 689 01:00:50,710 --> 01:00:55,160 because it's everybody starting this question "as far as I understood". So I think, 690 01:00:55,160 --> 01:00:58,840 this was a really nice comprehensive talk and I want to thank you. And everybody who 691 01:00:58,840 --> 01:01:03,660 has more questions, perhaps can find you here and ask you more or have a look into 692 01:01:03,660 --> 01:01:06,990 the paper, perhaps read everything in detail there. 693 01:01:06,990 --> 01:01:11,540 So, please another big round of applause for Mathy and his amazing talk! 694 01:01:11,540 --> 01:01:13,276 Thank you very much. MV: Thank you! 695 01:01:13,276 --> 01:01:20,510 *applause* 696 01:01:20,510 --> 01:01:41,861 *34c3 outro*