ArticlePDF Available

A Study of MAC Address Randomization in Mobile Devices and When it Fails

Authors:

Abstract and Figures

Media Access Control (MAC) address randomization is a privacy technique whereby mobile devices rotate through random hardware addresses in order to prevent observers from singling out their traffic or physical location from other nearby devices. Adoption of this technology, however, has been sporadic and varied across device manufacturers. In this paper, we present the first wide-scale study of MAC address randomization in the wild, including a detailed breakdown of different randomization techniques by operating system, manufacturer, and model of device. We then identify multiple flaws in these implementations which can be exploited to defeat randomization as performed by existing devices. First, we show that devices commonly make improper use of randomization by sending wireless frames with the true, global address when they should be using a randomized address. We move on to extend the passive identification techniques of Vanhoef et al. to effectively defeat randomization in ~96% of Android phones. Finally, we identify a previously unknown flaw in the way wireless chipsets handle low-level control frames which applies to 100% of devices we tested. This flaw permits an active attack that can be used under certain circumstances to track any existing wireless device.
Content may be subject to copyright.
arXiv:1703.02874v1 [cs.CR] 8 Mar 2017
A Study of MAC Address Randomization in Mobile Devices and
When it Fails
Jeremy Martin
, Travis Mayberry
, Collin Donahue, Lucas Foppe, Lamont Brown,
Chadwick Riggins, Erik C. Rye
, and Dane Brown §
US Naval Academy
Abstract
Media Access Control (MAC) address randomization
is a privacy technique whereby mobile devices rotate
through random hardware addresses in order to pre-
vent observers from singling out their traffic or phys-
ical location from other nearby devices. Adoption
of this technology, however, has been sporadic and
varied across device manufacturers. In this paper,
we present the first wide-scale study of MAC address
randomization in the wild, including a detailed break-
down of different randomization techniques by oper-
ating system, manufacturer, and model of device.
We then identify multiple flaws in these implementa-
tions which can be exploited to defeat randomization
as performed by existing devices. First, we show that
devices commonly make improper use of randomiza-
tion by sending wireless frames with the true, global
address when they should be using a randomized ad-
dress. We move on to extend the passive identifica-
tion techniques of Vanhoef et al. to effectively defeat
randomization in 96% of Android phones. Finally,
we show a method that can be used to track 100% of
devices using randomization, regardless of manufac-
turer, by exploiting a previously unknown flaw in the
way existing wireless chipsets handle low-level control
frames.
jmartin@usna.edu
mayberrry@usna.edu
rye@usna.edu
§dabrown@usna.edu
1 Introduction
Smartphones are one of the most impactful technolo-
gies of this century. The ability to access the Internet
anytime and anywhere has fundamentally changed
both work and personal life across the globe [21]. It is
gradually becoming clear, however, that in exchange
for this level of access to the Internet people may be
giving up a substantial amount of privacy. In par-
ticular, it has recently been made public that state
sponsored intelligence agencies, in countries such as
Russia and China [5, 11, 3], as well as private sec-
tor companies [18], are actively attempting to track
cellphone users.
Smartphones conventionally have two major modes
of communication, both of which can potentially be
used to track users. The first and most obvious is the
cellular radio itself [8, 20]. However, an often over-
looked second avenue for tracking cellphones (and
their corresponding users) is the 802.11 (WiFi) ra-
dio that most smart phones also use.
Every 802.11 radio on a mobile device possesses
a 48-bit link-layer MAC address that is a globally
unique identifier for that specific WiFi device. The
MAC address is a crucial part of WiFi communica-
tion, being included in every link-layer frame that is
sent to or from the device. This unfortunately poses
a glaring privacy problem because any third party
eavesdropping on nearby WiFi traffic can uniquely
identify nearby cellphones, and their traffic, through
their MAC addresses [10].
There is one particular type of WiFi packet, called
aprobe request frame, that is an especially vulner-
1
able part of WiFi traffic with respect to surveil-
lance. Since probe requests continuously broadcast
at a semi-constant rate they make tracking trivial.
Mobile devices are effectively playing an endless game
of digital “Marco Polo,” but in addition to “Marco”
they are also broadcasting out their IDs (in the form
of a MAC address) to anyone that cares to listen.
To address this problem, some modern mobile de-
vices make use of temporary, randomized MAC ad-
dresses that are distinct from their true global ad-
dress. When probe requests are sent out, they use a
randomized pseudonym MAC address that is changed
periodically. A listener should be unable to continu-
ously track the phone because the MAC changes in a
way that hopefully cannot be linked to the previous
address.
In this work we evaluate the effectiveness of
various deployed MAC address randomization
schemes. We first investigate how exactly differ-
ent mobile Operating Systems (OSs) actually imple-
ment randomization techniques, specifically looking
at how the addresses are generated and under what
conditions the devices actually use the randomized
address instead of the global one. Using real-world
datasets we provide the first evaluation of adoption
rates for randomization across a diverse manufacturer
and model corpus.
After establishing the current state of randomiza-
tion for widely used phone models and OS versions,
we move on to show several weaknesses in these
schemes that allow us to track phones within and
across multiple collections of WiFi traffic. Our work
builds on the fingerprinting techniques of Matte et al.
[17] in addition to new approaches for deanonymizing
phones based on weaknesses we discovered while ana-
lyzing wireless traffic from many randomizing phones.
This paper makes the following novel contribu-
tions:
We decompose a large 802.11 corpus, providing
the first granular breakdown of real-world MAC
address randomization. Specifically, we develop
novel techniques to identify and isolate random-
ization and randomization schemes from large
collections of wireless traffic.
We present the first manufacturer and device
breakdown for MAC randomization, describing
the particular technique each uses. Our results
indicate that adoption rates are surprising low,
specifically for Android devices.
We review previous techniques for determining
global MAC addresses and find them to be in-
sufficient. We provide additional context and im-
provements to existing passive and active tech-
niques, substantially increasing their effective-
ness.
We identify significant flaws in the majority of
randomization implementations on Android de-
vices. These flaws allow for trivial retrieval of
the global MAC address.
Discovery and implementation of a control frame
attack which exposes the global MAC address
(and thus allows tracking/surveillance) for all
known devices, regardless of OS, manufacturer,
device type, or randomization scheme. Further-
more, Android devices can be susceptible to this
attack even when the user disables WiFi and/or
enables Airplane Mode.
2 Background
2.1 MAC Addresses
Every network interface on an 802.11 capable device
has a 48-bit MAC address layer-2 hardware identi-
fier. MAC addresses are designed to be persistent and
globally unique. In order to guarantee the unique-
ness of MAC addresses across devices the Institute of
Electrical and Electronics Engineers (IEEE) assigns
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-
tifier (OUI), may be purchased and registered with
the IEEE [15], which gives the organization control of
and responsibility for all addresses with a particular
three-byte prefix. The manufacturer is then free to
assign the remaining low-order three bytes (224 dis-
tinct addresses) any value they wish when initializing
2
devices, subject to the condition that they do not use
the same MAC address twice.
An implication of the IEEE registration system is
that it is trivial to look up the manufacturer of a de-
vice given its MAC address. Using, again, the exam-
ple of a wireless eavesdropper, this means that anyone
listening to 802.11 traffic can determine the manu-
facturer of nearby devices. To combat this, the IEEE
also provides the ability to purchase a “private” OUI
which does not include the company’s name in the
register. However, this additional privacy feature is
not currently used by any major manufacturers that
we are aware of.
01 :23 :45 :67 :89 :AB
OUI NIC
00000001 Unicast/Multicast Bit
Universal/Local Bit
Figure 1: 48-bit MAC Address Structure
In addition to the public, globally unique, and
manufacturer assigned MAC address, modern devices
frequently use locally assigned addresses [6] which are
distinguished by a Universal/Local bit in the most
significant byte. Locally assigned addresses are not
guaranteed to be unique, and generally are not used
in a persistent manner. Locally assigned addresses
are used in a variety of contexts, including multi-
Service Set IDentifier (SSID) configured access points
(APs), mobile device-tethered hotspots, and peer-to-
peer (P2P) services. A visual depiction of the MAC
address byte structure is illustrated in Figure 1.
Most importantly for this paper, locally assigned
addresses may also be used to create randomized
MAC addresses as an additional measure of privacy.
Similar to an OUI, a three-byte Company Identi-
fier (CID) prefix can be purchased from the IEEE,
with the agreement that assignment from this ad-
dress space will not be used for globally unique ap-
plications. As such, a CID always has the local
bit set, and is predisposed for use within MAC ad-
dress randomization schemas. One such example, the
Google owned DA:A1:19 CID, is prominent within
our dataset.
With the advent of randomized, locally assigned
MAC addresses that change over time, tracking a
wireless device is no longer trivial. For this reason,
we frequently observe 802.11 probe requests using lo-
cally assigned addresses when the device is in a disas-
sociated state (not associated with an AP). When a
mobile device attempts to connect to an AP, however,
it reverts to using its globally unique MAC address.
As such, tracking smartphones becomes trivial while
they are operating in an associated state.
Since mobile devices are usually only associated
while the user is relatively stationary (otherwise they
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
state, which usually occurs when the user is mov-
ing from one location to another. Additionally, there
are several good reasons to use a global address in
an associated state, such as to support MAC address
filtering on the network. Therefore we concentrate,
in this paper, on evaluating randomization methods
and tracking of unassociated devices.
2.2 Mobile OS MAC Randomization
A particularly sensitive privacy issue arises from
the manner in which wireless devices identify access
points within close proximity. Traditionally, devices
perform active scanning where they broadcast probe
request frames asking nearby APs to identify them-
selves and respond with 802.11 parameter informa-
tion required for connection setup. These probe re-
quest frames require a source MAC address, but if an
802.11 device uses its globally unique MAC address
then it is effectively broadcasting its identity at all
times to any wireless receiver that is nearby. Wire-
less device users can then easily be tracked across
temporal and spatial boundaries as their devices are
transmitting with their unique identity.
To combat this privacy concern, both Android and
Apple iOS operating systems allow for devices in a
disassociated state to use random, locally assigned
3
MAC addresses when performing active scans. Since
the MAC address is now random, users gain a mea-
sure of anonymity up until they associate with an
AP.
The particular software hooks used for randomiza-
tion vary between operating systems. See Appendix
A for a discussion of the OS mechanisms and config-
uration files that support MAC randomization.
3 Related Work
Vanhoef et al. [22] present several techniques for
tracking devices regardless of privacy countermea-
sures such as MAC address randomization. These
attacks rely on devices’ support for Wi-Fi Protected
Setup (WPS), a protocol that allows unauthenti-
cated devices to negotiate a secure connection with
access points. Unfortunately, in order to facilitate
this process, extra WPS fields are added in a device’s
probe requests that contain useful information for de-
vice tracking. Among these is the manufacturer and
model of the device, but also a unique identifier called
the Universally Unique IDentifier-Enrollee (UUID-E)
which is used to establish WPS connections. The flaw
that Vanhoef et al. [22] discovered is that the UUID-E
is derived from a device’s global MAC address, and by
using pre-computed hash tables an attacker can sim-
ply lookup the UUID-E from the table and retrieve
the global MAC address [22, 16]. We refer to this
technique as UUID-E reversal. Since the UUID-E
does not change, the implication is that even if the
MAC address is randomized, an attacker can still re-
cover the original, global address by performing this
reversal technique on the UUID-E.
While the revelation of the flaw was significant,
several holes in the analysis were observed due to the
dataset on which the work was evaluated. The at-
tack was applied against an anonymized dataset from
2013 [7]. This dataset did not include randomized
MAC address implementations as they did not exist
in 2013. Additionally, due to the fact that the data
was anonymized, and ground truth was not available,
a validation of the reversal technique was not pro-
vided. The authors state that the address could not
be confirmed to be the WiFi MAC address, rather
it may represent the Bluetooth MAC address of the
device. Because of this, the reader is left with little
understanding on the scope of practical use of these
attacks. Namely, is the attack truly viable against
devices performing randomization?
The first contribution of this paper is a better eval-
uation of the attacks presented by Matte et al. [17].
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
improvement on their technique can achieve a higher
success rate, up 99.9% effectiveness against vulner-
able devices. We are also able to confirm that the
retrieved MAC address is in fact the 802.11 WiFi
identifier and not the Bluetooth address using addi-
tional techniques. More importantly, we provide a
real-world assessment for the scope of the attack, re-
vealing that only a small portion of Android devices
are actually vulnerable.
Vanhoef et al. [22] and Matte et al. [17] present
an additional technique: fingerprinting of the probe
request 802.11 Information Elements (IEs). IEs are
optional, variable length fields which appear in WiFi
management frames and are generally used to im-
plement extensions and special features on top of
the standard WiFi protocol. Importantly, there are
enough of these extensions and manufacturer spe-
cific functions that the various combinations which
are supported on a particular device may be unique
to that device, causing the IEs to form a fingerprint
which can be used to identify traffic coming from that
device.
However, we find one significant flaw in the eval-
uation of these fingerprints: locally assigned MAC
addresses were ignored by the authors. Nearly all
randomization schemes utilize locally assigned MAC
addresses to perform randomization. As such, pre-
vious research failed to identify problems observed
when tracking randomized MAC addresses. A sim-
ple example of this is the signature of a device’s probe
request, which we observed changing during random-
ization and even when not randomizing. Only by ob-
serving these behaviors can we truly implement effec-
tive derandomization techniques and present honest
reflections on the limitations of the attack methods.
4
Also presented in [22] is a revival of the Karma at-
tack using a top-n popular SSID honeypot approach.
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
with an identical name (SSID) to one that the device
is set up to automatically connect to. In effect, this
forces the devices into an authenticated state where
it reveals its global MAC address and bypass ran-
domization. We validate this attack by finding that
the increased prevalence of seamless WiFi-offloading
from cellular networks means that many devices in
the wild are vulnerable.
4 Methodology
Our initial goal is to identify which mobile devices are
using randomization, in order to narrow down further
investigation into their exact methods for doing so.
Since this is not a capability that is advertised on a
spec sheet, we resort to broad capture and analysis
of WiFi traffic in order to determine which device
models are doing randomization.
Over the course of approximately two years, we
captured unencrypted 802.11 device traffic using in-
expensive commodity hardware and open-source soft-
ware. We primarily use an LG Nexus 5 Android
phone running Kismet PcapCapture paired with an
AWUS036H 802.11b/g Alfa card. We hop between
the 2.4GHz channels 1, 6, and 11 to maximize cov-
erage. We additionally employ several Raspberry
Pi devices running Kismet with individual wireless
cards each dedicated to channels 1, 6, and 11. Our
corpus spans January 2015 to December 2016 and
encompasses approximately 9,000 individual packet
captures. The collection contains over 600 gigabytes
(GBs) of 802.11 traffic, consisting of over 2.8 million
unique devices.
It is important to note that, since devices only ran-
domize when they are unassociated, the only traffic
we are interested in is 802.11 management frames
and unencrypted multicast Domain Name System
(mDNS) packets. Therefore we did not capture
actual intentional user traffic from the device, i.e.
web browsing, email, etc., but only automatic, non-
personal traffic sent by the device.
4.1 Ethical Considerations
Our collection methodology is entirely passive. At no
time did we attempt to decrypt any data, or perform
active actions to stimulate or alter normal network
behavior while outside of our lab environment. Our
intent is to show the ease with which one can build
this capability with low-cost, off-the-shelf equipment.
However, given the nature of our data collection, we
consulted with our Institutional Review Board (IRB).
The primary concerns of the IRB centered on: i)
the information collected; and ii) whether the exper-
iment collects data “about whom” or “about what.”
Because we limit our analysis to 802.11 manage-
ment frames and unencrypted mDNS packets, we do
not observe Personally Identifiable Information (PII).
Although we observe IP addresses, our experiment
does not use these layer-3 addresses. Even with an
IP address, we have no reasonable way to map the
address to an individual. Further, humans are in-
cidental to our experimentation as our interest is in
the randomization of wireless device layer-2 MAC ad-
dresses, or “what.” Again, we have no way to map
MAC addresses to individuals.
Finally, in consideration of beneficence and re-
spect for persons, our work presents no expectation
of harm, while the concomitant opportunity for net-
work measurement and security provides a societal
benefit. Our experiment was therefore determined to
not be human subject research.
4.2 Identifying Randomization
We know devices implement MAC randomization in
different ways. In order to quantify the vulnerabili-
ties of employed randomization policies, we first at-
tempt to categorize devices into different bins, with
identical behavior, so that we can investigate char-
acteristics of these individual techniques and seek to
identify flaws in their implementation. For instance,
as we will see, all iOS devices fall into the same bin,
in that they handle randomization in a similar way.
5
Table 1: Corpus Statistics
Category # MACs
Corpus 2,604,901
Globally Unique 1,204,148
Locally Assigned 1,400,753
Table 2: Locally Assigned Bins
Category # MACs
Locally Assigned 1,400,753
Service 3,147
Randomized 1,388,566
Unknown 9,040
Table 3: Randomization Bins
Category # MACs
Randomized 1,388,566
Android: DA:A1:19 (WPS) 8,761
Android: DA:A1:19 43,924
Android: 92:68:C3 (WPS) 8,961
iOS 1,326,951
Windows 10 / Linux 59
Android devices, on the other hand, differ signifi-
cantly from iOS, and also vary greatly from manu-
facturer to manufacturer.
Our first step is to identify whether a device is
performing randomization. This starts with extract-
ing all source MAC addresses derived from probe re-
quest frames in our corpus. If the local bit of the
MAC address is set, we store the address as a lo-
cally assigned MAC address in our database. Since
randomized addresses cannot be unique, we assume
at this point that any device using randomization
will set the local bit in its MAC address and there-
fore all randomization candidates will be in this data
set. For each address we then parse the advertised
WPS manufacturer,model name,model number,
and uuid evalues. Additionally, we build signatures
derived from a mapping of the advertised 802.11 IE
vendor fields using techniques from related work in
device-model classification [22, 13]. Each MAC ad-
dress, associated WPS values (when applicable), and
the device IE signature are stored in our database.
Our device signatures are created using custom
built Wireshark dissectors to parse the 802.11 ven-
dor IE fields and values. Our modifications to stan-
dard wireshark files (packet-ieee80211.c and packet-
ieee80211.h) allow us to efficiently create the indi-
vidual device signatures as we process the packet
captures, eliminating any need for post-processing
scripts. Furthermore, this allows us to use a signa-
ture as a display filter while capturing. We will later
use the device signatures for both passive and active
derandomization techniques.
Our corpus contained a total of 66 million in-
dividual probe requests. We have a dataset of 2.6
million unique source MAC addresses after removing
duplicates. In Table 1 we observe that 1.4 million
(53%) of the 2.6 million distinct MAC addresses
had locally assigned MAC addresses. Recall that lo-
cally assigned addresses are not only used for ran-
domization. Therefore, after partitioning the corpus,
we separate the locally assigned MAC addresses that
are used for services such as P2P and WiFi-Extenders
from those used as randomized addresses for privacy
purposes. Doing so required us to manually inspect
the frame attributes and look for identifying charac-
teristics.
One prevalent P2P service that makes use of lo-
cally assigned addresses is WiFi-Direct. Fortunately,
WiFi-Direct operations contain a WiFi-Direct IE
(0x506f9a,10). Specifically, the following attributes
are are observed with all WiFi-Direct traffic: i) WiFi-
Direct IE is present, ii) the observed OUI is sim-
ply the original OUI with the local bit set, and iii)
the SSID value, if observed, is set with a prefix of
DIRECT-. Furthermore, manual inspection of the
packet capture reveals that these devices use a single
locally assigned MAC address for all observed probe
request frames. As these devices are not conducting
randomization we remove them from our dataset.
Similarly, Nintendo devices operating in a P2P
mode are observed utilizing a locally assigned ad-
dress. Associated frames use a modified Nintendo
OUI, one with the local bit set. Additionally, all
Nintendo P2P probe requests contain a unique Ven-
dor Specific IE, 0x00:1F:32, allowing for an efficient
identification and removal from our dataset.
Lastly, the remainder of our service-based locally
assigned addresses were attributed to WiFi exten-
ders forwarding client probe requests. These were
also identified as modifying their original OUI by set-
ting the local bit. Commonly observed OUIs, such as
Cisco, D-Link, and Belkin indicated a likely associ-
ation to infrastructure devices. We confirmed our
assumptions through manual packet analysis, which
6
showed: i) the MAC address never changes, ii) each
unique device probes for only one SSID, and iii) de-
vices with WPS attributes clearly indicate wireless
extender models.
Table 2 illustrates that 99.12% of all locally as-
signed mac addresses are randomized addresses, rep-
resenting 53% of our total corpus. While this may
seem like it indicates a large rate of adoption for MAC
randomization, these addresses do not directly corre-
late to the number of unique devices in our dataset.
While globally unique addresses have a 1-to-1 rela-
tionship with individual devices, a device perform-
ing randomization has a 1-to-many relationship. It
is plausible that a device conducting randomization
may have tens of thousands of addresses over a collec-
tion period. Therefore we posit that much less than
50% of devices conduct randomization.
Our goal, to identify and evaluate potential flaws
in currently fielded randomization policies, requires
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
in practice and why? What operating systems are
prevalent? Which randomization policies are actu-
ally used?
As discussed above, we must first identify distinct
bins of randomization within the data. Table 3 high-
lights the results of this analysis. We completed this
analysis by evaluating the following; i) the MAC
address prefix (OUI, CID, random), ii) WPS at-
tributes, iii) 802.11 IE derived device signatures, and
iv) mDNS fingerprinting techniques [16]. Lastly, we
confirm our analysis using devices procured by our
team and evaluated in a controlled Radio Frequency
(RF) environment. We provide detailed analysis of
our methods, results, and answers to our stated ques-
tions in §5.
5 Analysis
5.1 Android Randomization
After removing all of the service-based locally as-
signed MAC addresses described in §4.2, we aim to
separate the remaining 1.388 million addresses into
distinct bins. First we perform a simple query of
our database where we identify the most common
three byte prefixes. We expect that the prefixes with
the highest occurrences will be the CID owned by
the representative devices. Our findings were sur-
prising: first, the Google owned CID DA:A1:19, was
by far the most commonly observed prefix (52,595),
while the second most common prefix 92:68:C3, ob-
served 8,691 times was not an IEEE allocated CID,
but rather a Motorola owned OUI with the local bit
set.
The remaining 177k observed three-byte prefixes,
each with total occurrences ranging from a low of
two to a high of seven, show no indication of being
a defined prefix or CID. While we expected to see
the Google owned CID, we also expected to see addi-
tional CIDs configured by manufacturers to override
the default Google CID.
5.1.1 92:68:C3
Investigating the 92:68:C3 prefix in more detail, we
see that devices using this prefix always transmit
granular WPS details. This is helpful as it lets us
easily determine the device model (see §3). First,
the Motorola Nexus 6 is the only device using this
prefix. Using the WPS derived UUID-E as a unique
identifier, we see that there were 849 individual Mo-
torola Nexus 6 devices in our dataset. Second, in
order to retrieve the global MAC address we use
the UUID-E reversal technique previously mentioned
[22, 16]. We find that the actual prefix of the device’s
MAC address is not the expected 90:68:C3 OUI.
Rather, we observe a set of different Motorola owned
OUIs. In combination with with the config.xml file
(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
owned CID.
Searching open source Android code repositories
revealed no additional config.xml defined prefixes
other than the Google and Motorola ones. This
matches what we observe in our real-world dataset.
7
5.1.2 DA:A1:19
The analysis of the Google CID DA:A1:19 proved
more complex, having serious implications to prior
work in derandomization attacks. Unlike the Mo-
torola prefix, not all devices using the Google CID
transmit WPS attributes. This had multiple ef-
fects on our analysis. First, we were unable to eas-
ily identify the manufacturer and model information
when no WPS information was present. Lacking a
UUID-E, we were unable to precisely identify total
device counts. More importantly, we were unable to
retrieve the global MAC address via the reversal tech-
nique. Surprisingly, only 19% of observed MAC
addresses with the Google CID contain UUID-E val-
ues. Since the reversal technique of Matte et al. [17]
require a UUID-E, this emphasizes the fact that pre-
vious evaluations are insufficient. A large majority
of Android phones are not vulnerable to UUID-E re-
versal, despite how valuable the technique initially
seems.
We evaluated the 8,761 addresses that have WPS
values before attempting to breakdown the 43,924
DA:A1:19 MAC addresses with no WPS information.
We observed a diverse, yet limited spread of manufac-
turers and models, depicted in Table 4. Huawei was
the most prevalent manufacturer observed, primarily
attributed to the (Google) Nexus 6P (1660 unique
devices). Various versions of the Huawei Mate and
Huawei P9 were also commonly observed. Sony was
well-represented with 277 unique devices across 23
variations of Xperia models. There were several sur-
prising observations in this list, namely that Samsung
was absent despite having the largest market share
for Android manufacturers [19]. Blackberry, HTC,
and LG were also poorly represented. The Black-
berry device models were actually four derivations of
the Blackberry Priv, accounting for 277 unique de-
vices observed. HTC was largely represented by the
HTC Nexus 9 from the Google Nexus line, which ex-
plains the likely use of randomization. The HTC One
M10 was the remaining HTC device and was only ob-
served once. The only observed LG device was the
LG G4 model. We provide a full device breakdown
in Appendix C.
Table 4: DA:A1:19 Manufacturer Breakdown
Manufacturer Total Devices Model Diversity
Huawei 1708 11
Sony 277 23
BlackBerry 234 4
HTC 108 2
Google 13 2
LG 1 1
In all, devices having randomized MAC addresses
with a Google CID and containing WPS attributes
amount to a total of 2,341 unique devices. Taking
into account the 849 unique Motorola Nexus 6 de-
vices, only 3,188 devices spanning 44 unique mod-
els are susceptible to the UUID-E reversal attack.
Effectively, 99.98% of the locally assigned MAC
addresses in our corpus are not vulnerable to the
UUID-E attack. Furthermore, our corpus contains
approximately 1.2 million client devices with glob-
ally unique MAC addresses and over 600 manufactur-
ers and 3,200 distinct models using WPS data fields.
This begs the question, are a large number of Android
devices not conducting randomization? Do we expect
the 43,924 randomized addresses using the Google
CID that did not not transmit WPS information to
make up all remaining Android devices?
We attempt to answer these questions by evaluat-
ing the 43,924 DA:A1:19 MAC addresses where no
WPS derived data is available. The process proceeds
as follows:
1. Divide the entire bin into segments, based on the
device’s signature described in §4.2, resulting in
67 distinct device signatures, with a starting hy-
pothesis that each signature represents a distinct
model of phone.
2. For each signature, parse every packet capture
file where that device signature and the CID
DA:A1:19 were observed.
3. Apply to our parsing filter our custom Tshark
device signature and limit to probe request
frames.
The output of the algorithm is the source MAC ad-
dress, sequence number, SSID, and device signature.
8
Left with 2,858 output files, each mapping a device
signature with distinct packet capture, we system-
atically retrieve the global MAC addresses for the
randomized devices. We will describe in detail the
methods for derandomization for this portion of the
dataset in §6. After we obtain the global MAC ad-
dress for the set of randomized MAC addresses within
each bin, we attempt to identify the device model us-
ing a variety of techniques. It is trivial to identify
the manufacturer as the OUI provides sufficient res-
olution. However, in order to conjecture the device
model we borrow from the work of [16] in which we
obtain model granularity from MAC address decom-
position. Next, we look for any case where a device
using a global MAC address as the source of a probe
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
the mDNS packet [16]. This leaves us with guesses
as to what devices randomize MAC addresses using
the DA:A1:19 CID and transmit no granular WPS-
derived model data. We posit that our set of 67 sig-
nature bins can be condensed into groups of similar
signatures based on our derived model correlations.
In order to better evaluate our assumptions, and
now that we have a smaller, manageable set of pos-
sible devices, we procure devices for lab testing. We
test each device using an RF enclosed chamber to
ensure we limit our collection to only our individual
test phones. We leave each device in the chamber for
approximately five minutes, collecting only the probe
requests.
We evaluate the collection results by comparing
to our derived signatures and ask the following: do
we observe MAC address randomization? If so, does
the device signature match expectations when using
a global address? Similarly, does the device signa-
ture match expectations when using a randomized
address? Our findings are presented in Table 5.
Bin 1 is represented by the Google devices LG
Nexus 5X and Google Pixel. This bin encompasses
57.7% of the 43,924 MAC addresses observed using
the Google CID without WPS data. It is prudent to
mention that we cannot claim that is an exhaustive
list of devices implementing randomization using this
set of signatures.
Table 5: DA:A1:19 no WPS
Category Confirmed % of no WPS
Bin 1 57.7%
LG Nexus 5X
Google Pixel
Bin 2 18.5%
LG G5
LG G4
Bin 3 2.0%
OnePlus 3
Xiaomi Mi Note Pro
Bin 4 .2%
Huawei
Sony
Bin 5 2.6%
Cat S60
Bin 6 12.2%
Composite
Bin 7 6.8%
Unknown
Next, we evaluate bin 2, representing 18.5% of the
category’s total. We observe only LG devices, specif-
ically we posit that LG G series devices make up this
subset. We confirm that both the LG G4 and G5 de-
vices match the signatures and behavior of this bin.
We surmise that additional G series devices are rep-
resented, however we have no validation at this time.
Worth mentioning is that the LG G4 and Pixel iden-
tified in the previous DA:A1:19 with WPS section
were only observed because a WPS action was trig-
gered. By default, WPS data is not transmitted by
the devices in our no-wps category. We confirm this
analysis in our lab environment, observing WPS data
fields only when the user triggers a WPS event.
In bin 3, a smaller bin (2%), the OnePlus 3, and
the Xiamoi Mi Note Pro are representative of the
identified signatures.
Bin 4, the smallest of our bins with less then one
percent of our dataset, consisted of Huawei and Sony
devices. These are devices seen using WPS, but in
some frames do not include the WPS data fields.
The Cat S60 smartphone was the only device iden-
tified in bin 5. As in other bins, we make no claim
that no other devices share this signature.
Bin 6 represents a combination of the aforemen-
tioned devices observed in the various bins. This is
caused by a device, that on occasion rotate between
a standard device signature and a stripped down ver-
sion with limited 802.11 IE fields. An example of this
9
signature behavior is described in §6.4 and depicted
in Figure 2. As such, this bin is represented by the
previously mentioned devices.
We fail to identify anything with any sense of con-
fidence within bin 7.
5.1.3 Motorola
After an exhaustive look at the randomization
schemes employed by Android we still lack any evi-
dence of MAC address randomization by Samsung or
Motorola devices (other then the Google based Mo-
torola Nexus 6). We attempt to find any evidence of
non-standard randomization employed by these mod-
els by looking at probe requests with globally as-
signed MAC addresses. In a similar manner to how
we identified the most common prefixes for locally as-
signed addresses, we attempt to identify OUIs with
unusually high occurrences within individual packet
captures. Our premise is that this will indicate the
use of an OUI as a prefix for a set of randomized
MAC addresses.
We first ruled out all P2P service related addresses
as previously described, leaving a single manufacturer
of interest - Motorola. We identified multiple occur-
rences of various Motorola OUIs with an abnormally
high percentage of the unique addresses in a packet
capture. After inspecting forty captures with this
anomaly we confirmed that a subset of Motorola de-
vices perform randomization using neither a CID nor
an OUI with the local bit set. These devices used
one of several Motorola owned OUIs, using the global
MAC address occasionally, and a new randomized
MAC address when transmitting probe requests.
This is an especially strange result because it shows
that Motorola is using randomized global addresses.
This violates the core expectation that no two devices
will use the same global MAC address. In particular,
it is possible for one of these devices to temporarily
use the true, global MAC address of another device
as one of its random addresses.
We identified two distinct signatures consistently
observed within this Motorola dataset. Using the
aforementioned mDNS techniques to guess a device
model we posit that one signature belongs to the
Moto G4 model while the second corresponds to a
Moto E2. We acquired Moto G4 and E2 smartphones
and confirmed our hypothesis. Additionally, we ob-
served that a Moto Z2 Play device model shares the
same randomization behavior and signature as the
Moto G4.
5.1.4 Samsung
It is interesting to note that we never observed
Samsung devices performing MAC address random-
ization, despite being the leading manufacturer of
Android smartphones. Samsung uses their own
802.11 chipsets, so it is possible that chipset compati-
bility issues prevent implementing randomized MACs
addresses. Samsung devices alone represent 23% of
Android devices in our data set, contributing sub-
stantially to the low adoption rate that we see.
5.2 iOS Randomization
After completing the randomization analysis of
Android devices, we still have over 1.3 million
MAC addresses not attributed to any randomization
scheme. Next we turn to the analysis of iOS random-
ization.
Upon the release of iOS 8.0, Apple introduced
MAC address randomization, continuing with mi-
nor but valuable updates to the policy across subse-
quent iOS releases. We were faced with an immediate
dilemma, how do we identify iOS associated probe
requests? Apple iOS devices do not transmit WPS
fields to indicate any sort of model information, and
we had no knowledge of any Apple owned CID. In
order to identify any prefix pattern we once again uti-
lized our RF-clean environment to test Apple device
behavior. Our goal was to create as many random-
ized MAC addresses as possible from a device and
look for a pattern in the resulting prefixes. To force
a new randomized MAC address we simply enable
and disable WiFi mode repeatedly.
Our initial thought was that Apple would use a
OUI or CID like other manufacturers and simply ran-
domize the least significant 24 bits of the MAC ad-
dress. However, we quickly found that the MAC ad-
dresses randomly generated by iOS devices do not
share any common prefix. In fact, they appear to be
10
completely random, including the 24 OUI bits, ex-
cept for the local bit which is always set to 1 and
the multicast bit which is set to 0. To lend credence
to this new hypothesis we sampled 47,255 random
MAC addresses from an iOS device and ran standard
statistical tests to determine if they were uniformly
distributed (see Appendix B). These tests confirmed
that, with the exception of the local and unicast
bit, iOS most likely implements true randomization
across the entire MAC address. This is interesting
given the fact that the IEEE licenses CID prefixes
for a price, meaning that Apple is freely making use
of address space that other companies have paid for.
Based on these findings, we are faced with identi-
fying a randomization scheme where randomness is
applied across 246 bits of the byte structure. We can
not simply assume that if the prefix does not match
an offset of an allocated OUI that it is an iOS de-
vice. This is due to the aforementioned clobbering
of other manufacturers OUI space. Our next step
was to leverage the use of mDNS once again. We
take the union of global MAC addresses derived from
probe requests that are also seen as source addresses
for iOS related mDNS packets. This results in a set
of probe requests that we can confirm are Apple iOS
devices. We then extract all of the signatures for
these devices. We suspected that this retrieved only
a portion of the relevant iOS signatures. Next we col-
lected signatures from all of our Apple iOS lab test
devices using our RF enclosure. Finally, we identify
signatures of all remaining locally assigned MAC ad-
dresses in which we have no assigned categorization.
We then seek to find any probe requests with global
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
different then our mDNS test as we cannot attribute
the signature to a specific set of iOS device models.
We test our entire iOS signature set and ensure that
no non-iOS global MAC addresses are ever observed
with these signatures.
In June 2016, midway through our research, iOS 10
was released. Inexplicably the addition of an Apple
vendor specific IE was added to all transmitted probe
requests. This made identification of iOS 10 Apple
devices trivial regardless of the use of MAC address
randomization. We believe the difficulty of identify-
ing MAC address randomization to be one of the best
countermeasures to defeating randomization. Com-
pounding our incredulity, the data field associated
with this IE never changes across devices.
Using our combined set of all Apple iOS signatures,
we identify 1.3 million distinct randomized MAC
addresses, by far the most populous (94.7%) of our
randomization categories.
5.3 Windows 10 and Linux Random-
ization
To conclude our categorization of randomization
schemes, we look to identify the probe requests from
devices using Windows 10 and Linux MAC address
randomization implementations. Our first test com-
pares the signatures obtained from laboratory lap-
tops to the signatures of our locally assigned dataset.
We find 59 matches to our laptop signatures, indi-
cating possible Windows 10 or Linux randomization.
Next, we parse collection files using the locally as-
signed MAC addresses from the probe request frames
of these devices. Our hypothesis, if we find matching
locally assigned MAC addresses in authentication, as-
sociation, or data frames, that the randomizations
scheme is likely Windows 10 or Linux. This assump-
tion is due to the fact that the randomization policies
use the same locally assigned address for network es-
tablishment and higher layer data frames. To that
end, we find that 14 of the 59 devices assessed to
be Windows/Linux computers use a locally assigned
MAC address when associated to a network.
6 MAC Randomization Flaws
Now that we have a baseline understanding of the
randomization implementations used by modern mo-
bile OSs we are able to assess for vulnerabilities.
6.1 Adoption Rate
The most glaring observation, while not necessarily
a flaw per se, is that the overwhelming majority of
Android devices are not implementing the available
11
randomization capabilities built into the Android
OS. We expect that this may be partly due to
802.11 chipset and firmware incompatibilities. How-
ever, some non-randomizing devices share the same
chipsets as those implementing randomization, so it is
not entirely clear why they are not utilizing random-
ization. Clearly, no effort by an attacker is required
to target these devices.
6.2 Global Probe Request
We next explore the flaws of the observed MAC ad-
dress randomization schemes. One such flaw, the in-
explicable transmission of the global MAC address in
tandem with the use of randomized MAC addresses.
We observe this flaw across the gamut of Android de-
vices. The single device in which we do not observe
this was the Cat S60 smartphone. In no instance did
the Cat S60 transmit a global MAC address probe
request, except immediately prior to an association
attempt. Exploiting this flaw it was trivial to link
the global and randomized MAC addresses using our
device signatures and sequence number analysis. Be-
tween probe requests, the sequence numbers increase
predictably so an entire series of random addresses
can be linked with a global address by just following
the chain of sequence numbers. While using sequence
numbers has been discussed before in prior work [22],
the fact that the global MAC address is utilized while
in a supposedly randomized scan state has not. This
strange behavior is a substantial flaw, and effectively
negates any privacy benefits obtained from random-
ization. In our lab environment we observed that
in addition to periodic global MAC addressed probe
requests, we were able to force the transmission of
additional such probes for all Android devices. First,
anytime the user simply turned on the screen, a set
of global probe requests were transmitted. An active
user, in effect, renders randomization moot, eliminat-
ing the privacy countermeasure all together. Second,
if the phone received a call, regardless of whether the
user answers the call, global probe requests are trans-
mitted. While it may not always be practical for an
attacker to actively stimulate the phone in this man-
ner, it is unfortunate and disconcerting that device
activity unrelated to WiFi causes unexpected conse-
quences for user privacy.
6.3 UUID-E Reversal
Vanhoef et. al. introduce the UUID-E reversal at-
tack against Android devices [22]. Devices transmit-
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
be retrieved using the WPS UUID-E value. The flaw
caused by the construction of the UUID-E, where the
MAC address is used as an input variable along with a
non-random hard-coded seed value. This implemen-
tation design flaw allows for the computation of pre-
computed hash tables, whereby retrieving the global
MAC address requires only a simple search of the
hash tables. This revelation, both groundbreaking
and disconcerting, still leaves the reader to guess as
to the plausibility of the attack against randomized
devices. We find several issues with their approach,
specifically in respect to derandomization analysis:
i) randomization was not employed in 2013, when
the data used in their evaluation was gathered ii)
anonymized data eliminates accuracy checks, and iii)
removing locally assigned MAC addresses effectively
eliminates the ability to evaluate the attack against
devices performing randomization.
Accordingly, we use our corpus of DA:A1:19 and
92:68:C3 datasets to evaluate the effectiveness and
viability of the UUID-E attack. Our foremost obser-
vation is that only 29% of random MAC addresses
from Android devices include WPS attributes. Ef-
fectively 71% of this Android dataset is completely
immune to the UUID-E reversal attack. This is in
addition to the fact that iOS devices are wholly im-
mune to the attack, as they do not use WPS. We
refer back to Table 4 the limited number of Android
models performing randomization and transmitting
the necessary WPS UUID-E attribute.
We then retrieve the global MAC address from the
probe requests of these devices that used both ran-
dom and global MAC addresses, exploiting the previ-
ously discussed flaw. We use this set of 1,417 ground
truth MAC addresses to test the effectiveness of the
UUID-E reversal attack. First we pre-compute the
12
required hash tables. To build hash tables for the en-
tire IEEE space would be non-trivial, requiring sig-
nificant disk space and processing time. While an ex-
haustive compilation of the address space is certainly
possible, we use the knowledge gained from decom-
posing the randomization schemes to efficiently con-
struct our tables. We build the hash tables using only
the OUIs owned by manufacturers we have observed
to implement randomization. The resulting hash ta-
ble is a manageable 2.5TBs, where using pre-sorting
techniques, we can retrieve an UUID-E’s global MAC
address in <1 second.
We retrieve a global MAC address for 3,187 of the
3,188 UUID-Es. In previous work it was left incon-
clusive whether the retrieved MAC addresses were in
fact the global 802.11 MAC address or instead the
Bluetooth MAC address. The UUID-E derived from
the HTC One M10 device, was the example UUID-E
listed in the wpa supplicant.conf file. With exception
of the HTC Nexus 9, all HTC phones in our dataset
(regardless of randomization) used this non unique
UUID-E.
Comparing the 1,417 ground truth addresses to
those retrieved from the UUID-E attack we achieve a
100% success rate. Indicating that the retrieved ad-
dresses are in fact the global 802.11 MAC addresses,
completing the missing link from the evaluation of
Vanhoef et al. [22].
6.4 Device Signature
To aide in derandomization we employ fingerprinting
techniques, using signatures derived from the 802.11
IEs borrowed from previous work [22, 13]. We used
this technique first to aide in the identification of
the randomization schemes employed by Android and
iOS devices.
This technique allows us to remove all extrane-
ous probe request traffic, providing us a “cleaner”
dataset in which to employ sequence number analy-
sis. We modify the Wireshark files packet-ieee80211.c
and packet-ieee80211.h, creating a new dissector fil-
ter, device.signature. We are able to filter previous
collection files as well as conduct filtering on live col-
lection. While our contribution to the Wireshark dis-
tribution is novel, the fingerprinting technique is not,
as we borrowed from related work. However, prior
work tested against datasets not performing random-
ization which fails to provide accurate context. We
test the signature technique against our real world
corpus, revealing flaws in previous signature based
attacks.
Regardless of the Android implementation, a de-
vice transmits probe request frames which have vary-
ing signatures (based on IEs, see §3). Devices of-
ten use two or more signatures while using a global
MAC address, so simply using the signature is in-
sufficient. Additionally, the same holds for random-
ized addresses, in which we observe multiple signa-
tures. In both cases, the second signature, has min-
imal 802.11 IEs. Due to the fact that nearly all de-
vices periodically use this signature, it creates signif-
icant complexity to any signature based derandom-
ization attack. Finally, as Figure 2 illustrates, we
observe that most Android devices use different sig-
natures when randomizing compared to when using
a global MAC address. As such, previously described
signature-based tracking methods fail to correlate the
addresses. Using our decomposition of Android ran-
domization schemes, and the derived knowledge of
how distinct bins of devices behave, we properly pair
the signatures of probe requests using global and ran-
domized MAC addresses. Only by combining these
signatures are we able to accurately and efficiently
retrieve the global MAC address.
We observe no such change in signatures of iOS
devices within a collection timeframe. While an iOS
device may not use alternate signatures, they do not
send globally addressed probe requests. Therefore,
at this juncture, we have not identified a method of
resolving the global MAC address.
6.5 Association/Authentication
Frames
We observe that Android and iOS devices use se-
quential sequence numbers across management frame
types. Using only passive analysis we can follow a de-
vices transition from randomized probe requests to an
authentication or association frame by following the
sequence numbers. This is particularly useful as all
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
the techniques described in [13] we create a set of
signatures for the association frames of iOS devices,
specifically to aide in confirmation that the device
observed in the probe request is also the same device
type as the association frame. This method relies on
the targeted device attempting to establish a network
connection with a nearby AP. As this is fairly user-
activity dependent, we reinvestigate the plausibility
of the Karma attack against current randomization
schemes.
6.6 Karma Attack
The current versions of iOS and Android random-
ization policies have eliminated the vast majority of
cases where a directed probe is used. A directed
probe is a probe request containing a specified SSID
that the device wishes to establish a connection (a
previously known or configured SSID), as opposed
to a broadcast probe which solicits a response from
all APs in range. Today, the predominant use of
broadcast probes has directly effected the ability for
a Karma-based attack to succeed. Karma-based at-
tacks work by simulating an access point that a device
prefers to connect to. A variety of implications such
as man-in-the-middle attacks are common follow-on
consequences, however we are only interested in re-
trieving the global MAC address and therefore re-
quire only a single authentication frame to be trans-
mitted by a targeted device. To this end Vanhoef et.
al. also investigate Karma attacks, implemented via
a predefined top-n SSID attack, achieving a 17.4%
success rate, albeit not specifically related to devices
performing randomization.
Unlike previous work, we observe devices while in a
randomized state in order to identify specific behav-
iors that directly counteract randomization privacy
goals. Specifically, do we observe traits that allow
for a targeted Karma attack? It is well known that
hidden networks require directed probes, so while this
is a vulnerability to randomization, it is fairly uncom-
mon, and a decision in which a user chooses to imple-
ment. Similarly, previous connections to ad hoc net-
works, saved to the devices network list, cause both
Android and iOS devices to send directed probes. As
with hidden networks, this uncommon condition re-
quires action from the user, however when observed,
the Karma attack is viable.
Finally, we observe a more disconcerting trend: de-
vices configured for seamless cellular to WiFi data-
offloading, such as Hotspot 2.0, EAP-SIM and EAP-
AKA force the use of directed probes and are inher-
ently vulnerable to Karma-based attacks [4]. The
expanding growth of such handover polices reveals
a significant vulnerability to randomization counter-
measures. Further exasperating the problem, these
devices are pre-configured with these settings, requir-
ing no user interaction. We confirmed these settings
by inspecting the wpa supplicant.conf file of a Mo-
torola Nexus 6 and Nexus 5X. Removing the networks
from the configuration file requires deletion by a rare
user with both command line savvy and awareness of
this issue.
We test for the presence of these network configura-
tions in our corpus by evaluating all randomized ad-
dresses using WPS fields. We are able to accurately
evaluate unique devices using the UUID-E value as
the unique identifier. We filter for any instance where
the device sends a directed probe, retrieving the SSID
value for each. Sorting by most common occurrence
the top three most common SSIDs were BELL WIFI,
5099251212, and attwifibn. The SSIDs BELL WIFI
and 5099251212 are used by the mobile carrier Bell
Canada for seamless WiFi offloading. Interestingly,
the attwifibn SSID is related to free WiFi hotspots
provided by the Barnes and Noble bookstore. Only
5% of the datasets 3,188 devices transmitted a di-
14
rected probe. However, of those that did, 17% of were
caused by the preconfigured mobile provider settings.
Next we take a cursory look at Apple iOS and
Android devices with no amplifying WPS informa-
tion. We do not get precise statistics, however, we
observe the same trend.
6.7 Control Frame Attack
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-
vice performing MAC address randomization to re-
spond to frames targeting the global MAC address?
This would allow for easy tracking of devices, even
when they are randomizing, because an active at-
tacker could elicit a specific response from them at
any time if they are within wireless range.
Table 6: Class 1 Frames [12]
Control Management Data
RTS Probe Request Frame w/DS bits false
CTS Probe Response
Ack Beacon
CF-End Authentication
CF-End+CF-Ack Deauthentication
ATIM
Figure 3 depicts the 802.11 state diagram illustrat-
ing the various states of association for 802.11 devices
[12]. We are particularly interested in the frame types
that can be sent or received while in an unauthenti-
cated and unassociated state (State 1). The frame
types (Class 1 frames) allowed while in State 1 are
depicted in Table 6.
In our lab environment, we use packet crafting
tools (SCAPY, libtins) to transmit customized pack-
ets for each frame type, targeting the global MAC of
the device.
The source MAC address of the frame is a uniquely
crafted MAC address. It is not the actual MAC ad-
dress of our transmitter. This ensures that we can ac-
curately track any responses to our crafted message,
removing any possible control frames that happen to
be sent to the actual transmitter address. Of the
twelve Class 1 frame types used for the attack, we suc-
State 3
Authenticated
and associated
State 2
Authenticated
and unassociated
State 1
Authenticated
and unassociated
Class 1, 2
and 3 frames
Class 1 and 2
frames
Class 1 frames
Disassociation
Deauthentication
Association
Authentication
Figure 3: 802.11 State Diagram
cessfully elicited a response from only the Request-
to-Send (RTS) frame.
Request to Send and Clear to Send (RTS/Clear-to-
Send (CTS)) transmissions are available in the IEEE
802.11 specification as part of a Carrier Sense Multi-
ple Access with Collision Avoidance scheme. When
a node desires to send data an RTS may be sent to
alert other nodes on the channel that a transmission
is about to begin and the period of time during which
they should not transmit on that channel so as to
avoid collisions. If there are no conflicting uses of the
channel, the target node will respond with a CTS
to acknowledge the request and give the transmit-
ting node permission to solely communicate on the
medium.
As for previous location and tracking attacks, some
researchers have used RTS/CTS messages to perform
Time of Arrival computations [14] while others have
extended these techniques to perform Time Differ-
ence of Arrival calculations from timestamps in ex-
changed frames [9]. These older methods perform lo-
calization on Access Points from client devices. The
novelty in our method is that we are sending RTS
frames to IEEE 802.11 client devices, not APs, to ex-
15
tract a CTS response message which we derive the
true global MAC address of that device. Instead of a
localization attack, we are using RTS/CTS exchanges
to perform derandomization attacks.
The result of sending a RTS frame to the global
MAC address of a device performing randomization
was that the target device responded with a CTS
frame. A CTS frame, having no source MAC address,
is confirmed as a response to our attack based on the
fact that it was sent to the original, crafted source
MAC address. A full device listing utilized for the
control frame attack is available in Appendix D.
Once the global MAC address is known, that de-
vice can be easily tracked just as if randomization
were never enabled. This might cause one to won-
der why vendors would go to such lengths to include
MAC address randomization in a device only to allow
that same device to divulge the protected information
through an administrative protocol. We assert that
this phenomenon is beyond the control of individual
vendors. The fact is that this behavior occurs across
the board on every device we have physically tested as
shown in Appendix D. This leads us to believe that
RTS/CTS responses are not a function of the OS,
but of the underlying IEEE 802.11 chipset. Manu-
facturers have configured their chipset hardware with
default RTS/CTS operation which may not even be
accessible to configure at the OS level. If we are cor-
rect, this derandomization issue can not be fixed with
a simple patch or OS update. Susceptible mobile de-
vices will be unmasked by this method for the life-
time of the device. Additionally, due to the hard-
ware level nature of this phenomenon, there will be
a significant delay in the market until mobile devices
resistant to this attack are produced, assuming man-
ufacturers recognize this as a flaw and subsequently
design a process truly capable of delivering MAC ad-
dress privacy.
There are multiple scenarios in which a motivated
attacker could use this method to violate the privacy
of an unsuspecting user. If the global MAC address
for a user is ever known, it can then be added to a
database for future tracking. This global MAC ad-
dress can be divulged using the techniques discussed
in this paper, but it can also be observed any time
the user is legitimately using that global MAC ad-
dress, such as when connected to an AP at home or
work. This single leakage of the true identifier will
allow an attacker to send an RTS frame containing
that global MAC address in the future to which that
host will respond with a correct CTS when it is in
range. Conceivably, an adversary with a sufficiently
large database and advanced transmission capabil-
ities could render randomization protections moot.
Additional tests, while the target device had WiFi
or Airplane-modes, enabled or disabled respectively,
revealed further concerns. Namely, Android devices
performing location-service enabled functions wake
the 802.11 radio. Our RTS attack was thusly able to
trigger a CTS response from the target, circumvent-
ing even extreme privacy countermeasures.
Lastly, we add improvements, using our Wireshark
signature filters, to eliminate the constant barrage of
transmitted RTS frames. Our collection algorithm
is pre-loaded with the target of interest’s device sig-
nature, where upon observing the signature in the
target area we launch the preconfigured MAC ad-
dress. We test this against our diverse test phones
with 100% success.
6.7.1 Bluetooth Correlation
We offer an additional method to derive the global
WiFi MAC address for later use in a RTS attack.
Wright and Cache [23] claim that Apple iPhone de-
vices, beginning with the iPhone 3G, utilize a one-off
scheme for the allocation of the Bluetooth and WiFi
MAC addresses, where the MAC address is actually
equal to the Bluetooth address, plus or minus one.
Using a novel algorithm to calculate the WiFi and
Bluetooth MAC address from iOS devices operating
in hotspot mode, we provide evidence countering this
claim.
We identified that Apple iOS devices, operating
in hotspot mode, send beacon management frames
containing an Apple vendor specific IE. This Type
6field closely resembles the source MAC address of
the device. As Wireshark does not process this field
correctly we built custom dissectors to create display
filters for the Apple vendor tag IE and associated
data fields. We first test on 29 Apple iOS lab devices,
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 Hotsp ot 2.0 - Directed Prob es 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
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 observe that the Type 6 field exactly repre-
sents the Bluetooth MAC address. The source MAC
address of the Beacon frame has the local bit set.
However, the first byte of the source MAC address
is not a simple offset of the global MAC address as
seen in most P2P operations. To resolve the actual
global MAC address we find that replacing the first
byte of the source MAC address with the first byte
of the Type 6 (Bluetooth Derived) MAC address, we
obtain the correct WiFi MAC address of the device.
This permutation is successfully tested for all 29 test
devices across the gamut of model and iOS versions.
Interestingly, six of the 29 test devices did not show
a one-off MAC address allocation. As such, we seek to
identify the accuracy of the previous claim that iOS
devices use this one-off scheme by evaluating across
our entire corpus.
A total of 3,576 devices were identified in our
dataset containing the Type 6 field of which 95.4%
utilized a one-off addressing scheme. Interestingly,
88.2% of those devices had a Bluetooth address that
was one-higher then the WiFi MAC address. Indi-
cating that even when the offset is used it is not uni-
formly implemented. We are unsure as to why 4.6%
of iOS devices do not use the one-off policy. Regard-
less, in all cases the OUI of the two interfaces are
the same. Using the mDNS model correlation anal-
ysis we observed no indication that offset scheme is
correlated with the device model.
7 Conclusions
We provide a detailed breakdown of the randomiza-
tion polices implemented, the associated device mod-
els, and the identification methods thereof. This
granularly detailed decomposition allowed for fine-
tuned improvements to prior attempts at MAC ad-
dress derandomization as well as providing novel ad-
ditions.
Our analysis illustrates that MAC address random-
ization policies are neither universally implemented
nor effective at eliminating privacy concerns. Ta-
ble 7 depicts the diversity of presented attacks, across
the spectra of randomization schemes and OSs, high-
lighted by the RTS control frame attack targeting a
widespread low-level chipset vulnerability.
To be truly effective, randomization should be uni-
versally adopted. A continued lack of adoption, al-
lowing for simpler identification, effectively reduces
the problem set for an attacker. The more de-
vices performing randomization within a test set, the
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-
lem set.
We propose the following best practices for MAC
address randomization. Firstly, mandate a universal
randomization policy to be used across the spectra of
802.11 client devices. We have illustrated that when
vendors implement unique MAC address randomiza-
tion schemes it becomes easier to identify and track
those devices. A universal policy must include at
minimum, rules for randomized MAC address byte
structure, 802.11 IE usage, and sequence number be-
havior.
17
To reiterate, these best practices can only be truly
effective when enforced across the spectrum of de-
vices. Granular examples of such policy rules:
Randomize across the entire address, providing
246 bits of randomization.
Use a random address for every probe request
frame.
Remove sequence numbers from probe requests.
If sequence numbers are used, reset sequence
number when transmitting authentication and
association frames.
Never send probe requests using a global MAC
address.
Enforce a policy requiring a minimal and stan-
dard set of vendor IEs. Move any lost function-
ality to the authentication/association process,
or upon network establishment utilize discovery
protocols.
Specifically, the use of WPS attributes should
be removed except when performing P2P opera-
tions. Prohibit unique vendor tags such as those
introduced by Apple iOS 10.
Eliminate the use of directed probe requests for
cellular offloading.
Mandate that chipset firmware remove behavior
where RTS frames received while in State 1 elicit
a CTS response.
References
[1] Linux wpa supplicant (ieee 802.1x,
wpa, wpa2, rsn, ieee 802.11i). URL
https://w1.fi/wpa_supplicant/.
[2] wpa supplicant change log. URL
https://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog.
[3] China deputizes smart phones to spy on bei-
jing residents’ real-time location, Oct 2011. URL
https://www.eff.org/deeplinks/2011/03/china-deputizes-smart-phones-spy- beijing-residents.
[4] Wifigate - how mobile carriers expose
us to wi-fi attacks, Apr 2014. URL
https://www.skycure.com/blog/wifigate-how-mobile-carri
[5] Danger close: Fancy bear tracking of
ukrainian field artillery units, Jan 2017. URL
https://www.crowdstrike.com/blog/danger-close-fancy-be
[6] D. E. 3rd and J. Abley. IANA Considera-
tions and IETF Protocol and Documentation
Usage for IEEE 802 Parameters. RFC 7042
(Best Current Practice), Oct. 2013. URL
http://www.ietf.org/rfc/rfc7042.txt.
[7] M. V. Barbera, A. Epasto, A. Mei, S. Kosta,
V. C. Perta, and J. Stefa. CRAW-
DAD dataset sapienza/probe-requests.
http://crawdad.org/sapienza/probe-requests/20130910,
Sept. 2013.
[8] J. Bard. Unpacking the dirtbox: Confronting
cell phone location tracking with the fourth
amendment. BCL Rev., 57:731, 2016.
[9] Z. Cui and A. Agrawala. Wifi localization based
on ieee 802.11 rts/cts mechanism. In Proceed-
ings of the 12th EAI International Conference
on Mobile and Ubiquitous Systems, pages 199–
208. ICST, 2015.
[10] M. Cunche. I know your mac address: tar-
geted tracking of individual using wi-fi. Journal
of Computer Virology and Hacking Techniques,
2014.
[11] . Dara Kerr July 29. Russian police spy on peo-
ple’s mobile data to catch thieves, Jul 2013. URL
https://www.cnet.com/news/russian-police-spy-on-people
[12] M. Gast. 802.11 wireless networks : the
definitive guide. O’Reilly, Beijing, Farn-
ham, 2005. ISBN 0-596-10052-3. URL
http://opac.inria.fr/record=b1128195.
[13] D. Gentry and A. Pennarun. Passive taxon-
omy of wifi clients using MLME frame con-
tents. CoRR, abs/1608.01725, 2016. URL
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-
ration
A.1 Android
In October 2014 the wpa suppplicant.conf file, used
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-
dress randomization in network scans. Full imple-
mentation support was added in March 2015 [2]. List-
ing 1 depicts the added support for MAC address
randomization. It is worth noting that the configura-
tion file provides two policies for using a non-globally
unique address while in an associated state. If the
variable mac addr is set to 1the device will use a
randomized MAC address for each unique network
the device connects to. If mac addr is set to 2the
device will randomize the lower three bytes of the
MAC address prefixed with the original OUI where
the local bit has been set to 1.
The wpa supplicant.conf file also addresses the ran-
domization policies available for disassociated devices
conducting active scanning. In this case, the variable
preassoc mac addr can be set similarly to the pre-
viously described address policies.
Listing 1: wpa supplicant.conf
# MAC address policy default
# 0 = use permanent MAC address
# 1 = use random MAC address for each ESS
connection
# 2 = like 1, but maintain OUI (with local
admin bit set)
#
# By default, permanent MAC address is used
unless policy is changed by
# the per-network mac_addr parameter. Global
mac_addr=1 can be used to
# change this default behavior.
#mac_addr=0
# Lifetime of random MAC address in seconds
(default: 60)
#rand_addr_lifetime=60
# MAC address policy for pre-association
operations (scanning, ANQP)
# 0 = use permanent MAC address
# 1 = use random MAC address
# 2 = like 1, but maintain OUI (with local
admin bit set)
#preassoc_mac_addr=0
Android introduced MAC address randomization
for probe requests with Android 6.0 (Marshmal-
low) and in an incremental patch to 5.0 (Lollipop).
With the release of Marshmallow, the WifiStateMa-
chine.java and WifiNative.java files were modified
to implement MAC address randomization for active
scanning. When the SupplicantStartedState function
is called upon enabling WiFi, a call to the newly
added setRandomMacOui function sets the first three
bytes of the MAC address to the default Google CID
(DA:A1:19). If the config wifi random mac oui
variable has been redefined in the config.xml file, that
prefix will be used in place of the default Google CID.
The XML configuration file allows an Android smart-
phone manufacturer to override the default Google
CID with a prefix to be used as the substitute for
the OUI. Finally, the prefix is passed to another
function, setScanningMacOui located in the WifiNa-
tive.java file which calls a corresponding function at
a lower, native level. If the device chipset is compat-
ible to support randomization then the prefix will be
used during active scans.
We extracted the wpa supplicant.conf,WifiS-
tateMachine.java, and WifiNative.java files from
Android devices that do and do not perform
MAC address randomization. We found that the
wpa supplicant file was never utilized to implement
randomization, as attempts to modify the random-
ization settings of the file had no affect on any device.
The Java files also had the supporting functions for
randomization included, regardless if the device used
them. Interestingly, with logging enabled, the devices
that did not conduct randomization sent output to
the logs indicating that the random MAC had been
set, where devices seen randomizing did not.
20
A.2 iOS
In late 2014, Apple introduced MAC address random-
ization with the release of iOS 8.0. Apple iOS ran-
domization settings are not device-model customiz-
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
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-
tion from different devices and iOS versions in §5.
B iOS Randomization Tests
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-
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
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:
E[# of collisions] = n
2
m
E[# of triple collisions] = n
3
m2
where n= # of addresses observed
m= # of possible prefixes (222 )
Comparing our empirical results with the statisti-
cal expectations, we get:
For :
Collisions : expected = 266, observed = 262
Triple collisions : expected = 1, observed = 3
Additionally, we decomposed the bytes of subse-
quent MAC addresses into a bit stream and ran the
tests specified in the FIPS 140-1 standard published
by NIST to test random number generators. We ob-
tained the following results:
Monobit test: 9939
Poker test: 13.56
Runs test length 1: 2515
Runs test length 2: 1342
Runs test length 3: 581
Runs test length 4: 281
Runs test length 5: 166
Longest run test: 12
All tests passed within the allowable ranges. These
tests indicate to us that the MAC addresses are dis-
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
... In the following, we elaborate on the various features comprised in Table 1. All listed versions use MAC address randomisation while probing [19,13,34]. In Android 9 devices, users can choose via Developer Options whether a randomised MAC address should be used while connected. ...
Preprint
Full-text available
Probe requests help mobile devices discover active Wi-Fi networks. They often contain a multitude of data that can be used to identify and track devices and thereby their users. The past years have been a cat-and-mouse game of improving fingerprinting and introducing countermeasures against fingerprinting. This paper analyses the content of probe requests sent by mobile devices and operating systems in a field experiment. In it, we discover that users (probably by accident) input a wealth of data into the SSID field and find passwords, e-mail addresses, names and holiday locations. With these findings we underline that probe requests should be considered sensitive data and be well protected. To preserve user privacy, we suggest and evaluate a privacy-friendly hash-based construction of probe requests and improved user controls.
... Thus, major mobile phone manufacturers such as Apple and Huawei have used the MAC address randomization technology to solve these privacy issues [87]. MAC address randomization refers to the rotation of mobile devices through random hardware addresses to prevent observers from picking out their traffic or physical location from other nearby devices [102]. The experimental results in [87] show that most Android phones did not use randomization when the experiments were conducted, while Apple devices running on iOS 9 seemed to change MAC addresses only when the user turned the screen on and off. ...
Article
Full-text available
With the increasing innovation and development of Wi-Fi technology, its penetration in the various fields of industry and academia is becoming more and more profound. As the core infrastructure of traffic data collection in the field of Intelligent Transportation Systems (ITS), Wi-Fi-based traffic detectors have great potential for use in traffic target positioning, perception, and pattern recognition due to their low-cost and extensive infrastructure deployment. This paper conducts a comprehensive review of three major Wi-Fi-based traffic detection applications in the field of ITS: target positioning, traffic parameter extraction, and travel mode identification. Among these, target positioning is one of the most widespread applications of Wi-Fi technology, which is also the basis for two other research aspects. Moreover, Wi-Fi-based positioning can be divided into two categories: ranging-based positioning and range-free one; in the field of transportation, it can also be categorized into pedestrian positioning and vehicle positioning based on travel mode. To further demonstrate the effectiveness of Wi-Fi-based ITS applications in practice, this study compares with the various Wi-Fi-involved models and algorithms around the world, as well as provides some ideas and inspiration along with this direction.
... We extend their work by evaluating modern devices supporting wider bandwidth channels, and additionally show two-meter level accuracy can be achieved on low-multipath 20 MHz bandwidth channels, matching evaluation results obtained in [11]. Furthermore, even though Wi-Fi MAC address randomization has been studied at length [12,28,47], and countermeasures to deanonymization and tracking mechanisms were proposed (e.g., randomization of sequence numbers) [36], we find these have not seen their adoption in protocols such as Wi-Fi FTM. Next, researchers have shown fingerprinting techniques to uniquely identify Wi-Fi cards [44,50,55], and in [14], the authors performed fingerprinting by including Wi-Fi FTM configuration parameters. ...
Article
Full-text available
With the standardization of Wi-Fi Fine Timing Measurement (Wi-Fi FTM; IEEE 802.11mc), the IEEE introduced indoor positioning for Wi-Fi networks. To date, Wi-Fi FTM is the most widely supported Wi-Fi distance measurement and positioning system. In this paper, we perform the first privacy analysis of Wi-Fi FTM and evaluate devices from a wide variety of vendors. We find the protocol inherently leaks location-sensitive information. Most notably, we present techniques that allow any client to be localized and tracked by a solely passive adversary. We identify flaws inWi-Fi FTM MAC address randomization and present techniques to fingerprint stations with firmware-specific granularity further leaking client identity. We address these shortcomings and present a privacy-preserving passive positioning system that leverages existing Wi-Fi FTM infrastructure and requires no hardware changes. Due to the absence of any client-side transmission, our design hides the very existence of a client and as a side-effect improves overall scalability without compromising on accuracy. Finally, we present privacy-enhancing recommendations for the current and next-generation protocols such as Wi-Fi Next Generation Positioning (Wi-Fi NGP; IEEE 802.11az).
Article
Tracking people’s flows has become crucial, not only for safety and security, but also for numerous practical business applications and better management of urban spaces, facilities and services. In this paper, we proposed methodologies that, exploiting IoT technology deployed at the edge of the network, allow for the analysis of people’s movement in urban environments, both outdoors and indoors. In particular, leveraging the use of WiFi probe packets sent by smart devices carried by people on the move, we first describe an implementation of our methodology using off-the-shelf hardware to count people boarding public transportation vehicles. We then present an alternate implementation using commercial WiFi scanners connected to the edge and leveraging suitably deployed virtual network functions to process the data collected by a OneM2M IoT platform, proposing also a mobility tracking procedure that can be applied to anonymized data provided by commercial WiFi scanners. Our experimental results show that the proposed approaches to people counting and mobility detection can achieve a good level of accuracy, while overall carrying a low price tag.
Article
The purpose of the study is to investigate the comparative field performance of Wi-Fi, Bluetooth Classic (Bluetooth) and Bluetooth Low Energy (BLE) signal modes for integration in vehicle–pedestrian collision warning systems. The study compares these wireless signal modes to find out which one is most appropriate to be utilized in these systems and provides better results in terms of accuracy and functionality. Five factors including received signal strength indicator (RSSI)-distance relationship, rainfall effects on the signals, motion effects, non-line of sight effects and signal transmission rates were selected for evaluation. These factors were selected considering the requirements of vehicle–pedestrian collision warning systems and compared with each other based on experimental outcomes. The results of the experiments indicated the overall superiority of BLE mode over Wi-Fi and Bluetooth modes to be utilized in these systems. Application of this mode may provide the possibility of fast collision warnings thanks to low signal transmission intervals and high probability of simultaneous signal detections by multiple signals scanners. Moreover, the capability of this mode to accurately estimate distance and position is higher than Wi-Fi mode and not significantly different from Bluetooth mode.
Article
Full-text available
In supporting Wifi networks it is useful to identify the type of client device connecting to an AP. Knowing the type of client can guide troubleshooting steps, allow searches for known issues, or allow specific workarounds to be implemented in the AP. For support purposes a passive method which analyzes normal traffic is preferable to active methods, which often send obscure combinations of packet options which might trigger client bugs. We have developed a method of passive client identification which observes the contents of Wifi management frames including Probes and Association requests. We show that the management frames populated by modern Wifi chipsets and device drivers are quite distinguishable, making it possible in many cases to identify the model of the device. Supplementing information from the Wifi management frames with additional information from DHCP further extends the set of clients which can be distinguished.
Conference Paper
Full-text available
Location Based Services are providing one of the fastest growing market segments today. While the most common technique for location determination is GPS, several alternative approaches have been proposed for Wi-Fi environments, based on time of flight, signal strength, etc. Time based techniques not only require accurate timestamping mechanisms, but also precise and synchronized clocks, which is quite difficult and expensive in industry. On the other hand, signal strength based methods need a lot of ground truth data. These method also require time consuming work and efforts before the system comes into use. In considerations of costs and time consumption, we present in this paper an approach for determining the location of a general Wi-Fi device combining RTS/CTS and TDoA techniques. The proposed model is deployable in various environments and contains two different methods, with clock mapping functions and asynchronized clocks. We also explain limitations of current round trip time (RTT) based RTS/CTS systems. Extensive experiments have been conducted and demonstrated how an accuracy of about one foot can be obtained and also the assumption of RTT measurements have been verified.
Article
Full-text available
Active service discovery in Wi-Fi involves wireless stations broadcasting their Wi-Fi fingerprint, i.e. the SSIDs of their preferred wireless networks. The content of those Wi-Fi fingerprints can reveal different types of information about the owner. We focus on the relation between the fingerprints and the links between the owners. Our hypothesis is that social links between devices’ owners can be identified by exploiting the information contained in the fingerprint. More specifically we propose to consider the similarity between fingerprints as a metric, with the underlying idea: similar fingerprints are likely to be linked. We first study the performances of several similarity metrics on a controlled dataset and then apply the designed classifier to a dataset collected in the wild. Finally we discuss potential countermeasures and propose a new one based on geolocation. This study is based on a dataset collected in Sydney, Australia, composed of fingerprints belonging to more than 8000 devices.
Article
Full-text available
Motivated by the proliferation of wireless-enabled de- vices and the suspect nature of device driver code, we develop a passive fingerprinting technique that identifies the wireless device driver running on an IEEE 802.11 compliant device. This technique is valuable to an at- tacker wishing to conduct reconnaissance against a po- tential target so that he may launch a driver-specific ex- ploit. In particular, we develop a unique fingerprinting tech- nique that accurately and efficiently identifies the wire- less driver without modification to or cooperation from a wireless device. We perform an evaluation of this fin- gerprinting technique that shows it both quickly and ac- curately fingerprints wireless device drivers in real world wireless network conditions. Finally, we discuss ways to preventfingerprinting that will aid in improving the secu- rity of wireless communication for devices that employ 802.11 networking.
Conference Paper
Common among the wide variety of ubiquitous networked devices in modern use is wireless 802.11 connectivity. The MAC addresses of these devices are visible to a passive adversary, thereby presenting security and privacy threats - even when link or application-layer encryption is employed. While it is well-known that the most significant three bytes of a MAC address, the OUI, coarsely identify a device's manufacturer, we seek to better understand the ways in which the remaining low-order bytes are allocated in practice. From a collection of more than two billion 802.11 frames observed in the wild, we extract device and model information details for over 285K devices, as leaked by various management frames and discovery protocols. From this rich dataset, we characterize overall device populations and densities, vendor address allocation policies and utilization, OUI sharing among manufacturers, discover unique models occurring in multiple OUIs, and map contiguous address blocks to specific devices. Our mapping thus permits fine-grained device type and model predictions for unknown devices solely on the basis of their MAC address. We validate our inferences on both ground-truth data and a third-party dataset, where we obtain high accuracy. Our results empirically demonstrate the extant structure of the low-order MAC bytes due to manufacturer's sequential allocation policies, and the security and privacy concerns therein.
Conference Paper
MAC address randomization is a common privacy protection measure deployed in major operating systems today. It is used to prevent user-tracking with probe requests that are transmitted during IEEE 802.11 network scans. We present an attack to defeat MAC address randomization through observation of the timings of the network scans with an off-the-shelf Wi-Fi interface. This attack relies on a signature based on inter-frame arrival times of probe requests, which is used to group together frames coming from the same device although they use distinct MAC addresses. We propose several distance metrics based on timing and use them together with an incremental learning algorithm in order to group frames. We show that these signatures are consistent over time and can be used as a pseudo-identifier to track devices. Our framework is able to correctly group frames using different MAC addresses but belonging to the same device in up to 75% of the cases. These results show that the timing of 802.11 probe frames can be abused to track individual devices and that address randomization alone is not always enough to protect users against tracking.
Conference Paper
We present several novel techniques to track (unassociated) mobile devices by abusing features of the Wi-Fi standard. This shows that using random MAC addresses, on its own, does not guarantee privacy. First, we show that information elements in probe requests can be used to fingerprint devices. We then combine these fingerprints with incremental sequence numbers, to create a tracking algorithm that does not rely on unique identifiers such as MAC addresses. Based on real-world datasets, we demonstrate that our algorithm can correctly track as much as 50% of devices for at least 20 minutes. We also show that commodity Wi-Fi devices use predictable scrambler seeds. These can be used to improve the performance of our tracking algorithm. Finally, we present two attacks that reveal the real MAC address of a device, even if MAC address randomization is used. In the first one, we create fake hotspots to induce clients to connect using their real MAC address. The second technique relies on the new 802.11u standard, commonly referred to as Hotspot 2.0, where we show that Linux and Windows send Access Network Query Protocol (ANQP) requests using their real MAC address.
Article
This work is about wireless communications technologies embedded in portable devices, namely Wi-Fi, Bluetooth and GSM. Focusing on Wi-Fi, we study the privacy issues and potential missuses that can affect the owners of wireless-enabled portable devices. Wi-Fi enable-devices periodically broadcast in plain-text their unique identifier along with other sensitive information. As a consequence, their owners are vulnerable to a range of privacy breaches such as the tracking of their movement and inference of private information (Cunche et al. in Pervasive Mobile Comput, 2013; Greenstein in Proceedings of the 11th USENIX workshop on hot topics in operating systems, pp 10:1–10:6. USENIX Association, Berkeley, 2007). As serious as those information leakage can be, linking a device with an individual and its real world identity is not a straightforward task. Focusing on this problem, we present a set of attacks that allow an attacker to link a Wi-Fi device to its owner identity. We present two methods that, given an individual of interest, allow identifying the MAC address of its Wi-Fi enabled portable device. Those methods do not require a physical access to the device and can be performed remotely, reducing the risks of being noticed. Finally we present scenarios in which the knowledge of an individual MAC address could be used for mischief.
Conference Paper
Smartphones with Wi-Fi enabled periodically transmit Wi-Fi messages, even when not associated to a network. In one 12-hour trial on a busy road (average daily traffic count 37,000 according to the state DOT), 7,000 unique devices were detected by a single road-side monitoring station, or about 1 device for every 5 vehicles. In this paper, we describe a system for passively tracking unmodified smartphones, based on such Wi-Fi detections. This system uses only common, off-the-shelf access point hardware to both collect and deliver detections. Thus, in addition to high detection rates, it potentially offers very low equipment and installation cost. However, the long range and sparse nature of our opportunistically collected Wi-Fi transmissions presents a significant localization challenge. We propose a trajectory estimation method based on Viterbi's algorithm which takes second-by-second detections of a moving device as input, and produces the most likely spatio-temporal path taken. In addition, we present several methods that prompt passing devices to send additional messages, increasing detection rates an use signal-strength for improved accuracy. Based on our experimental evaluation from one 9-month deployment and several single-day deployments, passive Wi-Fi tracking detects a large fraction of passing smartphones, and produces high-accuracy trajectory estimates.