An argument for a dynamic root of trust in mission-critical systems

August 05, 2024

Alex Olson

Star Lab Software

A dynamic root of trust measurement (DRTM) approach can greatly decrease the risk of exploitation of sensitive key materials used in defense and related applications. Failure to protect these implicitly trusted components can mean opponents interfere with the mission of the subsequent operational environment or expose sensitive key material, algorithms, or data. Including DRTM for measured boot on mission-critical systems is necessary for ensuring secure and uncorrupted data.

Measured boot can provide a means of both authenticating early boot components and tying the release of sensitive key material and data to a known good, trusted state. However, relying entirely upon static root of trust measurements (SRTM) assumes a degree of implicit trust in an increasingly complex firmware and early boot software stack which may be exploited at runtime.

Security measures such as mandatory access control (MAC) and full-disk encryption are only effective if a system remains trustworthy. For example, a system that can be readily modified by an adversary could leak the encryption key or contain malware. A measured boot provides assurance that a specific combination of boot components is being used and that they have not been altered.

With a measured boot solution, each component is measured (using a cryptographic hash) before it executes. A trusted platform module (TPM) is often used to hold these measurements since it is relatively isolated from the rest of the system. More specifically, measurements are stored in platform configuration registers (PCRs) using a chain of cryptographic hashes, not unlike the design of Git source control and blockchain technologies. A critical feature is that a single altered measurement will alter the entire chain of measurements, and there is no way to “go back” to the unaltered state. The starting point for measurements is known as the “root of trust.”

The value of a strong measured boot solution exceeds mere attestation. For example, full-disk encryption requires an encryption key to be stored somewhere. A powerful solution is to store such keys in the TPM, bound to the PCR values from the measured boot. In such a design, the TPM will not release the encryption key if the PCR values vary from the expected.

Static root of trust for measurements (SRTM)

Consider a modern x86 Linux system using UEFI firmware. (UEFI stands for unified extensible firmware interface, a specification from the UEFI Forum that defines a new model for the interface between personal-computer operating systems and platform firmware.) UEFI Secure Boot – a UEFI firmware security feature developed by the UEFI Forum that ensures only immutable and signed software are loaded during the boot time – is a standard feature that primarily implements verified boot, and optionally a measured boot. However, the boot process is complex, containing many components like those found in Table 1. The measurement/verification of each component is implemented separately by different vendors. A vulnerability in even a single layer effectively breaks the chain of trust.

[Table 1 ǀ A table shows the common UEFI components.]

Verified boot is not enough

UEFI secure boot is primarily a solution for a “verified boot,” since the cryptographic signatures enable the user to prove that components originated from trusted sources, although it can perform measurement as well. However, even in the absence of vulnerabilities, UEFI secure boot does not necessarily prevent tampering. Perhaps surprisingly, with the default set of UEFI secure boot keys, nothing prevents the booting of an entirely different Linux distribution, or even Microsoft Windows instead of Linux. Remedies do exist, but they come with a significant learning curve, along with significant added complexity in terms of key management and provisioning.

The weakest link

In the 1980s, BIOS firmware was under 64K bytes in size and had a simple purpose. Today, UEFI firmware is easily 16 Mbytes, containing highly complex runtime layers with many interfaces, such as:

• USB stack
• Network stack, HTTP client
• Graphics drivers
• File system drivers

Any one of these layers is ripe for exploitation. It is difficult to overstate the complexity of UEFI firmware. Its size and complexity compare with operating systems not long ago. For example, a common corporate laptop’s UEFI firmware has these specs: 177 UEFI PEI modules, 388 UEFI DXE drivers, and over 250 EFI variables.

This attack surface is enormous. It only takes a single vulnerability in a PEI/DXE driver or the handling of a single EFI variable to result in arbitrary code execution and the complete defeat of Intel’s boot guard, UEFI secure boot, or other security measures. These are not theoretical concerns: In 2022, researchers at firmware-security company Binarly announced finding 23 high-impact UEFI vulnerabilities affecting 25 computer vendors. In 2023, they also announced the “LogoFAIL” vulnerability, which affected the vast majority of x86 and Arm systems with UEFI firmware. Exploitation of such security measures enables an attacker to bypass Intel’s boot guard and UEFI secure boot at the same time.

Weakness in the “shim”

