Home
Documentation Tutorials

Attestation

In this article we introduce the basic concept of remote attestation.

Introduction

Have you asked yourself how to verify through the Internet the fact that workload runs indeed in the enclave? You can't go to the datacenter, knock on the door, and scrutinise the servers providing workload. With confidenital computing, security processors have the capability to act in the role as attestors/auditors and measure the workload.

Each processor has a certified identity from the CPU manufacturer what allows to verify if the security processor is trusted. The CPU audits the workload by measuring the integrity of the workload and issues the attestation report. Technically the enclaivelet shim retrieves the attestation report and sends it to Nitride for validation.

What is Attestation?

In the context of computer security attestation refers to the process of verifying the trustworthiness of a platform or system. It's essentially a way for one entity to gain confidence that another entity is genuine and operates as expected.

Here's a breakdown of the attestation process:

  1. Establishing a Root of Trust: There needs to be a starting point, a trusted entity that everyone can rely on. This could be a cryptographic key held by a trusted manufacturer or a pre-installed security module on the device.

  2. Building a Chain of Trust: Using cryptography, the root of trust signs other keys or pieces of information. These signed elements become trusted because of their connection to the verified root. This creates a chain of trust where each link verifies the one below it.

  3. Verification by the Requesting Entity: The entity seeking to verify the platform obtains the public keys or certificates associated with the chain of trust. It then cryptographically verifies the signatures, working its way back to the trusted root.

By successfully completing this verification, the requesting entity gains assurance about the platform's trustworthiness.

Nitride Attestation Framework

Attestation protocols can vary depending on the security processor, the CSPs implementation and the desired statement of security. However, the core principle remains the same: establishing a chain of trust that allows entities to verify the authenticity and trustworthiness of a platform.

Drawing
Nitride attestation protocol flow

The Nitride attestation works as follows:

  • The compute provider registers the security processor with the CPU vendor's CA (1).

  • As part of the boot process the enclaivelet is loaded. The enclaivelet is an attestation shim, enabling to interact with the security processor and other trusted devices (e.g., vTPMs, HSMs) and meta services (e.g. CSP meta APIs) to create the attestation report (see below).

  • The enclaivelet connects to nitride (2) and executes a remote attestation (3-4): it receives a challenge from nitride and generates for this challenge the attestation report. The report comprises measurements of the integrity of the TCB, optionally of the enclave code base along some identity information of the platform. The report is signed by an attestation key which is either linked to the security processor or the cloud service provider, and rooted in the PKI of the CPU manufacturer.

  • Nitride issues an auth token granting access to third-party services, such as key management. See use case attested secret provisioning.

Attestation report

As of today, there exists no standard for attestation. Every CSP implements its own variant of remote attestation, leveraging different security processor technologies. Some example reports can be found in the table below.

```json
{"Version":1,
"Source":"kraud",
"Protocol":"sev-snp",
"Instance":"test-instance",
"Attestation":
{
"Version":1,
"Product":"Milan",
"Report":"AgAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAAAGcwEAAAAAAAAAAAAAAAAAAAAOdBorIj5QCum1MOTHf43Iy/ilbsByh8hu0+V8t5MAxiVKtoH520qZEG5vj46nsO4Sv8ziA49cUDLSoBav3cn1bc7o2ZATFLV+WbWmxZTVKCI3lVIcdayxtUWkBWOy/QTLPtgpvTxTXQ23oVPw8JfUF37i4SEFnyyhRfoQVFWJhMtk65eHY34se2tOl2ZhLgsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADVV2PIaZ/3Fof68FRaxVMwo10ncdTlbIJB0wS0jbW/Mv//////////////////////////////////////////AgAAAAAABnMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiZrNBWrlyze8u+gVEwzX165v4K9Qla6nb1lovEfuIX862sA5N4nP6aY/Dk8zS3f88veK0j9Vr02bo+X/N/Vp1AgAAAAAABnMDMwEAAzMBAAIAAAAAAAZzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1wgUTI/UcwHd/Cd+BK+zAk+JHG6lYbroQvmMyaGBfsP02z46p/P83PxmZBk3WnJRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjZpvd96gbS1WUjX3OhWBAwACPWi5EXK1Q/UZuo1ijYVIBtcDo2t4txDefhBs+Q9GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"Data":"eyJOb25jZSI6ImRHVnpkQzF1YjI1alpRbz0iLCJDb25maWciOnt9fQ=="}
}
```

Last updated