- mbed-tls - lists.trustedfirmware.org

How to use just RSA algorithm in the tls library with stm32

by arman_ilmak＠yahoo.com

Hi I just needed to use rsa.c but its a little complicated. Can anyone help me or give me any document about how i can use it without use of tls. I just saw a doc on tls.mbed.org but the site is not working anymore.

3 years, 2 months

1
0
0 0

psa_crypto_init() asks for entropy even it is not needed for every use case

by heinrich.mueller＠g-ushin.com

Hello, currently, I am evaluating the mbed-tls. I already created some smaller demos regarding AES and RSA. I do so on a PC with cygwin and with Keil micro vision for a NXP S32K144. One demo is just validating some data with a signature and an existing public key. Here is the point that puzzles me a bit. As far as I understand this cybersecurity stuff entropy is not needed for the above use case. Some of my colleagues would agree with me. Once psa_crypto_init() is called on a target NXP S32K144 the function returns PSA_ERROR_INSUFFICIENT_ENTROPY. So far so good https://os.mbed.com/docs/mbed-os/v6.15/porting/entropy-sources.html gives the hints on how to handle this in general but I did not find any information on how to disable the "request for entropy" in a save way once your use case does not need any new secrets. Can you give me a hint why psa_crypto_init() is implemented that way? It may also be that I still have a conceptual understanding problem!? Regards Heico

3 years, 2 months

2
2
0 0

*_ALT vs PSA for HW crypto and upstreaming

by mathieu.rondonneau＠broadcom.com

Hi mbed-tls Team, PSA crypto API for HW acceleration seems pretty new. Question1: is there some reference code or project I could poke around to see how it is being used? Currently I have added (locally) a set of driver to make use of our HW crypto using the *_ALT way (the old way?) and for what I understand, the PSA API is the "new way" to do things. But It is still unclear how vendor do upstream there HW acceleration drivers. If this part is kept in another repo, then the mbedTLS build does not have any "hooks" to pull-in the vendor specific code to build the mbedTLS library with. The current implementation seems to be agnostic to any vendor specific HW so I am wondering if there is a "standard" way for vendor to upstream their mbedTLS HW acceleration code that would be built as part of mbedTLS library. I have posted a similar thread to the "issue" ticket of the mbedtls repo for reference: https://github.com/Mbed-TLS/mbedtls/issues/5975 Thanks for any feedback/pointers/ideas. Regards, -Mathieu

3 years, 2 months

3
2
0 0

LWIP/MbedTLS - any idea if SPI SRAM (block-accessible RAM) could be used for buffers?

by Peter

Hi All, My target has 128k SRAM which has about 60k spare, and 64k CCM which is allocated whole to FreeRTOS stacks etc (its private heap, memory model #4). I am running a simplified HTTP server (for local config etc), which uses fairly minimal RAM (a few k), and an HTTPS/TLS client which uses about 50k (for its private heap). So if both of the above are running concurrently, there is only ~10k RAM left, but it does work, but when TLS is doing its handshake/negotiation (which on a 168MHz 32F417 takes 2-3 seconds) the HTTP server temporarily hangs. Investigating this, it appears that LWIP is running out of buffers during TLS and is rejecting incoming packets. I don't really want to change the CPU to the next one up which has another 64k RAM, because a) I have stock of the 417 and this took about a year to get, b) the design is rock solid and I don't want to tempt fate (there is a lot of subtle hardware usage e.g. DAC ADC DMA timers) even though in theory it should be just alternate function pin changes, c) some versions of the product may not need TLS at all. I have an option of an 8 megabyte SPI-attached RAM https://www.eevblog.com/forum/microcontrollers/lyontek-ly68l6400-8-megabyte… which does work and is not bad at $3 (there are cheaper 128kbyte versions too), but obviously cannot be addressed as normal RAM. The ESP32 can do that but the 32F4 can't. Does anyone know enough about the internals of MbedTLS, or even LWIP, to know whether the memory usage structure lends itself to this kind of "overlay" memory? One can read or write say 1k bytes in 400us, in my target (21MHz SPI with DMA). Obviously this would be horribly inefficient for a byte at a time emulation but perhaps one can switch buffers in and out... Thank you in advance. If somebody knows of a concrete route, I am happy to pay for the time. Regards, Peter

3 years, 2 months

1
0
0 0

Reminder: MBed TLS Technical Forum next Monday

by don.harbin＠linaro.org

Hi All, This is a gentle reminder that the next MBed TLS Tech forum is next Monday 4:30 PM UK time. If you have any topics, please let Dave Rodgman know. :) Best regards, Don MBed TLS Technical Forum Monday Jul 4, 2022 ⋅ 8:30am – 9:30am Mountain Standard Time - Phoenix Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum Time: Oct 25, 2021 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Oct 25, 2021 04:30 PM Nov 22, 2021 04:30 PM Dec 20, 2021 04:30 PM Jan 17, 2022 04:30 PM Feb 14, 2022 04:30 PM Mar 14, 2022 04:30 PM Apr 11, 2022 04:30 PM May 9, 2022 04:30 PM Jun 6, 2022 04:30 PM Jul 4, 2022 04:30 PM Aug 1, 2022 04:30 PM Aug 29, 2022 04:30 PM Sep 26, 2022 04:30 PM Oct 24, 2022 04:30 PM Nov 21, 2022 04:30 PM Dec 19, 2022 04:30 PM Jan 16, 2023 04:30 PM Feb 13, 2023 04:30 PM Mar 13, 2023 04:30 PM Apr 10, 2023 04:30 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT… Meeting ID: 959 6263 5632 Passcode: 018366 One tap mobile +13462487799,,95962635632# US (Houston) +16699009128,,95962635632# US (San Jose) Dial by your location +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 301 715 8592 US (Washington DC) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 959 6263 5632 Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org nnac123(a)gmail.com

3 years, 2 months

1
0
0 0

Is tls.mbed.org down?

by Max Peng

