Differentiate between _key identifiers_, which are always `uint32_t`,
and _key file identifiers_, which are platform-dependent. Normally,
the two are the same.
In `psa/crypto_platform.h`, define `psa_app_key_id_t` (which is always
32 bits, the standard key identifier type) and
`psa_key_file_id_t` (which will be different in some service builds).
A subsequent commit will introduce a platform where the two are different.
It would make sense for the function declarations in `psa/crypto.h` to
use `psa_key_file_id_t`. However this file is currently part of the
PSA Crypto API specification, so it must stick to the standard type
`psa_key_id_t`. Hence, as long as the specification and Mbed Crypto
are not separate, use the implementation-specific file
`psa/crypto_platform.h` to define `psa_key_id_t` as `psa_key_file_id_t`.
In the library, systematically use `psa_key_file_id_t`.
perl -i -pe 's/psa_key_id_t/psa_key_file_id_t/g' library/*.[hc]
When `MBEDTLS_PLATFORM_C` is not enabled, our PSA Crypto implementation
depends on the standard C library for functions like snprintf() and
exit(). However, our implementation was not including the proper header
files nor redefining all `mbedtls_*` symbols properly to ensure
successful builds without MBEDTLS_PLATFORM_C. Add the necessary header
files and macro definitions to our PSA Crypto implementation.
Move the persistent storage implementation from psa_key_slot_t to
psa_key_id_t. For the most part, this just means changing the types of
function arguments.
Update the documentation of some functions to reflect the fact that
the slot identifier is purely a storage identifier and is not related
to how the slot is designated in memory.
Add a magic header to the storage format used with files. The
header is used as an initial check that the data is what we expect,
rather than garbage data.
Add new functions, psa_load_persistent_key(),
psa_free_persistent_key_data(), and psa_save_persistent_key(), for
managing persistent keys. These functions load to or save from our
internal representation of key slots. Serialization is a concern of the
storage backend implementation and doesn't abstraction-leak into the
lifetime management code.
An initial implementation for files is provided. Additional storage
backends can implement this interface for other storage types.
