Hi @mastupristi ,
I think the following method should be used for your case, since SNVS master key is provisioned by NXP and only the DCP module inside can access it, so you have to re-encrypt the image by the boot loader.
Please kindly refer to https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/release/25.06.00/ota_examples/_doc/encrypted... for more details.
Have a great day,
Kan
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
Hi @Kan_Li
Do you think I didn't follow the documentation when doing this?
Let's do this: try to get the board working in E-XIP yourself with a micro on which you have written 0b10 in the BEE_KEY1_SEL fuses.
But in the meantime, I want to explain what I do in more detail.
spoiler: I have 3 different cases:
- the examples works out of the box
- the examples works following the documentation to enable E-XIP with SW key
- the example does not work any more after fusing 0b10 to BEE_KEY1_SEL to select OTPMK instead of SW key
On RT1020-EVK, and I tried mcuboot_opensource and ota_mcuboot_basic examples provided by SDK 25.06.00.
As I said in a previous mail, I was able to successfully run the examples as is. After flashing the bootloader itself, I wrote an image to the secondary slot. The image was only signed (using the instrucion of the example https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/release/25.06.00/ota_examples/mcuboot_openso...), and the bootloader validated it, copied it to the primary slot, and executed it successfully.
Then I wanted to try the Encrypted XIP feature. And for this too, I followed the instructions in the documentation (https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/release/25.06.00/ota_examples/_doc/encrypted...). I only added this two defines in the bootloader:
#define CONFIG_ENCRYPT_XIP_EXT_ENABLE
#define ENCRYPTED_XIP_BEE
And I built the image adding encryption, indeed enabling CONFIG_ENCRYPT_XIP_EXT_ENABLE also enable CONFIG_BOOT_ENCRYPT_RSA (see https://github.com/nxp-mcuxpresso/mcuboot/blob/mcux_main/boot/nxp_mcux_sdk/include/mcuboot_config/mc...)
And it worked again.
But it is using the SW key as explained in the code (https://github.com/nxp-mcuxpresso/mcuboot/blob/mcux_main/boot/nxp_mcux_sdk/encrypted_xip/src/encrypt...). So I burned 0b10 to BEE_KEY1_SEL fuse to enable OTPMK instead of SW key, leaving bootloader and ota_mcuboot_basic untouched.
I flashed the image of ota in secondary slot, the bootloader validates it and write the primary slot, as done in the previous test, but at this point the image is not valid anymore:
here is the the serial log:
hello sbl.
Bootloader Version 2.1.0
Primary slot: version=1.1.0+0
Image 0 Secondary slot: Image not found
writing copy_done; fa_id=0 off=0x1fffe0 (0x43ffe0)
Image 0 loaded from the primary slot
Starting post-bootloader process of encrypted image...
Referenced image is located in the primary slot
Decrypting and loading the MCUBOOT AES-CTR key for staged image...
AES-CTR key loaded
Checking the execution slot...
No valid image found in staging area...
Preparing execution slot for new image
On-the-fly decryption initialization completed
Installing new image into execution slot from staged area...
Re-encrypting staged image to execution slot...
processed 41668/41668 bytes
Loading image successful
Image verification failed
verify_image failed
Failed to process encrypted image. Please reboot...
I also thought that the problem might be related to the algorithm for obtaining the counter from the nonce.
In fact, we found conflicting information in the documentation and code. We have always understood that to obtain the counter, the upper 96 bits of the nonce are taken, and the 4-bit shifted address is placed in the lower 32 bits.
This is confirmed by the code (https://github.com/nxp-mcuxpresso/mcuboot/blob/mcux_main/boot/nxp_mcux_sdk/encrypted_xip/src/encrypt...), but also in the documentation:
However, in another part of the documentation, we found this:
I wonder if this algorithm is used exclusively when OTPMK is used.
Otherwise, can you help us understand where we are going wrong?
regards
Max
so did you encrypt the app image again with this key before downloading into region 1 on your device?
Of course. I thought I had already made this point abundantly clear in previous posts.. As you surely know, it is made by the code provided by NXP:
https://github.com/nxp-mcuxpresso/mcuboot/blob/mcux_main/boot/nxp_mcux_sdk/encrypted_xip/src/encrypt...
You will also have noticed the lines of the serial trace, which should prove beyond doubt that the image is being re-encrypted:
hello sbl.
Bootloader Version 2.1.0
Primary slot: version=1.1.0+0
Image 0 Secondary slot: Image not found
writing copy_done; fa_id=0 off=0x1fffe0 (0x43ffe0)
Image 0 loaded from the primary slot
Starting post-bootloader process of encrypted image...
Referenced image is located in the primary slot
Decrypting and loading the MCUBOOT AES-CTR key for staged image...
AES-CTR key loaded
Checking the execution slot...
No valid image found in staging area...
Preparing execution slot for new image
On-the-fly decryption initialization completed
Installing new image into execution slot from staged area...
Re-encrypting staged image to execution slot...
processed 41668/41668 bytes
Loading image successful
Image verification failed
verify_image failed
Failed to process encrypted image. Please reboot...
I hope that this time I have dispelled all reasonable (and even unreasonable) doubts, so that we can finally get to a solution.
regards
Max
