- mbed-tls - lists.trustedfirmware.org

by Zhang, Hao

Hi TF-M and mbedtls community, I am new to TF-M, I have a few questions about CryptoCell and random number generation. Thank you in advance. 1. I figure there seems to have two CryptoCell 312 implementations within TF-M. One under lib/ext/cryptocell-312-runtime and the other under platform/ext/accelerator/cc312/cc312-rom. What are the difference between these two? 2. For lib/ext/cryptocell-312-runtime, it does not define MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG whereas /ext/accelerator/cc312/cc312-rom does. Does that mean cryptocell-312-runtime is initiating RNG cryptodriver by using mbedtls_entropy_add_source whereas cc312-rom is using mbedtls_psa_external_get_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. If so, may I ask why these two cryptocells take two different approaches? I read from one of the documentation that mbedtls_psa_external_get_random is used when entropy is sufficient. So if entropy is sufficient, is it always preferred to have MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG defined and implements mbedtls_psa_external_get_random? What are the differences between the two approaches. 3. I also found cryptocell-312-runtime defines the entry point function cc3xx_init_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. But since PSA random number entry point funciton is not complete, the cc3xx_init_random is not being called anywhere, right? [https://opengraph.githubassets.com/17cdebc400b0ed807c620b586b21f3f77ff9c5d3…]<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> trusted-firmware-m/platform/ext/accelerator/cc312/cc312-rom/psa_driver_api/src/cc3xx_psa_random.c at 8df9cc8baf46252fd188bba1d87333a8daa9a5e8 · zephyrproject-rtos/trusted-firmware-m<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> Zephyr repository tracking https://git.trustedfirmware.org/trusted-firmware-m.git/ - zephyrproject-rtos/trusted-firmware-m github.com 4. I know random number generation PSA entry point function is in development, may I ask when that would be expected to complete? Thank you very much! Best regards, Hao

1 year, 4 months

1
0
0 0

Request for feedback about Mbed TLS 4: DRBG interfaces

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/107 Should TF-PSA-Crypto 1.0 (and thus Mbed TLS 4.0) have an interface for *pseudo*-random generation? It will, of course, still have a pseudorandom generator (= deterministic random bit generator = DRBG) internally, to power psa_generate_random(), psa_generate_key(), etc. The question is whether there will still be a public interface to create other DRBG instances, and if so, with what interface. If you want to be able to create instances of HMAC_DRBG and CTR_DRBG from application code in TF-PSA-Crypto 1.0, please let us know what your use case is. In particular, what parameters do you need (HMAC_DRBG and CTR_DRBG have many)? Do you need reseeding, and if so under whose control (the DRBG, or the caller)? In the absence of feedback, it is likely that HMAC_DRBG and CTR_DRBG will not be publicly available. Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 4 months

1
0
0 0

mbedtls 3.6.0: zero-sized array gives compiler warning (is undefined behavior)

by Almut Herzog

Hi all, I have a custom configuration where MBEDTLS_ECDSA_C is defined but MBEDTLS_PSA_CRYPTO_C and MBEDTLS_PSA_CRYPTO_CONFIG are not. This leads to a compiler warning in e.g. psa_util.c because a zero-sized array is declared (because PSA_VENDOR_ECC_MAX_CURVE_BITS is defined as 0). As of C99, §6.7.5.2 Array declarators: "If the expression is a constant expression, it shall have a value greater than zero." psa_util.c: #if defined(MBEDTLS_PSA_UTIL_HAVE_ECDSA) // Line 368 int mbedtls_ecdsa_raw_to_der(...) // Line 433 unsigned char r[PSA_BITS_TO_BYTES(PSA_VENDOR_ECC_MAX_CURVE_BITS)]; // Line 436 --> becomes in my config: unsigned char r[0]; MBEDTLS_PSA_UTIL_HAVE_ECDSA is automatically defined in my configuration due to the following code in config_adjust_legacy_crypto.h: #if defined(MBEDTLS_ECDSA_C) || (defined(MBEDTLS_PSA_CRYPTO_C) && \ (defined(PSA_WANT_ALG_ECDSA) || defined(PSA_WANT_ALG_DETERMINISTIC_ECDSA))) #define MBEDTLS_PSA_UTIL_HAVE_ECDSA #endif PSA_VENDOR_ECC_MAX_CURVE_BITS only receives a non-zero value if a PSA_WANT_<CURVE>, e.g. PSA_WANT_ECC_BRAINPOOL_P_R1_256, is defined. PSA_WANT_<CURVE> only gets defined in crypto_config.h if MBEDTLS_PSA_CRYPTO_CONFIG is defined (which it is not in my configuration). I have worked around it by explicitly defining e.g. PSA_WANT_ECC_BRAINPOOL_P_R1_256 in my configuration. But I believe there is some mismatch in the defines, at least in this example case, because mbedtls_ecdsa_raw_to_der() is only used in pk_wrap.c if MBEDTLS_USE_PSA_CRYPTO is defined. Impact: * In general, zero-sized arrays have undefined behavior in C (but are allowed by some compiler extensions) and thus behave differently for different compilers --> you might want to review PSA_VENDOR_ECC_MAX_CURVE_BITS and PSA_VENDOR_FFDH_MAX_KEY_BITS (and possibly more definitions) that fall through to 0 and are used as array sizes. * In my particular case, I believe code is compiled that is not needed (defines in psa_util.c and pk_wrap.c do not seem to match)

1 year, 4 months

2
1
0 0

Request for feedback about Mbed TLS 4: size_t printing with %zu

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/9307 Mbed TLS requires a C99 platform, with some pragmatic restrictions. One restriction is that we do not require printf and friends to support %zu for size_t printing. Starting with Mbed TLS 4.0, we are considering requiring printf() and friends (or the mbedtls_printf() and friends alternatives if overridden) to support %zu. This only affects the TLS library, not X.509 and crypto. Is it still necessary in 2025 to support platforms where printf() does not support the z modifier? Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 4 months

1
0
0 0

Request for feedback about Mbed TLS 4 and TF-PSA-Crypto: build system

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/106 We are evaluating build systems for TF-PSA-Crypto, and this will influence the Mbed TLS build as well (the Mbed TLS build scripts will call the TF-PSA-Crypto build scripts, whatever they are). Our current thinking is that we would like to have *CMake as the sole build system*. (We're still investigating whether CMake can do all we need.) That would mean that we would no longer provide GNU makefiles or Visual Studio solutions. As this remains a C project, for just building the library, compiling all the .c files with an include path covering all the .h files will keep working in common cases (but, as today, it isn't something we support officially). The main case I can think of where this wouldn't work is when cryptographic accelerator support requires special includes or compiler flags. Are there environments where the use of CMake is a problem? What is the oldest version of CMake that you'd like us to be compatible with? Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 4 months

1
0
0 0

Request for feedback about Mbed TLS 4: RSA decryption cipher suites

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8170 We are considering removing support for RSA and RSA-PSK key exchanges in Mbed TLS 4. These are cipher suites that use RSA encryption, as opposed to cipher suites using a key agreement (ECDHE) plus RSA signature. These key exchanges are hard to implement securely (we believe we got it right, but it's very delicate code), and they add significantly to the complexity of the TLS code. They have been formally deprecated for a long time and were removed in TLS 1.3. However, I'm aware that some ecosystems are clinging to RSA key exchange. Are RSA-encryption key exchanges still relevant for Mbed TLS? If you want Mbed TLS 4 to keep supporting RSA-encryption cipher suites in TLS 1.2, please let us know and tell us about your use cases. Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 4 months

1
1
0 0

Request for feedback about Mbed TLS 4: AESNI without compiler intrinsics

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8231 We currently have two implementations of accelerated AES on x86_64 using AESNI (Intel AES acceleration): using assembly or using compiler intrinsics. The assembly code works with GCC and Clang without any compilation options, but not with MSVC. The intrinsics work with MSVC, but not with ancient GCC/Clang and they require compiling at least aesni.c with suitable CPU variant options (e.g. -maes -mpclmul for Clang). We're considering removing the assembly implementation. Is there still interest in compiling AESNI support with older compilers or with simple build systems that don't pass machine options? Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 4 months

1
0
0 0

How to read ecp private key

by arun.lal＠intel.com

I am generating a ECP key in following way. And now how do I get the private key? TEE_Result gen_ec_keys(mbedtls_pk_context* pk, mbedtls_entropy_f_source_ptr f_source, __maybe_unused TEE_Param params[TEE_NUM_PARAMS]) { int ret = 1; mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; const char* pers = "gen_key"; TEE_Result res = TEE_SUCCESS; unsigned char output_buf[16000]; memset(output_buf, 0, 16000); mbedtls_entropy_init(&entropy); mbedtls_ctr_drbg_init(&ctr_drbg); if ((ret = mbedtls_entropy_add_source(&entropy, f_source, NULL, 48, MBEDTLS_ENTROPY_SOURCE_STRONG)) != 0) { params[2].value.a = 1; goto exit; } if ((ret = mbedtls_ctr_drbg_seed(&ctr_drbg, f_entropy, &entropy, (const unsigned char*)pers, strlen(pers))) != 0) { mbedtls_printf(" failed\n ! mbedtls_ctr_drbg_seed returned -0x%04x\n", (unsigned int)-ret); params[2].value.a = 2; goto exit; } if ((ret = mbedtls_pk_setup(pk, mbedtls_pk_info_from_type(MBEDTLS_PK_ECKEY))) != 0) { EMSG(" failed\n ! mbedtls_pk_setup returned -0x%04x", (unsigned int)-ret); params[2].value.a = 3; goto exit; } if ((ret = mbedtls_ecp_gen_key(MBEDTLS_ECP_DP_SECP384R1, mbedtls_pk_ec(*pk), mbedtls_ctr_drbg_random, &ctr_drbg)) != 0) { EMSG(" failed\n ! mbedtls_ecp_gen_key returned -0x%04x", (unsigned int)-ret); params[2].value.a = 4; goto exit; } exit: mbedtls_ctr_drbg_free(&ctr_drbg); mbedtls_entropy_free(&entropy); return res; }

1 year, 4 months

4
4
0 0

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

1 year, 4 months

3
4
0 0

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);

1 year, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls