Benefits and use case
By using secure enclaves, Hyker have made it possible to provide secure cloud key storage. Using this technology, we can achieve HSM-like (Hardware Security Module) properties, without expensive hardware that needs purchasing, setting up and maintaining.
Cryptographic keys need safeguarding. They need protection from both internal and external threats. They also need backup. For this problem, Hyker Security provides a solution for key protection and backup in the cloud; so that our customers can reduce cost, work overhead and maintenance associated with other solutions relying on specialized hardware.
HSMs has long been a go-to solution, for those who can afford it, for secure key backup. It has enjoyed this popularity because of its properties of trusted hardware which brings verifiability and confidentiality properties. However, they also have some drawbacks. For example, they are expensive pieces of specialized hardware, they need maintenance and they need to be deployed in a centralized way. In essence, they are not very compatible with the cloud.
Hardware Security Modules
First, let’s talk about why people use HSMs. An HSM has many purposes, like cryptographic offloading and key generation. In Wikipedias article on HSM we can read:
“A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.”
In this article, we are interested in one of these functions, namely secure key backup. Reading the Wikipedia quote with that focus, we can extract two key things from it:
● An HSM is a physical computing device, i.e. we need an actual box, or as wikipedia puts it: a plug-in card or an external device that attaches directly to a computer or network server.
● A key purpose of an HSM is to protect cryptographic keys.
Enter secure enclaves
A new technology, called secure enclaves, has recently appeared. The most prominent of these enclaves is Intel SGX. This technology is another beast than HSMs. Both HSMs and SGX are examples of trusted hardware, however SGX has one strong advantage, it can run standard program code. Further, it is possible for a user to verify that the correct version of the code is running in an SGX enclave. The user can also check that nobody has manipulated the software. Lastly, since they can check that the code is running within an enclave, the user can be sure that the host of the enclave, i.e. a cloud service, can not access any data or code within the enclave. The secrecy of the input data, code and results is guaranteed.
Because of these properties, it is now possible to build secure key storage in software only, and deploy it to a cloud while maintaining all benefits from traditional HSMs.
This is exactly what we at Hyker have done.
To demonstrate how this can be of use, let’s do a use case. We will go with a use case that actually exists. In 2017 one of our customers at Hyker came to us with a need:
“I do penetration tests. When I am to deliver the results to a customer, this is highly sensitive information. It is basically a recipe for hacking them. Therefore, using easy to use services like Dropbox is not an option. Secure services like SFTP are often also out of the question, because they are too hard for the customer to use. Do you know of any tool that is both easy to use and end-to-end secure?”
This led us to build our service Konfident.io, an easy to use end-to-end encrypted document sharing tool in the browser.
Konfident.io has 2 main features:
● It is fully secure. No data, including cryptokeys, is ever exposed to any party except sender and receiver. Not even Hyker can read the data.
● It is easy to use. The user does not have to install anything, set anything up, remember passwords or store and backup cryptographic keys.
That last part about storing and doing backup of cryptographic keys is problematic. Usability requires that Hyker takes care of backup of data and keys, but security requires that Hyker has no knowledge of data and keys. This is where Intel SGX comes to the rescue.
In Konfident.io, we store cryptographic keys in the cloud using SGX enclaves. This enables us to backup cryptographic keys without compromising end-to-end security, without interfering with usability.
So how does this solution work? The design is fairly simple in nature. It consists of 2 SGX enclaves, the Vault and the Authenticator , responsible for securing keys and authenticating users respectively. As helping entities, there is also a standard database for the Vault, and an external authenticator for the enclave authenticator. The external auth is the authenticating mechanism of choice for the system developer, e.g. Auth0 or Active Directory. You can see how these things connect in the image below.
Let’s start with the data flow before we describe the pieces individually. The flow for storing a cryptographic key goes like this:
1. The client makes a store request to the vault enclave. The vault needs an authenticator in order to fulfill this request, so the client tells the vault which authenticator to use and how to connect to it.
2. The vault encrypts the data, and stores it in a central database. It also stores the instructions on how to authenticate any future collect requests.
3. The client later makes a collect request to the vault enclave, in order to get the stored data. This client does not have to be the same client that made the store request and can be any client, as long as the authenticator authorizes the client.
4. The vault loads the instructions on how to authenticate the user from the database, verifies the integrity of the instructions, and calls the authenticator specified in the instructions.
5. The authenticator either responds with OK or DENY.
6. Now that the vault has received a response from the authenticator, it can go ahead and load the stored data from the database, decrypt it, and return it to the client.
The vault is the most central part of this design. It is responsible for encrypting data belonging to clients, e.g. client cryptographic keys, with its own encryption key. The purpose being that if we encrypt this data, we can store it anywhere without worrying about data leaks. If this was not done by a secure enclave, we would not be able to solve the problem of secure storage, since we would just have created a new encryption key which we would have to store securely as well. But since our encryption key is stored within an enclave, we don’t have to worry about that. The enclave encryption key safely resides within the enclave, so that not even Hyker, the builder and provider of the enclave, or the host e.g. AWS, can access the key.
There is not much to be said about the database. The different elements are encrypted by the vault before entering the database. So the only thing we have to take care of is availability and backups, for which there exists many solutions.
Why do we require an authenticator running in an enclave in between the vault and the external authenticator? This is because of separation of concerns. We don’t want the vault to be concerned with the way the authentication works. Though, we have to place certain parts of the authentication process within an enclave. For example the rules for what a user is allowed to do and how a user should be authenticated is something which is critical to security. If this is maliciously changed, we have a security flaw. Therefore we have an authenticator enclave as well.
The External Authenticator
But a user should be able to authenticate in many ways, how this authentication works is subject to change. Plus it is a matter of market penetration and subjective taste of desired authentication solutions. Therefore we make this part of the solution external. This enables us to be flexible in terms of supported authentication solutions, while keeping the core logic of our own within the authenticator enclave.
So, using SGX enclaves, we have managed to build our own customized HSM, which is way cheaper, more flexible and can be deployed in an instant in the cloud. This way we could solve many of the problems that come from trying to build a secure system, while maintaining usability and security of user data. Because of this solution, the system is easy to use for both users, and for us at Hyker. The users don’t need to worry about security, and we at Hyker don’t have to handle cumbersome HSMs.
Joakim Brorsson, Director Hyker Labs & PhD student LTH
Emil Boman, Lead developer SGX technology