Trusted Boot features within redpesk OS
One of the increasingly requested features in embedded systems is to improve the security of an operating system depending either on the hardware or the software. Indeed, the IoT.bzh team is currently working on some additions of hardware security features like Trusted Boot in redpesk OS images for the following boards:
- ARM64
- Emulation
- ARM TrustZone image with QEMU
Although these additions are still under development, the IoT.bzh team can implement more features on demand.
Understanding essential technical concepts
Trusted Boot
Highly known as the mandatory feature to have a root of trust on an operating system, the Trusted Boot is a security framework that aims to ensure the integrity of a system from power-on to operating system load. It does this by using a variety of security methods, including the Secure Boot, the Measured Boot and the Verified Boot.
The Trusted Boot is often implemented using a Trusted Platform Module (TPM), which is a secure chip that can be used to store cryptographic keys and perform other security functions. The TPM can be used to verify the authenticity of firmware, operating system, and other critical software components.
Secure Boot
The goal of the Secure Boot is to enforce the boot phase to prevent as many attacks as possible. Its primary purpose is to ensure that only authorized and digitally signed software components are allowed to run during the startup process. This helps protect the system from loading any potentially harmful or unauthorized software.
It works by using cryptographic techniques. Each piece of software that is loaded during the boot process has a unique digital signature. Before executing any software, the Secure Boot checks these signatures to confirm they are valid and match the trusted signatures from the system manufacturer. If a signature is not recognized or has been tampered with, Secure Boot will prevent the software from running. In essence, the Secure Boot acts like a security checkpoint at the very beginning of a system’s startup, ensuring that only verified and safe software can proceed, which significantly reduces the risk of malicious programs taking control of the system.
Verified Boot
The Verified Boot is a specific type of the Trusted Boot that is used on ARM SoC based boards. It uses digital signatures to verify the authenticity of the bootloader and kernel that are loaded during the boot process. If the bootloader or kernel is not signed by a trusted authority, the boot process will be halted. In redpesk OS, the Verified Boot is used within the U-Boot bootloader.
Measured Boot
Another security feature called Measured Boot creates a hash of some critical firmware and operating system that are loaded during the boot process. This hash can then be used to verify the integrity of the system at a later time.
Measured Boot can be used to detect malware that has been injected into redpesk OS after it has booted up. It can also be used to verify the integrity of the system before allowing it to connect to a network or perform other sensitive operations.
Trusted Boot on x86 systems (64 bits)
There are different implementations of the Trusted Boot on various architectures. On x86_64 systems (Intel), the UEFI firmware (Unified Extensible Firmware Interface) is responsible for implementing the Secure Boot. UEFI Secure Boot (SB) is a security feature that verifies the trustworthiness of code initiated by a UEFI firmware, safeguarding against potentially harmful code execution in the early stages of the boot process, prior to the loading of the operating system. SB operates by utilizing cryptographic checksums and signatures for each program loaded by the firmware. It checks the program’s integrity and authenticity before permitting execution.
The UEFI firmware verifies the digital signature of executable files at startup, including the bootloader and operating system drivers. This ensures that only files signed by trusted keys can be loaded and executed on the system. When SB is active, any attempt to execute untrusted code is blocked, preventing unauthorized operations in the UEFI environment.
Microsoft made the Secure Boot feature mandatory on Windows 11 (with a TPM 2.0). For a use on redpesk OS, it depends on the board and the bootloader chosen. More information are available on the Red Hat documentation about some Secure Boot examples on x86 systems. We saw the UEFI but it could be possible to use the Secure Boot on Das U-Boot in a x86_64 SoC.
Secure Boot on ARM systems (64 bits)
On ARM architectures, the ARM TrustZone is a hardware implementation that provides a separate secure environment (referred to as the “trusted world”) that operates in parallel with the standard execution environment (referred to as the “non-secure world”). The system’s root of trust is guaranteed by this, which contains trusted firmware, encryption keys, cryptographic functions, and more. So the Secure Boot is a security process that incorporates cryptographic checks at various stages of the boot process in the Secure world. Its goal is to validate the integrity of all software images executed in the Secure world, preventing any unauthorized or maliciously altered software from running. The chosen cryptographic protocol is typically based on a public-key signature algorithm.
Unless hardware shack attacks can be ruled out, the root of trust must be in the on-SoC ROM. The on-SoC One-Time-Programmable (OTP) hardware, like eFuses, can be used to store unique values like public keys used in a SRK table - as shows the figure above - in each SoC during the device manufacture.
To defend against shack attacks, keeping Secure world resource execution within on-SoC memory locations is the simplest approach. By not exposing code and data outside the SoC package, it becomes substantially more challenging for an attacker to snoop or modify data values. The Secure Boot code is typically responsible for loading code into on-SoC memory, and proper ordering of authentication is crucial to avoid creating an opportunity for an attacker. A design that authenticates an image and then copies it into a safe memory location risks vulnerability to attack during the short window between the check and the copy process.
Please refer to the official ARM’s implementation for more technical facts on the Secure Boot.