Author: Dipl.-Ing. (FH) Holger Dengler, linutronix GmbH<\/p>\n
Today's embedded systems are increasingly exposed to attacks from various sources. Therefore, it is becoming ever more important that the code executed on these systems comes from trusted sources. Code integrity checks during the boot process are of central importance here, as almost all subsequent checks depend on which bootloader or Linux kernel is running on the system.<\/strong><\/p>\n Even before IoT and Industry 4.0 became widely discussed, the networking requirements for embedded systems were constantly growing. Use cases range from providing and aggregating operational data and remote maintenance access to the complete integration of a control component into a networked plant.<\/p>\n Ten years ago, serial interfaces were the only way to access a control system. Today, it's not uncommon for an embedded system to communicate with the outside world via more than one interface, such as Ethernet, Wi-Fi, Bluetooth, CAN, Modbus, or ZigBee. Each interface also increases the system's attack surface.<\/p>\n Many operating systems, such as Linux, used on embedded systems now offer effective measures for protecting these interfaces. However, these measures only work if the software provided by the manufacturer is also used.<\/p>\n The boot process is of central importance here, as it determines which Linux kernel is loaded. Since this task is handled by the bootloader, it is also crucial to pay attention to which bootloader is used after a system reset.<\/p>\n Although the boot process differs slightly in detail from platform to platform, the following steps are usually performed:<\/p>\n The bootloader and Linux kernel are loaded from non-volatile memory areas (e.g., NOR or NAND flash) (see Figure 1).,\u00a0PDF<\/a>).<\/p>\n In this process, usually only the integrity of the ROM code is ensured, as it originates from a read-only memory on the system-on-a-chip (SoC) itself. Many manufacturers of embedded system hardware offer code mechanisms in this ROM to verify the integrity of the bootloader using a cryptographic signature as soon as it is loaded. Similarly, all current bootloaders offer functions to also verify the Linux kernel and device tree using such a signature. This modifies the boot process of an embedded system:<\/p>\n Cryptographic methods are now used to ensure the integrity of not only the ROM code but also the bootloader and the Linux kernel\/device tree. Depending on the configuration, the embedded system will abort the boot process as soon as one of these integrity checks fails (see Figure 2).,\u00a0PDF<\/a>).<\/p>\n As shown in Figure 2 (see\u00a0PDF<\/a>As shown in the diagram, the bootloader's integrity check is ensured by the ROM loader. Since the ROM code varies from SoC to SoC, it's now time to illustrate the processes and procedures using a concrete hardware example. Many current SoCs also offer these features in one form or another and are equally suitable for implementation.<\/p>\n The i.mx7d from NXP, as one of the representatives of the i.mx family, offers a so-called High Assurance Boot, version 4 (HABv4), which allows the integrity of loaded images to be checked even before the actual bootloader is executed.<\/p>\n The integrity check is based on one of up to four SystemRoot Keys (SRKs) that are loaded with the image. This prevents arbitrary SRKs from being used as "\u201eRoot of Trust\u201c<\/em>\u00a0To prevent unauthorized access, the chip contains a One-Time Programmable Area (OTP) where the hash of the valid SRKs for this device is stored. The configuration of these hashes in the OTP fuses is the responsibility of the manufacturer. This determines which keys can be used to generate valid code signatures for this device (see Figure 3).,\u00a0PDF<\/a>).<\/p>\n Next, a CommandSequenceFileKey (CSFK) certificate and an ImageKey (IMGK) certificate are loaded. Both certificates must have a valid signature from the SRK being used.<\/p>\n HABv4 can be parameterized via a Command Sequence File (CSF). The sequence steps contained within it are highly security-relevant, which is why the integrity of this CSF must also be protected. To this end, HAB will verify the signature of the CSF with the CSFK certificate before execution (see Figure 4).,\u00a0PDF<\/a>).<\/p>\n The bootloader image is also signed by the manufacturer. After loading the image, the HAB will verify the integrity of the bootloader image using the IMGK certificate before handing control over to the bootloader as a final step (see Figure 5).,\u00a0PDF<\/a>).<\/p>\n The three HAB checks (SRK check, CSF check, and image check) now ensure the code integrity of the bootloader. This allows the bootloader to subsequently check and thus guarantee the integrity of the Linux kernel and device tree during the boot process. This procedure was previously presented in the article "Linux Secured Integrity Protects Against Network Attacks" (ESE Congress 2013, Holger Dengler).<\/p>\n As shown in Figure 3 (see\u00a0PDF<\/a>) shows that the HAB uses one of the available SRKs as \u201eRoot of Trust\u201c<\/em>. Using this foundation, all other certificates must be verifiable. Conversely, this means that the owner of the SRKs must sign the certificates for CSFK and IMGK, thereby authorizing their use in the boot process.<\/p>\n The bootloader (e.g., u-boot) also verifies the integrity of the Linux kernel using a certificate and its embedded public key. This certificate does not necessarily have to be signed by the SRK or the underlying CFSK or IMGK. Since the public key is integrated into the u-boot image during its creation, this certificate can also originate from a different key space.<\/p>\n Similarly, the Linux kernel also uses its own key for integrity checks of modules and, if necessary, parts of the root filesystem as "\u201eRoot of Trust\u201c<\/em>. As with the bootloader, this key can also originate from a different key space, since its integrity is ensured by the integrity of the entire kernel image.<\/p>\n This may seem confusing at first glance, but it offers maximum flexibility in creating a trust chain and the necessary public key infrastructure. Those who do not wish to utilize this freedom, or who prefer a simpler structure for the sake of clarity, can drastically reduce this complexity by using, for example, the IMGK in the bootloader and kernel image (see Figure 6).,\u00a0PDF<\/a>).<\/p>\n NXP's High Assurance Boot concept and the integrity checks of the bootloader (u-boot) and Linux kernel work hand in hand, enabling seamless integrity verification from reset to Linux userspace. The key spaces used can be adapted to specific requirements and circumstances. If board manufacturers, system providers, and end users need to use separate keys, this concept offers the necessary flexibility. If, to reduce complexity, the setup needs to be limited to a single key space, this can also be implemented without difficulty.<\/p>\n The integrity check of the code during the boot process thus becomes the robust, secure backbone of all further security efforts in the embedded system.<\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topic of Open Source \/ Embedded Software Engineering.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in the field of Open Source \/ Embedded Software Engineering is available.\u00a0here\u00a0<\/strong><\/a>Available for you to download free of charge.<\/p>\nLinux Secured Integrity<\/h2>\n
The boot process<\/h2>\n
\n
\n
Bootloader integrity check<\/h2>\n
Kernel integrity check<\/h2>\n
Key rooms and "Root of Trust"\u201e<\/h2>\n
Conclusion<\/h2>\n
\nOpen Source \u2013 our training & coaching<\/h2>\n
\nOpen Source \u2013 Expertise<\/h2>\n