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.
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.
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.
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.
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.
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.
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)?
>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.
IOS, like the linux's NetworkManager (and probably whatever android, didn't check), just assume that the AP could be hidden and try to connect to it anyway. Those people, that did something as stupid as that(for "user convenience"), later implemented MAC randomization in their network managers. Windows has a checkbox for 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)?
Yes. No. MAC address randomization helps somewhat, as per glancing at pdf.
All in all just fire up airodump-ng and see for yourself.
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.
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.
This is very similar to our earlier work on the security of MAC address randomization: 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..
https://play.google.com/store/apps/details?id=eu.chainfire.p...
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.