A Study of MAC Address Randomization in Mobile Devices and

When it Fails
arXiv:1703.02874v1 [cs.CR] 8 Mar 2017

Jeremy Martin ∗, Travis Mayberry †, Collin Donahue, Lucas Foppe, Lamont Brown,
Chadwick Riggins, Erik C. Rye ‡, and Dane Brown §

US Naval Academy

Abstract 1 Introduction
Smartphones are one of the most impactful technolo-
Media Access Control (MAC) address randomization gies of this century. The ability to access the Internet
is a privacy technique whereby mobile devices rotate anytime and anywhere has fundamentally changed
through random hardware addresses in order to pre- both work and personal life across the globe [21]. It is
vent observers from singling out their traffic or phys- gradually becoming clear, however, that in exchange
ical location from other nearby devices. Adoption for this level of access to the Internet people may be
of this technology, however, has been sporadic and giving up a substantial amount of privacy. In par-
varied across device manufacturers. In this paper, ticular, it has recently been made public that state
we present the first wide-scale study of MAC address sponsored intelligence agencies, in countries such as
randomization in the wild, including a detailed break- Russia and China [5, 11, 3], as well as private sec-
down of different randomization techniques by oper- tor companies [18], are actively attempting to track
ating system, manufacturer, and model of device. cellphone users.
We then identify multiple flaws in these implementa-
Smartphones conventionally have two major modes
tions which can be exploited to defeat randomization of communication, both of which can potentially be
as performed by existing devices. First, we show that used to track users. The first and most obvious is the
devices commonly make improper use of randomiza-
cellular radio itself [8, 20]. However, an often over-
tion by sending wireless frames with the true, global looked second avenue for tracking cellphones (and
address when they should be using a randomized ad-
their corresponding users) is the 802.11 (WiFi) ra-
dress. We move on to extend the passive identifica-
dio that most smart phones also use.
tion techniques of Vanhoef et al. to effectively defeat
Every 802.11 radio on a mobile device possesses
randomization in ∼96% of Android phones. Finally,
a 48-bit link-layer MAC address that is a globally
we show a method that can be used to track 100% of
unique identifier for that specific WiFi device. The
devices using randomization, regardless of manufac-
MAC address is a crucial part of WiFi communica-
turer, by exploiting a previously unknown flaw in the
tion, being included in every link-layer frame that is
way existing wireless chipsets handle low-level control
sent to or from the device. This unfortunately poses
frames.
a glaring privacy problem because any third party
eavesdropping on nearby WiFi traffic can uniquely
∗ [email protected]
identify nearby cellphones, and their traffic, through
† [email protected] their MAC addresses [10].
‡ [email protected] There is one particular type of WiFi packet, called
§ [email protected] a probe request frame, that is an especially vulner-

1
able part of WiFi traffic with respect to surveil- • We present the first manufacturer and device
lance. Since probe requests continuously broadcast breakdown for MAC randomization, describing
at a semi-constant rate they make tracking trivial. the particular technique each uses. Our results
Mobile devices are effectively playing an endless game indicate that adoption rates are surprising low,
of digital “Marco Polo,” but in addition to “Marco” specifically for Android devices.
they are also broadcasting out their IDs (in the form
of a MAC address) to anyone that cares to listen. • We review previous techniques for determining
To address this problem, some modern mobile de- global MAC addresses and find them to be in-
vices make use of temporary, randomized MAC ad- sufficient. We provide additional context and im-
dresses that are distinct from their true global ad- provements to existing passive and active tech-
dress. When probe requests are sent out, they use a niques, substantially increasing their effective-
randomized pseudonym MAC address that is changed ness.
periodically. A listener should be unable to continu-
ously track the phone because the MAC changes in a • We identify significant flaws in the majority of
way that hopefully cannot be linked to the previous randomization implementations on Android de-
address. vices. These flaws allow for trivial retrieval of
the global MAC address.
In this work we evaluate the effectiveness of
various deployed MAC address randomization • Discovery and implementation of a control frame
schemes. We first investigate how exactly differ- attack which exposes the global MAC address
ent mobile Operating Systems (OSs) actually imple- (and thus allows tracking/surveillance) for all
ment randomization techniques, specifically looking known devices, regardless of OS, manufacturer,
at how the addresses are generated and under what device type, or randomization scheme. Further-
conditions the devices actually use the randomized more, Android devices can be susceptible to this
address instead of the global one. Using real-world attack even when the user disables WiFi and/or
datasets we provide the first evaluation of adoption enables Airplane Mode.
rates for randomization across a diverse manufacturer
and model corpus.
After establishing the current state of randomiza- 2 Background
tion for widely used phone models and OS versions,
we move on to show several weaknesses in these 2.1 MAC Addresses
schemes that allow us to track phones within and
across multiple collections of WiFi traffic. Our work Every network interface on an 802.11 capable device
builds on the fingerprinting techniques of Matte et al. has a 48-bit MAC address layer-2 hardware identi-
[17] in addition to new approaches for deanonymizing fier. MAC addresses are designed to be persistent and
phones based on weaknesses we discovered while ana- globally unique. In order to guarantee the unique-
lyzing wireless traffic from many randomizing phones. ness of MAC addresses across devices the Institute of
This paper makes the following novel contribu- Electrical and Electronics Engineers (IEEE) assigns
tions: blocks of addresses to organizations in exchange for
a fee. A MAC Address Block Large (MA-L), com-
monly known as an Organizationally Unique Iden-
• We decompose a large 802.11 corpus, providing tifier (OUI), may be purchased and registered with
the first granular breakdown of real-world MAC the IEEE [15], which gives the organization control of
address randomization. Specifically, we develop and responsibility for all addresses with a particular
novel techniques to identify and isolate random- three-byte prefix. The manufacturer is then free to
ization and randomization schemes from large assign the remaining low-order three bytes (224 dis-
collections of wireless traffic. tinct addresses) any value they wish when initializing

2
devices, subject to the condition that they do not use bit set, and is predisposed for use within MAC ad-
the same MAC address twice. dress randomization schemas. One such example, the
An implication of the IEEE registration system is Google owned DA:A1:19 CID, is prominent within
that it is trivial to look up the manufacturer of a de- our dataset.
vice given its MAC address. Using, again, the exam- With the advent of randomized, locally assigned
ple of a wireless eavesdropper, this means that anyone MAC addresses that change over time, tracking a
listening to 802.11 traffic can determine the manu- wireless device is no longer trivial. For this reason,
facturer of nearby devices. To combat this, the IEEE we frequently observe 802.11 probe requests using lo-
also provides the ability to purchase a “private” OUI cally assigned addresses when the device is in a disas-
which does not include the company’s name in the sociated state (not associated with an AP). When a
register. However, this additional privacy feature is mobile device attempts to connect to an AP, however,
not currently used by any major manufacturers that it reverts to using its globally unique MAC address.
we are aware of. As such, tracking smartphones becomes trivial while
they are operating in an associated state.
OUI NIC Since mobile devices are usually only associated
while the user is relatively stationary (otherwise they
01 : 23 : 45 : 67 : 89 : AB would be out of range of the AP), tracking them in
this state is less of a privacy vulnerability than hav-
ing the ability to track devices in an unassociated
00000001 Unicast/Multicast Bit state, which usually occurs when the user is mov-
ing from one location to another. Additionally, there
Universal/Local Bit are several good reasons to use a global address in
an associated state, such as to support MAC address
Figure 1: 48-bit MAC Address Structure filtering on the network. Therefore we concentrate,
in this paper, on evaluating randomization methods
and tracking of unassociated devices.
In addition to the public, globally unique, and
manufacturer assigned MAC address, modern devices
frequently use locally assigned addresses [6] which are
2.2 Mobile OS MAC Randomization
distinguished by a Universal/Local bit in the most A particularly sensitive privacy issue arises from
significant byte. Locally assigned addresses are not the manner in which wireless devices identify access
guaranteed to be unique, and generally are not used points within close proximity. Traditionally, devices
in a persistent manner. Locally assigned addresses perform active scanning where they broadcast probe
are used in a variety of contexts, including multi- request frames asking nearby APs to identify them-
Service Set IDentifier (SSID) configured access points selves and respond with 802.11 parameter informa-
(APs), mobile device-tethered hotspots, and peer-to- tion required for connection setup. These probe re-
peer (P2P) services. A visual depiction of the MAC quest frames require a source MAC address, but if an
address byte structure is illustrated in Figure 1. 802.11 device uses its globally unique MAC address
Most importantly for this paper, locally assigned then it is effectively broadcasting its identity at all
addresses may also be used to create randomized times to any wireless receiver that is nearby. Wire-
MAC addresses as an additional measure of privacy. less device users can then easily be tracked across
Similar to an OUI, a three-byte Company Identi- temporal and spatial boundaries as their devices are
fier (CID) prefix can be purchased from the IEEE, transmitting with their unique identity.
with the agreement that assignment from this ad- To combat this privacy concern, both Android and
dress space will not be used for globally unique ap- Apple iOS operating systems allow for devices in a
plications. As such, a CID always has the local disassociated state to use random, locally assigned

