“Your secure software is open source: doesn’t that make it less secure?”
This is a recurring question that we get at Benetech about Martus—our free, strongly encrypted tool for secure collection and management of sensitive information, built and provided by the Benetech Human Rights Program. It’s an important question for us and for all of our peers developing secure software in today’s post-Snowden environment of fear and worry about surveillance. We strongly believe not only that open source is compatible with digital security, but that it’s also essential for it.
Let me explain with the following analogy:
Think of encryption as a locked combination safe for your data. You may be the only one who has the combination, or you may entrust it to select few close associates. The goal of a safe is to keep unauthorized people from gaining access to its content. They might be burglars attempting to steal valuable business information; employees trying to learn confidential salary information about their peers; or a fraudster who wants to gain confidential information in order to perpetrate a scam. In all cases, you want the safe to keep your stuff secure and keep out unauthorized people.
Now, let’s say I’m choosing a safe for my valuables. Do I choose Safe Number One that’s advertised to have half-inch steel walls, an inch thick door, six locking bolts, and is tested by an independent agency to confirm that the contents will survive for two hours in a fire? Or, would I opt for Safe Number Two, where the vendor just tells me to trust them, my stuff is safe with them, but insists the design details of their safe is a trade secret? It could be the safe is made of plywood painted to look like metal in the catalog, and made from thin sheet metal. It might even be stronger than Safe Number One, but I have no idea if it is.
I know which one I’d choose!
|License: CC0 Public Domain|
Granted, there is no such thing as perfect security. Everyone so far that has advertised an uncrackable safe has been promising more than they can deliver. The goal of locking up your valuables is not to make them impossible to steal, but rather expensive to steal—whether in terms of money (better tools cost more), time, or the possibility of being sent to jail. The more you raise the cost of cracking a safe, the more secure your valuables are.
The point is this: knowing the specifications of a safe, and hence what it would take to crack it, doesn’t make it less secure. Knowing that the walls are half an inch thick might help a burglar know what tools are required to cut through a half inch of case hardened steel, but this knowledge doesn’t make it less costly to do so. Knowing the combination is designed to have millions of possibilities rather than hundreds discourages attackers who might try to guess your combination or try all of the possibilities. A well-designed safe with a hard-to-guess combination will discourage most attackers.
The analogy of the strong safe with an open design is directly applicable to secure software design. Just as with the safe, the security of a strongly encrypted software tool is not compromised by having its code openly available as open source. In fact, that the tool’s source code is open strengthens its security and, by extension, the safety and privacy of its users. If the code is public and freely available for review, then the end-users, their experts, and the open source community at large can verify that the software does exactly what it claims to do and that there are no “back doors.” In a world where hyper-surveillance is the norm, it is only natural that users insist on commitment to transparency by software developers. This is especially critical for human rights defenders, activists, journalists, civil society groups, and other social justice actors whose digital security and physical safety are closely linked.
It may seem a paradox that opening up the source code of secure software actually makes it more trustworthy. As toolmakers, though, our goal is not to keep the software design secret, but rather protect the confidentiality of the information entrusted to the software. As the safe analogy shows, the strength of security of software depends on the quality of design and the difficulty of guessing the password. With a strong, openly accessible design, the other key security element is encouraging users to choose long, strong, non-obvious passwords. The combination of a secure design and a good confidential password makes it unlikely that all but the most dedicated and well-resourced attackers will be able to access the confidential information stored in open source security software.
Just as the most secure safe will eventually yield to a dedicated assault from an expert with plenty of time and resources, secure software will also eventually yield to a similar assault. The goal of secure software is to raise the cost of such attacks to the point where attackers rarely bother you: they’ll attack your less secure neighbors!
At Benetech, we believe that collaboration and community best help deliver strong security. Here the open source approach to software development makes it easier to collaborate and incorporate existing important innovations. In the case of Martus, we didn’t have to re-implement cryptography libraries, as we used a strong open source one (Bouncy Castle). Likewise, we didn’t need to reinvent anonymity tools, as we integrated Tor into Martus. In this way, our users benefit from an entire community that supports their work with better digital security tools.
The major funders of technology for human rights groups have concluded that open source software is more trustworthy for the activists they want to support. Some of them, like the Open Technology Fund, are actively encouraging their grantees to have their software audited by third party experts, and funding those audits.
With greater transparency, accountability, independent verifiability, and collaboration comes stronger security. The open source way moves us all towards that goal.
This article originally appeared on Opensource.com under a Creative Commons Attribution-ShareAlike 4.0 International License.