1. Securing the WUR Date: 2016-07-26 Authors: July 2016 March 2014
doc.: IEEE /0216r0
July 2016
Securing the WUR
Date:
Authors:
Yunsong Yang, Huawei
Stephen McCann, Blackberry

2. March 2014
doc.: IEEE /0216r0
July 2016
Abstract
The WUR concept has been introduced in [1-3]. This contribution describes some attacks that may be launched on a WUR-capable station, potentially with an effect equivalent to that of denial-of-service (DoS) attacks. Certain high level WUR design requirements for countering such attacks have been suggested.
Yunsong Yang, Huawei
Stephen McCann, Blackberry

3. Vulnerability of WUR (I)
July 2016
Vulnerability of WUR (I)
A main target area of WUR includes sensors running on coin batteries. Malicious attacks on these devices using wake-up packets can cause the WUR receiver to falsely wake up the main radio. Frequently repeating such attacks can quickly drain the battery and ultimately disable the device.
E.g., a security motion sensor may be designed to normally wake up once a day (e.g., to report battery status) and to last for years. But if a hacker can successfully wake up the main radio on the sensor once per second, the sensor may be disabled within one to a few days (see appendix for the estimation).
Imagine the home owner who installed this sensor is on a Christmas trip …
Yunsong Yang, Huawei

4. Vulnerability of WUR (I) - Brute-force Attack
July 2016
Vulnerability of WUR (I) - Brute-force Attack
Threat model: the attacker sends one or more Wake-up packets with randomly or sequentially selected WUR addresses until one matches the right address (the attacker can see the STA is waked up). Then, the attacker sends the right wake-up packet repeatedly to kill the battery.
The attacker can send several Wake-up packets at a time to speed it up.
Difficulty to perform: relatively easy unless the WUR address is long enough.
Requirements to counter the attack:
The WUR address should be long enough to make it hard to guess right.
The WUR address should be changed frequently (preferably changed during every wake-up) so that a random success in guessing it right doesn’t lead to repeated successes, making the brute-force attack less rewarding.
Yunsong Yang, Huawei

5. Vulnerability of WUR (I) - Replay Attack
July 2016
Vulnerability of WUR (I) - Replay Attack
Threat model: the attacker obtains a legitimate wake-up packet by eavesdropping then replays the wake-up packet repeatedly to kill the battery.
Difficulty to perform: easy unless the WUR address is changed during every wake-up.
Requirements to counter the attack:
The WUR address should be changed frequently (preferably changed during every wake-up) so that the replay attack won’t work, as a legitimate WUR address is used only once (for a long while).
Yunsong Yang, Huawei

6. Vulnerability of WUR (II)
July 2016
Vulnerability of WUR (II)
If the WUR address is changed during every wake up event as a counter-measure against attacks on the battery as described previously, a second type of vulnerability may arise, i.e., an attacker may impersonate the AP or the STA to cause the AP and the STA out of synch in terms of the WUR address that each use.
Threat model I: the attacker impersonates a legitimate STA who falsely detects a wake-up packet (i.e., a faked false positive event) and starts to communicate with the AP on its main radio (while the legitimate STA is still in deep sleep), triggering the AP to assign a new WUR address to the legitimate STA, thus causing the AP and the legitimate STA out of synch in terms of the WUR address being used.
Difficulty to perform: easy to hard depending on security measures.
Requirements to counter the attack:
During every wake-up event, the AP should verify the authenticity of the message(s) from the STA before using a new WUR address for the STA.
Yunsong Yang, Huawei

7. Vulnerability of WUR (II) – Cont’d
July 2016
Vulnerability of WUR (II) – Cont’d
Threat model II: the attacker impersonates the legitimate AP and wakes up the STA (through interception/eavesdropping then replay, or brute- force attack), and then assigns a faked WUR address to the STA before putting the STA into deep sleep. As a result, the STA’s WUR keeps monitoring the wrong WUR address and won’t be waked up by the legitimate AP again.
Difficulty to perform: medium to hard depending on security measures.
Requirements to counter the attack:
During every wake-up event, the STA should verify the authenticity of the message(s) from the AP before the STA uses the new WUR address.
Yunsong Yang, Huawei

8. July 2016
Summary
It is NOT our intention to suggest that the WUR SG addresses the security issues that might already exist in PHY and MAC today. Rather, we want to narrowly focus on preventing an attacker from effectively achieving the same goal of denial-of-service (DoS) attacks through disabling a device’s battery or causing the device to be unable to be waked up by a legitimate counterpart.
Thus, we suggest that the WUR SG considers counter-measures in the WUR design to mitigate the potential impacts of such attacks on the WUR.
Following WUR design requirements may be considered as a starting point:
The WUR address should be long enough.
The WUR address should be changed frequently, preferably changed during every wake- up event.
During every wake-up event, the STA and the AP should verify the authenticity of the message(s) from each other before assigning or using the new WUR address for the STA’s next wake-up event.
Yunsong Yang, Huawei

9. July 2016
Appendix: Estimation of battery capacity consumed per day under repeated attacks
Assumptions:
Wake up frequency: once per second (continually for 24 hrs).
Average wake up duration (considering message exchanges needed to correct the situation): 50 msec.
Estimated average current during wake up period: 50 mA (Doc ax- simulation-scenarios).
Result:
24 x 3600 x 0.05 x 50 / 3600 = 60 mAh
[4, 5] suggest that the effective capacity
can be significantly reduced (by as much as
one half ) under high discharge rate.
Conclusion:
Most coin batteries would last less than a
day under such repeated attacks.
Yunsong Yang, Huawei

10. July 2016
References
[1] r1 [2] r0 [3] r0 [4]. [5].
Yunsong Yang, Huawei