i.MX8M Mini/Nano: HAB unable to authenticate encrypted files from U-Boot on closed devices

[gabrielvalcazar]

Good morning. I'm currently implementing secure and encrypted boot mechanisms on i.MX8M Mini and i.MX8M Nano System On Modules.

So far, I'm able to do the following on closed devices:

• Boot a signed imx-boot image
• Boot a signed+encrypted imx-boot image
• Authenticate signed artifacts from U-Boot

This last scenario is a custom one, in which we take a file from the boot partition (such as a bootscript, a kernel or a device tree), append an "artificial" IVT to it and sign it. This allows us to authenticate these files and stop the boot process if the authentication fails. This use case is working fine so far.

However, I can't do the same with signed+encrypted files. These kinds of files have been tested to work fine on other HABv4 devices such as i.MX6 and i.MX6UL (the HAB can decrypt the file using a DEK blob stored in memory, and the signature is verified), but when I use the same CSF format and the same mechanism in U-Boot for the i.MX8M Mini/Nano, I always get a HAB event related to the CAAM.

For example, here is the CSF used to sign an encrypt a small U-Boot script for an i.MX8M Mini (you can see that only some specific sections are signed/encrypted while others are left out, but I can guarantee that this CSF can be authenticated perfectly fine on an i.MX6/i.MX6UL device and it guarantees that the main content of the file remains encrypted):

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

[Install SRK]
    File = "SRK_table.bin"
    Source index = 0

[Install CSFK]
    File = "CSF1_1_sha256_4096_65537_v3_usr_crt.pem"

[Authenticate CSF]

[Unlock]
    Engine = CAAM
    Features = RNG,MID

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

[Authenticate Data]
    Verification index = 2
    Blocks = 1078464512 4096 0x20 "bootscr-signed"

[Authenticate Data]
    Verification index = 2
    Blocks = 1078460672 0x100 0x20 "bootscr-signed"

[Authenticate Data]
    Verification index = 2
    Blocks = 0x40480000 0x0 0x40 "bootscr-signed"

[Install Secret Key]
    Verification index = 0
    Target index = 0
    Key = "dek.bin"
    Key Length = 128
    Blob address = 1078460160

[Decrypt Data]
    Verification index = 0
    Mac Bytes = 16
    Blocks = 1078460480 0x40 192 "bootscr-signed", \
             1078460704 288 3808 "bootscr-signed"

Then, in U-Boot, with everything in place (script and DEK blob in the correct memory address), the authentication fails. Here's is the output with extra debug info:

   Authenticate image from DDR location 0x40480000... 
ivt_offset = 0x1000, ivt addr = 0x40481000
ivt entry = 0x40480100, dcd = 0x00000000, csf = 0x40481020
Dumping IVT
40481000: 402000d1 40480100 00000000 00000000    .. @..H@........
40481010: 00000000 40481000 40481020 00000000    ......H@ .H@....
Dumping CSF Header
40481020: 43a000d4 000c00be 00001703 a0000000    ...C............
40481030: 020c00be 01000009 e0080000 000c00ca    ................
40481040: 001dc501 340e0000 1d0800b2 03000000    .......4........
40481050: 000c00be 02000009 38110000 001400ca    ...........8....

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!


Calling authenticate_image in ROM
        ivt_offset = 0x1000
        start = 0x40480000
        bytes = 0x3020
FAILED!

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99

--------- HAB Event 1 -----------------
event data:
        0xdb 0x00 0x24 0x43 0x33 0x30 0xc0 0x1d
        0x10 0x02 0x11 0x22 0x40 0x00 0x08 0x16
        0x55 0x55 0x00 0x0f 0x00 0x10 0x20 0x00
        0x00 0x00 0x00 0x01 0x91 0x00 0x88 0x0e
        0x00 0x00 0x02 0x05

STS = HAB_FAILURE (0x33)
RSN = HAB_ENG_FAIL (0x30)
CTX = HAB_CTX_COMMAND (0xC0)
ENG = HAB_ENG_CAAM (0x1D)

It seems to me like the authentication process is failing when the CAAM is decrypting the blob. Maybe it's because the decryption is happening in a "non-secure world" context, but I doubt so because the authentication of signed-only files is working fine.

Is there any way for HAB to decrypt a DEK blob from U-Boot in order to authenticate encrypted files? Am I missing something in the CSF or in the signing/encryption process? I understand that this feature is not standard and that it includes some peculiar customizations, such as appending artificial IVTs to files... But since we already have this working for other HAB and AHAB i.MX System On Modules, it would be nice to include this feature for the i.MX8M MIni/Nano as well.

Best regards,

Gabriel

[gabrielvalcazar]

Hi once again. I've done some more tests to see exactly what causes the issue to stop happening.

By default, I'm unable to authenticate encrypted files from U-Boot due to a CAAM error in the HAB. However, with these following changes in the imx-atf and imx-optee-os repos, I can get the authentication working (albeit with the CAAM being unusable in regular context, such as DEK blob creation).

imx-atf:

diff --git a/plat/imx/imx8m/imx8m_caam.c b/plat/imx/imx8m/imx8m_caam.c
index 478005e2e..aaeb00103 100644
--- a/plat/imx/imx8m/imx8m_caam.c
+++ b/plat/imx/imx8m/imx8m_caam.c
@@ -20,7 +20,7 @@ void imx8m_caam_init(void)
        mmio_write_32(SM_CMD, sm_cmd);
 
        /* config CAAM JRaMID set MID to Cortex A */
