- 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

5 months, 1 week

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,

5 months, 2 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

5 months, 4 weeks

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]

5 months, 4 weeks

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

6 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.

6 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]

6 months, 1 week

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.

6 months, 2 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

6 months, 2 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

6 months, 3 weeks

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

6 months, 3 weeks

1
1
0 0

Integrating Mbed TLS with LWIP

by Bas Prins

Dear Mbed TLS team, I am trying to integrate Mbed TLS in our platform: - nxp imx rt 1024 CPU (arm based) - FreeRTOS (10.6) - Lwip (2.2) - Mbed TLS (3.6.2) I am using the LWIP port to Mbed TLS and managed to create an client configuration by supplying a google certificate which I created as follows: openssl s_client -showcerts -connect www.google.com:443 </dev/null 2>/dev/null | openssl x509 -outform PEM > google_root_ca.pem PS: using the true random number generator in our CPU as the entropy source for Mbed TLS. I ran into some issues which I managed to resolve by adding another option in Mbed TLS (found this on a forum which solved the problem): #define MBEDTLS_RSA_C /* required for google's root CA */ #define MBEDTLS_PKCS1_V21 /* required for RSA */ Next I connected our http client to use the TLS configuration and gave it a first spin by trying to send a HTTP GET request to google.com. The TLS handshake failed. I enabled logging in the hope this would give me a direction, but I can't see where things go wrong (until the obvious error -0x7780 (MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE)). Can somebody see what goes wrong on the client side, which results in the server deciding to fail the request? Attached the log and will paste it here in the email. ====================== [2024-12-11 09:08:28] 2024-12-10 12:53:35.612 [Info ] [Http] GET from google.com:443 - / [2024-12-11 09:08:28] 2024-12-10 12:53:35.630 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(1327): The SSL configuration is tls12 only. [2024-12-11 09:08:28] 2024-12-10 12:53:35.676 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4606): => handshake [2024-12-11 09:08:28] 2024-12-10 12:53:35.678 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.678 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.696 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_HELLO_REQUEST [2024-12-11 09:08:28] 2024-12-10 12:53:35.718 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.736 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.766 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_CLIENT_HELLO [2024-12-11 09:08:28] 2024-12-10 12:53:35.792 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(919): => write client hello [2024-12-11 09:08:28] 2024-12-10 12:53:35.820 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): dumping 'client hello, random bytes' (32 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.848 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): 0000: 7b 5a 55 53 71 4d 5d ec 7e 88 19 f8 fc b7 72 b4 {ZUSq M].~.....r. [2024-12-11 09:08:28] 2024-12-10 12:53:35.878 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): 0010: d1 7e 13 df 21 b8 b6 3f 38 36 d4 63 19 f4 27 89 .~..! ..?86.c..'. [2024-12-11 09:08:28] 2024-12-10 12:53:35.904 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(511): dumping 'session id' (0 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.930 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(369): client hello, add ciphersuite: c02b, TLS-ECDHE-ECDSA-WITH-AES -128-GCM-SHA256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.962 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(387): adding EMPTY_RENEGOTIATION_INFO_SCSV [2024-12-11 09:08:28] 2024-12-10 12:53:35.988 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(396): client hello, got 2 cipher suites [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(230): client hello, adding supported_groups extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(249): got supported group(0017) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(281): NamedGroup: secp256r1 ( 17 ) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(249): got supported group(0018) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(281): NamedGroup: secp384r1 ( 18 ) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(301): dumping 'Supported groups extension' (6 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(301): 0000: 00 04 00 17 00 18 ..... . [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9593): adding signature_algorithms extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9613): got signature scheme [403] ecdsa_secp256r1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9622): sent signature scheme [403] ecdsa_secp256r1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9613): got signature scheme [401] rsa_pkcs1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9622): sent signature scheme [401] rsa_pkcs1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(105): client hello, adding supported_point_formats extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(688): client hello, total extension length: 26 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): dumping 'client hello extensions' (26 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): 0000: 00 1a 00 0a 00 06 00 04 00 17 00 18 00 0d 00 06 ..... ........... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): 0010: 00 04 04 03 04 01 00 0b 00 02 ..... ..... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2783): => write handshake message [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2943): => write record [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3027): output record: msgtype = 22, version = [3:3], msglen = 75 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): dumping 'output record sent to network' (80 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0000: 16 03 03 00 4b 01 00 00 47 03 03 7b 5a 55 53 71 ....K.. .G..{ZUSq [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0010: 4d 5d ec 7e 88 19 f8 fc b7 72 b4 d1 7e 13 df 21 M].~... ..r..~..! [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0020: b8 b6 3f 38 36 d4 63 19 f4 27 89 00 00 04 c0 2b ..?86.c ..'.....+ [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0030: 00 ff 01 00 00 1a 00 0a 00 06 00 04 00 17 00 18 ....... ......... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0040: 00 0d 00 06 00 04 04 03 04 01 00 0b 00 02 01 00 ....... ......... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3080): <= write record [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2904): <= write handshake message [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(1012): <= write client hello [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:36.008 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2367): message length: 80, out_left: 80 [2024-12-11 09:08:28] 2024-12-10 12:53:36.044 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2374): ssl->f_send() returned 80 (-0xffffffb0) [2024-12-11 09:08:28] 2024-12-10 12:53:36.082 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2401): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:36.114 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_SERVER_HELLO [2024-12-11 09:08:28] 2024-12-10 12:53:36.142 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1193): => parse server hello [2024-12-11 09:08:28] 2024-12-10 12:53:36.170 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4189): => read record [2024-12-11 09:08:28] 2024-12-10 12:53:36.196 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:28] 2024-12-10 12:53:36.226 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 0, nb_want: 5 [2024-12-11 09:08:28] 2024-12-10 12:53:36.256 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 0, nb_want: 5 [2024-12-11 09:08:28] 2024-12-10 12:53:36.284 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4617): <= handshake [2024-12-11 09:08:28] 2024-12-10 12:53:36.314 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.344 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.374 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.400 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:37.380 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:37.382 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:30] 2024-12-10 12:53:37.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:30] 2024-12-10 12:53:37.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:30] 2024-12-10 12:53:38.392 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:30] 2024-12-10 12:53:38.394 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:38.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:31] 2024-12-10 12:53:38.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.346 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4606): => handshake [2024-12-11 09:08:31] 2024-12-10 12:53:39.346 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.348 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.348 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_SERVER_HELLO [2024-12-11 09:08:31] 2024-12-10 12:53:39.350 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1193): => parse server hello [2024-12-11 09:08:32] 2024-12-10 12:53:39.350 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4189): => read record [2024-12-11 09:08:32] 2024-12-10 12:53:39.352 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.378 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 0, nb_want: 5 [2024-12-11 09:08:32] 2024-12-10 12:53:39.404 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 0, nb_want: 5 [2024-12-11 09:08:32] 2024-12-10 12:53:39.430 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2318): ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) [2024-12-11 09:08:32] 2024-12-10 12:53:39.460 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2340): <= fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.490 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3855): dumping 'input record header' (5 bytes) [2024-12-11 09:08:32] 2024-12-10 12:53:39.516 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3855): 0000: 15 03 03 00 02 ..... [2024-12-11 09:08:32] 2024-12-10 12:53:39.542 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3857): input record: msgtype = 21, version = [0x303], msglen = 2 [2024-12-11 09:08:32] 2024-12-10 12:53:39.570 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.598 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 5, nb_want: 7 [2024-12-11 09:08:32] 2024-12-10 12:53:39.630 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 5, nb_want: 7 [2024-12-11 09:09:51] 2024-12-10 12:53:39.656 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2318): ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) [2024-12-11 09:09:51] 2024-12-10 12:53:39.688 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2340): <= fetch input [2024-12-11 09:09:51] 2024-12-10 12:53:39.722 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3964): dumping 'input record from network' (7 bytes) [2024-12-11 09:09:52] 2024-12-10 12:53:39.756 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3964): 0000: 15 03 03 00 02 02 28 ......( [2024-12-11 09:09:55] 2024-12-10 12:53:39.782 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(5092): got an alert message, type: [2:40] [2024-12-11 09:09:55] 2024-12-10 12:53:39.810 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(5099): is a fatal alert message (msg 40) [2024-12-11 09:09:55] 2024-12-10 12:54:59.004 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4244): mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) [2024-12-11 09:09:55] 2024-12-10 12:54:59.036 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1197): mbedtls_ssl_read_record() returned -30592 (-0x7780) [2024-12-11 09:09:55] 2024-12-10 12:54:59.062 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4617): <= handshake [2024-12-11 09:09:55] 2024-12-10 12:54:59.094 [Debug] [External] mbedtls_ssl_handshake failed: -30592 [2024-12-11 09:09:55] 2024-12-10 12:55:02.000 [Debug] [Http] Download failed: httpc_result 4, srv_resp 0, err -15 ====================== Many thanks in advance! Best regards, Bas

