armmbed / mbed-crypto

The development of Mbed Crypto has moved to Mbed TLS. No updates will be made to the mbed-crypto repository anymore.

The development of Mbed Crypto has moved to Mbed TLS. No updates will be made to the mbed-crypto repository anymore.

Mbed TLS and Mbed Crypto have the same APIs, and the same build system, so most users only need to change the URL to clone or download the library from.

To save build time and possibly avoid system dependencies, you may want to exclude the X.509 and TLS parts of the library by running

scripts/config.py crypto

or

scripts/config.py crypto_full

before building Mbed TLS.

See #374 for more details on this migration.

PSA cryptography API

The cryptography library in Mbed TLS is a reference implementation of the cryptography interface of the Arm Platform Security Architecture (PSA). This is a preview release of Mbed Crypto, provided for evaluation purposes only.

Arm's Platform Security Architecture (PSA) is a holistic set of threat models, security analyses, hardware and firmware architecture specifications, and an open source firmware reference implementation. PSA provides a recipe, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level.

The PSA cryptography API provides access to a set of cryptographic primitives. It has a dual purpose. First, it can be used in a PSA-compliant platform to build services, such as secure boot, secure storage and secure communication. Second, it can also be used independently of other PSA components on any platform.

The design goals of the PSA cryptography API include:

• The API distinguishes caller memory from internal memory, which allows the library to be implemented in an isolated space for additional security. Library calls can be implemented as direct function calls if isolation is not desired, and as remote procedure calls if isolation is desired.
• The structure of internal data is hidden to the application, which allows substituting alternative implementations at build time or run time, for example, in order to take advantage of hardware accelerators.
• All access to the keys happens through handles, which allows support for external cryptoprocessors that is transparent to applications.
• The interface to algorithms is generic, favoring algorithm agility.
• The interface is designed to be easy to use and hard to accidentally misuse.

Arm welcomes feedback on the design of the API. If you think something could be improved, please discuss it on the psa-crypto mailing list. Alternatively, if you prefer to provide your feedback privately, please email us at [email protected]. All feedback received through this email is treated confidentially.

mbed-crypto's Issues

Supply a Docker image for test execution

Description

The test scripts (especially all.sh) have a number of dependencies. Supplying a Dockerfile and helper scripts would make it easier for contributors (running Linux at least) to set up a complete environment for running tests.

Mbed-TLS/mbedtls#2314 provides a good basis for this.

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

ATECC608A example fails to build using IAR

Description

Building the ATECC608A example using IAR fails with:
Error[Pe183]: type of cast must be integral sig_size = PSA_ASYMMETRIC_SIGN_OUTPUT_SIZE(key_type, key_bits, alg),

Full log available here: https://jenkins-internal.mbed.com/job/mbed-crypto-release-ci-testing-2/74/execution/node/2679/log/

Mbed OS at 9974899 Merge pull request #10833 from jamesbeyond/master
The versions of Mbed TLS and Mbed Crypto are those specified in update-crypto.sh in https://github.com/ARMmbed/mbed-os-example-atecc608a

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

psa_asymmetric_encrypt doesn't returns PSA_ERROR_BUFFER_TOO_SMALL

Description

The function psa_asymmetric_encrypt when called with an output_size less than the required size returns PSA_ERROR_INVALID_ARGUMENT instead of PSA_ERROR_BUFFER_TOO_SMALL.

My Sample input set:

1. Key type: PSA_KEY_TYPE_RSA_PUBLIC_KEY
2. RSA 256 public key as input
3. Key usage: PSA_KEY_USAGE_ENCRYPT
4. PSA_ALG_RSA_PKCS1V15_CRYPT
5. Salt: Null, salt size: 0
6. Output buffer size: 120

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

PSA: missing test coverage for BUFFER_TOO_SMALL

Description

We mostly don't test what psa_xxx functions do if they write output to a buffer and that buffer is too small.

Example bug (wrong error code): #199

For all API functions that take an output buffer, there should be at least one test that expects PSA_ERROR_BUFFER_TOO_SMALL with parameters that are correct except for one output buffer which is too small.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Test ASN.1 in Mbed Crypto

Description

ASN.1 is mostly tested through X.509 and TLS. With the separation between Mbed Crypto and Mbed TLS, the ASN.1 modules end up in Mbed Crypto but they're barely tested there. It would be useful to test them.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

psa_key_agreement API limitation

Description

psa_key_agreement API doesn't have salt and label parameters.
It calls psa_key_derivation_internal with NULL as a salt and label.

Lets add four following parameters to psa_key_agreement API:
const uint8_t *salt, size_t salt_length,
const uint8_t *label, size_t label_length
And use them for psa_key_derivation_internal function call.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Test "nonexistent" in psa its suite causes NULL p_data to propagate to fwrite in psa_its_set

Description

