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
Solved! Go to 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?
Can you share the error while using key3 or key 4?
Best regards
Harvey
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?
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?