Trusted Platform Module Based Remote Attestation Overview

1. Introduction

Remote attestation is a method by which a host (client) authenticates its hardware and software configuration to a remote host (server). At ZEDEDA, remote attestation aims to enable a remote system (challenger) to determine the level of trust in another system's platform (attestator).
One of the most common security challenges that could be faced by an Edge Node is, an attacker accessing the restricted resources. All edge nodes must be made ready to tackle this kind of threat. To counter these threats, platforms should implement a secure Root of Trust (RoT) and RoT services (including crypto, attestation, secure storage). Restricted resources and assets (secrets) should be maintained in a hardware-isolated domain and key operations performed via secure services.

The Trusted Platform Module (TPM)

The Trusted Platform Module (TPM) is an international standard for a secure crypto-processor and is an integral part of the ZEDEDA Edge Node ecosystem. TPM cannot alter the system's execution flow (for example, booting, execution of applications).
Main functions of TPM:
  • Cryptographic key generation
  • Protection of cryptographic keys
  • Hardware pseudo-random number generation
  • Hardware authentication
  • Sealed storage (passwords, encryption keys, and digital certificates)
  • Remote attestation


Security features inbuilt in EVE-OS

Edge Virtualization Engine (EVE-OS), an open edge computing engine (part of LF Edge), is built with security at the core of its design. EVE-OS's security principles provide:
  • A deterministic way to measure its software layers, right from firmware, all through bootloader, kernel, and user-space applications.
  • A mechanism to report these measurements (Platform Configuration Register values) to a third party for attestation. A Platform Configuration Register (PCR) is a memory location in the TPM with some unique properties.

Platform Configuration Register (PCR) values

As shown in the diagram above, each of the software layers can be compromised. Hence, each layer in the software stack measures the next layer. A chain of trust is established. For example, let's say the firmware is verified and trusted, then firmware measures BIOS. If the BIOS measurements are verified, then BIOS is trusted. Eventually, if EVE-OS is trustworthy, then the application instances launched by EVE-OS will also be trustworthy.

2. TPM Operations

TPM is used to establish a chain of trust. ZEDEDA uses two key operations of the trusted platform module called 'PCR extent' and 'Seal' to achieve this feature. For more information about the TPM-based remote attestation, click here.

2.1. PCR Extend

TPM can be asked to perform a 'PCR Extend' command. A particular hash value would be added to the existing hash value in a Platform Configuration Register(PCR), and the resultant hash value can be stored back in the same PCR. i.e.,
PCR_ContentNew = Extend (PCR_ContentCurrent, New_Measurement)
One can only extend the current value in the PCR with a new hash value, and the existing contents can not be overwritten. This provides us with these key capabilities:
  1. The order of measurements—the final value will be the same if the measurements are done in the same order.
  2. The final PCR value captures the whole history of measurements—useful in quick validation of final states against the expected state.
  3. Deterministic—If one repeats the same history of measurements, he will end up in the same final PCR value—useful in validating a change in one of the input sequences.

2.2. Seal

TPM can seal a piece of given secret information against the current PCR values through a TPM command called 'Seal.' Once sealed, the information can be read back only through an unseal command, which will succeed only if those PCRs hold the same set of values as they were during the sealing operation. In other words, if those PCR values aren’t the same, the secret can not be recovered.
Using these two TPM capabilities, one can build powerful solutions to measure and validate a given system's software state. The measuring process is called Measured Boot, and the method of getting the measurements verified and attested through a third party is called 'Remote Attestation.'
Measured Boot is a method where each of the software layers in the device's booting sequence measures the layer above that and extends the value in a designated PCR. e.g., BIOS measures various components of Bootloader and stores these values in PCRs 0-7. Likewise, bootloaders can measure the Linux kernel and store the measurements in PCRs 8-15. The Linux kernel has a feature called Integrity Measurement Architecture (IMA), where various kernel executables/drivers can be measured and stored in PCR 10.

3. Remote Attestation of an Edge Node from the ZEDEDA Platform

Attestation can happen in two ways:

  • While onboarding an Edge Node to the ZEDEDA platform.
  • By enforcing the attestation policy, after the edge node is onboarded successfully.
The following diagram shows a typical device attestation workflow. The only difference between the two ways is the first step.

Attestation Policy Enforcement

The attestation policy can be enforced on an edge node to enable remote attestation.
Once the attestation policy is enforced, the edge node generates the attestation request with PCR values (there is a nuance provided by the ZEDEDA for which the edge node generates the PCR quote, included in the attestation request). The attestation request is then sent to ZEDEDA to match the PCR values with the template. ZEDEDA releases the key to unseal the edge node's encrypted disc only when the match is successful. The Edge Node stores the key in TPM thereafter.
Note: Click here, to get details and UI screens of upload measurements, attestation status, PCR values, and 'Application Data Encryption at Rest' status.

4. Attestation During Edge Node Modification

The following workflow captures the modification of one or more PCR values as it happens on the edge node. After the initial attestation of the onboarded edge node is successful, whenever there is a change in any software layers, for example, an EVE-OS version update, the re-attestation process is performed automatically. The flow of the attestation, in this case, is represented in the following diagram.
Attestation fails when the PCR values do not match with the already present template. As a result, ZEDEDA does not release the key to unseal the edge node's encrypted disc. This results in the locking of the edge node.
The user has to upload the new template, against which the validation of the PCR values happens. ZEDEDA releases the key to unseal the edge node's encrypted disc only when the match is successful. The Edge Node stores the key in TPM thereafter.

5. Attestation Scenarios

5.1. Attestation Failure

In the case of tampering or changes in any PCR values, the attestation continues to fail until the user intervenes by uploading a new template. The flow is represented in the following diagram.
Attestation fails when the PCR values do not match either the already present template or the newly uploaded template. As a result, ZEDEDA does not release the key to unseal the edge node's encrypted disc. This results in the locking of the edge node.

5.2. Edge Node Unreachable From ZEDEDA

This section is about successful attestation without PCR generation. For example, let's say the edge node is not reachable to ZEDEDA, and a reboot action is performed on the edge node. The edge node gets unsealed using the key obtained from ZEDEDA, which is stored in the TPM. This scenario is possible only when the PCR values are the same before and after the reboot.
Was this article helpful?
1 out of 1 found this helpful

Articles in this section