Intel SGX® Remote Attestation

1. Introduction

Remote attestation is a core feature of confidential computing that allows a user, let’s call her Alice, on machine A to receive a proof (quote) that machine B runs a specific piece of code in a trusted execution environment, the Intel® SGX enclave. If Alice audited the source code of the enclave and now wants to exchange confidential data with the enclave, she can use remote attestation to establish a secure communication channel with the enclave and start interacting with the enclave. The code executed inside the enclave, its working memory and sealed data are isolated by the CPU from any other software on machine B, so Alice can be sure that her data is processed in exactly the same way as she expects it from her source code audit.

The quote describes the identity and configuration of the target enclave, the Trusted Compute Base (TCB) of the platform (both software and hardware) running that enclave, and additional data associated with the enclave. Alice verifies this information to decide whether to trust the enclave. During the setup of the communication session, the quote works similarly to how the Public Key Infrastructure (PKI) is used in regular HTTPS secure session negotiation, except it is based on the building blocks of Intel® SGX. The quote contains a chain of signatures rooted in the root certificate owned by Intel®^[1], and the quote itself serves as a signature for the key material used in the key-agreement protocol^[2] for the secure session setup.

There are two types of remote attestation in Intel® SGX:

ECDSA attestation: The newer type and the way forward for remote attestation. Alice can download a set of certificates and additional data from Intel® and validate the proof from machine B herself.
EPID attestation: The original attestation variant but no longer supported by newer CPUs. Alice needs to ask a service hosted by Intel® whether a given proof from machine B is valid. It was designed to not leak the identity of the Intel® SGX machine to Alice.

2. ECDSA Attestation

With ECDSA Attestation Alice (or the host of the Intel® SGX application, etc) can occasionally download and cache a set of certificates and additional data from Intel® and use this to verify quotes. In comparison to EPID attestation, this solution removes the Intel® Attestation Service (IAS) from the runtime requirements of an Intel® SGX application, or in other words the availability of the Intel® SGX application is less dependent on the availability of the external services and live internet access.

The chain of signatures and the reason how Alice can trust each link is shown in the following image and explained in the following list. Alice received a quote from the remote Intel® SGX application and wants to verify it so she can continue with the key-agreement protocol. Therefore she uses an Intel® provided library to verify the trustworthiness of the quote.

Intel® SGX Root CA Private Key: This key is only known to Intel®. Alice trusts Intel® that they store this key in a secure way and use it only in the documented ways. It is used to sign the Intel® SGX PCK Processor CA Certificate (and more, but they are omitted here for brevity).
Intel® SGX PCK Processor CA Private Key: This key is only known to Intel®. Alice trusts Intel® that they store this key in a secure way and use it only in the documented ways. It is used to sign the Intel® SGX PCK Certificate.
Intel® SGX PCK Private Key: This key is derived from a Root Provisioning Key (RPK) which is both known to Intel® and securely stored in the CPU. Each CPU has its own unique RPK. Intel® knows each RPK exactly for the purpose of supporting remote attestation^[3].
The only enclave which can derive the Intel® SGX PCK Private Key from the RPK is the Provisioning Certification Enclave (PCE): The RPK can only be accessed indirectly through the Intel® SGX EGETKEY instruction. EGETKEY uses the RPK and the mrsigner value of the requesting enclave (and more) to derive a key which is handed to the enclave^[4].
A rogue enclave, i.e. not signed by Intel® and thus having a different mrsigner, could only derive some different private key. It can only use the RPK indirectly through EGETKEY which enforces the use of the different mrsigner value for the key derivation.
Alice trusts Intel® that they only release trustworthy enclaves which do not misuse the Intel® SGX PCK Private Key, and Alice trusts Intel® that they store their copy of the RPK in a secure way and use it only in the documented ways.
Attestation Private Key: This key is generated by and only known to the Quoting Enclave (QE). The Quoting Enclave Report which the PCE signs contains not only the Attestation Public Key, but also identity information of the quoting enclave, like mrsigner, mrenclave, isvprodid etc. These information were given to the PCE through the special Intel® SGX instruction EREPORT and are tamper-proof. Since Alice trusts the PCE, she also trusts these values and can either compare them against reference values provided by Intel®, or perform a source code audit of the QE.
Hence Alice trusts that the QE stores the Attestation Private Key in a secure way and uses it only in the documented ways.
Application Enclave Report: This report was generated in a similar way to the Quoting Enclave Report through the EREPORT instruction and signed by the QE whom Alice trusts. Alice can compare the contained mrsigner, mrenclave, isvprodid etc values against the known reference values which she received from trusted auditors, or perform a source code audit of the application enclave herself.
Hence Alice trusts that the key material was generated by the application enclave, and that the corresponding private key material is stored and used in expected ways as per the source code audit.

The quote format is shown in detail here in A.4. Quote Format.

3. EPID Attestation

EPID attestation uses a similar quote and a similar chain of trust, though it cannot be directly verified by Alice but needs to be sent to the Intel® Attestation Service (IAS) first. The IAS then issues an Intel®-signed Attestation Verification Report containing the original quote and its verification status. After that step Alice has again a chain of signatures, she knows the root certificate and can verify the application enclave identity and use the key material for further key-agreement.

The way how EPID attestation ensures that the identity of attested Intel® SGX machines does not leak to the attester is better explained in other places. Sharemind HI does not require this property.

The IAS is managed by Intel® and one requires a commercial license agreement to verify production mode enclaves.

4. Remote Attestation in Sharemind HI

Sharemind HI supports both attestation variants. Which one shall be used needs to be configured in the server configuration, the Sharemind HI Client does not need to be configured separately. Each variant has its own additional setup process (ECDSA, EPID).

The Sharemind HI Client performs remote attestation of the Attestation Enclave which is then used to extend the web of trust to the Core Enclave, Key Enclave and the Task Enclaves. Remote attestation can be invoked manually, or is otherwise by default performed transparently whenever no authenticated communication channel exists between the Sharemind HI Client and the Attestation Enclave. The Sharemind HI Server discards any client connections whenever a power transition event (e.g. suspend, hibernate or reboot) occurs.

For key-agreement we use the protocol as proposed by Intel®^[5], with the minor modification that the Sharemind HI Client itself does never talk to Intel® services directly, but gets any material (IAS response, ECDSA attestation collateral) from the Sharemind HI Server.

5. Session Creation

When the user has performed remote attestation of the Attestation Enclave, they can continue to create sessions with the core enclave, key enclave and task enclaves. The session creation uses a key-agreement protocol based on the SIGMA protocol (section 5.1) and then uses this to initialize libsodium’s secretstream.

1. In the case of EPID attestation the quote must be augmented by the IAS to complete the chain of signatures

2. In general the key material could be directly part of the Diffie-Hellman key exchange, or it could just be another key in the chain of signatures which will ultimately sign key material of the Diffie-Hellman key exchange. The former is used with the original Intel® SGX EPID attestation protocol, the latter is used in a newer integration of remote attestation and TLS.

3. Each Intel® SGX capable CPU has additional root key material which is not known to Intel® and used for other key derivations.

4. The PCE specific code is here, where the use of mrsigner is hard-coded for provisioning key as per Table 41-56. Key Derivation

5. For an analysis of the security of this key-agreement protocol you might refer to a similar protocol presented in the SIGMA paper section 5.1 "The Basic SIGMA Protocol".