[Dyaz17]

What is the attack Vector that this solution prevent ?

Am I missing something obvious ?

Will it prevent Google from being able to have a Root access to the VM?

From my understanding it does not seem to protect from Google. If they are still able to have a Root Access to the VM it does not matter if the memory is encrypted or not.

The only thing that I see, is in case of a spectre/meltdown vulnerabilty where the isolation of the RAM fails...

[nellydpa]

GCP does not have root access to the customers VMs. Confidential VMs with AMD SEV create an additional cryptographic isolation layer (in addition to virtualization one) between tenants and Google infra, mitigate 0days guest escapes, make observability attacks less possible, protect against some set of DMA attacks, and mitigate memory physical access attacks. To add to this not all spectre variants are applicable to AMD SEV, e.g. L1TF or foreshadow is not.

[derefr]

> GCP does not have root access to the customers VMs

I mean, they have physical access to the hypervisor host machines, where they could do anything they like to them, e.g. tap the JTAG pins of the CPU.

Insofar as you assume that the attack here is “the NSA compels Google to gather evidence against you”, the lack of just being able to log into the VM doesn’t really change much.

[asah]

This protects against remote rogue employees and intruders.

As for physical attacks, Google is ultra paranoid about physical access to DCs, and I think we can quickly agree that rogue employees and outsiders would have little chance of successful attack given the outrageous (and secret) methods that Google employs. Remember, this is one of the most-attacked organizations in the world, they've had decades (plural) to enact defenses and test them, and a successful attack would cost them over $10 billion - there's a virtually unlimited budget for physical defense. Circa 2020, I'd put Google's physical intrusion defenses up against most military installations.

[nitrogen]

Is there something special that happens when a legit remote cloud user logs in that doesn't happen when a rogue remote Google admin logs in? Something that prevents a modified web client from stealing the creds during a user's web console session?

[theevilsharpie]

SEV protects against physical attacks. A rogue admin logging in through a management console would have to go through whatever controls and auditing the console's access control functionality provides.

[frandroid]

> decades (plural)

Namely, two at most.

[Kye]

Is there a point of diminishing returns on experience for security? Two might be enough.

[remus]

> Insofar as you assume that the attack here is “the NSA compels Google to gather evidence against you”, the lack of just being able to log into the VM doesn’t really change much.

For most people (and especially businesses) this is a totally unrealistic security aim. If what you're worried about is the government using it's legal ability to compel people and businesses to provide evidence then there's ~no product or service from that country that you could realistically use.

[derefr]

I mean, yes, there's no service where the security/privacy is contractual, that is safe from the state overriding the contract.

But the promise of things like homeomorphic encryption, is that you can do a computation on a truly untrusted substrate, i.e. you can trust computations performed by an untrusted adversary, and also know that they didn't learn anything about those computations. It's a technical solution to security/privacy, not a contractual one.

The ideal that everyone's hoping for, is that there's a way to get that same kind of technical guarantee from cloud compute providers, without needing a layer of maths that makes Monte Carlo quantum simulation look fast.

[Spooky23]

All commercial activities are at the core protected by contractural protections and good faith. Cloud is not as different as you may think.

Any other expectation of protection from the state are a limited based on probability, seriousness of the matter, and your potential culpability. Your employees, service providers and others can be required to provide information without informing you. In extreme cases, agents will pose as utility, security or building management.

[derefr]

> Your employees, service providers and others can be required to provide information without informing you. In extreme cases, agents will pose as utility, security or building management.

...and homeomorphic encryption would stop all of those attacks. Presuming it's a homeomorphically-encrypted substrate for an autonomous agent, making its own "evaluations" of the data it can perceive from the outside world (ala a smart contract with access to an oracle) rather than simply trusting data from the insecure domain that happens to be signed with the right key.

