Tutorials

Learn about using Nitride to attest a workload

These tutorials provides a conceptual overview of setting up and executing attestation using the Nitride API and the vhsm tool. It involves: 1. Configuring Attestation 2. Performing Attestation

Drawing
Attestation Process

Configuring Attestation

This phase involves defining what you consider trustworthy and how that trustworthiness should be verified.

  1. Define Identities: "What to Attest"

You start by defining "identities." These are essentially trusted baselines or fingerprints of components that make up your workload such as a specific firmware version, or a hash of your application code. You register these known-good values with the attestation service.

  1. Create Policies: "How to Attest"

You create policies. A policy is a set of rules that specifies which identities what you defined must be present and what criteria they must meet for an attestation to be considered valid. Policies also indicate the "provider" or the specific attestation technology, like AWS SEV-SNP or Azure vTPM that will be used.

  1. Register Your Workload: "Linking Workload to Policy"

You create an attestation record for your specific workload. This record links your running workload to a specific policy that governs its attestation verification. This is how the service knows which rules to apply when your workload sends its report.

Performing Attestation

This phase involves the running workload interacting with the attestation service to prove its trustworthiness.

The workload, leveraging its integrated hardware security module such as a virtual TPM, takes cryptographic "measurements" of its current state such as loaded firmware, operating system components, application binaries. It then incorporates the nonce received and cryptographically signs this entire data set using its unique, hardware-protected keys. This signed package is the "attestation report."

The generated attestation report is sent by the workload or a client on its behalf to the Enclaive attestation service for verification.

The attestation service receives the report. It first validates the report's cryptographic signature to ensure its authenticity. Then, it compares the measurements and other claims in the report against the rules defined in the policy linked to that specific workload .

Result:

  • If the report successfully verifies against the policy, the service issues an authentication token. This token serves as a cryptographically backed proof that the workload is in a trusted state and can be used to authorize access to other resources.

  • If the verification fails such as measurements don't match, signature is invalid, or nonce is incorrect, an error message is returned.

Last updated

Was this helpful?