How does Vault encrypt data?

Transcript

Vault encrypts data by leveraging a few key sources. The first is the libraries that Vault uses, or the cryptography modules, specifically that Vault uses to encrypt that data. That is Golang's crypto and x/crypto libraries that are part of the golang language.

Vault cryptography libraries

This is very important and it's part of our open-source story because we at HashiCorp abide by something called Kerckhoffs's principle. Kerckhoffs's principle is a principle that comes from a 19th-century military cryptologist who stated that basically there is no security in obscurity. If you have a very secure system that everything that talks about how that system protects itself should be visible.

We translate that into modern times to mean that the source code for how you encrypt and decrypt data should be open source, and that's why HashiCorp's Vault source code for how it—Vault—handles encryption is all composed in its open-source binary. You can go into GitHub and take a look at it now, for example.

So we leverage those Golang crypto and x/crypto libraries to handle the heavy lifting associated with encrypting and decrypting data. Those libraries contain the methods and functions that are the implementations of various algorithms like AES256 that are used within Vault, for either internally encrypting data and decrypting data or fo—as part of our transit backend—allowing you to leverage cryptography without having to deploy your own cryptographic infrastructure.

Vault key management

There's also this element of key management, how does Vault manage keys that are associated with these cryptographic functions? Vault handles this all through its own internal keyring, which is again also in open source, and allows Vault to not have to require a user to integrate into something like an HSM (Hardware security module) unless they want to.

Vault cryptography integrations

Beyond this, when we talk about encryption, there are two key things that we need to focus on. The first is entropy and the second is how that encryption algorithm links to other cryptographic standards or follows cryptographic standards.

We talk about entropy with Vault. The entropy of Vault's encryption varies depending upon what system Vault is being run on. So with Golang's crypto and x/crypto libraries, they use a randomized function that calls different entropy pools depending on which operating system you're deploying that on. For example, Windows uses a different type of entropy pool than the entropy pool used by Linux.

One question that you need to really ask yourselves is, "What is sufficient entropy for Vault?" In many ways, those random number generators are sufficiently random. However, especially with Vault Enterprise customers, there are times where we run into questions about, "Is that entropy sufficiently random? Is the method that's used to randomly derive the numbers—used for either salts or otherwise numbers used only once or nonces to protect certain cryptographic components that are protected by Vault—sufficiently random for my threat model?" And if it's not, this is where a Vault Enterprise feature called Seal Wrap comes into play.

Seal Wrap allows us to leverage external cryptographic modules, such as those that are contained within your HSM, to protect and wrap the cryptographic infrastructure of Vault in such a way that we can allow Vault to operate within very rigorous cryptographic environments in a way that doesn't violate their story around entropy, their story around key rotation, key management, etc.

For example, the US standard of FIPS 140-2 has different levels that refer to how secure an implementation of cryptography is. Well, with Seal Wrap, Vault can allow its data that's being used and stored within cryptographic reservoirs within Vault—so its keyring, the methods that it uses to encrypt data, etc.—all that can be wrapped with another layer of cryptography that comes from a separate, very secure source such as an HSM. And in that kind of model, those HSMs can be configured to run at a very high level of a FIPS level. Thus allowing Vault to non-disruptively operate in FIPS 140-2 level one, two, and three environments.