HashiCorp's Vault

HashiCorps Vault received the highest score in an comparative analysis of KMS's in this paper, is open-source and widely used. Running in an enclave, it provides the cluster with a secure way of data-at-rest encryption, secret storage and authorized access to secrets. Enclaive provides an authentication plug-in for an enclaved Vault for RA-TLS secret provisioning. Because the plug-in is used to create a proof-of-concept, this section describes how it works.

Enclaive's RA-TLS plug-in workflow

To not have to modify the application, Enclaive integrates a binary, called pre-main, into each enclave, which executes before the main application. This is done for each container containing an enclave, including the Vault, since it is also a container. There are two of such binaries, one for the Vault and one for enclaves requesting secrets of the Vault. In case of the Vault, the pre-main generates a self-signed TLS certificate, that is later used by the Vault for all incoming TLS connections, and hosts an API endpoint for the cloud customer, which returns the attestation report. The Vault's certificate is extracted from the TLS connection. Now, the cloud customer has to verify the attestation report, before configuring the Vault, to check, if the measurements and attributes are as expected and the certificate chain is valid. Furthermore, the attestation report holds the certificates hash in the optional user-data field and the cloud customer has to verify, that the hash of the extracted TLS certificate matches the hash in the user-data field. Since only the Vault should know the private key, the verifier can be confident that this certificate belongs to the enclave referenced in the attestation report and the Vault started with the right measurements. (Step 1 figure above)

In Gramine, the enclaved applications have to provide an interface for remote attestation report requests and is not provided automatically. After the endpoint of the Vault's pre-main to receive the attestation report is called, for a user-defined amount, the pre-main starts the Vault (Step 2.). Now, the cloud customer is able to initialize the Vault after verification by using TLS and the earlier provided certificate to authenticate the Vault (Step 3). The initialization returns an admin-token and an unseal key for the Vault. Both values can be stored in a hardware security module (HSM) to protect the secrets. Authentication plug-ins are only installable, after the initialization of the vault, thus by providing the admin-token, the cloud customer now needs to install the RSA-TLS authentication plug-in. So, the plug-in is not covered by the Vault's measurement.

Moreover, a cloud customer has to configure a user for every enclave requesting secrets from the vault. This user holds a unique username, called enclave name, and the enclave's measurements. Subsequently, a secret associated with one or more users can be created for provisioning. Additionally, every enclave receives a certificate, which can be used for in-cluster authentication. For security reasons, the vault creates a root CA and an intermediate CA. Only the intermediate CA, signs the certificates for the enclaves. Should an enclave have a security vulnerability inside it's code, which allows an attacker to read the private key of it's certificate, the intermediate CA can be rotated. Finally, when the enclave is launched, it's pre-main starts first, which in return requests a quote, creates a self-signed certificate including the enclave name as the subject-name and quote in an extensions field, uses the self-signed certificate to establish a RA-TLS connection to the vault and requests a secret (step 4.). On the basis of the certificate, the Vault verifies the attestation report and the subject-name, logs the user in and authorizes the access if the secret is associated with that user. After receiving the secret, the pre-main can passes it as an argument or environment variable to the main application and start it (Step 5.). Because the RAM is encrypted, this is safe to do. The certificate, which is public information, can be written to disk. Should a decryption key be provisioned, Gramine stores it RAM and uses it to encrypt and decrypt the specified file paths. HashiCorps Vault is only one example of a KMS and therefore the following sections will continue to refer to KMS's in general terms.