- mbed-tls - lists.trustedfirmware.org

Custom MBEDTLS_CONFIG_FILE with CMake subproject

by mickael.bonjour＠cysec.com

Hello, I need some help to setup mbedtls as a CMake subproject, I added it as a subdirectory in my CMakeLists. However, I can't figure out how to use my own config file for mbedtls (MBEDTLS_CONFIG_FILE option to the file I want as a config file). When I put my custom config file to the include folder of mbedtls in the place of the original mbedtls_config.h file it works wel,l but it's not a future-proof option for me, is there anyone that could help me with this setup ?

2 years, 4 months

2
1
0 0

Missing PSA wrapper for MAC verify

by Ruchika Gupta

Hi, I have noticed that PSA driver wrapper function is missing for single part MAC verify function. In the current implementation, it calls the MAC compute wrapper and does the comparison using mbedtls_psa_safer_memcmp. The hardware I am working on allows the complete process to be offloaded to it. Can we have an option for the same in wrapper layer for PSA for MAC verify ? Regards, Ruchika

2 years, 4 months

2
2
0 0

New releases: Mbed TLS 3.4.1 and 2.28.4 LTS

by Dave Rodgman

Hi Mbed TLS users, We are releasing Mbed TLS 3.4.1 and 2.28.4 LTS. As the point release suggests, this is a small update which primarily addresses some expiring test certificates. Full details are available via the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.4.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.4 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Thanks, The Mbed TLS team

