- mbed-tls - lists.trustedfirmware.org

Using mbedTLS for TLS&X509 with a separate PSA Crypto Implementation

by Zak, Kevin

Hello mbedtls mailing list, I'm working to modify mbedTLS (3.6.2) to use our PSA Crypto Implementation in a separate library. Our solution does not make use of PSA 'drivers' that mbedTLS refers to. I've modified makefiles to not build PSA Crypto files, and have enabled MBEDTLS_PSA_CRYPTO_C & MBEDTLS_USE_PSA_CRYPTO. I've also defined MBEDTLS_PSA_ACCEL_ALG_XXX for our supported algorithms. 1. Is there a good way to determine whether a given TLS/X509 configuration would require a certain 'legacy' (maybe a better term is 'non-PSA') crypto file to be built into the mbedTLS library? * The goal is to build as few crypto source files into the mbedTLS source files as possible, maximizing usage of our separate PSA implementation 2. Example: My test application using mbedtls_x509_crt_parse() receives linking errors for mbedtls_ecp_(group/point)_xxx() and mbedtls_mpi_xxx() that are referenced in pkparse.c (which I am building into the library). * Ecp.c is currently excluded from the build (as is its define) - if I add it, I add significantly more linking errors for mbedtls_mpi APIs. I was under the impression that ECP and MPI APIs could be avoided with the correct configuration. * If ecp/mpi helper APIs are needed still for x509, this would be good to know. However, I'd like to avoid usage of MPI APIs that perform actual software calculations. See the screenshot for a list of non-PSA crypto files I am currently building to test with. I imagine I may have to add more incrementally. [cid:image001.png@01DB726D.879014D0] Any insights on this general use case or my ECP troubles with x509 would be appreciated. I plan to extend the strategy as these are the findings from an attempt to use just one x509 API. Best, Kevin Zak

9 months, 2 weeks

2
1
0 0

Use mbedtls_gcm_auth_decrypt get wrong tag

by Elva Huang

Dear mbed TLS team, Recently, while debugging my code, I encountered an issue when using the AES-GCM algorithm. I found that when calling the mbedtls_gcm_auth_decrypt interface in version 3.6.1, the calculated tag consistently does not match the input tag. However, when using the same interface in version 2.28.2, the tag is successfully calculated as expected. Below is the demo code we are using: tstSecKeyList g_stPreInterKey = { .u8KeyNum = 5U, .u8IsUse = 1U, .u16KeyLen = 16U, .u16IVLen = 12U, .u16AddLen = 16U, .enuSecType = SEC_AES_GCM, .au8Key = { 0x68U, 0xffU, 0xb7U, 0xffU, 0x5eU, 0xffU, 0x10U, 0xffU, 0x9eU, 0xffU, 0xb8U, 0xffU, 0x01U, 0xffU, 0xb9U, 0xffU, 0xa0U, 0xffU, 0x1cU, 0xffU, 0xdfU, 0xffU, 0x0aU, 0xffU, 0xe6U, 0xffU, 0xc8U, 0xffU, 0xc5U, 0xffU, 0x39U, 0xffU }, .au8Iv = { 0x3, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x0, 0x1, 0x2, 0x3 }, .au8Add = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } .u16AddLen = 0, }; static uint8_t s_au8SecMemoryBuffer[6*1024]; mbedtls_gcm_context aesGcmContext; uint8_t *pau8EncryptedPlain = inParam0; (note: inParam0=434421d30c9abf31b96d2d28d00b5cb4e6fe84033999d53d3a50674b3aedd81f) uint8_t *pau8AesTag = inParam0 + 16; (e6fe84033999d53d3a50674b3aedd81f) uint8_t u8EncryptedPlainLen = 16; uint8_t u8AesTagKeyLen = 16; mbedtls_gcm_init(&aesGcmContext); mbedtls_memory_buffer_alloc_init(s_au8SecMemoryBuffer, 6*1024); vidPreInterKeyget(g_stPreInterKey.au8Key, au8preInterKey); mbedtls_gcm_setkey(&aesGcmContext, MBEDTLS_CIPHER_ID_AES, au8preInterKey, 16*8); s32Ret = mbedtls_gcm_auth_decrypt(&aesGcmContext, u8EncryptedPlainLen, g_stPreInterKey.au8Iv, g_stPreInterKey.u16IVLen, g_stPreInterKey.au8Add, g_stPreInterKey.u16AddLen, pau8AesTag, u8AesTagKeyLen, pau8EncryptedPlain, s_au8DecryptKey); Best regards,

9 months, 3 weeks

1
1
0 0

Question Regarding Change Cipher Spec States in the TLS 1.3 Handshake Protocol

