start	end	text
0	5200	Hello, I am Mati Vanhoef and I'm going to give a presentation about our paper titled
5200	12340	Protecting Wi-Fi Beacons from Outsider Forgeries. This research was published at the WISEC conference
12340	18420	just a few months ago and this was joint work with Prasant Adhikari and Christina Popper.
18620	24600	In this presentation I'm going to give a summary of our results. So as the title of the presentation
24600	31740	implies, we're going to protect Wi-Fi beacons. Before we get into that, what exactly is a Wi-Fi
31740	38820	beacon? Well, Wi-Fi networks use Wi-Fi beacons to announce their presence to nearby clients
38820	46960	and they are sent roughly every 100 milliseconds by an access point. These beacons contain various
46960	51420	properties of the network. For example, they contain the name of the network,
51420	58280	they contain the supported bit range, for example, whether the network supports the 11n or 11ac
58280	65240	standard. They also contain certain regulatory constraints, for example, the maximum transmission
65240	72580	power and so on. But the problem in practice is that these beacons are not protected and they can
72580	80660	be forged by an adversary. In our work, in this presentation, we present novel attacks that abuse
80660	88080	beacons and motivated by these novel attacks that we discovered, we implement a defense to prevent
88080	95260	outsiders from forging beacons. And we also standardized this defense as part of the 802.11
95260	104060	specification that underpins Wi-Fi. And on top of all of this, we also have an implementation on
104060	114240	Linux and our defense might even become part of WPA3. But before we get into these details,
114240	119840	let's take a step back and look at the history of Wi-Fi security. And here we can see that
119840	126780	previously the focus was on protecting transmitted data and not beacons. For example, if we look at
126780	137400	on WPA1 and 2, they really focus on protecting data only. Now, WPA3 does mandate that certain
137400	144280	management frames are also authenticated. However, unfortunately, this does not include beacons.
144280	152100	And even if we look at some very recent additions to Wi-Fi, such as operating channel validation,
152100	156760	this only verifies the information about the current channel at the access point.
156780	164280	In other words, even if we use all the modern standards,
164280	172320	beacons are not protected and they can be forged by an adversary. And if we look at the contents
172320	179220	inside a beacon, we see that there's a lot of information that a beacon contains. And a small
179220	186400	amount of information is indirectly verified when you connect to the network. For example, the WPA
186400	192840	version that is supported by the network on the current operating channel is securely verified
192840	199840	when you are connecting to a network. But all the other information that is contained in a beacon,
199840	204680	and here we are only showing a small part of the possible information in the beacon,
205040	213520	can be spooked by an adversary and possibly be abused. So, the first thing that we did in our
213520	221200	research is that we searched for novel attacks that an adversary can carry out by spoofing these
221200	229840	beacon frames. One of the first attacks that we discovered is what we call a power-constrained
229840	238960	attack. Namely, as I already hinted at previously, beacons contain the maximum allowed transmit power
238960	247260	that a client should be using. For example, if we look at the following beacon content in Wireshark,
247260	253700	we can see that it contains the maximum transmit power that is allowed in a certain country. And
253700	260840	on top of that, the beacon can even further lower the maximum transmit power below this
260840	268700	regulatory maximum. In other words, to simplify, an access point can command the client into using
268860	276420	a certain maximum transmit power. An adversary can abuse this by forging a beacon that instructs
276420	282620	clients into using an extremely low transmission power. In turn, this causes the network connection
282620	289880	of the victim to become almost unusable. That's because the frames that the victim is transmitting
289880	296240	will no longer reach the access point. Essentially, this means the client will no longer have a stable
296240	303440	internet connection. So if we look in practice, we tested this attack against various operating
303440	311880	systems, and we found that an iPad on a MacBook was vulnerable to an attack, and Linux was also
311880	320300	vulnerable to attacks. Other devices were not affected. It is unclear why, although we conjecture
320300	327500	that after injecting forged beacons, other devices may reset their parameters back to normal once
327500	336320	they receive a legitimate beacon. Now, we also found a minor variant of this attack against
336320	343740	Linux. Namely, when we were inspecting the source code of the Linux kernel, we noticed that it's
343740	352380	also able to parse a vendor-specific information element that belonged to Cisco. And what's
352380	360540	interesting about this implementation in Linux is that normally, if we follow the specification,
360540	367140	we cannot set a negative maximum transmission power. But by abusing this vendor-specific element
367140	376260	of Cisco, we can. And it turns out that if we are able to set a negative transmission limit,
376260	382140	then the drivers of Linux do not handle this properly, and as a result, they forcibly are
382140	389800	disconnected from the network. So let's show a demonstration of this. In our demo, we can see now
389800	395960	that the victim has a stable internet connection. However, as an adversary, we're now going to
395960	403060	inject 10 beacons to make sure at least one of them arrives at the victim. And if we now look
403060	409880	at the debug messages of the victim, we can see that it indeed lowered its transmission power.
410060	415060	And if we look in Wireshark, if we look at the spoofed beacon, it now indeed contains this
415060	420340	power-constrained element that reduces the transmission power of the client.
420340	426440	If the victim now tries to refresh the website or visit a new one, you will see that
426440	431670	the website is no longer loading, meaning our attack was successful.
433720	440170	Now, a second attack we discovered is that we can lower a victim's bandwidth by spoofing beacons.
440700	448360	And this abuses the way that a normal Wi-Fi device transmits frames. In particular, before a Wi-Fi
448360	455660	device will transmit a frame, it will first check whether the medium is idle or not. And in case
455660	462500	another device is transmitting a frame, it will first wait until this device finished transmitting.
463140	469300	And after that, it will wait a very short amount of time called the SIFS interval.
469520	477100	And this is mandatory. Every device must wait this amount of time. Additionally, it will wait
477100	482340	an amount of time that depends on the priority of the frame that it wants to transmit. This is
482340	491300	called the AIFSN period. And for example, if the device wants to send a high priority voice packet,
491300	497000	this period is relatively short. While if the device wants to send some background traffic,
497000	504620	this period is a bit longer. Then finally, the device will also wait a random amount of time
504620	512920	called the backoff window or the contention window. And this is a random value. And it is used to
512920	520720	also give other clients an opportunity to transmit as well. In case during these three periods no
520720	528200	other device started transmitting, in that case the device can transmit its own frame.
529050	536480	Now, what is interesting is that the specific values for these waiting periods are determined
536480	544220	by the network configuration. In particular, they are defined by the beacon. So, if we look at a
544220	550720	beacon in Wireshark, we can for example see that it advertises the specific value for the AIFSN
550720	559460	period. Additionally, the minimum and maximum duration of the backoff window is also defined
559460	566420	in the beacon. And of course, as an adversary, we can spoof beacons where these values are very
566420	575040	large. And this means we can force a victim into delaying its transmission for a longer amount of
575040	584080	time. And this effectively reduces the bandwidth of a victim. Now, the impact can in fact be much
584800	590760	higher than simply lowering the bandwidth of a victim. And that's because if another device
590760	598160	starts transmitting during any of these waiting periods, then the device will need to completely
598160	604840	restart its waiting procedure. In other words, if there is another nearby client that is
605420	611760	downloading or uploading a file, our victim may simply never get the chance to transmit the frame
611760	621280	and our attack will result in a denial of service. So, we tested this attack in practice and we found
621280	630100	that Linux is affected independent of the network card being used. We also tested some Apple devices
630100	635820	and here we found that the MacBook Pro, the iPhone, and the iPad are all vulnerable.
636820	644640	We also tested Windows 10 and here we noticed that the impact depends on the specific network card
644640	652940	that this operating system is using. For example, if we use an alpha or TP-Link USB Wi-Fi dongle,
652940	659820	then we found that Windows 10 was vulnerable. However, if we used the built-in network card
659820	666620	of certain laptops, which is typically an Intel network card, at least on the devices we tested,
666620	674400	then Windows 10 was not vulnerable. Finally, we also tested two Android devices, one more
674400	682480	recent Nexus 5X device, and it was vulnerable to our attack. But our fairly old Samsung device
682480	689100	was not vulnerable to our attack. So, let's show a demo of this attack in practice.
689100	696200	We will target an iPad device and we can see that before starting the attack, the iPad has a
696200	703160	throughput of about 10 megabit per second. Then, as an adversary, we will spoof two beacons and if
703160	709220	we look in Wireshark, this spoofed beacon has the maximum value for the back-off window and also the
709220	717240	maximum value for the AIFSN waiting period as well. And if we now measure the throughput on the iPad,
717240	722050	we see that it is substantially lower, meaning our attack has succeeded.
723220	727860	We also discovered several other attacks. For instance, we discovered a partial
727860	734150	machine-in-the-middle attack, and this attack bypasses channel operating validation in Linux.
734760	740700	And for the details, I will refer you to the paper. We also discovered battery depletion attacks,
740700	747000	where we can spoof beacons to make clients stay awake longer than they normally are.
747000	752940	Additionally, we also found that it is possible to send beacons as unicast frames, and this allows
752940	759120	us to target specific clients. This technique worked against all the devices we tested.
760060	766820	So how can we prevent these attacks in practice? Well, the idea is to authenticate beacons such
766820	773080	that an adversary can no longer spoof them. But before we get into those details, let's first
773080	780020	state the goal of our defense. And the goal is to come up with a practical and simple design
780020	786520	to encourage adoption in practice. So this means that our cryptographic operations must be
786520	792620	efficient, and that the bandwidth overhead must be low as well, because beacons are sent at a low
792620	799380	bitrate, and even adding a few bytes will consume a significantly higher airtime.
800380	805760	Finally, we also want the defense to be straightforward to implement, because then this
805760	812820	increases the chance that vendors will actually adopt our defense in practice. And ideally,
812820	818220	we will accomplish this by reusing existing cryptographic primitives that were already used in
818220	826640	Wi-Fi. So how can we achieve these design goals? Well, we will rely on symmetric encryption,
826640	833800	we will reuse a crypto-primitive that is already part of management frame protection. Additionally,
833800	840160	we only defend against outsider attacks. In other words, we assume that the adversary does not
840160	846560	possess the credentials of the network. And this assumption is similar to how broadcast
846560	855880	on multicast traffic is protected in WPA-213 as well. So concretely, how does our defense work?
855880	862480	Well, we add a new type length value element to beacons. This element is shown here,
862480	867940	and the two most important fields here are highlighted in green.
868960	873860	Now, before I discuss the details of these two important fields, I first want to mention that
873860	878700	clients that do not recognize this new type length value element, they will automatically
878700	885400	ignore it. This makes our defense backwards compatible with existing Wi-Fi implementations.
885880	892960	So first, we have the nonce field. And the nonce field is essentially an incremental number that
892960	900440	is used to prevent replay attacks. And then the mic field, which stands for message integrity check,
900440	907880	is a CMAQ or GMAQ authentication tag that is calculated over the beacon. And here the CMAQ
907880	914140	and GMAQ are existing cryptographic primitives of management frame protection. And the interesting
914140	921600	thing is that all WPA3 capable devices are already required to support these operations,
921600	925980	meaning vendors will already have implemented them by now.
926820	934020	So the remaining question now is, which key will be used to generate this authentication tag?
934200	940620	And here we decided to let the access point generate a new beacon protection key when it
940620	947920	starts. And this beacon protection key is always sent to the client when it is connecting. In
947920	953480	particular, even if the client may not support beacon protection, the access point will still
953480	959500	send this beacon key to the client. And older clients will simply ignore this new key,
959500	965920	but new clients will treat it as an indication that the access point supports beacon protection.
965920	972240	Now the interesting thing about this construction is that an adversary cannot manipulate the
972240	977700	handshake that transports the beacon key. This means that downgrade attacks are prevented because
977700	984060	an adversary cannot somehow remove the beacon key that is being transported to a client.
985320	991760	The final important thing to discuss is how that clients handle beacons that are received before
991760	998080	they have connected to a network. Because recall that a client only receives the beacon key once
998080	1003960	it has connected to the network, meaning that beacons that are received before that cannot be
1003960	1011280	authenticated because the client does not possess the key to verify their authenticity. So how can
1011280	1019340	we handle this in practice? Well, our solution is that before a client connects to a network,
1019340	1025640	it will store one beacon as a reference and it will extract all information of the network
1025640	1033140	from this reference beacon. And when the client now connects to this network and once it has
1033140	1038820	received the beacon protection key, it can take this reference beacon and then verify its
1038820	1046020	authenticity. And in case this check fails, it means there was an attack and then the client
1046020	1053100	can disconnect from the network. On the other hand, if the authenticity of the reference beacon
1053100	1061760	can be successfully validated, then the client can send data frames to the network and can operate
1061760	1068540	as normal. Now that we have our defense, an interesting question is how a client should
1068540	1073900	act when it receives a forged beacon. And we decided that in that case the client should
1073900	1079960	send a notification to the access point. This allows the access point to detect rogue IPs that
1079960	1087120	are far away. For example, in our illustration here, the rogue IP is out of range of the real IP.
1087160	1093500	However, when a client receives a forged beacon from the rogue IP, it can notify the real access
1093500	1100220	point of this and then the real access point can take appropriate actions. So now I want to discuss
1100220	1106100	some practical impact of our research. First and foremost, we created our specification of our
1106100	1113340	defense in collaboration with Intel, Broadcom, Qualcomm, and Huawei. And our defense is now part of the
1113340	1122180	draft IEEE 802.11 standard, meaning vendors will likely adopt this in practice as well. Moreover,
1122180	1127860	the Wi-Fi Alliance has recently expressed interest in our defense as well, meaning it might become
1127860	1137140	part of an update to WPA3 or it might become part of a separate certification program. Our defense
1137140	1142940	is independently also being implemented by Linux, where the kernel generates and verifies authentication
1142940	1149540	tags and host AP manages keys and enables beacon protection if it is supported by the network.
1149560	1155320	We will now show a demo of this on a recent Linux kernel, where if we start the access point and
1155320	1160760	view the beacons in Wireshark, we can indeed see that the authentication tag is being added to
1160760	1166640	beacons. If we now connect to this network, the client will indeed receive the beacon protection
1166640	1173520	key and it will enable beacon protection. As a result, if we now inject a beacon as an adversary,
1173520	1180100	the client will detect this spoofed beacon. In this demo, we made the client print a small debug message,
1180100	1184700	and if we now look at the debug log, we can confirm that the forged beacon has been detected
1184700	1192040	and the attack has been prevented. To conclude our talk, we proposed a defense to prevent
1192040	1198040	outsiders from forging beacons, and our focus on practicality has paid off, because our defense is
1198040	1204740	now part of the 802.11 standard. It is independently being implemented by Linux, and it might become
1204740	1209580	part of an update to WPA3. Thank you for your attention.