Some limitations of wifi MAC address randomization

September 1, 2019

In a comment on my entry on an Android-based gadget with aggressive wifi MAC randomization, Jukka wrote:

The DHCP issues notwithstanding, I applaud this kind of MAC randomization. Easy to do manually, of course, but I haven't realized that also off-the-shelf products are doing it. Good for them: so-called WiFi tracking is nowadays rampant in public spaces. They're even combining this tracking with facial recognition and whatnot; cf. <link>

I sure hope that your university is not among these "smart offices"...

My university isn't (and hopefully never will be; I think a lot of people would object), but part of my reaction to Jukka's mention is that if it was, wifi MAC randomization wouldn't protect me because all of our wifi networks require authentication, generally through things like 802.1x. The university doesn't need to even try to track me indirectly by device MAC address when it can track me directly by authentication.

(There are no anonymous wifi networks at work, or at least there aren't supposed to be; it's a university policy that all wireless network access has to be identifiable and authenticated in some way.)

This points directly to the fundamental limitation of MAC randomization, which is that MAC randomization conceals your device's identity but not yours. Actively authenticated network access is one way to identify and track you, but it's far from the only one. For instance, a public wifi network with a captive portal could drop a cookie on you the first time you visit and then try to read it back out on later visits, so it could associate your current MAC with past ones (and such a cookie would be a first-party cookie, so not subject to many browser precautions). It could even sell this as a convenience; if you have your identifying cookie, it'll automatically authorize you since it has an acceptable indication that you've already agreed to the network's TOS.

(Various intrusive forms of traffic monitoring can be used to create some sort of fingerprint of your activity and your device's signature actions. Some of this will get harder when encrypted SNI rolls out, since then traffic monitoring will have to work harder to identify what HTTPS sites your device is checking in with.)

This doesn't make MAC randomization completely pointless on authenticated networks and other such environments; if nothing else, it potentially hides information on how many distinct devices you have (although that may be revealed if the devices have other identifying quirks, such as fixed DHCP 'host name' fields).


Comments on this page:

By Jukka at 2019-09-02 02:56:40:

University or other workplace networks are not the best example, of course. What is rampant is the kind of MAC-based tracking they're doing in shopping centers, public transport, and similar places that provide public WiFi. I think they're mostly targeting smartphones, so also Bluetooth-based tracking is often present.

In essence, I think the simple goal is often to build a huge database of identifiers, so that you know when a customer revisits your shop, caffeteria, or whatever. You can then correlate these identifiers to other information (including CCTV data, etc.).

By Jukka at 2019-09-02 08:21:03:

I did a little search, and indeed many Android devices do MAC randomization:

https://petsymposium.org/2017/papers/issue4/paper82-2017-4-source.pdf

While there seems to be many limitations, I am not sure whether these apply to custom randomization on Linux/Unix. After all: this kind of tracking is usually implemented based on 802.11 probes alone, i.e. without even necessarily attempting to provide a network connection as such.

Written on 01 September 2019.
« The sorts of email attachments that we get these days have become boring
Another way to do easy configuration for lots of Prometheus Blackbox checks »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 1 22:40:58 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.