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
Solved! Go to Solution.
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.
#####
Any updates on this? We are looking to use HSM for the Layerscape NXP CoT as well.
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.
Okay, thank you for the quick answer. We will probably have to do something similar.
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.
#####