topic Re: Regarding the limitations of Key Scramble settings in MCUXpresso Secure Provisioning Tool

Regarding the limitations of Key Scramble settings

Omar_hong — Mon, 23 Dec 2024 08:12:24 GMT

Hi NXP

According to NXP application note, OTFAD_KEY_SCRAMBLE and ALIGN were arbitrary word and byte.

But when I set non-SPT default values (0x33AA55CC & 0x1B), the RT10101 fails to decrypt and boot .[On my EVT board] .It stops in ISP mdoe.

===================================================================
On the NXP RT1010 EVB, writing the default settings(0x33AA55CC & 0x1B) allows it to boot successfully.

The following are the steps on NXP EVB

Step 1. Burning fuses[OTFAD KEK & SCRAMBLE] => boot successfully.
Step 2. Burning fuses[HAB] => boot successfully.

===================================================================
On non-NXP EVB device, writing the non-default settings ,the RT10101 fails to decrypt and boot and stops in ISP mdoe.
The following are the steps on my EVT board

Step 1. Burning fuses[OTFAD KEK] => boot successfully.
Step 2. Burning fuses[HAB] => boot successfully.
Step 3. Burning fuses[SCRAMBLE] => boot Fail.

I use SPT for programming, and during the programming process, it will verify that the SPT fuses settings match the device. Therefore, my settings should be correctly written to my EVT board.

Using the SPT OTP setting function, I also confirmed that my settings were successfully written to the eFuses.

I tried changing the OTFAD encryption block to an unwritten block (e.g., 0x60020000), and my EVT board can boot normally.
=>This indicates that there might be an issue with the decryption process.
===================================================================

Based on the above successful and failed boot cases:

1. Does the order of writing eFuses affect the functionality of OTFAD and Scramble?

2. Are there any configuration limitations for OTFAD_KEY_SCRAMBLE and ALIGN?

Does this mean there is an issue with OTFAD and Scramble?

Re: Regarding the limitations of Key Scramble settings

marek-trmac — Thu, 02 Jan 2025 08:50:34 GMT

Hi Omar,

after you burn SCRAMBLE, you need to update key blobs (because key blobs are affected by the SCRAMBLE).

There is application note with details about OTFAD encryption on RT101x, which might help: AN12670 How to use encrypted XIP boot.in i.MX RT1010

About ALIGN, please refer to chapter "Key blob KEK details" in Security Reference Manual.

Re: Regarding the limitations of Key Scramble settings

Omar_hong — Thu, 02 Jan 2025 09:35:30 GMT

Hi @marek-trmac

Thank you for your reply.

I have used SPT to erase the flash in the above steps, and then used SPT to rewrite the updated KEY blobs and firmware.

Re: Regarding the limitations of Key Scramble settings

marek-trmac — Thu, 02 Jan 2025 09:41:15 GMT

Hi Omar,

what ALIGN fuse value did you burn? Does default OTFAD settings works on your custom board?

Re: Regarding the limitations of Key Scramble settings

Omar_hong — Thu, 02 Jan 2025 10:13:14 GMT

Hi @marek-trmac

Thank you for your reply.

what ALIGN fuse value did you burn?

=>Since the setting values are intended for future production, it is inconvenient to disclose them. I can only say that I have set them within the range of 0x00 to 0xFF.

Does default OTFAD settings works on your custom board?

=>Due to concerns about causing the aforementioned situation again, I am currently not burn any scramble config( OTFAD_KEY_SCRAMBLE and ALIGN) to the custom board.

Re: Regarding the limitations of Key Scramble settings

marek-trmac — Fri, 03 Jan 2025 12:47:24 GMT

Hi Omar,

we confirm the problem, we found the keyblob is generated wrongly for same scramble values. The problem is reproducible since SEC tool v8. Could you use SEC tool v7? In version 7 the tool uses image_enc utility to generate the keyblob and there is no such issue.

We are sorry for the inconvenience. We'll fix the problem for next release.

Re: Regarding the limitations of Key Scramble settings

Omar_hong — Mon, 06 Jan 2025 07:36:14 GMT

Hi @marek-trmac

I am using SPT V9.0.1. Do you mean that I need to use version V7.0 to generate the correct keyblob data based on my scramble values ?

Re: Regarding the limitations of Key Scramble settings

marek-trmac — Mon, 06 Jan 2025 07:47:05 GMT

Hi Omar,

yes, use SEC v7. The problem is in nxpimage utility, which is used to generate keyblob since SEC v8. In the older versions, keyblob was generated using image_enc utility.

Re: Regarding the limitations of Key Scramble settings

svoulaz_ik — Tue, 21 Jan 2025 16:34:49 GMT

Hello, having same trouble on rt1176 using SEC V10 - can you confirm the problem still exists on V10?

Besides, since V7 does not accept binary images with boot header nor ELF files (at least, not those built within MCUXpresso IDE v11.9.0 Build 2144), I'm having hard times with V7 too - and the encrypted image (from blinky sample) does not work anyway. Looks like older image_enc tool suffers the same bug with some scrambling value and/or align.

I am quite surprised this issue has not been addressed yet, since it is actually a security flaw - scrambling is definitely useless if you can (safely) use only default values.

Kudos

Stefano

Re: Regarding the limitations of Key Scramble settings

marek-trmac — Wed, 22 Jan 2025 07:28:38 GMT

Hi Stefano,

scramble for RT116x/7x and RT10xx is confirmed bug in MCUXpresso Secure Provisioning tool v10 and currently there is not planned any hotfix. RT117x is supported since MCUXpresso Secure Provisioning tool v5, so we recommend to use older version (v7). There is not known such problem for image_enc tool.

For the input image, kindly follow the description in chapter 6.2.1.1 and disable XIP_BOOT_HEADER_ENABLE (images with the header are not supported in tool version 7).

We are sorry for inconvenience

Re: Regarding the limitations of Key Scramble settings

svoulaz_ik — Wed, 22 Jan 2025 09:13:23 GMT

Hello Marek,

I can confirm that image produced with V7 using a scramble value of 0x19a8c836 and a scramble align of 0xd6 doesn't work - while using the default values the image works. Note however that I used different keys and random counter.

I carefully checked fuse settings on the non-working board (the one with the mentioned scramble values) and they look correct. Apparently, image_enc tool is producing a bad key blob.

As a side note, I am surprised that issues on such a sensitive topic (image protection) are not being appropriately addressed: how is it possible that, although ages have passed, it is still not possible to reliably get a correctly formed bootable image from SPT?

Best regards,
Stefano

Re: Regarding the limitations of Key Scramble settings

marek-trmac — Thu, 23 Jan 2025 10:17:46 GMT

Hi Stefano,

Here is an update for your problem: for i.MX RT116x/7x, the image_enc utility was replaced by nxpimage already in SEC v7. That's why SEC v7 produces same problem in keyblob as SEC v10. For RT117x kindly use SEC v6. You can still use the processor with your custom fuses, only the keyblob needs to be fixed (bootable_images\otfad_keyblobs.bin).

Alternatively, it shall be also possible to generate keyblob in SEC v6 and replace the keyblob generated by SEC v10 (it is possible to add hook into SEC v10 build script). To do this, you must have all keys and all OTFAD parameters same in both workspaces.

We are sorry for inconvenience