Authentication of another bootloader while S32K312 MCU SecureBoot is enabled

[jeongwoo]

Hello, I would like to inquire if there is a way to re-authenticate when changing the FBL after activating Secureboot.

When changing to a different FBL while Secureboot is enabled, the META Data values ​​generated via the HMAC Key change. As the FBL is changed, the HSE needs to recalculate the META Data using the HMAC Key; however, because the HMAC Key is deleted due to the new FBL, recalculating the META Data becomes impossible. Consequently, a reset occurs due to a verification failure at the FBL, making it impossible to launch the application. Is there a way to re-authenticate the changed FBL using the HMAC Key, thereby allowing both the FBL and the application to run normally?

 

[lukaszadrapa]

Hi @jeongwoo 

That is essentially the purpose of Secure Boot: to prevent execution of software that fails authentication.

The key question is whether you still have access to the debug interface, or whether the issue must be recovered in the field without debugger access.

In the field, if there is no alternate/recovery image that was designed with such functionality in advance (for example, importing an HMAC key, generating a new authentication tag, accepting a new externally generated authentication tag, or reinstalling/reconfiguring the SMR), then recovery is generally not possible.

If you have access to the debug interface, the simplest solution is typically to calculate a new authentication tag externally and program the updated tag into flash using a debugger. This approach requires that the HSE_SMR_CFG_FLAG_INSTALL_AUTH flag was set when the SMR was installed.

If HSE_SMR_CFG_FLAG_INSTALL_AUTH was not set, HSE uses the internally stored hash for verification. In that case, updating the authentication tag alone is not sufficient and the SMR must be reinstalled with the new image parameters.

Regards,

Lukas

[jeongwoo]

Hello Lukas,

In the previous state, our controller does not have HSE_SMR_CFG_FLAG_INSTALL_AUTH set. I'm trying to apply the method you mentioned — reinstalling the SMR with new image parameters. Is the relevant part of Fota_S32k3_SecureBootProcess shown below correct?

pSmrEntryInstall->accessMode = HSE_ACCESS_MODE_ONE_PASS;
pSmrEntryInstall->entryIndex = 0u;
pSmrEntryInstall->pSmrEntry = (HOST_ADDR)&smrEntry;

pSmrEntryInstall->pSmrData = (HOST_ADDR)IVT.pAppImg_addr_0; /* pointing to active partition */
pSmrEntryInstall->smrDataLength = smrEntry.smrSize;
pSmrEntryInstall->pAuthTag[0] = (HOST_ADDR)smrEntry.pInstAuthTag[0]; /* pointing to passive partition */
pSmrEntryInstall->pAuthTag[1] = (HOST_ADDR)smrEntry.pInstAuthTag[1]; /* pointing to passive partition */
pSmrEntryInstall->authTagLength[0] = HmacTagLength;
pSmrEntryInstall->authTagLength[1] = HmacTagLength;
If this is correct, when I run the HSE_SRV_ID_SMR_ENTRY_INSTALL service, the HseResponse is returned as 0xA5AA5317, which corresponds to:

#define HSE_SRV_RSP_KEY_EMPTY ((hseSrvResponse_t)0xA5AA5317UL)
indicating that the key is empty. (As I asked previously, I suspect this is displayed because that part has been erased.)

I would greatly appreciate it if you could guide me on how to inject the key or otherwise resolve this issue.

Thank you very much.

[lukaszadrapa]

Hi @jeongwoo 

I can see no problem in those parameters. But you shared only hseSmrEntryInstallSrv_t but not hseSmrEntry_t (pSmrEntryInstall->pSmrEntry = (HOST_ADDR)&smrEntry;).

Structure hseSmrEntry_t contains other important parameters needed for installation.

To confirm if the key is erased or not, you can use service HSE_SRV_ID_GET_KEY_INFO, structure struct hseGetKeyInfoSrv_t. Using this service, you will get information in hseKeyInfo_t, so you can check the state of key.

Regards,

Lukas