Quaestion:
What does exactly the RNG_TRIM after burning the SRK hash table? There is no such thing on the former i.MX HAB procedure. What would a random generator stuff bring here?
Additionnally, there is the possibility to lock the SRK shadow register via an OTP bit. Is it recommeneded to lock it? if not, is it really possible to change the SRK hash value by modofying the shadow register value before performing the SRK hash key check in a HAB boot process?
One last question: the PKI requires the user to enter a certificate lifetime. Does that really mean that openssl will refuse generating new signatures once the certificates lifetime is expired?
Answer:
1. The intent of the of the RNG_TRIM fuses is for Freescale to essentially extendthe amount of time the RNG4 in CAAM has to generate entropy. The longer this period the more likely it is that RNG4 will generate entropy that will pass its internal statistical tests. The reason for the fuses is HAB (in the Closed configuration only) instantiates the RNG by default and needs some external indication on how to progran the RNG4 in CAAM to ensure the internal HW statistical tests will pass. This was to allow the RNG to be useable by application code after execution has left the ROM. However this requires that the RNG_TRIM fuse value be fully characterized across numerous conditions temperature, voltage etc. This effort is still on going. For customers performing secure boot (in Closed configuration) we recommend they follow Section 6.3 of http://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf. In this case the RNG4 can be instantiated by CAAM driver code which can be easily changed if required.
2. Yes, once the SRK hash is provisioned to the SRK_HASH field it is recommended to blow the corresponding SRK_LOCK fuse. If the SRK_LOCK fuse is not blown then additional fuses in the SRK_HASH field can be blown. This will cause devices in the closed configuration to fail to boot. i.e. "bricking" the device.
3. Please see https://community.freescale.com/message/334186#334186 for the answer to your question on the certificate validity period.
