AnsweredAssumed Answered

SRK revocation, SRK_REVOKE_LOCK default protection

Question asked by Jose Diaz de Grenu de Pedro on Jun 13, 2016
Latest reply on Aug 10, 2016 by Yuri Muhin

I am reading AN4581 Secure Boot on i.MX50, i.MX53, and i.MX 6 Series using HABv4, Rev. 1, 10/2015, on Appendix A. SRK Revocation on i.MX 6 Series the following is stated:


(...) However, in the Closed configuration, HAB, by default, sets the SRK_REVOKE_LOCK sticky bit in the OCOTP controller to write protect this eFuse field. To instruct HAB not to lock the SRK_REVOKE field requires the use of the Unlock CSF command, with the command flag indicating to unlock the SRK_REVOKE field. Including this command in a CSF signature allows the SRK0 fuse to be blown by a trusted bootloader or runtime image. Below is an example CSF command that unlocks the SRK_REVOKE eFuse field, allowing U-Boot or a later stage to burn the fuse.


I built a signed U-Boot with the following CSF description file:



    Version = 4.0

    Hash Algorithm = sha256

    Engine Configuration = 0

    Certificate Format = X509

    Signature Format = CMS

[Install SRK]

    File = "SRK_table.bin"

    Source index = 3

[Install CSFK]

    File = "CSF4_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate CSF]


    Engine = CAAM

    Features = RNG

[Install Key]

    Verification index = 0

    Target index = 2

    File = "IMG4_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate Data]

    Verification index = 2

    Blocks = 0x177FF400 0 0x60C00 "u-boot-pad.imx"


And I have able to burn the SRK_REVOKE field, and revoke the key index 2. Notice that the following block:



Engine = OCOTP

Features = SRK Revoke


is *not* present the CSF description file I used.


I was expecting not to be able to program the SRK_REVOKE field. Could you explain this behaviour?