Hello,
I'd like to report an issue I encountered with CST regarding RSA-PSS signature verification on an i.MX93-evk platform, which I believe is a bug. Below, I describe the steps that led me to this discovery.
I'm currently implementing the secure boot procedure on an i.MX93-EVK platform and successfully got it working with the standard, documented procedure using CST v4.0.1.
I then wanted to sign the various binaries outside of CST, using OpenSSL directly (note: this is not a PKCS#11 setup, I'm just using my own RSA key with the OpenSSL CLI/API). I came across the following procedure, which describes exactly what I wanted to achieve: Using HSM mode for code signing in AHAB devices.pdf
This works well with keys generated using the ahab_pki_tree tool provided by the Code Signing Tool (CST), with the following parameters:
However, the reason I want to sign binaries outside of CST is that I already have an RSA key that is used for signing various other artifacts. When I use this key to sign the various bin files and then try to reintegrate the signed hashes as described in the linked procedure, I get the following error (CST v4.0.1):
[ERROR] CST: The signature file spl_data.sig is not valid
After double-checking that everything was correct, I also tested verifying my signature using OpenSSL as follows:
$ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK
Expected vs actual: since OpenSSL confirms the signature is a valid PSS signature, I expected CST to accept it during reintegration as well. Instead, CST rejects it as invalid.
I started digging into the CST source code and found why it was incorrectly reporting the signature as invalid, even though it was successfully verified by OpenSSL.
When CST checks the signature, it does the following:
When generating/using what the NXP documentation calls "RSA-PSS" keys, the "Public Key Algorithm" field is equal to rsassaPss and the checks above work correctly.
However, when using a generic RSA key, the "Public Key Algorithm" field is equal to rsaEncryption, and CST wrongly assumes this means the signature format is PKCS#1 v1.5, even though it's entirely possible to sign using the PKCS#1 v2.1 (PSS) format.
I confirmed this incorrect assumption by hardcoding into the CST source code that my signature was a PSS one, and I was then able to get my signature successfully verified and reinserted by CST into the final binary. It then worked as expected on my closed device.
I'm happy to provide more details if needed, especially regarding the various OpenSSL function calls involved.
Could you confirm whether this is a known limitation of CST, or if I might be missing something in how I'm generating/using the signature with a generic RSA key?
As a side question, I also tried using SPSDK, which seems to be the new tool NXP is promoting for AHAB-based platforms, but I couldn't find a way to export the binaries to be signed, sign them manually, and then reinsert them, similar to the CST procedure. Do you know if this is feasible?
Thanks in advance.
Hello,
Actually the document that you are using is correct, is the aproach we suggest for customers that are still using CST. For AHAB, and specially new i.MX9 familly we suggest customers to move to the SPSDK as this is the tool we are using for enablement on security.
Even so you can share the steps you have followed and the changes you made to the tool, so I can review and share with internal team if needed.
Also, for the SPSDK you may have a look to the following:
https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html
Hope this helps,
Best regards/Saludos,
Aldo.