Linux app/lib/script that checks CSF signature

[johnjanecek]

To do a firmware upgrade, I would like to verify the CSF signature in user space prior to installing the new firmware.  It seems a user space app can read the SRK fuses and duplicate the signing algorithm using OpenSSL.  Is there an app/lib/script already available that does this? If not, what is the algorithm the CST tool uses for creating the CSF signature?    One could also use this to test the cst tool itself without using the iMX platform.  

[b36401]

Please refer chapter 1.7 OCOTP_CTRL of Security Reference Manual for i.MX 6 Families of Applications Processors regarding to fuses scan protection.

Have a great day,

Victor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[johnjanecek]

Not sure what you mean, but it seems you are implying that the SRK hash cannot be read from user space as you are referring to the fuses scan protection and not the availability of a user space app/lib/script that can check the CSF signature.  I am evaluating the SabreSD i.MX6SX platform and I can run the following commands to read from the eFuse shadow cache:

root@imx6sxgen4:/sys/fsl_otp# cat HW_OCOTP_SRK0

0x0

root@imx6sxgen4:/sys/fsl_otp# cat HW_OCOTP_LOCK

0x20820002

From the Security doc it does mention "Scan protection", but this seems to be from the perspective of JTAG scanning.  Some fuses are (and should be) read protected such as HW_OCOTP_OTPMK0 (master key): 

root@imx6sxgen4:/sys/fsl_otp# cat HW_OCOTP_OTPMK0

0xbadabada

But the SRK hash is not something that needs to be confidential so I would expect it to be readable.  The reference manual (6/2016) seems to support this from section 44.5.25 Shadow Register form OTP Bank3 Word0 (SRK Hash) (OCOTP_SRK0):

Shadow register for the hash of the Super Root Key word0 (Copy of OTP Bank 3, word 0 (ADDR =0x1C)). These bits become read-only after the HW_OCOTP_LOCK_SRK bit is set.

So it seems it is still readable even when the SRK is locked (as expected).  Granted, the device does not have the SEC_CONFIG bit set so I’m not sure if the behavior of reading the SRK shadow registers using sysfs changes under these conditions.  Are you saying that HW_OCOTP_SRK0..7 cannot be read, or more specifically cannot be read after SEC_CONFIG bit is set? If yes, why?