- mbed-tls - lists.trustedfirmware.org

psa_raw_key_agreement does not like PSA_ALG_ECDSA(PSA_ALG_SHA_256)

by Christian Huitema

I am not sure I completely understand the PSA API for key exchange. I have been creating a private key, exporting the public key, passing that successfully to the peer, obtaining the peer's public key, and I want to use psa_raw_key_agreement to obtain the shared secret. But it fails in: if (!PSA_ALG_IS_KEY_AGREEMENT(alg)) { status = PSA_ERROR_INVALID_ARGUMENT; goto exit; } The value of "alg" is 0x06000609, computed as PSA_ALG_ECDSA(PSA_ALG_SHA_256). That's probably wrong, but I do not know why... -- Christian Huitema

2 weeks, 1 day

1
1
0 0

Output format of mbedtls_ecdh_make_params does not play well with TLS 1.3

by Christian Huitema

In TLS 1.3, one half of an ECDH exchange is defined as a "key entry", coded as: struct { NamedGroup group; opaque key_exchange<1..2^16-1>; } KeyShareEntry; The opaque data is typically encoded as a one byte format (e.g., 0x04, no compression), and then the encoding of either one or two points: 32 bytes for one point with CURVE25519, 64 bytes for two points with SECP256R1. The encoding for the "public key" output of mbedtls_ecdh_make_params is different: 1 byte of length, followed by 2 bytes of curve ID, followed by the raw encoding of the point or points. The related encoding of the server public key output of mbedtls_ecdh_make_public is also different: 1 byte of length, followed by 2 bytes of curve ID, followed by the raw encoding of the point or points. To make that work, I need some reformatting: strip out 3 bytes for the client public key, write a single 0x04 byte instead; strip out one byte from the key-exchange data received at the server and write 3 bytes of length and curve ID instead. Also, make sure to reset the strings to the unmodified value before calling mbedtls_ecdh_calc_secret, which probably means maintaining two copies, thus twice the memory. This is a bit messy, and probably unnecessary. The extra parameters "length" is already passed through the API (the &olen argument) and the "group_id" could easily be passed as well. Or maybe I am looking at the wrong API... -- Christian Huitema

2 weeks, 2 days

3
7
0 0

TLS handshake with AWS IoT MQTT broker seems to succeed and then is terminated by the broker

by Roger Sala

