Continuing on the Android Q changes that affect the EMM. Today’s subject is the upcoming mandatory Wi-Fi MAC Randomization: what is it, how does this affect you, and what do you need to do now or later about it.
This article is based on my own exploration of the source code and may not be entirely correct. It may be updated when Q finally comes out and more details become available.
What is it?
Google started crackdown on Hardware IDs since quite a while:
- In Android M, the default getMacAddress API was rewritten to return the same default value “02:00:00:00:00:00” (indicating that it is a locally administered MAC address). So the apps on the device could no longer see the real MAC, but the WLAN APs still certainly could, since the actual hardware MAC was used.
- In Android 8 the device would use a random MAC address while probing, but still connect with the real MAC. Which means that any sort of Wi-Fi Karma attack would reveal your MAC. And many devices plain ignored the feature altogether.
- An Android 9 device could use the randomized MAC for both probing and the actual connections, but the feature was optional (try it out in Developer Options) and off by default.
- Beginning with Android Q it will be mandatory.
The official Google documentation is extremely scarce on the matter. According to what had been explained at the summit, the following happens:
When a new network is added on a device – the OS randomly chooses a MAC address and sticks to it for the entire lifetime of that network.
The presenter at the summit said that “network” means WLAN and VPN, but I could not find any MAC randomization traces in the native VPN code. Mind you, I only have access to Pie code, and not Q
This means that:
- If you have, say 3 WI-FI profiles, your device will have 4 MACs (Factory MAC + 3x WLAN).
- If you have any MAC-based authentication systems serving those different WLANs – they will treat your device as multiple independent devices.
- If you have pseudo-static DHCP – you will have to re-work it, since the MACs will be different, and if you delete and re-deploy the WLAN profile – there is no guarantee that they won’t change
More interestingly, if you have a management/monitoring system that uses MAC as the primary device identifier – what will happen then?
[Un]surprisingly, this depends on how well your MDM/EMM/UEM will support this change! According to the presenter:
- Profile and Device Owner apps (= EMM agent) can access any random MACs for profiles created through them.
- Device Owner (and only DO) also has an API to read the true hardware MAC.
That is it! What would it mean to us?
How does this affect me?
I could come up with the following implications. Can you add more? Discussion is welcome!
1. MAC address is no longer constant through device life cycle. This has huge implications that we will review later, but in many “typical” cases you won’t see the difference: your Wi-Fi will work, RADIUS will work, hotspots will work. Everything session-based will work.
2. Solutions where MAC needs to persist across multiple sessions (inventory, forensics, etc) now MUST integrate with EMM. MAC whitelisting is a good example (actually, a virtually useless security “enhancement”, just as the MAC randomization itself). Anyway, scanning the MAC address from the box will no longer help you. Same for asset tracking etc.
3. Re-deploying corporate WLAN profiles may become a very unpleasant task if you then need to forward those updated MACs elsewhere (pseudo-static DHCP, still used in some rugged scenarios). Will be interesting to see what happens when you only, say, rotate PSK: some EMMs just push a new version profile (“overwrite, =keep MAC), while some others fully uninstall and re-install the new profile (= new MAC). What a fun world it would be!
4, We now need tools that understand that device’s MAC may change throughout its lifecycle, and act accordingly (store/process/search multiple MACs, including the date ranges). Also, consider that collisions are possible, when two different devices choose the same MAC address (simultaneously, or within different date ranges).
5. Corporate-issued devices used with solutions relying on Hardware MAC for inventory purposes must be enrolled as Work Managed or COPE (i.e. using Device Owner). Otherwise you will see a random MAC, which may change over time, and will not be able to correlate to the MAC on device/box label.
Since enrolling as COPE/WM requires a factory reset, and we don’t know what else will Google come up with in the future, I’d default to COPE/WM with Zero-Touch enrollment and use Work Profile for BYOD only (unless you face really strict privacy/etc governance)
!! The change is unavoidable. Device Admin goes away in Q. If the previous AE “innovations” could simply be skipped by staying on legacy management – you won’t be able to work around this one.
What do I need to do about it?
- Start asking around if any of your enterprise systems rely on MAC addresses and how.
- Talk to owners of those systems to explain the upcoming changes and see if they think those will affect them, especially given that MAC may change during the life cycle of the device if you re-deploy the corresponding profile. In many cases it won’t, but in some it may.
- Talk to your EMM vendor to see if they have APIs reporting device MAC addresses, and what [and when!] in general they are going to implement to support this change in Q
- Worst case scenario (very applicable for rugged customers and some other use cases): stock up on pre-Q devices and ensure that OS updates are disabled! 🙂
Summary and further resources
We have looked at the upcoming mandatory MAC address randomization in Android Q. It sounds scarier than it really is, but it may nevertheless backfire.
- My personal opinion since years is that the whole MAC Randomization issue is nothing but “Security Theatre”, creating more issues than solving. Read this study as an example: A Study of MAC Address Randomization in Mobile Devices and When it Fails
- Implementation details in the Android P source code:
- Method configureRandomizedMacAddress()
- Method getOrCreateRandomizedMacAddress()
- Method createRandomUnicastAddress() . which creates a random Locally managed Unicast MAC.
- Funny enough, the OS tries to create a random valid MAC just 3 times ( MAXIMUM_RANDOM_MAC_GENERATION_RETRY = 3 ), and then falls back to the default MAC of 02:00:00:00:00.
What are your thoughts?