HABv4 encrypted boot is not working in certain devices on L4.14.78_1.0.0_GA release

[#1]

Background:

The HABv4 Encrypted Boot feature available in CAAM supported devices adds an extra security operation to the bootloader sequence. It uses cryptographic techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used by unauthorized users.

The Code Signing Tool (CST) automatically generates a random AES Data Encryption Key (DEK) when encrypting an image. This key is used for both encrypt and decrypt operations and should be present in the final image structure encapsulated by a CAAM blob, also know as DEK Blob.

U-Boot supports the dek_blob command tool which is used to encapsulate DEKs generated by CST. The tool is based in a CAAM descriptor, users should provide the plain text key as input and receive a DEK blob which is unique per device.

Additional information about encrypted boot can be found in the documents listed in the reference section of this document.

Issue Description:

For preparing a HABv4 encrypted boot image it's necessary to encapsulate the generated DEK in a blob. In all CAAM IPs versions after ERA 8 (please contact your local NXP representative for information) the blob generation function takes into consideration the Job Ring TrustZone ownership configuration field (JROWN_NS) which is available in Job Ring MID register (JRaMIDR_MS). The generated DEK blob can be only decapsulated by an environment running in the same JR configuration.

The ROM code expects DEK blobs encapsulated by the Secure World environments which commonly have JROWN_NS = 0. As U-Boot in imx_v2018.03_4.14.78_1.0.0_ga release is running in Secure World we must set JROWN_NS=0 so the blobs generated by dek_blob tool can be decapsulated by the ROM code.

Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to non-TrustZone") is incorrectly handling the JROWN_NS field and breaks HABv4 encrypted boot support in the certain i.MX devices. DEK blobs encapsulated by this environment cannot be decapsulated at ROM level and i.MX target fails to boot.

Impacted devices and BSP releases:

The following devices support CAAM ERA 8 or newer thus are impacted by this issue introduced in the imx_v2018.03_4.14.78_1.0.0_ga release branch.

- i.MX 6UL
- i.MX 7S
- i.MX 7D
- i.MX 7ULP

All U-Boot releases after imx_v2018.03_4.14.98_2.0.0_ga have the proper fix in place, thus are not impacted.

Please note:
- This issue does not impact i.MX 6DQ, i.MX 6SDL, i.MX 6DQP and i.MX 6SX devices as TrustZone configuration is not considered in these devices (please contact your local NXP representative for information).
- This issue does not impact older U-Boot GA releases, only imx_v2018.03_4.14.78_1.0.0_ga release branch is impacted.

Workaround:

Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to non-TrustZone") can be safely reverted as NXP BSP does not require all job-rings assigned to non-Secure world, users can use the command below based in imx_v2018.03_4.14.78_1.0.0_ga release branch:

$ git revert 22191ac35344‍‍‍

Users can also refer to commit below on imx_v2018.03_4.14.98_2.0.0_ga release branch:

MLK-21386 Revert "drivers/crypto/fsl: assign job-rings to non-TrustZone"

References:

- U-Boot documentation, encrypted boot guide for i.MX6 and i.MX7 family devices.

- AN12056: Encrypted Boot on HABv4 and CAAM Enabled Devices.

This issue does not compromise the i.MX security.