Let’s talk about security
</div><p>Post by: astor on August 14, 2013, 03:06 am
In the wake of the Freedom Hosting exploit, I think we should reevaluate our threat model and update our security to better protect ourselves against the real threats that we face. So I wrote this guide in order to spark a conversation. It is by no means comprehensive. I only focus on technical security. Perhaps others can address shipping and financial security. I welcome feedback and would like these ideas to be critiqued and expanded.</p>
As I was thinking about writing this guide, I decided to take a step back and ask a basic question: what are our goals? I’ve come up with two basic goals that we want to achieve with our technical security.
1. Avoid being identified.
2. Minimize the damage when we are identified.
You can think of these as our _guiding security principles_. If you have a technical security question, you may be able to arrive at an answer by asking yourself these questions:
1. Does using this technology increase or decrease the chances that I will be identified?
2. Does using this technology increase or decrease the damage (eg, the evidence that can be used against me) when I am identified?
Obviously, you will need to understand the underlying technology to answer these questions.
The rest of this guide explains the broad technological features that decrease the chances we are identified and that minimize the damage when we are identified. Towards the end I list specific technologies and evaluate them based on these features.
First, let me list the broad features that I have come up with, then I will explain them.
1. Simplicity
2. Trustworthiness
3. Minimal execution of untrusted code
4. Isolation
5. Encryption
To some extent, we’ve been focusing on the wrong things. I’ve predominantly been concerned with network layer attacks, or “attacks on the Tor network”, but it seems clear to me now that application layer attacks are far more likely to identify us. The applications that we run over Tor are a much bigger attack surface than Tor itself. We can minimize our chances of being identified by securing the applications that we run over Tor. This observation informs the first four features that we desire.
===Simplicity===
Short of not using computers at all, we can minimize threats against us by simplifying the technological tools that we use. A smaller code base is less likely to have bugs, including deanonymizing vulnerabilities. A simpler application is less likely to behave in unexpected and unwanted ways.
As an example, when the Tor Project evaluated the traces left behind by the browser bundle, they found 4 traces on Debian Squeeze, which uses the Gnome 2 desktop environment, and 25 traces on Windows 7. It’s clear that Windows 7 is more complex and behaves in more unexpected ways than Gnome 2. Through its complexity alone, Windows 7 increases your attack surface, exposing you to more potential threats. (Although there are other ways that Windows 7 makes you more vulnerable, too.) The traces left behind on Gnome 2 are easier to prevent than the traces left behind on Windows 7, so at least with regard to this specific threat, Gnome 2 is desirable over Windows 7.
So, when evaluating a new technological tool for simplicity, ask yourself these questions:
Is it more or less complex than the tool I’m currently using?
Does it perform more or fewer (unnecessary) functions than the tool I’m currently using?
===Trustworthiness===
We should favor technologies that are built by professionals or people with many years of experience rather than newbs. A glaring example of this is CryptoCat, which was developed by a well-intentioned hobbyist programmer, and has suffered severe criticism because of the many vulnerabilities that have been discovered.
We should favor technologies that are open source, have a large user base, and a long history of use, because they will be more thoroughly reviewed.
When evaluating a new technological tool for trustworthiness, ask yourself these questions:
Who wrote or built this tool?
How much experience do they have?
Is it open source, and how big is the community of users, reviewers, and contributors?
===Minimal Execution of Untrusted Code===
The first two features assume the code is trusted but has potential unwanted problems. This feature assumes that as part of our routine activities, we may have to run arbitrary untrusted code. This is code that we can’t evaluate in advance. The main place this happens is in the browser, through plug-ins and scripts.
You should completely avoid running untrusted code, if possible. Ask yourself these questions:
Are the features that it provides absolutely necessary?
Are there alternatives that provide these features without requiring plug-ins or scripts?
===Isolation===
Isolation is the separation of technological components with barriers. It minimizes the damage incurred by exploits, so if one component is exploited, other components are still protected. It may be your last line of defense against application layer exploits.
The two types of isolation are physical (or hardware based) and virtual (or software based). Physical isolation is more secure than virtual isolation, because software based barriers can themselves be exploited by malicious code. We should prefer physical isolation over virtual isolation over no isolation.
When evaluating virtual isolation tools, ask yourself the same questions about simplicity and trustworthiness. Does this virtualization technology perform unnecessary functions (like providing a shared clipboard)? How long has it been in development, and how thoroughly has it been reviewed? How many exploits have been found?
===Encryption==
Encryption is one of two defenses we have to minimize the damage when we are identified. The more encryption you use, the better off you are. In an ideal world, all of your storage media would be encrypted, along with every email and PM that you send. The reason for this is because, when some emails are encrypted but others are not, an attacker can easily identify the interesting emails. He can learn who the interesting parties are that you communicate with because those will be the ones you send encrypted emails to (this is called metadata leakage). Interesting messages are lost in the noise when everything is encrypted.
The same goes for storage media encryption. If you store an encrypted file on an unencrypted hard drive, an adversary can trivially determine that all the good stuff is in that small file. But when you use full disk encryption, you have more plausible deniability as to whether the drive contains data that would be interesting to that adversary, because there are more reasons to encrypt an entire hard drive than a single file. Also, an adversary who bypasses your encryption would have to cull through more data to find the the stuff that is interesting to him.
Unfortunately, using encryption incurs a cost that the vast majority of people can’t bare, so at a minimum, sensitive information should be encrypted.
On a related note, the other defense against damage is secure data erasure, but that takes time that you may not have. Encryption is preemptive secure data erasure. It’s easier to destroy encrypted data, because you only have to destroy the encryption key to prevent an adversary from accessing the data.
Finally, I’d like to add a related non-technical feature.
===Safe Behavior===
In some cases, the technology we use is only as safe as our behavior. Encryption is useless if your password is “password”. Tor is useless if you tell someone your name. It may surprise you how little an adversary needs to know about you in order to uniquely identify you. Here are some basic rules to follow:
Don’t tell anyone your name. (obv)
Don’t describe your appearance, or the appearance of any major possessions (car, house, etc.).
Don’t describe your family and friends.
Don’t tell anyone your location beyond a broad geographical area.
Don’t tell people where you will be traveling in advance (this includes festivals!).
Don’t reveal specific times and places where you lived or visited in the past.
Don’t discuss specific arrests, detentions, discharges, etc.
Don’t talk about your school, job, military service, or any organizations with official memberships.
Don’t talk about hospital visits.
In general, don’t talk about anything that links you to an official record of your identity.
===A List of Somewhat Secure Setups for Silk Road Users===
I should begin by pointing out that the features outlined above are not equally important. Physical isolation is probably the most useful and can protect you even when you run complex and untrusted code. In each of the setups below, I assume a fully updated browser / TBB with scripts and plug-ins disabled. Also, the term “membership concealment” means that someone watching your internet connection doesn’t know you are using Tor. This is especially important for vendors. You can use bridges, but I’ve included extrajurisdictional VPNs as an added layer of security.
With that in mind, here is a descending list of secure setups for SR users.
Starting off, I present to you the most secure setup!
#1
A router with a VPN + an anonymizing middle box running Tor + a computer running Qubes OS.
Advantages: physical isolation of Tor from applications, virtual isolation of applications from each other, encryption as needed, membership concealment against local observers with VPN
Disadvantages: Qubes OS has a small user base and is not well tested, as far as I know.
#2
Anon middle box (or router with Tor) + Qubes OS
Advantages: physical isolation of Tor from applications, virtual isolation of applications from each other, encryption as needed
Disadvantages: Qubes OS has a small user base and is not well tested, no membership concealment
#3
VPN router + anon middle box + Linux OS
Advantages: physical isolation of Tor from applications, full disk encryption, well tested code base if it’s a major distro like Ubuntu or Debian
Disadvantages: no virtual isolation of applications from each other
#4
Anon middle box (or router with Tor) + Linux OS
Advantages: physical isolation of Tor from applications, full disk encryption, well tested code base
Disadvantages: no virtual isolation of applications from each other, no membership concealment
#5
Qubes OS by itself.
Advantages: virtual isolation of Tor from applications, virtual isolation of applications from each other, encryption as needed, membership concealment (possible? VPN may be run in VM)
Disadvantages: no physical isolation, not well tested
#6
Whonix on Linux host.
Advantages: virtual isolation of Tor from applications, full disk encryption (possible), membership concealment (possible, VPN can be run on host)
Disadvantages: no physical isolation, no virtual isolation of applications from each other, not well tested
#7
Tails
Advantages: encryption and leaves no trace behind, system level exploits are erased after reboot, relatively well tested
Disadvantages: no physical isolation, no virtual isolation, no membership concealment, no persistent entry guards! (but can manually set bridges)
#8
Whonix on Windows host.
Advantages: virtual isolation, encryption (possible), membership concealment (possible)
Disadvantages: no physical isolation, no virtual isolation of applications from each other, not well tested, VMs are exposed to Windows malware!
#9
Linux OS
Advantages: full disk encryption (possible), membership concealment (possible)
Disadvantages: no physical isolation, no virtual isolation
#10
Windows OS
Advantages: full disk encryption (possible), membership concealment (possible)
Disadvantages: no physical isolation, no virtual isolation, the biggest target of malware and exploits!
Assuming there is general agreement about the order of this list, our goal is to configure our personal setups to be as high up on the list as possible.
Thanks for your attention, and again I welcome comments and criticism.
Share and Enjoy
Updated: 2014-05-11