i.MX8MP hab signing with key 3 and 4 fails

[per_christensen]

Hi, 
I'm testing hab signing on a imx8mp-evk with cst tool version 3.3.1.
Using key 1 and key 2 is working fine as expected but when switching to key 3 or key 4 the signing is not accepted by the target (imx8mp-evk).

The csf_spl.txt used is like this:

[Header]
  Version = 4.3
  Hash Algorithm = sha256
  Engine = CAAM
  Engine Configuration = 0
  Certificate Format = X509
  Signature Format = CMS

[Install SRK]
  # SRK_TABLE is full path to SRK_1_2_3_4_table.bin
  File = "/<path-to-keys>/crts/SRK_1_2_3_4_table.bin"
  Source index = 0

[Install CSFK]
  # CSF_KEY is full path to CSF1_1_sha256_4096_65537_v3_usr_crt.pem
  File = "/<path-to-keys>/crts/CSF1_1_sha256_secp521r1_v3_usr_crt.pem"

[Authenticate CSF]

[Unlock]
  Engine = CAAM
  Features = MID

[Install Key]
  Verification index = 0
  Target Index = 2
  # IMG_KEY is full path to IMG1_1_sha256_4096_65537_v3_usr_crt.pem
  File = "/<path-to-keys>/crts/IMG1_1_sha256_secp521r1_v3_usr_crt.pem"

[Authenticate Data]
  Verification index = 2
  # FIXME: Adjust start (first column) and size (third column) here
  Blocks = 0x91ffc0 0x0 0x29f00 "flash.bin"

When switching to key 3, Source index is changed to 2 and csfk key is changed to CSF3_1_sha256_secp521r1_v3_usr_crt.pem and image key is changed to IMG3_1_sha256_secp521r1_v3_usr_crt.pem.

Why is key 1 and 2 working and key 3 and 4 not? - all keys are generated with cst tool version 3.3.1

Keys and SRK are generated with following command:

~/cst-3.3.1/keys$ ./hab4_pki_tree.sh -existing-ca n -use-ecc y -kl p521 -duration 100 -num-srk 4 -srk-ca y

~/cst-3.3.1/crts$ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256  -f 1 -c ./SRK1_sha256_secp521r1_v3_ca_crt.pem,./SRK2_sha256_secp521r1_v3_ca_crt.pem,./SRK3_sha256_secp521r1_v3_ca_crt.pem,./SRK4_sha256_secp521r1_v3_ca_crt.pem

[Harvey021]

Can you share the error while using key3 or key 4?

Best regards

Harvey

[per_christensen]

I'm using usb-serial download via uuu. When downloading an u-boot image signed with key 1 or 2, a lot of boot information is printed on the debug uart - normal u-boot output. but when signing the u-boot image (flash.bin) with ex. key 4 there is nothing printede out - not even an CSF error-code. of course uuu fails with 

Wait for Known USB Device Appear...
New USB Device Attached at 3:12
3:12>Start Cmd:SDPS: boot -f "flash.bin"
13%3:12>Fail HID(W):LIBUSB_ERROR_IO(0.034s)

but I don't think you can use uuu's error to finde the problem.

Therefore to go a step deeper, I have tried to sign the spl with key 1 and the fit-image with key 4, simply by having csf_spl.txt to point at source index 0 and csf_fit.txt to point at source index 3. Now spl boots as expected but the fit-images fails - still without any error-code

U-Boot SPL 2023.07-00049-g6a6d86cd3d (Nov 06 2023 - 11:01:52 +0100)
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
Trying to boot from BOOTROM
Boot Stage: USB boot
Find img info 0x4802c000, size 763443
Need continue download 762880

Authenticate image from DDR location 0x44000000...
spl: ERROR: image authentication unsuccessful

resetting ...

To get a step deeper I have modify the hab.c to print debug out and to get the hab status when the authentication fails - with the following changes:

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 439cdaf07a..70d5966786 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -3,6 +3,8 @@
  * Copyright (C) 2010-2015 Freescale Semiconductor, Inc.
  */
 
+#define DEBUG
+
 #include <common.h>
 #include <command.h>
 #include <config.h>
@@ -246,7 +248,7 @@ void *hab_rvt_authenticate_image(uint8_t cid, ptrdiff_t ivt_offset,
        return ret;
 }
 
-#if !defined(CONFIG_SPL_BUILD)
+// #if !defined(CONFIG_SPL_BUILD)
 
 #define MAX_RECORD_BYTES     (8*1024) /* 4 kbytes */
 
