Bring Your Own Key — A Placebo?

Let’s start with some basics: Your data can, and should, be encrypted at rest and in motion.

Data can be encrypted on the client side or on the server side. In the security realm, we have well-known best practices, which include defense in depth (i.e., not relying on a single security protective measure), and security by obscurity, which really isn’t security.

Here's what the cloud industry is doing, along with some underlying gaps. Most cloud service providers (CSPs) offer bring your own key (BYOK) in one way or another. Amazon Web Services, for instance, supports the following key management service (KMS) options:

KMS only: Customer-managed keys (CMKs) stored in the KMS.

KMS with customer key store and CMK: Again, managed by the customer and stored in the cloud hardware security module (HSM ).

KMS with third-party HSM: Customer-provided KMS with a direct connection to the KMS.

The keys are retained in the volatile KMS memory, meaning once the data encryption keys (DEKs) are decrypted, they are accessible within the CSP environment without requiring the key encrypting key (KEK) for each decryption or encryption.

In all implementation options listed, the data encryption keys are generated by the CSP's KMS and may or may not be exportable. The DEK is used to encrypt defined scopes of data (e.g., per bucket, day, file, etc.) and these DEKs are encrypted with the KEK.

BYOK Benefits and Risks

BYOK is meant to provide cloud customers more control over their hosted data. In reality, when BYOK is used, it actually works more like share your own key (SYOK), since once the key is provided to the CSP, customers have no control over the key use. The only benefit of SYOK, in my view, is ensuring the key randomness if you don't trust their random number generator. Otherwise, you may as well let the CSP generate the key.

BYOK is also offered by some CSPs in another model and connects to the customer’s hardware, which stores and controls the KEK. There are several outstanding issues with this model.

The DEKs may still be accessible to the service provider, purposely or otherwise, in addition to a malicious actor capable of succeeding in breaching the CSP's protective measures technically, or via social engineering, thus gaining access to the DEKs, whether in memory, cache, log files, or a malicious codebase. Retaining the KEK in memory is a double-edged sword, since you're effectively performing SYOK for better performance. But then why not just perform SYOK, in that case?

Another issue is that the service provider may not use the customer KEK to secure the DEK. And the CSP architecture, code, and various offerings may have security lapses that allow interception points. Even if DEKs are decrypted on the fly, which isn't usually supported or recommended, a communication issue could bring your business to a grinding halt, preventing existing data from being decrypted and new DEKs from being encrypted.

Trust is also a key element when working with a CSP. Trust should stem from certifications and third-party audits. Reference customers using the CSP for their sensitive data or production may also be an important factor in strengthening this trust. You also have to decide if you trust the CSP's authentication and authorization security. Even with federated security, that doesn't mean there aren't additional authentication and privilege escalation means.

In short: BYOK does not solve the problem nor reduce the risk!

What Else Can We Do?

Most CSPs offer customers self-service capabilities to revoke, rotate, and otherwise control the KEK. Enhanced security may be achieved by protecting the data prior to moving or granting the CSP access to it. But this is rarely beneficial and mostly recommended for securing PII/PHI or other strongly regulated data.

The most important factor is to consider all ingress and egress routes, including APIs and file transfers, as well as various privileged access needs. This also extends to authentication and authorization that uses role- or attribute-based access control to ensure non-repudiation, data sanitation, and industry best practices like zero trust.

The Bottom Line

My goal here is to raise awareness, not to reflect negatively on CSPs. But BYOK, for the most part, is snake oil. It’s often misunderstood as a panacea to working in the cloud while not requiring trust for the CSP.

SYOK is worthless. If you assume the CSP cannot generate sufficiently random keys for the KEK, why rely on it for the DEK? It's important to ensure there’s a well-designed security architecture in place that is constantly reassessed, tested, and monitored.

Results for “"byok"”

Bring Your Own Key — A Placebo?