Source-linked AI summary
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, Dane Brown
TL;DR
Mobile MAC randomization is intended to prevent WiFi observers from linking a device’s traffic over time, but adoption and implementation vary across devices. The paper studies deployed schemes in the wild, analyzes their weaknesses, and finds that existing randomization can be defeated through address misuse, passive identification, and a chipset control-frame flaw.
Problem
The paper addresses limited evidence about real-world MAC randomization adoption and whether deployed schemes actually prevent tracking.
Method
The authors decompose large wireless-traffic collections, characterize schemes across operating systems, manufacturers, and models, and develop passive, active, and control-frame attacks.
Results
The study identifies widespread implementation flaws, improves derandomization techniques, and presents a control-frame attack targeting devices across operating systems, manufacturers, device types, and randomization schemes.
Takeaways & Limitations
MAC randomization policies are neither universally implemented nor effective at eliminating privacy concerns, and diverse vendor schemes can make devices easier to identify and track.
Takeaways & Limitations
The Karma attack requires directed probes for hidden or previously used ad hoc networks, conditions that are uncommon and user-dependent.
Abstract
from arXiv · showhide
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 show a method that can be used to track 100% of devices using randomization, regardless of manufacturer, by exploiting a previously unknown flaw in the way existing wireless chipsets handle low-level control frames.
1 Introduction
The paper evaluates how mobile devices implement MAC address randomization and identifies weaknesses that enable device tracking despite the intended privacy protection.
- MAC addresses expose nearby smartphones and their traffic because every WiFi frame includes a globally unique device identifier.Probe requests are especially trackable because they broadcast continuously at a semi-constant rate.
- The study provides the first manufacturer- and device-level breakdown of MAC randomization techniques and adoption rates using real-world datasets.It examines how addresses are generated and when devices use randomized rather than global addresses.
- The analysis develops techniques to identify and isolate randomization schemes from large wireless-traffic collections.These techniques support granular decomposition of real-world randomization and improvements to passive and active derandomization methods.
- The paper finds significant flaws in most Android randomization implementations that allow trivial retrieval of global MAC addresses.The authors also build on prior fingerprinting methods and introduce new deanonymization approaches based on observed wireless-traffic weaknesses.
- A control-frame attack exposes the global MAC address for all known devices regardless of OS, manufacturer, device type, or randomization scheme.Android devices may remain susceptible even when WiFi is disabled or Airplane Mode is enabled.
2 Background
WiFi MAC addresses are persistent identifiers that can expose device manufacturers and enable tracking. Randomized locally assigned addresses provide anonymity mainly while devices are disassociated, but devices revert to global addresses when associating.
- 2.1 MAC Addresses: Every 802.11 interface has a 48-bit MAC address designed to be persistent and globally unique.IEEE-assigned organizational blocks make manufacturer identification possible from the address.
- 2.1 MAC Addresses: Listeners can determine a nearby device’s manufacturer from its MAC address, while major manufacturers do not use IEEE private OUIs.Private OUIs omit company names from the registration record.
- 2.1 MAC Addresses: Locally assigned addresses use the Universal/Local bit and support contexts including tethered hotspots, peer-to-peer services, and randomized MAC addresses.A three-byte Company Identifier prefix, such as Google’s DA:A1:19, is suited to randomized address schemes.
- 2.2 MAC Randomization: Devices commonly use locally assigned addresses while disassociated but revert to globally unique addresses when connecting to an access point.This makes tracking trivial in the associated state, although that state is generally more stationary and can support features such as MAC filtering.
- 2.2 MAC Randomization: Android and iOS use random locally assigned MAC addresses for active scans while disassociated, providing anonymity until association.The software hooks supporting randomization differ between operating systems.
3 Related Work
Prior work showed that probe-request metadata and WPS identifiers can defeat MAC randomization, but its evaluation did not establish practical scope on randomized devices. This paper reevaluates those attacks and identifies additional limitations in fingerprint-based methods.
- WPS-based tracking: UUID-E reversal recovers a device’s global MAC address because the UUID-E is derived from that address and remains unchanged under randomization.Attackers can use precomputed hash tables to map UUID-E values back to global MAC addresses.
- Limits of prior evaluation: The earlier UUID-E evaluation used a 2013 anonymized dataset lacking randomized MAC implementations and ground truth validation.The recovered address could not be confirmed as the WiFi MAC rather than the Bluetooth MAC.
- Reevaluation of prior attacks: 99.9% effectiveness was achieved against vulnerable devices by improving Matte et al.’s technique, while confirming that recovered addresses were WiFi identifiers.The paper’s real-world assessment found that only a small portion of Android devices were vulnerable.
- Fingerprinting limitations: Probe-request Information Element fingerprints can support device tracking, but prior evaluations ignored locally assigned MAC addresses used by nearly all randomization schemes.The paper observes that probe-request signatures can change during randomization and even when the device is not randomizing.
- Active attacks: Karma attacks can force devices into an associated state, where MAC randomization stops and the global MAC address is revealed.A rogue access point uses a matching SSID to trigger automatic connection behavior.
4 Methodology
The study passively analyzes large-scale WiFi traffic to identify randomized devices, classify their behaviors, and evaluate implementation flaws. It combines packet-level features, device fingerprints, manual inspection, and controlled validation while excluding intentional user traffic.
- Data collection: Over approximately two years, the researchers captured unencrypted 802.11 traffic with inexpensive commodity hardware and open-source software.The collection used an LG Nexus 5, an Alfa wireless card, and Raspberry Pi monitors across 2.4GHz channels 1, 6, and 11.
- Data collection: The passive dataset contains management frames and unencrypted mDNS packets, not intentional user traffic such as web browsing or email.No data was decrypted, and no active actions were used outside the laboratory environment.
- Randomization identification: Android devices vary substantially by manufacturer, unlike iOS devices, which were grouped into a common randomization behavior bin.The study therefore evaluates randomization policies across operating systems, manufacturers, and models.
- Corpus characterization: The corpus contained approximately 66 million probe requests and 2.6 million unique source MAC addresses, including 1.4 million locally assigned addresses.Locally assigned addresses were separated into randomization, P2P, and infrastructure-related categories.
- Randomization identification: WiFi-Direct, Nintendo P2P, and wireless extenders were removed from the randomization analysis using service-specific identifiers and manual packet inspection.Extender validation found that addresses never changed, each device probed only one SSID, and WPS attributes identified extender models.
- Corpus characterization: 99.12% of locally assigned MAC addresses were classified as randomized, representing approximately 53% of the corpus, but address counts do not equal device counts.A single randomizing device can generate tens of thousands of addresses over the collection period.
- Randomization identification: Devices were classified into behavioral bins using MAC prefixes, WPS attributes, 802.11 Information Element signatures, and mDNS fingerprints.The analysis was validated with devices procured by the team in a controlled RF environment.
5 Analysis
The analysis finds substantial variation in Android and iOS randomization schemes, with device fingerprints and protocol details enabling classification or attacks. It also identifies implementation choices that undermine privacy, including globally valid randomized addresses and persistent iOS vendor information.
- Android randomization: 52,595 observations used Google’s DA:A1:19 prefix, while 8,691 used the unallocated 92:68:C3 prefix.The latter was purposefully configured by Motorola to replace Google’s prefix.
- Android randomization: Only 3,188 devices across 44 models were susceptible to UUID-E reversal, leaving ∼99.98% of locally assigned addresses outside that attack.The vulnerable devices included 2,341 Google-CID devices with WPS attributes and 849 Motorola Nexus 6 devices.
- Android randomization: 57.7% of 43,924 Google-CID addresses without WPS data fell into a bin represented by the LG Nexus 5X and Google Pixel.The authors caution that this is not an exhaustive list of devices matching those signatures.
- Android randomization: Android signatures varied across bins: LG devices comprised 18.5%, OnePlus 3 and Xiaomi Mi Note Pro 2%, and Huawei and Sony devices less than 1%.A further bin combined devices whose signatures sometimes included full and sometimes stripped-down 802.11 information elements.
- Android randomization: Motorola devices sometimes randomized with Motorola-owned globally valid OUIs, potentially allowing one device to temporarily use another device’s true global address.This behavior violates the expectation that global MAC addresses are not reused as random addresses.
- Android randomization: Samsung devices showed no observed MAC randomization and represented ∼23% of Android devices in the dataset, contributing substantially to low adoption.The authors suggest chipset compatibility issues as a possible explanation.
- iOS randomization: iOS randomized across the full MAC address except the local and multicast bits, with tests of 47,255 addresses supporting uniform distribution.The scheme complicates device identification because generated addresses do not share a common prefix.
- iOS randomization: iOS 10 added a constant Apple vendor-specific information element to every probe request, making device identification trivial regardless of randomization.The associated data field never changed across devices.
6 MAC Randomization Flaws
The study finds that deployed MAC randomization is frequently absent or flawed, allowing devices to be linked to their global addresses through passive fingerprints, directed probes, and low-level control frames.
- Adoption: Most Android devices do not implement the randomization capabilities available in Android, leaving them directly targetable without attacker effort.The authors suggest chipset and firmware incompatibilities may partly explain this, but note that devices sharing chipsets can differ in adoption.
- Global-address leakage: Android devices commonly transmit global-MAC probe requests alongside randomized requests, allowing sequence numbers and device signatures to link pseudonyms to the true address.The authors describe this behavior as negating the privacy benefits of randomization; Cat S60 was the only tested exception, apart from immediately before association.
- Passive derandomization: 29% of random Android MAC addresses include WPS attributes, leaving 71% of the Android dataset immune to the UUID-E reversal attack; iOS devices are wholly immune because they do not use WPS.For addresses with UUID-E data, the attack retrieved 3,187 of 3,188 global MAC addresses, and comparison with 1,417 ground-truth addresses achieved a 100% success rate.
- Karma attack: Directed probes remain uncommon, but hidden networks, saved ad hoc networks, and especially preconfigured cellular-to-WiFi offloading settings can make Karma-based attacks viable.Only ∼5% of the 3,188-device datasets transmitted a directed probe, and 17% of those were caused by preconfigured mobile-provider settings.
- Control-frame attack: RTS/CTS control frames expose the global MAC address across tested devices because the response behavior appears rooted in chipset hardware rather than the operating system.Only RTS among twelve Class 1 frame types elicited a response; a crafted RTS produced a CTS response confirming the target’s global address, including during tested WiFi or Airplane-mode conditions.
7 Conclusions
The paper finds that MAC randomization policies are diverse, inconsistently adopted, and vulnerable to attacks across devices. It proposes universal policies and concrete rules to improve protection.
- Detailed breakdowns of randomization policies and device models enabled improved prior derandomization methods and novel attacks.
- Randomization policies are neither universally implemented nor effective at eliminating privacy concerns, with the RTS control frame attack exploiting a widespread chipset vulnerability.
- Universal adoption is necessary because non-randomizing devices are easier to identify, while diverse schemes can make devices easier to track.
- The proposed universal policy should standardize randomized MAC structure, information-element usage, and sequence-number behavior across 802.11 client devices.
- Best practices include 246 bits of randomization, a new address for every probe, and removing or resetting sequence numbers during authentication and association.
- Recommended safeguards also prohibit global addresses, unnecessary vendor information, directed probes, and CTS responses to RTS frames in State 1.
A.1 Android
Android and related client configurations expose multiple address-policy options, but implementation support does not guarantee actual randomization. Device behavior varies with configuration, firmware, and chipset compatibility.
- The configuration supports permanent, per-network, or randomized addresses for associated devices, plus analogous policies for pre-association scanning.
- The default policy uses the permanent MAC address unless changed through the per-network mac_addr parameter.
- Android added probe-request randomization in Android 6.0, with an incremental patch for Android 5.0.
- Android can assign a manufacturer-configurable prefix, such as the default Google CID, when chipset support is compatible.
- Randomization functions appeared in Java files regardless of device behavior, while configuration-file changes had no effect on tested devices.
A.2 iOS
Apple introduced MAC address randomization in iOS 8.0 and continued updating its policy. Unlike Android, iOS does not allow device-model customization, and iOS 10.x randomizes only while disassociated.
- iOS introduced MAC address randomization with iOS 8.0 and made minor policy updates in later releases.
- iOS randomization settings are not customizable by device model, unlike Android settings such as the CID.
- As of iOS 10.x, Apple devices use locally assigned MAC addresses only while disassociated.
B iOS Randomization Tests
The iOS prefix observations were tested against statistical expectations and FIPS 140-1 random-number tests. All reported tests fell within allowable ranges, indicating uniformly distributed MAC addresses.
- The analysis compares observed prefix collisions and runs with expectations for an ideal random distribution.
- Collisions were 262 observed versus 266 expected, while triple collisions were 3 observed versus 1 expected.
- The study decomposed successive MAC-address bytes into a bit stream and applied FIPS 140-1 tests for random-number generators.
- The longest run test result was 12.
- All tests passed within allowable ranges, indicating that the MAC addresses were distributed uniformly.
C Google CID Device Breakdown
This section presents a model breakdown for DA:A1:19 with WPS.
- Table 8 provides the DA:A1:19 model breakdown with WPS.
- The breakdown is organized around the WPS condition.
- The section concerns device-model-level analysis.
D RTS Control Frame Attack - Device Diversity
This section presents device diversity for the RTS control frame attack.
- Table 9 reports device diversity for the RTS control frame attack.
- The analysis focuses on RTS control frames.
- The section compares the attack across devices.