-       mmio_write_32(CAAM_JR0MID, CAAM_NS_MID);
+       //mmio_write_32(CAAM_JR0MID, CAAM_NS_MID);
        mmio_write_32(CAAM_JR1MID, CAAM_NS_MID);
        mmio_write_32(CAAM_JR2MID, CAAM_NS_MID);

 imx-optee-os:

diff --git a/core/drivers/crypto/caam/hal/common/hal_cfg.c b/core/drivers/crypto/caam/hal/common/hal_cfg.c
index 9ed36c52..8122bedf 100644
--- a/core/drivers/crypto/caam/hal/common/hal_cfg.c
+++ b/core/drivers/crypto/caam/hal/common/hal_cfg.c
@@ -97,9 +97,10 @@ void caam_hal_cfg_common_setup_nsjobring(struct caam_jrcfg *jrcfg)
                if (jr_offset == jrcfg->offset)
                        continue;
 #endif
-               status = caam_hal_jr_setowner(jrcfg->base, jr_offset,
-                                             JROWN_ARM_NS);
+               /* Skip the configuration of JR0 */
+               if (jrnum != 1)
+                       status = caam_hal_jr_setowner(jrcfg->base, jr_offset,
+                                                     JROWN_ARM_NS);
                if (status == CAAM_NO_ERROR)
                        caam_hal_jr_prepare_backup(jrcfg->base, jr_offset);
        }

Note that both changes are needed for the authentication to work, if only one of the patches is applied it will either hang or generate a HAB event.

Here's a rundown of the workflow I can observe when these patches aren't applied:

1. The closed device successfully authenticates and boots an encrypted SPL U-Boot image. The CAAM's JR0MID register (offset 0x10) is configured either by the ROM code or by default with a value of 0x8011 (or at least that's the value I'm reading from the register while the SPL is running). From what I understand, this value means that JR0 is owned by the secure ARM and also that it's owned by Trustzone (bit JRxDID_MS_TZ_OWN in imx-optee-os).
2. The SPL authenticates the encrypted FIT image successfully and jumps to the ATF. The ATF then writes the JR0MID register with a value of 0x1 (which means that JR0 is now owned by the non-secure Cortex A).
3. The ATF jumps to the OP-TEE, which configures the JR0MID register once again with a new value of 0x80001 (JRxDID_MS_PRIM_CID and JRxDID_MS_PRIM_ICID bits representing the non-secure owner)
4. U-Boot is launched, and any attempt at using the HAB to authenticate an encrypted file will result in a CAAM error. The rest of the CAAM functionality works fine.

When the patches are applied:

1. Same as before
2. The ATF no longer writes to the JR0MID register, causing its value to remain as 0x8011
3. The OP-TEE no longer writes to the JR0MID register, so it still contains 0x8011
4. With U-Boot launch, any regular usage of the CAAM doesn't work anymore, but if you use the HAB to authenticate an encrypted file, it will work.

To try to solve this, I tried momentarily changing the value of the JR0MID register before using the HAB to authenticate an encrypted file. If I try to modify the register directly from U-Boot, the new value doesn't persist (I write 0x8011 but the register contains 0x1). I implemented a custom PTA in OP-TEE to write the register from a more "trusted" context. The value of 0x8011 is written correctly, but the HAB authentication still doesn't work. I also tried de-allocating the 0 partition, writing the JR0MID register, re-allocating the partition and allocating pages 0 and 1 to said partition, but the result is still the same (even when done from OP-TEE via the PTA).

I get the feeling that once the JR0MID register is configured for non-secure world from the ATF, there's no going back to the secure configuration... is this true? Or is there a way to momentarily change the CAAM configuration so it can be used by the HAB once U-Boot has loaded?

I feel like I've run out of ideas and that the system is designed so that the HAB cannot decrypt any data once in non-secure world. In this case, we will have to drop the feature for the modules based on the i.MX8M family.

Best regards,

Gabriel

[gabrielvalcazar · Accepted solution]

Hi again, I believe I found the root of the problem.

If I alter the ATF an OP-TEE code to skip any CAAM initialization, I can finally use HAB to authenticate encrypted files from U-Boot. Of course, other CAAM functionality stops working, such as the DEK blob encapsulation via the "dek_blob" command, but at least I'm confident now that the issue is caused by the CAAM reconfiguration in the ATF and the OP-TEE.

My new question is: would it be possible to find a common configuration that allows both use cases (HAB authentication of encrypted files from U-Boot and DEK blob encapsulation via OP-TEE)? If not, would it be feasible to temporarily change back to the original CAAM configuration before doing a HAB authentication, and then change back to the OP-TEE configuration?

Thanks in advance and best regards,

Gabriel

[Yuri]

@gabrielvalcazar 
Hello,

  I've sent You some considerations.

Regards,
Yuri.

[lcllcl001]

Hello,gabrielvalcazar  

Thank you for your method.@gabrielvalcazar

@Yuri  

Hello,Yuri  

I am also encounter the same problem.

Could you send me the considerations that you send to gabrielvalcazar  ?

Thanks and Best Regards,

Chunli

[Yuri]

@lcllcl001 
Hello,

  the mentioned materials are under NDA.
Please create request for further considerations.

https://www.nxp.com/support/support:SUPPORTHOME?tid=sbmenu

Regards,
Yuri.

[lcllcl001]

Hello

Thank you for your reply.

I knew it.

Thanks and Best Regards,

Chunli