How to sign binaries with CST and using a HSM instead of srk.pri/pub local files

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to sign binaries with CST and using a HSM instead of srk.pri/pub local files

Jump to solution
1,356 Views
teddy_gom_e
Contributor III

For a target LS1043AE I can sign ATF  and U-Boot using NXP CST tool to have a secure boot chain of trust.

This tool, CST,  rely on srk.pri and srk.pub local files at root of ATF source tree to sign binaries.

I want to use my company HSM accessed by PKCS#11 to avoid to expose these files (and have them generated inside it).

Is this possible ?

I can build a special version of OpenSSL with engine implementing PKCS#11 and using CST flags OPENSSL_INC_PATH and OPENSSL_LIB_PATH , but how to tell CST to use PKCS#11 instead of local files srk.pri ?

 

edit: typo

Labels (1)
0 Kudos
1 Solution
1,344 Views
yipingwang
NXP TechSupport
NXP TechSupport

You will need access to the public and private key pairs to sign the image and get the public key(s) hash. So there is no work around for that.
One suggestion is to have a dedicated machine to have the CST tool install (not LSDK) to sign the image. You need to secure the access of the software signing machine to minimize the exposure of those files.

The TAUG describes this scenario. They can use the CST for doing all the formatting and creating the hash, then sign the hash with their own HSM. The public key needs to conform to a PEM format. Search for PEM in the TAUG and it should have the guidance they are looking for.

The TAUG has a section cover import and export keys. Please refers to QORIQTRUST21UG_RevC.pdf.
#####
section 8.1.4.2 Externally generated keys
Use of the CST for signing isn't predicated upon the CST generating the RSA keys. Keys can be generated using external mechanisms and imported into the CST in PEM format (base64 encoded). User's generating keys and Super Root Key Hashes with a tool other than the NXP CST are strongly encouraged to confirm that their tools can reproduce the outputs provided in NXP's examples prior to programming values into fuses.
It is also possible to perform the digital signature outside of the CST, using a private key and signing infrastructure external to the manufacturing environment.
#####

View solution in original post

4 Replies
737 Views
jclsn
Contributor IV

Any updates on this? We are looking to use HSM for the Layerscape NXP CoT as well.

0 Kudos
723 Views
teddy_gom_e
Contributor III

Hello,

We  did change our signature process strategy ...

Our new strategy is to generate software without key, copy artifact on USB key and transfer to a secure offline computer to do the final signature process. So the secure computer contains CST and keys..

 

It seems possible to modify CST source code to integrate pkcs12 and using openssl but it was too much time consumming to investigate more, for us.

0 Kudos
705 Views
jclsn
Contributor IV

Okay, thank you for the quick answer. We will probably have to do something similar.

1,345 Views
yipingwang
NXP TechSupport
NXP TechSupport

You will need access to the public and private key pairs to sign the image and get the public key(s) hash. So there is no work around for that.
One suggestion is to have a dedicated machine to have the CST tool install (not LSDK) to sign the image. You need to secure the access of the software signing machine to minimize the exposure of those files.

The TAUG describes this scenario. They can use the CST for doing all the formatting and creating the hash, then sign the hash with their own HSM. The public key needs to conform to a PEM format. Search for PEM in the TAUG and it should have the guidance they are looking for.

The TAUG has a section cover import and export keys. Please refers to QORIQTRUST21UG_RevC.pdf.
#####
section 8.1.4.2 Externally generated keys
Use of the CST for signing isn't predicated upon the CST generating the RSA keys. Keys can be generated using external mechanisms and imported into the CST in PEM format (base64 encoded). User's generating keys and Super Root Key Hashes with a tool other than the NXP CST are strongly encouraged to confirm that their tools can reproduce the outputs provided in NXP's examples prior to programming values into fuses.
It is also possible to perform the digital signature outside of the CST, using a private key and signing infrastructure external to the manufacturing environment.
#####