- mbed-tls - lists.trustedfirmware.org

by Nassim Eddequiouaq

Hi, I'm running into a signature verification issue with ECDSA. I've generated test values with python and have a working signature verification: --------- Python --------- In [66]: sig_bytes.hex() Out[66]: '30440220704fb7e4e51dc0f2f9bb0a3645d433bdd7ea23dff5e0e231449261f043c645db02203e648d4924c56b14004d984bcacf954e47ae6109db15597695664d06c0b782c2' In [67]: statement Out[67]: b'1:VALID_SESSION:2:xxxx' In [68]: key = load_pem_public_key(b'-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWaBFEuO91YcVK6mJqDtjCvRT8cE7\nfjKNmOxU/wYzSPVHyyZ0IhxY9 ...: UFwZKWO1iEWkeReHK/SNRk2rtvX4qX44g==\n-----END PUBLIC KEY-----\n') In [69]: key.verify(sig_bytes, statement, primitives.asymmetric.ec.ECDSA(primitives.hashes.SHA256())) Success ---------------------------- And have the following code on the mbedTLS C side which fails on mbedtls_ecdsa_read_signature(): --------- MbedTLS --------- uint8_t sha256_digest_buff[SHA256_DIGEST_BYTES] = { 0 }; uint8_t* message = (uint8_t*)"1:VALID_SESSION:2:xxxx"; uint8_t* public_key_pem = (uint8_t*)"-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEc8uijCCOayvXQz5+2fjVjAbNraYf\nReDKcN8p5ttPedCXxr8A9rGcmA89pFcmpuDRvZgx+qiRC/pNcs0kqy1VVQ==\n-----END PUBLIC KEY-----\n"; uint8_t signature[70] = {0x30, 0x44, 0x02, 0x20, 0x70, 0x4f, 0xb7, 0xe4, 0xe5, 0x1d, 0xc0, 0xf2, 0xf9, 0xbb, 0x0a, 0x36, 0x45, 0xd4, 0x33, 0xbd, 0xd7, 0xea, 0x23, 0xdf, 0xf5, 0xe0, 0xe2, 0x31, 0x44, 0x92, 0x61, 0xf0, 0x43, 0xc6, 0x45, 0xdb, 0x02, 0x20, 0x3e, 0x64, 0x8d, 0x49, 0x24, 0xc5, 0x6b, 0x14, 0x00, 0x4d, 0x98, 0x4b, 0xca, 0xcf, 0x95, 0x4e, 0x47, 0xae, 0x61, 0x09, 0xdb, 0x15, 0x59, 0x76, 0x95, 0x66, 0x4d, 0x06, 0xc0, 0xb7, 0x82, 0xc2}; [...] int mbedtls_status = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED; mbedtls_pk_context pubkey_ctx; mbedtls_ecdsa_context ecdsa_ctx; mbedtls_ecp_curve_info *curve_info = NULL; /* Create public key context */ mbedtls_pk_init(&pubkey_ctx); /* Create ecdsa context */ mbedtls_ecdsa_init(&ecdsa_ctx); /* Parse public key */ if ((mbedtls_status = mbedtls_pk_parse_public_key(&pubkey_ctx, pubkey_pem, pubkey_pem_len)) != 0) { ERRORF("Failure failure parsing PEM-encoded ecdsa-p256r1 public key, mbedTLS status: %d", mbedtls_status); ret = E_INVAL_PUBKEY; goto cleanup; } /* Hash the message with sha256 */ if ((mbedtls_status = mbedtls_sha256_ret(message, message_len, sha256_digest_buff, 0 /* Not 224 bits hashing */ )) != 0) { ERRORF("Failure sha256-hashing message before ecdsa-p256r1 signature verification, mbedTLS status: %d", mbedtls_status); ret = E_FAILED_HASH; goto cleanup; } /* Set the public key as the ecdsa signature verification key */ if ((mbedtls_status = mbedtls_ecp_copy(&ecdsa_ctx.Q, &mbedtls_pk_ec(pubkey_ctx)->Q)) != 0 ) { ERRORF("Failure copying ecdsa-p256r1 public key to ecdsa context, mbedTLS status: %d", mbedtls_status); ret = E_UNKNOWN; goto cleanup; } if ((mbedtls_status = mbedtls_ecp_group_copy(&ecdsa_ctx.grp, &mbedtls_pk_ec(pubkey_ctx)->grp)) != 0 ) { ERRORF("Failure copying ecdsa-p256r1 public key group to ecdsa context, mbedTLS status: %d", mbedtls_status); ret = E_UNKNOWN; goto cleanup; } /* Verify ecdsa-p256r1 signature verification */ if ((mbedtls_status = mbedtls_ecdsa_read_signature(&ecdsa_ctx, sha256_digest_buff, sizeof(sha256_digest_buff), signature, signature_len)) != 0) { ERRORF("Failure verifying ecdsa-p256r1 signature against message, mbedTLS status: %d", mbedtls_status); ret = E_INVALID_SIG; goto cleanup; } /* Success */ ret = E_SUCCESS; ---------------------------- Also, `mbedtls_ecp_curve_info_from_grp_id( ecdsa_ctx.grp.id )->name` yields the right curve prior to the signature verification. I must be missing something in the process. Would love to get some input, thanks a lot! -- Nassim Eddequiouaq

