Key lifetimes

The default lifetime for volatile keys.

A volatile key only exists as long as the identifier to it is not destroyed. The key material is guaranteed to be erased on a power reset.

A key with this lifetime is typically stored in the RAM area of the PSA Crypto subsystem. However this is an implementation choice. If an implementation stores data about the key in a non-volatile memory, it must release all the resources associated with the key and erase the key material if the calling application terminates.

The default lifetime for persistent keys.

A persistent key remains in storage until it is explicitly destroyed or until the corresponding storage area is wiped. This specification does not define any mechanism to wipe a storage area, but integrations may provide their own mechanism (for example to perform a factory reset, to prepare for device refurbishment, or to uninstall an application).

This lifetime value is the default storage area for the calling application. Integrations of Mbed TLS may support other persistent lifetimes. See psa_key_lifetime_t for more information.

The persistence level of volatile keys.

See psa_key_persistence_t for more information.

The default persistence level for persistent keys.

See psa_key_persistence_t for more information.

A persistence level indicating that a key is never destroyed.

See psa_key_persistence_t for more information.

Whether a key lifetime indicates that the key is volatile.

A volatile key is automatically destroyed by the implementation when the application instance terminates. In particular, a volatile key is automatically destroyed on a power reset of the device.

A key that is not volatile is persistent. Persistent keys are preserved until the application explicitly destroys them or until an implementation-specific device management event occurs (for example, a factory reset).

Parameters

lifetime

The lifetime value to query (value of type psa_key_lifetime_t ).

Returns

1 if the key is volatile, otherwise 0 .

Whether a key lifetime indicates that the key is read-only.

Read-only keys cannot be created or destroyed through the PSA Crypto API. They must be created through platform-specific means that bypass the API.

Some platforms may offer ways to destroy read-only keys. For example, consider a platform with multiple levels of privilege, where a low-privilege application can use a key but is not allowed to destroy it, and the platform exposes the key to the application with a read-only lifetime. High-privilege code can destroy the key even though the application sees the key as read-only.

Parameters

lifetime

The lifetime value to query (value of type psa_key_lifetime_t ).

Returns

1 if the key is read-only, otherwise 0 .

Construct a lifetime from a persistence level and a location.

Parameters

persistence	The persistence level (value of type psa_key_persistence_t ).
location	The location indicator (value of type psa_key_location_t ).

Returns

The constructed lifetime value.

The local storage area for persistent keys.

This storage area is available on all systems that can store persistent keys without delegating the storage to a third-party cryptoprocessor.

See psa_key_location_t for more information.

The null key identifier.

The minimum value for a key identifier chosen by the application.

The maximum value for a key identifier chosen by the application.

The minimum value for a key identifier chosen by the implementation.

The maximum value for a key identifier chosen by the implementation.

Encoding of key lifetimes.

The lifetime of a key indicates where it is stored and what system actions may create and destroy it.

Lifetime values have the following structure:

