Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Cloud Now Allows Customer-Generated Encryption (thestack.com)

Posted by EditorDavid on from the cloud-encryption dept.

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.

19 comments

  1. Not Client Side? by icebike · · Score: 2

    If it's not Client Side encryption, it's not encrypted.

    --
    Sig Battery depleted. Reverting to safe mode.
    1. Re: Not Client Side? by Anonymous Coward · · Score: 0

      It's fine, when Google gets bored of this service in 2 years they'll delete* everything anyway.

      *sell information to advertisers

    2. Re:Not Client Side? by mridoni · · Score: 2

      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 your data (or at least the disk images, not the data that has been encrypted client-side and uploaded) but this prevents anyone in your organization from doing the same unless he/she has the right decryption key.

    3. Re:Not Client Side? by Anonymous Coward · · Score: 0

      You could use homomorphic encryption. Such a system would boot and run without the host knowing the key.

      The problem is that I know of no way to exchange ANY data with it without the encryption key.

      Oh, and it'll run slower than a machine from the 80's.

    4. Re:Not Client Side? by Assmasher · · Score: 2

      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 starting to embrace enterprise key management (but is just starting.)

      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?

      --
      Loading...
    5. Re:Not Client Side? by Anonymous Coward · · 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.

    6. Re:Not Client Side? by Assmasher · · Score: 2

      Homomorphic encryption won't run anywhere near that fast ;)...

      --
      Loading...
    7. Re:Not Client Side? by icebike · · Score: 2

      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.

      --
      Sig Battery depleted. Reverting to safe mode.
    8. Re:Not Client Side? by davester666 · · Score: 1

      It's code that likes reach-arounds? Or it back-doors itself?

      --
      Sleep your way to a whiter smile...date a dentist!
    9. Re:Not Client Side? by Anonymous Coward · · Score: 0

      +1
      I read all the time stuff about "secured email" servers or whatever, emphasizing how much non-IT people do not understand what security is...
      You're basically right. If you do not encrypt yourself, on your machine, using your own tools and keys, there is no way you can start considering your data as secured. I say "start" because it is necessary but not sufficient. Other factors are playing a role, like your own keys length, the tools (open source of course) you are using and even the trust you have in person you are sending this data to...

  2. Security theater by ptaff · · Score: 2

    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.

    1. Re:Security theater by Assmasher · · Score: 1

      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.

      --
      Loading...
    2. Re:Security theater by Anonymous Coward · · Score: 0

      For a large company like Google, it would be pretty damn hard to look at your keys (I work for Google). First of all, the binary would not support dumping user keys, so someone would need to add that functionality. Binaries are rolled out through an automated system that build them from the source code repo. In other words, any code stealing a specific customers keys, would need to be checked in. This already means that any Google engineer would be able to see the code and leak it.

      You could of course circumvent the build and deployment systems, but it would require collusion from multiple teams. The probability that you won't find some engineer that will leak such shenanigans going on would be close to nil. If someone with root on the production systems tried to do this, then they would have the problem that everything they do as root would be audited and many operations also show up in customer audit logs. You would then have to again patch binaries to prevent it from showing up and you run into the same problem as above.

  3. Right, sure by Anonymous Coward · · Score: 0

    This is absolute bollocks. If Google knows my private key, how is it private? Doesn't further actual security at all.

    1. Re:Right, sure by cfalcon · · Score: 2

      > 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 on top of theirs if possible and desired.

      But yes, it is does not prevent against every single potential adversary. Still, it is what they can offer, which is good.

    2. Re: Right, sure by Anonymous Coward · · Score: 0

      No, it is not good. It is slightly better than shit, but still quite comparable to shit.

      Currently there is no security on servers connected to the Internet. Pretending there is is bullshit.

    3. Re: Right, sure by Anonymous Coward · · Score: 0

      So we should all just remove all passwords, stop using TLS for e-commerce traffic, right? Since anything is insecure, there's no point doing anything?

      Sorry, but as with any security, you only need to make it more expensive to break into a system than what the value of that system is to the attacker.

  4. Yes and no by jopsen · · Score: 3, 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...

  5. GOOGLY SPY SERVERS CALL THEMSELVES CLOUDS by Anonymous Coward · · Score: 0

    That is the whole story. Google is a fully established United States Government surveillance apparatus in every capacity they exist in.