Randomize full MAC address
It would be great to enable users to randomize the OUI part of the MAC address too. That's hard to do right, as explained in the design doc.
#1 Updated by darkgrid about 5 years ago
This would actually be an easy fix since macchanger is already implemented, just need a couple extra lines of code.
If the "All random" is selected on startup do a simple ifconfig wlan0 down, macchanger -r, ifconfig wlan0 up or something similiar to that.
As far as the random hostname, I think that's a much needed feature however that might take a little longer to implement than the random mac but it shouldn't be that difficult to do.
Just one thing I want to mention about the random hostname. I'm a system administrator myself of a mid-size network and if I see an "amnesia" hostname on my network that's a red flag however if it's something random that will do a better job at flying under the radar and not calling so much attention to itself.
The hostname can be random characters however most hostnames are peoples computer names (Mike, Laptop, Susan, HomePC, Sunshine, moon, bluelap, etc.). A better way to implement this feature would be to a have a word list with something like the top 50,000 common English words or top 10,000 common names. If "Random hostname" is selected at startup the script basically picks one word or name from the list and sets it as the computers hostname. Of course this method will be a little more difficult to implement.
For a quick and easy way to implement the random hostname I see a random number 1 - 10,000 being a easy and effective fix.
#2 Updated by pluto about 5 years ago
This is a much needed feature, I constantly find myself having to manually assign a random mac everytime I use Tails which is rather annoying.
All they would need to do is change the startup from macchanger -a to macchanger -r if "Completely Random" checkbox is marked on startup.
Shouldn't be more than 2 or 3 lines of code change.
Hopefully Tails developers notice this and implement it in Tails 1.0
#5 Updated by intrigeri about 5 years ago
As an added bonus if a user selects this "Fully Random" option upon startup it can also assign a random host name instead of just "amnesia" which it currently assigns.
Please don't use a single ticket for two different feature requests. Thanks in advance :)
#6 Updated by sajolida about 5 years ago
- Subject changed from Extended mac changer option to Randomize full MAC address
#11 Updated by anonym about 5 years ago
I'd like to start by pointing out that the MAC spoofing feature in Tails is not only about hiding the user's real MAC address, but is trying to achieve multiple goals at the same time, sometimes with tradeoffs due to conflicts between them. I recommend that you all read the "Threat model" section of our MAC spoofing design document so you get an understanding of, in particular,
anonym, please answer this. I guess your answer will be a good draft for #7054 :)
I gave it a shot (will reference this comment in #7054):
A MAC address has two components:
1. The first six bytes determines the Organizationally Unique Identifier (OUI) which in practice is the chipset's manufacturer. Note that manufacturers generally do not have only a single OUI, but multiple.
2. The last six bytes are used to enumerate unique network interfaces for a particular OUI, i.e. so cards within the same OUI can be distinguished.
Spoofing the OUI part in a way that satisfies our threat model is not straightforward because of
AvoidIdMacSpoof since multiple, large categories of OUIs violate that user goal:
- Unregistered OUI so its not used for any real device (
- Registered OUI that was registered but never used for any real device (
- Registered OUI but NICs are special purpose and hence impossible to run Tails on, e.g. NICs only used in ATMs, vending machines or embedded devices (
- Registered OUI used for NICs in normal computers but for a different type of NIC than the device being spoofed, e.g. wireless vs wired (
-aif we consider other NIC categories than simply "wireless vs wired" since that's the only distinction
- Registered OUI used for NICs in normal computers but they were manufactured decades ago (
- Registered OUI used for NICs in normal computers but whose distribution is limited to some restricted, geographical area (
So we have ruled out all
macchanger options except
-e, which means leaving the OUI as it is. We know it isn't the perfect strategy. The more uncommon the OUI is, the more that part can be used for tracking and the more it violates the
AvoidTracking user goal. At least this comes with some uncertainty compared to many of the impossible choices of OUI listed above, which would guarantee widespread violation of
AvoidIdMacSpoof among Tails users.
macchanger aside, we've learned that when spoofing the OUI, it has to be picked very carefully, and there are other tools that take smarter approaches.
macchiato, for instance, aims to maintain lists of current and common MAC addresses for different categories of devices so one can do less suspicious choices. However, both the "current" and "common" here are disputable since the criteria for inclusion in
macchiato seems rather lax. The verification is up to the submitter, so an ignorant (not necessarily malicious) submitter can easily get an uncommon OUI into the lists. See e.g. the "Contribute" section of the homepage, or the author's request on reddit.
Furthermore, the lists do not take into account that some devices are pretty much only used in some geographical areas. To end with, the lists are very small with around ~20 OUIs in most categories in current Git (as of 2014-04-16). Because of all this, the benefit and potential drawbacks of using
macchiato are not well-understood.
Since we haven't found anything better than
macchiato, leaving the OUI seems like the best tradeoff between the different user goals in our threat model for now.
#12 Updated by intrigeri about 5 years ago
- Status changed from New to In Progress
- Assignee deleted (
- Priority changed from Normal to Low
- Type of work changed from Discuss to Research
- Starter changed from No to Yes
The design doc now puts it clearly why this is a hard task. Turning it into a low priority Research one, as I doubt we'll undertake it any time soon.