FWIW, Google has been doing this for some time, well before the current controversy. A few months ago, it was reported that Google was challenging the courts on the highly secret national security letters, which mandated that recipients not disclose their existence and which were issued without needing court approval:
NSL's are a serious issue and as much a threat to our liberty as what was disclosed by Snowden's leak. The outrage sparked by Snowden's effort is hopefully something that leads to good reform and protection of our liberties, but the fodder for outrage has existed for a long time now.
"If Amazon faced a subpoena that required it to keep the order secret, such encryption would be useful to customers. “If the data is encrypted, all we’d be handing over would be the cypher text,” he said."
That strikes me as a little misleading. I'm sure the subpoena would request a snapshot of all running VMs's memory & CPU state, from which (I believe) it's relatively easy to extract encryption keys. If the first subpoena didn't, the second one sure would!
The terrifying thing is that they could be required to keep doing this in the background indefinitely, compromising both all the data and any future users -- sort of like the Hushmail compromise.
Using AWS the way cpercival does for tarsnap (with keys managed outside, and S3 as dumb storage) is reasonable. Using AWS to run a game or other toy app is reasonable. Using AWS if you yourself are a USG entity (and thus immune to lesser legal action) is fine.
I can't imagine using AWS (or any outsourced cloud provider) to run sensitive apps using current EC2-type technology in the current legal climate in the US. The other scary thing is AWS is probably among the best providers for technical security, and still has this vulnerability (disclaimer: I haven't yet checked out Google Cloud Engine much).
Colocation or managed hosting is borderline in some situations too (particularly if you allow the provider unlimited access to singleuser mode on your boxes, don't encrypt drives, manage keys and credentials through the provider, etc.), but it's a lot better than virtual hosting for anything at all sensitive.
It's not just official USG action to fear; it's provider staff or technical compromise as well.
Hushmail had you log in with u/p first, then would serve an applet, which would then download your encrypted private key and you'd decrypt it locally. They used your public key to encrypt incoming mail and store it until you wanted to log in to view it (which is a fundamentally reasonable approach; the problem is compatibility with existing mail clients, and search, but you can solve that by downloading to a local mail client using something "special" and running search locally as well.)
The enemy made Hushmail serve a "bad" applet to certain users which (in addition to decrypting) sent back either credentials or key to hushmail (and thus allowed decrypting of the mail).
There are ways to address this attack but they're essentially in the realm of release engineering and separation of control; you have one group develop, another group serve, another group execute, and the groups have to be mutually distrustful and audit everything that passes between them. This is hard.
The irony is I worked for the company which developed the initial hushmail product back in 1998/1999. It had to be done by non-US Citizens due to export control, so I wasn't involved, but pretty much as soon as it was clear they weren't going to address this (obvious) attack in their threat model, I assumed they were either incredibly incompetent or an active honeypot, so I ceased any involvement and never used the product. (an adequate solution for java applets would have been putting the signing key under neutral third-party control; I don't think a java applet based solution is viable today, since java is such a clusterfuck; I'd just do a secure iOS or Android app instead and stick to mobile users, like silenttext does from silentcircle).
I'd personally skip webmail or even desktopmail and just build something which is mobile-secure-mail/messages/voice.
Silentcircle is my favorite voice product right now, but it's fundamentally doomed (IMO) due to being commercial on both sides. I'd want something where at most one party in every communication is a paid user, and the counterparty uses a free and lightweight app. And/or something with great group management functionality, which it also doesn't do. The market for discrete individuals who both pay for the service and only communicate with other discrete disconnected individuals is kind of zero.
Crypto.cat seems to be a browser extension only model now, which is a lot better. I don't use it and haven't looked at it seriously, so I don't know what kind of auto-updating it does, which would be a problem. Assuming the authors (or someone else in control of their extension-submitting password) wanted to serve malicious code, they'd either need to get users to manually download a "bad" extension, or auto-update. To the extent that the browser vendors can be trusted, this isn't as big a problem -- you couldn't backdoor just a given ephemeral applet, so someone might catch it. OTOH, I think a browser vendor could choose to give a single user a "bad" extension, and could modify it themselves without crypto.cat's involvement, so you can only trust it as much as you trust the weakest of Apple, Microsoft, Google, Mozilla, Crypto.Cat, or anyone who can technically or legally compromise any of them.
Crypto.cat internally implements OTR now, so it has forward secrecy. So all of these attacks are around gaining limited access -- to the contents sent using the exploited application.
The old javascript version was at risk to cloudflare, the crypto.cat team, and everyone else. Plus browser exploits. It was horrible. The worst part was the crypto.cat developers responded very...emotionally...to any criticism of their security, which kind of detracted from the whole thing.
This whole "binaries distributed by a third party" model used on mobile and for browsers does expose a lot of problems. Since there isn't a strong cryptographic signature on the binaries linked to a key uniquely controlled by a developer and securely distributed to the end user and verified in something the user can trust, the platform or store vendors (Apple, Microsoft, Google, Mozilla, ...) can pretty much screw users at will. (they can just use a different trusted key to sign the binary).
The old "distribute source code with PGP signatures or signed hashes of the tarballs" is still the best way to distribute secure software.
My #1 feeling about crypto.cat is extreme envy for the Catalan domain name.
The impression I get, as a consumer, is that I can no longer trust official statements from the likes of Google, Amazon, etc since they could have been legally gagged from telling the truth. I've lost confidence in US tech companies, because they could be forced to act without being allowed to disclose it or reasonably fight it.
To date I still don't believe what Google/Amazon are saying. It all feels like weasel words. Like when Obama stated that the NSA "cannot" listen to your calls. He meant that they cannot by law, rather than cannot because they dont have access. The way he phrased it though meant that 80% of people listening would've thought it was the latter definition.
And to have the National Intelligence guy on record lie to Congress? Who is controlling whom here? It really does feel like the US government has lost control of its intelligence services.
Now don't mind me, I'm busy trying to find somewhere on the map I can relocate my services to.
> He meant that they cannot by law, rather than cannot because they dont have access.
Really what he meant is that the NSA can't target their listening at you, but they certainly can listen to your calls accidentally or in a mission targeted at some other person or targeted at you if they don't know for a fact that you're a U.S. person, and once they do listen to your calls, they certainly can forward that information to any appropriate law enforcement agency to take action against you, and they certainly can use that information to get a warrant to legalize targeting you if need be.
So really what he meant is that yes, the NSA can listen to your calls, "legally", in almost all circumstances. By taking care not to initially link up phone numbers and names/addresses, they can maintain that they didn't know you were a U.S. person for as long as they need to.
If you didn't understand that from his use of the word "cannot", well, I guess that's just your poor listening skills at fault.
> “If a U.S. entity is serving us with a legally binding
> subpoena, we contact our customer and work with that
> customer to fight the subpoena. We will do that proactively
> and help the customer in any way to comply with the
> subpoena or fight it.”
How does that work, with gag-ordered FISA requests?
This is answered directly in the article where they suggest you take advantage of their encryption offerings.
> If Amazon faced a subpoena that required it to keep the order secret, such encryption would be useful to customers. “If the data is encrypted, all we’d be handing over would be the cypher text,” he said.
It doesn't protect you meaningfully as an EC2 user, since there's no (current, on AWS) way to do an "encrypted VM" where everything including memory is encrypted and the hypervisor can't be coerced into decrypting it en masse.
It does protect you for S3 if and only if you conduct the crypto outside AWS and generate/manage the keys yourself (e.g. how tarsnap does it). It may protect you for some of the other AWS services IFF you use them in the same hybrid way, but I don't know of anyone who uses AWS's database services without just using EC2 nodes primarily to talk to them.
AFAIK there is no curent, practical "encrypted VM" that can protect itself from the hypervisor. Homomorphic encryption can theoretically do that, but is very slow and unproven right now.
I only glimpsed it some years ago, but I got the impression that "anything the vendor can do, the attacker can circumvent one level deeper", especially as a criticism of TXT:
One interesting tidbit from the AWS re:invent conference in November: According to Stephen Schmidt, Amazon does regular "drills" where they pretend that a warrant has been received for a user's data, and they need to identify and isolate and copy all of it.
This tells me two things: First, that Amazon gets these requests often enough to have a well-tested procedure for handling them; and second, that it's still very much a manual process -- and that government agencies can't just reach in and grab data on their own.
As an alternate explanation: we practice fire drills, but that doesn't mean building fires are routine. Drills are indicative of something you want to get right when the time comes, not frequency.
They're in Switzerland and seem committed to maintaining your data/security (and they have the full force/support of Swiss law).
Their UI is super usable. It's a true pleasure to use. You can choose from several posix distros and a Windows one. There's decent selection for different sizing. But they're in beta now, so there's not a full lineup of features. The pricing is very good. And the support is awesome. I've raised a couple of tickets and they were responded to in a couple of hours.
If it's true that the US authorities can order a company to implement access for the NSA and lie to its customers about the fact, I don't see how you can trust any US company with data that need to be secure.
Also, AWS recently signed a huge deal with the CIA (http://www.businessinsider.com/cia-600-million-deal-for-amaz...). I doubt that a company that works so closely with US government agencies is jumping through hoops to protect its customers from government snooping.
I don't understand the whole fight subpoenas and contact the customers thing. Isn't a big part of the PRISM system them NOT having direct access and just trying to collect all the data from certain systems and rebuilding it, or pulling stuff from it? Like basically just tapping the line?
http://www.wired.com/threatlevel/2013/04/google-fights-nsl/
NSL's are a serious issue and as much a threat to our liberty as what was disclosed by Snowden's leak. The outrage sparked by Snowden's effort is hopefully something that leads to good reform and protection of our liberties, but the fodder for outrage has existed for a long time now.