Martus: Software for human rights groups [LWN.net]

October 18, 2011

This article was contributed by Dave Neary

What constitutes a hostile environment for software? For one Martus user in Colombia, it meant being held up at gunpoint one evening after leaving work and being forced to hand over her laptop. Without Martus, doing so may have placed the lives of a large number of people in danger. Thanks to Martus, she could hand over the computer secure in the knowledge that these people were safe.

Martus (from the Greek for "Witness") is a fairly simple program - it records reports of human rights abuses ("bulletins" in Martus terminology), encrypts them, and stores them securely off site. But given the circumstances under which it's used, it is vital that its users have an absolute confidence that it does those things well.

At the recent Open World Forum in Paris, I had the opportunity to talk with Dr. Jeff Klingner of Benetech, the US-based non-profit that wrote Martus. Jeff was speaking in the "Humanitarian Free and Open Source Software" track at the conference. He mentioned that "NGOs [Non-governmental organizations] who use Martus have confidence in the security of our software because it's open source". Because records are stored encrypted by Benetech, "they don't even have to trust us" - something Jeff admitted was a concern for some NGOs around the world.

Security before convenience

Martus is designed for ease of use, but whenever security concerns come into conflict with usability, security wins through. One example: there is no key recovery service. If you lose your private key or forget your passphrase, any data encoded with that key is lost. Benetech has put a lot of effort into educating its users about best security practices - there is an entire chapter of the Martus user guide [PDF] dedicated to safe computing, guarding against malware and handling passwords. Martus also includes an onscreen keyboard for password entry, to help defend against key-sniffer malware.

Martus is written in Java, and licensed under the GPL. It consists of two distinct parts: a server which stores encrypted bulletins, and a client, which provides for data entry, search and encoding of bulletins.

Each Martus user has their own key and passphrase, which is used to encrypt all data they enter into the system. In addition, users may set up a HQ account, so that others who you trust in your organization will be able to see your private data, once you have sent it to the server. Bulletins are also kept encrypted on the local hard drive until they are deleted by the user.

Internally, keypairs are 2048-bit RSA keys that are encrypted with SHA1 and TwoFish using a passphrase. All bulletin data is encrypted with 256-bit AES, and signed using SHA1 digests and the private key. And all client-server communications are transferred using SSL with self-signed certificates. The team have considered using biometrics or physical objects to complement passphrases and private keys, but according to Benetech engineer Kevin Smith, the Martus Technical Lead, "whenever we have researched biometric authentication, we have not been comfortable with the reliability and security, and/or with the impossibility of changing your credentials if they become compromised".

Releasing the software as open source has not been a panacea for the project. Jeff Klingner notes that "we have been asking for a security audit by the open source community for years, but to our knowledge no-one has done one." Just because the project is open source does not mean that people are reading or reviewing the source code. He did mention that he suspected that some governments may have taken a look at the software, but (unsurprisingly) did not share the results of their review.

So what is the basis for Martus's users trusting the software? In the absence of a security review, isn't there a chance of a Haystack-style security flaw? Jeff says:

There's two senses to the term "trust": If you mean trust that we are not deceiving them and have not snuck in a back door through which we, the US govt, or their govt/police could see the data, this trust is based on two things: they usually trust us as partners, and because it is open source. They trust us as partners, because of they way we deal with them, and because of the long history of human rights groups and truth commissions we've worked with successfully.

The second sense of trust is trust that we haven't made a mistake in our implementation that has led to an unintentional security hole. In the absence of an audit, this trust is based on our credentials, and on a clean history, with no known attacks or post-release vulnerabilities discovered to date.

In addition to their track record, Jeff also pointed to the core team members, Kevin Smith and Scott Weikart. Scott in particular "has a totally paranoid approach to security and dreams up security threats that would never have occurred to me. The Martus data servers are locked up tighter than any other Linux security configuration I have ever seen" according to Jeff.

Several other things make Jeff confident that Martus will not see a Haystack-like security vulnerability uncovered. Firstly, Martus is open, while Haystack was not. Secondly, Benetech are very clear what is and is not being protected against - and are frank about their potential failings. According to Jeff, "even though we've been as careful as I think it's possible for people to be, we also understand and openly acknowledge the very real possibility that we've made an important security mistake. This fact comes through in Martus's documentation, and in the way we present Martus to potential users".

