We are signing imx-boot and linux-imx using a HSM, cst_signer, CST 3.4.0.
Before issuing a ahab_close, verifying SECO events with ahab_status, we see the following in u-boot:
=> ahab_status
Lifecycle: 0x0020, NXP closed
SECO Event[0] = 0x0087FA00
CMD = AHAB_AUTH_CONTAINER_REQ (0x87)
IND = AHAB_BAD_KEY_HASH_IND (0xFA)
sc_seco_get_event: idx: 1, res:3
Reading the SRK OTP values from u-boot, using fuse read 0 730 16 results in the values we have in our uuu script.
We cannot understand where that mismatch is coming from. Any help what we could verify that or guidance in how to debug it would be appreciated.
If any additional info is required to help us to solve this issue, we can provide it.
---
Summary of the commands we are running, our build is yocto-based.
We export from the HSM 4 certificates, let's call them cert{1,2,3,4}.pem.
create table.bin and fuse.bin
.../cst-3.4.0/linux64/bin/srktool -a -s sha384 -t table.bin \
-e fuse.bin -f 1 \
-c cert1.pem,cert2.pem,cert3.pem,cert4.pem
linux-imx:
.../cst_signer -d -i flash_os.bin -c csf.cfg --pkcs11
mv signed-flash_os.bin os_cntr_signed.bin
imx-boot:
cst_signer -d -i imx-boot-imx8qxp-d7-sd.bin-flash -c csf.cfg --pkcs11
Note: the --pkcs11 flag on cst_signer is a patch we've added. It just adds the -b pkcs11 to the call to cst.
csf.cfg looks like this
#Header
header_version=1.0
#Install SRK
srktable_file=SRK_1_2_3_4_table.bin
srk_source=pkcs11:model=YubiHSM;token=YubiHSM;object=./SRK1_sha384_p384_v3_usr;type=cert;pin-value=xxyyxxyyxxyyxxyy
srk_source_index=0
srk_source_set=OEM
srk_revocations=0x0
#Install Certificate
sgk_file=
sgk_permissions=
PKI tree in the HSM params:
Existing CA: N
Use ECC: Y
Key Length: p384
Digest Algorithm: sha384
Duration: 5 years
SRK CA: N