3
MAC addresses when performing active scans. Since it may represent the Bluetooth MAC address of the
the MAC address is now random, users gain a mea- device. Because of this, the reader is left with little
sure of anonymity up until they associate with an understanding on the scope of practical use of these
AP. attacks. Namely, is the attack truly viable against
The particular software hooks used for randomiza- devices performing randomization?
tion vary between operating systems. See Appendix The first contribution of this paper is a better eval-
A for a discussion of the OS mechanisms and config- uation of the attacks presented by Matte et al. [17].
uration files that support MAC randomization. Using more recent real-world data, we verify that this
technique is plausible for defeating randomization for
a small set of devices. However, we also show that an
3 Related Work improvement on their technique can achieve a higher
success rate, up 99.9% effectiveness against vulner-
Vanhoef et al. [22] present several techniques for able devices. We are also able to confirm that the
tracking devices regardless of privacy countermea- retrieved MAC address is in fact the 802.11 WiFi
sures such as MAC address randomization. These identifier and not the Bluetooth address using addi-
attacks rely on devices’ support for Wi-Fi Protected tional techniques. More importantly, we provide a
Setup (WPS), a protocol that allows unauthenti- real-world assessment for the scope of the attack, re-
cated devices to negotiate a secure connection with vealing that only a small portion of Android devices
access points. Unfortunately, in order to facilitate are actually vulnerable.
this process, extra WPS fields are added in a device’s
probe requests that contain useful information for de- Vanhoef et al. [22] and Matte et al. [17] present
vice tracking. Among these is the manufacturer and an additional technique: fingerprinting of the probe
model of the device, but also a unique identifier called request 802.11 Information Elements (IEs). IEs are
the Universally Unique IDentifier-Enrollee (UUID-E) optional, variable length fields which appear in WiFi
which is used to establish WPS connections. The flaw management frames and are generally used to im-
that Vanhoef et al. [22] discovered is that the UUID-E plement extensions and special features on top of
is derived from a device’s global MAC address, and by the standard WiFi protocol. Importantly, there are
using pre-computed hash tables an attacker can sim- enough of these extensions and manufacturer spe-
ply lookup the UUID-E from the table and retrieve cific functions that the various combinations which
the global MAC address [22, 16]. We refer to this are supported on a particular device may be unique
technique as UUID-E reversal. Since the UUID-E to that device, causing the IEs to form a fingerprint
does not change, the implication is that even if the which can be used to identify traffic coming from that
MAC address is randomized, an attacker can still re- device.
cover the original, global address by performing this However, we find one significant flaw in the eval-
reversal technique on the UUID-E. uation of these fingerprints: locally assigned MAC
While the revelation of the flaw was significant, addresses were ignored by the authors. Nearly all
several holes in the analysis were observed due to the randomization schemes utilize locally assigned MAC
dataset on which the work was evaluated. The at- addresses to perform randomization. As such, pre-
tack was applied against an anonymized dataset from vious research failed to identify problems observed
2013 [7]. This dataset did not include randomized when tracking randomized MAC addresses. A sim-
MAC address implementations as they did not exist ple example of this is the signature of a device’s probe
in 2013. Additionally, due to the fact that the data request, which we observed changing during random-
was anonymized, and ground truth was not available, ization and even when not randomizing. Only by ob-
a validation of the reversal technique was not pro- serving these behaviors can we truly implement effec-
vided. The authors state that the address could not tive derandomization techniques and present honest
be confirmed to be the WiFi MAC address, rather reflections on the limitations of the attack methods.

4
 Also presented in [22] is a revival of the Karma at- web browsing, email, etc., but only automatic, non-
tack using a top-n popular SSID honeypot approach. personal traffic sent by the device.
As noted above, MAC randomization stops once a de-
vice becomes associated with an AP. Karma attacks
are active attacks where a rogue AP is configured 4.1 Ethical Considerations
with an identical name (SSID) to one that the device
Our collection methodology is entirely passive. At no
is set up to automatically connect to. In effect, this
time did we attempt to decrypt any data, or perform
forces the devices into an authenticated state where
active actions to stimulate or alter normal network
it reveals its global MAC address and bypass ran-
behavior while outside of our lab environment. Our
domization. We validate this attack by finding that
intent is to show the ease with which one can build
the increased prevalence of seamless WiFi-offloading
this capability with low-cost, off-the-shelf equipment.
from cellular networks means that many devices in
However, given the nature of our data collection, we
the wild are vulnerable.
consulted with our Institutional Review Board (IRB).
The primary concerns of the IRB centered on: i)
the information collected; and ii) whether the exper-
4 Methodology iment collects data “about whom” or “about what.”
Because we limit our analysis to 802.11 manage-
Our initial goal is to identify which mobile devices are ment frames and unencrypted mDNS packets, we do
using randomization, in order to narrow down further not observe Personally Identifiable Information (PII).
investigation into their exact methods for doing so. Although we observe IP addresses, our experiment
Since this is not a capability that is advertised on a does not use these layer-3 addresses. Even with an
spec sheet, we resort to broad capture and analysis IP address, we have no reasonable way to map the
of WiFi traffic in order to determine which device address to an individual. Further, humans are in-
models are doing randomization. cidental to our experimentation as our interest is in
Over the course of approximately two years, we the randomization of wireless device layer-2 MAC ad-
captured unencrypted 802.11 device traffic using in- dresses, or “what.” Again, we have no way to map
expensive commodity hardware and open-source soft- MAC addresses to individuals.
ware. We primarily use an LG Nexus 5 Android Finally, in consideration of beneficence and re-
phone running Kismet PcapCapture paired with an spect for persons, our work presents no expectation
AWUS036H 802.11b/g Alfa card. We hop between of harm, while the concomitant opportunity for net-
the 2.4GHz channels 1, 6, and 11 to maximize cov- work measurement and security provides a societal
erage. We additionally employ several Raspberry benefit. Our experiment was therefore determined to
Pi devices running Kismet with individual wireless not be human subject research.
cards each dedicated to channels 1, 6, and 11. Our
corpus spans January 2015 to December 2016 and
4.2 Identifying Randomization
encompasses approximately 9,000 individual packet
captures. The collection contains over 600 gigabytes We know devices implement MAC randomization in
(GBs) of 802.11 traffic, consisting of over 2.8 million different ways. In order to quantify the vulnerabili-
unique devices. ties of employed randomization policies, we first at-
It is important to note that, since devices only ran- tempt to categorize devices into different bins, with
domize when they are unassociated, the only traffic identical behavior, so that we can investigate char-
we are interested in is 802.11 management frames acteristics of these individual techniques and seek to
and unencrypted multicast Domain Name System identify flaws in their implementation. For instance,
(mDNS) packets. Therefore we did not capture as we will see, all iOS devices fall into the same bin,
actual intentional user traffic from the device, i.e. in that they handle randomization in a similar way.

5
 Table 1: Corpus Statistics Table 2: Locally Assigned Bins Table 3: Randomization Bins
Category # MACs Category # MACs Category # MACs
Corpus 2,604,901 Locally Assigned 1,400,753 Randomized 1,388,566
Globally Unique 1,204,148 Service 3,147 Android: DA:A1:19 (WPS) 8,761
Locally Assigned 1,400,753 Randomized 1,388,566 Android: DA:A1:19 43,924
Unknown 9,040 Android: 92:68:C3 (WPS) 8,961
iOS 1,326,951
Windows 10 / Linux 59

