Register now for OC3, the premier event for confidential computing, on March 13 - free and online
Bring your own key (BYOK) is a popular term used by cloud service providers (CSPs) when it comes to cloud security features.
It allows customers to stay in control of their cryptographic keys and split the trust between the cloud provider and the key owners.
Instead of the CSP generating and controlling the keys, the customers generate and manage their own keys. Usually, they securely store them in a key management system (KMS), either in the cloud or in their physically controlled on-prem environment. Often these systems are backed by a secure hardware module (HSM). Finally, the customers configure which cloud services and contexts can access the keys to use them for cryptographic operations.
Sounds great so far, doesn't it?
The problem are the cryptographic operations. They are still controlled and performed by the CSP and the managed cloud services. That means, whenever keys are used to either encrypt data or as a form of authentication, they need to stay accessible to that service. Consequently, whoever has access to the service has direct access to the keys. Additionally, while the keys are in use, they are residing in plaintext in the main memory of that service. Hence, also everyone that can acquire a way into the memory of that service either virtually or physically can leak the keys from there.
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 tenants? And why go through all that trouble of BYOK and separation of concerns?
Fortunately, confidential computing (CC) technology can help with this. The basic idea of CC is to have the processor of a system create a highly secure environment for data processing. Such execution environments are often referred to as trusted execution environments (TEEs) in the literature. In the following, we use the term "confidential computing environment" (CCE) to refer to TEEs with specific capabilities.
CCEs have the following three defining properties:
Regarding BYOK, CCEs allow you to fill in the gaps and guarantee end-2-end protection of your keys:
A great example of such an end-2-end secure environment is our open-source Confidential Kubernetes distribution, Constellation. It wraps your K8s cluster into a single CCE that is shielded from the underlying cloud infrastructure. Everything inside is always encrypted, including at runtime in memory.
Internally, the keys, secrets, and certificates managed by Kubernetes and Constellation, respectively, are protected by the properties of the CCE. In one of its upcoming features, Constellation will allow attaching common KMSs such as HashiCorp Vault or other KMIP-compatible KMS solutions. That will enable further separation of concerns so that you can keep root keys in a separate context if you want to do so.
In another example, Google released a case study of a secure key release from a KMS to a Confidential VM based on attestation statements. The concept is called "Ubiquitous data encryption".
BYOK 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".