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.

[hpalacio]

Hello @AZaki.2 

I'm also looking into signing the FIP image. May I ask you for an example of the cert_create command you used to sign the certificates accessing the private key via PKCS11? I think I need to build a proper PKCS11 URI, and an example would help me a lot.

Thank you!

[SimK]

It's a while since i did this, i didn't check the newest baseline from ST, but back then for kirkstone it was really incomplete support for FIP signing (and no yocto support for TF-A signing at all).

 

I had to build and install it for my host environment (HOSTTOOLS) in order to do the "communication" with the host openssl / pkcs11 instance for the ROT key (which is an USB stick in my case).

Clone it from master (https://github.com/ARM-software/arm-trusted-firmware.git) and then get the baseline for your yocto (e.g. based on the used BSP from ST). I used kirkstone v4 so we used v2.6 and i backported all changes for the cert_create folder of tf-a. (a handfull commits).

in case we are signing via PKCS11 i set the CERTTOOL variable to the external "cert_create", which is installed under a different name in our build system:

CERTTOOL = "${@bb.utils.contains('EXTERNAL_SIGN_PKCS11','1','cert_create_ext', 'cert_create',d)}"

FIP_SIGN_KEY has then to point to the URI like

pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=xyz;token=xyz;id=%01;object=tfa-pkey00;type=private

i used the STM32MP_KeyGen_CLI to create the keys (for STM32MP13 eight keys):

STM32MP_KeyGen_CLI -abs <path> -pwd <pwd1> <pwd2>... -n8

(this is relatively good documented)

 

then import it into your token, e.g with softhsm

softhsm2-util --import privateKey00.pem --label tfa-pkey00 ....

 

if you need the infos for URI creation i can recommend the p11tool with the option "--list-all". It shows all infos which should be part of the URI.

 

If i remember correctly you have to import all eight ROT keys (no matter that you use only one selected key for signing) so that the Signing-Tool can use them to create the hashtable for fusing at the end.

[AZaki.2]

Hi,

 

we have integrated automated HSM Signing (SoftHSM, NitroKey, AWS) for TF-A/FIP/FitImage in Yocto Build,

Please get in touch on [e-mail] for Commercial Support if needed.

 

Best regards 

[GatienC]

Hello, I made a guide using SoftHSM as the external HSM. This example uses a PKCS11 engine. Please have a look here: Signing a software using an external HSM.

 

Hope this helps. Note that some OpenSSLV1.x version will need the following patch: Certtool patch 

[SimK]

Hi, thank you for the article. The real effort for us was not using PKCS but building the signing into the Yocto build process, at least for kirkstone there was nothing. It would be nice if complete signing of TF-A and FIP could be incorporated into the BSP. We were able to add everything to the existing tasks thanks to Yocto's prepend/append mechanism, but it was a bit of effort. 

And ST could consider disclosing the source code of the signing tool so that you can see directly what is happening.

[AZaki.2]

Hi, We have developed an alternative BSP layer for the STM32MP15x platform:

https://github.com/embetrix/meta-stm32mp15x

 

Secure Boot Chain of Trust, fully implemented signing for:

TF-A → FIP (Optee + U-Boot) → FitImage → Kernel Modules

 

It also Utilizes a reverse-engineered Python tool, stm32mp-keygen, instead of ST's official signing tools.

 

It's Lightweight and Flexible and seamlessly integrates into Yocto builds and Docker-based containerized build environments.

 

Comprehensive build instructions are provided n README for easy setup.

 

Premium Offering:

For paying customers, we also provide HSM-based signing solutions for enhanced security and compliance.

 

If you’re interested in leveraging this solution and security-focused BSP layer or the advanced HSM signing capabilities, feel free to reach out at : [e-mail]