Secure Boot on Torizon OS

info

Secure Boot is an Early Access feature. It means that:

• Breaking changes may be introduced at any given time, irrespective of the Toradex Embedded Linux Support Strategy.
• Software support and functionality are limited.

Introduction

This article presents an overview on Secure Boot implementation with Torizon OS.

To learn how to integrate Secure Boot with Torizon OS, read our dedicated article:

• How to Integrate Secure Boot on Torizon OS

What is Secure Boot?

Secure Boot, for the sake of this article, is the process of booting an image that comes from a valid trusted source (authenticity check) while ensuring it has not been modified in any way (integrity check). The actual artifact used for booting - the Torizon OS image with Secure Boot support enabled - is referred to as the Secure Boot image.

Signing software components is a means to ensure authenticity and integrity, and thus to implement Secure Boot. The individual or company releasing the software has a securely stored Private Key that signs software artifacts at build time, and the corresponding Public Key is used to validate those artifacts at runtime on the devices.

Since the artifacts must be sequentially validated during the boot process, it is common to refer to a Chain of Trust (CoT). In summary, it is a process where one bootable artifact possesses the public key and thus is capable of validating the integrity and authenticity of the next one that will be loaded by the system. For example, the ROM firmware has the bootloader public key, and it validates it before booting, and in turn, the bootloader validates the kernel FIT image, which then validates the root filesystem.

To ensure that the first stage of installable software is signed, the corresponding public key must be stored on the device in a way that it cannot be changed, which is usually done by executing one-time operations on Efuses. The process of burning the Efuse that effectively enables Secure Boot is often referred to as closing the device.

Secure Boot in Other Contexts

Depending on the source and context, some texts refer to Secure Boot, Verified Boot, Measured Boot, and Chain of Trust with different technical scopes and names. In this article's context, Secure Boot is a generic and embracing term that focuses on the validation of authenticity and integrity of embedded Linux systems, as already explained in the previous section. Related terms with different meanings are often described below, although there may even exist others:

• Secure Boot as implemented by Microsoft, often referred to as UEFI Secure Boot, and commonly employed in x86 consumer devices has been the first implementation of Secure Boot and it targets only PCs. It is a method for validating bootloader and kernel artifacts with an asymmetric key. The term became more widely used and the original scope of UEFI and PC became a subset of broader Secure Boot definitions adopted in other places.
• Verified Boot as implemented by Android and commonly used in smartphones, including the Android Verified Boot (AVB) reference implementation, is comparable to Secure Boot from the standpoint that both aim to secure the boot process. The Verified Boot as defined by Android includes the bootloader and boot partition, and also some filesystem partitions, by establishing a Chain of Trust.
• Verified Boot in other sources - and a more generic definition - is the process of using asymmetric cryptography to verify the boot's integrity and authenticity. From this standpoint, Secure Boot implementations that rely on asymmetric cryptography can be considered a type of Verified Boot.

What Secure Boot Isn't

Encryption isn't in the scope of Secure Boot as a mandatory component, although they can both be employed together. Anyone with access to an unencrypted secure boot image can check its contents. It is a topic outside the scope of this article.

The integrity and authenticity of the RAM are not covered by Secure Boot, and after something is loaded to the RAM, it isn't protected by Secure Boot against attacks.

Secure Boot is a broad topic and it isn't in the scope of this article to explain it in-depth.

Toradex Secure Boot Implementation

This section provides a high-level overview of the Secure Boot implementation carried out by Toradex. A phased implementation is being adopted to incrementally secure the system components over time, and thus different CoT coverage levels are defined specific to this implementation:

• Minimal Chain of Trust (MCoT): only the first link of the chain is present whereby the signed bootloader is validated by the ROM code.
• Basic Chain of Trust (BCoT): the chain extends to the second link of the chain such that the kernel artifacts are signed and validated as well; additionally, U-Boot is hardened to enhance security (see below).
• Extended Chain of Trust (ECoT): the chain is further extended to encompass most of the root filesystem but it still does not cover container images.
• Full Chain of Trust (FCoT): in addition to the ECoT components, the container images are also validated.

Generally speaking, the hardening modifications to U-Boot included in the BCoT coverage level intend to:

• Prevent tampering of the running software (i.e. to U-Boot itself).
• Prevent execution of unsigned software.
• Prevent injection of kernel arguments.

