 Hello, I am Mati Vanouf and I'm going to give a presentation about our paper titles Protecting Wi-Fi Beacons from Outsider Forgeries. This research was published at the WISAC conference just a few months ago, and this was joint work with Prasant Adhikari and Christina Pepper. In this presentation, I'm going to give a summary of our results. So as the title of the presentation implies, we're going to protect Wi-Fi Beacons. Before we get into that, what exactly is a Wi-Fi beacon? Well, Wi-Fi networks use Wi-Fi beacons to announce their presence to nearby clients, and they are sent roughly every 100 milliseconds by an access point. These beacons contain various properties of the network. For example, they contain the name of the network, they contain the supported bit-rains, for example, whether the network supports the 11n or 11ac standard. And they also contain certain regulatory constraints, for example, the maximum transmission power, and so on. But the problem in practice is that these beacons are not protected, and they can be forged by an adversary. In our work on this presentation, we present novel attacks that abuse beacons, and motivated by these novel attacks that we discovered, we implement a defense to prevent outsiders from forging beacons. And we also standardize this defense as part of the 802.11 specification that underpins Wi-Fi. On top of all of this, we also have an implementation on Linux, and our defense might even become part of WPA3. But before we get into these details, let's take a step back and look at the history of Wi-Fi security. And here we can see that previously the focus was on protecting transmitted data and not beacons. For example, if we look at WEP on WPA1 and 2, they really focus on protecting data only. Now, WPA3 does mandate that certain management frames are also authenticated, however, unfortunately, this does not include beacons. And even if we look at some very recent additions to Wi-Fi, such as operating channel validation, this only verifies the information about the current channel that the access point is operating on. In other words, even if we use all the modern standards, beacons are not protected on they can be forged by an adversary. And if we look at the contents inside a beacon, we see that there's a lot of information that a beacon contains. And a small amount of information is indirectly verified when you connect to the network. For example, the WPA version that is supported by the network on the current operating channel is securely verified when you are connecting to an network. But all the other information that is contained in the beacon, and here we are only showing a small part of the possible information in the beacon, can be spooned by an adversary and possibly be abused. So the first thing that we did in our research is that we searched for novel attacks that an adversary can carry out by spoofing these beacon frames. One of the first attacks that we discovered is what we call a power-constrained attack. Namely, as I already hinted at previously, beacons contain the maximum allowed transmit power that a client should be using. For example, if we look at the following beacon content in Wireshark, we can see that it contains the maximum transmit power that is allowed in a certain country. And on top of that, the beacon can even further lower the maximum transmit power below this regulatory maximum. In other words, to simplify, an access point can command the client into using a certain maximum transmit power. An adversary can abuse this by forging a beacon that instructs clients into using an extremely low transmission power. In turn, this causes the network connection of the victim to become almost unusable. That's because the frames that the victim is transmitting will no longer reach the access point. Essentially, this means the client will no longer have a stable internet connection. So if we look in practice, we tested this attack against various operating systems. And we found that an iPad on a MacBook was vulnerable to an attack, and the Linux was also vulnerable to attacks. Other devices were not affected. It is unclear why. Although we conjecture that after injecting a forged beacon, other devices may reset their parameters back to normal once they receive a legitimate beacon. Now, we also found a minor variant of this attack against Linux. Namely, when we were inspecting the source code of the Linux kernel, we noticed that it's also able to parse a vendor-specific information element that belonged to Cisco. And what's interesting about this implementation in Linux is that normally, if we follow this specification, we cannot set a negative maximum transmission power. But by abusing this vendor-specific element of Cisco, we can. On the turns out that if we are able to set a negative transmission limit, then the drivers of Linux do not handle this properly, and as a result, they forcibly are disconnected from the network. So let's show a demonstration of this. In our demo, we can see now that the victim has a stable internet connection. However, as an adversary, we're now going to inject 10 beacons to make sure at least one of them arrives at the victim. And if we now look at the debug messages of the victim, we can see that it indeed lowered its transmission power. If we look in Wireshark, if we look at the spoofed beacon, now indeed contains this power-constrained element that reduces the transmission power of the client. If the victim now tries to refresh the website or visit the new one, you will see that the website is no longer loading, meaning our attack was successful. Now a second attack we discovered is that we can lower a victim's bandwidth by spoofing beacons. And this abuses the way that a normal Wi-Fi device transmits frames. Particularly, before a Wi-Fi device will transmit a frame, it will first check whether the medium is idle or not. And in case another device is transmitting a frame, it will first wait until this device finished transmitting. And after that, it will wait a very short amount of time called the SIFS interval, and this is mandatory. Every device must wait this amount of time. Additionally, it will wait an amount of time that depends on the priority of the frame that it wants to transmit. This is called the AIFSN period. And for example, if the device wants to send a high priority voice packet, this period is relatively short. Or if the device wants to send some background traffic, this period is a bit longer. Then finally, the device will also wait a random amount of time called the back-off window or the contention window. And this is a random value, and it is used to also give other clients an opportunity to transmit as well. In case during these three periods no other device started transmitting, in that case the device can transmit its own frame. Now, what is interesting is that the specific values for these waiting periods are determined by the network configuration. In particular, they are defined by the beacon. So, if we look at the beacon in Wireshark, we can for example see that it advertises the specific value for the AIFSN period. Additionally, the minimum on the maximum duration of the back-off window is also defined in the beacon. And of course, as an adversary, we can spoof beacons where these values are very large. And this means we can force a victim into delaying its transmission for a longer amount of time. And this effectively reduces the bandwidth of a victim. Now, the impact can in fact be much higher than simply lowering the bandwidth of a victim. And that's because if another device starts transmitting during any of these waiting periods, then the device will need to completely restart its waiting procedure. In other words, if there is another nearby client that is actively downloading or uploading a file, our victim may simply never get the chance to transmit the frame and our attack will result in a denial of service. So, we tested this attack in practice and we found that Linux is affected independent of the network card being used. We also tested some Apple devices and here we found that the MacBook Pro, the iPhone and the iPad are all vulnerable. We also tested Windows 10 and here we noticed that the impact depends on the specific network card that this operating system is using. For example, if we use an alpha or TP-Link USB Wi-Fi dongle, then we found that Windows 10 was vulnerable. However, if we used the built-in network card of certain laptops, which is typically an Intel network card, at least some devices we tested, then Windows 10 was not vulnerable. Finally, we also tested two Android devices, one more recent Nexus 5X device and it was vulnerable to our attack. But our fairly old Samsung device was not vulnerable to our attack. So, let's show a demo of this attack in practice. We will target an iPad device and we can see that before starting the attack, the iPad has a throughput of about 10 megabit per second. Then, as an adversary, we will spoof two beacons. If we look in Wireshark, this spoof beacon has the maximum value for the back-off window and also the maximum value for the AI FSN waiting period as well. If we now measure the throughput on the iPad, we see that this substantially lower, meaning our attack has succeeded. We also discovered several other attacks. For instance, we discovered a partial machine-in-the-middle attack on this attack bypasses channel operating validation in Linux. For the details, I will refer you to the paper. We also discovered battery depletion attacks, where we can spoof beacons to make clients stay awake longer than they normally are. Additionally, we also found that it is possible to send beacons as unicost frames. This allows us to target specific clients on this technique worked against all the devices we tested. How can we prevent these attacks in practice? Well, the idea is to authenticate beacons such that an adversary can no longer spoof them. But before we get into those details, let's first state the goal of our defense. The goal is to come up with a practical and simple design to encourage adoption in practice. This means that our cryptographic operations must be efficient, and that the bandwidth overhead must be low as well, because beacons are sent at a low bitrate, and even adding a few bytes will consume a significantly higher airtime. Finally, we also want the defense to be straightforward to implement, because then this increases the chance that vendors will actually adopt our defense in practice. Ideally, we will accomplish this by reusing existing cryptographic primitives that were already used in Wi-Fi. So how can we achieve these design goals? Well, we will rely on symmetric encryption, and we will reuse a crypto primitive that is already part of management frame protection. Additionally, we only defend against outsider attacks. In other words, we assume that the adversary does not possess the credentials of the network. And this assumption is similar to how broadcast on multicast traffic is protected in WPA 2 on 3 as well. So concretely, how does our defense work? Well, we add a new type-length value element to beacons. On this element is shown here, on the two most important fields here are highlighted in green. Now, before I discuss the details of these two important fields, I first want to mention that clients that do not recognize this new type-length value element, they will automatically ignore it. And this makes our defense backwards compatible with existing Wi-Fi implementations. So first we have the nonce field. And the nonce field is essentially an incremental number that is used to prevent replay attacks. And then the mick field, which stands for message integrity check, is a CMAC or GMAC authentication tag that is calculated over the beacon. And here the CMAC and GMAC are existing cryptographic primitives of management frame protection. And the interesting thing is that all WPA 3 capable devices are already required to support these operations, meaning vendors will already have implemented them by now. So the remaining question now is which key will be used to generate this authentication tag? And here we decided to let the access point generate a new beacon protection key when it starts. And this beacon protection key is always sent to the client when it is connecting. In particular, even if the client may not support beacon protection, the access point will still send this beacon key to the client. And older clients will simply ignore this new key, but new clients will treat it as an indication that the access point supports beacon protection. Now the interesting thing about this construction is that an adversary cannot manipulate the handshake that transports the beacon key. This means that dome grade attacks are prevented because an adversary cannot somehow remove the beacon key that is being transported to a client. The final important thing to discuss is how that clients handle beacons that are received before they have connected to a network. Because recall that a client only receives the beacon key once it has connected to the network, meaning that beacons that are received before that cannot be authenticated because the client does not possess the key to verify their authenticity. So how can we handle this in practice? Well, our solution is that before a client connects to a network, it will store one beacon as a reference and it will extract all information of the network from this reference beacon. And when the client now connects to this network and once it has received the beacon protection key, it can take this reference beacon and then verify its authenticity. And in case this check fails, it means there was an attack and then the client can disconnect from the network. On the other hand, if the authenticity of the reference beacon can be successfully validated, then the client can send data frames to the network and can operate as normal. Now that we have our defense, an interesting question is how a client should act when it receives a forged beacon and we decided that in that case the client should send a notification to the access point. This allows the access point to detect rogue APs that are far away. For example, in our illustration here, the rogue AP is out on range of the real IP. However, when a client receives a forged beacon from the rogue AP, it can notify the real access point of this and then the real access point can take appropriate actions. So now I want to discuss some practical impact of our research. First and for all, we created a specification of our defense in collaboration with Intel Broadcom Qualcomm and Huawei. And our defense is now part of the draft IEEE 802.11 standard, meaning vendors will likely adopt this in practice as well. Moreover, the Wi-Fi Alliance has recently expressed interest in our defense as well, meaning it might become part of an update to WPA3 or it might become part of a separate certification program. Our defense is independently also being implemented by Linux, where the kernel generates and verifies authentication tags and host AP manages keys on enables beacon protection if it is supported by the network. We will now show a demo of this on our recent Linux kernel, where if we start the access point on view the beacons and wire shark, we can indeed see that the authentication tag is being added to beacons. If we now connect to this network, the client will indeed receive the beacon protection key on it will enable beacon protection. As a result, if we now inject the beacon as an adversary, the client will detect this spoofed beacon. In this demo, we made the client print a small debug message. If we now look at the debug log, we can confirm that the forge beacon has been detected on the attack has been prevented. To conclude our talk, we propose the defense to prevent outsiders from forging beacons, and our focus on practicality has sped off, because our defense is now part of the 802.11 standard, is independently being implemented by Linux, and it might become part of an update to WPA3. Thank you for your attention.