7 months

1
0
0 0

C448 according RFC7748?

by Tom Strolch

Hello all, I want to use mbedtls-functions for "Shared Secret" according ECDH with C448. First I want to check the test vectors mentioned in RFC7748 (chapter 6.2). But it fails in function mbedtls_ecdh_compute_shared(...) with return value -0x4C80 MBEDTLS_ERR_ECP_INVALID_KEY (please see code below) But up to now I can't find the root cause. Is there a similar example available? Regards, Tom // Alice's private key static const unsigned char alice_private_key[] = { 0x77, 0x07, 0x6d, 0x0a, 0x73, 0x18, 0xa5, 0x7d, 0x3c, 0x16, 0xc1, 0x72, 0x51, 0xb2, 0x66, 0x45, 0xdf, 0x4c, 0x2f, 0x87, 0xeb, 0xc0, 0x99, 0x2a, 0xb1, 0x77, 0xfb, 0xa5, 0x1d, 0xb9, 0x2c, 0x2a }; // Bob's private key static const unsigned char bob_private_key[] = { 0x5d, 0xab, 0x08, 0x7e, 0x62, 0x4a, 0x8a, 0x4b, 0x79, 0xe1, 0x7f, 0x8b, 0x83, 0x80, 0x0e, 0xe6, 0x6f, 0x3b, 0xb1, 0x29, 0x26, 0x18, 0xb6, 0xfd, 0x1c, 0x2f, 0x8b, 0x27, 0xff, 0x88, 0xe0, 0xeb }; int main() { mbedtls_ecdh_context ecdh; unsigned char shared_secret[32]; size_t olen; int ret; mbedtls_ecdh_init(&ecdh); // Load Bob's private key ret = mbedtls_ecp_group_load(&ecdh.grp, MBEDTLS_ECP_DP_CURVE25519); if (ret != 0) { printf("Failed to load group\n"); return 1; } ret = mbedtls_mpi_read_binary(&ecdh.d, bob_private_key, sizeof(bob_private_key)); if (ret != 0) { printf("Failed to read private key\n"); return 1; } // Compute the shared secret ret = mbedtls_ecdh_compute_shared(&ecdh.grp, &ecdh.z, &ecdh.Qp, &ecdh.d, mbedtls_ctr_drbg_random, NULL); if (ret != 0) { printf("Failed to compute shared secret\n"); return 1; } ... Test vector: Alice's private key, a: 9a8f4925d1519f5775cf46b04b5800d4ee9ee8bae8bc5565d498c28d d9c9baf574a9419744897391006382a6f127ab1d9ac2d8c0a598726b Alice's public key, X448(a, 5): 9b08f7cc31b7e3e67d22d5aea121074a273bd2b83de09c63faa73d2c 22c5d9bbc836647241d953d40c5b12da88120d53177f80e532c41fa0 Bob's private key, b: 1c306a7ac2a0e2e0990b294470cba339e6453772b075811d8fad0d1d 6927c120bb5ee8972b0d3e21374c9c921b09d1b0366f10b65173992d Bob's public key, X448(b, 5): 3eb7a829b0cd20f5bcfc0b599b6feccf6da4627107bdb0d4f345b430 27d8b972fc3e34fb4232a13ca706dcb57aec3dae07bdc1c67bf33609 Their shared secret, K: 07fff4181ac6cc95ec1c16a94a0f74d12da232ce40a77552281d282b b60c0b56fd2464c335543936521c24403085d59a449a5037514a879d

