Not logged in » Login
Jul 29 2015

Google Introduces “Customer-Supplied Encryption Keys”

Online storage services are still the killer application that prompts users to flock to and around CSPs, regardless of where they are – at home, at the office or on the go. But protecting confidential information in such environments isn't exactly easy, especially if there's no encryption option or the CSP has access to customers' encryption keys. Google's new service – currently in beta state – is an attempt to give users "more control over how [they] manage security on Google Cloud Platform."

Since yesterday, users of the Google Cloud Platform have been able to add an extra security layer for data that is best kept secret, e.g. files from the R&D department or silly snapshots taken at the latest company get-together. Typically, such info was already encrypted before while at rest in the one-time search giant's cloud, with the process being "handled and managed" by Google's very own Compute Engine without any kind of customer interaction. But while most users were fond of automated encryption in general, quite a few were concerned about a lack of control and being involved. In other words, they didn't like the idea of 'Big G' providing and managing the encryption keys, since that meant its staffers would be able to access and decrypt confidential data at any time – especially if ordered to. So to prevent inopportune discussions, the company decided to hand over some of the control it had previously reserved for itself – and allow users to "protect Google's encryption keys with AES-256 encryption." That means, Google's servers still generate the keys, but afterwards users can apply their own keys (and key management policy) to further complicate data breaches. According to a recent announcement made in Google's Cloud Platform online documentation, "only users who can provide the correct key can use resources protected by a customer-supplied encryption key." Moreover, the firm promises not to store any "customer-supplied" keys on its servers, which would mean there's no chance for its employees to read or alter stored information unless users hand them over (or leave them somewhere on the rented servers by mistake). The downside is that users who forget their keys are left in the lurch, as Google won't be able to recover any of them – and neither the data encrypted with the encrypted keys.

The service is currently undergoing beta tests, so for the time being comes with a number of built-in restrictions. Number one is limited availability. Per the above-mentioned blog entry, only customers in seven select markets – Canada, France, Germany, Japan, Taiwan, the U.S. and the UK – are eligible to run the tests. Users from elsewhere can request to have their countries added to the list. Numbers 2 to 6 are technical restrictions:

  • At the moment, the mechanism only works with newly created persistent disks and cannot be applied retroactively to existing persistent disks.
  • Likewise, it won't work with local SSDs, Google Cloud Platform's alternate storage medium for VMs, because they cease to exist as soon as the governing VM is terminated.
  • Users can't stop an instance with a persistent disk that has been encrypted with their own key because it is not possible to provide a key when restarting a stopped instance.
  • Admins must use the Compute Engine Beta API to inject their keys into the process.
  • Customer keys must be provided as "a 256-bit string encoded in standard base64."

Alternatively, Google suggests RSA key wrapping as a method for encrypting encryption keys. In this case, users would employ an RSA public key certificate that's provided by Google to add an extra protective layer. The problem with this approach is that the data (keys) encrypted with such a public key can only be decrypted with the matching private key, which in this case belongs to the search-giant-cum-CSP. That's probably not quite the privacy customers had in mind.

For a detailed description and technical advice, please see the cited online documentation. Those of you who'd like a little more background info should read Thomas Claburn's piece at InformationWeek.


Comments on this article

No comments yet.

Please Login to leave a comment.


Please login

Please log in with your Fujitsu Partner Account.


» Forgot password

Register now

If you do not have a Fujitsu Partner Account, please register for a new account.

» Register now