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.
psa_key_derivation requires the caller to specify a maximum capacity.
This commit adds a special value that indicates that the maximum
capacity should be the maximum supported by the algorithm. This is
currently meant only for selection algorithms used on the shared
secret produced by a key agreement.
On key import and key generation, for RSA, reject key sizes that are
not a multiple of 8. Such keys are not well-supported in Mbed TLS and
are hardly ever used in practice.
The previous commit removed support for non-byte-aligned keys at the
PSA level. This commit actively rejects such keys and adds
corresponding tests (test keys generated with "openssl genrsa").
Remove the need for an extra function mbedtls_rsa_get_bitlen. Use
mbedtls_rsa_get_len, which is only correct for keys whose size is a
multiple of 8. Key sizes that aren't a multiple of 8 are extremely
rarely used, so in practice this is not a problematic limitation.
Skip all writing to the target buffer if its size is 0, since in this
case the pointer might be invalid and this would cause the calls to
memcpy and memset to have undefined behavior.
Change the import/export format of private elliptic curve keys from
RFC 5915 to the raw secret value. This commit updates the format
specification and the import code, but not the export code.
Wipe the whole MAC intermediate buffer, not just the requested MAC
size. With truncated MAC algorithms, the requested MAC size may be
smaller than what is written to the intermediate buffer.
There was a lot of repetition between psa_aead_encrypt and
psa_aead_decrypt. Refactor the code into a new function psa_aead_setup.
The new code should behave identically except that in some cases where
multiple error conditions apply, the code may now return a different
error code.
Internally, I rearranged some of the code:
* I removed a check that the key type was in CATEGORY_SYMMETRIC because
it's redundant with mbedtls_cipher_info_from_psa which enumerates
supported key types explicitly.
* The order of some validations is different to allow the split between
setup and data processing. The code now calls a more robust function
psa_aead_abort in case of any error after the early stage of the setup.
OFB and CFB are streaming modes. XTS is a not a cipher mode but it
doesn't use a separate padding step. This leaves only CBC as a block
cipher mode that needs a padding step.
Since CBC is the only mode that uses a separate padding step, and is
likely to remain the only mode in the future, encode the padding mode
directly in the algorithm constant, rather than building up an
algorithm value from a chaining mode and a padding mode. This greatly
simplifies the interface as well as some parts of the implementation.
Mbed TLS distinguishes "invalid padding" from "valid padding but the
rest of the signature is invalid". This has little use in practice and
PSA doesn't report this distinction. We just report "invalid
signature".