Every day a new data breach or cyber attack impacts even the most proactive of organizations. Protecting sensitive information stored in the cloud is more critical than ever, and while some software providers offer encryption solutions, most of them do not deliver the level of security and control that businesses should need.

This is where BYOK (Bring Your Own Key) and HYOK (Hold Your Own Key) encryption come in. In this post, we'll explore the world of BYOK and HYOK encryption, examining what they are, their benefits, common implementations, and what to look for when evaluating a company's encryption setup. By the end, our goal is for you to leave able to make informed decisions about how secure a software providers encryption really is. Let's dive in and take control of your security!

So, what is BYOK and HYOK Encryption?

Encryption is the act of scrambling data in a way that allows a key to unscramble it later. This encryption is performed using an algorithm that works like a lock. Some locks require one key, some require multiple, but all of them are functionally similar - they protect you by making it harder or impossible for someone to break in and read your data directly.

BYOK stands for Bring Your Own Key. Think of the last time you bought a padlock. It probably came with a key, made by the lock's manufacturer. You don't know the history of that key, and it could have been duplicated or tampered with. On the other hand, if you bought a programmable padlock, you know for certain that the manufacturer didn't have the chance to duplicate your key because you created it. That's what BYOK is - you are providing the key yourself, which gives you confidence (in theory) that nobody else has the ability to decrypt (unlock) your data.

HYOK stands for Hold Your Own Key. Imagine that, like with BYOK, you buy a programmable padlock where only you know the key. But then, you also buy a bunch of secondary padlocks that come with normal keys. You use those secondary padlocks to encrypt your data, but then you take the extra step of locking up the keys to the secondary padlocks, using your programmable padlock! This offers the highest level of security, because nobody can ever access your data without first asking you to unlock the programmable pad lock. The keen-eyed among you may have spotted a problem here, so let's read on!

B Stands for Broken

BYOKs biggest flaw lies in how its many possible implementations leave uncertainty around the true security measures in place. It's hard to tell when someone is using BYOK as a buzzword, or really knows what they're talking about. Before we cover all these possible BYOK implementations, we ought to first understand what goals are in mind when building such a system. It's helpful to visualize these goals in a table, and we will create a scorecard with this table for comparing BYOK and HYOK implementations.

Note: SP = Service Provider / Software Provider

With these laid out, we can now fill out a score sheet for common implementations of BYOK Encryption and see what we learn!

Bring Your Own String

By far the most common approach to "BYOK" is to have customers input a string (any series of letters or numbers) in a settings menu, and encrypt data at a field-level using this string as the key. Before we dive in though, what exactly is field-level encryption?

