Unify your cryptography with Vault Transit Engine

Why HashiCorp Vault is an Adaptable Cryptography Platform

HashiCorp Vault is a secrets management solution that offers a broad range of capabilities like secure storage of secrets, dynamic database credentials, or Kubernetes secrets to name a few. One of the most popular Vault use cases is encryption as a service, which allows you to offload the encryption of your application data to Vault by simply invoking an API.

You can send plaintext data securely via HTTPS to Vault, Vault encrypts it, sends the ciphertext back, and you can store this data wherever you need it to be stored. That’s it — now you can focus on your core competencies rather than having to rack your brains about how to correctly implement encryption algorithms in your application.

This powerful functionality is handled by Vault’s Transit secrets engine. However this engine comes with many more capabilities that allow you to centralize your key and cryptography management on one platform-agnostic solution, and in this article we will take a look at how this can be achieved.

Centralize cryptography and key management

Centralizing your cryptography management on a single, platform-agnostic solution comes with a lot of advantages, like standardization of security, the ability to focus on your core competencies, as well as a reduced blast radius and much lower maintenance costs.

By centralizing and standardizing your cryptography on a single platform you can offer it as a service to your customers and developers. In short, it is the first step towards cryptography as a service. In a recent project I worked on, a customer wanted to achieve exactly this. The solution was to rely on Vault, more specifically on Vault’s Transit secrets engine, for secure management of keys and centralized cryptography.

What are the capabilities of the Transit engine?

Transit creates and manages the lifecycle of keys. Different key types are supported in Vault and you can find the full list of supported key types here.

The keys can be rotated automatically, adding an additional layer of protection. They can also be backed up and if they need to be exported. Exports however, should be handled with care and are not enabled by default.

In a classical encryption as a service scenario, the generated keys are now used to encrypt and decrypt data. While encryption was also part of the project I mentioned earlier, it was not the main use case. The customer’s main use case was overall key management as well as performing cryptographic operations like HMAC generation or signing and verifying data. These are all possible with the Transit secrets engine.

Another requirement we had in the project was key generation during the production process. To generate those keys, random numbers are provided by the IT security team that must be used. However, the key generation process itself is decoupled from the IT security team and a strict separation of responsibilities is enforced. Those organizational structures made it impossible to onboard the key generation of those keys onto Vault. So how can we still consolidate cryptography management while aligning to the historical requirement of segregation of duties?

We can leverage the random byte generation that Transit offers. Those bytes are fed into the production system, which then generates the keys. In order to use those keys for cryptographic operation, you need to import them into Vault’s Transit secrets engine.

Another make or break requirement we had in the project was the ability to integrate into existing hardware security modules (HSMs).

I already have an HSM, can I use it with Vault?

Many organizations have the requirement to use an HSM. Luckily Vault Enterprise allows you to integrate your Vault with any HSM that supports PKCS#11.

For our use case, entropy augmentation is especially interesting. When you create a cryptographic key in Vault, Vault sources entropy from the platform it is running on. If you have entropy augmentation enabled, entropy is sourced from the cryptographic module of your HSM.

The same goes for random byte generation. When you want to generate random bytes, you can choose if you would like to use platform entropy, which means the entropy of the platform Vault runs on. Or you can choose seal, which leverages the cryptographic module of your configured HSM. By doing so you can funnel the access to your HSM through Vault and have your users generate keys without needing to directly access the HSM.

But what if you have the requirement to generate certain keys directly on the HSM? Can they still be used for cryptographic operations? Yes, they can.

Bring your own key to Vault

In Vault 1.11 we added Bring-your-own-key (BYOK) support to the Transit secrets engine. Now you have the option to import existing keys into Vault and treat them as if they were native keys.

One quick note of caution: it is always more secure to have the keys generated and managed in Vault directly. Sometimes this is not possible, as we might face historical barriers that cannot be changed overnight. In that and similar situations you can create the keys outside of Vault (e.g. directly on an HSM) and use the new BYOK API endpoint of Vault. Imported keys are fully managed by Vault. Once the key is imported in Transit, you can perform all cryptographic operations that Transit supports.

Conclusion/Summary

With Vault you can centralize and consolidate key and cryptography management in your organization. Vault becomes the entry point for key consumption and improves access to your HSMs. It generates, stores, and manages all your keys. With the Transit secrets engine, BYOK capability, and HSM integration it allows you to consolidate your cryptography and offer cryptography as a service to your teams and customers, allowing them to perform cryptographic operations without the keys ever having to leave Vault. With this you achieve a seamless experience for your key and cryptography management.