Android devices, on the other hand, differ signifi- had locally assigned MAC addresses. Recall that lo-
cantly from iOS, and also vary greatly from manu- cally assigned addresses are not only used for ran-
facturer to manufacturer. domization. Therefore, after partitioning the corpus,
Our first step is to identify whether a device is we separate the locally assigned MAC addresses that
performing randomization. This starts with extract- are used for services such as P2P and WiFi-Extenders
ing all source MAC addresses derived from probe re- from those used as randomized addresses for privacy
quest frames in our corpus. If the local bit of the purposes. Doing so required us to manually inspect
MAC address is set, we store the address as a lo- the frame attributes and look for identifying charac-
cally assigned MAC address in our database. Since teristics.
randomized addresses cannot be unique, we assume One prevalent P2P service that makes use of lo-
at this point that any device using randomization cally assigned addresses is WiFi-Direct. Fortunately,
will set the local bit in its MAC address and there- WiFi-Direct operations contain a WiFi-Direct IE
fore all randomization candidates will be in this data (0x506f9a,10). Specifically, the following attributes
set. For each address we then parse the advertised are are observed with all WiFi-Direct traffic: i) WiFi-
WPS manufacturer, model name, model number, Direct IE is present, ii) the observed OUI is sim-
and uuid e values. Additionally, we build signatures ply the original OUI with the local bit set, and iii)
derived from a mapping of the advertised 802.11 IE the SSID value, if observed, is set with a prefix of
vendor fields using techniques from related work in DIRECT-. Furthermore, manual inspection of the
device-model classification [22, 13]. Each MAC ad- packet capture reveals that these devices use a single
dress, associated WPS values (when applicable), and locally assigned MAC address for all observed probe
the device IE signature are stored in our database. request frames. As these devices are not conducting
Our device signatures are created using custom randomization we remove them from our dataset.
built Wireshark dissectors to parse the 802.11 ven- Similarly, Nintendo devices operating in a P2P
dor IE fields and values. Our modifications to stan- mode are observed utilizing a locally assigned ad-
dard wireshark files (packet-ieee80211.c and packet- dress. Associated frames use a modified Nintendo
ieee80211.h) allow us to efficiently create the indi- OUI, one with the local bit set. Additionally, all
vidual device signatures as we process the packet Nintendo P2P probe requests contain a unique Ven-
captures, eliminating any need for post-processing dor Specific IE, 0x00:1F:32, allowing for an efficient
scripts. Furthermore, this allows us to use a signa- identification and removal from our dataset.
ture as a display filter while capturing. We will later Lastly, the remainder of our service-based locally
use the device signatures for both passive and active assigned addresses were attributed to WiFi exten-
derandomization techniques. ders forwarding client probe requests. These were
Our corpus contained a total of ∼66 million in- also identified as modifying their original OUI by set-
dividual probe requests. We have a dataset of 2.6 ting the local bit. Commonly observed OUIs, such as
million unique source MAC addresses after removing Cisco, D-Link, and Belkin indicated a likely associ-
duplicates. In Table 1 we observe that 1.4 million ation to infrastructure devices. We confirmed our
(∼53%) of the 2.6 million distinct MAC addresses assumptions through manual packet analysis, which

6
showed: i) the MAC address never changes, ii) each separate the remaining ∼1.388 million addresses into
unique device probes for only one SSID, and iii) de- distinct bins. First we perform a simple query of
vices with WPS attributes clearly indicate wireless our database where we identify the most common
extender models. three byte prefixes. We expect that the prefixes with
Table 2 illustrates that 99.12% of all locally as- the highest occurrences will be the CID owned by
signed mac addresses are randomized addresses, rep- the representative devices. Our findings were sur-
resenting ∼53% of our total corpus. While this may prising: first, the Google owned CID DA:A1:19, was
seem like it indicates a large rate of adoption for MAC by far the most commonly observed prefix (52,595),
randomization, these addresses do not directly corre- while the second most common prefix 92:68:C3, ob-
late to the number of unique devices in our dataset. served 8,691 times was not an IEEE allocated CID,
While globally unique addresses have a 1-to-1 rela- but rather a Motorola owned OUI with the local bit
tionship with individual devices, a device perform- set.
ing randomization has a 1-to-many relationship. It The remaining 177k observed three-byte prefixes,
is plausible that a device conducting randomization each with total occurrences ranging from a low of
may have tens of thousands of addresses over a collec- two to a high of seven, show no indication of being
tion period. Therefore we posit that much less than a defined prefix or CID. While we expected to see
∼50% of devices conduct randomization. the Google owned CID, we also expected to see addi-
Our goal, to identify and evaluate potential flaws tional CIDs configured by manufacturers to override
in currently fielded randomization policies, requires the default Google CID.
that we must first answer non-trivial questions about
our real-world dataset. How many devices were ac-
tually performing randomization? Which manufac-
turers and models have implemented randomization 5.1.1 92:68:C3
in practice and why? What operating systems are
prevalent? Which randomization policies are actu- Investigating the 92:68:C3 prefix in more detail, we
ally used? see that devices using this prefix always transmit
granular WPS details. This is helpful as it lets us
As discussed above, we must first identify distinct
easily determine the device model (see §3). First,
bins of randomization within the data. Table 3 high-
the Motorola Nexus 6 is the only device using this
lights the results of this analysis. We completed this
prefix. Using the WPS derived UUID-E as a unique
analysis by evaluating the following; i) the MAC
identifier, we see that there were 849 individual Mo-
address prefix (OUI, CID, random), ii) WPS at-
torola Nexus 6 devices in our dataset. Second, in
tributes, iii) 802.11 IE derived device signatures, and
order to retrieve the global MAC address we use
iv) mDNS fingerprinting techniques [16]. Lastly, we
the UUID-E reversal technique previously mentioned
confirm our analysis using devices procured by our
[22, 16]. We find that the actual prefix of the device’s
team and evaluated in a controlled Radio Frequency
MAC address is not the expected 90:68:C3 OUI.
(RF) environment. We provide detailed analysis of
Rather, we observe a set of different Motorola owned
our methods, results, and answers to our stated ques-
OUIs. In combination with with the config.xml file
tions in §5.
(see Appendix A) retrieved from publicly available
repositories we identify that the prefix 92:68:C3 was
purposefully set by Motorola to replace the Google
5 Analysis owned CID.
5.1 Android Randomization Searching open source Android code repositories
revealed no additional config.xml defined prefixes
After removing all of the service-based locally as- other than the Google and Motorola ones. This
signed MAC addresses described in §4.2, we aim to matches what we observe in our real-world dataset.

7
5.1.2 DA:A1:19 Table 4: DA:A1:19 Manufacturer Breakdown
Manufacturer Total Devices Model Diversity
Huawei 1708 11
The analysis of the Google CID DA:A1:19 proved Sony 277 23
more complex, having serious implications to prior BlackBerry 234 4
HTC 108 2
work in derandomization attacks. Unlike the Mo- Google 13 2
torola prefix, not all devices using the Google CID LG 1 1
transmit WPS attributes. This had multiple ef-
fects on our analysis. First, we were unable to eas-
ily identify the manufacturer and model information In all, devices having randomized MAC addresses
when no WPS information was present. Lacking a with a Google CID and containing WPS attributes
UUID-E, we were unable to precisely identify total amount to a total of 2,341 unique devices. Taking
device counts. More importantly, we were unable to into account the 849 unique Motorola Nexus 6 de-
retrieve the global MAC address via the reversal tech- vices, only 3,188 devices spanning 44 unique mod-
nique. Surprisingly, only ∼19% of observed MAC els are susceptible to the UUID-E reversal attack.
addresses with the Google CID contain UUID-E val- Effectively, ∼99.98% of the locally assigned MAC
ues. Since the reversal technique of Matte et al. [17] addresses in our corpus are not vulnerable to the
require a UUID-E, this emphasizes the fact that pre- UUID-E attack. Furthermore, our corpus contains
vious evaluations are insufficient. A large majority approximately 1.2 million client devices with glob-
of Android phones are not vulnerable to UUID-E re- ally unique MAC addresses and over 600 manufactur-
versal, despite how valuable the technique initially ers and 3,200 distinct models using WPS data fields.
seems. This begs the question, are a large number of Android
devices not conducting randomization? Do we expect
We evaluated the 8,761 addresses that have WPS the 43,924 randomized addresses using the Google
values before attempting to breakdown the 43,924 CID that did not not transmit WPS information to
DA:A1:19 MAC addresses with no WPS information. make up all remaining Android devices?
We observed a diverse, yet limited spread of manufac- We attempt to answer these questions by evaluat-
turers and models, depicted in Table 4. Huawei was ing the 43,924 DA:A1:19 MAC addresses where no
the most prevalent manufacturer observed, primarily WPS derived data is available. The process proceeds
attributed to the (Google) Nexus 6P (1660 unique as follows:
devices). Various versions of the Huawei Mate and
Huawei P9 were also commonly observed. Sony was 1. Divide the entire bin into segments, based on the
well-represented with 277 unique devices across 23 device’s signature described in §4.2, resulting in
variations of Xperia models. There were several sur- 67 distinct device signatures, with a starting hy-
prising observations in this list, namely that Samsung pothesis that each signature represents a distinct
was absent despite having the largest market share model of phone.
for Android manufacturers [19]. Blackberry, HTC,
and LG were also poorly represented. The Black- 2. For each signature, parse every packet capture
berry device models were actually four derivations of file where that device signature and the CID
the Blackberry Priv, accounting for 277 unique de- DA:A1:19 were observed.
vices observed. HTC was largely represented by the
HTC Nexus 9 from the Google Nexus line, which ex- 3. Apply to our parsing filter our custom Tshark
plains the likely use of randomization. The HTC One device signature and limit to probe request
M10 was the remaining HTC device and was only ob- frames.
served once. The only observed LG device was the
LG G4 model. We provide a full device breakdown The output of the algorithm is the source MAC ad-
in Appendix C. dress, sequence number, SSID, and device signature.

