 I'm really 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 Fanhof. Welcome to the translation of the chat about how to break the WP2 with forcing a reuse of numbs. Thank you, CCC, for allowing me to speak here. I'm going to talk about my research on WP2 and you probably have already heard about this under the name of CrackAttacks. During my PhD I was already researching the security of wireless networks. One of the jury members in my PhD asked, hey, you're recommending WP2 with AES in your thesis, but are you sure that's really a secure solution? And someone asked me, hey, are you recommending WP2 with AES for more than a decade? Are you sure that's secure? If you select a secure password, then there are no real weaknesses that are known. And my answer was, well, yes, this is 14 years ago. I was staring at some open BSD code and particularly I was looking at this function called ICSET key. Now the details aren't important here yet, but this key installs the encryption key for use for the run. I was wondering what would happen if this function is called twice? And it turns out that answering this question led to the attack I found as you know by now this one covered the flaw in WP2. 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 that again soon, before we can check. So to explain the attack, I will illustrate that again soon, before we can check. After that, I will discuss the impact of the attack. Then I will go over some common misconceptions that have been floating around the internet. 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. The first question I have to answer here is, what exactly is this four-way handshake? What is the four-way handshake? It is executed whenever you connect to a protected network. So it is 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 user name on the password to login. On the purpose of this handshake is to clarify that you possess the correct credentials in order to connect to the network. At the same time, this four-way handshake negotiates a fresh session key that will be used to encrypt data frames. On this session key is called the key to get the pairwise temporal key. As I mentioned, this handshake seemed to be really secure because for over a decade, no handshakes have been found against it, assuming that a secure password has been used to hunt. But suppose that the four-way handshake was formally proven to be secure, and the application algorithm is used after the four-way handshake, which generally is ASC-CMP, that was also formally proven to be secure. Yet somehow we did find an attack even though we have always produced this protocol that has been around for that long. So what went wrong? To explain this, I'm going to explain how the four-way handshake works, so let's say we have the client 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. To start the connection, we need to find a common password. But if you have an enterprise or a more professional network, then where, for example, you have to use your name on the password, then first on 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. Once we have this shared secret, we can execute the four-way handshake once. What the first two messages and 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 non-spanied on the inter-transported to the client. And then in reaction to that, the client will generate its own random number, or if you make it non-spanied, it will basically send them to the access point, and it will send that random number to the access point in the second edition of the handshake. Once both devices have two random numbers, then we can derive this in per-session key count. The first random number of each device is very simple. We take this key that is known between these two devices, and combine that with most of these random numbers on the access point. The first random key can later be used to encrypt data frames. Now, I want to have a little thing. You might have heard about this research under the name key reinstallation attacks. Probably you have heard about a key reinstallation attack. I want to say that this attack is not about random non-predictable. It refers to non-reuse that will happen during the encryption algorithm, which I explained. Okay, so that's it for the first stage of the four-way handshake. Well, that's the first part of the four-way handshake. A bit simplified, it basically confirms that both of these negotiated the same PTKC. Confirms that both clients or both parties negotiated the same key. So that frame, if everything looks okay, is going to be using message four to the access point. Once these four-way handshakes have been exchanged, both the client or access point driver will be exchanged. So now data frames can be exchanged, and these data frames will be encrypted. Now we can understand what a four-way handshake is. Now the final thing I need to explain before we can get to some of the key points of the four-way handshake is how to get to some of the key points of the four-way handshake and how to get to some of the key points of the four-way handshake. But first, to explain this, let's take a look at the encryption sense on plaintext data, for example, from the client to the access point. For example, a data package of a client to the access point, and we will combine that with a packet number. Here is the packet number and the number of the package, which we will call nonce. On the ID here is that by combining the session key with the packet number, we get a unique per-packet key for everything. The P.T.K., that is, the session key with the packet number, which is the nonce, we have a single packet key, a single packet key. And then we have a stream, a long key, that we can make a XOR with the original data. And as a result, we have an encrypted data. This is basically an encryption in which the nonce is used to obtain a single key per packet. But under a particular session key, a nonce value should only be used once. Because if you ever use a nonce pattern, you will generate the same pattern. You will generate the same key stream on the decrypt packets that are sent, and depending on the specific nonce that is being used, it will allow you to get all the same frames. So now the question here is, is this a nonce pattern only used once? And the question is, is this nonce really used only once? So the only question that remains is to what is this encrypted number initialized? And the answer is quite simple. The P.T.K. has resolved this initialized to zero. When you install the P.T.K., this means you initialize the nonce to zero. This has a lot of sense. You start with a nonce to zero, and every time you add one, then every nonce is unique. But unfortunately, this is not the case. This nonce, this value of nonce, sometimes is used more than once. Because we can force the reinstallation of a P.T.K., which will produce a nonce to zero. How can we force this P.T.K. reinstallation, this key reinstallation? Let's go back to the example in which there is a client on the left and the access point on the right. And we have now an attacker in the middle, who is going to use a money in the middle based on channels. This attacker can't decrypt any packages yet, but it can reorder the packet on so on. It can block the transmission of the packets between the client and the P. So what I'm going to do is take all the packets that I've broadcasted to the P.T.K. and reorder them on the channel 1. Then we force this rogue access point on this different channel. So this man in the middle position, on channel 1, we don't modify any frames at all. So we simply forward all the frames between these two different channels, when they negotiate the authentication, we simply pass it, we simply send it between the P.T.K. and the client, but when the client sends the packet number 4 to the P.T.K. we don't forward it to the P.T.K. So we block the message 4. This is basically what is happening. The P.T.K. never receives the packet number 4, but from the client's perspective, the handshake was completed. The client thinks that the handshake is done, meaning that the P.T.K. was completed. So the P.T.K. installs the session key on its side. The client thinks that the handshake was completed, the client has finished his part, but the access point hasn't received the message 4 yet. The access point is going to try to save the situation by retransmitting the message 3. The client will accept this retransmitted message. The attacker sends that message 3 to the client. You will reply using a new message 4 and the protocol says that the client will send the message 4 and reinstall the P.T.K. We reply using a new message 4. However, this message 4 will be already encrypted at the link layer and the reason it's already encrypted is because these handshake messages are normal data frames. That retransmission of the P.T.K. is already encrypted at the link layer. I want to say that the Wi-Fi standard says that the next message 4 shouldn't be encrypted. So, in theory, according to the documentation, this problem shouldn't exist. So, as I said, once the client sends the message 3 again, it will send the message 4 encrypted and reinstall the decision key, which will start with the non-zero again. Meaning, we have keystream reuse. Meaning, we can now try to abuse this. Now, how are we precisely going to use this? Because we do somehow need to recover the keystream that was used. And we go back to our observation that we have a message 4 here that is initially encrypted. Meaning that there is a message 4 and a retransmission of that package 4 that is encrypted in this case. Well, there is a small difference between those two messages. But essentially, we have a message in plaintext without encrypting and another encrypted one. So, with an XOR, we can also recreate our keystream specific for our non-zero. And with another XOR, we can encrypt the package. So, at least from the known non-zero. Thank you. Thank you very much. So, that describes the attack against the four-way handshake. That describes the attack against the four-way handshake. This is not the only vulnerable part. There are other handshakes that can be attacked in a similar way. I'm not going to describe them all, but I'm just going to refer to an academic paper and I'm going to talk about the ideas behind the attack. One of the vulnerable points is the group key handshake, like the group key greeting. Then we also have the FT handshake. The FT handshake is used when you roam from one access point to another access point, and also when you do roaming between one access point and another access point of the same network, Wi-Fi, so that you can do roaming without cuts. Another handshake is the pier key handshake, where the two clients want to communicate directly. So, I'm now going to discuss in a bit more detail what the practical impact of our attacks are. I'm first going to start with the practical impact of all this. A device that's vulnerable. This device can either be a client device, for example, it can be a phone or a laptop. Or even a bread toaster. Or it can also be an access point. Or an access point to our key re-installation attack. The first thing that a client can do as an access point are vulnerable to an attack of key re-installation. And cryptid data frames, we can force it to reuse the nonce, which if this device sends encrypted packages at some point, we can force it to re-install the key to be able to re-encrypt its encrypted packages. Now, why is that the case? Another thing that we can re-install, not only is this transmit nonce reset, but a non-transmitter, which is called a replay counter. It is also a replay counter. As the name implies, it's used to detect re-transmissions or it's used to detect malicious replays. Re-install, when a counter is reset, it's used to detect if a re-transmission is done or not. By resetting that counter, packages can be re-transmitted without the victim noticing it. Influence the exact impact of the attack. One of the things that probably has the biggest influence is the encryption algorithm in Wi-Fi networks. These days, it's where Wi-Fi networks use ASCCMP. It's the most widely used encryption algorithm in Wi-Fi networks. The algorithms that are used to re-encrypt the communications. Today, the most common is to use ASCCMP on replaying frames. It's not possible to abuse our key re-installation attack to now forge views. With this algorithm of encryption, it's practically impossible to invent packages and re-transmit them. You can only re-transmit or re-encrypt packages. Is that the algorithm? We would be able to recover the message and technical changes with the ASCC word for the authentication key. Once we have that, we would be able to be sent here to be sent by the new packages. Interestingly, lately, there's been a encryption algorithm that's being re-encrypted. That algorithm is called GCCMP. Very few devices still support it. The impact of a key re-encryption is really the worst, because here we can again recover the authentication key. And it's the worst, because here you can also recover the authentication key. And this key is used in both directions, from client to client and vice versa. And then here we could invent packages in both directions. We would only be sent by the device that is under attack. So, in my opinion, this is a bit surprising, because GCCMP is the latest encryption algorithm that is the latest encryption algorithm. But this is also why I think this new protocol of the best is the biggest impact. If today everyone was using this algorithm, the impact of the crack attack would be much, much worse. Another issue is that if we attack the group key handshake, then the whole thing we're doing is attacking the group or multicast. If we were attacking the group key handshake, we would only be attacking the group key handshake. We are attacking the client. And the client is never sending extra broadcast frames. So, we'll never reuse the broadcast frames, because it's never triggered the frame. Why is the client never sending broadcast frames? Well, let's say we have the network layout shown here. Why is this never happening? Here we have the client on the left who wants to send a broadcast to the rest of the clients. And what happens then is that the client is going to send a single cast to the group key. And in this case, it's not going to use the group key to encrypt the package, but the client is going to send a broadcast package using the group key. And this is done so that all the clients who are at the request of the client receive the package. 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. So, when we attack the group key handshake, the final result is that we're only going to be able to replicate broadcast packages that send the call to the client, but it's not going to be the case because those packages of the client broadcast don't exist. Which limits the impact of an attack on this type of handshake. For example, to turn on the frigorific, the impact of replicating broadcast package frames is low. But it depends on the rate of the attack that was attacked. Well, the for-high handshake that we have discussed, we can attack the client, we can replicate the decryption algorithm used to decrypt and even, maybe, create our own packages. It's a little more interesting for the handshake FET and to remind you that this handshake is only used if it's in roaming. In this case, the access point can be attacked. So, we don't need this man-in-the-middle position anymore. And why? Well, let's explain it. Here we have our situation again. The handshake is the same as the for-way handshake. At a high level, the handshake FET is identical to the for-way handshake. The difference is that, in this case, it's the client who sends the first package. While in the for-way handshake, the access point was sent to the first package. So, if the client sends two different handshakes and then both these endpoints can generate the fresh encryption key. So, the last two frames are used to transfer the first package and then they will negotiate the encryption. I want to go in a bit more detail here on this last phase on what happens here is that the first frame of the handshake is now sent from the client to the access point. On that is a re-association request is that in this case the third package what it does is re-associate the client at the point of access and the point of access will approve it and at this point is where the session key is installed and from now on all packages will be encrypted and what we can do as a person who wants to attack the communication is to take that approval message for the re-association and block it. In this case the client will send a re-association question again and a new point of re-install the encryption key. Here it goes wrong because we are re-installing this encryption key. The attacker again re-re 보�es this dataframe request for re-association from the client as many times as he wants which produces that the PPS installs the PTK, with which to reset the NONS, with which the same key is returned and the NONS is reused, which derives from the fact that you can decrypt the packages that the AP sends. In the case of the Forthwind Handshake, the Handshake contains a counter that is used to avoid retransmissions, but in this case of the Handshake FT, this counter does not exist, so there is no protection for sending packages, as in this case the one we are sending as if for a client. Then there is a topic with which is the implementation. In iOS 10 and Windows, the standards do not really follow, and when receiving a retransmission of the Message 3, they do not follow the protocol and do not reinstall a PTK. So this attack is not vulnerable to group key attacks, meaning that one is vulnerable to attacks against the Forthwind Handshake. Curiously, iOS 11 is vulnerable to the Forthwind Handshake attack. In Linux, the issue is particular, because if we attack WPA Supplicant, if we do a key re-installation attack, it will not reinstall the original key, which with which they started the conversation, but they will reinstall a key that is pure zeros, with which they become completely trivial to decrypt the traffic. How does this happen? I can understand why this went wrong, so I'm going to explain what the implementation does wrong, to explain how is the implementation to understand how we get to use a key of all zeros. I'm going to explain a bit on the implementation of the Android, and we're going to look at two entities. We're first going to look at the WPA Supplicant, which is represented by the Handshake icon here. The hands represent WPA Supplicant, the demon that runs in user space, and WPA Supplicant will be responsible for executing the Forthwind Handshake. The WPA Supplicant is responsible for doing the Forthwind Handshake, and the kernel of the Forthwind Handshake. What does the attacker have to do to cause this installation to the Forthwind Handshake? Well, that's the four we have to execute. When the access point sends message to the Forthwind Handshake, we're going to have Android RoboPry using message four, Android will respond with the message four, and we're going to block it as an attacker so that it doesn't get to the access point. This is totally similar to what we were looking at before, with which it will install the PTTK key. What it does is that WPA Supplicant asks the kernel that installs the PTTK key in the driver. The driver will copy the memory key, with which WPA Supplicant doesn't need to save the key, because it already has the driver, with which WPA Supplicant eliminates the key from its memory. When the attacker transmits the message three, WPA Supplicant will respond with the message four, and he will ask the kernel, hey, please install the key, but when he sends a key reading the memory that was deleted, with which he sends pure zeros, and with which the driver will happily accept the command of installing a key that is pure zeros. And then it will be trivial to intercept and manipulate all the client's traffic. Basically we are now a rogue access point and we can manipulate the traffic of the client. Now we have total control of the client's traffic, from our access point of the attacker. Then there are some bugs in these Wi-Fi devices, which cause all the scripts to fail. How you should do that is also explained on this page. What you should also do is to deactivate the encryption of the hardware. What you can do is to check the attack on the four-way handshake, on the group handshake, and also on the handshake FET. So if you want to see which devices are vulnerable, what you will probably see is that many devices are still vulnerable against our attacks. We can modify access points to prevent attacks against the client. In particular, what we can do is to avoid modifying the access point in such a way that the client is not vulnerable to most of our attacks. Among other things, that does not transmit the message 3, and in the case of the group handshake, that does not transmit the message 1. There will still be some special cases in which the devices are vulnerable, but those attacks do not have a great impact. So these modifications will ensure certain access points. Especially in a noisy environment, because we do not reach these messages anymore, that the handshake may fail because the other reliability is now... However, it can be that in places with a lot of traffic, if you have a router, it does not get the message 3 in a natural way. So if a producer of devices says that there are additional modifications of all the problems of vulnerability, it will not necessarily mean that the access point has also been modified with these modifications, since these are additional modifications that will also protect the clients, apart from the access point. So in this last phase I want to talk about the false information that is reproduced on the internet. There are people who say that if you only patch the client or the access point, only contains these normal patches, the normal patches should be enough to protect them. What is not correct is not vulnerable. So as I mentioned, connected clients are only... Only the fans of these devices are really excellent on top of the default patches. They are still vulnerable. That is why they have to make the additional modifications that we have described. There are other people who say that it is an interesting attack, but the attacker has to be very close to the network he wants to attack. What is not necessarily true is that with special antennas directed, a Wi-Fi network can also be attacked at very high distances. There are even attacks described by the NSA with distances of up to 8 miles. So obviously it needs a specific location, but it does not have to be close. Another false information is that you have to be connected to the network as an attacker to be able to attack it. That is not true. The only thing you have to do is to be close to the network and the person attacked, the victim, and that is enough to attack. One remark that I can understand is that some people say that there are people who say that they can attack the handshake and they can decrypt the data right after you connect to a Wi-Fi network, but normally after connecting to a network, the information that is sent is not interesting, because there is no use for information to be transmitted at this time. Unfortunately, at least the services again are not true, because all 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, but not in the middle of that while the victim is, for example, surfing the internet, we can de-authenticate the network on the network. For example, in the middle of a navigation session, we can de-authenticate the client, with which the operating system of the client re-initiates a new handshake, with which the first packages after the handshake will be of interesting data. We can de-authenticate the victim, it will execute a new handshake, and then we can decrypt the data that will be transmitted right after that. Another thing that is obtaining this channel-based man in the middle is difficult, because you might be thinking in order to force the client to connect to the rogue access point, but again, unfortunately, this is not true, because we can use a special Wi-Fi packet, called channel switch announcements, which are called switching to a Wi-Fi channel, which tells the client that it has to be switched to a channel. So we don't need a high signal strength, we simply command a victim into a space which this channel won't connect to our access point. With a very high signal strength, we only have to tell the client, hey, you have to switch to a channel. Another thing you might say that the complexity of the attack is high. This is in order to make a certain set of concepts, and this is partially true, that you need to understand the entire Wi-Fi protocol, but this means that someone can write a script and the rest of the people can use it. This has happened in other cases. And the scripts that are uploaded and that other people simply download them and run them. Another myth is that if you use ASCMP, this damages the attack. And this is also not true, unfortunately. The attacker is still able to decrypt on replay. In this case, the attacker can't invent packages, but he's still able to decrypt and re-transmit packages. Another myth is that the enterprise networks are not affected because they don't execute the 4-way handshake, but this is not true either, because they also use the 4-way handshake. And the last myth is that it's the end of the world because all security is broken, and my suggestion is that we don't go crazy. So sometimes the impact is actually really low, but of course if the attacker is very high, for example, then the device, then the attacker can... And in some cases, yes, the impact is very deep, like, for example, in an Android device, in which the attacker can do practically whatever he wants. That we can learn from this attack and also the research. And one of the most important and interesting lessons learned during all this, and the reason why I really like this attack myself, is that the 4-way handshake, the encryption protocol, in particular AES, the encryption protocol was formally approved, and then suddenly we lose all security. The 4-way handshake was also formally approved, but if we combine these two things, the combination of these two things is not certain. And this is very interesting because each individual part of the system was formally investigated and approved for security. But not only... There you don't have to finish the investigation, but we have to prove that the combination of these things is for security. The authors, they modeled the handshake in a rather abstract way. In the paper of the 4-way handshake, the authors model the 4-way handshake in a slightly abstract way, so that we also look at the combinations of... We also need to share our own use, reflect the message. So we have to make sure that in these... we should keep the protocols and also... abstract representations are not too far from reality. WPA supplicants 2.6, when we were studying this version of... especially when we looked at the implementation of WPA supplicants 2.6, however, when we were notifying companies of the 4-way handshake, we found out that it was not vulnerable. However, while we were notifying companies of the 4-way handshake, another researcher contacted us and told us that there were... that there were vulnerable versions. And the reason why we didn't find it is that WPA supplicants 2.6 is written with a totally complex machine and we couldn't verify it because of the complexity. So just like the CIA also says, we should reduce complexity and necessity. Typically they have a document where the CIA advises people to properly hide vulnerabilities that they want to send data back to us. Of course, use encryption. But in that encryption algorithm, don't enable re-key functionality because it 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. Another thing that we can learn is that the standard needs to be specified very precisely. It was a bit fake. The standard original of WPA 2 was a little... it was a little... specific. It was described with a state machine. But it doesn't define what it should do and it doesn't define the order and it doesn't define what it should do. But there is an amendment of the order and it defines how and when to handle messages. But even that standard is a little more specific. I want to remark here that because the original is standard, I can forgive IOS on Windows for deviating a bit from the standard. And I want to say that it's not terrible that Windows and Android don't use the standard specifically as described because sometimes it's not easy to discover what it wants to describe. I want to invite you to a workshop if you are working on this topic. Please join me. And the last thing I want to mention about this is how the disclosure of vulnerability like this coordinates the publication of a vulnerability like this. This is not a topic that only affects a hardware manufacturer, but something that probably affects all the devices in the world. Who are you going to notify? With what deadlines are you going to notify? We are going to show you the strategy that we use. First, this really is a general problem. We wanted to make sure that this was the case. First, we contacted some vendors who were selected specifically. We found this vulnerability and we couldn't check if your products are vulnerable, but please check it. And some of them answered yes, our products are also vulnerable. And we also got a bit of feedback on the attack we are seeing. Yes, it was general, because products that we hadn't even tried were vulnerable. So at this point we came to the conclusion that it was a standard problem and everyone was affected. So who are you going to notify? Clearly, the great hardware producers and the great participants of the brand. And with a team of SERT, then you can just ask a vendor that you contacted already for or a vendor that also might be affected by the bug. You can ask one of the vendors that you contacted already for as much vendors as possible. On the other hand, you can get more contact from other vendors. Because if you are going to notify everyone, then the chance of the details leaking is going to be able to notify a lot of people, but not necessarily to everyone, because the fact that there is a leak on the vulnerability is close to one. Then the issue of a deadline on how to act. If the period of the embargo is too long, there is a lot of risk that it ends up leaking information about the vulnerability, but a too short embargo doesn't give time for people to patch up their products. But surely you have to make a deadline precise to avoid uncertainty. With that, we can close the chat. The failure is in the standard WPA. The most surprising thing about this research is that WPA had been tested as something more than that for a decade, but it's insecure. It's insecure. That the attack has a practical impact and that you have to check all the clients and APs. Thank you very much. If you have a question, please ask and the audience will applaud. And keep applauding. The first question is you mentioned that GSMP is the most vulnerable algorithm. Do you know if there is a non-use-resistant scheme like a synthetic initialization vector to prevent this non-use in this algorithm? Yes, there have been some proposals to make an encryption algorithm more resistant to the ongoing research. So there are proposals to make an algorithm that you can use. I'm not aware of actual encryption protocols. For example, I don't know the protocols of encryption being really used. Or more in CFRG, so a company-owned research group in ITF standardization is taking place in an ITF work group. But the question is if you would use an ASGCM instead of the deterministic initialization vector, there is a random... If you use GSMP 96 bit, then the impact won't be pounded. There is a vector of initialization that you could attack. To answer the first question, I don't know ideas to modify the standard of the Wi-Fi to defend against handshakes, but they don't want to change the number of handshakes resistant to nonce-reuse. They want to inspire technology to be more mature and then use that. And your second question is if there are encryption algorithms where GSMP is randomized, there are two possibilities. In the GSM standard, I'm still answering the question, there is a risk of using a random solution vector. The risk of using a random initialization is that, on the one hand, you can still have a nonce-reuse and you can still use a nonce-reuse, even with a randomized nonce. And with which you could do different attacks. For example, there is a paper where you can attack different libraries of TLS, where nonce isn't really random. For example, sometimes they don't use nonce, but the nonce isn't really randomized. A direct answer to the question number one. There is a work currently to modify the standard to resist this attack, but now there is no working group that is trying to fix this. They are working to avoid the key reinstallation. But there is no working official group. Yes, there are people working on the solution. Another question. Thank you very much for the fantastic chat. Could you go back to the initial foreway handshake? Yes, with the attack or the handshake. So, all you get from this is the key stream that is used to encrypt the message. That's all you get, isn't it? Yes, but you can use it to start decrypting packages. You can do it as an attacker, you have several options. The first thing you can do is to do this several times and to authenticate it several times and decrypting each package one by one. What you can also do is to wait to re-transmit that package because sometimes you know the content of the package like for example the HCP or something like that and then you can send packages where you know the content to discover the content of the next packages. After a while you can collect many key streams to modify the content of the communication. You can try to discover the content of the package and then you can play around with that. Yes, but in this case all you get is a key stream that is used immediately. Well, we know the message after the message 4. We use it to get the key stream and then we can use it to encrypt new packages that we don't know. That's a later discussion with more in detail. That's for discussion later. Great find really and an awesome talk. Very good talk, incredible. We could talk a little more about how to use security in a sense. How can you still benefit from verification? Well, I think what we should believe is that the formal verification can give us more confidence that it's secure for certain protocols, but it can't give us security that it's secure. What many people used to believe is that it's formally verified so it shouldn't be vulnerable. So no, that's not... Let's see if the formal verification really reflects reality. So we should still verify formally, but we should only use it as additional evidence, which is secure. Well, the first part is in the diapositive. The retransmission of the package 4 doesn't mean that it's encrypted according to the standard. So if it was the standard, this wouldn't be a problem, right? No, you do have a problem because the only thing you have to do is wait for a package you know, such as an ARP request or a TCP package or simply a plain text package from HTML. For example, what people have done is try to look at the large package to determine the content of the page you're looking at and then you know the package. So there are many ways to predict the content of a package and to continue with the attack. Okay, we have time for one last question. Mike, number one. As far as I understood your research, so if we... You deployed in the network, we are still vulnerable to the attack because as WD specifies the encryption supposed by this amendment is also done by the encryption used on the network like before. So it's not really a way to secure the network. Well, if I got it right, 11W is one of these protected management frames. 11W protects the management frames. The management does not defend against these attacks. Okay. I think there's still quite details where people are curious about because it's everybody starting from the top. There are a lot of comprehensive talk and I want to thank you and everybody to have a look into the paper. Please read everything in detail there. It's amazing. You can read the documentation. Thank you. A big applause.