i.MX 93 Processor: Explaining Secure Boot Signing and Authentication Recently, legal regulations such as the Cyber Resilience Act (EU) and JC-STAR (Japan) are being established around the world. Secure boot is also included among these technical requirements, and you may have heard of it as an important function.
However, many users actually use Secure Boot without understanding how it works. Therefore, I would like to explain how it works using i.MX 93 Secure Boot (AHAB) as an example.
table of contents
i.MX 93 AHAB Signature and Authentication Mechanism
1. Containerizing the image
2. Add the public key and signature to the container
3. Authenticating Signed Containers
4. Authenticating Signed Containers in U-Boot
i.MX 93 AHAB Signature and Authentication Mechanism¶
This article explains how the i.MX 93 processor's Advanced High Assurance Boot (AHAB) signing and authentication works.
The i.MX 93 boot file is in a unique container format. Secure boot using AHAB adds a public key and signature to the container, and when the device boots, it authenticates the public key included in the container and verifies that the contents of the container have not been altered, preventing the launch of unauthorized software.
1. Containerize the image¶
Keita_Nagashima_0-1765854081919.png
Fig. 1 Containerizing an image¶
Images that i.MX 93's BOOTROM and U-Boot load into memory and use must be converted to container format beforehand.
Note
The image here refers to U-Boot-SPL, U-Boot, ATF, OPTEE, M-Core SW, Kernel, DTB, Ramdisk, and any other data you want to place in memory.
Details of the container format can be found in the System Boot chapter of the i.MX 93 Applications Processor Reference Manual .
To containerize the image, use imx-mkimage and the included tool called mkimage_imx8 .
When a container is generated, a Container Header is added to the beginning of the container file. This includes an ImageArray that collects the offset, size, hash value, etc. of each image, and a Signature Block where the public key and signature for secure boot are written. The Signature Block is generated in a mostly empty state.
Multiple images can be combined into one container, and the image data will be concatenated to the end of the container file.
2. Add public key and signature to container¶
Keita_Nagashima_1-1765854199747.png
Fig. 2 Adding a public key and signature to a container¶
To prevent unintended use of containers on i.MX 93 devices and to detect any alteration of the container contents, a public key and signature are added to the container using the Code Signing Tool (hereafter referred to as CST).
First, generate a Super Root Key (SRK).
The script ahab_pki_tree.sh included in the CST generates the CA and SRK1 to SRK4. The SRK consists of a pair of public and private keys, and the private key must be kept secret.
Using srktool included in the CST, an SRK Table is generated by concatenating the four public keys SRK1 to SRK4. At the same time, an SRK Hash, which is the SHA-256 of the SRK Table, is also generated. The SRK Hash is written to the SRK_HASH fuse of the i.MX 93 device.
The SRK should be preserved for the long term until the end of the i.MX 93 device lifecycle.
Next, cst in the CST will attach the public key and signature to the container.
The SRK Table generated earlier is written to the SRK Table field of the Signature Block.
The area from the beginning of the Container Header to the end of the SRK Table field is signed using one of the SRK private keys.
The signature data is written to the Signature field of the Signature Block.
3. Authenticating Signed Containers¶
Keita_Nagashima_2-1765854309584.png
Fig. 3. Signed container authentication¶
First, calculate the SHA-256 of the SRK Table on the container, and if it matches the contents of the SRK_HASH fuse on the i.MX 93 device, you can authenticate that the SRK Table is the same as the SRK used for signing.
Once the SRK Table is authenticated, the SRK public key and signature data contained in the SRK Table can then be used to verify whether the area from the beginning of the Container Header to the end of the SRK Table field has been altered.
Finally, if you can verify that the Container Header has not been altered, you can verify that the images have not been altered by comparing the hash value written in the ImageArray with the hash value of each Image.
4. Authenticating Signed Containers in U-Boot¶
The U-Boot command auth_cntr is used to authenticate signed containers in U-Boot.
https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L811-L815
auth_cntr When the command is executed, the do_authenticate function is called, which calls the authenticate_os_container function.
https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L400-L416
The authenticate_os_container function calls the ahab_auth_cntr_hdr and ahab_verify_cntr_image functions.
https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L330-L398
The ahab_auth_cntr_hdr function calls the ele_auth_oem_ctnr function. The ahab_verify_cntr_image function calls the ele_verify_image function.
https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L261-L278
https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L297-L309
The ele_auth_oem_ctnr and ele_verify_image functions send commands to ELE and receive results from ELE.
https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/drivers/misc/imx_ele/ele_api.c#L76-L104
https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/drivers/misc/imx_ele/ele_api.c#L134-L161
You can check the authentication result with the U-Boot ahab_status command. The main error codes are as follows:
Table 1 Major error codes for the ahab_status command¶
Error Code
What the error means
Situations in which the error occurs
ELE_NO_AUTHENTICATION_FAILURE_IND (0xEE)
No authentication was performed.
You tried to authenticate an unsigned container.
ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
The fuse SRK_HASH does not match the HASH in the SRK Table of the signed container.
- Attempting to authenticate a signed container on a device where nothing is written to the fuse SRK_HASH.
- An attempt was made to authenticate a container signed with an SRK that is not included in the SRK Table used when generating the FUSE SRK_HASH.
- The SRK table of the signed container has been rewritten.
- The SRK table for the signed container could not be loaded correctly (it was not written correctly in memory).
ELE_BAD_SIGNATURE_FAILURE_IND (0xF0)
The signature is incorrect.
- The signed region of a signed container has been rewritten.
- The signature of a signed container has been rewritten.
- One of the above could not be loaded correctly. (It was not written correctly in memory.)
ELE_BAD_HASH_FAILURE_IND (0xF1)
The image hash is different from the hash written in the image array.
- The image of the signed container has been rewritten.
- The signed container image could not be loaded correctly (it was not written correctly in memory).
Note
These error codes can be observed in the OEM Open state. In the OEM Closed state, the device stops when an error occurs, so no error codes are displayed.
This document is a reference for using NXP products.
For official specifications, please refer to the product manual and application notes.
Actual operation may differ from the contents described due to differences in various conditions, such as the version of the software used.
Not all functions have been verified, so please be sure to verify and test the product to suit your intended use.
Next time, I would like to explain how Secure Boot (AHAB) is implemented and works.
Article: i.MX 93 Processor: How to Implement Secure Boot - Practical Guide (Japanese blog)
=========================
We are currently unable to respond to comments in the " Comment " section of this post . We apologize for the inconvenience, but when making inquiries, please refer to " How to contact NXP with technical questions ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may contact the person in charge directly. )
Recently, legal regulations such as the Cyber Resilience Act (EU) and JC-STAR (Japan) are being established around the world. Secure boot is also included among these technical requirements, and you may have heard of it as an important function.
However, many users actually use Secure Boot without understanding how it works. Therefore, I would like to explain how it works using i.MX 93 Secure Boot (AHAB) as an example. i.MX Processors Security Japanese Blog
記事全体を表示