7 months, 1 week

1
0
0 0

Migrate LWIP mbed TLS port to Mbed TLS 3.6.2 (or later)

by Bas Prins

Dear Mbed TLS team, I am trying to integrate Mbed TLS in our platform: - nxp imx rt 1024 CPU (arm based) - FreeRTOS (10.6) - Lwip (2.2) - Mbed TLS (3.6.2) LWIP supports Mbed TLS when adding defines in their configuration: /* ---------- TLS ------------------------- */ #define LWIP_ALTCP 1 #define LWIP_ALTCP_TLS 1 #define LWIP_ALTCP_TLS_MBEDTLS 1 But, unfortunately this supports an older version of Mbed TLS (I believe 2.2.x). When I try to compile against the Mbed TLS 3.6.2 libraries, I get a bunch of compiler warnings / errors. Most of them are mentioned in the migration guide, but even then, I have a hard time figuring out how to resolve them "the right way". 1. Private fields The migration guide <https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/3.0-migration-gui…> explains that most structs are now considered private. 1.1: The altcp_mbed module in LWIP relies on the *out_left* field of the *ssl context* struct. /* calculate TLS overhead part to not send it to application */ overhead = state->overhead_bytes_adjust + state->ssl_context.out_left; I am correct that this field is simply not exposed through accessor functions? I can find functions like mbedtls_ssl_get_avail, so I would expect something like mbedtls_ssl_get_bytes_to_write or something like that? 1.2: The altcp_mbed module in LWIP relies on the *start* field of the *ssl session* struct. err_t altcp_tls_set_session(struct altcp_pcb *conn, struct altcp_tls_session *session) { if (session && conn && conn->state) { altcp_mbedtls_state_t *state = (altcp_mbedtls_state_t *)conn->state; int ret = -1; * if (session->data.start)* ret = mbedtls_ssl_set_session(&state->ssl_context, &session->data); return ret < 0 ? ERR_VAL : ERR_OK; } return ERR_ARG; } I also don't know how to obtain this field "the right way". I know this is a bad idea, but it's all I got if (session->data.*private_start)* ... 2. parse key expects a RNG function This is also explained in the migration guide: *Some functions gained an RNG parameterThis affects users of the following functions: `mbedtls_ecp_check_pub_priv()`,`mbedtls_pk_check_pair()`, `mbedtls_pk_parse_key()`, and`mbedtls_pk_parse_keyfile()`.You now need to pass a properly seeded, cryptographically secure RNG whencalling these functions. It is used for blinding, a countermeasure againstside-channel attacks.* Can you please give me some guidance here? I looked for examples in Mbed TLS repo and ended up with this (bold parts are added, using the key_app.c in your repo as leading example): * mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; mbedtls_entropy_init(&entropy); mbedtls_ctr_drbg_init(&ctr_drbg); if ((ret = mbedtls_ctr_drbg_seed( &ctr_drbg, mbedtls_entropy_func, &entropy, privkey, privkey_len)) != 0) { // TODO: handle error } * ret = mbedtls_pk_parse_key( conf->pkey, privkey, privkey_len, privkey_pass, privkey_pass_len, *mbedtls_ctr_drbg_random, &ctr_drbg*); 3. The altcp_mbed module in LWIP relies on mbedtls_ssl_flush_output The altcp_mbed module had an include on ssl internal. #include "mbedtls/ssl_internal.h" /* to call mbedtls_flush_output after ERR_MEM */ This header seems no longer part of the library. But the prototype of the function is now part of ssl_misc.h, but I don't think I am supposed to rely on this header either. I have a couple of options: - ignore the compiler warning /home/dev_container/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c:535:5: warning: implicit declaration of function 'mbedtls_ssl_flush_output'; did you mean 'mbedtls_ssl_tls_prf'? [-Wimplicit-function-declaration] 535 | mbedtls_ssl_flush_output(&state->ssl_context); - copy paste the declaration in the LWIP source file - Or.... don't flush any buffers managed by Mbed TLS in the first place? For the last one, I could really use your input. Can you say anything meaningful about the flush (line in bold) In the below function, Is it mandatory? Or can I trust the Mbed TLS will flush the output buffer whenever it needs to get flushed? /** Sent callback from lower connection (i.e. TCP) * This only informs the upper layer the number of ACKed bytes. * This now take care of TLS added bytes so application receive * correct ACKed bytes. */ static err_t altcp_mbedtls_lower_sent(void *arg, struct altcp_pcb *inner_conn, u16_t len) { struct altcp_pcb *conn = (struct altcp_pcb *)arg; LWIP_UNUSED_ARG(inner_conn); /* for LWIP_NOASSERT */ if (conn) { int overhead; u16_t app_len; altcp_mbedtls_state_t *state = (altcp_mbedtls_state_t *)conn->state; LWIP_ASSERT("state", state != NULL); LWIP_ASSERT("pcb mismatch", conn->inner_conn == inner_conn); /* calculate TLS overhead part to not send it to application */ mbedtls_ssl_get_bytes_avail(&state->ssl_context); overhead = state->overhead_bytes_adjust + state->ssl_context.private_out_left; if ((unsigned)overhead > len) { overhead = len; } /* remove ACKed bytes from overhead adjust counter */ state->overhead_bytes_adjust -= len; /* try to send more if we failed before (may increase overhead adjust counter) */ *mbedtls_ssl_flush_output(&state->ssl_context); // Does it make sense this LWIP port is responsible for flushing here??* /* remove calculated overhead from ACKed bytes len */ app_len = len - (u16_t)overhead; /* update application write counter and inform application */ if (app_len) { state->overhead_bytes_adjust += app_len; if (conn->sent) return conn->sent(conn->arg, conn, app_len); } } return ERR_OK; } After applying the changes I mentioned above, the software compiles against Mbed TLS. I haven't dared to run anything, I just want to enjoy this short moment where I have the feeling I achieved something before runtime errors ruin my day :). Many thanks in advance for any reply! Best regards, Bas [image: image.png]

