I'm not sure what you're looking for. Do you mean open source projects
like Curl and Hiawatha that can use Mbed TLS as a cryptography provider?
Those are generally using the classic API, and so can't make generic use
of secure elements. I am aware of private projects using the limited
features available today (for example, TLS servers can use async private
key operations to put the key in an HSM — see
I've used SoftHSM in the past as a way to test portable PKCS#11 client
code without hardware. It did the job well. I can't speak for the
quality of its cryptography since I was only using it for testing.
If you're looking for a generic interface between applications and
secure elements, then I would recommend PSA crypto over PKCS#11. We did
try to make PSA Crypto a better PKCS#11. Obviously I'm biased :) But of
course PKCS#11 is old and venerable, whereas PSA is new and the support
for hardware secure elements is still a work in progress.
Mbed TLS developer and PSA Crypto architect
On 21/02/2021 17:11, Frank Bergmann via mbed-tls wrote:
> Hi Gilles,
> thank you for your detailled answer.
> Honestly I was in fear that your answer would look like this. ;-)
> Do you maybe know of any plans of any software project to use mbed TLS
> together with a secure element?
> I asked SoftHSM because it looks much promising for our goals but they
> answered that they don't have any plans to use different ssl libs.
> On 08.02.21 23:07, Gilles Peskine via mbed-tls wrote:
>> Hi Frank,
>> Support for HSM keys in Mbed TLS is a work in progress. The way it will
>> work eventually is by plugging an HSM driver under the PSA crypto API,
>> which supports both transparent and opaque keys.
>> The TLS code can already use the PSA crypto API for some things,
>> including client signature. Enable MBEDTLS_USE_PSA_CRYPTO, call
>> mbedtls_pk_setup_opaque() to create a PK object for the key, and declare
>> the key to the TLS code with mbedtls_ssl_conf_own_cert() as usual.
>> To create the key, you will need to write a PKCS#11 secure element
>> driver. ("Secure element" = "HSM" for this purpose.) I think it would
>> make sense to have one in Mbed TLS, but I don't know when we might get
>> around to writing one.
>> There are two secure element driver interfaces in Mbed TLS right now:
>> MBEDTLS_PSA_CRYPTO_SE_C (dynamic secure element interface) and
>> MBEDTLS_PSA_CRYPTO_DRIVERS (unified driver interface). Both are still
>> experimental: we can't guarantee API stability at this stage.
>> MBEDTLS_PSA_CRYPTO_SE_C was the first proposal, and its development is
>> currently frozen and may be abandonned, so I don't recommend investing
>> any effort in it at the moment, but if you need something fast (e.g. for
>> a demo/proof-of-concept), it's your best bet. MBEDTLS_PSA_CRYPTO_DRIVERS
>> is the way of the future, but it's an active work in progress.
>> If you're creating the key from your application, just call
>> psa_generate_key. If the key was provisioned externally, it's
>> unfortunately not so easy. With MBEDTLS_PSA_CRYPTO_SE_C, you can
>> register a key that's already present in the secure element with
>> mbedtls_psa_register_se_key(). The corresponding facility in the
>> MBEDTLS_PSA_CRYPTO_DRIVERS interface is a "get_builtin_key" entry point,
>> but this is not implemented yet. (There's a prototype at
but nobody is working on
>> it. The specification is in docs/proposed/psa-driver-interface.md.)
>> There's an example application with a MBEDTLS_PSA_CRYPTO_SE_C driver at
. We don't have
>> example code for MBEDTLS_PSA_CRYPTO_DRIVERS yet, or good documentation,
>> or an easy-to-use build system — those are still a few months in the future.
>> If you write a driver in the next few months, I recommend that you stay
>> in touch with the Mbed TLS development team and follow the development
>> branch of Mbed TLS closely, since it's a very active area of development
>> at the moment.