Add anchor.

[tails/vicves.git] / wiki / src / blueprint / macchanger.mdwn

[[!toc levels=2]]

# Rationale

The uniqueness of [[!wikipedia 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 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]

## Adversary goals

We assume an adversary whose goals are the following, which all
happens on a global, omniscient level thanks to AdvCapSniff:

1. Monitoring of when and where a particular MAC address with a known
   owner is used. In other words, monitoring of an individual's
   geographical movement while using a certain device (thanks to
   AdvCapOwners).  [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. If Tails (or Tor) usageAdv can be
   fingerprinted, then that fact is documented about a particular
   individual (thanks to AdvCapOwners). [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. [AdvGoalIdMacSpoof]

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

## 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 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]

4. Avoid network connection problems due to MAC address white-listing,
   fixed ARP tables, 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 AvoidIdMacSpoof 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. AvoidIdMacSpoof 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
AvoidIdTails aren't relevant. AvoidIdMacSpoof 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 AvoidIdTails 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.

AvoidIdMacSpoof 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 AvoidIdMacSpoof, 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 AvoidIdTails. It could cause problems to both
AvoidIdMacSpoof 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 AvoidIdMacSpoof 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.

# Leak prevention

It is conceivable that NICs may send packets before the user has made
a decision about whether to use MAC spoofing or not. In fact, someone
on tails-dev@
[alluded](https://mailman.boum.org/pipermail/tails-dev/2013-January/002491.htm)
to this being possible for wireless NICs although without any
references (this may refer to so called "active probing"; see section
below). If this is the case it at the very least implies that we must
enforce the MAC spoofing setting as early as possible.

However, since we (obviously) cannot foresee the user's decision we get
a problematic time frame between when a network device is added during
early boot and when the user makes the decision later on. Enforcing a
default MAC spoofing setting immediately when a network device is
added, that then potentially is reversed when the user makes the
decision, leads to problems in some scenarios if we assume these early
leaks happen:

* If MAC spoofing is enabled before the user has made the decision, a
  fake MAC address would leak before the user made the decision, and
  the decision was to disable MAC spoofing. The sudden switch of MAC
  address may result in a breach of AvoidIdMacSpoof.

* If MAC spoofing is disabled before the user has made the decision, the
  real MAC address would leak even if the user wanted MAC spoofing
  enabled, which leaks to breaches of AvoidTracking and AvoidIdTails.
  The sudden switch of MAC address may result in a breach of
  AvoidIdMacSpoof.

The first is clearly less bad than the second, but the ideal, which
avoids these problems altogether.

The real solution is therefore to eliminate the problematic this time
frame completely by preventing any network devices from being enabled
at all until the decision has been made, and have the MAC spoofing
setting applied immediately when the device is added.

# 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,
and that we make this documentation easily available from inside
Tails Greeter.

<a id="active-probe-fingerprinting"></a>

# Active probe fingerprinting

**NO PREVENTION AGAINST THIS IS IMPLEMENTED YET**

There's an opportunity for an adversary to achieve AdvGoalTracking and
AdvGoalProfiling due to "active probing" performed by NetworkManager
for Wi-Fi connections. This puts AvoidTracking at risk.

Wi-Fi has both a passive and active scanning mode. Passive scanning,
as the name suggests, passively listens for broadcasted wireless
networks, which is entirely safe. Active scanning, however, actively
sends probes for any known networks. In our case these are the saved
connections in NetworkManager, so this turns especially problematic
when persistent NM-connections are used; the (potentially long) list of
networks actively probed for can be used as a fingerprint by an
adversary, breaching AvoidTracking.

While this has nothing to do with MAC spoofing, it does strongly
affect the (arguably) most important user goal of this feature, namely
AvoidTracking. Because of this, active scanning should be disabled in
NetworkManager when MAC spoofing is enabled.

# Implementation

The current implementation spoofs the non-vendors bits of any network
device's MAC address immediately after it is added by udev. Furthermore, to
deal with potential network leaks before the user has chosen whether
to enable MAC spoofing or not, the addition of network devices is delayed
until after Tails Greeter knows the user's final decision.

## Network blocking

As suggested in the "Leak prevention" section, we block all network
devices' modules from being loaded until the user has made the decision about
whether to enable MAC spoofing or not. The way we do this is by
generating a list of all network device modules during build time, and
add these to a `modprobe.d`-type blacklist. In Tails Greeter's
post-login script (when we know the user's decision) we unblock the
network by simply removing that list, and then we have udev "re-probe"
for network devices and load their modules.

Scripts:

* [[!tails_gitweb config/chroot_local-hooks/80-block-network]] (runs at
  build time)

* [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/tails-unblock-network]]
  (runs right after Tails Greeter logs in)

## 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 the real MAC address
shouldn't leak.

Hook:
[[!tails_gitweb config/chroot_local-includes/etc/udev/rules.d/00-mac-spoof.rules]]

### Discarded approaches

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.

Helper scripts:
[[!tails_gitweb config/chroot_local-includes/usr/local/sbin/tails-spoof-mac]]

## Connection failure detection

This section deals with AvoidConnectionProbs. The goal is to somehow
identify connection errors that are related to MAC spoofing, and
notify the user when this happens.

Due to lack of hooks into NetworkManager's connection error handling
we currently use a simple monitoring script that's started when MAC
spoofing is enabled. It scans syslog for the error message patterns
from NetworkManager and `wpa_supplicant` expected when the connection
fails due to MAC spoofing. When such a pattern is found, a
notification is shown to the user, stating that the connection problem
*may* be MAC spoofing related. Due to the uncertainty and lack of
information available for this approach, there certainly will be false
positives.

At the moment this script only deals with wireless connections. It
successfully distinguishes between MAC-spoof related errors and errors
when entering the wrong passphrase, so no false positives in that
(relatively common) case.

For details, see the script:
[[!tails_gitweb config/chroot_local-includes/usr/local/sbin/tails-blocked-network-detector]]

## MAC spoofing and virtual machine networking issues

Some virtualization tools seem to behave poorly when spoofing virtual NIC
MAC addresses. For instance, VirtualBox's networking completely breaks
when using bridge- and NAT-based adapters in combination with
MAC-spoofing, and those two are probably the two most common scenarios
(NAT-based in particular). Therefore, if it is detected (using
`virt-what`) that Tails is running inside a virtual machine, then
MAC spoofing is disabled by default. If the user still enables the
option, a warning is immediately shown.

When running Tails inside a virtual machine, MAC spoofing is mostly
useless, at least when NAT-based (and similar) approaches to network
sharing are used, since only the host system will see the MAC address.
However, that's not the case with bridged connections, but on the other
hand only the virtual NICs MAC address is leaked, which usually is
randomised upon creation any way. Still, this could leak to breaking
AvoidTracking, since the MAC address usually is persistent. We may
want to document this, and advice users to preferably use NAT-based
virtual adapters (which usually is the default). Users that must use
bridged connection will have to manually randomise the MAC address
each boot.

# Future work

## Using NetwokManager for AvoidConnectionProbs?

Instead of our current hack, we'd ideally want to hook into
NetworkManager's error handling, which certainly would be more robust,
and hopefully would provide more information about the error, but this
currently seems unsupported.

An experiment has 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.

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>

## 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

## MAC spoof failure warning and failsafe

If MAC spoofing fails for some interface we'd like to prevent it from
exposing the real MAC address, and warn the user about this via a
notification.

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 section about "Connection
failure detection", there's none yet.

An alternative would be to do this in
[[!tails_gitweb config/chroot_local-includes/usr/local/sbin/tails-spoof-mac]], which
is run by the udev hook. In the end of the script we could try to
verify that the spoofing indeed happened for the NIC in question, and
if it didn't we could go into full-out panic mode:

1. Down the interface
2. Try to unload the module used by the NIC. While one easily can find
   the module used by a `$NIC` via `readlink
   "/sys/class/net/${NIC}/device/driver/module"`, we'd also have to
   resolve reverse dependencies. For instance, for current Intel
   wireless chipsets, the `iwlwifi` module is loaded, but with current
   Linux kernels another module called `iwldvm` is loaded, and it uses
   `iwlwifi`, so a `morprobe -r iwlwifi` will fail. Sadly `modprobe`
   doesn't have a `--recursive-remove` or `--show-reverse-depends` so
   we'd have to e.g. parse "Used by" field of `lsmod` or similar, and
   we'd have to do it recursively to be rigorous.
3. Perhaps prevent NetworkManager from starting if the previous step
   failed?
4. Show a scary error message to the user

It would obviously require to drop `set -e`, because errors are indeed
what could cause this to happen.

## Detecting MAC-spoof related connection errors for wired NICs

While Wi-Fi connection are covered, this gets trickier for wired
connections. The problem is that there's no strong concept of being
"associated" to a wired network (at least a "standard" one, perhaps
there is with 802.1x security...). It'll probably be hard to identify
blocking without confusing it with other types of wired connection
failures (i.e. false positives). How does wired MAC address blocking
usually work? On which level? DHCP? Lower layer?

# Old stuff from blueprint

## Improving macchanger

Some of our goals would be easier to achieve by patching macchanger
itself. Since it's been unmaintained upstream for a while, we've been
discussing and working with someone who has taken its maintenance over
and has already started patching it to better suit our needs:

* [Redmine project](https://labs.riseup.net/code/projects/show/macchanger)
* Git repository: `git://labs.riseup.net/backupninja.git`
* Debian packages: the maintainer of the macchanger package in
  Debian has already integrated some of these patches (uploaded to
  sid: 1.5.0-8) and is likely to go on this way. Tails has been
  using this improved version for a while.

## Inspiration sources

### Haven

Haven does not automatically start network-manager at boot time.
It provides shortcuts in the application menu to run macchanger-gtk
and start the network if desired.

### Liberte Linux

Liberte Linux randomises wireless MAC addresses at boot time and
allows changing wired interfaces' MAC addresses after boot, see their
`src/usr/local/sbin/mac-randomize` that uses `ifconfig IFACE hw ether`
rather than macchanger.

## Documentation

Investigate and possibly document the kind of information that could
still be seen on the LAN about the system. Such as the manufacturer (ex:
Sony), model number, BIOS and version, etc.?