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.
Move psa_load_persistent_key_into_slot,
psa_internal_make_key_persistent and psa_internal_release_key_slot to
the slot management module.
Expose psa_import_key_into_slot from the core.
After this commit, there are no longer any functions declared in
psa_crypto_slot_management.h and defined in psa_crypto.c. There are
still function calls in both directions between psa_crypto.c and
psa_crypto_slot_management.c.
Move the key slot array and its initialization and wiping to the slot
management module.
Also move the lowest-level key slot access function psa_get_key_slot
and the auxiliary function for slot allocation
psa_internal_allocate_key_slot to the slot management module.
Since Mbed TLS 2.10, there is a single copy of
mbedtls_platform_zeroize for the whole library instead of one per
module. Update the PSA crypto module accordingly.
This commit finishes the removal of support for direct access to key
slots in psa_crypto.c.
This marks the end of the necessary phase of the transition to key
handles. The code should subsequently be refactored to move key slot
management from psa_crypto.c to psa_crypto_slot_management.c.
This commit marks the beginning of the removal of support for direct
access to key slots. From this commit on, programs that use
psa_key_slot_t will no longer compile.
Subsequent commits will remove the now-unused legacy support in
psa_crypto.c.
Many places in the code called psa_remove_key_data_from_memory (which
preserves metadata for the sake of failues in psa_import_key) followed
by clearing the slot data. Use an auxiliary function for this.
Access the slot directly rather than going through psa_get_key_slot.
Unlike other places where key slots are accessed through
psa_get_key_slot, here, we know where all the slots are and there are
no policy or permission considerations.
This resolves a memory leak: allocated slots were not getting freed
because psa_get_key_slot rejected the attempt of accessing them
directly rather than via a handle.
Implement psa_allocate_key, psa_open_key, psa_create_key,
psa_close_key.
Add support for keys designated to handles to psa_get_key_slot, and
thereby to the whole API.
Allocated and non-allocated keys can coexist. This is a temporary
stage in order to transition from the use of direct slot numbers to
allocated handles only. Once all the tests and sample programs have
been migrated to use handles, the implementation will be simplified
and made more robust with support for handles only.
At the moment, the in-storage slot identifier is the in-memory slot
number. But track them separately, to prepare for API changes that
will let them be different (psa_open_key, psa_create_key).
Add missing compilation guards that broke the build if either GCM or
CCM was not defined.
Add missing guards on test cases that require GCM or CBC.
The build and tests now pass for any subset of {MBEDTLS_CCM_C,
MBEDTLS_GCM_C}. There are still unused variables warnings if neither
is defined.
Add a function to configure entropy sources. For testing only.
Use it to test that the library initialization fails properly if there is no
entropy source.
Allow mbedtls_psa_crypto_free to be called twice, or without a prior
call to psa_crypto_init. Keep track of the initialization state more
precisely in psa_crypto_init so that mbedtls_psa_crypto_free knows
what to do.
When generating keys that have persistent lifetime, we will need
the keys to be in the exported format to save to persistent storage.
This refactoring to separate checking the slots usage from the
exporting of the key data will be necessary for using
psa_internal_export_key in psa_generate_key.
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.
Create a new function psa_remove_key_from_memory() from psa_destroy_key().
This is needed as psa_destroy_key() will remove all key data, including
persistent storage. mbedtls_psa_crypto_free() will now only free in-memory
data and not persistent data.
Create a new function psa_import_key_into_slot() from psa_import_key().
This is common functionality that will be used both when importing a
key and loading a key from persistent storage.
If psa_key_derivation_internal() fails, it's up to the caller to clean
up. Do this, and add a note at the top of
psa_key_derivation_internal() and its auxiliary functions.
There is no non-regression test because at the moment the only way to
trigger an error is a borderline low-memory condition and we don't
have the means to trigger this.
Add missing checks for defined(MBEDTLS_MD_C) around types and
functions that require it (HMAC, HKDF, TLS12_PRF).
Add missing checks for defined(MBEDTLS_ECDSA_DETERMINISTIC) around
code that calls mbedtls_ecdsa_sign_det().
Add missing checks for defined(MBEDTLS_ECDH_C) around ECDH-specific
functions.
The standard prohibits calling memcpy() with NULL pointer
arguments, even if the size argument is 0.
The TLS-1.2 PRF generator setup function previously called
memcpy() with the label and salt as the source, even if
they were of length 0, as exercised by the derive_key_policy
test case in the PSA crypto test suite.
This commit adds guards around the memcpy() calls so that they
are only executed of salt or label have positive length, respectively.
In psa_key_agreement_ecdh, check that the public key is on the same
curve as the private key. The underlying mbedtls API doesn't check.
If the curves don't match, psa_key_agreement_ecdh is practically
guaranteed to return INVALID_ARGUMENT anyway, because way the code is
written, the public point is interpreted on the curve of the private
point, and it is rejected because the point is not on the curve. This
is why the test case "PSA key agreement setup: ECDH, raw: public key
on different curve" passed even before adding this check.
In ECDH key agreement, allow a public key with the OID id-ECDH, not
just a public key with the OID id-ecPublicKey.
Public keys with the OID id-ECDH are not permitted by psa_import_key,
at least for now. There would be no way to use the key for a key
agreement operation anyway in the current API.