We recently presented the paper Protecting Wi-Fi Beacons from Outsider Forgeries at the WiSec 2020 conference. You can view the recorded presentation on YouTube:
After the presentation we received a lot of interesting question, and it's useful to discuss these in more detail. So let's dig into some of the details of our work!
How does beacon protection handle hidden networks?
A hidden network still sends out beacon frames just like a normal network. The only difference with a hidden network is that its beacons do not contain the SSID of the network. As a result, all our attacks apply to hidden networks as well. Additionally, our defense works exactly the same for hidden networks.
Did you observe any clients recover from attacks after they received a beacon from the real AP?
In our attacks we spoof beacons to influence the behavior of clients. We found that with some attacks, such as those manipulating the throughput of clients, the effects of the attack are reset when the victim receives a real beacon (after we injected a spoofed one). In this specific case however, we found a way to make the effect permanent, and I refer to the second paragraph of section 3.3 in our paper on how we accomplished that.
Additionally, our transmission power attack did not work against all operating systems, and this might be because these devices reset their behavior back to normal when receiving a real beacon.
What makes certain devices more vulnerable than others?
Certain devices or operating systems may not support all features that are advertised in a beacon, and therefore they may not be affected.
Another reason why some devices are not affected to certain attacks is because they do not constantly track all information in a beacon. Put differently, some devices initialize parameters when they connect to the network, and will not update these parameters while being connected. As a result, if we spoof a beacon with different parameters, these updated values will simply be ignored.
What are the differences between beacon protection and Management Frame Protection of 802.11w?
We purposely designed beacon protection to be similar to Management Frame Protection. In particular, they both use the same underlying cryptographic primitives. This will hopefully simplify implementations and encourage vendors to adopt our defense.
Unfortunately, Management Frame Protection did not authenticate beacons and left them unprotected. In order to also protect beacons we cannot simply protect them in exactly the same way though: several edge cases have to be handled differently. This is discussed in more detail in section 4 of the paper. For example, care is needed when handling "Multiple BSSID" beacons, we need backwards compatibility, we added a capability to report rogue APs, and we are using a new beacon protection key.
Why do we need a new key? Why not use the same key used by Management Frame Protection?
Using the same key will only be secure if the same nonce (i.e. replay counter) will never be reused. This would imply using the same replay counter for beacons and other broadcast management frames. Unfortunately, this is surprisingly hard to implement: in practice the Wi-Fi chip may reorder beacons and broadcast management frames right before their transmission (after they were authenticated!). Preventing this is non-trivial. Unfortunately, we also cannot use two different replay counters under the same key, because they would again result in nonce reuse. All combined, the easier solution in practice is to generate a second key.
Have you thought about clients maliciously reporting fake beacons even if there aren't any?
We only prevent outsider attacks, so an insider can indeed maliciously report fake beacons. The impact of this is likely low though. The idea behind reporting fake beacons is that the network administrated is aware that something fishy is going on in the network (e.g. someone setting up rogue APs). So maliciously reporting fake beacons will annoy the network administrator, but other than that will likely have no impact.
In practice we can also consider fake beacon reports valid if multiple clients send a report. Additionally, in an enterprise network such as Eduroam, the network administrator can determine the username of the device that reported a fake beacon. This means such misbehaving insiders can be issued a warning or even banned from the network.