For AEAD ciphers, the information contained in mbedtls_cipher_info
is not enough to deduce a PSA algorithm value of type psa_algorithm_t.
This is because mbedtls_cipher_info doesn't contain the AEAD tag
length, while values of type psa_algorithm_t do.
This commit adds the AEAD tag length as a separate parameter
to mbedtls_cipher_setup_psa(). For Non-AEAD ciphers, the value
must be 0.
This approach is preferred over passing psa_algorithm_t directly
in order to keep the changes in existing code using the cipher layer
small.
Mbed TLS cipher layer allows usage of keys for other purposes
than indicated in the `operation` parameter of `mbedtls_cipher_setkey()`.
The semantics of the PSA Crypto API, in contrast, checks key
usage against the key policy.
As a remedy, this commit modifies the PSA key slot setup to
always allow both encryption and decryption.
This commit implements the internal key slot management performed
by PSA-based cipher contexts. Specifically, `mbedtls_cipher_setkey()`
wraps the provided raw key material into a key slot, and
`mbedtls_cipher_free()` destroys that key slot.
This field determines whether a cipher context should
use an external implementation of the PSA Crypto API for
cryptographic operations, or Mbed TLS' own crypto library.
The commit also adds dummy implementations for the cipher API.
For Makefiles, enable overriding where includes can come from in order to
enable the parent module to set the include path. This allows the parent
module to specify that its config.h should be used, even when the submodule
when built standalone would use a different config.h.
For CMake, always look in the parent's include folder and our own. List the
parent's include folder first, so that preference is given to parent
include files.
When building Mbed Crypto as a subproject, don't add targets for
libmbedx509 or libmbedtls, as the parent project should build these. The
parent project will define USE_CRYPTO_SUBMODULE variable when using Mbed
Crypto as a submodule, so we can depend on that variable to control whether
or not we build non-crypto libraries.
The new file is conditionally compiled with the new mbedtls
configuration option that Mbed OS would set by default -
`MBEDTLS_PSA_CRYPTO_STORAGE_ITS_C`.
-
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.
Add a magic header to the storage format used with files. The
header is used as an initial check that the data is what we expect,
rather than garbage data.
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.
Mbed TLS version 2.14.0
Resolved conflicts in include/mbedtls/config.h,
tests/scripts/check-files.py, and yotta/create-module.sh by removing yotta.
Resolved conflicts in tests/.jenkins/Jenkinsfile by continuing to run
mbedtls-psa job.
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.
