All, Not sure if this is the right audience (If it is not let me know if there is a better place to ask the following question)
We have been looking at future security requirements for CPE devices, and we think that we need the following functionality that is currently not really available in the current crypto libraries.
- Support for Quantum computing secure algorithms (Post Quantum of PQ algorithms)
- Support for Hybrid keys ( PQ plus Classic algorithm), preferable in any configuration.
- Modularized public key crypto algorithms implementation, to simplify adding new algorithms
- Updating public key architecture to simplify off-loading private key operations to a Trusted Execution environment or other security HW.
We initially looked at openssl, but found the openssl difficult to work with, so we decided to look at Mbedtls, which has a more lightweight design.
We modified the mbedtls 'pkey' code to make it more modularized (building on the pkwrap design), and added to support for Hybrid keys, which was relatively easy to do. Updating the TLS library to support hybrid keys has however been a big challenge. The TLS code is very interwoven with the 'pkey' code, and seems to have almost unique implementation for each type of key, making it difficult to follow and modify. Adding support for other (PQ) algorithms within that design will be challenge.
Before spending too much time on this we would like to know if there is an interest in the MBEDTLS community for a redesign of the code to support hybrid keys, PQ algorithms and modularized public key architecture.
Thanks, Robert
E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
Hello,
Mbed TLS is currently transitioning from its classic cryptography API (mbedtls_pk_xxx, mbedtls_rsa_xxx, etc.) to a new API (psa_xxx, https://armmbed.github.io/mbed-crypto/html/ https://armmbed.github.io/mbed-crypto/html/). A major difference is that the new API is a lot more opaque, which makes it easier to swap crypto implementations and algorithms under the hood. An application using the PSA crypto API should need very little change to use a different signature algorithm and moving the implementation of the crypto primitives to a TEE/SE should be fully transparent.
For a TEE, the idea is to run the crypto-and-keystore library as a TEE service.� We are working on implementing a driver mechanism (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver... https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver-interface.md, https://github.com/orgs/ARMmbed/projects/18#column-15836331 https://github.com/orgs/ARMmbed/projects/18#column-15836331 �Driver interface: API design and prototype� and more) that allows plugging in accelerator drivers (using keys in cleartext) and secure element drivers (where the crypto library only has a handle to the key, or a wrapped copy of the key, and the driver contacts the SE to perform the operation). The parts that are already implemented are being used in production, but a lot of features are still missing.
The PSA crypto API is not ready for PQC. It makes some assumptions (public keys are small, signatures are small, keys have no state, ...) that make sense for classic asymmetric crypto but not for PQC. We intend for version 2 of this API to have modifications for PQC, but I have no idea when this will happen.
One of the changes we're making in the move to PSA crypto is that the mbedtls_pk_ API is becoming a wrapper around psa_xxx calls. A limitation of the PSA API is that it doesn't have any form of key parsing (e.g. PKCS#8, X.509). In the long term, the pk module may stay on as a key parsing and formatting layer, or that may become a new psa API, we haven't decided yet. We also don't know if pk would be extended to cover new algorithms.
The X.509 and TLS code have to care a lot about specific public-key algorithms, and to a lesser extent about specific cipher algorithms, due to the history of the protocols. TLS 1.3 has made the story a lot simpler, but for older versions, the TLS code needs to know how to negotiate supported groups and point formats, to combine CBC and HMAC when not using AEAD, etc. We are currently switching the X.509 and TLS code to use the PSA crypto API, often across mbedtls_cipher and mbedtls_pk compatibility layers (https://github.com/orgs/ARMmbed/projects/18#column-15836318 https://github.com/orgs/ARMmbed/projects/18#column-15836318 �Use PSA Crypto more - part 1� and more), but this won't help to reduce all the algorithm-specific code that has to be there due to the protocol design.
We would be happy to collaborate on adding support for hybrid cryptography. However, at the moment, we are prioritizing other topics: (D)TLS 1.3, full transition to the PSA API, full support for accelerator drivers and secure elements...
Best regards,
mbed-tls@lists.trustedfirmware.org
-
Gilles Peskine -
Hulshof, Robert