In the MBEDTLS_PK_OPAQUE, have mbedtls_pk_get_psa_attributes() require the
specified usage to be enabled for the specified key. Otherwise the following
call to mbedtls_pk_import_into_psa() is unlikely to result in a key with a
useful policy, so the call to mbedtls_pk_get_psa_attributes() was probably
an error.
Adjust the existing test cases accordingly and add a few negative test
cases.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_pk_get_psa_attributes() actually works without having initialized
the PSA subsystem, because it doesn't call any non-client PSA API functions.
But the function is only useful in conjunction with the PSA API: it's
meant to be followed by importing a key with the resulting attributes. We
don't advertize it to work without an up-and-running PSA subsystem, and
there's no need to test it without an up-and-running PSA subsystem as we
were (accidentally) doing.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In principle the RSA tests shouldn't depend on RSA key generation: they just
need to operate on RSA keys. However they do need some method of creating an
RSA key, and we're currently doing random generation. So depend on what the
test code needs.
Depend on the legacy RSA interface, since driver-only RSA isn't currently
supported in the PK module.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Ideally this and other pk functions would work with
MBEDTLS_PSA_CRYPTO_CLIENT (i.e. whether PSA API functions are implemented
locally or via client-server communication). However, at the moment, some
helper functions are missing when MBEDTLS_PSA_CRYPTO_C is disabled, at least
mbedtls_ecc_group_to_psa(). For the time being, don't provide
mbedtls_pk_get_psa_attributes() when MBEDTLS_PSA_CRYPTO_C is disabled. We
can improve later, looking generally at a group of functions to generalize,
not mixed with delivering new APIs.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When building without PSA crypto functions, disable
MBEDTLS_PSA_CRYPTO_CLIENT as well as MBEDTLS_PSA_CRYPTO_C. With
just MBEDTLS_PSA_CRYPTO_CLIENT, PSA crypto API functions are supposed to
exist at link time but be provided by a third party.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In our tests, we run `tests/scripts/doxygen.sh`, which checks that `doxygen`
runs without warnings after `scripts/config.py realfull`. In this
configuration, alternative implementations such as `MBEDTLS_RSA_ALT` are
enabled, which allows the documentation to contain references to the
`MBEDTLS_xxx_ALT` symbol itself. However, this disables context types that
alternative implementations must define in their header, such as
`mbedtls_rsa_context`. See https://github.com/Mbed-TLS/mbedtls/issues/4518
As a partial fix, allow `tests/scripts/doxygen.sh` to see dummy definitions
of the context type. This way, we can use both `#MBEDTLS_RSA_ALT` and
`#mbedtls_rsa_context` cross-references in our documentation. This is not
ideal, because `doxygen.sh` isn't testing for errors in the documentation of
the affected context types, but it's cheap progress.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit makes the code arguably slightly simpler and fixes the build
with clang -Wimplicit-fallthrough. No intended semantic change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This isn't officially supported, but it's convenient to build the library
this way for quick testing.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add code and unit tests for MBEDTLS_PK_ECxxx in
mbedtls_pk_get_psa_attributes().
This commit only supports built-in ECC (MBEDTLS_ECP_C). A subsequent commit
will handle driver-only ECC.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This avoids a possible gotcha when if the application code reuses an
existing attribute structure.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Change renegotiation test to use G_NEXT_SRV
to avoid problems when sending TLS 1.3
extensions since we exceed the extension
limit in G_SRV.
Signed-off-by: Waleed Elmelegy <waleed.elmelegy@arm.com>
