Remote Attestation Overview

​

Introduction

Remote attestation is a security mechanism that allows Edge Infrastructure Services to verify that a node is in an expected, untampered state. It uses cryptographically signed evidence of the node’s hardware configuration, firmware, operating system, and running applications, validated using the Trusted Platform Module (TPM) built into the device. Remote attestation is a core security feature of EVE-OS (Edge Virtualization Engine) and is part of the zero-trust security model built into Edge Infrastructure Services.

​

Prerequisites

• A node with a TPM 2.0 implementation that provides a SHA-256 PCR bank. Discrete TPM chips and firmware TPMs both qualify. TPM 1.2 is not supported.
• A ZEDEDA enterprise with an attestation policy configured in the project.
• You have the SysAdmin role in your enterprise. See Manage Roles.

​

How It Works

​

The Trusted Platform Module (TPM)

The Trusted Platform Module (TPM) is a security component, implemented either as a discrete chip or in platform firmware, that performs cryptographic operations and stores keys in an isolated domain. The TPM cannot alter the system’s execution flow but plays a critical role in establishing trust. Key TPM functions used in remote attestation:

• Cryptographic key generation and protection. Keys are created inside the TPM and never leave it in plaintext.
• Hardware authentication. The TPM proves the identity of the device to Edge Infrastructure Services.
• Sealed storage. Secrets can only be read back if the system is in the same state as when they were sealed.
• Remote attestation. Generating cryptographically signed evidence of the system’s state.

EVE-OS keeps several TPM-backed keys and certificates for these functions. The device certificate identifies the node to Edge Infrastructure Services. The attestation (quote) key signs PCR quotes. The ECDH key derives shared secrets for encrypting sensitive configuration in transit. The endorsement key certificate, issued by the TPM manufacturer, proves the TPM itself is genuine. All of these are created at first boot and stored in the /persist/certs directory.

​

Measured boot

Measured boot is the process by which each layer of the boot sequence measures the next layer before it executes. Starting from firmware, each component (BIOS, bootloader, kernel) computes a hash of the next component and stores that hash in a Platform Configuration Register (PCR) in the TPM. This creates a chain of trust: if firmware is verified and trusted, firmware measures BIOS. If the BIOS measurements match expectations, BIOS is trusted. If EVE-OS is trustworthy, the application instances it launches are also trustworthy.

​

Platform Configuration Registers (PCRs)

PCRs are memory locations in the TPM with special properties:

• A PCR can only be extended (not overwritten). Extending adds a new hash value to the existing hash, producing a new combined value.
• The final PCR value captures the complete history of all measurements made in the same order.
• The result is deterministic. The same sequence of measurements always produces the same final value.

EVE-OS uses two key TPM operations to build attestation:

• PCR Extend: Measures each software layer and records the hash in the designated PCR.
• Seal: Encrypts a secret against the current PCR values. The secret can only be recovered if the PCR values are identical to when the sealing occurred. If the software state has changed, access is denied.

​

Attestation in Edge Infrastructure Services

Attestation can occur in two situations:

1. During onboarding as part of enrolling a new node into the enterprise.
2. By policy enforcement after onboarding, whenever an attestation policy is applied to a project.

​

Attestation policy enforcement

When an attestation policy is enforced on a project, each attestation cycle follows these steps:

1. Edge Infrastructure Services sends a fresh nonce (a random, single-use value) to the node.
2. The node asks the TPM for a quote: a statement of the current values of PCRs 0–15 in the SHA-256 bank, combined with the nonce and signed by the TPM’s attestation key. The node also sends the raw PCR values and the TPM event log so that Edge Infrastructure Services can trace how each value was built.
3. Edge Infrastructure Services verifies the signature using the node’s attestation certificate, confirms the nonce matches, and compares each quoted PCR value against the PCR template it holds for the node.
4. If the values match, Edge Infrastructure Services issues the node an integrity token and, if the node has requested it, returns the node’s encrypted vault key backup.
5. The node decrypts the backup with its own TPM and re-seals the vault key to its current PCR values.

The vault key backup held by Edge Infrastructure Services is encrypted with a key that exists only inside the node’s TPM. Edge Infrastructure Services cannot read the backup; it can only return it to the same device that created it. The integrity token is required for every subsequent configuration request. A node without a valid token receives an HTTP 403 response when it asks for configuration, which forces it back into attestation. This is what makes attestation enforcing rather than advisory: a node that fails attestation cannot receive new configuration or its vault key until the mismatch is resolved. If the PCR values do not match the template, Edge Infrastructure Services withholds both the integrity token and the vault key backup. The node cannot unlock encrypted volumes, so edge containers that depend on them cannot start. If the vault stays inaccessible beyond the timer.vault.ready.cutoff interval (300 seconds by default), EVE-OS reboots the node or places it in maintenance mode so that the failure is visible and recoverable.

​

Re-attestation after node changes

Whenever a software layer changes (for example, after an EVE-OS version update) the PCR values change. The node can no longer unseal its vault key locally, so it requests the key backup from Edge Infrastructure Services, which triggers a new attestation cycle. If the new PCR values do not match the existing template, attestation fails and the node cannot unlock its vault. To recover the node, upload a new PCR template that matches the updated software state. Edge Infrastructure Services issues the integrity token and returns the key backup after the new values are verified.

​

Attestation failure

Attestation continues to fail until a user uploads a matching template. If tampering occurred, the new PCR values will not match any template, and the node remains without an integrity token and without its vault key until a matching template is provided. A mismatch on a single PCR does not always mean tampering. Some platforms measure volatile data into certain indexes, most often PCR 1. For how to tell a legitimate change from a suspicious one, and what to do about it, see Excluded PCRs: Disk-Key Sealing vs. Attestation Template.

​

Offline re-attestation

If a node is unreachable from Edge Infrastructure Services and a reboot is performed, the node unseals the vault key directly from its TPM, provided the PCR values in the sealing policy have not changed since the key was last sealed. This allows the node to unseal its disk and continue operating without an active connection to Edge Infrastructure Services.

​

Next Steps