The default UEFI secure boot keys allow for Microsoft-signed binaries, enabling Microsoft Windows to boot when UEFI secure boot is enabled. Similarly, PCIe option ROMs are also signed with a similar key. To avoid requiring Microsoft signatures on every build of the GRUB boot loader/boot manager, mainstream Linux distributions use a small “shim” loader to delegate signature validation, which itself is signed by Microsoft. The shim loader validates GRUB against the distribution’s internal signing key, not the Microsoft one. Unfortunately, exploitable vulnerabilities have been seen even in the shim loader. Moreover, as was discovered in 2023, CVE-2023-40547 was a remote-code-execution vulnerability in shim that could be weaponized to defeat UEFI secure boot, through no fault of the UEFI implementation. This was just one of six CVEs [common vulnerabilities and exposures] in the shim discovered in 2023.

Weaknesses in GRUB

The GRUB bootloader itself now has the same complexity issues as the UEFI network stack. Far from the early days of Linux, where the LILO [Linux loader] bootloader was just a few disk sectors, GRUB spans several megabytes and contains many similar components as UEFI firmware (network stack, USB, graphics, etc.).

Many GRUB vulnerabilities have been discovered, including those enabling bypass of UEFI secure boot and Linux kernel signature enforcement. In 2020 and 2021, at least eight such CVEs were announced, most of which provide a way to bypass UEFI secure boot. They originated from heap/stack overflows, command/config parsing, and incompletely restricted commands. The GRUB and UEFI environments lack many mitigations normally assumed today such as ASLR [address space layout randomization, a computer-security technique]. Humorously, six years of GRUB releases were vulnerable to CVE-2015-8370, which could be exploited simply by pressing the “backspace” keyboard key 28 times. Such vulnerabilities are often the consequences of complexity.

What about DMA?

Validation and measurement of the boot process is primarily software-based. However, accessing USB, network, disk, etc. involves direct memory access (DMA) by PCIe devices. (Figure 1.)

[Figure 1 ǀ While validation and measurement of the boot process is mostly done in software, access to USB, network, disk, and the like involves direct memory access by PCIe devices.]

Traditionally, PCIe devices have full access to the entire memory space. Modern systems contain an IOMMU [input–output memory management unit], such as Intel Vt-d, which limits what memory regions devices may access, but it is generally disabled by default. The GRUB bootloader has no IOMMU support, and the Linux kernel often boots with no IOMMU protection.

In other words, a malicious PCIe device could attack either GRUB or the Linux kernel during the boot without altering TPM measurements or failing a cryptographic signature validation.

Dynamic root of trust for measurements

A stronger security posture is to shorten the chain of trust and consequently reduce the potential attack surface. This cannot be accomplished with software alone. However, this is readily available using Intel TXT, which combines custom CPU instructions, chipset design, and TPM specifications to create a dynamic root of trust for measurements (DRTM). The root of trust begins with the execution of the GETSEC instruction to validate and launch an Intel-signed authenticated code module (ACM) in a DMA-protected environment with only a single CPU active. The ACM extends DMA protection to the next boot component, measures it, and extends TPM PCRs with its measurements. A number of open-source boot components using TXT exist, such as Intel tboot and TrenchBoot, as well as commercial solutions.

BIOS and UEFI support

Unlike UEFI secure boot, TXT-based DRTM solutions support both UEFI and BIOS systems as well. Due to complexities of the BIOS boot process, a DRTM-based solution is practically the only possible way to ensure a measured boot on BIOS systems.

A major advantage of DRTM-based solutions for mission-critical use is that they do not necessarily require the system to be in a trustworthy state. For example, one could securely utilize a DRTM to network-boot (using PXE, etc.) a Linux system, without including the option ROM – PXE implementation – in the chain of trust. Even for traditional disk-based booting, one needn’t rely on the bootloader or rely on UEFI signature verification of boot images; instead, DRTM-based solutions can focus on measuring the OS kernel with a reduced attack surface.

Alex Olson is the Titanium Secure Boot Lead Engineer at Star Lab, with over 18 years of experience in embedded firmware development ranging from microcontrollers to high-end servers. His background includes both offensive and defensive cybersecurity roles. He is an inventor in eight patents and holds a master’s degree in computer engineering from University of Texas at Austin.

Star Lab Software • https://www.starlab.io/