mirror of
https://0xacab.org/anarsec/anarsec.guide.git
synced 2025-07-24 15:15:29 -04:00
fix notrace.how footnotes
This commit is contained in:
parent
cba3b08223
commit
3c2946baac
8 changed files with 27 additions and 27 deletions
|
@ -14,7 +14,7 @@ a4="tails-best-a4.pdf"
|
|||
letter="tails-best-letter.pdf"
|
||||
+++
|
||||
|
||||
This text describes some additional precautions you can take that are relevant to an anarchist [threat model](/glossary/#threat-model) — operational security for Tails. Not all anarchist threat models are the same, and only you can decide which mitigations are worth putting into practice for your activities, but we aim to provide advice that is appropriate for high-risk activities. The [No Trace Project Threat Library](https://www.notrace.how/threat-library/) is another great resource for thinking through your threat model and appropriate mitigations. If you are new to Tails, start with [Tails for Anarchists](/posts/tails/).
|
||||
This text describes some additional precautions you can take that are relevant to an anarchist [threat model](/glossary/#threat-model) — operational security for Tails. Not all anarchist threat models are the same, and only you can decide which mitigations are worth putting into practice for your activities, but we aim to provide advice that is appropriate for high-risk activities. The [No Trace Project Threat Library](https://notrace.how/threat-library/) is another great resource for thinking through your threat model and appropriate mitigations. If you are new to Tails, start with [Tails for Anarchists](/posts/tails/).
|
||||
|
||||
<!-- more -->
|
||||
|
||||
|
@ -39,7 +39,7 @@ You can mitigate this first issue by **cleaning metadata from files before shari
|
|||
|
||||
You can mitigate this second issue by what's called **"compartmentalization"**:
|
||||
|
||||
* [Compartmentalization](https://www.notrace.how/threat-library/mitigations/compartmentalization.html) means keeping different activities or projects separate. If you use Tails sessions for more than one purpose at a time, an adversary could link your different activities together. For example, if you log into different accounts on the same website in a single Tails session, the website could determine that the accounts are being used by the same person. This is because websites can tell when two accounts are using the same Tor circuit.
|
||||
* [Compartmentalization](https://notrace.how/threat-library/mitigations/compartmentalization.html) means keeping different activities or projects separate. If you use Tails sessions for more than one purpose at a time, an adversary could link your different activities together. For example, if you log into different accounts on the same website in a single Tails session, the website could determine that the accounts are being used by the same person. This is because websites can tell when two accounts are using the same Tor circuit.
|
||||
* To prevent an adversary from linking your activities while using Tails, restart Tails between different activities. For example, restart Tails between checking different project emails.
|
||||
* Tails is amnesiac by default, so to save any data from a Tails session, you must save it to a USB. If the files you save could be used to link your activities together, use a different encrypted ([LUKS](/glossary/#luks)) USB stick for each activity. For example, use one Tails USB stick for moderating a website and another for researching actions. Tails has a feature called Persistent Storage, but we do not recommend using it for data storage, explained [below](/posts/tails-best/#using-a-write-protect-switch).
|
||||
|
||||
|
@ -83,7 +83,7 @@ When using Wi-Fi in a public space, keep the following operational security cons
|
|||
|
||||
As described in the quotation above, a global adversary (i.e. the NSA) may be capable of breaking Tor through a correlation attack. If this happens, the Internet address you used in a coffee shop without CCTV cameras will only lead to your general area (e.g. your city) because it is not associated with you. Of course, this is less true if you use the location routinely. Correlation attacks are even less feasible against connections to an .onion address because you never leave the Tor network, so there is no "end" to correlate with through network traffic analysis (if the server location is unknown to the adversary). It is worth emphasizing that "End-to-end correlation attacks have been studied in research papers, but we don't know of any actual use to deanonymize Tor users."
|
||||
|
||||
What we will term a "targeted" correlation attack is possible by a non-global adversary (i.e. local law enforcement), if you are already in their sights and a target of [physical surveillance](https://www.notrace.how/threat-library/techniques/physical-surveillance/covert.html) and/or [digital surveillance](https://www.notrace.how/threat-library/techniques/targeted-digital-surveillance.html). This is a subtype of correlation attack where the presumed target is already known, thus making the attack easier to achieve because it vastly reduces the amount of data to filter through for correlation. A non-targeted correlation attack used to deanonymize a Tor user is unprecedented in current evidence used in court, although [a "targeted" correlation attack has been used](https://medium.com/beyond-install-tor-signal/case-file-jeremy-hammond-514facc780b8) as corroborating evidence — a suspect had already been identified, which allowed investigators to correlate their local footprint with specific online activity. Specifically, they correlated Tor network traffic coming from the suspect's house with the times their anonymous alias was online in chatrooms.
|
||||
What we will term a "targeted" correlation attack is possible by a non-global adversary (i.e. local law enforcement), if you are already in their sights and a target of [physical surveillance](https://notrace.how/threat-library/techniques/physical-surveillance/covert.html) and/or [digital surveillance](https://notrace.how/threat-library/techniques/targeted-digital-surveillance.html). This is a subtype of correlation attack where the presumed target is already known, thus making the attack easier to achieve because it vastly reduces the amount of data to filter through for correlation. A non-targeted correlation attack used to deanonymize a Tor user is unprecedented in current evidence used in court, although [a "targeted" correlation attack has been used](https://medium.com/beyond-install-tor-signal/case-file-jeremy-hammond-514facc780b8) as corroborating evidence — a suspect had already been identified, which allowed investigators to correlate their local footprint with specific online activity. Specifically, they correlated Tor network traffic coming from the suspect's house with the times their anonymous alias was online in chatrooms.
|
||||
|
||||
To explain how this works, it helps if you have a basic understanding of what Tor information is visible to various third parties — see the EFF's [interactive graphic](https://www.eff.org/pages/tor-and-https). For a non-targeted correlation attack, the investigator will need to **start from after Tor's exit node**: take the specific online activity coming from the exit node and try to correlate it with an enormous amount of global data that is entering Tor entry nodes. However, if a suspect is already identified, the investigator can instead do a "targeted" correlation attack and **start from before Tor's entry node**: take the data entering the entry node (via **the suspect's physical or digital footprint**) and try to correlate it with **specific online activity** coming from an exit node.
|
||||
|
||||
|
@ -91,10 +91,10 @@ A more sophisticated analysis of the specific online activity would involve logg
|
|||
|
||||
To mitigate the risk of "targeted" correlation attacks:
|
||||
|
||||
* If you only need to use the Internet briefly to submit a communique, you can **do [surveillance detection](https://www.notrace.how/threat-library/mitigations/surveillance-detection.html) and [anti-surveillance](https://www.notrace.how/threat-library/mitigations/anti-surveillance.html) before going to a coffee shop**, just like you would prior to a direct action.
|
||||
* If you only need to use the Internet briefly to submit a communique, you can **do [surveillance detection](https://notrace.how/threat-library/mitigations/surveillance-detection.html) and [anti-surveillance](https://notrace.how/threat-library/mitigations/anti-surveillance.html) before going to a coffee shop**, just like you would prior to a direct action.
|
||||
* For projects like moderating a website or hacking that require daily Internet access, it is not realistic to find a new Wi-Fi location every day. In that case, the ideal mitigation is to **use a Wi-Fi antenna from indoors** — a physical surveillance effort won't see you entering a cafe, and a digital surveillance effort won't see anything on your home Internet.
|
||||
* If a Wi-Fi antenna is too technical for you, you may even want to **use your home internet** for some projects that require frequent internet access. This contradicts the previous advice to not use your personal Wi-Fi. It's a trade-off: using Tor from home avoids creating a physical footprint that is so easy to observe, at the expense of creating a digital footprint which is more technical to observe, and may be harder to draw meaningful conclusions from (especially if you intentionally [make correlation attacks more difficult](/posts/tails/#make-correlation-attacks-more-difficult)). In our view, the main risk of using your home internet is not that the adversary is able to break Tor through a correlation attack, but that the adversary is able to hack your system, such as through [phishing](/posts/tails-best/#phishing-awareness), which [enables them to bypass Tor](/posts/qubes/#when-to-use-tails-vs-qubes-os).
|
||||
* If you want to submit a report-back the morning after a riot, or a communique shortly after an action (times when there may be a higher risk of targeted surveillance), consider waiting and at least taking surveillance detection and anti-surveillance measures beforehand. In 2010, the morning after a bank arson in Canada, police surveilled a suspect as he traveled from his home to an Internet cafe, and watched him post the communique and then bury the laptop in the woods. More recently, investigators physically surveilling [an anarchist in France](https://www.notrace.how/resources/#quelques-premiers-elements-du-dossier-d-enquete-contre-ivan) installed a hidden camera to monitor access to an Internet cafe near the comrade's home and requested CCTV footage for the day an arson communique was sent.
|
||||
* If you want to submit a report-back the morning after a riot, or a communique shortly after an action (times when there may be a higher risk of targeted surveillance), consider waiting and at least taking surveillance detection and anti-surveillance measures beforehand. In 2010, the morning after a bank arson in Canada, police surveilled a suspect as he traveled from his home to an Internet cafe, and watched him post the communique and then bury the laptop in the woods. More recently, investigators physically surveilling [an anarchist in France](https://notrace.how/resources/#quelques-premiers-elements-du-dossier-d-enquete-contre-ivan) installed a hidden camera to monitor access to an Internet cafe near the comrade's home and requested CCTV footage for the day an arson communique was sent.
|
||||
|
||||
To summarize: For sensitive and brief Internet activities, use Internet from a random cafe, preceeded by surveillance detection and anti-surveillance. For activities that require frequent internet access such that the random cafe model isn't sustainable, it's best to use a Wi-Fi antenna positioned behind a window to access from a few hundred metres away. If this is too technical for you, using your home Wi-Fi is an option, but requires putting faith in it being difficult to break Tor with a non-targeted correlation attack, and it being difficult to draw meaningful conclusions from your home's Tor traffic through a "targeted" correlation attack.
|
||||
|
||||
|
@ -209,7 +209,7 @@ Our recommendations are:
|
|||
|
||||
> **Tip**
|
||||
>
|
||||
> Diceware passphrases can be easy to forget if you have several to keep track of, especially if you use them infrequently. To reduce the risk of forgetting a diceware passphrase, you can store all "memorized" passphrases on a LUKS USB that you create using Tails, which is hidden somewhere off-site where it won't be recovered during a police raid. You should be able to reconstruct the LUKS passphrase if a lot of time has passed. See the [No Trace Project](https://www.notrace.how/threat-library/mitigations/digital-best-practices.html) for two different approaches you can take: one relies on a trusted comrade, and the other is self-sufficient. As with all important backups, you should have at least two.
|
||||
> Diceware passphrases can be easy to forget if you have several to keep track of, especially if you use them infrequently. To reduce the risk of forgetting a diceware passphrase, you can store all "memorized" passphrases on a LUKS USB that you create using Tails, which is hidden somewhere off-site where it won't be recovered during a police raid. You should be able to reconstruct the LUKS passphrase if a lot of time has passed. See the [No Trace Project](https://notrace.how/threat-library/mitigations/digital-best-practices.html) for two different approaches you can take: one relies on a trusted comrade, and the other is self-sufficient. As with all important backups, you should have at least two.
|
||||
|
||||
For Tails, you need to memorize two passphrases:
|
||||
|
||||
|
@ -220,7 +220,7 @@ If you are using Persistent Storage, this is another passphrase that you will ha
|
|||
|
||||
## Encrypted containers
|
||||
|
||||
[LUKS](/glossary/#luks) is great, but defense-in-depth can't hurt. If the police seize your USB in a house raid, they will try a [variety of tactics to bypass the authentication](https://www.notrace.how/threat-library/techniques/targeted-digital-surveillance/authentication-bypass.html), so a second layer of defense with a different encryption implementation can be useful for highly sensitive data.
|
||||
[LUKS](/glossary/#luks) is great, but defense-in-depth can't hurt. If the police seize your USB in a house raid, they will try a [variety of tactics to bypass the authentication](https://notrace.how/threat-library/techniques/targeted-digital-surveillance/authentication-bypass.html), so a second layer of defense with a different encryption implementation can be useful for highly sensitive data.
|
||||
|
||||
|
||||
[Gocryptfs](https://nuetzlich.net/gocryptfs/) is an encrypted container program that is [available for Debian](https://packages.debian.org/bullseye/gocryptfs) and can be easily installed as [additional software](/posts/tails/#optional-create-and-configure-persistent-storage). If you don't want to reinstall it every session, you will need to [configure Additional Software in Persistent Storage](/posts/tails-best/#using-a-write-protect-switch).
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue