Wi-Fi MAC Randomization - Privacy and Collateral Damage

As data analytics have evolved from snowball to avalanche, data privacy initiatives have been standing in the gap between individuals and the companies that wish to harness their data. As we know, Apple has been a strong privacy advocate all along (their marketing teams will tell you again and again), but in iOS 14, they almost took it to a whole new level.

Mac Randomization

As many of you know, MAC addresses are “burned in” identifiers of radio chips that give them what is supposed to be a unique worldwide address. The chip uses the MAC address for network communications, which, in wireless, are sent over the air for all to see. Because of that uniqueness, the MAC address historically represented the chip itself, the device with the installed chip, and the user that carries it around. Thus, MAC addresses are a bit of a battleground for personal data privacy.

For several years now, iOS and Android have supported MAC randomization, which is a way to dynamically change the MAC address used for over-the-air communications. In previous versions, the MAC address was only randomized during the device’s discovery process, which is how devices scan to learn about nearby networks. This prevented most types of device/user tracking of passerby (or disconnected) users. But once a device connects to a network, the device would only and always use the “real” MAC address.

What's New?

The reason for this article is that Apple created quite an industry scare in its first few beta releases of iOS 14. Even though the final iOS 14 release has less aggressive randomization behavior than betas, the world of MAC randomization is changing, and network operators are wise to follow it.

In iOS 14, Apple adds MAC randomization for all Wi-Fi connections, not just for scanning. For each unique SSID (wireless network), the device will choose a new randomized address and use that private address for the network (during beta-testing, this address was also randomized every 24 hours). The private addressing feature is enabled by default, but it can be disabled by the user or via network profiles pushed by administrators.

Figure 1: iOS 14 private MAC address

It’s entirely possible that Apple legitimately planned to release an aggressive randomization algorithm, and they were talked off the ledge by the industry. However, I think it’s more likely that they played the role of change agent in a way that only Apple can. By teasing out the aggressive behavior, they got everyone’s attention, and their goal was to influence the industry to embrace operational paradigms that don’t depend so heavily on MAC addresses. But, this change will take time for network operators.

Despite the fact that Apple rocked the boat in their beta, Android has had MAC randomization behavior for connected sessions since Android 10.0. Android defaults to a randomized MAC, which can be disabled, as shown below.

In addition to OS manufacturers, the IEEE 802.11aq working group has also incorporated enhancements for MAC privacy. 802.11aq notes that MAC addresses, OFDM data scramblers, sequence numbers, probe request data, and other attributes can all be used to uniquely identify devices. There are ways to address this within the protocol, and there is a broader industry effort to improve individual privacy.

Just so you know, it’s that second hex value in the MAC address that indicates a private (software-generated) address. Any address matching one of the following patterns is considered private:

• x2:xx:xx:xx:xx:xx
• x6:xx:xx:xx:xx:xx
• xA:xx:xx:xx:xx:xx
• xE:xx:xx:xx:xx:xx

Security analytics platforms like Extreme AirDefense should also be able to identify whether devices are using private addresses.

So, what's the big deal?

To be honest, for now, there isn’t one. Crisis averted.

However, the iOS 14 beta triggered a bit of panic in some industries as everyone struggled to assess the collateral damage. I say “collateral” because Apple is focused on privacy, and they will continue prioritizing it in the future. The whole point of MAC randomization is to obscure some aspects of presence tracking that identify patterns in behavior, especially across different networks and venues that could indicate user activity.

As privacy initiatives push forward (and they will), there may also be side effects in user experience and operator workflows. Keep in mind that MAC addresses have always been a predictable long-term device identifier, which means that network ecosystem tools, processes, and connection paradigms are often built around MAC addresses.

So here’s the important point. MAC addresses of the future may not behave the same as MAC addresses today (or yesterday). Your homework is to evaluate all of your network's common workflows that rely on a steady and stable MAC address. Then rethink whether they will work if the MAC address is different, or if the MAC changes regularly (e.g. every 24 hours). Start retooling now so that you are not caught off guard later. Here are some operational areas to get you started.

Captive Web Portals

Captive portals are web pages presented to users during initial network connection, typically for guest networks. They’re used to deliver legal terms and agreements, for guest/visitor login, to capture some guest info in exchange for connectivity, and for authentication/billing purposes, such as usage-based hotspots.

In many cases, captive web portals use the MAC address as the device anchor, and so the user’s authorization state is connected to the MAC. If the MAC ever changes, the infrastructure will force the user through the portal again, creating a user-experience challenge.

It’s hard to give specific guidance for evolving portal workflows because they’re used in so many varied ways. One consideration would be to look at alternate authentication schemes that are not keyed by MAC, such as an 802.1X certificate workflow (I know, certs are scary), Extreme’s private PSK, or Hotspot 2.0.

MAC Authentication

Although MAC addresses have always been vulnerable to over-the-air eavesdropping and spoofing (copying by an attacker), some systems use MAC addresses for device authentication. In security-sensitive contexts, this practice is highly uncommon and not recommended, but it does still happen. In some corporate environments, IT uses a combination of 802.1X user authentication and MAC authentication to provide two-factor authentication of IT-owned devices. In this case, the MAC randomization problems can be avoided because IT can push a profile to devices that disables the randomization feature during onboarding. It’s just one more box to check in the profile installation (once your MDM or other provisioning tool supports the private MAC toggle). Also, consider the impact of a per-SSID randomized MAC if corporate IT devices connect to more than one SSID.

