This blog post is a part of a series about our research toward the next-generation SecureDrop server. In part 1, “Future directions for SecureDrop,” we outlined our current work on the Qubes OS-based SecureDrop Workstation and described our plans for a redesign of SecureDrop. In part 2, “Anatomy of a whistleblowing system,” we drew on existing research to describe the core principles of any secure whistleblowing system. And in this post, we discuss the impact of those constraints on our research into an end-to-end encryption protocol for SecureDrop.

Recap

Recall the description of the core requirements of a whistleblowing system that we cited in our previous blog post, and the way those principles apply to SecureDrop:

• Anonymity of the whistleblower.
  • Consider metadata and submission data, message timestamps, and account creation information.
  • Prioritize anonymity protections at a technical level (the system should not dox the source).
• Confidentiality and integrity of the disclosures.
  • Include modern encryption properties.
• Plausible deniability of the whistleblower.
  • Leave no forensic evidence on the source’s machine; further, short of obtaining a source’s passphrase (“rubber-hose cryptography”), do not store data that proves that a source has interacted with a server.
• Authenticity of the receiver.
  • Allow for a combination of newsroom behavior (using known channels to publicize means of contact), whistleblower behavior (verifying authenticity to the best of their ability before contacting a newsroom), and infrastructure provided by Freedom of the Press Foundation (FPF) (SecureDrop directory, potential PKI for known/verified SecureDrops, etc.).

Our design principles

Our redesign has some additional goals:

• Decrease technical barriers to entry and maintenance/deployment costs.
  • Allow for our redesigned server architecture to at least have the potential to be deployed using commercial cloud-based offerings, whether or not that is one of our recommended paths.
• Meaningfully improve on the existing architecture with respect to all the properties described above.

Taking these as design principles, a redesign of SecureDrop would need to satisfy at minimum the following properties:

• Use modern end-to-end encryption (specific properties such as forward secrecy will be discussed in more detail below).
• Do not require file or information persistence on the source/whistleblower side.
  • This means no “SecureDrop app,” SecureDrop browser extension, etc., as those leave behind evidence of whistleblowing.
• Ensure system architecture does not preclude deployment in a hostile, potentially compromised environment.
  • For example, an attacker that can roll back RAM and disk, take arbitrary snapshots, and so on.
• Avoid, minimize, and hide metadata from the server.
  • Even information such as the number of whistleblowers/sources, messages on the server, message timestamps, or the intended message recipient(s) should not be exposed to an attacker that controls the server.

We also have some nonrequirements. They aren’t constraints, but may afford us some flexibility:

• SecureDrop isn’t a high-volume, high-traffic system. It doesn’t have the same scalability requirements as many other end-to-end encrypted messaging projects.
• Some latency is acceptable — SecureDrop does not need to be a true instant messaging platform.
• SecureDrop does not have to support arbitrary-sized groups, arbitrary DMs, or federation. Messages exchanged on SecureDrop are between a whistleblower and a newsroom; no direct messaging is supported between individual journalists, between sources, or between SecureDrop instances.

Don’t roll your own

While the security community is sometimes fragmented, almost everyone can agree on one thing: don't roll your own crypto. Cryptographic primitives are designed for specific use-cases, and have undergone extensive scrutiny, peer review, and cryptanalysis. Even minute errors can result in catastrophic consequences, of which there are many highly-publicized examples.

In practice, this means designing a system around robust, well-reviewed, open source tools, which are considered industry-standard building blocks. Need to hash a password? Take argon2 and use a well-established library. Key agreement or symmetric encryption? Pick libsodium and an established binding in your target programming language. Transport security? Use TLS. Software signing? Have a look at sigstore.

SecureDrop has always relied on this principle as well, purposefully using “boring” — stable, robust, well-reviewed — tools and frameworks. For this reason, when considering a rearchitecture of SecureDrop, we first turned to existing messaging protocols.

One of our most significant efforts was to build a SecureDrop proof-of-concept using the Signal protocol, first by developing a Python binding to the official Rust libsignal library, and ultimately extending it to the full SecureDrop architecture, available in the securedrop-e2e repo. The goal of this project was to reuse a stable, peer-reviewed scheme, and avoid the risks of customized cryptography.

But when compared to existing messaging protocols, including the Signal protocol, our requirements are atypical, to say the least, and they interact in ways that present a serious design challenge.

The problem of state

As mentioned previously, a source submission application (“SecureDrop app”) would violate our plausible deniability constraint, as it would leave potentially compromising forensic evidence on a source’s machine. But designing a messaging platform where one side has no file-based persistence has implications for the type of cryptography we can perform.

All messaging platforms that implement perfect forward secrecy require client-side storage, and for good reason: be it the ratcheting state, message counters, or ephemeral keys, every interaction requires a client-side understanding of its own state in order to provide some of the core security features of each protocol.

