July 2022 - mbed-tls - lists.trustedfirmware.org

by Subramanian Gopi Krishnan

Hi, I have an inhouse developed secure authentication program that uses certificate for authentication. I have used mbedtls library for the x.509 certificate verification purpose. In our custom PKI we have only three level of certificates, Root-CA -> Intermediate-CA -> Device-Cert. The embedded device has very limited memory, so instead of sending whole certificate chain, the devices communicates intermediate_CA and device cert (in der format base64 encoded) in separate packet. Root-CA will be available on node as trusted-ca. Intermediate is verified against Root; then device cert is verified against intermediate. The problem is, the poc developed on linux platform is working fine - but on embedded platform I encounter either 0x3b00(parsing failed) or 0x2700(with flag 8). Also the error code are inconsistent. I verified the integrity of packet with certificate using crc16. So no chance of certificate getting corrupted. Also verified the certificate's base64 format integrity using crc16. All certificates are sha256WithRSAEncryption; RSA Public-Key: (4096 bit) Attached config.h on target platform for reference - could you help me if anything wrong with configuration. While trying to trace, the flag was set from x509_crt.c from below code. /* No parent? We're done here */ if( parent == NULL ) { printf("NO_PARENT\r\n"); *flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED; return( 0 ); } Any clue would be helpful. Thanks, Gopi Krishnan

7 months, 2 weeks

2
1
0 0

Question about handshake MTU

by Martin Man

Hi guys, I use mbedtls for years (since 2.10 IIRC) upgrading to latest available as time goes by. For DTLS that is. I remember a case in the past where a link would have a small MTU (around 500 bytes) and I had to tune ssl_context.handshake.mtu to a lower value to successfully complete handshakes. I do not remember exactly why, but I did not want to actually restrict maximum value via mbedtls_ssl_set_mtu, maybe it was even ignored back then for handshakes… but Now when working on migration to 3.2.1 (gave some time to 3x releases to stabilize) I noticed that the whole ssl_context.handshake member is now private and inaccessible, which I guess is fine. Could somebody with more knowledge of the code recommend what is the best strategy for DTLS app where MTU may not always be 1400? thanks a lot for your time, Martin

2 years, 2 months

4
7
0 0

HMAC and CMAC Verification

by Ahmed Mohammed

Hello, I am wondering if there are APIs for Hmac and Cmac verification? from md.h and cmac.h, Hmac and Cmac generation functionalities are provided in a single and streaming approach. But is there a plan to add verification APIs for future releases maybe? Kind regards, Ahmed Mohammed

2 years, 3 months

2
1
0 0

User configuration

by Ahmed Mohammed

Hello, What is the difference between these two macros in include/mbedtls/build_info.h: MBEDTLS_CONFIG_FILE MBEDTLS_USER_CONFIG_FILE In other words, why would I have two different user configuration files? Or I misunderstand the difference between such files. Kind regards, Ahmed Mohammed

2 years, 3 months

2
1
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 4 months

1
0
0 0

totally beginner question...

by boddeke＠mac.com

