Hacker News new | ask | show | jobs
by theamk 2143 days ago
A somewhat more technical explanation: https://cloud.google.com/blog/products/identity-security/int...

This using a feature in AMD processors which protects one VM from another, by encrypting memory with VM-specific key. I think the idea is that even if hypervisor is compromised, there is no way to access running data of the machine.

From the practical standpoint, you still have to trust Google's infrastructure. Here is a key quote:

> all GCP workloads you run in VMs today can run as a Confidential VM. One checkbox—it’s that simple.

The video confirms it -- you click on the checkbox while creating VM, it starts as usual, you ssh into it as usual, the only sign that you are protected is a line in dmesg output.

So there is nothing "game changing" about this -- your threat model is mostly the same, but your attack surface is slightly reduced. The biggest threats (misconfigurations and network attacks on vulnerable software) are still there, and are not changed in any way at all. And you have to keep absolutely trusting your cloud provider, too.

It looks like the main point of this whole project is to satisfy government regulators, big bosses, security consultants and to check boxes on security evaluation worksheets.

3 comments

> So there is nothing "game changing" about this -- your threat model is mostly the same, but your attack surface is slightly reduced.

If done correctly (using attestation, as mentioned here already), this can reduce the attack surface significantly.

Right now, you need to both trust your cloud provider to not introduce backdoors for themselves or some government _and_ to keep doing so until the end of your business relationship with them.

Ideally, with trusted/confidential computing, you only need to trust the vendor to initially do as they say and not outright lie to you (e.g. by making the checkbox a no-op). In many ways, this would protect a cloud provider from themselves.

Of course, with the current implementation non-successes like Intel's SGX, one could argue that this is merely kicking the can of trust down the road to the hardware vendor, but as far as I understand it, this is not an inherent flaw of the idea of trusted computing but rather a specific implementation.

> you only need to trust the vendor to initially do as they say and not outright lie to you (e.g. by making the checkbox a no-op)

The cloud provider can't lie to you (assuming you know how to check, anyway). There are instructions available to your code to have the CPU perform cryptographic attestation regarding its current state. These instructions can't be emulated because they involve producing a cryptographic signature using a private key embedded in the hardware (which chains back to a root of trust for the hardware vendor).

Basically, you can ask the CPU running your code "are you in confidential mode?" and it will respond in the affirmative with a cryptographic verification that chains back to the hardware vendor. You do this before loading the encryption keys for your super sekrit data store over the network.

Ah, I wasn't aware that AMDs implementation already supported attestation in addition to just memory encryption.
I feel the need to disclaim that I have no actual experience using SEV. Also it looks like the attestation protocol may have been broken by attacking the PSP firmware? I have no idea what the current state of affairs is, particularly regarding the claimed firmware downgrade vulnerability.

https://arxiv.org/abs/1908.11680

https://berlin-crypto.github.io/event/amdsev.html

If one is using attestation and independent verification, then I agree.

But this is not what the article says. It specifically mentions "Confidential VMs." and says "giving customers a simple, easy-to-use option". Looking up the actual product, they strongly recommend using google-provided images.

So this particular announcement does not change much. You still need the trust the cloud provider to not introduce backdoors.

And I bet that all the pre-made images will have "https://packages.cloud.google.com/apt" in the sources.list -- so if Google wants to snoop on you, all they need is to ship a backdoored package. And if this does not work, they may send you a regular email saying "the physical host is failing, please reboot to migrate" -- and when you reboot, it will be not in the protected mode.

So yes, the general idea of "Confidential Computing" is sound, but reading the post carefully shows the current system is just for making non-technical people excited.

It’s “game changing” to attract clicks.
I wonder how this might affect startups that are trying to sell security in that specific area - e.g. Hysolate [0] (no affiliation).

[0]: https://www.hysolate.com/

No you don't. Look up remote attestation.