i.MX8 ULP secure boot questions

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

i.MX8 ULP secure boot questions

Jump to solution
2,086 Views
ddresser
Contributor III

 

 

Hello,

I'm trying to implement AHAB on an i.MX8 ULP EVK board.  I'm building the core-image-minimal-secure-boot image with Yocto.  I am currently getting this when booting with my signed image.

=> ahab_status
Lifecycle: 0x00000008, OEM Open

        0x0287f0d6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_SIGNATURE_FAILURE_IND (0xF0)
        STA = ELE_SUCCESS_IND (0xD6)

        0x0287f0d6
        IPC = MU APD (0x2)
        CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
        IND = ELE_BAD_SIGNATURE_FAILURE_IND (0xF0)
        STA = ELE_SUCCESS_IND (0xD6)
I generated both SRKs and SGKs and created the table and fuse binaries using

../linux64/bin/srktool -a -d sha256 -s sha384 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -f 1 -c SRK1_sha384_secp256r1_v3_ca_crt.pem,SRK2_sha384_secp256r1_v3_ca_crt.pem,SRK3_sha384_secp256r1_v3_ca_crt.pem,SRK4_sha384_secp256r1_v3_ca_crt.pem
I used this command to dump the fuse.bin

od -t x4 /opt/cst-3.4.1/crts/SRK_1_2_3_4_fuse.bin
and burned the corresponding bits using

fuse prog 15 0 <bits>

fuse prog 15 1 <bits>

fuse prog 15 2 <bits>.....

 

 

I can see the correct (exact same as above command) bits using

 

 

fuse read 15 0 8

 

 

However, my image currently shows different fuse hash using

 

 

parse_sig_blk.py signed-imx-boot-imx8ulp-lpddr4-evk-sd.bin-flash_singleboot_m33 0x400

 

 

Here is my csf_ahab.cfg file

 

 

#Header
header_version=1.0
#Install SRK
srktable_file=SRK_1_2_3_4_table.bin
srk_source=SRK1_sha384_secp256r1_v3_ca_crt.pem
srk_source_index=0
srk_source_set=OEM
srk_revocations=0x0
#Install Certificate
sgk_file=SGK1_1_sha384_secp256r1_v3_usr_crt.pem
sgk_permissions=0x1

 

 

What should I be looking at or changing.  How can I sign my image to work with the fuses?  Thanks in advance for any help.

 

0 Kudos
Reply
1 Solution
1,799 Views
ddresser
Contributor III

Wanted to follow up and close this out.  My issue was because I was using a different ECC curve length (256) and hash size (384).  This was the word from NXP.

“On 8ULP as well, customer is not able to mix hash size and ecc curve length. This is due to the security architecture EdgeLock Enclave on 8ULP and 9 series of devices.

If customer needs Secure Boot, then they will need new hardware as the fuses cannot be reprogrammed."

View solution in original post

0 Kudos
Reply
6 Replies
1,824 Views
ddresser
Contributor III

Thanks for the reply.

Here is one of my SRKs

SRK1_sha384_secp256r1_v3_ca_crt.pem

From this you can see that I chose an elliptic curve with a length of 256 and a hashing algorithm sha384.  Though it isn't indicated in the documentation, apparently there is a requirement that the key length and hash length match. Since my SRK hash has already been burned to the fuses, I think I'm stuck.  If you know more about this or have any other guidance, please let me know.

0 Kudos
Reply
1,800 Views
ddresser
Contributor III

Wanted to follow up and close this out.  My issue was because I was using a different ECC curve length (256) and hash size (384).  This was the word from NXP.

“On 8ULP as well, customer is not able to mix hash size and ecc curve length. This is due to the security architecture EdgeLock Enclave on 8ULP and 9 series of devices.

If customer needs Secure Boot, then they will need new hardware as the fuses cannot be reprogrammed."

0 Kudos
Reply
1,936 Views
ddresser
Contributor III

After some helpful info fro NXP, I can see that the signing SRK Hash and the SRK Hash stored in the fuses is the same.  The important part is the "sha256" at the end of this command.

TL;DR - My SRK Hashes match but I still get a 

ELE_BAD_SIGNATURE_FAILURE_IND (0xF0)

error.

From the signed image:

ddresser@elmore:~/src/imx-yocto-bsp-secureboot/build/tmp/deploy/images/imx8ulp-lpddr4-evk$ !746                                                                                              
/opt/cst-3.4.1/add-ons/ahab_signature_block_parser/parse_sig_blk.py signed-imx-boot-imx8ulp-lpddr4-evk-sd.bin-flash_singleboot_m33 0x400 sha256                                              
File............ signed-imx-boot-imx8ulp-lpddr4-evk-sd.bin-flash_singleboot_m33                                                                                                              
Offset.......... 0x400             
--------------------------------------------------------------------------------
Container header:
    type............ Image array
    length.......... 800 (0x320)
    srk set......... OEM
    srk source...... 0
    srk revocations. 0
    number of images 3