by 千山啼祢

Dear Developer, I was reviewing the code and noticed that in the TLS 1.3 handshake protocol state machine, the "Change Cipher Spec" state has been divided into five different states based on its occurrence timing. Could you please clarify if there are any specific considerations for this approach? Additionally, these states can appear multiple times during a single handshake, which implies multiple "Change Cipher Spec" messages. However, the TLS 1.3 standard suggests that the "Change Cipher Spec" should only appear once in a single handshake. Could you kindly explain the rationale behind this design decision? Thank you for your time and assistance. I look forward to your response. Best regards, XiangDong Li

10 months

1
0
0 0

Inquiry Regarding mbedTLS v2.16.2 Compatibility for Secure MQTT Connection on STM32CubeIDE

by Noushad

Hello, I am currently working on a project using STM32CubeIDE, where I am leveraging mbedTLS v2.16.2 to establish a secure MQTT connection with a Mosquitto broker on port 8883. During my implementation, I encountered a TLS handshake error with the following details: mbedtls_ssl_handshake failed. -29312 (-0x7280) I would like to confirm if mbedTLS v2.16.2, as provided in STM32CubeIDE, supports secure TLS connections (e.g., Secure MQTT) and is compatible with Mosquitto broker configurations. Additionally, I would appreciate guidance on resolving this error. Here are some specific details about my setup: 1. mbedTLS version: 2.16.2 (as integrated into STM32CubeIDE). 2. Broker: Mosquitto, configured for secure MQTT on port 8883. 3. Issue: TLS handshake fails with the error mentioned above. 4. Certificates: [CA certificates, ]. Please let me know if additional information Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB65BA.1F5B9660]

10 months

1
0
0 0

Question Regarding Change Cipher Spec States in the TLS 1.3 Handshake Protocol

by 千山啼祢

Dear Developer, I was reviewing the code and noticed that in the TLS 1.3 handshake protocol state machine, the "Change Cipher Spec" state has been divided into five different states based on its occurrence timing. Could you please clarify if there are any specific considerations for this approach? Additionally, these states can appear multiple times during a single handshake, which implies multiple "Change Cipher Spec" messages. However, the TLS 1.3 standard suggests that the "Change Cipher Spec" should only appear once in a single handshake. Could you kindly explain the rationale behind this design decision? Thank you for your time and assistance. I look forward to your response. Best regards, XiangDong Li

10 months, 1 week

1
0
0 0

Heap and stack usage information

by Michael Thomas

Hi, I am trying to determine what would be an optimal stack and heap allocation for mbedtls. I realize this changes with algorithms, some configuration macros for the algorithms as well as concurrency. But is there any information on stack and heap usage that I can use as a starting point? And is there any information on the same for a crypto suite. Thanks Michael T Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.

10 months, 1 week

1
0
0 0

Inquiry Regarding mbedTLS v2.16.2 Compatibility for Secure MQTT Connection on STM32CubeIDE

by Noushad

Hello, I am currently working on a project using STM32CubeIDE, where I am leveraging mbedTLS v2.16.2 to establish a secure MQTT connection with a Mosquitto broker on port 8883. During my implementation, I encountered a TLS handshake error with the following details: mbedtls_ssl_handshake failed. -29312 (-0x7280) I would like to confirm if mbedTLS v2.16.2, as provided in STM32CubeIDE, supports secure TLS connections (e.g., Secure MQTT) and is compatible with Mosquitto broker configurations. Additionally, I would appreciate guidance on resolving this error. Here are some specific details about my setup: 1. mbedTLS version: 2.16.2 (as integrated into STM32CubeIDE). 2. Broker: Mosquitto, configured for secure MQTT on port 8883. 3. Issue: TLS handshake fails with the error mentioned above. 4. Certificates: [Specify if you are using self-signed certificates, CA certificates, etc.]. Please let me know if additional information or logs would be helpful for diagnosing the issue. Thank you for your assistance. Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB5D28.96B30030] Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB5D28.96B30030]

10 months, 2 weeks

2
1
0 0

Request for Assistance with Iterative Loading and Verification of Built-in Certificates in Mbed TLS

by xiaobing wang

