> 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? And why go through all that trouble of BYOK and separation of concerns?
Because as owner of the CMK, I can rotate it as often as I want and limit the exposure if one instance of the CMK has been exposed by the CSP.
And I can decide my own policy on having CMK shared across CSP and not be tied to just one CSP.
Confidential Computing is not a replacement for the discussion on who manages the key-encryption-key.
However, suppose I'm a famous carmaker [1]. What are the chances that I screw up and publish my CMK in a public repo, compared to the chances of my CSP screwing up and publishing my tenant's PMK on a public repo?
I wasnt a heavy Slashdot user I read it nearly daily until I found HN.
I assume that it is a portmanteu of "Slashdot" (https://slashdot.org/) and "advertisement".
So a blog post with the author advertising a product.
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.
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...
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.
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?
HSMs can produce a log every time the key is used, and as long as you trust the hardware to be doing the right thing (if you don't you've got bigger problems) the log should be verifiable so you know if there's a missing entry.
Cloud provider has the key, but gives you verifiable logs of it being used so you can catch them if they're doing the wrong thing.
Confidential Computing fundamentally changes this by providing protection for keys in use and enabling trusted and verifiable runtime environments.
Solutions such as Constellation solve the shortcomings of BYOK using Confidential Computing so you can finally “Bring your own key — keep it yours”.
