Your MAC Address Randomization attempts are futile!

Patrick · July 7, 2016, 3:43pm

Originally published at: News - Whonix Forum
The following paper explains why.

Why MAC Address Randomization is not Enough:
An Analysis of Wi-Fi Network Discovery Mechanisms

The above interesting paper has been found by HulaHoop and added to Whonix MAC address documentation.

Patrick · July 7, 2016, 3:49pm

torjunkie · July 11, 2016, 5:18pm

Hi Patrick,

Yes - and your chats in the link below were interesting.

github.com/QubesOS/qubes-issues

MAC Randomization for iwlwifi

opened 05:24PM - 08 Mar 15 UTC

closed 04:12AM - 26 May 18 UTC

marmarek

T: enhancement help wanted C: other P: major release notes privacy

**Reported by andrewb on 6 Dec 2014 03:15 UTC** See https://groups.google.com/d/…msg/qubes-users/Yo73MZC4038/a5ONmKpLB5YJ -- qubes-users subject "MAC randomization experiments": On 07/17/14 13:51, Joanna Rutkowska wrote: > On 07/09/14 14:36, cprise wrote: > > > As a follow-up to the 'random MAC addresses (wifi)' thread, I was > > wondering if anyone has tried automating it on Qubes and if so, what > > some of your experiences are. > > > > I have started trying out different approaches, but it appears that the > > hooks/interfaces needed at this level are undergoing a great deal of > > flux, and the fact of having wifi live in a vm throws a wrinkle or two > > in there as well. > > > > My underlying rule is: Since bootup /and/ resume both reset the address > > to the hardware ID, randomization must be handled during those events to > > prevent the wifi interface from becoming active with and broadcasting > > the hardware ID. Handling the bootup part is easy; Suspend is a whole > > other story. > > The NICs I played with some years ago, specifically Intel AGN WiFi, used > to relay on the driver code to set the MAC address on device > initialization. The code looked more or less like this (quoting from > memory): > > my_nc_mac = read_eeprom (eeprom_address_mac); > set_hw_mac_address (my_nic_mac); > > This means the h/w itself doesn't know the MAC apriori (i.e it's not > burned into the chip), but expects the driver to tell it what the mac > should be. > > Patching the driver code above should be the most sure way to change the > mac address and ensure the NIC never ever use the original mac. > > joanna. Since iwlwifi devices are so popular with the business-class systems that seem to work well with Qubes, it makes sense to adopt this "surefire" MAC randomization strategy. Most people who want Qubes probably also want MAC randomization. Unless there's a more general solution, let's adopt this idea. How much effort would it take to maintain this patch for iwlwifi? Has someone else done it already? Migrated-From: https://wiki.qubes-os.org/ticket/938

Good to see some progress has been made on this issue via Bugzilla (June). There are so many weaknesses with wi-fi (see DefCon in any given year for example), that it is probably best not to use it at all.

Out of interest, I know Whonix hides the MAC addresses from the net VM in Qubes, but for fun I tried the Qubes spoofing instructions anyway.

The instructions below do not work for me (ethernet) when running Qubes-Whonix. It will always fail at 80% bootstrapping, despite presence of the service in the net VM, successful change of the MAC address when checked under ifconfig etc.

https://www.qubes-os.org/doc/anonymizing-your-mac-address/

I wonder if anybody else has had luck, or is it not meant to work at all while running Whonix concurrently. I know this is total overkill, but it is always fun to play around with