We keep forgetting to register new test suites in tests/CMakeLists.txt. To
fix this problem once and for all, remove the need for manual registration.
The following test suites were missing:
test_suite_cipher.aria
test_suite_psa_crypto_driver_wrappers
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Expected output generated by OpenSSL (see below) apart from the case
where both password and salt are either NULL or zero length, as OpenSSL
does not support this. For these test cases we have had to use our own
output as that which is expected. Code to generate test cases is as
follows:
#include <openssl/pkcs12.h>
#include <openssl/evp.h>
#include <string.h>
int Keygen_Uni( const char * test_name, unsigned char *pass, int
passlen, unsigned char *salt,
int saltlen, int id, int iter, int n,
unsigned char *out, const EVP_MD
*md_type )
{
size_t index;
printf( "%s\n", test_name );
int ret = PKCS12_key_gen_uni( pass, passlen, salt, saltlen, id, iter,
n, out, md_type );
if( ret != 1 )
{
printf( "Key generation returned %d\n", ret );
}
else
{
for( index = 0; index < n; ++index )
{
printf( "%02x", out[index] );
}
printf( "\n" );
}
printf( "\n" );
}
int main(void)
{
unsigned char out_buf[48];
unsigned char pass[64];
int pass_len;
unsigned char salt[64];
int salt_len;
/* If ID=1, then the pseudorandom bits being produced are to be used
as key material for performing encryption or decryption.
If ID=2, then the pseudorandom bits being produced are to be
used as an IV (Initial Value) for encryption or decryption.
If ID=3, then the pseudorandom bits being produced are
to be used as an integrity key for MACing.
*/
int id = 1;
int iter = 3;
memset( out_buf, 0, sizeof( out_buf ) );
memset( pass, 0, sizeof( pass ) );
memset( salt, 0, sizeof( salt ) );
Keygen_Uni( "Zero length pass and salt", pass, 0, salt, 0, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
Keygen_Uni( "NULL pass and salt", NULL, 0, NULL, 0, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
salt[0] = 0x01;
salt[1] = 0x23;
salt[2] = 0x45;
salt[3] = 0x67;
salt[4] = 0x89;
salt[5] = 0xab;
salt[6] = 0xcd;
salt[7] = 0xef;
Keygen_Uni( "Zero length pass", pass, 0, salt, 8, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
Keygen_Uni( "NULL pass", NULL, 0, salt, 8, id, iter, sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
memset( salt, 0, sizeof( salt ) );
pass[0] = 0x01;
pass[1] = 0x23;
pass[2] = 0x45;
pass[3] = 0x67;
pass[4] = 0x89;
pass[5] = 0xab;
pass[6] = 0xcd;
pass[7] = 0xef;
Keygen_Uni( "Zero length salt", pass, 8, salt, 0, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
Keygen_Uni( "NULL salt", pass, 8, NULL, 0, id, iter, sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
salt[0] = 0x01;
salt[1] = 0x23;
salt[2] = 0x45;
salt[3] = 0x67;
salt[4] = 0x89;
salt[5] = 0xab;
salt[6] = 0xcd;
salt[7] = 0xef;
Keygen_Uni( "Valid pass and salt", pass, 8, salt, 8, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
return 0;
}
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Running the out of source CMake test on Ubuntu 16.04 using more than one
processor (as the CI does) can create a race condition whereby the build
fails to see a generated file, despite that file actually having been
generated. This problem appears to go away with 18.04 or newer, so make
the out of source tests not supported on Ubuntu 16.04
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Can't call mbedtls_cipher_free(&invalid_ctx) in cleanup if
mbedtls_cipher_init(&invalid_ctx) hasn't been called.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add dependencies on built-in hash of signature/
signature verification and asymmetric
encryption/decryption tests. The dependency is
not added for tests based on SHA-256 as SHA-256
is always present when PSA is involved (necessary
to the PSA core) and that way most of PSA signature
/verification tests are still run when PSA hash
operations are accelerated.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
As PSA signatures rely on built-in hash implementations
(cannot take an advantage of an accelerator for the
time being), chose an available built-in hash for
tests exercising a signature key.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Add ECDSA and RSA signature acceleration testing
with signature capabilitites removed from the
Mbed TLS library.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The current testing of the PSA configuration is
based on test code located in the library itself.
Remove this code as we are moving to using a
test library instead.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This commit removes the test_psa_crypto_config_basic
all.sh component that can no longer work without
adapting it to the separately compiled test driver
library. This component is replaced by several
components in the following commits to test various
type of acceleration independently.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
PR #3959 has proven that by adding a prefix
(LIBTESTDRIVER1/libtestdriver1_ in this commit) to
all MBEDTLS/PSA_* and mbedtls/psa_* symbols of a copy
of the Mbed TLS library, we can build a library that
can be linked with the Mbed TLS library.
This commit leverages this to build a PSA test driver
library based on the Mbed TLS library code.
The cryptographic features supported by the test
library are defined by:
. a minimal configuration (in the sense of config.h),
see config_test_driver.h
. PSA_WANT_* and PSA_ACCEL_* defined macros.
The PSA_WANT_* macros have to be the same as the ones
used to build the Mbed TLS library the test driver
library is supposed to be linked to as the PSA_WANT_*
macros are used in the definition of structures and
macros that are shared by the PSA crypto core,
Mbed TLS drivers and the driver test library.
The PSA_ACCEL_* macros are intended to define the
cryptographic features that have to be removed
from the Mbed TLS library and thus supported by the
test library in test scenarios. The PSA_ACCEL_* macros
to build the test library are thus mirrored from the
ones to build the Mbed TLS library by extended the
crypto_config.h: see
crypto_config_test_driver_entension.h.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Rename test driver entry points to
libtestdriver1_<name of the Mbed TLS entry point>.
This aligns with the renaming of all Mbed TLS APIs
for the test driver library (that will be put in place
in the following commits) to avoid name conflicts
when linking it with the Mbed TLS library.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In preparation of the driver test entry points to be
provided by a test driver library, move their prototypes
to tests directory.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Define test driver entry points that provide an alternative
to Mbed TLS driver entry points only when the PSA configuration
is used. Their purpose is only to test the PSA configuration
thus there is no good reason to use them out of this scope.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Align RSA/ECP sign/verify hash dispatch with the
corresponding code of the library. The library
code was modified recently but not the test code
one and these modifications ease the following work.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Add non regression test for invalid usage of
the output buffer in psa_cipher_encrypt().
The output buffer should not be used to pass
the IV to the driver as a local attacker could
be able to control the used IV.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Add non regression test for invalid usage of
the output buffer in psa_cipher_generate_iv().
The output buffer should not be used to pass
the IV to the driver as a local attacker could
be able to control the used IV.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Under gcc11(+) both message and received would cause errors for
potentially being used uninitialised. We fixed many of these issues in
another PR, but this one is only seen under certain configs.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>