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.
The persistent key implementation will be split across multiple
files as it will eventually be implementing multiple storage
backends. As these internal functions will need to be callable by
other files, we will add the headers in the library folder. This
commit adds this include location to the necessary scripts.
For tests, the library is added as an include location as testing
on-target with Mbed OS is not possible with paths including ".."
In /crypto/.gitignore, list files that are generated by a build done
under /crypto/. In the outer /.gitignore, list files under /crypto/
only if they are created by the export process.
This commit slightly refines both lists and adds some build products
to /crypto/.gitignore.
