Re: Beyond MAC randomization (prevent tracking)



On Tue, 2017-04-11 at 11:30 -0400, Chris Laprise wrote:
On 04/10/2017 01:35 PM, Chris Laprise wrote:


Hi Chris,


1. A Study of MAC Address Randomization in Mobile Devices and
When it Fails
https://arxiv.org/pdf/1703.02874v1.pdf



A listing of best practices from the paper:

Randomize across the entire address, providing
2^46 bits of randomization.

This can be configured via the wifi.scan-generate-mac-address-mask
setting (man NetworkManager.conf). Likewise, there are the per-
connection settings wifi.generate-mac-address-mask and
ethernet.generate-mac-address-mask.
Note, that you can at most randomize 47 bits (to create a unicast MAC
address, see man nm-settings).
By default the local-address bit is set too, leaving you with mentioned
46 bits. The generate-mac-address-mask setting allows you to explicitly
configure which bits are set and/or randomized.



Use a random address for every probe request
frame.


Remove sequence numbers from probe requests.

If sequence numbers are used, reset sequence
number when transmitting authentication and
association frames.

All that NM's randomization does, is to configure a MAC address before
issuing the scanning (or before associating). In the logfile you can
grep for "set-hw-addr:".

It does not sync with supplicant beyond that. This needs investigation
what is needed there.


Never send probe requests using a global MAC
address.

NM should set a random MAC address before requesting the first scan.
So, the permanet MAC address shouldn't leave the device.
(would need testing + verification).


Enforce a policy requiring a minimal and stan-
dard set of vendor IEs. Move any lost function-
ality to the authentication/association process,
or upon network establishment utilize discovery
protocols.

Specifically, the use of WPS attributes should
be removed except when performing P2P opera-
tions. Prohibit unique vendor tags such as those
introduced by Apple iOS 10.

Eliminate the use of directed probe requests for
cellular offloading.

Mandate that chipset firmware remove behavior
where RTS frames received while in State 1 elicit
a CTS response.

this also seems to affect more the lower layers + supplicant.
Needs investigation.


Seems like NM and careful configuration might address some of theseĀ 
points...


(BTW, the usna.edu address appears to be disabled.)


I agree, it would be a worthy task to investigate and fix issues.
Thanks for bringing up this topic.


Thomas

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]