Bring your own key (BYOK) was a lie!

What is Bring Your Own Key (BYOK)?

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?

So, what is the problem?

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.

So what? I trust my cloud environment and my CSP!

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?

What is the solution?

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:

1. Runtime encryption: The processor keeps all the CCE's data encrypted in the main memory. Any system component or hardware attacker attempting to read a CCE's data directly from memory will only ever see encrypted data. Likewise, encryption prevents the modification of a CCE's data through direct memory access.
   
2. Isolation: the processor blocks software-based access to the CCE. Software like the operating system or other apps can only communicate with the CCE over specific interfaces. You can think of this as an API that the CCE exposes to the outside world.
   
3. Remote attestation: on demand, the processor can issue a cryptographic certificate that proves the integrity and authenticity of a CCE and the data it produced.
   

Regarding BYOK, CCEs allow you to fill in the gaps and guarantee end-2-end protection of your keys:

1. Runtime encryption ensures that keys cannot be leaked from the main memory
   
2. Isolation ensures no other component or actor in the cloud environment can access the keys via an escalation of privilege or cross-tenant access
   
3. Remote attestation allows for restricting the access and release of keys to CCE environments. Hardware-based attestation statements represent an unforgeable form of identity that uniquely identify CCEs based on their unique fingerprint. The KMS can verify the attestation statement and thereby, that a request genuinely comes from a specific CCE.
   

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

Conclusion

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

If you want to learn more about confidential computing, follow Edgeless Systems on LinkedIn and Twitter, and check our OSS projects on GitHub.

Author: Moritz Eckert