Integrity of embedded systems
BlogFebruary 28, 2019
It is critical to be able to verify the integrity of systems used in military and other applications to ensure that they have not been modified or corrupted. It is of course best to prevent a system from being tampered with. If this can't be done, it is vital to detect tampering. In many cases it is better to prevent a system from operating at all if you can't be sure it hasn't been modified. In all cases it is vital to protect information on the system and especially critical secrets like crypto keys.
A variety of tools at the operating system level help with ensuring the integrity of software. These include storage encryption, cryptographic signing of software packages, check-sums of files, and tools for checking the system. But what can be done to ensure that the underlying system has not been compromised - to verify the hardware, BIOS and other firmware, and the bootloader? And what can be done if problems are detected?
Let’s consider what can be done using a Hardware Root of Trust and recent developments in the Linux operating system that provide a view into the integrity of the underlying system.
The first factor is LUKS, a robust and secure storage encryption capability built into Linux. LUKS encrypts every-thing from disk drives to USB drives, SD cards, and even network storage. LUKS encrypts at the volume level, and Linux systems can be configured as either a single volume or multiple independent volumes on a single drive. This gives considerable flexibility and power for configuring and protecting the information on an embedded system.
One of the use cases for LUKS is to encrypt the system drive. When this is done the LUKS password must be provided to boot the system. With systems like laptops this is commonly done by typing in the password. Network Bound Disk Encryption (NBDE) is a new Linux package that uses a network service or a Hardware Root of Trust to provide the LUKS key to boot the system.
NBDE is a flexible crypto framework that uses various pins or crypto engines to encrypt and decrypt secrets such as LUKS keys. NBDE is designed to be extended and currently supports two pins: a network tang server and a TPM 2.0 Hardware Root of Trust. Additional pins can be developed such as a Systems Integrator might implement a NBDE pin supporting CAC cards. (As a side note, the open source Linux community would welcome submissions of other pins for NBDE.) NBDE also implements policies which allow multiple pins to be combined.
NBDE with TPM2 is a good choice for embedded systems in remote locations without secure network connections. This ensures that the system will only boot if the OS disk is in a system with a properly configured TPM2 module and it has been bound to that TPM2 module.
The next element to consider is secure boot. This is implemented in the UEFI firmware and requires that the bootloader and operating system are signed with a known and approved software key before it will allow the system to boot. Secure boot is a good tool for ensuring that the operating system is valid. Industry standard secure boot keys are commonly installed in the UEFI firmware at the factory. These keys can be used as is, custom keys can be added, or the standard keys can be deleted, and only custom keys used.
Secure boot is an effective tool and should be used. However, secure boot can’t verify the underlying hardware, the firmware, or that secure boot itself is running. This is where TPM2 and measured boot come into play. Measured boot is sometimes referred to as Trusted Boot.
Measured boot works at multiple levels. The TPM2 module contains a set of 24 Platform Configuration Registers, or PCRs. Software, such as UEFI firmware, is hashed using an algorithm like SHA-256 and the hash is stored in a PCR. However, the hash isn’t written directly into the PCR. Rather the hash is extended into the PCR using cryptographic operations inside the TPM2. Multiple measurements can be combined into a single PCR. The final value in the PCR depends on the hash of each file and the order the files are evaluated. This process is deterministic, given a set of files and an order of measurement, you get the same results each time. These measure and extend operations can be replicated outside of a TPM -- you can determine in advance what the final value in a PCR should be.
Measured boot updates the PCRs in a sequence of operations: a very low-level software routine, essentially part of the hardware, measures the UEFI firmware and option roms such as NICs and storage controllers. The UEFI firmware measures the Master Boot Record and bootloader. The bootloader measures the kernel and related files. Other tools, such as Linux Integrity Measurement Architecture (IMA) can then measure the rest of the system. Measurement can include both files and configuration. Eight of the PCR registers are pre-defined for system use and eight are available for custom use by applications.
The TPM and PCR model is designed to make it impossible to modify PCR measurements without detection and very difficult to interfere with the measurement process without detection.
PCR measurements can be used for a variety of purposes, including local and remote attestation of the integrity of the system. They can also be used for sealing operations inside a TPM. In TPM sealing a TPM protected secret is further protected by a TPM policy that checks PCR values against approved values before decrypting the secret.
As a concrete example, using NBDE you can seal the LUKS password against PCRs 0, 2, and 7. This would measure the UEFI bios (PCR0), firmware on other devices in the system (PCR2), and secure boot (PCR7). The LUKS password would only be provided if the UEFI firmware had not been modified, another device firmware had not been modified, and secure boot were still enabled. Note that these checks are done inside the TPM. These measurements ensure that the firmware has not been corrupted and that no rootkits have been added. While not absolute protection, it significantly improves the integrity of the system.
In this example the operating system and applications can be easily updated without touching the TPM. Firmware can still be updated - this would require resealing the TPM with the new values.
Secure military systems which should not be changed outside of depot- or even factory-level maintenance can be locked down even tighter, perhaps using multiple PCRs and other factors such as connecting to a network service; a sensor array has to be communicating to be useful, so this can be a reasonable approach.
Any secrets can be protected using the approaches described here. Crypto keys can be loaded directly from the TPM2 into memory and then wiped as soon as they are no longer needed; there is no reason for them to persist on disk. And the entire TPM can be instantly wiped by issuing a TPM_reset command.
Full details on the range of protections available using TPM2, PCRs, and sealing is available from the Trusted Computing Group at trustedcomputinggroup.org. Details on NBDE and the clevis framework are available at github.com/latchset/clevis.
