Allow use of persistent keys, including configuring them, importing and
exporting them, and destroying them.
When getting a slot using psa_get_key_slot, there are 3 scenarios that
can occur if the keys lifetime is persistent:
1. Key type is PSA_KEY_TYPE_NONE, no persistent storage entry:
- The key slot is treated as a standard empty key slot
2. Key type is PSA_KEY_TYPE_NONE, persistent storage entry exists:
- Attempt to load the key from persistent storage
3. Key type is not PSA_KEY_TYPE_NONE:
- As checking persistent storage on every use of the key could
be expensive, the persistent key is assumed to be saved in
persistent storage, the in-memory key is continued to be used.
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.
Even with a shallow clone of the repo where there are no tags available
to version with, don't error and instead show a unique abbreviated
commit hash as fallback.
Create a tarball-based ditribution of the Mbed Crypto source code using the
code from Mbed TLS. Only export the files needed by Mbed Crypto to
implement the PSA Crypto API. Rename "mbedtls_*" and "MBEDTLS_*" symbols to
"mbedcrypto_*" and "MBEDCRYPTO_*".
The exported distribution can stand alone, without any Mbed TLS repository
needing to be present. "make test" will continue to work as before and will
run only the PSA Crypto test suite.