[raesene9]

If you don't trust your CSP (the threat model discussed in the article) then I'm not sure that confidential computing will save you as you're relying on the CSP to implement and provide that service faithfully.

The CSP installs chooses and installs and manages the hardware, you can likely only interface with that hardware through CSP provided software, if the CSP is malicious it would seem likely that they could backdoor this stack to allow them access to encryption keys...

If you don't trust the CSPs surely the right answer is on-prem hardware.

[m1ghtym0]

I hear that argument a lot. The key aspect here is remote attestation. Often enough CC is only seen from a memory encryption angle. It's maybe not straight forward, however remote attestation and of course the verifiability of such attestation claims are what makes CC unique.

The remote attestation capabilities of CC hardware allow to establish a secure channel from the hardware to the user, taking the CSP fully out of the equation. That applies even though the CSP implements the IaaS in between.

There is documentation that explains this in more detail if that's of interest to anyone following these discussions: * https://confidentialcomputing.io/wp-content/uploads/sites/85... * https://content.edgeless.systems/hubfs/Confidential%20Comput...

[mjg59]

AMD's SEV supports providing an attestation to the launch state of the VM, including information about whether the hypervisor has any visibility into the contents of the VM. If this works as described it does genuinely let you decouple trust from the CSP, instead placing it purely in the CPU vendor.

But I agree with the general thrust of the post - simply providing your own keys isn't sufficient to remove the CSP from the set of people you need to trust. There are reasons to do this (eg, you want the ability to extract your encrypted data and make use of it, or you want to have a chain of trust back to keys that you control), but the moment you upload a private key anywhere it's obviously no longer private in the same sense it was before you did that.

[raesene9]

So with AMDs SEV (and I'm guessing similar systems) what's the interface by which a customer will get that information?

What I'm interested in is, is there not a CSP controlled API between the literal hardware and the CSP customer, that might be subject to attack?

[mjg59]

The OS running inside the VM hits an external API (one you control, not the CSP), that returns a challenge, the CPU signs a response that includes that challenge and its state, you verify that the signature chains back to AMD. The CSP isn't directly involved in the exchange.

[raesene9]

So the CSP has physical access to the CPU (and the rest of the hardware), is it possible to attest that it hasn't been tampered with after it leaves the CPU manufacturer's control?

(I'm not saying that's it's in anyway easy to modify, but if our threat model here is a malicious company with the resources of AWS/Azure/GCP then it seems sensible to consider even difficult attacks)

[m1ghtym0]

The thing you're looking for is called remote attestation. That means there is a direct channel from the hardware to the user that attests the confidentiality and integrity of the VM. Such attestation statement is signed by a key burned into the CPU at production time. The remaining attack vector is leaking that key from the hardware itself. There is academic research on this topic. In essence, while technically possible, it is considered not practical, especially not at scale.

[candiddevmike]

Do you know of anyone offering this at the moment? I wonder if you could use that for Vault authentication somehow.

[derpsteb]

Constellation (a Kubernetes distro) [1] on Azure would give you this attestation feature. You could then run sth like HashiCorp's Vault in that cluster. You will know that all nodes of that cluster are in the state that you expect them to be through the attestation statement.

[1] https://github.com/edgelesssys/constellation

Disclaimer: I work for Edgeless Systems.

[eschneider]

This. A thousand times this.