TL;DR:
Many cloud-based SaaS companies have adopted a form of BYOK (Bring Your Own Key) in an attempt to tackle the intractable problems of customer privacy and data security. But every BYOK implementation is a compromise between the enterprise customer’s security requirements and the SaaS team’s ability to maintain app performance and functionality.
I co-founded Antimatter to build a security solution that isn’t a zero-sum game: our product’s implementation process is fast and simple, there’s no impact to SaaS code, SaaS app performance remains strong, and the security guarantees we offer are best-in-class, transparent, and provable. We make it easy for SaaS companies to become security leaders by giving their customers powerful control over their own data.
BYOK probably isn’t what you think it is
BYOK broadly refers to the security practice of allowing customers of cloud-based SaaS apps to generate and retain control of their own encryption keys. Marketing tends to represent BYOK as a simple and standardized data security solution, keeping customer data safe from security breaches, inappropriate access by SaaS employees, warrants from law enforcement agencies, and other threats.
But the reality is far more complicated. BYOK isn’t a cure-all—it isn’t even well-defined. As security executive Paul Rich wrote last year: “BYOK is a useless acronym/term because there is no standard technical design, architecture, principles, or outcome.”
BYOK is better thought of as a loose conceptual framework than a standardized, boolean feature. Checking “BYOK” off a list of desired security features isn’t particularly meaningful because BYOK implementations vary wildly in efficacy. With a strong and thoughtful implementation, BYOK can be a meaningful security tool. With a weak implementation, it can do virtually nothing—or even create a false sense of security.
Without Antimatter, regardless of implementation quality, the vendor and customer are stuck in an arena of zero-sum tradeoffs.
Common BYOK implementations and their shortcomings
Customers are justified in their demands for secure data, but the complex engineering work involved can add months or years to a product roadmap. Today, adding BYOK represents a negotiation between the customer’s security needs and the SaaS team’s ability to deliver on security while maintaining app performance and functionality under time and resource constraints.
Let’s consider some common implementations and their strengths and limitations.
1: Powerful security, impaired functionality
First, imagine a version of BYOK in which the only entity who can use the encryption key is the customer. In this scenario, in order to process customer data, the SaaS application has to transfer data to the customer to decrypt and return in plaintext. This setup is extremely secure: no one at the SaaS app ever sees the customer-generated key, so the customer can be confident in their ability to revoke access to data. But this implementation massively downgrades functionality because of the vast data transfers required—in practice, it’s only viable for apps that primarily store or deliver data, or would only be doing client-side processing anyway (ex: file storage or messaging apps).
2. Strong performance, weak security guarantees
On the other end of the spectrum, consider an implementation in which the SaaS application fetches the key from the customer’s key server whenever it needs to decrypt customer data, then uses and caches the key locally. In this scenario, performance remains strong. But it also offers minimal security benefits: the SaaS application and its team have direct access to the customer’s key. Revocation wouldn’t achieve much.
3. Intermediate keys, intermediate security
An ideal solution would combine the best aspects of the two implementations above—great security guarantees and minimally impacted performance—while mitigating their flaws. Many popular SaaS applications are attempting to find the middle ground by using a system of intermediate keys.
In this kind of implementation, the SaaS app creates an intermediate key, stored within the SaaS app’s infrastructure, that can be used to decrypt the customer’s data. This intermediate key is encrypted by a root key generated and stored by the customer. The SaaS application is programmed to forget the intermediate key on a regular basis, usually every few minutes. Every time this happens, the SaaS company must ask the customer to re-decrypt the intermediate key in order to continue accessing customer data.
The performance implication is minimal, but this implementation has serious security vulnerabilities. The SaaS app could stop “forgetting” the intermediate key without the customer’s knowledge—meaning that even if the customer revokes access to the root key, SaaS employees (or attackers) might have continued access to the intermediate key. This is a solution used by some of the most popular SaaS apps on the market—and it’s still fundamentally exploitable.
Solving for data security comes at a steep cost to SaaS teams
We’ve looked at three BYOK implementations, none of which offer a satisfying solution for both the vendor and customer. This isn’t because of a lack of effort by SaaS companies. It’s because they're put in an impossible position.
Customers often want security guarantees that are either inherently contradictory or infeasible given time and skill constraints—and implementing any version of BYOK is a massively time-consuming engineering problem. We’ve heard from leading, well-resourced SaaS teams that the roadmap for building and testing an intermediate key-style implementation is around two years.
On top of that, it’s not in most SaaS vendors’ best interests to focus on developing vast in-house security teams (nor is it always possible)—their focus should remain on building products customers love.
On the buyer side, it’s nearly impossible to gauge precisely how secure data is within a SaaS app. Checking off a feature called “BYOK” without delving into the details doesn’t tell you much—and getting into the security details of every SaaS vendor isn’t a realistic expectation. Instead, enterprise buyers have to assess their own tradeoffs, gauging whether a SaaS app’s strengths outweigh its security risks.
Antimatter: Security, performance, and ease, with no zero-sum tradeoffs
To summarize: until now, the best option for even the most well-resourced SaaS team was to spend years on an in-house BYOK implementation that contained troubling security vulnerabilities and was frustratingly opaque to its customers. But it doesn’t have to be this way.
It should be easy for SaaS companies to provide customers with best-in-class security guarantees, and just as easy for enterprise customers to retain control of their data and trust the SaaS apps they rely on. We spent six years researching and developing a solution to make this possible.
Antimatter takes the intermediate key-style implementation, solves its security weaknesses while enhancing its strengths, provides a new level of transparency for the customer, and makes implementation fast and easy.
In our implementation, root keys are generated and stored by the customer in their choice of cloud or local storage. The root key encrypts a set of intermediate keys that are used by the SaaS application. Thanks to a combination of advanced cryptography and confidential compute enclaves (recently available on all major clouds) we ensure that these keys can’t be copied and automatically expire every few minutes. This means that if the customer revokes their root key, it’s guaranteed that all customer data will be inaccessible in minutes—no matter where data is held. Moreover, a hacker or malicious user can’t access the keys because they are never exposed.
With Antimatter, the SaaS app doesn’t need to be trusted to forget the intermediate key. Instead, code running in a secure enclave is responsible for forgetting. The pattern is similar, but the details change everything: Because the intermediate key is stored in an enclave, the SaaS vendor never sees the intermediate key and neither does Antimatter. It’s not just about moving the trust from SaaS companies to a third party—less trust is needed.
We’re an infrastructure solution that slides under existing SaaS applications, meaning we give SaaS companies the ability to offer better than state-of-the-art security with little to no changes to code. Our product passes six years of research and development along to SaaS vendors, massively reducing the time and skill required for vendors to become security leaders. Instead of a two-year roadmap, Antimatter can make the entire implementation process as short as a couple of weeks.
Antimatter allows vendors and customers to exit the zero-sum arena. While there are always some intrinsic tradeoffs to be made between security and performance, our product takes the SaaS vendor’s resource constraints out of the equation. Instead of haggling with the SaaS vendor over the timeline and cost, Antimatter allows the customer to work with the vendor to choose which security features matter to them.
If you’re a SaaS engineer struggling with customers’ security demands, or an enterprise buyer concerned with the safety of your data in the apps you rely on, I’d love to show you how we’re solving this problem. Follow Antimatter on LinkedIn or send me a message to learn more.
