Secure Storage
Last updated
Last updated
In it is shown, that often API Keys, secrets as database passwords etc, are hard-coded into the source code and leaked, when uploaded into a public code repository as GitHub or even stored unencrypted on a hard drive. strengthens this statement, by showing that 10 million secrets were leaked in public GitHub repositories, only in 2022. Human errors as such are very common and avoided with a KMS.
In confidential computing technologies, the system software is used to create the TEE. During the creation process, the untrusted system software is able to read, all the code and data it loads into the TEE. Secrets should never be hard coded and loaded into an TEE only after it's being created via Secret Key Provisioning. For this purpose a KMS protected by confidential computing is necessary, when the KMS is deployed in an untrustworthy environment as the cloud, which is often the case. KMS system often provide data-at-rest security by encrypting the secrets while they are on a storage device. To actually be able to manage keys or secrets, the KMS must load them into RAM and decrypt them. Two problems arise here when the attacker has access to the system on which the KMS is running. Initially, the key to decrypt the stored secrets is in plain text inside the RAM and after decryption of the secrets, so are the secrets. This was only an example, there are several features of a KMS where a secret is in plain text in the RAM. Confidential computing is used to provide data-in-use security and also to isolate the KMS from the rest of the untrustworthy system.
In RA-TLS only the SCSC provides a remote attestation report and the KMS provides a regular X509 certificate. However, the SCSC needs to be sure, that the KMS runs in an enclave with valid code. An untrustworthy KMS could provide the SCSC with weak keys or even keys known to an attacker. Also, when the SCSC wants to store a secret in the KMS, this secret will be leaked, if the KMS is malicious. The KMS can use regular certificates, but the SCSC's have to rely on the cloud customer as the trust anchor. Before SCSC's are deployed, the cloud customer has to verify the attestation report of the KMS.
The private key of the certificate should be generated within the KMS and never leave it, otherwise using the cloud customer to provision the certificate and private key could potentially leak the private key, when the cloud customer's system was infected by an adversary. To be able to assign a generated certificate by a KMS to it, the hash of the certificate must be included as optional user data in the attestation report, when the cloud customer verifies the KMS. Additionally, the certificate must be provisioned to the cloud customer alongside the attestation report for distribution. In this case, the certificate is only distributed, when the report is valid and the hash inside the report matches the hash of the provided certificate.
The generated public key to verifiy the certificate of the KMS should be hard-coded into the code of every SCSC. Since the public key is no sensitive information, this is not a problem. In fact, this enhances security, because the public key used to verify the certificate of the KMS is now covered by the measurement. Gramine offers here a good solution, by being able to mount files into the enclave, which are covered by the measurement, without having to hard-code the files inside the actual code. Additionally, it is important to only establish a TLS connection from a SECS to a KMS using this particular certificate for secret key provisioning.
As mentioned earlier, the KMS stores data persistently by encrypting it. The encryption key generated by the KMS for this purpose is provided to the cloud customer over TLS. The cloud customer should store this key securely locally, not in the cloud.
Put into the context of SGX, the code running inside an enclave and the author of the enclave have to be verified. The author is the enclave creator, here the cloud customer. To verify an enclave, the MRENCLAVE and the MRSIGNER value for measurement verification, the attributes, and additionally the whole certificate chain has to be verified. It is often necessary to make keys and secrets available only to specific containers. To do this, the KMS must support RA-TLS. Communication with the KMS happens only via RA-TLS or by providing an admin token, only known to the cloud customer, via TLS. The admin token is used by the customer to configure the KMS. Stored secrets in the KMS are always associated with a measurement. When a strong confidential serverless container (SCSC) wants to access a secret of the KMS, it initializes a RA-TLS connection with it. The KMS then checks whether the SCSC is authorized to access the secret by comparing the stored measurements with the one provided by the SCSC via RA-TLS.
In RA-TLS only the SCSC provides a remote attestation report and the KMS provides a regular X509 certificate. However, the SCSC needs to be sure, that the KMS runs in an enclave with valid code. An untrustworthy KMS could provide the SCSC with weak keys or even keys known to an attacker. Also, when the SCSC wants to store a secret in the KMS, this secret will be leaked, if the KMS is malicious. The KMS can use regular certificates, but the SCSC's have to rely on the cloud customer as the trust anchor. Before SCSC's are deployed, the cloud customer has to verify the attestation report of the KMS.
The private key of the certificate should be generated within the KMS and never leave it, otherwise using the cloud customer to provision the certificate and private key could potentially leak the private key, when the cloud customer's system was infected by an adversary. To be able to assign a generated certificate by a KMS to it, the hash of the certificate must be included as optional user data in the attestation report, when the cloud customer verifies the KMS. Additionally, the certificate must be provisioned to the cloud customer alongside the attestation report for distribution. In this case, the certificate is only distributed, when the report is valid and the hash inside the report matches the hash of the provided certificate.
The generated public key to verifiy the certificate of the KMS should be hard-coded into the code of every SCSC. Since the public key is no sensitive information, this is not a problem. In fact, this enhances security, because the public key used to verify the certificate of the KMS is now covered by the measurement. Gramine offers here a good solution, by being able to mount files into the enclave, which are covered by the measurement, without having to hard-code the files inside the actual code. Additionally, it is important to only establish a TLS connection from a SECS to a KMS using this particular certificate for secret key provisioning.
As mentioned earlier, the KMS stores data persistently by encrypting it. The encryption key generated by the KMS for this purpose is provided to the cloud customer over TLS. The cloud customer should store this key securely locally, not in the cloud.
The KMS should be used to store an encryption key for every serverless container that needs to store data persistently. This key is then provisioned on start up via Gramine's secret key provisioning and is used to encrypt and decrypt files transparently of a mounted volume. Every secret of the KMS has to be associated with a measurement, meaning with a MRENCLAVE and/or MRSIGNER. By associating a secret with only MRSIGNER, every enclave having the same enclave author, is able to request this secret. When using only MRENCLAVE, every enclave having the same code, could request this secret. Naively, one might think that this would already be enough, however, imagine the following scenario. A company wants to enclave an application and stores an encryption key within a secure KMS associated with only the MRENCLAVE of the application. Now, what an adversary can do strictly depends on the application. Should the enclaved application use a key-pair for RA-TLS, that is read from the file-system without being measured, then the attacker is able to generate a key-pair and locate it at the position, where the enclave will read it and receive the remote attestation report that includes the hash of the public key as user data. Since on a RA-TLS the remote attestation report is sent not encrypted, the report can easily be received by an adversary. What he can do now is, he can request the encryption key of the KMS, because he has the used key-pair and a valid remote attestation report for RA-TLS. If the key-pair should be generated inside the enclave, then the only way to retrieve the encryption key is through an interface provided by the application. For example an application provides a management interface for an admin, that allows him to read the encryption key. As a result, if only one enclave is to have access to the secret, then the secret should always be associated with MRENCLAVE and MRSIGNER.
Anytime an enclave requests or stores a secret, it has to establish a RA-TLS channel with the KMS. Here, the KMS receives the remote attestation report of the enclave, verifies the certificate chain and the attributes first, then it checks if the MRENCLAVE and MRSIGNER is known to the KMS and cache both values. Otherwise the connection is rejected. The last verification step is done for performance reasons, to not have ongoing TLS connections with enclaves, which are not authorized to do anything. Enclaves with debugging enabled should always be rejected, since memory encryption is disabled and the secrets can easily be read. Now since MRENCLAVE and MRSIGNER are cached, the KMS can check, if the enclave requests to retrieve or store secrets, if the values match the stored values and then let the enclave perform the action. Verification, when storing secrets is done, to disallow a potential malicious enclave to repeatedly store secrets and fill up the memory.
Should a SCSC receive an update, it's measurement will change. Thus, it is not being able to access it's secrets in the KMS anymore. The cloud customer has to update the stored measurements associated with the SCSC in the KMS, so it can again receive it's secrets. New revisions are also created by Knative when the configuration of a service changes. However, this does not always result in a code change and thus the measurement can remain the same. Only if a revision is created by a code update, this must be considered. In this case the old version, depending on the configuration of the service, remains online for a short period of time, as configured. In order for the old version to still be able to store or query secrets, if wanted by the cloud customer, multiple valid measurements would have to be stored for the same container in the KMS. It is important to consider the case when a security update is released and the old version is completely untrustworthy. Then the measurement of the old version should always be removed instantly and all secrets associated with the old version should be updated.
Arguably, when the KMS is deployed on a trusted system, there is no need to protect it with confidential computing.
Any adversary in the threat model can delete files from a mounted storage device of the VM. Therefore, backups of persistent data are essential to ensure data availability. Any encrypted persistent data stored in the cloud should also be encrypted on the cloud customer's local storage device.