One of the big questions that will inevitably come up as media organizations consider adopting SecureDrop, our new open-source whistleblower submission system, is: How secure is it?

We should make one thing clear off the top: any organization or product that promises 100% security is not telling the truth. SecureDrop attempts to create a significantly more secure environment for sources to get information than exists through current digital channels, but there are still legal and technical risks any time a source wishes to submit documents to journalists—no matter the service.

However, we are committed to making and keeping SecureDrop as secure as we possibly can, while retaining usability for both the source and journalist. To that end, we are hiring a security expert full-time to continually manage the code and harden the environments around it. We also plan on commissioning regular security audits for SecureDrop as we continue to update it, so we can ensure we keep it as safe as possible for any news organization and their sources.

Indeed, a team of University of Washington researchers led by Alexei Czeskis—and which also included Tadayoshi Kohno, Jacob Appelbaum, and security expert Bruce Schneier—has already conducted a comprehensive security audit of SecureDrop (then called DeadDrop), which was completed in August of this year. You can read the full audit here.

Importantly, the security audit found no critical flaws in the code of SecureDrop itself. The audit did, however, find several problems with the documentation (so it was close to impossible to install at an optimum security level without the creators’ help), and usability issues on both the source and journalist side (which were correctly interpreted as security flaws since a user mistake can unduly expose information). You can read the New Yorker's reply to the security audit here. The New Yorker was the first major news organization to implement SecureDrop's code.

We are committed to fixing virtually all of their recommendations. Many of these updates have already been completed, and in the coming weeks we will have completed the rest of the recommendations, which mostly deal with creating best practices guides for sources and journalists.

But since the security community may be interested, and we are a transparency organization after all, we wanted to take the time to explain in detail what we’ve done since we took over the project, and what we plan to do in the future.

On page 20 of the security audit, the authors give several recommendations. Here are the recommendations we’ve already fixed:

  • Fixed the SecureDrop deployment/hardening script.
  • Modified the passphrase dictionary to remove non-ASCII characters and switched to a dictionary with less words, but more words in the passphrase. Specifically, we're using the Diceware dictionary.
  • We now use bcrypt to hash the source’s passphrase instead of SHA.
  • We now use version numbers (starting with 0.1), and we display this number of every page of the source and journalist web interfaces.

Recommendations that are coming soon:

  • A set of anonymity best practice guides that will be displayed on the SecureDrop landing page.
  • Use ECC instead of RSA for encryption to make DoS attacks based on key generation less of an issue.
  • A procedure for the loss of journalists’ OpenPGP keys. This will be part of the journalists’ best practices guide.
  • A system for backing up all relevant cryptographic keys so they do not get lost.

What we’d like to have soon (possibly with your help!):

  • Develop a set of metadata filter/scrubbers as documents are submitted through the source interface to prevent the source’ identity from leaking through document metadata.

Right now, we warn sources to scrub the metadata on documents and suggest they use the Metadata Anonymization Toolkit. We’d like to make this easier for them if they so choose. It’s possible the source would like to keep this type of metadata on the document since it is often important to journalists to authenticate the documents they receive.

We’d like to offer this potential feature as an option to the individual media organization installing it. Currently, on the journalist’s side, the journalist already has a document metadata scrubber that she should always use before moving any documents off of the secure viewing station and into pre-publication.

  • Right now the SecureDrop source server generates OpenPGP keypairs for sources. While we aim for maximum server security, and the only entry point for attackers is the Tor hidden service web application, it's still possible that an attacker could exploit a web app bug to compromise the security of the source's crypto. We would like to offer the option of sources generating their own keys locally and encrypting documents client-side using a browser extension in Tor Browser, but there are still many issues and open questions with this approach. We are open to ideas.

However, it's important to remember: even if an attacker were to compromise the source's crypto as it's set up now, the attacker will not be able to see what document the source previously uploaded. They would only be able to see incoming messages from the journalist. To mitigate and defend against attacks, we have a separate monitor server that will both detect DoS attacks and attempted attacks that target the source and document server. 

In addition, if the journalist is doing everything correctly, they will have deleted the document from the document server as well, and moved it to an air gapped viewing station, where it is much safer from any attack. Read more about air-gapped machines in this essay Bruce Schneier just published for Wired. Ultimately, any sensitive document would be sitting on an Internet-connected server for as short of time as possible.

There is also the possibility that a government would attempt to compel a media organization into handing over its crypto keys (similar to what the US government just attempted with Lavabit), or it's plaintext correspondence with sources. Even if they choose to cooperate, SecureDrop is designed to keep the source anonymous from the media organization itself. By forcing the source to submit documents through Tor, as long as the source doesn't accidentally give away their identity through either document metadata or through messages they send to the journalists, not even the media organization should be able to compromise the source's anonymity.

Additionally, in the United States, this would be completely unprecedented and would quickly escalate into one of the biggest press freedom fights in US history. In other countries, this risk may be greater and media organizations should plan for such contingencies in any event where they are compelled to hand over crypto keys to the entire system.

If you have suggestions for how we can make SecureDrop better, or you’d like to help with development, please sign up for our developers mailing list here.

Since WikiLeaks pioneered the use of anonymous submission systems more than half a decade ago, the rest of the journalism world has yet to replicate the ability to safely accept documents from potential whistleblowers. We hope our investment into SecureDrop will inspire other developers to create new types of submission systems, which we will be happy to support if they are as technically secure as possible.

The more diverse systems, and the more media organizations that deploy them, the harder they are to stop. This is how we can ensure press freedom in the 21st Century.