The general availability of the Key Management Secrets Engine in Vault 1.7+ent or higher facilitates the creation, management and deployment of symmetric and asymmetric cryptographic keys from HashiCorp Vault to remote keystores. Currently, this enterprise engine supports the Azure Key Vault as a target Key Management System (KMS), but ships beta support for AWS KMS already. The engine is part of the Vault Enterprise Advanced Data Protection (ADP) offering and useful for enterprises required to control the lifecycle of cryptographic keys (creation, distribution, rotation, revocation, etc.).

Use Vault >= 1.7.2+ent. It includes a fix for a panic error that occurred on audit logging while reading keys from the engine.

The engine increases the portability of cryptographic keys, because the secret key can be distributed to remote key stores while protecting the original key source in Vault. Prevalent security modules or keystores keep secret key material locked tight. For instance, the Azure Key Vault does not support export operations on the private key, i.e., allows exporting the public part of the key material only, not the actual secret. In this sense, the Vault Key Management Secrets Engine represents a holistic solution to generate, maintain and transport secret cryptographic material.

This post captures a few thoughts on how the Key Management Secrets Engine can meet the requirement for secure cryptographic keys of your business. For technical details on how to use the Key Management Secrets Engine refer to HashiCorp learn, the official documentation for the secrets engine and the corresponding API documentation page.

Contact us to explore how Vault can be implemented in your workflows and environment to protect your applications key and cover your  secret management needs.

Why to Use Your Own Key

Use the terminology with a grain of salt. The content on which this blog post is based evolved during the last year and was adapted frequently to changes in the upstream documentation.

The Key Management Secrets Engine opens the door for a plenary of interesting application scenarios. Among others, it allows the distribution of cryptographic keys to Azure Key Vault. The keys in Azure Key Vault can then be consumed by a myriad of downstream applications:

• Encryption at rest for Azure VM Disks: Azure Disk Encryption (ADE) or Server-Side Encryption (SSE) for Azure Disks
• Encryption at Rest for Azure Storage (Blob, Files)
• Bring Your Own Key (BYOK) for Azure Azure Information Protection (AIP)

Clearly, the Vault Key Management Secrets Engine is beneficial for applications that use the keys stored in the remote key management systems. For example, keys in Azure Key Vault can be used to protect data in Snowflake (data warehouse). With the “tri-secret secure” Snowflake enterprise feature, Snowflake encryption keys can be combined with a BYOK key to create a composite master key for data protection. Thus, data can no longer be decrypted if either one of the keys is revoked, the key in Azure Key Vault originating at HashiCorp Vault or the key maintained by Snowflake.

The Key Management Secrets Engine also enables some use cases which might not be obvious on first sight and lead back to Vault as downstream consumer. For instance, the engine can be used to manage and keep in charge of cloud keys which are used to unseal other Vault clusters (i.e., backup of the actual cloud auto-unsealing keys and not just the recovery keys).

Procedures for the distribution of customer-managed keys to cloud environments (cloud key management or key brokering) can be categorized in Hold Your Own Key (HYOK) or Bring Your Own Key (BYOK) solutions.

The two abbreviations or terms are easily confused and flexed to a certain degree. In a mixed HYOK/BYOK scenario, the remote service requests the key material from HashiCorp Vault. The request is initiated at the consumer side (pull mode). The request can be directed immediately to Vault (e.g, authenticated with the Vault JWT backend) or intercepted by an intermediary API, such as the Distributey key wrapper. No Key Management Secrets Engine is needed in this situation, because the Vault Transit engine is sufficient to implement a scenario where the remote service fetches the key material from Vault. This mixed model with an intermediary API sources the keys from the Vault Transit engine. It proved useful in situations where the remote service cannot retrieve key material from a remote key store supported by the Vault Key Management Secrets Engine.

Depending on the understanding and definition of HYOK, the remote service may not be allowed to read the plain-text user data (data opacity). In this purest form of the HYOK model, the user is in possession of the private key and the raw payload (user data) at all times and actually “owns and holds the key”. As a result, data protected by a local key cannot be automatically encrypted and processed by cloud applications without the users consent. This restrictive form of protection is suitable for very sensitive data that requires no processing in the cloud. The private key is not transferred to the remote service at all, rather, data is encrypted before transmission. However, there exists no agreement on this mental model for HYOK and the term HYOK is therefore not always treated equally across cloud providers. For example, secret key material is cached in the cache-only key service by Salesforce, which was labeled a HYOK solution until recently, whereas Azure insists that the private key remains on premises when using HYOK. Hence, the location of the cache and the cache TTL can make the exact identification of HYOK and BYOK solutions a fuzzy affair. Azure permits the operation of both key paradigms, HYOK and BYOK. It is recommended to use the BYOK paradigm for AIP as well, since the AIP classic client is deprecated and the HYOK approach mainly targeted this classic client.

In contrast to HYOK, the key material is pushed from Vault to the remote service when using BYOK. In other words, there is usually no inbound request from the service provider. In practice, the BYOK approach is easier to implement, because engineering efforts for additional infrastructure (key wrapper) can be neglected. Also, publishing the API of a key wrapper (interface or actual HashiCorp Vault) increases the potential attack surface.

