Secure boot issue on i.MX6Q

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Secure boot issue on i.MX6Q

1,480 Views
Demc
Contributor I

Hello everyone,

I'm trying to create a secure boot setup on a custom i.MX6Q board based on the Sabre design and have faced an issue with HAB error messages with a signed U-Boot image.

Here is what I did:

1. Generated secure keys using the CST 3.4.1 with the following command:

./hab4_pki_tree.sh -existing-ca n -kt rsa -kl 2048 -duration 100 -num-srk 4 -srk-ca y

2. Created the hash table and fuse files:

cd ../crts

../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c SRK1_sha256_2048_65537_v3_usr_crt.pem,SRK2_sha256_2048_65537_v3_usr_crt.pem,SRK3_sha256_2048_65537_v3_usr_crt.pem,SRK4_sha256_2048_65537_v3_usr_crt.pem -f 1

Number of certificates = 4
SRK table binary filename = SRK_1_2_3_4_table.bin
SRK Fuse binary filename = SRK_1_2_3_4_fuse.bin
SRK Fuse binary dump:
SRK HASH[0] = 0x71807F6D
SRK HASH[1] = 0xC7712A7B
SRK HASH[2] = 0x4FD1F177
SRK HASH[3] = 0xD9B6A0BA
SRK HASH[4] = 0x6C68932D
SRK HASH[5] = 0xA39A2D5A
SRK HASH[6] = 0x31E7FE5E
SRK HASH[7] = 0x7E7146C7

3. Programmed the fuses to the OTP. The OTP words match the one generated by srktool:

=> fuse read 3 0 8
Reading bank 3:

Word 0x00000000: 71807f6d c7712a7b 4fd1f177 d9b6a0ba
Word 0x00000004: 6c68932d a39a2d5a 31e7fe5e 7e7146c7

4. Took the u-boot-sd-2023.04-r0.imx file (size 748544 bytes) built in Yocto.

5. Edited a CST configuration example file csf_image0-my.txt:

[Header]
        Version = 4.3
        Hash Algorithm = sha256
        Engine = CAAM
        Engine Configuration = 0
        Certificate Format = X509
        Signature Format = CMS
[Install SRK]
        File = "/home/dk/legrand/cst-3.4.1/crts/SRK_1_2_3_4_table.bin"
        Source index = 0
[Install CSFK]
        File = "/home/dk/legrand/cst-3.4.1/crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
[Authenticate CSF]
[Unlock]
<------>Engine = CAAM
<------>Features = RNG
[Install Key]
        Verification index = 0
        Target index = 2
        File = "/home/dk/legrand/cst-3.4.1/crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
[Authenticate Data]
        Verification index = 2
        Blocks = 0x177FF400 0x00000000 0x000B6C00 "u-boot-sd-2023.04-r0.imx"

6. Signed the U-Boot image as follows:

cst --i csf_image0-my.txt --o csf_image0-my.bin && cat u-boot-sd-2023.04-r0.imx csf_image0-my.bin > my-signed-u-boot

7. When the my-signed-u-boot image is booted on the board from USB or EMMC, I get the following messages in hab_status:

=> hab_status                                                                                                                                                                                              
                                                                                                                                                                                                           
Secure boot disabled                                                                                                                                                                                       
                                                                                                                                                                                                           
HAB Configuration: 0xf0, HAB State: 0x66                                                                                                                                                                   
                                                                                                                                                                                                           
--------- HAB Event 1 -----------------                                                                                                                                                                    
event data:                                                                                                                                                                                                
        0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00                                                                                                                                                            
        0x00 0x00 0x00 0x00 0x17 0x7f 0xf4 0x00                                                                                                                                                            
        0x00 0x00 0x00 0x20                                                                                                                                                                                
                                                                                                                                                                                                           
STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)


--------- HAB Event 2 -----------------
event data:
        0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
        0x00 0x00 0x00 0x00 0x17 0x7f 0xf4 0x20
        0x00 0x00 0x00 0x01

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)


--------- HAB Event 3 -----------------
event data:
        0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
        0x00 0x00 0x00 0x00 0x17 0x80 0x00 0x00
        0x00 0x00 0x00 0x04

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)


