How to Enable Secure Boot on Linux-Based Platforms

October 10, 2025

Blog

Secure boot is a fundamental security mechanism designed to protect devices from executing unauthorized or malicious code at startup. The problem it solves is simple but crucial: without validation, a device could load altered firmware or malware at startup, potentially compromising the entire system.

In this first article of our secure boot series, Zakaria, an engineer at The Embedded Kit, discusses the concepts and mechanisms associated with the secure boot process.

Secure Boot and Chain of Trust

The main principle of Secure Boot is based on the chain of trust: each step in the boot process verifies the integrity and authenticity of the next step before handing over control to it. This chain begins with an unalterable hardware-anchored root of trust. From this root, each subsequent component is verified to ensure that only trusted and cryptographically validated software runs on the device.

This process relies on a cryptographic triplet: the data (such as firmware), its digital signature, and the corresponding public key. The signature is generated offline with a private key, while the device stores the matching public key. During boot, the public key is used to check that the data matches the signature, proving both its authenticity and integrity.

Many industrial sectors leverage secure boot, such as energy smart grids, mobile asset tracking, and many more, where Linux devices are in public areas or within reach of possible malevolent people.

In this article, we will focus on embedded Linux systems with ARM processors.

Core Steps

We are now going to look at each step of the boot sequence of an embedded device, starting from the first executed firmware to the filesystem mounting, as described in the following diagram:

1. Bootloader Authentication

The first step is where the ROM code, residing in an untampered Read-Only memory of the silicon chip, does the authentication of the bootloader. Chips generally can do that using a public key. Chip vendors provide all necessary instructions about the process, sometimes under Non-Disclosure Agreements (NDA), and tools.

A common pattern of how the ROM code authenticates the bootloader is as follows:

• At manufacturing time: The SHA256 hash of the ROOTKEY (ROOTKEY-hash) must be injected into the chip, into a One-Time Programmable (OTP) memory segment.
• At boot time, the ROM code:
• verifies if the ROOTKEY matches ROOTKEY-hash;
• Then, using ROOTKEY, verify if the bootloader and its signature match.

If any of these verifications fail, then the ROM code stops the boot process, thus preventing any unauthenticated bootloader from executing.

2. FIT & Kernel Verification

When the bootloader starts, it often relies on a Flattened Image Tree (FIT) image to securely load and verify the kernel. A FIT image is a structured container format that can bundle together the kernel, device tree blobs (DTBs), Ramdisk, and cryptographic metadata. Each component inside the FIT image can be accompanied by a digital signature, which is verified by the bootloader using the trusted SWK1 public key contained in the authenticated bootloader.

3. Root Filesystem Integrity

Once the kernel is authenticated and running, the next step is to ensure the integrity of the root filesystem. The kernel may use the dm-verity feature to authenticate the read-only partitions of the system. It works by storing a hash tree of the filesystem blocks, allowing the kernel to detect any modification or corruption during runtime. The public key (SWK1), already verified by the bootloader, is passed to the kernel and used to validate the root filesystem’s integrity data.

Conclusion

Secure Boot establishes a chain of trust that starts from the ROM code, extends through the bootloader, kernel, and finally the root filesystem.

However, this trust extends only to the components within the secured scope. Running binaries or scripts from unprotected filesystem partitions bypasses authentication and effectively breaks the Secure Boot mechanism.

To maintain long-term security, systems must also support key revocation and key rolling, enabling compromised or outdated keys to be replaced. The details of how the ROM code authenticates the first bootloader stage vary significantly by chip vendor, and vendors typically provide dedicated signing utilities as part of their ecosystem.

This article is part of a series brought to you by The Embedded Kit team. At The Embedded Kit, we develop software tools and frameworks designed to streamline and accelerate embedded software development. Among our offerings is Welma, a Yocto-based Linux distribution built for reliability, scalability, and secure deployment in embedded environments, which already integrates a secure boot mechanism. To learn more about Welma and explore our full suite of tools, visit our website theembeddedkit.io.