Understanding Attestation Process in a Confidential Computing Solution
In my previous blog, I touched up the subject of understanding a confidential computing solution.
In this blog, I’ll dive deeper into the attestation process. Attestation is the process that answers the following essential question in confidential computing — “How to be sure the application is running securely in a Trusted Execution Environment (TEE)?”
Simply put, attestation is how one software environment proves that a specific program is running on particular hardware.
In the context of confidential computing, attestation is about proving the trustworthiness of the TEE. It proves which set of software layers are running on the TEE.
The attestation can be initiated by the TEE environment when it loads, and you can get a detailed report. Further, your application running in the TEE can perform attestation, establish a secure channel and retrieve the secrets by using the tooling available for specific TEEs.
As defined by IETF Remote Attestation Procedures Architecture (RATS), there are two models.
I’ll use the “Backgroud check” model to explain the process. The “background check” model also forms the basis of attestation in the CNCF confidential containers project.
The following diagram shows the different components in the attestation workflow using the “background check” model of the IETF Remote Attestation Procedures (RATS) workflow.
Source: https://ietf-rats-wg.github.io/architecture/draft-ietf-rats-architecture.html
Following are the key players in the attestation process:
Attester — The Attester is the entity which informs the relying party of the state of the system by sending evidence. The evidence informs the relying party about the state of the system, the Trusted Computing Base (the part of hardware, firmware and software that is trusted) and other aspects of the system. The evidence comprises a set of claims, later asserted or denied by the verifier. The evidence is cryptographically signed with a key (e.g. coming from the silicon vendor) that is used during the verification process.
If you are looking for a deep dive into the attestation flows and how they differ between different vendors, I would recommend reading this paper — https://systex22.github.io/papers/systex22-final79.pdf
Relying Party/Key Broker Service (KBS) — The KBS is the relying party and the following are its primary function:
- Receives evidence from the attester (confidential VM or container) via challenge-response protocol
- Relay the evidence to the Attestation Service (Verifier) for verification.
- Apply appraisal policy for the returned Attestation Results to assess the trustworthiness of the attester.
- Interact with Key Management Service to retrieve the keys and send them to the attester
Verifier (Attestation Service) — The Attestation service verifies the evidence, based on configured policy and reference values. Think of reference values as “good” and “trusted” values which are known beforehand and used for verification of the evidence sent by the attester. These reference values are typically generated when building the system software and firmware layers, through a coupled CI/CD pipeline.
Key management service — A service for securely storing, managing, and backing up cryptographic keys used by applications and users.
I hope this helps you to get an idea of one of the critical aspects of confidential computing technology. If you want to read more about RATS and its different models, the following doc is a good read.
If you want to get involved in the development of the remote attestation procedure for confidential containers, here are a few links to get started.
As we head towards the first release of the confidential containers project, one of the goals is to make it easier for developers and early adopters to experiment and evaluate the technology. Would love to hear your feedback on the scope of the release.
I would also like to thank Samuel Ortiz; without his help, this blog wouldn’t have been possible.
