Thank you for your interest in Tails. Installing Tails can be quite long but we hope you will still have a good time:) We will first ask you a few questions to choose your installation scenario and then guide you step by step. Step by step instructions on how to download and verify Tails OS 4.2, burn it to a USB drive and run it from this flash drive on your Apple Mac OS X and then use the Tor Browser for the optimal.
- Restrictions
- Threat model
- Use case analysis
- Using Tails at a friend's place
- Using Tails at a restricted public network
- Using Tails at an open public network
- How to spoof the MAC address
- Implementation
- Trigger
- MAC changing tool
The uniqueness of MAC addresses introduce two types ofpotential issues for Tails users, in particular if the MAC address canbe linked to the user's identity:
Geographical location tracking: A time-stamped log of a MAC addressties a device to a certain location at a particular time. If thedevice's owner is known, his or her movements are also known. Incase an unknown owner, the tracked movements leak information aboutthe owner, which eventually may lead to identification.
Identify Tails (or Tor) users: If the usage of Tails (or Tor) canbe fingerprinted on the network (despite other measures taken), andthe owner of a device is known, it can be determined that the owneralso is a Tails (or Tor) user.
Spoofing the MAC address is the natural solution. Unfortunately, insome cases MAC spoofing may cause network connection issues or evenraise alarms; care should be taken to prevent MAC spoofing in suchsituations.
While some of the following concerns are related to MAC spoofing (orvery similar in spirit) they are not covered in this feature.
IMEI
IMEI numbers is another unique modifier affecting mobilenetwork devices (e.g. 3G, but not Wi-Fi) that is very similar to MACaddresses and can be used by adversaries in similar ways. Given thissimilarity we'd like to deal with IMEI spoofing (or similar) in thisfeature but the lack of proper tools prevent us from doing itproperly.
Pre-OS network activity
It should be noted that we cannot do anything against network activitycaused at BIOS time, such as Intel AMT, beyond urgingusers to disable such features (if possible, like it is for Intel AMT).
Profiling based on chipset/driver particularities
It's possible to profile the particular chipset and/or driver used bya device based on the active probing algorithm used, and itsparameters (e.g. channel probe order, how many probes sent perchannel, time spend per channel). See for instance the paperA Characterization of Wireless NIC Active Scanning Algorithms.
Dealing with this may be impossible, or at least require re-writingall Linux wireless drivers so that the parameters can be changed so wecannot practically deal with this issue at this point.
Adversary capabilities
The adversary's capabilities are assumed to be:
Omniscient wireless snooping of when and where (via triangulation)all MAC addresses are used. Also access to Time-stamped logs of thepresence of MAC addresses on all wired networks (think compromisedrouters and/or ISP:s). [AdvCapSniff]
Has access, on specific request, to all user/customer records andsurveillance data of any public network. [AdvCapRecords]
Knows who owns which MAC address according to the last traceabletransaction (e.g. credit card trail). Cash purchase, trade, trashsalvaging or theft are ways to potentially avoid this but theadversary can interrogate the previous owner to obtain thatinformation if remembered (or at all known). [AdvCapOwners]
Adversary goals
We assume an adversary whose goals are the following, which allhappens on a global, omniscient level thanks to AdvCapSniff:
Monitoring of when and where a particular MAC address with a knownowner is used. In other words, monitoring of an individual'sgeographical movement while using a certain device (thanks toAdvCapOwners). [AdvGoalTracking]
Dragnet-style logging of when and where MAC addresses with unknownowners are used for large-scale social graphing and profiling whichleaks information owners' identities. [AdvGoalProfiling]
Identify Tails (and Tor) users. If Tails (or Tor) usageAdv can befingerprinted, then that fact is documented about a particularindividual (thanks to AdvCapOwners). [AdvGoalIdTails]
Identify MAC spoofing individuals. We assume that our adversary hasbought into the 'nothing to hide' argument, which makes suchsuspicious behaviour valuable information. [AdvGoalIdMacSpoof]
Tails user goals
Hide geographical movement, i.e. prevent AdvGoalTracking andAdvGoalProfiling. [AvoidTracking]
No unspoofed usage of Tails (or Tor), i.e. prevent AdvGoalIdTails.[AvoidIdTails]
Not raising alarms on the network, i.e. prevent AdvGoalIdMacSpoof,but also avoid alarming the local administrators (imagine asituation where security guards are sent to investigate an 'aliencomputer' at your workplace, or similar). Mozilla firefox for mac os download. [AvoidIdMacSpoof]
Avoid network connection problems due to MAC address white-listing,fixed ARP tables, hardware or driver issues, orsimilar. [AvoidConnectionProbs]
Below we analyse how MAC address spoofing relates to each user goalfor the given situation.
Tails Os Usb Mac
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 Tailsdoesn't matter; the location is already directly related to the user'sidentity. Similarly, because of this, MAC spoofing is of very limitedvalue for both AvoidTracking and AvoidIdTails value.
MAC spoofing could hinder AvoidIdMacSpoof if detected by the ISP'shardware (i.e. no trusted router in the way). Similarly, ISP-providedhardware may employ some sort of MAC address white-listing (e.g. onlyX unique ones are allowed) that can prevent AvoidConnectionProbs.
Summary: MAC spoofing should be avoided but isn't terribly dangerousif enabled.
Using Tails at a friend's place
Using your computer
MAC spoofing should be enabled for both AvoidTracking andAvoidIdTails. AvoidIdMacSpoof won't be your problem but your friend's(which isn't a problem at all unless you're there spoofing all thetime). AvoidConnectionProbs can be problematic for the same reasons asin 'Using Tails at home'.
Summary: Enable MAC spoofing!
Using any other computer
Since the computer you use isn't tied to you, AvoidTracking andAvoidIdTails aren't relevant. AvoidIdMacSpoof won't be your problem butyour friend's. AvoidConnectionProbs can be problematic for the samereasons as in 'Using Tails at home'.
Summary: MAC spoofing should be avoided but isn't terribly dangerousif 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. universitycomputer labs and workplaces) to access.
This should probably also cover otherwise unrestricted networks thatsnoops on users in other ways, e.g. a library with video camerasurveillance.
Using your computer
Since the user is registered for network access, both AvoidTrackingand AvoidIdTails are hard to get. However, AdvCapRecords requiresexplicit targeting (more expensive), while AdvCapSniff isn't, and MACspoofing would defeat the latter, so it's not without merit.
AvoidIdMacSpoof could be problematic if your registered presence on thenetwork is correlated to constantly new MAC addresses. A quite likelysituation for this case is that you login via some captive portal, andthese often use your MAC address for access control purposes, so a logof which you have used
AvoidConnectionProbs is a problem if your MAC address becomes part ofyour registration, and is assumed to not change (maybe a place whereyou have to pay for each device you connect with). This seems prettyfar-fetched, though.
Summary: There's no easy choice here but in most scenariosAvoidTracking is probably more valuable than AvoidIdMacSpoof, so MACspoofing should be enabled.
Using a public computer
Since the computer isn't tied to you, MAC spoofing does nothing toAvoidTracking and AvoidIdTails. It could cause problems to bothAvoidIdMacSpoof and AvoidConnectionProbs.
Summary: MAC spoofing should be avoided but isn't terribly dangerousif 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 andAvoidIdTails. Such a network should expect to see many unique MACaddresses daily, and be ready to deal with it, so AvoidIdMacSpoof andAvoidConnectionProbs 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 dangerousif enabled.
Conclusions
The strong requirement of enabling MAC spoofing in a few cases, andthe low risk of keeping it enabled even in the cases where it shouldbe avoided, warrants for making this feature enabled by default, withthe possibility to opt-out.
It is conceivable that NICs may send packets before the user has madea decision about whether to use MAC spoofing or not. In fact, someoneon tails-dev@alludedto this being possible for wireless NICs although without anyreferences (this may refer to so called 'active probing'; see sectionbelow). If this is the case it at the very least implies that we mustenforce the MAC spoofing setting as early as possible.
However, since we (obviously) cannot foresee the user's decision we geta problematic time frame between when a network device is added duringearly boot and when the user makes the decision later on. Enforcing adefault MAC spoofing setting immediately when a network device isadded, that then potentially is reversed when the user makes thedecision, leads to problems in some scenarios if we assume these earlyleaks happen:
If MAC spoofing is enabled before the user has made the decision, afake MAC address would leak before the user made the decision, andthe decision was to disable MAC spoofing. The sudden switch of MACaddress may result in a breach of AvoidIdMacSpoof.
If MAC spoofing is disabled before the user has made the decision, thereal MAC address would leak even if the user wanted MAC spoofingenabled, which leaks to breaches of AvoidTracking and AvoidIdTails.The sudden switch of MAC address may result in a breach ofAvoidIdMacSpoof.
The real solution is therefore to eliminate the problematic this timeframe completely by preventing any network devices from being enabledat all until the decision has been made, and have the MAC spoofingsetting applied immediately when the device is added.
No protection against this is implemented yet
There's an opportunity for an adversary to achieve AdvGoalTracking andAdvGoalProfiling due to 'active probing' performed by NetworkManagerfor 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 wirelessnetworks, which is entirely safe. Active scanning, however, activelysends probes for any known networks. In our case these are the savedconnections in NetworkManager, so this turns especially problematicwhen persistent NM connections are used; the list of (up to 5, as ofNetworkmanager 1.4.2) networks actively probed for can be used asa fingerprint by an adversary, breaching AvoidTracking.
While this has nothing to do with MAC spoofing, it does stronglyaffect the (arguably) most important user goal of this feature, namelyAvoidTracking. Because of this, active scanning should be disabled inNetworkManager when MAC spoofing is enabled: #6453.
Spoofing the OUI part of the MAC address
This is currently not implemented. See theLimitation: Only spoof the NIC part of the MAC addresssection below.
The first three bytes of a MAC address determine the Organizationally Unique Identifier(OUI) which in practice determines the chipset's manufacturer, whogenerally owns several OUIs. Spoofing the OUI part in a way thatsatisfies our threat model is not straightforward because ofAvoidIdMacSpoof since multiple, large categories of OUIs violatethat user goal:
Unregistered OUI so it's not used for any real device.
Registered OUI that was never used for any device.
Registered OUI that is used for special purpose devices unlikely tobe used on most networks, e.g. NICs only used in ATMs, vendingmachines or embedded devices.
Registered OUI used for NICs in normal computers but for a differenttype of NIC than the device being spoofed. This is only relevantwhen this difference actually can be detected by the adversary, likewith wired vs. wireless.
Registered OUI used for NICs in normal computers but they weremanufactured decades ago.
Registered OUI used for NICs in normal computers but whosedistribution is limited to some restricted, geographical area.
Registered OUI used for NICs in normal computers but that simply isvery rare.
Great care should be taken when picking the OUI to avoid thesecategories. The whole point is to randomly pick an OUI that theadversary expects to see. In particular the OUI should be one used forcommon, consumer oriented hardware.
Spoofing the NIC part of the MAC address
The last three bytes of the MAC address are meant to distinguishindividual devices among those with the same OUI. These should simplybe selected at random, with the exception that we never allow it tostay the same, even if done in a fair, random way. Theoreticallyspeaking this leaks up to 24/2^24 bits of the NIC part of the realMAC address per Tails session but in practice the complete NIC part isleaked to adversaries that do not anticipate MAC spoofing, which ismuch worse.
The current implementation leaves the OUI part unchanged, and only spoofs thelast three bytes of any network device's MAC address immediately afterit is added by udev. Furthermore, to deal with potential network leaksbefore the user has chosen whether to enable MAC spoofing or not, theaddition of network devices is delayed until after the Welcome Screen knowsthe user's final decision.
Network blocking
As suggested in the 'Leak prevention' section, we block all networkdevices' modules from being loaded until the user has made the decision aboutwhether to enable MAC spoofing or not. The way we do this is bygenerating a list of all network device modules during build time, andadd these to a modprobe.d-type blacklist. An implication of this isthat in-kernel drivers and modules installed after build time will notbe in the blacklist and hence are not supported. In the Welcome Screen'spost-login script (when we know the user's decision) we unblock thenetwork by simply removing that list, and then we have udev 're-probe'for network devices and load their modules.
Scripts:
config/chroot local-hooks/80-block-network (runs atbuild time)
config/chroot local-includes/etc/gdm3/PostLogin/Default (where
tails-unblock-networkis started)
Trigger
We use udev as the trigger that hooks MAC address spoofing. Because ofthat, it happens for every Ethernet device automatically, as early aspossible (i.e. immediately after it's added), so even if there's somekind of weird leak before a device is up:ed the real MAC addressshouldn't leak.
Hook: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 useNetworManager the exact behaviour is blurred and not particularlywell-documented. It doesn't feel robust for this reason.Hence, we leave the macchanger package's built-in way to spoofMAC addresses disabled.
NetworkManager hook: NM doesn't trigger events equivalent toif-pre-up, so this isn't possible. See the commented parts in:
/etc/NetworkManager/dispatcher.d/01ifupdown. Note thatNetworkManager 0.9.10 introduces pre-up hooks, but they're used to'allow scripts to execute before NetworkManager announcesconnectivity to applications' (according to a blogpostby Dan William), that is, after network activity (e.g.DHCP requests) has already occurred.NetworkManager's own support for MAC address randomization: see#11293 for details. We explicitly disable
cloned-mac-addresshandling, as the default on Debian Stretchis to reset the MAC address to the permanent one:config/chroot local-includes/etc/NetworkManager/conf.d/spoof-mac.conf.systemd integration: We did not use systemd yet back when we madethis design decision.
NetworkManager plugin: While this certainly would have a nice impactoutside of Tails, the added maintenance burden makes it lessattractive.
MAC changing tool
The tool used to change the MAC address is simply macchanger, mostlybecause it's in Debian (where the known vulnerabilities are patched)and macchiato isn't (andit's not as well tested, yet). macchanger isused in a very straightforward way, so if we want to switch tool inthe future it's a simple task.
Helper scripts:config/chroot local-includes/usr/local/lib/tails-spoof-mac
Limitation: Only spoof the NIC part of the MAC address
To put the categories listed in the 'Spoofing the OUI part of the MACaddress' section into context, let's look at macchanger'soptions. Among the ones that some how modifies the OUI part of the MACaddress (-r, -a and -A) all have a significant probability ofpicking an OUI from the problematic categories that violate theAvoidIdMacSpoof user goal.
Another MAC spoofing tool,macchiato, takes thisto the next level by maintaining lists of 'common enough' OUIs fordifferent categories of devices so a less suspicious choice of OUI canbe made. However, the verification of the OUI being 'common enough'lands on 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 its homepage, or the author's request onreddit.
Another issue is that macchiato's lists do not take into accountthat some devices are pretty much only used in some geographicalareas. Note that collecting such data probably is orders of magnitudeharder than macchiato's current quest, and that the user interfacewould be further complicated (in Tails we'd have to ask for thecurrent geographical location in the Welcome Screen, or similar). The realimpact of this should be evaluated; it's very likely that the benefitsstill outweigh this risk.
To end with, macchiato's lists are very small with only ~20 OUIs inmost of the relevant categories as of the current Git state (commit90fa147d), 2014-04-25. The exact impact of this is notwell-understood. This is probably the main blocker for Tails to switchto macchiato and dare saying we satisfy the 'Spoofing the OUI partof the MAC address' requirement from above.
What remains is to only spoof the latter three bytes, the NIC part. Weknow it isn't a perfect strategy. The more uncommon the OUI of auser's device is, the more it can be used for tracking the user, i.e.the more it violates the AvoidTracking user goal. At least thiscomes with some uncertainty compared to many of the impossible choicesof OUI listed above, which would guarantee widespread violation ofAvoidIdMacSpoof among Tails users, so this seems like a reasonabletradeoff at the moment.
MAC spoofing fail safe
For any network device, the MAC address is recorded both before andafter the actual MAC spoofing. If the values are equal, or if theycould not be obtained, we fail closed by going into 'panic mode' forthe device. This means that the device is down:ed, and its module isunloaded and blacklisted. If the network device's interface stillexists after this, networking is completely disabled by shutting downNetworkManager. The user is notified of which device was the culprit,and whether the module was unloaded, or if the network was completelydisabled.
Note that we treat the perfectly fine macchanger behaviour ofrandomly picking the real MAC address as a failure. Since we randomisethe lower 3 bytes of the MAC address there's a 1/2^24 chance forthis happening for each device. To make it a bit less frequent (!) werepeat the MAC spoofing until a new address is obtained, with up tothree tries.
Script:config/chroot local-includes/usr/local/lib/tails-spoof-mac
Connection failure detection
This section deals with AvoidConnectionProbs. The goal is to somehowidentify connection errors that are related to MAC spoofing, andnotify the user when this happens.
Note: the implementation described below had to be disabled:
IMEI numbers is another unique modifier affecting mobilenetwork devices (e.g. 3G, but not Wi-Fi) that is very similar to MACaddresses and can be used by adversaries in similar ways. Given thissimilarity we'd like to deal with IMEI spoofing (or similar) in thisfeature but the lack of proper tools prevent us from doing itproperly.
Pre-OS network activity
It should be noted that we cannot do anything against network activitycaused at BIOS time, such as Intel AMT, beyond urgingusers to disable such features (if possible, like it is for Intel AMT).
Profiling based on chipset/driver particularities
It's possible to profile the particular chipset and/or driver used bya device based on the active probing algorithm used, and itsparameters (e.g. channel probe order, how many probes sent perchannel, time spend per channel). See for instance the paperA Characterization of Wireless NIC Active Scanning Algorithms.
Dealing with this may be impossible, or at least require re-writingall Linux wireless drivers so that the parameters can be changed so wecannot practically deal with this issue at this point.
Adversary capabilities
The adversary's capabilities are assumed to be:
Omniscient wireless snooping of when and where (via triangulation)all MAC addresses are used. Also access to Time-stamped logs of thepresence of MAC addresses on all wired networks (think compromisedrouters and/or ISP:s). [AdvCapSniff]
Has access, on specific request, to all user/customer records andsurveillance data of any public network. [AdvCapRecords]
Knows who owns which MAC address according to the last traceabletransaction (e.g. credit card trail). Cash purchase, trade, trashsalvaging or theft are ways to potentially avoid this but theadversary can interrogate the previous owner to obtain thatinformation if remembered (or at all known). [AdvCapOwners]
Adversary goals
We assume an adversary whose goals are the following, which allhappens on a global, omniscient level thanks to AdvCapSniff:
Monitoring of when and where a particular MAC address with a knownowner is used. In other words, monitoring of an individual'sgeographical movement while using a certain device (thanks toAdvCapOwners). [AdvGoalTracking]
Dragnet-style logging of when and where MAC addresses with unknownowners are used for large-scale social graphing and profiling whichleaks information owners' identities. [AdvGoalProfiling]
Identify Tails (and Tor) users. If Tails (or Tor) usageAdv can befingerprinted, then that fact is documented about a particularindividual (thanks to AdvCapOwners). [AdvGoalIdTails]
Identify MAC spoofing individuals. We assume that our adversary hasbought into the 'nothing to hide' argument, which makes suchsuspicious behaviour valuable information. [AdvGoalIdMacSpoof]
Tails user goals
Hide geographical movement, i.e. prevent AdvGoalTracking andAdvGoalProfiling. [AvoidTracking]
No unspoofed usage of Tails (or Tor), i.e. prevent AdvGoalIdTails.[AvoidIdTails]
Not raising alarms on the network, i.e. prevent AdvGoalIdMacSpoof,but also avoid alarming the local administrators (imagine asituation where security guards are sent to investigate an 'aliencomputer' at your workplace, or similar). Mozilla firefox for mac os download. [AvoidIdMacSpoof]
Avoid network connection problems due to MAC address white-listing,fixed ARP tables, hardware or driver issues, orsimilar. [AvoidConnectionProbs]
Below we analyse how MAC address spoofing relates to each user goalfor the given situation.
Tails Os Usb Mac
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 Tailsdoesn't matter; the location is already directly related to the user'sidentity. Similarly, because of this, MAC spoofing is of very limitedvalue for both AvoidTracking and AvoidIdTails value.
MAC spoofing could hinder AvoidIdMacSpoof if detected by the ISP'shardware (i.e. no trusted router in the way). Similarly, ISP-providedhardware may employ some sort of MAC address white-listing (e.g. onlyX unique ones are allowed) that can prevent AvoidConnectionProbs.
Summary: MAC spoofing should be avoided but isn't terribly dangerousif enabled.
Using Tails at a friend's place
Using your computer
MAC spoofing should be enabled for both AvoidTracking andAvoidIdTails. AvoidIdMacSpoof won't be your problem but your friend's(which isn't a problem at all unless you're there spoofing all thetime). AvoidConnectionProbs can be problematic for the same reasons asin 'Using Tails at home'.
Summary: Enable MAC spoofing!
Using any other computer
Since the computer you use isn't tied to you, AvoidTracking andAvoidIdTails aren't relevant. AvoidIdMacSpoof won't be your problem butyour friend's. AvoidConnectionProbs can be problematic for the samereasons as in 'Using Tails at home'.
Summary: MAC spoofing should be avoided but isn't terribly dangerousif 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. universitycomputer labs and workplaces) to access.
This should probably also cover otherwise unrestricted networks thatsnoops on users in other ways, e.g. a library with video camerasurveillance.
Using your computer
Since the user is registered for network access, both AvoidTrackingand AvoidIdTails are hard to get. However, AdvCapRecords requiresexplicit targeting (more expensive), while AdvCapSniff isn't, and MACspoofing would defeat the latter, so it's not without merit.
AvoidIdMacSpoof could be problematic if your registered presence on thenetwork is correlated to constantly new MAC addresses. A quite likelysituation for this case is that you login via some captive portal, andthese often use your MAC address for access control purposes, so a logof which you have used
AvoidConnectionProbs is a problem if your MAC address becomes part ofyour registration, and is assumed to not change (maybe a place whereyou have to pay for each device you connect with). This seems prettyfar-fetched, though.
Summary: There's no easy choice here but in most scenariosAvoidTracking is probably more valuable than AvoidIdMacSpoof, so MACspoofing should be enabled.
Using a public computer
Since the computer isn't tied to you, MAC spoofing does nothing toAvoidTracking and AvoidIdTails. It could cause problems to bothAvoidIdMacSpoof and AvoidConnectionProbs.
Summary: MAC spoofing should be avoided but isn't terribly dangerousif 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 andAvoidIdTails. Such a network should expect to see many unique MACaddresses daily, and be ready to deal with it, so AvoidIdMacSpoof andAvoidConnectionProbs 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 dangerousif enabled.
Conclusions
The strong requirement of enabling MAC spoofing in a few cases, andthe low risk of keeping it enabled even in the cases where it shouldbe avoided, warrants for making this feature enabled by default, withthe possibility to opt-out.
It is conceivable that NICs may send packets before the user has madea decision about whether to use MAC spoofing or not. In fact, someoneon tails-dev@alludedto this being possible for wireless NICs although without anyreferences (this may refer to so called 'active probing'; see sectionbelow). If this is the case it at the very least implies that we mustenforce the MAC spoofing setting as early as possible.
However, since we (obviously) cannot foresee the user's decision we geta problematic time frame between when a network device is added duringearly boot and when the user makes the decision later on. Enforcing adefault MAC spoofing setting immediately when a network device isadded, that then potentially is reversed when the user makes thedecision, leads to problems in some scenarios if we assume these earlyleaks happen:
If MAC spoofing is enabled before the user has made the decision, afake MAC address would leak before the user made the decision, andthe decision was to disable MAC spoofing. The sudden switch of MACaddress may result in a breach of AvoidIdMacSpoof.
If MAC spoofing is disabled before the user has made the decision, thereal MAC address would leak even if the user wanted MAC spoofingenabled, which leaks to breaches of AvoidTracking and AvoidIdTails.The sudden switch of MAC address may result in a breach ofAvoidIdMacSpoof.
The real solution is therefore to eliminate the problematic this timeframe completely by preventing any network devices from being enabledat all until the decision has been made, and have the MAC spoofingsetting applied immediately when the device is added.
No protection against this is implemented yet
There's an opportunity for an adversary to achieve AdvGoalTracking andAdvGoalProfiling due to 'active probing' performed by NetworkManagerfor 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 wirelessnetworks, which is entirely safe. Active scanning, however, activelysends probes for any known networks. In our case these are the savedconnections in NetworkManager, so this turns especially problematicwhen persistent NM connections are used; the list of (up to 5, as ofNetworkmanager 1.4.2) networks actively probed for can be used asa fingerprint by an adversary, breaching AvoidTracking.
While this has nothing to do with MAC spoofing, it does stronglyaffect the (arguably) most important user goal of this feature, namelyAvoidTracking. Because of this, active scanning should be disabled inNetworkManager when MAC spoofing is enabled: #6453.
Spoofing the OUI part of the MAC address
This is currently not implemented. See theLimitation: Only spoof the NIC part of the MAC addresssection below.
The first three bytes of a MAC address determine the Organizationally Unique Identifier(OUI) which in practice determines the chipset's manufacturer, whogenerally owns several OUIs. Spoofing the OUI part in a way thatsatisfies our threat model is not straightforward because ofAvoidIdMacSpoof since multiple, large categories of OUIs violatethat user goal:
Unregistered OUI so it's not used for any real device.
Registered OUI that was never used for any device.
Registered OUI that is used for special purpose devices unlikely tobe used on most networks, e.g. NICs only used in ATMs, vendingmachines or embedded devices.
Registered OUI used for NICs in normal computers but for a differenttype of NIC than the device being spoofed. This is only relevantwhen this difference actually can be detected by the adversary, likewith wired vs. wireless.
Registered OUI used for NICs in normal computers but they weremanufactured decades ago.
Registered OUI used for NICs in normal computers but whosedistribution is limited to some restricted, geographical area.
Registered OUI used for NICs in normal computers but that simply isvery rare.
Great care should be taken when picking the OUI to avoid thesecategories. The whole point is to randomly pick an OUI that theadversary expects to see. In particular the OUI should be one used forcommon, consumer oriented hardware.
Spoofing the NIC part of the MAC address
The last three bytes of the MAC address are meant to distinguishindividual devices among those with the same OUI. These should simplybe selected at random, with the exception that we never allow it tostay the same, even if done in a fair, random way. Theoreticallyspeaking this leaks up to 24/2^24 bits of the NIC part of the realMAC address per Tails session but in practice the complete NIC part isleaked to adversaries that do not anticipate MAC spoofing, which ismuch worse.
The current implementation leaves the OUI part unchanged, and only spoofs thelast three bytes of any network device's MAC address immediately afterit is added by udev. Furthermore, to deal with potential network leaksbefore the user has chosen whether to enable MAC spoofing or not, theaddition of network devices is delayed until after the Welcome Screen knowsthe user's final decision.
Network blocking
As suggested in the 'Leak prevention' section, we block all networkdevices' modules from being loaded until the user has made the decision aboutwhether to enable MAC spoofing or not. The way we do this is bygenerating a list of all network device modules during build time, andadd these to a modprobe.d-type blacklist. An implication of this isthat in-kernel drivers and modules installed after build time will notbe in the blacklist and hence are not supported. In the Welcome Screen'spost-login script (when we know the user's decision) we unblock thenetwork by simply removing that list, and then we have udev 're-probe'for network devices and load their modules.
Scripts:
config/chroot local-hooks/80-block-network (runs atbuild time)
config/chroot local-includes/etc/gdm3/PostLogin/Default (where
tails-unblock-networkis started)
Trigger
We use udev as the trigger that hooks MAC address spoofing. Because ofthat, it happens for every Ethernet device automatically, as early aspossible (i.e. immediately after it's added), so even if there's somekind of weird leak before a device is up:ed the real MAC addressshouldn't leak.
Hook: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 useNetworManager the exact behaviour is blurred and not particularlywell-documented. It doesn't feel robust for this reason.Hence, we leave the macchanger package's built-in way to spoofMAC addresses disabled.
NetworkManager hook: NM doesn't trigger events equivalent toif-pre-up, so this isn't possible. See the commented parts in:
/etc/NetworkManager/dispatcher.d/01ifupdown. Note thatNetworkManager 0.9.10 introduces pre-up hooks, but they're used to'allow scripts to execute before NetworkManager announcesconnectivity to applications' (according to a blogpostby Dan William), that is, after network activity (e.g.DHCP requests) has already occurred.NetworkManager's own support for MAC address randomization: see#11293 for details. We explicitly disable
cloned-mac-addresshandling, as the default on Debian Stretchis to reset the MAC address to the permanent one:config/chroot local-includes/etc/NetworkManager/conf.d/spoof-mac.conf.systemd integration: We did not use systemd yet back when we madethis design decision.
NetworkManager plugin: While this certainly would have a nice impactoutside of Tails, the added maintenance burden makes it lessattractive.
MAC changing tool
The tool used to change the MAC address is simply macchanger, mostlybecause it's in Debian (where the known vulnerabilities are patched)and macchiato isn't (andit's not as well tested, yet). macchanger isused in a very straightforward way, so if we want to switch tool inthe future it's a simple task.
Helper scripts:config/chroot local-includes/usr/local/lib/tails-spoof-mac
Limitation: Only spoof the NIC part of the MAC address
To put the categories listed in the 'Spoofing the OUI part of the MACaddress' section into context, let's look at macchanger'soptions. Among the ones that some how modifies the OUI part of the MACaddress (-r, -a and -A) all have a significant probability ofpicking an OUI from the problematic categories that violate theAvoidIdMacSpoof user goal.
Another MAC spoofing tool,macchiato, takes thisto the next level by maintaining lists of 'common enough' OUIs fordifferent categories of devices so a less suspicious choice of OUI canbe made. However, the verification of the OUI being 'common enough'lands on 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 its homepage, or the author's request onreddit.
Another issue is that macchiato's lists do not take into accountthat some devices are pretty much only used in some geographicalareas. Note that collecting such data probably is orders of magnitudeharder than macchiato's current quest, and that the user interfacewould be further complicated (in Tails we'd have to ask for thecurrent geographical location in the Welcome Screen, or similar). The realimpact of this should be evaluated; it's very likely that the benefitsstill outweigh this risk.
To end with, macchiato's lists are very small with only ~20 OUIs inmost of the relevant categories as of the current Git state (commit90fa147d), 2014-04-25. The exact impact of this is notwell-understood. This is probably the main blocker for Tails to switchto macchiato and dare saying we satisfy the 'Spoofing the OUI partof the MAC address' requirement from above.
What remains is to only spoof the latter three bytes, the NIC part. Weknow it isn't a perfect strategy. The more uncommon the OUI of auser's device is, the more it can be used for tracking the user, i.e.the more it violates the AvoidTracking user goal. At least thiscomes with some uncertainty compared to many of the impossible choicesof OUI listed above, which would guarantee widespread violation ofAvoidIdMacSpoof among Tails users, so this seems like a reasonabletradeoff at the moment.
MAC spoofing fail safe
For any network device, the MAC address is recorded both before andafter the actual MAC spoofing. If the values are equal, or if theycould not be obtained, we fail closed by going into 'panic mode' forthe device. This means that the device is down:ed, and its module isunloaded and blacklisted. If the network device's interface stillexists after this, networking is completely disabled by shutting downNetworkManager. The user is notified of which device was the culprit,and whether the module was unloaded, or if the network was completelydisabled.
Note that we treat the perfectly fine macchanger behaviour ofrandomly picking the real MAC address as a failure. Since we randomisethe lower 3 bytes of the MAC address there's a 1/2^24 chance forthis happening for each device. To make it a bit less frequent (!) werepeat the MAC spoofing until a new address is obtained, with up tothree tries.
Script:config/chroot local-includes/usr/local/lib/tails-spoof-mac
Connection failure detection
This section deals with AvoidConnectionProbs. The goal is to somehowidentify connection errors that are related to MAC spoofing, andnotify the user when this happens.
Note: the implementation described below had to be disabled:
Due to lack of hooks into NetworkManager's connection error handlingwe currently use a simple monitoring script that's started when MACspoofing is enabled. It scans the NetworkManager unit's journal forthe error message patterns expected when the connectionfails due to MAC spoofing. When such a pattern is found, anotification is shown to the user, stating that the connection problemmay be MAC spoofing related. Due to the uncertainty and lack ofinformation available for this approach, there certainly will be falsepositives.
At the moment this script only deals with wireless connections. Itsuccessfully distinguishes between MAC-spoof related errors and errorswhen entering the wrong passphrase, so no false positives in that(relatively common) case.
Tails Os For Mac Os
Wi-Fi scanning
During Wi-Fi access point scanning, NetworkManager randomizes MACaddresses (wifi.scan-rand-mac-address), so the MAC address used forscanning is different from the one later used to connect to a Wi-Fiaccess point. This makes it slightly harder to correlate scanningactivity with actual connections to a Wi-Fi network.
