Unlocking the Mysteries of Trusted Boot: A Deep Dive into Secure System Boot Processes
In the evolving landscape of cybersecurity, protecting the integrity of computing systems from the moment they power on has become very important. As threats become more sophisticated, understanding and implementing advanced boot security mechanisms like Trusted Boot, Full Disk Encryption (FDE), Secure Boot, and Measured Boot are critical for safeguarding data and ensuring system integrity. This article demystifies these concepts, explores their significance, and examines their implementation in modern computing environments, particularly focusing on the Linux ecosystem and the approaches within the Kairos project.
We are facing new challenges as 2024 starts. While AI is pushing innovating technologies to the edge, security becomes even more critical for organizations to protect sensitive data.
Image credits https://www.reddit.com/r/PBSOD/comments/c8nusw/it_is_now_safe_to_turn_off_your_computer_atm_in/
As industries evolve over time, security measures are increasing to protect edge devices from attackers. New attack vectors and vulnerabilities are exploited every day by cybercriminals, making it crucial for industries to continuously update and enhance their security systems. In the context of edge devices, which are computing elements that process data at the edge of the network, closer to the source of data generation, this need is even more pronounced. These devices, including ATMs, point-of-sale systems, and IoT devices, are often the front line of cybersecurity battles.
One of the primary challenges in securing edge devices is their inherent diversity and distributed nature. Unlike centralized systems, edge devices are spread across various locations, often in unsecured or semi-secured environments, making physical and network security a significant concern. This dispersion also implies a broad attack surface, with each device potentially offering a unique set of vulnerabilities. What we are trying to build here is a new foundation to define how to deploy secure devices which cannot be tampered with, and can keep data secure from malicious actors. We do want to protect the software stack that we run on it .
Our goal is simple but complex to achieve: No unauthorized access to the software, to the data which is generated by the machine, and finally, we don’t want the machine to execute modified code.
The Essence of Boot Security and Encryption
Here comes Trusted Boot and SENA to the rescue. Easier to explain with an Alice metaphor.
You can read more about Trusted Boot in the Lennart blog and about SENA in our blog post
Let’s imagine Alice has this super cool treasure chest, chock-full of her most prized stuff. She’s big on security, but in a high-tech way – kind of like how your computer needs to keep its data safe. To get this done, your computer uses some smart tricks, things like Trusted Boot, Full Disk Encryption (FDE), Secure Boot, and Measured Boot.
To picture Full Disk Encryption, or FDE, think of it as Alice’s treasure chest having a lock that only opens with a secret code. It’s so clever that if someone breaks into her house and finds the chest, they still can’t get inside without that special code. FDE is like that for your computer – it scrambles all your data so that only someone with the right password can read it.
Next, there’s Secure Boot. Imagine if Alice had this smart doorbell. When someone presses it, the doorbell checks if they’re on the guest list. If they’re not, no entry. Secure Boot is your computer’s version of this smart doorbell. It checks every piece of software when your computer starts up and only lets the good, trusted stuff in. It keeps out anything that looks fishy.
And then, we have Measured Boot. Picture this as Alice keeping a super detailed logbook. She writes down everything that goes on in her house – who comes in, what they do, you name it. If anything odd pops up, she’s on it. Measured Boot does something similar for your computer. It watches over the startup process, takes notes, and makes sure everything’s running just like it should, no funny business.
Putting all these together, you’ve got Trusted Boot, which is like Alice’s ultimate home security system – the secret-code lock, the smart doorbell, and the detailed logbook, all working together. We’re going to unpack how these nifty tools keep your computer as secure as Alice’s treasure chest, making sure your digital world is safe every time you power up.
Challenges and Solutions in Implementing FDE on Linux
While FDE is a standard feature in various operating systems, its implementation in Linux presents unique challenges. The initial boot stage, including the kernel and initial file system setup, cannot be fully encrypted as they have to be read by the firmware and the kernel respectively, leaving a portion of the system exposed. The initramfs for instance is responsible for unencrypting the portions of the disk. However, through careful measures, this unencrypted segment can be protected against tampering, thus securing the system’s boot process and the encrypted data it accesses.
The Kairos project adopts “Unified Kernel Images” (UKI) to enhance boot security as defined by the UAPI group. UKI files are single, fat binaries that contain the OS and necessary boot components in a single, verified file. This approach simplifies the boot process, allowing for the entire system to be booted securely and efficiently, but it presents as well interesting challenges due to the Firmware restrictions that might depend on the hardware used(such as booting EFI large files, or handling Secure Boot certificates). By leveraging EFI files that can be signed and verified through Secure Boot and measured as a single entity, UKI files represent a significant advancement in boot security.
Central to the Trusted Boot mechanism is the Trusted Platform Module (TPM), a dedicated hardware (also emulated by firmware) component designed for secure cryptographic operations. TPM chips play a critical role in storing encryption keys and measurements securely, enabling the system to verify boot integrity and encrypt user data effectively.
From Grub to systemd-boot
Trusted Boot is deeply integrated into systemd and is currently being actively developed. Linux offers a variety of init systems and bootloaders, such as GRUB. However, systemd includes tools like systemd-measure and ukify, which, although they work with various bootloaders, are particularly effective with systemd-boot. What sets systemd-boot apart from GRUB and other bootloaders is its focus on hardware compatibility support. As we aim to support modern hardware that must meet specific requirements, we prioritize minimizing the attack surface. Therefore, a narrower scope of support is a better fit for our specific needs and preferred over bootloaders designed for broad hardware compatibility, which often carry legacy code and a large patchset (for instance, you can see the number of patches that SUSE applies on top of standard GRUB package to add support to specific hardware/improve the functionalities). This presents a strong argument for choosing systemd, especially systemd-boot, over other bootloaders which targets recent hardware and a smaller scope.
Why this makes sense: We’re now in an era where outdated hardware is not our concern. Modern devices don’t require old drivers, so we have the opportunity to streamline our systems. This translates to a principle of ’less is more’ in our code and in our stack - less software in our stack means enhanced security. We aim for a leaner runtime to run our software, minimizing potential security vulnerabilities. In addition, it also makes sense to use tools that adhere closely to standard specifications.
Considering the transition to modern hardware, especially with widespread EFI support, systemd-stub or systemd-boot is a strong contender to replace GRUB. GRUB has been a staple in the Linux community for years, evolving from versions 0.x to 2.x, which if you are seasoned like me, you have witnessed almost all of them! However, it’s worth considering the extensive patches applied by distributions and its expansive codebase. While its extensive support and scripting capabilities were once advantageous, they now detract from its suitability as a lightweight option.
The goal is clear: we aim to minimize complexity in building a secure, efficient stack, reusing as much components well trusted and established by the community. By reducing the number of components, we strive for a more secure and streamlined system.
Booting in Linux
When a Linux system starts, it goes through a multi-stage process to load the operating system. This process can be broken down roughly into the following steps:
- Firmware Initialization: The system’s firmware, which could be BIOS or UEFI, performs initial hardware checks and configurations. It then searches for a bootloader, which is typically located in the boot partition or the Master Boot Record (MBR) of the storage device.
- Bootloader Execution: The bootloader, such as GRUB, is a software responsible for loading the main part of the operating system. Its primary task is to find the Linux kernel, usually located in the same partition, and load it into memory. The bootloader might present a menu or configuration options to choose different kernels or operating systems if multiple are installed.
- Kernel Loading and Initialization: The kernel is the core of the Linux operating system. Once loaded, it initializes the system’s hardware and sets up essential services. During this phase, the kernel decompresses and loads an initrd (initial ramdisk). The initrd is a temporary root file system loaded into memory. It includes essential tools and scripts needed to mount the real root file system. In modern Linux systems, initrd is often replaced by initramfs, which serves a similar purpose.
- File System Setup and Transition: Inside initrd, scripts are executed to prepare the actual root file system. This includes tasks like decrypting and encrypted partitions if present. After preparations are complete, the system makes a transition, referred to as “pivoting”, to the actual root file system.
- Root File System and User Data: The root partition, now mounted as the root file system, contains all the user data, system configurations, binaries, drivers, and other necessary components for the operating system to function. This is where the system runs from once the boot process is complete.
Throughout these stages, the components—firmware, bootloader, kernel, initrd, and the root file system—work in a sequence to load the operating system successfully.
This chain is the one we in the Linux and tech industry are very much familiar with. Several designs and strategies have been developed to secure this stack over time, for instance Verified kernels and drivers, or Secure Boot to sign the bootloader and be able to trust its authenticity. There are various bootloader implementations as well, tied to more secure HW (like TPM devices).
However, as technologies and security measures evolved, attacks evolved as well. Specific hardware now can be leveraged to increase the security posture of the boot process, and it is time for a change, as the market demands more sophisticated security measures to protect against malicious actors.
Booting with a TPM-equipped Hardware
When a device equipped with TPM, and a sufficiently modern hardware 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.
Next, the BIOS or firmware measures the subsequent stage (bootloader or UKI) and sends it to the TPM, then 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 any 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 (the host is still recoverable by re-installing everything from scratch).
Kairos and Trusted Boot
To gain a deeper understanding of the mechanics behind EFI files and the boot process, let’s delve into the way typical Linux distributions manage booting with Full Disk Encryption (FDE):
- Initially, the firmware retrieves the bootloader from the boot partition (or Master Boot Record - MBR) and transitions control to a kernel.
- This kernel then unpacks an initrd, which houses essential tools needed for initializing the file system (FS) and transitioning to the operational system environment.
In this setup, each component is distinct: the Kernel and Initrd are separate files, whereas the root partition is a unified file system encompassing all user data (such as installed binaries, password files, sensitive information, drivers, etc.). The primary function of the initrd in this scenario is to decrypt partitions and set up mount points as it transitions control to a different partition.
Contrastingly, the Kairos architecture utilizes a singular image file that amalgamates the rootfs, kernel, and initrd. Here, the initrd is responsible for establishing the FS and activating the rootfs.
The bootloader plays a pivotal role in this architecture by accessing image files stored within the state partition.
While the state partition remains unencrypted, the system’s operational projection is derived from the encrypted user-data partition. Directories such as /etc and /opt (which can be fully customized) are overlaid, safeguarding sensitive information from being exposed within the state partition. Nevertheless, this design, along with the previously mentioned setup, is vulnerable to “Evil Maid Attacks.” These attacks involve altering the system by booting from a LiveCD and modifying the booted images.
In the context of the UKI (Unified Kernel Image) architecture, which closely resembles the Kairos model, the primary distinction lies in the storage of a singular EFI image file within the boot partition. This arrangement facilitates the signing and verification of EFI files to ensure they haven’t been tampered with, leveraging SecureBoot in tandem with Measured Boot. These mechanisms verify that the image is certified by a trusted authority and remains unmodified.
During the boot process, cryptographic assessments are made using the Trusted Platform Module (TPM) to confirm the system’s integrity. Drive decryption during boot is contingent upon consistent signing by the same authority and accurate boot measurement matching. System upgrades involve updating the boot measurement to enable access to the user data partitions.
Security consideration
The existing framework guarantees that the initial phase (UKI file) remains immutable, with only this phase capable of decrypting the drive’s encrypted data. Indeed there is no pivoting into another system like in the traditional Linux boot process. This design choice ensures that the system remains a single component, with the UKI file acting as the sole point of entry for the system.
Shifting to a different image would have introduced potential security vulnerabilities and constraints:
- The current Systemd tools lack the capability to assess another rootfs/file.
- There is an absence of mechanisms to incorporate PCR with hash checksums of bespoke files in the expanded PCR banks within systemd.
- The inability to evaluate a secondary phase means any alterations in this stage could remain undetected during operation.
Also, implementing measurements for a second phase would significantly complicate the update process, as each version (A/B, Recovery) would require corresponding updates and measurements for every file involved in the transition.
An alternative approach involves maintaining a singular initial phase, which would entail measuring all subsequent stages. However, this concept remains a topic of ongoing debate without any concrete solutions thus far.
A concrete example: should a hacker remotely access the system without measures in place for the transitioned stage, they could alter the entire rootfs during operation without detection. In contrast, by leaving the first stage unaltered in the current method, modifications to the rootfs are prevented.
Learn More
Trusted boot is one of many recommended security techniques — but it’s absolutely critical to ensuring you can trust the integrity of your device, particularly when it’s deployed in the field.
We’ve only 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.
- 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 for yourself.