7 months, 1 week

1
0
0 0

MbedTLS 2.5 vs MbedTLS 3.6

by Michael Khoyilar

Hi Team I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks Michael

7 months, 1 week

5
5
0 0

Trying to integrate Mbed TLS (3.6) with LWIP (2.x)

by Bas Prins

Dear Mbed TLS team, I am at the early steps of trying to integrate Mbed TLS with LWIP for our project (imx rt 1024 NXP micro, arm M7, running FreeRTOS and LWIP). I understand the basics of TLS, but I am far from an expert. Let me first apologise for the lengthy first email. I am afraid to leave out details. Feel free to skip directly to the end marked with: ============================= My questions: ============================= Some background / translation of how I think it (should) work: From a distance, I understand that LWIP has an abstraction layer on their TCP module, which can be used to integrate Mbed TLS. In fact, LWIP already did this, all I need to do is enable some directives (LWIP_ALTCP_TLS and LWIP_ALTCP_TLS_MBEDTLS). The implemented integration assumes a somewhat older version of Mbed TLS, so I have to adjust a couple to cope with the breaking changes from Mbed TLS 2.x to Mbed TLS 3.6.2. But other than that, integrating Mbed TLS would mean: - figure out which options i want to enable in Mbed TLS - cross compile it for our arm toolchain - extend our build scripts to compile against 3 static Mbed TLS libraries - figure out how to read the CA certificates, and provide them to Mbed TLS - test and fail, and hopefully be man enough to solve the challenges ahead... I haven't achieved much yet, but at least I managed to compile Mbed TLS with our toolchain and recompile our project against the linked libraries. This steps fails though, I get a bunch of linker errors : [100%] Linking CXX executable app.axf /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_encrypt_buf': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:1211:(.text.mbedtls_ssl_encrypt_buf+0x1b4): undefined reference to `mbedtls_cipher_auth_encrypt_ext' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_decrypt_buf': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:1638:(.text.mbedtls_ssl_decrypt_buf+0x180): undefined reference to `mbedtls_cipher_auth_decrypt_ext' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_transform_free': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:6213:(.text.mbedtls_ssl_transform_free+0x14): undefined reference to `mbedtls_cipher_free' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:6214:(.text.mbedtls_ssl_transform_free+0x1e): undefined reference to `mbedtls_cipher_free' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_transform_init': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:1028:(.text.mbedtls_ssl_transform_init+0x18): undefined reference to `mbedtls_cipher_init' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:1029:(.text.mbedtls_ssl_transform_init+0x22): undefined reference to `mbedtls_cipher_init' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_get_mode_from_ciphersuite': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:2453:(.text.mbedtls_ssl_get_mode_from_ciphersuite+0x12): undefined reference to `mbedtls_cipher_info_from_type' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_parse_finished': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:8680:(.text.mbedtls_ssl_parse_finished+0xac): undefined reference to `mbedtls_ct_memcmp' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `ssl_tls12_populate_transform': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:8878:(.text.ssl_tls12_populate_transform+0xa6): undefined reference to `mbedtls_cipher_info_from_type' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9136:(.text.ssl_tls12_populate_transform+0x454): undefined reference to `mbedtls_cipher_setup' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9142:(.text.ssl_tls12_populate_transform+0x476): undefined reference to `mbedtls_cipher_setup' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9148:(.text.ssl_tls12_populate_transform+0x4a8): undefined reference to `mbedtls_cipher_setkey' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9155:(.text.ssl_tls12_populate_transform+0x4da): undefined reference to `mbedtls_cipher_setkey' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: CMakeFiles/app.dir/home/dev/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c.obj: in function `altcp_mbedtls_sndbuf': /home/dev/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c:1192:(.text.altcp_mbedtls_sndbuf+0x7e): undefined reference to `mbedtls_ssl_get_max_frag_len' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls12_server.c.obj): in function `ssl_parse_client_psk_identity': /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_server.c:3638:(.text.ssl_parse_client_psk_identity+0xb6): undefined reference to `mbedtls_ct_memcmp' The distinct list undefined references of the above: undefined reference to `mbedtls_cipher_auth_encrypt_ext' undefined reference to `mbedtls_cipher_auth_decrypt_ext' undefined reference to `mbedtls_cipher_free' undefined reference to `mbedtls_cipher_init' undefined reference to `mbedtls_cipher_info_from_type' undefined reference to `mbedtls_ct_memcmp' undefined reference to `mbedtls_cipher_setup' undefined reference to `mbedtls_cipher_setup' undefined reference to `mbedtls_cipher_setkey' undefined reference to `mbedtls_cipher_setkey' undefined reference to `mbedtls_ssl_get_max_frag_len' All except the last one are coming from Mbed TSL internally, so I *guess* this means I am missing options? Or maybe I am still having too many? The last one is called from the LWIP integration of Mbed TLS, and I could "sweep this under the carpet" by disabling "MBEDTLS_SSL_MAX_FRAGMENT_LENGTH". But I haven't looked further in what I cause if I do not support "RFC 6066 max_fragment_length extension in SSL" My Mbed TLS configuration: I followed the suggestion of your documentation, and went for a minimal example configuration. Pure on intuition, I went for "config-ccm-psk-dtls1_2.h". Because the file name suggests it brings TSL 1.2 which is basically all I need. I think. I did had to make the following changes in order to be able to compile it: 1. Comment out two defines in order to get rid of module requiring "windows or unix" //#define MBEDTLS_NET_C //#define MBEDTLS_TIMING_C 2. Add a define, again to get rid of the compiler error "require windows or unix" #define MBEDTLS_NO_PLATFORM_ENTROPY After applying these small changes to the include/mbedtls/mbedtls_config.h I was able to cross compile (and link) Mbed TLS with arm-none-eabi toolchain. Once I adjusted the build scripts to lnk against the Mbed TLS static libraries, I finally ended up with the earlier mentioned linker errors. ============================= My questions: ============================= 1. Does my starting point configuration make sense? As mentioned earlier, pure intuition made me try the "config-ccm-psk-dtls1_2.h" configuration example, which after some modifications compiled and produced 3 static libraries. but, this bit in the example header worries me a bit: * Distinguishing features: * - Optimized for small code size, low bandwidth (on an unreliable transport), * and low RAM usage. * - No asymmetric cryptography (no certificates, no Diffie-Hellman key * exchange). * - Fully modern and secure (provided the pre-shared keys are generated and * stored securely). * - Very low record overhead with CCM-8. * - Includes several optional DTLS features typically used in IoT. What does "no asymmetric cryptography" exactly mean? Isn't that the pure basis of TLS altogether? If I want to achieve HTTPS using TLS, is this a good starting point? 2. Undefined references: wrong configuration, or should I supply some of the implementations? As mentioned before, I have quite a few linking errors related to the cipher module. I tried to find answers in the documentation, but came up empty. I assume (again...) that I should be able to get rid of these linking errors by enabling more features in Mbed TLS. But I honestly get lost in #define's. And maybe it's documented somewhere, but I couldn't find it. 3. Root CA provided by me? I assume I *need* to provide at least one root CA for Mbed TLS to be able to verify the public key provided by the server, at some point, right? I would expect some callback I need to implement where such a root CA was read (in my case, i would have to read if from flash). Am I misunderstanding Mbed TLS on this aspect also? Or did I just miss the obvious spot where to Mbed TLS requests a root CA? 4. More examples available for typical microcontroller projects (FreeRTOS/LWIP)? My experience so far is: - Mbed TLS is well documented - LWIP is no longer actively maintained, and lacks documentation in general - Google finds a painful amount of LWIP/TLS integrations which are based on really old implementations of both, which does more harm than good for me - Chat GPT knows everything, even when it doesn't, which is a really great recipe to get on the wrong track... It doesn't seem rather helpful on my integration questions for Mbed TLS/LWIP. Disclaimer: could be that my lack of knowledge is causing gpt to come up with wrong answers of course... I understand that my email is (too?) long, and that the chance somebody will actually find the time to help me out is limited. I expect nothing, I hope for everything :) ANY help is more than welcome. Good references, links to official documentation I missed, or in the best case: answers to my questions/uncertainties. Many thanks in advance. Best regards, Bas

