More info from Martus authors [LWN.net]

More info from Martus authors

Posted Oct 25, 2011 12:36 UTC (Tue) by jeff.k (guest, #81002)
Parent article: Martus: Software for human rights groups

"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".

(Log in to post comments)