The mobile computing is on a steep rise for over a decade now and so is the always-on networking. You probably have a networked phone in your pocket now, carry a laptop and maybe a tablet computer, all connected to the Internet.

With the availability of the wireless networks, mobile networking is easier than ever. What’s also easier than ever is violating one’s privacy. Even when you’re super careful about encrypting your Internet traffic, the meta-data can leak enough information to make you worried.

What’s also easier than ever is violating one’s privacy.

IEEE, the standard body behind the Wi-Fi specification, set up a study group to cope with the problem and the industry starts coping with the problem as well. Let’s have a more detailed look!

Your identity in a Wi-Fi network

In wired (Ethernet) networks, each network node (computer) is identified by a unique number, a MAC address, that’s assigned by the manufacturer of the network hardware.

If multiple machines on the same network used the same number, it wouldn’t be possible for others on the network to tell one from another, which would result in no end of mayhem.

The phone in your pocket probably broadcasts its MAC address everywhere you go.

The Wi-Fi networks use a similar mechanism. When joined to a network, an unique MAC address identifies a node to avoid addressing clashes. There’s one very important difference from the wired networks: wireless hardware communicates even when not joined to a network. It looks for access points to connect to and also uses this MAC address to identify itself. Thus, the phone in your pocket probably broadcasts its MAC address everywhere you go. You get the up-to-date list of access points and the access points get your MAC address. It’s a fair deal to some, but possibly a great concern for the privacy-savvy.

How to anonymize you?

An obvious solution would be to randomize the address. There are several problems to consider. The MAC address identifies your hardware to the access point. If you change it while you’re associated the access point no longer knows who you are. You lose connectivity. Also, the MAC address is often used (or abused) for media-layer filtering. Some access points hijack your traffic until you authorize yourself in a captive portal. Change your MAC address and you’re unknown and unauthorized again. And there’s the uniqueness problem. If you generated the MAC address, there’s no way to ensure someone else isn’t using it.

What seems like a viable option is randomizing the MAC address while scanning, changing it every now and then, but still use the hard-wired MAC address for association and actual connectivity. Apple pioneered this approach with its mobile operating system, iOS version 8. Since the worst thing that can happen in an unlikely event of MAC address clash is that your AP list is incomplete for a while it seems like a fairly safe choice.

Apple pioneered MAC address randomization for scanning with iOS 8. With the upcoming NetworkManager 1.2 we’re doing this too.

This approach is tested on vast amount of devices now too. With the upcoming NetworkManager 1.2 (when using wpa_supplicant 2.3 2.4 or newer) we’re doing this too.

What’s next

Could we randomize the permanent address too? We added option for that to NetworkManager 1.2 too, but are leaving it off. The chance of causing havoc and confusion with the ever-present mac filters on access point is way too big. Nevertheless, if you believe the risks are a good price for the tracking protection you can turn it on.

It seems that there’s still room for improvement. Perhaps the MAC address could be both random and stable. This approach was used for the IPv6 addressing as defined by RFC7217 and implemented in NetworkManager 1.2. Outside the Linux landscape, Windows 10 offers this functionality.

Perhaps the MAC address could be both random and stable.

If it turns out to work well in real world use, the inclusion in the next version of NetworkManager is likely. Stay tuned!

Update 2016/08/30: With NetworkManager 1.4 the MAC spoofing is more versatile. Check out Thomas’ article!

Thanks to Michael Biebl for pointing out the correct version of needed wpa_supplicant.