AM6442: Extending Yocto tiboot3.bin build to support HSM

Hi David,

I am not sure, if I am able to follow your request.

Please clarify:

1) Are you requesting to build tiboot3.bin for HS-SE device with device programmed with your custom keys?

2) Have you built u-boot locally outside yocto and validated the tiboot3.bin?

Thanks

Yogesh

Clarification:

1) No, we know how to build tiboot3.bin for an HS-SE device with our custom key file.

2) No, we have not attempted to build u-boot outside Yocto (and really don't even want to consider doing that)

So to re-state the problem; we think we understand the Yocto flow for building secured binaries with a custom key file. But when you use an HSM, the keys are stored remotely (inside the HSM) and need to be accessed via a token. To achieve that, 'openssl' has to be extended with an 'engine' or a 'provider', and extra arguments are then passed to 'openssl' to indicate which HSM and key should be used for the signing operation.

So the question is - how do we achieve this with the TI tooling within Yocto ?

Hi David,

We have not looked into signing the images using keys from HSM server. Please give us more time to get back on this.

Thanks

Yogesh 

Hi David,

In the spirit of the community I will share what we have learned so far - although in my humble opinion TI or in our case the SOM manufacturer should provide support on this most basic security functionality.

This is a crude edit and I believe there is likely a more elegant solution but by editing/patching openssl.py args parameters (around lines 149 and 230) with something like:

args = ['req', '-new', '-x509', '-engine', 'pkcs11', '-keyform', 'engine', '-nodes',
'-outform', 'DER', '-out', cert_fname, '-config', config_fname,
'-sha512', '-key', 'pkcs11:model=...']

and adding something like the following to recipe-sysroot-native/etc/ssl/openssl.cnf:

engines = engine_section

[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so
MODULE_PATH = ...
INIT_ARGS = ...

I can successfully sign the bootloader binaries by accessing the SMPK private key in the HSM.

I'm having trouble passing in the key path from local.conf and the HSM pin-value with a hidden variable. So if you make any progress in these areas please share your findings.

Regards,

Chris

Chris, that is a *huge* help, thank you.

Yes, it is a hack, and I am pushing for TI to provide a supported solution - but this at least gives me a path forward.

There is a similar Forum question about how to use an HSM for creating the 'opt-keywriter' executable, for blowing the fuses in the first place. I think that is more tricky, in that it looks as if the AES key is also involved in the process; but as that is 'pure' TI scripting, I think that the solution there need to be from TI themselves.

David,

You are correct about the key writer script.  Although looking deeper into how the AES key is used it only protects the hash of the public key (not something that needs protecting) and the SMEK (which currently isn't being used - at least not in Yocto).  Here are my edits to use the HSM when creating the cert used to blow the fuses:

The following changes are necessary to gen_keywr_cert_helpers.sh
line 224
openssl dgst -engine pkcs11 -keyform engine -sign "pkcs11:..." -out "$2" -sha512 "$3"

line 234
<custom command to extract public key from HSM>

The following changes are necessary to gen_keywr_cert.sh:
line 705
openssl req -new -x509 -engine pkcs11 -keyform engine -key <key-id> \

Hope this helps,

Chris

Chris,

That is just *so* helpful !!

As I said, I hadn't got into digging through the TI scripts in this level of detail, but this clarifies much of what goes on under the hood.

It would be really good to see this in a TI App note or equivalent, as I am certain that we are not the only folk wanting to use an HSM for production signing !

David

Thanks Chris!! Appreciate providing the pointers.

David,

TI was using k3-image-gen tool to sign the images before switching to binman. The idea was to use open-source tool to sign the images that is expandable.

We agree that TI should provide app-note/FAQ to extend the binman to use HSM server for signing.

We plan to provide a working reference by 3/21 with the changes to bin-man and yocto integration. Will try and publish this in 2Q 2025.

Feel free to reach out, if you are already trying Chris suggestion and running into any issues.

Thanks

Yogesh

Yogesh,

That would be amazing !! Thank you.

I confess that it puts us in a tricky position, as we are currently expected to make a delivery this quarter to a customer with this all operational; but having a schedule from TI for a supported integration may help with setting our delivery feature-set.

Please feel free to ask me to try any prototypes you wish to experiment with

Regards,

David

Gentlemen,

I was not aware of this thread so far.

We implemented HSM integration exactly the same way as Chris did. We also think that TI should provide an according modification basically in <u-boot-root>/tools/binman/btool/openssl.py and bring that modification mainline.

From a user point of view, we suggest to enhance the ti_secure and ti_secure_rom entries (see https://docs.u-boot.org/en/stable/develop/package/entries.html#entry-ti-secure-entry-containing-a-ti-x509-certificate-binary) to allow two additional properties optionally being defined, e.g. "engine" and "keyform". Whenever one or both of the optional properties are defined, then OpenSSL should be called with according additional options.

This would allow us - together with the already existing "keyfile" property - to have cryptographic operations offloaded to a HSM.

Regards

Walter

Yogesh,

Is the Q2 plan still on track? Is there a working reference you are able to share already?

Could you also address Chris his remarks that the AES key is not used to encrypt the actual binary but rather the hash of the public key or SMEK?

Having a full working reference of a full HSM flow would be extremely helpful as this is currently a pain point we encounter pretty much everywhere.

I've been able to get quite far into how it all fits together but a sort of all in one guide would still be helpful.

There is also quite some distributed information, so if there would be a possibility for a full guide or appnote that elaborates on all the signing, what the encryption does, what all the interacting tools/components are and how to protect the full lifecycle of associated signing/encryption keys with a HSM during generation/signing/encryption/provisioning would be very much appreciated and would put TI way above what other manufacturers currently provide.

Regards,

Jesse

One item of note that we have run into here...

Due to the way the k3-binman.dtsi and k3-am64x-binman.dtsi files are processed, the pkcs11 strings used to access the HSM get stored in the dtb (together with the password-pin in my early attempt !!)

This is not the most secure procedure !! Ok-ish for filenames, but not for signing key-names.

So it would be good if the way the key-access-information could be provided "outside" the compiled dtb, or if there could be a way to strip the the key information out of the dtb before it is packed into the final binary. (tricky, because this needs to be completed before any signatures are taken of the dtb)

Regards,

David

Ouch, that is indeed a rather major oversight.

Key lifecycle security and correct management should be baked in from the start, glad you're raising the issue!