8
 Left with 2,858 output files, each mapping a device Table 5: DA:A1:19 no WPS
signature with distinct packet capture, we system- Category Confirmed % of no WPS
atically retrieve the global MAC addresses for the Bin 1 √ 57.7%
LG Nexus 5X
randomized devices. We will describe in detail the Google Pixel
√
methods for derandomization for this portion of the Bin 2 √ 18.5%
dataset in §6. After we obtain the global MAC ad- LG G5 √
LG G4
dress for the set of randomized MAC addresses within Bin 3 √ 2.0%
each bin, we attempt to identify the device model us- OnePlus 3 √
Xiaomi Mi Note Pro
ing a variety of techniques. It is trivial to identify Bin 4 .2%
√
the manufacturer as the OUI provides sufficient res- Huawei √
Sony
olution. However, in order to conjecture the device Bin 5 2.6%
√
model we borrow from the work of [16] in which we Cat S60
obtain model granularity from MAC address decom- Bin 6 √ 12.2%
Composite
position. Next, we look for any case where a device Bin 7 6.8%
using a global MAC address as the source of a probe Unknown

request matches the desired signature and also trans-

mitted a mDNS packet at some point. For this sub-
set we simply retrieve the model information from Next, we evaluate bin 2, representing 18.5% of the
the mDNS packet [16]. This leaves us with guesses category’s total. We observe only LG devices, specif-
as to what devices randomize MAC addresses using ically we posit that LG G series devices make up this
the DA:A1:19 CID and transmit no granular WPS- subset. We confirm that both the LG G4 and G5 de-
derived model data. We posit that our set of 67 sig- vices match the signatures and behavior of this bin.
nature bins can be condensed into groups of similar We surmise that additional G series devices are rep-
signatures based on our derived model correlations. resented, however we have no validation at this time.
In order to better evaluate our assumptions, and Worth mentioning is that the LG G4 and Pixel iden-
now that we have a smaller, manageable set of pos- tified in the previous DA:A1:19 with WPS section
sible devices, we procure devices for lab testing. We were only observed because a WPS action was trig-
test each device using an RF enclosed chamber to gered. By default, WPS data is not transmitted by
ensure we limit our collection to only our individual the devices in our no-wps category. We confirm this
test phones. We leave each device in the chamber for analysis in our lab environment, observing WPS data
approximately five minutes, collecting only the probe fields only when the user triggers a WPS event.
requests. In bin 3, a smaller bin (2%), the OnePlus 3, and
We evaluate the collection results by comparing the Xiamoi Mi Note Pro are representative of the
to our derived signatures and ask the following: do identified signatures.
we observe MAC address randomization? If so, does Bin 4, the smallest of our bins with less then one
the device signature match expectations when using percent of our dataset, consisted of Huawei and Sony
a global address? Similarly, does the device signa- devices. These are devices seen using WPS, but in
ture match expectations when using a randomized some frames do not include the WPS data fields.
address? Our findings are presented in Table 5. The Cat S60 smartphone was the only device iden-
Bin 1 is represented by the Google devices LG tified in bin 5. As in other bins, we make no claim
Nexus 5X and Google Pixel. This bin encompasses that no other devices share this signature.
57.7% of the 43,924 MAC addresses observed using Bin 6 represents a combination of the aforemen-
the Google CID without WPS data. It is prudent to tioned devices observed in the various bins. This is
mention that we cannot claim that is an exhaustive caused by a device, that on occasion rotate between
list of devices implementing randomization using this a standard device signature and a stripped down ver-
set of signatures. sion with limited 802.11 IE fields. An example of this

9
signature behavior is described in §6.4 and depicted Moto E2. We acquired Moto G4 and E2 smartphones
in Figure 2. As such, this bin is represented by the and confirmed our hypothesis. Additionally, we ob-
previously mentioned devices. served that a Moto Z2 Play device model shares the
We fail to identify anything with any sense of con- same randomization behavior and signature as the
fidence within bin 7. Moto G4.

5.1.3 Motorola 5.1.4 Samsung

After an exhaustive look at the randomization It is interesting to note that we never observed
schemes employed by Android we still lack any evi- Samsung devices performing MAC address random-
dence of MAC address randomization by Samsung or ization, despite being the leading manufacturer of
Motorola devices (other then the Google based Mo- Android smartphones. Samsung uses their own
torola Nexus 6). We attempt to find any evidence of 802.11 chipsets, so it is possible that chipset compati-
non-standard randomization employed by these mod- bility issues prevent implementing randomized MACs
els by looking at probe requests with globally as- addresses. Samsung devices alone represent ∼23% of
signed MAC addresses. In a similar manner to how Android devices in our data set, contributing sub-
we identified the most common prefixes for locally as- stantially to the low adoption rate that we see.
signed addresses, we attempt to identify OUIs with
unusually high occurrences within individual packet
5.2 iOS Randomization
captures. Our premise is that this will indicate the
use of an OUI as a prefix for a set of randomized After completing the randomization analysis of
MAC addresses. Android devices, we still have over 1.3 million
We first ruled out all P2P service related addresses MAC addresses not attributed to any randomization
as previously described, leaving a single manufacturer scheme. Next we turn to the analysis of iOS random-
of interest - Motorola. We identified multiple occur- ization.
rences of various Motorola OUIs with an abnormally Upon the release of iOS 8.0, Apple introduced
high percentage of the unique addresses in a packet MAC address randomization, continuing with mi-
capture. After inspecting forty captures with this nor but valuable updates to the policy across subse-
anomaly we confirmed that a subset of Motorola de- quent iOS releases. We were faced with an immediate
vices perform randomization using neither a CID nor dilemma, how do we identify iOS associated probe
an OUI with the local bit set. These devices used requests? Apple iOS devices do not transmit WPS
one of several Motorola owned OUIs, using the global fields to indicate any sort of model information, and
MAC address occasionally, and a new randomized we had no knowledge of any Apple owned CID. In
MAC address when transmitting probe requests. order to identify any prefix pattern we once again uti-
This is an especially strange result because it shows lized our RF-clean environment to test Apple device
that Motorola is using randomized global addresses. behavior. Our goal was to create as many random-
This violates the core expectation that no two devices ized MAC addresses as possible from a device and
will use the same global MAC address. In particular, look for a pattern in the resulting prefixes. To force
it is possible for one of these devices to temporarily a new randomized MAC address we simply enable
use the true, global MAC address of another device and disable WiFi mode repeatedly.
as one of its random addresses. Our initial thought was that Apple would use a
We identified two distinct signatures consistently OUI or CID like other manufacturers and simply ran-
observed within this Motorola dataset. Using the domize the least significant 24 bits of the MAC ad-
aforementioned mDNS techniques to guess a device dress. However, we quickly found that the MAC ad-
model we posit that one signature belongs to the dresses randomly generated by iOS devices do not
Moto G4 model while the second corresponds to a share any common prefix. In fact, they appear to be

