Authentication of another bootloader while S32K312 MCU SecureBoot is enabled

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Authentication of another bootloader while S32K312 MCU SecureBoot is enabled

208 Views
jeongwoo
Contributor I

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?

FBL_FAIL_scenario.png

Tags (1)
0 Kudos
Reply
4 Replies

184 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

162 Views
jeongwoo
Contributor I

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.

0 Kudos
Reply

115 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

55 Views
jeongwoo
Contributor I

Hello Lukas,

Thank you for your reply. I checked the smrEntry values you mentioned. When I set a breakpoint at the point where SecurebootState is 0, I confirmed that smrEntry was entirely 0. And when I set a breakpoint at the return part where Fota_S32k3_SecureBootProcess ends, I confirmed that the values appear. At the time of return, the SecureBootState value is 1.
Has this information been helpful in solving the problem?


1) When a breakpoint is set at if(SecureBootState == 0) / Result: smrEntry = 0

jeongwoo_2-1785202546706.png

jeongwoo_4-1785202712594.png

2) A breakpoint at return secureBootProcessResult, the last part of the Fota_S32k3_SecureBootProcess function

jeongwoo_5-1785202790581.png

jeongwoo_6-1785202803402.png



Regards, jeongwoo

0 Kudos
Reply