[i.MX8M/8MM] CAAM Manufacturing Protection not supported on certain part numbers

Yes

Background:

The CAAM manufacturing protection feature provides a mechanism to authenticate the chip to the OEM's server. The manufacturing protection feature can be used to ensure that the chip:

Is a genuine NXP SoC
Is the correct device type and part number
Has been properly configured by means of fuses
Is running authenticated OEM software
Is currently in the secure or trusted mode

The CAAM manufacturing protection feature is based on an ECC private key generated by the High Assurance Boot (HAB) code on every boot cycle. The Manufacturing Protection (MP) private key generation takes as input several fixed secrets and the MANUFACTURE_PROTECTION_KEY[255:0] being one of them in SoC fuses.

Issue Description:

On certain i.MX 8M and i.MX 8M Mini devices the MANUFACTURE_PROTECTION_KEY[255:0] fuses were incorrectly programmed at the NXP factory. During the MP private key generation, the CAAM block validates the inputs provided and fails as the MANUFACTURE_PROTECTION_KEY[255:0] provided is not a valid one.

As the MPPubK-generation and MPSign CAAM functions depends on the result of MPPrivK-generation function the CAAM manufacturing protection feature cannot be used on the impacted devices.

Details regarding manufacturing protection functions can be found in the section "Manufacturing-protection chip-authentication process" in i.MX 8M/i.MX 8MM security reference manuals (SRM). A preliminary application note is also available on request.

Please note that in closed mode the CAAM MPPrivK-generation function can be only executed once in the same power-on session. Running a second time returns a CAAM error (0x40000481) undefined protocol command which is not related to the issue described in this document.

Checking if your device is impacted:

Customers can check if their device is impacted by following the 2 steps below:

1. Checking HAB events:

The HAB code logs a warning event in the HAB persistent memory region after detecting a failure in the MP private key generation. This warning is logged independently regardless of whether HAB is enabled (SEC_CONFIG =1) or not.

Customers can parse the HAB persistent memory region in order to get the warning events, more details in the HAB Persistent memory in various MPU and MCU chipsets document.

Impacted devices should report the event below:

Event    | 0xdb | 0x0024 | 0x43 | SRCE Field: 69 30 e1 1d
            |   |        |       |             STS = HAB_WARNING (0x69)
            |   |       |       |             RSN = HAB_ENG_FAIL (0x30)
            |   |       |       |            CTX = HAB_CTX_ENTRY (0xE1)
            |   |       |       |            ENG = HAB_ENG_CAAM (0x1d)
            |   |       |       | Evt Data (hex):
            |   |       |       |   00 08 00 02 40 00 04 cc 55 55 00 0f 00 00 00 00
            |   |       |       |   00 00 00 00 00 00 00 00 00 00 02 05

2. Checking the CAAM SCFGR register

After running the MPPrivK-generation function the CAAM block stores in the CAAM SCFGR register the elliptic curve that was selected when the MPPrivK generation protocol was executed.

Users can check the MPCURVE field [31:28] in the CAAM SCFGR register and on impacted devices this field will be 0. For more details, contact your local FAE.

NOTE: In case your i.MX8MQ B0 device has an MPCURVE and still reporting HAB CAAM Warnings please refer to the document below:
RNG self test errors on select i.MX device revisions

List of impacted devices: (Under development)

i.MX 8MM:

PIMX8MM6DVTLZAA 0N87W W8 D

i.MX 8MQ:

- All i.MX 8MQ B0 devices with ON14W mask code are impacted. (e.g. PIMX8MQ6DVAJZAA ON14W SBAC1748C)
- Some i.MX 8MQ B0 devices with 1N14W mask code are impacted, please check MPCURVE field [31:28] in the CAAM SCFGR register.
- i.MX 8MQ B1 devices are not impacted.

Workaround:

No Software Workaround can be implemented.

Customers planning to use the Manufacturing Protection feature should request for SoC's that have the correct fuse programming.

Please Note: This issue does not impact the Secure Boot flow and does not compromise the i.MX security.