10
completely random, including the 24 OUI bits, ex- randomization. We believe the difficulty of identify-
cept for the local bit which is always set to 1 and ing MAC address randomization to be one of the best
the multicast bit which is set to 0. To lend credence countermeasures to defeating randomization. Com-
to this new hypothesis we sampled 47,255 random pounding our incredulity, the data field associated
MAC addresses from an iOS device and ran standard with this IE never changes across devices.
statistical tests to determine if they were uniformly Using our combined set of all Apple iOS signatures,
distributed (see Appendix B). These tests confirmed we identify ∼1.3 million distinct randomized MAC
that, with the exception of the local and unicast addresses, by far the most populous (94.7%) of our
bit, iOS most likely implements true randomization randomization categories.
across the entire MAC address. This is interesting
given the fact that the IEEE licenses CID prefixes
5.3 Windows 10 and Linux Random-
for a price, meaning that Apple is freely making use
of address space that other companies have paid for. ization
Based on these findings, we are faced with identi- To conclude our categorization of randomization
fying a randomization scheme where randomness is schemes, we look to identify the probe requests from
applied across 246 bits of the byte structure. We can devices using Windows 10 and Linux MAC address
not simply assume that if the prefix does not match randomization implementations. Our first test com-
an offset of an allocated OUI that it is an iOS de- pares the signatures obtained from laboratory lap-
vice. This is due to the aforementioned clobbering tops to the signatures of our locally assigned dataset.
of other manufacturers OUI space. Our next step We find 59 matches to our laptop signatures, indi-
was to leverage the use of mDNS once again. We cating possible Windows 10 or Linux randomization.
take the union of global MAC addresses derived from Next, we parse collection files using the locally as-
probe requests that are also seen as source addresses signed MAC addresses from the probe request frames
for iOS related mDNS packets. This results in a set of these devices. Our hypothesis, if we find matching
of probe requests that we can confirm are Apple iOS locally assigned MAC addresses in authentication, as-
devices. We then extract all of the signatures for sociation, or data frames, that the randomizations
these devices. We suspected that this retrieved only scheme is likely Windows 10 or Linux. This assump-
a portion of the relevant iOS signatures. Next we col- tion is due to the fact that the randomization policies
lected signatures from all of our Apple iOS lab test use the same locally assigned address for network es-
devices using our RF enclosure. Finally, we identify tablishment and higher layer data frames. To that
signatures of all remaining locally assigned MAC ad- end, we find that 14 of the 59 devices assessed to
dresses in which we have no assigned categorization. be Windows/Linux computers use a locally assigned
We then seek to find any probe requests with global MAC address when associated to a network.
source address that have matching signatures. If the
OUI of the global addresses resolves to an Apple OUI
we consider that a valid signature. This is slightly 6 MAC Randomization Flaws
different then our mDNS test as we cannot attribute
the signature to a specific set of iOS device models. Now that we have a baseline understanding of the
We test our entire iOS signature set and ensure that randomization implementations used by modern mo-
no non-iOS global MAC addresses are ever observed bile OSs we are able to assess for vulnerabilities.
with these signatures.
In June 2016, midway through our research, iOS 10
6.1 Adoption Rate
was released. Inexplicably the addition of an Apple
vendor specific IE was added to all transmitted probe The most glaring observation, while not necessarily
requests. This made identification of iOS 10 Apple a flaw per se, is that the overwhelming majority of
devices trivial regardless of the use of MAC address Android devices are not implementing the available

11
randomization capabilities built into the Android activity unrelated to WiFi causes unexpected conse-
OS. We expect that this may be partly due to quences for user privacy.
802.11 chipset and firmware incompatibilities. How-
ever, some non-randomizing devices share the same 6.3 UUID-E Reversal
chipsets as those implementing randomization, so it is
not entirely clear why they are not utilizing random- Vanhoef et. al. introduce the UUID-E reversal at-
ization. Clearly, no effort by an attacker is required tack against Android devices [22]. Devices transmit-
to target these devices. ting probe request frames with WPS enriched data
fields, specifically, the UUID-E are vulnerable to a
reversal attack where the global MAC address can
6.2 Global Probe Request be retrieved using the WPS UUID-E value. The flaw
caused by the construction of the UUID-E, where the
We next explore the flaws of the observed MAC ad- MAC address is used as an input variable along with a
dress randomization schemes. One such flaw, the in- non-random hard-coded seed value. This implemen-
explicable transmission of the global MAC address in tation design flaw allows for the computation of pre-
tandem with the use of randomized MAC addresses. computed hash tables, whereby retrieving the global
We observe this flaw across the gamut of Android de- MAC address requires only a simple search of the
vices. The single device in which we do not observe hash tables. This revelation, both groundbreaking
this was the Cat S60 smartphone. In no instance did and disconcerting, still leaves the reader to guess as
the Cat S60 transmit a global MAC address probe to the plausibility of the attack against randomized
request, except immediately prior to an association devices. We find several issues with their approach,
attempt. Exploiting this flaw it was trivial to link specifically in respect to derandomization analysis:
the global and randomized MAC addresses using our i) randomization was not employed in 2013, when
device signatures and sequence number analysis. Be- the data used in their evaluation was gathered ii)
tween probe requests, the sequence numbers increase anonymized data eliminates accuracy checks, and iii)
predictably so an entire series of random addresses removing locally assigned MAC addresses effectively
can be linked with a global address by just following eliminates the ability to evaluate the attack against
the chain of sequence numbers. While using sequence devices performing randomization.
numbers has been discussed before in prior work [22], Accordingly, we use our corpus of DA:A1:19 and
the fact that the global MAC address is utilized while 92:68:C3 datasets to evaluate the effectiveness and
in a supposedly randomized scan state has not. This viability of the UUID-E attack. Our foremost obser-
strange behavior is a substantial flaw, and effectively vation is that only 29% of random MAC addresses
negates any privacy benefits obtained from random- from Android devices include WPS attributes. Ef-
ization. In our lab environment we observed that fectively 71% of this Android dataset is completely
in addition to periodic global MAC addressed probe immune to the UUID-E reversal attack. This is in
requests, we were able to force the transmission of addition to the fact that iOS devices are wholly im-
additional such probes for all Android devices. First, mune to the attack, as they do not use WPS. We
anytime the user simply turned on the screen, a set refer back to Table 4 the limited number of Android
of global probe requests were transmitted. An active models performing randomization and transmitting
user, in effect, renders randomization moot, eliminat- the necessary WPS UUID-E attribute.
ing the privacy countermeasure all together. Second, We then retrieve the global MAC address from the
if the phone received a call, regardless of whether the probe requests of these devices that used both ran-
user answers the call, global probe requests are trans- dom and global MAC addresses, exploiting the previ-
mitted. While it may not always be practical for an ously discussed flaw. We use this set of 1,417 ground
attacker to actively stimulate the phone in this man- truth MAC addresses to test the effectiveness of the
ner, it is unfortunate and disconcerting that device UUID-E reversal attack. First we pre-compute the

12
required hash tables. To build hash tables for the en- as we borrowed from related work. However, prior
tire IEEE space would be non-trivial, requiring sig- work tested against datasets not performing random-
nificant disk space and processing time. While an ex- ization which fails to provide accurate context. We
haustive compilation of the address space is certainly test the signature technique against our real world
possible, we use the knowledge gained from decom- corpus, revealing flaws in previous signature based
posing the randomization schemes to efficiently con- attacks.
struct our tables. We build the hash tables using only Regardless of the Android implementation, a de-
the OUIs owned by manufacturers we have observed vice transmits probe request frames which have vary-
to implement randomization. The resulting hash ta- ing signatures (based on IEs, see §3). Devices of-
ble is a manageable 2.5TBs, where using pre-sorting ten use two or more signatures while using a global
techniques, we can retrieve an UUID-E’s global MAC MAC address, so simply using the signature is in-
address in < 1 second. sufficient. Additionally, the same holds for random-
We retrieve a global MAC address for 3,187 of the ized addresses, in which we observe multiple signa-
3,188 UUID-Es. In previous work it was left incon- tures. In both cases, the second signature, has min-
clusive whether the retrieved MAC addresses were in imal 802.11 IEs. Due to the fact that nearly all de-
fact the global 802.11 MAC address or instead the vices periodically use this signature, it creates signif-
Bluetooth MAC address. The UUID-E derived from icant complexity to any signature based derandom-
the HTC One M10 device, was the example UUID-E ization attack. Finally, as Figure 2 illustrates, we
listed in the wpa supplicant.conf file. With exception observe that most Android devices use different sig-
of the HTC Nexus 9, all HTC phones in our dataset natures when randomizing compared to when using
(regardless of randomization) used this non unique a global MAC address. As such, previously described
UUID-E. signature-based tracking methods fail to correlate the
Comparing the 1,417 ground truth addresses to addresses. Using our decomposition of Android ran-
those retrieved from the UUID-E attack we achieve a domization schemes, and the derived knowledge of
100% success rate. Indicating that the retrieved ad- how distinct bins of devices behave, we properly pair
dresses are in fact the global 802.11 MAC addresses, the signatures of probe requests using global and ran-
completing the missing link from the evaluation of domized MAC addresses. Only by combining these
Vanhoef et al. [22]. signatures are we able to accurately and efficiently
retrieve the global MAC address.
We observe no such change in signatures of iOS
6.4 Device Signature
devices within a collection timeframe. While an iOS
To aide in derandomization we employ fingerprinting device may not use alternate signatures, they do not
techniques, using signatures derived from the 802.11 send globally addressed probe requests. Therefore,
IEs borrowed from previous work [22, 13]. We used at this juncture, we have not identified a method of
this technique first to aide in the identification of resolving the global MAC address.
the randomization schemes employed by Android and
iOS devices. 6.5 Association/Authentication
This technique allows us to remove all extrane-
Frames
ous probe request traffic, providing us a “cleaner”
dataset in which to employ sequence number analy- We observe that Android and iOS devices use se-
sis. We modify the Wireshark files packet-ieee80211.c quential sequence numbers across management frame
and packet-ieee80211.h, creating a new dissector fil- types. Using only passive analysis we can follow a de-
ter, device.signature. We are able to filter previous vices transition from randomized probe requests to an
collection files as well as conduct filtering on live col- authentication or association frame by following the
lection. While our contribution to the Wireshark dis- sequence numbers. This is particularly useful as all
tribution is novel, the fingerprinting technique is not, authentication and association frames from iOS and

