S32K312 Change FBL after Secureboot authentication

[jeongwoo]

Hello NXP,

I previously contacted you regarding the same issue, but I need additional assistance, so I am reaching out again. We are using the S32K312 MCU, with HSE version 2.6.0.

Issue: With Secure Boot enabled, following an FBL (Flash Bootloader) change, the ECU does not boot normally (APP execution is not possible).

When checking with hseImportKeySrv_t (HSE_SRV_ID_IMPORT_KEY), the result returned was KEY_EMPTY. Additionally, within Fota_S32k3_SecureBootProcess, the hseRequestResult value is also returned as KEY_EMPTY, causing retVal to be 1 (NOT_OK). Because this authentication fails, SMR Verify is failing.

We attempted to perform the key injection needed for SMR verification via SU (Super User) rights authentication using CMAC, RSA, or ECDSA, but we understand that obtaining such rights requires an authentication key, which we have not been able to locate. We also attempted to erase the IVT sector, but this is not possible either, since the Life-Cycle is set to IN_FIELD.

Questions:

1. Is there a way to grant SU rights? (i.e., is it possible to look up/retrieve the authentication key?)

2. Given that flashing the previous bootloader results in normal execution, does this suggest that the old META value is still remaining in the HSE?

3. When we executed Crypto_Hse_GetKeyInfo(FOTA_HSE_MU0_INSTANCE, Crypto_aKeyElementList[ElementIndex].u32HseKeyHandle), the value of Crypto_aKeyElementList[ElementIndex].u32HseKeyHandle returned as 66305. Could this indicate a mismatch in the HSE memory/slot/handle, which is causing the SMR verification to fail? (i.e., is an HSE memory/slot/handle mismatch the root cause?)

4. If we are unable to obtain the SU authentication key, and Format Key Catalog is also not supported in this state, could you please advise whether there is an official NXP recovery procedure (e.g., special access via Secure Debug Authentication, RMA, or a separate vendor provisioning procedure) that can be used to properly recover this device, which is currently in the IN_FIELD life-cycle state with a partially lost key catalog?

Thank you in advance for your support.

[davidtosenovjan]

Lukas is currently on vacation, so I will try to answer your questions in the meantime.

Q1: SU rights can be obtained in IN_FIELD via Challenge-Response (HSE_SRV_ID_SYS_AUTH_REQ / HSE_SRV_ID_SYS_AUTH_RESP), but only if the CUST/OEM authorization key was provisioned before advancing to IN_FIELD. If it was not provisioned, or the private key is not held externally, SU rights cannot be obtained and the key cannot be retrieved.

Q2: Based on the fact that the old FBL works normally, it is likely that the HMAC key and original authentication tag are still intact in HSE SYS-IMG. If that is the case, the new FBL would be failing because the authentication tag was computed over the old binary and no longer matches the new one. Re-running HSE_SRV_ID_SMR_ENTRY_INSTALL with the new FBL content would fix it — but requires SU rights. Could you confirm whether this matches your setup?

Q3: Handle 66305 (0x10301) decodes to NVM catalog, group 3, slot 1 — which appears to be empty. This suggests the HMAC key may be provisioned at a different slot, and the new FBL's FOTA code is referencing a wrong hardcoded handle. As a first step, please compare the authKeyHandle from the original HSE_SRV_ID_SMR_ENTRY_INSTALL call against what your new FBL's FOTA code references — they most likely differ. However, without seeing your full configuration we cannot say this with certainty.

Q4: Two options: (1) If CUST/OEM authorization key was provisioned — use Challenge-Response for SU rights. (2) If ADKP was provisioned — Secure Debug Authentication unlocks JTAG for diagnostics only, not HSE NVM writes.