TEE and Remote Attestation

Trusted Execution Environment (TEE)

The Trusted Execution Environment (TEE), also known as Intel SGX (Software Guard Extensions), is a secure area constructed on a computing platform using both software and hardware methods. It ensures that the code and data loaded within this secure area are protected in terms of confidentiality and integrity. The primary goal is to ensure that a task executes as expected, guaranteeing the confidentiality and integrity of the initial state and runtime state.

Intel SGX specifically enhances the security of application code and data by allowing developers to encapsulate secure operations within a container called an Enclave. This safeguards critical code and data integrity and confidentiality. SGX supports proving the integrity and authenticity of a user program running within an Enclave to a challenger through remote attestation. The following diagram illustrates the remote attestation process in SGX.

Remote attestation using SGX involves three main entities:

The Service Provider (Challenger):
1. This is the entity providing the service or challenging the enclave.
The Application with Its Enclave and Its Quoting Enclave (QE):
1. The application contains the enclave and its quoting enclave responsible for generating remote attestation.
Intel Attestation Service (IAS):
1. IAS is responsible for verifying the enclave.

Remote Attestation Process

The ISV enclave (2) sends an initial request to the remote service provider (1), including the platform's claim that it is a member of its EPID group.
1. If the service provider (1) wishes to provide services for the declared group's members, it may request an updated SigRL from IAS.
2. Then, the service provider (1) constructs a challenge message, consisting of SPID, dynamic random nonce, updated SigRL, and an optional basename parameter (if pseudonymous signatures are needed).
The application (2) passes the challenge to its enclave (2).
If the enclave (2) supports the requested signing mode, it calls the EREPORT instruction to create a locally verifiable REPORT for the platform QE. To establish an authenticated secure channel between the enclave (2) and the service provider (1), the newly generated temporary public key is added to the user data field of the REPORT.
The application (2) passes both the REPORT and SP's challenge to QE (2).
(Local attestation occurs here) QE calls EGETKEY to obtain the REPORT KEY and verify the REPORT, determining if the enclave is running on the same platform. If successful, QE calls EGETKEY again to receive the platform's Provisioning Seal Key, which is used to decrypt the platform's remote attestation key (EPID private key).
1. The attestation key is then used to sign a challenge's basename or a random value, depending on the signing mode. If a non-random basename is used, the signature is pseudonymous; otherwise, it is fully anonymous.
2. Then, using the attestation key, the QE calculates two knowledge signatures on the platform's identity signature (MRENCLAVE). The first proves that the identity signature is signed by the Intel attested key. The second is an irrevocable proof that the key used for the identity signature is not listed in the challenged SigRL.
3. Finally, using IAS's public key (hard-coded in QE), the final QUOTE is generated and encrypted, then sent back to the application. The QUOTE contains the attested enclave's identity, execution mode details (e.g., SVN level), and other data.
The application forwards the QUOTE to the service provider for verification.
Since QUOTE is encrypted, only Intel can verify it. Therefore, the service provider (1) simply forwards QUOTE to IAS for verification.
IAS first verifies the EPID proof of the QUOTE's identity signature, checking the QUOTE.
1. Then, it verifies that the platform is not listed in the Priv-RL revocation list, by computing the signature of each private key in the Revocation List against the basename of the Quote and ensuring none of these signatures matches the identity signature of the Quote.
2. IAS then creates a new attestation verification report in response to the service provider (SP). The attestation verification report includes the platform's QUOTE structure generated for the attested enclave.
3. A positive attestation verification report confirms that the enclave runs a specific code snippet on a true Intel SGX processor. The SP is then responsible for verifying the ISV enclave's identity and providing the appropriate response to the platform.

PreviousPLONK Proof System NextRoadmap

Last updated 8 months ago

Trusted Execution Environment (TEE)

Remote attestation using SGX involves three main entities:

The Service Provider (Challenger):

This is the entity providing the service or challenging the enclave.

The Application with Its Enclave and Its Quoting Enclave (QE):

The application contains the enclave and its quoting enclave responsible for generating remote attestation.

Intel Attestation Service (IAS):

IAS is responsible for verifying the enclave.

Remote Attestation Process

The ISV enclave (2) sends an initial request to the remote service provider (1), including the platform's claim that it is a member of its EPID group.

If the service provider (1) wishes to provide services for the declared group's members, it may request an updated SigRL from IAS.
Then, the service provider (1) constructs a challenge message, consisting of SPID, dynamic random nonce, updated SigRL, and an optional basename parameter (if pseudonymous signatures are needed).

The application (2) passes the challenge to its enclave (2).

If the enclave (2) supports the requested signing mode, it calls the EREPORT instruction to create a locally verifiable REPORT for the platform QE. To establish an authenticated secure channel between the enclave (2) and the service provider (1), the newly generated temporary public key is added to the user data field of the REPORT.

The application (2) passes both the REPORT and SP's challenge to QE (2).

(Local attestation occurs here) QE calls EGETKEY to obtain the REPORT KEY and verify the REPORT, determining if the enclave is running on the same platform. If successful, QE calls EGETKEY again to receive the platform's Provisioning Seal Key, which is used to decrypt the platform's remote attestation key (EPID private key).

The attestation key is then used to sign a challenge's basename or a random value, depending on the signing mode. If a non-random basename is used, the signature is pseudonymous; otherwise, it is fully anonymous.
Then, using the attestation key, the QE calculates two knowledge signatures on the platform's identity signature (MRENCLAVE). The first proves that the identity signature is signed by the Intel attested key. The second is an irrevocable proof that the key used for the identity signature is not listed in the challenged SigRL.
Finally, using IAS's public key (hard-coded in QE), the final QUOTE is generated and encrypted, then sent back to the application. The QUOTE contains the attested enclave's identity, execution mode details (e.g., SVN level), and other data.

The application forwards the QUOTE to the service provider for verification.

Since QUOTE is encrypted, only Intel can verify it. Therefore, the service provider (1) simply forwards QUOTE to IAS for verification.

IAS first verifies the EPID proof of the QUOTE's identity signature, checking the QUOTE.

Then, it verifies that the platform is not listed in the Priv-RL revocation list, by computing the signature of each private key in the Revocation List against the basename of the Quote and ensuring none of these signatures matches the identity signature of the Quote.
IAS then creates a new attestation verification report in response to the service provider (SP). The attestation verification report includes the platform's QUOTE structure generated for the attested enclave.
A positive attestation verification report confirms that the enclave runs a specific code snippet on a true Intel SGX processor. The SP is then responsible for verifying the ISV enclave's identity and providing the appropriate response to the platform.