The Signal protocol is no exception — it requires a state on each client, managed by Signal Messenger on users’ phones. In our prototype, to avoid client-side storage on the source side, an encrypted blob uploaded to the server upon source registration served this purpose. (Storing a persistent client-side state on the journalist side is acceptable, since our journalist users are threat-modeled as semipublic figures who are not in need of plausible deniability with respect to their usage of SecureDrop.)

But while this approach allowed for forward secrecy against an attacker that could gain a single copy of the server disk and the source’s passphrase, it did not protect against a hypothetical cloud attacker, whose capabilities, as mentioned above, include the ability to gather arbitrary snapshots over time. For this reason, attempting to engineer source-side ephemerality by periodically removing keys, then updating the encrypted source blob server-side, would not be considered an adequate implementation. Under that scheme, if an attacker had periodic, saved snapshots of the server, the one-time compromise of a source’s passphrase could conceivably result in the recovery of historical “ephemeral” keys, so this type of implementation would not guarantee key ephemerality in our threat model.

Deployment and infrastructure

Signal is also a centralized service and can absorb the increased infrastructure/deployment burden of features such as HSMs/SGX. By contrast, SecureDrop is decentralized. Deployment cost and complexity are already a significant pain point for our users; even setting trust considerations with SGX aside, we aim to design a system that does not preclude smaller organizations or individuals from setting up SecureDrop.

Server metadata and the problem of accounts

Given the relatively low messaging volume on a SecureDrop instance, even account creation information, timestamps, or the number of submissions on a SecureDrop server at a given point in time could be used to deanonymize a whistleblower. We decided that our eventual implementation would best protect sources if we could avoid the concept of source “accounts.”

Server code integrity

Another issue that is particularly relevant in light of our need to avoid client-side persistence on the source side is the integrity of the code provided by the server. As mentioned in our previous post, this remains an open research problem relevant to any project that does in-browser client-side cryptography, such as Proton Mail, the WhatsApp web client, etc. We’ll have more to say about our work in this area in the coming months.

Taking stock of our requirements

Our need for plausible deniability for the source — which in practical terms implies a lack of persistent state on the source’s machine — conflicts in part with our desire to adopt existing end-to-end encryption schemes with perfect forward secrecy, such as Signal’s Double Ratchet algorithm, that require both parties to keep an updated client-side state.

Workarounds to the above problem that involve storing client-side state encrypted on the server for subsequent retrieval do not address the need to protect against an attacker that can take arbitrary snapshots of the server. To some extent, this problem is unavoidable; if we must make this compromise, we’d aim to meet other privacy-related goals, such as eliminating the concept of user accounts.

Besides the Signal protocol, we also explored messaging protocols, including MLS, OMEMO, Vuvuzela, and SimpleX, always hitting another version of the same roadblock: The limitation on source client-side storage imposes a conflict between our need for plausible deniability/repudiation and our need for modern end-to-end encryption with some form of forward secrecy.

In addition, adapting any of the protocols we studied to fit SecureDrop’s threat model would mean changing such significant properties to try to approximate our own use-case that we were, despite our hopes, essentially entering “roll your own protocol” territory.

Can a new protocol advance the conversation?

We realized that we wanted a protocol based on the proven usage of established cryptographic primitives, with the additional constraints of avoiding account creation, limiting metadata exposed to the server, and providing, at minimum, forward secrecy for communications flowing from the source to the journalist.

In November 2022, three years after our initial research into the Signal protocol began, we began discussing the development of a new protocol that met all of our design constraints. By early 2023, we had developed a proof-of-concept, in collaboration with an external security research firm.

In conjunction with the protocol development, we were also working on an early version of a white paper that described this protocol and the use-case it is designed to serve, which we began sharing for review and feedback in spring 2023. For the past year, we have been soliciting feedback on the draft white paper, the protocol, and our overall assessment of our need to develop this protocol.

This is not a decision we make lightly, and it rightly deserves a lot of scrutiny. Our hope is that by drawing more attention to the problem space, the open problems we are trying to solve, and the limitations of current tools for a use-case such as SecureDrop, we will spotlight the topic and help advance the conversation on secure, anonymized communication strategies.

What’s next

In late 2023, we commissioned an initial audit of our proof-of-concept protocol. We have received the initial audit report, and are now working toward publication of the protocol, the audit report, and an accompanying white paper, to provide the wider community a chance to give feedback.

It has already inspired other similar initiatives. (We’re so thankful for all the feedback and assistance we’ve received to date and will be more formally acknowledging those efforts in our next publication.)

We’re also working with academics to collaborate on formal modeling of our protocol, which would allow us to more confidently reason about and prove the security properties we have alluded to above.

Finally, as mentioned above and in our previous post, the web code integrity research aimed at addressing the issue of server trust is still ongoing.

Have an opinion?

If you’re interested in following, contributing to (or critiquing!) our work, we’d love to hear from you. For now, you can reach us at securedrop@freedom.press (GPG), on Mastodon at https://fosstodon.org/@securedrop, or via our Contact Form. When we publish our protocol proof-of-concept and accompanying materials, we’ll include information on joining our mailing list.