New - Amazon S3 Server Side Encryption for Data at Rest | Hacker News Reader

New - Amazon S3 Server Side Encryption for Data at Rest

aws.typepad.com

66 pointsjeffbarr44 comments

So they're allowing us to store our data in encrypted form, but they keep the encryption key, and will decrypt requests for the data?

How exactly will this protect my data?

I think it's designed to stop someone driving a tank into the datacenter and making off with the hard drive.

B-b-but they have my keys stored in that datacenter !

Don't worry. That datacenter's keys are stored on the encrypted disk at the other datacenter ;)

Darn, so they have effectively doubled the cost of data theft from one tank to two tanks.

Agreed, this is more of an item to check off on a list than an actual, meaningful feature. It's the kind of thing that some exec who doesn't understand the details will take comfort in, even though at the end of the day the benefit is minimal.

The only way to do this safely is to do the encryption yourself prior to uploading to S3 and manage the keys yourself.

Yes, this. It's awesome that AWS is providing server-side encryption at no additional cost and with no additional client-side implementation effort, but ultimately your data is still at risk.

When Dropbox's authentication layer failed, their encryption was meaningless. Same thing here: data is still vulnerable to errors, misappropriation, subpoena, etc.

This is an 'enterprise-friendly' feature - the appearance of thorough security ("all our data is stored with AES-256 encryption") with only a nominal increase in actual security.

Just think: there will be AWS accounts using this while their master AWS console account continues to have a single-dictionary-word password and no MFA. Truly the Cloud is the silver bullet to save us all from shoddy CIOs!

Well it's another link in the security chain.

You would be negligent not to implement this if you're storing sensitive data on AWS. No?

As I understand it the encryption adds both latency and more points of failure to S3 (keys stored on separate servers). How is adding both of that negligent?

From a security point of view the encryption adds no value at all: Either I trust Amazon to not look at my data, or I don't trust them. If I don't trust them with my data, surely I also can't trust them with my encryption keys.

I've already got this implemented by using duplicity for backing up to S3. All my data is securely stored using GnuPG and encrypted on upload.

Absolutely. This feature is really bad. I would even argue that, giving people who have no idea about security an additional false sense of it, actually decreases security overall. Now people will more likely give their money for this feature instead of paying a proper security analyst to implement security client side.

