Remove the dynamic SE interface in 4.0

[daverodgman]

Remove the dynamic SE interface (supplanted by opaque drivers). MBEDTLS_PSA_CRYPTO_SE_C must be removed from mbedtls_config.h. All code related to this should be removed, except mbedtls_psa_register_se_key() which first needs to change to work with new-style drivers.

Mailing list thread: https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/7AM6WGPCIEHOZQ5G3M5LPZHNG5CSOPAP/

[mpg]

Note: a good portion of docs/architecture/testing/driver-interface-test-strategy.md can be removed as well.

[mpg]

Note: I think this will close #3856 as well. Actually, when addressing this, we should search for "SE", MBEDTLS_PSA_CRYPTO_SE_C, etc. in open issues and close those that become irrelevant.

[gilles-peskine-arm]

close those that become irrelevant.

Agreed that we should do that. But double check that the issues don't also apply to the new driver interface, or if they do that there is an issue for that.

I tend to call MBEDTLS_PSA_CRYPTO_SE_C the “old driver interface” or “dynamic secure element driver interface” or “dynamic SE drivers”.

[gilles-peskine-arm]

Note that at least mbedtls_psa_register_se_key should stay but be adapted to the new kind of opaque drivers.

[mimok]

I'm still using the "old" dynamic SE interface and i'm wondering whether the new PSA driver interface is actually in production or not before switching. I mean the driver interface cannot be fully defined through JSON files, you still need to manually modify the jinja templates. Is this really the way it is expected to work ?

[gilles-peskine-arm]

The C part is ready for production and actually used in production by several early adopters. Unfortunately, you do need to edit psa_crypto_driver_wrappers* manually at the moment. The way this is supposed to work is that you would provide a JSON file, but the script to generate the wrappers from JSON is not ready for production yet.

[DarkDust]

I was looking into how to wrap Apple keychain identities (certificate + private key) and APIs for use with mbedTLS (to do TLS 1.3). It seemed writing a dynamic PSA driver would be the way to go now, but then I found this issue. I've read through some of the docs and just want to know I'm understanding correctly what this means for me as a developer who wants to write a secure element driver:

• I have to write a driver, as described in the docs.
• For the integration, I have to patch the mbedTLS source.
  • The files to patch should "just" be the ones in scripts/data_files/{driver_jsons,driver_templates}/*.
• Which means, with every update of mbedTLS I have to make sure my patch still applies and potentially fix any issue due to code changes in mbedTLS.

Is that correct? From what I'm understanding, maintaining a custom driver using psa_register_se_driver seems easier to implement and maintain. But according to this issue, the project's intention is to remove support for dynamic drivers in the long run, so right now it's already better to do it the way I've summarized above, right?

[gilles-peskine-arm]

That is correct, yes.

The old, dynamic interface only looks more stable because we've abandoned development on it. It's only partially implemented, and not tested much.

The new interface does require you to patch either the template files or the generated C files (I think it makes more sense to patch the generated C files) so that the dispatch code knows about your driver. This is temporary: we have a tool whose job is to read the template and your driver declaration, and generate the required dispatch code. Unfortunately, this tool is very incomplete, so it isn't ready for production.

You can use dynamic drivers in 2.28 and 3.6, but we won't help you unless you run into a major bug. In particular we won't add any features or resolve documented limitations. And we won't maintain that interface past 3.6.

If there is, specifically, demand for drivers that must be registered at runtime, we may add this ability back at some point after 4.1. It would be based on the new driver interface, not reusing any of the existing code of the old interface.

[mimok]

Hi @gilles-peskine-arm, i'm still wondering whether i should switch to the new driver interface. Yesterday, i was digging into the code and it is unclear how an opaque SE driver could be actually implemented using the new driver interface. Indeed, a free slot ID is required to import a key into a SE however only the old driver interface allow to retrieve a free slot ID from this external SE. There is also no "atomic write" of the SE keys as implemented here:

mbedtls/tf-psa-crypto/core/psa_crypto.c

Line 1975 in b6860cf

psa_crypto_prepare_transaction(PSA_CRYPTO_TRANSACTION_CREATE_KEY);

[gilles-peskine-arm]

@mimok Beware that atomic write is not implemented for the old SE driver interface either! We have code that sets up a transaction for writing, but we don't have the code to recover an interrupted transaction.

The new SE driver interface all of the functionality of the old one, except for the ability to load drivers at runtime.

[mimok]

@gilles-peskine-arm

The new SE driver interface all of the functionality of the old one, except for the ability to load drivers at runtime.

My apologizes but i still don't understand how to use the new interface to implement a driver for an external secure element with storage using mbedTLS v3.6.2.

For example, when MBEDTLS_PSA_CRYPTO_SE_C is disabled there is no slot_number field in the attribute structure, no slot allocation mechanism, etc. I can't find in the source code what is described here:

mbedtls/docs/proposed/psa-driver-interface.md

Line 1125 in ce3c2dd

#### Key management in a secure element with storage

[gilles-peskine-arm]

With the old interface, using a secure element with storage is implemented at a proof-of-concept quality: you have the functionality, but if the device loses power at a bad time, you may end up with corrupted storage.

With the new interface, using a secure element with storage is not implemented yet.

That is filed in our roadmap as part of “[PSA Crypto][PSA Secure Element, Crypto Accelerator Support Enhancements]”. Note that it may be technically be possible to implement this in the 3.6 long-time support branch, but we (the Mbed TLS maintainer team) have no bandwidth to work on it until late 2025 at best.

[gilles-peskine-arm]

By the way, the current implementation can use keys that are stored in a secure element, by declaring them as built-in keys. See mbedtls_psa_platform_get_builtin_key() for more details. What we currently can't do is create keys that are stored in a secure elements, due to the lack of transaction handling.