{{Header}}
{{#seo:
|description=Development notes for adding MAC address anonymization to {{project_name_long}}.
}}
<div class="mininav">
* [[MAC Address]]
* [[Dev/MAC|MAC address (developers)]]
</div>
{{intro|
Development notes for adding MAC address anonymization to {{project_name_long}}.
}}
= Introduction =
Reliable MAC hiding is difficult beyond practicality.

MAC spoofing is just bolted-on, low priority. The Linux kernel, NetworkManager, systemd, udev, Debian, Kicksecure, Whonix, Qubes, any other Linux distribution or anyone else does not dedicate their life for the purpose of MAC hiding.

There's the [[MAC_Address#Auto-connect_Risk|Auto-connect Risk]] when new devices are connected.

We might also need to put MAC hiding into a bigger context by zooming out 1 level. What is the purpose of MAC hiding?

By default, when using computers, there are some persistent identifiers that can be detected by the internet access point such as a WiFi router / hotspot. A MAC address is one such persistent identifier.

A user that intents to hide their MAC address wishes to hide these persistent identifiers.

How about other persistent identifiers? The wiki mentions [[MAC_Address#Other_Location_Tracking_Risks|Other Location Tracking Risks]].

= Leak-proof MAC Randomization - Technical Implementation Challenges =

Leak-proof MAC randomization - ensuring that the real MAC address is never leaked - is very difficult to implement. Implementations using tools such as <code>NetworkManager</code>, <code>udev</code>, and/or the init system (such as <code>systemd</code>) might, in theory, leak the original MAC address. This is because these are complex code bases with intricate system interactions, where MAC randomization was not originally supported but later bolted on as an afterthought. Supporting MAC randomization at a different level, such as by the kernel, might be a more reliable approach to MAC randomization.

Related bug reports and discussions:

* NetworkManager bug report: [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1710 CRITICAL - True MAC address leaked during NM startup, despite rand/cloned being configured]
* https://forums.whonix.org/t/mac-randomization-is-flawed-proposed-new-solution/21366/8
* https://forum.qubes-os.org/t/mac-randomization-is-flawed-proposed-new-solution/32150
* https://gitlab.tails.boum.org/tails/tails/-/issues/11293#note_253628
* Tails ticket: [https://gitlab.tails.boum.org/tails/tails/-/issues/17128 Investigate whether internal network adapters consistently use their previously spoofed MAC address after resuming from suspend]
* Tails bug report [https://gitlab.tails.boum.org/tails/tails/-/issues/17115 MAC spoofing can fail and disable a network adapter when waking up from suspend]

Related general security ecosystem-wide issues:

* {{kicksecure_wiki
|wikipage=Dev/About_Computer_(In)Security
|text=About Computer (In)Security
}}

= Other Issues =
* https://forums.whonix.org/t/mac-address-randomization-not-as-random-as-you-think/3791
* https://forums.whonix.org/t/your-mac-address-randomization-attempts-are-futile/2719
* https://forums.whonix.org/t/mac-randomization-is-flawed-proposed-new-solution/21366

= Use Case Overview =
Attempting to design a user interface for a MAC changer that fulfills all requirements mentioned in [https://gitlab.tails.boum.org/tails/tails/-/issues/5421 this issue].

To better understand the problem and ensure clarity in discussions, it may be helpful to create an overview. Therefore, a table summarizing various use cases is provided below.

There are numerous different threat models and goals. This complexity might make it too difficult for the average user. Supporting all use cases would result in a massive user interface, just for deciding which MAC address to use.

A public computer could be, for example, a library computer.

Public network_C could be a free WiFi hotspot in a mall.

Public network_A, public network_B, public network_D, and public network_E could be different coffee shops with free WiFi.

{| class="wikitable"
! align="left" | Number
! align="left" | Place
! align="left" | Past Usage
! align="left" | Threat Model
! align="left" | New Recommendation
|- class="odd"

| align="left" | 1
| align="left" | Home computer
| align="left" | Real MAC
| align="left" | None
| align="left" | Macchiato MAC random
|- class="even"

| align="left" | 2
| align="left" | Public computer
| align="left" | Real MAC
| align="left" | Changing MAC draws admin attention and/or breaks network access
| align="left" | Real MAC
|- class="odd"

| align="left" | 3
| align="left" | Public network_A
| align="left" | Real MAC
| align="left" | Admin monitors for consistent MAC addresses
| align="left" | Real MAC
|- class="even"

| align="left" | 4
| align="left" | Public network_B
| align="left" | Macchanger random MAC_B
| align="left" | Admin checks for consistent MAC addresses but does not monitor Tor usage or vendor IDs
| align="left" | Macchanger random MAC_B
|- class="odd"

| align="left" | 5
| align="left" | Public network_C
| align="left" | Never used
| align="left" | High user volume; admin logs MAC addresses and detects uncommon vendor IDs
| align="left" | Random Macchiato MAC
|- class="even"

| align="left" | 6
| align="left" | Public network_D
| align="left" | Never used
| align="left" | Admin logs MAC addresses, detects uncommon vendor IDs, and looks for consistency
| align="left" | Macchiato MAC_D
|- class="odd"
| align="left" | 7
| align="left" | Public network_E
| align="left" | Never used
| align="left" | Admin logs MAC addresses, detects uncommon vendor IDs, and looks for consistency
| align="left" | Macchiato MAC_E
|-

|}

'''Legend:'''

* '''Consistent MAC:''' Always the same once chosen, instead of generating a new one each time.
* '''[https://github.com/EtiennePerot/macchiato Macchiato]'''
* '''Macchiato MAC random:''' Uses a popular vendor ID, but the latter part changes randomly each time.
* '''Macchiato MAC_D (or E):''' Uses a popular vendor ID; the latter part is randomly generated upon first use but remains consistent when selecting Macchiato MAC_D or MAC_E in the future.

= Or in Words... =

# "I am using my home computer. Give me a Macchiato MAC random. I don't really need it, but it makes me feel better. Just in case."
# "I am using a public computer. Don't change the MAC. Otherwise, this might attract unwanted admin attention or make the network inaccessible."
# "I am using public network_A. I have always used my real MAC in the past. The admin knows all users and gets suspicious if someone changes their MAC. Stick to my real MAC."
# "I am in public network_B again. I previously used Macchanger to get a random MAC_B. The admin checks for consistency but does not recognize that the vendor ID is non-existent. Stick to my old random MAC_B."
# "I am using public network_C for the first time. Many users connect here, and I believe the admin logs all MAC addresses. I also suspect the admin is aware of uncommon vendor IDs and GNU Macchanger. Since this is a popular network, the admin won’t remember me specifically. Assign me a random MAC from a popular vendor ID (Macchiato)."
# "I am using public network_D for the first time. I suspect the admin logs MAC addresses and recognizes uncommon ones. The admin also gets suspicious if someone changes their MAC frequently. Assign me a random MAC from a popular vendor ID, name it MAC_D, and ensure I use the same one whenever I revisit this network."
# "Yes, network_E is very similar to network_D. I suspect the admin logs MAC addresses and detects uncommon ones. The admin also gets suspicious if someone changes their MAC frequently. Assign me a random MAC from a popular vendor ID, name it MAC_E, and ensure I use the same one whenever I revisit this network. Don't confuse it with other MACs."

= Thoughts =

Supporting use cases 6 and 7 would either require persistence or require the user to remember or write down the MAC address, which is difficult.

An ideal solution should not require persistence.

A possible approach is for the user to enter a keyword, and using that keyword would consistently generate the same Macchiato MAC_D or Macchiato MAC_E.

= Newer =
Thesis:

{{quotation
|quote=Like with Tor and anonymity in general, you cannot hide the fact that you are trying to hide.
}}

See also:

* [[Fingerprint]]
* [[Hide Tor from your Internet Service Provider]]
* https://forums.whonix.org/t/idea-proposal-of-cover-traffic-a-fake-workstation/146

From [https://tails.boum.org/contribute/design/MAC_address/ this Tails design page]:

{{quotation
|quote=
* '''AdvCapSniff'''
* '''AdvCapRecords'''
* '''AdvCapOwners'''
}}

{{quotation
|quote=
* '''AdvGoalTracking'''
* '''AdvGoalProfiling'''
* '''AdvCapOwners'''
* '''AdvGoalIdTails'''
* '''AdvGoalIdMacSpoof'''
}}

{{quotation
|quote=
* '''AvoidTracking'''
* '''AvoidIdTails'''
* '''AvoidIdMacSpoof'''
* '''AvoidConnectionProbs'''
}}

= Suspicious MAC Addresses =
When MAC spoofing design has been considered by Tails, an argument has been made about some types of random MAC addresses might raise suspicion. To explain this, one needs to know a bit about the format of a MAC address.

{{quotation
|quote=
The first three bytes of a MAC address determine the Organizationally Unique Identifier (OUI) which in practice determines the chipset's manufacturer 
}}

{{quotation
|quote=Adversary goals
[...]
Identify MAC spoofing individuals. We assume that our adversary has bought into the "nothing to hide" argument, which makes such suspicious behaviour valuable information. [AdvGoalIdMacSpoof]
[...]
Not raising alarms on the network, i.e. prevent AdvGoalIdMacSpoof, but also avoid alarming the local administrators (imagine a situation where security guards are sent to investigate an "alien computer" at your workplace, or similar). [AvoidIdMacSpoof]
[...]
Great care should be taken when picking the OUI to avoid these categories. The whole point is to randomly pick an OUI that the adversary expects to see. In particular the OUI should be one used for common, consumer oriented hardware.
|context=[https://tails.boum.org/contribute/design/MAC_address/ this Tails design page]
}}

So in summary, the argument has been brought forward, that if the OUI is non-existing (as in not assigned to any chipset manufacturer), this might raise suspicion. However, it is important to consider the context of that consideration. This has been considered many years before Apple iOS and Android started some form of MAC randomization.

Is MAC randomization less suspicious nowadays that Apple and Android started with some form of MAC addresses randomization by default? This might depend on how exactly these popular phone producers randomize MAC addresses.

For instance, Samsung randomizes MAC address by default per WiFi but keeps using same MAC per WiFi.

{{quotation
|quote=The Android framework uses two types of MAC randomization: [https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior#persistent persistent randomization] and [https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior#non-persistent non-persistent randomization].
|context=[https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior Android: MAC randomization behavior]
}}

= Leak Testing =
TODO:

Can MAC address leak testing be done:

* non-Qubes: on the host operating system
* Qubes: inside sys-net

Or,

* is using an outside device required?

TODO: Log/report (hashed?) MAC addresses? Note in a log if the real MAC address or a spoofed MAC address has been used.

= hostname =
Hostname leaks...

* NetworkManager feature request: [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/584 No way to set dhcp-send-hostname globally]
* NetworkManager pull request: [https://github.com/QubesOS/qubes-issues/issues/7701 device: Support configuring dhcp-send-hostname globally]
* Quote Qubes feature request [https://github.com/QubesOS/qubes-issues/issues/7701 Hostname leak prevention]

<blockquote>
The reason the hostname is not being sent on debian-11 is because /etc/hostname (the static hostname) file is missing (it needs to be present when NetworkManager service is started).
</blockquote>

In conclusion, if using DHCP, it's best if file <code>/etc/hostname</code> does not exist.

= See Also =
* {{kicksecure_wiki
|wikipage=MAC_Address
|text=MAC Address
}}
* {{whonix_wiki
|wikipage=MAC_Address
|text=MAC Address
}}
* [https://tails.boum.org/contribute/design/MAC_address/ Tails MAC Address Design]
* [https://gitlab.tails.boum.org/tails/tails/-/issues/5421 MAC Changer Issue]
* [https://gitlab.tails.boum.org/tails/blueprints/-/wikis/macchanger/ Tails MAC Changer Wiki]
* Worth reading! Thanks to Tails!
* https://perot.me/mac-spoofing-what-why-how-and-something-about-coffee

= Forum Discussions =
* https://forums.whonix.org/t/mac-address-anonymization/24
* https://github.com/Kicksecure/security-misc/issues/184

{{Footer}}
[[Category:Development]]
[[Category:Design]]