Fail to generate a signed flashloader.bin file for i.MX RT1060 EVKB

[FMA]

Hello,

I am trying to activate the HAB on my MIMXRT1060EVKB board but I am failing to generate a signed flashloader.bin file in order to load a signed firmware on the board.

1. I have generated the set of certificates and keys (4 public keys) according to the documentation provided in the CST documentation (and have cross checked it with information given in the "RT1050 HAB Encrypted Image Generation and Analysis" article and also in the "i.MX RT: Secure Boot Episode 1" lab information). I also generated the hash table and signature files according the those documents and everything seems to be fine.

2. Following instructions given in section 4.3 of the i.MX RT 1060 Manufacturing User's Guide (doc IMXMCUMFUUG) (which are pretty similar to the instruction given in the above mentioned documents) I have:

- Generated an .sd file

options {
    flags = 0x08;
    startAddress = 0x60000000;
    ivtOffset = 0x1000;
    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";
    # Note: This is required if the default entrypoint is not the Reset_Handler 
    #       Please set the entryPointAddress to base address of Vector table
    # entryPointAddress = 0x60002000;
}

sources {
    elfFile = extern(0);
}

constants {
    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;
}

section (SEC_CSF_HEADER; 
    Header_Version="4.3", 
    Header_HashAlgorithm="sha256", 
    Header_Engine="DCP", 
    Header_EngineConfiguration=0, 
    Header_CertificateFormat="x509",
    Header_SignatureFormat="CMS"
    )
{
}

section (SEC_CSF_INSTALL_SRK; 
    InstallSRK_Table="crts/NCS_IMX_SRK_1_2_3_4_table.bin", // "valid file path"
    InstallSRK_SourceIndex=0 
    )
{
}

section (SEC_CSF_INSTALL_CSFK; 
    InstallCSFK_File="crts/NCS_IMX_CSF1_1_sha256_4096_65537_v3_usr_crt.pem", // "valid file path"
    InstallCSFK_CertificateFormat="x509" // "x509"
    )
{
}

section (SEC_CSF_AUTHENTICATE_CSF)
{
}

section (SEC_CSF_INSTALL_KEY; 
    InstallKey_File="crts/NCS_IMX_IMG1_1_sha256_4096_65537_v3_usr_crt.pem", 
    InstallKey_VerificationIndex=0, // Accepts integer or string 
    InstallKey_TargetIndex=2) // Accepts integer or string 
{
}

section (SEC_CSF_AUTHENTICATE_DATA;
    AuthenticateData_VerificationIndex=0, 
    AuthenticateData_Engine="DCP",
    AuthenticateData_EngineConfiguration=0) 
{
}

section (SEC_SET_ENGINE;
    SetEngine_HashAlgorithm = "sha256", // "sha1", "Sha256", "sha512" 
    SetEngine_Engine = "DCP", // "ANY", "SAHARA", "RTIC", "DCP", "CAAM" and "SW" 
    SetEngine_EngineConfiguration = "0") // "valid engine configuration values"
{
}


section (SEC_UNLOCK;
    Unlock_Engine = "SNVS, OCOTP", // "SRTC", "CAAM", SNVS and OCOTP 
    Unlock_features = "ZMK WRITE, SRK REVOKE" // "Refer to Table-24" 
    )
{
}

- Copied all required files to the same folder as the one containing the elftosb.exe utility

3. I run the following command line to try to generate the signed flashloader .bin file. The command line only returns the following line then stops and generates a 0kB evkbmimxrt1060_flashloader_signed.bin file

>elftosb.exe -f imx -V -c imx-flexspinor-normal-signed.bd -o evkbmimxrt1060_flashloader_signed.bin flashloader_1060.srec

        Section: 0x14
        Section: 0x15
        Section: 0x16
        Section: 0x18
        Section: 0x19
        Section: 0x1a
        Section: 0x1f
        Section: 0x21

>

Could you help me figure out what I might be doing wrong ?

Also, could you please explain to me the following things related to the .sb file which are not clearly explained in the documentations:

- in the .bd file the SEC_CSF_INSTALL_SRK, SEC_CSF_INSTALL_CSFK, SEC_CSF_INSTALL_KEY always deal with the installation of public keys from the certificates (either for the root for the SEC_CSF_INSTALL_SRK, the CSF for SEC_CSF_INSTALL_CSFK or the IMG (why ?) in the SEC_CSF_INSTALL_KEY). There is never a path allowing to locate a private key counterpart that would actually be used to sign the binary file. So how can the output file be actually authenticated since the public key should not be secret and could be associated to any firmware ?

