New Boot Security Allows Updates Without Key Loss

The presenter opened by highlighting the classic joke about computer security, where the most trusted state for a general computer is achieved by turning it off, encasing it in concrete, and sinking it into the sea. This humorous example underscored the inherent difficulty and sometimes extreme measures associated with ensuring true computer security.

Modern security standards such as secure boot and trusted platform modules (TPM) are exceptionally complex systems. The specification documents alone for a TPM are vast, highlighting the intricate nature of current security solutions. This complexity makes hardware-based security difficult to manage and implement effectively in various environments.

There is a pressing need for simpler, yet equally effective, trust mechanisms that can be applied to a wider range of devices without requiring extensive overhead or specialized knowledge.

Many years ago, researchers at Microsoft developed a method for performing measured boot in constrained environments, initially as part of the RIOT project. This technology has since evolved and is now widely known as DICE (Device Identifier Composition Engine), standardized by the Trusted Computing Group.

DICE focuses on providing robust measured boot capabilities specifically for resource-limited devices, aiming to simplify the complexities associated with securing the boot process.

In the context of measured boot, 'measured' refers to a trusted piece of code that computes a hash digest of specific data. This data can include critical components such as CPU instructions within a program or other essential input data that defines the system's state.

Once computed, this hash digest must be securely stored and made readable for subsequent verification, ensuring that any unauthorized alteration of the measured data is immediately detectable.

Layer zero represents the first mutable code executed during the boot process, serving as a critical foundation for device identity. At this stage, a Unique Device Secret (UDS) is embedded into the device during manufacturing.

This UDS is randomly generated and protected by hardware, preventing unauthorized access or modification by any program other than the firmware or bootloader, thus ensuring its integrity.

The Compound Device Identity (CDI) forms the base secret for the entire system, derived through a cryptographic hash function, specifically Blake2S. This calculation involves hashing the Unique Device Secret (UDS), a measured application ID (which is the integrity hash of the program), and potentially a user-supplied secret.

The combination of these inputs ensures that the CDI is unique to the device's hardware, its current software state, and any user-defined security parameters, creating a robust and fundamental security anchor.

DICE operates on a trust on first use (TOFU) model, where the system establishes trust based on the initial measurement of the software. A key characteristic of this system is that the Compound Device Identity (CDI) is volatile and not stored persistently, meaning it is re-calculated with each boot.

Crucially, if even a single bit of the program changes, the CDI and all derived cryptographic keys also change. This mechanism inherently prevents malicious code from leveraging valid cryptographic keys because any alteration to the application binary will invalidate the associated keys, thereby upholding the integrity of the system.

Verified boot typically involves verifying a signature over a program or its digest against a publisher's public key, focusing on the origin and authenticity of the software.

In contrast, the new measured boot system relies on a dynamic assessment of the hardware and software state, ensuring that the entire system environment is trustworthy. This approach avoids locking the system to a single vendor, providing greater flexibility and independence.

A significant problem with current DICE-like measured boot systems is the inability to update programs without losing cryptographic keys. When a program changes, including simply updating to a new version, the Compound Device Identity (CDI) and any derived key material will also change.

This means that any existing cryptographic keys tied to the previous program version become invalid, rendering existing DICE-like systems difficult to maintain and hindering regular software updates.

To address the key loss problem, a novel solution involves introducing hardware resets that revert control back to the trusted firmware or bootloader. This mechanism allows for chaining of applications, enabling measurements of two distinct types of application identity.

This new approach effectively reintroduces a form of verified boot, but within a combined framework that leverages the strengths of both measured boot and verified boot principles. This hybrid model aims to allow program updates without compromising key integrity.

Chain measurement is a valuable technique that uses the existing Compound Device Identity (CDI) as an input for calculating the next program's CDI. This ensures that a continuous chain of unique secrets can be generated and maintained across an entire boot sequence.

This method effectively guarantees the integrity of secrets throughout the boot chain without needing to reintroduce the full complexity of traditional verified boot mechanisms. Furthermore, it avoids vendor-specific locking, promoting a more open and flexible security ecosystem.

The verifier is a compact device application specifically tasked with validating the subsequent stage of the boot.

In Stage 2, the verifier retrieves metadata and performs signature validation on the incoming components. The system is designed with explicit system calls that facilitate controlled and secure transitions between these stages, ensuring integrity at each step.

Before a hardware reset occurs, the system prepares a verified digest of the next program intended to be loaded after the reset. This preparation is a critical step to ensure integrity during the transition.

Once the digest is prepared and validated, the actual hardware reset takes place, smoothly transitioning the device from firmware mode to the newly loaded application, all while maintaining a continuous chain of trust.

When programs are chained together in this new boot process, the measured application ID is derived from the current layer's Compound Device Identity (CDI) and any remaining unmeasured components from that layer. This method ensures that the application's identity remains consistent and unbroken even after a hardware reset.

By preserving this identity, the system allows for the seamless continuation of cryptographic processes and maintains the integrity binding between the software and hardware across boot stages.

The verified boot process offers strong guarantees that the correct boot stages are executed and that the intended verifier code is running. This ensures a high level of integrity throughout the boot sequence.

Furthermore, the publisher's identity is cryptographically bound to the application. Any changes to the publisher or the application name will result in an incorrect Compound Device Identity (CDI), effectively preventing unauthorized modifications or impersonations.

The core challenge with original DICE-like boot systems was that measuring the entire binary meant any program update would inevitably lead to changes in cryptographic keys and the loss of all existing key material. This made continuous updates impractical for secure systems.

The newly developed approach overcomes this by allowing programs to be chained, maintaining a consistent Compound Device Identity (CDI) across updates. This innovation preserves hardware and software integrity binding while enabling application updates without compromising cryptographic keys.

Despite significant progress, several open questions remain for the open-source implementation, particularly concerning key management. It's unclear whether to use only the application name, the publisher's key, or a combination for measurement, making key distribution a complex problem.

Another critical challenge is effectively handling downgrade attacks, which could potentially roll back a device to an older, less secure version of its software. The project actively seeks community contributions to find robust solutions to these issues.

Addressing these challenges will further strengthen the security posture and practical deployability of the system in real-world scenarios.

When an application and its boot verifier are loaded from a client, the client itself provides the publisher key, which is then validated via measurement. This mechanism ensures the integrity of the key during the boot process.

The publisher key can be stored in metadata on flash file systems. This verification process is crucial for preventing malicious key injection from compromising the system's identity, thereby maintaining a secure chain of trust from the client to the device.