How to use a smartcard (pkcs11) with create_cert/fiptool

[workhero]

Hi All.

Our target, using the STM32MP153c, shall boot secure. The signing private keys should not be accessible via the filesystem. The secure boot signing is implemented with development keys within yocto at moment. Moving to productive environment will need to use the private secrets from a smart card in a kind of after-yocto signing script.

Currently all private keys used to sign images are in files on filesystem. To sign the TF-A the STM32MP_SigningTool_CLI seems to be feasible of using a secret provided via smartcard, but how to achieve this with the create_cert and/or fiptool for signing the fip image? Especially as the STM32MP_SigningTool_CLI and fiptool should use the same private key. (from my expectation because there is only one public key hash in OTP used to verify the signatures by bootrom and tf-a).

At moment I do not see any other solution then having the private key in filesystem what is not useable in our productive environment. Please hint how to sign the fip image with a HSM (smart card, libp11, openssl-engine).

Thanks in advance.

KR, workhero

[OlivierK]

Hi workhero (Community Member)

Our Chain of Trust relies on secrets (including the keys) to be provisionned in OTP memory, as well as secure closing the chip relying on TF-A BL2 implementing an authentication framework.

https://wiki.st.com/stm32mpu/wiki/TF-A_BL2_Trusted_Board_Boot

OTP secrets are not accessible by the filesystem. it make sense to fuse the secrets in OTP, in a trusted environement using fuse command using STM32CubeProgrammer, or in a untrusted environment using an HSM through the SSP flow (secure secret provisionning).

https://www.st.com/resource/en/application_note/an5510-overview-of-the-secure-secret-provisioning-ssp-on-stm32mp1-series-stmicroelectronics.pdf

Once the OTP secrets are populated, at the end of the SSP flow, the chip will be in Secure closed state. Therefore only TF-A BL2 with authentication enabled (TRUSTED_BOARD_BOOT=1) will be recognized by the BootRom.

Certificates are created during the TF-A BL2 at compilation time, It is possible to directly generate the FIP with all the necessary certificates using the specific build flag GENERATE_COT=1 (can be used along TRUSTED_BOARD_BOOT=1)

https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_BL2

Hope it helps.

Regards,

Olivier

[workhero]

Hi OliverK.

Unfortuantely, this does not help. Because this is already running in Target with development keys.

My question concerns more about the image signing process and the used private key on the signing-machine.

How to use a private key in pksc11 infrastructure for image signing? Trusted board boot supports PKI?

KR,

Micha

[OlivierK]

Hi workhero (Community Member)

Since DV4.0 ecosystem, there is indeed a PKCS#11 support in SigningTool (V2.11.0) which is part of STM32CubeProgrammer package.

STM32MP_SigningTool_CLI -help

...

 --module     -m   : Specify a PKCS#11 module/Library path to load (dll, so, dylib)

               Syntax: -m <File_Path>

 --key-index    -ki   : List of used keys indexes in hex format.

               Use 1 index for Header v1 and 8 indexes for header v2

               Syntax: -ki <value>

 --slot-index   -si   : Specify the index of the slot to use (default 0)

               Syntax: -si <value>

 --active-keyIndex -aki  : Specify th actual active key index (default 0)

               Syntax: -aki <value>

Therefore you can manipulate and sign input binaries based on ECDSA public/private keys stored in security tokens. Available in Windows/Linux/MacOS.

ie: cmd in SigningTool

-bin tf-a.bin -iv <value> -pwd <value> -la <value> -ep <value> -t <type> -of <value> --key-index <value> -aki 0 --module softhsm2.dll --slot-index <index> -o tf-a.stm32

STM32MP SigninTool is able to use preconfigured HSM but it is (not yet) designed to manage or create new security objects.

Kind Regards

Olivier

[workhero]

Hi OliverK,

this is fine for signing the TF-A binary, but how to sign the FIP image? Currently we use create_cert/fiptool to sign the image. As far as I understood those tools, they work with certs and private key in file system.

Do we need to initialize the pcks11 openssl engine before using the fiptool? So we could give a privatekey.pem with content like "pkcs11:token=bla:id=foo" ?

KR,

Micha

[OlivierK]

Hi workhero (Community Member)

cert_create uses openssl API. So in theory it is possible to support pkcs11 via openssl using cert_create.

But as we speak, the cert_create (TF-A version) does not support custom OpenSSL engine.

cert_create (TF-A version) can only take a root-key in .pem format. fiptool doesn't allow to sign certificates, it can remove/add a binary from/to the FIP or create the FIP from binaries.

Kind Regards,

Olivier

[AZaki.2]

Hi all,

I'm also trying to use PKCS#11 for the signing, TF-A signing looks straight forward.

For the FIP by looking at the code, there is no signing of binary but certificates are generated out of of the private key:

https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.8-stm32mp/tools/cert_create/src/main.c#L538

The certificates are then attached to the fip container, I'm wondering how the integrity of the fip is guaranteed without signing ! ?

This does break the secure boot chain completely and make it worthless just to sign the TF-A!

[SimK]

Hi,

i know this is a late response, but perhaps for someone else looking at this:

(@AZaki.2) I think this works in such a way that both TrustedWorldKey and NonTrustedWorldKey are secured via the trusted_key_cert, which is verified with one of the public keys in the TF-A binary, trusted by the fused hashes. The CoT then is below this, e.g. for OPTEE verification:
TrustedWorldPK -> trusted_os_fw_key_cert (publickey) ->trusted_os_fw_content_cert (hash of OPTEE). 

This makes it impossible to embed manipulated certificates in the FIP image.

Unfortunately, my problem is the same as that of the thread creator. I have done several secure boot projects (other SOC vendors) and actually every customer has the requirement to keep the signing keys secret, e.g. via USB tokens, signing servers, whatever. At the latest when the customer is told that something like this can be done, he wants it. The fact that cert_create does not support this and the topic is not covered up in the ST documentation is difficult. (I also think the topic of Yocto configuration and Secureboot is a bit short in the ST documentation - which I otherwise think is very good:-)

As far as I have seen, there is a corresponding commit for TF-A 2.8, I will try to integrate it into our TF-A 2.6 (we are using kirkstone, november 2021 but this was added end of last year):
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=616b3ce27d9a8a83a189a16ff6a05698bc6df3c8

[AZaki.2]

@SimK  thanks for the valuable input, I have already integrated something similar into v2.6 version and is working fine.