--------------------------------------------------------------------------------
Signature block:
    offset.......... 0x590
    length.......... 400 (0x190)
    SRK table:
        offset.......... 0x5a0
        length.......... 308 (0x134)
        SRK Table records:
            signature algo.. ECDSA
            hash algorithm.. sha384
            key size/curve.. secp256r1
            curve len....... 32 (0x20)
            SRK 1 record:
                ** SRK record being used **
                offset.......... 0x5a4
                length.......... 76 (0x4c)
            SRK 2 record:
                offset.......... 0x5f0
                length.......... 76 (0x4c)
            SRK 3 record:
                offset.......... 0x63c
                length.......... 76 (0x4c)
            SRK 4 record:
                offset.......... 0x688
                length.......... 76 (0x4c)
        SRK Hash fuses:
            fuse word  0.... 0x9480ad14
            fuse word  1.... 0x7fc5bfc2
            fuse word  2.... 0x53f73ee8
            fuse word  3.... 0xfbf4341d
            fuse word  4.... 0x6a7c4bc1
            fuse word  5.... 0x9a415d07
            fuse word  6.... 0xbf28617b
            fuse word  7.... 0xca922e4c

    Signature:
        offset.......... 0x6d8
        length.......... 72 (0x48) 

 and from the fuses:

Reading bank 15:
Word 0x00000000: 9480ad14 7fc5bfc2 53f73ee8 fbf4341d
Word 0x00000004: 6a7c4bc1 9a415d07 bf28617b ca922e4c
=>   

And here is the fuse.bin contents:

ddresser@elmore:/opt/cst-3.4.1/crts$ od -t x4 SRK_1_2_3_4_fuse.bin 
0000000 9480ad14 7fc5bfc2 53f73ee8 fbf4341d
0000020 6a7c4bc1 9a415d07 bf28617b ca922e4c
0000040
ddresser@elmore:/opt/cst-3.4.1/crts$

But when I flash this image:

sudo uuu -b emmc_all signed-imx-boot-imx8ulp-lpddr4-evk-sd.bin-flash_singleboot_m33

 This is the result in u-boot. I get a "Bad Signature Failure":

 

U-Boot 2024.04-lf_v2024.04+g6c4545203d1+p0 (Nov 15 2024 - 04:02:13 +0000)
M33 Sync: OK
CPU:  i.MX8ULP(Dual 7) rev1.2 at 800MHz
CPU current temperature: 25
Reset cause: POR
Boot mode: Single boot
Model: NXP i.MX8ULP EVK
DRAM: 2 GiB
ERROR:  Agent 0 Protocol 0x10 Message 0x7: not supported
Core: 55 devices, 29 uclasses, devicetree: separate
MMC:  FSL_SDHC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
[*]-Video Link 0 (720 x 1280)
    [0] display-controller@2e050000, video
    [1] dsi@2db00000, video_bridge
    [2] panel@0, panel
In:  serial
Out:  serial
Err:  serial
SEC0: RNG instantiated
switch to partitions #0, OK
mmc0(part 0) is current device
UID: d50e11eab2154685a87d86a866375fe4
flash target is MMC:0
Net:  eth0: ethernet@29950000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
=> ahab_status
Lifecycle: 0x00000008, OEM Open
0x0287f0d6
    IPC = MU APD (0x2)
    CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
    IND = ELE_BAD_SIGNATURE_FAILURE_IND (0xF0)
    STA = ELE_SUCCESS_IND (0xD6)
    0x0287f0d6
    IPC = MU APD (0x2)
    CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
    IND = ELE_BAD_SIGNATURE_FAILURE_IND (0xF0)
    STA = ELE_SUCCESS_IND (0xD6)
=>
8:33
=> fuse read 15 0 8
Reading bank 15:
Word 0x00000000: 9480ad14 7fc5bfc2 53f73ee8 fbf4341d
Word 0x00000004: 6a7c4bc1 9a415d07 bf28617b ca922e4c
=>
8:35
ddresser@elmore:/opt/cst-3.4.1/crts$ od -t x4 SRK_1_2_3_4_fuse.bin 
0000000 9480ad14 7fc5bfc2 53f73ee8 fbf4341d
0000020 6a7c4bc1 9a415d07 bf28617b ca922e4c
0000040
ddresser@elmore:/opt/cst-3.4.1/crts$

