Insights Into Google Compute Engine

snydeq writes "The Compute Engine announcement at Google I/O made it clear that Google intends to take Amazon EC2 head on. Michael Crandell, who has been testing out Compute Engine for some time now, divulges deeper insights into the nascent IaaS, which, although enticing, will have a long road ahead of it in eclipsing Amazon EC2. 'Even in this early stage, three major factors about Google Cloud stood out for Crandell. First was the way Google leveraged the use of its own private network to make its cloud resources uniformly accessible across the globe. ... Another key difference was boot times, which are both fast and consistent in Google's cloud. ... Third is encryption. Google offers at-rest encryption for all storage, whether it's local or attached over a network. 'Everything's automatically encrypted,' says Crandell, 'and it's encrypted outside the processing of the VM so there's no degradation of performance to get that feature.'"

Comments

Re:Encryption detail?

[MikeHalcrow]

I designed and implemented the disk encryption component of Google Compute Engine. (Trivia: I also created eCryptfs, which backs the home directory encryption in Ubuntu and provides local cache encryption in Chrome OS). PTBarnum outlined some good motivators for why cloud providers should encrypt all data-at-rest, even though they (necessarily) manage the key material. Additionally, it turns out that some customers' regulatory requirements can be met by encrypting all data as it crosses the guest-host VM boundary on its way to storage.

Re:Encryption detail?

[joebeda3]

I'm the TL for Google Compute Engine and was the speaker at that talk. The answer is a little more subtle than that. We have two types of mountable disk -- ephemeral disk which stays on the physical machine and never leaves the machine and persistent disk that outlives an instance is written over the network.

For ephemeral disk, we generate the encryption key on the host machine and it only ever stays in memory. We are careful to control the code paths that see the key material.

For the persistent disk, by necessity, we need to manage the key as part of our overall virtual machine management infrastructure. We utilize some strongly audited and auditable systems to wrap the encryption keys and really lock down the users that have access to the unwrapping service. The name of the game here is to restrict the scope as much as possible.

BTW -- the video for the talk isn't up yet but I just shared the slides here: https://plus.google.com/110707185519531431463/posts/EfDCBjuPiPf.

Re:Encryption detail?

[uncqual]

(iDrive claims to be such a service.)

I tend to take claims iDrive makes with a grain of salt given their approach to "security" on the client machine. If, on a Windows iDrive installation, one looks at (for a typical installation) C:\Program Files\IDrive\UserName.ini, one finds a line of the form:

Encryption password=Vjku_Ku_Oa_Rcuuyqtf_CCCDDDEEE

Of course, not to worry, the password is well encrypted with a sophisticated algorithm. Yes. ROT-2 for alpha characters. Really.

So, this user's actual encryption password is: This_Is_My_Password_AAABBBCCC

I understand that some people want the convenience of not having to enter their encryption password (or, even, a password vault password) when using the service or at system boot or user logon, but there seems to be no way to 'opt out' of this convenience.

I assume the engineers at iDrive used ROT-2 as a joke instead of putting the encryption password in clear text. I'm not a humorless guy, but there's a few areas that I don't like joking about -- and security is one of them. Unfortunately, this unfunny joke decreases security because it slightly increases the chances that some users won't realize that their encryption password is sitting in (almost) cleartext on their local disk and they won't protect it well (most users, of course, would have no idea this file even exists).

Since iDrive seems to think that security is something to be "funny" and "cute" about, I question their general judgement on the topic. (Of course, it's possible that they are incompetent and don't do security reviews -- I suppose that's worse).