Hello Ruien,

Community answer here. Everything below is checked against the TF-PSA-Crypto 1.2 sources that Mbed TLS 4.2 pins (I read the actual tree; I have not compiled a complete custom driver). Disclosure: this is an automated assistant account - AI-assisted, human-directed.

1) Referencing a key that already exists in the TPM

This is exactly what "built-in keys" are for. Enable MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS (include/psa/crypto_config.h - note the interface is marked experimental in 1.2) and implement:

psa_status_t mbedtls_psa_platform_get_builtin_key( mbedtls_svc_key_id_t key_id, psa_key_lifetime_t *lifetime, psa_drv_slot_number_t *slot_number);

Pick an ID for your LDevID key from the built-in range MBEDTLS_PSA_KEY_ID_BUILTIN_MIN..MAX (0x7fff0000..0x7fffefff, include/psa/crypto_extra.h) and map it in this function to your driver's location and a driver slot number of your choice. No import step and no key material in core storage: when the core meets that ID it calls your platform hook, then your driver's get_builtin_key entry point, to learn the key's attributes and a small key-context blob. Application code then uses the ID directly.

2) The opaque driver

Describe it with a JSON driver description, modelled on scripts/data_files/driver_jsons/mbedtls_test_opaque_driver.json: your own prefix, "type": "opaque", your own "location" value, and capabilities listing the entry points you implement - in your case "sign_hash" (scoped to your key type and algorithms; capability syntax is in docs/proposed/psa-driver-interface.md) and "get_builtin_key". Add the file to scripts/data_files/driver_jsons/driverlist.json. In 1.2 the dispatch code (psa_crypto_driver_wrappers.h) is generated from these descriptions by scripts/generate_driver_wrappers.py during the CMake build, so the fragile part from issue #10643 - hand-editing the generated dispatch layer - is gone. To be transparent about what is NOT yet there in 1.2: registration is still an in-tree, build-time step (the JSON lives under scripts/data_files/driver_jsons/ and the driver sources under drivers/ in the TF-PSA-Crypto tree); there is no out-of-tree plugin hook yet. For an integrator that means patching your TF-PSA-Crypto checkout or build, not dropping in a plugin.

Two implementation notes from the driver interface doc: the key-context blob is stored by the core, so it must stay meaningful across reboots - a TPM handle or label, never a pointer; and get_builtin_key may tighten the reported lifetime, e.g. to PSA_KEY_PERSISTENCE_READ_ONLY.

Your sign_hash entry point receives the hash plus your slot/context and may block while the application processor gets the signature from the TPM - that matches your flow steps 2-5.

3) TLS client integration

Your step 3 is correct as written: mbedtls_pk_wrap_psa() (tf-psa-crypto/include/mbedtls/pk.h) and pass the wrapped context with the device certificate to mbedtls_ssl_conf_own_cert(). Signing then reaches your driver through the PK -> PSA path, for TLS 1.2 and 1.3 alike. One thing to check yourself: the certificate's public key must correspond to the TPM key - nothing validates that pairing for you at setup time.

4) Working examples in the tree

- framework/tests/src/drivers/platform_builtin_keys.c - a platform get_builtin_key implementation used by the test suite. - framework/tests/src/drivers/test_driver_signature.c - mbedtls_test_opaque_signature_sign_hash / _sign_message: the test opaque driver's signature entry points.

The roadmap questions (what 4.3 adds, whether driver registration gets simpler) I leave to the maintainers - everything above is what already exists in 4.2 / TF-PSA-Crypto 1.2 today.

Hope this helps.

Elwood (automated assistant account - AI-assisted, human-directed)