Dear Mbed TLS Support Team, I am currently working on a project using Mbed TLS version 3.6 on FreeRTOS, and I am encountering an issue with handling multiple CA certificates during the TLS handshake process. My device has a set of built-in certificates, and I need to try each certificate one by one to establish a successful connection to my server. However, I am facing difficulties in this process. ### System Information: - **Mbed TLS version**: 3.6 - **Operating System**: FreeRTOS - **Configuration**: Default - **Compiler and Options**: N/A (using default configuration) ### Expected Behavior: The first certificate (e.g., `cdotroot.cer`) cannot be verified by Mbed TLS, while the correct certificate should successfully establish a connection. ### Actual Behavior: Both the incorrect and correct CA certificates fail to establish a connection successfully. ### Steps to Reproduce: Here is a sample of my code: ```c static int load_and_verify_certificates(int conn_id, uint8_t *cert_buffer, size_t buffer_size) { int ret; bool connection_established = false; uint32_t cert_index = 0; while (!connection_established && cert_index < MAX_CERT_COUNT) { size_t cert_size = buffer_size; // Free and initialize the certificate context mbedtls_x509_crt_free(&cacert[conn_id]); mbedtls_x509_crt_init(&cacert[conn_id]); // Load the built-in certificate ret = try_built_in_certificate(cert_buffer, &cert_size, cert_index); if (ret == CERT_ERR_INDEX_OUT_OF_RANGE) { break; } if (ret != CERT_SUCCESS) { cert_index++; continue; } // Parse the certificate cert_buffer[cert_size] = '\0'; ret = mbedtls_x509_crt_parse(&cacert[conn_id], cert_buffer, cert_size + 1); if (ret < 0) { cert_index++; continue; } // Set the certificate chain mbedtls_ssl_conf_ca_chain(&conf[conn_id], &cacert[conn_id], NULL); // Perform the TLS handshake ret = mbedtls_ssl_handshake(&ssl[conn_id]); if (ret == 0) { uint32_t flags = mbedtls_ssl_get_verify_result(&ssl[conn_id]); if (flags == 0) { connection_established = true; // Cache the certificate cache_certificate(cert_buffer, cert_size, cert_index); break; } } else { LOGD("Failed to perform handshake with certificate index %d, error: -0x%x\n", cert_index, -ret); } // Reset the SSL session ret = mbedtls_ssl_session_reset(&ssl[conn_id]); if (ret != 0) { LOGD("Failed to reset SSL session, error: -0x%x\n", -ret); return ret; } cert_index++; } return connection_established ? 0 : -1; } ``` ### Additional Information: Here are the logs: ``` Reading certificate 'cdotroot.cer' at address 0x08100650, size: 1348 Failed to perform handshake with certificate index 0, error: -0x2700 Reading certificate 'digicertroot.cer' at address 0x08100B94, size: 1360 Failed to perform handshake with certificate index 1, error: -0x7300 ... ``` I suspect that the issue may be related to the limited RAM space available on my device. I am looking for guidance on how to properly iterate through and verify the built-in certificates within these constraints. Any suggestions or best practices for handling multiple certificates in such an environment would be greatly appreciated. Thank you for your assistance. Best regards, [Tony] --- Feel free to replace `[Your Name]` with your actual name before sending the email.

10 months, 3 weeks

1
0
0 0

How to use a different mbedtls_config.h file?

by Alexander Slatina

Hello, I described an issue I have here: https://github.com/Mbed-TLS/mbedtls/issues/9867 During compilation it compiles with the wrong mbedtls_config.h even though I set up this part in my CMakeLists.txt: #MbedTLS default START # 1. MbedTLS custom config setup set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mbedtls) set(MBEDTLS_CONFIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/mbedtls_config.h") add_compile_definitions( MBEDTLS_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}" MBEDTLS_USER_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}" ) set(ENABLE_TESTING OFF CACHE BOOL "Disable mbedtls testing" FORCE) set(ENABLE_PROGRAMS OFF CACHE BOOL "Disable mbedtls programs" FORCE) set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mbedtls) # Add mbedtls build add_subdirectory(${MBEDTLS_DIR}) #MbedTLS END There’s more information on the GitHub link. Thank you in advance. Alex

10 months, 3 weeks

1
0
0 0

TF-PSA-Crypto

by Janos Follath

Dear Mbed TLS users, Mbed TLS has contained the reference implementation of the PSA Crypto API since the early days of the standard. This implementation was experimental at first, but over years of development it reached maturity, and the experimental status was removed three years ago (in version 3.6.1.). Shortly after that, in 2022, the TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> repository was created just for the PSA Crypto API implementation to make it more accessible for users only interested in that. This repository was only a mirror of the main one and the development of the PSA Crypto API implementation remained integral part of Mbed TLS. In the background, work has been started to make this repository the place where the development of the PSA Crypto API reference implementation happens. This work has finally been completed and from now on TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> is ready to receive contributions, bug reports and enhancement requests. TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> will now be the development repository for the PSA Crypto reference implementation. Mbed TLS will continue to rely on TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> and will be using it as a submodule. Many thanks, Janos Follath Mbed TLS developer

10 months, 4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls