[Cryptography] Insufficient MAC randomization

[Christian Huitema]

On 2/12/2018 9:22 AM, Ryan Carboni wrote:

> MAC randomization for only probe requests in insufficient. MAC
> addresses used for wireless communication should be the product of a
> hash of the SSID and some secret value.
> There is the risk that there is a collision of MAC addresses, but most
> networks don't handle that many devices, and wifi MAC addresses in use
> could be detected.

MAC Randomization has been available in Windows 10 since December 2015.
It is not limited to probe requests, but there are lots of practical
issues that needs to be dealt with, such as not paying multiple times
for Wi-Fi in an hotel room, or playing nice with corporate Wi-Fi (see:
https://huitema.wordpress.com/2015/12/31/mac-address-randomization-in-windows-10/).
There is also an implementation in Linux, although I don't know the details.

>
> Although I wonder if that even matters.
> https://en.wikipedia.org/wiki/Radio_fingerprinting

Maybe. But I don't know whether the average hacker or advertiser can
afford the required equipment, and deploy it at all locations that needs
surveillance. State agencies probably can do that in a targeted manner.

In any case, just randomizing the MAC address is not enough -- see
https://papers.mathyvanhoef.com/asiaccs2016.pdf for a list of issues in
the Wi-Fi stack that also need to be patched, and
https://securityaffairs.co/wordpress/57076/uncategorized/mac-address-randomization-flaws.html
for another set of such issues. AFAIK, the various stacks are patching
these bugs, but YMMV.

And then, there is also the case of MAC-like identifiers used in DHCP --
see RFC 7819 (https://datatracker.ietf.org/doc/rfc7819/) for a list of
issues, and RFC 7844 (https://datatracker.ietf.org/doc/rfc7844/) for
DHCP anonymous mode. This was implemented in Windows 10, and should also
be implemented in Linux by now.

-- Christian Huitema