GrapheneOS / os-issue-tracker

Issue tracker for GrapheneOS Android Open Source Project hardening work. Standalone projects like Auditor, AttestationServer and hardened_malloc have their own dedicated trackers.
https://grapheneos.org/
361 stars 21 forks source link

change per-network randomized MAC to save a per-network random MAC instead of calculating it with a keyed hash #3441

Open no-usernames-left opened 7 months ago

no-usernames-left commented 7 months ago
  1. Connect to a Wi-Fi network
  2. Change the Privacy setting to Use per-network randomized MAC (which will also disconnect you)
  3. Connect to the network again
  4. Note the MAC shown
  5. Tap Forget
  6. Connect to the same Wi-Fi network as before
  7. Change the Privacy setting to Use per-network randomized MAC (which will also disconnect you)
  8. Connect to the network yet again

Expectation: the MAC is different than before

Reality: the MAC is the same as before, even across a Forget

This is not "random" for any commonly-accepted definition of the term "random".

thestinger commented 7 months ago

GrapheneOS our own approach of using a per-connection random MAC by default along with using fresh DHCP state for each network connnection. We recommend leaving this setting at the default value. Filtering based on MAC address is pure security theater and you should avoid doing that on your networks.

The per-network random MAC setting is the standard Android approach which we kept in case you ever have to use a network where you need to register with a specific MAC address. It uses the standard approach to this which calculates a per-network value from a random value. Please read this documentation:

https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior#persistent

You can make it less persistent via Android's standard developer mode toggle for non-persistent per-network random MAC which will use a fresh value after DHCP state expires. We recommend using our per-connection random MAC approach instead.

no-usernames-left commented 7 months ago

GrapheneOS our own approach of using a per-connection random MAC by default along with using fresh DHCP state for each network connnection. We recommend leaving this setting at the default value.

Hi Daniel,

I appreciate this, and I almost always do, but on networks with a captive portal it causes me to have to reauthenticate (which also breaks my always-on VPN until I do) every time the device deassociates from the Wi-Fi, which is obnoxious.

Once I'm done on that network, I would like to be able to Forget it and know that next time I join it in per-network MAC mode it will be a fresh MAC; as it stands I cannot rid myself of the MAC no matter what I do while keeping the MAC the same across associations.

This is a bug and should be fixed; simply randomize the MAC once and store it along with the rest of the data, instead of apparently taking the output of some deterministic hash of the ESSID or whatever it's doing today.

thestinger commented 7 months ago

I appreciate this, and I almost always do, but on networks with a captive portal it causes me to have to reauthenticate (which also breaks my always-on VPN until I do) every time the device deassociates from the Wi-Fi, which is obnoxious.

The connectivity checks will detect the captive portal and trigger a prompt for handling it, which bypasses the VPN. This is the main purpose of the connectivity checks. Did you disable them?

This is a bug and should be fixed; simply randomize the MAC once and store it along with the rest of the data, instead of apparently taking the output of some deterministic hash of the ESSID or whatever it's doing today.

It uses a keyed hash with a random key. The random keys are kept persistently and used across networks. It's the officially documented behavior of Android's standard MAC randomization so it cannot be considered a bug. We don't change anything about how the standard randomization works but rather we add our own per-connection MAC randomization and modify DHCP to avoid leaking that it's the same device as before by clearing the state for each connection.

You're making a feature request for a new GrapheneOS specific randomization mode in between our per-connection randomization and their persistent per-network randomization. We don't like the approach of either their persistent or non-persistent randomization but we can't change how that works without breaking it for everyone with it set up already. We'd need to add our own approach to per-network randomization, and we could use the new mode by default for new networks. That's a feature request, not a bug report.

thestinger commented 7 months ago

You could use their non-persistent per-network MAC randomization mode if you don't have any networks where you want a long term persistent MAC address but rather you want a mix of per-connection MAC addresses and short term persistent per-network MAC addresses. In non-persistent mode, it should cycle after you forget the network.

no-usernames-left commented 7 months ago

The connectivity checks will detect the captive portal and trigger a prompt for handling it, which bypasses the VPN. This is the main purpose of the connectivity checks. Did you disable them?

No. As I said, I have to reauthenticate, and in the meantime while I have not been paying attention to my device's display my connection has died, important notifications have not been received, etc.

You could use their non-persistent per-network MAC randomization mode if you don't have any networks where you want a long term persistent MAC address but rather you want a mix of per-connection MAC addresses and short term persistent per-network MAC addresses. In non-persistent mode, it should cycle after you forget the network.

What do you mean by this?

thestinger commented 7 months ago

Read the linked section on the standard Android persistent and non-persistent MAC randomization modes. You can turn on their experimental non-persistent mode if you want, which doesn't save them beyond DHCP lease expiry, 24h or forgetting the network.

no-usernames-left commented 7 months ago

If we were happy with stock Android, none of this would exist.

If I hit Forget, I would like every aspect of the network to be forgotten, including the per-network "randomized" MAC.

I have elucidated the value to users, especially those temporarily using networks with a captive portal, and those users should not need to resort to developer hacks.

Please reopen as a feature request.

gsture commented 5 months ago

If we were happy with stock Android, none of this would exist.

If I hit Forget, I would like every aspect of the network to be forgotten, including the per-network "randomized" MAC.

I have elucidated the value to users, especially those temporarily using networks with a captive portal, and those users should not need to resort to developer hacks.

Please reopen as a feature request.

There is nothing wrong with this toggle under developer options and has nothing to do with "hacks" it's just an option that's offered for those few that need a different approach then what is currently offered.

Mac

I personally use "turn of absolute volume" for example because I can't stand the default approach.

Maybe grapheneos will add a different option, maybe not but in the mean time the suggestion to use this toggle is a great option to try.

thestinger commented 5 months ago

There is nothing wrong with this toggle under developer options and has nothing to do with "hacks" it's just an option that's offered for those few that need a different approach then what is currently offered.

The approach it uses doesn't make much sense. It changes MAC when DHCP lease expires and when the network is forgotten, which makes sense, but changing it on every reboot too doesn't make much sense.