I wanted to access Mbed TLS knowledge Base (https://tls.mbed.org/kb) but fails. It seems tls.mbed.org was down for few days. Is this a known issue?

3 years, 3 months

3
4
1 0

RFC: removing support for DHE in TLS 1.2 in Mbed TLS 4.0?

by Manuel Pegourie-Gonnard

Hi all, We're seeking feedback on our plans regarding support for Finite-Field DHE (also known as FFDH(E), as opposed to the Elliptic Curve version, ECDH(E)). Currently the PSA Crypto API only supports FFDH with named groups, which aligns well with modern cryptographic practice and the needs of TLS 1.3, but less well with TLS 1.2 where arbitrary parameters can be chosen by the server, leading to various interoperability and security issues (see the introduction of RFC 7919, hence the general move to named groups). Some data suggests that FFDH is already seeing very little use (less than 1% of TLS 1.2 traffic) on major websites, and presumably this would be even less when constrained devices are involved, since ECDH is less resource-intensive. So, we are currently planning on removing support for DHE-RSA and DHE-PSK key exchanges in TLS 1.2 in the next major version of Mbed TLS. We would retain support of ECDHE in TLS 1.2, and of DHE (in addition to ECDHE) in TLS 1.3. (Support for FFDH in TLS 1.2 would also be present in the LTS version released around the same time as the next major version.) If you have any objection to this plan, please let us know about your use case and motivations, either by responding to this email, or by commenting on the corresponding github issue: https://github.com/Mbed-TLS/mbedtls/issues/5278 Thank you! Best regards, Manuel for the Mbed TLS team.

3 years, 3 months

1
0
0 0

Verify cert chain

by Subramanian Gopi Krishnan

Hi, I have one root ca, intermediate ca, and device certificate in der format. While am trying to verify one by one as intermediate-ca with root-ca and device cert with intermediate-ca; things work fine. But if I tried to verify like having two context one for ca and one chain. I parse root ca on CA context and intermediate ca and device cert on chain context. Now verification fails with flag 8 error code -0x2700. I have attached verify_der_one_by_one.c it is working without any issue; but verify_der_chain.c is causing the issue stated above. Any help would be appreciated. Thanks, Gopi Krishnan

3 years, 3 months

1
0
0 0

VIA padlock support

by Gilles Peskine

Hello, Mbed TLS supports AES acceleration with VIA Padlock (MBEDTLS_PADLOCK_C). We do not have the hardware to test it, so this should be considered strictly community-maintained. We are making a patch to the AES module which has a small risk of breaking VIA padlock support: https://github.com/Mbed-TLS/mbedtls/pull/5896 . If you are using VIA padlock, please test this change and let us know if something's wrong. On a related note, we intend to drop the Padlock code in the next major version of Mbed TLS (https://github.com/Mbed-TLS/mbedtls/issues/5903). If you care about this feature, please let us know. Best regards, -- Gilles Peskine Mbed TLS developer

3 years, 3 months

1
0
0 0

Clear master secret from mbedtls_ssl_session after handshake is ready

by Maarten Meijer

Hi all, I'm using an mbedTLS server on a CPU with a small memory foot print. In a search to serve as many as possible TLS clients, I found that the mbedtls_ssl_session.master[48] structure member is still in memory after the handshake is over. (I filed an issue to start with, but was quickly directed to this mailing list, thanks to Tom Cosgrove. See Clear master secret from mbedtls_ssl_session after handshake is ready * Issue #5832 * Mbed-TLS/mbedtls (github.com)<https://github.com/Mbed-TLS/mbedtls/issues/5832>) I'm wondering why this is needed. The `master` secret references I can find in the code are either related to the TLS handshake, or to serialization/deserialization. I am wondering whether it makes sense to serialize/deserialize the master secret but I'm not sure if it is a use case to support serialization of ongoing handshake operations. Based on this 2 questions: * Is the master secret relevant when the handshake is over? * Is the master secret really useful in serialization/deserialization? If so, I could use `MBEDTLS_SSL_CONTEXT_SERIALIZATION` in my eventual merge request to keep facilitating this. Looking forward for relevant answers. Thanks in advance, Maarten

3 years, 3 months

2
3
0 0

Invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 2am to 2:50am on Monday 20 times (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

You have been invited to the following event. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 2am to 2:50am on Monday 20 times Mountain Standard Time - Phoenix Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MzE1cHJuZGxwMDFo… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 3 months

1
0
0 0

Reminder: MBed TLS Technical Forum June 6th

by Don Harbin

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

3 years, 3 months

1
0
0 0

PSA API on non-threaded environment

by gergely.nagymate＠generalmechatronics.com

Hi, I am using mbedTLS v3.0.0 on a low performance CPU on a non-threaded environment, a custom task manager, which is not a preemptive operating system. I have been using MBEDTLS_ECP_RESTARTABLE so even the long ECC calculations during the handshake periodically returned so the external logic and task manager could run without being blocked for too long. Recently an IoT SAFE implementation was introduced through PSA API. It is used for RNG and verification calculation, but not for ECDSA and ECDH during key exchange. PSA API is designed for threaded environments and can not simultaneously use MBEDTLS_ECP_RESTARTABLE. Now the ECC functions block for several seconds. Do you have a recommendation on how to use PSA on non-threaded environments, or how to inject external logic execution during these long ECC operations? Thanks, Gergely

3 years, 3 months

2
1
0 0

PSA API on non-threaded environment

by Gergely Nagymáté

Hi, I am using mbedTLS v3.0.0 on a low performance CPU on a non-threaded environment, a custom task manager, which is not a preemptive operating system. I have been using MBEDTLS_ECP_RESTARTABLE so even the long ECC calculations during the handshake periodically returned so the external logic and task manager could run without being blocked for too long. Recently an IoT SAFE implementation was introduced through PSA API. It is used for RNG and verification calculation, but not for ECDSA and ECDH during key exchange. PSA API is designed for threaded environments and can not simultaneously use MBEDTLS_ECP_RESTARTABLE. Now the ECC functions block for several seconds. Do you have a recommendation on how to use PSA on non-threaded environments, or how to inject external logic execution during these long ECC operations? Thanks, Gergely

3 years, 3 months

1
0
0 0

"RAW RSA" encoding method for signatures

by THIERRY BINIGUER

Hi all, I can see a "RAW RSA" encoding method for signatures both implemented in mbed TLS and PSA API and I'm wondering about the motivations and rational of this variant. Could you tell more about it, please ? Below details. Thierry It was introduced since 2017 in mbed TLS in this sha1 ID : fdf38030de70b95a77205f17d65591f05e74be08 ("Outsource code for generating PKCS1 v1.5 encoding"). As far as I know, standard does not specifically mention it but RFC 8017 ($9.2) specifies EMSA-PKCS1-v1_5 as a deterministic encoding method (no randomness) with a buffer that is built as an encoded message EM = 0x00 || 0x01 || PS || 0x00 || T, where PS being padding bytes, T being a DER encoding of a digestInfo, where digestInfo contains : - the hash function (so called AlgorithmIdentifier applied on the message) - and the hash value (so called digest H = = Hash(M)) PSA defines the RAW RSA in its API. It is said a signature algorithm, without hashing. In this raw RSA PKCS#1 v1.5, the hash parameter to psa_sign_hash is computed "externally". It is a DER encoding, “ready-to-use" hash, so called raw data in PSA and mbed TLS. In the RSA PKCS#1 v1.5, the hash parameter to psa_sign_hash is H (computed with the hash function as indicated in the standard). mbed TLS implementation manages RAW data in rsa_rsassa_pkcs1_v15_encode(), it copies raw data as they are given and pads accordingly. Even if from a security perspective, this variant does not seem to introduce vulnerabilities, there is no information on the used hash algorithm inside the signature itself, therefore making mandatory for the verifier to know exactly which algorithm is used, and therefore less trivial in term of device interoperability.

3 years, 3 months

2
1
0 0

Cancelled event: MBed TLS Technical Forum - Asia @ (BST) (mbed-tls@lists.trustedfirmware.org)

by Mike Holmes

This event has been cancelled. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: United Kingdom Time Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 4 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 21:00 to 21:50 on Monday from Mon 31 Jan to Mon 23 May (AEDT) (mbed-tls@lists.trustedfirmware.org)

by santosdanillo＠gmail.com

This event has been changed. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 21:00 to 21:50 on Monday from Mon 31 Jan to Mon 23 May Eastern Australia Time - Sydney (changed) Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 4 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 19:00 to 19:50 on Monday 13 times (AEST) (mbed-tls@lists.trustedfirmware.org)

by santosdanillo＠gmail.com

This event has been changed. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 19:00 to 19:50 on Monday 13 times Eastern Australia Time - Sydney (changed) Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 4 months

1
0
0 0

Require cross compilation steps

by Krunal Chauhan

Hi, I need updated mbed TLS library version 3.1.0 I need step/procedure to cross compile mbed TLS library. Best Regards, [Logo]<https://www.slscorp.com/> Krunal Chauhan Senior Engineer Email: krunal.chauhan(a)slscorp.com | www.slscorp.com<http://www.slscorp.com> Plot#32, Zone-D/4, Phase-1, GIDC Estate V.U. Nagar - 388 121, Gujarat, India

3 years, 4 months

1
0
0 0

Re: AES Memory Leak

by Minos Galanakis

Hi Subramanian. Thank you for your report. Would it be possible to provide some further information on how the program is structured? Is the code snippet running in a single thread or a multithreaded application? How often is data transmitted (As to many invocations are we considering for an 8-hour window)? How is that while(1) loop interrupted? Which platform architecture is the program running at? I have been trying to reproduce it by expanding the Valgrind test suite, as to repeat the logic included in the example for UINT_MAX iterations, without success. Minos ________________________________ From: Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 16 March 2022 04:24 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] AES Memory Leak Hi, I have developed a program to send encrypted data continuously. The program is working fine for few hours. After 6 to 8 Hrs, I get returned MBEDTLS_ERR_CIPHER_ALLOC_FAILED -0x6180 Do I need to free the gcm context for every time I send data? What would be the root cause. #define AEAD_KEY_SIZE (32) /**< AEAD Key Size(in bytes). */ #define AEAD_IV_SIZE (12) /**< AEAD IV Size(in bytes). */ #define AEAD_AD_SIZE (16) /**< AEAD AAD Size(in bytes). */ #define AEAD_TAG_SIZE (16) /**< AEAD Tag Size(in bytes). */ #define AEAD_ID_SIZE (4) /**< AEAD Tag Size(in bytes). */ #define MAX_CIPHER_SIZE (2048)/**< AEAD Cipher/Plaintext Segent Size unoperation(in bytes). */ typedef struct { mbedtls_gcm_context CtxAead; /**< aes-gcm 3rd party library context */ uint8_t pu8Key[AEAD_KEY_SIZE]; /**< Key - Randomly Generated */ uint8_t pu8InitVector[AEAD_IV_SIZE]; /**< Randomly Generated */ uint8_t pu8AddData[AEAD_AD_SIZE]; /**< Additional Associated Data - md5sum() */ uint8_t pu8Tag[AEAD_TAG_SIZE]; /**< Hold Digest/Tag of encryped data */ uint8_t pu8Id[AEAD_ID_SIZE]; /**< KeyID is generated */ uint8_t pu8Data[MAX_CIPHER_SIZE]; /**< Buffer to hold plain-text after decipher */ uint8_t pu8Cipher[MAX_CIPHER_SIZE]; /**< Buffer to hold cipher-text after cipher */ uint16_t u16Length; /**< Current length of buffer to encrypt/decrypt */ }S_Aead; int32_t i32Aead_EncryptionCycle(S_Aead *ctx ,uint8_t *pu8AddData, uint16_t u16Length ) { int32_t i32Ret = 0; if(NULL == ctx) { return (NULL_AEAD_CTX); } /* Initilaze GCM Context **/ mbedtls_gcm_init ( &(ctx->CtxAead) ); /*SETTING ADDITIONAL DATA as MD5 of incoming data **/ if( AEAD_AD_SIZE < u16Length ) { return (ERROR_INPUT_BUFFER_TOO_LONG); } memset( ctx->pu8AddData, 0x00, AEAD_AD_SIZE ); i32Ret = mbedtls_md5_ret(pu8AddData, u16Length, ctx->pu8AddData); if (i32Ret) { return (i32Ret); } /* symetric key for testing */ memset( ctx->pu8Key, 0xAB, AEAD_KEY_SIZE ) /* Setting the key */ if( i32Ret = mbedtls_gcm_setkey ( &(ctx->CtxAead), MBEDTLS_CIPHER_ID_AES, ctx->pu8Key, AEAD_KEY_SIZE*OCTETS ) ) { return (i32Ret); } while(1) { /* OS Wait for 1000ms for data to get ready */ if( OS_WaitSingleEventTimed( TX_DATA_BUFFER_READY, WAIT_1000MS ) ) { if( ctx->u16Length == 0 ) { /* No data ready for sending (or) timed-out */; continue; } /* New Initial Vector */ if( i32Ret = i32NewRandomByte( ctx->pu8InitVector, AEAD_IV_SIZE, "AEAD_NEW_IV_GENERATION" ) ) { return(i32Ret); } ctx->u16Length = u16Length; if( i32Ret = mbedtls_gcm_crypt_and_tag( &(ctx->CtxAead), MBEDTLS_GCM_ENCRYPT, ctx->u16Length, ctx->pu8InitVector, AEAD_IV_SIZE, ctx->pu8AddData, AEAD_AD_SIZE, ctx->pu8Data, ctx->pu8Cipher, AEAD_TAG_SIZE, ctx->pu8Tag)) { return(i32Ret); } if( ctx->u16Length == send_data(ctx->pu8Cipher, ctx->u16Length) ) { /* tx success*/ memset( ctx->pu8Data, 0x00, ctx->u16Length ); memset( ctx->pu8Cipher, 0x00, ctx->u16Length ); ctx->u16Length = 0; } } } /* Free GCM Context */ mbedtls_gcm_free( &(ctx->CtxAead) ); /* Reset context memory */ memset(ctx, 0, sizeof(S_Aead)); }

3 years, 5 months

1
0
0 0

Re: mbed-tls Digest, Vol 26, Issue 5

by Christie Su

Hi, Is there anyone who can tell me how to send the question related to MbedTLS? Which forum can I sign in? Thanks, Christie -----Original Message----- From: mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: April-25-22 8:00 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: mbed-tls Digest, Vol 26, Issue 5 Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to mbed-tls-request(a)lists.trustedfirmware.org You can reach the person managing the list at mbed-tls-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mbed-tls digest..." Today's Topics: 1. misc. questions (Frank Bergmann) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Apr 2022 12:47:07 +0200 From: Frank Bergmann <mbedtls(a)tuxad.com> Subject: [mbed-tls] misc. questions To: mbed-tls(a)lists.trustedfirmware.org Message-ID: <20220425104707.GA3579(a)treferpol.tuxad.net> Content-Type: text/plain; charset=us-ascii 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 ------------------------------ Subject: Digest Footer mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org ------------------------------ End of mbed-tls Digest, Vol 26, Issue 5 ***************************************

3 years, 5 months

1
0
0 0

Reminder: MBed TLS Technical Forum - Asia

by don.harbin＠linaro.org

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBest TLS Tech forum is next Monday. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Mon Apr 25, 2022 2am – 2:50am Mountain Standard Time - Phoenix Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com

3 years, 5 months

1
0
0 0

Mbed tls handshake returns –x7200

by arman_ilmak＠yahoo.com

Hey friends Im trying to do a secure connection between my stm32 board and server. I wrote the code based on GitHub - eziya/STM32F4_HAL_ETH_MBEDTLS: STM32 mbedTLS library testing (SSL/TLS client) that i found. My board is based on stm32h7 series. And im using google to test my app.(ip 142.250.74.196 port 443) This is the debug section: https://aws1.discourse-cdn.com/standard17/uploads/mbed/original/2X/e/ee636c… How should i solve the problem?

3 years, 5 months

2
2
0 0

Issues with mbedtls_rsa_import_raw + mbedtls_rsa_pkcs1_verify

by m4D

Greetings! I'm having an issue while veryfing signature with imported RSA2048 public key, generated with Win7 CryptoAPI (PUBLICKEYBLOB) into latest mbedtls 2.28.x. The blob contains RSA modulus N (256 bytes) and public exponent E (4 bytes) - I do extract them succesfully, then provide into mbedtls_rsa_import_raw. It all goes smth. like this: u32 errval = mbedtls_rsa_init(ctx, MBEDTLS_RSA_PKCS_V15, 0); // errval == 0 here errval = mbedtls_rsa_import_raw(ctx, n, nlen, 0l, 0, 0l, 0, 0l, 0, e, elen); // errval == 0 here errval = mbedtls_rsa_complete(ctx); // errval == 0 here errval = mbedtls_rsa_check_pubkey(ctx); // errval == 0 here Then i ran: errval = mbedtls_rsa_pkcs1_verify(ctx, 0l, 0l, MBEDTLS_RSA_PUBLIC, MBEDTLS_MD_SHA512, 0, _src, _sign); and get -0x4380 (verify failed) _src - is sha512 hash of data to be verified (64 bytes) _sign - is 256 bytes of signature, provided by win7 cryptoapi P.S. just in case, i did tried messing with endianess in every way for e AND n, it didn't help. I added a little debugging inside library/rsa.cpp, turned out we do call mbedtls_rsa_rsassa_pkcs1_v15_verify, and there is a memcmp between 'encoded' and 'encoded_expected' bufs. 'encoded' is derived from signature (_sign), and 'encoded_expected' is derived from hash (_src) printhex for 'encoded' looks like this: 1a1da83b 14be17a2 c8401d41 1d453909 ... total 16 lines (256 bytes) ... 7fb37ea2 719a5562 aebdb3ed 296e0ed1 but printhex for 'encoded_expected' looks like this: ffff0100 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ... wtf??? padding ??? ... ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 30513000 6009060d 65014886 03020403 40040005 b190b45a a40b354f 32271b34 f022abd3 ... sha512-derived data here, 64 bytes 557abf2b e2cc4e0f 0b77bdfc b45688b0 So, there is no way these two bufs match. I wonded if there is some issue in parsing _sign, or I didn't prepared input data good enough. Any ideas? B.R., m4D.

3 years, 5 months

1
0
0 0

How to verify in a server that session cache resumption was used for a given connection

by eoin.mcmahon.dev＠gmail.com

I am trying to modify the dtls_server.c example to keep track of whether session caching was used for a given connection. Ideally I would have an interget value i.e `session_resumed = #1 or 0` One way I tried to do this was by reading the value of the mbedtls_ssl_context struct `ssl`: ``` /* * 5. Handshake */ do ret = mbedtls_ssl_handshake( &ssl ); while( ret == MBEDTLS_ERR_SSL_WANT_READ || ret == MBEDTLS_ERR_SSL_WANT_WRITE ); if( ret == MBEDTLS_ERR_SSL_HELLO_VERIFY_REQUIRED ) { printf( " hello verification requested\n" ); ret = 0; goto reset; } else if( ret != 0 ) { printf( " failed\n ! mbedtls_ssl_handshake returned -0x%x\n\n", (unsigned int) -ret ); goto reset; } printf( " session cache status: %d\n", ssl.handshake.resume ); ``` The issue with this is that the ssl struct is set to private, so the code fails to compile with the error: 'struct mbedtls_ssl_context' has no member named 'handshake' Can somebody help me with some example code that would make this possible?

3 years, 5 months

3
3
0 0

Mbed TLS GitHub migration

by Dave Rodgman

Hi all, Please note that in the next couple of weeks, we will migrate Mbed TLS to a new GitHub organisation. Your existing scripts, links etc for accessing Mbed TLS on GitHub should not be affected. This will change the url from https://github.com/ARMmbed/mbedtls to https://github.com/Mbed-TLS/mbedtls . GitHub will redirect any accesses to the old URL for the foreseeable future, but we would recommend updating your links once the migration is complete. All of the Mbed TLS repositories will migrate to this new organisation, i.e.: mbedtls mbedtls-docs mbedtls-test Thanks Dave Rodgman

3 years, 5 months

1
1
0 0

ECDSA Help

by Deep Patel

Hello, mbedTLS has ECDSA module that takes Signature with ASN1 encoding as input mbedtls_pk_verify() The Signature I receive is without ASN1 encoded. Trying to find an implementation within mbedTLS that can add ASN1 to signature before I feed into the verify function. Any help ? [RF IDeas]<http://www.rfideas.com/> Deep Patel Sr. Embedded Software Engineer D: 224-333-2084 P: 847-870-1723 Ext 437 E: ddpatel(a)rfideas.com<mailto:ddpatel@rfideas.com> A: <https://www.rfideas.com/> 425 North Martingale Road, Suite 1680, Schaumburg, IL 60173 <https://www.rfideas.com/>

3 years, 5 months

2
1
0 0

TrustedFirmware Code of Conduct

by Don Harbin

Hi All, Please find the link to the TrustedFirmware Community Code of Conduct here: https://developer.trustedfirmware.org/w/collaboration/community_guidelines/… Trusted Firmware has a very diverse and global developer community. It is important that we adhere to the code of conduct in all our interactions. For some of you all this may be new and for others just a gentle reminder. In either case, if you have any questions, please feel free to reach out to me directly. And thanks to you all for your contributions to the TrustedFirmware community! Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 6 months

1
0
0 0

Official release with mutual authentication support

by Tove Rumar

Hello! Is there a time plan for when there will be an official release with TLS 1.3 (Client) that supports mutual authentication? Kind Regards Tove Rumar Software Engineer u-blox Malmo Östra Varvsgatan 4 SE- Malmö www.u-blox.com<https://www.u-blox.com> Reliable. Smart. Secure.

3 years, 6 months

1
0
0 0

AES Memory Leak

by Subramanian Gopi Krishnan

Hi, I have developed a program to send encrypted data continuously. The program is working fine for few hours. After 6 to 8 Hrs, I get returned MBEDTLS_ERR_CIPHER_ALLOC_FAILED -0x6180 Do I need to free the gcm context for every time I send data? What would be the root cause. #define AEAD_KEY_SIZE (32) /**< AEAD Key Size(in bytes). */ #define AEAD_IV_SIZE (12) /**< AEAD IV Size(in bytes). */ #define AEAD_AD_SIZE (16) /**< AEAD AAD Size(in bytes). */ #define AEAD_TAG_SIZE (16) /**< AEAD Tag Size(in bytes). */ #define AEAD_ID_SIZE (4) /**< AEAD Tag Size(in bytes). */ #define MAX_CIPHER_SIZE (2048)/**< AEAD Cipher/Plaintext Segent Size unoperation(in bytes). */ typedef struct { mbedtls_gcm_context CtxAead; /**< aes-gcm 3rd party library context */ uint8_t pu8Key[AEAD_KEY_SIZE]; /**< Key - Randomly Generated */ uint8_t pu8InitVector[AEAD_IV_SIZE]; /**< Randomly Generated */ uint8_t pu8AddData[AEAD_AD_SIZE]; /**< Additional Associated Data - md5sum() */ uint8_t pu8Tag[AEAD_TAG_SIZE]; /**< Hold Digest/Tag of encryped data */ uint8_t pu8Id[AEAD_ID_SIZE]; /**< KeyID is generated */ uint8_t pu8Data[MAX_CIPHER_SIZE]; /**< Buffer to hold plain-text after decipher */ uint8_t pu8Cipher[MAX_CIPHER_SIZE]; /**< Buffer to hold cipher-text after cipher */ uint16_t u16Length; /**< Current length of buffer to encrypt/decrypt */ }S_Aead; int32_t i32Aead_EncryptionCycle(S_Aead *ctx ,uint8_t *pu8AddData, uint16_t u16Length ) { int32_t i32Ret = 0; if(NULL == ctx) { return (NULL_AEAD_CTX); } /* Initilaze GCM Context **/ mbedtls_gcm_init ( &(ctx->CtxAead) ); /*SETTING ADDITIONAL DATA as MD5 of incoming data **/ if( AEAD_AD_SIZE < u16Length ) { return (ERROR_INPUT_BUFFER_TOO_LONG); } memset( ctx->pu8AddData, 0x00, AEAD_AD_SIZE ); i32Ret = mbedtls_md5_ret(pu8AddData, u16Length, ctx->pu8AddData); if (i32Ret) { return (i32Ret); } /* symetric key for testing */ memset( ctx->pu8Key, 0xAB, AEAD_KEY_SIZE ) /* Setting the key */ if( i32Ret = mbedtls_gcm_setkey ( &(ctx->CtxAead), MBEDTLS_CIPHER_ID_AES, ctx->pu8Key, AEAD_KEY_SIZE*OCTETS ) ) { return (i32Ret); } while(1) { /* OS Wait for 1000ms for data to get ready */ if( OS_WaitSingleEventTimed( TX_DATA_BUFFER_READY, WAIT_1000MS ) ) { if( ctx->u16Length == 0 ) { /* No data ready for sending (or) timed-out */; continue; } /* New Initial Vector */ if( i32Ret = i32NewRandomByte( ctx->pu8InitVector, AEAD_IV_SIZE, "AEAD_NEW_IV_GENERATION" ) ) { return(i32Ret); } ctx->u16Length = u16Length; if( i32Ret = mbedtls_gcm_crypt_and_tag( &(ctx->CtxAead), MBEDTLS_GCM_ENCRYPT, ctx->u16Length, ctx->pu8InitVector, AEAD_IV_SIZE, ctx->pu8AddData, AEAD_AD_SIZE, ctx->pu8Data, ctx->pu8Cipher, AEAD_TAG_SIZE, ctx->pu8Tag)) { return(i32Ret); } if( ctx->u16Length == send_data(ctx->pu8Cipher, ctx->u16Length) ) { /* tx success*/ memset( ctx->pu8Data, 0x00, ctx->u16Length ); memset( ctx->pu8Cipher, 0x00, ctx->u16Length ); ctx->u16Length = 0; } } } /* Free GCM Context */ mbedtls_gcm_free( &(ctx->CtxAead) ); /* Reset context memory */ memset(ctx, 0, sizeof(S_Aead)); }

3 years, 6 months

1
0
0 0

MBed TLS Technical Forum - reminder

by Don Harbin

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

3 years, 6 months

1
0
0 0

signature verification of ECC type

by Sunil Jain

Hello, we are using mbedTLS version 2.16. We are facing a problem in verifying the signed message for ECDSA type of algorithms. Do you have any sample code for this as given for the RSA type algorithm in rsa_verify.c. We have derived the R and S values and their length, but we are not sure which context to use to verify the signature. Please help urgently. -- Regards, Sunil Jain

3 years, 6 months

2
1
0 0

Re: How to verify in a server that session cache resumption was used for a given connection

by Eoin McMahon

Hi thanks for getting back to me, That's fine if it doesn't work in future releases, I will most likely stay on 3.0.0. Unfortunately when trying to add this line to the dtls_server example I get: error: dereferencing pointer to incomplete type 'mbedtls_ssl_handshake_params' {aka 'struct mbedtls_ssl_handshake_params'} int resumed = ssl.MBEDTLS_PRIVATE(handshake)->resume; ^~ my use case for this is to test a client's ability to connect to the server and use session caching, I want to essentially send messages to the server from a client, and have the server send a message back either 'session cache was used' or 'session cache was not used'.

3 years, 6 months

2
1
0 0

Realization TLS 1.2. in libiec61850

by kirilllatyshov99＠gmail.com

Good afternoon, I'm trying to implement TLS 1.2. for MMS using the library libiec61850. When a connection is established, the interaction is interrupted at the stage "Client Key Exchange". Also, when monitoring the interaction through wireshark, I see that an error is displayed at the "Certificate Request" stage. I use default certificates, the project is built through CMake on Windows and TLS 1.1. works flawlessly. In the file tls_mbedtls.c I changed only the values of the minimum and maximum versions to TLS 1.2. Thank you in advance for your response.

3 years, 7 months

1
0
0 0

Reminder: MBed TLS Technical Forum - Asia

by don.harbin＠linaro.org

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBest TLS Tech forum is next Monday. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Mon Feb 28, 2022 3am – 3:50am Mountain Standard Time - Phoenix Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com

3 years, 7 months

1
0
0 0

Re: ssl_server2 failed with mbedtls_ssl_handshake returned error -30976

by Dave Rodgman

Hi Dmitrij, (Please note, I've moved this question to the main Mbed TLS list as this is the right place for this kind of question). I've tested our example ssl_client2 against test.mosquitto.org, using a client certificate & key generated via https://test.mosquitto.org/ssl/index.php, and CA file from https://test.mosquitto.org/. This connects properly using the command line: ./ssl_client2 server_addr=test.mosquitto.org server_port=8884 ca_file=mosquitto.org.crt server_name=test.mosquitto.org crt_file=client.crt key_file=client.key Similarly, OpenSSL succeeds using the same certificates: openssl s_client -connect test.mosquitto.org:8884 -CAfile mosquitto.org.crt -servername test.mosquitto.org -cert client.crt -key client.key However, if I omit the client key (i.e. remove "-key client.key"), Mbed TLS fails in the manner you describe. It looks like you are not supplying the client key? Regards Dave Rodgman On 21/02/2022, 10:55, "Dmitrij Shabroff via Mbed-tls-announce via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> wrote: Good day Please answer my questions - there is very little literature on the topic. I do not know what to do. I have dealt with the message [2:40] issue. I did not enroll the user certificate using: if((ret = mbedtls_ssl_conf_own_cert(&conf, &clicert, &pkey))!= 0) and this certificate was not transmitted. Now I have taken it a step further, the certificate is successfully transferred and the server does not break the connection. I switched to TLS 1.3. ---------------------------------------------------------------------- But in your examples, I see the use of two certificates: mbedtls_ssl_conf_ca_chain( &conf, &cacert, NULL ); ret = mbedtls_ssl_conf_own_cert( &conf, &clicert, &pkey ) ) And also the key: ret = mbedtls_pk_parse_key( &pkey, (const unsigned char *) mbedtls_test_cli_key, mbedtls_test_cli_key_len, NULL, 0, rng_get, &rng ); In my version, I only have a client certificate. I working with https://test.mosquitto.org/ Would you advise where to get the missing certificates and where to get the key for the mbedtls_pk_parse_key function? ---------------------------------------------------------------------- Now in both functions I use the same certificate and a PCA key from the example. I get a message: ..\Src\mbedTLS\library\ssl_msg.c:4645:got an alert message, type: [2:51] ..\Src\mbedTLS\library\ssl_msg.c:4653:is a fatal alert message (msg 51) ..\Src\mbedTLS\library\ssl_msg.c:3763:mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) ..\Src\mbedTLS\library\ssl_msg.c:4771:mbedtls_ssl_read_record() returned -30592 (-0x7780) Sincerely, Shabrov Dmitry >Понедельник, 7 февраля 2022, 16:28 +03:00 от B Mahesh via Mbed-tls-announce via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>: > >Hi , > > > >*Problem description :* > > > >Trying to run example >https://github.com/ARMmbed/mbedtls/blob/master/programs/ssl/ssl_server2.c . > >Updated ssl_server2 port to listen on 7777 for incoming client request >,ssl_server2 >will be waiting for remote connection continuously. > >There was no client request for connection on this port, but still server >is getting some spurious connection request and goes for handshake and >fails with below error code. > > > >Error code: mbedtls_ssl_handshake returned error -30976 > > > > >*Steps to reproduce: =============* > > 1. start ssl_server2 program > 2. Monitor for ssl_server2 connection waiting , observe ssl_server2 will > accept spurious connection request and goes for handshake and fails >with above > mentioned error code. > > > >*Expected behavior:* >ssl_server2 wait for remote connection infinitely and connect to valid >client request and perform handshake every time. > > >*Actual behavior:* >Occasionally ssl_server2 will accept spurious connection request and goes >for handshake and fails with below error code. > > > >Error code: >mbedtls_ssl_handshake returned error -30976 on ssl_server2 > > > >*Analysis:* > >As per below logs what we understand is ssl_server2 will accept spurious >connection request and goes for handshake and fails with error code >-30796 ,MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO >on ssl_server2 side . > > > >Can you please help us to understand this behavior? > >What could be the reason for ssl_server2 to connect to a spurious >connection request?, as mentioned above there was no client request for >connection on this ssl_server2 port( 7777) . > >We have tried this on other SERVER_PORT as well . > > > >*Logs Snippet:* > >*==========* > > > >. Seeding the random number generator... ok > > . Loading the CA root certificate ... ok (0 skipped) > > . Loading the server cert. and key... ok > > . Bind on tcp://*:7777/ ... ok > > . Setting up the SSL/TLS structure... ok > > . Waiting for a remote connection ...ok > > . Performing the SSL/TLS handshake... failed > > ! mbedtls_ssl_handshake returned -0x7900 > > > >Last error was: -30976 - SSL - Processing of the ClientHello handshake >message failed > > > > . Waiting for a remote connection ... ok > > . Performing the SSL/TLS handshake... failed > > ! mbedtls_ssl_handshake returned -0x7900 > > > >Last error was: -30976 - SSL - Processing of the ClientHello handshake >message failed > > > > . Waiting for a remote connection ... ok > > . Performing the SSL/TLS handshake... failed > > ! mbedtls_ssl_handshake returned -0x7900 > > > >Last error was: -30976 - SSL - Processing of the ClientHello handshake >message failed > > > >Regards >Mahesh >-- >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 >-- >mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org >To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org -- 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 -- mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org

3 years, 7 months

2
1
0 0

TLS PSK display X.509 verified

by Subramanian Gopi Krishnan

Hi, I am evaluating TLS PSK capability on mbedlts-2.16.12 by running following command. I modified TLS client to have only PSK and removed all private key and certificate related code. However, the servier indicated x.509 verification ok. What is it? ./a.out ok . Performing the SSL/TLS handshake... ok [ Protocol is TLSv1.2 ] [ Ciphersuite is TLS-PSK-WITH-AES-128-GCM-SHA256 ] [ Record expansion is 29 ] . Closing the connection... done ./ssl_server2 psk="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" psk_list="Client_identity","AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" force_ciphersuite=TLS-PSK-WITH-AES-128-GCM-SHA256 . Seeding the random number generator... ok . Loading the CA root certificate ... ok (0 skipped) . Loading the server cert. and key... ok . Bind on tcp://*:4433/ ... ok . Setting up the SSL/TLS structure... ok . Waiting for a remote connection ... ok . Performing the SSL/TLS handshake... ok [ Protocol is TLSv1.2 ] [ Ciphersuite is TLS-PSK-WITH-AES-128-GCM-SHA256 ] [ Record expansion is 29 ] [ Maximum fragment length is 16384 ] . Verifying peer X.509 certificate... ok < Read from client: 34 bytes read GET / HTTP/1.0 Extra-header: > Write to client: 144 bytes written in 1 fragments HTTP/1.0 200 OK Content-Type: text/html <h2>mbed TLS Test Server</h2> <p>Successful connection using: TLS-PSK-WITH-AES-128-GCM-SHA256</p> . Closing the connection... done . Waiting for a remote connection ... Thanks, Gopi Krishnan

3 years, 7 months

2
1
0 0

Re: TLS PSK display X.509 verified

by Hannes Tschofenig

Hi Gopi, When you say "I modified TLS client to have only PSK and removed all private key and certificate related code." did you set the C processor directives in the include/mbedtls/mbedtls_config.h file? To me it seems that you didn't do this and hence you still use the default configuration settings, which means that all PKI-related code is compiled into your binary. Ciao Hannes From: Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Sent: Tuesday, February 22, 2022 12:15 PM To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> Subject: [mbed-tls] TLS PSK display X.509 verified Hi, I am evaluating TLS PSK capability on mbedlts-2.16.12 by running following command. I modified TLS client to have only PSK and removed all private key and certificate related code. However, the servier indicated x.509 verification ok. What is it? ./a.out ok . Performing the SSL/TLS handshake... ok [ Protocol is TLSv1.2 ] [ Ciphersuite is TLS-PSK-WITH-AES-128-GCM-SHA256 ] [ Record expansion is 29 ] . Closing the connection... done ./ssl_server2 psk="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" psk_list="Client_identity","AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" force_ciphersuite=TLS-PSK-WITH-AES-128-GCM-SHA256 . Seeding the random number generator... ok . Loading the CA root certificate ... ok (0 skipped) . Loading the server cert. and key... ok . Bind on tcp://*:4433/ ... ok . Setting up the SSL/TLS structure... ok . Waiting for a remote connection ... ok . Performing the SSL/TLS handshake... ok [ Protocol is TLSv1.2 ] [ Ciphersuite is TLS-PSK-WITH-AES-128-GCM-SHA256 ] [ Record expansion is 29 ] [ Maximum fragment length is 16384 ] . Verifying peer X.509 certificate... ok < Read from client: 34 bytes read GET / HTTP/1.0 Extra-header: > Write to client: 144 bytes written in 1 fragments HTTP/1.0 200 OK Content-Type: text/html <h2>mbed TLS Test Server</h2> <p>Successful connection using: TLS-PSK-WITH-AES-128-GCM-SHA256</p> . Closing the connection... done . Waiting for a remote connection ... Thanks, Gopi Krishnan

3 years, 7 months

1
0
0 0

[Mbed-tls-announce] ssl_server2 failed with mbedtls_ssl_handshake returned error -30976

by B Mahesh via Mbed-tls-announce

Hi , *Problem description :* Trying to run example https://github.com/ARMmbed/mbedtls/blob/master/programs/ssl/ssl_server2.c . Updated ssl_server2 port to listen on 7777 for incoming client request ,ssl_server2 will be waiting for remote connection continuously. There was no client request for connection on this port, but still server is getting some spurious connection request and goes for handshake and fails with below error code. Error code: mbedtls_ssl_handshake returned error -30976 *Steps to reproduce: =============* 1. start ssl_server2 program 2. Monitor for ssl_server2 connection waiting , observe ssl_server2 will accept spurious connection request and goes for handshake and fails with above mentioned error code. *Expected behavior:* ssl_server2 wait for remote connection infinitely and connect to valid client request and perform handshake every time. *Actual behavior:* Occasionally ssl_server2 will accept spurious connection request and goes for handshake and fails with below error code. Error code: mbedtls_ssl_handshake returned error -30976 on ssl_server2 *Analysis:* As per below logs what we understand is ssl_server2 will accept spurious connection request and goes for handshake and fails with error code -30796 ,MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO on ssl_server2 side . Can you please help us to understand this behavior? What could be the reason for ssl_server2 to connect to a spurious connection request?, as mentioned above there was no client request for connection on this ssl_server2 port( 7777) . We have tried this on other SERVER_PORT as well . *Logs Snippet:* *==========* . Seeding the random number generator... ok . Loading the CA root certificate ... ok (0 skipped) . Loading the server cert. and key... ok . Bind on tcp://*:7777/ ... ok . Setting up the SSL/TLS structure... ok . Waiting for a remote connection ...ok . Performing the SSL/TLS handshake... failed ! mbedtls_ssl_handshake returned -0x7900 Last error was: -30976 - SSL - Processing of the ClientHello handshake message failed . Waiting for a remote connection ... ok . Performing the SSL/TLS handshake... failed ! mbedtls_ssl_handshake returned -0x7900 Last error was: -30976 - SSL - Processing of the ClientHello handshake message failed . Waiting for a remote connection ... ok . Performing the SSL/TLS handshake... failed ! mbedtls_ssl_handshake returned -0x7900 Last error was: -30976 - SSL - Processing of the ClientHello handshake message failed Regards Mahesh -- 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

3 years, 7 months

2
2
0 0

MBEDTLS_ERR_CIPHER_ALLOC_FAILED on Embedded Platform

by Subramanian Gopi Krishnan

Hi, I have ported mbedtls library on am embedded platform developed to encrypt / decrypt messages using AES GCM 256 key. After several hours of running, we are experiencing error MBEDTLS_ERR_CIPHER_ALLOC_FAILED 0x6180 and malloc functions fails as the heap seems to be piled-up. How could I is using correct free function and the actual allocated memory is freed? Thanks, Gopi Krishnan

3 years, 7 months

2
1
0 0

Tentative: MBed TLS Technical Forum

by Gergely Pintér

3 years, 7 months

1
0
0 0

Future crypto library features

by Hulshof, Robert

All, Not sure if this is the right audience (If it is not let me know if there is a better place to ask the following question) We have been looking at future security requirements for CPE devices, and we think that we need the following functionality that is currently not really available in the current crypto libraries. - Support for Quantum computing secure algorithms (Post Quantum of PQ algorithms) - Support for Hybrid keys ( PQ plus Classic algorithm), preferable in any configuration. - Modularized public key crypto algorithms implementation, to simplify adding new algorithms - Updating public key architecture to simplify off-loading private key operations to a Trusted Execution environment or other security HW. We initially looked at openssl, but found the openssl difficult to work with, so we decided to look at Mbedtls, which has a more lightweight design. We modified the mbedtls 'pkey' code to make it more modularized (building on the pkwrap design), and added to support for Hybrid keys, which was relatively easy to do. Updating the TLS library to support hybrid keys has however been a big challenge. The TLS code is very interwoven with the 'pkey' code, and seems to have almost unique implementation for each type of key, making it difficult to follow and modify. Adding support for other (PQ) algorithms within that design will be challenge. Before spending too much time on this we would like to know if there is an interest in the MBEDTLS community for a redesign of the code to support hybrid keys, PQ algorithms and modularized public key architecture. Thanks, Robert E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

3 years, 7 months

2
1
0 0

MBed TLS Technical Forum - reminder

by don.harbin＠linaro.org

Hi All, A gentle reminder that the US-Europe timezone-friendly MBest TLS Tech forum is next Monday. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Title: MBed TLS Technical Forum Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum Time: Oct 25, 2021 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Oct 25, 2021 04:30 PM Nov 22, 2021 04:30 PM Dec 20, 2021 04:30 PM Jan 17, 2022 04:30 PM Feb 14, 2022 04:30 PM Mar 14, 2022 04:30 PM Apr 11, 2022 04:30 PM May 9, 2022 04:30 PM Jun 6, 2022 04:30 PM Jul 4, 2022 04:30 PM Aug 1, 2022 04:30 PM Aug 29, 2022 04:30 PM Sep 26, 2022 04:30 PM Oct 24, 2022 04:30 PM Nov 21, 2022 04:30 PM Dec 19, 2022 04:30 PM Jan 16, 2023 04:30 PM Feb 13, 2023 04:30 PM Mar 13, 2023 04:30 PM Apr 10, 2023 04:30 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT… Meeting ID: 959 6263 5632 Passcode: 018366 One tap mobile +13462487799,,95962635632# US (Houston) +16699009128,,95962635632# US (San Jose) Dial by your location +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 301 715 8592 US (Washington DC) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 959 6263 5632 Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y When: Mon Feb 14, 2022 9:30am – 10:30am Mountain Standard Time - Phoenix Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com

3 years, 7 months

1
0
0 0

mbedTLS Question

by SHIRLEY Murray

Hello, I am evaluating the mbedTLS library and trying to create a build with Visual Studio 2010, but I am encountering errors. Below are the steps I have taken: 1. Downloaded "mbedtls-3.1.0.zip" and extracted the contents to my Windows 10 computer. 2. Run Visual Studio 2010 and open the solution "mbedTLS.sln" in the folder "mbedtls-3.1.0\visualc\VS2010". 3. Select the "mbedTLS" project and select "Rebuild Only mbedTLS". This is for the Release configuration targeting Win32. 4. During the build process multiple errors are encounter, which seem to be related to Visual Studio's limited C Compiler support. The build output is attached. Am I missing any steps for configuring the solution or project? I was under the impression that mbedTLS offered support for compiling with Visual Studio 2010? Any help that you can provide would be greatly appreciated. Best regards, Murray Shirley, P.Eng. MicroSurvey Software, Inc. (250) 707-0000 murray.shirley(a)microsurvey.com<mailto:murray.shirley@microsurvey.com>

3 years, 7 months

2
1
0 0

TLS Only for Data Authentication

by Subramanian Gopi Krishnan

Hi, I am developing TLS client and server for embedded systems. Considering the operational efficiency, it is sufficient to have data authentication. Is it possible to setup a TLS communication with data authentication and without encryption? Consider a PLC network, 1. Within physical secure zone. 2. Requires faster data transfer. 3. Data are not confidential, but must be cryptographically authenticated. Thanks, Gopi Krishnan

3 years, 7 months

2
1
0 0

Please, help me about Mbedtls_ssl_handshake return error -0x2700

by Dmitrij Shabroff

Hello. I am facing the issue of certificate verification error during handshake.The problem is described by me in the appropriate section of the forum. https://forums.mbed.com/t/mbedtls-failing-with-the-certificate-is-not-corre… Please help me figure it out - there is no one else to turn to. Sincerely, Shabrov Dmitry

3 years, 7 months

1
0
0 0

Does MbedTLS provide paid tech support?

by Tom Zhu

We are interested in whether there are paid supports from MbedTLS regarding optimization on some ARM MCUs. If so, whom should we contact? Thanks! Tom

3 years, 7 months

1
0
0 0

TLS 1.3 support

by Lukas Frei

Good morning, My team and me are starting a bigger project concerning object control on the rail. The security specifications shall use TLS version 1.3. I could read on some forums that you are actually working on it. Could I please get some information about the release date of it? If not provided soon we will be forced to switch to another library. Thanks a lot for your help. Best Regards, Lukas Frei Dipl. MSc Universität Bern und BFH in Biomedical Engineering Embedded Software Engineer CSA Engineering AG Hans Huber-Strasse 38 CH-4500 Solothurn Direkt +41 32 626 35 81 Telefon +41 32 626 35 55 Fax +41 32 626 35 50 mailto:lukas.frei@csa.ch https://www.csa.ch ________________________________ Confidentiality Note: This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are not the/an intended recipient, please contact the sender and delete this message. Any unauthorized use of the information contained in this message is prohibited.

3 years, 7 months

2
1
0 0

Now Im subscribe

by Dmitrij Shabroff

Good afternoon. I am a microcontroller product designer. I ported MBED TLS to STM 32L471 microcontroller. While I do not understand how can I use the certificate. My customer gave me a certificate in the form of a center2m.com.cer file. The file contains the 3 fields: -----BEGIN CERTIFICATE----- MIIGVzCCBT+gAwIBAgIMEnU/ ... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIET ... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIDDX ... -----END CERTIFICATE----- tell me please, how to port my certificate to certs.c file. The question is which fields to insert where? Please help. No one can answer this question except you. Sincerely, development engineer, Shabrov Dmitrii

3 years, 7 months

2
3
0 0

Next MBed TLS Tech Forum - Monday

by Don Harbin

Hi All, This is a gentle reminder that the next MBed TLS Tech forum is next Monday @10am UK time. Reminders: - This is the "Asia timezone friendly" session, but the session recording and supporting content are archived here <https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/>. - Dial-in details can be found in the online calendar <https://www.trustedfirmware.org/meetings/>. If you click on this event in the calendar, it also provides the option to add it to your personal calendar if you wish If anyone has topics you would like to see added to the agenda, please share and Dave and the team will work to get these onto the agenda. Best regards, Don

3 years, 8 months

1
0
0 0

Tentative: MBed TLS Technical Forum - Asia

by Gergely Pintér

3 years, 8 months

1
0
0 0

mbedtls handshake error

by MATRIX 小牧

Hello. I'm sorry for the sudden email. I have a question about mbedtls. Currently, HTTPS communication is performed by mbedtls with a microcomputer called esp32-wroom-32d. The following error occurs when validating the root certificate. --------------------------------------------- mbedtls: ssl_tls.c: 5808 x509_verify_cert () returned -12288 (-0x3000) --------------------------------------------- I can't find out the details even if I check the error code. Changing the certificate will eliminate the error. It has been confirmed that the certificate is legitimate and can be used. [SecurityCommunicationRootCA1.pem] ---- Success [SecurityCommunicationRootCA2.pem] ---- Failure I would like to have any information. Sorry for the unfamiliar English. I look forward to working with you. Komaki

3 years, 8 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 3am to 3:50am on Monday 17 times (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been changed. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 3am to 3:50am on Monday 17 times Mountain Standard Time - Phoenix Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum @ Every 4 weeks from 9:30am to 10:30am on Monday 17 times (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been changed. Title: MBed TLS Technical Forum Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum Time: Oct 25, 2021 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Oct 25, 2021 04:30 PM Nov 22, 2021 04:30 PM Dec 20, 2021 04:30 PM Jan 17, 2022 04:30 PM Feb 14, 2022 04:30 PM Mar 14, 2022 04:30 PM Apr 11, 2022 04:30 PM May 9, 2022 04:30 PM Jun 6, 2022 04:30 PM Jul 4, 2022 04:30 PM Aug 1, 2022 04:30 PM Aug 29, 2022 04:30 PM Sep 26, 2022 04:30 PM Oct 24, 2022 04:30 PM Nov 21, 2022 04:30 PM Dec 19, 2022 04:30 PM Jan 16, 2023 04:30 PM Feb 13, 2023 04:30 PM Mar 13, 2023 04:30 PM Apr 10, 2023 04:30 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT… Meeting ID: 959 6263 5632 Passcode: 018366 One tap mobile +13462487799,,95962635632# US (Houston) +16699009128,,95962635632# US (San Jose) Dial by your location +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 301 715 8592 US (Washington DC) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 959 6263 5632 Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y When: Every 4 weeks from 9:30am to 10:30am on Monday 17 times Mountain Standard Time - Phoenix Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWdhMWpuZ2ZpdWNp… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Entropy PSA Crypto driver support

by François Beerten

Hi everyone, The PSA Crypto Driver Interface describes entry points for collecting entropy from drivers: |psa_status_t acme_get_entropy(uint32_t flags, size_t *estimate_bits, uint8_t *output, size_t output_size);| Currently, MbedTLS does not have any kind of support for those PSA driver entry points. I'm currently looking at trying to add initial support for those in the code. The idea is to write a very simple solution to get the ball rolling and that can be extended and improved later on. Is there interest for a patch to add this? There are different ways to integrate it into the current MbedTLS code. Do you already have plans or ideas on how it should be done? After multiple attempts locally, I've came up with an approach that can work well. Like for other PSA Crypto drivers, the entropy entry points would be listed in the generated "psa_crypto_driver_wrappers.c" file. Those entry points can then be used by a sub-function of mbedtls_entropy_gather(). What do you think of that approach? Best regards, François.

3 years, 8 months

2
1
0 0

Re: License conflict with OpenVPN

by Dave Rodgman

Hi Max, Unfortunately, it would not be possible for us to re-license the project to GPLv2 - this would require agreement with all copyright holders of code contributed to Mbed TLS 2.17, which isn't feasible. For this reason I'm afraid we cannot offer an exception for individual projects. Regards Dave Rodgman On 13/01/2022, 10:28, "Maximilian Fillinger via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> wrote: Hello! OpenVPN can be compiled with OpenSSL or mbedtls. However, OpenVPN is licensed under GPLv2 only. If I understand correctly, that means it is not legal to distribute binaries of OpenVPN that are linked with mbedtls 2.17 or later. At Fox Crypto, we produce a hardened version of OpenVPN, called OpenVPN-NL, for use by the Dutch government, which uses mbedtls. (The latest release is rather old and still uses 2.16.) Is there anyone I could ask about making an exception for linking OpenVPN with mbedtls? Regards, Max Fillinger -- mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org

3 years, 8 months

1
0
0 0

Invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 3am to 3:50am on Monday 17 times (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

You have been invited to the following event. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 3am to 3:50am on Monday 17 times Mountain Standard Time - Phoenix Joining info: Join with Google Meet https://meet.google.com/fwh-srqw-rgf?hs=224 Join by phone (US) +1 304-397-0314 (PIN: 358348986) More phone numbers: https://tel.meet/fwh-srqw-rgf?pin=6539665554630&hs=0 Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Invitation: MBed TLS Technical Forum @ Every 4 weeks from 9:30am to 10:30am on Monday 17 times (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

You have been invited to the following event. Title: MBed TLS Technical Forum Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum Time: Oct 25, 2021 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Oct 25, 2021 04:30 PM Nov 22, 2021 04:30 PM Dec 20, 2021 04:30 PM Jan 17, 2022 04:30 PM Feb 14, 2022 04:30 PM Mar 14, 2022 04:30 PM Apr 11, 2022 04:30 PM May 9, 2022 04:30 PM Jun 6, 2022 04:30 PM Jul 4, 2022 04:30 PM Aug 1, 2022 04:30 PM Aug 29, 2022 04:30 PM Sep 26, 2022 04:30 PM Oct 24, 2022 04:30 PM Nov 21, 2022 04:30 PM Dec 19, 2022 04:30 PM Jan 16, 2023 04:30 PM Feb 13, 2023 04:30 PM Mar 13, 2023 04:30 PM Apr 10, 2023 04:30 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT… Meeting ID: 959 6263 5632 Passcode: 018366 One tap mobile +13462487799,,95962635632# US (Houston) +16699009128,,95962635632# US (San Jose) Dial by your location +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 301 715 8592 US (Washington DC) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 959 6263 5632 Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y When: Every 4 weeks from 9:30am to 10:30am on Monday 17 times Mountain Standard Time - Phoenix Joining info: Join with Google Meet https://meet.google.com/ofy-jxph-boy?hs=224 Join by phone (US) +1 704-705-7047 (PIN: 141276187) More phone numbers: https://tel.meet/ofy-jxph-boy?pin=3695767709143&hs=0 Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWdhMWpuZ2ZpdWNp… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Adding lists to the MBed TLS Tech Forum invite

by Don Harbin

Hi All, FYI, per Shebu, I'm adding both mbed-tls(a)lists.trustedfirmware.org and psa-crypto(a)lists.trustedfirmware.org to the MBed TLS Tech Forum invites. Please look for this in your inbox and accept it if you would like the series added to your calendar. - Note that this is a monthly meeting but you will see two invites, one that is for Asia timezones and one for Europe/US. Just delete the series that isn't timezone friendly for you. - FYI, recall that this and other tech forums can be found in the meeting calendar on the TF website <https://www.trustedfirmware.org/meetings/>. If you see a meeting in that calendar, click on the entry and an option comes up saying "copy to my calendar." It will import that single instance into your personal calendar from there if you wish. I wasn't able to test this feature with outlook, but it worked fine for google calendar. Please let me know if you have any questions. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 8 months

1
0
0 0

License conflict with OpenVPN

by Maximilian Fillinger

Hello! OpenVPN can be compiled with OpenSSL or mbedtls. However, OpenVPN is licensed under GPLv2 only. If I understand correctly, that means it is not legal to distribute binaries of OpenVPN that are linked with mbedtls 2.17 or later. At Fox Crypto, we produce a hardened version of OpenVPN, called OpenVPN-NL, for use by the Dutch government, which uses mbedtls. (The latest release is rather old and still uses 2.16.) Is there anyone I could ask about making an exception for linking OpenVPN with mbedtls? Regards, Max Fillinger

3 years, 8 months

1
0
0 0

Tinycrypt performance & integration

by andrei.menzopol＠nxp.com

Hello, I want to test/analyze the performance increase of using tinycrypt for ECC operations instead of the standard MbedTLS ECC functions. Could you please help me with a few answers regarding this? I am aware that tinycrypt is already integrated in the baremetal branch. Do you happen to know what is the performance increase of using this tinycrypt uECC implementation instead of the standard one on arm cortex m4 microcontrollers? I would like to port the tinycrypt uECC changes from baremetal branch to a Mbed TLS 2.25.0 version used in Matter repo (from where Mbed TLS repo is refered), more exactly this commit: https://github.com/ARMmbed/mbedtls/tree/1c54b5410fd48d6bcada97e30cac417c5c7… What do you think is the best approach? I thought of forking Mbed TLS, creating a separate branch with that commit and adding there the tinycrypt changes from baremetal branch. However, I'm not sure how to proceed next since the Matter repo refers the MbedTLS repo. Is this approach ok? Thank you!

3 years, 8 months

1
0
0 0

EC and FF checks support

by Thomas Fossati

Hi all, Does mbedTLS implement any of the checks in NIST SP 800 56Ar3? (In particular, I am interested in those defined in Section 5.6.2 [1]?) Thanks, cheers! [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf…

3 years, 8 months

1
0
0 0

request to unsubscribe from this mailing list

by Innocenti, Michele

Hi, I have completed my job on these topics so I would like to unsubscribe from this mailing list, can you help me? Thank you! Michele [cid:image001.png@01D7FCCB.D711FD40] Hillrom is now a part of Baxter Michele Innocenti Sr Principal Engineer, SW Eng Gambro Dasco S.p.A. Via Modenese 66 / 41036 Medolla, Modena, Italy T. +39 0535.50578 michele_innocenti(a)baxter.com<mailto:michele_innocenti@baxter.com>

3 years, 8 months

3
2
0 0

Side by side installation of mbedtls 2.x and mbedtls 3.x

by Fabrice Fontaine

Dear all, mbedtls 3.x is incompatible with mbedtls 2.x so the transition of all the packages using mbedtls will take a long time. However, from my understanding, it is not possible to install both versions side by side as a lot of headers are common to both versions and installed in include/mbedtls. This fact is raising concern on buildroot side, see: https://patchwork.ozlabs.org/project/buildroot/patch/20211228153345.4087026… Can you confirm that a side-by-side installation of both mbedtls versions is not possible and/or can you share some inputs on this topic? Best Regards, Fabrice

3 years, 8 months

2
1
0 0

Mbed TLS releases: 2.16.12, 2.28.0, 3.1.0

by Dave Rodgman

Hi, We are pleased to announce the release of Mbed TLS 2.16.12, 2.28.0 and 3.1.0. These releases of Mbed TLS address several security issues, provide bug fixes, and new features, including initial support for TLS 1.3 in Mbed TLS 3.1.0. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/v3.1.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.28.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.12). Mbed TLS 2.16.12 will be the last release in the 2.16 LTS; it will no longer be supported. Mbed TLS 2.28 is the new long-term support release, and will be supported with bug-fixes and security fixes until end of 2024. We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

3 years, 9 months

1
0
0 0

Commercial Support Request

by Felix Knorr

Dear MBedTLS-Team, we are currently evaluating MBedTLS for use in our Product. We develop an implant for blood pressure patients, and our implant and its charger need to communicate securely. We already have an AES encrypted communication running, but so far we just store the password in every device, and we would like to switch to RSA to exchange an AES key. It would also be important for us to be able to validate an x509 certificate on the implant. However, due to energy constraints, our internal flash memory on the implant is extremely small, and we would like to not parse the certificate on the implant, but rather send only the key and the signature directly, and then "validate by hand" on the implant. If I understand the procedure correctly, that would only involve taking a hash of the pubkey, decrypting the signature with a stored CA-public key, and compare them, correct? Would that be possible? Besides normal support during our implementation phase, we would be interested in being informed whenever a vulnerability is found in MBedTLS and a fast update. Do you offer such a service? If so, what will it cost? Kind Rergards, Felix Knorr -- Mit freundlichen Grüßen neuroloop GmbH i.A. Felix Knorr Senior Software Developer -------------------------------------- neuroloop GmbH Engesserstr. 4, 79108 Freiburg, Germany Amtsgericht Freiburg HRB 713935 Geschäftsführer: Dr. Michael Lauk, Dr. Dennis Plachta The information contained in this communication is confidential, may be attorney-client privileged, may constitute inside information, and is intended only for the use of the addressee. It is the property of the company of the sender of this e-mail. Unauthorized use, disclosure, or copying of this communication or any part thereof is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by return e-mail and destroy this communication and all copies thereof, including all attachments.

3 years, 9 months

2
1
0 0

mbedtls communication issue - handshake error -0x50 - NET - Connection was reset by pee

by Alugoju, Shailaja

Hi, I am trying to encrypt data on my rabbitmq communication. On the rabbitmq server end I am using the openssl and on the client end I cant use openssl but I can use mbedtls. I am using mbedtls-2.26.0 version in my rabbimq-c client . The certificate is generated via https://github.com/michaelklishin/tls-gen The certificate is valid and has no issue because the communication works fine when I use the ssl_client2 and ssl_server2 applications from the mbedtls-2.26.0\programs. The communication works fine when I use the rabbitmq openssl client and openssl server. But when I try to use the rabbitmq openssl server and ssl_client2 from mbedtls-2.26.0\programs the connection is reset. I think it’s a config issue but I am not able to figure out the solution or the rootcause. I am not sure if I can use mbedtls client with openssl server. Could you please help me in this. Below is the log from wireshark. Attached is the log from sslclient2 program. After the certificate is verified the broker resets the connection TCP 60271 → 5671 [SYN] Seq=0 Win=65535 Len=0 MSS=65475 WS=256 SACK_PERM=1 TCP 5671 → 60271 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65475 WS=256 SACK_PERM=1 TCP 60271 → 5671 [ACK] Seq=1 Ack=1 Win=2618880 Len=0 TLSv1.2 Client Hello TCP 5671 → 60271 [ACK] Seq=1 Ack=305 Win=2618880 Len=0 TLSv1.2 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done TCP 60271 → 5671 [ACK] Seq=305 Ack=1976 Win=2616832 Len=0 TLSv1.2 Certificate TCP 5671 → 60271 [ACK] Seq=1976 Ack=945 Win=2618112 Len=0 TLSv1.2 Client Key Exchange TCP 5671 → 60271 [ACK] Seq=1976 Ack=1088 Win=2618112 Len=0 TLSv1.2 Certificate Verify TCP 5671 → 60271 [ACK] Seq=1976 Ack=1173 Win=2618112 Len=0 TLSv1.2 Change Cipher Spec TCP 5671 → 60271 [ACK] Seq=1976 Ack=1179 Win=2618112 Len=0 TLSv1.2 Encrypted Handshake Message TCP 5671 → 60271 [ACK] Seq=1976 Ack=1216 Win=2617856 Len=0 TLSv1.2 Change Cipher Spec, Encrypted Handshake Message TCP 60271 → 5671 [ACK] Seq=1216 Ack=2019 Win=2616832 Len=0 TLSv1.2 Application Data TCP 5671 → 60271 [ACK] Seq=2019 Ack=1245 Win=2617856 Len=0 TLSv1.2 Application Data TCP 60271 → 5671 [ACK] Seq=1245 Ack=2048 Win=2616832 Len=0 TLSv1.2 Encrypted Alert TCP 60271 → 5671 [ACK] Seq=1245 Ack=2071 Win=2616832 Len=0 TCP 5671 → 60271 [RST, ACK] Seq=2071 Ack=1245 Win=0 Len=0 Thanks, Shailaja

3 years, 9 months

1
0
0 0

Mbed TLS Tech Forum

by Dave Rodgman

Hi, On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise. Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below Dave Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt

3 years, 9 months

3
4
0 0

Help troubleshooting mbedtls_pk_sign() returned -17280 (-0x4380)

by Martin Man

Hi guys, I have a mbetls based server client application (DTLS) written in Apple Swift language, wrapping the mbedtls C api, running just fine for many years now on iOS, Android, and Linux. We have been compiling the code with Swift 5.0, 5.1, 5.2, 5.3, 5.4 in both release and debug mode. Recently I just recompiled my code with Swift 5.5 in release mode, and my handshakes started failing on the Linux server with cryptic mbedtls_pk_sign() returned -17280 (-0x4380). When I take the same code and recompile in debug mode (-Onone) it works as expected. The same code compiled with Swift+C for iOS and macOS still works in both debug and release mode on both client/server. If I understand the compilation process correctly, the Swift Package Manager that we use to wrap mbedtls simply uses CMakeLists.txt to compile mbedtls and pick up the right flags. I am attaching excerpt from the log where the server part of the handshake fails (in release mode) and succeeds (in debug mode). I am certain this is probably caused by my code and how I wrap C mbedtls sources in Swift, but I can not yet rule out a bug in Swift/C compiler part for Linux which from time to time does have bugs related to code optimization. Could any good soul who understands the parts of the code below point me in the direction where to look and why would the mbedtls_pk_sign fail this way? What parts of the SSL context does it use? I will deep dive into the code to see whether this can be caused by memory corruption or anything else. It’s on LTS mbedtls-2.16.11. Could I run some tests to perhaps verify that mbedtls is compiled and working correctly? thanks for any help, Martin — failing handshake — Dec 7 15:54:53 ssl_srv.c:3296 => write server key exchange Dec 7 15:54:53 ssl_srv.c:3074 ECDHE curve: secp521r1 Dec 7 15:54:53 ssl_srv.c:3100 value of 'ECDH: Q(X)' (521 bits) is: Dec 7 15:54:53 ssl_srv.c:3100 01 d0 5f 4a fa 12 f8 46 75 fb 3e 38 db ba 88 ff Dec 7 15:54:53 ssl_srv.c:3100 73 72 79 78 21 dd 9f ac ac 02 db e7 7e 91 6e 5c Dec 7 15:54:53 ssl_srv.c:3100 06 ed 77 19 42 f1 11 6a f5 75 04 20 d8 51 50 a5 Dec 7 15:54:53 ssl_srv.c:3100 8f 5a 3d 8c b3 c0 15 df cc d7 5b e5 eb 04 2e b6 Dec 7 15:54:53 ssl_srv.c:3100 2f e7 Dec 7 15:54:53 ssl_srv.c:3100 value of 'ECDH: Q(Y)' (518 bits) is: Dec 7 15:54:53 ssl_srv.c:3100 26 c1 52 f0 b6 20 4c aa 53 7c aa 27 12 5f 72 7f Dec 7 15:54:53 ssl_srv.c:3100 11 ea a9 34 9a f5 ef 63 28 76 d8 52 4e 31 a3 13 Dec 7 15:54:53 ssl_srv.c:3100 52 a5 c9 52 5f 6b 41 b6 7e 47 0e 2a 68 c5 e5 80 Dec 7 15:54:53 ssl_srv.c:3100 14 27 ad aa 96 5b 89 41 55 5b d5 52 61 66 8c 06 Dec 7 15:54:53 ssl_srv.c:3100 4b Dec 7 15:54:53 ssl_srv.c:3163 pick hash algorithm 8 for signing Dec 7 15:54:53 ssl_srv.c:3201 dumping 'parameters hash' (64 bytes) Dec 7 15:54:53 ssl_srv.c:3201 0000: 55 c8 d2 5c 83 d8 6b e3 9f 9c b2 f4 e7 f7 4d 26 U..\..k.......M& Dec 7 15:54:53 ssl_srv.c:3201 0010: b4 ce c9 df c2 ae 7a 60 cb e8 02 13 d5 6d d8 ec ......z`.....m.. Dec 7 15:54:53 ssl_srv.c:3201 0020: 48 72 77 9f e2 69 4e f5 b4 1d db 9a 75 2a 5e c7 Hrw..iN.....u*^. Dec 7 15:54:53 ssl_srv.c:3201 0030: e1 1b 66 fc a6 ff 37 c6 6d 42 9b b3 cf 63 bb 0e ..f...7.mB...c.. Dec 7 15:54:53 ssl_srv.c:3274 mbedtls_pk_sign() returned -17280 (-0x4380) Dec 7 15:54:53 ssl_tls.c:8219 <= handshake — successful handshake — Dec 7 16:13:52 ssl_srv.c:3296 => write server key exchange Dec 7 16:13:52 ssl_srv.c:3074 ECDHE curve: secp521r1 Dec 7 16:13:52 ssl_srv.c:3100 value of 'ECDH: Q(X)' (519 bits) is: Dec 7 16:13:52 ssl_srv.c:3100 52 5f 4e 78 48 bd be 6a e4 98 21 30 ce 1c ba 08 Dec 7 16:13:52 ssl_srv.c:3100 b7 ae 88 d3 ff c9 c4 a5 8c 13 1e 73 5b 1f 08 60 Dec 7 16:13:52 ssl_srv.c:3100 7c 51 a7 ec 91 54 d7 52 f3 55 6a 34 92 cf 92 e8 Dec 7 16:13:52 ssl_srv.c:3100 c8 39 33 5e d3 46 3d 89 e7 6d 8f 41 d9 e0 67 e6 Dec 7 16:13:52 ssl_srv.c:3100 7c Dec 7 16:13:52 ssl_srv.c:3100 value of 'ECDH: Q(Y)' (520 bits) is: Dec 7 16:13:52 ssl_srv.c:3100 87 48 29 20 93 8e f8 9a a9 54 70 26 58 79 9d 67 Dec 7 16:13:52 ssl_srv.c:3100 8c ec 0f 06 ae 73 13 40 72 58 fe c1 6e 14 b4 48 Dec 7 16:13:52 ssl_srv.c:3100 55 a1 27 74 9d 63 36 aa db 80 29 f8 ab 9c 64 ba Dec 7 16:13:52 ssl_srv.c:3100 f9 0a 19 af 9a 65 6f 02 96 c6 53 4d 49 4f b4 f5 Dec 7 16:13:52 ssl_srv.c:3100 46 Dec 7 16:13:52 ssl_srv.c:3163 pick hash algorithm 8 for signing Dec 7 16:13:52 ssl_srv.c:3201 dumping 'parameters hash' (64 bytes) Dec 7 16:13:52 ssl_srv.c:3201 0000: e1 65 f4 f0 a6 a3 67 7d 32 55 ed 2a 13 08 71 8a .e....g}2U.*..q. Dec 7 16:13:52 ssl_srv.c:3201 0010: 7e 13 f6 30 85 ed c3 c9 10 e8 b2 43 75 bc 6c 24 ~..0.......Cu.l$ Dec 7 16:13:52 ssl_srv.c:3201 0020: 8f fb d8 90 cb 53 7f 13 53 13 1b f4 eb bd 38 5c .....S..S.....8\ Dec 7 16:13:52 ssl_srv.c:3201 0030: ec 46 c2 0c a9 93 5b 60 5e 5d 81 f2 b3 b0 b5 a8 .F....[`^]...... Dec 7 16:13:52 ssl_srv.c:3361 dumping 'my signature' (256 bytes) Dec 7 16:13:52 ssl_srv.c:3361 0000: 7a a7 0f 17 79 33 36 b7 0c 17 84 5b cc ca 1c 0c z...y36....[.... Dec 7 16:13:52 ssl_srv.c:3361 0010: cb f5 56 80 ea 5d 7f cf ab 86 d5 f9 91 36 0e 68 ..V..].......6.h Dec 7 16:13:52 ssl_srv.c:3361 0020: 76 c6 c0 4b 77 bf 28 e7 b8 c0 a7 de ea d8 a0 30 v..Kw.(........0 Dec 7 16:13:52 ssl_srv.c:3361 0030: 3a b3 4e 24 ea e0 c8 0b e7 ad ba 4d 35 30 c0 39 :.N$.......M50.9 Dec 7 16:13:52 ssl_srv.c:3361 0040: a8 ff f0 6d 8f 28 db fc 5e c3 fb 21 fe 76 dd 07 ...m.(..^..!.v.. Dec 7 16:13:52 ssl_srv.c:3361 0050: 1b 2c 58 fe 7b 0a f5 72 49 d9 d1 9a 10 af 29 21 .,X.{..rI.....)! Dec 7 16:13:52 ssl_srv.c:3361 0060: 7a d9 01 a4 99 01 de 6e ae fd 76 ce b9 64 84 49 z......n..v..d.I Dec 7 16:13:52 ssl_srv.c:3361 0070: 96 97 2d 3a 15 ed 5b de d5 99 9d 1b eb 4c 1a aa ..-:..[......L.. Dec 7 16:13:52 ssl_srv.c:3361 0080: a8 e6 36 29 bd 67 b0 50 91 6e b8 cb 0a 42 4a 79 ..6).g.P.n...BJy Dec 7 16:13:52 ssl_srv.c:3361 0090: 4a 65 ae 95 d0 bc 5a e1 e7 75 2a f9 ba 51 1c 2c Je....Z..u*..Q., Dec 7 16:13:52 ssl_srv.c:3361 00a0: ff 67 e3 df eb a0 d7 6c d2 cf 71 d2 ea 24 7c 16 .g.....l..q..$|. Dec 7 16:13:52 ssl_srv.c:3361 00b0: f8 5b 72 83 56 a9 48 e1 b6 cd d0 bd dd 20 23 d5 .[r.V.H...... #. Dec 7 16:13:52 ssl_srv.c:3361 00c0: 80 c4 bd 6e 42 1c 61 b2 e4 41 01 ce c8 85 26 21 ...nB.a..A....&! Dec 7 16:13:52 ssl_srv.c:3361 00d0: b4 0a 5e fe 50 0d 6f 45 a8 fe 15 18 87 e3 ae b3 ..^.P.oE........ Dec 7 16:13:52 ssl_srv.c:3361 00e0: ac 46 c5 c6 bb bc 70 1b 32 b7 15 c5 3d fb 09 1e .F....p.2...=... Dec 7 16:13:52 ssl_srv.c:3361 00f0: 8f 69 f7 e7 a8 86 4d 0b 87 ea 4b fe 08 7e 00 0b .i....M...K..~.. Dec 7 16:13:52 ssl_tls.c:3289 => write handshake message Dec 7 16:13:52 ssl_tls.c:2917 => ssl_flight_append Dec 7 16:13:52 ssl_tls.c:2953 <= ssl_flight_append Dec 7 16:13:52 ssl_tls.c:3425 <= write handshake message Dec 7 16:13:52 ssl_srv.c:3380 <= write server key exchange

3 years, 9 months

2
2
0 0

Benchmark on esp32

by Marco Portoni

Hi, Is it possible to run the benchmark of all cyphers natively on a ESP32 board? I have already run them on laptop but my goal is to run them on esp32, using for example tool like espifd.

3 years, 9 months

1
0
0 0

lists.trustedfirmware.org

by Philip Colmer

Hello You are receiving this email because you are subscribed to one or more mailing lists on lists.trustedfirmware.org. The purpose of this email is to let you know that the software on the server is being upgraded between Wednesday 29th December and Friday 31st December. During that time, the server will be unavailable and any email sent to a list on the server will be queued for later delivery. After the upgrade has been completed, you will receive a follow-up email from me to confirm that the upgrade has been completed and to provide you with instructions on how to set up your account on the new server. With the new software, you have one account regardless of how many mailing lists you are subscribed to. Regards Philip Colmer Director, Information Services Linaro

3 years, 9 months

1
0
0 0

Output a mbedtls_x509_crt?

by Felipe Gasper

Hello, Is it possible to output a mbedtls_x509_crt as PEM or DER? I’ve been combing the API docs but don’t see how I can do this export. I see controls for exporting a newly-built cert, but not one that comes from, e.g., mbedtls_ssl_get_peer_cert(). Thank you! Cheers, -Felipe Gasper

3 years, 9 months

2
3
0 0

What am I doing wrong?

by Felipe Gasper

https://gist.github.com/FGasper/43758d13e987518009d18ec8951ffcbb ^^ With 3.0.0 this prints: seeded entropy mbedtls connected trust loaded ok SNI set ok handshake tried handshake: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed … but if I switch to the development branch, it works. Same trust chain, same code … but the production code fails while the dev one works … Am I just “holding it wrong”? Thank you in advance! -FG

3 years, 9 months

1
1
0 0

MbedTLS - which protocols are advisable to support, and memory usage

by Peter

Hi All, I am new here. With a colleague, I am working on a product which previously used PolarSSL but was later changed to MbedTLS which, in the ST ARM 32F417 implementation, is believed to be less buggy. It is working ok as far as we have got, but we are finding that as well as needing some 100k more FLASH, it needs nearly 50k of RAM, which on the 32F417 (128k RAM) would normally be OK but due to other required functionality it leaves us just 10k. The architecture we are using for MbedTLS is a 48k (48k was found to be the smallest that works) static buffer within which TLS runs its own heap. I am aware that in the most generic case one has to have enough for one 16k buffer (plus a bit) for HTTPS, but what concerns me is that there appears to be no way to determine the worst case memory usage, across various usage scenarios. It would also be great to reduce this 48k to say 30k. Some of the protocols we know we don't need (e.g. PPP) but within any of them there is the question of which cipher suite needs supporting. What is the minimum cipher suite required to be able to use MbedTLS as an HTTPS client for use with typical current cloud-based file storage or data logging APIs such as Dropbox, Google Drive, Loggly etc? And what is the recommended minimum cipher suite required to implement an HTTPS server that would be able to negotiate a session with most current web-browsers? The goal is to ideally reduce both RAM and code size requirements for use in an embedded device that needs to work both as a general purpose server and client, without requiring support for multiple concurrent sessions. The other thing is that even the ST port of MbedTLS doesn't appear to make use of ST CPU hardware features such as AES256, DES, etc, which the 32F417 has in hardware. This speeds things up hugely but much more importantly in our case, saves a lot of RAM. For example AES256 can use about 10k if done in software. Thank you very much in advance for any input on what can be done. Peter

3 years, 9 months

1
0
0 0

Question about a research project: ESP32 mbed-tls

by Marco Portoni

Hello, I am Marco Portoni and I am working on a thesis research for the University of Study of Milan. It is focused on cryptographic libraries in the IoT world, and my question is: is it possible to run the benchmark on a ESP32? I have already runned the benchmark on 2 of my laptops to test and collected the results, but my ultimate goal is to make the benchmark run on the ESP. Is it possible to do it? Thanks for every help! Marco

3 years, 9 months

1
0
0 0

Build shared on macOS?

by Felipe Gasper

Hello, I’m trying to build shared from git on macOS and having no luck. I’m doing: > mkdir build; cd build > cmake DUSE_SHARED_MBEDTLS_LIBRARY=On .. … > make … > ls -la library total 2944 drwxr-xr-x 10 felipe staff 320 Dec 1 08:49 . drwxr-xr-x 15 felipe staff 480 Dec 1 08:49 .. drwxr-xr-x 8 felipe staff 256 Dec 1 08:49 CMakeFiles -rw-r--r-- 1 felipe staff 92755 Dec 1 08:49 Makefile -rw-r--r-- 1 felipe staff 2942 Dec 1 08:49 cmake_install.cmake -rw-r--r-- 1 felipe staff 34055 Dec 1 08:49 error.c -rw-r--r-- 1 felipe staff 916112 Dec 1 08:49 libmbedcrypto.a -rw-r--r-- 1 felipe staff 315856 Dec 1 08:49 libmbedtls.a -rw-r--r-- 1 felipe staff 104072 Dec 1 08:49 libmbedx509.a -rw-r--r-- 1 felipe staff 26265 Dec 1 08:49 version_features.c Am I just missing something? It seems like I’m following what the README says to do; I also did `export SHARED=1` just in case, but that made no difference. Thank you in advance! -FG

3 years, 9 months

3
3
0 0

Re: [mbed-tls] End of Life of LTS branch 2.16

by Dave Rodgman

Hi Radhika, We do not plan to extend support for Mbed TLS 2.16 beyond the three year support period. We do plan to release a 2.x LTS (probably 2.28) alongside the final 2.16 release, so that we always have an LTS available. Regards Dave Rodgman From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Radhika Jandhyala via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Radhika Jandhyala <radhikaj(a)microsoft.com> Date: Monday, 22 November 2021 at 10:50 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] End of Life of LTS branch 2.16 Hi, I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project. Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022? https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this? We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes. Thank you very much! Radhika

3 years, 10 months

2
2
0 0

Mbed TLS long term support release plans

by Dave Rodgman

Hi, Mbed TLS 2.16 LTS is approaching the end of its support period – it was originally announced that it would be maintained for at least 3 years up until the end of 2021 – and currently there is no other LTS branch. To ensure that there is no period of time without a supported LTS branch, we plan to release 2.28 LTS in the near future (which will have the usual 3 year support period). We will continue supporting 2.16 LTS until this is available. The expectation is that as 2.28 will be API-compatible with 2.16, users of 2.16 LTS will be able to upgrade to 2.28 very easily. Progress towards 2.28 LTS can be followed here: https://github.com/orgs/ARMmbed/projects/18#column-15836286 Dave Rodgman

3 years, 10 months

1
0
0 0

End of Life of LTS branch 2.16

by Radhika Jandhyala

Hi, I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project. Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022? https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this? We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes. Thank you very much! Radhika

3 years, 10 months

1
0
0 0

PSA Crypto non-optional in Mbed TLS 3.1

by Manuel Pegourie-Gonnard

Hi, We'd like to announce a change we intend to make: starting with Mbed TLS 3.1, it will no longer be possible to build with TLS, X.509, or PK without support for PSA Crypto. Details: currently, use of PSA Crypto APIs from the TLS, X.509 and PK layers is controlled by the option MBEDTLS_USE_PSA_CRYPTO. When this option is disabled (which is the default), it's possible to build without MBEDTLS_PSA_CRYPTO_C. Starting with 3.1, we intend to start making TLS, X.509 and PK use PSA Crypto unconditionally, so MBEDTLS_PSA_CRYPTO_C will be automatically enabled in the build as soon as TLS, X.509 or PK is enabled. Impact: for users who already build with PSA Crypto enabled (the default), no impact. For users who currently disable MBEDTLS_PSA_CRYPTO_C in their configuration, starting with 3.1 there will be no functional changes, but the size of the built library will increase due to the additional features enabled. The increase depends on the configuration, application, platform, and toolchain, but the order of magnitude currently ranges from about 9 KB for a minimal TLS configuration with LTO (link-time optimisation) to about 30 KB for a full configuration without link-time garbage collection (though size-constrained devices are very unlikely to use such a configuration); we aim to reduce this overhead in the future. Rationale: maintaining two versions of every cryptographic operation in upper layers (one PSA, one non-PSA) imposes a significant burden on new developments. By removing that burden, we hope to progress faster on things that are more important in the long run, including better integration of PSA Crypto in TLS and X.509, and future code size optimisation of PSA Crypto. We realise the impact on users who were excluding PSA Crypto is significant. We're going to release Mbed TLS 2.28 in the coming months, which is not affected by this change and will receive bug fixes and security fixes for at least 3 years; we hope it provides an acceptable fall-back solution to affected users. In the long run, PSA Crypto will become the only Crypto API we offer; we want to make its footprint as small as possible considering its feature set and we hope this change will enable us to make faster progress towards that goal. Best regards, Manuel Pégourié-Gonnard for the Mbed TLS team.

3 years, 10 months

1
0
0 0

About `MBEDTLS_ALLOW_PRIVATE_ACCESS`

by Aditya Patwardhan

Hi, While working on updating mbedtls to v3.0, I saw that the internal fields in MBEDTLS have been made private. ( ref- here<https://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guid…>). It says there and I quote "As a last resort, you can access the field foo of a structure bar by writing bar.MBEDTLS_PRIVATE(foo). Note that you do so at your own risk, since such code is likely to break in a future minor version of Mbed TLS.” I just wanted to know if there is any alternative solution to this, rather than using `MBEDTLS_PRIVATE` everywhere. I know the next release of mbedtls probably plans to fix this with appropriate solution. But we wanted to push out our feature branch As early as possible. I saw in the PR<https://github.com/zephyrproject-rtos/zephyr/pull/37753> in zephyr RTOS about updating to mbedtls-3.0. They have just added this line<https://github.com/ceolin/zephyr/blob/5bf3128a9703561e578651218f5bcdafb96f8…> #if !defined(MBEDTLS_ALLOW_PRIVATE_ACCESS) #define MBEDTLS_ALLOW_PRIVATE_ACCESS # endif Is this an alternative solution to using `MBEDTLS_PRIVATE` for accessing a private field. If yes, can somebody please point me to respective document as this would greatly reduce our code-changes. I understand there is some discussion going on in mbedtls about this change, and appropriate getter-setter functions shall be provided. But we wanted to push out out feature branch for early testing. Thanks and Regards, Aditya

3 years, 10 months

2
2
0 0

Mbed TLS Tech Forum

by Dave Rodgman

Hi, On Monday 8th we will have the next Mbed TLS Tech Forum. Please reply to the list if you have any agenda topics to raise. As a starter for the agenda, we will likely discuss: https://github.com/ARMmbed/mbedtls/pull/5067 Proposal for driver dispatch code gen Dave Rodgman Zoom details below. The call will be recorded and made available on the TF website : https://www.trustedfirmware.org/meetings/ Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt

3 years, 10 months

1
0
0 0

mbedtls client: TLS 1.2 Client Hello triggers a -0x7780 fatal internal server error...?

by secretimap＠nickpelling.com

Hi everyone, The company I’m working for uses mbedtls to drive an embedded TLS server (for HTTPS): but now needs the same device to also act as a TLS client for logging in to remote servers (e.g. for LDAP etc). My embedded test code tries (but fails) to connect to a remote HTTPS server on port 443: I can connect to the same server via openssl on a desktop command line, so it seems to be working. Basically, the client hello message goes out fine (for brevity, I’ve skipped all the ciphersuites, but note that the list does contain the 0xC030 ciphersuite that desktop openssl is able to connect to OK): .ssl_cli.c:934: client hello, got 25 ciphersuites (excluding SCSVs) .ssl_cli.c:943: adding EMPTY_RENEGOTIATION_INFO_SCSV .ssl_cli.c:992: client hello, compress len.: 1 .ssl_cli.c:994: client hello, compress alg.: 0 .ssl_cli.c:186: client hello, adding signature_algorithms extension .ssl_cli.c:271: client hello, adding supported_elliptic_curves extension .ssl_cli.c:336: client hello, adding supported_point_formats extension .ssl_cli.c:518: client hello, adding encrypt_then_mac extension .ssl_cli.c:552: client hello, adding extended_master_secret extension .ssl_cli.c:585: client hello, adding session ticket extension .ssl_cli.c:1071: client hello, total extension length: 52 0000: 16 03 01 00 95 01 00 00 91 03 03 16 e9 7a ea aa 0010: 31 81 60 b6 a8 d3 32 93 a4 50 ca f3 e0 66 f8 47 0020: 56 95 0c cd a0 db b6 0e ae a7 d4 00 00 34 c0 30 0030: 00 9f c0 ad c0 9f c0 24 c0 28 00 6b c0 0a c0 14 0040: 00 39 c0 af c0 a3 c0 2b c0 2f 00 9e c0 ac c0 9e 0050: c0 23 c0 27 00 67 c0 09 c0 13 00 33 c0 ae c0 a2 0060: 00 ff 01 00 00 34 00 0d 00 16 00 14 06 03 06 01 0070: 05 03 05 01 04 03 04 01 03 03 03 01 02 03 02 01 0080: 00 0a 00 04 00 02 00 17 00 0b 00 02 01 00 00 16 0090: 00 00 00 17 00 00 00 23 00 00 However, the server hello that comes back is both unhappy and unhelpful: .ssl_tls.c:2721: in_left: 5, nb_want: 7 .ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) .ssl_tls.c:2742: <= fetch input .ssl_tls.c:4233: dumping 'input record from network' (7 bytes) .ssl_tls.c:4233: 0000: 15 03 03 00 02 02 50 ......P .ssl_tls.c:5170: got an alert message, type: [2:80] .ssl_tls.c:5178: is a fatal alert message (msg 80) .ssl_tls.c:4369: mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) .ssl_cli.c:1506: mbedtls_ssl_read_record() returned -30592 (-0x7780) Putting the ciphersuites to one side, I suspect that what is happening here is that the (remote) server is complaining about a TLS extension the mbedtls client is either including or omitting. (I’ve already disabled the max fragment extension). But because I can’t see inside the remote server, I can’t tell. ☹ Might the mbedtls TLS client need the supported_versions extension (43) to work with many remote TLS servers? Is this a known issue? I’ve gone through loads of mailing list archive messages here, but haven’t found anything that matches this. Thanks, Nick PS: when OpenSSL connects to the server, the client hello message (that works fine) looks like this in Wireshark: Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 358 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 354 Version: TLS 1.2 (0x0303) Random: [SNIP] GMT Unix Time: Jan 21, 2095 20:50:07.000000000 GMT Standard Time Random Bytes: [SNIP] Session ID Length: 32 Session ID: [SNIP] Cipher Suites Length: 90 Cipher Suites (45 suites) [SNIP!] Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 191 Extension: status_request (len=5) Type: status_request (5) Length: 5 Certificate Status Type: OCSP (1) Responder ID list Length: 0 Request Extensions Length: 0 Extension: supported_groups (len=22) Type: supported_groups (10) Length: 22 Supported Groups List Length: 20 Supported Groups (10 groups) Supported Group: x25519 (0x001d) Supported Group: secp256r1 (0x0017) Supported Group: secp384r1 (0x0018) Supported Group: secp521r1 (0x0019) Supported Group: x448 (0x001e) Supported Group: ffdhe2048 (0x0100) Supported Group: ffdhe3072 (0x0101) Supported Group: ffdhe4096 (0x0102) Supported Group: ffdhe6144 (0x0103) Supported Group: ffdhe8192 (0x0104) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: signature_algorithms (len=34) Type: signature_algorithms (13) Length: 34 Signature Hash Algorithms Length: 32 Signature Hash Algorithms (16 algorithms) [SNIP!] Extension: signature_algorithms_cert (len=34) Type: signature_algorithms_cert (50) Length: 34 Signature Hash Algorithms Length: 32 Signature Hash Algorithms (16 algorithms) [SNIP!] Extension: status_request_v2 (len=9) Type: status_request_v2 (17) Length: 9 Certificate Status List Length: 7 Certificate Status Type: OCSP Multi (2) Certificate Status Length: 4 Responder ID list Length: 0 Request Extensions Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: supported_versions (len=5) Type: supported_versions (43) Length: 5 Supported Versions length: 4 Supported Version: TLS 1.3 (0x0304) Supported Version: TLS 1.2 (0x0303) Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: key_share (len=38) Type: key_share (51) Length: 38 Key Share extension Client Key Share Length: 36 Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 9f8e83a6859e6b4c6c3e43b524b81e6f63cc409c5757692a2343a2929c681c17

3 years, 10 months

1
0
0 0

Compact public ECC key representation

by Hristozov, Stefan

Hi all, For an IETF protocol that I am currently implementing a compact representation [1] of ECDH public keys needs to be sent over the network and be used on the receiving side for deriving a shared secret. With psa_export_public_key() I can export the public key form a psa_key_id_t object. The exported key is 65 bytes long (I am working with P256) which has the format 04|x|y as documented in [2]. It is easy to compress the public key before sending it -> just send the x part. How to decompress the x part back to the representation 04|x|y. As far I understand the psa_raw_key_agreement() function the public key must be encoded "in the same format that psa_import_key() accepts", that is 04|x|y [3]. Is there a function for that? [1]: https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#appendix-B draft-ietf-lake-edhoc-12<https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#appendix-B> Network Working Group G. Selander Internet-Draft J. Preuß Mattsson Intended status: Standards Track F. Palombini Expires: 23 April 2022 Ericsson 20 October 2021 Ephemeral Diffie-Hellman Over COSE (EDHOC) draft-ietf-lake-edhoc-12 Abstract This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. datatracker.ietf.org [2]: https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b… [https://opengraph.githubassets.com/aee6bf8d395880d12a54b66dd4188b9fd92064a1…]<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> An open source, portable, easy to use, readable and flexible SSL library - mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls github.com [3]: https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b… [https://opengraph.githubassets.com/aee6bf8d395880d12a54b66dd4188b9fd92064a1…]<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> An open source, portable, easy to use, readable and flexible SSL library - mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls github.com Br, Stefan

3 years, 11 months

1
0
0 0

Using mbedtls with a CA chain

by Loren Rogers

I need to use mbedtls (bundled with Nordic SDK, and unsure of version) to do some cloud-based functionality (AWS cloud, using OpenAM with a CA chain containing 4 certs). According to something I read, I need to use a pkcs7 container? If so, it seems that mbedtls does not support pkcs7? I did hand-copy some code from a PR, but as I was looking through the pkcs7.c, it seems that it still only supports the CA Root. Is this true? Is there anyone that can give me a hand in solving what I am attempting to do? Thank you /Loren Rogers

3 years, 11 months

1
0
0 0

password for the files root.cer, client1.cer and client1-key.pem

by lekshmi g

Dear Sir,/Madam We need to convert the files - root.cer,client1.cer and client1-key.pem to jks using the tool keystore explorer. For that, the password for the files are needed.Please provide passwords.We need to establish connection between java client and mbedtls c server.Kindly provide help. Regards Lekshmi G

3 years, 11 months

1
0
0 0

TLS connection establishment between OpenMUC java client and mbedtls server

by lekshmi g

Dear Madam/Sir, We are working on a project which requires IEC 62351 standards. For that we had developed a TLS server in C language and we had the requirement of developing a TLS client in Java language. We had used the *mbedTLS library for server* and *OpenMUC libraries for client*. But we are getting exception while certificate exchange phase and all. We had attached the listed exceptions and errors. Kindly provide necessary support for the same. Also please confirm whether we can develop above specified architecture, ie TLS based server in C language and client in Java. If available please share some sample programs also. Please reply ASAP. We have debugged the code and the following are the messages we have got in mbedtls java server and OPENMUC java tls client . During certificate exchange from client to server (MBEDTLS_SSL_CLIENT_CERTIFICATE case in server), the function returns a nonzero value and the alert shows in server is 49 (ie, MBEDTLS_SSL_ALERT_MSG_ACCESS_DENIED). *Please check Fig 1 and Fig 2* for the messages displayed during connection establishment.Kindly help us to solve the issues. [image: image.png] Fig 1- case:MBEDTLS_SSL_CLIENT_CERTIFICATE fails [image: image.png] Fig 2-OPENMUC java client error when connecting to mbedtlsserver ReplyForward <https://drive.google.com/u/0/settings/storage?hl=en&utm_medium=web&utm_sour…> <https://www.google.com/intl/en/policies/terms/> <https://www.google.com/intl/en/policies/privacy/> <https://www.google.com/gmail/about/policy/>

3 years, 11 months

1
0
0 0

[Mbed-tls-announce] Mbed TLS Tech Forum

by Dave Rodgman via Mbed-tls-announce

Hi, I would like to announce the Mbed TLS Tech Forum, a regular engineering call to discuss topics of interest to the Mbed TLS community. The call is currently planned to take place every two weeks, alternating between US-friendly and China-friendly times (16:30 and 10:00 UK time), starting on the 25th October at 16:30 BST. Please reply to the list if you have any agenda topics to raise. As a starting point, we will cover: Format – check if times & cadence are suitable TLS 1.3 – high-level update on progress & direction PSA Cryptoprocessor Driver Interface – code generation for driver dispatch as per https://github.com/ARMmbed/mbedtls/pull/5067 Zoom details below. The call will be recorded and made available on the TF website: https://www.trustedfirmware.org/meetings/ Dave Rodgman Mbed TLS tech lead -- Dave Rodgman is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://armltd.zoom.us/j/93259847316?pwd=N0d4Z0o5RXRLKzZFaE1sd044bm14dz09&f… Meeting ID: 932 5984 7316 Passcode: 991642 One tap mobile +442034815240,,93259847316#,,,,*991642# United Kingdom Dial by your location +44 203 481 5240 United Kingdom +1 346 248 7799 US (Houston) +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +91 116 480 2722 India +91 224 879 8012 India +91 406 480 2722 India +91 806 480 2722 India +852 5803 3730 Hong Kong SAR +46 8 4468 2488 Sweden +972 3 978 6688 Israel +353 1 536 9320 Ireland +36 1 408 8456 Hungary +33 1 7037 2246 France +358 3 4109 2129 Finland +45 32 70 12 06 Denmark +1 438 809 7799 Canada +65 3158 7288 Singapore +27 87 550 3946 South Africa +32 1579 5132 Belgium +48 22 307 3488 Poland +386 1600 3102 Slovenia +60 3 3099 2229 Malaysia +886 (2) 7741 7473 Taiwan Meeting ID: 932 5984 7316 Passcode: 991642 Find your local number: https://armltd.zoom.us/u/adTMafG7oQ Join by SIP 93259847316(a)zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 209.9.211.110 (Hong Kong SAR) 149.137.40.110 (Singapore) 64.211.144.160 (Brazil) 69.174.57.160 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 932 5984 7316 Passcode: 991642 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 https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

3 years, 11 months

3
2
0 0

switching from libressl to MbedTLS

by LM

I'm hoping to make the switch from libressl to MbedTLS. I'm working on a Linux from scratch style project. Curl works fine with MbedTLS and most of the utilities I work with use libcurl. I'm also using libtomcrypt for some of its hash and cryptographic functionality. The only place I'm having a problem making the switch at present is when I follow the LFS logic to make certificates (make-ca). There's a openssl/libressl command in the script that looks like the following: openssl x509 -hash -noout -in "$1" Is there a way to replace this functionality with a command or procedure or function from another program so that libressl or openssl isn't needed to perform this step? Thanks.

3 years, 11 months

1
0
0 0

Mbedtls Client Key Exchange Time

by Duygu D.

Hello, I'm using mbedTLS on baremetal lwip+stm32f4 system as a Server. TLS working successfully with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 but when I receive the Client Hello message than my receive proccess function in ethernetif_input: err = netif->input(p, netif); takes 300ms time. This function normaly takes 1ms. I need to reduce this time. How Can I do that ? This is my config file: https://paste.ofcode.org/Bdt4FapskKY7M5ggm3uViJ Best Regards. -- Embeded System Engineer

3 years, 11 months

1
0
0 0

passing jks format client certificate

by lekshmi g

Dear Madam/Sir We need to establish connection with security between MMS client application in java(OPENMUC java client) and MMS server (tls_server_example in mbedtls).The java client application uses keystore.jks and truststore.jks (*jks format* ) instead of certificate in *cer *format.Is it possible to establish connection between OPENMUC java mms client and libiec61850 1.5 with mbedtls-2.16.6* ?* . We have added the *root.cer details *(certificate in the sample mbedtls server program ) to * truststore.jks* in client (openmuc java) and *client1.cer details* (client1 certificate in the sample mbedtls server program ) *to keystore.jks* .When trying to establish connection server hello messages are completed ,but showing the following error: *MBEDTLS_ERR_SSL_NO_CLIENT_CERTIFICATE.* * Please help...* *Regards* *Lekshmi G*

3 years, 11 months

1
0
0 0

Re: [mbed-tls] [TF-M] Adding platform specific functions to Crypto Service.

by Fabian Schmidt

Hi Roman, My understanding is that you would like to add features to the Crypto service API, but the features which you would like to add are not cryptographic in nature. Have you considered creating your own service for those features, instead of modifying the Crypto service? Or is there anything makes this not a viable option? If you are thinking about adding hardware acceleration for some Crypto features, that's indeed covered in Shebu's link. Greetings, Fabian Schmidt From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: Dienstag, 12. Oktober 2021 11:46 To: David Hu <David.Hu(a)arm.com>; Roman.Mazurak(a)infineon.com; tf-m(a)lists.trustedfirmware.org; mbed-tls(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] Adding platform specific functions to Crypto Service. Caution: EXT Email Hi Roman, I also might not have understood the question completely. As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver -interface.md <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2FARMmbed%2Fmbedtls%2Fblob%2Fdevelopment%2Fdocs%2Fproposed%2Fpsa-driver-in terface.md&data=04%7C01%7Cfabian.schmidt%40nxp.com%7C17489158b6384ef5caa308d 98d654ead%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637696288543072051%7C Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC JXVCI6Mn0%3D%7C1000&sdata=uKX4sUH37jNx1%2BvACuN8tBQl05OaXPPnMT9FqMwbhdU%3D&r eserved=0> Also adding mbed-tls mailing list as the thread is crypto related.. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org <mailto:tf-m-bounces@lists.trustedfirmware.org> > On Behalf Of David Hu via TF-M Sent: Tuesday, October 12, 2021 4:18 AM To: Roman.Mazurak(a)infineon.com <mailto:Roman.Mazurak@infineon.com> ; tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com <mailto:nd@arm.com> > Subject: Re: [TF-M] Adding platform specific functions to Crypto Service. Hi Roman, Are you asking about adding platform specific HAL API to implement PSA Crypto API function? Please correct me if I misunderstand your question. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org <mailto:tf-m-bounces@lists.trustedfirmware.org> > On Behalf Of Roman Mazurak via TF-M Sent: Monday, October 11, 2021 9:45 PM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Adding platform specific functions to Crypto Service. Hi all, We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions? Best regards, Roman.

3 years, 11 months

3
3
0 0

Re: [mbed-tls] Adding platform specific functions to Crypto Service.

by Shebu Varghese Kuriakose

Hi Roman, I also might not have understood the question completely. As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive… Also adding mbed-tls mailing list as the thread is crypto related.. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, October 12, 2021 4:18 AM To: Roman.Mazurak(a)infineon.com; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Adding platform specific functions to Crypto Service. Hi Roman, Are you asking about adding platform specific HAL API to implement PSA Crypto API function? Please correct me if I misunderstand your question. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Roman Mazurak via TF-M Sent: Monday, October 11, 2021 9:45 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Adding platform specific functions to Crypto Service. Hi all, We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions? Best regards, Roman.

3 years, 11 months

1
0
0 0

MbedTLS and IPv4 packet length problem

by Duygu D.

Hello, I am using this example for the source of the my main purpose : https://github.com/straight-coding/LPC407x-NoOS-LWIP-MBEDTLS-HTTPD-KEIL/blo… This example using https but I'm trying to use this example on Modbus Server. This is init function for the server tcp connections: BOOL xMBTCPPortInit( USHORT usTCPPort ) { struct altcp_pcb *pxPCBListenNew, *pxPCBListenOld; BOOL bOkay = (BOOL)FALSE; USHORT usPort; extern struct altcp_tls_config* getTlsConfig(void); tls_config = getTlsConfig(); mbedtls_ssl_conf_dbg(tls_config, my_debug, NULL); mbedtls_debug_set_threshold(5); if( usTCPPort == 0 ) { usPort = MB_TCP_DEFAULT_PORT; } else { usPort = ( USHORT ) usTCPPort; } if( ( pxPCBListenNew = pxPCBListenOld = altcp_tls_new( tls_config,IPADDR_TYPE_ANY) ) == NULL ) { /* Can't create TCP socket. */ bOkay = (BOOL)FALSE; } else if( altcp_bind( pxPCBListenNew, IP_ANY_TYPE, ( u16_t ) usPort ) != ERR_OK ) { /* Bind failed - Maybe illegal port value or in use. */ ( void )altcp_close( pxPCBListenOld ); bOkay = (BOOL)FALSE; } else if( ( pxPCBListenNew = altcp_listen( pxPCBListenNew ) ) == NULL ) { ( void )altcp_close( pxPCBListenOld ); bOkay = (BOOL)FALSE; } else { // altcp_tls_new(pxPCBListenNew, IP_GET_TYPE(ip_addr))*/; /* Register callback function for new clients. */ altcp_accept( pxPCBListenNew, prvxMBTCPPortAccept ); /* Everything okay. Set global variable. */ pxPCBListen = pxPCBListenNew; #ifdef MB_TCP_DEBUG vMBPortLog( MB_LOG_DEBUG, "MBTCP-ACCEPT", "Protocol stack ready.\r\n" ); #endif SerialPrint("MBTCTP-ACCEPT"); } bOkay = (BOOL)TRUE; return bOkay; } struct altcp_tls_config* getTlsConfig(void) { struct altcp_tls_config* conf; size_t privkey_len = strlen(privkey) + 1; size_t privkey_pass_len = strlen(privkey_pass) + 1; size_t cert_len = strlen(cert) + 1; conf = altcp_tls_create_config_server_privkey_cert((u8_t*)privkey, privkey_len, (u8_t*)privkey_pass, privkey_pass_len, (u8_t*)cert, cert_len); return conf; } And I am using basic python tls client example to show successful mbedtls handshake. This is my client.py codes: import time from socket import create_connection from ssl import SSLContext, PROTOCOL_TLS_CLIENT import ssl hostname='example.org' ip = '192.168.1.2' port = 502 context = SSLContext(PROTOCOL_TLS_CLIENT) context.options |= ssl.OP_NO_SSLv3 context.options |= ssl.OP_NO_TLSv1 context.options |= ssl.OP_NO_TLSv1_1 context.load_verify_locations('cert.pem') with create_connection((ip, port)) as client: with context.wrap_socket(client, server_hostname=hostname) as tls: print(f'Using {tls.version()}\n') tls.sendall(b'Hello world') data = tls.recv(1024) print(f'Server says: {data}') When I try to start communication I get below outputs on wireshark: [image: image.png] When the server send hello message I've this error on the line: [image: image.png] When I checked the low_level_output functions I get sending data bytes 150 byte but Ipv4 length shows us 576 byte, opt.h file set as default but if I changed TCP_MSS as a 250 byte so I can send 136 byte and Ipv4 packet lenght shows me 136. But does not make sense. I couldnt do successful handshaking. My mbedtls debug outputs in this link https://paste.ofcode.org/PP3zFmrLcKqPdRMT3LzETz How cna I solve this problem ? What is the reason for the lenght problem ? Best Regards. -- Embeded System Engineer

3 years, 11 months

3
4
0 0

image-20211001180442075

by Shudong Zhang

Hello, I am very sorry about last email by mistakes. I have some questions about multiplication on ecp curves. I add an ecp curve parameter in ecp_curve.c form SM2 algorithm standard, and the parameter is as follow: Then I followed the loading method of secp256r1 to load, but I don’t know how to perform fast calculations, so I commented NIST_MODP( p256 ). #if defined(MBEDTLS_ECP_DP_SECP256R1_ENABLED) caseMBEDTLS_ECP_DP_SECP256R1: NIST_MODP( p256 ); return( LOAD_GROUP( secp256r1 ) ); #endif #if defined(MBEDTLS_ECP_DP_SM256_ENABLED) caseMBEDTLS_ECP_DP_SM256: //NIST_MODP( p256 ); return( LOAD_GROUP_A( sm256 ) ); #endif Then I call the functional interface mbedtls_ecp_mul to perform the multiplication operation, but the heap memory keeps increasing . voidtest() { intret; mbedtls_mpiUd; mbedtls_ecp_groupgrp; mbedtls_ecp_pointT_Q; mbedtls_mpi_init(&Ud); mbedtls_ecp_group_init( &grp ); mbedtls_ecp_point_init( &T_Q ); ret=mbedtls_mpi_read_binary(&Ud, arrUd, sizeof(arr_U_d)); // ret = mbedtls_ecp_group_load(&grp,MBEDTLS_ECP_DP_SECP256R1); ret=mbedtls_ecp_group_load(&grp,MBEDTLS_ECP_DP_SM256); ret=mbedtls_ecp_mul(&grp, &T_Q, &Ud, &(grp.G), NULL, NULL) ; printf("%x\n", -ret); mbedtls_mpi_free(&Ud); mbedtls_ecp_group_free( &grp ); mbedtls_ecp_point_free( &T_Q ); } intmain() { for(inti=0; i<10; i++) test(); return0; } The heap memory is mesaured by massif( valgring tools), Can someone tell me what this is because of and how to fix this problem ? Best Regards. Shudong Zhang

3 years, 11 months

1
0
0 0

Add an ecp curves, but the multiplication add heap memory continuouly

by Shudong Zhang

Hello， I add an ecc curve parameter in ecp_curve.c form SM2 algorithm, and the parameter is as follow:

3 years, 11 months

2
1
0 0

Unable to enable CCM ciphers in mbedtls

by Ron Eggler

The |mbedtls| client project I'm working on, is to also support the cipher suites: |TLS-ECDHE-ECDSA-WITH-AES-256-CCM| & |TLS-ECDHE-ECDSA-WITH-AES-128-CCM|. I have specified them like: |const int ciphersuites[] = { MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA384, MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM, MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_256_CCM, 0 }; mbedtls_ssl_conf_ciphersuites(&ctxt->conf,ciphersuites); | and while I can see the GCM ciphers in the |Client Hello|, I cannot see the |CCM| ciphers. In |mbedtls/include/mbedtls/config.h|, the following are enabled: |#define MBEDTLS_CCM_ALT #define MBEDTLS_CCM_C #define MBEDTLS_ECDH_GEN_PUBLIC_ALT #define MBEDTLS_ECDH_COMPUTE_SHARED_ALT #define MBEDTLS_ECDSA_SIGN_ALT | What is still missing? While CCM is not listed under The following ciphers may be included <https://tls.mbed.org/module-level-design-cipher>, the ciphers i would like to add definitely show up under Supported SSL / TLS ciphersuites <https://tls.mbed.org/supported-ssl-ciphersuites>, Can someone help out?

3 years, 11 months

2
2
0 0

RAM usage and Slowness issue

by Sunil Jain

Hello, *RAM USAGE:* We are using mbedTLS 2.16 for TLS communication and found that it is consuming more RAM compared to other Cybersecurity library (Mocana ) which we were using earlier. I want to reduce the RAM usage, if there are any settings which i can apply to reduce the RAM usage Presently MbedTLS is using almost 38KB of RAM per TLS connection, I have small memory in my device (STM32F437), I want to reduce this RAM consumption to 30KB per TLS connection. *SLOWNESS:* we have found that after 4 TLS connections on STM32F437 controller, communication becomes very slow, we measured the CPU utilization at this point of time, and it's only 40% ustilized, we are not getting any clue why it becomes so slow. When we compare with Mocana cyber security library we were able to run 6 TLS connections with good speed. Please help us with the above 2 topics. -- Thanks and Regards, Sunil Jain

3 years, 12 months

2
1
0 0

TLS 1.3 support

by Alex Sukhov

Hi mbedTLS team, Our teams are in the process of reviewing available TLS library options. Is there any information that we can find with respect to the mbedTLS stance on TLS 1.3 support? I.E is there a timeline available supporting TLS 1.3? Alternatively is there documentation available that outlines the expected deltas between TLS 1.2 and 1.3 that can help compare the value gained by using TLS 1.3 instead of 1.2? Regards, Alex Sukhov Geotab Embedded System Developer, Team Lead Toll-free Visit +1 (877) 431-8221 www.geotab.com Twitter <https://twitter.com/geotab> | Facebook <https://www.facebook.com/Geotab> | YouTube <https://www.youtube.com/user/MyGeotab> | LinkedIn <https://www.linkedin.com/company/geotab/>

4 years

3
2
0 0

Doubt in mbedtls version support for libiec61850-1.5

by lekshmi g

When we are using the version *mbedtls-2.16.6* with *libiec61850-1.5*, the TLS connection is established successfully. But when we use the *2.7.19*, the connection fails(we renamed *mbedtls 2.7.19* as *mbedtls 2.16* and put in the folder third_party\mbedtls ). We had occurred following error during the execution of client- server example programs tls_server_example and tls_client_example using 2.7.19 version. During handshaking process till CASE " MBEDTLS_SSL_CLIENT_CHANGE_CIPHER_SPEC " it worked as expected. But In CASE "MBEDTLS_SSL_CLIENT_FINISHED" the return value should be zero. But we got in function mbedtls_ssl_safer_memcmp mac_peer==41155316 mac_expect==41155356 diff=255 (this value has to be 0 for connection establishment) But we are getting 255 constantly in all runnings. Kindly help us to resolve the issue. If this issue is due to the non supporting of mbedtls version ?.Thanks in advance. Please let us know the *supporting versions of mbedtls *for *libiec61850-1.5 *.

4 years

2
2
0 0

2025

2024

2023

2022

2021

2020

mbed-tls