For a detailed description of these modifications, refer to article Security Hardening of U-Boot.

tip

Some hardware vendors and secure boot implementations only cover a limited version of the BCoT. One example is the UEFI Secure Boot by Microsoft.

Make sure to consider the practical differences when comparing the Toradex Secure Boot with other implementations.

Support Status and Limitations

This section summarizes the status of the Secure Boot implementation in Torizon OS, as well as related features and tooling commonly used alongside it. By consolidating all this information here, we aim to provide users with a comprehensive overview of the aspects our security solution currently addresses and those planned for future coverage.

The legend below is used in the following feature tables:

• ✅ feature is supported
• ❌ feature is not supported
• – feature is not available / cannot be supported (usually because it requires hardware capabilities not provided by the particular SoM)
• ⌛ feature is under (or scheduled for) development
• 📅 feature is planned for the future

info

Should your project require features that are not yet available, you are encouraged to contact us at support@toradex.com.

Secure Boot Features

The table below provides the status of the Secure Boot features. The features actually present on a given Torizon OS image will depend on the configuration set during build, but Toradex provides two predefined configurations that both Yocto and non-Yocto users (those taking a prebuilt OS image from Toradex) can utilize: one configuration offers BCoT coverage and another gives ECoT coverage level. The features marked with (*) are present both in BCoT and ECoT, while those marked with (**) are present only in ECoT.

Device → Feature ↓	Aquila iMX95	Aquila AM69	Verdin iMX8M Mini	Verdin iMX8M Plus	Verdin iMX95	Verdin AM62	Verdin AM62P	SMARC iMX8M Plus	SMARC iMX95	Apalis iMX6	Apalis iMX8	Colibri iMX6	Colibri iMX6ULL (eMMC)	Colibri iMX7 (eMMC)	Colibri iMX8X
Bootloader authentication (*)	⌛	✅	✅	✅	✅	✅	✅	✅	⌛1	✅	✅	✅	✅	✅	✅
Bootloader hardening2 (*)	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
Kernel image authentication (*)	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
Root Filesystem authentication (**)	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
Container images authentication	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅

Related Low-level Security Features

The features below are offered by meta-toradex-security and, at the moment, are available to Yocto users only (see the section on TorizonCore Builder ahead for more information).

Device → Feature ↓	Aquila iMX95	Aquila AM69	Verdin iMX8M Mini	Verdin iMX8M Plus	Verdin iMX95	Verdin AM62	Verdin AM62P	SMARC iMX8M Plus	SMARC iMX95	Apalis iMX6	Apalis iMX8	Colibri iMX6	Colibri iMX6ULL (eMMC)	Colibri iMX7 (eMMC)	Colibri iMX8X
TEE
OP-TEE	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	📅3	✅	–4	✅	📅3
OP-TEE firmware TPM	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	📅3	✅	–4	✅	📅3
OP-TEE firmware PKCS#11	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	📅3	✅	–4	✅	📅3
Data storage5 / encryption6
Data partition5	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
Data-at-rest encryption (CAAM7 backend)	–	–	✅	✅	–	–	–	✅	–	✅	✅	✅	–	✅	✅
Data-at-rest encryption (TPM backend)	⌛8	✅8	✅8	✅8	✅8	✅8	✅8	✅8	✅8	✅8	✅8	✅8	✅8	✅8	✅8
Data-at-rest encryption (TEE backend)	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	📅3	✅	–4	✅	📅3

Related Torizon OS Support Features

The table below lists a series of Torizon OS features that support workflows primarily associated with Secure Boot:

