KMU PSA persistent key generation

RE: KMU PSA persistent key generation

Hieu — Wed, 30 Jul 2025 21:24:30 GMT

Hello Jan_Herr,

As a support engineer, I can only say that I fully understand your frustration. As mentioned, we have registered the issue internally and will get to it to improve the customer experience.

If you have a Nordic sales contact, please drop a word with them as well. I am sure they would want to understand customers' needs and frustrations.

Our apologies for the inconvenience.

Best regards,

Hieu

RE: KMU PSA persistent key generation

Jan_Herr — Tue, 29 Jul 2025 08:36:36 GMT

Hi, we are also wondering about the same architectural decision, albeit on the nrf5340.
Going into this, we actively chose an SoC with dedicated key storage for storing secrets there. I get that ITS needs to provide a mechanism for system w/o KMU but end of the day, we as customers are paying extra for the CC3xx module, aren't we ?
Finding out that this is not supported, even though the ecosystem is more or less entirely provided by ARM is rather annoying.

RE: KMU PSA persistent key generation

Hieu — Wed, 02 Jul 2025 11:42:03 GMT

Hi Andreas,

My apologies. I previously misunderstood that all your questions are resolved. While referring to this case today, I realized you have a question unanswered.

[quote user="Andreas u-blox"]Am I missing some config to keep the footprint down here because I can't see how it would be worth wasting this much RAM/NVM just to be able to store some keys. Isn't the purpose of the KMU exactly to keep the keys securly stored but with the main difference that it's a HW block which cost no RAM/NVM?[/quote]

Unfortunately, this is the case for now. The Crypto partition of TF-M depends on the ITS Partition (ref), so to enable crypto APIs, ITS must also be enabled. This is a part of TF-M architecture, which is designed to work with even devices without KMU.

We have registered this issue in our backlog and will try to improve this.

Our apologies for the inconvenience.

Best regards,

Hieu

RE: KMU PSA persistent key generation

Andreas u-blox — Wed, 12 Feb 2025 10:04:24 GMT

Hi Hieu!
Sorry for not coming back to you sooner - had some urgent tasks I needed to do.
Thank you very much for the patch! With it I can get the KMU slots to work both with and without TF-M enabled.

In our application we will just use one or two keys. We would like to use TF-M as long as the memory footprint isn't too large. However, this is what I'm facing right now:
If I enable CONFIG_TFM_PROFILE_TYPE_MINIMAL the I get these numbers:

[191/195] Linking C executable bin/tfm_s.axf
Memory region         Used Size  Region Size  %age Used
           FLASH:       25660 B        26 KB     96.38%
             RAM:        9332 B        32 KB     28.48%

These could be OK for us. I.e. TF-M only uses ~10 KB of RAM and I think CONFIG_PM_PARTITION_SIZE_TFM_SRAM can adjust the dedicated RAM area so that it doesn't need to reserve the 32 KB it currently does.

The problem I'm facing is when I'm enabling CONFIG_TFM_ITS_ENCRYPTED. This config doesn't work with CONFIG_TFM_PROFILE_TYPE_MINIMAL so then when compiling I get this footprint:

[245/249] Linking C executable bin/tfm_s.axf
Memory region         Used Size  Region Size  %age Used
           FLASH:       78096 B       254 KB     30.03%
             RAM:       56744 B        76 KB     72.91%

It also needs the extra NVM partitions for the trusted storage not listed here.

Am I missing some config to keep the footprint down here because I can't see how it would be worth wasting this much RAM/NVM just to be able to store some keys. Isn't the purpose of the KMU exactly to keep the keys securly stored but with the main difference that it's a HW block which cost no RAM/NVM?

The remaining problem I see now is that if we want to use TF-M I still need to enable CONFIG_TFM_ITS_ENCRYPTED even if I use the KMU to store the key resulting in the big mem footprint.

Kind regards

/Andreas

RE: KMU PSA persistent key generation

Hieu — Fri, 07 Feb 2025 20:07:14 GMT

Hi Andreas,

Some colleagues helped me look into it. There are a few issues that we need to address:

There is indeed a bug in NCS v2.9.0 that makes psa_cipher_encrypt() failed. It is fixed here with this PR: https://github.com/nrfconnect/sdk-nrf/pull/20199.

You can patch NCS with that PR, or try NCS main branch right now.
ALG_CBC_NO_PADDING requires that the plain text is a multiple of the AES block size, 16. Therefore, please ensure this.
There seems to be some issue with KMU slot 2 at the moment. We are looking into it.

Meanwhile, please try some other slot, like 3 or 4.

Below I also attached my tested sample. Remember that it only works with PR 20199 patched.

By the way, if you don't mind sharing, our team would like to ask you about the reason you don't want to use Trusted Storage. We hope it is not also some RAM consumption issue, which can be a little strange.

