Trusted Boot: What to Know About Securing Devices at the Edge

To protect the vital workloads and data that run on edge compute devices, you must start by securing those devices when they’re at their most vulnerable — the moment they boot up.

If an attacker can physically tamper with your device and modify the boot hardware, firmware, Linux bootloader or operating system (OS), all the security measures you apply later, higher up the stack, are that much weaker. For example, anti-malware and access controls haven’t even loaded at that point.

That’s not such a problem in the data center, where devices are protected by physical security. But many edge computing deployments are installed in unattended or insecure locations, meaning they’re at continual risk of physical attacks or even being stolen and probed at leisure by a determined adversary. Edge devices, including ATMs, point-of-sale systems, medical equipment and Internet of Things (IoT) devices, are on the true front line of cybersecurity battles.

There’s one more factor at play here: Increasingly, edge devices not only hold sensitive data but also valuable intellectual property, such as artificial intelligence (AI) models.

Imagine that malicious actors steal a defense drone. If no security measures are in place, they could reverse-engineer it, open it up and get all the precious data it contains, including how the OS and the model it uses to recognize targets work. The adversary could even alter the device and put it back out into the field.

What Does It Mean to ‘Secure the Boot’?

In these scenarios, you need a mechanism that resists tampering with the device’s critical boot components and verifies their state at the moment of boot, preventing any tampered systems from loading the OS and decrypting any sensitive user data.

The goal is simple but complex to achieve: You must prevent unauthorized access to the software or the data generated by the machine and make it impossible for the machine to execute modified code.

What’s more, the device must be able to verify its “good state” and authorize its own boot and decryption of user partitions without any external input; when you’re talking about thousands of headless edge devices, you can’t require a human user to enter a password, physical key or biometric to OK the boot.

The complex and cutting-edge mechanisms that achieve this goal (in full or in part) are known by terms like secure boot, verified boot and trusted boot, and they’re used in conjunction with full-disk encryption (FDE).

Defining the Terms

There’s a lot of confusion around these terms, and they may be totally new to you — so let’s get things clear.

FDE stands for full-disk encryption. It is a security measure that encrypts the entire contents of a disk drive, including the OS, system files and user data. FDE’s purpose is to protect data stored on the disk from unauthorized access in the event the device is stolen or lost.

Secure boot is a security feature in modern computer systems that ensures only properly signed and authenticated OSes are allowed to run during the boot process. When secure boot is enabled, it helps prevent loading malicious or unauthorized code at the early stages of the system startup, thus helping protect the integrity of the boot process.

Measured boot involves creating a record, or measurements, of each step in the boot process and storing the measurements in specific hardware dedicated to cryptographically secure operations (a trusted platform module, or TPM) or similar secure storage. This allows the system to verify the integrity of each component of the boot process and detect any unauthorized changes. Measured boot provides comprehensive and continuous security checks throughout the boot sequence.

By combining secure boot, measured boot and FDE, you can guarantee a system was not tampered with and the user data is protected against cold attacks. This combination of technologies stacked together is called trusted boot. You can learn more about trusted boot in this detailed blog post by Lennart Poettering (the author of systemd).

How Kairos Implements Trusted Boot

Several organizations are working toward the different elements needed for effective Linux trusted boot, from chipmakers like Intel to a range of open source and commercial teams, such as Canonical with Ubuntu and Talos Linux.

At Kairos, we’ve been working on incorporating trusted boot into our open source codebase, too, and from there into Spectro Cloud’s Palette Edge. This continues the work that we started last year with Secure Edge-Native Architecture (SENA) — a joint project between Spectro Cloud and Intel to deliver edge computing security. Soon you can use our implementation when deploying Linux to your edge devices, the foundation for your edge Kubernetes stacks.

When combined with the other architectural features that make Kairos unique, this trusted boot capability will make Kairos a strong choice for safe and secure edge computing. You’ll be able to customize your system from containers and build out your OS and Kubernetes stack, with the resulting single container images being more secure and easier to manage through atomic A/B upgrades and immutability.

To achieve trusted boot, here’s what we do.

Instead of using a multistage “pivot” to load large file systems, from an initial RAMdisk to a final system, we use unified kernel image (UKI) files. These are small (under 300MB) single binary files that can be verified and contain the kernel and all other elements needed to minimally boot the system and decrypt the other partitions.

The UKI images are stored in the EFI partition; the firmware directly loads the UKI files as standard EFI files. UKI is a file specification tailored to achieve a tamperproof system and encryption of user data bound to the silicon by relying on hardware capabilities. The advantage of using EFI files is they can be signed and verified with the secure boot mechanism and measured as a single file during boot, enhancing the system’s overall security posture.

As part of this re-architecture, instead of the old faithful Grub bootloader, we use the more modern systemd-boot, which has a smaller attack surface and plays well with tools like systemd-measure and ukify that help with trusted boot.

👁 Diagram of systemd-boot-based architecture

Trusted Boot on TPM-Equipped Hardware

When the device boots, several steps happen sequentially.

Many hardware platforms use a Core Root of Trust for Measurements (CRTM), which is the very first thing that boots, even before the firmware. The CRTM gets a hash of the firmware and sends it to the TPM chip, which measures the running software and is a requirement for trusted boot. The TPM chip then loads the firmware/BIOS.

The TPM takes note of the measurement and stores the hash in a bank of multiple platform configuration registers (PCRs). In order to store measurements, the TPM chip extends the banks from the previous values, as these changes to the stack are easy to recognize during the boot.

👁 Diagram of trusted boot on TPM equipped hardware

Next, the BIOS or firmware measures the subsequent stage (bootloader or UKI) and sends it to the TPM; then it loads the UKI and continues booting.

Once the TPM is asked to release an encryption key to unseal the full disk encryption, it will check if the measurements it has are valid. If a bootloader is present, it will have already measured the UKI files, and measurement also happens when initrd starts and when the running system is ready to check eventual manipulations (e.g., kernel boot command line). The process is also bound to the secure boot signatures, so any manipulation of the UKI files would be allowed only by the key holders.

If a malicious attacker tries to load custom software or modify an image in any way, they must extend the PCR value and align it with the value it would have had following an expected boot. The cryptographic robustness of the hash algorithm makes achieving this computationally expensive, thereby helping to support security.

If the firmware or bootloader have been tampered with, the hash values stored in the PCR won’t match expected measurements, and the system will flag an alert and prevent boot from happening — intentionally bricking the host device as a failsafe.

Learn More

Trusted boot is one of many recommended security techniques — but it’s critical to ensuring you can trust the integrity of your device, particularly when it’s deployed in the field.

I’ve just scratched the surface of trusted boot as a concept, how it works and the architectural details of the Kairos implementation that contribute to the overall security posture. If you’d like to learn more:

Check out our CNCF presentation, available on demand.

Attend our panel about special-purpose operating systems at KubeCon Paris on March 22.

Learn more secure edge architectures including trusted boot, by downloading the SENA white paper.

Check out Kairos’ trusted-boot architectural documentation and try it out yourself.