If psa_mac_finish_internal fails (which can only happen due to bad
parameters or hardware problem), the error code was converted to
PSA_ERROR_INVALID_SIGNATURE if the uninitialized stack variable
actual_mac happened to contain the expected MAC. This is a minor bug
but it may be possible to leverage it as part of a longer attack path
in some scenarios.
Reported externally. Found by static analysis.
Rename some macros and functions related to signature which are
changing as part of the addition of psa_sign_message and
psa_verify_message.
perl -i -pe '%t = (
PSA_KEY_USAGE_SIGN => PSA_KEY_USAGE_SIGN_HASH,
PSA_KEY_USAGE_VERIFY => PSA_KEY_USAGE_VERIFY_HASH,
PSA_ASYMMETRIC_SIGNATURE_MAX_SIZE => PSA_SIGNATURE_MAX_SIZE,
PSA_ASYMMETRIC_SIGN_OUTPUT_SIZE => PSA_SIGN_OUTPUT_SIZE,
psa_asymmetric_sign => psa_sign_hash,
psa_asymmetric_verify => psa_verify_hash,
); s/\b(@{[join("|", keys %t)]})\b/$t{$1}/ge' $(git ls-files . ':!:**/crypto_compat.h')
When registering a key in a secure element, go through the transaction
mechanism. This makes the code simpler, at the expense of a few extra
storage operations. Given that registering a key is typically very
rare over the lifetime of a device, this is an acceptable loss.
Drivers must now have a p_validate_slot_number method, otherwise
registering a key is not possible. This reduces the risk that due to a
mistake during the integration of a device, an application might claim
a slot in a way that is not supported by the driver.
If none of the inputs to a key derivation is a
PSA_KEY_DERIVATION_INPUT_SECRET passed with
psa_key_derivation_input_key(), forbid
psa_key_derivation_output_key(). It usually doesn't make sense to
derive a key object if the secret isn't itself a proper key.
Allow a direct input as the SECRET input step in a key derivation, in
addition to allowing DERIVE keys. This makes it easier for
applications to run a key derivation where the "secret" input is
obtained from somewhere else. This makes it possible for the "secret"
input to be empty (keys cannot be empty), which some protocols do (for
example the IV derivation in EAP-TLS).
Conversely, allow a RAW_DATA key as the INFO/LABEL/SALT/SEED input to a key
derivation, in addition to allowing direct inputs. This doesn't
improve security, but removes a step when a personalization parameter
is stored in the key store, and allows this personalization parameter
to remain opaque.
Add test cases that explore step/key-type-and-keyhood combinations.
The signature must have exactly the same length as the key, it can't
be longer. Fix#258
If the signature doesn't have the correct size, that's an invalid
signature, not a problem with an output buffer size. Fix the error code.
Add test cases.
In psa_asymmetric_sign, immediately reject an empty signature buffer.
This can never be right.
Add test cases (one RSA and one ECDSA).
Change the SE HAL mock tests not to use an empty signature buffer.
Zero-length keys are rejected at creation time, so we don't need any
special handling internally.
When exporting a key, we do need to take care of the case where the
output buffer is empty, but this is easy: an empty output buffer is
never valid.
At the end of `psa_hmac_setup_internal()`, the ipad is cleared.
However, the size that was given to clear was `key_len` which is larger
than the size of `ipad`.
In psa_import_key, the key bits value was uninitialized before
calling the secure element driver import function. There is a
potential issue if the driver returns PSA_SUCCESS without setting
the key bits. This shouldn't happen, but shouldn't be discounted
either, so we initialize the key bits to an invalid issue.
Adopt a simple method for tracking whether there was a failure: each
fallible operation sets overall_status, unless overall_status is
already non-successful. Thus in case of multiple failures, the
function always reports whatever failed first. This may not always be
the right thing, but it's simple.
This revealed a bug whereby if the only failure was the call to
psa_destroy_se_key(), i.e. if the driver reported a failure or if the
driver lacked support for destroying keys, psa_destroy_key() would
ignore that failure.
For a key in a secure element, if creating a transaction file fails,
don't touch storage, but close the key in memory. This may not be
right, but it's no wronger than it was before. Tracked in
https://github.com/ARMmbed/mbed-crypto/issues/215
When a key slot is wiped, a copy of the key material may remain in
operations. This is undesirable, but does not violate the safety of
the code. Tracked in https://github.com/ARMmbed/mbed-crypto/issues/86
The methods to import and generate a key in a secure element drivers
were written for an earlier version of the application-side interface.
Now that there is a psa_key_attributes_t structure that combines all
key metadata including its lifetime (location), type, size, policy and
extra type-specific data (domain parameters), pass that to drivers
instead of separate arguments for each piece of metadata. This makes
the interface less cluttered.
Update parameter names and descriptions to follow general conventions.
Document the public-key output on key generation more precisely.
Explain that it is optional in a driver, and when a driver would
implement it. Declare that it is optional in the core, too (which
means that a crypto core might not support drivers for secure elements
that do need this feature).
Update the implementation and the tests accordingly.
Register an existing key in a secure element.
Minimal implementation that doesn't call any driver method and just
lets the application declare whatever it wants.
Pass the key creation method (import/generate/derive/copy) to the
driver methods to allocate or validate a slot number. This allows
drivers to enforce policies such as "this key slot can only be used
for keys generated inside the secure element".
Let psa_start_key_creation know what type of key creation this is. This
will be used at least for key registration in a secure element, which
is a peculiar kind of creation since it uses existing key material.
Allow the application to choose the slot number in a secure element,
rather than always letting the driver choose.
With this commit, any application may request any slot. In an
implementation with isolation, it's up to the service to filter key
creation requests and apply policies to limit which applications can
request which slot.
This function no longer modifies anything, so it doesn't actually
allocate the slot. Now, it just returns the empty key slot, and it's
up to the caller to cause the slot to be in use (or not).
Add a slot_number field to psa_key_attributes_t and getter/setter
functions. Since slot numbers can have the value 0, indicate the
presence of the field via a separate flag.
In psa_get_key_attributes(), report the slot number if the key is in a
secure element.
When creating a key, for now, applications cannot choose a slot
number. A subsequent commit will add this capability in the secure
element HAL.
Add infrastructure for internal, external and dual-use flags, with a
compile-time check (if static_assert is available) to ensure that the
same numerical value doesn't get declared for two different purposes
in crypto_struct.h (external or dual-use) and
psa_crypto_core.h (internal).
mbedtls_ctr_drbg_random can only return up to
MBEDTLS_CTR_DRBG_MAX_REQUEST (normally 1024) bytes at a time. So if
more than that is requested, call mbedtls_ctr_drbg_random in a loop.
When psa_generate_random fails, psa_generate_key_internal frees the
key buffer but a the pointer to the now-freed buffer in the slot. Then
psa_generate_key calls psa_fail_key_creation which sees the pointer
and calls free() again.
This bug was introduced by ff5f0e7221
"Implement atomic-creation psa_{generate,generator_import}_key" which
changed how psa_generate_key() cleans up on errors. I went through the
code and could not find a similar bug in cleanup on an error during
key creation.
Fix#207
Conflict resolution:
* `scripts/config.pl`:
Take the exclusion of `MBEDTLS_PSA_CRYPTO_SE_C` from the API branch.
Take the removal of `MBEDTLS_PSA_CRYPTO_STORAGE_ITS_C` (obsolete) from
the development branch.
* `tests/scripts/all.sh`:
Multiple instances of factoring a sequence of `config.pl` calls into
a mere `config.pl baremetal` in the development branch, and a change in
the composition of `baremetal` in the API branch. In each case, take the
version from development.
* `tests/suites/test_suite_psa_crypto_slot_management.function`:
A function became non-static in development and disappeared in the API
branch. Keep the version from the API branch. Functions need to be
non-static if they're defined but unused in some configurations,
which is not the case for any function in this file at the moment.
* `tests/suites/test_suite_psa_crypto.function`:
Consecutive changes in the two branches, reconciled.
The flag to mark key slots as allocated was introduced to mark slots
that are claimed and in use, but do not have key material yet, at a
time when creating a key used several API functions: allocate a slot,
then progressively set its metadata, and finally create the key
material. Now that all of these steps are combined into a single
API function call, the notion of allocated-but-not-filled slot is no
longer relevant. So remove the corresponding flag.
A slot is occupied iff there is a key in it. (For a key in a secure
element, the key material is not present, but the slot contains the
key metadata.) This key must have a type which is nonzero, so use this
as an indicator that a slot is in use.
There is now a field for the key size in the key slot in memory. Use
it.
This makes psa_get_key_attributes() marginally faster at the expense
of memory that is available anyway in the current memory layout (16
bits for the size, 16 bits for flags). That's not the goal, though:
the goal is to simplify the code, in particular to make it more
uniform between transparent keys (whose size can be recomputed) and
keys in secure elements (whose size cannot be recomputed).
For keys in a secure element, the bit size is now saved by serializing
the type psa_key_bits_t (which is an alias for uint16_t) rather than
size_t.
Change the type of key slots in memory to use
psa_core_key_attributes_t rather than separate fields. The goal is to
simplify some parts of the code. This commit only does the mechanical
replacement, not the substitution.
The bit-field `allocate` is now a flag `PSA_KEY_SLOT_FLAG_ALLOCATED`
in the `flags` field.
Write accessor functions for flags.
Key slots now contain a bit size field which is currently unused.
Subsequent commits will make use of it.
65528 bits is more than any reasonable key until we start supporting
post-quantum cryptography.
This limit is chosen to allow bit-sizes to be stored in 16 bits, with
65535 left to indicate an invalid value. It's a whole number of bytes,
which facilitates some calculations, in particular allowing a key of
exactly PSA_CRYPTO_MAX_STORAGE_SIZE to be created but not one bit
more.
As a resource usage limit, this is arguably too large, but that's out
of scope of the current commit.
Test that key import, generation and derivation reject overly large
sizes.
Move the "core attributes" to a substructure of psa_key_attribute_t.
The motivation is to be able to use the new structure
psa_core_key_attributes_t internally.
For a key in a secure element, save the bit size alongside the slot
number.
This is a quick-and-dirty implementation where the storage format
depends on sizeof(size_t), which is fragile. This should be replaced
by a more robust implementation before going into production.
Add a parameter to the key import method of a secure element driver to
make it report the key size in bits. This is necessary (otherwise the
core has no idea what the bit-size is), and making import report it is
easier than adding a separate method (for other key creation methods,
this information is an input, not an output).
Nothing has been saved to disk yet, but there is stale data in
psa_crypto_transaction. This stale data should not be reused, but do
wipe it to reduce the risk of it mattering somehow in the future.
Introduce a new function psa_get_transparent_key which returns
NOT_SUPPORTED if the key is in a secure element. Use this function in
functions that don't support keys in a secure element.
After this commit, all functions that access a key slot directly via
psa_get_key_slot or psa_get_key_from_slot rather than via
psa_get_transparent_key have at least enough support for secure
elements not to crash or otherwise cause undefined behavior. Lesser
bad behavior such as wrong results or resource leakage is still
possible in error cases.
Pass information via a key attribute structure rather than as separate
parameters to psa_crypto_storage functions. This makes it easier to
maintain the code when the metadata of a key evolves.
This has negligible impact on code size (+4B with "gcc -Os" on x86_64).
Key creation and key destruction for a key in a secure element both
require updating three pieces of data: the key data in the secure
element, the key metadata in internal storage, and the SE driver's
persistent data. Perform these actions in a transaction so that
recovery is possible if the action is interrupted midway.
When creating a key with a lifetime that places it in a secure
element, retrieve the appropriate driver table entry.
This commit doesn't yet achieve behavior: so far the code only
retrieves the driver, it doesn't call the driver.
The psa_tls12_prf_set_seed() and psa_tls12_prf_set_label() functions did
not work on platforms where malloc(0) returns NULL.
It does not affect the TLS use case but these PRFs are used in other
protocols as well and might not be used the same way. For example EAP
uses the TLS PRF with an empty secret. (This would not trigger the bug,
but is a strong indication that it is not safe to assume that certain
inputs to this function are not zero length.)
The conditional block includes the memcpy() call as well to avoid
passing a NULL pointer as a parameter resulting in undefined behaviour.
The current tests are already using zero length label and seed, there is
no need to add new test for this bug.
Secure element support has its own source file, and in addition
requires many hooks in other files. This is a nontrivial amount of
code, so make it optional (but default on).
PSA_ERROR_BAD_STATE means that the function was called on a context in a
bad state.
This error is something that can't happen while only using the PSA API and
therefore a PSA_ERROR_CORRUPTION_DETECTED is a more appropriate error
code.
The macro initialiser might leave bytes in the union unspecified.
Zeroising it in setup makes sure that the behaviour is the same
independently of the initialisation method used.
The TLS 1.2 pseudorandom function does a lot of distinct HMAC operations
with the same key. To save the battery and CPU cycles spent on
calculating the paddings and hashing the inner padding, we keep the
hash context in the status right after the inner padding having been
hashed and clone it as needed.
Technically we could have reused the old one for the new API, but then
we had to set an extra field during setup. The new version works when
all the fields that haven't been set explicitely are zero-initialised.
The specific key derivation input functions support a subset of the
input options and need to check it anyway. Checking it at the top level
is redundant, it brings a very little value and comes with a cost in
code size and maintainability.
This change affects the psa_key_derivation_s structure. With the buffer
removed from the union, it is empty if MBEDTLS_MD_C is not defined.
We can avoid undefined behaviour by adding a new dummy field that is
always present or make the whole union conditional on MBEDTLS_MD_C.
In this latter case the initialiser macro has to depend on MBEDTLS_MD_C
as well. Furthermore the first structure would be either
psa_hkdf_key_derivation_t or psa_tls12_prf_key_derivation_t both of
which are very deep and would make the initialisation macro difficult
to maintain, therefore we go with the first option.
Some key derivation operation contexts (like
psa_tls12_prf_key_derivation_t) directly contain buffers with parts of
the derived key. Erase them safely as part of the abort.
Add the compile time option PSA_PRE_1_0_KEY_DERIVATION. If this is not
turned on, then the function `psa_key_derivation()` is removed.
Most of the tests regarding key derivation haven't been adapted to the
new API yet and some of them have only been adapted partially. When this
new option is turned off, the tests using the old API and test cases
using the old API of partially adapted tests are skipped.
The sole purpose of this option is to make the transition to the new API
smoother. Once the transition is complete it can and should be removed
along with the old API and its implementation.
When MBEDTLS_PSA_INJECT_ENTROPY is used, we now require also defining
MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES. When
MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES is defined, we do not add entropy
sources by default. This includes the NV seed entropy source, which the
PSA entropy injection API is built upon.
The PSA entropy injection feature depends on using NV seed as an entropy
source. Add NV seed as an entropy source for PSA entropy injection.
Fixes e3dbdd8d90 ("Gate entropy injection through a dedicated configuration option")
Now that psa_allocate_key() is no longer a public function, expose
psa_internal_allocate_key_slot() instead, which provides a pointer to
the slot to its caller.
Remove the key creation functions from before the attribute-based API,
i.e. the key creation functions that worked by allocating a slot, then
setting metadata through the handle and finally creating key material.
When importing a private elliptic curve key, require the input to have
exactly the right size. RFC 5915 requires the right size (you aren't
allowed to omit leading zeros). A different buffer size likely means
that something is wrong, e.g. a mismatch between the declared key type
and the actual data.
generate_key is a more classical name. The longer name was only
introduced to avoid confusion with getting a key from a generator,
which is key derivation, but we no longer use the generator
terminology so this reason no longer applies.
perl -i -pe 's/psa_generate_random_key/psa_generate_key/g' $(git ls-files)
“Tampering detected” was misleading because in the real world it can
also arise due to a software bug. “Corruption detected” is neutral and
more precisely reflects what can trigger the error.
perl -i -pe 's/PSA_ERROR_TAMPERING_DETECTED/PSA_ERROR_CORRUPTION_DETECTED/gi' $(git ls-files)
Generators are mostly about key derivation (currently: only about key
derivation). "Generator" is not a commonly used term in cryptography.
So favor "derivation" as terminology. Call a generator a key
derivation operation structure, since it behaves like other multipart
operation structures. Furthermore, the function names are not fully
consistent.
In this commit, I rename the functions to consistently have the prefix
"psa_key_derivation_". I used the following command:
perl -i -pe '%t = (
psa_crypto_generator_t => "psa_key_derivation_operation_t",
psa_crypto_generator_init => "psa_key_derivation_init",
psa_key_derivation_setup => "psa_key_derivation_setup",
psa_key_derivation_input_key => "psa_key_derivation_input_key",
psa_key_derivation_input_bytes => "psa_key_derivation_input_bytes",
psa_key_agreement => "psa_key_derivation_key_agreement",
psa_set_generator_capacity => "psa_key_derivation_set_capacity",
psa_get_generator_capacity => "psa_key_derivation_get_capacity",
psa_generator_read => "psa_key_derivation_output_bytes",
psa_generate_derived_key => "psa_key_derivation_output_key",
psa_generator_abort => "psa_key_derivation_abort",
PSA_CRYPTO_GENERATOR_INIT => "PSA_KEY_DERIVATION_OPERATION_INIT",
PSA_GENERATOR_UNBRIDLED_CAPACITY => "PSA_KEY_DERIVATION_UNLIMITED_CAPACITY",
); s/\b(@{[join("|", keys %t)]})\b/$t{$1}/ge' $(git ls-files)
When importing a private elliptic curve key, require the input to have
exactly the right size. RFC 5915 requires the right size (you aren't
allow to omit leading zeros). A different buffer size likely means
that something is wrong, e.g. a mismatch between the declared key type
and the actual data.
In psa_import_key, change the order of parameters to pass
the pointer where the newly created handle will be stored last.
This is consistent with most other library functions that put inputs
before outputs.
In psa_generate_derived_key, change the order of parameters to pass
the pointer where the newly created handle will be stored last.
This is consistent with most other library functions that put inputs
before outputs.
Only allow creating keys in the application (user) range. Allow
opening keys in the implementation (vendor) range as well.
Compared with what the implementation allowed, which was undocumented:
0 is now allowed; values from 0x40000000 to 0xfffeffff are now
forbidden.
Make it a little easier to add ChaCha20-Poly1305.
This also fixes the error code in case mbedtls_gcm_setkey() fails with
a status that doesn't map to INVALID_ARGUMENT.
In psa_import_key and psa_copy_key, some information comes from the
key data (input buffer or source key) rather than from the attributes:
key size for import, key size and type and domain parameters for copy.
If an unused attribute is nonzero in the attribute structure, check
that it matches the correct value. This protects against application
errors.
Read extra data from the domain parameters in the attribute structure
instead of taking an argument on the function call.
Implement this for RSA key generation, where the public exponent can
be set as a domain parameter.
Add tests that generate RSA keys with various public exponents.
Change psa_get_domain_parameters() and psa_set_domain_parameters() to
access a psa_key_attributes_t structure rather than a key handle.
In psa_get_key_attributes(), treat the RSA public exponent as a domain
parameter and read it out. This is in preparation for removing the
`extra` parameter of psa_generate_key() and setting the RSA public
exponent for key generation via domain parameters.
In this commit, the default public exponent 65537 is not treated
specially, which allows us to verify that test code that should be
calling psa_reset_key_attributes() after retrieving the attributes of
an RSA key is doing so properly (if it wasn't, there would be a memory
leak), even if the test data happens to use an RSA key with the
default public exponent.
Instead of passing a separate parameter for the key size to
psa_generate_key and psa_generator_import_key, set it through the
attributes, like the key type and other metadata.
Implement attribute querying.
Test attribute getters and setters. Use psa_get_key_attributes instead
of the deprecated functions psa_get_key_policy or
psa_get_key_information in most tests.
Implement the new, attribute-based psa_import_key and some basic
functions to access psa_key_attributes_t. Replace
psa_import_key_to_handle by psa_import_key in a few test functions.
This commit does not handle persistence attributes yet.
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.
Merge the Mbed Crypto development branch a little after
mbedcrypto-1.0.0 into the PSA Crypto API 1.0 beta branch a little
after beta 2.
Summary of merge conflicts:
* Some features (psa_copy_key, public key format without
SubjectPublicKeyInfo wrapping) went into both sides, but with a few
improvements on the implementation side. For those, take the
implementation side.
* The key derivation API changed considerably on the API side. This
merge commit generally goes with the updated API except in the tests
where it keeps some aspects of the implementation.
Due to the divergence between the two branches on key derivation and
key agreement, test_suite_psa_crypto does not compile. This will be
resolved in subsequent commits.
MBEDTLS_PSA_HAS_ITS_IO is not really useful since it doesn't actually
enable anything except the entropy seed file support, which only
requires the ITS interface and not a native implemetation. Remove it.
In places where we detect a context is in a bad state and there is no
sensitive data to clear, simply return PSA_ERROR_BAD_STATE and don't
abort on behalf of the application. The application will choose what to
do when it gets a bad state error.
The motivation for this change is that an application should decide what
to do when it misuses the API and encounters a PSA_ERROR_BAD_STATE
error. The library should not attempt to abort on behalf of the
application, as that may not be the correct thing to do in all
circumstances.
Calling psa_*_setup() twice on a MAC, cipher, or hash context should
result in a PSA_ERROR_BAD_STATE error because the operation has already
been set up.
Fixes#10
Check generator validity (i.e. that alg has been initialized) before
allowing reads from the generator or allowing reads of the generator's
capacity.
This aligns our implementation with the documented error code behavior
in our crypto.h and the PSA Crypto API.
PSA spec now defines more generic PSA storage types instead of the ITS
specific ones. This is necessary in order to integrate with
the newer implementation of PSA ITS landing in Mbed OS soon.
Changes include the following:
- psa_status_t replaces psa_its_status_t
- psa_storage_info_t replaces psa_its_info_t
- psa_storage_uid_t replaces psa_its_uid_t
Mbed TLS has deprecated a few module specific error codes in favor of
more general-purpose or cross-module error codes. Use these new error
codes instead of the deprecated error codes.
Remove extra status handling code from psa_import_key_into_slot(). This
helps save a tiny amount of code space, but mainly serves to improve the
readability of the code.
Move pk-using code to inside psa_import_rsa_key(). This aligns the shape
of psa_import_rsa_key() to match that of psa_import_ec_private_key() and
psa_import_ec_public_key().
Remove front matter from our EC key format, to make it just the contents
of an ECPoint as defined by SEC1 section 2.3.3.
As a consequence of the simplification, remove the restriction on not
being able to use an ECDH key with ECDSA. There is no longer any OID
specified when importing a key, so we can't reject importing of an ECDH
key for the purpose of ECDSA based on the OID.
Use the PSA-native status type in psa_key_agreement_ecdh() in
preparation for us calling PSA functions (and not just Mbed TLS
functions) and still being able to return a psa_status_t (without having
to translate it to a Mbed TLS error and then back again).
Remove pkcs-1 and rsaEncryption front matter from RSA public keys. Move
code that was shared between RSA and other key types (like EC keys) to
be used only with non-RSA keys.
New function psa_copy_key().
Conflicts:
* library/psa_crypto.c: trivial conflicts due to consecutive changes.
* tests/suites/test_suite_psa_crypto.data: the same code
was added on both sides, but with a conflict resolution on one side.
* tests/suites/test_suite_psa_crypto_metadata.function: the same code
was added on both sides, but with a conflict resolution on one side.
You can use PSA_ALG_ANY_HASH to build the algorithm value for a
hash-and-sign algorithm in a policy. Then the policy allows usage with
this hash-and-sign family with any hash.
Test that PSA_ALG_ANY_HASH-based policies allow a specific hash, but
not a different hash-and-sign family. Test that PSA_ALG_ANY_HASH is
not valid for operations, only in policies.
Change the key derivation API to take inputs in multiple steps,
instead of a single one-site-fits-poorly function.
Conflicts:
* include/psa/crypto.h: merge independent changes in the documentation
of psa_key_agreement (public_key from the work on public key formats
vs general description and other parameters in the work on key derivation).
* tests/suites/test_suite_psa_crypto.data: update the key agreement
tests from the work on key derivation to the format from the work on
public key formats.
* tests/suites/test_suite_psa_crypto_metadata.function: reconcile the
addition of unrelated ALG_IS_xxx macros
Get rid of "key selection" algorithms (of which there was only one:
raw key selection).
Encode key agreement by combining a raw key agreement with a KDF,
rather than passing the KDF as an argument of a key agreement macro.
Use separate step types for a KDF secret and for the private key in a
key agreement.
Determine which key type is allowed from the step type, independently
of the KDF.
Forbid raw inputs for certain steps. They definitely should be
forbidden for asymmetric keys, which are structured. Also forbid them
for KDF secrets: the secrets are supposed to be keys, even if they're
unstructured.
DSA and static DH need extra domain parameters. Instead of passing these
in with the keys themselves, add get and set functions to set and
retrieve this information about keys.
Remove extra status handling code from psa_import_key_into_slot(). This
helps save a tiny amount of code space, but mainly serves to improve the
readability of the code.
Move pk-using code to inside psa_import_rsa_key(). This aligns the shape
of psa_import_rsa_key() to match that of psa_import_ec_private_key() and
psa_import_ec_public_key().
Remove front matter from our EC key format, to make it just the contents
of an ECPoint as defined by SEC1 section 2.3.3.
As a consequence of the simplification, remove the restriction on not
being able to use an ECDH key with ECDSA. There is no longer any OID
specified when importing a key, so we can't reject importing of an ECDH
key for the purpose of ECDSA based on the OID.
Use the PSA-native status type in psa_key_agreement_ecdh() in
preparation for us calling PSA functions (and not just Mbed TLS
functions) and still being able to return a psa_status_t (without having
to translate it to a Mbed TLS error and then back again).
You can use PSA_ALG_ANY_HASH to build the algorithm value for a
hash-and-sign algorithm in a policy. Then the policy allows usage with
this hash-and-sign family with any hash.
Test that PSA_ALG_ANY_HASH-based policies allow a specific hash, but
not a different hash-and-sign family. Test that PSA_ALG_ANY_HASH is
not valid for operations, only in policies.
Remove pkcs-1 and rsaEncryption front matter from RSA public keys. Move
code that was shared between RSA and other key types (like EC keys) to
be used only with non-RSA keys.
Previously we weren't initializing the freshly allocated ECP keypair
when importing private EC keys. This didn't seem to cause problems, at
least according to our current test coverage, but it's better to ensure
we don't have a partially initialized object by explicitly initializing
the keypair.
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.
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".
There were only 5 categories (now 4). Reduce the category mask from 7
bits to 3.
Combine unformatted, not-necessarily-uniform keys (HMAC, derivation)
with raw data.
Reintroduce a KEY_TYPE_IS_UNSTRUCTURED macro (which used to exist
under the name KEY_TYPE_IS_RAW_DATA macro) for key types that don't
have any structure, including both should-be-uniform keys (such as
block cipher and stream cipher keys) and not-necessarily-uniform
keys (such as HMAC keys and secrets for key derivation).
The last slot in the array was not freed due to an off-by-one error.
Amend the fill_slots test to serve as a non-regression test for this
issue: without this bug fix, it would cause a memory leak.
MBEDTLS_PK_WRITE_C only requires either MBEDTLS_RSA_C or MBEDTLS_ECP_C to be defined.
Added wrappers to handle the cases where only one has been defined.
Moved mbedtls_pk_init to be within the ifdefs, so it's only called if appropriate.
In psa_generator_import_key, if generating a DES or 3DES key, set the
parity bits.
Add tests for deriving a DES key. Also test deriving an AES key while
I'm at it.
In psa_generator_hkdf_read, return BAD_STATE if we're trying to
construct more output than the algorithm allows. This can't happen
through the API due to the capacity limit, but it could potentially
happen in an internal call.
Also add a test case that verifies that we can set up HKDF with its
maximum capacity and read up to the maximum capacity.
New key type PSA_KEY_TYPE_DERIVE. New usage flag PSA_KEY_USAGE_DERIVE.
New function psa_key_derivation.
No key derivation algorithm is implemented yet. The code may not
compile with -Wunused.
Write some unit test code for psa_key_derivation. Most of it cannot be
used yet due to the lack of a key derivation algorithm.
Add an API for byte generators: psa_crypto_generator_t,
PSA_CRYPTO_GENERATOR_INIT, psa_crypto_generator_init,
psa_get_generator_capacity, psa_generator_read,
psa_generator_import_key, psa_generator_abort.
This commit does not yet implement any generator algorithm, it only
provides the framework. This code may not compile with -Wunused.
In psa_mac_setup and psa_hmac_setup_internal, perform a sanity check
on the hash size and the hash block size respectively. These sanity
checks should only trigger on an incompletely or incorrectly
implemented hash function.
Remove the check on the block size in psa_hmac_finish_internal
because at this point it has already been checked and used.
In the common case (key no longer than the block size), psa_hash_setup
was being called twice in succession. With current implementations
this is just a small performance loss, but potentially with
alternative implementations this could have lead to a memory leak.
Call psa_hash_setup in psa_hmac_setup_internal rather than
psa_mac_init. This makes it easier to use psa_hmac_setup_internal on
its own (for the sake of using HMAC internally inside the library).
Create internal functions for HMAC operations. This prepares for two
things: separating crypto-sensitive code from argument decoding and
validation, and using HMAC for other purposes than a MAC inside the
library (e.g. HMAC_DRBG, HKDF).
No intended observable behavior change in this commit.
Although RSASSA-PSS defines its input as a message to be hashed, we
implement a sign-the-hash function. This function can take an input
which isn't a hash, so don't restrict the size of the input, any more
than Mbed TLS does.
Remove a redundant check that hash_length fits in unsigned int for the
sake of Mbed TLS RSA functions.
Test that PSS accepts inputs of various lengths. For PKCS#1 v1.5
signature in raw mode, test the maximum input length.
No common signature algorithm uses a salt (RSA-PKCS#1v1.5, RSA-PSS,
DSA, ECDSA, EdDSA). We don't even take an IV for MAC whereas MAC
algorithms with IV are uncommon but heard of. So remove the salt
parameter from psa_asymmetric_sign and psa_asymmetric_verify.
