DeadDrop/Strongbox Security Assessment
UW Computer Science and Engineering Technical Report #13-08-02, August 8, 2013.
Executive Summary:
Several media articles have recently reported on a newly developed system called DeadDrop, which is specifically designed to provide anonymous communication between individuals (sources) and journalists in the face of very powerful adversaries (e.g., oppressive regimes) Initially designed and developed by the late Aaron Swartz, DeadDrop comes at an interesting time when leaked documents are being discussed in the media. If DeadDrop takes off, it could significantly change the way that journalists and individuals communicate anonymously across the world, which could have a significant impact on a wide variety of reporting.
DeadDrop has the goal of being secure against adversaries that can (and there is precedent for this) monitor communications of the press and pursue (and punish) whistleblowers. Given that DeadDrop has already been deployed by at least one prolific media organization, The New Yorker, we wanted to understand whether DeadDrop actually provides the security properties necessary for anonymous communication in the face of such strong adversaries.
We acknowledge that DeadDrop can be used for many purposes, ranging from those that some might argue as ethical and legal to those that some might argue as unethical or illegal. We observe that similar statements have been made about other types of security technologies in the past. For example, in the past people have argued that making email encryption broadly available was unethical—despite its clear benefits in many legitimate scenarios—because email encryption could be used for illegal purposes. In this document, we take no stance on the ways in which DeadDrop should be used, but rather focus on the system design, implementation, and usability in the ways that the system does or does not support anonymous communication.
Generally speaking, DeadDrop is designed to work as follows: a media organization deploys DeadDrop on its servers. Individuals (sources) who want to anonymously communicate with journalists visit the organization’s DeadDrop deployment page and are shown four random codewords, which the source is supposed to remember. The source is then shown a page that allows him or her to submit messages and documents. The DeadDrop system is designed to encrypt all messages and documents in such a way that only the journalists are able to decrypt them. The journalists can communicate back to the source by leaving messages in the DeadDrop application, which the source can view by visiting the DeadDrop page as before and entering his/her codewords. Messages for the source are encrypted and are designed to only be decryptable using the codewords. Conceptually, DeadDrop creates anonymous mailboxes that the source and journalist can use to communicate with each other. DeadDrop uses several techniques designed to prevent the journalist from learning the source’s identity (including the source’s IP address or location). Similarly, DeadDrop is designed to safeguard the privacy and confidentiality of the source’s submitted messages and files in case of global internet monitoring and even physical removal of the DeadDrop servers.
We performed a rigorous technical assessment of the DeadDrop documentation, design, and implementation, analyzing the system for resilience against a variety of possible attacks. We also deployed an instance of DeadDrop and analyzed the usability of the system both from the source’s and the journalist’s point of view.
The conclusion of our analysis is that many of the technical properties of DeadDrop are decent; however, we do not believe that DeadDrop is yet ready for deployment in an ecosystem with nation-state capable adversaries and non-expert users. The lack of software versioning, reliance on VPN, the errors in the installation and deployment documentation, leaking of document metadata, and lack of anonymity best practices all contribute to our reluctance for suggesting that DeadDrop is ready for mass deployment.
Additionally, the usability of the system is sometimes lacking, potentially leading to insecure use. For example, DeadDrop requires a fair amount of technical sophistication on behalf of journalists (such as being able to use the GPG encryption software) and sources (such as being able to sanitize the metadata in the submitted documents). We believe that this lack of usability may lead to failures in anonymization. We enumerate the usability pitfalls we found, as well as suggested remediation approaches in our report.
We also briefly analyzed The New Yorker‘s deployment of DeadDrop, called “StrongBox,” and provide feedback on the deployment. Though we were only able to perform a blackbox analysis, we identified a number of issues. For example, The New Yorker does not use HTTPS for the page advertising StrongBox. Additionally, we believe that StrongBox was not installed using the best practices given in the DeadDrop installation document. For example, the StrongBox deployment leaks HTTP server version—something that is specifically forbidden in the installation documents. We believe these issues should be fixed immediately.
As part of this assessment of Strongbox, we submitted specially crafted documents in order to evaluate whether The New Yorker was indeed checking submissions correctly (on an air-gapped system) if at all. The documents contained requests for The New Yorker staff to reply to our documents, and instructions on how to do so. Unfortunately, after more than 9 weeks, we received no reply from The New Yorker and are unable to speculate on whether they received the documents or not. To our understanding, StrongBox staff was repeatedly informed about our submissions via a media contact, and were explicitly asked—by that media contact—to look at the submissions and reply.
We hope that this analysis will prove useful to users of DeadDrop (both anonymous sources and journalists) and to the DeadDrop developers. Some of the issues we identified are already being addressed. We invite subsequent, even deeper analyses into the technical properties and usability properties of the system.
Categories: Miscellaneous Papers