Image not getting booting after flashed image in Encrypted(IEE) authenticated mode for i.MXRT1160EVK

vishnusudhankj · ‎07-11-2022

With MCUXpresso user guide reference, I have tried the following steps for booting image in IEE encrypted image authenticated (RT11xx) mode.

To build the image, followed the below steps :

In the Toolbar set Boot type to Encrypted (IEE) authenticated.
For Source executable image, used the sample blinky/ Hello world program available in the MCUXpresso SDK.
Keys generated in the PKI management.
Use the following keys selected the key, SRK1: IMG1_1+CSF1_1.
Clicked the IEE encryption menu to open the IEE Configuration window. In the window set, configured the number of IEE regions (contexts), KEK, AES encryption mode, and user keys for regions, regions ranges, random key generation.
Clicked Build image.
Check that the bootable image was built successfully.

To write the image, did the following procedure:

Switched to Write image view.
The board is set to Serial bootloader (ISP) mode.
Confirmed Use built image checkbox is selected.
Open OTP configuration, reviewed the settings.
To set a corresponding GPIO pin to enable XIP encryption without burning the fuse. set sw1 to internal boot mode 0010 & SW2 as 0100000000. (tried checking with SW1 set to 0001 ,also burned into fuse register)
Select HAB Closed life cycle.
Click Write image.

Once the write process gets success , the switch(sw2) bring back to off state & reset the device.

I cannot able to see any image gets bootup. In serial terminal , I can see only blank window. Seems something gets corrupted & booting up process not getting happening.

Also in user guide, its mentioned as , Set a corresponding GPIO pin to enable XIP encryption without burning the fuse. Set SW1 as 0010 & SW2 as 0100000000. But with this case also , the windows gets popup to write the values into fuse.

Kindly suggest any steps has been missed ? Why image not getting bootup for IEE encrypt authentication mode for MCUXpresso sample example also? Let us know any additional setting required to do for bootup process?

jeremyzhou · ‎07-15-2022

Hi,
Thanks for your reply.
After double-checking the log, I find you create the boot image: evkmimxrt1160_hello_world_demo_cm7_bootable.bin firstly, however, after that, you program the zephyr_nopadding.bin to the MCU, it seems to be a bit weird, please clarify it.

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.
-------------------------------------------------------------------------------

jeremyzhou · ‎07-11-2022

Hi，
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To be prudent, I was wondering if you can share the MCUXpresso Secure Provisioning's log of the building image and writing image.
Further, please illustrate the steps of generating the source executable image.
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.
-------------------------------------------------------------------------------

vishnusudhankj · ‎07-12-2022

@jeremyzhou

1. Source file -> Sample hello world available in the MCUXpresso IDE , set the XIP_BOOT_HEADER_ENABLE=0 and build the image & provided in the SPT tool as below,

For build & write log , please find the attached file. iEE_log_spt.docx

jeremyzhou · ‎07-12-2022

Hi，
After going through the iEE_log_spt.docx, I find the base_addr is 0x30001000 that the IEE key blob is placed at.

However, it doesn't conform to the Boot image layout, and I'll confirm it with the SPT team later.

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.
-------------------------------------------------------------------------------

vishnusudhankj · ‎07-15-2022

HI @jeremyzhou

Sorry for confusion, attached latest log (IEE_SAMPLE_HELLO_WORLD_LOG.docx)

After going through the iEE_log_spt.docx, I find the base_addr is 0x30001000 that the IEE key blob is placed at.

--> For this , Seems the keyblob written at 0x3000000 location , so as showed in the image layout , its written at proper memory location , but upon reset execution of application image is getting failed.

blhost succeeded

### Write IEE key blobs ###

blhost -t 5000 -u 0x15A2,0x0073 -j -- write-memory 0x30000000 "C:\Users\vishnusudhan\secure_provisioning0\bootable_images\iee_keyblobs.bin" 9

WARNING:spsdk.mboot.mcuboot:Note: memoryId is not required when accessing mapped external memory

{

"command": "write-memory",

"response": [

384

],

"status": {

"description": "0 (0x0) Success.",

"value": 0

}

blhost succeeded

jeremyzhou · ‎07-17-2022

Hi，
Thanks for your reply.
Firstly, I agree with you that the above commands are in charge of programming the key blob.
Next, in the AN13250, it mentions that
the IEE key blob containing keys and context structures (Table 4) is encrypted by a KEK according to the RFC3394 key-wrapping algorithm, because the key blob resides in the external memory along with the image and it must be protected. The IEE key blob will be protected by AES-512-XTS.
So in my opinion, the IEE key blob is necessary no matter choose AES-CTR or AES-XTS for encrypted XIP.
Meanwhile, in the 4.6.4 Encrypted XiP with IEE section in the ANAN13250, it set BASE_ADDR=0x30000000 which is the beginning address of the external QSPI flash and it is used in the below command.

set IEE_LOCK=0
image_enc.exe ifile=output_file_signed.bin ofile output_file.bin base_addr=%BASE_ADDR% ikbek1=%KEK1%
ikbek2=%KEK2% iee_arg=[%AES_XTS_KEY1%,%AES_XTS_KEY2%,%START_ADDR%,%END_ADDR%,%SEC_MODE%,%KEY_SIZE%,
%IEE_LOCK %]

However, in the SPT tool, the base_addr will have a 0x1000 offset.

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.
-------------------------------------------------------------------------------

vishnusudhankj · ‎07-18-2022

@jeremyzhou

Thanks for answer,

1. For IEE -> I used AES-CTR 256 (mode & key size) for Encrypted (IEE) authenticated.

2. Also, with the same board , I couldn't able to perform the Encrypted (OTFAD) authenticate .

While try to write the image , I am getting following error,

ERROR: Request: 0x970 |= 0x0 (mask: 0x1000); current value=0x1000; status=MISMATCH� , ERROR: SUMMARY: Detected status of fuses for write operation: some fuse(s) were already burned and does not match with requested value(s)� .. This fuse value already we written during IEE encryption method

3. For IEE & OTFAD , Is it Boot header also will get encrypted?

Kindly suggest how to overcome these issue, because i need to chose which encryption method is preferable to move further for our work.

jeremyzhou · ‎07-20-2022

Hi @vishnusudhankj ，
Just a reminder.
After double checking, the AE team replicated the issue and they found that SPT lost IVT data of the application image, in another word, if SPT programmed the application image without IVT data, it should cause the boot to fail. Now we could confirm that it is caused by the SPT tool. We will submit a ticket to the tool team in order to fix the bug.
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.
-------------------------------------------------------------------------------

jeremyzhou · ‎07-19-2022

Hi,

Thanks for your reply.
1）For IEE & OTFAD , Is it Boot header also will get encrypted?
-- Yes, as the encrypted area can contain the IVT and boot data.
2) Kindly suggest how to overcome these issues, because i need to chose which encryption method is preferable to move further for our work.
-- Regarding the above issue, I guess it's a software bug in the SPT tool and I'm waiting for confirmation from the SPT team.
So I'd like to choose the OTFAD encrypted method, not only to avoid the issue but also because of the OTFAD encrypted performance.
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.
-------------------------------------------------------------------------------

vishnusudhankj · ‎07-11-2022

Also for both IEE & OTFAD , how to check these feature without writing into fuse. Followed as mentioned in SPT user guide , Need to set switch SW1 as 0010(internal boot mode) & Switch SW2 as 0100000000 for SPI NOR flash. By even setting these GPIO, I am getting pop up like as below,

Kindly suggest how to check these modes , without writing into fuse?