In some public access networks with usage subscriptions (monthly, yearly, metered), usage plans may be device-specific, where the MAC is used in an accounting workflow to track user data consumption. Those workflows may need a new approach to associate accounts to devices if the user has private addressing enabled (or if the private MAC ever changes for the SSID). In most cases, these operators will adjust to alternate forms of authentication (potentially in a Hotspot 2.0 workflow) whether usernames and passwords, certificates, apps, profiles on devices, or SIMs. Of course, they can combat this the manual way by showing users how to disable the feature and stick with the non-private address.

Device Analytics

Now we’re finally getting to the topic of interest for Apple. In reality, the iOS 14 behavior didn’t change the analytics story very much, but there are some points to keep in mind:

• If private MAC addresses change, then the new MAC address will be considered a new unique device, which can sway device/user counts.
• Private addresses will not map to OUI databases. OUI is a trivial mechanism to map a MAC to a device manufacturer, but private addresses will obscure even that basic mechanism.
• It is increasingly becoming impossible to make a connection between a scanning device and a connected device, for example, to identify specific visitors with “engaged” visitors. But arguably, this engagement tracking use case was more slideware anyways.
• Since the MAC stays the same for a given SSID, it’s still possible to measure repeat versus new guests, and ultimately tie a user’s activity over time to a specific session.

Most other presence analytics remain unchanged, like occupancy measurements, user density, location flow data—and of course, any time we can map a specific user to a random MAC, we may gain more.

Thinking ahead to MAC randomization that rotates daily or weekly, one course of action is for venue operators to focus on driving user adoption of apps—of course, this is the holy grail of engagement. To engage users, track user repeats, or extract information, operators may have to sweeten the pot with on-device apps that add more value for the user, which simply raises the cost of entry for a business case.

MAC Registration

For some environments where operators want users to register their devices, MAC addresses are often used as a simple form of access gatekeeping. For example, in university environments, students in dorms may be expected to register devices (printers, gaming consoles, TVs, IoT wares) that do not support 802.1X security. Further, in university and other multi-dwelling unit contexts, a MAC registration database can be used for private network security that allows users to access their own devices (similar to home networks), while being blocked from seeing others’ devices. The main challenge for today is to make sure that the registration happens with the private MAC tied to the operational SSID. This is very important to the workflow because the onboarding SSID may not match the operational SSID, so the private MAC may be different for these sites. Another useful option here is to provide unique authentication credentials, such as private PSKs. Private Pre-Shared Keys (PPSKs) provide identity visibility via unique per-device or per-user PSKs that can be grouped together as part of user policy.

For now, this may not be a common problem since mobile devices are the primary randomization target, and they do support flexible authentication mechanisms.

MAC Denial Lists

There are also workflows in Wi-Fi where systems automatically apply (or admins do it manually) an access denial rule to users who have behaved maliciously, violated a usage policy, or have repeatedly failed authentication. In reality, these blacklists don’t stop determined attackers or violators. Still, they are security-lite tools in the network admin’s toolbox that may no longer be effective for violators using platforms with randomization behaviors.

Troubleshooting

In connectivity troubleshooting workflows, the MAC address may be the only identifier for IT to get started in troubleshooting with product tools, logs, or packet captures. Obtaining MAC addresses the manual way for troubleshooting is not really convenient, but it may be the only option in some situations. In iOS 14, Apple actually made it easier to solve this problem by displaying the MAC address right in the connection utility. The beta behavior with daily randomization pretty much destroyed this workflow, but the final iOS 14 release made randomized MAC addresses visible. To find the MAC address, just open the Wi-Fi menu and click the network to see the private address.

Planning long-term, make sure you build your connectivity troubleshooting workflows around usernames, hostnames, or other policy-related identifiers to troubleshoot specific devices.

MAC-Based Policies

Home Wi-Fi routers increasingly support time and content restrictions that can be applied to specific devices (like your child’s phone). These policies are enforced by MAC address. If they’re no longer working, it’s because the MAC is now a private address. The easy solution here is to disable the feature for home networks. But savvy young people may simply re-enable the feature to bypass security controls. So, you’d better define the policy for both the actual as well as the private address.

MAC-Based IP Reservations

I don’t expect to see many use cases where mobile devices have reserved IP addresses on the DHCP server, but it may happen. MAC addresses are the usual linking entity for this feature. Presumably, these use cases have IT oversight, so the feature can easily be disabled on the device, or the private address can be used for the reservation entry.

Usage Forensics

In cases where public Wi-Fi has been used to commit online crimes, MAC addresses are a critical part of the forensic toolkit that can be used to correlate a device to a user. The laws for this type of forensic application varies by country, so it may not apply equally everywhere. Again, the beta implementation demolished this use case, while the iOS 14 release keeps it in play, as long as you perform forensics on both the actual and private addresses, just in case.

Closing thoughts

This conversation feels like a classic game of security versus ease of use. As privacy moves forward, the industry will need to adjust. You might say the MAC address was never meant to be used in all the ways we use it today. However, for over 20 years, the MAC address has been a reliable component of the wireless protocol, and 20 years of functionality have been built around it. Apple spared network operators a lot of pain by abandoning their beta implementation, but I think the MAC randomization paradigm will keep changing. It would be wise for network operators to think about (and start designing for) a world where MAC addresses are not just private, but are regularly rotating.

Resources

Apple has posted a brief knowledgebase page on this topic: https://support.apple.com/en-us/HT211227

This blog was originally authored by Marcus Burton, Architect, Cloud Technology