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

21–28 of 28 posts

Re: Bring your own key was a lie

#21

Post by politelemon »

assusdan wrote: post #18
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?

Post a technical article highlighting problems with X, and as part of it, mention your product which happens to not have those problems or deals with it a certain way.

So a blog post with the author advertising a product.

Re: Bring your own key was a lie

#22

Post by m1ghtym0 »

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…

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

Re: Bring your own key was a lie

#23

Post by giancarlostoro »

assusdan wrote: post #18
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?

I assume its like the term slashdotted which is from slashdot, in this case the headline baits you into some companies advertisement article intended to make you buy into their product.

I wasnt a heavy Slashdot user I read it nearly daily until I found HN.

Re: Bring your own key was a lie

#25

Post by q-big »

assusdan wrote: post #18
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?

> What is the Slashvertisement?

I assume that it is a portmanteu of "Slashdot" (https://slashdot.org/) and "advertisement".

Re: Bring your own key was a lie

#26

Post by candiddevmike »

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.

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

Re: Bring your own key was a lie

#27

Post by Rygian »

assusdan wrote: post #18
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?

A targeted form of unsolicited advertising (ie. spam).

Re: Bring your own key was a lie

#28

Post by derpsteb »

candiddevmike wrote: post #26
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.

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

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.

Post reply on HN