[STDS-802-Privacy] Guidelines proposition for correct implementation of MAC address randomization
Hello all,
I'm about to finish my PhD on Wi-Fi tracking [1]. In this thesis, I
studied various methods that can render MAC address randomization
insufficient to prevent tracking. I've been supervised by Mathieu
Cunche, who already made several talks on the topic here.
Based on our observations, we produced a series of guidelines regarding
a correct implementation of MAC address randomization. I would like to
share these guidelines to this list, as they could be used as a draft
for a recommendation to the industry.
The guidelines are the following:
1. The MAC address must be changed in every burst of probe requests.
2. Probe requests must be devoid of unnecessary Information Elements.
3. In particular, SSIDs must always be null (see below for the hidden AP
case).
4. Sequence numbers must be randomized at the beginning of every burst
of probe request, or maintain a fixed value (0).
5. The function generating the random addresses must be of cryptographic
level so as to guarantee unlinkability between frames, as its purpose is
to protect privacy-sensitive information. It must have a reliable
entropy source, as MAC address changes can be very frequent.
6. It must be ensured that the global address is never used for active
scanning.
7. The OUI part of the MAC address should preferably be randomized as
well. To do so, randomized OUI should have their LA bit set to 1 and
should not be registered by a company.
8. Efforts must be done to break timing patterns of probe requests: for
instance, random delay can be added between bursts.
Additionally, we advise dropping the support of hidden Access Points.
They hinder a correct implementation of randomization, as devices need
to add identifying SSIDs to their probe requests to discover them. They
constitute a bad security practice anyway, as they're based on the
broken security-by-obscurity concept. They should be replaced with
Access Points using a strong encryption scheme and strong passwords.
These guidelines can be compared to those produced by Martin et al. [2],
which notably also add a countermeasure against an active attack they
discuss in their paper.
[1]: https://ploudseeker.com/files/these.pdf
[2]: https://arxiv.org/abs/1703.02874v1
Regards,
--
Célestin Matte