Hello,
As you may be aware, there is work in progress to implement support for
hardware drivers in Mbed TLS when using the PSA API. These are direct
calls from the PSA frontend layer to driver code, without going through
mbedtls_xxx APIs and the ALT implementations. The specifications are the
psa-driver-*.md files in
https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed and
you can watch the work in progress in the “Unified driver interface: API
design and prototype” epic
https://github.com/ARMmbed/mbedtls/projects/2#column-8543266 .
When an algorithm is implemented in hardware, in most cases, it is
unnecessary to include a software implementation, and it should be
possible to exclude the software implementation from the build to keep
the code size down. Unfortunately the current Mbed TLS configuration
mechanism does not support this, because it does not distinguish “I want
AES” from “I want mbedtls_aes_xxx”. So we need new compile-time options
to convey “I want PSA_KEY_TYPE_AES in my application but I don't care
whether it's done in hardware or mbedtls_aes_xxx”.
We are going to implement a configuration mechanism to select which
cryptographic algorithms are included in the PSA interface in a build of
Mbed TLS. It will rely on #define statements, like the existing
config.h, but with different naming conventions for PSA. You can see the
specification proposal at https://github.com/ARMmbed/mbedtls/pull/3628 .
Feedback is welcome. We're likely to merge this pull request soon, but
even after it's merged I'll keep watching comments, or you can post
feedback on the mailing list, or raise an issue on GitHub if you have a
specific feature request.
A major difference between the current MBEDTLS_xxx_C configuration and
the new PSA_WANT_xxx configuration is that PSA_WANT_xxx is additive: if
PSA_WANT_xxx depends on some other feature, enabling PSA_WANT_xxx will
automatically enable that feature in most cases (the exception being
when there's more than one way to enable the dependent feature, e.g.
when a hash algorithm is needed but it doesn't matter which hash). This
is in contrast with the current strict mechanism where enabling
MBEDTLS_xxx_C is an error if it depends on some other feature that isn't
enabled. We haven't decided yet, but we're thinking of changing to an
additive mechanism for the whole Mbed TLS configuration in Mbed TLS 3.0.
If you want to watch the implementation work in progress, it will be
under the “Driver Interface: Removing unused code” epic
https://github.com/ARMmbed/mbedtls/projects/2#column-9449707 .
Note that the #define-based mechanism is somewhat experimental and we
won't commit yet about its long-term stability in Mbed TLS. It is likely
to be complemented by a JSON-based mechanism in the future. This JSON
mechanism would be similar to the proposed mechanism for drivers and
would allow finer granularity (for example, RSA verification without RSA
signature). Arm is considering standardizing the (as yet non-existent)
JSON mechanism as a PSA specification.
Best regards,
--
Gilles Peskine
Mbed TLS developer (and PSA crypto architect)