Mbed Crypto 1.1.1
Toolchain GCC 9.1.1
Target Linux 5.1.20 x86_64 (Fedora 30 5.1.20-300)

Test
https://github.com/ARMmbed/mbed-crypto/blob/mbedcrypto-1.1.1/tests/suites/test_suite_psa_its.function#L167
will propagate NULL p_data to fwrite
https://github.com/ARMmbed/mbed-crypto/blob/mbedcrypto-1.1.1/library/psa_its_file.c#L212
which must not be NULL. This is reproduced with appending sanitizer flags -fsanitize=address,undefined flags to CFLAGS in library/Makefile and tests/Makefile and building and running the tests with sanitizers enabled.

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

mbedtls_platform_setup and psa_crypto_init

Description

Work out how mbedtls_platform_setup() and psa_crypto_init() should interact.

See discussion at ARMmbed/mbed-os-example-tls#232 (comment)

Some scenarios to consider:

• As an application writer, I'm using Mbed TLS for TLS and I don't care about Mbed Crypto.
• As an application writer, I'm using the PSA crypto API and I don't care about how it's implemented.
• As an application writer, I'm combining one module that uses Mbed TLS and one that uses PSA crypto.
• … and my application is multithreaded.
• As an operating system integrator, I provide my own version of mbedtls_platform_setup.
• As a device integrator, I'm using Mbed OS and I don't care what various bits may be doing under the hood.

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

When used as a submodule, PSA source files pick up the wrong config.h

Description

When Mbed Crypto is used as a submodule in Mbed TLS, only the config.h of Mbed TLS should be used. But PSA source files use the ones in the submodule.

Steps to reproduce:

git clone https://github.com/ARMmbed/mbedtls
cd mbedtls
git submodule update
rm crypto/include/mbedtls/config.h
make

Expected behavior: since Mbed Crypto is used as a submodule in Mbed TLS, the config.h file under crypto should not be used.

Actual behavior:

…
  CC    psa_crypto.c
In file included from ../include/psa/crypto.h:25:0,
                 from psa_crypto.c:31:
../include/psa/crypto_platform.h:41:31: fatal error: ../mbedtls/config.h: No such file or directory
compilation terminated.
Makefile:146: recipe for target 'psa_crypto.o' failed
make[2]: *** [psa_crypto.o] Error 1
Makefile:152: recipe for target 'libmbedcrypto.a' failed
make[1]: *** [libmbedcrypto.a] Error 2
Makefile:19: recipe for target 'lib' failed
make: *** [lib] Error 2

Validation: to make sure that the wrong config.h is not used, we should do a build where its contents are replaced by something that will cause a build error, e.g. #barf.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

psa_cipher_update with AES-CTR fails when used in-place for a non-block-aligned size

Description

Expected behavior: a call to psa_cipher_update on AES-CTR used with the nominal sequence of operations succeeds to encrypt 36 bytes.

Actual behavior: psa_cipher_update returns PSA_ERROR_INVALID_ARGUMENT.

Reported internally by @davidsaada, encountered with mbedcrypto-1.0.0d2 on Mbed OS. I reproduced it with the latest development (72f40c6) on Linux.

#include <psa/crypto.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int encrypt_test()
{
    const int enc_block_size = 16;

    psa_key_handle_t enc_handle;
    psa_cipher_operation_t operation;
    char *data = "Data value of key 3 is the following";
    size_t data_size = strlen(data);
    unsigned char encrypt_key[enc_block_size];
    unsigned char iv_buf[enc_block_size];
    psa_key_policy_t policy = PSA_KEY_POLICY_INIT;
    size_t out_len;

    memset(encrypt_key, 0xa5, enc_block_size);
    memset(iv_buf, 0, enc_block_size);
    iv_buf[0] = 1;

    psa_status_t psa_ret = psa_crypto_init();
    if (psa_ret != PSA_SUCCESS) {
        goto fail;
    }

    psa_ret = psa_allocate_key(&enc_handle);
    if (psa_ret != PSA_SUCCESS) {
        goto fail;
    }

    psa_key_policy_set_usage(&policy, PSA_KEY_USAGE_ENCRYPT, PSA_ALG_CTR);
    psa_ret = psa_set_key_policy(enc_handle, &policy);
    if (psa_ret != PSA_SUCCESS) {
        goto fail;
    }

    psa_ret = psa_import_key(enc_handle, PSA_KEY_TYPE_AES, encrypt_key, enc_block_size);
    if (psa_ret != PSA_SUCCESS) {
        goto fail;
    }

    memset(&operation, 0, sizeof(operation));
    psa_ret = psa_cipher_encrypt_setup(&operation, enc_handle, PSA_ALG_CTR);
    if (psa_ret != PSA_SUCCESS) {
        goto fail;
    }

    psa_ret = psa_cipher_set_iv(&operation, iv_buf, enc_block_size);
    if (psa_ret != PSA_SUCCESS) {
        goto fail;
    }

    psa_ret = psa_cipher_update(&operation, (const unsigned char *) data, data_size, (unsigned char *) data, data_size, &out_len);
    if (psa_ret != PSA_SUCCESS) {
        goto fail;
    }

    psa_cipher_abort(&operation);
    psa_destroy_key(enc_handle);
    return PSA_SUCCESS;

fail:
    printf("Operation failed. err %d\n", psa_ret);
    return psa_ret;
}


