S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Area?

[Yiming2]

Hello NXP Support Team,

We are implementing HSE-based Secure Boot with SMR on the S32K312 and would like to confirm whether an SMR signature can be permanently stored in the UTEST DCF record area.

Our current implementation is as follows:

1. We store a 512-byte RSA-4096 signature in UTEST, starting at address:

0x1B001A00U

The occupied address range is:

0x1B001A00 to 0x1B001BFF

This region belongs to the UTEST DCF record area.

1. Our project does not require any DCF configuration in this area. Therefore, we are currently considering using the unused DCF record space to store permanent security data, including the public key and the SMR signature.

2. Since the software image and its signature are fixed in our use case, the signature is not expected to change during the product lifetime.

3. In the SMR Entry, we configure the signature reference as follows:

smrEntry.pInstAuthTag[0] = 0x1B001A00U;

smrEntry.pInstAuthTag[1] = 0U;

Our expectation is that, during subsequent Secure Boot verification, HSE will read the 512-byte signature directly from the UTEST address specified by pInstAuthTag[0].

1. When installing the SMR Entry through HSE_SRV_ID_SMR_ENTRY_INSTALL, we initially configured the installation service authentication tag to reference the same UTEST address:

pSmrEntryInstall->pAuthTag[0] = 0x1B000A00U;

However, the SMR installation service returned HSE_SRV_RSP_INVALID_PARAM, apparently because the UTEST address was rejected as an invalid input address for the service.

1. As a workaround, before calling the SMR installation service, we copy the 512-byte signature from UTEST into a shared RAM buffer:

UTEST 0x1B000A00

|

| Copy 512 bytes

v

Shared RAM buffer

We then configure the installation request as follows:

pSmrEntryInstall->pAuthTag[0] =

PTR_TO_HOST_ADDR(signatureRamBuffer);

pSmrEntryInstall->authTagLength[0] = 512U;

The SMR Entry itself still contains:

smrEntry.pInstAuthTag[0] = 0x1B000A00U;

With this configuration, HSE_SRV_ID_SMR_ENTRY_INSTALL returns success and the SMR Entry is installed successfully.

Could you please clarify the following questions?

1. Is 0x1B001A00U a valid address for hseSmrEntry_t.pInstAuthTag[0] on the S32K312?

2. During a subsequent Secure Boot, can HSE_B directly access the UTEST DCF record area and read the signature referenced by pInstAuthTag[0]?

3. Does a successful HSE_SRV_ID_SMR_ENTRY_INSTALL response confirm that the persistent pInstAuthTag[0] address is valid for later boot-time SMR verification, or does the installation service only verify the signature supplied through hseSmrEntryInstallSrv_t.pAuthTag[0]?

4. Is there a difference between the memory regions accepted for:

hseSmrEntryInstallSrv_t.pAuthTag[0]

and:

hseSmrEntry_t.pInstAuthTag[0]

In our test, the UTEST address is rejected when used directly as pAuthTag[0], but the SMR installation succeeds when the same signature is copied to RAM while pInstAuthTag[0] still points to UTEST.

1. Could this configuration pass SMR installation but fail during the next reset or Secure Boot because HSE cannot access the UTEST address at boot time?

2. Is the unused UTEST DCF record area allowed to store customer application data such as a public key or an SMR signature when no DCF records are required by the project?

3. Could using this DCF record area cause any conflict with HSE firmware, ROM boot code, future DCF processing, lifecycle transitions, debug configuration, or device configuration scanning?

4. Are there any alignment, record-format, ECC, programming, locking, or access restrictions for storing a raw 512-byte signature in this UTEST area?

5. If UTEST is not supported for pInstAuthTag[0], should the persistent SMR signature always be stored in normal application Code Flash or Data Flash?

The main point we would like to confirm is whether the following configuration is officially supported and safe for production:

/* Persistent signature location used during Secure Boot /

smrEntry.pInstAuthTag[0] = 0x1B000A00U;

/ Temporary RAM copy used only during SMR installation */

pSmrEntryInstall->pAuthTag[0] =

PTR_TO_HOST_ADDR(signatureRamBuffer);

pSmrEntryInstall->authTagLength[0] = 512U;

MCU: S32K312
HSE type: HSE_B
Signature algorithm: RSASSA-PSS with RSA-4096
Signature length: 512 bytes
Persistent signature address: 0x1B001A00U

Thank you.

[lukaszadrapa]

Hi @Yiming2 

I tested it on my board because it is not explicitly mentioned in the documentation if UTEST can be used or not. And I got similar results.

If pAuthTag = pInstAuthTag = 0x1B001A00, I got HSE_ SRV_ RSP_ INVALID_ ADDR response.

Then I placed pAuthTag into RAM memory while pInstAuthTag was pointing still to UTEST and this works. Once secure boot is enabled by BOOT_SEQ bit, secure boot is successful, application is working. HSE is able to read the signature in UTEST DCF area.

Based on the test results, HSE firmware obviously checks if address pAuthTag falls within RAM or code/data flash memory while pInstAuthTag in UTEST is accepted.

It’s not documented but it works.

But if you do not plan to update the signature, an option is to keep HSE_SMR_CFG_FLAG_INSTALL_AUTH zero, so internal verification scheme (internal hash) would be used for verification. Your signature would be used only for installation and pInstAuthTag would be ignored.

In my opinion, this setup makes more sense if you do not plan to update the image. Also the verification would be much faster (hash vs. RSA algorithm). This is probably the best way to keep it simple and to get better performance.

If HSE_SMR_CFG_FLAG_INSTALL_AUTH is set and pInstAuthTag is used, this targets mainly a use-case when you want to easily update an application: application and authentication tag is updated and you do not need to modify or reinstall that SMR.

DCF is scanned up to stop record (all 0xFF’s), the rest is ignored. Normally the DCF area is not supposed to be used for user data but I can’t see a problem here.

The only restriction for UTEST is that it is OTP area. And the same ECC limitations apply (like for code or data flash) – once an aligned double word is programmed, you should not program the same double word again because it would cause ECC error.

Regards,

Lukas

[Yiming2]

sorry the Signature location is not 0x1B000A00U. it is 0x1B001A00U.