I am using the iMXRT1021 with flexqspiNOR flash. We want to encrypt the .sb image and the use on-the-fly BEE decryption. I am using the elftosb.exe, sdphost and blhost to produce and flash the .sb image.
This all works for normal (unsigned) image, but I cannot get the past the first stage of encryption.
I have downloaded, "Code-signing-tools", "openssl", "ubuntu shell for win10". I can create all the SRKs and certificates.
elftosb\elftosb.exe -f imx -V -c bd_file\imx-flexspinor-normal-signed.bd -o elftosb\img\ivt_output_xip.bin elftosb\img\hermes.s19
results in a ivt_output_xip.bin with 0kB.
elftosb\elftosb.exe -f kinetis -V -c bd_file\program_flexspinor_image_qspinor_encrypt.bd -o elftosb\img\encrypt_hermes_image.sb elftosb\img\ivt_output_xip_nopadding.bin
failed to open source file: elftosb\img\ivt_output_xip_nopadding.bin (ignoring for now)
error: line 55: error opening source 'myBinFile'
And no .sb image is produced.
Please advise how I can generate an encrypted .sb file, download and execute with BEE.
flags = 0x04;
startAddress = 0x60000000;
ivtOffset = 0x0400;
initialLoadSize = 0x2000;
//DCDFilePath = "dcd.bin";
# Note: This is required if the cst and elftsb are not in the same folder
// cstFolderPath = "/Users/nxf38031/Desktop/CSTFolder";
cstFolderPath = "/Projects/code_signing_tool/cst-3.2.0/release/";
# Note: This is required if the default entrypoint is not the Reset_Handler
# Please set the entryPointAddress to Reset_Handler address
// entryPointAddress = 0x60002411;
entryPointAddress = 0x60019358;
elfFile = extern(0);
SEC_CSF_HEADER = 20;
SEC_CSF_INSTALL_SRK = 21;
SEC_CSF_INSTALL_CSFK = 22;
SEC_CSF_INSTALL_NOCAK = 23;
SEC_CSF_AUTHENTICATE_CSF = 24;
SEC_CSF_INSTALL_KEY = 25;
SEC_CSF_AUTHENTICATE_DATA = 26;
SEC_CSF_INSTALL_SECRET_KEY = 27;
SEC_CSF_DECRYPT_DATA = 28;
SEC_NOP = 29;
SEC_SET_MID = 30;
SEC_SET_ENGINE = 31;
SEC_INIT = 32;
SEC_UNLOCK = 33;
SEC_XIP_REGION0 = 34;
SEC_XIP_REGION1 = 35;
InstallSRK_Table="crts/SRK_1_2_3_4_table.bin", // "valid file path"
InstallCSFK_File="crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem", // "valid file path"
InstallCSFK_CertificateFormat="x509" // "x509"
InstallKey_VerificationIndex=0, // Accepts integer or string
InstallKey_TargetIndex=2) // Accepts integer or string
SetEngine_HashAlgorithm = "sha256", // "sha1", "Sha256", "sha512"
SetEngine_Engine = "DCP", // "ANY", "SAHARA", "RTIC", "DCP", "CAAM" and "SW"
SetEngine_EngineConfiguration = "0") // "valid engine configuration values"
Unlock_Engine = "SNVS", // "SRTC", "CAAM", SNVS and OCOTP
Unlock_features = "ZMK WRITE" // "Refer to Table-24"
Some progress my end.
I re-built the blinky code using the start up procedure from our app. I put in ram funcs and an asm jmp to a bank in flash to execute the code. This all worked ok. I was able to attach the debugger to the encrypted code on the EVK and step through the start-up.
I went back to the target board running the encrypted download and repeated the debugger attachment. I was able to pause, reset to start of execution and step through the code. This initialisation appears to be good, but things get a bit erratic after that. However I was able to communicate with the the CLI shell we have running and execute a number of commands. Then it crashed.
So I am more confident that I can get the application working as it should, we are still in development.
The srec file is attached.
Thanks for your new updated information and hear you make the progress.
I checked your .s19, the code boot from the external QSPI flash, I checked the IVT, the header side, the boot should work.
Now, when you make the EVK works, you can move it to your own board and test it step by step.
If you need any help from your side, just kindly let me know.
BTW, if you have the new question, it's better to create the new question post, because this post is really very long now. Thanks a lot for your understanding.
I'm trying to understand what issues could be causing my startup problem.
One possibility is ramfuncs?
I have a number of functions that are designated ramfunc. On startup they are copied from flash to ITCM and then executed from that location.
What I would like to know is;
Is the ramfunc flash resident code de-crypted on-the-fly when it is copied to RAM and then executed as unecrypted code?
Or are the functions copied encrypted into RAM and then de-crypted by BEE on execution from RAM?
I thought the BEE was coupled to the flexspi bus (external flash) but I'm not sure about ITCM?
Hi Tony Thurgood,
Thanks a lot for your effort and test result.
So, now, your issue is the BEE encrypt boot problem with your own board?
1, Please share your own board app source .srec code, and the corresponding BEE secured code which is read out from the MCUBootutility tool, BEE code is c14_enc_image.docx right? I still need your source .srec code.
2. What's the situation of your encrypted_xip pin on your own board? GPIO_EMC_18(BT_CFG).
If you already fan out this pin, I highly suggest you use the external GPIO boot at first, which I have told you in the previous reply, I just want to do it very carefully, step by step, fuse modification(bt_fuse_sel and encrypted_xip) should be put in the last stage after we make sure the BEE encrypt boot works with your own board.
3. What's the boot mode you are using after you burn the bt_fuse_sel and encrypted_xip? You need to set boot mode=00.
4. Please enter serial download mode, connect your own board, and readout the fuse map, and send me your newest fuse map which already include the modification for bt_fuse_sel and encrypted_xip.
5. About your request for image_enc2 source code, I will help you to check with the author in the next week, now is the weekend time. In the future, if you use RT1010 OTFAD, I also would like to help you, you can create the new case or new post and let me know at that time, if you really need my help.
Anyway, let's do it together, try to make your own board BEE boot works at first.
6. About your question: Is the ramfunc flash resident code de-crypted on-the-fly when it is copied to RAM and then executed as unecrypted code?
Thanks for your reply, going through your suggestions...
1. I am not allowed to share source code/design on a public forum. Please email me directly or provide a secure method of data transfer.
2. Our design uses the 100 pin package and most of the GPIO_EMC_18 to GPIO_EMC_27 pins are assigned to logic control. It powers up with Boot From Fuses mode (BOOT_MODE[1:0] = 00b), the default internal fuse settings put the chip in serial mode. The image is downloaded via serial port and then BT_SEL_FUSE is blown. Thereafter the board starts up with normal execution and allows j-link debugger to attach. We could feasibly cut tracks and try to manage the boot mode with external pins.
3. Yes, it is always boot mode=00.
4. Once the BT_FUSE_SEL is blown and power cycled, it is not possible to re-connect the serial port. This picture shows the state of the Cfg fuses after encrypted download...
6. So you are saying the ramfuncs are read out of flash using BEE, decrypted and then copied to ICTM ram. They are not just read from flash and copied to ITCM. Please confirm.
I can provide you with all src etc, please contact me direct.
Hi Tony Thurgood,
1. Maybe some misunderstanding, not source code, just the app.srec which you are using, unsecured app.srec.
I want to check your app.srec address location situation.
2. It's good, please use the external GPIO as the BOOT_CFG to test it, make sure it is not caused by the boot problem.
When you use the GPIO as the BOOT_CFG pin, please choose boot mode as Internal Boot (BOOT_MODE[1:0]=10).
4.you are right
If BT_FUSE_SEL is set, you can't enter the serial download mode.
So, let's still test the GPIO boot at first, it will be more safe, at least we still can enter the serial download mode, to modify the app.
6. As I know, yes,
Read out of flash using BEE, decrypted and then copied to ITCM ram, then run from ITCM.
Do you need to run the code in the internal RAM, not just do the XIP directly in the external QSPI flash?
Hi Tony Thurgood,
1. When you try the image.bin in DEV download mode, don't burn any fuse, whether it boots OK or not?
2. Your BT_CFG is totally didn't fan out? Or just connect to other modules?
If you already fan out, I highly suggest you try to use the external EncryptedXIP pin at first, after the boot really works, then we can burn the EncryptedXIP fuse again.
3. After the chip is secured, you really can't use the JTAG to debug it directly. So, normally, we do the secure function in the product last phase.
4. The user key should also works, anyway, I think you can follow my OTPMK key at first, after it works, then we can go to the user key together.
But the very important result from your side, you said you are using the user key, your fuse map result doesn't like what you have said.
0X460 is 0x00002012, what does it mean?
It means you are still choosing the OTPMK not the SWGP2.
Are you use you have chosen the user key?
BTW, if you choose the key, you need to share your configuration picture.
Anyway, your BEE_KEY0_SEL is 10 now, not 11.
I am really very happy that you have make it work on the MIMXRT1020-EVK, at least it is the progress.
Now, you can do the same operation on your own board.
About the BEE_KEY0_SEL, it is related to your BEE secured key source.
If you choose SNVS, then BEE_KEY0_SEL is 10, but if you choose user key.
then your BEE_KEY0_SEL will be 11, this is what the detail information which I want to tell you in my above reply.
Anyway, if you have any difficulties, please kindly let me know.
I am interested in your own board BEE test result.
Using my srec image and target board, I setup with the Tool.
I used All-in-one to download an unencrypted image, reset and that ran normally.
I selected BEE encryption and used the settings/certs that I used on the EVK. I used All-in-one to perform the download and fuse blowing. I additionally set bt_fuse_sel and encrypted_xip. then power cycled the boad.
It failed to run.
So I know the unencrypted image works with the tool and target. I know the encrypted demo app runs on the EVK.
For some reason my target + encryption doesn't start.
I have attached logs, pngs and a copy of "View Bootable Image".
Yes, I always have master mode selected. The "one step" only defines how the tool connects to the flashloader via the serial port. Doing that manually makes no difference. Sometimes connecting can be a bit erratic, so that why I used single step.
Hi Tony Thurgood,
Thanks for your feedback, it's really a little confusing to you.
Now, I already send the following files to your DFAE Avnet(Jason Muriel), as I can't share it directly in the public community.
The following are the usage:
unzip it, will get image_enc.exe, copy it to:
The following 3 files, normally should be generated by the customer and set the customer's SRK, the customer can refer to the application note:
chapter 3.1. Authenticate using elftosb
But, now, I also share my generated files and SRK for customer's reference, I have tested it in the newest version MCUBoot2.2.0, it works fine!
But, if you already configured your own related files, you also can use it directly, if you still failed, you can try my files in the new chip.
Copy to :
Delete the original cst folder.
Copy SRK_1_2_3_4_fuse.bin and SRK_1_2_3_4_table.bin to folder:
I un-zipped the files received ...thank you.
1. I copied the enc file to... NXP-MCUBootUtility-2.2.0\tools\image_enc2\win\image_enc.exe
2. Removed cst folder and added your cst
3. Copied SRK_1_2_3_4_fuse.bin and SRK_1_2_3_4_table.bin to folder:
3. connected the target board, selected image file, set the Advanced settings, Generated .sb selected.
4. Clicked "All-In-One-Action"
The tool ran for 5 seconds, but then hung up without downloading the image or blowing any fuses.
I have attached logs and images.
I tried other boards, but the same result.
Hi Tony Thurgood，
Good that you get the files.
1. Do you tried your board like me with DEV unsigned image boot mode and readout the orignal fuse map at first?
This is important.
Please try DEV unsigned image in the new chip at first, and switch to the boot internal mode, make sure your board normal download and boot have no issue.
2. If the DEV unsigned image boot works, then you can try the BEE mode.
If you find the fuse map is not burn after you download BEE code, please click the following button in your picture:
Burn SRK data, if your fuse is not burn automatically, just as Jay told you, he leave the fuse burn to the customer instead of the tool download it directly.
In your picture, I find your SRK table already list, you just need to click Burn SRK data.
But you said, the tool even didn't burn the image, I highly suggest you try the DEV mode instead of BEE mode directly, make sure your board configuration is correct, you need to select the correct external QSPI flash.
Any updated information, let me know ASAP.