13
 SigG = 0,1,50,3,45,221(0x50f2,8),htcap:012c,htagg:03,htmcs:000000ff
SigR = 0,1,50
Figure 2: Device Signature (Motorola Moto E2)

Android devices use the global MAC address. Using hidden networks require directed probes, so while this
the techniques described in [13] we create a set of is a vulnerability to randomization, it is fairly uncom-
signatures for the association frames of iOS devices, mon, and a decision in which a user chooses to imple-
specifically to aide in confirmation that the device ment. Similarly, previous connections to ad hoc net-
observed in the probe request is also the same device works, saved to the devices network list, cause both
type as the association frame. This method relies on Android and iOS devices to send directed probes. As
the targeted device attempting to establish a network with hidden networks, this uncommon condition re-
connection with a nearby AP. As this is fairly user- quires action from the user, however when observed,
activity dependent, we reinvestigate the plausibility the Karma attack is viable.
of the Karma attack against current randomization
schemes. Finally, we observe a more disconcerting trend: de-
vices configured for seamless cellular to WiFi data-
6.6 Karma Attack offloading, such as Hotspot 2.0, EAP-SIM and EAP-
AKA force the use of directed probes and are inher-
The current versions of iOS and Android random- ently vulnerable to Karma-based attacks [4]. The
ization policies have eliminated the vast majority of expanding growth of such handover polices reveals
cases where a directed probe is used. A directed a significant vulnerability to randomization counter-
probe is a probe request containing a specified SSID measures. Further exasperating the problem, these
that the device wishes to establish a connection (a devices are pre-configured with these settings, requir-
previously known or configured SSID), as opposed ing no user interaction. We confirmed these settings
to a broadcast probe which solicits a response from by inspecting the wpa supplicant.conf file of a Mo-
all APs in range. Today, the predominant use of torola Nexus 6 and Nexus 5X. Removing the networks
broadcast probes has directly effected the ability for from the configuration file requires deletion by a rare
a Karma-based attack to succeed. Karma-based at- user with both command line savvy and awareness of
tacks work by simulating an access point that a device this issue.
prefers to connect to. A variety of implications such
as man-in-the-middle attacks are common follow-on We test for the presence of these network configura-
consequences, however we are only interested in re- tions in our corpus by evaluating all randomized ad-
trieving the global MAC address and therefore re- dresses using WPS fields. We are able to accurately
quire only a single authentication frame to be trans- evaluate unique devices using the UUID-E value as
mitted by a targeted device. To this end Vanhoef et. the unique identifier. We filter for any instance where
al. also investigate Karma attacks, implemented via the device sends a directed probe, retrieving the SSID
a predefined top-n SSID attack, achieving a 17.4% value for each. Sorting by most common occurrence
success rate, albeit not specifically related to devices the top three most common SSIDs were BELL WIFI,
performing randomization. 5099251212, and attwifibn. The SSIDs BELL WIFI
Unlike previous work, we observe devices while in a and 5099251212 are used by the mobile carrier Bell
randomized state in order to identify specific behav- Canada for seamless WiFi offloading. Interestingly,
iors that directly counteract randomization privacy the attwifibn SSID is related to free WiFi hotspots
goals. Specifically, do we observe traits that allow provided by the Barnes and Noble bookstore. Only
for a targeted Karma attack? It is well known that ∼5% of the datasets 3,188 devices transmitted a di-

14
rected probe. However, of those that did, 17% of were State 3
caused by the preconfigured mobile provider settings. Class 1, 2 Authenticated
Next we take a cursory look at Apple iOS and and 3 frames and associated
Android devices with no amplifying WPS informa-
tion. We do not get precise statistics, however, we
Disassociation Association
observe the same trend.

State 2
6.7 Control Frame Attack Class 1 and 2 Authenticated
frames and unassociated
We now evaluate active attack methods for identify-
ing a device by its global MAC address while in a
randomized state. Our premise: can we force a de- Deauthentication Authentication
vice performing MAC address randomization to re-
spond to frames targeting the global MAC address?
State 1
This would allow for easy tracking of devices, even
Class 1 frames Authenticated
when they are randomizing, because an active at-
and unassociated
tacker could elicit a specific response from them at
any time if they are within wireless range.
Figure 3: 802.11 State Diagram
Table 6: Class 1 Frames [12]
Control Management Data
RTS Probe Request Frame w/DS bits false
cessfully elicited a response from only the Request-
CTS Probe Response to-Send (RTS) frame.
Ack Beacon
CF-End Authentication Request to Send and Clear to Send (RTS/Clear-to-
CF-End+CF-Ack Deauthentication Send (CTS)) transmissions are available in the IEEE
ATIM
802.11 specification as part of a Carrier Sense Multi-
ple Access with Collision Avoidance scheme. When
Figure 3 depicts the 802.11 state diagram illustrat- a node desires to send data an RTS may be sent to
ing the various states of association for 802.11 devices alert other nodes on the channel that a transmission
[12]. We are particularly interested in the frame types is about to begin and the period of time during which
that can be sent or received while in an unauthenti- they should not transmit on that channel so as to
cated and unassociated state (State 1). The frame avoid collisions. If there are no conflicting uses of the
types (Class 1 frames) allowed while in State 1 are channel, the target node will respond with a CTS
depicted in Table 6. to acknowledge the request and give the transmit-
In our lab environment, we use packet crafting ting node permission to solely communicate on the
tools (SCAPY, libtins) to transmit customized pack- medium.
ets for each frame type, targeting the global MAC of As for previous location and tracking attacks, some
the device. researchers have used RTS/CTS messages to perform
The source MAC address of the frame is a uniquely Time of Arrival computations [14] while others have
crafted MAC address. It is not the actual MAC ad- extended these techniques to perform Time Differ-
dress of our transmitter. This ensures that we can ac- ence of Arrival calculations from timestamps in ex-
curately track any responses to our crafted message, changed frames [9]. These older methods perform lo-
removing any possible control frames that happen to calization on Access Points from client devices. The
be sent to the actual transmitter address. Of the novelty in our method is that we are sending RTS
twelve Class 1 frame types used for the attack, we suc- frames to IEEE 802.11 client devices, not APs, to ex-

15
tract a CTS response message which we derive the dress, such as when connected to an AP at home or
true global MAC address of that device. Instead of a work. This single leakage of the true identifier will
localization attack, we are using RTS/CTS exchanges allow an attacker to send an RTS frame containing
to perform derandomization attacks. that global MAC address in the future to which that
The result of sending a RTS frame to the global host will respond with a correct CTS when it is in
MAC address of a device performing randomization range. Conceivably, an adversary with a sufficiently
was that the target device responded with a CTS large database and advanced transmission capabil-
frame. A CTS frame, having no source MAC address, ities could render randomization protections moot.
is confirmed as a response to our attack based on the Additional tests, while the target device had WiFi
fact that it was sent to the original, crafted source or Airplane-modes, enabled or disabled respectively,
MAC address. A full device listing utilized for the revealed further concerns. Namely, Android devices
control frame attack is available in Appendix D. performing location-service enabled functions wake
Once the global MAC address is known, that de- the 802.11 radio. Our RTS attack was thusly able to
vice can be easily tracked just as if randomization trigger a CTS response from the target, circumvent-
were never enabled. This might cause one to won- ing even extreme privacy countermeasures.
der why vendors would go to such lengths to include Lastly, we add improvements, using our Wireshark
MAC address randomization in a device only to allow signature filters, to eliminate the constant barrage of
that same device to divulge the protected information transmitted RTS frames. Our collection algorithm
through an administrative protocol. We assert that is pre-loaded with the target of interest’s device sig-
this phenomenon is beyond the control of individual nature, where upon observing the signature in the
vendors. The fact is that this behavior occurs across target area we launch the preconfigured MAC ad-
the board on every device we have physically tested as dress. We test this against our diverse test phones
shown in Appendix D. This leads us to believe that with 100% success.
RTS/CTS responses are not a function of the OS,
but of the underlying IEEE 802.11 chipset. Manu- 6.7.1 Bluetooth Correlation
facturers have configured their chipset hardware with
default RTS/CTS operation which may not even be We offer an additional method to derive the global
accessible to configure at the OS level. If we are cor- WiFi MAC address for later use in a RTS attack.
rect, this derandomization issue can not be fixed with Wright and Cache [23] claim that Apple iPhone de-
a simple patch or OS update. Susceptible mobile de- vices, beginning with the iPhone 3G, utilize a one-off
vices will be unmasked by this method for the life- scheme for the allocation of the Bluetooth and WiFi
time of the device. Additionally, due to the hard- MAC addresses, where the MAC address is actually
ware level nature of this phenomenon, there will be equal to the Bluetooth address, plus or minus one.
a significant delay in the market until mobile devices Using a novel algorithm to calculate the WiFi and
resistant to this attack are produced, assuming man- Bluetooth MAC address from iOS devices operating
ufacturers recognize this as a flaw and subsequently in hotspot mode, we provide evidence countering this
design a process truly capable of delivering MAC ad- claim.
dress privacy. We identified that Apple iOS devices, operating
There are multiple scenarios in which a motivated in hotspot mode, send beacon management frames
attacker could use this method to violate the privacy containing an Apple vendor specific IE. This Type
of an unsuspecting user. If the global MAC address 6 field closely resembles the source MAC address of
for a user is ever known, it can then be added to a the device. As Wireshark does not process this field
database for future tracking. This global MAC ad- correctly we built custom dissectors to create display
dress can be divulged using the techniques discussed filters for the Apple vendor tag IE and associated
in this paper, but it can also be observed any time data fields. We first test on 29 Apple iOS lab devices,
the user is legitimately using that global MAC ad- placing each in hotspot mode and collecting the bea-

