Article by : Mohamed BELOUARGA & Fabien Lahoudere

The world is becoming more and more connected, and millions of devices are developed to be connected either to servers or to each other. This hyper connectivity comes with many threats and  Linux-based embedded systems are not exempt from them.

In this article, we will discuss a technique that adds security to embedded Linux devices, but the reader should be aware that this method does not protect embedded Linux devices from all threats. 

The reader should know that the author is an embedded Linux engineer and not a cybersecurity expert.

What is a secure boot?

Secure boot is all about implementing a trust chain between different software components of an embedded Linux device. This chain of trust is implemented to prevent the devices from running corrupted software, or software that does not originate from the device manufacturer.

This chain of trust is, in fact, a layered verification process that will identify the origin of these software components

First the ROM code verifies that the bootloader comes from the manufacturer, then the bootloader verifies that the Linux kernel also comes from the manufacturer before launching it and finally the kernel verifies that the ROOTFS (the application) comes from the manufacturer.

We will see below how this trust chain works – or what we call secure boot-, and how to implement it.

How to implement secure boot

Securing the bootloader

This part is hardware dependent and realized by hardware and ROM code. The ROM code verifies that the bootloader is from the manufacturer, by checking its signature. The signature of the bootloader is usually its hash encrypted by a private key.

If the signature is corrupted, the ROM code does not launch the bootloader, thereby the device doesn’t boot.

Securing the kernel

After its verification, the ROM code launches the bootloader.

The bootloader initializes just enough hardware (at least SDRAM and serial console) to boot the kernel and to load the kernel as well as the device tree into RAM.

The bootloader checks kernel and the device tree signature’s (and other binaries if necessary), before booting the kernel.

If binaries have to be checked, a FIT image containing all these binaries, can be used to gain some efficiency in this process.

Securing the ROOTFS

To secure the ROOTFS, it is preferable to use a read-only ROOTFS and take advantage of a feature provided by the kernel, called DM-verity.

Dm-verity uses a hash tree to ensure that the ROOTFS is not corrupted. Layer0 of the hash tree contains the ROOTFS hashes -one hash for every 4k.

More detail in the schema below.

• Layer 0 contains hashes of the ROOTFS, one hash for every 4kB of memory
• LAYER 1 contains hashes of LAYER 0
• LAYER 2 hashes of LAYER 1 …
• Until we finish with one hash called root hash.

In order to use DM-verity on the ROOTFS partition, it is easier to use an InitRamFS that launches DM-verity on the partition of the ROOTFS before switching to the ROOTFS.

The InitRamFS (that contains the root hash) should be added to the FIT image and should also be signed.

If DM-verity detects a corruption in the ROOTFS or if the root hash changed, the feature generates a kernel panic, which blocks the launch.

Example of imx8

To illustrate some hardware dependent aspects of the secure boot, we will take imx8 as an example:

CST tools

Before trying to implement secure boot on imx8, we need to generate some private keys that will be used to sign the binaries. NXP provides CST tools (Code Signing Tool) that generates privates and public keys, and allows us to sign the bootloader and other binaries.

Fuses and CAAM

Imx8 has a module called CAAM (Cryptographic Acceleration and Assurance Module) that will be used to speed up the verification of all signatures. Imx8 also has some registers called One-Time Programmable registers (eFuse).

In order to enable signature verification, SRK_HASH eFuses must be programmed with the generated public keys hashes, and to lock the card, another eFuse should be programmed.

All these elements will be used to implement the HAB (High Assurance Boot): the imx secure boot.

ROM code

At the boot time, The ROM code verifies if the SRK_HASH eFuses are programmed. If it is the case, it will verify the signature of the bootloader (SPL + ATF + OPTEE + U-boot). Depending on the card being locked or not, the rom code will continue the booting process, or will stop it:

The Rom code verifies an image, as the picture below shows:

Note: Other eFuses also need to be programmed to properly implement Secure Boot. For example, the eFuse that disables the JTAG.

Imx-boot

After verifying its signature, the ROM code launches the bootloader (SPL then ATF and OPTEE then U-boot).

U-boot should be configured to check the signature of the FIT image if the HAB is activated. The verification of the signature of the FIT image is done by making some calls to the ROM code (through ATF).

U-boot will then behave like the ROM code in the previous step: if the card is locked and the signature is corrupted, it will stop the booting process.

Fit Image and ROOTFS

The Fit Image contains at least three elements: the kernel, the device tree and the InitRamFS.

When U-boot checks the signature of the Image: it extracts these elements and launches the kernel.

When the kernel is launched with the InitRamFS, this last one applies DM-verity on the ROOTFS partition, and it gives the kernel the root hash. Finally, the kernel continues booting on the ROOTFS.

These different steps constituted the secure boot for imx8:

The curious reader can find more documentation about HAB implementation on internet, this second part of the article was not meant to explain the whole HAB details, but only to show the relationship between secure boot and the hardware.