Attestation
Last updated
Last updated
An attestation report of an enclave is generated by invoking the EREPORT command and includes MRENCLAVE, MRSIGNER, the enclave's product ID, the enclave's SVN, the enclave's attributes from the enclave's SECS, and an optional 64-byte user data field for additional data. The CPUSVN's are also included in the report to remotely verify the TCB versions that the enclave is running on.
is used to authenticate two enclaves, A and B, running on the same Intel CPU. When A wants to authenticate B, the following steps are performed:
A sends it's MRENCLAVE to B over an untrusted channel.
B generates it's EREPORT and instructs the SGX hardware to generate A's report key by providing A's MRENCLAVE, which returns a message authentication code (MAC) that verifies the EREPORT. Note that A's report key is never known to B and remains in the CPU. B then sends the EREPORT and MAC to A.
After receiving B's EREPORT, A calls EGETKEY to get it's report key. Finally, A can verify the MAC with its report key and is convinced that B must be on the same CPU, since the RSK is known only to the CPU and is included in the key derivation process of the report key.
Since EGETKEY always includes the calling enclave's MRENCLAVE by extracting it from the SECS, B can't derive A's report key. Report keys do not include all the entries described in the Key Derivation table. The CPUSVN used in the KDF is provided by the CPU itself and includes all current versions.
\is SGX's current solution for remote attestation in a cloud environment. Intel SGX introduces two architectural enclaves for remote attestation, the Provisioning Certification Enclave (PCE) and the Quoting Enclave (QE).
During platform initialization, these two enclaves are provisioned locally. The PCE is a local CA that uses a Provisioning Certification Key (PCK) to issue certificates for the provisioning enclaves. This key is a 256-bit ECDSA key on the NIST-standardized p-256 curve. It is derived from the Intel SGX TCB SVN, the PCE ISVSVN, the RPK, and a Platform Provisioning ID (PPID) unique to the platform. By including the security numbers, security updates that fix vulnerabilities in the SGX (Intel SGX TCB SVNs) and in the PCE (PCE ISVSVN) are reflected in the PCK.
The first step is to send the encrypted PPID (see figure above) to the cloud provider's inventory management service (IMS). Encryption is done for privacy reasons since it identifies the platform. In DCAP, the IMS is used to store all used attestation identities (PPID) in encrypted form (step 2), to keep track of all attestation platforms, and to request PCK certificates from Intel (step 3). Intel's root CA identifies the platform by its PPID in the certificate request and the public PCK, verifies the requesting platform and running TCB versions by deriving the PCK, and issues a certificate to the PCE (Step 4). Note that this is possible because the RPK is stored in Intel's database. Because Intel has verified the TCB's SVN's, remote parties that verify the certificate chain can trust the specification in the PCE's certificate. Intel maintains a certificate revocation list for PCKs and publishes all issued certificates for PCE's. This creates a certificate infrastructure for PCE's. The issued certificate is stored in a database maintained by Intel (step 5). After the IMS retrieves the certificate, it is stored in a database (step 6) and provisioned to the requesting PCE. Each QE generates its own attestation key pair using the preferred EGETKEY algorithm, requests a certificate for the public part of the attestation key, and the PCE first authenticates the request via local attestation and then issues a certificate (SIGSTRUCT) signed by the PCK for the QE (Step 7). The attestation key is derived from it's sealing key and therefore survives CPU power cycles. Finally, the certificate infrastructure is complete and the QE is ready to sign certificate requests from user enclaves (Step 10). Before issuing a certificate to user enclaves, the user enclave is verified by local attestation. The MAC is then replaced with the QE's signature and the resulting report is then called a qoute.
DCAP builds the following chain of trust:
Intel Root CA Key → Provisioning Certification Key → Attestation Key → User Enclave Key
Verification of the trust chain by a remote party is done by checking all signatures in the certificates, checking that no key has been revoked, checking that all measurements of enclaves and all TCB versions match the expected values. Hence, Intel is the trust anchor and you have to trust Intel that the root CA is really only issuing certificates for Intel SGX enabled CPUs.