From a legal perspective, the HYOK method is oftentimes favored because of the aforementioned mental image of a pure HYOK implementation. HYOK enjoys a more advantageous wording, and if implemented very restrictively, can be considered superior from a security point of view.

Obviously, the short list of use cases above and the schematic example scenarios in Fig. 1 can never be conclusive. Get in touch with us to explore how Vault can fulfill the key brokering requirements of your specific business case.

 

Key Wrapping in Transport and at Rest

Independent of the exact model for key distribution (Key Management Secrets Engine or Transit engine combined with on-prem wrapping API), the cryptographic keys are usually exchanged with the industry standard JSON Web Encryption format (JWE, see RFC7516). JWE leverages a combination of symmetric (shared) and asymmetric key encryption to encrypt the key material during transport. The Vault Key Management Secrets Engine abstracts this wrapping process. In other words, wrapping procedures (JWE) are taken care of by HashiCorp Vault when the Key Management Secrets Engine is applied in a BYOK transfer, which clearly is an advantage compared to mixed or pure HYOK style of transfers.

Double encryption, composite or wrapped keys are common techniques to protect the user data in the remote service with a local key from on-premises (the BYOK key). In this way, the trust radius spans multiple parties, since both the key of the data owner and the cloud provider are required to decrypt and process the payload. An example scenario for key transport includes three types of keys:

• Data Encryption Key (DEK): Local target key from HashiCorp Vault which will be used to encrypt the user data. This key can be generated with the Transit or Key Management Secrets Engine, depending on the “own key model” depicted in Fig. 1 and the interoperability capabilities of the remote service with common cloud key stores such as AWS KMS or Azure Key Vault.
• Content Encryption Key (AES CEK): Locally generated key for key wrapping
• Key Encryption Key (RSA KEK): Key pair of the key consumer

The Data Encryption Key (DEK) is the target key material from the Vault Transit engine and first encrypted with an ephemeral AES wrapping key (CEK). In a second step, the CEK is encrypted with the public key of the receiver (KEK). The doubly encrypted keys are both part of the message sent to the remote service. The remote service decrypts the CEK and unpacks the DEK to finally encrypt user data.

An additional key hierarchy in the cloud service can benefit from the same double encryption technique at rest, similar to the one used during transport, to further organize and simplify key management or to improve performance of encryption/decryption operations for large amounts of data.

Different from the general technique of wrapping keys or data within multiple layers of encryption, the Double Key Encryption service is an actual piece of software developed by Microsoft to ensure that user data cannot be encrypted without a local key. Nevertheless, the RSA keys for this local service could also be sourced and managed with the HashiCorp Transit engine.

Similarly to the Distributey key wrapper in a mixed HYOK/BYOK model (see Fig. 1), the request to retrieve key material would also be initiated by the service provider. However, unlike the Distributey key wrapper, the Double Key Encryption service only returns the public key for encryption. This message does not require JWE or wrapping for protection. The purpose of the Double Key Encryption service is different from the Distributey (or any other) key wrapper API, because it is used to decrypt data locally and does not act as a proxy for transferring secret key material.

 

How to Distribute Keys from HashiCorp Vault to Azure Key Vault

The general process for distributing encryption keys from HashiCorp Vault to Azure Key Vault can be summarized as follows:

1. Enable the Key Management Secrets Engine in Vault
2. Create a named cryptographic key of a specific type (e.g., 2048 bit RSA key)
3. Configure the KMS provider in Vault with the credentials of the Azure service principal
4. Distribute the key from step (2) to Azure Key Vault

 

Vault Key Management for Azure Information Protection (AIP)

“Azure Information Protection (AIP) is a cloud-based solution that enables organizations to discover, classify, and protect documents and emails by applying labels to content.”

What is Azure Information Protection?

When the Vault Key Management Secrets Engine provisions the tenant root key for Azure Information Protection (AIP), the KEK used to protect the DEK from Vault is derived from an HSM protected Azure Key Vault (premium SKU). The tenant root key for AIP can be rekeyed later on in response to a data breach or changing organizational structures. Compared to a key solely managed by the cloud provider, the key lifecycle is primarily determined by the actions performed in HashiCorp Vault. With a BYOK created in HashiCorp Vault, organizations have more control over key operations compared to a tenant key which is only managed by Microsoft.

The key specifications for the intended target key store and application usage should be carefully planned for. For instance, to construct key material that can later be used for AIP, a 2048 bit RSA key is recommended. Fortunately this type of key is supported by the HashiCorp Key Management Secrets Engine as well. As mentioned previously, it is required to use the premium tier Key Vault backed by an HSM for performing BYOK procedures on Azure Key Vault, because the KEK can not be derived from keys stored in software protected Key Vaults (standard tier). Moreover, the Azure service principal needs the correct Azure access policy on the Azure Key Vault. Finally, the key purpose is not to be confused with the Azure Key Vault access policy. It defines the permitted Azure Key Vault operations and can be specified at distribution time.

To begin exploring HashiCorp Vault with the Transit and Key Management Secrets Engine on your own, start your free trial for Vault Enterprise today and let us know how Adfinis can support your business to keep being in charge of secrets and key material.