Secure Boot for IMXRT processor

[Kevin_Kunnel]

Hi,

I'm working on enabling secure boot for IMXRT processor.

As per our design we have 3 boot images including our custom bootloader. I would like to implement the secure boot extending till the application image with the chain of trust through all three boot stage images.

Please answer the below queries in this regard.

1. If the SRK hash is fused, does the processor always try to authenticate the primary image being loaded, without any further configuration ? (Board in Open configuration)

2. To extend the chain of trust, I have read about using HAB library and RVT. Where do I find the HAB library ? Does it need to be builded along with bootloader ? Or is it part of the boards shipped form NXP by default ?

3. How the RVT configurations to be done ? Does it require individual calls for each images to be authenticated ?

Thanks,

Kevin

[Kevin_Kunnel]

Hi,

Thanks for the response.

I have already gone through the applications note AN12681.

My major concern is on authenticating multiple images to form the chain of trust ?

I got from some investigation that ROM vector table should be used with HAB APIs.

Or if all the images are signed separately with each of them having its own CSF, still does it require RVT configuration ?

If yes could you provide some more details on configuring RVT for IMXRT MCU

Thanks

[jeremyzhou]

Hi,
1) My major concern is on authenticating multiple images to form the chain of trust ?
-- Regarding your purpose, in my experience, I'd usually recommend the customer to combine multi image files via editor prior to generating the boot image, in another word, in the below figures, the application partial can consist of muli application demo code, such as secondary bootloader, primary application, etc.

In further, all these image files will be authenticated during boot up.
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[Kevin_Kunnel]

Hi Jeremy,

I have a confusion regarding your proposal.

Could you confirm if the below steps will work.

1. Create .csf file with authenticate data contains blocks from multiple image files

2. create csf.bin file using cst tool

3. append the csf.bin to primary image.

4. ivt of the primary image should contain the address of csf data.

5. now flash all three images.

6. flash the srk fuse data as well.

Now will the secure boot works fine ?

[jeremyzhou]

Hi，
Thanks for your reply and let me clarify it.
In general, the application area only has an application code, however, the application code is able to contain multi-application codes (as the below figures show), for instance, secondary bootloader, primary application, etc.

As I mentioned before, it can combine multi-image files via the editor, but keep in mind, it needs to put the application codes in right place, as these application codes' begin address is specific.
After combining multi-image files into an application image, then use the NXP-MCUBootUtility to implement the Authenticated boot as the https://www.nxp.com/webapp/sps/download/mod_download.jsp?colCode=AN12681&appType=moderated
demonstrates.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

1）Is this an error on my side or is the support for this wizard simply missing in LittleVGL? If so, will this be fixed in future versions?
-- The SDK wizard hasn't provided the LittleVGL option until now, and I'll report the drawback in the next round of Field Trial.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Whether you want to know the MCU that is able to replace the MIMXRT1052DVL6B directly, if yes, you can consider the MIMXRT1061DVL6B and MIMXRT1061DVL6B.
If you have any further questions about it, please feel free to contact me.
If you do not have one, would you please help to close this Case? Then you'll receive a survey in a moment and please fill it out.

[Kevin_Kunnel]

Hi Jeremy,

Thanks for the response.

I have a different use case.

In production phase, most often the application binary will get regular OTA updates. But there I do not want to touch the bootloader part.

Hence I prefer a separate and individual signature for the application binary.

And another separate signature for the bootloader binary.

As per my understanding, once SRK hash is fused, the hab will try to authenticate the primary image which is the bootloader.

Once the authentication is successful, It jumps to Application code, This also has to be authenticated against its signature.

Could you check if, having a boot header and CSF part in application binary also, is enough to trigger its authentication ?

In the secure boot guides, I see that the flashloader and the application binaries are signed separately and are expected to be authenticated by hab.

[Kevin_Kunnel]

Hi Jeremy,

Thanks for the suggestion.

But as per the design of our project, we have to keep the three boot images separate due to some specific requirements.

Hence could you provide details on how I can configure to authenticate all three images, one by one, during boot up.

I have another query with respect to signed image creation.

When I use elftosb tool to create signed image with my .srec file, The IVT part is not having proper values or mostly gets filled by zero.

Could you guide me how this can be corrected while creating the signed image.

I also have FCB data which configures the flex_spi nor. And i want it also tgo be part of the image header.

How can I provide to .bd file ?

Does it require any update in the .bd file ?

I have attached the zipped .bd file currently being used to sign my first image.

Thanks

[jeremyzhou]

Hi,
Thanks for your reply.
1) Hence could you provide details on how I can configure to authenticate all three images, one by one, during bootup.
-- No, I'm afraid that the HAB secure boot support to authenticate multiple images separately.
3) According to the authenticating process as the AN12681 shows, the FCB data doesn't participate in this process.

Hope this is clear.
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jeremyzhou]

Hi,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To provide the fastest possible support, I'd highly recommend you to refer to the application note: https://www.nxp.com/webapp/sps/download/mod_download.jsp?colCode=AN12681&appType=moderated
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------