topic Re: iMX6 Solo Encrypted Boot in i.MX Processors

iMX6 Solo Encrypted Boot

danielberhe — Mon, 08 Mar 2021 10:58:31 GMT

Hi All,

I'm trying to implement encrypted boot on my custom iMX6 Solo board. Booting a signed uboot is working fine - the issue I'm having is booting an encrypted and signed image. Since my iMX6 is in closed configuration, I can't check for the status as it is just refusing to boot. The reason why I've already closed it is because I originally intended to use just signed uboot but would now like to extend it to have the encryption.

The build log of my uboot (u-boot.imx.log) shows the following values:

Image Type: Freescale IMX Boot Image
Image Ver: 2 (i.MX53/6/7 compatible)
Mode: DCD
Data Size: 450560 Bytes = 440.00 KiB = 0.43 MiB
Load Address: 177ff908
Entry Point: 17800000
HAB Blocks: 0x177ff8e8 0x00000000 0x00069c00
DCD Blocks: 0x00910000 0x0000002c 0x00000300

And I have written the signature CSF file based on the values above. The CSF I use just for signature (and it works fine) is as follows:

[Header]
    Version = 4.1
    Hash Algorithm = sha256
    Engine Configuration = 0
    Certificate Format = X509
    Signature Format = CMS
    Engine = CAAM

[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
    File = "crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem"

[Authenticate Data]
Verification index = 2
Blocks = 0x177ff8e8 0x0 0x69c00 "output/u-boot.imx"

For the encryption CSF, I modified the signature CSF to include encryption (following example from here

[Header]
    Version = 4.1
    Hash Algorithm = sha256
    Engine Configuration = 0
    Certificate Format = X509
    Signature Format = CMS
    Engine = CAAM

[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]

[Unlock]
Engine = CAAM
Features = RNG

[Install Key]
    Verification index = 0
    Target index = 2
    File = "crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem"

[Authenticate Data]
    Verification index = 2
    # I got the 0x718 by subtracting 0x177ff8e8 from 0x17800000
    # I also checked u-boot.imx and verified that u-boot.bin is starting at
    # offset 0x718
    Blocks = 0x177ff8e8 0x0 0x718 "output/u-boot.imx"

[Install Secret Key]
    Verification index = 0
    Target index = 0
    Key = "output/dek.bin"
    Key Length = 128
    # Blob address = 0x177ff8e8 + 0x00069c00 (size of u-boot.imx)
    # + 0x1f00 (csf binary + padding)
    Blob Address = 0x1786B3e8

[Decrypt Data]
    Verification index = 0
    Mac Bytes = 16
    # I think the 0x6900 below should be u-boot.imx size (0x69c00) minus
    # 0x718 but I was ending up with length that isn't a
    # multiple of 16 (cst was complaining)
    Blocks = 0x17800000 0x718 0x69000 "output/u-boot.imx"

Can anyone spot where I might be going wrong?

I have had a look at (and tried) the methods outlined in AN12056, where the image is encrypted first and then signed; signed and then encrypted. Either method didn't produce a different result to when I used the CSF posted above.

I also tried the method outlined in High Assurance Boot (HAB) for Dummies without success.

I came across a forum where one of the comments said that the cache should be turned off (icache off, dcache off) before I run the dek_blob command on the board, but this didn't fix the problem I'm having.

One thing that's nagging me is the 0x69000 address I used in the Blocks section of Decrypt Data. I would like to modify uboot so that u-boot.bin starts at a sensible offset other than 0x718 but I haven't figured out how. Does anyone know how I can do this?

I am using mainline U-Boot version 2019.10 and booting off SPI flash.

Any help would be great!

Daniel

Re: iMX6 Solo Encrypted Boot

Yuri — Tue, 09 Mar 2021 06:42:58 GMT

@danielberhe
Hello,

please check Your image preparation sequence regarding U-boot recommendations:

https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/guides/mx6_mx7_encrypted_boot.txt?h=imx_v2019.04_5.4.3_2.0.0

Regards,
Yuri.

Re: iMX6 Solo Encrypted Boot

danielberhe — Tue, 09 Mar 2021 20:09:13 GMT

Hi Yuri,

Thank you for your response.

The cause for the strange address of 0x718 turned out to be because I used 'BOOT_OFFSET FLASH_OFFSET_STANDARD' in my .cfg file. I've now changed to the deprecated 'BOOT_FROM spi', and the the size of the header is 0xc00. Below is the contents of u-boot.imx.log

Image Type: Freescale IMX Boot Image
Image Ver: 2 (i.MX53/6/7 compatible)
Mode: DCD
Data Size: 421888 Bytes = 412.00 KiB = 0.40 MiB
Load Address: 177ff420
Entry Point: 17800000
HAB Blocks: 0x177ff400 0x00000000 0x00062c00
DCD Blocks: 0x00910000 0x0000002c 0x00000310

Sadly, encrypted boot still isn't working. I had seen the link you sent to the txt file. The method outlined there is the same as what's described in AN12056 in section 4.3.1.4. I gave it another go just now and the board still isn't booting. I am getting confused by the conflicting information regarding the location of the DEK blob. In the link you sent and in AN12056, it is recommended that the CSF bin is padded to 0x2000 before the dek_blob.bin is appended. This link and this say that the dek_blob.bin should be within the 0x2000 boundary, otherwise the ROM code won't load the DEK blob. Which is it?

Another thing that's confusing me is that in the link you sent and AN12056, two CSF are used - one for encrypting the image and another for signing the encrypted image. This link and this seem to use and single CSF to produce a bootable encrypted image. Which way is correct?

Daniel

Re: iMX6 Solo Encrypted Boot

Yuri — Thu, 11 Mar 2021 10:54:48 GMT

@danielberhe
Hello,

1) As for size 0x2000:

https://community.nxp.com/t5/i-MX-Processors/AN12056-Encrypted-boot-application-note-questions/m-p/1151590

2) Use example from U-boot documentation.

Regards,
Yuri.

Re: iMX6 Solo Encrypted Boot

danielberhe — Mon, 15 Mar 2021 08:50:24 GMT

Encrypted boot is now working on my board. The issue turned out to be a missing CONFIG_RNG_INIT. I'd patched my uboot with a fix from here so need to include CONFIG_RNG_INIT in my board header file. I also needed to use the BOOT_FROM macro I mentioned above.