• Bits 0-7 (#PSA_KEY_LIFETIME_GET_PERSISTENCE( lifetime )): persistence level. This value indicates what device management actions can cause it to be destroyed. In particular, it indicates whether the key is volatile or persistent . See psa_key_persistence_t for more information.
• Bits 8-31 (#PSA_KEY_LIFETIME_GET_LOCATION( lifetime )): location indicator. This value indicates which part of the system has access to the key material and can perform operations using the key. See psa_key_location_t for more information.

Volatile keys are automatically destroyed when the application instance terminates or on a power reset of the device. Persistent keys are preserved until the application explicitly destroys them or until an integration-specific device management event occurs (for example, a factory reset).

Persistent keys have a key identifier of type mbedtls_svc_key_id_t . This identifier remains valid throughout the lifetime of the key, even if the application instance that created the key terminates. The application can call psa_open_key() to open a persistent key that it created previously.

The default lifetime of a key is PSA_KEY_LIFETIME_VOLATILE . The lifetime PSA_KEY_LIFETIME_PERSISTENT is supported if persistent storage is available. Other lifetime values may be supported depending on the library configuration.

Values of this type are generally constructed by macros called PSA_KEY_LIFETIME_xxx .

Note

Values of this type are encoded in the persistent key store. Any changes to existing values will require bumping the storage format version and providing a translation when reading the old format.

Encoding of key persistence levels.

What distinguishes different persistence levels is what device management events may cause keys to be destroyed. Volatile keys are destroyed by a power reset. Persistent keys may be destroyed by events such as a transfer of ownership or a factory reset. What management events actually affect persistent keys at different levels is outside the scope of the PSA Cryptography specification.

The PSA Cryptography specification defines the following values of persistence levels:

• 0 = PSA_KEY_PERSISTENCE_VOLATILE : volatile key. A volatile key is automatically destroyed by the implementation when the application instance terminates. In particular, a volatile key is automatically destroyed on a power reset of the device.
• 1 = PSA_KEY_PERSISTENCE_DEFAULT : persistent key with a default lifetime.
• 2-254 : currently not supported by Mbed TLS.
• 255 = PSA_KEY_PERSISTENCE_READ_ONLY : read-only or write-once key. A key with this persistence level cannot be destroyed. Mbed TLS does not currently offer a way to create such keys, but integrations of Mbed TLS can use it for built-in keys that the application cannot modify (for example, a hardware unique key (HUK)).

Note

Key persistence levels are 8-bit values. Key management interfaces operate on lifetimes (type psa_key_lifetime_t ) which encode the persistence as the lower 8 bits of a 32-bit value.

Values of this type are encoded in the persistent key store. Any changes to existing values will require bumping the storage format version and providing a translation when reading the old format.

Encoding of key location indicators.

If an integration of Mbed TLS can make calls to external cryptoprocessors such as secure elements, the location of a key indicates which secure element performs the operations on the key. Depending on the design of the secure element, the key material may be stored either in the secure element, or in wrapped (encrypted) form alongside the key metadata in the primary local storage.

The PSA Cryptography API specification defines the following values of location indicators:

• 0 : primary local storage. This location is always available. The primary local storage is typically the same storage area that contains the key metadata.
• 1 : primary secure element. Integrations of Mbed TLS should support this 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.
• 2-0x7fffff: other locations defined by a PSA specification. The PSA Cryptography API does not currently assign any meaning to these locations, but future versions of that specification or other PSA specifications may do so.
• 0x800000-0xffffff : vendor-defined locations. No PSA specification will assign a meaning to locations in this range.

Note

Key location indicators are 24-bit values. Key management interfaces operate on lifetimes (type psa_key_lifetime_t ) which encode the location as the upper 24 bits of a 32-bit value.

Values of this type are encoded in the persistent key store. Any changes to existing values will require bumping the storage format version and providing a translation when reading the old format.

Encoding of identifiers of persistent keys.

• Applications may freely choose key identifiers in the range PSA_KEY_ID_USER_MIN to PSA_KEY_ID_USER_MAX .

  Note

  This file was shipped as part of the Silicon Labs SDK. Users of the Silicon Labs SDK need to be aware that the entire SDK is considered the 'application' from the mbed TLS / PSA documentation perspective. Please refer to sl_psa_usage_key_namespacing to see which key identifiers are available to Silicon Labs SDK users.

• The implementation may define additional key identifiers in the range PSA_KEY_ID_VENDOR_MIN to PSA_KEY_ID_VENDOR_MAX .
• 0 is reserved as an invalid key identifier.
• Key identifiers outside these ranges are reserved for future use.

Note

Values of this type are encoded in the persistent key store. Any changes to how values are allocated must require careful consideration to allow backward compatibility.

Encoding of key identifiers as seen inside the PSA Crypto implementation.

When PSA Crypto is built as a library inside an application, this type is identical to psa_key_id_t . When PSA Crypto is built as a service that can store keys on behalf of multiple clients, this type encodes the psa_key_id_t value seen by each client application as well as extra information that identifies the client that owns the key.

Note

Values of this type are encoded in the persistent key store. Any changes to existing values will require bumping the storage format version and providing a translation when reading the old format.