int main(void)
{
    return !!encrypt_test();
}

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

psa_generate_random fails on large requests

Description

Bug: psa_generate_random fails with the error PSA_ERROR_NOT_SUPPORTED if asked to generate more than 1024 bytes in one call. This also affects psa_generate_key when generating symmetric keys.

More precisely, the limit is MBEDTLS_CTR_DRBG_MAX_REQUEST. This limit can be configured in config.h, but there is little reason to reduce it since it won't reduce the memory consumption of the library.

Workaround: call psa_generate_random in a loop, retrieving at most 1024 bytes per call.

Affected versions: all versions of Mbed Crypto until this is fixed.

Impact: applications should check the return value of psa_generate_random, so the bug should at least be detectable. But an application that does not check the return value and assumes that psa_generate_random always succeeds would silently operate with non-random data. For psa_generate_key, there is probably no real-world impact since 1024 bytes is well above the usual size of symmetric keys.

Cause: psa_generate_random calls mbedtls_ctr_drbg_random which is unwilling to return more than MBEDTLS_CTR_DRBG_MAX_REQUEST in a single call.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

psa_key_agreement doesn't check the generator is not active

Description

API psa_key_agreement does not check that the generator object is not active.
I think a check similar to the check in psa_key_derivation is missing:

if( generator->alg != 0 )
    return( PSA_ERROR_BAD_STATE );

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Zero length keys not supported when generating persistent keys

Description

psa_save_generated_persistent_key does not support zero-length keys on all platforms. This has been missed due to not having a test for zero-length raw keys.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Maintenance: Use `offsetof()` instead of manual offset calculation

Description

It's fragile to manually calculate offsets within structs like so, which the current code does in psa_parse_key_data_from_storage().

GET_UINT32_LE(policy->alg2, storage_format->policy, 2 * sizeof( uint32_t ));

We should instead look into using offsetof(). This will make the library more portable and easier to maintain. it's not likely to be "more correct", since we have tests that would catch these types of padding issues in this instance.

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

Make PSA entropy injection easier to use

Description

Currently, a user must define their own NV seed read and write callbacks when they enable PSA entropy injection. Also, they must ensure that their NV seed read and write callbacks are compatible with how the seed is written from Mbed Crypto. This is bad coupling and makes the feature too hard to use.

Instead, provide default, Mbed-Crypto-compatible NV seed read and write callbacks, automatically register them with the Mbed TLS NV Seed system, and error if any other NV Seed configuration options are set (as only one set of NV Seed callbacks can be present in any given system).

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

PSA_CRYPTO_GENERATOR_INIT does not initialize struct psa_crypto_generator_s completely

Description

Mbed Crypto 1.1.1
Toolchain GCC 9.1.1 with CompCert 3.5
Target Linux 5.1.20 x86_64 (Fedora 30 5.1.20-300)

Related: AbsInt/CompCert#312

When compiling tag mbedcrypto-1.1.1 with CompCert 3.5, host and target are Fedora 30 5.1.20-300 x86_64, toolchain is taken from GCC 9.1.1, using

make test CC=ccomp CFLAGS='-O1 -fbitfields -fstruct-passing -finline-asm' WARNING_CFLAGS= DEBUG=1 -j

The library's test suite test_suite_psa_crypto has two tests fail:

PSA key derivation: HKDF SHA-256, RFC5869 #1, output 42+0 ......... FAILED
  ( ( psa_key_derivation( &generator, handle, alg, salt->x, salt->len, label->x, label->len, requested_capacity ) ) ) == ( ((psa_status_t)0) )
  at line 4248, suites/test_suite_psa_crypto.function

and

PSA key derivation: HKDF SHA-256, exercise HKDF-SHA-256 ........... FAILED
  ( ( psa_key_derivation( &generator, handle, alg, label, label_length, seed, seed_length, sizeof( output ) ) ) ) == ( ((psa_status_t)0) )
  at line 532, suites/test_suite_psa_crypto.function

Both tests pass on GCC and clang because it appears that those simply zero out memory of the whole structure, but on CompCert, where only select fields are initialized, code will read uninitialized memory when it accesses some fields of hkdf or tls12_prf.
https://github.com/ARMmbed/mbed-crypto/blob/mbedcrypto-1.1.1/tests/suites/test_suite_psa_crypto.function#L523
https://github.com/ARMmbed/mbed-crypto/blob/mbedcrypto-1.1.1/tests/suites/test_suite_psa_crypto.function#L4216

