Analysis To protect mobile devices from being tracked as they move through Wi-Fi-rich environments, there's a technique known as MAC address randomization. This replaces the number that uniquely identifies a device's wireless hardware with randomly generated values.
In theory, this prevents scumbags from tracking devices from network to network, and by extension the individuals using them, because the devices in question call out to these nearby networks using different hardware identifiers.
It's a real issue because stores can buy Wi-Fi equipment that logs smartphones' MAC addresses, so that shoppers are recognized by their handheld when they next walk in, or walk into affiliate shop with the same creepy system present. This could be used to alert assistants, or to follow people from department to department, store to store, and then sell that data to marketers and ad companies.
Public wireless hotspots can do the same. Transport for London in the UK, for instance, used these techniques to study Tube passengers.
Regularly changing a device's MAC address is supposed to defeat this tracking.
But it turns out to be completely worthless, due to a combination of implementation flaws and vulnerabilities. That and the fact that MAC address randomization is not enabled on the majority of Android phones.
In a paper published on Wednesday, US Naval Academy researchers report that they were able to "track 100 per cent of devices using randomization, regardless of manufacturer, by exploiting a previously unknown flaw in the way existing wireless chipsets handle low-level control frames."
Beyond this one vulnerability, an active RTS (Request to Send) attack, the researchers also identify several alternative deanonymization techniques that work against certain types of devices.
Cellular radio hardware has its own set of security and privacy issues; these are not considered in the Naval Academy study, which focuses on Android and iOS devices.
Hardware makers can register with the Institute of Electrical and Electronics Engineers (IEEE) to buy a block of MAC addresses for their networking products: the manufacturer is assigned a three-byte Organizationally Unique Identifier, or OUI, with is combined with an additional three-byte identifier that can be set to any value. Put those six bytes together, and you've got a 48-bit MAC address that should be globally unique for each device.
The IEEE's registration system makes it easy to identify the maker of a particular piece of network hardware. The IEEE also provides the ability to purchase a private OUI that's not associated with a company name, but according to the researchers "this additional privacy feature is not currently used by any major manufacturers that we are aware of."
Alternatively, the IEEE offers a Company Identifier, or CID, which is another three-byte prefix that can be combined with three additional bytes to form 48-bit MAC addresses. CID addresses can be used in situations where global uniqueness is not required. These CID numbers tend to be used for MAC address randomization and are usually transmitted when a device unassociated with a specific access point broadcasts 802.11 probe requests, the paper explains.
The researchers focused on devices unassociated with a network access point – as might happen when walking down the street through various Wi-Fi networks – rather than those associated and authenticated with a specific access point, where the privacy concerns differ and unique global MAC addresses come into play.
Previous security research has shown that flaws in the Wi-Fi Protected Setup (WPS) protocol can be used to reverse engineer a device's globally unique MAC address through a technique called Universally Unique IDentifier-Enrollee (UUID-E) reversal. The US Naval Academy study builds upon that work by focusing on randomized MAC address implementations.
The researchers found that "the overwhelming majority of Android devices are not implementing the available randomization capabilities built into the Android OS," which makes such Android devices trivial to track. It's not clear why this is the case, but the researchers speculate that 802.11 chipset and firmware incompatibilities might be part of it.