In my last article we talked about the problems associated with modern data security and the principle that we use at Kunai to solve that problem: Trust No 1. You should never trust any one person or system with data of significant value. Instead you need at least three parties.
Ben Franklin’s quote is, “Three may keep a secret, if two are dead.” Probably good advice, but we don't want users to have to kill us to protect secrets, and let's face it: it's just not practical (or legal 😉). In the context of data security, however, the first part of that quote is useful. Three can keep a secret. It’s how our modern HTTPS protocol, which protects every private internet conversation, works.
With the HTTPS protocol we do what amounts to the following: Ask a site that we want to talk privately to, to prove who they are. They give us a certificate that says, cryptographically, who they are. We validate that certificate with a third party identity provider that we trust. After confirmation, we exchange cryptographic secrets with the validated site, then we proceed with a private conversation.
This system of having three separate parties is what we leverage for our security architectures at Kunai. For data protection we extend this with a simple rule suggested in the first article, which is: Don’t keep the keys with the encrypted data. Here’s what this looks like...
In this model, much like the HTTPS model, one cloud provides identity. That cloud is responsible for saying who all the faces are in the diagram, and to what team they belong. Since we don’t want to place blanket trust in our IT department, that includes all the faces in the diagram, not just the users. The individuals that allocate identities are never part of the other teams. Never. Period.
The second cloud stores and manages encryption materials. The individuals controlling that cloud manage the encryption materials and they are also never part of the other teams.
The third cloud stores the data. Again, individuals controlling that cloud manage the encryption materials and they are never part of the other teams.
Finally in order to drive the system, users interact with each of the clouds. They go to the identity cloud to obtain an identity, then they interact with the encryption cloud to get materials to encrypt and decrypt sensitive information. After that, they can safely store the data in the third cloud.
This architecture is very secure. The basic mechanics of it are used for a great many things like secure messaging and password managers, but it has a problem: what happens when you need to process the stored data without the user’s direct involvement? At Kunai we do this with two different security architectures defined by two usage scenarios and one key question: Does the business logic act on the sensitive data?
Two usage scenarios
To simplify securing data, we like to break things down into two usage scenarios for sensitive data. The simple usage scenario is also probably the most common one: you collect some sensitive data that your business logic doesn’t act on. You just pass it along to some other entity. Examples of this: You collect a SSN and you are not the IRS. You collect a Driver’s License Number and you are not the DMV. You collect a credit card number and you are not the issuing bank. In each of these cases you are not acting on the data, you are just collecting it so that you can pass it along to some other business-to-business entity. For this usage scenario, the industry standard architecture that Kunai leverages is called Endpoint Encryption. It’s a straightforward problem with a fair amount of off the shelf ways to implement it and I’ll describe them in the next section.
The second and more complex scenario is that you act on the sensitive data. This is not ideal. There aren’t any solid off the shelf solutions yet for securing this type of data at scale. An example of this are systems that must collect scanned or otherwise unprocessed documents that contain sensitive data, like scanned tax forms. A second example of this would be a system that creates sensitive data, such as a system that tracks blood test results, or sensitive internal chat data, or private judicial records, etc. For this usage scenario the industry standard high security solution is called client side encryption. Every cloud provider gives you the raw API’s needed to implement it, but I have yet to see an off the shelf solution that uses it properly. Since I can’t easily describe an off the shelf solution, I’ll instead describe the architecture Kunai uses to construct custom solutions for this scenario, but I’ll do this in the next article.
Right now, though, let’s get things started by talking about the less complex solution...
Endpoint Encryption (KeyStor)
The Endpoint Encryption solution is pretty simple and it works as follows: If you want to upload sensitive data to your main data center, encrypt the data before it leaves the client’s control, and store the encryption materials you need to decrypt it somewhere else. The basic security architecture looks like this:
The organization of teams remains the same. The first cloud is still identity. The second cloud is expanded to provide a proxy service that never stores data, but can encrypt it at the end point. This cloud can also decrypt it when it is being passed to an external API. The third cloud is expanded to include the business logic.
If this is what you need, there are many options that fit this security architecture. Which option you pick will determine how much control you have and how much security and compliance scope you have. Let’s talk about a few.
Option 1: Let the third party that’s going to get the data do it all
The way that this works is you add something provided by a third party to your client side code that will eventually receive the data. It encrypts the data for you before it leaves the client and heads to your data center. After that your data center receives the encrypted data and it can do whatever it likes with it. When the business logic needs to pass it to the third party, the third party will be able to decrypt it (and then act on it). Depending on what you want to collect and accomplish, there may be some services out there that will allow you to use this architecture. This is how plaid.com works. There are also products from PayPal, Square and others that work this way. It’s how most e-commerce business sites take payments.
The downside is that it’s no longer your application that’s collecting that data. That might be a problem for you, but there’s an easy fix...
Option 2: Use SaaS encryption services
What if you want to take sensitive data that you don’t act on and pass it to multiple API’s that will act on it? What if you want full control over your UI/UX? What if the API that you want to communicate with doesn’t provide client side endpoint encryption for your client app? This isn’t uncommon, and there are still off the shelf solutions that can help you. One excellent solution is Very Good Security. It’s not free, but VGS assumes all the risk for you and since you don’t operate it, it’s easy to maintain the three different IT teams because they become the purple team.
Option 3: Create a self managed solution
Ok, but what if you are a really large company and you don’t want to depend on VGS, or VGS is too expensive. Don’t worry, Kunai has an open source project you can use called KeyStor. It lets you do what VGS does, but you will have to carefully manage it in a data center separate from your main data center. It requires extra work to do this, but it can be done, and we’ve given you a totally free solution that’s easy to deploy, so there’s no excuse for not doing it.
What if I need to modify the data that I’m collecting?
Yep, sometimes that’s important. The simple answer is that if you need to act on the data then do it while it’s still under the end user’s control. This means that you will have to build this business logic into the application that you deliver to the end user. This isn’t always possible or practical. There’s also the possibility that your business logic actually generates sensitive data. Kunai has a solution that solves this use case as well. Things get quite a bit more complicated, and there’s no off the shelf solution that solves this problem properly. In my next article I’ll show you how we do that.
For now, let’s simply revel in the fact that Endpoint Encryption allows our users to follow Ben Franklin’s advice and never tell us their secrets.