16
 Table 7: Derandomization Technique Results
Randomization Bin UUID-E Reversal Global MAC Address Auth/Assoc Hotspot 2.0 - Directed Probes RTS Attack
Probe Request Frames Karma Attack
√ √ √ √ √
DA:A1:19 with WPS √ √ √ √
DA:A1:19 w/o WPS ×
√ √ √ √ √
92:68:C3 with WPS √ √ √
Motorola (No local bit) × × √ √ √
Apple iOS × ×

con frames. We retrieve the true Bluetooth and WiFi 7 Conclusions

MAC addresses from the device settings menu of the
phone. We then parse the beacon frames, outputting
the source MAC address and six byte Type 6 IE. We provide a detailed breakdown of the randomiza-
tion polices implemented, the associated device mod-
els, and the identification methods thereof. This
We observe that the Type 6 field exactly repre- granularly detailed decomposition allowed for fine-
sents the Bluetooth MAC address. The source MAC tuned improvements to prior attempts at MAC ad-
address of the Beacon frame has the local bit set. dress derandomization as well as providing novel ad-
However, the first byte of the source MAC address ditions.
is not a simple offset of the global MAC address as
seen in most P2P operations. To resolve the actual Our analysis illustrates that MAC address random-
global MAC address we find that replacing the first ization policies are neither universally implemented
byte of the source MAC address with the first byte nor effective at eliminating privacy concerns. Ta-
of the Type 6 (Bluetooth Derived) MAC address, we ble 7 depicts the diversity of presented attacks, across
obtain the correct WiFi MAC address of the device. the spectra of randomization schemes and OSs, high-
This permutation is successfully tested for all 29 test lighted by the RTS control frame attack targeting a
devices across the gamut of model and iOS versions. widespread low-level chipset vulnerability.
To be truly effective, randomization should be uni-
versally adopted. A continued lack of adoption, al-
Interestingly, six of the 29 test devices did not show
a one-off MAC address allocation. As such, we seek to lowing for simpler identification, effectively reduces
identify the accuracy of the previous claim that iOS the problem set for an attacker. The more de-
devices use this one-off scheme by evaluating across vices performing randomization within a test set, the
our entire corpus. harder it will be to diffuse each device’s associated
traffic. This is particularly true if we can continue to
bin the various schemes, further reducing the prob-
A total of 3,576 devices were identified in our lem set.
dataset containing the Type 6 field of which ∼95.4%
utilized a one-off addressing scheme. Interestingly, We propose the following best practices for MAC
∼88.2% of those devices had a Bluetooth address that address randomization. Firstly, mandate a universal
was one-higher then the WiFi MAC address. Indi- randomization policy to be used across the spectra of
cating that even when the offset is used it is not uni- 802.11 client devices. We have illustrated that when
formly implemented. We are unsure as to why ∼4.6% vendors implement unique MAC address randomiza-
of iOS devices do not use the one-off policy. Regard- tion schemes it becomes easier to identify and track
less, in all cases the OUI of the two interfaces are those devices. A universal policy must include at
the same. Using the mDNS model correlation anal- minimum, rules for randomized MAC address byte
ysis we observed no indication that offset scheme is structure, 802.11 IE usage, and sequence number be-
correlated with the device model. havior.

17
 To reiterate, these best practices can only be truly [4] Wifigate - how mobile carriers expose
effective when enforced across the spectrum of de- us to wi-fi attacks, Apr 2014. URL
vices. Granular examples of such policy rules: https://www.skycure.com/blog/wifigate-how-mobile-carri

• Randomize across the entire address, providing [5] Danger close: Fancy bear tracking of
246 bits of randomization. ukrainian field artillery units, Jan 2017. URL
https://www.crowdstrike.com/blog/danger-close-fancy-be
• Use a random address for every probe request
frame. [6] D. E. 3rd and J. Abley. IANA Considera-
tions and IETF Protocol and Documentation
• Remove sequence numbers from probe requests.
Usage for IEEE 802 Parameters. RFC 7042
• If sequence numbers are used, reset sequence (Best Current Practice), Oct. 2013. URL
number when transmitting authentication and http://www.ietf.org/rfc/rfc7042.txt.
association frames.
[7] M. V. Barbera, A. Epasto, A. Mei, S. Kosta,
• Never send probe requests using a global MAC V. C. Perta, and J. Stefa. CRAW-
address. DAD dataset sapienza/probe-requests.
http://crawdad.org/sapienza/probe-requests/20130910,
• Enforce a policy requiring a minimal and stan- Sept. 2013.
dard set of vendor IEs. Move any lost function-
ality to the authentication/association process, [8] J. Bard. Unpacking the dirtbox: Confronting
or upon network establishment utilize discovery cell phone location tracking with the fourth
protocols. amendment. BCL Rev., 57:731, 2016.

• Specifically, the use of WPS attributes should [9] Z. Cui and A. Agrawala. Wifi localization based
be removed except when performing P2P opera- on ieee 802.11 rts/cts mechanism. In Proceed-
tions. Prohibit unique vendor tags such as those ings of the 12th EAI International Conference
introduced by Apple iOS 10. on Mobile and Ubiquitous Systems, pages 199–
208. ICST, 2015.
• Eliminate the use of directed probe requests for
cellular offloading. [10] M. Cunche. I know your mac address: tar-
geted tracking of individual using wi-fi. Journal
• Mandate that chipset firmware remove behavior
of Computer Virology and Hacking Techniques,
where RTS frames received while in State 1 elicit
2014.
a CTS response.
[11] . Dara Kerr July 29. Russian police spy on peo-
References ple’s mobile data to catch thieves, Jul 2013. URL
https://www.cnet.com/news/russian-police-spy-on-people
[1] Linux wpa supplicant (ieee 802.1x,
[12] M. Gast. 802.11 wireless networks : the
wpa, wpa2, rsn, ieee 802.11i). URL
definitive guide. O’Reilly, Beijing, Farn-
https://w1.fi/wpa_supplicant/.
ham, 2005. ISBN 0-596-10052-3. URL
[2] wpa supplicant change log. URL http://opac.inria.fr/record=b1128195.
https://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog.
[13] D. Gentry and A. Pennarun. Passive taxon-
[3] China deputizes smart phones to spy on bei- omy of wifi clients using MLME frame con-
jing residents’ real-time location, Oct 2011. URL tents. CoRR, abs/1608.01725, 2016. URL
https://www.eff.org/deeplinks/2011/03/china-deputizes-smart-phones-spy-beijing-residents.
http://arxiv.org/abs/1608.01725.

