PSA: support arbitrary data storage from secure element drivers

[gilles-peskine-arm]

Secure element drivers may need to hand back a wrapped key to the generic code, and have the generic code generate it. In such cases there may not be a concept of slot number.

This is part of a larger redesign of the secure element interface in #3287 and should not be implemented independently of this redesign.

Goals:

• Support secure element drivers which have no state, and where the generic code stores the opaque blob passed by the driver.
• Don't break the existing support for secure elements which do store the key.
• At least smoke tests. Detailed testing is out of scope of this task.

[gilles-peskine-arm]

With the unified driver interface, key contexts for opaque drivers are opaque blobs. The job of the core is merely to allocate memory for this blob and store it.

There is a moderately complex way for drivers to specify the size of this blob in the driver description file. The complexity is intended to support implementations that allocate memory statically. Since Mbed TLS allocates memory dynamically, this complexity is not needed. For this task, only handle drivers that provide a function

size_t acme_driver_context_size(psa_key_type_t key_type, size_t key_bits)

that returns the size of the context based on the key type and size. The driver glue code will define a function

size_t mbedtls_psa_opaque_driver_size( psa_key_attributes_t *attributes );

that calls the correct driver for a key with the given attributes.

For this task, in the library code, assume that mbedtls_psa_opaque_driver_size is already defined. Until the automation to generate the glue code from driver descriptions is available, tests will need to define mbedtls_psa_opaque_driver_size manually.

Necessary changes in the library;

• When creating an opaque key, allocate its context, which becomes key->data.
• When loading an opaque key from storage, allocate its context based on the stored size.
• Pass the context when calling opaque drivers.
• Unit tests.

#3492 has already done a significant part of the work.

[jdurkop]

How is #3546 related to this tasking. That one seems focused on copyright notice updates.

[gilles-peskine-arm]

Sorry, must have been a copy-paste error. I meant #3492

[jdurkop]

No problem. That one looks more relevant.

[jdurkop]

Here are some of the questions I have based on the task list in the issue comments.

1. For defining the the mbedtls_psa_opaque_driver_size for testing, is there a preferred set of guards to place around that type of code?
2. Is the key context you refer to the one that is already in psa_crypto_core.h (struct key_data)?
3. Is there a sample driver build I could look at? I didn’t see any in the current code base. I don’t think I necessarily need it to complete this task, but I think it would be helpful for me to see how the whole system is put together.
4. For the unit tests, is there any specific requirements we want to ensure are working properly for this specific set of changes? i.e. validate context is created at appropriate times and passed to correct functions.