- mbed-tls - lists.trustedfirmware.org

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

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

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

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

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

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

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

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

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

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

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

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

1
0
0 0

Intent to remove DES in Mbed TLS 4.0

by Gilles Peskine

Hello, We intend to remove DES (including Triple-DES) in the next major version of Mbed TLS, i.e. Mbed TLS 4.0. We do not yet have a release date, but at the moment it seems likely that there will be a new major version in 2024. As usual, the Mbed TLS 3.x series will keep the current support for DES, and we intend to maintain the last 3.x minor release as a long-term support branch for 3 years. Rationale: Most security standards deprecate DES if they do not forbid it already. Tooling is widely available to switch to AES or other cipher. In particular, NIST will forbid Triple-DES except to decrypt legacy data after 31 December 2023 (following SP 800-131A <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf>). We would like to remove the last 64-bit block cipher from Mbed TLS to simplify some parts of the code and reduce the maintenance burden. If you wish for Mbed TLS to keep supporting DES longer, please let us know what your business case is, either by replying to this email or on the GitHub issue: https://github.com/Mbed-TLS/mbedtls/issues/7024 Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 2 months

2
1
0 0

Builtin keys and Opaque driver wrappers.

by Rehan Malak

Dear MbedTLS dev, I am writing an opaque driver (equivalent of PSA_CRYPTO_TEST_DRIVER_LOCATION/PSA_KEY_PERSISTENCE_READ_ONLY in the test suite) with the PSA API compiled with MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS. But I am not sure if I have to use "psa_import_key" before "psa_driver_wrapper_sign_message" or if I have to "read/generate" the builtin key on the fly, at each psa_driver_wrapper_* operation ? Would it be possible to add this example in the test suite ? Or explain how builtin key + opaque driver is supposed to be used with, for example, "psa_driver_wrapper_sign_message" ? I put more details below. Thank you in advance, Best regards, Rehan ############################################################################# I would like to write an example doing : I) psa_sign_message (ECDSA SECP256R1 SHA-256) II) psa_export_public_key III) psa_verify_message (with the public key from II) I am following the examples provided by the test suite, especially : 1) sign_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256 using the API : - psa_import_key - psa_sign_message with the attributes : - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) 2) PSA opaque driver builtin pubkey export: secp256r1 using the API : - psa_export_public_key with the attributes : - key_id = MBEDTLS_PSA_KEY_ID_BUILTIN_MIN + 1 - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) and the driver code : - platform_builtin_keys.c : mbedtls_psa_platform_get_builtin_key() (PSA_KEY_PERSISTENCE_READ_ONLY, PSA_CRYPTO_TEST_DRIVER_LOCATION) - test_driver_key_management.c : mbedtls_test_opaque_export_public_key() 3) verify_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256 using the API : - psa_import_key - psa_verify_message with the attributes : - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) It seems to me that II)=2) and 3) should be pretty similar to III) because I assume that neither transparent vs opaque, nor PSA_KEY_TYPE_ECC_KEY_PAIR vs PSA_KEY_TYPE_ECC_PUBLIC_KEY_BASE, is gonna change much here. But the signature I) is less clear... Has the built-in key feature been thought such that the read-only key is read each time we call a different PSA API function ? Long story short, an "opaque driver + builtin keys" equivalent of the "sign_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256" example in the test-suite would be really helpful :)

2 years, 3 months

2
1
0 0

PSA crypto support for RH850 Microcontroller

by Tambe, Ujjwal (TCS)

Hello, Is it possible to use PSA crypto APIs for SHA256 and RSA signature verification for RH850F1KMS1 microcontroller from renesas which has G3KH cpu core. Let me know your thoughts. Thank you in advance. Regards, Ujjwal

2 years, 3 months

1
0
0 0

Mbed TLS support for Renesas RH850 microcontroller

by Tambe, Ujjwal (TCS)

Hello, I am writing this mail in order to get support. I am using RH850-F1KMS1 microcontroller from Renesas, and I need to integrate mbed to perform SHA256 and RSA-1024 digital signature verification. The controller is bare metal and does not have any OS like freeRTOS. Just want to understand how to integrate mbed code in our project. Thank you in advance for the help. Regards, Ujjwal

2 years, 3 months

1
0
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is 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. :) Dave, Please keep in mind that next Monday is a Federal Holiday in the US, so this may impact attendance. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 3 months

1
0
0 0

[Mbed-tls-announce] Coding style change in Mbed TLS

by Gilles Peskine via Mbed-tls-announce