Standard reference: ISO C 99, section 6.7.8, paragraph 17:
Each brace-enclosed initializer list has an associated current object. When no designations are present, subobjects of the current object are initialized in order according to the type of the current object: array elements in increasing subscript order, structure members in declaration order, and the first named member of a union.

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

psa_key_derivation_input_bytes with LABEL or SALT

Description

Version: psa-crypto-api-1.0-beta

API: psa_key_derivation_input_bytes with label/seed as step

Method:
Calling key derivation setup with alg such that PSA_ALG_IS_KEY_DERIVATION is true.
Then, calling psa_key_derivation_input_bytes with step as PSA_KEY_DERIVATION_INPUT_LABEL.
The return value is expected to be PSA_SUCCESS but the actual return value is PSA_ERROR_INVALID_ARGUMENT.
The same case with step as PSA_KEY_DERIVATION_INPUT_SEED

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Test that PSA headers work in C++

Description

We test that Mbed TLS headers are compatible with C++. We only test include/mbedtls/*.h. We should also test include/psa/*.h.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Implement separate-inputs key derivation and key agreement

Implement the changes to the key derivation and key agreement API made in PSA Crypto API 1.0 beta1:

• Key derivation takes one input at a time, with new functions psa_key_derivation_setup, psa_key_derivation_input_bytes, psa_key_derivation_input_key, psa_set_generator_capacity.
• Key agreement uses separate functions to chain a key derivation (changed prototype of psa_key_agreement) or not (new function psa_key_agreement_raw_shared_secret).

Draft (internal link): https://github.com/ARMmbed/mbedtls-psa/pull/244

psa_mac_compute doesn't have PSA_ERROR_BUFFER_TOO_SMALL error code

Description

Version: psa-crypto-api-1.0-beta
API: psa_mac_compute

One of the parameters of this function is mac_size. The specification doesn't mention about returning PSA_ERROR_BUFFER_TOO_SMALL when the mac_size is less than the actual required size.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Exclude third party symbols from the library.

Description

Add an MBEDTLS_NOEXPORT sort of mechanism that both check-names.sh and the linker should understand to exclude third party symbols from the library.

Mbed-TLS/mbedtls@176587f#r241732324

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Unable to import an RSA keypair with P=Q=0

Description

Hello everyone,
First of all sorry for all the mistake(s) that you will find in the following part, but english is not my first language.

I'm currenlty trying to do a RSA sign with the function RSA_PKCS1v15_Sign and it seem that i came accross an issue in psa_import_key.
To be more accurate, this issue is in the function pk_parse_key_pkcs1_der. (see at the end for the complete path to this function)

After all imports (in my case i have only the parameters n, d and e), the function call mbedtls_rsa_complete. This function is trying to find p and q. Until here nothing wrong.

And now for the strange part :), in mbedtls_rsa_deduce_primes (the function call by mbedtls_rsa_complete) the first line is a check:
if( P == NULL || Q == NULL || P->p != NULL || Q->p != NULL )
but just before (in pk_parse_key_pkcs1_der), the mbedtls_rsa_import_raw is initialising P->p and Q->p to something not NULL, so i got MBEDTLS_ERR_MPI_BAD_INPUT_DATA everytime.

And here is my issue.

Maybe my code is wrong, i'm pretty confident about it, but i'm open to every sugestions and comments...

path:
RSA_PKCS1v15_Sign
->psa_import_key
->psa_import_key_into_slot
->psa_import_rsa_key
->mbedtls_pk_parse_key
->pk_parse_key_pkcs1_der
->mbedtls_rsa_complete
->mbedtls_rsa_deduce_primes

Have a good day,
Best regards,

userMF

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Doxygen can't seem to link to MBEDTLS_PARAM_FAILED

Description

In #187, in include/mbedtls/config.h, we changed #MBEDTLS_PARAM_FAILED to MBEDTLS_PARAM_FAILED to get doxygen.sh to pass. Given that this link works in Mbed TLS, it's odd that it doesn't also work in Mbed Crypto. Why not?

We've reviewed the doxygen/mbedtls.doxyfile and include/mbedtls/config.h in both repos and don't yet see why this link should work in one but not the other. We should be able to link to #MBEDTLS_PARAM_FAILED in Mbed Crypto.

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

different behavior in `calloc` on different libraries when trying to allocate 0 bytes

Description

man calloc describes the following:

If nmemb or size is 0, then calloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().

This causes different behavior when calling the library wiht 0 bytes to allocate.
For example:
a call to psa_import_key() will result in an error when slen is 0 because in prepare_raw_data_slotoreoare_data_slot() we will have:

    /* Allocate memory for the key */
    raw->bytes = PSA_BITS_TO_BYTES( bits );
    raw->data = mbedtls_calloc( 1, raw->bytes  );
    if( raw->data == NULL )
    {
        raw->bytes = 0;
        return( PSA_ERROR_INSUFFICIENT_MEMORY );
    }

