Programs and tests need to be able to use PSA header files when
USE_CRYPTO_SUBMODULE and MBEDTLS_USE_PSA_CRYPTO are set. Add the crypto
submodule include folder, which contains psa headers, after the main
include folder so that psa headers can be found and crypto submodule
headers don't take precedence over mbedtls headers.
The check-files script contains the strings "TODO" and "todo" in order to
search for files that contain TODO items. So, any check-files script would
need to be excluded from the list of files that gets checked for "TODO".
Normally, the script excludes itself from checks, but with the addition of
the crypto submodule, there is another copy of the script present from the
project root. We must avoid checking check-files scripts for TODO items.
This also helps if you run check-files from another working tree in your
working tree.
So far, make sure we test the following ciphersuites
without any fallback to non-PSA ciphers:
TLS-ECDHE-ECDSA-WITH-AES-128-CCM
TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8
TLS-ECDHE-ECDSA-WITH-AES-256-CCM
TLS-ECDHE-ECDSA-WITH-AES-256-CCM-8
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
The test suites `test_suite_gcm.aes{128,192,256}_en.data` contains
numerous NIST test vectors for AES-*-GCM against which the GCM
API mbedtls_gcm_xxx() is tested.
However, one level higher at the cipher API, no tests exist which
exercise mbedtls_cipher_auth_{encrypt/decrypt}() for GCM ciphers,
although test_suite_cipher.function contains the test auth_crypt_tv
which does precisely that and is already used e.g. in
test_suite_cipher.ccm.
This commit replicates the test vectors from
test_suite_gcm.aes{128,192,256}_en.data in test_suite_cipher.gcm.data
and adds a run of auth_crypt_tv for each of them.
The conversion was mainly done through the sed command line
```
s/gcm_decrypt_and_verify:\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):
\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\)/auth_crypt_tv:
\1:\2:\4:\5:\3:\7:\8:\9/
```
It's better for names in the API to describe the "what" (opaque keys) rather
than the "how" (using PSA), at least since we don't intend to have multiple
function doing the same "what" in different ways in the foreseeable future.
Unfortunately the can_do wrapper does not receive the key context as an
argument, so it cannot check psa_get_key_information(). Later we might want to
change our internal structures to fix this, but for now we'll just restrict
opaque PSA keys to be ECDSA keypairs, as this is the only thing we need for
now. It also simplifies testing a bit (no need to test each key type).
While at it, clarify who's responsible for destroying the underlying key. That
can't be us because some keys cannot be destroyed and we wouldn't know. So
let's leave that up to the caller.
Previously, command line arguments `psk_slot` and `psk_list_slot`
could be used to indicate the PSA key slots that the example
applications should use to store the PSK(s) provided.
This commit changes this approach to use the utility function
`mbedtls_psa_get_free_key_slot()` to obtain free key slots from
the PSA Crypto implementation automatically, so that users only
need to pass boolean flags `psk_opaque` and `psk_list_opaque`
on the command line to enable / disable PSA-based opaque PSKs.
