And also it is another line of defense, which can only improve security, not worsen it.
I agree, it's defense in depth.
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?
Re:Bring your own key was a lie
by actionfromafar on Thursday October 13, 2022 @06:00AM
(#33189149)
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.
What is the Slashvertisement?
Re:Bring your own key was a lie
by politelemon on Thursday October 13, 2022 @08:04AM
(#33189830)
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
by giancarlostoro on Thursday October 13, 2022 @08:05AM
(#33189837)
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.
> What is the Slashvertisement?
I assume that it is a portmanteu of "Slashdot" (https://slashdot.org/) and "advertisement".
A targeted form of unsolicited advertising (ie. spam).
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.
> 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.