Featured Article

Shanwei Cen (@shnwc), Dan Middleton (@dcmiddle)

We’re excited to announce some recent attestation news. One of the hallmarks of confidential computing is the ability to build trusted communication with an application running in a hardware-based trusted execution environment. To make attestation easily accessible it can be incorporated into common protocols. That way developers don’t need to figure out all the details to build a secure protocol themselves. One of these protocols is called Remote Attestation TLS (RA-TLS), which builds on the ubiquitously used Transport Layer Security protocol underlying most secure internet communication. It turns out several projects independently implemented RA-TLS with tiny but incompatible differences. In the CCC Attestation SIG, we’ve agreed on and, in some cases, already implemented changes to make them all be able to interoperate.

The CCC Attestation SIG is chartered to develop attestation-related software aimed at improving interoperability, and to achieve harmonization and de-fragmentation between multiple projects. One approach is to identify and review projects in SIG meetings, propose improvements for interoperability and standardization, and work with these projects for implementation and tests. Interoperable RA-TLS is a great example showcasing how the SIG delivers on its charter.

RA-TLS (Remote Attestation TLS) architecture is defined in the white paper Integrating Remote Attestation with Transport Layer Security, to enable Intel® Software Guard Extensions (Intel® SGX) remote attestation during the establishment of a standard Transport Layer Security (TLS) connection. In a TLS server / client scenario, the TLS server runs inside an SGX enclave. It generates a public-private keypair, creates an SGX report with a hash of the public key in its user-data field, and gets an SGX quote for this report. It then creates an X.509 certificate with a custom extension containing this SGX quote. This customized certificate is sent to a TLS client in the TLS handshake protocol. The client gets the SGX quote from the certificate and performs remote attestation to verify that the connected server runs inside an authentic Intel® SGX enclave.

There are a few aspects of RA-TLS architecture that were not covered in this white paper. Some of the gaps include the specific X.509 extension OID value for the SGX quote, the supported types of SGX quote, and how the public key is hashed. Additionally, since the white paper was published, new TEEs like Intel® Trust Domain Extensions (Intel® TDX) and new quote formats have become available. The level of specificity in the RA-TLS paper left room for incompatibility between different implementations and prevented their interoperability.

RA-TLS has been supported in multiple open-source projects, including Gramine, RATS-TLS, Open Enclave Attested TLS, and SGX SDK Attested TLS. The CCC Attestation SIG invited these projects to its meetings for review, and recommended further investigation to look into harmonization between them for interoperability. Following up on this recommendation, we conducted an in-depth investigation and identified areas of incompatibility. We documented our findings, created a draft proposal for an interoperable RA-TLS architecture, and presented our work back to the SIG.

Based on the interoperable RA-TLS draft proposal, we refined the design, and aligned it with the upcoming DICE Attestation Architecture v1.1 draft standard on X.509 extension OID value and evidence format definition (as a tagged CBOR byte string). We created an CCC Attestation SIG github project interoperable-ra-tls to host the design documents and interoperability tests. This project also facilitates discussion among members of the RA-TLS projects and the CCC Attestation SIG community in general. In addition, we registered the needed CBOR tags with the IANA registration service. In the process, we provided feedback to the DICE Attestation Architecture workgroup for refinement of their draft standard specification.

Great progress has been made to implement this proposed interoperable RA-TLS scheme in the RA-TLS projects. We’ve worked with all the projects to create issues and pull requests for their implementations. Especially, as discussed in some of the interoperable-ra-tls project issues, Gramine and RATS-TLS have completed their implementation, and have been active in interoperability tests.

In summary, the interoperable RA-TLS work demonstrated the value of the CCC Attestation SIG in providing a constructive forum to collaborate on attestation technology. We invite you to try out the new unified implementations in Gramine and RATS-TLS. If you are interested in getting more involved, please join us at the CCC Attestation SIG or any other facet of our Confidential Computing Consortium open source community. All are welcome here.