mx6ul, hab, secureboot and fuse progr

[giuliodominutti]

Hi everybody, I'm new in this field, so please be patient if my questions will be too easy for you.

I started working on secure boot HAB and I have a few questions about this argument and u-boot signature.

1) many tutorial spoke about "fuse prog" for the SRK, I was wandering if it exists a different way to validate an u-boot image maybe only writing in the shadow memory before u-boot starts (via JTAG)? ( I wasn't able to understand if in the validation phase HAB uses values in shadows memory or not. (other way to debug a secure boot without prog the OTP fuse are appreciated)

2)When we create the signature using the tool ./cst I use the following csf file:

[Header]
    Version = 4.2
    Security Configuration = Open
    Hash Algorithm = sha256
    Engine Configuration = 0
    Certificate Format = X509
    Signature Format = CMS
[Install SRK]
    File = "../crts/SRK_1_2_3_4_table.bin"
    Source index = 0
   [Install CSFK]
     File = "../crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem"
[Authenticate CSF]
[Install Key]
    Verification index = 0
    Target Index = 2
    # Key to install
    File= "../crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem"
[Authenticate Data]
     Verification index = 2
    #AddressOffset     Length        Data     File         Path
    Blocks =        0x177FB000     0x000     0x87C00    "../../u-boot/u-boot.imx"

Can someone explain me exactly what the Blocks value are discovered?

2.1) is correct to sign all the .imx image? including IVT

2.2) where exactly can I find (understand) the first value of length ?

Thanks everybody.

[Yuri]

Hello,

  Please look at my comments below.

1.

  There is no different way to validate an u-boot image, using for example shadow

memory.

2.

  Section [Authenticate Data] is used to check signed padded u-boot, which

includes all data, starting from the IVT till the end with the length, stated

in the section (Blocks). Padded u-boot length is assumed.

This covers the essential parts: IVT, boot data and DCD.

Blocks have the following definition:

Image block start address on i.MX, Offset from start of image file,

Length of block in bytes, image data file.

  From HAB Code-Signing Tool User’s Guide :

Blocks - List of one or more data blocks. Each block is specified by four

parameters:

• source file (must be binary),

• starting load address in memory

• starting offset within the source file

• length (in bytes)

Have a great day,
Yuri

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

[giuliodominutti]

I followed your instruction with one difference at point 1, and I was sure that hab was successful, bun now I'm not: I explain better:

1) instead of fuse programming we tried a different approach. we stopped the board into a loop before it starts the process of reading from sd. here we write trough JTAG the shadow memory corresponding to the fuse and then jumping out the loop we resume the starting process.

My results:
--> using a u-boot.imx not signed with hab_status I obtained:

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

Secure boot disabled
HAB Configuration: 0xf0, HAB State: 0x66

the usual error logs (fine by now)

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

--> using the procedure described before and an u-boot-signed.imx with hab_status I obtained:

------------------------------------------------------------------------------
Secure boot disabled
HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

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

At this point I was sure to have done a good job, but this result is the same if I override the shadow memory or NOT.

In conclusion now I obtain no error logs just using a correctly signed image, also if corresponding values of fuse are all zeros. There is something missing? maybe the command "fuse prog" performs something more than just writing in fuses?? And despite this you still suggest me that this approach of using JTAG to write in shadow is useless in HAB authentication?
Thanks a lot

[Romain-PC]

Hi,

I'm interested in having shadow fuses used by the HAB. On IMX8M.

What do you mean by stoping the board in a loop? And do you have resources explaining how to interact with the board via JTAG even before launching the bootloader?

Thanks !

Best regards,

Romain

[Yuri]

Hello,

 Note,

 “there is a known limitation about the verification of the SRK table in the ROM of i.MX 6 Series devices. In these devices, the intent was to only verify the SRK table hash, when the SRK fuse field was non-zero for Open configuration. However, for i.MX 6 Series in Open configuration, the HAB always skips the verification of the SRK table, regardless of whether the SRK fuse field has been provisioned or not. This means that it is necessary to ensure that the SRK field is correctly programmed, prior to moving the i.MX 6 Series security configuration to Closed. It is highly recommended to use the srktool included as part of the CST release. The byte ordering of the SRK table hash value should be correct to ensure proper operation. Failing to follow the steps in provisioning the SRK hash eFuses correctly results in a device that will not boot in Closed configuration."

Regards,

Yuri.

[Yuri]

Hello,

   I am afraid, we cannot discuss this with you in public anyway.

Regards,

Yuri.