SecureDrop

https://www.schneier.com/blog/archives/2013/10/securedrop.html

by hatchan • 13 years ago

203 28 13 years ago

StavrosK• 13 years ago

Hmm, what security does this actually provide? It seems to me that it only secures materials from the server to the operators, but that's a really small part of it. Someone malicious with access to the server can just inject something to get the plaintext, no?

crb002• 13 years ago

Documents are public key encrypted and you view them on an airgapped laptop. Submission server is on TOR to provide obfuscation of the transmission source.

IMHO the system is over complicated. There should just be a client side HTML5 drag and drop that encrypts files pre-transmission. Should be symmetric so both source and journalist are reading messages on an airgapped laptop.

solutionyogi• 13 years ago

What's your credential to claim that system is over complicated? Are you a security professional? Have you performed a full blown security audit of the system? Have you designed an alternate system which is less complicated and equally secure?

jarrett3• 13 years ago

There should just be a client side HTML5 drag and drop that encrypts files pre-transmission.

The problem is that you'd be doing crypto in JavaScript. We're not currently at a point where that's viable:

http://www.matasano.com/articles/javascript-cryptography/

Currently, if you want to securely transmit a document, you're pretty much stuck with learning and using something like PGP/GPG. Which is a pain for a lot of people, because there are new concepts to learn, software to install, and keyrings to manage. But it's the best we have right now.

JshWright• 13 years ago

I'm not sure you understand what 'airgapped' means... (Hint: WiFi doesn't count)

not_rhodey• 13 years ago

I'm inclined to agree with you, generally speaking simplicity is security. Also, I believe that the "secure JS in-browser crypto is impossible" argument is entirely bunk in this context-- people need to stop reciting this compulsively and take the time to think each situation through.

Realize that the SecureDrop document submission client is a web application. The browser of the document submitter will run whatever the SecureDrop Source Server provides it barring the edge case of the submitter verifying the source page source with GitHub before allowing JS in NoScript.

The security of the document submitter is already prone to compromise by way of a malicious web app provided by malicious Source Server or MITM. Moving the project to something more JS heavy on the client side would in no way worsen the threat model.

andrewcooke• 13 years ago

https://tnysbtbxsf356hiy.onion.to/privacy

[not sure why that's been downvoted - it's the same system, and it explains what security guarantees are provided in layman terms.]

danso3• 13 years ago

There needs to be more information on now usable this is. That is key for adoption but particularly so at media organizations where many of the professionals can barely operate a spreadsheet. When security systems get cumbersome, they take shortcuts in security. Hence, the recent number of high profile Twitter phishing hacks among news orgs

willvarfar• 13 years ago

As they are now getting arrested and wire tapped, they are heavily motivated to do it right though?

Suddenly they realise that they must be scrupulously disciplined.

larrys• 13 years ago

I agree.

But then again remember (I do) those drivers ed videos in high school. (They were "films" back then actually) They showed all the bad things that could happen to you if you drove fast. They scared the you know what out of you. It lasted for a few days. Then most went back to driving as they wished.

danso3• 13 years ago

It's true that even having something like this software imbues a certain awareness of, "Gee, if there has to be special software to keep transmitted files secret...does that mean all the other times I've been transmitting files via email is unsafe?"

But even when the spirit is willing, the flesh is weak...It's been well known for at least a century that you should wash your hands before doing critical surgery...and yet today it's been somewhat of a revolution to mandate checklists that enforce this at modern hospitals. It's not because surgeons are stupid, it's because the workflow can be so dynamic that critical, easy steps are often missed when unexpected scenarios occur...especially when humans are involved (i.e. all major surgeons today)

http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...

tomp• 13 years ago

So... can this protect against internal attack, or attack by courts, like the one witnessed in the Lavabit case? I certainly hope so, since it uses TOR, but I don't know enough about TOR to be able to claim that the source remains hidden even if the destination is owned.

Another possibility is that courts would allow journalists to keep their sources hidden, but I wouldn't count on it...

pessimizer• 13 years ago

As far as I can tell, the journalist wouldn't be able to identify the source, or even the codename that the source was using in order to interact with them.

splatcollision• 13 years ago

Github Link: https://github.com/freedomofpress/securedrop/

shennyg• 13 years ago

Try The New Yorker's Strong Box without a client: https://tnysbtbxsf356hiy.onion.to/

danso3• 13 years ago

The audit that Schneier participated in doesn't sound promising. These things stuck out to me:

http://homes.cs.washington.edu/~aczeskis/research/pubs/UW-CS...

First, we experimented with leaking data to our DeadDrop deployment. We are not aware of the ways that actual leaked documents are submitted, but we assume that this way of leaking data is at least plausible.

In this controlled test, the researchers found that the app did not protect against sources accidentally including their meta-data in the submitted files (i.e the Properties of a Word Document, for instance)...this meta-data has been a classic source of amusement and stories for journalists when they make public records requests and government officials forget to remove it...so, in other words, given that DeadDrop is meant for tech novices...it did not, in its audited form, protect against one of the most basic human-snafus in document-leaking.

But that can be fixed...what I'm concerned about is that this audit -- and Aaron and his original collaborators -- may not have considered the other less obvious human vulnerabilities. For instance...many (if not most) leak investigation/prosecutions happen well after the publication of a story. It's not the journalist who gets the hammer, but the whistleblower.

At this point, the "attacker" (the government authority) has a short list of candidates for who the leaker could be: i.e. anyone who had access to the info that a journalist published...It's not a matter of intercepting all of the journalist's communications, but intercepting all of these shortlisted suspects' communications, and any prior network activity, either at the workplace, from their work phones, or even at home.

The "attackers" could seize on something as seemingly innocuous as the leaker visiting "newsorg.com/deaddrop/faq" from his office computer. And sure, they can't prosecute on something that circumstantial...but that's not the point...they just have to keep limiting their scope and keep questioning (the suspect, the suspect's associates) until they find the smoking gun.

I think too many tech people (though not Bruce) think that this process fails alone on the technology...i.e. if they can't break 4096-bit encryption, then you're good to go. But they don't have to break the security technology, just the person.

This should be pretty clear from the story of Silk Road's takedown, which was operated by someone who was more technically savvy than most of DeadDrop's audience:

http://arstechnica.com/tech-policy/2013/10/how-the-feds-took...

The Feds didn't get their initial lead by using sophisticated NSA wiretapping. They did the kind of Google work that every amateur researcher can do: look for the earliest mentions of something that was previously unheard of, and find the pattern in those mentions:

The post directed readers to visit silkroad420.wordpress.com, belonging to the blogging operator WordPress, where further instructions would be found for accessing the real Silk Road site. A subpoena to WordPress Revealed that the blog had been set up on January 23, only four days before the Altoid post. If this wasn't the first mention of Silk Road, it was certainly one of them. Altoid became a person of interest, but who was he? Further research revealed that Altoid had been posting on a board called Bitcoin Talk—further suggesting a possible link to the Silk Road, which operated on Bitcoin. A key break came when the agent found an October 11, 2011 post by Altoid, looking for an "IT pro in the Bitcoin community" and directing all inquiries to "rossulbricht at gmail dot com."

Protecting against this kind of info-leaking before using the app is outside of DeadDrop's purview of course...but that's kind of the problem. The kind of exposure vulnerabilities that leakers face is not typically from encryption cracking, but inadverdent human mistakes...

But perhaps even having a DeadDrop, heavily used or not, will at least put everyone at the news org (and their sources) on a higher level of situational awareness, and that would be valuable enough.

danielweber• 13 years ago

Is Schneier any good at auditing code? He has a big name but that's not my question.

Goopplesoft• 13 years ago

Well he does have an extensive background in cryptography: http://en.wikipedia.org/wiki/Bruce_Schneier#Cryptographic_al...

But more than that University of Washington and Jacob Applebaum (tor) participated (http://en.wikipedia.org/wiki/Jacob_Appelbaum)

OvidNaso• 13 years ago

I don't know the answer, but don't forget that Schneier got his initial fame from writing Applied Cryptography.

dobbsbob• 13 years ago

His team created Skein and it was a NIST finalist for SHA3 so he obviously can audit code. He also I believe has a position this year at a university for a few months to work with students and their graduate projects in crypto engineering.

fsckin• 13 years ago

Protecting against this kind of info-leaking before using the app is outside of DeadDrop's purview of course

I don't think it is outside the purview of DeadDrop. It is a huge bug that MSOffice files, PDFs, images, etc. leak meta data to the journalist. Meta data can (and should) be stripped on the fly during upload and never logged.

Anonymity through obscurity is pointless if the journalist can be compelled to turn over original files (containing meta data) that could identify the source.

emiliobumachar• 13 years ago

Your parent mentions two issues. The one out of purview is when the whistleblower associates the topic to their identity before the leak, on the internet, in a way that may not draw attention at the time but stays registered forever.

rsync• 13 years ago

Can we rename the meme "war on whistleblowers" ?

When it is phrased like that, there's some ambiguity about the whistleblower ... since there could be good ones and bad ones. Further, a lot of folks may have been swayed by propaganda and believe that "whistleblower" is a negative term in all contexts.

I would like to suggest:

"war on transparency"

Cheers!

yeukhon• 13 years ago

So this system at its best is just GPG?

SecureDrop

Related Stories