Secret Key Provisioning

Because the untrusted system software loads all code and data into an enclave through the EADD instruction, secrets are provisioned into an enclave after the enclave is initialized and should not be hard-coded. Otherwise, the system software will be able to read the secrets. Secret key provisioning is done via RA-TLS, which adds a remote attestation report as a X509 extension to the certificate used for authentication. Here, a Key Management System (KMS) could be used to store and provision secrets. The KMS uses a regular X509 certificate for authentication. RA-TLS differs from TLS only in how the enclave's X509 certificate is generated and verified. An enclave's certificate generation works as follows: First, the enclave generates a signing key pair (pk,sk) and requests an attestation report by optionally providing as user input the hash of the signing public key H(pk), where H is a secure hash function with a maximum output of 64 bytes. After receiving the remote attestation report, the enclave creates a self-signed certificate $cert_{Enc}$ by signing it with sk and includes the attestation report in the X509 extensions field. Now the enclave can use cert to authenticate to the KMS. Upon receiving cert, the KMS first verifies the attestation report, as described in Certificate, and then the self-signed certificate. Since pk is included in the attestation report and verifies the self-signed certificate, the holder of the X509 certificate, owner of sk, must be the enclave referenced in the report. The KMS may reject the RA-TLS connection if MRENCLAVE, MRSIGNER or the SVN's do not have the values it expects.

One of the features of Gramine is that it already provides an interface for secret provisioning using RA-TLS. Additionally, it provides the ability to use the received secret to transparently encrypt and decrypt files on read and write access. These files are referenced as encrypted files in the manifest file.