Demystify Remote Attestation: Explore the DCAP Certificate Chain
06/15/2022
PreviousMPC 101: Secure Multi-Party Computation And MultisignatureNextBitcoin Taproot Upgrade: Changes to Transaction Privacy
Last updated
06/15/2022
Last updated
By Gavin
Remote attestation can have the verifier to distinguish the software logic of verified Trusted Execution Environment, to see if the code is modified or tampered with. Generally, in remote attestation, the party to be attested will generate one certificate via trusted hardware and the certificate contains one report. This report illustrates the metrics of the software code currently running in the Trusted Execution Environment. Vefirier can verify the validity of the certificate to see whether the software process on the trusted hardware has been modified.
Intel® Software Guard Extensions Data Center Attestation Primitives (Intel® SGX DCAP) provides SGX attestation support targeted at data centers, cloud services providers and enterprises via elliptic curve digital signature algorithm (ECDSA) to protect keys, isolate encrypted modules, confidential computing, etc. For example, verify key is generated in TEE which is against key leakage, and the authorized deployment of platform services to validate whether running services are valid or not. Safeheron trusted policy engine is integrated with DCAP to make sure every policy is executed in TEE and cannot be tampered with.
One of the strengths of Intel® Software Guard Extensions Data Center Attestation Primitives (Intel® SGX DCAP) is that it allows data centers to own their attestation infrastructure. The attestation collateral needed to both generate and verify quotes is contained completely on premise, which eliminates runtime dependencies on external services and enables trust decisions to be made in-house. Attestation collateral including TCB Information, Certificate Revocation Lists and QE/QVE Identities. The essence of having this strength is that there’s a complete certificate chain that connects the whole attestation system, from beginning to end, to verify the identity of the data owner making sure that no data is tampered with.
Certificate Chain is introduced to solve the risk of leakage caused by having root certificate issues user certificate. If the private key of the root certificate is leaked, then it will affect all user certificates signed by this root certificate with very serious security risks following. So, to avert security risks of root certificate, the certificate authority (CA) adopts a root certificate to sign the intermediate certificate. An intermediate certificate is used to sign the user certificate. Even if something goes wrong with the intermediate certificate, the wrong intermediate certificate can be abandoned for the security of the root certificate while scaling down the scope of associated user certificates, from all to partial. In short, the certificate chain consists of a root certificate, intermediate certificate(s), and user certificate(s). Only when every certificate on the certificate chain is valid, the corresponding service will then deem the current certificate for the user valid and trusted.
Certificate Chain Structure in DCAP
Several typical elements from the above:
Root CA Certificate: Root Certificate, issue Intel® SGX-related certificates
PCK Platform CA Certificate: Intermediate Certificate, issue Intel® SGX PCK certificate and its corresponding revocation list for multi-package platforms
PCK Processor CA Certificate: Intermediate Certificate, issue Intel® SGX PCK certificate and its corresponding revocation list for single-package platforms
PCK Certificate: User Certificate, sign Intel® SGX TCB data for Intel platforms (both multi-package and single-package)
Here’s the clear relationship among certificates on the certificate chain:
Root CA —> PCK platform/Processor CA（Intermediate）—> PCK Certificate
Root certificate issues the intermediate certificate and the intermediate certificate issues the user certificate.
Testing Examples (Testing Data by Intel® )
Root Certificate: Intel SGX Root CA Certificate Revocation List (CRL)
$ openssl crl -inform PEM -text -noout -in rootCaCrl.pem
Intermediate Certificate: PCK Processor CA Certificate Revocation List (CRL)
$ openssl crl -inform PEM -text -noout -in intermediateCaCrl.pem
User Certificate: PCK Certificate signed by Intel® SGX Processor CA
$ openssl x509 -in pckCert.pem -text -noout
Intermediate Certificate: PCK Processor CA Certificate
$ openssl x509 -in pckSignChain.pem -text -noout
A root certificate is the start of the certificate chain which is the self-signed certificate generated by Intel®. In other words, all data of the certificate chain, in the end, count on the root certificate. If an error is found in the process of traceability verification on trustworthiness, it means that the data is currently untrusted and vice versa.
View Certificate Info
$ openssl x509 -in IntelSGXRootCA.crt -text -noout
See below
First, we need to make some concepts clear:
Issuer: Certificate authority
Subject: Certificate owner
Subject Public Key Info: The public key for the certificate owner
X509v3 Authority Key Identifier: The only identifier for the corresponding public key of the certificate’s private key
X509v3 Subject Key Identifier: The only identifier for the public key of the current certificate
Four points to be noted from the above pic:
Issuer is the same as Subject
Issuer: CN = Intel SGX Root CA, O = Intel Corporation, L = Santa Clara, ST = CA, C = US
Subject: CN = Intel SGX Root CA, O = Intel Corporation, L = Santa Clara, ST = CA, C = US
It shows that the certificate authority and certificate owner are the same entity, that’s to say, the certificate is the self-signed certificate generated by Intel®. It’s a root certificate, so it’s unconditionally trusted.
The Authority Key Identifier in the root certificate is the same as the Subject Key Identifier
X509v3 Authority Key Identifier:
22:65:0C:D6:5A:9D:34:89:F3:83:B4:95:52:BF:50:1B:39:27:06:AC
X509v3 Subject Key Identifier:
22:65:0C:D6:5A:9D:34:89:F3:83:B4:95:52:BF:50:1B:39:27:06:AC
Two Key IDs are the same, as the above Issuer and Subject, which again verifies the root certificate is an Intel® self-signed certificate.
Relationship between Certificate Revocation List and Root Certificate
View CRL (Certificate Revocation List)
$ openssl crl -inform PEM -text -noout -in IntelSGXRootCA.crl
X509v3 Authority Key Identifier:
22:65:0C:D6:5A:9D:34:89:F3:83:B4:95:52:BF:50:1B:39:27:06:AC
Authority Key Identifiers for the IntelSGXRootCA.crl and the IntelSGXRootCA.crt are the same. So, the two certificates are published by Intel® and can verify each other.
Public Key for the Private Key of Root certificate
As shown in the Root Certificate picture above：
We can see the code below from Intel® SGX open source code.
The QVE Encalve is used for Intel® verifying signature that two pubic keys are the same. Now we can tell that Intel® uses Root Certificate for DCAP.
We can use Intel® SGX Provisioning Certification Service (PCS) or Intel® SGX Provisioning Certificate Caching Service (PCCS) API to obtain corresponding certificates.
PCCS and PCS are essentially the same things. Both store certificates and hardware-related information, but PCCS can be built on the cloud, locally, or on a local area network, which is more convenient for users.
The above shows verification logic and relationship. The subordinate certificate has the DN (Distinguished Name) of its superior certificate. During authentication, each level will index the superior certificate through the DN, and use the public key of the superior certificate to verify whether the signature of the inferior certificate is correct. If there are multiple intermediate certificates, traceability verification will be implemented from the bottom up. Since the self-signed root certificate has been built into the operating system and is the root certificate trusted by the system, the verification can be completed when the root certificate is reached, and thus a complete chain of trust is formed.
Parts of Intel® open source code are shown below
The process is as follows:
Extract the PCK Cert chain from the given quote
Extract root CA from PCK cert chain in quote
Verify the public key of the root certificate
According to the DN and other information from local to remote to carry out layer-by-layer authentication
https://api.portal.trustedservices.intel.com/provisioning-certification
https://download.01.org/intel-sgx/sgx-dcap/1.10/linux/docs/SGX_DCAP_Caching_Service_Design_Guide.pdf
https://www.zhaohuabing.com/post/2020-03-19-pki/
https://github.com/intel/SGXDataCenterAttestationPrimitives
