uni_sign public key hashing

[joshuafaust]

I am re-creating the CSF generation within java as we have a security requirement to use TRNG RSA keys. As such, I am now running into one issue, the hash of the public key for secure boot. I have found the three different functions that are being called to create the SHA256 hash within crypto_utils.c however, the parameters that are being passed do not make much sense to me. So, during my testing process I have been just hashing the public key but I will get the

ERROR :: 400 :: Public key hash comparison failed

I have hashed the public key in all of the following formats but my hashes never match those generated by the uni_sign and all subseqent program calls uni_sign uses:

1. Standard PEM base64 formatting in ASN.1 with Key Headers
2. Standard PEM base64 formatting in ASN.1 w/o Key Headers
3. Binary file (base64 –d) in ASN.1
4. Binary file (base64-d) raw key (Two big integers)
5. ASCII representation of Binary File in ASN.1
6. ASCII representation of Binary File raw

Can someone point me in the right direction? What is the data that needs to be hashed?

[Larry5335]

I assume you are asking about the SRKH calculation. In the SDK
documentation (e.g. SDK2.0 1703), it shows the CST commands to create
CSF header for above mentioned images

./uni_sign input_files/uni_sign/<platform>/sdboot/input_uboot_secure

CSF Header Format (B4/T1/T2/T4 Platforms) shows 0x08 Srk table flag.
This flag indicates whether hash burnt in srk fuse is of a single key
or of a srk table.

Are you using single key OR key list? That may be what you are missing
from creating the HASH parameters form the CST. CST generates and
stores a SHA-256 hash of the public key/table of 4 keys.

Please refer to the "input_files/uni_sign/<platform>/input_uboot_secure"
for more detail what CST expects.

When performing this hash without the CST, remember to convert the
public key to PEM format, then perform a binary hash of the hex bytes.
Do not perform a string hash of the text.

[joshuafaust]

Thank you for replying Larry,

• Looking at both the ESBC and ISBC CSF files, byte 0x08 is 00.
• We do not utilize a list of keys rather, just a single key.
  •  The RSA 4096 Public Key is generated using a Thales HSM which is exported in a PEM format. I have also noticed that NXP uses a different formatting within their PEM key output as there are an extra 25 bytes of data in an OpenSSL or HSM generated key (800 bytes) compared to one generated with the gen_keys (775 Bytes). Also the start and end text of the PubK PEM is different as NXP uses "----- BEGIN RSA PUBLIC KEY----" and "-----END RSA PUBLIC KEY-----" whereas a key generated from OpenSSL CLI tools or the Thales HSM has "-----BEGIN PUBLIC KEY -----" and "-----END PUBLIC KEY-----". These differences have been noted and I have formatted the HSM created public key into a format that complies with the key generated by gen_keys. 
• Our hash digest is a single function that takes a byte array as a parameter and then feeds those bytes to the SHA 256 digest. I originally thought my main issue was that first, the HSM and OpenSSL's definition of a PEM format in ASN.1 DER was not symmetrical to that of gen_keys function. Which was correct as I mentioned above but, even with the key changes, we get a different hash then that of uni_sign. 

Thanks for the help so far. Hopefully, we can figure this one out haha!