Update persistent_key_load_key_from_storage to the new attribute-based
key creation interface. I tweaked the code a little to make it simpler
and more robust without changing the core logic.
This commit starts a migration to a new interface for key creation.
Today, the application allocates a handle, then fills its metadata,
and finally injects key material. The new interface fills metadata
into a temporary structure, and a handle is allocated at the same time
it gets filled with both metadata and key material.
This commit was obtained by moving the declaration of the old-style
functions to crypto_extra.h and renaming them with the to_handle
suffix, adding declarations for the new-style functions in crypto.h
under their new name, and running
perl -i -pe 's/\bpsa_(import|copy|generator_import|generate)_key\b/$&_to_handle/g' library/*.c tests/suites/*.function programs/psa/*.c
perl -i -pe 's/\bpsa_get_key_lifetime\b/$&_from_handle/g' library/*.c tests/suites/*.function programs/psa/*.c
Many functions that are specific to the old interface, and which will
not remain under the same name with the new interface, are still in
crypto.h for now.
All functional tests should still pass. The documentation may have
some broken links.
Since there is now a single storage backend, we don't need a backend
interface. Make the functions that were declared in
psa_crypto_storage_backend.h and are now both defined and used in
psa_crypto_storage.c static, except for psa_is_key_present_in_storage
which is used by the gray-box tests and is now declared in
psa_crypto_storage.h.
Remove the type and bits arguments to psa_allocate_key() and
psa_create_key(). They can be useful if the implementation wants to
know exactly how much space to allocate for the slot, but many
implementations (including ours) don't care, and it's possible to work
around their lack by deferring size-dependent actions to the time when
the key material is created. They are a burden to applications and
make the API more complex, and the benefits aren't worth it.
Change the API and adapt the implementation, the units test and the
sample code accordingly.
Add new initializers for key policies and use them in our docs, example
programs, tests, and library code. Prefer using the macro initializers
due to their straightforwardness.
Change the way some lines are wrapped to cut at a more logical place.
This commit mainly rewrites multi-line calls to TEST_EQUAL, and also a
few calls to PSA_ASSERT.
This commit is the result of the following command, followed by
reindenting (but not wrapping lines):
perl -00 -i -pe 's/^( *)TEST_ASSERT\(([^;=]*)(?: |\n *)==([^;=]*)\);$/${1}TEST_EQUAL($2,$3);/gm' tests/suites/test_suite_psa_*.function
This commit is the result of the following command, followed by
reindenting (but not wrapping lines):
perl -00 -i -pe 's/^( *)TEST_ASSERT\(([^;=]*)(?: |\n *)==\s*PSA_SUCCESS\s*\);$/${1}PSA_ASSERT($2 );/gm' tests/suites/test_suite_psa_*.function
Switch from the direct use of slot numbers to handles allocated by
psa_allocate_key.
The general principle for each function is:
* Change `psa_key_slot_t slot` to `psa_key_handle_t handle` or
`psa_key_id_t key_id` depending on whether it's used as a handle to
an open slot or as a persistent name for a key.
* Call psa_create_key() before using a slot, instead of calling
psa_set_key_lifetime to make a slot persistent.
Remove the unit test persistent_key_is_configurable which is no longer
relevant.
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.
