In confidential computing environments, attestation is crucial in verifying the trustworthiness of the location where you plan to run your workload or where you plan to send confidential information. Before actually running the workload or transmitting the confidential information, you need to perform attestation.

This blog provides an overview of the components implemented in the confidential containers (CoCo) to support the IETF RATS model (Remote ATtestation procedureS Architecture). The components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH). The AS, KBS, and RVPS components are part of the Trustee project, whereas the AA and CDH are part of the guest-components project in CoCo.

We begin by introducing the RATS model and its components. After that, we discuss the Trustee project, its various components, and how they relate to the RATS model. Finally, we present a few use cases that demonstrate the usage of the CoCo Trustee and guest-components project.

RATS architecture and key components

The key components in the RATS architecture are described in the following diagram:

• Attester - provides Evidence, which is evaluated and appraised to decide its trustworthiness (for instance, a test to see whether it’s authorized to perform some action). Evidence may include configuration data, measurements, telemetry, or inferences.
• Verifier - evaluates the validity of the evidence received from the attester and produces attestation results, which are sent to the Relying party. Attestation results typically include information regarding the Attester, while the Verifier vouches for the validity of the results.
• Relying party - depends on the validity of information originating from the attester for reliably applying an action. This information can come from the verifier or directly through the attester.
• Relying party owner - authorized to configure the appraisal policy that the relying party will use when receiving the attestation results (such as admin).
• Verifier owner - authorized to configure the appraisal policy the verifier will use when receiving the evidence.
• Endorser - for us, the hardware manufacturer who provides an endorsement, which the verifier uses to validate the evidence received from the attester. The endorsement is a secure statement the Endorser vouches for on the integrity of an Attester's various capabilities
• Reference Value Provider - for us the hardware manufacturer who provides reference values, which the verifier uses to verify that claims were recorded by the attester. Reference values are, for example, golden measurements or nominal values.

In practice, the data flow between the verifier, attester, and relying party can be done through the passport check model and background check model.

Passport check model

In the passport model, the attester validates an identification token with the verifier. It then presents the identification token to the relying party. It's a similar process to when you present your passport at an airport to confirm your own identity when entering a country.

In this model, the attester requests the passport from the verifier by providing evidence and receives a passport in the form of attestation results. It can now interact directly with the relying party by presenting its passport (attestation result).

The following diagram shows this flow: 

Background check model

In the background check model, the relying party asks for verification each time the attester presents its evidence. This is similar to performing a full background check on an individual every time the individual enters a country.

The attester provides evidence to the relying party, which forwards it directly to the verifier. The verifier compares the evidence with the appraised policy it contains, and returns an attestation result to the relying party. The relying party compares the attestation results with its own appraisal policy.

Unlike a passport model, where the attester sends attestation results to the relying party, the background model requires the attester to send the relying party evidence (which is sent as-is to the verifier).

The following diagram illustrates the background check model:

The Trustee project

The trustee project (previously known as CoCo KBS) includes components deployed on a trusted side and used to verify whether the remote workload is running in a trusted execution environment (TEE). It also verifies that the remote environment uses the expected software and hardware versions.

This diagram shows the architecture for the Trustee model:

The left side includes the guest components running inside the TEE, including the Attestation Agent (AA) and Confidential Data Hub (CDH). The right side includes the external components, which the guest components interact with, such as the Key Broker Service (KBS), Attestation Service (AS), and the Reference Value Provider Service (RVPS).

Trustee and guest components

Key Broker Service (KBS)

The Key Broker Service (KBS) facilitates remote attestation and managing and delivering secrets. Equating this to the RATS model, the KBS is the relying party entity. The KBS, however, doesn’t validate the attestation evidence. Instead, it uses the attestation service (AS) to verify the TEE evidence.

Attestation Service (AS)

The Attestation Service (AS) is responsible for validating the TEE evidence. This includes evidence from the following TEEs: Intel TDX, Intel SGX, AMD SEV-SNP, ARM CCA, Hygon CSV, and more.

When mapped to the RATS model, the AS is the equivalent of the verifier.

The AS receives attestation evidence and returns an attestation token containing the results of a two-step verification process. Note that the KBS is the client of the AS, however the evidence originates from the attestation agent (AA).

The following diagram shows the AS components:

The AS runs the following verification process:

1. Verify the formatting and the origin of the evidence - for example, checking the signature of the evidence. This is accomplished by one of the platform-specific Verifier Drivers.
2. Evaluate the claims provided in the evidence - for example, validating that the measurements are what the client expects. This is done by a Policy Engine with help from the RVPS.

