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>
`psa_key_file_id_t` was defined in `crypto_platform.h` and
not `crypto_types.h` even if it wasn't platform dependent
because back when the PSA Crypto Specification was put
together `crypto_types.h` was meant to contain only types
that were intended to make it to the specification. There
is not such constraint anymore thus move the definition
of `psa_key_file_id_t` to crypto_types.h.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
GCC up to 4.x defaults to C89. On our CI, we run the arm-none-eabi-gcc
version from Ubuntu 16.04 on Travis, and that's 4.9, so the gcc-arm
builds started failing on Travis when we introduced a C99 construct in
the configurations that we test on arm on Travis. Other builds, and
Jenkins CI, are not affected because they use GCC 5.x or newer.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Return a name that more clearly returns nonzero=true=good, 0=bad. We'd
normally expect check_xxx to return 0=pass, nonzero=fail so
check_parity was a bad name.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
An early draft of the PSA crypto specification required multipart
operations to keep working after destroying the key. This is no longer
the case: instead, now, operations are guaranteed to fail. Mbed TLS
does not comply yet, and still allows the operation to keep going.
Stop testing Mbed TLS's non-compliant behavior.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Rely on Asan to detect a potential buffer overflow, instead of doing a
manual check. This makes the code simpler and Asan can detect
underflows as well as overflows.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the cleanup code for persistent_key_load_key_from_storage(), we
only attempt to reopen the key so that it will be deleted if it exists
at that point. It's intentional that we do nothing if psa_open_key()
fails here.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If any of the TEST_ASSERT()s that are before the call to
mbedtls_pk_warp_as_opaque() failed, when reaching the exit label
psa_destroy_key() would be called with an uninitialized argument.
Found by Clang.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
I might be wrong, but lcc's optimizer is curious about this,
and I am too: shouldn't we free allocated stuff correctly
before exiting `dh_genprime` in this certain point of code?
Signed-off-by: makise-homura <akemi_homura@kurisa.ch>
Replace server2.crt with server2-sha256.crt which, as the name implies, is
just the SHA-256 version of the same certificate.
Replace server1.crt with cert_sha256.crt which, as the name doesn't imply, is
associated with the same key and just have a slightly different Subject Name,
which doesn't matter in this instance.
The other certificates used in this script (server5.crt and server6.crt) are
already signed with SHA-256.
This change is motivated by the fact that recent versions of GnuTLS (or older
versions with the Debian patches) reject SHA-1 in certificates by default, as
they should. There are options to still accept it (%VERIFY_ALLOW_BROKEN and
%VERIFY_ALLOW_SIGN_WITH_SHA1) but:
- they're not available in all versions that reject SHA-1-signed certs;
- moving to SHA-2 just seems cleaner anyway.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Recent GnuTLS packages on Ubuntu 16.04 have them disabled.
From /usr/share/doc/libgnutls30/changelog.Debian.gz:
gnutls28 (3.4.10-4ubuntu1.5) xenial-security; urgency=medium
* SECURITY UPDATE: Lucky-13 issues
[...]
- debian/patches/CVE-2018-1084x-4.patch: hmac-sha384 and sha256
ciphersuites were removed from defaults in lib/gnutls_priority.c,
tests/priorities.c.
Since we do want to test the ciphersuites, explicitly re-enable them in the
server's priority string. (This is a no-op with versions of GnuTLS where those
are already enabled by default.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Update copyright notices to newly added files since merge of original
PR #3546 "Update copyright notices to use Linux Foundation guidance".
Generated using the same script.
Signed-off-by: Dan Handley <dan.handley@arm.com>