3 years, 6 months

1
0
0 0

Re: [mbed-tls] Request for Support [Issue : Webserver handshake failing with self-signed certificate]

by Selin Chris

Hi Gilles, Thanks for the quick reply. I migrated to version 2.16, and I have seen the same issue is still there. Moreover, we have reseeded the RNG, still issue is there. I created a client and it's working fine, it's able to handshake and send data to the server. Only problem is server communication where control is going in infinite loop while creating server key exchange. As you asked for the call stack of the loop, I am attaching the call stack with this mail. Please support us. Thank you. Regards, Selin. On Fri, May 21, 2021 at 5:30 PM <mbed-tls-request(a)lists.trustedfirmware.org> wrote: > Send mbed-tls mailing list submissions to > mbed-tls(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > or, via email, send a message with subject or body 'help' to > mbed-tls-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > mbed-tls-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mbed-tls digest..." > > > Today's Topics: > > 1. Re: Request for Support [Issue : Webserver handshake failing > with self-signed certificate] (Gilles Peskine) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 20 May 2021 15:13:54 +0200 > From: Gilles Peskine <gilles.peskine(a)arm.com> > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] Request for Support [Issue : Webserver > handshake failing with self-signed certificate] > Message-ID: <93c3cd71-bdc1-c3ec-4bbc-89ff995a8444(a)arm.com> > Content-Type: text/plain; charset=utf-8 > > Hi Selin, > > A possible problem could be a misconfigured random generator. However > this is purely speculation. Can you get a stack trace? Finding the root > cause requires finding where mbedtls_mpi_cmp_mpi is called. > > Please note that Mbed TLS 2.16.3 has known bugs and vulnerabilities. You > should upgrade to the latest bug-fixing version of the 2.16 branch, > 2.16.10. > > -- > Gilles Peskine > Mbed TLS developer > > On 20/05/2021 13:06, Selin Chris via mbed-tls wrote: > > > > Hi, > > > > Thank you for adding me to the mbed-tls mailing list. > > > > We have created a self-signed certificate with ECC key of > > MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate > > after we send the certificate to chrome from our web server it shows > > not trusted and goes to the page where we need to manually proceed > > with the acceptance of the certificate to allow further communication. > > After this we again have to perform handshake for which we need to > > prepare the server key exchange, while preparing the server key > > exchange we notice that it is infinitely calling the > > mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is not > > able to proceed hereafter. Sometimes we also see that when executing > > ssl_prepare_server_key_exchange() function in ssl_srv.c we find > > ciphersuite_info pointer as null and the program goes into data panic > > due to that. We have checked our stacks and not seen any sign of > > corruption. > > > > The mbedtls version that we are using is mbedtls-2.16.3. > > Please find the attached wireshark trace during this scenario. The IP > > 192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc > > with the browser. > > > > Please let us know the root-cause of the issue and the actions to be > > taken to fix this - can you please expedite as this is a blocking > > issue in our project. > > > > Thanks for the support. > > > > Regards, > > Selin. > > > > > > > > > > ------------------------------ > > Subject: Digest Footer > > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > ------------------------------ > > End of mbed-tls Digest, Vol 15, Issue 8 > *************************************** >

3 years, 6 months

1
0
0 0

Server and client fails with “Verification of the message MAC failed” after Successful Handshake

by Vaibhav Sathye

Hi I am writing a server client with Libuv as tcp stack and mbedtls as ssl. I am able to do a successful handshake between server and client but after that when I try to write/read application data it fails with “Verification of the message MAC failed”. After inspecting debug logs, I found the server and client have the same Pre-master master secret and IV and still it is failing. Currently both client and server are on the same machine . I am attaching server and client logs. Any help is appreciated. server.log <https://drive.google.com/file/d/1oaMMV2_YVDL8GLn6GH3PIQSIH5BDbGeU/view?usp=…> client.log <https://drive.google.com/file/d/1Z9P1ssglqRpBUmXF9TuRQd6KJKvyw6RJ/view?usp=…> Thanks Vaibhav

3 years, 6 months

1
0
0 0

Re: [mbed-tls] Request for Support [Issue : Webserver handshake failing with self-signed certificate]

by Gilles Peskine

Hi Selin, A possible problem could be a misconfigured random generator. However this is purely speculation. Can you get a stack trace? Finding the root cause requires finding where mbedtls_mpi_cmp_mpi is called. Please note that Mbed TLS 2.16.3 has known bugs and vulnerabilities. You should upgrade to the latest bug-fixing version of the 2.16 branch, 2.16.10. -- Gilles Peskine Mbed TLS developer On 20/05/2021 13:06, Selin Chris via mbed-tls wrote: > > Hi, > > Thank you for adding me to the mbed-tls mailing list. > > We have created a self-signed certificate with ECC key of > MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate > after we send the certificate to chrome from our web server it shows > not trusted and goes to the page where we need to manually proceed > with the acceptance of the certificate to allow further communication. > After this we again have to perform handshake for which we need to > prepare the server key exchange, while preparing the server key > exchange we notice that it is infinitely calling the > mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is not > able to proceed hereafter. Sometimes we also see that when executing > ssl_prepare_server_key_exchange() function in ssl_srv.c we find > ciphersuite_info pointer as null and the program goes into data panic > due to that. We have checked our stacks and not seen any sign of > corruption. > > The mbedtls version that we are using is mbedtls-2.16.3. > Please find the attached wireshark trace during this scenario. The IP > 192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc > with the browser. > > Please let us know the root-cause of the issue and the actions to be > taken to fix this - can you please expedite as this is a blocking > issue in our project. > > Thanks for the support. > > Regards, > Selin. > > >

3 years, 6 months

1
0
0 0

Request for Support [Issue : Webserver handshake failing with self-signed certificate]

by Selin Chris

Hi, Thank you for adding me to the mbed-tls mailing list. We have created a self-signed certificate with ECC key of MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate after we send the certificate to chrome from our web server it shows not trusted and goes to the page where we need to manually proceed with the acceptance of the certificate to allow further communication. After this we again have to perform handshake for which we need to prepare the server key exchange, while preparing the server key exchange we notice that it is infinitely calling the mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is not able to proceed hereafter. Sometimes we also see that when executing ssl_prepare_server_key_exchange() function in ssl_srv.c we find ciphersuite_info pointer as null and the program goes into data panic due to that. We have checked our stacks and not seen any sign of corruption. The mbedtls version that we are using is mbedtls-2.16.3. Please find the attached wireshark trace during this scenario. The IP 192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc with the browser. Please let us know the root-cause of the issue and the actions to be taken to fix this - can you please expedite as this is a blocking issue in our project. Thanks for the support. Regards, Selin.

3 years, 6 months

1
0
0 0

Re: [mbed-tls] Query for TLS 1.3

by Shebu Varghese Kuriakose

Hi Manoj, As you might have seen, TLS1.3 prototype is available in github https://github.com/hannestschofenig/mbedtls/tree/tls13-prototype The project is working on reviewing the prototype and upstreaming parts of it to Mbed TLS. The currently open pull requests to Mbed TLS project can be found here: https://github.com/ARMmbed/mbedtls/labels/MPS%20%2F%20TLS%201.3 Some of the outstanding work is captured here - https://github.com/ARMmbed/mbedtls/projects/2#column-12964476 If possible, please test the TLS1.3 prototype and let know if you have any feedback. Also welcome to review any patches. 1. Expected date for release of MbedTLS with TLS 1.3 support? A subset of TLS 1.3 features is aimed to be available around the last quarter of 2021. TLS1.3 support in Mbed TLS at that point would be limited for TLS (no DTLS), Client side and ECDHE. There won't be support for server side, PSK and 0-RTT in this initial version. Note the last quarter target is based on high level task estimations and can change based on progress made in the coming months. You can use the prototype above in the interim for prototyping/development purposes. It is not expected to be integrated on production platforms though. 1. Is MbedTLS with TLS 1.3 support available under paid subscription? No, there is no paid offerings in Mbed TLS project. Mbed TLS project is an open source community project under trustedfirmware.org (https://www.trustedfirmware.org/) and is available to use under the open source license (Refer license section - https://github.com/ARMmbed/mbedtls). 1. Process for paid subscription (if point #2 applicable) Not Applicable Regards, Shebu From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>> On Behalf Of Manoj Srivastava via mbed-tls Sent: Monday, May 17, 2021 8:57 PM To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> Subject: [mbed-tls] Query for TLS 1.3 Hello, I am using mbedTLS for TLS support. I am looking for TLS 1.3 support for PSK only mode. I have checked source code online but didn't get TLS 1.3 PSK only code. I found all prototype code only. Can you please highlight the repository if the same is available ? In case fixed code for TLS 1.3 for PSK only mode is not available then can please answer followings: 1. Expected date for release of MbedTLS with TLS 1.3 support? 2. Is MbedTLS with TLS 1.3 support available under paid subscription? 3. Process for paid subscription (if point #2 applicable) Best Regards, Manoj Srivastava

3 years, 6 months

1
0
0 0

Query for TLS 1.3

by Manoj Srivastava

Hello, I am using mbedTLS for TLS support. I am looking for TLS 1.3 support for PSK only mode. I have checked source code online but didn't get TLS 1.3 PSK only code. I found all prototype code only. Can you please highlight the repository if the same is available ? In case fixed code for TLS 1.3 for PSK only mode is not available then can please answer followings: 1. Expected date for release of MbedTLS with TLS 1.3 support? 2. Is MbedTLS with TLS 1.3 support available under paid subscription? 3. Process for paid subscription (if point #2 applicable) Best Regards, Manoj Srivastava

3 years, 6 months

1
0
0 0

Re: [mbed-tls] Support for ECDH key generation with Curve25519

by brian_d＠tutanota.com

Hi, thanks a lot for the fast reply and sorry for my late answer but I did a lot of tests in order to solve the problem (I never had success on compute shared function when "talking" with another peer). Yes, you're right, no need to modify anything. The issue was that mbedtls uses ecp point coordinates in big endian format while the other peer bytes were intended to be in little endian format. After reversing the bytes before compute shared everything worked! Thank you, have a nice day! Brian 3 mag 2021, 21:53 da mbed-tls(a)lists.trustedfirmware.org: > Hi Brian, > > It's not clear to me what you're trying to do. Mbed TLS supports > Curve25519 arithmetic for X25519, accessible through the > mbedtls_ecdh_xxx interface. If you want to use Curve25519 for some other > purpose, this may or may not be supported via direct access to the > mbedtls_ecp_xxx interface. The curve arithmetic code only supports > predefined groups, it does not support changing the generator without > patching the library. > > For Curve25519, the generator is the point (X,Z)=(9,1). Isn't this the > generator you want? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > On 30/04/2021 17:39, Brian via mbed-tls wrote: > >> Hi all, >> I'm trying to set the generator g to a value of 9 for the Curve25519 with mbedtls_ecp_gen_key function. However I cannot find any way to accomplish that. >> Could anyone help me? >> Thank you, have a nice day,Brian >> > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

3 years, 6 months

1
0
0 0

Not sure if the TLS implementation is correct or not

by Younes Boulahya

Please see these 2 stackoverflow posts: Implementing TLS over HTTP in STM32F303RC using W5500 <https://stackoverflow.com/questions/67522903/implementing-tls-over-http-in-…> HTTPS Handshake Debugging <https://stackoverflow.com/questions/67534996/https-handshake-debugging> In short I have implemented mbedtls over an HTTP Client but I am not sure if it's working or not, when I debug using wireshark I can see the handshake and the encrypted data sent to the server, but I don't see any records added to mysql database. [image: 1.PNG]

3 years, 6 months

1
0
0 0

mbedTLS -entropy source issue

by Pandurangan, Devi

Hi, I'm trying to integrate NXPs secure element SE050 into an application running on MSP432E401Y chip. I was able to successfully integrate their middleware(Plug and trust) on a baremetal project with mbedTLS enabled. It seems on this baremetal project, entropy_source (from entropy_alt.c) is not working. And this has a knock on effect on mbedtls_ctr_drbg_seed function which fails and takes the entire project down with it. Also, from the sole example given in the Simplelink SDK (tcpechotls), I see that mbedtls is used in a project with RTOS enabled. Should I try integrating this code in an RTOS based project and check? Has anyone worked on this ? Thanks, Devi Pandurangan Lead Engineer - Embedded Software Armstrong Fluid Technology #59, "Hampapura Mane" 3rd Main, Margosa Road, Malleswaram, Bangalore, Karnataka, 560 003, India T : +91-80-49063555<tel:+91-80-49063555> | F : +91-80-23343535 www.armstrongfluidtechnology.com [cid:image001.jpg@01D741AF.326E2340]<http://www.armstrongfluidtechnology.com/> [cid:image002.jpg@01D741AF.326E2340]<http://twitter.com/ArmstrongFT_UK> [cid:image003.jpg@01D741AF.326E2340]<http://plus.google.com/+Armstrongfluidtechnology> [cid:image004.jpg@01D741AF.326E2340]<http://www.linkedin.com/company/armstrong-fluid-technology> [cid:image005.jpg@01D741AF.326E2340]<http://www.youtube.com/user/ArmstrongFT> [cid:image006.jpg@01D741AF.326E2340]<https://www.facebook.com/ArmstrongFluidTechnology/> [cid:image007.jpg@01D741AF.326E2340]<https://www.flickr.com/photos/armstrongintegrated/collections/> DISCLAIMER: This email and any attachments are sent in confidence, subject to applicable legal privilege and upon the basis that the recipient will conduct appropriate checks. If you have received this email in error, please send it back to us and immediately and permanently delete it: you are strictly prohibited from using, copying or disclosing it or any information contained in it or in any attachment. Internet communications are not secure and Armstrong Design Private Limited is not responsible for their abuse by third parties, nor for any alteration or corruption in transmission, nor for any damage or loss caused by any virus or other defect. Armstrong Fluid Technology is a trading name of Armstrong Design Private Limited, #59, First Floor, 3rd Main Margosa Road, Malleswaram, Bangalore, 560 003, India registered in India company no. 029120KA2004PTC034014.

3 years, 6 months

1
0
0 0

2024

2023

2022

2021

2020

mbed-tls