Tails prototype branch: feature/spoof-mac
Tails Greeter prototype branch: feature/spoof-mac
Ticket:
https://labs.riseup.net/code/issues/5421 (and sub-tickets)
Below are the initial design after an internal discussion. It's
up-to-date version can be found at:
https://tails.boum.org/blueprint/macchanger/
All comments are welcome!
# Rationale
The uniqueness of MAC addresses introduce two types of potential
issues for Tails users, in particular if the MAC address can be linked
to the user's identity:
1. Geographical location tracking: A time-stamped log of a MAC address
ties a device to a certain location at a particular time. If the
device's owner is known, his or her movements are also known. In
case an unknown owner, the tracked movements leak information about
the owner, which eventually may lead to identification.
2. Identify Tails (or Tor) users: If the usage of Tails (or Tor) can
be fingerprinted on the network (despite other measures taken), and
the owner of a device is known, it can be determined that the owner
also is a Tails (or Tor) user.
Spoofing the MAC address is the natural solution. Unfortunately, in
some cases MAC spoofing may cause network connection issues or even
raise alarms; care should be taken to prevent MAC spoofing in such
situations.
# Threat model
## Adversary goals
We assume an adversary whose goals are the following:
1. Monitoring of when and where a particular MAC address with a known
owner is used, or, in other words, monitoring of an individual's
geographical movement while using a certain device.
[AdvGoalTracking]
2. Dragnet-style logging of when and where MAC addresses with unknown
owners are used for large-scale social graphing and profiling which
leaks information owners' identities. [AdvGoalProfiling]
3. Identify Tails (and Tor) users, i.e. if Tails (or Tor) can be
fingerprinted, note that about a particular
individual. [AdvGoalIdTails]
4. Identify MAC spoofing individuals. We assume that our adversary has
bought into the "nothing to hide" argument, which makes such
suspicious behaviour valuable information. [AdvGoalSuspicion]
Note that none of the goals deal with other types of unique
identifiers than MAC addresses. In particular, logging of IMEI:s [1],
used by mobile NIC:s, are omitted (mostly due to lack of proper
tools).
[1]
http://en.wikipedia.org/wiki/IMEI
## Adversary capabilities
The adversary's capabilities are assumed to be:
1. Omniscient wireless snooping of when and where (via triangulation)
all MAC addresses are used. Also access to Time-stamped logs of the
presence of MAC addresses on all wired networks (think compromised
routers and/or ISP:s). [AdvCapSniff]
2. Has access, on specific request, to all user/customer records and
surveillance data of any public network. [AdvCapRecords]
3. Knows who owns which MAC address according to the last traceable
transaction (e.g. credit card trail). Cash purchase, trade, trash
salvaging or theft are ways to potentially avoid this but the
adversary can interrogate the previous owner to obtain that
information if remembered (or at all known). [AdvCapOwners]
## Tails user goals
1. Hide geographical movement, i.e. prevent AdvGoalTracking and
AdvGoalProfiling. [AvoidTracking]
2. No unspoofed usage of Tails (or Tor), i.e. prevent AdvGoalIdTails.
[AvoidIdTails]
3. Not raising alarms on the network, i.e. prevent AdvGoalSuspicion,
but also avoid alarming the the local administrators (imagine a
situation where security guards are sent to investigate an "alien
computer" at your workplace, or similar). [AvoidSuspicion]
4. Avoid network connection problems due to MAC address white-listing,
hardware or driver issues, or similar. [AvoidConnectionProbs]
# Use case analysis
Below we analyse how MAC address spoofing relates to each user goal
for the given situation.
## Using Tails at home
First, note that the user's relation (owner, family member's,
friend's, work's, borrowed, etc.) to the computer running Tails
doesn't matter; the location is already directly related to the user's
identity. Similarly, because of this, MAC spoofing is of very limited
value for both AvoidTracking and AvoidIdTails value.
MAC spoofing could hinder AvoidSuspicion if detected by the ISP's
hardware (i.e. no trusted router in the way). Similarly, ISP-provided
hardware may employ some sort of MAC address white-listing (e.g. only
X unique ones are allowed) that can prevent AvoidConnectionProbs.
Summary: MAC spoofing should be avoided but isn't terribly dangerous
if enabled.
## Using Tails at a friend's place
### Using your computer
MAC spoofing should be enabled for both AvoidTracking and
AvoidIdTails. AvoidSuspicion won't be your problem but your friend's
(which isn't a problem at all unless you're there spoofing all the
time). AvoidConnectionProbs can be problematic for the same reasons as
in "Using Tails at home".
Summary: Enable MAC spoofing!
### Using any other computer
Since the computer you use isn't tied to you, AvoidTracking and
AvoidIfTails isn't relevant. AvoidSuspicion won't be your problem but
your friend's. AvoidConnectionProbs can be problematic for the same
reasons as in "Using Tails at home".
Summary: MAC spoofing should be avoided but isn't terribly dangerous
if enabled.
## Using Tails at a restricted public network
Access is restricted to registered users' identities only. We use
"registration" a bit loosely, but example of networks like these are:
* paid-for access when there's a money trail (e.g. credit cards).
* captive portals requiring logging in with an identity-tied account.
* locations requiring a identity-tied key card (e.g. university
computer labs and workplaces) to access.
This should probably also cover otherwise unrestricted networks that
snoops on users in other ways, e.g. a library with video camera
surveillance.
### Using your computer
Since the user is registered for network access, both AvoidTracking
and AvoidIfTails are hard to get. However, AdvCapRecords requires
explicit targeting (more expensive), while AdvCapSniff isn't, and MAC
spoofing would defeat the latter, so it's not without merit.
AvoidSuspicion could be problematic if your registered presence on the
network is correlated to constantly new MAC addresses. A quite likely
situation for this case is that you login via some captive portal, and
these often use your MAC address for access control purposes, so a log
of which you have used
AvoidConnectionProbs is a problem if your MAC address becomes part of
your registration, and is assumed to not change (maybe a place where
you have to pay for each device you connect with). This seems pretty
far-fetched, though.
Summary: There's no easy choice here but in most scenarios
AvoidTracking is probably more valuable than AvoidSuspicion, so MAC
spoofing should be enabled.
### Using a public computer
Since the computer isn't tied to you, MAC spoofing does nothing to
AvoidTracking and AvoidIfTails. It could cause problems to both
AvoidSuspicion and AvoidConnectionProbs.
Summary: MAC spoofing should be avoided but isn't terribly dangerous
if enabled.
## Using Tails at an open public network
Access is completely open, and no kind of registration is needed.
### Using your computer
MAC spoofing should be enabled for both AvoidTracking and
AvoidIdTails. Such a network should expect to see many unique MAC
addresses daily, and be ready to deal with it, so AvoidSuspicion and
AvoidConnectionProbs are of no consequence.
Summary: Enable MAC spoofing!
### Using a public computer
Same as using a public computer at a restricted public network.
Summary: MAC spoofing should be avoided but isn't terribly dangerous
if enabled.
## Conclusions
The strong requirement of enabling MAC spoofing in a few cases, and
the low risk of keeping it enabled even in the cases where it should
be avoided, warrants for making this feature enabled by default, with
the possibility to opt-out.
# User interface design
This option, which is of the on/off variety, will be implemented as a
check box in Tails Greeter. The problem is to formulate a concise
description that's clear and informative enough to guide the user to
make an informed decision.
In our previous blueprint we state that we want a user interface that
presents the option using "simple words such as 'I am using a public
computer' instead of speaking geek-language about mac addresses or
whatever". However, in the use case analysis above it's obvious that
simply "public or not" isn't enough to differentiate between the
different use cases, and it seems unlikely to be the case for any
other easily understood concept.
Therefore it seems that the label of the option isn't what we should
focus on, so we might just as well call it "Spoof all MAC addresses",
which at least can help advanced users that know what they're
doing. Beyond a concise summary in Tails Greeter, it's also highly
important that we have clear and complete documentation about this.
I envision a GUI looking like this:
---------- Spoof all network cards' MAC addresses ----------
This options prevents leaving traces of your geographical
location. Leaving this option enabled is generally not harmful but
may cause network connection problems. See the documentation.
[x] Spoof all network cards' MAC addresses
## Things to consider
### No mention of AvoidIdTails as motivation?
The real solution to AvoidIdTails is to use obfuscated Tor bridges;
MAC spoofing is at best an additional safe-guard if the obfuscation is
broken. While this can be mentioned in the full documentation, we
don't have to make the short summary any more complicated by trying to
include it.
### Be more specific about when to disable?
The current wording is based on that it's "generally not harmful" to
leave this option enabled. Indeed, the situation when it may be
harmful are first of all not very harmful to begin with, and also
quite very difficult to explain in a few words. Therefore I think we
should just refer to the documentation. After all, users that don't
press on "more options" won't even be aware of any issue we would
spell out there. If that's a problem for this case, we definitely have
to reconsider having MAC spoofing enabled by default option as well.
### "network connection problems" problems :)
We may want to drop the "network connection problems" part of the
short summary. Although it refers to being able to establish a network
connection, users may confuse it with the similar problem of a captive
portal blocking the normal browser, or other post-connect problems.
The user may then wrongly disable MAC spoofing in a bad situation.
# Implementation
The current implementation assumes we want MAC spoofing of the
end-bits for all Ethernet NICs by default, so all such devices present
before T-G log in are spoofed as soon as they are plugged. This is
reversed in T-G's post-login script if the option is disabled
there. Any device plugged afterwards will have the user's chosen
preference enforced.
## Trigger
We use udev as the trigger that hooks MAC address spoofing. Because of
that, it happens for every Ethernet device automatically, as early as
possible (i.e. immediately after it's added), so even if there's some
kind of weird leak before a device is up:ed (someone on tails-dev@
alluded to this being possible for wireless NICs [2] although without
any references) the real MAC address shouldn't leak.
[2]
https://mailman.boum.org/pipermail/tails-dev/2013-January/002491.html
All other triggers that were considered do not deal with the "early"
leaks issue, in addition to other reasons for being discarded:
* ifupdown hook: A if-pre-up hook would probably work but since we use
NetworManager the exact behaviour is blurred and not particularly
well-documented. It doesn't feel robust for this reason.
* NetworkManager hook: NM doesn't trigger events equivalent to
if-pre-up, so this isn't possible. See the commented parts in:
/etc/NetworkManager/dispatcher.d/01ifupdown
* systemd integration: We don't use this yet.
* NetworkManager plugin: While this certainly would have a nice impact
outside of Tails, the added maintenance burden makes it less
attractive.
## MAC changing tool
The tool used to change the MAC address is simply macchanger, mostly
because it's in Debian (where the known vulnerabilities are patched)
and macchiato isn't (and it's not as well tested, yet). macchanger is
used in a very straightforward way, so if we want to switch tool in
the future it's a simple task.
# Future work
## Documentation access in Tails Greeter
For this Tails Greeter option, and similar complicated options to
come, it would be very handy to be able to access the appropriate
documentation inside Tails Greeter, similar to how we do it in
Whisperback.
## Connection failure detection
I've failed to find a way to hook into NetworkManager's connection
error handling. An experiment showed that when connecting to a
password-protected (WPA-PSK) wireless network with MAC address
white-listing, spoofed (and hence blocked) MAC addresses resulted in
an endless cycle of NM asking for passphrase. When cancelled, NM
displays a "Disconnected" notification, and during this time no NM
dispatcher events were emitted.
Unfortunately I'm not sure we can do this one without some serious
patching of NetworkManager. Some bugs of interest that may bring some
hope:
* <
https://bugzilla.gnome.org/show_bug.cgi?id=387832>
* <
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518368>
* <
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/336736>
## Pre-up Failsafe
In the current implementation there's no failsafe that verifies that
the selected MAC spoofing setting has been enforced before
connecting. This would be easy if there was something like pre-up NM
dispatcher hooks but just like in the previous section, there's none
yet.
## Vendor bit randomisation with macchiato
These are the current relevant OUI counts from macchiato's git:
5 oui/bluetooth_laptop.sh
2 oui/bluetooth_misc.sh
12 oui/bluetooth_mobile.sh
1 oui/bluetooth_pmp.sh
2 oui/wired_console.sh
3 oui/wired_desktop_dedicated.sh
11 oui/wired_desktop_onboard.sh
8 oui/wired_infrastructure.sh
17 oui/wired_laptop.sh
6 oui/wired_misc.sh
4 oui/wired_printer.sh
2 oui/wireless_camera.sh
1 oui/wireless_console.sh
4 oui/wireless_desktop_dedicated.sh
2 oui/wireless_desktop_onboard.sh
4 oui/wireless_handheld.sh
6 oui/wireless_infrastructure.sh
1 oui/wireless_laptop_dedicated.sh
21 oui/wireless_laptop.sh
17 oui/wireless_mobile.sh
7 oui/wireless_pmp.sh
4 oui/wireless_printer.sh
8 oui/wireless_usb.sh
In particular there's ~20 each in wireless_laptop and wired_laptop,
which is what we should care about most (desktops rarely need MAC
spoofing). However, after investigating the sources for some OUI:s
(via git history), some OUI:s are (according to the submitter) only
common in certain geographical areas. This makes the lists too small
and unreliable at the moment.
# Questions, remaining issues, and other random stuff
## Leaking spoofed MAC address on public computer?
In the current implementation all NICs will be spoofed before the user
has the option to disable it, which s/he shouldn't do when using
e.g. a public computer. This may be an issue if there are "early"
leaks like alluded to in [3], as it may raise alarms; first an unknown
MAC address is detected from a computer, than it shortly after
switches back to the expected one. So we have these sub-questions:
### Is there any wired activity before T-G?
As of commit 34a6bf0 we only start NM after T-G logs in. Hopefully
there's no wired activity for other reasons but this should be
investigated.
### Is there any wireless activity before T-G?
In our blueprint it's stated that: "Network manager will automatically
begin to scan the network with a non-fake mac address". This implies
that scanning is active, not passive. Is this what [3] alludes to?
Does any one know more about this?
### Should we rfkill wifi?
Especially if the previous question has a positive answer, maybe we
should make a udev hook for when the rfkill switch device is added by
udev (assuming that it's possible) that blocks wifi. After Tails Greeter
logs in, we'd then unblock it.
### Completely block network devices until T-G post-login?
If we block all network devices from being added by udev until after
T-G has logged in (when we known the user's MAC spoof preference) then
the whole "early leaks of spoofed MAC addresses" issue would be
solved, provided the user did the right choice. Maybe this is
worthwhile?
Cheers!
