
A Study of MAC Address Randomization in Mobile Devices and When It Fails - oretoz
https://arxiv.org/abs/1703.02874v1
======
problems
The main Android detection here can probably be defeated using a tool like
Pry-Fi on a rooted device,

[https://play.google.com/store/apps/details?id=eu.chainfire.p...](https://play.google.com/store/apps/details?id=eu.chainfire.pryfi&hl=en)

You can also set specific MACs per-AP so it'll defeat probe-based attacks too
theoretically. This should get it by 4/5 attacks here.

Their RTS/CTS method in particular sounds like it'll be impossible to defeat
without Wifi chipset manufacturers simply removing their hardcoded MAC and
switching to letting the OS pick it - unless there's a possibility of
triggering that change via a driver already, might be time to start looking at
datasheets on wifi chips.

~~~
teacup50
At least for Broadcom (nee Cypress) WiFi chipsets used in a lot of these
devices, the canonical MAC used by hardware is encoded in one of three places:

\- Onboard SPROM: easily modified by a driver, but shouldn't be rewritten to
achieve randomized MACs; you'll blow through your flash write cycles.

\- Onboard OTP (one-time programmable memory): also easily modified, but it's
one-time writable; you can only set bits to 1, never 0.

\- External NVRAM / NVRAM image (e.g. supplied by the driver): totally
controlled by the driver/host OS, can be set to whatever you want.

Changing this behavior would require changing the firmware image uploaded to
the WiFi chipset by the driver.

~~~
problems
Ah, interesting, are these firmwares typically signed or is it something that
could be reverse engineered and modified by anyone?

~~~
teacup50
In theory you can supply your own firmware.

~~~
scintill76
Some Sony Android phones apparently use your third model, with Linux pushing
the firmware image to the wifi card. The MAC address is in that image, but not
baked in to the distributed file, so something has to fetch the unique MAC
from somewhere and write it in to be sent to the wifi chip. And the MAC seems
to be unprotected by signatures.

At least this is what I gathered from looking at CyanogenMod source awhile
back. mac-update[0] reads the MAC (multiple of them, apparently) from some
files on /data[1] (which I think are put there by a proprietary blob that got
them from a separate partition dedicated to storing provisioning data),
copying the firmware image from /system and writing the patched version to
/data (which path the kernel loads from to send into the wifi card.) As I
recall, changing my MAC address "permanently" was as easy as changing the MAC
file on /data, but I don't have the phone anymore.

[0] [https://github.com/CyanogenMod/android_device_sony_qcom-
comm...](https://github.com/CyanogenMod/android_device_sony_qcom-
common/blob/40c07439a871c94bfb386dc4435787f040ef8d17/mac-update/mac-update.c)
[1] [https://github.com/CyanogenMod/android_device_sony_qcom-
comm...](https://github.com/CyanogenMod/android_device_sony_qcom-
common/blob/40c07439a871c94bfb386dc4435787f040ef8d17/mac-update/mac-update.h)

------
AndyMcConachie
I get the idea from reading this paper that the authors don't have much
networking experience. Having lots of MAC addresses randomly changing in your
network is more than a potential headache. It can really cause stuff to break
and the authors don't even address that.

At the very least, I expected a discussion of arp for IPv4 and
ICMPv6/NDP/RA/SLAAC/DHCPv6 for IPv6. But beyond that, I really need to see
some discussion on the effect of randomization on L2 security mechanisms like
limiting MAC learning on ports. A smart thing to do if you're a network admin
concerned about security is to limit the number of MACs that can be learned on
a given port/vlan. So randomizing MACs on devices would cause some devices to
just drop connection occasionally. The authors don't address this.

It's almost like they don't even realize that MAC addresses are used for
things in networks besides invading people's privacy. There might be very good
reasons why manufacturers of mobiles do things the way they do them. However,
it doesn't look like the author's reached out vendors at all to ask.

~~~
hamsandwiched
You're missing a key point - MAC addresses don't randomize while connected to
a network, they only change while in a disassociated state. They need to use
their true, assigned MAC while associated to a network.

The authors aren't proposing the use of randomization while associated to a
network. Instead they're showing how current implementations aren't achieving
their intent.

~~~
AndyMcConachie
I missed that small but important tidbit in section 2.2, now I see it. But
then in section 4 they mention mDNS. Which confuses me, because L2 switches
will definitely learn MACs on mDNS traffic.

It also brings up another question I have which is what about roaming? And
what about setups where there are L2 switches between radios and the devices
that handle the 802.11 authentication? How does randomization affect learning
in those environments?

In general I would have appreciated more discussion on on how randomization
affects L2 switches and the protocols I mentioned. Either that, or ask someone
at Google why Android behaves the way it does.

------
Sidnicious
Side question: the last time I watched broadcasts coming out of my
unassociated iPhone, it was specifically asking for certain SSIDs. The set
seemed somewhat random (I've joined all of them, but not recently), and I
don't think any of them had ever been hidden networks.

Are these broadcasts viable for tracking (it seems like they would be)? Is
there anything I can do as a user to mitigate the effects (other than turning
off WiFi)?

~~~
driverdan
Delete APs when you're done using them if they're not ones you'll regularly
access. This is especially important for open, unencrypted WiFi since a
malicious AP could claim to be that ID.

The only way to prevent this behavior entirely is to shut off WiFi.

~~~
Sidnicious
iOS doesn't have UI to delete networks unless they're currently in range
(except a big "Reset Network Settings" button). The only workaround I know of
is to sync your networks with iCloud Keychain and use a computer to delete
them.

------
gipsies
This is very similar to our earlier work on the security of MAC address
randomization:
[http://papers.mathyvanhoef.com/asiaccs2016.pdf](http://papers.mathyvanhoef.com/asiaccs2016.pdf)
They provide some more practical details if you want to implement our probe
request fingerprint tracking mechanism. This is a passive tracking technique.

Their method to track all devices requires actively sending packets for every
single MAC address that is being tracked. The (imperfect) passive tracking
techniques can be used to reduce the number of MAC addresses you have to try
though. Nice finding overall! And it will likely be hard to patch this issue..

Sometimes there are also silly driver bugs that allow you to get the real MAC
address of a device when the user is using a spoofed MAC address :)
[http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-
ad...](http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-address.html)

------
mangix
They didn't mention of they used windows or Linux when testing the USB device
as. I would expect different results.

