[lxgr]

> 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.

[Reelin]

> 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.

[lxgr]

Ah, I wasn't aware that AMDs implementation already supported attestation in addition to just memory encryption.

[Reelin]

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

[theamk]

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.

[m3kw9]

It’s “game changing” to attract clicks.