I'm trying to understand why. Any help is appreciated.

My current csf_ahab.cfg file:

#Header
header_version=1.0
#Install SRK
srktable_file=SRK_1_2_3_4_table.bin
srk_source=SRK1_sha384_secp256r1_v3_ca_crt.pem
srk_source_index=0
srk_source_set=OEM
srk_revocations=0x0
#Install Certificate
sgk_file=
sgk_permissions=

 

Here are a few more details that may be relevant.

  • I did generate SGK Certs, but they were not included in the list of certs used to generate the SRK Table
  • I have tried specifying an SGK Install Certificate with no change in behavior

Thanks again for any help.

0 Kudos
Reply
2,040 Views
ddresser
Contributor III

Can anyone from NXP comment on the AHAB configuration on i.MX8 ULP EVK?

The fuse on the board appears to only have room for 8 words, but the meta-nxp-security-reference-design yocto layer generates a signed image with a 16 word SRK hash?  What am I missing?

0 Kudos
Reply
2,055 Views
ddresser
Contributor III

Ok, trying to understand something specific.  If I parse my signed image, I get this for the SRK Hash. These are the actual values shown, but they don't match the values dumped from my fuse.bin file.

From parsing the image:

        SRK Hash fuses:

            fuse word  0.... 0x0b2f3e4a

            fuse word  1.... 0x3fd5a13e

            fuse word  2.... 0x8bf5dca6

            fuse word  3.... 0xddc16c2f

            fuse word  4.... 0xf63c34db

            fuse word  5.... 0x6a0267b3

            fuse word  6.... 0x45cc92e2

            fuse word  7.... 0x33d1b23b

            fuse word  8.... 0xb6254a49

            fuse word  9.... 0x8d43a32b

            fuse word 10.... 0x12874d17

            fuse word 11.... 0x90bd1a25

            fuse word 12.... 0x5986bf7b

            fuse word 13.... 0xe552a0a1

            fuse word 14.... 0xabff4bd0

            fuse word 15.... 0xff7f6992

 

dumping the fuse.bin file looks like this (not the real values):

/tmp/parsed/output$ od -t x4 /opt/cst-3.4.1/crts/SRK_1_2_3_4_fuse.bin                                                                                                                             

0000000 0c2f37b9 47b35da1 7ab38fe2 def1322f                                                                                                                                                                       

0000020 3cf567b3 c45d92e2 a1be723b

a2dc573b

First thing I notice is that the hash parsed from the signed image is 512 bits where the has dumped from my fuse.bin file is 256.

from the documentation

  On i.MX8ULP/9x family, the SRK Hash uses sha256 and dump 8 words fuses
  $ od -t x4 SRK_1_2_3_4_fuse.bin
  0000000 db2959f2 90dfc39c 53394566 e0b75829
  0000020 85e6f3b1 af00983d e5e804fe 7a451024

 

My question is where does the fuse hash that is parsed from the image come from?(what code) and how can I get it to embed a 256bit hash?  Thanks for any help.

0 Kudos
Reply
1,842 Views
LFGP
NXP TechSupport
NXP TechSupport
dear @ddresser,
I suggest you to start building Android images once again in order to have a fresh build, then sign the containers, once you are generating the AHAB SRK please follow the next two steps:
Generate AHAB SRK tables.
Enter the directory of ${CST}/crts/, and execute the following command:
$ ../linux64/bin/srktool -a -s sha384 -t SRK_1_2_3_4_table.bin \
-e SRK_1_2_3_4_fuse.bin -f 1 -c \
SRK1_sha384_secp384r1_v3_usr_crt.pem,\
SRK2_sha384_secp384r1_v3_usr_crt.pem,\
SRK3_sha384_secp384r1_v3_usr_crt.pem,\
SRK4_sha384_secp384r1_v3_usr_crt.pem
Additionally, for platforms like i.MX 8ULP and i.MX 95, which only has 8 words of SRK fuses, regenerate
SRK_1_2_3_4_fuse.bin by SHA256 from SRK_1_2_3_4_table.bin:
$ openssl dgst -binary -sha256 SRK_1_2_3_4_table.bin > SRK_1_2_3_4_fuse.bin
After the command is executed successfully, the SRK table and its SHA512 or SHA256 value are generated
and saved respectively in two files under ${CST}/crts/.

the whole process is in the next link
https://www.nxp.com/docs/en/user-guide/IMX_ANDROID_SECURITY_USERS_GUIDE.pdf

thanks for your patience
regards
LFGP
0 Kudos
Reply