Verifier driver

A verifier driver parses the attestation evidence provided by the hardware TEE. It performs the following tasks:

1. Verifies the hardware TEE signature of the TEE quote and report provided in the evidence
2. Receives the evidence and organizes the status into a JSON format to be returned

Policy Engine

The AS allows users to upload their own policies when performing evidence verification. When an attestation request is received by the AS, it uses a policy ID in the request to decide which policies should be evaluated. The results of all policies evaluated are included in the attestation response.

Reference Value Provider Service (RVPS)

The reference value provider service (RVPS) is a component in the AS responsible for verifying, storing, and providing reference values. RVPS receives and verifies inputs from the software supply chain, stores the measurement values, and generates reference value claims for the AS. This operation is performed based on the evidence verified by the AS.

The following diagram shows the RVPS components:

RVPS contains the preprocessors, extractors, and store components:

Preprocessors

These are plugins that preprocess the reference value registration messages before sending it to extractors.

Extractors

These are plugins that process different types of provenance in the input message. Each plugin consumes the input message, and then generates an output Reference value.

Store

The store component provides persistent storage for the reference values.

Attestation Agent (AA)

The Attestation Agent (AA) is the entity running inside the TEE that connects to the KBS in order to perform attestation.  AA is responsible for sending the evidence (claims) from the TEE to prove the trustworthiness of the environment.

Confidential Data Hub (CDH)

The Confidential Data Hub (CDH) facilitates secure key retrieval for kata-agent and applications. It also provides additional services, such as secure mount for external storage or key management client services to retrieve keys directly from external Key Management Services. The secure mount service enables mounting of encrypted storage inside the TEE. We'll cover the secure mount service in a subsequent blog.

The following diagram shows the CDH components:

Resources for learning about the attestation flow

For an overview of attestation, read our Learn about Confidential Computing Attestation blog series.

For details on attestation flow in confidential containers, read our Understanding the Confidential Containers Attestation Flow article.

For a step-by-step flow of confidential containers attestation on Azure cloud, read our Confidential Containers on Azure with OpenShift: A technical deep dive article.

Mapping Trustee components to the RATS model

This is how the RATS model maps to the Trustee components model:

Note the following:

• The Attester functionally is performed by the AA and CDH guest side components.
• The Verifier is mapped to the AS.
• The Relying party is mapped to the KBS receiving attestation results from the AS, and performing actions based on the results.
• The Endorser usually originates from the platform manufacturer (Intel, AMD, IBM, and so on), so it can be the manufacturer itself or a CSP that got endorsed by the hardware manufacturer.
• The Reference Value Provider is mapped to the RVPS and provides the endorsed reference. Note that reference values do not originate from the hardware manufacturer, but rather they reference measurements of the kernel, firmware image, and so on. They are trusted artifacts meaning signed by an identity you can trust and are used for performing the verification.
• The Verify owner and Relying Party owner are the entities who operate the KBS and AS on the user's behalf.

Background check model

The background check model is a common way to configure the KBS and AS components, so we present it before the passport model. The following diagram shows the model: 

In this model, the AA communicates with the KBS providing the hardware evidence and the KBS communicates with the AS to verify it. After the evidence is verified, the KBS releases the secrets back to the CDH when requested.

In background check mode, the KBS is the relying party, the AS is the verifier, and the AA is the attester.

Passport model

In the passport model, the validation of evidence and provisioning of resources are typically handled by  different KBSes. The following diagram shows the model: 

We now have 2 KBS entities:

• The first KBS, with the AS, verifies the evidence from the guest.
• The second KBS provides secrets to the guest.

The AA interacts with upper KBS + AS (Trustee 1) in order to attest, verify the evidence, and receive a token (a passport). It then requests the secret resources from the lower KBS (Trustee 2).

In practice, we recommend using the passport model when the attestation and resource provisioning are handled by separate entities.

Attestation use cases leveraging Trustee components

There are many use cases that can leverage the Trustee and guest components. For simplicity, we focus on the background check model (a single KBS) and not the passport model (with two KBS entities).

Attestation for virtual machines (VMs) and their workloads

Confidential VMs (CVMs) leverage hardware-based security features, such as AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) or Intel TDX (Trust Domain Extensions) to provide a secure execution environment for sensitive workloads. These VMs confirm that code and data remain encrypted and isolated, even from other privileged softwares on the host system. However, validating the integrity of these VMs and their underlying hardware is critical to guaranteeing the confidentiality and security of the data that is processed.