2 years, 4 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 3am to 3:50am on Monday from Mon Jan 30 to Sun Aug 13 (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been updated Changed: time MBed TLS Technical Forum - Asia Every 4 weeks from 3am to 3:50am on Monday from Monday Jan 30 to Sunday Aug 13 Mountain Standard Time - Phoenix 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 Guests 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 kris.kwiatkowski(a)pqshield.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=MzE1cHJuZGxwMDFo… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=MzE1cHJuZGxwMDFo… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

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

by don.harbin＠linaro.org

This event has been updated Changed: time, description MBed TLS Technical Forum - Asia Every 4 weeks from 2am to 2:50am on Monday 3 times Mountain Standard Time - Phoenix Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS - AsisTime: Aug 14, 2023 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Aug 14, 2023 10:00 AM Sep 11, 2023 10:00 AM Oct 9, 2023 10:00 AM Nov 6, 2023 10:00 AM Dec 4, 2023 10:00 AM Jan 1, 2024 10:00 AM Jan 29, 2024 10:00 AM Feb 26, 2024 10:00 AM Mar 25, 2024 10:00 AM Apr 22, 2024 10:00 AM May 20, 2024 10:00 AM Jun 17, 2024 10:00 AM Jul 15, 2024 10:00 AM Aug 12, 2024 10:00 AM Sep 9, 2024 10:00 AM Oct 7, 2024 10:00 AM Nov 4, 2024 10:00 AM Dec 2, 2024 10:00 AM Dec 30, 2024 10:00 AM Jan 27, 2025 10:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEpcOivrT4jGtzyd1M9ASL221VfGUYcCKhw/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95471735908?pwd=WStaaWhEVXNqcWx1S2pEQU13cHU2UT09Meeting ID: 954 7173 5908Passcode: 300608---One tap mobile+13462487799,,95471735908# US (Houston)+16694449171,,95471735908# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 689 278 1000 US• +1 301 715 8592 US (Washington DC)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 954 7173 5908Find your local number: https://linaro-org.zoom.us/u/aEkjrvuAZ Guests 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 kris.kwiatkowski(a)pqshield.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=MzE1cHJuZGxwMDFo… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=MzE1cHJuZGxwMDFo… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

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

by don.harbin＠linaro.org

This event has been updated MBed TLS Technical Forum Every 4 weeks from 9:30am to 10:30am on Monday 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 View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

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

by don.harbin＠linaro.org

This event has been updated Changed: title, description MBed TLS Technical Forum - US Every 4 weeks from 8:30am to 9:30am on Monday Mountain Standard Time - Phoenix Trusted Firmware is inviting you to a scheduled Zoom meeting.Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Tech Forum - USTime: Aug 28, 2023 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Aug 28, 2023 04:30 PM Sep 25, 2023 04:30 PM Oct 23, 2023 04:30 PM Nov 20, 2023 04:30 PM Dec 18, 2023 04:30 PM Jan 15, 2024 04:30 PM Feb 12, 2024 04:30 PM Mar 11, 2024 04:30 PM Apr 8, 2024 04:30 PM May 6, 2024 04:30 PM Jun 3, 2024 04:30 PM Jul 1, 2024 04:30 PM Jul 29, 2024 04:30 PM Aug 26, 2024 04:30 PM Sep 23, 2024 04:30 PM Oct 21, 2024 04:30 PM Nov 18, 2024 04:30 PM Dec 16, 2024 04:30 PM Jan 13, 2025 04:30 PM Feb 10, 2025 04:30 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJ0udu2spj0vHtbQtlCmHwhHCT7ECtJI39J4/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/99314486542?pwd=Q1ZjaFhQeDRrQWxsa3MvT1Mwditqdz09Meeting ID: 993 1448 6542Passcode: 628327---One tap mobile+13462487799,,99314486542# US (Houston)+16694449171,,99314486542# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 993 1448 6542Find your local number: https://linaro-org.zoom.us/u/adSjuOyMhI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org nnac123(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

Reminder: MBed TLS Tech Forum - US/Europe External

by Don Harbin

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

2 years, 4 months

1
0
0 0

mbedtls_pk_verify verify report MBEDTLS_ERR_RSA_VERIFY_FAILED

by yang ming

When `mbedtls_pk_verify` is used to verify digital signatures generated by openssl, the MBEDTLS_ERR_RSA_VERIFY_FAILED error occurs, openssl Specifies the command used to generate a certificate: ```bash openssl md5 -sign private.key -out sign test.md ``` But when I use `mbedtls_pk_sign(&pk_pri_ctx, MBEDTLS_MD_MD5, md, 0, sign_info, sizeof(sign_info), &size, mbedtls_ctr_drbg_random, &ctrl_drbg)` Generating the signature and using `mbedtls_pk_verify` results are successful, Print the signatures generated by mbedtls are not found to be the same as those generated by openssl. Please help。 mbedtls version: ```c #define MBEDTLS_VERSION_STRING "3.4.0" #define MBEDTLS_VERSION_STRING_FULL "mbed TLS 3.4.0" ``` openssl version: ```c OpenSSL 1.1.1 11 Sep 2018 ```

2 years, 5 months

2
1
0 0

PSA crypto drivers

by Ruchika Gupta

Hi, I am currently working on PSA driver for our SoC's security crypto-processor. This processor needs to do some handling when a key is destroyed. In the current implementation in mbedTLS, I don't see a driver wrapper function available in psa_destroy_key(). Is there a specific reason for not having wrapper for driver function available for psa_destroy_key() ? Another query pertaining to the tests in the testsuite in mbedTLS. I was exploring if I could reuse the tests for the crypto-processor implementation. Have these been written with this kind of reuse in mind ? Basically I would like the ability to add driver location to the cases. The few cases I have looked at for psa seem to be very specific. Any pointers/suggestions if anyone is reusing this test suite to test their specific PSA drivers? Regards, Ruchika

2 years, 5 months

2
1
0 0

Crash observed while using MBED-TLS

by Ajay Mishra

Hi All, Thank you for sharing the MBED-TLS open source platform. I need help with on of the crashes that I am observing right now. Below are my setup details: Below are my setup details: System information Client side setup Platform : Micro controller based platform stm32 OS : FreeRTOS Compiler: gcc-arm-none-eabi-8-2019-q3-update Below is the backtrace: (gdb) bt #0 panicCB (file=0xc94d7 "memory", line=734, message=0x2000ff50 <sli_wisun_event_loop_task_stack+4224> "Ajay Malloc Failed 88") at build/3pp/freertos/FreeRTOS/Source/include/../../Source/portable/GCC/ARM_CM3/portmacro.h:237 #1 0x0003b2ae in panicHalt_ (file=file@entry=0xc94d7 "memory", line=line@entry=734, message=<optimized out>) at src/platform/core/assert.c:34 #2 0x0003bf0a in reallocInternal (p=<optimized out>, size=68, zeroFill=<optimized out>, file=0xc94d7 "memory", line=734) at src/platform/core/memory.c:317 #3 0x0003c2d8 in reallocWrapper (p=p@entry=0x0, size=<optimized out>, zeroFill=zeroFill@entry=true, file=file@entry=0xc94d7 "memory", line=line@entry=734) at src/platform/core/memory.c:673 #4 0x0003c350 in platformCalloc (n=<optimized out>, size=<optimized out>) at src/platform/core/memory.c:734 #5 0x00043dac in mbedtls_mpi_grow (nblimbs=17, X=0x2001001c <sli_wisun_event_loop_task_stack+4428>) at build/3pp/mbedtls/library/bignum.c:125 #6 mbedtls_mpi_grow (X=0x2001001c <sli_wisun_event_loop_task_stack+4428>, nblimbs=17) at build/3pp/mbedtls/library/bignum.c:115 #7 0x0004414a in mbedtls_mpi_shift_l (X=X@entry=0x2001001c <sli_wisun_event_loop_task_stack+4428>, count=count@entry=256) at build/3pp/mbedtls/library/bignum.c:1016 #8 0x00044818 in mbedtls_mpi_div_mpi (Q=Q@entry=0x0, R=R@entry=0x200100bc <sli_wisun_event_loop_task_stack+4588>, A=A@entry=0x200100bc <sli_wisun_event_loop_task_stack+4588>, B=B@entry=0x200101d0 <sli_wisun_event_loop_task_stack+4864>) at build/3pp/mbedtls/library/bignum.c:1812 #9 0x00044a46 in mbedtls_mpi_mod_mpi (R=R@entry=0x200100bc <sli_wisun_event_loop_task_stack+4588>, A=A@entry=0x200100bc <sli_wisun_event_loop_task_stack+4588>, B=B@entry=0x200101d0 <sli_wisun_event_loop_task_stack+4864>) at build/3pp/mbedtls/library/bignum.c:1917 #10 0x00046486 in ecdsa_verify_restartable (grp=grp@entry=0x20010184 <sli_wisun_event_loop_task_stack+4788>, buf=buf@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", blen=blen@entry=32, Q=Q@entry=0x2001020c <sli_wisun_event_loop_task_stack+4924>, r=r@entry=0x20010120 <sli_wisun_event_loop_task_stack+4688>, s=s@entry=0x2001012c <sli_wisun_event_loop_task_stack+4700>, rs_ctx=0x0) at build/3pp/mbedtls/library/ecdsa.c:649 #11 0x00046660 in mbedtls_ecdsa_read_signature_restartable (ctx=ctx@entry=0x20010184 <sli_wisun_event_loop_task_stack+4788>, hash=hash@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hlen=hlen@entry=32, sig=sig@entry=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, slen=slen@entry=70, rs_ctx=rs_ctx@entry=0x0) at build/3pp/mbedtls/library/ecdsa.c:881 #12 0x0004668e in mbedtls_ecdsa_read_signature (ctx=ctx@entry=0x20010184 <sli_wisun_event_loop_task_stack+4788>, hash=hash@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hlen=hlen@entry=32, sig=sig@entry=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, slen=slen@entry=70) at build/3pp/mbedtls/library/ecdsa.c:832 #13 0x0004a830 in ecdsa_verify_wrap (ctx=ctx@entry=0x20010184 <sli_wisun_event_loop_task_stack+4788>, md_alg=md_alg@entry=MBEDTLS_MD_SHA256, hash=hash@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hash_len=hash_len@entry=32, sig=sig@entry=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, sig_len=sig_len@entry=70) at build/3pp/mbedtls/library/pk_wrap.c:633 #14 0x0004a872 in eckey_verify_wrap (ctx=<optimized out>, md_alg=<optimized out>, hash=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hash_len=32, sig=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, sig_len=70) at build/3pp/mbedtls/library/pk_wrap.c:252 #15 0x0004a3de in mbedtls_pk_verify (ctx=ctx@entry=0x2001ce48, md_alg=<optimized out>, hash=<optimized out>, hash_len=<optimized out>, sig=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, sig_len=70) at build/3pp/mbedtls/library/pk.c:326 #16 0x0004a55c in mbedtls_pk_verify_ext (type=<optimized out>, options=<optimized out>, ctx=ctx@entry=0x2001ce48, md_alg=<optimized out>, hash=<optimized out>, hash@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hash_len=<optimized out>, hash_len@entry=32, sig=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, sig_len=70) at build/3pp/mbedtls/library/pk.c:390 #17 0x0004feb4 in x509_crt_check_signature (rs_ctx=<optimized out>, parent=0x2001cd7c, child=0x2001f8a8) at build/3pp/mbedtls/library/x509_crt.c:2474 #18 x509_crt_find_parent_in (rs_ctx=<optimized out>, self_cnt=<optimized out>, path_cnt=<optimized out>, top=<optimized out>, r_signature_is_good=<optimized out>, r_parent=<optimized out>, candidates=<optimized out>, child=<optimized out>) at build/3pp/mbedtls/library/x509_crt.c:2612 #19 x509_crt_find_parent (rs_ctx=<optimized out>, self_cnt=<optimized out>, path_cnt=<optimized out>, signature_is_good=<optimized out>, parent_is_trusted=<optimized out>, parent=<optimized out>, trust_ca=<optimized out>, child=<optimized out>) at build/3pp/mbedtls/library/x509_crt.c:2709 #20 x509_crt_verify_chain (f_ca_cb=0x0, p_ca_cb=0x0, rs_ctx=0x0, ver_chain=0x200102c4 <sli_wisun_event_loop_task_stack+5108>, profile=0xcd08c <mbedtls_x509_crt_profile_default>, ca_crl=0x0, trust_ca=0x2001cd7c, crt=0x2001f8a8) at build/3pp/mbedtls/library/x509_crt.c:2919 #21 x509_crt_verify_restartable_ca_cb (crt=crt@entry=0x2001f8a8, trust_ca=trust_ca@entry=0x2001cd7c, ca_crl=0x0, profile=0xcd08c <mbedtls_x509_crt_profile_default>, cn=0x0, flags=0x2001dd30, f_vrfy=0x695f1 <tls_sec_prot_lib_x509_crt_verify>, p_vrfy=0x2001c8a0, rs_ctx=0x0, p_ca_cb=0x0, f_ca_cb=0x0) at build/3pp/mbedtls/library/x509_crt.c:3150 --Type <RET> for more, q to quit, c to continue without paging-- #22 0x00050090 in mbedtls_x509_crt_verify_restartable (crt=crt@entry=0x2001f8a8, trust_ca=trust_ca@entry=0x2001cd7c, ca_crl=<optimized out>, profile=<optimized out>, cn=0x0, flags=0x2001dd30, f_vrfy=0x695f1 <tls_sec_prot_lib_x509_crt_verify>, p_vrfy=0x2001c8a0, rs_ctx=rs_ctx@entry=0x0) at build/3pp/mbedtls/library/x509_crt.c:3258 #23 0x00058f7c in ssl_parse_certificate_verify (rs_ctx=0x0, chain=0x2001f8a8, authmode=<optimized out>, ssl=0x2001c918) at build/3pp/mbedtls/library/ssl_tls.c:2542 #24 mbedtls_ssl_parse_certificate (ssl=ssl@entry=0x2001c918) at build/3pp/mbedtls/library/ssl_tls.c:2795 #25 0x00051d1c in mbedtls_ssl_handshake_client_step (ssl=0x2001c918) at build/3pp/mbedtls/library/ssl_cli.c:4295 #26 0x00058210 in mbedtls_ssl_handshake_step (ssl=0x2001c918) at build/3pp/mbedtls/library/ssl_tls.c:5668 #27 0x00069922 in tls_sec_prot_lib_process () #28 0x0006b442 in client_tls_sec_prot_state_machine () #29 0x00069af8 in tls_sec_prot_receive () #30 0x00068072 in supp_eap_tls_sec_prot_state_machine () #31 0x000627b8 in supp_eap_tls_sec_prot_receive () #32 0x0006d28c in kmp_eapol_pdu_if_receive () #33 0x0007d602 in ws_eapol_pdu_mpx_data_indication () #34 0x00080f2e in ws_llc_mac_indication_cb.lto_priv () #35 0x000a8df6 in mac_mcps_sap_data_tasklet.lto_priv () #36 0x000ae3f8 in event_loop_thread.lto_priv () #37 0x000414c0 in xEventGroupSetBitsFromISR (xEventGroup=<optimized out>, uxBitsToSet=<optimized out>, pxHigherPriorityTaskWoken=<optimized out>) at build/3pp/freertos/FreeRTOS/Source/event_groups.c:724 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) (gdb) I see a crash while my node is trying to authenticate using EAP-TLS to a gateway. I am able to consistently reproduce observe this issue. Is this something that has been already solved or is seen by anybody ? Any inputs on this will help. With regards, Ajay.

2 years, 5 months

2
1
0 0

mbedTLS hardware cryptography support

by Achraf BENLETAIFA

Hi, i wanted to ask if the hardware accelerators and TRNG of the Hardware Security Engine (HSE) of NXP S32K3XX microcontrollers are supported by the mbedTLS Library ? because i can't find it in the "MBEDTLS HARDWARE CRYPTOGRAPHY SUPPORT" list. Best regards, Ben

2 years, 5 months

2
1
0 0

Re: [EXTERNAL] Re: mbedtls_platform_setup/teardown in TF-M ?

by Shebu Varghese Kuriakose

+ Mbed TLS mailing list for visibility… Regards, Shebu From: Rehan Malak via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, July 10, 2023 9:44 AM To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: [EXTERNAL] Re: mbedtls_platform_setup/teardown in TF-M ? Hi Antonio, Thanks a lot for your answer ! Looking at the MbedTLS github link you sent (and the one therein) - https://github.com/Mbed-TLS/mbedtls/issues/6228 PSA: separate driver initialization with a nicer fixed ordering - https://github.com/Mbed-TLS/mbedtls/issues/6007 Define the PSA subsystem initialization interface in Mbed TLS it seems that for the best would be indeed to provide feedback to the MbedTLS/PSA team such that TF-M could just run the adequate psa_* functions. Thanks ! Rehan Intrinsic ID ________________________________ From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>> Sent: Saturday, July 8, 2023 12:13 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Rehan Malak <Rehan.Malak(a)intrinsic-id.com<mailto:Rehan.Malak@intrinsic-id.com>> Subject: [EXTERNAL] Re: mbedtls_platform_setup/teardown in TF-M ? Hi Rehan, This looks like a non-PSA standardized feature specific to mbed TLS. We don't have any platform in TF-M that requires such setup/teardown so I can't comment from experience, but to me it looks like this would be an mbed TLS specific feature that needs to be hooked underneath the service and into the library. The most natural choice would be indeed to have them as part of the psa_crypto_init() and lower functions, but at this stage I think is not possible to implement this without patching the source code (i.e. there are no options to allow this at build time in TF-M, at least). Note also that mbed TLS has a on open ongoing issue to better define the initialisation sequence for the various operations in psa_crypto_init(): PSA: separate driver initialization with a nicer fixed ordering · Issue #6228 · Mbed-TLS/mbedtls (github.com)<https://github.com/Mbed-TLS/mbedtls/issues/6228> It might be a good place to start to provide feedback regarding this particular aspect of custom platform initialisation if is not being considered there. To conclude, if you want to propose a patch for TF-M to allow such functions to be plugged in (in the meantime that mbed TLS agrees on the long term course of action), I will be happy to review it. Thanks, Antonio ________________________________ From: Rehan Malak via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Friday, July 7, 2023 13:15 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] mbedtls_platform_setup/teardown in TF-M ? Dear TF-M developers, I am currently adapting a basic MbedTLS / PSA Crypto example such that it would run on the NS side with TF-M doing the crypto. At the end, this is very similar to this psa_sign_verify_message_test from the NS crypto test suite : https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… But my build config of MbedTLS has MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT enabled because I have a custom mbedtls_platform_setup / mbedtls_platform_teardown. And I can't see any place in TF-M where mbedtls_platform_setup/mbedtls_platform_teardown are called : ? -> mbedtls_platform_setup ? -> mbedtls_platform_teardown At first, I tried to put this code into the psa_driver_wrapper_init/psa_driver_wrapper_free but I have a similar problem : tfm_crypto_engine_init -> psa_crypto_init -> psa_driver_wrapper_init ? -> mbedtls_psa_crypto_free -> psa_driver_wrapper_free Is there any cmake/Kconfig option or any C macros to hook TF-M initialization/shutdown with mbedtls_platform_setup/mbedtls_platform_teardown without patching TF-M ? If not, could mbedtls_platform_setup be called here ? https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/… or is there a nicer way of doing this ? (btw, I am currently experimenting on qemu mps2-an521) Thanks for any advice ! 🙂 Best regards, Rehan MALAK Intrinsic ID

2 years, 5 months

2
1
0 0

Python version requirements

by Gilles Peskine

Hello, This is a question for integrators and packagers of Mbed TLS, especially if you're integrating the library in some embedded OS or BSP. To build, configure and test Mbed TLS, we use Python for several purposes: * To configure the library with scripts/config.py, unless you use the default configuration or write your own configuration from scratch. * To generate some configuration-independent library source files, but only if you use the development branch, not if you use a release or an LTS branch. * To generate some glue code for PSA drivers, if you use PSA drivers and don't write the glue code by hand. * To generate the unit test source files. * (We have many more maintenance and test scripts but they're out of scope here.) (Python is not necessary, and will remain unnecessary, to configure and build the library with a given set of hardware drivers, so that a typical BSP will not have to depend on Python.) For each of these purposes, how problematic is it if we require a recent version of Python? We're currently planning to drop support for older versions of Python as soon as they become unsupported upstream (so officially dropping 3.8 now — although right now all scripts still work on 3.5). This includes versions of Python that are still shipped in e.g. Linux distributions that are themselves officially supported. Is there demand for supporting older Python versions for some scripts? Also, how problematic is it if some of these purposes require third-party Python packages? Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 5 months

1
0
0 0

Reminder: MBed TLS Tech Forum - US/Europe External

by Don Harbin

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

2 years, 5 months

1
1
0 0

Fwd: [Tf-openci-triage] FYI; Cambridge Lab Down

by Don Harbin

FYI to all TF dev teams leveraging Open CI. Best regards, Don ---------- Forwarded message --------- From: Glen Valante via Tf-openci-triage < tf-openci-triage(a)lists.trustedfirmware.org> Date: Fri, 23 Jun 2023 at 08:41 Subject: [Tf-openci-triage] FYI; Cambridge Lab Down To: tf-openci-triage(a)lists.trustedfirmware.org < tf-openci-triage(a)lists.trustedfirmware.org> Hello All; FYI; the Cambridge lab took a serious power hit and is down. They are scrambling to get things back up, but it may take all weekend. Expect LAVA failures and other strange results. Thanks; -g -- [image: Linaro] <http://www.linaro.org> Glen Valante | *Director Program & Project Management* T: +1.508.517.3461 <1617-320-5000> glen.valante(a)linaro.org | Skype: gvalante <callto:gvalante> -- Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-triage-leave(a)lists.trustedfirmware.org

2 years, 5 months

1
0
0 0

Global entropy required for TLS 1.3?

by Jethro Beekman

The MbedTLS generally allows you to pass in an RNG callback for each function that requires it. This is even explicitly called out in the 3.x migration guide: > The RNG parameter is now mandatory for all functions that accept one https://github.com/Mbed-TLS/mbedtls/blob/a7d454cec2/docs/3.0-migration-guid… However, TLS 1.3 support requires MBEDTLS_PSA_CRYPTO_C https://github.com/Mbed-TLS/mbedtls/blob/a7d454cec2/include/mbedtls/check_c… And MBEDTLS_PSA_CRYPTO_C requires MBEDTLS_ENTROPY_C or MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG https://github.com/Mbed-TLS/mbedtls/blob/a7d454cec2/include/mbedtls/check_c… This seems to go against the general rule that MbedTLS doesn't require any global state. Was this done intentionally? -- Jethro Beekman | Fortanix

2 years, 6 months

2
2
0 0

Regarding adding a new encryption algorithm in mbedtls

by Vishal Rathod

Dear sir/madam, Hope you are doing good! We are working on a lightweight TLS implementation for embedded hardware and want to add our own algorithm inside mbedTLS. As per my knowledge, we have to add a .h file in mbedtls/include/mbedtls and .c file in the library. Also, we have to list our algorithm in library/CMakeLists.txt. Except these, what should be the procedure? Also, our task is during handshake, the receiver chooses our algorithm instead of the default one for encryption and decryption. If someone could help us regarding this then it would be great. Thanks in advance. Regards, -- *Dr. Vishal J. Rathod* *(Member - IEEE, ACM, IET)* *Senior Project Engineer (SPE),* *IoT R & D Group,* *C-DAC, Electronic City,* *Bengaluru, Karnataka, India.* *Email ID: rathodvishal78(a)gmail.com <rathodvishal78(a)gmail.com> and * vishalrathod(a)ieee.org *Mobile - 9879957770*

2 years, 6 months

1
0
0 0

Feature idea for mbedtls_net_connect()

by Alexander Timofeev

Hi! I am a new MbedTLS user and would like to say thanks to devs first! From my point of view mbedtls_net_connect() could handle binding socket to a specified local client port. Although it does not seem to be a common requirement and bloats API a little bit but otherwise user has to throw away mbedtls_net_connect() and implement connection function by their hands. Best, Alex

2 years, 7 months

1
0
0 0

Re: [psa-crypto] Benchmark application for PSA crypto API's

by Stephan Koch

Hi Ruchika, as an addition to the previous answers, there is also the SecureMark-TLS benchmark from EEMBC that "Analyzes the costs associated with implementing TLS on an edge device using a common IoT cyphersuite comprised of ECC & ECDSA on the NIST secp256r1 curve, SHA256, and AES128-CCM/ECB", see: https://www.eembc.org/securemark/ It provides profiles to run benchmarks against Mbed TLS API, PSA Crypto API, and wolfSSL, see sources here: https://github.com/eembc/securemark-tls/tree/main/examples/selfhosted/profi… The chosen cipher-suite is similar to the TF-M medium profile and it allows estimates of speed and power consumption for TLS on microcontrollers. It also allows to add - manually - footprint data. Best Stephan From: Ruchika Gupta via psa-crypto <psa-crypto(a)lists.trustedfirmware.org> Reply to: Ruchika Gupta <ruchika.gupta_1(a)nxp.com> Date: Tuesday, 16 May 2023 at 13:40 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>, "psa-crypto(a)lists.trustedfirmware.org" <psa-crypto(a)lists.trustedfirmware.org> Subject: [psa-crypto] Benchmark application for PSA crypto API's Hi, For mbedtls API’s, there is a benchmark application available. Are there any plans to implement benchmark application for PSA crypto APIs ? Regards, Ruchika

2 years, 7 months

2
3
0 0

Benchmark application for PSA crypto API's

by Ruchika Gupta

Hi, For mbedtls API's, there is a benchmark application available. Are there any plans to implement benchmark application for PSA crypto APIs ? Regards, Ruchika

2 years, 7 months

3
4
0 0

PSA key slot management functions access private structure members

by S Krishnan, Archanaa

Hello, In mbedLS v3.4.0, I came across a build error that there are no members for type and flag in psa_core_keyattributes_t structure. The following functions in psa_crypto_core.h access private members type and flag of psa_core_keyattributes_t structure without the MBEDTLS_PRIBATE() private access. * psa_is_key_slot_occupied() * psa_key_slot_get_flags() * psa_key_slot_set_flags() * psa_key_slot_set_bits_in_flags() * psa_key_slot_clear_bits() Updating to private access for attribute struct members in psa_crypto_core.h fixed the build errors. Regards, Archanaa

2 years, 7 months

2
4
0 0

Reminder: MBed TLS Tech Forum - US/Europe

by Don Harbin

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

2 years, 7 months

1
5
0 0

Canceled event with note: MBed TLS Technical Forum @ Mon May 8, 2023 8:30am - 9:30am (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been canceled with a note: "Cancelled due to Bank Holiday" MBed TLS Technical Forum Monday May 8, 2023 ⋅ 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 nnac123(a)gmail.com psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 7 months

1
0
0 0

Minimum size in RSA key generation

by Gilles Peskine

Hello, To strengthen Mbed TLS against accidental misuse, we're going to enforce a minimum size for RSA key generation. Currently the minimum is 128 bits, just to avoid some edge cases in the implementation. So for example, if you want a 2048-bit key but accidentally pass a number of bytes, the library will happily generate a 256-bit key. We want to prevent this scenario. What should the minimum be? If we make the minimum 2048 bits, will this be a problem? We will not make the minimum any higher. But we're considering enforcing only a minimum 1024 bits, which is over the record from public breaks and largely resolves the risk of bits/bytes confusion. Should we also enforce a minimum (perhaps lower) in the 2.28 long-time support branch? If you're using Mbed TLS to generate small RSA keys, please let us know on the mailing list, on GitHub at https://github.com/Mbed-TLS/mbedtls/issues/7556, or by private email. Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 7 months

1
0
0 0

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

by don.harbin＠linaro.org

MBed TLS Technical Forum Every 4 weeks from 9:30am to 10:30am on Monday 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 View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 7 months

1
0
0 0

Troubles with server certificate verification

by François Legal

Hello, using mbed TLS pavkaged with esp32 toolchain, for doing eap-tls with server certificate verification using CA cert. Mbed TLS rejects certificate in mbedtls_x509_crt_check_key_usage (x509_crt.c), because usage_may variable is 0. usage is set by mbedtls_ssl_check_cert_usage (ssl_tls.c) to MBEDTLS_X509_KU_DIGITAL_SIGNATURE because my keys are ECDHE-ECDSA. Is this the expected behaviour ? Thanks in advance François

2 years, 7 months

1
0
0 0

Help with unexpected generic_sum result

by joe＠polka.cat

Hello, I was working on packaging up mbedtls for [tea, a new package manager](https://tea.xyz/) and ran into an error validating the built products. I was hoping maybe someone more knowledgeable could take a quick look. I followed the homebrew formula here: https://github.com/Homebrew/homebrew-core/blob/af8e7e97432944a65c0f985132a7… Here's the PR for adding it to tea: https://github.com/teaxyz/pantry/pull/1822 For some reason I'm not getting the expected checksum from `generic_sum`. Any help would be much appreciated. Thanks! -Joe

2 years, 7 months

2
1
0 0

Support for SHA3 and HMAC with SHA3

by Nilesh.Badodekar＠infineon.com

Hi, Is there a plan to support SHA3 (256 and 384) and subsequent usage in HMAC on mbedtls? - Regards Nilesh Badodekar

2 years, 7 months

2
2
0 0

TLS over UART using MbedTLS Library for STM32U5

by manish.verma＠cyient.com

Hi Team, I want to implement TLS over UART using MbedTLS library, But the issue i am facing right now is There are no example codes or any reference document for briefing how to import the libraries and what changes should be done to do so. I tried to use some examples for Lwip examples but i am getting errors while importing library like platform error, timing_alt.h error. Please help me out in urgent. Thanks !!

2 years, 7 months

2
2
0 0

Memory leak in mbedtls_ssl_handshake

by Malcolm Bugler

I have created an http server following the example for server1 under FreeRTOS and Lwip running on a STM32H753 using the Stm32CubeIDE. Everything seem to work correctly, however, I am experiencing a small memory leak over each successive TLS connection of 160 bytes. It is obvious that I must not be freeing a context, but as I am following the example very closely, except for running the code in a FreeRTOS thread, I must be missing something fundemental. Has anyone on this list experienced a similar issue or have any ideas on how to debug it?

2 years, 7 months

2
1
0 0

Reminder: MBed TLS Tech Forum - Asia/Europe

by Don Harbin

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

2 years, 7 months

1
0
0 0

best way to shut down network connection

by Gary Metalle

Hi What's the best way to shutdown a network connection for when say an embedded device is shutting down or going to reboot? I have the following code I call when I am going to kick off a reboot: LOG_DEBUG("Network Manager: Ethernet is going down%s", networkManager->rebootInProgress ? "..." : " for reconfiguration..."); netifapi_dhcp_release_and_stop(&networkManager->networkInterfaceContext); netifapi_netif_set_link_down(&networkManager->networkInterfaceContext); netifapi_netif_set_down(&networkManager->networkInterfaceContext); networkManager->ethernetLinkUp = false; if (networkManager->rebootInProgress) { netifapi_netif_remove(&networkManager->networkInterfaceContext); } The trouble is that the link seems to come back up again as soon as it goes down and my state machine starts doing stuff like kicking off a new DHCP request etc, right about the time the hardware reboots. I added in the call to netifapi_netif_remove() quite recently but it doesn't seem to make any difference. I could put some more code in my link status state machine for an impending reboot, but this seems more complicated than it probably needs to be, as I'm probably not doing something I should be. Gary Metalle Senior Embedded Software Engineer

2 years, 7 months

1
0
0 0

PSA API support

by S Krishnan, Archanaa

Hello, What is the extent of PSA Crypto API 1.1 support available in mbedTLS today? From the road map, API v1.0 is supported. I also see that PBKDF, which is in PSA API v1.1, is in development. Regards, Archanaa

2 years, 7 months

1
0
0 0

Is there a DTLS 1.3 roadmap?

by Achim Kraus

Hi List, last year I read in a comment https://github.com/Mbed-TLS/mbedtls/issues/5443#issuecomment-1017379238 that DTLS 1.3 is on the roadmap for the near future. Is it available? Are there any schedules? The Eclipse/wakaama project is looking for DTLS 1.3 (see https://github.com/eclipse/wakaama/issues/684), therefore I'm asking best regards Achim

2 years, 8 months

3
2
0 0

Canceled event with note: MBed TLS Technical Forum @ Mon Apr 10, 2023 8:30am - 9:30am (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been canceled with a note: "Bank Holiday - Cancelling " MBed TLS Technical Forum Monday Apr 10, 2023 ⋅ 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 nnac123(a)gmail.com psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 8 months

1
0
0 0

[Mbed-tls-announce] New Mbed TLS releases : 3.4.0 and 2.28.3

by Paul Elliott via Mbed-tls-announce

Hi Mbed TLS users, We have released Mbed TLS versions 3.4.0 and 2.28.3 These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes. (https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-3.4.0, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.28.3). We recommend all users to consider whether they are impacted, and to upgrade appropriately. The Mbed TLS team IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

2 years, 8 months

2
1
0 0

support of EC and hashing algorithms

by c.luetzenkirchen＠innolectric.ag

hello, I am currently evaluating if latest mbed-TLS release does support following algorithms: - ECDSA using secp521r1 curve - EDDSA using Edwards curves 448 or 448-Goldilocks - ECDH using mentioned curves - SHA512 - SHAKE256 For some of them like SHA512 I found information in the documentation. Others like EDDSA and SHAKE256 seem to be incomplete. Is my assumption correct that TLS 1.3 is therefore NOT ready to use yet? Best regards, Chris

2 years, 8 months

1
0
0 0

Question about long-time support for 3.x branch

by Maher Azarkan

Hello everyone, We are currently using the mbedTLS version 2.16.12 in our firmware and we are planning an update to a newer branch. I would like to know, how long the different 3.x branches will be supported. Is there any fix roadmap, how long an mbedTLS branch must be supported and maintained after its first release? I could only find this information for the 2.28 branch (support until end of 2024). Thank you for any help you can offer. Best regards Maher Azarkan Hilscher Gesellschaft f?r Systemautomation mbH Rheinstra?e 15 / D-65795 Hattersheim / Germany Sitz der Gesellschaft / place of business: Hattersheim | Gesch?ftsf?hrer / managing director: Sebastian Hilscher, Hans-J?rgen Hilscher Handelsregister / commercial register: Frankfurt B 26873 | Ust. Idnr. / VAT No.: DE113852715 Registergericht / register court: Amtsgericht Frankfurt/Main Important Information: This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails. Wichtiger Hinweis: Diese E-Mail einschlie?lich ihrer Anh?nge enth?lt vertrauliche und rechtlich gesch?tzte Informationen, die nur f?r den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und l?schen Sie diese Nachricht und ihre Anh?nge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Ver?nderung der E-Mail ist untersagt. Der Absender haftet nicht f?r Inhalte von ver?nderten E-Mails.

2 years, 8 months

3
2
0 0

Porting from OpenSSL to MbedTLS

by matteo.cogi＠alice.it

Dear all, I need to migrate from OpenSSL to MbedTLS. I have to implement a SCEP client in my embedded environment composed by FreeRTOS as OS, mbedTLS as security layer and LwIP as network stack. The best candidate for the SCEP client role is the sscep library. It works very well under Ubuntu, but now I need to use it in my embedded environment, so I have to adapt sscep for MbedTLS. I would like to know if there is some porting/migration guide from OpenSSL to MbedTLS. Any kind of suggestion or support will be appreciated. Thanks in advance. Regards, Matteo

2 years, 8 months

3
2
0 0

Reminder: MBed TLS Tech Forum - Asia/Europe

by Don Harbin

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

2 years, 8 months

1
0
0 0

security issue in mbedtls 3.30

by Avi Epstein

security issue in mbedtls 3.30 in the release notes: "An adversary with access to precise enough information about memory accesses (typically, an untrusted operating system attacking a secure enclave) could recover an RSA private key after observing the victim performing a single private-key operation if the window size used for the exponentiation was 3 or smaller. Found and reported by Zili KOU, Wenjian HE, Sharad Sinha, and Wei ZHANG. See "Cache Side-channel Attacks and Defenses of the Sliding Window Algorithm in TEEs" - Design, Automation and Test in Europe 2023." was this issue solved in this version?

2 years, 9 months

2
1
0 0

ECDSA read_signature returns "invalid signature" status

by Tilen Majerle

Hello, I have 3rd party custom ECC library, that can do ECDSA verification and uses secp256r1 compressed public key (33bytes) to do so - all works fine. Now I want to migrate to mbedTLS, to also benefit of other crypto schemes, hence use of mbedtls ECDSA was a natural way to go. Here I need (as I understand) PEM parser or optionally public key in uncompressed format (0x04 | X | Y). Problem is that loading of the key seems to work (func returns 0), but verification fails with -20450, indicating (if I well understood) invalid signature. Test data. PRIVATE KEY: -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgKNqyWso/lMuTlTE6 ll47Jboqq/Iz7OYDrr7TuXN+s2ChRANCAARNgfaUcxLoWWG01ekJFiqB8ujMgnHz P320ZgiZErH6zKjlB9EovIHrchj0240+EIpFios+2uM609FgRvu3+NrT -----END PRIVATE KEY----- PUBLIC KEY: -----BEGIN PUBLIC KEY----- MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADTYH2lHMS6FlhtNXpCRYqgfLozIJx 8z99tGYImRKx+sw= -----END PUBLIC KEY----- PUBLIC KEY UNCOMPRESSED SEC1: 0x4,0x4d,0x81,0xf6,0x94,0x73,0x12,0xe8,0x59,0x61,0xb4,0xd5,0xe9,0x9,0x16,0x2a,0x81,0xf2,0xe8,0xcc,0x82,0x71,0xf3,0x3f,0x7d,0xb4,0x66,0x8,0x99,0x12,0xb1,0xfa,0xcc,0xa8,0xe5,0x7,0xd1,0x28,0xbc,0x81,0xeb,0x72,0x18,0xf4,0xdb,0x8d,0x3e,0x10,0x8a,0x45,0x8a,0x8b,0x3e,0xda,0xe3,0x3a,0xd3,0xd1,0x60,0x46,0xfb,0xb7,0xf8,0xda,0xd3 PUBLIC KEY COMPRESSED SEC1: 0x3,0x4d,0x81,0xf6,0x94,0x73,0x12,0xe8,0x59,0x61,0xb4,0xd5,0xe9,0x9,0x16,0x2a,0x81,0xf2,0xe8,0xcc,0x82,0x71,0xf3,0x3f,0x7d,0xb4,0x66,0x8,0x99,0x12,0xb1,0xfa,0xcc INPUT STRING in TEXT format: "This is my input data" (remove quotes) INPUT STRING in HEX format: 0x54,0x68,0x69,0x73,0x20,0x69,0x73,0x20,0x6d,0x79,0x20,0x69,0x6e,0x70,0x75,0x74,0x20,0x64,0x61,0x74,0x61 SHA256 of INPUT STRING: 0xa7,0x3f,0x26,0xf4,0xa1,0xe4,0x61,0x61,0x0,0x1a,0x29,0xdf,0xd2,0xaf,0x7d,0xa,0x25,0x91,0xbb,0xcc,0x1f,0xbc,0xfb,0xdb,0x43,0xdb,0x57,0xf9,0x8d,0x94,0xeb,0x81 (x-checked here: https://emn178.github.io/online-tools/sha256.html) SIGNATURE of HASH signed with PRIVATE KEY: 0x80,0xe6,0xf5,0x97,0x6a,0x66,0xa2,0xe2,0x9a,0xd7,0x7f,0x9a,0x9b,0x3e,0x2b,0xde,0x1f,0x7c,0x3,0xb3,0x1,0xb8,0x6f,0xd8,0xf6,0xf,0x27,0x38,0x63,0x3,0x54,0x74,0x76,0x6d,0x1b,0x97,0xf0,0xbc,0xc5,0xd2,0x4b,0xae,0xf0,0x34,0xab,0x86,0xbd,0x55,0x0,0x8a,0x4c,0x9f,0x4e,0xa5,0x53,0x89,0xe8,0x0,0xb9,0x83,0x24,0x87,0x98,0x1 My custom library code looks like - this one works as expected: if (ecdsa_verify(public_key_compressed_33_bytes_array, hash_of_input_string, signature_signed_with_private_key)) { printf("Custom ECDSA lib verification is OK\r\n"); } My mbedTLS code looks like: ``` /* mbedTLS */ printf("mbedTLS way start\r\n"); mbedtls_ecdsa_init(&ctx); mbedtls_ecp_group_load(&ctx.private_grp, MBEDTLS_ECP_DP_SECP256R1); res = mbedtls_ecp_point_read_binary(&ctx.private_grp, &ctx.private_Q, ecc_public_key_uncompressed_bin, sizeof(ecc_public_key_uncompressed_bin)); if (res != 0) { printf("ECP point read binary failed: %d\r\n", res); } res = mbedtls_ecdsa_read_signature(&ctx, data_raw_hash_digest, sizeof(data_raw_hash_digest), signature, sizeof(signature)); if (res == 0) { printf("mbedTLS Verification is OK...\r\n"); } else { printf("mbedTLS Verification failed...: %d\r\n", res); } printf("mbedTLS way end\r\n"); ``` and it always fails with error code -20450. while loading keys function goes through well. Am I wrongly loading the keys?

2 years, 9 months

2
2
0 0

PKCS#7 signedAttributes and embedded cert chain

by Joakim Sindholt

Hi, I recently had to do some PKCS#7 signature validation and was disappointed to find that it didn't just work. After digging through RFCs to figure out the myriad of things I'd done wrong I was also left with a lack of 3 features in mbedtls: 1. The full certificate chain was not being loaded and explicitly not supported. I believe this is in error since the certificate was never actually used anywhere, meaning it basically errored out for no reason. Since this certificate chain also contains the key used to validate the signature in my case that presented a pretty fundamental problem. 2. signedAttributes were not supported at all. 3. All the fields in mbedtls_pkcs7 and its associated structures are marked as MBEDTLS_PRIVATE. I need to inspect both the certificates and the signedAttributes and would rather not have to parse the entire DER myself. I have attached patches implementing the first two. I believe I've done so without altering the behavior of the calls although I'm a bit unsure as to why mbedtls_x509_crt_verify doesn't take a const mbedtls_x509_crt. The third issue is a matter of policy and I don't know what your opinion on it is. For the moment I can at least get away with poking at the internal fields. I have tested it on several signatures, one of which I have included here and I apologize in advance for the absolute spew but I thought it better than attaching even more files. The data: 3059301306072A8648CE3D020106082A8648CE3D030107034200041B58AEE5B7C868AE0EED554133774B7C16802062EC2EB5A1A053318A9ED7DB943CE1F877671DADCFEB4D3171ACC2714ECBC0C0BCADE0569DF7CD0031623AF1BBDE72D8FFF60EC6D04B0D6C93658FC40F4AF2E22E1F68BF1A500FE00A94B804B7CA1DD7AF825C000FCF77A0ABB6918D2DF55C7A3CBC90BE14C59D8EE62A02B988DF7F32117770012AE362C03FB3AA3918AB9D10BE78442EFA7FCBA3CB02D6E196CE4137C6C3F280D963A5CD050EAC8871B3EB2C4500916FB3E39840D8EB198D58F49A434B2736385075BF9397405360B8694D0AD1E5DA8291F9EA47743F803F4A409EA72C2DF94F43DB60A0EAB8A8BD409C4D684200778B23D2A8126827995C3A80CAACA4AB7077266CED79BF91725330C9FCE3B8F1F5316C08C17B9994CF0ECB26D87A5C1F8FEB1FA737F78794895F6C5153B575EF8E95A8D433FD9486AA6C2B46ED6633D2BE0938202B99BEC21895018FB6FC59BAD662815A2C65200B8B1BAA4B69A8C89204B1EA70094026E9F710E599E14941476C8CD2E2879CF58E850DC732A506885F646BB9BE96B7A65355A6A9B907956E6DF65336504300CF062BA9DE50 It's SHA2-256 hash is: C76DE7AF191C16E01405CE8FE89136EB60AC035B3DDE34ACF65220AC7C3CA619 If you decode the signature DER you'll see a matching id-messageDigest in the signedAttributes towards the very bottom. The signature in DER format: 3082089B06092A864886F70D010702A082088C30820888020101310D300B0609608648016503040201300B06092A864886F70D010701A08206D9308203E330820388A00302010202084C304149519D5436300A06082A8648CE3D040302307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B3009060355040613025553301E170D3139303531383031333235375A170D3234303531363031333235375A305F3125302306035504030C1C6563632D736D702D62726F6B65722D7369676E5F5543342D50524F4431143012060355040B0C0B694F532053797374656D7331133011060355040A0C0A4170706C6520496E632E310B30090603550406130255533059301306072A8648CE3D020106082A8648CE3D03010703420004C21577EDEBD6C7B2218F68DD7090A1218DC7B0BD6F2C283D846095D94AF4A5411B83420ED811F3407E83331F1C54C3F7EB3220D6BAD5D4EFF49289893E7C0F13A38202113082020D300C0603551D130101FF04023000301F0603551D2304183016801423F249C44F93E4EF27E6C4F6286C3FA2BBFD2E4B304506082B0601 050507010104393037303506082B060105050730018629687474703A2F2F6F6373702E6170706C652E636F6D2F6F63737030342D6170706C65616963613330323082011D0603551D2004820114308201103082010C06092A864886F7636405013081FE3081C306082B060105050702023081B60C81B352656C69616E6365206F6E207468697320636572746966696361746520627920616E7920706172747920617373756D657320616363657074616E6365206F6620746865207468656E206170706C696361626C65207374616E64617264207465726D7320616E6420636F6E646974696F6E73206F66207573652C20636572746966696361746520706F6C69637920616E642063657274696669636174696F6E2070726163746963652073746174656D656E74732E303606082B06010505070201162A687474703A2F2F7777772E6170706C652E636F6D2F6365727469666963617465617574686F726974792F30340603551D1F042D302B3029A027A0258623687474703A2F2F63726C2E6170706C652E636F6D2F6170706C6561696361332E63726C301D0603551D0E041604149457DB6FD57481868989762F7E578507E79B5824300E0603551D0F0101FF040403020780300F06092A864886F76364061D04020500300A06082A8648CE3D0403020349003046022100BE09571FE71E1E7 35B55E5AFACB4C72FEB445F30185222C7251002B61EBD6F55022100D18B350A5DD6DD6EB1746035B11EB2CE87CFA3E6AF6CBD8380890DC82CDDAA63308202EE30820275A0030201020208496D2FBF3A98DA97300A06082A8648CE3D0403023067311B301906035504030C124170706C6520526F6F74204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B3009060355040613025553301E170D3134303530363233343633305A170D3239303530363233343633305A307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B30090603550406130255533059301306072A8648CE3D020106082A8648CE3D03010703420004F017118419D76485D51A5E25810776E880A2EFDE7BAE4DE08DFC4B93E13356D5665B35AE22D097760D224E7BBA08FD7617CE88CB76BB6670BEC8E82984FF5445A381F73081F4304606082B06010505070101043A3038303606082B06010505073001862A687474703A2F2F6F6373702E6170706C 652E636F6D2F6F63737030342D6170706C65726F6F7463616733301D0603551D0E0416041423F249C44F93E4EF27E6C4F6286C3FA2BBFD2E4B300F0603551D130101FF040530030101FF301F0603551D23041830168014BBB0DEA15833889AA48A99DEBEBDEBAFDACB24AB30370603551D1F0430302E302CA02AA0288626687474703A2F2F63726C2E6170706C652E636F6D2F6170706C65726F6F74636167332E63726C300E0603551D0F0101FF0404030201063010060A2A864886F7636406020E04020500300A06082A8648CE3D040302036700306402303ACF7283511699B186FB35C356CA62BFF417EDD90F754DA28EBEF19C815E42B789F898F79B599F98D5410D8F9DE9C2FE0230322DD54421B0A305776C5DF3383B9067FD177C2C216D964FC6726982126F54F87A7D1B99CB9B0989216106990F09921D3182018830820184020101308186307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B300906035504061302555302084C304149519D5436300B0609608648016503040201A08193301806092A864886F70D010903310B06092A864 886F70D010701301C06092A864886F70D010905310F170D3233303230393231333032345A302806092A864886F70D010934311B3019300B0609608648016503040201A10A06082A8648CE3D040302302F06092A864886F70D01090431220420C76DE7AF191C16E01405CE8FE89136EB60AC035B3DDE34ACF65220AC7C3CA619300A06082A8648CE3D04030204473045022100EE9B221CD9B5EEB1C6AF4160128D099C9414440A96C855A789846599E3BDE442022005AE51DC947E0B2AA6593E8FDB9F888782C71E5BB1CB6BF3C32B79C448C6A75D Joakim

2 years, 9 months

3
5
0 0

Reminder: MBed TLS Tech Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Feb 27th at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. As usual, if anyone has any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 9 months

1
0
0 0

Could anyone please handle these PR?

by Elsa zz

Hi, I'm new here. I found some issues and submitted the pull requests. Could anyone please handle these PR? - https://github.com/Mbed-TLS/mbedtls/pull/6511 - https://github.com/Mbed-TLS/mbedtls/pull/6224 Thanks!

2 years, 10 months

2
1
0 0

Where is the AES 128 GCM key expansion/generate round key performed?

by Mbed TLS

Hi, I'm using AES 128 GCM with TLS 1.2 and trying to understand the AES key expansion code for decrypting received SSL records. I'm not an expert on AES but as I understand it, we use the IV (4 byte salt + 8 byte explicit nonce in the received message), pad to 16 bytes, increment and use this as input to the AES key expansion for the first block of ciphertext. This produces a round key per AES round (10 rounds for AES 128). We then increment our IV as input to the key expansion and generate the rounding keys for the next block. I noticed aesni_setkey_enc_128 in aesni.c contains the Intel AES-NI instruction AESKEYGENASSIST which helps with key expansion. However, what's confusing me is when I add a breakpoint in GDB, this function is only called once, via mbedtls_ctr_drbg_seed in ctr_drbg.c. I thought we need to do the key expansion on every block, to generate the round keys? I kept looking at the code and I noticed mbedtls_aesni_crypt_ecb, which contains the Intel AES-NI instructions for performing decryption. This loads the round key via ctx->buf + ctx->rk_offset but I do not see any code updating this round key per block. Could someone please explain where the round keys are generated for each round, per block? Thanks,

2 years, 10 months

4
6
0 0

Should TLS be blocking all FreeRTOS tasks which use LWIP, during its RSA/EC phase, regardless of priorities?

by Peter

Hi All, I have a couple of tasks which use LWIP and which get suspended for a few seconds during TLS RSA/EC crypto. One (a primitive http server) uses Netconn and the other (a serial to TCP data copy process) uses sockets. I also have a number of tasks which don't do any networking and which run as they should, throughout. Experimentation of what priority these need is difficult but it looks like it needs to be at/above the tasks which invoke TLS. If their priority is 0 then TLS hangs them up as well. After much experimentation with RTOS priorities, this is what I found, and I wonder if it is right: TCP/IP applications (whether using the LWIP Netconn API or the LWIP socket API) should run at a priority equal to or lower than that of LWIP itself which [in this project] is osPriorityHigh (40). TCP/IP applications can be run with a priority all the way down to tskIDLE_PRIORITY (0). The exception is if TLS is in use. TLS does not yield to the RTOS; you get a solid CPU time lump of ~3 secs (STM 32F417, hardware AES only). TLS starts in the priority of the task which invokes it, but subsequent TLS-driven TCP/IP operations run at the priority of LWIP. So when TLS is doing the session setup crypto, tasks of a priority lower than LWIP get suspended. If this gap is an issue, the priority of the relevant tasks should be equal to LWIP's. Furthermore, due to the structure of LWIP, the priority of a task using it should not be higher than LWIP (24) since it might cause blocking on socket (or netconn) writes. Does this make sense? It looks like LWIP blocks all netconn and socket ops when TLS is using it. Is that possible? I am running with #define LWIP_TCPIP_CORE_LOCKING 0 #define LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT 1 #define SYS_LIGHTWEIGHT_PROT 1 as this was found to have much better granularity for task switching. With LWIP_TCPIP_CORE_LOCKING=1 you end up with a crude mutex across the entire API call, which is fine in a single RTOS task. Thank you in advance for any pointers. Peter

2 years, 10 months

2
2
0 0

Generating self signed certificate

by Prithvi Pai

Hi Team, I have a requirement to generate self signed certificate programmatically. I have raw EDCSA key pairs generated via OP-TEE APIs. I m trying to generate self signed certificate. I tried the example as shown in programs/x509/cert_write.c. This doesn't work for me as I have raw key pairs where as this expects the key pairs to be in either pem/der format. I tried the following code but it throws error "0xffffdd00" when I call mbedtls_x509write_crt_der Code to set the raw key pairs: mbedtls_ecdh_context issuer_ctx; mbedtls_ecdh_init(&issuer_ctx); ret = mbedtls_ecdh_setup(&issuer_ctx, MBEDTLS_ECP_DP_SECP384R1); if (ret != 0) { goto exit; } res = TA_ECSetPublicKey(&issuer_ctx, public_keyX, public_key_Y, 48); if (res != TEE_SUCCESS) { goto exit; } res = TA_ECSetPrivateKey(&issuer_ctx, private_key, 48); if (res != TEE_SUCCESS) { goto exit; } Am I doing something wrong ? Please help It would be very helpful if some working example of generating certificate programmatically is shared for my reference Thanks, Prithvi

2 years, 10 months

1
1
0 0

Can the same mbedtls_ssl_context be used simultaneously for send and receive from different tasks?

by pascal.haefliger＠schweizer-electronic.com

Hello, In our project we use mbedTLS together with freeRTOS. mbedTLS requires an mbedtls_ssl_context (let's say `ssl_context`) for the send (`mbedtls_ssl_write(...)`) and receive (`mbedtls_ssl_read(...)`) functions. In our project we have a freeRTOS task `A` to send data with mbedTLS and a freeRTOS task `B`to receive data with mbedTLS over the same session/interface. Both tasks use the same `ssl_context` instance. Potentially sending and receiving can happen at the same time. Is it safe to use the same `ssl_context` instance from both taks? Or should only one task access the `ssl_context`? At the moment we are using `mbedtls_ssl_read(...)` in blocking mode and hence the `ssl_context` cannot be protected against multiple access with a mutex because then the sending task cannot obtain the mutex as long as the receiving task is the blocked receiving state (holding the mutext). Thank you for your help. Best regards, Pascal

2 years, 10 months

1
0
0 0