Last week I passed along Google’s announcement that they now encrypt all cloud storage by default. I mentioned how this was following Amazon’s offerings of encryption for their S3 storage service.
We have been comparing Amazon’s client-side and server-side encryption in Learning Tree’s Cloud Security Essentials course for some time, and now Google’s new service needs to be mentioned. But as I said last week, Google’s encryption is just a feel-good feature providing a false sense of security. The path followed by Amazon provides the clearest explanation of both the technical and social angles.
Amazon’s first encryption offering for S3 storage was Client-Side Encryption. The customer uses a Java SDK (or Software Development Kit) to do the key management and encryption within an application on the client machine. Amazon provides further details if you’re interested. The encryption is done under the full control of the customer, Amazon is uninvolved beyond providing the Java SDK. As Amazon promises and then warns:
Your private encryption keys and your unencrypted data are never sent to AWS; therefore, it is important that you safely manage your encryption keys. If you lose your encryption keys, you won’t be able to unencrypt your data.
Early adopters of AWS found this very useful, but then early adopters of technology are more willing to get their hands dirty with the details. When they were audited for compliance, they could show their application codes and the hooks into the cryptographic API, and then demonstrate how they have to generate and manage their own keys because there is no place to store their private in Amazon’s data structures.
People who came to cloud storage later found the idea of encryption good, but the details and implementation work bothersome.
Amazon, like most any company in business to make money, knew that you make more money by providing more things that people are willing to pay for. So, they announced Server-Side Encryption. This can be used through programming APIs in Java, .NET, PHP and Ruby; through the REST API; and through the graphical management console.
Now, with Server-Side Encryption, Amazon says that they use 256-bit AES, and they generate and safely store a unique key for every data object. It’s not that I doubt them, but I certainly can’t prove that that’s really what they’re doing.
All you see is that your storage request is accompanied by a “Please encrypt this for me, OK?” parameter. And, when you check on your stored data objects, there’s a flag indicating “Trust us when we say that this is encrypted.”
I would have to warn a consulting client that while this looks the way that Amazon says it should look, we have absolutely no way of telling whether the data was really encrypted on Amazon’s servers. I don’t see how this could satisfy an honest compliance requirement.
And, the continuing NSA surveillance revelations show that this isn’t going to keep the U.S. Government from reading all the data supposedly protected by Server-Side Encryption, meaning that this would violate the compliance requirements of pretty much everyone except the U.S. Government.
Sorry, Google, I wasn’t fooled by Amazon’s easy check-box “security”, so a very similar Google-branded offering isn’t attractive either.