December 2021 - mbed-tls - lists.trustedfirmware.org

request to unsubscribe from this mailing list

by Innocenti, Michele

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

3 years

3
2
0 0

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

by Fabrice Fontaine

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

3 years

2
1
0 0

Mbed TLS releases: 2.16.12, 2.28.0, 3.1.0

by Dave Rodgman

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

3 years, 1 month

1
0
0 0

Commercial Support Request

by Felix Knorr

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

3 years, 1 month

2
1
0 0

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

by Alugoju, Shailaja

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

3 years, 1 month

1
0
0 0

Mbed TLS Tech Forum

by Dave Rodgman

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

3 years, 1 month

3
4
0 0

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

by Martin Man

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

3 years, 1 month

2
2
0 0

Benchmark on esp32

by Marco Portoni

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

3 years, 1 month

1
0
0 0

lists.trustedfirmware.org

by Philip Colmer

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

3 years, 1 month

1
0
0 0

Output a mbedtls_x509_crt?

by Felipe Gasper

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

3 years, 1 month

2
3
0 0

2025

2024

2023

2022

2021

2020

mbed-tls December 2021