When building with -Og (specifically Zephyr with
CONFIG_DEBUG_OPTIMIZATIONS=y) one observes the following warning:
'shared_secret' may be used uninitialized [-Werror=maybe-uninitialized]
Fix this by zero initializing 'shared_secret' similar to the issue
addressed in commit 2fab5c960 ("Work around for GCC bug").
Signed-off-by: Moritz Fischer <moritzf@google.com>
- define mbedtls_psa_random_context_t even when MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG
is defined
- define mbedtls_psa_legacy_get_random as pointer to function instead
of #define to make "check_names" test happy.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
The `flags` field in `psa_key_attributes_t` was a general mechanism that
only ever got used for a single flag: to indicate that the `slot_number`
field has been set. We have switched to a dedicated indicator for that, so
we can now remove `flags`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In `psa_key_attributes_t`, keep track of whether `slot_number` has been set
through a dedicated field, rather than using a flag.
This paves the way to removing `flags`, which is not used for anything else.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Access the fields of `psa_key_attributes_t` directly rather than through the
`core` field. This makes the `core` field obsolete.
This commit is fully automated:
```
git ls-files '*.h' '*.c' '*.function' '*.jinja' | xargs perl -l -i -pe '$core = qr/\b(core\b|MBEDTLS_PRIVATE\(core\))/; s/->$core\./->/g; s/&(\w+)\.$core\./&$1./g; s/(\w+)\.$core/$1/g'
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Now that a key slot contains the full `psa_key_attributes_t, the temporary
local variables holding a copy of core attributes read from the slot are no
longer needed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Switch `psa_key_slot_t` to the full `psa_key_attributes_t`, now that this
structure only has psa_core_key_attributes_t`.
To minimize the diff without breaking the build much, temporarily make
`psa_key_attributes_t` contain either the `core` field or all the fields.
This allows both things like `slot->attr.core.type` and `slot->attr.type`
to exist. The build breaks with compilers that don't support anonymous
unions and structs, which are only standard C since C11.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move the `slot_number` field of `psa_key_attributes_t` to
`psa_core_key_attributes_t`. This makes ``psa_core_key_attributes_t` core`
the sole field of `psa_key_attributes_t`. This paves the way to unifying
the two structures.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It means that mbedtls_psa_get_random() goes through the PSA interface
all the times. Fallbacks to CTR_DRBG or HMAC_DRBG are still possible,
but that depends on how the crypto provider is built.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Remove the ability to select a custom public exponent via domain parameters
in RSA key generation. The only way to select a custom public exponent is
now to pass custom production parameters to psa_generate_key_ext().
A subsequent commit will remove domain parameters altogether from the API,
thus this commit does not bother to update the documentation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The setup calls are the only calls to use a key ID.
The key is then copied into the operation object,
all future API calls use the copy instead of the key in the slot.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
The only interaction with key IDs here is in the changed function.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
One can input a key using a key identifier through the two changed functions.
Inputted keys are copied into the operation object.
Any material inputted in byte form is separate to the key slot system.
Outputting a key is threadsafe as per the key loading work.
The verification API is yet to be implemented.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Within setup we create a copy of the key and put it in the operation field.
After setup, we only ever use the new copy,
and do not interact with any key slots.
Therefore we need only register as a reader of the key during setup,
then unregister after we stop accessing the key.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
We copy the key from a slot to the operation object in _start.
_complete and _abort do not access any key slots, instead using
the local copy.
Concurrently using the same operation object is not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
We copy the key from a slot to the operation object in _start.
_complete and _abort do not access any key slots, instead using
the local copy.
Concurrently using the same operation object is not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Within setup we create a copy of the key and put it in the operation field.
After setup, we only ever use the new copy - and do not interact with any key slots.
Therefore we need only register as a reader of the key during setup,
then unregister after we stop accessing the key.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
"Key generation method" was misleading since it also applies to key
derivation. Change "key generation" to "key production", which we aren't
using yet and has roughly the right intuition. Change "method" to
"parameters" which there seems to be a slight preference for. Discussion
thread: https://github.com/Mbed-TLS/mbedtls/pull/8815#discussion_r1486524295
Identifiers renamed:
psa_key_generation_method_t → psa_key_production_parameters_t
psa_key_generation_method_s → psa_key_production_parameters_s
PSA_KEY_GENERATION_METHOD_INIT → PSA_KEY_PRODUCTION_PARAMETERS_INIT
method → params
method_data_length → params_data_length
default_method → default_production_parameters
psa_key_generation_method_is_default → psa_key_production_parameters_are_default
setup_key_generation_method → setup_key_production_parameters
key_generation_method_init → key_production_parameters_init
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the driver wrapper for psa_generate_key() and psa_generate_key_ext():
* Invoke the built-in code if using a non-default method, even if there
might be an accelerator. This is ok because we only support non-default
methods for RSA and we don't support driver-only RSA, therefore a
non-default method will always have built-in code behind it.
* Return NOT_SUPPORTED if trying to use a non-default method with an opaque
driver.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instead of passing the size of the whole structure, just pass the data
length and let the implementation worry about adding the size of the
structure. The intent with passing the structure size was to allow
the client code in a client-server implementation to know nothing
about the structure and just copy the bytes to the server. But that was not
really a useful consideration since the application has to know the
structure layout, so it has to be available in the client implementation's
headers. Passing the method data length makes life simpler for everyone by
not having to worry about possible padding at the end of the structure, and
removes a potential error condition
(method_length < sizeof(psa_key_generation_method_t)).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Implement and unit-test the new functions psa_generate_key_ext() and
psa_key_derivation_output_key_ext(), only for the default method.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This means we can hold the mutex around the call to reserve_free_key_slot
in get_and_lock_key_slot, avoiding inefficient rework.
(Changes to get_and_lock_key_slot are not in scope in this PR)
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Hold the mutex for the entirety of the call.
We need the mutex for the wipe, also hold it for aborting driver transactions as this
may have side effects.
We can't use the macros here as this function returns void.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Hold mutex for the entirety of the call.
We are writing to storage and writing to the slot state here.
If we didn't keep the mutex for the whole duration then we may end up with
another thread seeing that a persistent key is in storage before
our slot is set to FULL; this would be unlinearizable behaviour.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
These all follow a pattern of locking some key slot,
reading its contents, and then unregistering from reading the slot.
psa_copy_key also writes to another slot,
but calls the functions needed to be threadsafe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Between the call to psa_get_and_lock_key_slot and psa_unregister_read
we only read the contents of a slot which we are registered to read,
so no extra mutex taking is needed.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
We do not require linearizability in the case of destroying a key in use.
Using a key and destroying it simultaneously will not cause any issues
as the user will only use the copy of the key in the slot.
Two simulatenous deletion calls to one key cannot interfere, the first caller
sets the slot's state to PENDING_DELETION, the second caller will back off.
Remove outdated comment about one key being in multiple slots, psa_open_key
does not put the key into a new slot.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