and a call to psa_key_derivation() with the same empty key could result in a failure because in psa_generator_tls12_prf_setup():

   tls12_prf->key = mbedtls_calloc( 1, key_len + 1 );
    if( tls12_prf->key == NULL )
        return( PSA_ERROR_INSUFFICIENT_MEMORY );

If using memory_buffer_alloc feature, the calloc calls would return NULL and not a valid pointer because:

    if( n == 0 || size == 0 || len / n != size )
        return( NULL );

There are several ways to fix this:

1. Don't call mbedtls_calloc() for a zero length -> This could cause crashes in the library for some cases where the data cannot be zero lengthed
2. Always add one more to the size to allocate -> This adds some additional RAM. One could argue this is insignificant.
3. Have the memory_buffer_alloc() return a 4 byte aligned pointer for zero length allocation request. This perhaps will fix the specific use case, but on other platforms, that have some calloc function that returns NULL, as it's allowed,the error will remain.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Document the stability of PSA interfaces

Description

As the PSA interfaces are stabilizing, we should document what we'll maintain backward compatibility for and what we won't.

• Public APIs that haven't completely stabilized yet, but we'll provide a short transition period if we make changes: include/crypto/crypto.h, include/crypto/crypto_types.h, include/crypto/crypto_values.h (only the macros that have Doxygen documentation), include/crypto/crypto_extra.h. We should also note that even if the interfaces stabilize, that doesn't mean that the implementation is production-quality yet.
• Internal definitions that are platform-dependent and may change without notice: include/crypto/crypto_platform.h, include/crypto/crypto_struct.h
• File storage for persistent keys
• Driver HAL: not stable yet.

Where to document it: in the comment at the top of each header, in README.md, in the Doxygen documentation, …

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Implement psa_copy_key

Implement the new function psa_copy_key.

Test error cases of PK parse

Description

A code coverage review shows some test gaps in mbedtls_pk_parse_subpubkey: many error cases are never hit by the Mbed TLS, and many more are only hit by X.509 and TLS tests but not by crypto unit tests. So in Mbed Crypto, many error cases are not tested. Likewise, mbedtls_pem_read_buffer lacks a unit test for BASE64_INVALID_CHARACTER.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Missing test coverage for ciphers not requiring IVs

Description

Because we don't have any cipher modes that don't require an IV (e.g. RC4), we can't test this area of code properly.