7 months, 1 week

2
1
0 0

TLS 1.3 and brainpool curves

by Maren Konrad

Dear MbedTLS maintainers, we are already using MBedTLS, however, we recently enabled TLS 1.3 and found that our certificates doesn't work anymore, because they are brainpoolP256r1 (https://datatracker.ietf.org/doc/html/rfc8734). So the question would be, if I missed any configuration to enable the usage of brainpool curves (which are working for TLS 1.2) or if there are any plans, that these are getting supported by MBedTLS 3.6.x? Best regards, Maren Konrad

7 months, 4 weeks

2
1
0 0

Confirm if there is an upgrade to the PKCS#1 V2.2 standard.

by Elva Huang

Dear mbedtls platform, I would like to inquire whether the PKCS#1 standard in the source code of mbedtls V2.28.2 has been upgraded to V2.2. From which version does mbedtls start supporting PKCS#1 v2.2? Looking forward to your reply, thank you. Elva Huang | SW Engineer Tel: 18150372635 Email:elva.huang@robosense.cn<elva.huang(a)robosense.cn> 深圳市 - 南山区 - 速腾聚创产品中心 [image]<http://www.robosense.cn/> [image]<https://www.linkedin.com/company/13232246/admin/>[image]<https://twitter.com/RoboSenseLiDAR>[image]<https://www.facebook.com/RoboSenseLiDAR/>[image]<https://www.youtube.com/channel/UCYCK8j678N6d_ayWE_8F3rQ>