Device → Feature ↓	Aquila iMX95	Aquila AM69	Verdin iMX8M Mini	Verdin iMX8M Plus	Verdin iMX95	Verdin AM62	Verdin AM62P	SMARC iMX8M Plus	SMARC iMX95	Apalis iMX6	Apalis iMX8	Colibri iMX6	Colibri iMX6ULL (eMMC)	Colibri iMX7 (eMMC)	Colibri iMX8X
Fusing9
Fusing At-scale (production)	⌛	📅	✅	✅	⌛	📅	📅	⌛	⌛	✅	✅	✅	✅	✅	✅
Fusing via Online Update	⌛	📅	✅	✅	⌛	📅	📅	⌛	⌛	✅	✅	✅	✅	✅	✅
Fusing via Offline Update	⌛	📅	✅	✅	⌛	📅	📅	⌛	⌛	✅	✅	✅	✅	✅	✅
Updates
Custom Bootloader Updates10	⌛	⌛	✅	✅	⌛	✅	✅	⌛	⌛	✅	✅	✅	✅	✅	✅
OS Updates for BCoT images	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
OS Updates for ECoT images	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
In-field Upgrade11: unsigned → BCoT	⌛	📅	✅	✅	⌛	📅	📅	⌛	⌛	✅	✅	✅	✅	✅	✅
In-field Upgrade: unsigned → ECoT	⌛	📅	✅	✅	⌛	📅	📅	⌛	⌛	✅	✅	✅	✅	✅	✅
In-field Upgrade: BCoT → ECoT	⌛	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

Related TorizonCore Builder Features

TorizonCore Builder allows users to customize a binary Torizon OS image. Support for customizing different aspects of Secure Boot images is being introduced incrementally, as shown in the following table:

Device → Feature ↓	Aquila iMX95	Aquila AM69	Verdin iMX8M Mini	Verdin iMX8M Plus	Verdin iMX95	Verdin AM62	Verdin AM62P	SMARC iMX8M Plus	SMARC iMX95	Apalis iMX6	Apalis iMX8	Colibri iMX6	Colibri iMX6ULL (eMMC)	Colibri iMX7 (eMMC)	Colibri iMX8X
Re-sign Bootloader	⌛	⌛	⌛	✅	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Re-sign Kernel	⌛	⌛	⌛	✅	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Re-sign Root Filesystem	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Push Fuse Packages	⌛	⌛	✅	✅	⌛	⌛	⌛	⌛	⌛	✅	✅	✅	✅	✅	✅
Push Bootloader Packages	⌛	⌛	✅	✅	⌛	✅	✅	⌛	⌛	✅	✅	✅	✅	✅	✅
Push OS Packages (Kernel/Root Filesystem)	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
Customize Root Filesystem (BCoT)	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
Customize Root Filesystem (ECoT)	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Customize Splash Screen	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Customize Device-trees	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Customize Device-tree overlays	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Build out-of-tree Kernel Modules	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Customize Kernel Arguments	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛	⌛
Customize Data partition	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅
Customize Data-at-rest encryption	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅
Generate transitional image12 for ECoT	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅	📅

Related Torizon Cloud Features

There are currently no Torizon Cloud services related to Secure Boot, such as key management or similar features. Nonetheless, all existing services – including updates and device monitoring – are expected to function normally.

Footnotes

1. Support for bootloader authentication on the SMARC i.MX95 is currently available only for pre-production silicon versions (A0/A1); support for newer, production versions will be added soon. ↩

2. Bootloader hardening refers to a series of modifications to the bootloader to improve security, as described in Security Hardening of U-Boot. ↩

3. OP-TEE support is not yet implemented for the Apalis iMX8 and Colibri iMX8X. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

4. The iMX6ULL SoC does not support OP-TEE because there is no HUK (Hardware Unique Key) due to the lack of a CAAM (Cryptographic Acceleration and Assurance Module). ↩ ↩² ↩³ ↩⁴

5. Application data can be stored in a separate Data partition; learn more at README-data-partition.md. ↩ ↩²

6. Encryption is commonly used for protecting the data partition; learn more in the Encryption on Torizon OS article. ↩

7. CAAM is a piece of hardware available on NXP SoCs iMX6/7/8; it's not present on the NXP iMX6ULL or the iMX95; being NXP specific, it's not present on TI SoCs (AM6x). ↩

8. SoC does not have a TPM but users can add an external one or leverage the fTPM (firmware TPM) when supported. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵

9. Features to facilitate Fuse Programming for Secure Boot. ↩

10. Feature allows users to update the bootloader of their devices, as described in Custom Bootloader Updates; with Secure Boot, bootloaders delivered through updates are always custom, since they must be signed with the user's keys. ↩

11. Features to enable In-field Upgrades to Secure Boot. ↩

12. A transitional or intermediate image is needed to allow in-field upgrades enabling the Root Filesystem protection (part of ECoT); we have intentions to offer the ability to convert a normal ECoT image into an intermediate one via TorizonCore Builder, so users don't need to use Yocto to build their intermediate image. ↩