Secure boot

[Jayashree]

I am currently working on implementing the HSE secure boot process, specifically focusing on the third step outlined in the BSP 40 user manual, where U-Boot authenticates the Kernel image. I would like to clarify whether HSE APIs are utilized during this authentication step, or if it is both safe and secure to rely entirely on U-Boot for verifying the Kernel image using .its file and FIT image.

[alejandro_e]

Hello @Jayashree,

I am assuming you are using the S32G3 chip. 

After analyzing the ATF/u-boot code for BSP40, I can conclude that the HSE API is not used directly to verify the kernel. However, in this use case u-boot can be trusted to verify the kernel image, this is because it itself needs to be previously authenticated by the HSE FW, this means that the FIP image (which includes ATF and u-boot) needs to be signed to be loaded and executed. This prevents execution of unwanted FIP images and this in turn prevents the execution of unwanted kernel images. 

As you probably know, in the steps below the section you mentioned you can see all the information needed to sign the FIP image.

Let me know if you have more questions

[Jayashree]

Yes thank you for the clarification, I further wanted to know 

1. Steps to Authenticate U-Boot Using HSE Firmware

   • Is the authentication of U-Boot done using SMR and CR configurations?
   • Additionally, could you clarify which core (Cortex-A or Cortex-M) is responsible for performing these configurations? And how?

2. Secure Boot Flow and Code Reference

   • In the context of the secure boot flow, as outlined below:
     1. BootROM passes control to HSE firmware.
     2. HSE firmware authenticates the TF-A (Trusted Firmware-A) FIP, including U-Boot.
     3. U-Boot authenticates the Kernel image.
   • I would like to understand which of these three steps is related to the code reference in the link below:
     GitHub Link to hse-secboot.c

[alejandro_e]

Hello @Jayashree,

Please find my answers to your questions:

Q1) Is the authentication of U-Boot done using SMR and CR configurations?

A1) The SMR/CR Tables may be used in the process. The details of the process are cannot be shared.

Q2) Additionally, could you clarify which core (Cortex-A or Cortex-M) is responsible for performing these configurations? And how?

A2) The verification is performed by core HSE_ M7 core as you can see here [page 3 AN13750, Enabling Multicore Application on S32G2 using S32G2 Platform Software Integration, Rev. 0, 11/2022]:

Q3) I would like to understand which of these three steps is related to the code reference in the link below:

GitHub Link to hse-secboot.c

A3) That function is part of an example, which is used to format the key catalogs or setup the secure boot, therefore it is not used during the secure boot process.

You can learn more about it in page 85 of the BSP42 user manual:

To know where exactly the function you shared is used, I would recommend adding a printk inside the function and monitor the system messages.

Let me know if this information answers your question.

[Jayashree]

Thank you for the reply

In the U-Boot Verified Boot.txt, it says
The public key can be stored in U-Boot's CONFIG_OF_CONTROL device tree in
a standard place. Then when a FIT is loaded it can be verified using that
public key.

Is there any way the public key can be stored in secure key storage (HSE secure storage) rather than in the host system itself (U-Boot) for security purposes?
If possible will the u boot command bootm fetch it from HSE secure storage? what is the alternative to increase security?

[alejandro_e]

Hello @Jayashree,,

That functionality was not developed by NXP, therefore it is not supported by us. It is part of u-boot itself. However, in general you should not worry about sharing your public key, as the name suggest, it is meant to be available for the public, you should only worry about your private key.

If you have more questions about this topic please create a new post, since in the past you selected one of my answers as an accepted solution this post is closed and I wont received proper notifications.

Best regards,

Alejandro 

[Jayashree]

For bsp43 where bl2 and fip are flashed seperately,
As per the secure boot flow:
1.BootROM passes control to HSE Firmware.
2.HSE Firmware authenticates TF-A's Boot Loader Stage 2 (BL2).
3.BL2 authenticates the remaining BL3x components: BL31 (Secure Monitor), BL32 (Trusted OS), and BL33 (U-Boot).
4.U-Boot authenticates the Kernel image.
I would like to understand:
Who exactly performs step 3 (i.e., the authentication of BL31, BL32, and BL33)? Is it fully handled by BL2?
How can I verify that this authentication step is actually taking place?
(e.g., any logs, debug prints, or build-time flags that confirm successful verification?)

[alejandro_e]

Hello @Jayashree,

Please create a new post for me to receive proper notifications about this topic. since it is an old post it is not updated internally. You can add the link to this ticket or my username to ensure I continue with the topic if that is what you prefer.

Thanks.