I am developing an AWS IoT MQTT client on STM32H723 using FreeRTOS 10.3.1, LwIP 2.1.2 and MbedTLS. My first attempt used MbedTLS 2.16.2 and it mostly works except that sometimes, seemingly related to the timing of the network I'm using, it fails when my client fails to send out anything after the Client Key Exchange message and then the server responds with a Close Notify as follows: "Time","Source","Destination","Protocol","Length","Info" "0.000000","10.24.108.94","54.157.158.237","TLSv1.2","418","Client Hello" "0.016460","54.157.158.237","10.24.108.94","TLSv1.2","150","Server Hello" "0.002777","54.157.158.237","10.24.108.94","TLSv1.2","685","Certificate" "0.000000","54.157.158.237","10.24.108.94","TLSv1.2","438","Server Key Exchange, Certificate Request, Server Hello Done" "0.976521","10.24.108.94","54.157.158.237","TLSv1.2","1006","Certificate, Client Key Exchange" "0.014853","54.157.158.237","10.24.108.94","TLSv1.2","61","Alert (Level: Warning, Description: Close Notify)" When it works it looks like this: "Time","Source","Destination","Protocol","Length","Info" "0.000000000","10.0.0.11","54.84.254.130","TLSv1.2","418","Client Hello" "0.017495225","54.84.254.130","10.0.0.11","TLSv1.2","150","Server Hello" "0.001743255","54.84.254.130","10.0.0.11","TLSv1.2","685","Certificate" "0.000022282","54.84.254.130","10.0.0.11","TLSv1.2","392","Server Key Exchange" "0.000004428","54.84.254.130","10.0.0.11","TLSv1.2","100","Certificate Request, Server Hello Done" "2.606030441","10.0.0.11","54.84.254.130","TLSv1.2","1326","Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message" "0.027421478","54.84.254.130","10.0.0.11","TLSv1.2","105","Change Cipher Spec, Encrypted Handshake Message" "0.000971482","10.0.0.11","54.84.254.130","TLSv1.2","193","Application Data" "0.075384354","54.84.254.130","10.0.0.11","TLSv1.2","87","Application Data" The last two "Application Data" messages are the MQTT connect and connect ACK, So before I filed a bug report, I upgraded to MbedTLS 2.28.4. The good news is that this client always (seems) to successfully negotiate the TLS handshake, but after receiving the first encrypted "Application Data" (connect), the broker immediately sends and "Encrypted Alert", which I'm taking to be a Close Notify because a TCP FIN follows shortly thereafter. The Wireshark capture of the 2.28.4 handshake looks almost exactly like the successful 2.16.2 handshake: "Time","Source","Destination","Protocol","Length","Info" "0.000000000","10.0.0.11","44.195.98.16","TLSv1.2","336","Client Hello" "0.018450117","44.195.98.16","10.0.0.11","TLSv1.2","150","Server Hello" "0.000524146","44.195.98.16","10.0.0.11","TLSv1.2","685","Certificate" "0.000003168","44.195.98.16","10.0.0.11","TLSv1.2","392","Server Key Exchange" "0.000002995","44.195.98.16","10.0.0.11","TLSv1.2","100","Certificate Request, Server Hello Done" "2.517148776","10.0.0.11","44.195.98.16","TLSv1.2","1329","Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message" "0.016572792","44.195.98.16","10.0.0.11","TLSv1.2","60","Change Cipher Spec" "0.000007326","44.195.98.16","10.0.0.11","TLSv1.2","99","Encrypted Handshake Message" "0.001500778","10.0.0.11","44.195.98.16","TLSv1.2","193","Application Data" "0.031014646","44.195.98.16","10.0.0.11","TLSv1.2","85","Encrypted Alert" ... except for the "Encrypted Alert" from the broker that leads to the closing of the session. I'm hoping someone has an explanation of the behavior I'm seeing and can suggest a path forward for me. Another data point is the fact that the client with MbedTLS 2.28.4 can successfully authentic and negotiate a TLS handshake with a mosquitto broker I'm running locally using self signed certificates. ====================================================================== The information contained in this e-mail, including all of its attachments, is confidential and proprietary information of IPG Photonics and its affiliates and intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by telephone or e-mail, and destroy this communication and all copies. Thank you. ======================================================================= This Email has been scanned for all viruses by IPG Photonics Email Scanning Services.

2 weeks, 3 days

1
0
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 ReplyReply to allForward

2 weeks, 3 days

2
2
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 weeks

1
0
0 0

New TrustedFirmware Discord Server

by don.harbin＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 weeks

1
0
0 0

Does mbedtls support x509 certificates signed wih ED448 algorithm?

by Bahadır Maktav

Hi, I am trying to use a certificate with its public key algorithm is NIST P-384 and its signature algorithm is ED448. I am working on ESP board with IDF framework which supports mbedtls. But when I am trying to use that certificate, I got error message about 'MBEDTLS_ERR_X509_UNKOWN_SIG_ALG'. So, I thought that maybe mbedtls does not support certificates which signed with ED448.

1 month

2
1
0 0

Does mbedtls support x509 certificates signed wih ED448 algorithm?

by Bahadır Maktav

Hi, I am trying to use a certificate with its public key algorithm is NIST P-384 and its signature algorithm is ED448. I am working on ESP board with IDF framework which supports mbedtls. But when I am trying to use that certificate, I got error message about 'MBEDTLS_ERR_X509_UNKOWN_SIG_ALG'. So, I thought that maybe mbedtls does not support certificates which signed with ED448.

1 month

1
0
0 0

Example of AEAD decrypt?

by Christian Huitema

The example of AEAD encryption in "aead_demo" is very useful. Is there a similar example for decryption? -- Christian Huitema

1 month

2
1
0 0

Does mbedTLS TLS1.3 only support PSK?

by Thompson, Jeff

I've got mbedTLS 3.1.4 and want to use TLS 1.3. My handshake fails very early because I don't have any Pre-Shared Keys. Does mbedTLS TLS1.3 only support PSKs, or can I still use generated session keys as does TLS 1.2? If so, how? Jeff Thompson | Senior Electrical Engineer - Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D9D729.620C6230]

1 month

2
2
0 0

2023

2022

2021

2020

mbed-tls