8 months

2
1
0 0

How to export mbedtls_snprintf ?

by Gal Rosen

Hi, I am trying to build lief which is dependent on mbedtls as a static library. I am using conan recipe to build using cmake. The build of the library succeeded, however later while trying to build my own application and link with lief I get the following error: LIEF.lib(x509.obj) : error LNK2001: unresolved external symbol mbedtls_snprintf What do I do wrong? Or should I configure something while building the mbedtls library ? Thanks, Gal.

8 months, 1 week

1
0
0 0

Question about contribution of AES hardware support for RISC-V

by Rick Chen

Dear Mbed TLS maintainers, I have surveyed Mbed TLS and know that it has features which can improve AES block cipher performance by hardware instructions instead of SW implementation e.q., AESCE of ARMV8 and AESNI of INTEL. AS far as I know about RISC-V Cryptography extension(Zkne and Zknd), it also supports relevant AES instructions which can accelerate aes key schedule, encryption and decryption process. (https://tools.cloudbear.ru/docs/riscv-crypto-spec-scalar-1.0.0-rc6-20211012…) I want to ask for your opinions and agreement. Is there any willingness to accept this RISC-V accelerated feature idea and contribution to Mbed TLS ? If you agree with it, I would like to prepare a pull request for you to review. Sincerely, Rick

8 months, 3 weeks

2
1
0 0

Mbed TLS 3.6.2 release

by David Horstmann

Dear Mbed TLS users, We have released Mbed TLS version 3.6.2. This release provides a security fix for an out-of-bounds write vulnerability in the pkwrite module. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.2 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, David Horstmann Mbed TLS developer

8 months, 4 weeks

1
0
0 0

Checking that RSA key and issuer certificate match using mbedTLS 3.x

by Fabian Keil

Hi, I'm currently working on adding mbedTLS 3.x support for Privoxy [0]. Everything seems to be working but I ifdef'ed out the following code in [1] that worked with mbedTLS 2.28.8: /* * Check if key and issuer certificate match */ if (!mbedtls_pk_can_do(&issuer_cert.pk, MBEDTLS_PK_RSA) || mbedtls_mpi_cmp_mpi(&mbedtls_pk_rsa(issuer_cert.pk)->N, &mbedtls_pk_rsa(*issuer_key)->N) != 0 || mbedtls_mpi_cmp_mpi(&mbedtls_pk_rsa(issuer_cert.pk)->E, &mbedtls_pk_rsa(*issuer_key)->E) != 0) { log_error(LOG_LEVEL_ERROR, "Issuer key doesn't match issuer certificate"); ret = -1; goto exit; } As N and E are private now it no longer compiles. Is there a way to implement the check with mbedTLS 3.x? My impression is that the sanity check is overly cautious and we don't have equivalent code for OpenSSL and wolfSSL but I'm curious. Thanks, Fabian [0] <https://www.privoxy.org/> [1] <https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob;f=ssl.c;h=e8007cd9adad…>

9 months

2
2
0 0

Client Certificate Request Question

by Michael Reutman

Hello, I'm running into an issue with using Mbed-TLS on an embedded device of ours and I'm curious if anyone would be able to point me in the right direction. If this is the wrong channel for general use questions, let me know and I'll search elsewhere. As a forewarning, I'm still getting my bearings around the nuts and bolts of Mbed-TLS and network security; apologies if I misstate something or jumble things up. Our device uses Mbed-TLS 3.0.0; ideally I'd like to upgrade this to a newer version, but this version was included in a SDK package for our device and I'd like to get some basic functionality proven out first before trying to reintegrate a newer version into the rest of provided code. The current goal is to get our device to serve a web page over HTTPS with TLS. What we currently see is that the initial hello client and server messages are exchanged without issue, but the connection is rejected after the server requests a certificate from the client. In some browsers, this opens a prompt where you can select a given certificate on the machine; in others, it skips this prompt and sends a response back with an empty certificate. In both instances, the server will return an error and deny the connection. This seems like some sort of user configuration error, given your average web page served over HTTPS on the internet avoids making this request. The literature I've been able to find so far also seems to suggest this request is entirely optional. Is there some option I'm overlooking that makes the server skip asking the client for its certificate and lets connection continue on? Michael Reutman Senior Embedded Software Engineer NovaTech Automation 261 Brodhead Rd. Bethlehem, PA 18017 novatechautomation.com<http://www.novatechautomation.com/> | NovaTechLinkedIn<https://www.linkedin.com/company/565017> NovaTech Automation is Net Zero committed. #KeepItCool<https://www.keepitcool.earth/> Receipt of this email implies compliance with our terms and conditions<https://www.novatechautomation.com/email-terms-conditions>.

9 months, 1 week

2
2
0 0

Problem when parsing certificate without Distinguished Name

by Diego Santos

Hi, I'm trying to parse this DER encoded certificate in hex format: 3082018230820128a003020102020900f3b305f55622cfdf300a06082a8648ce3d04030230003020170d3735303130313030303030305a180f34303936303130313030303030305a30003059301306072a8648ce3d020106082a8648ce3d0301070342000458f7e9581748ff9bdd933b655cc0e5552a1248f840658cc221dec2186b5a2fe4641b86ab7590a3422cdbb1000cf97662f27e5910d7569f22feed8829c8b52e0fa38188308185308182060a2b0601040183a25a01010101ff0471306f042508021221026b053094d1112bce799dc8026040ae6d4eb574157929f1598172061f753d9b1b04463044022040712707e97794c478d93989aaa28ae1f71c03af524a8a4bd2d98424948a782302207b61b7f074b696a25fb9e0059141a811cccc4cc28042d9301b9b2a4015e87470300a06082a8648ce3d04030203480030450220143ae4d86fdc8675d2480bb6912eca5e39165df7f572d836aa2f2d6acfab13f8022100831d1979a98f0c4a6fb5069ca374de92f1a1205c962a6d90ad3d7554cb7d9df4 This certificate is part of a simple test for this specification https://github.com/libp2p/specs/blob/master/tls/tls.md I'm using this https://github.com/status-im/nim-mbedtls Nim language library wrapper for mbedtls. I don't know the mbedtls version exactly, but the lib is based on this commit https://github.com/Mbed-TLS/mbedtls/tree/09d23786f6fdcb4dfa88aad30c8767bd27…. In my code I use: proc parseUnverified*(derInput: seq[byte]) = var crt: mbedtls_x509_crt mbedtls_x509_crt_init(addr crt) var ret = mbedtls_x509_crt_parse_der(addr crt, unsafeAddr derInput[0], derInput.len.uint) if ret != 0: raise newException(Exception, "Failed to parse certificate, error code: " & $ret) which is a straightforward version of the C code, but ti fails with: Failed to parse certificate, error code: -9186 [Exception] It seems the problem is because the certificate doesn't have the Distinguished Name set. Does it make sense? If this is really the cause of the problem, is there any workaround? Regards.

9 months, 2 weeks

1
0
0 0

Need Info : mbedtls_x509_get_sig_alg API

by Satya Prakash Prasad

Hi, We were using old MBed TLS version 2.19.1 and existing trusted CA certificates were working fine in that release. Recently we upgraded to 3.6.0 and see that now certificate parsing is returning -ox262e value from function mbedtls_x509_get_sig_alg cause of which handshake is not even initiated. Can you please let us know what can cause such an issue and remedy the same? Regards, Prakash

9 months, 2 weeks

1
2
0 0

2025

2024

2023

2022

2021

2020

mbed-tls