--------- HAB Event 4 -----------------
event data:
        0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
        0x00 0x00 0x00 0x00 0x00 0x91 0x00 0x00
        0x00 0x00 0x02 0xf8

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)


--------- HAB Event 5 -----------------
event data:
        0xdb 0x00 0x14 0x41 0x33 0x1d 0xc0 0x00
        0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00
        0x00 0x00 0x00 0x50

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_KEY (0x1D)
CTX = HAB_CTX_COMMAND (0xC0)
ENG = HAB_ENG_ANY (0x00)

Is there any mistake in my key generation/image signing procedure? What does the HAB failure message may indicate?

Any help with this issue is highly appreciated.

Regards,

Dmitry

 

Labels (2)
0 Kudos
Reply
4 Replies

1,389 Views
Demc
Contributor I

Hi Harvey,

Thanks for the pointers, they helped. I was able to find out that the problem was with the SRK key as HAB complained about the key in HAB Event 5 in the log.

I seem to find the cause of the issue and it looks like a bug in the srktool utility. In a third-party sample of usage of the utility I noticed that the SRK certificate names are prepended with the "./" characters. When I modified the command as follows:

../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c ./SRK1_sha256_2048_65537_v3_usr_crt.pem,./SRK2_sha256_2048_65537_v3_usr_crt.pem,./SRK3_sha256_2048_65537_v3_usr_crt.pem,./SRK4_sha256_2048_65537_v3_usr_crt.pem -f 1

I got different SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files which made the signed image pass the HAB signature check (on another board, obviously, as the SRK hash changed and the first board is programmed with a wrong hash).

In the help strings printed by srktool there are no mentions that the "./" characters are mandatory. It only mentions that a file name can be prepended with the # sign to include the hash digest in the table file:

 -c, --certs <srk1>,<srk2>,...,<srk4>:
      X.509v3 certificate filenames.
        - Certificates may be either DER or PEM encoded format
        - Certificate filenames must be separated by a ','with no spaces
        - A maximum of 4 certificate filenames may be provided. Additional
          certificate names are ignored
        - Placing a % in front of a filename replaces the public
          key data in the SRK table with a corresponding hash digest

Also, there are no "./" in the samples in the help strings:

    srktool --hab_ver 4 --table table.bin  --efuses fuses.bin \ 
            --digest sha256 \ 
            --certs srk1_crt.pem,srk2_crt.pem,%srk3_crt.pem

Shouldn't this be fixed in srktool?

0 Kudos
Reply

1,382 Views
Harvey021
NXP TechSupport
NXP TechSupport

Hi 

I usually use the srktool for SRK table and fuse generation by following up the format as 

$ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e \
  SRK_1_2_3_4_fuse.bin -d sha256 -c \
  SRK1_sha256_2048_65537_v3_ca_crt.pem,\
  SRK2_sha256_2048_65537_v3_ca_crt.pem,\
  SRK3_sha256_2048_65537_v3_ca_crt.pem,\
  SRK4_sha256_2048_65537_v3_ca_crt.pem

Which can be found from here introduction_habv4.txt 

One thing to be noted, No space between certificate filenames and just the ",". Otherwise, the different fuse values would be expected.

 

Regards

Harvey

0 Kudos
Reply

1,375 Views
Demc
Contributor I
Hi Harvey,

It turned out that I initially used wrong USR (SRK1_sha256_2048_65537_v3_usr_crt.pem) keys instead of the CA (SRK1_sha256_2048_65537_v3_ca_crt.pem). The old key files might have stayed from some previous key generation attempt.

So, no issues with srktool, just my mistake.

Thanks for your help!
0 Kudos
Reply

1,447 Views
Harvey021
NXP TechSupport
NXP TechSupport

Hi,

The word - 0x33 0x0c 0xa0 0x00 indicates an assertion event, which means one of the following required areas is not signed as documented in the operation section for authenticate_image() API.

• IVT;
• DCD (if provided);
• Boot Data (initial byte - if provided);
• Entry point (initial word).

To refer to the HABv4_API, you will get more explanations. and you can have a dump your image to check its IVT.

 

Regards

Harvey

0 Kudos
Reply