The main Android detection here can probably be defeated using a tool like Pry-Fi on a rooted device,<p><a href="https://play.google.com/store/apps/details?id=eu.chainfire.pryfi&hl=en" rel="nofollow">https://play.google.com/store/apps/details?id=eu.chainfire.p...</a><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.<p>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.
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.<p>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.<p>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.
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.<p>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)?
This is very similar to our earlier work on the security of MAC address randomization: <a href="http://papers.mathyvanhoef.com/asiaccs2016.pdf" rel="nofollow">http://papers.mathyvanhoef.com/asiaccs2016.pdf</a> They provide some more practical details if you want to implement our probe request fingerprint tracking mechanism. This is a passive tracking technique.<p>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..<p>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 :) <a href="http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-address.html" rel="nofollow">http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-ad...</a>