For a detailed description of confidential VMs, read our Learn about Red Hat Confidential Virtual Machines blog series.

VM attestation verifies the integrity of a confidential VM and its underlying platform components, including the CPU, firmware, and hypervisor. The attestation process might be initiated by the firmware or initrd.

From a trust perspective, you need assurance that the VM you just created on a public cloud is really a CVM with an operating system of your choice. In particular, you need to make sure that the host hasn’t started a non-confidential VM with a specially crafted guest operating system to steal your secrets instead.

The following diagram shows the overall architecture for VM attestation: 

Note the following:

• The CVM can run over a KVM hypervisor, some other hypervisor on bare metal or on a public cloud provider infrastructure.
• The AA works with the Trustee AS.

Here is a list of Trustee and guest components being used:

Attestation for a confidential containers workload

Moving from the VM level attestation to a container level attestation, let’s focus on container workload the user wants to run in a secure manner protected from the host.

Attestation for confidential containers verifies the container runtime stack running in the confidential environment. This includes kata-agent, supporting services like agent-protocol-forwarder, process-user-data, open policy agent, and default policies that are needed to run the container.

If the confidential containers are using the VM trusted execution environment, then the attestation includes attestation of the VM followed by attestation of the container runtime components. This diagram shows the overall architecture for confidential container attestation: 

Note the following:

• Peer-pods are used for running confidential containers over VMs (on-prem and public cloud). For additional details, read Deploying confidential containers on the public cloud
• The trustee model is used twice in this case to attest the CVM and then attest the confidential container runtime components

Here's a list of Trustee and guest components being used:

Attestation to retrieve container image signing or decryption keys

This use case is specific to obtaining the key for signature verification of a signed container image or obtaining the decryption key for encrypted images. For example, you might use encrypted container images to ship proprietary or sensitive code, such as AI models.

If the confidential containers are using the VM trusted execution environment, then the attestation process begins with VM attestation to confirm the integrity of the underlying execution environment. Once the VM's trustworthiness is established, container attestation proceeds, confirming the authenticity and integrity of the container runtime components. After a successful attestation, the container runtime requests the key from the Key Broker Service (KBS) for signature verification or decryption of the container images before starting the application.

The following diagram shows the overall architecture for retrieving the container image signing or decryption keys:

The attestation process is similar to attesting a confidential container workload, with the extra step of CDH retrieving the signing or decryption key that gets used by the kata-agent for signature verification or decrypting the container image.

This is a list of Trustee and guest components being used:

Attestation for releasing application secrets

This use case is specific to obtaining the key used by the workload. An example use case for obtaining the key is Data Clean Rooms. 

A number of organizations want to analyze data without compromising the privacy of individuals whose data is being analyzed (a joint bank fraud detection effort, for example). They're required to create a shared secured environment for data leaving the boundaries of those individuals. They would also want that environment to run in the cloud at scale. This can be accomplished by a secure key release where the data decryption key is only released to a specific TEE based on attestation.

The following diagram shows the idea: 

If the confidential containers are using the VM trusted execution environment, then the attestation process begins with VM attestation to ensure the integrity of the underlying execution environment. Once the VM's trustworthiness is established, container attestation proceeds, confirming the authenticity and integrity of the container runtime components. After a successful attestation, the container runtime starts the application.

The application then starts another attestation sequence to request the application secret from the Key Broker Service (KBS).  Confidential Data Hub (CDH) is used to request the application secret from the KBS by initiating an attestation sequence to prove the trustworthiness of the environment.

The following diagram shows the additional step of obtaining the application secret:

Note the following:

• The attestation process is similar to attesting a confidential container workload, with the extra step of CDH retrieving the application secrets and providing it to the application
• If the container images are signed or encrypted, then first the signing or decryption key is fetched (as described in the previous use case), followed by the application secret retrieval by CDH

Here's a list of Trustee and guest components being used:

Trustee project and confidential computing

In this blog we have introduced the Trustee project which is part of the confidential containers CNCF initiative and includes a number of services providing attestation capabilities for containers, VMs, shared keys and more.

We’ve covered the IETF RATS model, reviewed the Trustee components and showed the mapping between Trustee and the RATS model. We’ve also reviewed a number of use cases requiring attestation and presented how the Trustee components are used for those purposes.

In future blogs, we'll dive deeper into the Trustee projects looking at the technical details and hands on instructions on how to try out things.