Accessing Bootloader-Imported HSE Keys via PKCS#11

[Sureshiast]

Yocto version: BSP43
Linux Kernel version: 6.6.52
HSE version: HSE_FW_S32G3XX_0_2_64_0

Description:
I have an RSA key that is imported into an HSE key slot (NVM) via HSE service descriptor by the NXP bootloader. On the Linux side, I am trying to access this key from the key slot using the pkcs11 tool with the key handle. However, I am unable to access it — the pkcs11 tool does not list the key objects that were loaded by the bootloader.

Key handle ID: 0x000501

Query:
Is it possible to access keys imported by the bootloader using the pkcs11 tool in Linux? If so, what steps or configurations are required to make the key visible through the PKCS11 interface?

[alejandro_e]

Hello @Sureshiast,

Thanks for reaching out to us and thanks for the very detailed description of your problem. Regarding your problem, what do you mean exactly when you say "the pkcs11 tool does not list the key objects that were loaded by the bootloader."?

If you try to use the key you mention in any HSE operation, do you receive an error? or what behavior do you see exactly?

Please ensure the SYSIMG is not being overwritten when the BSP is booting, since this would cause any key imported by the bootloader to be lost.

Thanks

[Sureshiast]

The bootloader is using the key catalogs as defined in the global_defs file, and my keys-config.h is taken from pkcs11-hse repository 

My concern is why the pkcs11-tool is unable to list or access the keys that were imported by the bootloader into the specified slot. However, if I manually load the keys using the pkcs11-tool command, then I’m able to access them without issue.

Could you clarify why the keys loaded by the bootloader are not visible or accessible through pkcs11-tool, but the manually loaded ones are?

[alejandro_e]

Hello @Sureshiast,

During your boot process, do you reload the HSE FW and HSE SYSIMG? My understanding is that you have a bootloader that loads the HSE FW and HSE SYSIMG then the ATF -> U-Boot -> Linux is performed, is ATF loading the HSE FW and HSE SYSIMG again? 

If so, the SYS-IMG (in which the keys are saved) will be overwritten, is loaded into the HSE secure RAM, this means that if the HSE core is restarted, the SYS-IMG will be loaded again, from the one in the ATF. 

You would need to publish your SYS-IMG into the ATF region so that HSE can load the updated version with your latest keys.

Please let me know if the description I shared above matches your setup.

[Sureshiast]

Hello @alejandro_e,

Thank you for the information.

I understand and I have confirmed that the bootloader is importing the keys into the HSE key handles. I’d like to clarify a couple of points regarding our setup:

1. ATF and HSE Firmware Reload

Does the ATF re-upload the HSE firmware during boot?

If so, this would mean the keys imported by the bootloader are lost, which could explain why they are not accessible later via pkcs11-tool.

How can I verify whether the HSE firmware and HSE-SYS img is being reloaded at this stage?

2. Yocto Configuration

In my local.conf, I have included:

DISTRO_FEATURES:append = " hse"

Does enabling this feature cause the HSE firmware to be loaded again ?

3. Key Visibility in PKCS11

Can pkcs11-tool access keys that were imported by the bootloader, or is it designed to only list and use keys that are explicitly loaded via pkcs11-tool itself?

[alejandro_e]

Hello @Sureshiast,

To answer your questions, yes adding DISTRO_FEATURES:append = " hse" to the local.conf file adds the HSE FW load process into ATF into the ATF, you can double check in the ATF compile log, in my setup for example is located in yocto/build_s32g399ardb3/tmp/work/s32g399ardb3-fsl-linux/arm-trusted-firmware/2.10.7-r0/temp/log.do_compile:

Image Layout
        IVT:                    Offset: 0x0             Size: 0x100
        DCD:                    Offset: 0x100           Size: 0x1c
        QSPI Parameters:        Offset: 0x200           Size: 0x200
        HSE Firmware:           Offset: 0x400
        HSE SYS Image:          Offset: 0x61560         Size: 0xc000
        AppBootCode Header:     Offset: 0x6d560         Size: 0x40
        Application:            Offset: 0x6d5a0         Size: 0x36800

As you can see, the HSE FW and SYS Image are being included in the ATF binary.

I have checked the documentation and I was not able to find the exact effect of loading the HSE FW twice, therefore I do not recommend that boot flow since as it may cause unexpected behaviors, just as the key access problems you have experienced.

[Sureshiast]

Hello @alejandro_e,

Thank you for the reply.

I don’t want to load the HSE firmware and SYSIMG twice. Since my bootloader is already handling the HSE firmware and SYSIMG loading, I don’t want ATF to reload them. In my use case, I also need to include the

DISTRO_FEATURES:append = " secboot "

, which by default triggers loading of the HSE firmware and SYSIMG in the ATF.

Is there a way to prevent ATF from loading them and ensure that the loading is done only by the bootloader?

Additionally, regarding the visibility of the key imported by the bootloader in Linux, I am able to retrieve the key information through the service descriptor, but I am unable to access the keys via the PKCS11 tool. Could you please let me know why I am unable to access it from the PKCS11 tool? Please find the screenshots attached for reference.

[alejandro_e]

Hello @Sureshiast,

Thanks for the information. Regarding the use of SecBoot without  loading the HSE FW in ATF, you would need to create your own recipe.

About libhse able to see the key whole PKCS does not, I was not expecting that behavior, I was expecting the keys to be completly overwritten in Linux. 

This last topic is outside my expertise of the HSE, I will contact the internal team for better support. I will get back to you with any update.

Thanks again for the tests 

[alejandro_e · Accepted solution]

Hello @Sureshiast,

I have received feedback from the internal team, here is the summarized information:

• To use the HSE both in the bootloader (M7) and Linux/PKCS (A53) you need to configure different message units (MUs) for each ones
• The PKCS11 library does not support creating the key object for the pre-installed HSE key in bootloader automatically. The customer should use the PKCS11 function to install the key object.
• The installed keys configured in bootloader could be used in Linux in hardware level, the customer can use the libhse to implement the crypto driver to use the correct key handle to do the crypto operations. But the PCKCS11 library does not support creating key objects for pre-installed key in software level.

Let me know if you need more information on this topic

[Sureshiast]

Hello @alejandro_e,

Thank you for your support and clarification. Your guidance helped me resolve the issue, and I truly appreciate your time and effort.

[alejandro_e]

Hello @Sureshiast,

Thanks a lot for the feedback! I am glad you were able to solve your issue.

Thanks also for selecting my reply as an accepted solution.

Best regards