The macro always meant 'location', but was mistakenly named 'lifetime'.
Naming it location instead makes much more sense, and drives home the
conceptual differences between location and lifetime values.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Builtin key support for the test driver is always compiled in, and no
longer guarded by MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS.
Parsing the key slot from the buffer by cast and assign instead of memcmp.
For exporting keys, the test driver no longer reaches into the key
identifier in order to check whether a key is builtin, but rather
assumes so based on the key buffer length. It's the driver's
responsibility to be able to detect the key material it returned as part
of the get_builtin_key operation.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
As part of test_psa_crypto_drivers, define a builtin symmetric
plus an ECC key on the test driver lifetime.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
According to the design in psa-driver-interface.md. Compiles without
issue in test_psa_crypto_drivers.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Remove cipher_generate_iv driver entry point as there
is no known use case to delegate this to a driver.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
As per drivers, pass to the Mbed TLS implementation of
the cipher multi-part operation its operation context
and not the PSA operation context.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
For cipher multi-part operations, dispatch based on
the driver identifier even in the case of the
Mbed TLS software implementation (viewed as a driver).
Also use the driver identifier to check that an
cipher operation context is active or not.
This aligns the way hash and cipher multi-part
operations are dispatched.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Change the operation context to the PSA one to be
able to call the software implementation from
the driver wrapper later on.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Change the signature of
psa_driver_wrapper_cipher_encrypt/decrypt_setup to
that of a PSA driver cipher_encrypt/decrypt_setup
entry point.
Change the operation context to the PSA one to be
able to call the software implementation from
the driver wrapper later on.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The hash driver entry points (and consequentially the hash driver core)
are now always compiled on when PSA_CRYPTO_DRIVER_TEST is turned on.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Drivers (both built-in and external) need to declare their context
structures in a way such that they are accessible by the
to-be-autogenerated crypto_driver_contexts.h file. That file lives in
include/psa, which means all builtin driver context structure
declarations also need to live in include/psa.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Apparently there's a goal to make the PSA Crypto core free from
dynamic memory allocations. Therefore, all driver context structures
need to be known at compile time in order for the core to know their
final size.
This change defines & implements for hashing operations how the context
structures get defined.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Change psa_driver_wrapper_sign/verify_hash signature
to that of a sign/verify_hash driver entry point.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Rename and export get_key_buffer_size to be able to call
it from psa_crypto.c to compute the size of buffers to
contain keys generated by an opaque driver without
storage.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Restrict the scope of get_expected_key_size to
generation of key in a secure element or
cryptoprocessor without storage.
For transparent driver, the key buffer size calculation is
for the time being moved to psa_driver_wrapper_generate_key
and will eventually be done by psa_get_key_buffer_size.
Rename the function to get_key_buffer_size to
align its naming with that of psa_get_key_buffer_size.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In case of a secure element or cryptoprocessor with
storage, when generating a key, the key material is
not exported from the secure element or cryptoprocessor
thus there is no need to allocate a buffer in that case.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Change psa_driver_wrapper_export_public_key() signature
to the signature of an export_public_key driver entry point.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In the course of the development of the PSA unified
driver interface, the validate_key entry point for
opaque drivers has been removed and replaced by an
import_key entry point. This commit takes into account
this change of specification.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In key slots containing the description of a key of a
dynamically registered Secure Element (SE), store the
key slot number in a key context as defined in the
PSA driver interface for opaque drivers.
That way transparent key data and slot numbers are
, in a key slot, both stored in a dynamically allocated
buffer. The `data` union in structures of type
psa_key_slot_t to distinguish between the storage of
transparent key data and slot numbers is consequently
not necessary anymore and thus removed.
This alignement of some part of the code dedicated to
dynamically registered SE with the PSA driver interface
specification is done to ease the support of both
dynamically registered and statically defined secure
elements.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
