SecureDrop 1.0 will be a complete re-architecture, designed to achieve two primary goals:
Each SecureDrop server should offer a simple API for clients to use in submitting information and conversing with journalists. Multiple client designs should be allowed, to satisfy a variety of source threat models and operational environments.
All encryption between sources and journalists should be end-to-end, accompanied with a variety of countermeasures to prevent or at least detect malicious tampering with the SecureDrop server.
Additionally, we should consider a design where both the server and client can cooperate to implement mitigations for traffic analysis.
A local observer (in the context of an anonymity network, any eavesdropper between the client and the first hop router) should only be able to determine that the user is using the anonymity network, but not that they are using SecureDrop.
A first step could be to randomly pad requests and responses to obfuscate the traffic fingerprint. Unfortunately, it is difficult to achieve certainty in effectiveness.
"Bucketing" requests and responses, in the manner of Pond, is unfortunately insufficient: the traffic pattern is still identifiable (which is acknowledged by Pond's design document).
We could use a more sophisticated scheme, such as Wright et. al's traffic morphing. Unfortunately, this is difficult to implement and has also been called into question. In general, the jury is still out on any "efficient" traffic analysis scheme.
Ideally, we would also implement mitigations for global adversary traffic analysis. We obviously cannot stop them from learning that a given user is using SecureDrop due to correlation, but we might be able to prevent them from associating a SecureDrop user with a specific submission or set of submissions.
In general, resisting traffic analysis may be better served by removing the assumption of a low latency anonymity network (e.g. Tor). We could consider something high latency (e.g. Mixminion). Unfortunately, there is no existing network with a large anonymity set (comparable to Tor's) and bootstrapping one is decidedly non-trivial.
Given the difficulty in implementing and ascertaining confidence in comprehensive traffic analysis mitigation, it may be better to treat it as a goal for a future (1.x) release, and implement simple mitigations for 1.0 (e.g. random padding, maybe bucketing).
TL;DR: Grab your personal computer, Tails USB, and documents—but leave your phone at home. Use cash and take a bus to a coffee shop you have never been to. Avoid shoulder surfers and CCTV. Using the Tor Browser, or preferably Tails, access your preferred news organization's SecureDrop onion URL from their open-wifi. Always be aware of all the info you are submitting, obvious or not. Only keep info for as long as you need it. Use a location once then consider it burned. Protect your codename. Don't tell anyone about what you are doing or have done, and never answer questions from investigators without a lawyer present.
To transfer the encrypted files you receive from the source to the secure viewing station, and then back to your workstation for publication, you will need to use at least two USB sticks.
Ideally, the journalist would not use USBs at all, but transfer each batch of documents using a different CD/DVD every time. As explained above, CD or DVD that are *not* re-writable are preferable to USB sticks. A journalist would copy the encrypted files from SecureDrop to a CD or DVD, copy them onto the Secure Viewing Station and then destroy the CD/DVD after first use. This requires a lot of CD/DVDs, however, and if a file is bigger than 4.7 gigabytes (the standard for DVDs), you may be forced to use a USB anyways. But again: using CD/DVDs is the safest way to prevent your Secure Viewing Station or your personal workstation from being infected by an attacker’s malware.
After decrypting the documents sent to you by the source, and before taking them to your normal workstation for publication, you should scrub any remaining metadata off the documents. This metadata, while potentially valuable in your authentication process, could put your source at risk if it were published.
Though some will only be entered once or rarely, the journalist will need to have at least four different passwords to operate SecureDrop properly. Creating a secure password in an age when computers can input billions of guesses per second is difficult. You can follow these instructions on creating a secure password, or you can use a password manager to create a random secure password for you.
A password manager also has the added benefit of keeping all your passwords in a safe place so you do not have to memorize them all.
While the Secure Viewing Station can be an old PC laptop, it is critical for security reasons that the hard drive is removed, the network cards removed or physically disabled, and the speaker and microphone lines are cut. This computer is never to touch the Internet or another hard drive and it’s important to do all these steps so it is never compromised.
James DThe SVS should be located to avoid any CCTV and shoulder surfers.
(James fill in)
Updating Tails DVD
Download and burn the updated version of Tails.
Updating Tails USB
Usee the built in gui to download and upgrade.
In the US, SecureDrop servers be located physically inside the physical newsroom of the media organization – not in a data center hosted off-site and not by a third party.
If a foreign news organization has the opportunity to host servers in the organization’s US office, it should do so. This may seem counter-intuitive basedon the fact that third party providers in the US have been accused of handing over foreign data to the NSA, but US newsrooms offer you by far the most protection.
Remember: the big advantage to SecureDrop is that you are not relying on any third party providers to help you communicate. That means if there is a legal order to hand over data on a certain communication, it must be served directly to the media organization, rather than a third party like Google. This gives the media organization a chance to fight such an order in court, a fight that every media organization will likely back, and therefore will likely dissuade certain agencies from requesting the data to begin with. Further, authorities will come to learn that parties using SecureDrop will actually have scant data to hand over and such requests will become legally burdensome, as they would also have to compel the production of pass-phrases, etc.
The Privacy Protection Act also provides enhanced protection to news organizations than normal houses. It severely restricts law enforcement’s ability to obtain journalistic work product and source materials.
Preferably, they have a trusted location to host the servers. (The idea is that the servers should be hosted in a location that is owned or occupied by the organization to ensure that their legal rights can not be bypassed with gag orders).
If at all possible, SecureDrop should connect to the Internet through a separate Internet circuit than the rest of your news organization’s corporate network. If that is not feasible, you should segment a portion of your network (subnet) to be used solely for SecureDrop.
The SecureDrop servers should be monitored by video camera with the ability to keep a few days worth of recordings. As stated above, SecureDrop is most vulnerable to an attack when the attacker has physical access to the servers, so their physical security is just as paramount as the digital security surrounding the application.
Someone at the news organization will have to monitor the OSSEC and other email alerts that are sent a few times a day. These alerts are critical in making sure the servers have not been attacked or the system is not under a denial of service attack that could knock it offline for an extended period.
Once it is established who will receive the alerts, the news organization should map out their response plan will be. For example, what do you do when there are technical outages? What happens with a denial of service attack is ongoing? What if the environment is compromised? These should cover all plausible scenarios including the potential forcompromise from intelligence agencies.
In the US, we have traditionally had strong press freedoms and journalists have traditionally been legally protected from revealing their sources.
Laws that protect journalists privilege are called shield laws. There are many state and local shield laws, although there is no federal shield law. The Supreme Court precedent for federal was a split decision that did require journalists to reveal their sources, although it is complicated and controversial (Branzburg v. Hayes). There is also the Whistleblower Protection Act at the federal level, although I am not sure if it is ever used. It does not cover government contracters, e.g. Edward Snowden.
Obama administration has been more aggressive than any other in pursuing sources in leak investigations.
Recently, it's become clear that the government feels it does not need to challenge journalists to reveal their source's identities. Instead, they can use surveillance (telecom metadata, NSA surveillance) to determine who the sources are and prosecute them without involving the journalists at all.
DOJ investigating AP reporters by subpoeaning telecom that served the AP office in NYC (all journalist's communications were retrieved)
Journalists in China, Iran, Syria (more specific examples would be good here)
They are trying to circumvent the need to challenge this difficult legal question, which cuts to the core of American civil rights and the Bill of Rights (1st, 4th, 5th amendements).
Journalists and sources should be able to communicate securely and anonymously to avoid these (extralegal?) manuevers.
In addition to this, we're trying to facilitate communication between journalists and sources, which will hopefully lead to more and better reporting on important issues. I call this the "Glenn Greenwald" problem (apologies to Glenn), who couldn't communicate with Edward Snowden initially because he found setting up and using PGP to be too onerous.
We are additionally interested in solving the inverse of that problem, and hopefully encouraging more sources to come forward and share information that is relevant to the public interest. Leakers shouldn't have to be computer experts, like Chelsea Manning or Edward Snowden, to leak safely and successfully. However, this problem is significantly more difficult and some could consider it reckless (because opsec is so important, and having good opsec requires deep knowledge of security and adversary/threat model).
The current release of Securedrop is 0.2.1 (soon to be .2) and is deployed by these news orgs:
And there are more major deployments in the pipeline.
How does it work?
Show demo site and aegis architecture diagram.
Todo: finish and land architecture diagram, update demo site to be 0.2.1