hello, we are testing a secure communication and got example code that uses the mbed-tls library. i am using the online keil studio with mbed.org: created a new project (compiles fine) and added in the mbed-tls library but this already gives compile errors. see below. i am using the latest greatest versions (mbed-os 6.16.0 and mbedtls-3.2.1) and tried some older versions. all seem to give the same problems. see below. i have tried commenting out MBEDTLS_HAVE_TIME in mbedtls_config.h but that does not seem to make any difference tried different target boards, also no difference any help is greatly appreciated! thanks frank Build started Using toolchain ARMC6 profile {'ENV': {'ARMLMD_LICENSE_FILE': '8224@10.10.101.194:8224@10.10.109.222'}, 'PATHS': {'ARMC6_PATH': '/opt/ARMCompiler6.15.13/bin/', 'ARM_PATH': '/opt/armcc5_06_u6/'}, 'common': ['-c', '--gnu', '-O3', '-Otime', '--split_sections', '--apcs=interwork'], 'cxx': ['--cpp', '--no_rtti'], 'COMPILE_C_AS_CPP': False, 'NEW_SCAN_RESOURCES': True} scan /tmp/chroots/ch-59110c86-ee99-44c4-9ef0-79f3efde74a7/src scan /tmp/chroots/ch-59110c86-ee99-44c4-9ef0-79f3efde74a7/extras/mbed-os.lib compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Config/RTX_Config.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/TOOLCHAIN_ARM/TARGET_RTOS_M4_M7/irq_cm4f.S compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_evflags.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_lib.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_mempool.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Library/cmsis_os1.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_evr.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_memory.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_delay.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_msgqueue.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_kernel.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_mutex.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_semaphore.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_system.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/Source/os_systick.c compile mbed-os/cmsis/CMSIS_5/CMSIS/TARGET_CORTEX_M/Source/mbed_tz_context.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_timer.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/Source/os_tick_ptim.c compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_thread.c "time.h included in a configuration without MBEDTLS_HAVE_TIME" unknown type name 'time_t'; did you mean 'size_t'? unknown type name 'time_t'; did you mean 'size_t'? unknown type name 'time_t'; did you mean 'size_t'? compile mbed-os/cmsis/device/rtos/source/mbed_rtos_rtx.c In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:107: /src/mbedtls/tests/include/baremetal-override/time.h:18:2: error: "time.h included in a configuration without MBEDTLS_HAVE_TIME" #error "time.h included in a configuration without MBEDTLS_HAVE_TIME" ^ In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21: /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:669:5: error: unknown type name 'time_t'; did you mean 'size_t'? time_t st_atime; ///< Time of last access ^~~~~~ size_t /opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here typedef unsigned int size_t; /* see <stddef.h> */ ^ In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21: /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:670:5: error: unknown type name 'time_t'; did you mean 'size_t'? time_t st_mtime; ///< Time of last data modification ^~~~~~ size_t /opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here typedef unsigned int size_t; /* see <stddef.h> */ ^ In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23: In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21: /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:671:5: error: unknown type name 'time_t'; did you mean 'size_t'? time_t st_ctime; ///< Time of last status change ^~~~~~ size_t /opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here typedef unsigned int size_t; /* see <stddef.h> */ ^ 4 errors generated. Internal error. Build failed Build failed

2 years, 4 months

1
0
0 0

misc. questions

by Frank Bergmann

Hi all, I have some questions. 1) If you have an established TLS connection (mbed TLS 3.x) and while the connection is up the (server-) certificate expires: Will the connection stay up? Or is a new handshake (with valid cert) REQUIRED? 2) Related to question 1: CAN mbed TLS switch to a new cert on an existing TLS connection? (e.g. by doing another handshake from server OR client side) 3) With 3.x some struct members are now "private". Even if you can allow private access by a define it would be better to use a getter. But for ssl context's "state" I am missing this and also for "p_bio" (to access fd). Is there a chance to get this implemented? BTW - a big "LIKE" for 3.x! I really appreciate the changes. Thank you! kind regards, Frank

2 years, 5 months

5
6
0 0

inline assembly MULADDC_CORE for Cortex M4

by Work Only

Hello everyone, Can anyone share some example code or hints on writing MULADDC_CORE for Cortex M4 in bn_mul.h? With Many thanks! Wade

2 years, 5 months

1
0
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is tomorrow (Monday) at 4:30 PM UK time. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 5 months

1
2
0 0

[Mbed-tls-announce] Mbed TLS 3.2.1 release

by Paul Elliott via Mbed-tls-announce

Hi Mbed TLS users, We have released Mbed TLS version 3.2.1. This release is functionally identical to 3.2.0, but includes a file that was missing from the 3.2.0 release (see https://github.com/Mbed-TLS/mbedtls/issues/6084). Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.2.1). We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, Mbed TLS Team. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

2 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

mbed-tls July 2022