@@ -555,7 +557,7 @@ static int get_hab_status_m4(void)
        return 0;
 }
 #endif
-
+#if !defined(CONFIG_SPL_BUILD)
 static int do_hab_status(struct cmd_tbl *cmdtp, int flag, int argc,
                         char *const argv[])
 {
@@ -937,7 +939,7 @@ int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
        puts("Dumping CSF Header\n");
        print_buffer(ivt->csf, (void *)(uintptr_t)(ivt->csf), 4, 0x10, 0);
 
-#if  !defined(CONFIG_SPL_BUILD)
+#if  defined(CONFIG_SPL_BUILD)
        get_hab_status();
 #endif
 
@@ -987,7 +989,7 @@ int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
        }
 
 hab_exit_failure_print_status:
-#if !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_SPL_BUILD)
        get_hab_status();
 #endif

The debug-output now comes with the following hab event:

U-Boot SPL 2023.07-00049-g6a6d86cd3d-dirty (Nov 06 2023 - 13:16:40 +0100)
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
Trying to boot from BOOTROM
Boot Stage: USB boot
Find img info 0x4802ae00, size 764147
Need continue download 763904

Authenticate image from DDR location 0x44000000...

ivt_offset = 0xbb000, ivt addr = 0x440bb000
ivt entry = 0x440bb000, dcd = 0x00000000, csf = 0x440bb020
Dumping IVT
  .. A...D........
  .......D ..D....
Dumping CSF Header
  ..`C...........`
  ................
  ................
  ...!............

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!


Calling authenticate_image in ROM
	ivt_offset = 0xbb000
	start = 0x44000000
	bytes = 0x440bb000

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99

--------- HAB Event 1 -----------------
event data:
	0xdb 0x00 0x14 0x45 0x33 0x1d 0xc0 0x00
	0xbe 0x00 0x0c 0x00 0x03 0x17 0x03 0x00
	0x00 0x00 0x00 0x60

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

spl: ERROR: image authentication unsuccessful

resetting ...

From this event message the error see to be invalid key, but how can the key be invalid if it is part of the SRK pki tree structure generated via the cst-3.3.1 tool?

[per_christensen · Accepted solution]

Problem found.

For some unknown reason the SRK_1_2_3_4_table.bin is only containing key 1 and 2.

After generating a new hash table with the srktool (from the existing certificates and with same commandline) and compare it with the old one - it is clear that the size is twice as large as the old one.

