Decrypting Enclaves: Encryption Key Hierarchy

Sneha Damle

Developer Evangelist at R3

Intel SGX is an implementation of a Trusted Execution Environment (TEE): an environment where data integrity and confidentiality and code integrity are protected by hardware-based encryption. Intel SGX isolates specific application code and data in a secure part of the module's memory, called "enclaves." Conclave makes it very easy for you to interact with enclaves in higher languages such as Java and Kotlin. Before we dig deep into Conclave, let’s talk a bit about the different encryption keys used throughout an enclave’s lifecycle.

An enclave uses "keys" as the root of trust instead of using certificates. They are the foundation for the software chain of trust.

There are multiple keys used at multiple points during an enclave’s lifecycle. To start with, Intel issues two key pairs which are fused into the CPU at the time of CPU manufacturing. All other keys are derived from these two keys. Keys are used in the attestation process to prove that a particular piece of code is running on a trusted SGX-enabled CPU. This proves the authenticity of the enclave on which your code runs. Keys are also used during sealing to encrypt your data. Now let's dive into the different keys used for the above-mentioned scenarios.

Root Provisioning Key: This key is fused into the Intel processor by Intel at the time of CPU manufacturing. Intel acts as a certifying authority (CA) and issues a digital certificate identifying this SGX-enabled CPU’s identity. This key is securely stored in an HSM within a facility managed by Intel and allows Intel to verify that the CPU is a genuine SGX-enabled part during remote attestation.

Root Sealing Key: This key is also baked by Intel into the CPU. This key is a unique key known only to the CPU and is used for sealing.

Let’s take a look at some common structures used by Intel SGX enclaves.

MRENCLAVE: This is the enclave’s identity, a SHA-256 hash of the log that records all activity while the enclave is being built. This log consists of code, data, heap, stack, and other attributes of an enclave. Once the build is complete, the final value of MRENCLAVE represents the identity of the enclave. In short, it’s the hash of the enclave code and initial data.

MRSIGNER: Each enclave is also signed by its author. MRSIGNER contains the hash of the public key of the author.

REPORT: The enclave creates a REPORT structure consisting of MRENCLAVE, MRSIGNER, and additional enclave attributes.

Enclaves cannot access these root keys directly; instead, they use a derivation function to derive them. The derivation function uses MRENCLAVE, MRSIGNER, the current CPU microcode security version number and other enclave attributes to derive the keys. A nonce is also given as an input to this function to add entropy. Usually this is a password specific to the owner of the system, allowing the owner to cryptographically destroy any data sealed by the system when it is deprovisioned.

Below are examples of keys that enclaves can derive.

Report Key: This is derived from the root seal seal key and is used during attestation. The enclave creates a REPORT structure consisting of MRENCLAVE, MRSIGNER and some more enclave attributes. An enclave is required to prove its authenticity and code integrity to either a client or an enclave running on a different system (remote attestation) or to another enclave running on the same system (local attestation). For local attestation, the host obtains a report from the enclave. This report contains the MRSIGNER, MRENCLAVE and other report attributes, including some user data which is normally a public key for communicating with the enclave. This report is actually the same for local and remote attestation. The report structure is then signed inside the enclave using the REPORT key. The hash of the REPORT data is encrypted with the REPORT key, and the signed report is then sent into another enclave on the same system via a host process. The other enclave has access to the same REPORT key so that it can generate a new hash over the report, decrypt the hash that the other enclave used to sign, then ensure the two are the same.

Provisioning Key: This is derived from the root provisioning key. This key is used by the CPU to identify itself to Intel for attestation. Remote attestation proves to a client that the correct code is deployed on a fully patched, SGX-enabled enclave. The attestation service could be either EPID or DCAP.

For both types of attestation, the current host (the process on which a current enclave is loaded) sends the REPORT to another enclave called a Quoting Enclave which verifies the signed REPORT (signed using the report key) and signs it using the provisioning key.

For Enhanced Privacy Identification (EPID), the REPORT signed by the quoting enclave (called the "quote") is sent to the Intel Attestation Service (IAS) by the host or the client, depending on the application (for Conclave, this is always the host). The IAS then verifies the quote and signs it with a certificate that is rooted within the Intel SGX root of trust. This Intel-signed verification can then be checked by the host and sent to a client, who only needs to check to see if the certificate is valid and trusted. This is mostly a legacy approach.

Data Center Attestation Primitives (DCAP) works a bit differently. The quote is signed using the same provisioning key as before, however, rather than sending the quote to Intel for verification, the host requests information about the platform from the Intel Provisioning Certification Service (PCS). This information is called "collateral" and includes Intel-signed information about the platform that can be used to verify the quote without sending it to Intel. The report/quote and the collateral are sent to a relying part (the client) which can then verify the collateral against the trusted Intel root certificate and verify the quote against the collateral. This is a newer approach focused on data centers and cloud service providers. This provisioning is based on ECDSA signatures which allow for construction of on-prem attestation services.

Seal Key: This key is derived from the root seal key. The memory used inside an enclave is encrypted using hardware and is isolated from other processes and applications. When the enclave stops, data in memory cannot be recovered. Sealing is a technique used to encrypt and export data outside the enclave without compromising data confidentiality or integrity. From outside it can be transmitted over a network or saved to an external storage location like an external database or hard disk. Sealing keys can be derived from MRENCLAVE or MRSIGNER for storing data.

Sealing to the MRENCLAVE makes the key available to any instance on the same physical system having the exact same MRENCLAVE. This will not allow any future software to read secrets of this enclave. Sealing to MRSIGNER will make the key available to any enclave running on the same physical system which has been signed by the same author, making the upgrades much easier. This will allow newer enclaves to read secrets of older versions but will require clients to trust the enclave signer. This trust can be gained through a defined enclave audit process. Sealing keys are only known to an enclave, so that only an enclave can decrypt the data.