Hello, You are concerned if: you contribute to Mbed TLS, or you maintain local patches to Mbed TLS. You are not concerned if: you just use Mbed TLS. We are going to change the C coding style in Mbed TLS. The new style is mostly what you'd find in The C Programming Language, 2nd edition, by Brian Kernighan and Dennis Ritchie (K&R2). The main changes compared to the current style are: * Spaces outside parentheses, not inside. No space in f(x). * Opening braces on the same line as if(), for(), etc., but on a separate line for functions. Indentation remains 4 spaces. The recommended maximum line length remains 80 columns. There are a few deviations from K&R2, documentation will be available shortly. The new code style will be enforced by the CI testing. This means that style that's rejected by the tool will not be merged, full stop. This also means that sometimes we'll have code that looks a bit less good to humans because the tool insists on it. We're doing this to avoid wasting reviewers' and contributors' time with style violations in code review. The tool we're using is uncrustify<https://github.com/uncrustify/uncrustify>. You can see how your code will look like by installing uncrustify 0.75.1 and running scripts/code_style.py from mbedtls-3.3.0 or mbedtls-2.28.2. There are previews of the rewritten branches at https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/development and https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/mbedtls-2.… (updated every few days until the real branches are rewritten). If you're now starting work on a new feature or bugfix, it will probably be easier to start from those branches, and do an easy rebase once they become official. If you've been working on a branch, we will provide a script to rebase the branch and rewrite it to the new style commit by commit. You'll need to have uncrustify 0.75.1. Concretely, when we change the code style: * If you've started to work on a branch but review has not started yet, we'll ask you to adapt your branch to the new code style. * If your work is under review, you'll need to adapt your branch to the new code style before it can be merged. Rebasing a branch is disruptive for reviews, so please synchronize with the reviewers to decide on a good time. We plan to do the switch during the first week of January 2023. Best regards, -- Gilles Peskine Mbed TLS developer 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, 3 months

2
2
0 0

[Mbed-TLS/mbedtls] MS-MPPE-RECV key is not getting correct value in MBEDTLS

by Ajay Mishra

Hi All, I raised the issue below in the MBED-TLS github, as per suggestion from the moderator asking it in the mailing-list. Below are the details. https://github.com/Mbed-TLS/mbedtls/issues/6864 I am running Mbed TLS as a core security library(2.24.0), on an embedded platform. I am using the FreeRADIUS server for AAA authentication. I am able to get the PMK values correctly at the supplicant side, however while decrypting the MPPE key at the gateway side I see that the values are incorrect specially in the API(radius_client_sec_prot_ms_mppe_recv_key_pmk_decrypt) Below are my setup details: FreeRADIUS server setup on Ubuntu(3.2.1) openssl :1.1.1f Ubuntu version : 20.04.04LTS System information Client side setup Platform : Micro controller based platform OS : FreeRTOS Compiler gcc-arm-none-eabi-8-2019-q3-update Sample example MPPE KEY in clear at RADIUS Server Fri Dec 30 23:50:13 2022 : Debug: (209) MS-MPPE-Recv-Key = 0x2f6c3e7e748eb49a598c208af3ef520454f5aa6873bc72f7f32be1053914a566 Fri Dec 30 23:50:13 2022 : Debug: (209) MS-MPPE-Send-Key = 0xa04539819a272e94782af1818b05878bb0e420d08a51accd6c3cb75baaecbd75 PMK Key values at Supplicant(which is same as MPPE-RECV-KEY) PMK Key values at Supplicant(which is same as MPPE-RECV-KEY) 2022-12-30 23:50:07.313 #1 0000000000000000 <log> 0:28:21.215 [debug] [ tlsp] {Wi-SUN Ev}: >>>> PRINT THE KEY PMK >>>> 2022-12-30 23:50:07.313 #1 0000000000000000 <log> 0:28:21.224 [debug] [ tlsp] {Wi-SUN Ev}: EAP-TLS key material 2f:6c:3e:7e:74:8e:b4:9a:59:8c:20:8a:f3:ef:52:04:54:f5:aa:68:73:bc:72:f7:f3:2b:e1:05:39:14:a5:66 which is same as the value that we see at the RADIUS Server. Decrypted key Value at Authenticator(using the API radius_client_sec_prot_ms_mppe_recv_key_pmk_decrypt) 2022-12-30 23:51:34.763 #1 0000000000000000 <log> 3:09:17.919 [debug] [ hmac] {Wi-SUN Ev}: hmac_md key a9:69:02:e9:3a:1d:cd:05:31:b3:77:cd:d6:d7:c2:c7:2d:52:4b:0a:5b:b1:aa:81:20:67:dd:b8:1c:04:ef:63 Mbed TLS version (number or commit id): 2.24.0 Operating system and version: Configuration (if not default, please attach mbedtls_config.h): Compiler and options (if you used a pre-built binary, please indicate how you obtained it): Additional environment information: Expected behavior The key should be decrypted with the correct value. Actual behavior The key is not getting the correct value. Steps to reproduce Additional information Kindly let me know what is missing here ? Thanks in advance. With regards, Ajay. Brentwood, UK.

2 years, 3 months

1
1
0 0

2025

2024

2023

2022

2021

2020