In “Future directions for SecureDrop,” the SecureDrop team laid out some goals for a redesign of the platform’s server architecture. Here, we go into more detail on those goals and describe the design constraints of a whistleblowing system as we see them.

Introduction

SecureDrop and other whistleblowing systems have played an important role in the journalism ecosystem for years. Due to the various privacy and anonymity protections these systems provide, it is impossible to fully assess their impact except for specific cases. However, there has been some research both on the technical and on the usage and impact sides.

“Digital Whistleblowing Platforms in Journalism” (2020) and “Securing Whistleblowing in the Digital Age: SecureDrop and the Changing Journalistic Practices for Source Protection” (2021) are important overviews and good starting points for a more systematic analysis of the ecosystem.

The core of a whistleblowing system

On the technical side, there is no established model for a whistleblowing system, but a common framework of certain properties has emerged.

For instance, in “A Simple and Robust End-to-End Encryption Architecture for Anonymous and Secure Whistleblowing” (2019), the authors identify the four core requirements of a whistleblowing system:

• Anonymity of the whistleblower
• Confidentiality and integrity of the disclosures
• Plausible deniability of the whistleblower
• Authenticity of the receiver

While SecureDrop has very similar goals and priorities, each of these properties must be properly contextualized in each party’s threat model.

The anonymity of the whistleblower must be preserved against all parties and in every possible scenario. Even assuming a Tor connection to reach the whistleblowing platform, metadata such as timing information, conversation flows, attachment sizes, or filenames on the server side can still leak information about access and submissions to the system.

Confidentiality and integrity are also a subtle matter, as different cryptographic schemes have different properties. For example, the classical OpenPGP encryption standard does not support forward or backward secrecy by default. In addition, different parties have different needs. For example, a whistleblower must have plausible deniability, meaning no incriminating traces should be left behind on their machine and assets.

The current on-premises SecureDrop model works

In its current architecture, SecureDrop must be deployed physically on-premises, under the full control and supervision of the adopting newsroom. We do not support third-party hosting and we strongly discourage any outsourcing of both the infrastructure and the administrative tasks. This allows the organizations to fully control and oversee their own SecureDrop server installations, without any external access or telemetry, including by Freedom of the Press Foundation. The reasons behind this are partly technically related to security, as explained in our previous post, and partly because we believe that organizations should be in full control.

This approach encourages safety practices in newsrooms and among journalists, decentralizes the ecosystem (since there is no single server or federation), and strengthens diversity. While the SecureDrop Directory lists instances for organizations we’ve vetted, we know there are other SecureDrops out there, and SecureDrop itself can be run invisibly and without anyone’s permission or knowledge: there is no telemetry and everything is open source. We consider this one of the strongest features of SecureDrop.

A lot of newer technologies, both primitives and fully fledged systems for privacy preserving communications, have been developed and studied. For instance, “A blockchain-based quantum-secure reporting protocol” (2021) proposes a blockchain-based, peer-to-peer protocol for whistleblowing. While we cannot dispute the validity of the protocol itself, we believe blockchain-based and peer-to-peer alternatives fail to satisfy some core requirements. Due to the deniability constraints, we cannot require sources to download dedicated software or store data on their devices. Furthermore, anonymity in a peer-to-peer network is harder to preserve, and the transparency of a blockchain, especially in smaller-scale systems, works against that anonymity property.

We observe similar limitations with decoy-based approaches, such as “A Secure Submission System for Online Whistleblowing Platforms” (2013) and “CoverDrop: Blowing the Whistle Through A News App” (2022).

Nonetheless, we are thankful to every researcher and institution who spent time, effort, and skills in modeling, developing, and publishing such systems. We have learned a lot from every single one and they contribute and deepen the level of our technical understanding.

Some constraints are here to stay

As described earlier, we do want to keep the one-server, one-organization model. Our next generation prototypes follow a similar architecture: a server, a journalist app, and a source submission tool.

For the journalist interface, we are in the process of moving away from our current Tails-based air-gapped workflow and focusing our effort on the Qubes OS-based SecureDrop Workstation, which we think is the best way forward for improving usability while maintaining a high degree of security. Furthermore, this architecture allows a more holistic integration of other tools, such as Dangerzone, which is now available natively for Qubes (in beta).

Given the requirement of plausible deniability, we still consider the best option for the source interface to be a web-based interface available only as a Tor Hidden service, accessed via Tor Browser. Tor Browser is a generic and widely used application that has uses other than whistleblowing, and it already has many of the security features we need.

The deniability problem

Deniability poses a major challenge: How can we minimize any traces of SecureDrop on sources' computers? A source should be able to access SecureDrop with one small, memorizable piece of information, so that they don't have to keep a record anywhere that could incriminate them. (For the same reason, we wouldn't want to create a "whistleblower app" or a SecureDrop browser extension — those would be pretty strong evidence that someone is a source!)

Currently, the only thing SecureDrop needs to authenticate sources is a single passphrase, and we want to keep it that way to keep the source experience as simple and consistent as possible. But this presents a technical challenge: to move to modern end-to-end encryption with forward secrecy, SecureDrop would need to generate what are called ephemeral keys. This is only possible with non-deterministic keys–that is, with keys that are randomly generated and eventually forgotten. But if the only piece of information being stored per source is their passphrase, then the conditions for creating non-deterministic keys can’t be met, since all subsequent encryption keys would be derived from this single seed (in a deterministic way).

We’re working on a custom end-to-end–encrypted messaging protocol to satisfy these constraints, about which we’ll publish more soon.

To use JavaScript or not to use JavaScript?

The usage of JavaScript for browser-side encryption is a common practice, yet it does not provide the same guarantees a dedicated client can offer. We can mention many use cases of such technologies, both open-source and proprietary, from Whatsapp Web and Protonmail to fully fledged collaboration suites such as CryptPad.

While more end-to-end encryption and privacy are great features, these implementations have a well-known drawback: since the encrypting JavaScript is served by a remote server each time, there is no way to systematically authenticate and perform integrity checks on such code. In other words, the server hosting the scripts has to be trusted, because it could serve backdoored or altered code that might weaken or leak cryptographic keys, attempt to deanonymize the user, or attempt to exploit the browser. It could do this undetected, even to only a single specific user who could never detect such a compromise on their own, and without leaving any traces behind.

In the context of SecureDrop, the impact on the threat model is even more significant: almost all browser exploits leading to either deanonymization or full code execution rely on JavaScript. We advise users to disable completely JavaScript in Tor Browser, and SecureDrop currently displays a warning when it detects that it is not the case. If SecureDrop used JavaScript-based encryption today, not only would the server still need to be trusted, but in case of a compromise the consequences would be much worse.

We are studying, working, and collaborating with the relevant stakeholders to improve the state-of-the-art on this issue.

Conclusion

Changing SecureDrop’s architecture is a complex technical challenge, especially with the goal of allowing deployment in untrusted environments, such as cloud servers. We are actively prototyping solutions to these challenges, and we will release our findings soon for community review, along with more detailed blog posts.

We are thankful to members of the research community who have looked into whistleblowing systems from several angles and to all those who advance the state of privacy preserving technologies. Please don’t hesitate to get in touch (securedrop@freedom.press) if you have questions or feedback.