Security

DeadDrop and Strongbox

In mid-May, US news magazine The New Yorker unveiled Strongbox, a service that lets whistleblowers and other potential news sources contact its reporters securely and anonymously. The security model is ambitious; it is reachable only on Tor, hides source identities (while preserving continuity across repeat visits), encrypts messages and uploaded files, and allows a monitoring station to watch for possible security breaches. It is also open source, and is the work of the late programmer and activist Aaron Swartz.

Wired's Kevin Poulsen wrote about the system's origin in a blog post timed to coincide with the debut of the service. The goal, he explained, was to create a modern system through which journalists could safely communicate with anonymous sources, since the old methods had not kept up with the pace of technology—including both legal access methods and "outright hacking." Poulsen had met Swartz in 2006 when Condé Nast (parent company to both Wired and The New Yorker) purchased news site Reddit (where Swartz worked). Poulsen asked Swartz to build the secure communications gateway in 2011, after seeing Swartz's work on Tor2Web.

The security model designed by the two incorporated several stringent requirements, such as ensuring that it was impossible for the news organization to know the origin of files or messages (thus it could not be compelled to disclose that origin), but it should also be able to run on servers at the news organization's offices (to reduce the likelihood of tampering). Swartz insisted that the project should be released as open source software, and they settled on the name DeadDrop. Outside security researchers audited the architecture of the system as well as the code. By December 2012, DeadDrop was reasonably stable and a launch was planned. But those plans came to a sudden halt with Swartz's suicide in January 2013.

Strongbox debuts

In the subsequent months, Poulsen consulted with Swartz's friends and family before eventually deciding to proceed with the launch, which finally happened on May 15. The public front-end of the service runs as a "hidden service" on Tor, accessible only through a .onion pseudo-domain. The front end itself is almost deceptively simple; when a user (the would-be whistleblower or source) logs in for the first time, the system creates a unique code name composed of four English words. In the future, the same user can visit the service from any location and log on again using the four-word code (hopefully without writing it down). When logged in, the user can type a message into a web form and optionally attach files to upload. Journalists can leave secure messages for the user in reply, which the user is encouraged to delete after reading.

Obviously the system cannot provide absolute security; among other things, if the user discloses personally identifiable information in his or her messages, the anonymity is gone. If the user writes down the unique code word identifier, someone else could copy it and spoof the user's identity. But if the instructions are followed correctly, the framework does offer a fairly strong guarantee of anonymity and protection against eavesdropping—certainly a far better offer than PGP encryption or a TLS-protected web form do alone. Instructions and a privacy pledge are posted on the Strongbox home page; hopefully anyone concerned enough about security and anonymity to use the system will take the time needed to learn how to use it correctly.

Drop it

The Strongbox site does not go into much detail about how the system works, but there is a good deal more to examine on the DeadDrop project site at GitHub. The threat model document provides an overview of the system from the outside source's perspective as well as the journalist and administrator's. The same application server provides the front end seen by sources over Tor (which we have already described) and the front end seen by journalists inside the news organization on its internal network. The other two pieces of the puzzle are the "secure viewing station" (SVS) where journalists decrypt and read messages and the auditing system.

But security starts on the application server. The four-word code name generated randomly for the source is never stored in the clear, but it is used. The SHA256 hash of the code name is stored on the server as the directory name for the user. Every message sent by the source includes the code name in the POST request, and the application checks its hash against the stored hash to authorize the request. The application also creates a GPG v2 key pair for each new user, and uses the code name as the secret key passphrase (which, again, is not stored in the clear). Replies from the journalist are encrypted with the public key from this pair, so that only the intended source can decrypt them, but the decryption happens automatically using the code name in the HTTP request, so the source is not required to store or memorize a separate passphrase.

Every message or file uploaded by a source is also encrypted, but with a different key pair, for which the application server only stores the public key. The journalist interface to the application is only available through a VPN requiring two-factor authentication. The application uses private SSL certificates distributed to the journalists' computers, with the certificates and revocation lists generated offline. When a journalist logs in to the system, he or she is presented with a list of new messages, and must download them in encrypted form and take them to a separate machine (the SVS) to read. The SVS is intended to be a diskless workstation booted from a live CD and not attached to the network. The private key for the application is stored on the SVS live CD, so the journalist can read messages and files. As an additional measure of security, the application presents a different set of code names in the journalist interface, so that the source's code name and hash are not known.

