Protecting and verifying the integrity of Internet of Things (IoT) systems is critical. A key element of system integrity is ensuring that a system has not been modified or corrupted. This is especially important for IoT gateways and edge servers that are directly attached to networks and to the Internet.

Ideally, it is best to prevent a system from being compromised in the first place. In many cases, it is better to prevent a system from operating at all if it has been corrupted or modified without authorization. No matter what, it is vital to protect information on the system and especially critical secrets like crypto keys.

Effective tools

An effective security program includes continuous monitoring, so users always know what’s happening, along with a clear response plan to efficiently handle surprises when they do happen.

A variety of tools at the operating system level help verify the integrity of software. These include storage encryption, cryptographic signing of software packages, checksums of files, and tools for checking the system. But what can be done to make sure 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 (HW) 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 Linux Unified Key Setup (LUKS), a robust storage encryption capability built into Linux. LUKS encrypts everything from disk drives to USB drives, SD cards, and 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 or multiple drives. This gives considerable flexibility and power for configuring and improving the protection of information on an IoT 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 Linux package that uses a network service or a HW 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 – it currently supports two pins: a network tang server and a Trusted Platform Module (TPM) 2.0 HW Root of Trust. NBDE also implements policies which allow multiple pins to be combined.

NBDE with TPM2 is a good choice for IoT systems in remote locations without secure network connections or complete physical security. This ensures that the system will only boot if the operating system (OS) disk is in a system with a properly configured TPM2 module and it has been bound to that TPM2 module.

Secure boot

The next element to consider is secure boot. This is implemented in the Unified Extensible Firmware Interface (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 (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 network interface cards (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, other 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 can significantly improve the integrity of the system.

Note that this approach also protects from live image attacks where you boot from a live image, mount the existing system disk, and read information off of it. In this case the TPM2 sealing would detect the presence of new hardware in the system and refuse to provide the LUKS key.

In this example the operating system and applications can be updated without touching the TPM. Firmware can still be updated – this would require resealing the TPM with the new values.

As previously mentioned a set of PCRs are available for user applications. User applications can extend values into these PCRs which can then be used to verify application level integrity and used to seal secrets.

Any secrets can be protected using the approaches described here. SSL keys, SSH keys, software license keys and device access codes can all be protected by TPM. 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.

In the case of a system compromise the entire TPM can be immediately wiped by issuing a TPM_reset command, making TPM protected secrets unavailable. 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.

Russell Doty, Product Manager for Emerging Technologies, Red Hat Enterprise Linux, Red Hat