The reason why this is a big deal is that it appears to satisfy PCI DSS requirements for key management (though I'm curious about their key rotation strategy). E-commerce hosts just got a lot more interested in S3.

From the business perspective I believe that we are talking about a whole new market, not just a feature.

I compare this business initiative with the past "e-mail managed service" market, where companies moved their own e-mail infrastructure to third parties (postini, messagelabs, mxlogic), something unthinkable (from a security or control point of view). Now security is moving to a managed service, seems strange but it can follow a similar route (new companies in this space + acquisitions by leaders).

Adding Identity Cryptography [http://en.wikipedia.org/wiki/ID-based_cryptography] to the game it will attract a lot of corporations.

A big advantage to this is for applications that require HIPAA compliance. One of the rules for HIPAA is to encrypt data at rest. There may be better ways to encrypt your information, but this will tick a box for compliance purposes (the advantage of this shouldn't be underestimated).

It basically allows HIPAA abiding applications to use S3 for data storage without the complexity of dealing with the encryption themselves, or using a 3rd party provider that offers this by proxy.

The only remaining step is to trial and error your way through using it due to the "light" documentation.

I don't see how this can work at all if Amazon has access to your keys but doesn't sign a Business Associate Agreement under HIPAA. They've refused to do this for us.

It might be viable to encrypt yourself and keep the keys, because then you're not giving them PHI---just goblety gook.

Could someone duplicate this server side encryption by inputting a key to hold in RAM that handles encryption? Or possibly a second server that accepts encrypted data and sends back decrypted data?

Which means that every time a system needs to reboot, losing key in RAM, someone needs to put in the key.

My naive view means someone with a tank can't run off with unencrypted data.

Google cold boot attack. Someone with a tank, a screwdriver and a can of coolant spray can.

Couldn't the same be said of AWS's offering too?

These are virtual machines right? You can easily read the contents of a virtual machines RAM from the host machine whilst it's running if you want the encryption key.

I'm not sure why they'd virtualize pure storage nodes. There'd be no benefit.

I neither stated, nor implied, that Amazon are doing that.

Ah, but you essentially have the 'evil maid' problem Schnier described. So I somehow gain physical access (or otherwise gain root) I then shut the server you are on down and replace the program that accepts your encryption key with my own program that saves the key for my own use. You'd see a reboot, you'd login and input your key, and I could run off with your data.

There are several other ways to do this; but really, countering the 'evil maid' attack is quite difficult.

Hence my second suggestion, a separate server akin to what AWS's post offered. Essentially the encryption server will get encrypted data, de-crypt it and then sends it back to production server (vice versa). It's not public facing, etc. Which means the attacker has to try to compromise the second server that's more locked down.

Or are you saying evil maid attacks can breach the VM they're on?

Pretty sure there is no VM involved... there'd be no reason to virtualize your storage nodes.

But yeah, you are right that if you kept the keys and did the encryption on the second server, you'd have to do the attack on the second server; but that's really just moving the problem around.

Configuring duplicity/rsync to use encryption, for example with database backups, was simple. There are a few guides around and in the end you retain control of your own encryption.

This can provide protection for example against a scenario where some of the hard disks used in S3 happen to end up in wrong place - for a reason or another. One should keep in mind that all data that is once put to the cloud can stay there forever - even if you try to delete it.

It'd be nice if they added first class support for accept-encoding after all these years.

or for custom headers, so that I could, for example, serve all my fonts from S3.

I thought you could set custom headers already.

You can set custom headers as long as they are prefaced with x-amz-meta...Other than that, you're limited to just a handful of headers. See my reply to thamer for more info.

You can, but maybe not from the web interface. I use s3cmd to upload files, and it sets the content-type just fine.

You can from the web interface too. You just have to right click to get to properties, then there is a tab for setting headers.

Sure, you can set custom headers as long as they are prefaced with x-amz-meta...Other than that, you're limited to just a handful of headers. This is a big deal for fonts because the Access-Control-Allow-Origin must be set appropriately to be able to use custom fonts from a different origin (i.e. host&port) and S3 will pretty much always be on a different origin than the rest of your website.

You can read more on the AWS forum post about the issue: https://forums.aws.amazon.com/thread.jspa?threadID=34281

Edit: For those interested the complete list of allowed headers is here: http://docs.amazonwebservices.com/AmazonS3/latest/API/index....

This is slightly off topic, but does anyone else find the AWS dashboard impenetrable? You have to hunt for each of the services you need to add, configuration is very well hidden and I can never find my S3 keys. I had to bookmark the link from the email because otherwise I kept going around in circles. I haven't used EC2 yet just because I'm intimidated by the complexity of that management interface...

Is it just me?

No you're definitely not the only one. My company uses EC2 for our production environment and I loathe the management interface with a passion. Amazon should definitely hire a UI expert to give that damn thing a face lift.

It's a mix really, some of it works beautifully, some of it leaves me thinking "I like this but... why haven't they tweaked x" and some really is just horrible.

New version of S3 Browser Freeware supports Amazon S3 Server Side Encryption: http://s3browser.com/amazon-s3-server-side-encryption.php

So now we can just point to Amazon when FBI asks for the keys, allowing us to blame Amazon when users raise their pitchfork? I like that.

Unless, of course, you are the victim.

This is excellent for backups to reduce server load on the client side (no more need to encrypt locally).

I assume there is no extra charge for this from Amazon? (ah I see the footnote, no charge for SSE)

I guess this also means you can upload very large objects without having the hassle of local pre-encryption too - this assumes you have a secure https link to aws though.

Of course this also means aws has your keys stored somewhere which is less secure.

Hmm - if there's no additional charge, why not do this by default?

Always a risk of data corruption, key management issues, etc. when encrypting at rest.

There must be some performance hit, however insignificant.

Reply on news.ycombinator.com