Google Cloud Now Allows Customer-Generated Encryption (thestack.com) 19
An anonymous Slashdot reader quotes The Stack: The Google cloud platform, Google Compute Engine, now allows customers to create their own encryption keys as an alternative to the Google-provided default encryption. Google Compute Engine automatically encrypts all data at rest, managing customer data encryption as a part of the Compute Engine service. However, some customers prefer to manage and control cloud encryption internally, to further tighten data security.
Google has released a comprehensive set of instructions for a customer to create their own encryption key. The Customer-Supplied Encryption Key (CSEK) is then used to protect the Google-generated keys that are used automatically for data encryption. The CSEK is an additional layer of protection for data stored in the cloud. Using an internally-generated encryption key also allows customers to control data encryption without using third-party providers, whose services are available at an additional cost.
Google has released a comprehensive set of instructions for a customer to create their own encryption key. The Customer-Supplied Encryption Key (CSEK) is then used to protect the Google-generated keys that are used automatically for data encryption. The CSEK is an additional layer of protection for data stored in the cloud. Using an internally-generated encryption key also allows customers to control data encryption without using third-party providers, whose services are available at an additional cost.
Not Client Side? (Score:3)
If it's not Client Side encryption, it's not encrypted.
Re: (Score:3)
Of course you are right, but there is no way around this: if you want your cloud-based instance (i.e. VM) to boot, the disk must be readable by the virtual infrastructure, so they must have the key to decrypt it (according to the instructions, you also have to supply your key when you restart an instance, but of course this does not prevent them from storing it without telling you). This is probably useful for clients who want some form of granular control on their infrastructure: Google can still access y
Re: (Score:1)
Oh, and it'll run slower than a machine from the 80's.
That's OK - we're already sprinting towards that goal by re-writing everything in javascript.
Re: (Score:3)
Homomorphic encryption won't run anywhere near that fast ;)...
Re: (Score:1)
It's code that likes reach-arounds? Or it back-doors itself?
Re: (Score:3)
This is a move by Google to allow enterprise key management systems employed by big business to operate in the Google Cloud (previously a very hacky arrangement.)
I wouldn't be surprised, given Google's new focus on the Enterprise with GCE (note the leadership changes), to see Google Docs starting to embrace a 'bring your own' encryption feature set to its applications as well.
This would be a differentiator for Google as Microsoft's solution (RMS) really doesn't work well in this scenario and Amazon is start
Re: (Score:3)
Google would be the first with a cloud offering, encryption integration points, and an enterprise encrypted document play that could be federated. The fear is, as some other posters noted, will Google commit to this or just do it for 2 years and then dump the whole thing?
If it has a revenue stream, (paying customers - not advertising) they probably won't dump it.
Security theater (Score:3)
If you need to share the key with the provider, sorry, by definition, this does not prevent the provider from peeking at your data. This is just, again, security theater, and will allow many business secrets to be in the hands of a company whose real customers are government agencies.
Yes and no (Score:4, Insightful)
If you need to share the key with the provider....
Yes, it's not the same a client side encryption. It's hardly an alternative, but it is most certainly a valuable addition.
It won't protect you from the NSA, etc.. But it can protect you from accidental leaks of credentials, compromised accounts, rouge under paid datacenter interns, discarded harddrives ending up who know where... Or software bugs at the provider.
It's an extra layer of attack mitigation that you should use in combination with client encryption, because client side encryption is easy to get wrong, so having an extra layer is good.
Also I'm sure this helps with compliance of regulations that might not always make sense...
Re: (Score:2)
It's not security theater - it's not intended to make things 'more secure' - it's intended to allow enterprises (Fortune 100 types) to integrate their existing centralized key management systems into GCE so that they don't have two sets of keys, two sets of audit data, two sets of key policies, et cetera.
This will make it an easier decision for enterprises to push their key-oriented applications/systems/service-bus' into GCE. Previously this was a pain in the rear.
Re: (Score:3)
> If Google knows my private key, how is it private?
It's not, but it's more protection than using their default service. Remember, there are a LOT more potential attacks besides "google is wholly malicious or compromised utterly and remembers my keys". There's attacks where google's keystore could be compromised, but if google isn't storing your key, that won't be enough to attack your data, for instance. Given how large and juicy a target Google ultimately is, it is reasonable to layer some security