Restriction from secure element to store specific type of key

[skirti]

I am using nrf5340dk board and trying to import a key using PSA API. The api used is psa_import_key() API for key attributes, 

key_id = 0x010001A0,   key_type = PSA_KEY_TYPE_AES ,  key_bits = 128,  key_usage = PSA_KEY_USAGE_DERIVE, key_alg = PSA_ALG_CMAC

key_lifetime = 0x00000101 ( Persistence level -> PSA_KEY_PERSISTENCE_DEFAULT, Location indicator -> Primary secure element ) 
                                                PSA spec says, Implementations should support Primary secure element(location indicator)
                                                value if there is a secure element attached to the operating environment.  As a guideline,
                                                secure elements may provide higher resistance against side channel and physical attacks
                                                than the primary local storage, but may have restrictions on supported key types, sizes,
                                                policies and operations and may have different performance characteristics.

If I use Primary local element  which means as per PSA spec, primary local storage is typically the same storage area that contains the key metadata instead of Primary secure element , key import works.

I would like to know if there is any restriction from hardware i.e. Primary secure element to store above specified type of key.

[Sigurd Hellesvik]

Hi,

So that we are on the same page: Can you provide a link to where the following documentation comes from?

key_lifetime = 0x00000101 ( Persistence level -> PSA_KEY_PERSISTENCE_DEFAULT, Location indicator -> Primary secure element ) 
                                                PSA spec says, Implementations should support Primary secure element(location indicator)
                                                value if there is a secure element attached to the operating environment.  As a guideline,
                                                secure elements may provide higher resistance against side channel and physical attacks
                                                than the primary local storage, but may have restrictions on supported key types, sizes,
                                                policies and operations and may have different performance characteristics.

Regards,
Sigurd Hellesvik

[skirti]

armmbed.github.io/.../lifetimes.html

Please check Primary secure element section in the given table in screenshot. Same can be accessed using the above link.

[Sigurd Hellesvik]

Hi,

Our nRF microcontrollers do not have secure elements built-in.

If you store persistent PSA keys, it will store the keys using the Internal Trusted Storage from Trusted Firmware-M.
This is internal flash which belongs to the secure partition.

If you need your keys to be a bit more secure than this, you can enable CONFIG_TFM_ITS_ENCRYPTED to make the ITS data encrypted.
The encryption key for the ITS data is derived from a Hardware unique Key
Keep in mind that Encrypted ITS is not in the PSA Spec as far as I know.

For some general Trusted Firmware-M concepts, see  An Introduction to Trusted Firmware-M (TF-M)

Regards,
Sigurd Hellesvik

[skirti]

Thank You Sigurd for the information.

Would like to confirm one more thing does nrf5340 supports PSA Protected storage implementation or only PSA Internal Trusted Storage ?

[Sigurd Hellesvik]

Hi,

Yes we support PSA Protected Storage.

If you want to store your own data I recommend Protected Storage, as Internal Trusted Storage is mostly used internally by TF-M as a backend.
For  example, the implementation of PSA Protected Storage use the PSA Internal Trusted Storage for the storage, if that makes sense.

EDIT: Also see the Zephyr PSA Protected Storage sample

Regards,
Sigurd Hellesvik