Implement `psa_generate_key_custom()` and
`psa_key_derivation_output_key_custom()`. These functions replace
`psa_generate_key_ext()` and `psa_key_derivation_output_key_ext()`.
They have the same functionality, but a slightly different interface:
the `ext` functions use a structure with a flexible array member to pass
variable-length data, while the `custom` functions use a separate parameter.
Keep the `ext` functions for backward compatibility with Mbed TLS 3.6.0.
But make them a thin wrapper around the new `custom` functions.
Duplicate the test code and data. The test cases have to be duplicated
anyway, and the test functions are individually more readable this way.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The #ifdef guard in the get_builtin_key() should be
PSA_CRYPTO_ACCELERATOR_DRIVER_PRESENT to allow for
multiple drivers to be plugged into the wrapper.
Signed-off-by: Antonio de Angelis <antonio.deangelis@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>
All paths in both switch statement lead to a return, therefore the
end block in both of these functions can never be reached. Fix this by
making sure the end block is always called (set status rather than just
return), as its safer for future changes. Found by coverity scan.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Move get_key_buf_size/get_builtin_key out of
the psa wrapper auto generated file
Slot_management.c include the head file instead of the source file
Signed-off-by: Xiaokang Qian <xiaokang.qian@arm.com>
The shipped Visual Studio project files were misconfigured for build
combinations of 64 bit Release builds.
Signed-off-by: Simon Butcher <simon.butcher@arm.com>
CryptGenRandom and lstrlenW are not permitted in Windows Store apps,
meaning apps that use mbedTLS can't ship in the Windows Store.
Instead, use BCryptGenRandom and wcslen, respectively, which are
permitted.
Also make sure conversions between size_t, ULONG, and int are
always done safely; on a 64-bit platform, these types are different
sizes.
Also suppress macro redefinition warning for intsafe.h:
Visual Studio 2010 and earlier generates C4005 when including both
<intsafe.h> and <stdint.h> because a number of <TYPE>_MAX constants
are redefined. This is fixed in later versions of Visual Studio.
The constants are guaranteed to be the same between both files,
however, so we can safely suppress the warning when including
intsafe.h.
Signed-off-by: Kevin Kane <kkane@microsoft.com>
Now that p256-m is officially a production feature and not just an example,
give it a more suitable name.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Transparent drivers don't have this entry points. Other entry points
that are only for opaque drivers are not listed here but only in the
opaque_driver.json file, so this was likely a mistake.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
(Reapplying changes as one commit on top of development post codestyle change instead of rewriting old branch)
Signed-off-by: Aditya Deshpande <aditya.deshpande@arm.com>
