When It Comes to Human Rights, There Are No Online Security Shortcuts

Photo courtesy Benetech

As one of people who built Martus, an encrypted database used by thousands of human rights activists around the world, I routinely confront the needs of users who are not in wealthy countries, as well as the difficult problem that creating real, easy-to-use security poses. My thoughts here are focused on the democracy activists, citizen journalists, and human rights workers in the world’s toughest political environments. These are our Martus users, and my colleagues and friends. These are people who need security more than just about anyone: it can be literally a question of life and death.

Patrick Ball

Patrick Ball has spent over 20 years applying scientific measurement to human rights. He designed databases and conducting quantitative analysis for truth commissions, non-governmental organizations, international criminal tribunals and United Nations missions in El Salvador, Ethiopia, Haiti, Chad, Sri Lanka, East Timor, Sierra Leone, South Africa, Kosovo, Liberia, and Peru. Dr. Ball is currently involved in HRDAG projects in Guatemala, Colombia, the DR Congo, Syria, and others. (Photo: Miguel Cruz)

One thing that makes that already difficult situation worse, though, is when otherwise well-informed people give bad advice about what is and is not secure. Unfortunately, an opinion piece at Wired recently espoused a view I find inaccurate, misleading, and potentially dangerous about using certain tools for human rights work. I’ll explain the problem here, and I’ll offer some questions you might ask about security applications in the future.

My concerns stem from a sharp debate over software called CryptoCat – a debate spurred largely by an admiring profile at Wired. CryptoCat is a web-based chat application which uses encryption to scramble the contents of a conversation, in theory resisting electronic snooping. The interesting twist is that CryptoCat does the crypto without using the easily-thwarted security built into browsers (called SSL), and without requiring the user to download and install additional software (like Pidgin and OffTheRecord).

Seems great, right?

Well, not so great. CryptoCat is one of a whole class of applications that rely on what’s called “host-based security”. The most famous tool in this group is Hushmail, an encrypted e-mail service that takes the same approach. Unfortunately, these tools are subject to a well-known attack. I’ll detail it below, but the short version is if you use one of these applications, your security depends entirely the security of the host. This means that in practice, CryptoCat is no more secure than Yahoo chat, and Hushmail is no more secure than Gmail. More generally, your security in a host-based encryption system is no better than having no crypto at all.

CryptoCat’s security is based on how it convinces your browser to do the encryption on your computer. To simplify, there are two parts to an encryption system: the encryption engine, and the key. The encryption engine is the software that does the actual work — everyone who uses the tool uses the same encryption engine. The second component is your key, which is unique to every user. The key holds, well, the key to your security. It must be kept secret, so only you have it. Again simplifying, the key consists of a tiny computer file and your passphrase. (If you want to know more about keys, see my earlier blog post on this topic).

In host-based systems, the host keeps the tiny computer file, but not your passphrase. The idea is that only you know your passphrase. In theory, the host cannot access your data because although they have part of your key, they don’t have your passphrase. When you login, the hosts sends the encryption engine to you in a computer program (called an applet) that runs inside your browser; the tiny computer file with part of your key is attached alongside the applet. All the encryption and decryption happens in your browser, on your computer. That means that the host only ever sees the encrypted data. Since only you have your passphrase, your data should be secure, even if the host wants to attack it.

But there’s a problem. If an attacker can get access to your key and your passphrase, all your encrypted data is now accessible to him. Remember that the host already has your key. All they need is your passphrase. So if the host wants to attack you, all they need to do is send you a special encryption engine that captures your passphrase the next time you use the service. As usual, it does all the encryption and decryption for you, right on your computer. But it also remembers your passphrase, and sends it secretly back to the host. This is the heart of the attack: if the server sends you a special applet that spies on you, all your encrypted data is now wide open.