- in the .bd file, we specify which SRK is going to be used in the SRK root of thrust by provinding the SEC_CSF_INSTALL_SRK.InstallSRK_SourceIndex property related to the hash values included in the SRK Table. If I am correct, the related CSF public key (specified in SEC_CSF_INSTALL_CSFK) is going to be validated from its certificate. After that, we also provide a "Verification Index" and a "Target Index" for the SEC_CSF_INSTALL_KEY configuration section. Can you clarify what those two properties relate to and how they actually differ ? Also, what is the actual purpose of the SEC_CSF_AUTHENTICATE_DATA.Authenticate_DataVerifcationIndex property ?

Thanks in advance

[tonythurood2]

I have exactly the same problem. I am trying to generate a signed image using elftosb.exe. My .bd file is the same as the top of this post and my folders are setup with all the necessary keys, certs, cst etc as described in IMXMCUMFUUG. 

input.srec -> [elftosb] -> output.bin

This did not work, I did not get...

"CSF Processed successfully and signed data available in csf.bin
iMX bootable image generated successfully"

and the output.bin = 0 size.

Having read the solution above, I modified the .bd options parameter...

# ivtOffset = 0x1000;
ivtOffset = 0x400;

It now produces a signed image.

But this fix is nonsense, the bat file runs...

..\elftosb.exe -V -f imx -c ..\..\bd_file\imx10xx\imx-flexspinor-normal-signed.bd.....etc

The -f imx implies and imxRT target, where the IVT is located a 0x1000.

Please explain why the wrong ivt address location is needed to produce a signed bin output?

fyi. I am not using a flashloader or any of the many NXP utilities, I just want to generate a signed binary image.

[FMA]

Hello Tony,

The IVT offset is impacted by the boot device type (see table  9-36) and can be either 0x1000 or 0x400:

- 0x1000 for FlexSPI NOR/SEMC NOR

- 0x400 otherwhise

[FMA]

Hello Jeremy,

Thank you for you answer, I think it did solve my problem (at least know I have the elftosb finishing and producing the two expected .bin files).

Just for the sake of information, I applied the following change to the option section of the bd file:

options {
    flags = 0x08;
    startAddress = 0x20000000;
    ivtOffset = 0x400;
    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";
    # Note: This is required if the default entrypoint is not the Reset_Handler 
    #       Please set the entryPointAddress to the base address of vector table
    // entryPointAddress = 0x20002000;
}

 As a note, though I got inspiration from an exemplary .sb file content provided in the "I.MX RT1060 Manufacturing User's Manual" (see section 7.2.3.1 Generate signed i.MX RT bootable image), the tool mentionned another problem with the .sb content illustrated in my original question:

I had

section (SEC_UNLOCK;
    Unlock_Engine = "SNVS, OCOTP", // "SRTC", "CAAM", SNVS and OCOTP 
    Unlock_features = "ZMK WRITE, SRK REVOKE" // "Refer to Table-24" 
    )
{
}

But with these, the tool crashed with the following message:

Invalid argument: Engine must have only 1 Engine in command Unlock
error: failed to run code signing tool

If I only setup the following it works fine.

section (SEC_UNLOCK;
    Unlock_Engine = "SNVS", // "SRTC", "CAAM", SNVS and OCOTP 
    Unlock_features = "ZMK WRITE" // "Refer to Table-24" 
    )
{
}

I am going to test everything with the board configured for HAB signed verification and see if I did not do any other mistake.

Thanks again.

[FMA]

As a note the flashloader has correctly been signed and I can run commands through the sdphost and blhost utilities to interact with the device.

C:\Flashloader_RT106x_1.0_GA\Tools\sdphost\win>sdphost.exe -p COM4 -- error-status
Status (HAB mode) = 305411090 (0x12343412) HAB enabled.
Reponse Status = 4042322160 (0xf0f0f0f0) HAB Success.

C:\Flashloader_RT106x_1.0_GA\Tools\sdphost\win>sdphost.exe -p COM4 -- write-file 0x20000000 "..\..\elftosb\win\evkbmimxrt1060_flashloader_signed.bin"
Preparing to send 102400 (0x19000) bytes to the target.
(1/1)1%Status (HAB mode) = 305411090 (0x12343412) HAB enabled.
Reponse Status = 2290649224 (0x88888888) Write File complete.

C:\Flashloader_RT106x_1.0_GA\Tools\sdphost\win>sdphost.exe -p COM4 -- jump-address 0x20000400
Status (HAB mode) = 305411090 (0x12343412) HAB enabled.

C:\Flashloader_RT106x_1.0_GA\Tools\sdphost\win>cd ../../blhost/win

C:\Flashloader_RT106x_1.0_GA\Tools\blhost\win>blhost.exe -p COM4 -- get-property 1
Ping responded in 1 attempt(s)
Inject command 'get-property'
Response status = 0 (0x0) Success.
Response word 1 = 1258422528 (0x4b020100)
Current Version = K2.1.0

