Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bring your own key was a lie

blog.edgeless.systems

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Bring your own key was a lie

#11

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

Re: Bring your own key was a lie

#12

Post by eschneider »

raesene9 wrote: post #11

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 back…

This. A thousand times this.

Re: Bring your own key was a lie

#13

Post by mjg59 »

raesene9 wrote: post #11

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 back…

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.

Re: Bring your own key was a lie

#14

Post by raesene9 »

mjg59 wrote: post #13
raesene9 wrote: post #11

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 back…

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 fro…

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?

Re: Bring your own key was a lie

#15

Post by mjg59 »

raesene9 wrote: post #14
mjg59 wrote: post #13

Earlier quoted context omitted.

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 fro…

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?

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.

Re: Bring your own key was a lie

#16

Post by Nextgrid »

actionfromafar wrote: post #8
Rygian wrote: post #3

What's the HN equivalent of Slashvertisement? > Fair enough, but then why did you split the trust in the first place using BYOK? Let’s think about the threat model here. Anyone leveraging privilege in the cloud or exploiting vulnerabilities in the isolation of cloud tenants, will inevitably gain access to the cryptographic services and eventually to your keys. So, do you trust the entire public cloud and its tenant?…

Slashvertisements, I forgot about those. I think they are considered virtuous now, especially on this forum.

Corporations expending energy refuting each other's bullshit/misleading claims means there's less energy available to con prospective customers, so I see that as a win.

Re: Bring your own key was a lie

#17

Post by raesene9 »

mjg59 wrote: post #15
raesene9 wrote: post #14

Earlier quoted context omitted.

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?

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.

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)

Re: Bring your own key was a lie

#18

Post by assusdan »

Rygian wrote: post #3

What's the HN equivalent of Slashvertisement? > Fair enough, but then why did you split the trust in the first place using BYOK? Let’s think about the threat model here. Anyone leveraging privilege in the cloud or exploiting vulnerabilities in the isolation of cloud tenants, will inevitably gain access to the cryptographic services and eventually to your keys. So, do you trust the entire public cloud and its tenant?…

What is the Slashvertisement?

Re: Bring your own key was a lie

#19

Post by m1ghtym0 »

raesene9 wrote: post #17
mjg59 wrote: post #15

Earlier quoted context omitted.

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.

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)

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.

Re: Bring your own key was a lie

#20

Post by m1ghtym0 »

Rygian wrote: post #3

What's the HN equivalent of Slashvertisement? > Fair enough, but then why did you split the trust in the first place using BYOK? Let’s think about the threat model here. Anyone leveraging privilege in the cloud or exploiting vulnerabilities in the isolation of cloud tenants, will inevitably gain access to the cryptographic services and eventually to your keys. So, do you trust the entire public cloud and its tenant?…

You are correct, KMS implement important aspects of key management. The conclusion of the article is not replacing KMS with Confidential Computing. Instead, the idea is to combine them to achieve the ultimate goal of protecting sensitive data. CC does not solve the who manages the KEK problem, it solves the using the DEK securely, accessing the KEK securely, and eventually, effectively protecting the processed data question.
Post reply on HN