Finally, the application server and the SVS are kept on the news organization's premises, under lock and key and monitored for unauthorized access. The application server has a hardware entropy source attached to generate strong cryptographic keys, and journalists are instructed to re-encrypt any files they take from the SVS to their personal workstations (using yet another GPG key pair). There is a separate machine running the OSSEC intrusion detection system and logging events from Tor, AppArmor, the firewall, and grsecurity. Just as the system provides guidance to sources using the service (including potentially unfamiliar pieces like Tor hidden services), there is a set of guidelines for security on the journalists' side of the system: GPG key type and key length, VPN settings, and browser certificates. There is an installation guide that walks the reader through the entire process, starting with installing the operating system with full-disk encryption.

Follow the money code

How much will Strongbox or any other DeadDrop installation ever get used? Those of us on the outside may never know for sure. Despite the best efforts of the designers to make DeadDrop easy-to-use, it should be clear to anyone who reads the threat model that balancing high security and ease-of-use remains a tall order. There are some very nice features in DeadDrop. The code name feature is quite clever; it allows both source and journalist to reliably feel confident that the same person is accessing any particular user account, but by using separate code names for the source and journalist front-ends, anonymity is preserved. Using the source's code name as both the POST authentication method and the GPG passphrase is a compromise, but it also reduces the burden of complexity placed on the source—who, in the real world, may already be taking on an enormous risk by talking to a reporter.

The downside is that some of DeadDrop's security stems from parameters that are hard or impossible for small organizations to implement, such as the constantly-guarded SVS and on-premises application server. Those features mandate dedicating a facility in a brick-and-mortar location (and ideally one that is distinct from the rest of the organization's network infrastructure). But physical security is a vital part of maintaining the overall integrity of the system; without it, someone could copy information from the server, install a keylogging device, or attempt any number of other attacks.

It is interesting to compare the design of DeadDrop to similar whistleblowing applications, like GlobaLeaks (which is arguably the best known). GlobaLeaks also allows sources to submit information to a news organization (or to any other entity running the service, of course), including a Tor hidden service front end. But GlobaLeaks does not implement the persistent identity across repeat visits feature (although it does allow a whistleblower to return to a specific "tip" by saving or remembering a ten-digit "receipt" string). GlobaLeaks also does not offer end-to-end encryption of uploaded messages and files, nor does it utilize DeadDrop's rather complex offline SVS scheme to ensure that communications are not monitored or intercepted.

Of course, to some budding journalists and whistleblowers, GlobaLeaks' lack of complexity may well be a plus. DeadDrop's architecture is set up to protect against a wider assortment of attacks, but along with the usual administrative overhead, a more complex system brings with it the increased chances of human error. That is almost always the case with security; the better password is harder to remember, the safer authentication method is easier to mess up—and in either case, the temptation to write down a secret for fear of forgetting it is an obstacle to which there is no technological solution. Then again, Whistleblowing fundamentally requires some leaps of faith; a source must trust the news organization to begin with or DeadDrop would not make them do so. But DeadDrop remains a valuable object for those interested in developing secure communication systems, regardless of whether or not their plans involve contacting The New Yorker.

Comments (17 posted)

Brief items

Security quotes of the week

Comments (none posted)

Strongbox and Aaron Swartz (The New Yorker)

Comments (32 posted)

New vulnerabilities

gallery3: cross-site scripting

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

kernel: privilege escalation

Comments (none posted)

kernel: information disclosure

Comments (none posted)

krb5: UDP ping-pong flaw in kpasswd

Comments (none posted)

libvirt: denial of service

Comments (none posted)

mediawiki: multiple vulnerabilities

Comments (none posted)

openstack-keystone: delayed token invalidation

Comments (none posted)

openstack-keystone: insecure signing directory

Comments (none posted)

openstack-nova: denial of service

Comments (none posted)

openswan: code execution

Comments (none posted)

openvpn: possible plaintext recovery

Comments (none posted)

ruby: object taint bypassing

Comments (none posted)

thunderbird: multiple vulnerabilities

Comments (none posted)

tomcat: information disclosure

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>