This is also, y'know, the security architecture that allows nuclear submarines to avoid being subverted by an enemy nation that has temporarily gained control of the White House. The sub's commander needs to know not only that they've received the order, but also that the world really looks like one where such an order would be legitimately given. The isolated secure agent, speaking to an insecure principal, needs not only proof of their credentials, but also needs to independently verify their claims about the state of the world. (And, if they can do that, the system is often architected such that the principal won't even communicate in the moment, but instead has just left flowchart-like orders in advance, involving various dead-man's-switch timers and so forth.)

[lioeters]

I think that's the reality, that most/all consumer and enterprise services can provide only a "reasonable" and compromised level of security and privacy.

If a nation state and/or corporation that runs the infrastructure decides to exfiltrate your data, legally or not - the power dynamic is totally asymmetrical.

Individuals and smaller businesses can only do so much within their power to protect themselves, and at some point accept the compromise that "perfect" security and privacy are not possible.

(Although, I can't help but think that there may be technical solutions as yet unimagined, which could level the playing field.)

[superkuh]

Right. And now that this is a realistic and regular worry for normal businesses doing normal things the value proposition of the cloud is looking worse.

[redblacktree]

Are you suggesting that US companies should fear the US government may... steal their IP? I'm not being facetious, I just don't understand what the "realistic and regular worries" you cite are supposed to be.

[Dyaz17]

You can login to your instances from the admin console according to this : https://cloud.google.com/compute/docs/instances/connecting-t... So Google has a way to login to your instances...

[pas]

That's probably because there's an agent running on the default image. (Yes, duh, but if you disable that then they don't have "root".)

Of course the question is basically moot, because unless they have some sort of third party append-only log of actions they perform on the hypervisors, how would anyone ever know? Yes, AMD this and Intel that, but since Google is building their own computers, and since it's close to impossible to verify that you are in fact running in the secure enclave ... then you should assume you aren't.

Naturally, if you come up with a structure where you can incentivize Google to remain honest (eg. somehow make it evident to the world if they access or tamper with your stuff), then it becomes safe to delegate running VMs to them.

Again, of course, the same problem comes up if you try to do it in-house. How do you verify the security staff at your data center is honest? CCTV? Who watches the watchers?

[londons_explore]

You could imagine a scheme in which the company running the data centers ran hypervisor software made by intel on chips made by intel. You trust intel, and you trust their software and hardware does as advertised, but you don't need to trust the hosting company (Google).

The software would run your VM, and provide some kind of API which your VM could query to be sure it was running in a secure enclave, managed by Intel's signed software. The result of the API could be signed with Intel's key.

[saagarjha]

> You trust intel, and you trust their software and hardware does as advertised, but you don't need to trust the hosting company (Google).

I should note that this by itself is a fairly hilarious proposition.

[exikyut]

That's pretty much the idea of SGX.

But SGX has been broken multiple times, and because people love breaking SGX because it's such a "all the security eggs in one basket" design, it will virtually certainly be broken again in the future.

Furthermore, SGX is reasonably disliked, inasmuch as people consider its equivalence to the security and boundary implications of the Management Engine.

[blibble]

they could make the "create confidental VM" checkbox do absolutely nothing if they wanted!

[theevilsharpie]

This provides an additional layer of confidentiality against physical attacks, as well as attacks cross-VM or VM-to-hypervisor attacks.

This gets you close to the security of a physically dedicated server, without the expense of actually buying/leasing a full server.

[parliament32]

The host (hypervisor) can usually dump a guest's (VM's) memory, or tamper with it. This removes that attack vector, whether it's from a rogue Google sysadmin, or from another user who escalated to the hypervisor.

Google probably has root by default via an agent, but you can remove that. Google can probably run single user mode to change your root password, but you can change your bootloader/kernel to forbid that. Google can probably mount your disk images and just read them, but you can use full disk encryption to avoid that.

[emceepeepants]

Google does not have an agent on confidential vms; that defeats the purpose. The confidential VM runs a shielded OS which includes vTPM based attestation to protect against boot/rootkits so you know if someone has tampered with your boot chain up thru kernel.

[numbsafari]

Protection from specter/meltdown or other memory isolation vulnerabilities is pretty significant.