Secure Boot on Torizon OS
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:
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.
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
Torizon OS support is limited to a partial implementation of the BCoT. The sub-section tables provide a granular description of supported and missing components and features.
Security Protections
| Toradex SoM | U-Boot signing | U-Boot hardening 1 | Kernel FIT image signing | Root filesystem signing | Container images signing |
|---|---|---|---|---|---|
| Apalis iMX6 | yes | yes | yes | yes2 | Coming soon |
| Apalis iMX8 | yes | yes | yes | yes2 | Coming soon |
| Colibri iMX6 | yes | yes | yes | yes2 | Coming soon |
| Colibri iMX6ULL | yes | yes | yes | yes2 | Coming soon |
| Colibri iMX7 | yes | yes | yes | yes2 | Coming soon |
| Colibri iMX8X | yes | yes | yes | yes2 | Coming soon |
| Verdin AM62 | yes | yes | yes | yes2 | Coming soon |
| Verdin iMX8M Mini | yes | yes | yes | yes2 | Coming soon |
| Verdin iMX8M Plus | yes | yes | yes | yes2 | Coming soon |
Device Features
| Toradex SoM | Build image | Sign image | Install image | Close device |
|---|---|---|---|---|
| Apalis iMX6 | yes | yes | yes | yes 3 |
| Apalis iMX8 | yes | yes | yes | yes 3 |
| Colibri iMX6 | yes | yes | yes | yes 3 |
| Colibri iMX6ULL | yes | yes | yes | yes 3 |
| Colibri iMX7 | yes | yes | yes | yes 3 |
| Colibri iMX8X | yes | yes | yes | yes 3 |
| Verdin AM62 | yes | yes | yes | yes3 |
| Verdin iMX8M Mini | yes | yes | yes | yes 3 |
| Verdin iMX8M Plus | yes | yes | yes | yes 3 |
Device Update Capabilities
| Toradex SoM | OS updates | Application updates | Bootloader updates | Offline updates |
|---|---|---|---|---|
| Apalis iMX6 | yes | yes | yes 4 | yes |
| Apalis iMX8 | yes | yes | yes 4 | yes |
| Colibri iMX6 | yes | yes | yes 4 | yes |
| Colibri iMX6ULL | yes | yes | yes 4 | yes |
| Colibri iMX7 | yes | yes | yes 4 | yes |
| Colibri iMX8X | yes | yes | yes 4 | yes |
| Verdin AM62 | yes | yes | yes 4 | yes |
| Verdin iMX8M Mini | yes | yes | yes 4 | yes |
| Verdin iMX8M Plus | yes | yes | yes 4 | yes |
Tools
| Toradex SoM | Yocto Project/OE | Toradex Easy Installer | TorizonCore Builder | Torizon Cloud 5 |
|---|---|---|---|---|
| Apalis iMX6 | yes | partial 6 | In progress 7 | - |
| Apalis iMX8 | yes | partial 6 | In progress 7 | - |
| Colibri iMX6 | yes | partial 6 | In progress 7 | - |
| Colibri iMX6ULL | yes | partial 6 | In progress 7 | - |
| Colibri iMX7 | yes | partial 6 | In progress 7 | - |
| Colibri iMX8X | yes | partial 6 | In progress 7 | - |
| Verdin AM62 | yes | partial 6 | In progress 7 | - |
| Verdin iMX8M Mini | yes | partial 6 | In progress 7 | - |
| Verdin iMX8M Plus | yes | partial 6 | In progress 7 | - |
Footnotes
-
Feature availability starting from Torizon OS 7 ↩
-
U-Boot hardening is discussed in the introductory section Toradex Secure Boot Implementation. Read it to learn more. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
Easy Installer isn't capable of burning fuses without customization. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
Bootloader updates will require you to push a signed bootloader to the Torizon Cloud using TorizonCore Builder. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
There are currently no services in the Torizon Cloud related to Secure Boot, such as key management, among other possible services. Nonetheless, all existing services such as updates, device monitoring, among others are expected to work. ↩
-
Easy Installer doesn't support a signed bootloader, therefore, once fuses are burned, you cannot easily load it via recovery mode. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
The workflows for secure boot, encryption and TPM integration work only using Yocto Project as of today. We are working on integrating these workflows into TorizonCore Builder. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9