Using PSA function to persist key in kmu AND later restore it for AES encryption

[Anthony Ambuehl]

NCS v2.3.0

NRF5340DK nrf5340 cpuapp

I'm trying to understand how I would configure and use the PSA functions to store a key in the KMU and then perform an encryption operation using the key directly from the kmu without loading into memory.

I saw this sample developer.nordicsemi.com/.../README.html which shows generating a random key and persisting it some place. Its unclear to me if this is actually stored in the kmu or if its stored in a secure partition. This example also does not demonstrate how to use a key that was previously created and persisted.

If I have multiple persistent keys that were previously created, how do I get the key_handle to them?

I noticed in crypto_extra.h there is an api to specify a slot number: psa_set_key_slot_number

and also an API for registering an already loaded key: mbedtls_psa_register_se_key

However I cannot figure out how to get these APIs enabled in my build.. it requires MBEDTLS_PSA_CRYPTO_SE_C which does not seem to have an existing KCONFIG flag.

Is the PSA a supported way to perform crypto operations with persistent keys? Do I need to use nrf3x and mbedtls functions directly as in this sample github.com/.../main.c ?

It would be great if the persistent key usage sample actually showed retrieving key and using it.

[Anthony Ambuehl]

I found there is a key_id attribute which can be set as an attribute.  Setting the key_id attribute automatically makes the associated key persistent.

Perhaps after creating (e.g. generating it) a key with an assigned key_id  from that point forward its possible to perform operations using that key_id without creating/importing/copying ? 

Still if that is the case, I would need a way to determine whether the key has been created previously.  

Also I still need to know understand where the key is actually stored and how it is moved to the cryptocell...

[Einar Thorsrud]

Hi,

When you store persistent keys with PSA crypto those are stored in the Internal Trusted Storage and not the KMU. However, the internal trusted storage is encrypted by a key that is stored in the KMU.

As you wound, they key is identified with an ID/handle (that you get when generating or importing it), and it is the handle you use to refer to that key whenever it is needed, never the key itself. You can se several examples of this in the examples under nrf\samples\crypto\.

There is no explicit API for checking if a key exists. So you would have to try to use it or generate it, and handle the error code if it did / did not exist.

I would recommend using the PSA APIs, but if you need to use the KMU directly to store your data there, you can use CC3XX Platform - KMU APIs.

[Anthony Ambuehl]

Hello Einar,

According to the ITS Design Documents  the ITS is NOT stored encrypted.  

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.0/tfm/technical_references/design_docs/tfm_its_service.html

Compared to Protected Storage, encryption, authentication and rollback protection are not required, so the SST encrypted object layer and the crypto and NV counter interfaces are not required.

Is it possible this design document is out of date, and the actual implementation is using encryption?

Also it seems I cannot use CC3XX Platform library if I have BUILD_WITH_TFM=y

EDIT:

After reviewing the git history for modules/tee/tf-m/trusted-firmware-m/secure_fw/partitions/internal_trusted_storage, it appears that Nordic added encryption to the implementation of ITS in 2021. 

It needs to be enabled with

CONFIG_TFM_ITS_ENCRYPTED=y

It seems without this flag ITS stores data unencrypted. 

Does Nordic have any additional design documents for the changes to ITS?

Is all information stored in ITS encrypted with a single key.  From the git change, it appears to be using a key derived from the HUK.  Is that correct?   How can I assess the security of the derived key?

 

 

[Einar Thorsrud]

Hi Anthony,

You are right, encrypted ITS is a non-standard feature we have implemented which needs to be enabled with CONFIG_TFM_ITS_ENCRYPTED as you have found. We do not have any design documents for it, unfortunately.