Key lifetimes#

psa_key_lifetime_t#

typedef uint32_t psa_key_lifetime_t

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.

psa_key_persistence_t#

typedef uint8_t psa_key_persistence_t

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.

psa_key_location_t#

typedef uint32_t psa_key_location_t

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.

psa_key_id_t#

typedef uint32_t psa_key_id_t

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 PSA Crypto key ID namespacing in the Silicon Labs SDK 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.

mbedtls_svc_key_id_t#

typedef psa_key_id_t mbedtls_svc_key_id_t

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

Some user code (e.g.

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.

PSA Crypto test suites) use the mbedtls_svc_key_id_t instead of psa_key_id_t to allow a multi-client service that exposes the PSA Cryptograpy API in each client and encodes the client identity in the key identifier (ref, MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER). The SiliconLabs TZ SKL does not support MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER but still some user code applies the mbedtls_svc_key_id_t without really using the client part (encoding of owner/client id). Therefore we need to defined mbedtls_svc_key_id_t equal to psa_key_id_t.

psa_key_lifetime_t#

typedef uint32_t psa_key_lifetime_t

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.

psa_key_persistence_t#

typedef uint8_t psa_key_persistence_t

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.

psa_key_location_t#

typedef uint32_t psa_key_location_t

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.

psa_key_id_t#

typedef uint32_t psa_key_id_t

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.

• 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.

mbedtls_svc_key_id_t#

typedef psa_key_id_t mbedtls_svc_key_id_t

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

Some user code (e.g.

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.

PSA Crypto test suites) use the mbedtls_svc_key_id_t instead of psa_key_id_t to allow a multi-client service that exposes the PSA Cryptograpy API in each client and encodes the client identity in the key identifier (ref, MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER). The SiliconLabs TZ SKL does not support MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER but still some user code applies the mbedtls_svc_key_id_t without really using the client part (encoding of owner/client id). Therefore we need to defined mbedtls_svc_key_id_t equal to psa_key_id_t.

mbedtls_svc_key_id_make#

static mbedtls_svc_key_id_t mbedtls_svc_key_id_make (unsigned int unused, psa_key_id_t key_id)

Utility to initialize a key identifier at runtime.

mbedtls_svc_key_id_equal#

static int mbedtls_svc_key_id_equal (mbedtls_svc_key_id_t id1, mbedtls_svc_key_id_t id2)

Compare two key identifiers.

Returns

• Non-zero if the two key identifier are equal, zero otherwise.

mbedtls_svc_key_id_is_null#

static int mbedtls_svc_key_id_is_null (mbedtls_svc_key_id_t key)

Check whether a key identifier is null.

Returns

• Non-zero if the key identifier is null, zero otherwise.