~/cst-3.3.1/crts$ hexdump -C SRK_1_2_3_4_table.bin 
00000000  d7 01 24 40 e1 00 90 27  00 00 00 80 4e 00 02 09
00000010  00 0d 41 15 06 62 c8 a3  9b dd e4 f5 aa 4e ea 53
00000020  18 d5 e8 84 e2 26 b1 17  c8 a3 a6 90 ef de 35 92
00000030  3c a5 17 af d0 9f b0 5d  c3 e1 4c 5e 94 f1 8c 13
00000040  24 e9 84 70 bd 3c fe 3c  47 fe 17 58 4d 40 97 77
00000050  48 bd 01 71 59 25 3c 0c  26 63 65 38 8b c8 48 f3
00000060  52 8b 15 87 16 62 21 54  2f bf 10 98 d9 7e d5 47
00000070  3f 64 0c 6b b6 82 a7 1d  27 27 b5 63 0f dd 56 16
00000080  f4 44 21 80 fd aa 8d ee  b8 26 e5 03 88 1d 53 53
00000090  0d 84 fe ea e1 00 90 27  00 00 00 80 4e 00 02 09
000000a0  01 cc 1f 73 e4 dd 3f d5  9e f2 3d a9 19 d6 a7 3e
000000b0  16 85 10 50 a3 cd cf ff  84 77 d6 0d 8f ee a8 e6
000000c0  34 cf 8d 3e d0 d9 94 3f  a4 e3 81 49 2d 07 7f 2d
000000d0  aa 74 0a 46 8a 22 fa d8  40 71 0b 92 b0 31 b5 79
000000e0  ce 25 00 95 69 5c 6d 81  35 d5 2a 9e af f1 0f ed
000000f0  6b ad 1d 55 46 01 f6 e4  9d 5c eb c3 d7 2d b1 14
00000100  6e 68 c0 8d 2f 94 b2 01  dd 02 66 38 f0 4d 42 ab
00000110  a5 97 07 9c 87 36 8a dc  bf 84 25 da 94 5e 80 09
00000120  bc 60 36 e6                                     
00000124
~/cst-3.3.1/crts$ hexdump -C TEST_1_2_3_4_table.bin 
00000000  d7 02 44 40 e1 00 90 27  00 00 00 80 4e 00 02 09
00000010  00 0d 41 15 06 62 c8 a3  9b dd e4 f5 aa 4e ea 53
00000020  18 d5 e8 84 e2 26 b1 17  c8 a3 a6 90 ef de 35 92
00000030  3c a5 17 af d0 9f b0 5d  c3 e1 4c 5e 94 f1 8c 13
00000040  24 e9 84 70 bd 3c fe 3c  47 fe 17 58 4d 40 97 77
00000050  48 bd 01 71 59 25 3c 0c  26 63 65 38 8b c8 48 f3
00000060  52 8b 15 87 16 62 21 54  2f bf 10 98 d9 7e d5 47
00000070  3f 64 0c 6b b6 82 a7 1d  27 27 b5 63 0f dd 56 16
00000080  f4 44 21 80 fd aa 8d ee  b8 26 e5 03 88 1d 53 53
00000090  0d 84 fe ea e1 00 90 27  00 00 00 80 4e 00 02 09
000000a0  01 cc 1f 73 e4 dd 3f d5  9e f2 3d a9 19 d6 a7 3e
000000b0  16 85 10 50 a3 cd cf ff  84 77 d6 0d 8f ee a8 e6
000000c0  34 cf 8d 3e d0 d9 94 3f  a4 e3 81 49 2d 07 7f 2d
000000d0  aa 74 0a 46 8a 22 fa d8  40 71 0b 92 b0 31 b5 79
000000e0  ce 25 00 95 69 5c 6d 81  35 d5 2a 9e af f1 0f ed
000000f0  6b ad 1d 55 46 01 f6 e4  9d 5c eb c3 d7 2d b1 14
00000100  6e 68 c0 8d 2f 94 b2 01  dd 02 66 38 f0 4d 42 ab
00000110  a5 97 07 9c 87 36 8a dc  bf 84 25 da 94 5e 80 09
00000120  bc 60 36 e6 e1 00 90 27  00 00 00 80 4e 00 02 09
00000130  00 3e 37 1c 5f 86 59 b1  11 98 50 69 7a 10 e1 5b
00000140  0f a9 fa 84 9f f9 ac 1f  59 12 da 1d fe 45 96 71
00000150  dd 34 40 d9 0c 21 c8 16  97 d2 a4 a6 20 d2 d4 52
00000160  c8 72 15 6e 2a 52 e4 af  b4 61 70 f3 f8 1e 7c f1
00000170  cf c7 00 c5 1c 06 af ac  9b 60 77 b7 2c 3c 9d 17
00000180  76 24 69 d4 3e 09 da 34  cb 8f b6 da 7f 52 d0 f6
00000190  53 30 18 b2 c7 97 84 3a  e5 a2 97 49 3d d2 85 f6
000001a0  94 0a 3a f0 b9 04 2a 97  ca 61 e4 8f 90 7a be 31
000001b0  cf 4d 6e 46 e1 00 90 27  00 00 00 80 4e 00 02 09
000001c0  01 c6 2c 1f 85 17 37 d7  d4 c6 f1 5a 89 19 0c eb
000001d0  2e 61 99 da f5 0d 6e a8  81 41 0a 24 71 9e 4d d5
000001e0  0b 71 57 08 58 1e 26 36  e6 93 bd 77 86 6b 62 bb
000001f0  ad 22 e7 a1 8d 4a 80 af  f6 d1 ed 57 be 96 18 85
00000200  a1 3f 00 20 1f 50 7f 50  9d fa e0 d4 75 5c 3a 79
00000210  84 0c 57 14 10 57 1e 80  2e ca 05 85 90 a3 ce 76
00000220  63 86 79 1f 77 a0 b8 94  5e ac 55 e9 35 b1 11 1c
00000230  5f 4e 75 47 e3 8f 54 d1  8b 79 db 80 0e 61 c9 20
00000240  46 46 c8 ef                                     
00000244

SRK_1_2_3_4_table.bin is the old table and TEST_1_2_3_4_table.bin is the new table

Is there a way to verify the table and fuse file against the certificates? - a sort of a reverse srktool?