Attestation and the trustee service

note

Not every Codesphere instance offers confidential compute. Ask your Codesphere administrator whether confidential compute is available on your instance. See Prerequisites.

The confidential architecture keeps your data encrypted in use, in transit and at rest. The keys for that encryption must come from somewhere the platform cannot reach. With confidential compute, the whole platform infrastructure counts as untrusted. Trust comes from one place outside the platform: the trustee service. It only hands out keys and secrets to services that prove they run untampered on genuine hardware.

What is remote attestation

Remote attestation answers one question: is this a genuine, untampered TEE running exactly the software I expect? This prevents the operator from tampering with your application or swapping it for a modified version.

An attestation report contains:

• The measurement of the guest image
• The version of the CPU firmware and security patches (the trusted computing base)
• A fresh random value (nonce) from the verifier, which prevents replaying old reports
• A signature by a key that chains back to the hardware manufacturer

The verifier checks that:

1. The signature chains back to the manufacturer's root certificate.
2. The firmware is recent and not known to be vulnerable.
3. The measurement matches a value the policy allows.
4. The nonce matches the one it sent.

The verification is remote because it runs outside the host being verified. The host cannot fake the result, since it has no access to the signing key inside the CPU.

The trustee service

The trustee service is an independent party that lives outside the Codesphere instance. Neither the platform nor the infrastructure operator controls it. It has three jobs:

• Verify. It checks attestation reports as described above.
• Enforce policies. It decides which guest images, which service images or signing keys, and which minimum firmware versions are acceptable.
• Release secrets. It hands out disk encryption keys, service mesh identities and application secrets, but only to services that passed attestation.

Because secrets are only released after attestation, a service started on tampered infrastructure gets nothing. It cannot decrypt its volumes, join the mesh or read application secrets.

Learn more

Internally, a trustee service consists of several components with separate roles. These roles are defined by the IETF Remote ATtestation procedureS (RATS) architecture. For details, see RFC 9334 and the RATS architecture draft.

Codesphere does not ship its own trustee service. You connect your confidential services to a trustee service that runs outside the platform. See Preliminary steps for how to get access to one.

Attestation flow

A confidential micro-VM becomes trusted in two stages. First its environment is verified (steps 1 to 6). Then the VM verifies the service itself (steps 7 and 8). Inside the micro-VM, an attestation agent handles all communication with the outside world during startup.

Corresponding accessible text description

1. The untrusted infrastructure schedules the service on a host with confidential hardware. The host starts the micro-VM with a fixed guest image (firmware, kernel, initial ramdisk and attestation agent). The CPU measures the guest image before it runs. The measurement is a cryptographic hash, so the host cannot change the image without changing the measurement.
2. The attestation agent requests a nonce from the trustee service.
3. The attestation agent asks the CPU for an attestation report that includes the nonce. The CPU signs the report.
4. The attestation agent sends the report to the trustee service.
5. The trustee service checks the signature, firmware, measurement and nonce against its policy.
6. If the policy matches, the trustee service releases the keys and secrets the VM needs. The VM is now a trusted environment.
7. The attestation agent pulls the service image from the image registry and verifies its digest or signature.
8. The attestation agent starts the user workload with the image and the secrets.

When attestation fails, the service does not start and receives no secrets. Common causes are an unknown guest image after a platform update, outdated firmware on the host, or a service image that the policy does not allow.

The second stage is why the content of your service image matters. The VM only verifies the image it starts. Anything the service downloads later is not covered. See Recommendations for production.

Secret distribution

The trustee service includes a vault that stores the secrets of your confidential services. After a successful attestation, the trustee service releases these secrets to the micro-VM:

• Disk encryption keys. The guest uses them to unlock its LUKS volumes. See Encryption at rest.
• Service mesh identity. The certificate the proxy uses for mutual TLS. See Service mesh.
• Application secrets. Sensitive values such as database passwords or API keys that you stored in the vault of the trustee service.

The secrets go directly into the encrypted memory of the micro-VM. They never pass through the platform in plain text.

Workloads

In the confidential compute domain, a workload is a group of confidential services that work together, and therefore need access to the same secrets. For example, an application and its database both need auth credentials at runtime. The application uses them to authenticate against the database, and the database uses them to verify the authentication.

Each confidential service is executed under a workload ID, which must be provided when running it. Services that work together and need access to the same secrets have to share the same workload ID. At startup time, during attestation, the trustee service verifies it and uses it to decide which policy and which secrets apply.

Corresponding accessible text description

In this example, the application and the database share the ID payments, so they can communicate and have access to the same secrets. The second application uses the ID analytics, therefore has its own secrets namespace and cannot reach either of the other servers.