How exactly will this protect my data?
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!
The only way to do this safely is to do the encryption yourself prior to uploading to S3 and manage the keys yourself.
When Dropbox's authentication layer failed, their encryption was meaningless. Same thing here: data is still vulnerable to errors, misappropriation, subpoena, etc.
You would be negligent not to implement this if you're storing sensitive data on AWS. No?
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 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.
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.
It might be viable to encrypt yourself and keep the keys, because then you're not giving them PHI---just goblety gook.
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.
There are several other ways to do this; but really, countering the 'evil maid' attack is quite difficult.
Or are you saying evil maid attacks can breach the VM they're on?
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.
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....
Is it just me?
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.