- mbed-tls - lists.trustedfirmware.org

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,

1 year, 6 months

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

1 year, 7 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]

1 year, 7 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

1 year, 7 months

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.

1 year, 7 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: [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]

1 year, 7 months

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.

1 year, 7 months

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

1 year, 7 months

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

1 year, 8 months

1
0
0 0

advice on mbedtls_ssl_context change between v2.16.1 and 3.6.2

by Daniel Webb

Hi, Can you give me a little advice on how v3 works? I've updated our mbed library from 2.16.1 to 3.6.2 which was mostly a very smooth experience, thanks. The one question in my mind relates to making p_bio private in mbedtls_ssl_context *I used to free it before calling mbedtls_ssl_free - is it ok to skip this now? ie:* //mbedtls_net_free((mbedtls_net_context *) m_ssl.p_bio); mbedtls_ssl_free(&m_ssl); *I also used to poll it before calling mbedtls_ssl_close_notify - is ok to skip this now? ie:* //if(mbedtls_net_poll((mbedtls_net_context *) m_ssl.p_bio, MBEDTLS_NET_POLL_WRITE, 0) < 0) // return; int ret; while((ret = mbedtls_ssl_close_notify(&m_ssl)) < 0) { if(ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE) return; } It all seems to run just fine like this, but I could really do with some confidence boosting validation of my cavalier commenting. Thank you Daniel

1 year, 8 months

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls