The road towards an integrated SecureDrop workstation(securedrop.org) |
The road towards an integrated SecureDrop workstation(securedrop.org) |
Just keep the air gap; anyone using this software can afford an extra computer. Put the two machines next to each other; duct tape them together if you want, or put two USB hubs on your desk - pull USB drive out of slot A, put it in slot B. And put the USB stick shredder directly beneath slot B. Not hard for the user: 1-2-3.
Even more importantly, it's critical that they communicate accurate information, in an unmistakable way, about the level of security they provide. Statements like these are troubling:
> Based on the threat model analysis, we will perform additional hardening of the prototype.
This implies they can actually protect their users against the attackers, which is not reasonable.
> Thanks to the work of developer Joshua Thayer
There is no way that one developer can possibly, in a lifetime, provide adequate security. You can't do it on the cheap. Joshua is facing multiple attackers with budgets in the millions and billions and with teams of hundreds or more specialists. He has my sympathies; will he get the blame when it fails?
Furthermore, your thread model is exaggerated. Yes, "they" have giant budgets. No, "they" won't call in the cavallery in most cases because most cases are simply not important enough to justify expenses beyond "an intern clicks through the existing tools".
Finally, if you want real security, do as a farmer(!) friend of mine says: Leave all electronics at home and go for a long walk with your source.
Three thoughts:
1. SecureDrop, like any security, has to work in the worst of circumstances, not just the best.
2. Governments are highly motivated to persecute journalists and their sources. Even in the U.S., the home of the 1st Amendment, look at leak investigations. SecureDrop is a very valuable target, an accidental honeypot for leakers.
3. Access to information before it's published can be extremely valuable. People can take steps to counteract bad news and even embarrass the journalists. And info that moves market prices in any significant way, whether stocks, bonds, commodities, derivatives, currencies, etc. is worth many millions, at least, and possibly billions.
It is much better to use cd-roms than usb (and to destroy/shred the cd roms after you pull them out of the secure machine you use to read data).
If you need to send data, using a second air gapped machine for that is probably best. This prevents a crafted file that gets root on the reading machine from phoning home unrelated documents.
Be sure to cut all the speaker/mic/wifi/bt lines, use an lcd (not crt), and run off a UPS battery, not the grid. Use the computer in a windowless room. This prevents 90’s era surevelliance vans from reading the data from the curb.
When you are not using the machines, store them in a tamper-evident box. One time pad encrypt your key pair, and keep the one time pad key with you. This makes it more expensive to tamper with the machines in a way that will cause them to allow the attacker to later steal them and get the documents / keypair.
Also, remember rubber hose cryptography.
You might be better off using something more mainstream, and blending with the crowd. For instance in recent civil wars, civilians turned mostly to stuff like facebook, fledgling chat apps, burner phones/identities, etc.
I guess the point of this long-winded comment is that nothing I mentioned has anything to do with special software. If you’re going down the path of using the linked system, be sure you understand what it can (and can’t) do for you.
I know I’m wrong about this, but deep down I don’t agree with this. I think the world is always ready for some UX shenanigans.
There is no way a non-expert journalist would be able to use this securely, too many failure modes.
I suspect you could have security levels, depending on your work and preferences. I could see journalists out in the field without reliable internet, so they need persistence for their working files. Others probably can rely on secure connections, so nothing need be persistent.
In any case, I'd want a very straightforward "burn" feature that obliterates persistent working files.
I already expect that history and cache and swap are not persistent, but as history can be ready useful as part of working files I might want an option how to handle it. Case by case.