Databases tend to be encrypted one way by default, which we call "at rest". This means that the SP has used some encryption key under their control (and possibly even their cloud provider's control) to encrypt the underlying hard drive that runs the database. That way, if the hardware is compromised, your database is safe, but anyone at the SP who has access to the database can still read and use it normally and see all of the data inside. A second and less common approach is to encrypt the contents of the database as well. Let's say you have a field in the database called "Name" which usually stores the name of users of the software. When we use field-level encryption, what we're really saying is that fields such as Name (or any other fields we deem as requiring this) are scrambled up and encrypted. As a result, if someone at the SP peered into the same database as before, it would be entirely useless to them!

Unfortunately, using Bring Your Own String for that encryption key, even at a field level, has many issues:

1. In order to encrypt data with the key, the SP must have access to it in plaintext.
2. Revocation of the key is impossible, or at least impossible to verify.
3. Key rotation is not possible for you to directly control.
4. You cannot audit usage of your key.
5. It isn't really "your" key at all!
6. The key could be stored in an insecure way, and there's no way to rectify that.

So, with the goals above, why would anyone ever implement BYOK this way? Well, the reality is that SP's are incentivized to add BYOK so that they can mark their software as secure or enterprise-ready, even if they don't serve real enterprises or care about security. Buzzwords like BYOK Encryption go further than you might think, and create these kinds of incentives to fake it.

It's worth noting that even this approach still accomplishes some of the goals we outlined, and can be a reasonable first step towards improving the security of your software! It makes it harder for employees to view the data, because it's encrypted at a field-level. With this approach, companies can store those keys in a separate database that fewer people in the company have access to, ensuring that the separation of concerns between the security team and engineering team decreases risk. Mostly though, it makes it trivial to ensure the product doesn't lose any functionality.

Bring Your Own HSM Key

Another common approach that improves on Bring Your Own String dramatically is when the Service Provider (SP) asks for access to a key in your own Hardware Security Module (HSM).

An HSM is a physical device that safeguards and manages digital keys, providing an additional layer of security. These HSMs are offered by all major cloud providers and allow applications to remotely encrypt/decrypt data without accessing the key in plaintext. Since cloud providers tend to lock these HSMs down by default, the SP's natural course of action is to assign only the software itself access, not employees. This is a huge advantage over storing the key in a database that engineers or other employees control, as it dramatically limits who has the ability to decrypt data.

In the event that an attacker gains full access to the database, they would not automatically obtain the keys used to encrypt individual fields. Instead, the attacker would need to make an unusually large number of requests to the HSM to decrypt customer data. This large number of requests can be quickly detected and shut down (in some cases, automatically), minimizing data loss and making it clear which customers were impacted and what data was leaked.

This approach isn't without its problems though, and using an HSM key for every operation can be incredibly expensive for the customer, while dramatically lowering the performance of the SP's product. Every single data read operation will incur a penalty on the order of 10-50ms, or even higher depending on where the HSM is located relative to the SP's database.

Hold Your Own Key

HYOK works by using many keys instead of one: data encryption keys (DEKs), and customer main keys (CMKs). CMKs may also be referred to as Customer Master Key, or Key Encryption Key. The idea is that you create a new DEK which is used to encrypt new data, but instead of storing those keys with the customer directly, the SP asks the customer to use they CMK to encrypt or "wrap" the DEKs with the customer-controlled key before they are saved.

Software providers may also choose to leverage a DEK cache to keep commonly-accessed DEKs in plaintext in memory (typically within a Trusted Execution Environment where the memory is fully encrypted, isolated, and code verified to be legitimate). That lets the SP explicitly trade off security for performance by adjusting how long DEKs stay in the cache, while also saving the customer money through fewer CMK encrypt/decrypt operations.

This has a few really great side effects:

1. The customer can now revoke data access in the SPs product at a granular level, since any number of DEKs may be used.
2. The SP can no longer decrypt any of the data without asking the customer first.
3. The performance impact can be adjusted, because the DEKs can be securely cached.

Trelent offers HYOK encryption to our single-tenant customers, which allows administrators to revoke keys for individual chats or users, while also having complete control over the length of time they are cached for. That let's them call the shots on what level of security they need, and what cost they are willing to pay for it. If you want to learn more about how we built our HYOK service, stay tuned or reach out!

Recap

BYOK and HYOK encryption are both extremely powerful tools for ensuring the security and privacy of sensitive data when done correctly. By allowing customers to maintain control over their encryption keys, these approaches can provide an extra layer of protection against data breaches of all sorts.

When evaluating a service provider's encryption implementation, it's crucial to see past the buzzwords and carefully consider how well it aligns with your security goals. A genuine BYOK setup should prevent service provider employees from viewing plaintext customer data, allow customers to revoke access to their data, provide auditing capabilities for key usage, and maintain product functionality. We hope that you can leave here knowing how to make an informed decision about which approach best suits your organization.

Remember, not all encryption implementations are created equal, so it pays to do your research and choose a provider that truly prioritizes your security! By taking control of your encryption keys and choosing the right encryption setup for your needs, you can ensure that your sensitive data remains secure, no matter where it resides. So get at it! Go review your providers, and take control of your data. Data breaches won't be waiting.

‍