psa_status_t psa_cipher_set_iv( psa_cipher_operation_t *operation,
                                const unsigned char *iv,
                                size_t iv_length )
{
    psa_status_t status;
    int ret;
    if( operation->iv_set || ! operation->iv_required )
    {
        status = PSA_ERROR_BAD_STATE;
        goto exit;
    }
/* ... */

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

Mklink issue when building on Windows

Description

When building with CMake on a Win 10 machine, creation of links using mklink (see CMakeLists.txt) doesn't always work.

This is a similar issue to Mbed-TLS/mbedtls#1496 reported for mbed-tls.

The root cause is: cmd.exe does allays only accept \ as directory separator, but file(TO_NATIVE_PATH ) is target host system specific and under some conditions will return PATHs with /.
In addition on some of our machines CMAKE_UNIX_HOST is set while ln is not available.
So I suggest checking if CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows" is true and to use string manipulation to convert directory separators and drive letters (i.e. /c/foo/bar -> c:\foo\bar and /cygdrive/c/foo/bar -> c:\foo\bar).

Howto reproduce:
Assumptions:

1. arm-none-eabi-gcc and gnumake is available on the PATH.
   Steps:
2. Start menu -> run -> cmd.exe
3. cd <mbed-crypto path>
4. mkdir build; cd build
5. cmake -DCMAKE_C_COMPILER=arm-none-eabi-gcc -DCMAKE_C_COMPILER_WORKS=True -G"Unix Makefiles" ..

Result:

C:\work\mbed-crypto\build>cmake -DCMAKE_C_COMPILER=arm-none-eabi-gcc -DCMAKE_C_COMPILER_WORKS=True -G"Unix Makefiles" ..
-- The C compiler identification is GNU 6.3.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting C compile features
-- Detecting C compile features - failed
-- Found PythonInterp: C:/Program Files/Python36/python.exe (found version "3.6.1")
-- Could NOT find Perl (missing: PERL_EXECUTABLE)
CMake Error at CMakeLists.txt:106 (message):
  Could not create symbolic link for: C:/work/mbed-crypto/include/mbedtls -->
  Invalid switch - "work".

Call Stack (most recent call first):
  include/CMakeLists.txt:20 (link_to_source)


-- Configuring incomplete, errors occurred!
See also "C:/work/mbed-crypto/build/CMakeFiles/CMakeOutput.log".
See also "C:/work/mbed-crypto/build/CMakeFiles/CMakeError.log".

C:\work\mbed-crypto\build>

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Spurious files and make rules in tests/data_files

Description

Out of the box as of Mbed Crypto 1.1.1:

$ cd tests/data_files
$ mbedtls_cert_req output_file=test-ca.req.sha256 filename=test-ca.key password=PolarSSLTest subject_name="C=NL,O=PolarSSL,CN=PolarSSL Test CA" md=SHA256
/bin/sh: 1: mbedtls_cert_req: not found
Makefile:47: recipe for target 'test-ca.req.sha256' failed
make: *** [test-ca.req.sha256] Error 127

It isn't a big deal, but we should clean up the things in data_files that require X509.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Test RNG failure in PSA

Description

We don't test the impact of RNG failure through the PSA API. This needs some infrastructure since normally the RNG never fails unless the entropy sources fail, and in that case the library initialization fails. For example, we don't have a way to cause the RNG to fail that could let us write a non-regression test for #207.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

psa_generate_key for a symmetric key of ≥1025 bytes causes a double free

Description

Steps to reproduce: on the psa-api-1.0-beta branch, call psa_generate_key() with any symmetric key type that allows large key sizes (e.g. PSA_KEY_TYPE_RAW, PSA_KEY_TYPE_HMAC, PSA_KEY_TYPE_DERIVE) and a size of 8200 bits or more (>1024 bytes). This causes a double free inside psa_generate_key.

Impacted product: This only affects the psa-api-1.0-branch, the offending code has never been merged to the Mbed Crypto development branch and thus this does not affect any Mbed Crypto release. The bug was introduced in #263, merged on 2019-05-03, earliest tag psa-api-1.0-beta3.

Impact: this is a double free(), so it can lead to arbitrary code execution. However, the exploitability is low, possibly nonexistent in single-threaded applications with many free() implementations, because there is only a very short window of time between the two free() calls, with no other call to malloc or free in between in the same thread.

Affected applications: The bug is triggered by a failure of psa_generate_random during key generation for a symmetric key (e.g. HMAC or derive, but not asymmetric keys such as RSA). This can happen in two ways:

• If the key size is 1025 bytes or more, due to #206.
• If the CTR_DRBG generator needs reseeding and the entropy source(s) fail, causing reseeding to fail. By default, the reseed interval for CTR_DRBG in Mbed Crypto is 10000 bytes. (Note that this is the total number of bytes generated internally, which is typically larger than the total number of bytes requested because CTR_DRBG generates a whole new block even when less than one block is requested.)

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

psa_asymmetric_verify failed to verify key pair

mbedtls_pk_verify for PSA failed to verify the key pair below.

Using EC key pair and hash below, mbedtls_pk_verify call to psa_asymmetric_verify which return MBEDTLS_ERR_ECP_VERIFY_FAILED.

const uint8_t der_private_ec_key[138] = \{ 0x30, 0x81, 0x87, 0x02, 0x01, 0x00, 0x30, 0x13, 0x06, 0x07, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x02, 0x01, 0x06, 0x08, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x03, 0x01, 0x07, 0x04, 0x6d, 0x30, 0x6b, 0x02, 0x01, 0x01, 0x04, 0x20, 0x00, 0x03, 0xe1, 0xcc, 0x78, 0xee, 0x88, 0xe6, 0x00, 0x3c, 0x78, 0x60, 0xb4, 0x4d, 0x2e, 0x33, 0x99, 0x3b, 0x5e, 0x36, 0x55, 0xfa, 0xdf, 0x24, 0xe2, 0x33, 0xed, 0xf5, 0x2f, 0x13, 0x76, 0xe9, 0xa1, 0x44, 0x03, 0x42, 0x00, 0x04, 0xac, 0x36, 0x73, 0x98, 0x49, 0xb8, 0xe6, 0x99, 0xe9, 0x6a, 0xcd, 0xc8, 0x80, 0x50, 0xc4, 0xda, 0xeb, 0xd4, 0x09, 0xa0, 0xcf, 0x3f, 0x33, 0x46, 0x52, 0xa3, 0x0d, 0x29, 0x7a, 0x14, 0x6e, 0x17, 0x2a, 0x69, 0x19, 0x2e, 0xaf, 0x0a, 0x4e, 0xcf, 0xca, 0x5a, 0x10, 0xca, 0x67, 0x65, 0x57, 0x11, 0xd3, 0x48, 0x8c, 0xfb, 0xfc, 0x18, 0xf7, 0x3c, 0x72, 0x51, 0x02, 0x4b, 0x3d, 0x05, 0x9a, 0xe7 };
const uint8_t der_public_ec_key[91] = \{ 0x30, 0x59, 0x30, 0x13, 0x06, 0x07, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x02, 0x01, 0x06, 0x08, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x03, 0x01, 0x07, 0x03, 0x42, 0x00, 0x04, 0xac, 0x36, 0x73, 0x98, 0x49, 0xb8, 0xe6, 0x99, 0xe9, 0x6a, 0xcd, 0xc8, 0x80, 0x50, 0xc4, 0xda, 0xeb, 0xd4, 0x09, 0xa0, 0xcf, 0x3f, 0x33, 0x46, 0x52, 0xa3, 0x0d, 0x29, 0x7a, 0x14, 0x6e, 0x17, 0x2a, 0x69, 0x19, 0x2e, 0xaf, 0x0a, 0x4e, 0xcf, 0xca, 0x5a, 0x10, 0xca, 0x67, 0x65, 0x57, 0x11, 0xd3, 0x48, 0x8c, 0xfb, 0xfc, 0x18, 0xf7, 0x3c, 0x72, 0x51, 0x02, 0x4b, 0x3d, 0x05, 0x9a, 0xe7 };
uint8_t hash[32] = { 0xa0,0x63,0xdf,0x83,0xa8,0xc2,0x8a,0x49,0xda,0xf4,0xae,0xba,0x0e,0x29,0xee,0x7b,0x21,0x77,0xe8,0x51,0x10,0x72,0x94,0x4c,0x3d,0x29,0x9c,0xf7,0x7d,0xc8,0x3e,0x7a };

The non-PSA version succeeds to verify the same key pair.
Tested using mbedtls version 2.17.0.

Add tests for abort functions

Description

We are missing targeted tests that ensure that psa_*_abort() behaves properly, as raised in #58 (comment)

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Change unsigned char to uint8_t in the API.

Description

Release 1.0 beta3 of the API Specification states that "A buffer parameter always has the type uint8_t * or const uint8_t *..." However there are six functions in the document

psa_cipher_generate_iv
psa_cipher_set_iv
psa_cipher_update
psa_aead_generate_nonce
psa_aead_set_nonce
psa_aead_update

that specify the buffer type as unsigned char, which is effectively equivalent to uint8_t, but it's good to be consistent.

Issue request type

[ ] Question
[ ] Enhancement
[x ] Bug

Double-underscore in macro names is not valid in C++

Description

Mbed Crypto headers define an identifier that is reserved in C++. Specifically PSA__ALG_AEAD_WITH_DEFAULT_TAG_LENGTH__CASE in include/psa/crypto_values.h. C++ reserves double underscores.

Note that it isn't enough to just change the double underscore to a single underscore: test_psa_constant_names.py picks up macros PSA_ALG_.* and would need to skip this one somehow. See https://github.com/ARMmbed/mbedtls-psa/pull/258 (private link).

Acceptance criteria:

• Add a check for double underscores. To check-names.sh, presumably. It already checks for trailing underscores, for whatever reason.
• Obviously, make the check pass without breaking anything else.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Test ARIA through the cipher interface

Description

ARIA is tested via the mbedtls_aria_xxx functions in test_suite_aria, but not through the mbedtls_ccm_xxx, mbedtls_gcm_xxx or mbedtls_cipher_xxx functions. There should be a test_suite_cipher.aria.data for non-authenticated modes, and test_suite_{ccm,gcm}.aria.data and entries in test_suite_cipher.{ccm,gcm}.data for authenticated modes, like what exists for AES and CAMELLIA.

I'm filing this as enhancement because the risk of an undetected bug here is low, considering that this interface is also tested indirectly in mbedtls via compat.sh.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Implement and test BAD_STATE in multipart operation setup

Description

Setup functions for multipart operations should return PSA_ERROR_BAD_STATE if the operation structure is already in use. #11 updates the documentation. This issue is for implementing this and adding corresponding negative tests.

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

Broken link to the specification (or documentation) in README.md

Description

In the library's README.md contains a “Documentation” section with links to PSA_Crypto_API_Overview.pdf and PSA_Crypto_API_Reference.pdf which are not up-to-date, and a link to “HTML format” which AFAIK has always been broken. You can get the HTML in your own copy by running make apidoc.

Goal:

• The links must not be broken on Github.
• Differentiate the specification from the library documentation (I'm working on splitting them right now).
• The readme file must indicate how to generate the documentation for your own copy locally.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Implement asymmetric key derivation

Description

Implement psa_generator_import_key() for DH and ECC.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Port the windows mbedtls issue fix to mbedcrypto

Hi,
I am trying to compile mbedcrypto on windows, but meet the same problem while I was working for mbedtls.
I am using cmake, with git bash + cmake on windows, not a cygwin environment.

The error message is:

CMake Error at CMakeLists.txt:114 (message):
Could not create symbolic link for:
C:/Users/user01/git/mbed-crypto/include/mbedtls -->
Call Stack (most recent call first):
include/CMakeLists.txt:20 (link_to_source)

I found the same issue at:
https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=a0f505c659e2af2ffa278d215045add711f7f2d8

Shall we port the fix on mbedtls into this?

Thanks.

ITS should call fsync

Description

The PSA ITS implementation in Mbed Crypto was originally developed for testing. It modifies files atomically, so it's resilient to interruptions such as a process crash, but it does not call any disk synchronization primitives, so it is not resilient to an operating system crash.

PSA ITS should call a disk synchronization primitive that is configurable at build time. On Unix systems, it should call fsync on the file and on the containing directory.

Cc @paulhowardarm

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Update mbedtls_to_psa_error with new mbedtls error codes

Description

In psa_crypto.c, the function mbedtls_to_psa_error translates Mbed TLS error codes (MBEDTLS_ERR_xxx) into PSA error codes (PSA_ERROR_xxx). This function was originally written for the features implemented over Mbed TLS 2.7 and not updated when we merged more recent versions of Mbed TLS. This can cause PSA_ERROR_UNKNOWN_ERROR to be reported in some error cases instead of the correct error.

Missing: new crypto modules (aria, chacha20, chachapoly), MBEDTLS_ERR_PLATFORM_FEATURE_UNSUPPORTED, MBEDTLS_ERR_PLATFORM_HW_ACCEL_FAILED, and some MBEDTLS_ERR_xxx_BAD_INPUT_DATA that shouldn't happen anyway.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Undefined behavior in mbedtls_platform_zeroize()

Description

Calling memset() with a non-NULL buffer argument is undefined in C. mbedtls_platform_zeroize() can end up calling memset() directly (via a function pointer). It might be good to make mbedtls_platform_zeroize() have defined behavior when the buffer argument in NULL and size is 0.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Test the functions in OID module in Mbed Crypto

Description

We don't directly test the functions in the OID module in Mbed Crypto. They only get tested indirectly through X.509 and TLS. We should write unit tests for these functions.

Note that test coverage tools may not give accurate results for oid.c because it uses macros to define many functions.

Related: #78 — test the OID values.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Allow omitting OID name/description

Description

On small systems (e.g. Cortex-M4) every KB of code footprint counts, and the OID name and description string tend to only be needed in certain debugging/tools contexts (e.g. mbedtls_x509_crt_info()). I've noticed that when building with -ffunction-sections, -fdata-sections, and gc-sections, there are a few KB of wasted code space because constant strings are entangled to types in a way that makes it hard for a linker to omit them.

I have a similar approach in mind as Mbed-TLS/mbedtls#2315, and propose the configuration MBEDTLS_OID_NAMES. If you agree I can get started on the PR.

Note that because mbed TLS now uses mbed-crypto, this issue is a dependency for that PR.

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

psa_cipher_setup leaves operation in partially initialized state in case of error

Description

in some of the setup functions the operation structure is not properly cleaned up in case of failure.
we specifically encountered this in the psa_cipher _setup. When passing in an invalid key handle (with other valid parameters) it will fail but leave the operation structure with the algorithm set.
This is OS and platform independent behavior.

Note: this likely also impacts other setup functions (e.g. psa_hmac_setup_internal, psa_mac_setup, etc..)

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

Add ability to link to a Linux-native PSA trusted_storage library when using Makefiles

Description

Add ability to link to a Linux-native PSA trusted_storage library when using Makefiles. This feature is added to Mbed Crypto for CMake via #186, but should also be added to Makefile for feature parity between all the relevant Mbed Crypto build systems.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Interoperability checks for OID values

Description

The OID module defines many OIDs. Mbed TLS tests that it has the correct values indirectly by using parsing those values in X.509 test data and by making TLS connections. With the split of Mbed Crypto and Mbed TLS, there's nothing to verify that we have the correct values for all the OID constants in Mbed Crypto itself. We should add some verification mechanism, e.g. asking some other library to parse our OIDs or checking the value against some online database.

Related: #77 — test the OID functions.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

psa_key_derivation_output_bytes requires both PSA_KEY_DERIVATION_INPUT_SECRET and PSA_KEY_DERIVATION_INPUT_INFO as input

Description

Version: psa-crypto-api-1.0-beta
a. API: psa_key_derivation_output_bytes
b. Below were the procedure followed:
i. Call psa_import_key with proper arguments and attributes
ii. Call psa_key_derivation setup
iii. Call psa_key_derivation_set_capacity
iv. Call psa_key_derivation_input_key
v. Call psa_key_derivation_output_bytes
The return value is PSA_ERROR_BAD_STATE. It seems like both PSA_KEY_DERIVATION_INPUT_SECRET and PSA_KEY_DERIVATION_INPUT_INFO should be set before calling the psa_key_derivation_output_bytes. Should both be provisioned before generating the output bytes. Also for the step as seed, label or salt secret required both info and secret to be set.

This check is a part of PSA ACK (psa_arch_test)

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug