mbed-tls June 2024

mbed-tls@lists.trustedfirmware.org

8 participants
12 discussions

Re: PSA Cryptoprocessor Driver Interface

by Shebu Varghese Kuriakose

+ Mbed TLS mailing list as well for visibility and any comments. Regards, Shebu From: Zhang, Hao via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 5, 2024 12:37 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Cryptoprocessor Driver Interface Hi TF-M community, TF-M allows Semiconductor vendors to plug in their HW accelerator using PSA cryptoprocessor driver interface. I have a couple of questions in terms of the driver interface. 1. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS using driver interface, for the multipart operation, https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa… states that "A driver that implements a multi-part operation must define all of the entry points in this family as well as a type that represents the operation context." Take aead encrypt as an example, if the underlying hardware does not support aead_abort, could it implements aead_abort by simply return PSA_ERROR_NOT_SUPPORTED? 1. The driver interface depends heavily on psa_crypto_driver_wrappers.h to dispatch operations to customized HW accelerator, where the psa_crypto_driver_wrappers.h file is automatically generated by scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS, would the approach be creating a customized psa_crypto_driver_wrappers.h.jinja file, the driver description file in JSON, and entry point functions. If so and we are considering upstreaming TF-M in the future, all these files would go inside platform/ext/accelerator/<vendor name>. Efforts need to be made so files such as psa_crypto_driver_wrappers.h.jinja should point to mbedtls, right? Additionally, as .jinja is retiring (mentioned in another email exchange), how would semi vendors update psa_crypto_driver_wrappers.h in the future? [https://opengraph.githubassets.com/c87e79773a7fb0841ea038f7cf3dfdf4170debb8…]<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls/docs/proposed/psa-driver-interface.md at zephyr * zephyrproject-rtos/mbedtls<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls module for Zephyr, this is not a mirror of the official mbedtls repository. - zephyrproject-rtos/mbedtls github.com Thank you very much! Best regards

3 weeks, 4 days

mbedtls_x509_dn_gets(): Different DN string for 2.28.8 and 3.6.0

by Almut Herzog

Hi, Not sure whether I should report this as a bug or maybe an enhancement issue or maybe it is as-designed: I recently migrated from 2.28.8 to 3.6.0 and noticed: An X.509 certificate DN coded as T61 string (done automatically so by openssl for a DN that contains an underscore) is returned as a hex string in 3.6.0 while it is returned as a regular, human-readable string in 2.28.8. As this is not working for us I patched mbedtls_c509_dn_gets() locally as shown below. Please feedback whether you want me to report an issue or if the 3.6.0 behavior is as-designed for a good reason. Best regards, /Almut --- mbedtls-3.6.0_orig/library/x509.c 2024-03-28 09:59:12.000000000 +0100 +++ mbedtls-3.6.0/library/x509.c 2024-05-21 10:43:43.327442284 +0200 @@ -840,9 +840,7 @@ MBEDTLS_X509_SAFE_SNPRINTF; } - print_hexstring = (name->val.tag != MBEDTLS_ASN1_UTF8_STRING) && - (name->val.tag != MBEDTLS_ASN1_PRINTABLE_STRING) && - (name->val.tag != MBEDTLS_ASN1_IA5_STRING); + print_hexstring = !MBEDTLS_ASN1_IS_STRING_TAG(name->val.tag); if ((ret = mbedtls_oid_get_attr_short_name(&name->oid, &short_name)) == 0) { ret = mbedtls_snprintf(p, n, "%s=", short_name);

3 weeks, 4 days

2024

2023

2022

2021

2020

mbed-tls June 2024