To test the proper handling of owner identifier as of key
identifiers, add owner identifier(s) to tests having
key identifier(s) as test parameters. Just don't do it for
tests related to tests invalid values of key identifiers
as there is no owner identifier invalid values.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Delete key files based on declaration by test cases and
not based on a hardcoded list of identifiers as in
test_suite_psa_crypto_slot_management.function. This fixes
the fact that in case of error the file associated to the
key identifier PSA_KEY_ID_VENDOR_MAX was not purged
(register_key_smoke_test test function).
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Remove systematic deletion of key file associated to key
identifier 0 as this file is not created under the hood
anymore by the library.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Fix PSA code and unit tests for the unit tests
to pass with key identifiers encoding owner
identifiers.
The changes in PSA code just make the enablement
of key identifiers encoding owner identifiers
platform independent. Previous to this commit,
such key identifiers were used only in the case
of PSA SPM platforms.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
With PSA crypto v1.0.0, a volatile key identifier may
contain a owner identifier but no file is associated
to it. Thus rename the type psa_key_file_id_t to
mbedtls_svc_key_id_t to avoid a direct link with a
file when a key identifier involves an owner
identifier.
The new type name is prefixed by mbedtls to highlight
that the type is specific to Mbed TLS implementation
and not defined in the PSA Cryptography API
specification.
The svc in the type name stands for service as this
is the key identifier type from the point of view of
the service providing the Cryptography services.
The service can be completely provided by the present
library or partially in case of a multi-client service.
As a consequence rename as well:
. MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER to
MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
. PSA_KEY_ID_INIT to MBEDTLS_SVC_KEY_ID_INIT
. PSA_KEY_FILE_GET_KEY_ID to MBEDTLS_SVC_KEY_ID_GET_KEY_ID
. psa_key_file_id_make to mbedtls_svc_key_id_make
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Define always psa_key_id_t as defined in the PSA
Cryptography API specification independently of
whether the MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
configuration file is set or not.
As a consequence, get rid of `psa_app_key_id_t` that is
not needed anymore.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The purpose of this commit and the following is for
psa_key_id_t to always be as defined by the PSA
Cryptography API specification.
Currently psa_key_id_t departs from its specification
definition when MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
configuration flag is set. In that configuration, it is set
to be equal to psa_key_file_id_t which in that configuration
encodes an owner identifier along the key identifier.
Type psa_key_file_id_t was meant to be the key identifier type
used throughout the library code. If
MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER is set it
includes both a key and owner identifier, otherwise it is
equal to psa_key_id_t.
It has not been the key identifier type throughout the
library so far because when the PSA Cryptography
specification was developped the library Doxygen
documentation was used to generate the PSA Cryptography API
specification thus the need to use psa_key_id_t and not
psa_key_file_id_t.
As this constraint does not hold anymore, move
to psa_key_file_id_t as the key identifier type throughout
the library code.
By the way, this commit updates the key identifier
initialization in the tests to be compatible with a
composit key identifier. A psa_key_id_make()
inline function is introduced to initialize key
identifiers (composit ot not) at runtime.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Rename PSA_ECC_CURVE_xxx to PSA_ECC_FAMILY_xxx, also rename
PSA_KEY_TYPE_GET_CURVE to PSA_KEY_TYPE_ECC_GET_FAMILY and rename
psa_ecc_curve_t to psa_ecc_family_t. Old defines are provided in
include/crypto_compat.h for backward compatibility.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Create an include folder dedicated to include files for
tests. With the upcoming work on tests for PSA crypto
drivers the number of includes specific to tests is going
to increase significantly thus create a dedicated folder.
Don't put the include files in the include folder but in
include/test folder. This way test headers can be included
using a test/* path pattern as mbedtls and psa headers
are included using an mbedtls/* and psa/* path pattern.
This makes explicit the scope of the test headers.
Move the existing includes for tests into include/test and
update the code and build systems (make and cmake)
accordingly.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Now that lifetimes have structures and secure element drivers handle
all the lifetimes with a certain location, update driver registration
to take a location as argument rather than a lifetime.
This commit updates the tests.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Define constants for ECC curve families and DH group families. These
constants have 0x0000 in the lower 16 bits of the key type.
Support these constants in the implementation and in the PSA metadata
tests.
Switch the slot management and secure element driver HAL tests to the
new curve encodings. This requires SE driver code to become slightly
more clever when figuring out the bit-size of an imported EC key since
it now needs to take the data size into account.
Switch some documentation to the new encodings.
Remove the macro PSA_ECC_CURVE_BITS which can no longer be implemented.
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')
Add invasive checks that peek at the stored persistent data after some
successful import, generation or destruction operations and after
reinitialization to ensure that the persistent data in storage has the
expected content.
Add a parameter to the p_validate_slot_number method to allow the
driver to modify the persistent data.
With the current structure of the core, the persistent data is already
updated. All it took was adding a way to modify it.
Drivers that allow destroying a key must have a destroy method. This
test bug was previously not caught because of an implementation bug
that lost the error triggered by the missing destroy method.
Add a flow where the key is imported or fake-generated in the secure
element, then call psa_export_public_key and do the software
verification with the public key.
Factor common code of ram_import and ram_fake_generate into a common
auxiliary function.
Reject key types that aren't supported by this test code.
Report the bit size correctly for EC key pairs.
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".
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.
Test the behavior of the getter/setter functions.
Test that psa_get_key_slot_number() reports a slot number for a key in
a secure element, and doesn't report a slot number for a key that is
not in a secure element.
Test that psa_get_key_slot_number() reports the correct slot number
for a key in a secure element.
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).
Run all functions that take a key handle as input with a key that is
in a secure element. All calls are expected to error out one way or
another (not permitted by policy, invalid key type, method not
implemented in the secure element, ...). The goal of this test is to
ensure that nothing bad happens (e.g. invalid pointer dereference).
Run with various key types and algorithms to get good coverage.
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).