Part of the reason for the lack of community traction could be how difficult it is to get hold of the software on Linux. There are no packages available for either RPM or .deb based systems, either for the server or client components. Binary distributions for Windows, Mac, and Linux are available from the project's download page, but there was a server problem when I tried to download the latest version of the client software. Source code is available directly on the project's sourceforge page, but I have not been able to find the project developers' mailing list. The project could definitely provide a better experience for developers, and if they do, there are a lot of easy ways for people to help, including packaging, translations, and security review.

Social coding for good

In addition to Martus, Benetech also runs a number of other projects in the areas of human rights, literacy, and environmental protection. To attract new contributors to these and other humanitarian software projects, the company recently launched a new initiative, Social Coding 4 Good, to increase awareness of these projects and to put potential contributors in contact with projects that can use their help. Jeff mentioned that he believed that a lot of young programmers would like to give time to a project which is both technically challenging and provides some social benefit - Social Coding 4 Good aims to fill that gap, in a way similar to what HFOSS does for academic programs.

More and more, people are interested in working on "stuff that matters", to use a phrase made famous by Tim O'Reilly. Projects like Martus, that can make a real difference during times of political turmoil in some of the most troubled regions of the world, offer an opportunity to do something that matters. If you want to help with the project, report a security bug or propose packaging the software for your Linux distribution, you can contact the project at info at martus.org.

(Log in to post comments)

More info from Martus authors

Posted Oct 25, 2011 12:36 UTC (Tue) by jeff.k (guest, #81002) [Link]

"We have been asking for a security for audit by the open source community for years" was an unfair overstatement by us. We haven't reached out to ask broadly, only in a few cases, like when we talk at security or open source conferences like the Open World Forum. We have been wanting one for years, and haven't ever had enough funding to pay for one. Our funders and users are always more interested in new features. In fact, we're hoping that readers of this article might be (or might know somebody who would be) interested in reviewing Martus's security design and implementation.

Also, some clarification of the fact that Martus has no password recovery option: The main point is that we (Benetech) cannot recover passwords. We do not have (and we very much do not want to have) any way at all to access the data human rights groups put into Martus. To mitigate the risk of data loss caused by a forgotten password, we included a way for people to recover their data, which they need to set up in advance themselves: a user can make a backup copy of their private key, in which the key is not protected by their passphrase but instead broken up into five separate files, each of which is stored on separate removable media (five burned CDs, five thumb drives, five floppies, etc.) The user then gives each of these removable media items to somebody they trust without telling them about the other four. Later, if they forget their password, they can recover their private key (and thus their data) by re-collecting any two of the removable media. (This is a (2,5) secret sharing threshold scheme.) This whole process takes place on the client and doesn't involve Benetech.

Some more information on our development practices from Kevin (the main author of the client), which we thought might be interesting to LWN readers but we didn't have ready for Dave when the article went to press:

Much of the security-sensitive code was developed with pair programming, and we did full-group code reviews for some of it. Furthermore, all the security-sensitive code and almost every line of non-UI code in Martus is protected by unit tests. That includes the crypto levels, as well as data handling, search, etc. Also, the crypto levels (what I would call low and medium levels) have been very stable (not many changes). If/when we have to make changes in those, we try to be extra careful.

And regarding sensitive data being stored unencrypted in RAM, Scott says "This is not an issue on the server; the server just stores data encrypted by clients (witness accounts and other human rights data), it never creates them." For the client, Kevin explains

This is a known issue on the client. We do "wipe" passphrases from memory as soon as we are finished using them, but other data may persist in RAM in plaintext form. We have considered this at times, but have not felt that this form of attack was our largest vulnerability. Keyboard sniffers, and thugs with sticks and guns demanding passwords are examples of more likely threats. In any case, unencrypted data never reaches the hard disk.

Related to the "thugs with sticks or guns" threat, Martus does have a feature to securely erase all of a user's data (and optionally Martus itself as well) in a single step. We call it the "panic button".