Currently, I'm trying to set up some build scripts for my project, and at this point, I'd like to set up the security features, namely, the encrypted XIP boot feature.
I already had a look at AN12079, AN12670 and AN1268, and I am aware of the NXP-MCUBootUtility tool for streamlining the process. However, I cannot access the image_enc.exe script needed to perform AES128-CTR encryption, even after having checked the "The step-by-step guide to build image_enc.exe for BEE/OTFAD encryption" mentioned on the GitHub page.
Is there any other way I can obtain the image_enc.exe script, or alternatively, where can I find a detailed explanation of the specific implementation of the AES128-CTR encryption algorithm.
I didn't get the image_enc.exe because I can't access the Baidu server it's currently residing on.
The chip I'm currently working with is the i.mx RT 1011, so the purpose here is to set up the encrypted OTFAD boot. I would like to avoid using the MCUBootUtility GUI as I'm trying to streamline the process myself for building those production images.
Thank you for your reply!
Unfortunately, the elftosb utility is not useful for us, since ultimately we'd like to make it so factory programming can be done directly through JTAG/SWD programming. So, ideally, the image binaries should be encrypted externally, for which I believe the image_enc.exe would be extremely useful.
I've read that some people have been able to replicate the encryption process with OpenSSL, but I was just hoping that these NXP tools would be more freely available for developers.
Thank you for your time,
I was finally able to obtain the image_enc.exe program and I've been trying to use it to encrypt a firmware image, but haven't succeeded so far. Ultimately, the objective is for it to generate and place the key blobs and encrypt the firmware image accordingly.
For this purpose I'm running the following command:
./image_enc.exe ifile=image.bin ofile=image_enc.bin base_addr=0x60000000 kek=00000000000000000000000000000000 otfad_arg=[000102030405060708090A0B0C0D0E0F,0123456789ABCDEF,60001000,1000],[000102030405060708090A0B0C0D0E0F,0123456789ABCDEF,60002000,1000],[000102030405060708090A0B0C0D0E0F,0123456789ABCDEF,60003000,1000],[000102030405060708090A0B0C0D0E0F,0123456789ABCDEF,60004000,1000] scramble=0 scramble_align=0 otfad_ctx_lock=0,0,0,0
This command should replicate the key blobs from evkmimxrt1010_otfad_keyblob example, which it appears to do successfully, however, the remainder of the image does not appear to be encrypted at all (since I'm getting an ever-repeating pattern at the output .bin file). Even though I'm using a dummy image.bin file (filled with 0xff), I would still expect the data to show more entropy given that the OTFAD is running aes128-ctr encryption (as opposed to aes128-ecb).
Any ideas on why I'm getting this behaviour? Can image_enc.exe actually generate an encrypted bootable image (this is not so clear anymore)?
If you already get the image_enc.exe, then do you mind using the MCUBootUtility tool try the BEE OTFAD encrypted operation? I know you don't want to use the MCUBootUtility tool in your production phase, but now you can use the MCUbootutility to test it, when it is a success, you also can follow the detail operation steps in the MCUbootUtility to do your own related process. When using the MCUBootUtility tool, it will printf the detail operation log. MCUBootUtililty BEE OTFAD operation is tested, I still don't have any other detail operation steps.
Thank you for your reply!
As you mentioned, I tried the MCUBootUtility and concluded that the image_enc.exe command mentioned above was correct. Eventually, I figured out the issue I was having (wrong encryption) was due to the fact that the input image was not a valid bootable image (it appears that the image_enc.exe can only encrypt a binary file if it recognizes it as a bootable image).
Now that I checked that OTFAD decryption is working I'm getting a new error when trying to execute code from RAM (ITCM). In particular, I am getting an Instruction access violation flag (IACCVIOL), whenever the program is trying to execute code from RAM (ITCM).
Will continue trying to figure out what could possibly be causing this.
I've tracked down this issue and it appears to be related a reset call to the FLESPI module, in flexspi_nor_flash_ops.c:
I replaced those calls with:
/* Do software reset. */
base->AHBCR |= FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK;
base->AHBCR &= ~(FLEXSPI_AHBCR_CLRAHBRXBUF_MASK | FLEXSPI_AHBCR_CLRAHBTXBUF_MASK);
and it seems to work correctly now, but I don't know whether this is the correct thing to do.
Any ideas as to why performing the software reset through the control register of the FLEXSPI module could be causing such issues, i.e. conflicts when using OTFAD?
Thanks so much for your sharing.
From the security block diagram:
We can find the OTFAD need to associate with FlexSPI.
So, my understanding is, when the FlexSPI do the software reset, then the OTFAD may can't obtain the FlexSPI data, it may have problems.
You can use your own workaround do more testing. If you still have problems, please kindly let us know.
Do you already get the image_enc.exe in the link which you have posted? Do you mean image_enc.exe is not enough and you need the source code? Do you have tried image_enc.exe with MCUBootutility tool on your side or not, whether it works or not?
You need to download v2.x, the second one, and copy it to \NXP-MCUBootUtility\tools\image_enc2
Do you want to use the BEE encrypted operation with MCUbootUtility?
Please also tell me which RT chip you are using?
If you want to use the BEE, you also need to configure your CST tool, you can refer to my detail RT1020-EVK BEE operation steps in this post:
The reply on Feb 24, 2020 7:55 AM
Wish it helps you!
If you still have questions about it, please let me know.