Apple, Google, and MAC Address Randomization

We reported that with the rollout of iOS 14 – starting in mid-September – an issue would affect all networks that use a device’s unique MAC address for authentication. It appeared that MAC address randomization was preset to occur every 24 hours, not only during scans but also after logging in. All indications pointed in that direction even in mid-September. Things have now turned out differently, which is why this article is receiving an update.

As a reminder: The first developments in this direction date back to the early 2010s. In fact, the unique MAC address assigned during the manufacture of a network-capable device—comparable to a license plate or serial number—enables the device in question to be uniquely identified worldwide. In all Ethernet networks, it would be problematic if, for example, a Layer 2 device address were duplicated, and this procedure reliably prevents that.

However, what ensures smooth operation for the intended functioning of a network can—like so much in technology—also be used for improper purposes. If, for instance, the MAC address of a particular system is known, an attacker could draw conclusions about the user and their activities and collect data, such as searching for data packets transmitted within a specific timeframe and comparing them with other periods.

Masking the MAC address is therefore considered a feature for enhanced data privacy; Google refers to it as “Privacy – Use randomized MAC“, while on the iPhone it is called “Private Wi-Fi Address“, accompanied by an explanation that using this feature helps prevent tracking.

Admittedly, this claim is certainly open to debate: not only do entirely different tracking methods exist, but there are also ways to force a smartphone to reveal its hardware MAC address, meaning the gain in security is not overwhelming. Accordingly, both manufacturers have taken steps to avoid disproportionately compromising user convenience. A hotel guest, for example, whose personal data appears in the guest registry, certainly has more convenience than risk to expect when a network operator is aware of their presence. They likely do not wish to log in to the WiFi again every day. The same is true for patients in hospitals, students and teachers on campus, and employees on company premises, or in their own home networks.

Accordingly, Android decided to mask the MAC address—meaning the hardware address is not displayed—while maintaining the simulated address per network SSID. This avoids experiences that impair user convenience while providing little security gain.

The situation looked different at Apple prior to the rollout. It was anticipated, and there were apparently beta versions that suggested re-randomization would occur every 24 hours. There were statements claiming that randomization would allegedly not apply to previously saved networks. Everyone was therefore eager to see how iPhones from version 6 onwards, all of which received this active default setting, would ultimately behave. Currently, updated devices behave like Android and keep the randomized address consistent per SSID. However, we would be well advised to prepare for the possibility that the situation may change sooner or later, requiring iPhone users to log in again every day.

Apple’s support pages describe how this behavior can be disabled. This allows users to decide, for each saved network, whether a randomized address or the device’s actual MAC address should be used: https://support.apple.com/de-de/HT211227.

Anyone reminded of the early 2010s is not mistaken. As early as iOS 8, the topic of MAC address masking was widely covered in the trade press. Moreover, the Hotspot 2.0 standard from the WiFi Alliance, once hailed as a “brave new hotspot world” with a seamless connectivity experience, is making headlines once again.

Hotspot 2.0 (HS2) / Passpoint, as a standard from the WiFi Alliance, was and continues to be frequently promoted as a solution for seamless connectivity; however, it was originally conceived for carriers and mobile network operators, rather than for operators looking to provide their customers with added value in the form of guest WiFi and establish a customer touchpoint. The use case of a guest arriving at a hotel without a regionally valid mobile contract (such as an international traveler) was not considered in those early scenarios.

Furthermore, the technology only works if the hardware supports it. Primarily US-oriented manufacturers have Passpoint-capable hardware in their portfolio, but even then not consistently across their entire product line, meaning implementation can prove quite challenging depending on the environment: Access points must be HS2 Passpoints, which means they must obtain or have obtained certification from the WiFi Alliance. Even with reputable manufacturers, this is often only available in conjunction with the WiFi controller. The technology also requires client-side support, which is likewise not universally present on today’s mainstream smartphones.

What does this mean for IACBOX operators?

Since we at Asteas know all too well how diverse the landscape of IACBOX operators is out in the field, we are preparing as a manufacturer for all eventualities.

The IACBOX will therefore support the Hotspot 2.0 standard, ensuring that everyone for whom configuring the network accordingly makes sense can rely on their familiar portal.

As a precaution, we will deactivate the information and the prepared pop-up screen, but we will retain them. Ultimately, we do not (yet) know whether this feature might still cause issues in certain cases.

What ultimately matters is the guest, who should feel comfortable with the settings and decide for themselves which balance between user convenience and privacy is right for them. Apple now appears to share this view.