 happy to be able to introduce our next speaker. Matty is a post-doc in network security and applied crypto. He took part in discovering and implementing quite some attacks in this field and especially in the wireless sector. And today he will show us that all our Wi-Fi devices are vulnerable. Especially the ones with Linux and Android. So I don't want to go into the technical details because he will do this. And I think if you're interested in even learning more about it, he even linked the research paper as well as the scripts and a website for this attack in the far plan. So for now, give a big round of applause for Matty van Hoef. Thank you for the introduction and thank you all for attending the talk even though it's already a bit late in the evening. Thank you CCC for allowing me to speak here. So today I'm going to talk about my research on WPA2 and you probably have already heard about this under the name of crack attacks. Now the history of this research is quite interesting because during my PhD, I was already researching the security of wireless networks. And during my PhD defense last year, when I was finishing up on writing my thesis, one of the jury members in my PhD asked, hey, you're recommending WPA2 with AES in your thesis. But are you sure that's really a secure solution? And last year my answer was, yeah, I mean it seems secure. It has been around for more than a decade. And if we ignore some brute force attacks against the password, if you select a secure password, then there are no real weaknesses that are known. On top of that, there are also mathematical proofs that state that if you have the four-way handshake on the encryption algorithm, that it's supposed to be secure. Unfortunately, a year later, I was staring at some open BSD code. In particular, I was looking at this function called IC set key. Now the details aren't important here yet, but this key installs the encryption key for use by the driver so frames get encrypted. And I was wondering what would happen if this function is called twice? And I was thinking like, will it reinstall the key? And what will happen when you reinstall the key? And it turns out that answering this question led to the attack I found on, as you know by now, this uncovered the flaw in WPA2. So in a sense, this talk is all about how I gave the wrong answer during my PhD defense. So to explain the attack, I will illustrate it against the four-way handshake. After that, I will discuss the impact of the attack in practice. Then I will go over some common misconceptions that have been floating around the Internet. And finally, I will discuss some lessons that we can learn from this research and from our findings. So let's get started with explaining the attack against the four-way handshake. And the first question I have to answer here is what exactly is this four-way handshake? And the four-way handshake is executed whenever you connect to a protected Wi-Fi network. So it's used when you connect to your home Wi-Fi network where you just have a pre-shared password. But it's also used in enterprise networks where you, for example, have a username on a password to log in. And the purpose of this handshake is to verify that you possess the correct credentials in order to connect to the network. And at the same time, this four-way handshake negotiates a fresh session key that will be used to encrypt data frames. And this session key is called the PTK, the pairwise temporal key. And as I mentioned, this handshake seemed to be really secure because for over a decade, no attacks have been founded against it, assuming that a secure password is being used. And on top of that, the four-way handshake was formally proven to be secure. On the encryption algorithm that is used after the four-way handshake, which generally is AAS CCMP, that was also formally proven to be secure. Yet somehow we did find an attack, even though we have all these formal proofs, even though this protocol has been around for that long. So what went wrong? To explain this, I'm going to explain how the four-way handshake works using this specific example. So let's say we have the clients on the right here that wants to connect to the access point on the left. Now in order to start the four-way handshake, there first needs to be some pre-shared secret between the client on the access point. And if you have a network at home, this pre-shared secret is basically the password of the network. But if you have an enterprise or a more professional network, then where you, for example, have to log in using a username on the password, then first 802.1x authentication algorithm is executed, which in practice is commonly some form of radius authentication. The details of that are not important. What's important here is the result, namely after this authentication phase, there is a shared secret between the client on the access point. And once we have this shared secret, we can execute the four-way handshake. And what the first two messages in the four-way handshake do is they transport a random number between both devices. So in particular, the access point will generate a random number called the access point nonce, the anons, and it will transport it to the client. Then in reaction to that, the client will generate its own random number called the supplicant nonce. And supplicant is basically a synonym for client. And it will send that random number, the s nonce, to the access point in the second message of the handshake. And once both devices have each other's random number, then we can derive this unique per session key. And how that key is derived is very simple. We take the pre-shared key that is known between these two devices. We combine that with both of these random numbers. And the result is the PTK, this fresh encryption key that will later be used to encrypt data frames. Now, I want to clarify one thing, and you might have heard about this research under the name key reinstallation attacks, forcing nonce reuse in WP2. I want to highlight here that the nonce reuse does not refer to the nonce reuse about the anons or s nonce during the four-way handshake. So here we're going to assume that these a nonce and s nonce that they are random and not predictable. The nonce reuse refers to nonce reuse that will happen during the encryption algorithm, which I will explain in a bit. Okay, so that's it for the first stage of the four-way handshake. The second stage of the four-way handshake, a bit simplified. It basically confirms that both parties negotiated the same PTK, the same encryption key. In particular, the access point will send message 3 to the client. The client will verify the authenticity of that frame. And if everything looks okay, the client will reply using message 4 to the access point. Once these four messages have been exchanged, both the client on the access point will install the PTK 4 used by the driver. So now data frames can be exchanged on these data frames will be encrypted. Okay, so now we covered the four-way handshake. We know the highlights of how it works. Now, the final thing I need to explain before we can get to the details of the attack is how does encryption work in a Wi-Fi network? To explain this, let's take the example here where we want to send some plain text data, for example, from the client to the access point. Then the first thing that will happen is that we will take the PTK, the fresh session key that the four-way handshake just negotiated, and we will combine that with a packet number. And here, this packet number is called a nonce. And the packet number is incremented by one for every frame that is transmitted. And the idea here is that by combining the session key with the packet number, we get a unique per packet key for every packet that we want to transmit. The way the encryption now works is fairly simple. We feed this per packet key as input to a stream cipher. We get us output some key stream. We simply XOR that key stream with the plain text. And the result is the encrypted data, the cipher text. Now, we prepend a plain text header with some metadata and also the packet number, the nonce value that we used. So the receiver will be able to decrypt the packet. So essentially, this is just a stream cipher where a nonce is used to always derive a unique per packet key. Now, there's one essential requirement in this encryption key. That is that under a particular session key, a nonce value should only be used once. Because if you ever reuse a nonce value, you will generate the same per packet key. You will generate the same key stream. And this will allow you to decrypt packets that are sent. And depending on the specific stream cipher that is being used, it will also allow you to forge frames. So now the question here is, is this nonce value indeed only used once? And we already know that is incremented by one for every packet that is transmitted. So the only question that remains is to what value is this packet number initialized? And the answer is quite simple. When the PTK is installed, this transmit nonce is initialized to zero. And at first sight, this makes a lot of sense. I mean, you initialize that number to zero, you incremented by one for every packet. So surely this nonce is a specific nonce value is only used once. Unfortunately, this is not the case. On the reason this nonce value or particular nonce value is sometimes used more than once is because we can force reinstallations of the PTK. And those reinstallations will again reset the nonce to zero. And then nonce value will be reused. So how can we force these key reinstallations as an attacker? Let's again take the example where we have a client on the left that wants to connect to the access point on the right. In this case, we also have an attacker that sits in the middle. And this attacker will assume a so-called channel-based man in the middle position. In this man in the middle position, the adversary isn't yet able to decrypt any packets. This man in the middle position is purely there so we can reliably block packets from arriving on that we can reorder the packet on so on. We are not breaking encryption yet. On the way we obtain this man in the middle position is we simply take all the frames that the access point which, for example, is on channel six, we take all the frames that it is broadcasting. As an attacker, we capture them until we re-broadcast them, we retransmit them on a different channel. For example, channel one. So we are effectively cloning the real access point on a rogue channel. Then we force the victim into connecting to this rogue access point on this different channel. So let's assume now that the attacker obtains this position, this man in the middle position. On the first stage of the four-way handshake, we don't modify any frames at all. So for example, if the client is using 802.1x authentication, we simply forward all the frames between these two different channels. Aren't we doing the same thing with the first three messages of the four-way handshake? We simply forward them unmodified. Where the attack starts, if the client sends message four of the four-way handshake, instead of forwarding this message to the access point, we don't forward it, which in our situation is equivalent to blocking the message from arriving at the access point. Now, what's interesting in this situation is that from the perspective of the client, the handshake now successfully completed. After all, it received message three, it replied using message four, and it thinks that the handshake is done, meaning it now installs the encryption key and installs the PTK for use. So let's make some space here. The client thinks that the handshake was completed, it has installed the key, but the access point hasn't received message four yet. The access point will try to recover from this situation, and it will do that by retransmitting a new message three. As we, as the attacker, will forward this message to the client, the client will accept this retransmitted message three, and then the Wi-Fi standard says that if you receive a retransmitted message three, you will reply using a new message four, and after that, you will also install the encryption key again. Now, one more mark that I want to make here is that when we receive the retransmitted message three, we reply using a new message four. However, this message four will be already encrypted at the link layer, and the reason it's already encrypted is because these handshake messages are normal data frames, and well, we already installed the encryption key to encrypt data frames. So nearly all implementations we tested will send message four, the retransmitted message four in an encrypted fashion. Now, I want to remark here that the Wi-Fi standard actually demands that message four, if it is retransmitted, should be sent in plain text. So according to the specification, this shouldn't happen, but nearly all implementations we tested sent a retransmitted message three using encryption, and we will abuse this observation later. So as I mentioned, after the client receives retransmitted message three, reply using message four, it will again install the encryption key. And as a result of that, this transmit nonce will be reset, which means that if the client now sends another data frame, it will again use this nonce value of one to encrypt the frame, meaning we have nonce reuse, and we have key stream reuse, meaning we can now try to abuse this to decrypt the data frame. Now, how are we precisely going to abuse this? Because we do somehow need to recover the key stream that was used. And we go back to our observation that we have a message four here that is initially sent in plain text, and a retransmission of message four is later sent in an encrypted fashion. Now, there is a small difference between these two messages, but essentially we have a message send in plain text, and we have a message sent encrypted. And all we need to do is we need to explore these two messages, and we have the key stream corresponding to the nonce value of one. And this data frame here at the bottom, it also uses nonce value of one, meaning it uses the exact same key stream. So we explore this packet with the key stream, and there you go, we decrypted the packet, and we have now defeated WPA2. So thank you. So, that describes the attack against the four-way handshake. The four-way handshake is not the only Wi-Fi handshake that is vulnerable. There are also other handshakes which can be attacked in a similar manner. But I'm not going to explain all of them in detail. If you want all the nitty gritty details, I'm going to refer you to our academic paper. Here, I'm just going to discuss more the high level concepts on the IDs behind the attack. So, for example, one handshake that is also vulnerable is the group key handshake. And that handshake is used to transport the group key from the access point to the client. And that key is used to encrypt broadcast and multicast traffic. Then we also have the FT handshake. The FT handshake is used when you roam from one access point to another access point of the same Wi-Fi network. It's used so you can quickly switch from one access point to another without a long timeout. And finally, another handshake that's also vulnerable is the peer key handshake. And that's used when two clients want to communicate directly with one another. Okay, so I'm now going to discuss in a bit more detail what the practical impact of our attacks are. And I'm first going to start with the general impact that a key reinstallation attack has. So, let's assume we have a device that's vulnerable. This device can either be a client device, for example, it can be a smartphone or a laptop or these days it can even be a toaster. They have Wi-Fi as well. Or it can also be an access point. So, if a client or access point is vulnerable to our key reinstallation attack, the first thing that generally always happens is that if this device ever sends encrypted data frames, we can force it to reuse the nonce, which in turn we can use to decrypt the data frames. But that's not the only thing we can do when the device is vulnerable. Another thing we can do is we can replay encrypted frames sent towards this device. Now, why is that the case? That's because if a key is reinstalled, not only is this transmit nonce reset to zero, but another parameter which is called the replay counter, it is also reset to zero. On this replay counter, as the name implies, it's used to detect retransmissions or it's used to detect malicious replays. If this counter is reset, we can also replay frames towards a vulnerable device. So, that's the general impact of a key reinstallation attack, but there are a lot of other factors which also influence the exact impact of the attack. One of the things that probably has the biggest influence is the encryption cipher that is being used. So, for example, these days it is quite common that Wi-Fi networks use AISCCMP. It's the most widely used encryption algorithm in Wi-Fi networks. Against this algorithm, the impact, in a sense, stays limited to only decrypting and replaying frames. It's not possible to abuse our key reinstallation attack to now forge frames. Really, we got lucky here because this is the most widely used cipher. Against this cipher, we cannot start to forge frames. Because if we would have been using the older encryption algorithm, which is WPATCIP, against that algorithm, we would be able to recover the message integrity check key, which is basically just a fancy word for the authentication key. Once we have that authentication key, we would be able to forge frames that appear to be sent by the device under attack. Interestingly, lately there's also been a new encryption algorithm that is being introduced. That algorithm is called GCMP. It's fairly new, so only a few devices currently supported. Currently, it is being rolled out under the name of YGIG. Against this algorithm, the impact of a key reinstallation attack is really the worst because here we can again recover the authentication key. But when we use GCMP, the same authentication key is used in both communication directions. So against GCMP, we would be able to forge frames that are sent from the client to the access point and also forge frames that appear to be sent from the access point to the client. While for the WPATCIP algorithm, we would only be able to forge frames that appear to be sent by the device that is under attack. So in my opinion, this is a bit surprising because GCMP is the latest encryption algorithm that is defined in the Wi-Fi standard, yet the impact against it would be the highest. So this is also why I think we got lucky here because if we would have found attack, say maybe five or 10 years later, on everyone would be using this algorithm, the impact would have been a lot worse. Another thing that influences the impact of the attack is which specific handshake we are attacking. For example, if we attack the group key handshake, then the only thing we can do is we can only replay broadcast or multicast frames. Now, why is that the case? Why can't we decrypt broadcast or multicast frames if a key reinstallation occurs? Well, the reason is that if we attack the group key handshake, we are attacking the client. The client is never sending actual encrypted broadcast frames. So it will never reuse the transmit nonce when it encrypts frames because it's never encrypting frames. Now, why is it that the client never sends real encrypted broadcast frames? Well, the reason is quite simple. Let's say we have the network layout shown here. On the client on the left wants to send a broadcast frame to all the other clients. Now, what happens here is that this client will send the data frame it wants to broadcast as a unicast frame to the access point only, meaning it won't encrypt it yet under the group key. It's the access point that will broadcast this frame to all connected clients and only the access point will then encrypt it using the group key. And this is to assure that all clients within range of the access point will receive this broadcast message. Now, for us, this means that only the access point is transmitting real encrypted broadcast frames. Well, in the group key handshake, we cannot attack the access point. We are only attacking the client, meaning in practice, we can only replay broadcast frames to the client, at least if we are targeting the group key handshake. So really, the impact is limited in practice if we attack this handshake because generally replaying broadcast frames is not a good idea. And the fact that the user doesn't have a high impact on the data doesn't have a high impact. So I do want to note that some home automation systems use broadcast traffic to, for example, send commands to turn the device on or off. For example, to turn your fridge on or to turn lines on or off. So although the impact of replaying broadcast frame is low, there are situations in practice where it does have some impact, but it is vulnerable is the four-way handshake, but we already discussed that. Against the four-way handshake, we can attack the client. The impact is that we can replay on the crypt frames. Depending on the encryption algorithm being used, we can possibly forge frames as well. The situation is a lot more interesting for the FT handshake, though. Remember, this handshake is used when you roam from one access point to another of the same network. Against the FT handshake, it's not the client that we can attack, but here we can attack the access point. On top of that, when attacking the FT handshake, we no longer need this man in the middle position. Now, why is that the case? Well, let's again explain this using our common example where a client wants to connect, where it is executing the FT handshake. At a high level, the FT handshake is the same as the four-way handshake, meaning you also have four frames that are transmitted. But the big difference here is that with the FT handshake, it's the client that sends the first message in the handshake. While for the four-way handshake, it was the access point that sends the first message. So the handshake is practically the same as the four-way handshake, meaning initially we have two messages that transport these random numbers, these nonsense, between both devices. Then both these endpoints can generate the fresh encryption key. Then the last two frames, they are again used to confirm that both parties negotiated the same encryption key. Now I want to go in a bit more detail here on this last phase. What happens here is that the third frame of the handshake is now sent from the client to the access point. That is a re-association request. After the access point receives this frame, it will apply using a re-association response frame, and it will install the encryption key. Once it has installed the encryption key, it can of course start sending encrypted data frames. So let's again make some room here. What we can now do as an attacker is we can take this re-association request that the client previously transmitted, and we can simply replay it. That's because in the FT handshake, there is no replay protection against messages of the handshake. So we can just take that frame, we can send it again to the access point. The access point will receive it, it will accept it, and it will apply using a re-association response. Now so far, this is not a problem. The problem here is that again the access point will reinstall the encryption key. And here it goes wrong because we are reinstalling this encryption key. The password nonce is again reset to zero, meaning if we now send the data frame against the nonce value of one is used to encrypt these data frames, meaning the same key stream is used, meaning we can start applying the same tricks to first derive some known key stream and to then abuse that to attack the handshake. So I want to highlight here a few things. On the first is the reason why we don't need a man in the middle position is because handshake messages in the FT handshake, they are not protected in the FT handshake. In the FT handshake, every handshake message contains a sequence counter where the receiver uses the sequence counter to detect replays. But for the FT handshake, that's not the case, so we can just take these messages, we can replay them and we don't need a man in the middle position to block packets and to trigger retransmissions. So that's the explanation for the FT handshake. Another factor that can influence the impact of our attack and practice is which operating system and which device precisely we are attacking. In particular, we see that iOS and Windows, they are not vulnerable against attacks against the FT handshake. And why is that the case? Well, that's because these two devices don't really follow the standard and they don't accept retransmissions of message 3. Meaning we cannot abuse these retransmissions of message 3 to trigger these key installations. Now, I want to make two remarks here. The first one is that against these devices we can still attack the group key handshake. Particularly when looking at iOS, if we look at iOS version 11, it does implement the standard properly and it does accept retransmissions of message 3, meaning that one is vulnerable to attacks against the 4-way handshake. Now, Linux is not much of a problem because if we look at Wi-Fi client that is used on Linux and, for example, on Android, it's called WPA supplicant and against WPA supplicant 2.4 and higher, we notice that if we try to perform a key reinstallation attack, it won't reinstall the secret key that wasn't negotiated, but no, instead it will suddenly install an all-zero encryption key. And then, of course, it becomes very trivial to start decrypting data that this device is transmitting. Now, why does this happen? I can actually sort of understand why this went wrong, so I'm going to explain what implementation does wrong to why it installs this all-zero key. To explain this, I'm going to assume that we have an Android device that is connecting to an access point and we're going to zoom in a bit on the application of the Android, and we're going to look at two entities. We're first going to look at WPA supplicant, which is represented by the handshake icon here, and we're also going to look at another entity, namely the Linux kernel, and it's the Linux kernel that will be responsible for encrypting data frames, and WPA supplicant will be responsible for executing the four-way handshake. And, of course, we assume that we as an attacker are nearby, and we have this man in the middle position. So, what does an attacker have to do to cause this installation of an all-zero encryption key? Well, again, we simply let the first face of the four-way handshake execute. Normally, when the access point sends message three of the four-way handshake, we forward that to the Android, Android RoboPri using message four. We will again block message four from arriving at the access point. Now, completely similar to the case with the four-way handshake, the client thinks that the handshake now successfully completed, meaning it will install the encryption key. How it will install the encryption key is as follows. It commands the Linux kernel into installing the encryption key in the driver. The driver itself will make a copy of the encryption key, and it will store it locally, and the driver will be able to install the encryption key in the driver. The driver will also be able to install the encrypted frames. Now, this means that WPA supplicant, which is just a user LAN program, no longer needs to store the encryption key, meaning it will clear it from memory. What will happen now if we continue with the attack is that the access point will retransmit message three, because it did not receive message four. The client will be able to install the encryption key in the driver, and it will be located at this address in the memory. But, of course, that memory is now all zeros because that key has just been cleared from memory. So now it's basically commanding the Linux kernel into installing an all zero encryption key, and the Linux kernel and driver will happily obey this command, and they will install an all zero encryption key, meaning at this point, all the data that the client will be able to access and, of course, we can also send any traffic we want to the client. Basically, we are now a rogue access point, and we can manipulate the traffic of the client as we wish. Thank you. So, after this, you might be wondering, well, gee, is my device vulnerable? And you can test your own device using the following script. It's on GitHub. I have tested this script on Linux, on Arch Linux, and also on Ubuntu, so I recommend using one of these distributions. I also recommend to use a Wi-Fi dongle that we or someone else has tested ourselves, because we notice that if you use our testing scripts with some older Wi-Fi devices, then there are some bugs in these Wi-Fi devices which cause our scripts to fail. One way to also prevent our scripts to fail is to use a local hardware encryption. Now, how you should do that is also explained on this page. Using these scripts, you can test both your client devices. You can test against attacks against the four-way handshake, the group handshake. There's also a script to test the access point, whether it's vulnerable against attacks against the FT handshake. Now, if you're going to try to see which devices are vulnerable, your clients are still vulnerable to our attacks. Luckily, we can modify the access point to prevent attacks against the client. In particular, we can make additional modifications to the access point such that the access point never retransmits message 3 of the four-way handshake and that it also never retransmits the first message of the group handshake. And if we do that, then clients that are connected to access points, they are no longer vulnerable against most attacks. There are still some edge cases where the device is vulnerable, but these have a very low impact. If we modify an access point in this way, then connected clients are no longer vulnerable. One downside here is that because we are no longer retransmitting certain messages, it could be that especially in a noisy environment because we don't retransmit these messages anymore that the handshake may fail because the reliability is now less. One thing I also want to remark here that if you have a router which is vulnerable against our attack, a vendor says hey, we patched our router, so we patched our access point to defend against the attacks, then this does not mean that this access point implements these countermeasures because these countermeasures, they are additional modifications on top of the normal patches to defend against attack. Only if a vendor explicitly says that our patches of the access point also prevent attacks against clients, then only if they explicitly say that our attacks against the client also prevent it. Now I want to cover some misconceptions that have been floating around the internet. The first one is that some people claim if you only patch the client or if you only patch the access point, then you're fine. But that's not the case because if you only patch the client, on the access point is vulnerable, then we can still attack the access point. If the access point only contains these normal patches, the normal patches to defend against attacks, then connected clients are also still vulnerable. So as I mentioned, connected clients are only defended if the access point contains extra modifications on top of the default patches. Now another common misconception is that some people might say, but yeah, it's a cool attack, but you have to be close to the network in order to pull off these attacks. Unfortunately, that's not the case because we can use a special antenna. On the special antenna, they can be made really cheap out of, for example, just a thin can. And with the special antenna, we can manipulate Wi-Fi traffic from up to, say, two miles. There are even leaked NSA documents where the NSA is able to exploit a Wi-Fi network using other attacks from up to eight miles away. Now that's of course with a clear line of sight, but still this shows that you don't have to be physically close to the network. You can still be relatively far away. Another strange remark that I sometimes hear is that you need to be connected to the network in order to pull off these attacks, which would basically mean you need to know the password of the network to carry out the attacks, but that's not the case. As I mentioned, during the attacks, you only need to be close enough. You need to be able to manipulate some encrypted packets, but you don't need to know anything about the network. You simply need to know the network is there, and there's a vulnerable client on access point, and then you can start attacking them. One remark that I can understand is that some people say that, yeah, okay, you can attack these handshakes, and you can decrypt data that is sent right after these handshakes, but generally right after you connect to a Wi-Fi network, you're not really sending interesting data, because at that point your device is sending, for example, ARP requests, or it's sending DHCP requests, or it's just creating TCP connections, but no useful information is transmitted at this time. Unfortunately, at least for a defender, this is again not true, because what we can do as an attacker is we can first let the client connect without manipulating any traffic. The client, the victim, will then, for example, start browsing the internet, start opening TCP connections, and in the middle of that, while the victim is, for example, surfing the internet, we can de-authenticate the client from the network, and all operating system will then immediately execute a new four-way handshake. And once that four-way handshake is then completed, it will send all the buffered TCP packets again to the access point, and also in the reverse direction. So basically, what we as an attacker can do, we can wait until we expect the victim to send interesting information, then we de-authenticate the victim, it will execute a new handshake, and then we can decrypt the data that will be transmitted right after that handshake. Another thing that makes that tech possibly hard is that obtaining this channel-based access point again in the middle is difficult. For example, you might be thinking that in order to force a client to connect to the rogue access point, you need a stronger signal strength than a real access point. But again, that's not the case. The reason this is not the case is because we can use special Wi-Fi packets on so-called channel switch announcements, which command a client into switching to a different Wi-Fi channel and connecting to a rogue access point. So we don't need a high signal strength, we can simply command a victim into saying, hey, switch to this channel and connect to our access point. These frames are not authenticated, so we can just forge them as an attacker. Another thing you might say that the complexity of the tech is hard, meaning it requires some expertise to implement this. This is true, you do need to know a bit about Wi-Fi in order to make a proof-of-concept reliable, but as usual, you only need to write this attack once and then people can use your script in order to attack others. This is similar to, for example, memory corruption attacks, such as buffer overflows or stack overflows, writing the proof-of-concept may be hard, but if you then give it to someone else or if you put it in metasploit or some other tool, all a user has to do is basically start the script and you can start attacking people. One other misconception that I sometimes encounter is that people say if you use AESCCMP, this mitigates the attack. Again, unfortunately, this is not true because the only advantage of using AESCCMP is that the attacker can no longer forge frames. The attacker is still able to decrypt on replay frames. Finally, the last misconception is that some people say that enterprise networks aren't vulnerable because they, for example, don't execute the four-way handshake. Again, unfortunately, that's wrong because even these networks use the four-way handshake and they can be attacked as well. Then you have some people that say OK, WPA2 is now completely broken. It's the end of the world and we're all doomed. Let's not get carried away though. We can patch these vulnerabilities in a backwards-compatible way and as I illustrated here in my talk, the impact also really depends on the devices that you are using on your own network setup. Sometimes the impact is actually really low, but of course sometimes the impact can be very high. For example, if you have a Linux device, then an attacker can do what he or she wishes, essentially. For the last part of the talk, I'm going to discuss some lessons that we can learn from this attack and also the research. I think one of the most important and interesting observations and it's also the reason why I really like this attack myself is that the four-way handshake was proven to be secure. The encryption protocol in particular AES has also been proven as secure. However, if we combine these two things then suddenly we lose all security. It's quite unfortunate and what this teaches us is that even though individual parts of a system were really investigated on perhaps formally analyzed, we also need to analyze the combination of these different entities on models and we also need to prove that these combinations are secure as well. Another way to look at this is that in the proof of the four-way handshake, the authors they modeled the handshake in a rather abstract way. In their proofs, specifically they did not model retransmissions of handshake messages and that's one of the things we abuse. So on one hand we need to assure that we also look at the combinations of these different entities but we also need to assure that the abstract models that we use reflect reality. Another thing that we can learn is that we should keep the protocols and also the implementations simple. For example, if we look at WPA supplicant 2.6 when we were studying this version ourselves we thought it wasn't vulnerable to key reinstallation attacks. However, when we were notifying companies of the vulnerabilities another researcher found an attack against this versions which did work and the reason we missed this attack against version 2.6 is because WPA supplicant uses a fairly complex implementation of the four-way handshake and the state machine is fairly complex to reason about. There are two ways to combat this. The first is to keep the protocol simple the second way to combat this is to formally verify implementations. Now of course we cannot formally verify all the codes but what we can do is really these cryptographic protocols which play a very important role at least we should pay enough attention to that. What's also interesting is that I encountered a document of the CIA which also agrees that complex implementations or protocols are bad. Specifically, they have a document where the CIA advises people how to properly implement backdoors essentially and they're saying that if you want to send data back to us of course use encryption but in that encryption algorithm don't enable rekey functionality because that enables additional features of the encryption algorithm on these additional features they cause unnecessary complexity and that generally leads to bugs. Another thing that we can learn is that the standard needs to be specified rigorously as precisely as possible because the original WP2 standard it was a bit fake. It didn't really define a state machine well the state machine that it defined says what an implementation sorry what an implementation should do if it receives a message let's go back to the slides but it doesn't define what an implementation should do when it receives an unexpected message so it doesn't define the order in which messages should be accepted now there is an amendment of the Wi-Fi standard which better defines how and when to handle messages but even that standard is a bit fake I want to remark here that because the original WP2 standard was a bit fake I can forgive iOS on Windows for deviating a bit from the standard because the standard was difficult to interpret correctly now on a bit of a related note I want to briefly mention a workshop that we are organizing which is exactly about how to implement these security protocols properly how to for example, first security protocols how to prove that they are correct how to make sure that we specify them rigorously so if you are working in this field do consider submitting to this now the last thing that I want to mention on what we can learn from this research is how we can coordinate the disclosure of a vulnerability like this because this is not an ordinary vulnerability that just affects one vendor it really affects possibly every Wi-Fi device that is around so how on earth are you going to start notifying companies who are you going to notify what will be the deadlines and so on well I am going to discuss a bit about the strategy that we used and what we used first is we first wanted to determine is this really a widespread issue we wanted to be sure of that before we started to notify a lot of companies and the way we tackled that problem is we first contacted a few selected vendors and we told them that hey we possibly found this flaw in the WPA2 protocol but we weren't able to test your devices but you should check this out and quite quickly we got a few responses from vendors saying that yes we looked at your attack and indeed some of our devices are vulnerable and this really confirmed to us that a device that we didn't test ourselves was vulnerable to the attack that we found so it confirmed that the issue is widespread and we also got a bit of feedback on the report that we sent towards them on the description of our attack so at this point we were convinced ourselves that this really was a flaw and a standard on that a lot of companies will be affected then the next question we had is okay who are we now all going to notify we of course notified the big names on the big companies but who else do we have to notify and at this point our tactic was to rely on a SIRT team specifically SIRT from the US and they did all the coordination for us but one other thing that you can do is that if you are not sure who all is affected or who all the vendors are then you can just ask a vendor that you contacted already for other vendors that also might be affected by the bug that you found for example now one thing that is more difficult here is that on one hand you want to notify as much vendors as possible on the other hand you also can't notify everyone because if you are going to notify everyone then the chance of the details leaking they become close to one another difficult thing to decide is how long should you give time to companies in order to patch this on again here you are mixed between two decisions on one hand you can give them a long period to patch everything but then again the risk of these details leaking increase on the other hand if the embargo period is too short people won't have time to patch it so this is quite a hard decision and then what we did is on which I would again do in the future is it's hard to pick a deadline but still do pick a deadline to avoid any uncertainty so that people know what to expect and finally I want to thank CERT on the ICASI for helping with the coordination and I also want to thank Cisco for some of the advice that they give so with that I can conclude the talk so what we discussed is a flaw in the WPA2 standard itself and the most surprising thing about this research is that WPA2 was proven to be correct yet we still found this attack after more than a decade on more than that not only is it just a theoretic attack the attack has actual impact and practice and finally in order to defend against this you should update all your clients and also check if your access points are affected so with that thank you for your attention and if there are any questions feel free to ask so do we have any questions just mics everywhere so please come in front and I think we already have the first question directly here in front on mic number one you mentioned that GCMP is most vulnerable do you know if there is any standardization going on about switching to non-missuse resistant scheme like ASGCM synthetic initialization vector yes so there have been some proposals in order to make the encryption algorithm defend against non-missuse now the impression I have that this is still a bit of ongoing research so there are proposals where you have an algorithm that you can use but I'm not aware of actual encryption protocols for example TLS or Wi-Fi that are using them but they exist but they are not yet being really used going on in CFRG so Cryptoform Research Group in ITF standardization but I was asking about Wi-Fi standardization if they are planning to use this and a related question would be if you would use in ASGCM instead of the deterministic initialization vector there is a random EV possible if you use 96 bit then the impact wouldn't be bounded so to answer the first question I'm not aware of the Wi-Fi standard from really modifying the standard to use a non-missuse resistant encryption cipher they are modifying the standard to defend against key re-installation attacks but I think they're not yet going to incorporate a non-missuse resistant encryption cipher because they still have the impression that they're going to wait probably a while and once that technology is more mature they're going to use that if I understood your second question you also have encryption algorithms that don't have a deterministic nonce but you have a non-switch for every encryption operation for example is random actually in the GCM standard there are two possibilities one deterministic and the second to random so the risk of using random initialization vector is that you may have a bad random generator until it can go wrong there that you still have nonce reuse so even with a randomly generated nonce it can also go bad but then there are different attacks and I think there has been a paper that analyzes certain TLS libraries where they do find attacks where in that case the GCM algorithm can still be attacked not through key re-installation attacks but because basically the nonce isn't really random for example sometimes bad implementations always uses the same random nonce direct answer to his question number one because he asked whether there is right now an approach to modify the standard towards being resistant against this attack right now there is no IEEE taskgroup working on the amendment which will fix this well there is they are working to prevent the key re-installation attack there is no official active taskgroup right now that could be but there are still people working on that they are working on that but no taskgroup right thank you number three thanks for your amazing talk just for my personal understanding would you briefly go back to the slide with the four-way handshake right in the beginning yep so the attack or the handshake itself yeah the attack so let's go to this slide yeah so all you get from this is the key stream that is used to encrypt the message for right that's all you get yes but you can already use that to start decrypting frames on what you can do as an attacker you have several options the first thing you can do is you can keep triggering new handshakes by de-authenticating the client so you can always decrypt one packet at a time what you can also do is you can wait with sending this retransmission to the client because sometimes you know the encrypted data that is sent so you know that a packet is an ARP request you know that the HCP request you can capture quite some packets where you know the content to derive some known key stream once you have that you can forward message to trigger a key reinstallation and then you have collected quite some key stream to be able to decrypt several packets at a time so you can use tactics like that you can rely on the packet length to basically determine what the type of packet is where you have known plain text and you can use that to derive new key stream there are a lot of ways to play around with that yeah but all you get here is the key stream that you get is already being used immediately because it's being used to encrypt message number 4 well we know the content of message 4 and we abuse that message 4 is encrypted to derive known key stream and we can then use that to encrypt data frames which we do not know we should discuss this offline yeah perhaps this is for a later discussion with more in detail now we switch to number 2 number 4 I think thanks great find really and an awesome talk could you maybe elaborate a bit on how to still use the advantage of formal verification in the sense of let's say the flaws that it has it gives a very false sense of security in the sense how can you still benefit from formal verification well I think the attitude we should adopt is that formal verification of code or of algorithms increases the amount of trust we can put into a program or into a protocol but it's not just because it's formally verified that it's secure perhaps one of the attitudes that people had was oh it's formally verified it must be fine we should abandon that attitude and instead we should say okay it's formally verified but let's check if the model they used reflects reality let's see if the proof is correct and so on so we should still employ formal verification but we should just treat it as additional evidence that something looks secure okay there's another question on mic number 2 the first part is on the slide you are currently on as far as I understood it in talk the retransmission of message 4 is not supposed to be encrypted by the standard so if you follow the standards you shouldn't have a problem here no then you still have a problem because what you can then do is just wait for a data packet where you know the contents of for example it can be an R request you can derive most fields of that it can be a DHCP request it can be a TCP SIN packet or it can be some plain tech HTML frames for example there has been work to finger print the length of HTTP request to be able to determine which page you are visiting so purely based on the length we can determine the contents of the website you are looking for we can then derive known plain text and basically there are a lot of ways to predict the content of a frame to then derive known key stream and to then trigger a key reinstallation attack to then abuse this okay we have time for one last question mic number one so as far as I understood your research and so if we have like 11W deployed in the network we are still venerable to the attack because as 11W dispecifies the encryption supposed by this amendment is also done by the encryption used on the network like before so 11W is not really a way to secure the network well if I got it right 11W is one of the things it does is protected management frames if I'm correct so using that does not defend against these attacks okay I think there is still quite details where people are curious about because everybody is starting this question as far as I understood so I think this was a really nice comprehensive talk and I want to thank you and everybody who has more questions perhaps can find you here and ask you more or have a look into the paper perhaps read everything in detail there so please another big round of applause for Matty in this amazing talk thank you very much thank you