C:\Flashloader_RT106x_1.0_GA\Tools\blhost\win>blhost.exe -p COM4 -- fill-memory 0x2000 4 0xc0000007
Ping responded in 1 attempt(s)
Inject command 'fill-memory'
Successful generic response to command 'fill-memory'
Response status = 0 (0x0) Success.

C:\Flashloader_RT106x_1.0_GA\Tools\blhost\win>blhost -p COM4 -- configure-memory 0x9 0x2000
Ping responded in 1 attempt(s)
Inject command 'configure-memory'
Successful generic response to command 'configure-memory'
Response status = 0 (0x0) Success.

C:\Flashloader_RT106x_1.0_GA\Tools\blhost\win>blhost -p COM4 -t 30000 -- flash-erase-region 0x60000000 0x100000
Ping responded in 1 attempt(s)
Inject command 'flash-erase-region'
Successful generic response to command 'flash-erase-region'
Response status = 0 (0x0) Success.

C:\Flashloader_RT106x_1.0_GA\Tools\blhost\win>blhost -p COM4 -t 30000 -- write-memory 0x60000000  "..\..\elftosb\win\u-boot_signed_mod.bin"
Ping responded in 1 attempt(s)
Inject command 'write-memory'
Preparing to send 262144 (0x40000) bytes to the target.
Successful generic response to command 'write-memory'
(1/1)100% Completed!
Successful generic response to command 'write-memory'
Response status = 0 (0x0) Success.
Wrote 262144 of 262144 bytes.

I also loaded a signed firmware to the SPI NOR memory connected on flexSPI interface, but, once I have configured back the switches for internal boot, the board does not seem to boot anymore.

Here is what I have done:

Modified the "options" section of the .bd file I used for the flashloader in order to reflect the change of memory and the information present in the unsigned firmware I used to successfully boot on the board:

options {
    flags = 0x08;
    startAddress = 0x60000000;
    ivtOffset = 0x1000;
    initialLoadSize = 0x2000;
    //DCDFilePath = "dcd.bin";
    # Note: This is required if the cst and elftsb are not in the same folder 
    //cstFolderPath = "C:/NXP-Code_Signing_Tool_for_IMX-3.3.1/mingw32/bin/";
    # Note: This is required if the default entrypoint is not the Reset_Handler 
    #       Please set the entryPointAddress to base address of Vector table
    entryPointAddress = 0x60001718;
}

 Sign the file with the elftosb command:

elftosb\win>elftosb.exe -f imx -V -c imx-flexspinor-normal-signed.bd -o u-boot_signed_2.bin u-boot.srec
        Section: 0x14
        Section: 0x15
        Section: 0x16
        Section: 0x18
        Section: 0x19
        Section: 0x1a
        Section: 0x1f
        Section: 0x21
Install SRK
Install CSFK
Authenticate CSF
Install key
Authenticate data
CSF Processed successfully and signed data available in csf.bin
iMX bootable image generated successfully

Added the information in the "FlexSPI Configuration Block" at the beginning of my file. These information are located from address 0x0000 of my file

Copied the resulting binary to the FlexSPI NOR memory using the above mentionned lines in the examples of interactions I could have with the board.

As a note, the elftosb version I ran is version 4.0.0 present in the Flashloader_RT106x_1.0_GA package. I also downloaded the 5.1.19 version from the NXP website hoping it would help but it does not change anything ...

[FMA]

Just for the sake of completing my post, it is now solved:

- The binary firmware generated by our BSP cannot be directly signed by elftosb since I have to add the u-boot DTB into the structure. However, having downloaded the latest version of elftosb utility, as this one generates the intermediate .csf file used by the cst, I could track down the issue.

With a little bit of manual edition of my binaries (I will now have to script it) I could generate a signed firmware that gets my board starting!

[jeremyzhou · Accepted solution]

Hi @FMA ,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) Could you help me figure out what I might be doing wrong?
-- In the above .bd file, the start Address and entry Point Address point to the FlexSPI's memory map, however, the flashloader should be executed in the RAM, so they're definitely in conflict.
2) So how can the output file be actually authenticated since the public key should not be secret and could be associated to any firmware ?
-- The elftosb.exe will locate the corresponding private keys under the keys folder according to .bd file, then sign the image file offline.
3) Can you clarify what those two properties relate to and how they actually differ ? Also, what is the actual purpose of the SEC_CSF_AUTHENTICATE_DATA.Authenticate_DataVerifcationIndex property ?
-- Please check the attachment, however, it's unnecessary to spend a lot of time figuring them out, in my opinion, it's okay to have a genal overview of them, as we usually use the GUI tool to generate the bd file automatically instead of creating a bd file manually.
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.
-------------------------------------------------------------------------------