Bring your own key was a lie
blog.edgeless.systems
Bring your own key was a lie
1–10 of 28 posts
Re: Bring your own key was a lie
#2BYOK was a lie because it was only protecting keys at rest. When the environment in use becomes accessible to so many actors, customers lose control of their keys and identities once they are accessible to that hostile environment. “Bring your own key — share it with everyone.”
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”.
Re: Bring your own key was a lie
#3What'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? 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.
Re: Bring your own key was a lie
#4What'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?…
And also it is another line of defense, which can only improve security, not worsen it.
Re: Bring your own key was a lie
#5They say that part of the solution is that their system provides runtime encryption, so third parties, whatever and whoever they might be, can't see the data. But where's physically the key used to encrypt? If it still has to be on the cloud, which I think would be the case, then the problem isn't solved.
Re: Bring your own key was a lie
#6Isn't the normal practice here to provide a key use transparency log?
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.
Re: Bring your own key was a lie
#7Author promotes deep hardware solutions, like Trusted Computing. I thought we've already passed that? TPM, Intel ME, AMD PSP...? If you are in a position to distrust your provider DON'T USE CLOUD. Build your infrastructure, use colocation, bring your own server. If you fear you may get poisoned, don't eat in public restaurants. And BYOK is just a minimal norm of basic security.
Re: Bring your own key was a lie
#8What'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.
Re: Bring your own key was a lie
#9What'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?…
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
#10There's also a lot of exciting developments coming out of academia, see structured encryption and its applications for encrypted search for example https://esl.cs.brown.edu/pubs/