

AWS: We’ll go to court to fight government requests for data - breadtk
http://www.itworld.com/cloud-computing/361679/amazon-web-services-we-ll-go-court-fight-gov-t-requests-data

======
justinsb
"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!

~~~
rdl
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.

~~~
ra
> sort of like the Hushmail compromise

That's interesting. I couldn't find anything that describes the hushmail
compromise in this way. Do you have a link that explains it?

(Am currently thinking about how to make a more secure email service)

~~~
rdl
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.

~~~
eliasmacpherson
What are your thoughts on crypto.cat and do you think a similar poisoning to
hushmail is possible with their model?

~~~
rdl
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.

~~~
eliasmacpherson
Thank you very much for the detailed reply, I am glad I asked, I would never
have thought of any of that!

------
cryptolect
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.

~~~
jellicle
> 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.

------
girvo

      > “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?

~~~
noir_lord
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.

~~~
rdl
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.

~~~
SpikeGronim
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.

~~~
rdl
There are tricks you can do with Intel TXT to trust only the CPU and cache
(TRESOR is an example) [http://www1.informatik.uni-
erlangen.de/tresor](http://www1.informatik.uni-erlangen.de/tresor)

It's missing a few elements you'd need to build a really awesome secure cloud,
though. (actually, intel hardware was missing it)

~~~
Nimi
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:

[http://www.blackhat.com/presentations/bh-
dc-09/Wojtczuk_Rutk...](http://www.blackhat.com/presentations/bh-
dc-09/Wojtczuk_Rutkowska/BlackHat-DC-09-Rutkowska-Attacking-Intel-TXT-
slides.pdf)

~~~
rdl
STM fixed that particular set of problems in 2010/2011\. There are still
issues with making all of this stuff useful, though.

------
cperciva
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.

~~~
chaz
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.

------
logn
FYI, for virtual machines, I've been thoroughly impressed with this service:

[http://www.exoscale.ch/](http://www.exoscale.ch/)

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.

------
workhere-io
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...](http://www.businessinsider.com/cia-600-million-deal-for-amazons-
cloud-2013-3)). I doubt that a company that works so closely with US
government agencies is jumping through hoops to protect its customers from
government snooping.

------
hornytoad
AWS will just lock you (or wikileaks) out on gov't request, although they'll
claim that to be "inaccurate":
[http://aws.amazon.com/message/65348/](http://aws.amazon.com/message/65348/)

------
danso
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:

[http://www.wired.com/threatlevel/2013/04/google-fights-
nsl/](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.

------
nacho2sweet
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?

------
hownottowrite
Yes, I'm sure they'll be happy to endanger a $600M cloud contract to protect
the data. [http://qz.com/95994/amazon-is-staffing-up-for-
its-600-millio...](http://qz.com/95994/amazon-is-staffing-up-for-
its-600-million-cloud-for-spooks/)

------
thejosh
Is it just me or is Amazon talking in "from now on" (future tense) instead of
past tense?

~~~
camus
it's pure PR. if they dontcomply => no juicy govermnent contracts.

~~~
kondro
I'd like to see government departments move off AWS once they've built
services specifically for the AWS platform.

------
orokusaki
Ha, this coming from the same company that is helping the CIA build a 600
million dollar data center for spying...