18
[14] C. Hoene and J. Willmann. Four-way toa and
software-based trilateration of ieee 802.11 de-
vices. In 2008 IEEE 19th International Sym-
posium on Personal, Indoor and Mobile Radio
Communications, pages 1–6, Sept 2008.
[15] IEEE. OUI Public Listing.
http://standards.ieee.org/develop/regauth/oui/oui.txt.
[16] J. Martin, E. Rye, and R. Beverly. Decompo-
sition of mac address structure for granular de-
vice inference. In Proceedings of the 32nd Annual
Conference on Computer Security Applications,
pages 78–88. ACM, 2016.
[17] C. Matte, M. Cunche, F. Rousseau, and M. Van-
hoef. Defeating mac address randomization
through timing attacks. In Proceedings of the 9th
ACM Conference on Security &#38; Privacy in
Wireless and Mobile Networks, WiSec ’16, pages
15–20. ACM, 2016.
[18] C. Mims. If you have a smart phone, anyone
can now track your every move, Oct 2012. URL
https://www.technologyreview.com/s/427687/if-you-have-a-smart-phone-anyone-can-now-track-your-every
[19] T. Mitchell. 2. smartphone ownership rates
skyrocket in many emerging economies, but
digital divide remains, Feb 2016. URL
http://www.pewglobal.org/2016/02/22/smartphone-ownership-rates-skyrocket-in-many-emerging-economies
[20] B. L. Owsley. Spies in the skies: Dirtboxes and
airplane electronic surveillance. Mich. L. Rev.
First Impressions, 113:75–75, 2015.
[21] M. Sarwar and T. R. Soomro. Impact of smart-
phone’s on society. European journal of scientific
research, 98(2):216–226, 2013.
[22] M. Vanhoef, C. Matte, M. Cunche, L. Cardoso,
and F. Piessens. Why MAC Address Random-
ization is not Enough: An Analysis of Wi-Fi
Network Discovery Mechanisms. In ACM Asi-
aCCS, 2016.
[23] J. Wright and J. Cache. Hacking Exposed
Wireless: Wireless Security Secrets & Solu-
tions. McGraw-Hill Education Group, 3rd edi-
tion, 2015. ISBN 0071827633, 9780071827638.

19
A OS Randomization Configu- # MAC address policy for pre-association
operations (scanning, ANQP)
ration # 0 = use permanent MAC address
# 1 = use random MAC address
A.1 Android # 2 = like 1, but maintain OUI (with local
admin bit set)
In October 2014 the wpa suppplicant.conf file, used #preassoc_mac_addr=0
by Android, Linux, Windows, and OS X client sta-
tions [1] for configuration of 802.11 networking, was
updated to add experimental support for MAC ad-
Android introduced MAC address randomization
dress randomization in network scans. Full imple-
for probe requests with Android 6.0 (Marshmal-
mentation support was added in March 2015 [2]. List-
low) and in an incremental patch to 5.0 (Lollipop).
ing 1 depicts the added support for MAC address
With the release of Marshmallow, the WifiStateMa-
randomization. It is worth noting that the configura-
chine.java and WifiNative.java files were modified
tion file provides two policies for using a non-globally
to implement MAC address randomization for active
unique address while in an associated state. If the
scanning. When the SupplicantStartedState function
variable mac addr is set to 1 the device will use a
is called upon enabling WiFi, a call to the newly
randomized MAC address for each unique network
added setRandomMacOui function sets the first three
the device connects to. If mac addr is set to 2 the
bytes of the MAC address to the default Google CID
device will randomize the lower three bytes of the
(DA:A1:19). If the config wifi random mac oui
MAC address prefixed with the original OUI where
variable has been redefined in the config.xml file, that
the local bit has been set to 1.
prefix will be used in place of the default Google CID.
The wpa supplicant.conf file also addresses the ran- The XML configuration file allows an Android smart-
domization policies available for disassociated devices phone manufacturer to override the default Google
conducting active scanning. In this case, the variable CID with a prefix to be used as the substitute for
preassoc mac addr can be set similarly to the pre- the OUI. Finally, the prefix is passed to another
viously described address policies. function, setScanningMacOui located in the WifiNa-
tive.java file which calls a corresponding function at
Listing 1: wpa supplicant.conf a lower, native level. If the device chipset is compat-
# MAC address policy default ible to support randomization then the prefix will be
# 0 = use permanent MAC address used during active scans.
# 1 = use random MAC address for each ESS
connection
# 2 = like 1, but maintain OUI (with local We extracted the wpa supplicant.conf, WifiS-
admin bit set) tateMachine.java, and WifiNative.java files from
# Android devices that do and do not perform
# By default, permanent MAC address is used MAC address randomization. We found that the
unless policy is changed by wpa supplicant file was never utilized to implement
# the per-network mac_addr parameter. Global randomization, as attempts to modify the random-
mac_addr=1 can be used to
ization settings of the file had no affect on any device.
# change this default behavior.
The Java files also had the supporting functions for
#mac_addr=0
randomization included, regardless if the device used
# Lifetime of random MAC address in seconds them. Interestingly, with logging enabled, the devices
(default: 60) that did not conduct randomization sent output to
#rand_addr_lifetime=60 the logs indicating that the random MAC had been
set, where devices seen randomizing did not.

20
A.2 iOS Additionally, we decomposed the bytes of subse-
quent MAC addresses into a bit stream and ran the
In late 2014, Apple introduced MAC address random-
tests specified in the FIPS 140-1 standard published
ization with the release of iOS 8.0. Apple iOS ran-
by NIST to test random number generators. We ob-
domization settings are not device-model customiz-
tained the following results:
able, unlike Android, which allows each model to
modify settings such as the CID. As of the current
iOS 10.x version, Apple devices only use the locally
assigned MAC address while in a disassociated state.
Since iOS is not open source, we cannot determine • Monobit test: 9939
the exact method or configuration options that Ap-
ple uses on their devices to support randomization.
Instead, we are left to determine device behavior from
a “black box” perspective by observing communica- • Poker test: 13.56
tion from different devices and iOS versions in §5.

B iOS Randomization Tests

• Runs test length 1: 2515
To determine if iOS is using random prefixes, or if
there is just a pattern that we have not been able
to see, we used several standard statistical tests to
compare our observations with an ideal, random dis- • Runs test length 2: 1342
tribution. First, we calculated the number of colli-
sions we observed, where the same prefix appeared
more than once. If they are truly random we would
expect to see a moderate number of collisions, which
• Runs test length 3: 581
is easy to quantify. We would also expect to see a
certain, far fewer, number of triple collisions where
one prefix appears three times. These numbers can
be calculated as follows:
• Runs test length 4: 281
n


2
E[# of collisions] =
m

n
3
E[# of triple collisions] = • Runs test length 5: 166
m2
where n = # of addresses observed
m = # of possible prefixes (222 )

• Longest run test: 12

Comparing our empirical results with the statisti-
cal expectations, we get:

For :
All tests passed within the allowable ranges. These
Collisions : expected = 266, observed = 262
tests indicate to us that the MAC addresses are dis-
Triple collisions : expected = 1, observed = 3 tributed uniformly.

21
C Google CID Device Break-
down

Table 8: DA:A1:19 with WPS Model Breakdown

Manufacturer Model Distinct Devices
Huawei Nexus 6P 1660
BlackBerry STV100-3 133
HTC Nexus 9 107
BlackBerry STV100-1 71
Sony E5823 61
Sony E6653 59
Sony SO-01H 29
Sony E6853 23
Blackberry STV100-4 20
Huawei NXT-L29 17
Sony SO-02H 17
Google Pixel C 12
Sony SO-03H 11
Sony SOV32 11
Huawei NXT-AL10 11
BlackBerry STV100-2 10
Sony SO-03G 9
Sony SOV31 8
Sony E6883 8
Sony E5803 8
Sony E6553 7
Huawei NXT-L09 6
Sony E6683 6
Huawei EVA-L09 5
Sony F5121 5
Sony E6533 4
Huawei EVA-AL00 3
Huawei KNT-AL20 2
Huawei EVA-AL10 2
Sony SGP712 2
Sony SGP771 2
Sony E6603 1
Sony E6633 1
Sony SO-05G 1
LGE LG-H811 1
Sony E6833 1
Huawei VIE-AL10 1
Huawei EVA-DL00 1
Sony 402SO 1
Google Pixel XL 1
Sony 501SO 1
Huawei EVA-L19 1
Sony F5321 1
HTC HTC 2PS650 1

22
D RTS Control Frame Attack -
Device Diversity

Table 9: RTS Control Frame Attack - Device

Diversity
Model OS Version Success
√
iPhone 6s 10.1.1 √
iPhone 6s 9.3.5 √
iPhone 6s Plus 9.3.5 √
iPhone 5s 10.1 √
iPhone 5s 9.3.5 √
iPhone 5 9.3.5 √
iPad Air 9.3.5 √
Google Pixel XL 7.1 √
LGE Nexus 5X 7.0 √
LGE G5 6.0.1 √
LGE G4 6.0.1 √
Motorola Nexus 6 6.0.1 √
Moto E2 5.1.1 √
Moto Z Play 6.0.1 √
OnePlus 3 6.0.1 √
Xiaomi Mi Note Pro 5.1.1

23