Secure boot in imxrt1024..5A Abhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.png I have attached a snap of hex compare of signed and unsigned image (signed using SPT) i can see IVT have several changes that i didnt understand. At 0x1000 offset Unsigned -> D1 00 20 41 00 20 00 60 00 00 00 00 00 00 00 00 Signed -> D1 00 20 40 DD 22 00 60 00 00 00 00 00 00 00 00 Question 1 i understand that 41 is the IVT version that is hardcode inside my code how this is changed to 40? question 2. Also i dont understand how 00 20 -> DD 22 At 0x1010 offeset This is clear as here CSF pointer got updated At 0x1020 Unsigned -> 00 00 00 60 00 00 40 00 00 00 00 00 Signed -> 00 00 00 60 00 A0 00 00 00 00 00 00 Question 3 how 00 40 is update with A0 00 The reason to ask these question is as per my understanding if development team gave bootable binary then i just need to append CSF.bin and update the CSF pointer in IVT to make it sign , but after seeing the difference i feel there are more things happening Re: Secure boot in imxrt1024..5A Abhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.png In earlier post i got this answer so i thought just appending csf and updating the vsff pointer in IVT means firmware is signed but since i want to use CST for signing the image how to do that? I already have bootable image (FCFB, IVT, BOOTDATA,...) . I just need to sign and ship the package how to do that , i have created hab.csf [Header] Version = 4.0 #Avalibale engine are DCP, SW, ANY for IMXRT Engine = DCP Engine Configuration = 0 Certificate Format = x509 Signature Format = CMS Hash Algorithm = sha256 #Install root public key for use in subsequent INSTALL CSFK or Install KEY #HAB install in slot 0 of its internal public key store # HAB just re-hashes the table and compares against the fused SRK-hash. [Install SRK] File = "keys/SRK_1_2_3_4_table.bin" #Tell which SRK to use, installation will fail if revocation fuse with this index is burned Source index = 0 Hash Algorithm = sha256 #HAB install CSF key's cert in slot 1 [Install CSFK] File = "crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem" Certificate Format = x509 #Authenticate CSF command authenticates the CSF from which it is executed [Authenticate CSF] #Install a public key for use in subsequent Install key or Authenticate Data commands #HAB install IMG cert into key slot 2 [Install Key] #Means this cert is checked against the SRK Verification index = 0 Target index = 2 File = "crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem" [Authenticate Data] #Should be same as Target Index in Install Key Verification index = 2 Blocks = 0x60001000 0x1000 0x6580 "evkmimxrt1024_iled_blinky_unsigned_original.bin" Re: Secure boot in imxrt1024..5A Hi @Abhay2080 ,
Thanks for your questions!
Based on the RT1024 IVT / Boot Data definition, the differences you see are expected and are not limited to the CSF pointer update.
Q1: Why does D1 00 20 41 become D1 00 20 40 ? D1 00 20 41 is the IVT header: 0xD1 is the IVT tag, 0x0020 is the fixed IVT length of 32 bytes, and the last byte is the version. The RT1024 Reference Manual defines the IVT version as 0x40/0x41 , so 0x40 is valid and not an error. Please check this online guide: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mcu_bootloader/docs/iMXRT1024_Manufacturing_User_Guide/topics/imx_rt_bootable_image.html
Q2: Why does 00 20 00 60 become DD 22 00 60 ? This is the IVT entry field. In little-endian format:
00 20 00 60 = 0x60002000
DD 22 00 60 = 0x600022DD
The RT1024 RM defines entry as the absolute address of the first instruction to execute from the image. AN12108 also states that if the default entry point is not Reset_Handler , entryPointAddress should be set to the Reset_Handler address. So SPT likely updated the IVT entry from 0x60002000 to the actual application entry point. Please confirm the Reset_Handler address in the map file / ELF symbol table.
Q3: Why does 00 00 40 00 become 00 A0 00 00 ? At 0x1020 this is Boot Data:
start remains 0x60000000
length changes from 0x00400000 to 0x0000A000
The RT1024 RM defines Boot Data as containing the image start address and image length, and the Boot ROM reads the image address and length from this structure. Therefore, SPT updated the length field to match the final generated bootable/signed image layout.
For RT-series HAB secure boot, the final signed image is not just “append CSF.bin + update the CSF pointer”. The IVT header, entry, Boot Data length, CSF pointer, and the address/length covered by the CSF Authenticate Data command must all be consistent. HAB recalculates the hash from the software in flash and compares it with the reference hash recovered from the signature; if an authenticated region is modified after signing, verification fails.[0dfe-E1] The recommended approach is to use the final signed image generated by SPT/CST, not to manually append CSF.bin only.
I hope this clarification helps!
Best regards, Gavin
Re: Secure boot in imxrt1024..5A Hi @Abhay2080 ,
Good question. The key point is: CST does not modify your image — it only computes the hash over the region you specify and produces the CSF (signature). It never changes IVT entry, Boot Data length, or version.
That is why those fields changed under SPT: SPT rebuilds the boot image from the ELF and normalizes IVT.entry (to the real Reset_Handler) and Boot Data length. Those changes come from image re-building, not from the signing step. With the CST-direct flow you do not need to reproduce them — if your original image already boots in the open/development state, its entry and version are already correct and can stay as-is.
However, there is one hard requirement. Your [Authenticate Data] block
Blocks = 0x60001000 0x1000 0x6580
covers the entire IVT, and the IVT CSF pointer sits inside this signed region. HAB re-hashes this region and compares it against the signature, so if any byte in it is changed after signing, authentication fails.
This is exactly why "sign first, then append CSF and update the CSF pointer" does not work — the order is wrong.
Correct CST sign-and-ship procedure (do this before running cst):
Decide where the CSF will sit (appended after the App). With your block, App ends at 0x1000 + 0x6580 = 0x7580 , so the CSF starts at file offset 0x7580 (memory 0x60007580 ).
In the image to be signed, pre-set:
IVT CSF pointer → CSF memory address (e.g. 0x60007580 );
Boot Data length → total image size including the CSF.
Keep FCFB and entry unchanged (FCFB is outside the HAB scope; ROM reads it before HAB).
Run: cst -i hab.csf -o csf.bin (your hab.csf with Engine = DCP is correct for RT1024).
Concatenate: cat prepared.bin csf.bin > signed_firmware.bin , place CSF at the address from step 1, and flash directly.
So your hab.csf itself is fine; the only fix is to set the CSF pointer and Boot Data length before signing, not after.
Best regards, Gavin
記事全体を表示