devzone.nordicsemi.com/.../c339750_5F00_persistent_5F00_key_5F00_usage_5F00_modified_5F00_kmu.zip

Hieu

RE: KMU PSA persistent key generation

Andreas u-blox — Wed, 05 Feb 2025 08:59:30 GMT

Hi Hieu,

ok, understod. I thought the only difference between nRF54L15 and nRF54L10 was NVM and RAM size according to the "nRF54L Series SoC options" in link below, so I'm a bit supprised that TF-M is supported only for nRF54L15:
https://www.nordicsemi.com/Products/nRF54L15

But let's focus on getting the generated keys stored in KMU with TF-M disabled if that helps.

[quote userid="9456" url="~/f/nordic-q-a/118434/kmu-psa-persistent-key-generation/521462"]Also, while we understood that you are concern about NVM and RAM consumption of TF-M[/quote]

As I mentioned when I enabled TF-M the TF-M firmware consumed 40% of the RAM. This is RAM that we can't use for our own app as it is dedicated for TF-M.

But I think we're getting a little out of topic. My question is how I get the things descripbed here to work:
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54l/cryptography.html
I.e. can you provide a working config (with or without TF-M) that allows us to use the PSA crypto API to generate and store keys in a KMU slot?

/Andreas

RE: KMU PSA persistent key generation

Hieu — Wed, 05 Feb 2025 08:37:38 GMT

Hi Andreas,

A colleague also points out that you are enabling TF-M for the nRF54L10, but I am not. I just built with the nrf54l15dk/nrf54l10/cpuapp target. That would explain the difference between your observation and mine.

However, the problem is that TF-M isn't supported on the nRF54L10 yet. See this Security Feature Support matrix.

Before we go further, can you proceed without TF-M for now?

Also, while we understood that you are concern about NVM and RAM consumption of TF-M, could you share why? This is to see if there are any alternatives that can help. Of course, as TF-M isn't supported now, the point is a little moot.

Hieu

RE: KMU PSA persistent key generation

Andreas u-blox — Tue, 04 Feb 2025 12:45:52 GMT

Hi Hieu,

If you use the persistent key storage example and build it for nrf54l15dk/nrf54l15/cpuapp/ns it will, by default, enable Trusted Firmware ITS through the CONFIG_TFM_ITS_ENCRYPTED. When this is enabled TF-M will use a lot of RAM and it will also add the extra partitions for TF-M secure storage. This is exactly what we want to avoid, so maybe you can use hello world app as a starting point instead (this is what I used). In this way we can make sure no other config is set.

Since the nRF54Lxx includes the Key Management Unit HW we want to store the keys directly in this HW instead of wasting a lot of RAM and flash using a software implementation of securly storing the keys using TF-M ITS. According to the doc below, as I read it, the way to do this is to use the PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION() with PSA_KEY_LOCATION_CRACEN_KMU when setting the lifetime by calling psa_set_key_lifetime(). As far as I understand from the same doc I also need to use PSA_KEY_HANDLE_FROM_CRACEN_KMU_SLOT() when setting the key_id using psa_set_key_id():
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54l/cryptography.html#programming_model_for_referencing_keys

[quote userid="9456" url="~/f/nordic-q-a/118434/kmu-psa-persistent-key-generation/520943"]If I replace either the lifetime attribute, or the algorithm attribute, or both, with the ones you used, psa_cipher_encrypt() returns -135, PSA_ERROR_INVALID_ARGUMENT.[/quote]

I think when you don't use these arguments the generated keys will be stored in TF-M ITS (Internal Trusted Storage) and not KMU. I have no problem running the Persistent key storage example without any modifications, the problem is that the keys then are stored in the TF-M ITS and not KMU. The reason that you get PSA_ERROR_INVALID_ARGUMENT instead of PSA_ERROR_NOT_SUPPORTED could maybe be that the Persistent key storage example sets CONFIG_TFM_ITS_ENCRYPTED which I don't use.

/Andreas

RE: KMU PSA persistent key generation

Hieu — Fri, 31 Jan 2025 20:25:17 GMT

Hi Andreas,

I was trying to reproduce your issue with the Crypto: Persistent key storage sample. I did run into issues, but not the one you have.

If I replace either the lifetime attribute, or the algorithm attribute, or both, with the ones you used, psa_cipher_encrypt() returns -135, PSA_ERROR_INVALID_ARGUMENT.

The key generation itself works fine. As this overall still failed, I will continue looking into it, but can you double check your setup to see if the key generation is working?

Hieu

RE: KMU PSA persistent key generation

Hieu — Wed, 29 Jan 2025 18:33:21 GMT

Hi Andreas,

I am new to this feature. Let me look into this a bit and I will get back to you this week.

Hieu