- mbed-tls - lists.trustedfirmware.org

by Nick Setzer

Hi, I have been working with Mbed TLS for the last 6 months in an extremely low memory use case. This library has been an absolute joy to work with because of how flexible it is. I have an interesting use case with how little RAM I have to work with (around 6kb on one microprocessor) and I have made some changes that I thought would be of interest. I'm not sure if I should submit them as a single changeset or a set of changes. I'll describe the changes and if there is interest I can clean them up for submission. The first change that I made was for a scenario with two microprocessors communicating over a UART. I was already using TLS offloading so that the private key was on one processor (with only 6kb of RAM free) and the SSL context stored on the other. I required generating a CSR and thus made some changes to the CSR code to be able to generate the CSR using a similar private key offloading strategy. I found an issue with downloading firmware for OTA from openssl web servers. This is a little tricky to describe. The server was not responsive to requests for reducing the max fragment length, which forced me to use MBEDTLS_SSL_MAX_CONTENT_LEN set to 16384. But I needed to have multiple ssl sessions open for other activities and did not have enough RAM to hold multiple large buffers. I have made a set of changes to allow setting the content length when the ssl context is initialized, as well as setting different IN and OUT content lengths to save memory. This change allowed me to set up one session with 16kb for the IN content length, and then 4kb for OUT content length, while a second session could use 2kb for a total of 24kb instead of 64kb. Related to the openssl issue, I found that the incoming ssl packet header length can sometimes be 8 or 16 bytes larger than expected depending on which AES method is selected. I'm not actually sure what the best way to solve this is. One way may be to change MBEDTLS_SSL_HEADER_LEN from 13 to 29 bytes. However I ended up solving it by adding 16 to both MBEDTLS_SSL_IN_BUFFER_LEN and MBEDTLS_SSL_OUT_BUFFER_LEN. This way I could handle the larger ssl header as well as receive the content body. If these three changes sound interesting I can start work on cleaning up the code to be less specific to my company and then submit the changes. Also I would like to know if there is any process I should be following when submitting these changes. Thanks, Nick Setzer SimpliSafe, Inc. 294 Washington Street, 9th Floor Boston, MA 02108

5 years, 11 months

1
0
0 0

Re: [mbed-tls] [Mbed-tls-announce] Force push on the master branch

by Scott Branden

Although this particular change doesn't affect me - rewriting history is a bad idea. Why not simply commit a revert back to a cleaner point on "master" branch and then commit the new changes you want from there? Then history is not lost on master branch. Or, with the BLM movement some repos are stopping use of master branch. github seems to be encourage it going forware: https://www.zdnet.com/article/github-to-replace-master-with-alternative-ter… So another option: stop using "master" branch. You could even create a tag/rename and then delete the branch name to avoid any confusions. History won't be rewritten then, just a little "hidden". And start using a new "main" branch. You can push you entire commit series there without revering anything on master branch. Regards, Scott -----Original Message----- From: Mbed-tls-announce [mailto:mbed-tls-announce-bounces@lists.trustedfirmware.org] On Behalf Of Janos Follath via Mbed-tls-announce Sent: Thursday, July 16, 2020 4:09 AM To: mbed-tls-announce(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [Mbed-tls-announce] Force push on the master branch Hi All, The master branch used to track the latest development release. This changed in early 2019 after the 2.16 LTS branch was released. Around this time the cryptography library of Mbed TLS was moved to a separate repository and since then it was used as a submodule. This was one of the main reasons behind the decision to keep master pointing to the 2.16 LTS releases. Recently we have merged the cryptography library back into Mbed TLS. We don't have any reasons any more to keep master tracking the 2.16 LTS release. Therefore we intend to update master to the latest development release. This will happen on 3rd August. The update will involve a force push, which can be disruptive to those users who take Mbed TLS from master. We would like to give such users enough time to adapt to this change. If you are relying on the master branch in a way that this force push affects you, please let us know on the developer mailing list<https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls> and we will do our best to accommodate your needs. Thanks and regards, Janos (on behalf of the Mbed TLS maintainer team) -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

5 years, 11 months

1
0
0 0

[Mbed-tls-announce] Force push on the master branch

by Janos Follath via Mbed-tls-announce

Hi All, The master branch used to track the latest development release. This changed in early 2019 after the 2.16 LTS branch was released. Around this time the cryptography library of Mbed TLS was moved to a separate repository and since then it was used as a submodule. This was one of the main reasons behind the decision to keep master pointing to the 2.16 LTS releases. Recently we have merged the cryptography library back into Mbed TLS. We don't have any reasons any more to keep master tracking the 2.16 LTS release. Therefore we intend to update master to the latest development release. This will happen on 3rd August. The update will involve a force push, which can be disruptive to those users who take Mbed TLS from master. We would like to give such users enough time to adapt to this change. If you are relying on the master branch in a way that this force push affects you, please let us know on the developer mailing list<https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls> and we will do our best to accommodate your needs. Thanks and regards, Janos (on behalf of the Mbed TLS maintainer team) -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

5 years, 11 months

1
0
0 0

Re: [mbed-tls] Upgrading from 2.13.1.to ??.??.??

by Manuel Pegourie-Gonnard

Hi Jeff, > Given the age of the version of mbedTLS I’m using, which is 2.13.1, plus the recent security alert, I think I need to upgrade the version of mbedTLS we have. The question is, which version to use? Indeed upgrading to a maintained branch is very recommended! There are currently two actively maintained branches you could use: * 2.16.x, which is our latest LTS branch, currently at 2.16.7. As an LTS branch, it only receives bug fixes and security updates, so it's pretty stable. In particular, since it doesn't receive any new feature, its footprint (code size) should remain mostly stable as well. * 2.x.y, released from the development branch, currently at 2.23.0. This is the branch where new features land. Both of these have full API compatibility with 2.13.1. We take great care not to break API compatibility between major releases - we haven't broken it since Mbed TLS 2.0.0 (release 2015-07-13), and the next release to break API compatibility with be 3.0.0 (now planned for early 2021). Until then, upgrading should be a simple matter of replacing the mbedtls directory in your source tree with the version of your choice, then rebuilding your project. (Moreover in the LTS branches we actually try maintain ABI compatibility as far as possible - that is, unless there's a security issue that can only be fixed by changing the ABI.) Mbed TLS is designed bo be quite modular an integrate with the OS and networking stack via user-provided hooks and compile-time configuration (`include/mbedtls/config.h`). I'm not sure how the integration with LwIP and FreeRTOS was done by your MCU vendor, but I suggest you check: * is the mbedtls directory in your source tree identical to our upstream release? If yes, you should be able to just replace it with the release of your choice and things should work. * otherwise, what's the nature of the differences: are filed shuffled to a different directory structure? is the build system different? has the `mbedtls/config.h` file been modified? have other files been modified (which ideally really shouldn't be necessary)? In that case, you'll probably need to apply the same changes to the upgraded version of Mbed TLS. Hopefully the differences if any will be small, and otherwise perhaps you MCU vendor can provide documentation about it. So I can't really say for this specific integration, but in principle upgrading Mbed TLS should be really painless - precisely so that people can upgrade easily in case of security fixes. Hope this helps, and let us know how it went! Regards, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Thompson, Jeff via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 14 July 2020 22:11 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Upgrading from 2.13.1.to ??.??.?? Given the age of the version of mbedTLS I’m using, which is 2.13.1, plus the recent security alert, I think I need to upgrade the version of mbedTLS we have. The question is, which version to use? Because we got mbedTLS as example code from the MCU vendor, it was already integrated with lwIP and FreeRTOS. I’m sure this will not be a trivial effort, but I do need to present my management with some idea of the time it could take. Does anyone have a rough estimate of what to expect? I’m thinking on the order of 2 to 4 weeks for someone who is an experienced C programmer, but unfamiliar with either mbedTLS or lwIP. Or is that a pipe dream, with the actual time being closer to 3 or 4 months? Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D659E2.BE6C0700]

5 years, 11 months

1
0
0 0

Upgrading from 2.13.1.to ??.??.??

by Thompson, Jeff

Given the age of the version of mbedTLS I'm using, which is 2.13.1, plus the recent security alert, I think I need to upgrade the version of mbedTLS we have. The question is, which version to use? Because we got mbedTLS as example code from the MCU vendor, it was already integrated with lwIP and FreeRTOS. I'm sure this will not be a trivial effort, but I do need to present my management with some idea of the time it could take. Does anyone have a rough estimate of what to expect? I'm thinking on the order of 2 to 4 weeks for someone who is an experienced C programmer, but unfamiliar with either mbedTLS or lwIP. Or is that a pipe dream, with the actual time being closer to 3 or 4 months? Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D659E2.BE6C0700]

5 years, 11 months

1
0
0 0

Re: [mbed-tls] mbed-tls canonical repository (trustedfirmware.org git empty)

by Shebu Varghese Kuriakose

Hi Matt. You are right - https://git.trustedfirmware.org/tls/mbed-tls.git seem to be empty. As part of Mbed TLS transitioning to trustedfirmware.org community project in March’20, a mirror of https://github.com/ARMmbed/mbedtls.git was created in the above trustedfirmware.org git. Yes, all the development is still carrying on in https://github.com/ARMmbed/mbedtls.git and the plan is to move the development of MbedTLS to trustedfirmware.org repository itself a bit later on. The trustedfirmware.org Mbed TLS mirror repository seem to have moved to https://git.trustedfirmware.org/mirror/mbed-tls.git/. Regards, Shebu From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt Walker via mbed-tls Sent: Wednesday, July 8, 2020 8:34 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] mbed-tls canonical repository (trustedfirmware.org git empty) Hi; For a while I've had a couple of projects pulling in mbed-tls from the trustedfirmware.org<http://trustedfirmware.org> git repository at https://git.trustedfirmware.org/tls/mbed-tls.git However, I just attempted to clone from that repository again only to discover it's now empty! I've searched around and I can't find any messaging on why this would be the case, so it's either an accident or my search foo is failing me. It looks like the majority of development for mbed-tls is still happening on github at https://github.com/ARMmbed/mbedtls.git but I'd rather point my upstream to the canonical location. Is this a temporary outage, or should github be considered the origin of all things mbed-tls? Thanks, Matt Walker

5 years, 11 months

2
1
0 0

Mbed TLS: Security Advisory and Release of Mbed TLS 2.23.0, 2.16.7 and 2.7.16

by Janos Follath

An Mbed TLS Security Advisory has been issued to accompany the release of Mbed TLS versions 2.23.0, 2.16.7 and 2.7.16, which have just been released. 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 Mbed TLS 2.23.0<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.23.0>, Mbed TLS 2.16.7<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.7>, Mbed TLS 2.7.16<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.7.16> and in the 2020-07 security advisory<https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi…>. We recommend all users to consider whether they are impacted, and to upgrade appropriately.

5 years, 11 months

1
0
0 0

mbed-tls canonical repository (trustedfirmware.org git empty)

by Matt Walker

Hi; For a while I've had a couple of projects pulling in mbed-tls from the trustedfirmware.org git repository at https://git.trustedfirmware.org/tls/mbed-tls.git However, I just attempted to clone from that repository again only to discover it's now empty! I've searched around and I can't find any messaging on why this would be the case, so it's either an accident or my search foo is failing me. It looks like the majority of development for mbed-tls is still happening on github at https://github.com/ARMmbed/mbedtls.git but I'd rather point my upstream to the canonical location. Is this a temporary outage, or should github be considered the origin of all things mbed-tls? Thanks, Matt Walker

5 years, 11 months

1
0
0 0

Re: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed

by Hannes Tschofenig

Hi all, I have been using Mbed TLS with mutual certificate-based authentication all the time. Here is the configuration: [cid:image004.jpg@01D65150.65DFD610] Here is a link to a webinar where I talk about certificate-based authentication and show-case mutual authentication with a Keil development board: https://www.youtube.com/watch?v=iH4v-aXQ2zQ<https://www.youtube.com/watch?v=iH4v-aXQ2zQ&feature=emb_logo> Slides are here: http://www2.keil.com/docs/default-source/default-document-library/keil_mbed… >From what I can tell (trying to connect to your test server myself) you haven't configured the auth_mode=required on the server side. Without it the TLS server will not send a CertificateRequest message. Ciao Hannes From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhilash Iyer via mbed-tls Sent: Friday, July 3, 2020 2:56 PM To: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com> Cc: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed Hi Gopi, Thank you very much for your feedback. I double checked all the recommended configuration that you mentioned but it did not help. I really suspect if I have hit a mbedTLS limitation here. Following our conversation, I tried connecting to the server using openSSL. Server: https://preview.auth.edgeai.azure.net/api/v1/device/auth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpreview.a…> OpenSSL commands: OpenSSL> s_client -connect preview.auth.edgeai.azure.net:443 -showcerts -debug -msg -state -tls1_2 -cert certificate1.pem -key privateKey1.pem GET /api/v1/device/auth HTTP/1.1 HOST:preview.auth.edgeai.azure.net With the above commands, I am able to send the client certificate to the server. I have attached the openSSL logs to show the flow of TLS activity. As per the logs attached, this is the flow of activity: 1. In the first TLS handshake there is no certificate request and no client certificate sent. I see ClientHello, ServerHello, ServerCertificate, ServerKeyExchange, Server Done, ClientKeyExchange, Change cipher spec, Certificate chain information and Server Cert. Till here, I do see: No client certificate CA names sent. 2. Now when I do a Get call & pass the HOST, client writes that call to the server and in turn the server returns me a "HelloRequest" which is encrypted. Now, this chain of handshake has a CertificateRequest, ClientCertificate, CertificateVerify etc. I see that 1009 bytes of data been written on the server under the name of client certificate. There is no way to see this certificate because the channel is encrypted now. 3. Lastly, we get HTTP/1.1 200 OK. Now when I do the same thing using the mbedTLS client on windows 10 PC, I see that the client gets reset during the renegotiation process. Note that the client cert was supposed to be exchanged in the renegotiation period, not the initial handshake. I have attached the logs for mbedTLS client as well and here are the commands that I use to communicate using mbedTLS client. ssl_client2.exe server_name=preview.auth.edgeai.azure.net server_port=443 debug_level=5 auth_mode=required renegotiate=1 reconnect=1 request_page=/api/v1/device/auth crt_file=certificate1.pem key_file=privateKey1.pem ca_file=server_prev1.pem I am wondering if this type of exchange of certs is not supported by mbedTLS at all. But it doesn't work with the remote server since this server looks for the client cert in the renegotiation phase to retain client certificate privacy. Can you confirm that this is a MBEDTLS limitation and have to move to a different library? Thanks, Abhilash From: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com<mailto:gopikrishnan.subramanian@kone.com>> Sent: Sunday, June 28, 2020 8:58 PM To: Abhilash Iyer <Abhilash.Iyer(a)microsoft.com<mailto:Abhilash.Iyer@microsoft.com>> Subject: [EXTERNAL] RE: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed Hi Abilash, Few things to verify 1. On server side - make sure the authentication mode is set to required instead of optional. * Test with browser, does Handshake is succeeding if cancelling to select Certificate. * If the above were success, then proceed to modify auth_mode on server as below and test once again. * mbedtls_ssl_conf_authmode( &conf, MBEDTLS_SSL_VERIFY_REQUIRED ); - insisting Server to Request Certificate. 2. On client side - check does it has a valid Certificate & Key set to TLS Configuration * mbedtls_ssl_conf_own_cert( &conf, &clicert, &pkey ); Thanks, Gopi Krishnan From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>> On Behalf Of Abhilash Iyer via mbed-tls Sent: Monday, June 22, 2020 2:00 PM To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> Subject: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed This message is from an external sender. Be cautious, especially with links and attachments. Hello, I am trying to incorporate Mutual Authentication TLS in my hardware. For testing the mutual authentication in TLS, I setup a demo service which would request a client certificate in the TLS handshake. I used MS Edge, Google Chrome to test whether the service requests a client certificate during the TLS 1.2 handshake. When I ping the website, I do receive a request for a client certificate as shown in the image below. On selecting a certificate, I am able to access the website. Link to the demo service: https://serviceforsomsecurity.azurewebsites.net/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservicefo…> [A screenshot of a cell phone Description automatically generated] The above validates that the service requires the client to provide the client certificate during the TLS handshake. Now, when I test this with the sample mbedTLS ssl_client2.c program: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>, the client does not send a certificate at all. The following are the steps that I carry out to test the TLS connection with my service with the sample mbedTLS ssl_client2.exe : 1. Open the mbedTLS.sln and build the ssl_client2 project. This creates a ssl_client2.exe under the Debug folder. 2. ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 The above command to test whether the client sends the client certificate during handshake. Here's the log: [A screenshot of a computer Description automatically generated] As you can see, in 3025 client receives: got no certificate request and then followed by server hello done at 3157. And then at 2080 & 2094, client skips writing certificate; during this handshake. 3. Then I tried including renegotiation flag: ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 renegotiate=1 Even in this case, the client does not get the certificate and abruptly ends during renegotiation due to timeout. I have included both the log files below for complete handshake review. [ssl_client_without_renegotiation.txt and ssl_client_with_renegotiation.txt] Can you please let me know how to debug this client certificate problem? It will be really a great help! Million thanks in advance. Regards, Abhilash

5 years, 11 months

2
3
0 0

Re: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed

by Abhilash Iyer

Hi Gopi, Thank you very much for your feedback. I double checked all the recommended configuration that you mentioned but it did not help. I really suspect if I have hit a mbedTLS limitation here. Following our conversation, I tried connecting to the server using openSSL. Server: https://preview.auth.edgeai.azure.net/api/v1/device/auth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpreview.a…> OpenSSL commands: OpenSSL> s_client -connect preview.auth.edgeai.azure.net:443 -showcerts -debug -msg -state -tls1_2 -cert certificate1.pem -key privateKey1.pem GET /api/v1/device/auth HTTP/1.1 HOST:preview.auth.edgeai.azure.net With the above commands, I am able to send the client certificate to the server. I have attached the openSSL logs to show the flow of TLS activity. As per the logs attached, this is the flow of activity: 1. In the first TLS handshake there is no certificate request and no client certificate sent. I see ClientHello, ServerHello, ServerCertificate, ServerKeyExchange, Server Done, ClientKeyExchange, Change cipher spec, Certificate chain information and Server Cert. Till here, I do see: No client certificate CA names sent. 2. Now when I do a Get call & pass the HOST, client writes that call to the server and in turn the server returns me a "HelloRequest" which is encrypted. Now, this chain of handshake has a CertificateRequest, ClientCertificate, CertificateVerify etc. I see that 1009 bytes of data been written on the server under the name of client certificate. There is no way to see this certificate because the channel is encrypted now. 3. Lastly, we get HTTP/1.1 200 OK. Now when I do the same thing using the mbedTLS client on windows 10 PC, I see that the client gets reset during the renegotiation process. Note that the client cert was supposed to be exchanged in the renegotiation period, not the initial handshake. I have attached the logs for mbedTLS client as well and here are the commands that I use to communicate using mbedTLS client. ssl_client2.exe server_name=preview.auth.edgeai.azure.net server_port=443 debug_level=5 auth_mode=required renegotiate=1 reconnect=1 request_page=/api/v1/device/auth crt_file=certificate1.pem key_file=privateKey1.pem ca_file=server_prev1.pem I am wondering if this type of exchange of certs is not supported by mbedTLS at all. But it doesn't work with the remote server since this server looks for the client cert in the renegotiation phase to retain client certificate privacy. Can you confirm that this is a MBEDTLS limitation and have to move to a different library? Thanks, Abhilash From: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com> Sent: Sunday, June 28, 2020 8:58 PM To: Abhilash Iyer <Abhilash.Iyer(a)microsoft.com> Subject: [EXTERNAL] RE: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed Hi Abilash, Few things to verify 1. On server side - make sure the authentication mode is set to required instead of optional. * Test with browser, does Handshake is succeeding if cancelling to select Certificate. * If the above were success, then proceed to modify auth_mode on server as below and test once again. * mbedtls_ssl_conf_authmode( &conf, MBEDTLS_SSL_VERIFY_REQUIRED ); - insisting Server to Request Certificate. 2. On client side - check does it has a valid Certificate & Key set to TLS Configuration * mbedtls_ssl_conf_own_cert( &conf, &clicert, &pkey ); Thanks, Gopi Krishnan From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>> On Behalf Of Abhilash Iyer via mbed-tls Sent: Monday, June 22, 2020 2:00 PM To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> Subject: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed This message is from an external sender. Be cautious, especially with links and attachments. Hello, I am trying to incorporate Mutual Authentication TLS in my hardware. For testing the mutual authentication in TLS, I setup a demo service which would request a client certificate in the TLS handshake. I used MS Edge, Google Chrome to test whether the service requests a client certificate during the TLS 1.2 handshake. When I ping the website, I do receive a request for a client certificate as shown in the image below. On selecting a certificate, I am able to access the website. Link to the demo service: https://serviceforsomsecurity.azurewebsites.net/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservicefo…> [A screenshot of a cell phone Description automatically generated] The above validates that the service requires the client to provide the client certificate during the TLS handshake. Now, when I test this with the sample mbedTLS ssl_client2.c program: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>, the client does not send a certificate at all. The following are the steps that I carry out to test the TLS connection with my service with the sample mbedTLS ssl_client2.exe : 1. Open the mbedTLS.sln and build the ssl_client2 project. This creates a ssl_client2.exe under the Debug folder. 2. ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 The above command to test whether the client sends the client certificate during handshake. Here's the log: [A screenshot of a computer Description automatically generated] As you can see, in 3025 client receives: got no certificate request and then followed by server hello done at 3157. And then at 2080 & 2094, client skips writing certificate; during this handshake. 3. Then I tried including renegotiation flag: ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 renegotiate=1 Even in this case, the client does not get the certificate and abruptly ends during renegotiation due to timeout. I have included both the log files below for complete handshake review. [ssl_client_without_renegotiation.txt and ssl_client_with_renegotiation.txt] Can you please let me know how to debug this client certificate problem? It will be really a great help! Million thanks in advance. Regards, Abhilash

5 years, 11 months

1
0
0 0

[Mbed-tls-announce] Mbed TLS: Security Advisory and Release of Mbed TLS 2.23.0, 2.16.7 and 2.7.16

by Janos Follath via Mbed-tls-announce

An Mbed TLS Security Advisory has been issued to accompany the release of Mbed TLS versions 2.23.0, 2.16.7 and 2.7.16, which have just been released. 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 Mbed TLS 2.23.0<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.23.0>, Mbed TLS 2.16.7<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.7>, Mbed TLS 2.7.16<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.7.16> and in the 2020-07 security advisory<https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi…>. We recommend all users to consider whether they are impacted, and to upgrade appropriately. -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

5 years, 11 months

1
0
0 0

[Mbed-tls-announce] Welcome to Mbed TLS Announce @ TrustedFirmware.org

by Janos Follath via Mbed-tls-announce

Welcome to the Mbed TLS Announcement list @ TrustedFirmware.org! This mailing list is the primary channel for announcements about upcoming Mbed TLS releases and security advisories. This mailing list includes all members of the higher traffic developer mailing list<https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls>. Therefore all announcements will also appear on the developer mailing list and there is no need to subscribe to both. Thanks and regards Janos (on behalf of the Mbed TLS maintainer 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 https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

5 years, 11 months

1
0
0 0

New TrustedFirmware.org security incident process is now live

by Dan Handley

Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

5 years, 12 months

1
0
0 0

Re: [mbed-tls] Choosing a cipher

by Gilles Peskine

The TLS protocol has many options. A TLS connection starts with a handshake whose role is mostly for the client and the server to agree on these options. The ciphersuite is one of these options. It determines which cryptographic primitives will be used for the various security properties (data confidentiality, data integrity, server authentication, etc.). A ciphersuite mismatch, or more generally a mismatch of some option of the protocol, or a certificate mismatch, would normally result in the dissatisfied party closing the connection. For a ciphersuite mismatch, the server should send an alert "handshake failure". For a certificate mismatch, there are several alerts ("bad certificate", "certificate expired", etc.). The first tool to turn to when debugging a TLS connection is Wireshark. Compare a failing connection with a successful connection with similar settings (preferably to the same server). Keep in mind that there can be many legitimate differences, so the first difference might not be the source of the problem. You can try connecting with programs/ssl/ssl_client2 from the mbedtls source tree with different sets of options. For some background on how a TLS connection should work, I suggest starting with Wikipedia, then https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work and https://tls.ulfheim.net/ (The Illustrated TLS Connection — note that while it's a very good explanation, it's for a specific choice of ciphersuite and other options). -- Gilles Peskine Mbed TLS developer On 29/06/2020 03:02, Thompson, Jeff via mbed-tls wrote: > Another baby step in discovering what's happening. The last message > from the server tells the client to change ciphersuites. I don't even > know what a ciohersuite actually is—something like RSA, AES, or > DES?—never mind how to change mine, though I have seen the list; my, > what a lot of conditionals it has. > > So, am I still dealing with a certificate issue? Where do I go from here? > > Get Outlook for Android <https://aka.ms/ghei36> > > ------------------------------------------------------------------------ > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of Thompson, Jeff via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Sent:* Friday, June 26, 2020 12:52:27 PM > *To:* mbed-tls(a)lists.trustedfirmware.org > <mbed-tls(a)lists.trustedfirmware.org> > *Subject:* Re: [mbed-tls] Choosing a cipher > > > A little progress. I figured out where—ssl_encrypt_buf() in > ssl_tls.c—to output the name of the offending ciphersuite, which is > included in all 3 of the preconfigure Google Cloud SSL policies. > > > > So what’s going on here? Why should the mbedTLS client wait forever > for 5 bytes it will never get, stalling the connection, instead timing > out or otherwise detecting an error it could return? > > > > I’m totally at a loss for what to do with this, other than looking for > a commercially supported alternative, which I don’t think would be > received very well by my manager. > > > > *Jeff Thompson* | Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com > > > > *From:* Thompson, Jeff > *Sent:* Friday, June 26, 2020 09:40 > *To:* mbed-tls(a)lists.trustedfirmware.org > *Subject:* Choosing a cipher > > > > The TLS handshake between my device and ghs.googlehosted.com gets > stalled when the server sends the device a Change Cipher Spec > message—the device waits forever, wanting 5 more bytes. From what I > Google’d, I need to change the cipher suite I’m using. How do I know > which cipher the server doesn’t like (so I can avoid that in future), > and which one I should be using—there are scores of these available in > the config file, though some of them clearly should not be used, as > they are commented that way.. > > > > *Jeff Thompson* | Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com > > > >

5 years, 12 months

1
0
0 0

Re: [mbed-tls] Choosing a cipher

by Janos Follath

Hi Jeff, There is a specification document for the TLS 1.2 handshake (RFC 5246: https://tools.ietf.org/html/rfc5246) that I think might help finding out what is going on. There is a graph depicting the handshake on page 37 which I think can be particularly useful. Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Thompson, Jeff via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Thompson, Jeff" <JeffThompson(a)invue.com> Date: Monday, 29 June 2020 at 02:02 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Choosing a cipher Another baby step in discovering what's happening. The last message from the server tells the client to change ciphersuites. I don't even know what a ciohersuite actually is—something like RSA, AES, or DES?—never mind how to change mine, though I have seen the list; my, what a lot of conditionals it has. So, am I still dealing with a certificate issue? Where do I go from here? Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Thompson, Jeff via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, June 26, 2020 12:52:27 PM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Choosing a cipher A little progress. I figured out where—ssl_encrypt_buf() in ssl_tls.c—to output the name of the offending ciphersuite, which is included in all 3 of the preconfigure Google Cloud SSL policies. So what’s going on here? Why should the mbedTLS client wait forever for 5 bytes it will never get, stalling the connection, instead timing out or otherwise detecting an error it could return? I’m totally at a loss for what to do with this, other than looking for a commercially supported alternative, which I don’t think would be received very well by my manager. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64DFD.447A03C0] From: Thompson, Jeff Sent: Friday, June 26, 2020 09:40 To: mbed-tls(a)lists.trustedfirmware.org Subject: Choosing a cipher The TLS handshake between my device and ghs.googlehosted.com gets stalled when the server sends the device a Change Cipher Spec message—the device waits forever, wanting 5 more bytes. From what I Google’d, I need to change the cipher suite I’m using. How do I know which cipher the server doesn’t like (so I can avoid that in future), and which one I should be using—there are scores of these available in the config file, though some of them clearly should not be used, as they are commented that way.. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64DFD.447A03C0]

5 years, 12 months

1
0
0 0

Re: [mbed-tls] Choosing a cipher

by Thompson, Jeff

Another baby step in discovering what's happening. The last message from the server tells the client to change ciphersuites. I don't even know what a ciohersuite actually is—something like RSA, AES, or DES?—never mind how to change mine, though I have seen the list; my, what a lot of conditionals it has. So, am I still dealing with a certificate issue? Where do I go from here? Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Thompson, Jeff via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, June 26, 2020 12:52:27 PM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Choosing a cipher A little progress. I figured out where—ssl_encrypt_buf() in ssl_tls.c—to output the name of the offending ciphersuite, which is included in all 3 of the preconfigure Google Cloud SSL policies. So what’s going on here? Why should the mbedTLS client wait forever for 5 bytes it will never get, stalling the connection, instead timing out or otherwise detecting an error it could return? I’m totally at a loss for what to do with this, other than looking for a commercially supported alternative, which I don’t think would be received very well by my manager. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64BB6.03781220] From: Thompson, Jeff Sent: Friday, June 26, 2020 09:40 To: mbed-tls(a)lists.trustedfirmware.org Subject: Choosing a cipher The TLS handshake between my device and ghs.googlehosted.com gets stalled when the server sends the device a Change Cipher Spec message—the device waits forever, wanting 5 more bytes. From what I Google’d, I need to change the cipher suite I’m using. How do I know which cipher the server doesn’t like (so I can avoid that in future), and which one I should be using—there are scores of these available in the config file, though some of them clearly should not be used, as they are commented that way.. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64BB6.03781220]

5 years, 12 months

1
0
0 0

Choosing a cipher

by Thompson, Jeff

The TLS handshake between my device and ghs.googlehosted.com gets stalled when the server sends the device a Change Cipher Spec message-the device waits forever, wanting 5 more bytes. From what I Google'd, I need to change the cipher suite I'm using. How do I know which cipher the server doesn't like (so I can avoid that in future), and which one I should be using-there are scores of these available in the config file, though some of them clearly should not be used, as they are commented that way.. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64B9D.863E3220]

5 years, 12 months

1
1
0 0

SSL/TLS Handshake Failure

by Thompson, Jeff

Much thanks to Manuel and Gilles for helping me get this far! I'm trying to connect to endpoint hosted by Google for IoT devices. The handshake appears to progress through certificate verification and key exchange, encrypts a payload and then times out waiting for 5 expected bytes. I've attached the last part of the mbedTLS output generated with DEBUG_LEVEL 5 (the entrie thing is too big to include here). I'm sure the problem is either my code, network configuration, or somewhere else on my end. Can anyone give me a clue as to what might be wrong? The starting point for attempting the connection is https_client_tls_xchg(), found in the attached snippet from the example httpsclient.c file as I've modified it. FWIW, I'm using mbedTLS 2.13.1 running on an MIMXRT1062DVJ6A with MCUXpresso SDK 2.6.2. My HTTPS client is based on NXPs example project lwip_httpscli_mbedtls_freertos. Thanks, Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64AE1.D6CB8F10]

6 years

1
0
0 0

Re: [mbed-tls] Working with a PEM file

by Gilles Peskine

[I assume you meant to reply to the list.] If you don't have a filesystem, call mbedtls_x509_crt_parse instead of mbedtls_x509_crt_parse_file. To save static data size, you may want to store the data in binary form instead of base64. To do this: 1. Split the PEM file into individual certificates. 2. Convert each file to DER (you can use programs/util/pem2der, but you need to split the file first, because it only converts the first PEM chunk). 3. Convert each binary file to a C unsigned char array literal. 4. In your code, call mbedtls_x509_crt_parse_der in a loop over the array. Your code might look something like this: const uint8_t cert1_der[] = {0x30, …}; const uint8_t cert2_der[] = {0x30, …}; … const struct {const uint8_t *data; size_t size;} root_certs_der = { {cert1_der, sizeof(cert1_der)}, … }; … mbedtls_x509_crt roots; mbedtls_x509_crt_init(&roots); for (i = 0; i < sizeof(root_certs_der)/sizeof(root_certs_der[0]); i++) mbedtls_x509_crt_parse_der(&roots, root_certs_der[i].data, root_certs_der[i].size); Best regards, -- Gilles Peskine Mbed TLS developer On 23/06/2020 23:31, Thompson, Jeff wrote: > I did see that function, but it assumes a file system, doesn't it? I'm not using one, and that would be a really big change to make this late in the development cycle, if I can avoid it. I can program the PEM file into flash memory, where it can be addressed, for reading only, just like ROM. Is there a way to use it like that? > > Jeff Thompson | Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Gilles Peskine via mbed-tls > Sent: Tuesday, June 23, 2020 4:38 PM > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] Working with a PEM file > > Hi Jeff, > > Don't modify or use the certificates in certs.c. The certificates in the certs module are only intended for testing and they will be moved from the library to the test code soon. They are never used automatically and should never be used outside of tests. > > The easiest way to set these root certificates is to pass the file to mbedtls_x509_crt_parse_file(). This gives you an object that represents the certificates and you can use those as the trusted CAs for certificate verification through the X.509 or TLS API. > > Your code might look like this (error checking and rest of the code > omitted): > > mbedtls_x509_crt roots; // head of the list of trusted CAs mbedtls_x509_crt_init(&roots); mbedtls_x509_crt_parse_file(&roots, "roots.pem"); … // Verify that there is a chain of trust from a certificate to one of the trusted CAs mbedtls_x509_crt_verify(&crt_to_verify, &roots, NULL, NULL, &flags, NULL, NULL); … // Use the trusted CAs for a TLS connection mbedtls_ssl_conf_ca_chain(&ssl_config, roots, NULL); … // Once the certificates are no longer used anywhere mbedtls_x509_crt_free(&roots); > > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > On 23/06/2020 21:38, Thompson, Jeff via mbed-tls wrote: >> I’ve downloaded https://pki.goog/roots.pem and want to use the >> certificates in it with mbedTLS. Is there some documentation that >> tells me how to do this? >> >> >> >> The certs.c file only contains only a handful of certs, while the PEM >> file has nearly 40. How do I know which one to use for what purpose? >> The certs.c file has these certificate char[]’s: >> >> >> >> mbedtls_test_ca_crt_ec >> >> mbedtls_test_srv_crt_ec >> >> mbedtls_test_cli_crt_ec >> >> mbedtls_test_ca_crt_rsa >> >> mbedtls_test_ca_crt_rsa >> >> mbedtls_test_srv_crt_rsa >> >> mbedtls_test_cli_crt_rsa >> >> >> >> I’m reasonably sure I don’t need to replace mbedtls_test_cli_crt_ec >> and mbedtls_test_cli_crt_rsa, since I am not using a client >> certificate. But I’m not at all sure about whether I need to replace >> the 3 **_ca_crt_** certs, the 2 **_srv_crt_** certs, or all 5. And, if >> so, using which certs from the PEM file to replace which certs in >> certs.c?. How do I figure out what to do here? I’ve never dealt with >> cloud communication like this before, so please pardon my ignorance; >> I’m eager to learn, but overwhelmed by so much that is new to me. >> >> >> >> Thanks, >> >> >> >> *Jeff Thompson* | Senior Electrical Engineer-Firmware >> +1 704 752 6513 x1394 >> www.invue.com >> >> >> >> > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

6 years

1
0
0 0

Re: [mbed-tls] Working with a PEM file

by Gilles Peskine

Hi Jeff, Don't modify or use the certificates in certs.c. The certificates in the certs module are only intended for testing and they will be moved from the library to the test code soon. They are never used automatically and should never be used outside of tests. The easiest way to set these root certificates is to pass the file to mbedtls_x509_crt_parse_file(). This gives you an object that represents the certificates and you can use those as the trusted CAs for certificate verification through the X.509 or TLS API. Your code might look like this (error checking and rest of the code omitted): mbedtls_x509_crt roots; // head of the list of trusted CAs mbedtls_x509_crt_init(&roots); mbedtls_x509_crt_parse_file(&roots, "roots.pem"); … // Verify that there is a chain of trust from a certificate to one of the trusted CAs mbedtls_x509_crt_verify(&crt_to_verify, &roots, NULL, NULL, &flags, NULL, NULL); … // Use the trusted CAs for a TLS connection mbedtls_ssl_conf_ca_chain(&ssl_config, roots, NULL); … // Once the certificates are no longer used anywhere mbedtls_x509_crt_free(&roots); Best regards, -- Gilles Peskine Mbed TLS developer On 23/06/2020 21:38, Thompson, Jeff via mbed-tls wrote: > > I’ve downloaded https://pki.goog/roots.pem and want to use the > certificates in it with mbedTLS. Is there some documentation that > tells me how to do this? > > > > The certs.c file only contains only a handful of certs, while the PEM > file has nearly 40. How do I know which one to use for what purpose? > The certs.c file has these certificate char[]’s: > > > > mbedtls_test_ca_crt_ec > > mbedtls_test_srv_crt_ec > > mbedtls_test_cli_crt_ec > > mbedtls_test_ca_crt_rsa > > mbedtls_test_ca_crt_rsa > > mbedtls_test_srv_crt_rsa > > mbedtls_test_cli_crt_rsa > > > > I’m reasonably sure I don’t need to replace mbedtls_test_cli_crt_ec > and mbedtls_test_cli_crt_rsa, since I am not using a client > certificate. But I’m not at all sure about whether I need to replace > the 3 **_ca_crt_** certs, the 2 **_srv_crt_** certs, or all 5. And, if > so, using which certs from the PEM file to replace which certs in > certs.c?. How do I figure out what to do here? I’ve never dealt with > cloud communication like this before, so please pardon my ignorance; > I’m eager to learn, but overwhelmed by so much that is new to me. > > > > Thanks, > > > > *Jeff Thompson* | Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com > > > >

6 years

1
0
0 0

Working with a PEM file

by Thompson, Jeff

I've downloaded https://pki.goog/roots.pem and want to use the certificates in it with mbedTLS. Is there some documentation that tells me how to do this? The certs.c file only contains only a handful of certs, while the PEM file has nearly 40. How do I know which one to use for what purpose? The certs.c file has these certificate char[]'s: mbedtls_test_ca_crt_ec mbedtls_test_srv_crt_ec mbedtls_test_cli_crt_ec mbedtls_test_ca_crt_rsa mbedtls_test_ca_crt_rsa mbedtls_test_srv_crt_rsa mbedtls_test_cli_crt_rsa I'm reasonably sure I don't need to replace mbedtls_test_cli_crt_ec and mbedtls_test_cli_crt_rsa, since I am not using a client certificate. But I'm not at all sure about whether I need to replace the 3 *_ca_crt_* certs, the 2 *_srv_crt_* certs, or all 5. And, if so, using which certs from the PEM file to replace which certs in certs.c?. How do I figure out what to do here? I've never dealt with cloud communication like this before, so please pardon my ignorance; I'm eager to learn, but overwhelmed by so much that is new to me. Thanks, Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64974.02162CD0]

6 years

1
0
0 0

Re: [mbed-tls] Using mbed without a client certificate

by Manuel Pegourie-Gonnard

Hi Jeff, if you don't want to provision a client certificate in your TLS client, all you have to do is to not call `mbedtls_ssl_conf_own_cert()` in your client code. Then the library will send an empty certificate list as required by the standard. Actually in the example code you have, if you look at the second and third argument in the call to `mbedtls_ssl_conf_own_cert()`, you should be able to remove all references to those arguments, and end up with a functional example without client certificates. Also, you might want to have a look at this example from our source, which is a simple client without client-side certificates: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client… Hope that helps, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Thompson, Jeff via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 22 June 2020 16:03 To: 'mbed-tls(a)lists.trustedfirmware.org' <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Using mbed without a client certificate I'm usiing: #define MBEDTLS_VERSION_NUMBER 0x020D0100 #define MBEDTLS_VERSION_STRING "2.13.1" #define MBEDTLS_VERSION_STRING_FULL "mbed TLS 2.13.1" According to RFC5246: If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. How do I do this with mbedTLS? The example code I have has certificates in it and calls mbedtls_x509_crt_parse(), which wants a list of certificates and will reject a zero-length list. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64864.692FAD30]

6 years

2
1
0 0

Re: [mbed-tls] BLE and Mbed TLS

by Janos Follath

Hi, The packet size limitations can be accommodated by using the Maximum Fragment Length extension (https://tools.ietf.org/html/rfc6066#section-4, enabled by MBEDTLS_SSL_MAX_FRAGMENT_LENGTH in Mbed TLS). In Mbed TLS this is only implemented for application data and DTLS handshake messages so far, and therefore you will need to use DTLS. Also the negotiation is driven by the client and it needs to be enabled both on the server and on the client. (See the documentation of mbedtls_ssl_conf_max_frag_len() for more details.) I hope that helps, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Fatima, Fariya via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Fatima, Fariya" <Fariya.Fatima(a)Carrier.com> Date: Tuesday, 23 June 2020 at 11:47 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] BLE and Mbed TLS Hi, Can anyone help if mbedTLS TLS/DTLS code would work on top of BLE (specifically SPP). I am not sure if the packet size limitation on SPP would make TLS work.. any pointers anyone? Would be really helpful. Regards, Fariya From: Fatima, Fariya Sent: Monday, June 15, 2020 9:21 AM To: 'mbed-tls(a)lists.trustedfirmware.org' <mbed-tls(a)lists.trustedfirmware.org> Subject: BLE and Mbed TLS Hi, I wanted to use TLS over BLE application. When I googled, I figured out that MbedTLS can work on BLE. If someone can share a sample application where-in MbedTLS APIs are used as part of a BT/BLE application, it will be of great help. Regards, Fariya

6 years

2
2
0 0

Re: [mbed-tls] BLE and Mbed TLS

by Fatima, Fariya

Hi, Can anyone help if mbedTLS TLS/DTLS code would work on top of BLE (specifically SPP). I am not sure if the packet size limitation on SPP would make TLS work.. any pointers anyone? Would be really helpful. Regards, Fariya From: Fatima, Fariya Sent: Monday, June 15, 2020 9:21 AM To: 'mbed-tls(a)lists.trustedfirmware.org' <mbed-tls(a)lists.trustedfirmware.org> Subject: BLE and Mbed TLS Hi, I wanted to use TLS over BLE application. When I googled, I figured out that MbedTLS can work on BLE. If someone can share a sample application where-in MbedTLS APIs are used as part of a BT/BLE application, it will be of great help. Regards, Fariya

6 years

1
0
0 0

Re: [mbed-tls] ECDH set custom private key

by Manuel Pegourie-Gonnard

Hi Oleksandr, I understand you want to validate your implementation against the test vectors in the cited reference. It's obvious, but just in case my reply is read out of context some day, I want to emphasize: what I'm recommending below is for testing purposes only, importing a private key from a public reference must never be done in production. In your situation the simplest way to proceed is probably to directly import the private and public key from the test vector to your ECDH context. For example (assuming the data in the reference is big-endian, and omitting error checking for brevity): static unsigned char private_a[32] = { 0x3f, 0x49, /* ... from the reference */ }; static unsigned char public_a[65] = { 0x04, /* this special value marks the start of an uncompressed public key */ 0x20, 0xb0, /* ... (public A(x) from the reference) */ 0xdc, 0x80, /* ... (public B(x) from the reference) */ }; static mbedtls_ecdh_context ctx_a; mbedtls_ecdh_init(&ctx_a); /* load the private/public key pair * this replaces mbedtls_ecdh_gen_public() */ mbedtls_mpi_read_binary( &ctx_a->d, private_a, sizeof( private_a ) ); /* should check errors! */ mbedtls_ecp_point_read_binary( &ctx_a->Q, public_a, sizeof( public_a ) ); /* should check errors! */ Doing the same with ctx_b and then exchanging public keys and computing the shared secret as usual, you should obtain values that match the reference. Again, this is only for validating against known test vectors. Importing a private key from a public reference must never be done in production. Hope that helps, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Oleksandr Nychyporuk via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 22 June 2020 15:33 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] ECDH set custom private key Hi, I wanna configure the ECDH algorithm to repeat the following keys: [image.png] I was able to configure the algorithm, generate private and public keys on both: client and server sides. And it works as expected. The secret keys are equal on both sides. But I did not manage to calculate the secret key that is on the picture. I do not know how to set these private keys. Could someone help me to do that? Thanks,

6 years

1
0
0 0

Using mbed without a client certificate

by Thompson, Jeff

I'm usiing: #define MBEDTLS_VERSION_NUMBER 0x020D0100 #define MBEDTLS_VERSION_STRING "2.13.1" #define MBEDTLS_VERSION_STRING_FULL "mbed TLS 2.13.1" According to RFC5246: If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. How do I do this with mbedTLS? The example code I have has certificates in it and calls mbedtls_x509_crt_parse(), which wants a list of certificates and will reject a zero-length list. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64864.692FAD30]

6 years

1
0
0 0

Re: [mbed-tls] mbed-tls Digest, Vol 4, Issue 15

by Oleksandr Nychyporuk

Attaching the keys from the picture: *7.1.2.1 P-256 Data Set 1* *Private A*: 3f49f6d4 a3c55f38 74c9b3e3 d2103f50 4aff607b eb40b799 5899b8a6 cd3c1abd *Private B*: 55188b3d 32f6bb9a 900afcfb eed4e72a 59cb9ac2 f19d7cfb 6b4fdd49 f47fc5fd *Public A(x):* 20b003d2 f297be2c 5e2c83a7 e9f9a5b9 eff49111 acf4fddb cc030148 0e359de6 *Public A(y)*: dc809c49 652aeb6d 63329abf 5a52155c 766345c2 8fed3024 741c8ed0 1589d28b *Public B(x)*: 1ea1f0f0 1faf1d96 09592284 f19e4c00 47b58afd 8615a69f 559077b2 2faaa190 *Public B(y)*: 4c55f33e 429dad37 7356703a 9ab85160 472d1130 e28e3676 5f89aff9 15b1214a *DHKey*: ec0234a3 57c8ad05 341010a6 0a397d9b 99796b13 b4f866f1 868d34f3 73bfa698 пн, 22 черв. 2020 о 16:33 <mbed-tls-request(a)lists.trustedfirmware.org> пише: > 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. ECDH set custom private key (Oleksandr Nychyporuk) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Jun 2020 16:33:15 +0300 > From: Oleksandr Nychyporuk <olexandr.nychyporuk(a)gmail.com> > To: mbed-tls(a)lists.trustedfirmware.org > Subject: [mbed-tls] ECDH set custom private key > Message-ID: > <CAAjyQQ4kQ8J-iVSV_yputKD83G9Aj65fYEWJ= > ObPTeptXogghw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I wanna configure the ECDH algorithm to repeat the following keys: > [image: image.png] > > I was able to configure the algorithm, generate private and public keys on > both: client and server sides. And it works as expected. The secret keys > are equal on both sides. > But I did not manage to calculate the secret key that is on the picture. I > do not know how to set these private keys. Could someone help me to do > that? > > Thanks, >

6 years

1
0
0 0

ECDH set custom private key

by Oleksandr Nychyporuk

Hi, I wanna configure the ECDH algorithm to repeat the following keys: [image: image.png] I was able to configure the algorithm, generate private and public keys on both: client and server sides. And it works as expected. The secret keys are equal on both sides. But I did not manage to calculate the secret key that is on the picture. I do not know how to set these private keys. Could someone help me to do that? Thanks,

6 years

1
0
0 0

Re: [mbed-tls] How to enable mbedtls complete debug logs?

by Srinivasa Rao Ragolu

Hi Hannes, See the output of ssl_client2 output with command line arguments Could you please help me in resolving the issue. Same source code on Ubuntu is working fine but not working on my embedded device(STM32MP157x-EV1) Your support is appreciated. =450a-certificate.pem.crt key_file=/certs/774a17950a-private.pem.key debug_leve . Seeding the random number generator... ok . Loading the CA root certificate ... ok (0 skipped) . Loading the client cert. and key... ok . Connecting to tcp/a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443... ok . Setting up the SSL/TLS structure...ssl_tls.c:0081: |3| set_timer to 0 ms ok . Performing the SSL/TLS handshake...ssl_tls.c:8084: |2| => handshake ssl_cli.c:3510: |2| client state: 0 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:3510: |2| client state: 1 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:0774: |2| => write client hello ssl_cli.c:0812: |3| client hello, max version: [3:3] ssl_cli.c:0703: |3| client hello, current time: 1592572806 ssl_cli.c:0821: |3| dumping 'client hello, random bytes' (32 bytes) ssl_cli.c:0821: |3| 0000: 5e ec bb 86 f1 65 15 c9 27 e1 12 b3 af 40 7d ab ^....e..'....@}. ssl_cli.c:0821: |3| 0010: 16 2e 28 f5 f6 e1 82 9b 2d 5c e7 93 e1 e6 e8 17 ..(.....-\...... ssl_cli.c:0874: |3| client hello, session id len.: 0 ssl_cli.c:0875: |3| dumping 'client hello, session id' (0 bytes) ssl_cli.c:0922: |3| client hello, add ciphersuite: cca8 ssl_cli.c:0922: |3| client hello, add ciphersuite: cca9 ssl_cli.c:0922: |3| client hello, add ciphersuite: ccaa ssl_cli.c:0922: |3| client hello, add ciphersuite: c02c ssl_cli.c:0922: |3| client hello, add ciphersuite: c030 ssl_cli.c:0922: |3| client hello, add ciphersuite: 009f ssl_cli.c:0922: |3| client hello, add ciphersuite: c0ad ssl_cli.c:0922: |3| client hello, add ciphersuite: c09f ssl_cli.c:0922: |3| client hello, add ciphersuite: c024 ssl_cli.c:0922: |3| client hello, add ciphersuite: c028 ssl_cli.c:0922: |3| client hello, add ciphersuite: 006b ssl_cli.c:0922: |3| client hello, add ciphersuite: c00a ssl_cli.c:0922: |3| client hello, add ciphersuite: c014 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0039 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0af ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a3 ssl_cli.c:0922: |3| client hello, add ciphersuite: c087 ssl_cli.c:0922: |3| client hello, add ciphersuite: c08b ssl_cli.c:0922: |3| client hello, add ciphersuite: c07d ssl_cli.c:0922: |3| client hello, add ciphersuite: c073 ssl_cli.c:0922: |3| client hello, add ciphersuite: c077 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00c4 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0088 ssl_cli.c:0922: |3| client hello, add ciphersuite: c02b ssl_cli.c:0922: |3| client hello, add ciphersuite: c02f ssl_cli.c:0922: |3| client hello, add ciphersuite: 009e ssl_cli.c:0922: |3| client hello, add ciphersuite: c0ac ssl_cli.c:0922: |3| client hello, add ciphersuite: c09e ssl_cli.c:0922: |3| client hello, add ciphersuite: c023 ssl_cli.c:0922: |3| client hello, add ciphersuite: c027 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0067 ssl_cli.c:0922: |3| client hello, add ciphersuite: c009 ssl_cli.c:0922: |3| client hello, add ciphersuite: c013 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0033 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0ae ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a2 ssl_cli.c:0922: |3| client hello, add ciphersuite: c086 ssl_cli.c:0922: |3| client hello, add ciphersuite: c08a ssl_cli.c:0922: |3| client hello, add ciphersuite: c07c ssl_cli.c:0922: |3| client hello, add ciphersuite: c072 ssl_cli.c:0922: |3| client hello, add ciphersuite: c076 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00be ssl_cli.c:0922: |3| client hello, add ciphersuite: 0045 ssl_cli.c:0922: |3| client hello, add ciphersuite: ccac ssl_cli.c:0922: |3| client hello, add ciphersuite: ccad ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ab ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a7 ssl_cli.c:0922: |3| client hello, add ciphersuite: c038 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00b3 ssl_cli.c:0922: |3| client hello, add ciphersuite: c036 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0091 ssl_cli.c:0922: |3| client hello, add ciphersuite: c091 ssl_cli.c:0922: |3| client hello, add ciphersuite: c09b ssl_cli.c:0922: |3| client hello, add ciphersuite: c097 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0ab ssl_cli.c:0922: |3| client hello, add ciphersuite: 00aa ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a6 ssl_cli.c:0922: |3| client hello, add ciphersuite: c037 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00b2 ssl_cli.c:0922: |3| client hello, add ciphersuite: c035 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0090 ssl_cli.c:0922: |3| client hello, add ciphersuite: c090 ssl_cli.c:0922: |3| client hello, add ciphersuite: c096 ssl_cli.c:0922: |3| client hello, add ciphersuite: c09a ssl_cli.c:0922: |3| client hello, add ciphersuite: c0aa ssl_cli.c:0922: |3| client hello, add ciphersuite: 009d ssl_cli.c:0922: |3| client hello, add ciphersuite: c09d ssl_cli.c:0922: |3| client hello, add ciphersuite: 003d ssl_cli.c:0922: |3| client hello, add ciphersuite: 0035 ssl_cli.c:0922: |3| client hello, add ciphersuite: c032 ssl_cli.c:0922: |3| client hello, add ciphersuite: c02a ssl_cli.c:0922: |3| client hello, add ciphersuite: c00f ssl_cli.c:0922: |3| client hello, add ciphersuite: c02e ssl_cli.c:0922: |3| client hello, add ciphersuite: c026 ssl_cli.c:0922: |3| client hello, add ciphersuite: c005 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a1 ssl_cli.c:0922: |3| client hello, add ciphersuite: c07b ssl_cli.c:0922: |3| client hello, add ciphersuite: 00c0 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0084 ssl_cli.c:0922: |3| client hello, add ciphersuite: c08d ssl_cli.c:0922: |3| client hello, add ciphersuite: c079 ssl_cli.c:0922: |3| client hello, add ciphersuite: c089 ssl_cli.c:0922: |3| client hello, add ciphersuite: c075 ssl_cli.c:0922: |3| client hello, add ciphersuite: 009c ssl_cli.c:0922: |3| client hello, add ciphersuite: c09c ssl_cli.c:0922: |3| client hello, add ciphersuite: 003c ssl_cli.c:0922: |3| client hello, add ciphersuite: 002f ssl_cli.c:0922: |3| client hello, add ciphersuite: c031 ssl_cli.c:0922: |3| client hello, add ciphersuite: c029 ssl_cli.c:0922: |3| client hello, add ciphersuite: c00e ssl_cli.c:0922: |3| client hello, add ciphersuite: c02d ssl_cli.c:0922: |3| client hello, add ciphersuite: c025 ssl_cli.c:0922: |3| client hello, add ciphersuite: c004 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a0 ssl_cli.c:0922: |3| client hello, add ciphersuite: c07a ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ba ssl_cli.c:0922: |3| client hello, add ciphersuite: 0041 ssl_cli.c:0922: |3| client hello, add ciphersuite: c08c ssl_cli.c:0922: |3| client hello, add ciphersuite: c078 ssl_cli.c:0922: |3| client hello, add ciphersuite: c088 ssl_cli.c:0922: |3| client hello, add ciphersuite: c074 ssl_cli.c:0922: |3| client hello, add ciphersuite: ccae ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ad ssl_cli.c:0922: |3| client hello, add ciphersuite: 00b7 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0095 ssl_cli.c:0922: |3| client hello, add ciphersuite: c093 ssl_cli.c:0922: |3| client hello, add ciphersuite: c099 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ac ssl_cli.c:0922: |3| client hello, add ciphersuite: 00b6 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0094 ssl_cli.c:0922: |3| client hello, add ciphersuite: c092 ssl_cli.c:0922: |3| client hello, add ciphersuite: c098 ssl_cli.c:0922: |3| client hello, add ciphersuite: ccab ssl_cli.c:0922: |3| client hello, add ciphersuite: 00a9 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a5 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00af ssl_cli.c:0922: |3| client hello, add ciphersuite: 008d ssl_cli.c:0922: |3| client hello, add ciphersuite: c08f ssl_cli.c:0922: |3| client hello, add ciphersuite: c095 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a9 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00a8 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a4 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ae ssl_cli.c:0922: |3| client hello, add ciphersuite: 008c ssl_cli.c:0922: |3| client hello, add ciphersuite: c08e ssl_cli.c:0922: |3| client hello, add ciphersuite: c094 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a8 ssl_cli.c:0934: |3| client hello, got 127 ciphersuites (excluding SCSVs) ssl_cli.c:0943: |3| adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_cli.c:0992: |3| client hello, compress len.: 1 ssl_cli.c:0994: |3| client hello, compress alg.: 0 ssl_cli.c:0069: |3| client hello, adding server name extension: a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com ssl_cli.c:0186: |3| client hello, adding signature_algorithms extension ssl_cli.c:0271: |3| client hello, adding supported_elliptic_curves extension ssl_cli.c:0336: |3| client hello, adding supported_point_formats extension ssl_cli.c:0518: |3| client hello, adding encrypt_then_mac extension ssl_cli.c:0552: |3| client hello, adding extended_master_secret extension ssl_cli.c:0585: |3| client hello, adding session ticket extension ssl_cli.c:1071: |3| client hello, total extension length: 128 ssl_tls.c:3184: |2| => write handshake message ssl_tls.c:3343: |2| => write record ssl_tls.c:3423: |3| output record: msgtype = 22, version = [3:1], msglen = 429 ssl_tls.c:3426: |4| dumping 'output record sent to network' (434 bytes) ssl_tls.c:3426: |4| 0000: 16 03 01 01 ad 01 00 01 a9 03 03 5e ec bb 86 f1 ...........^.... ssl_tls.c:3426: |4| 0010: 65 15 c9 27 e1 12 b3 af 40 7d ab 16 2e 28 f5 f6 e..'....@}...(.. ssl_tls.c:3426: |4| 0020: e1 82 9b 2d 5c e7 93 e1 e6 e8 17 00 01 00 cc a8 ...-\........... ssl_tls.c:3426: |4| 0030: cc a9 cc aa c0 2c c0 30 00 9f c0 ad c0 9f c0 24 .....,.0.......$ ssl_tls.c:3426: |4| 0040: c0 28 00 6b c0 0a c0 14 00 39 c0 af c0 a3 c0 87 .(.k.....9...... ssl_tls.c:3426: |4| 0050: c0 8b c0 7d c0 73 c0 77 00 c4 00 88 c0 2b c0 2f ...}.s.w.....+./ ssl_tls.c:3426: |4| 0060: 00 9e c0 ac c0 9e c0 23 c0 27 00 67 c0 09 c0 13 .......#.'.g.... ssl_tls.c:3426: |4| 0070: 00 33 c0 ae c0 a2 c0 86 c0 8a c0 7c c0 72 c0 76 .3.........|.r.v ssl_tls.c:3426: |4| 0080: 00 be 00 45 cc ac cc ad 00 ab c0 a7 c0 38 00 b3 ...E.........8.. ssl_tls.c:3426: |4| 0090: c0 36 00 91 c0 91 c0 9b c0 97 c0 ab 00 aa c0 a6 .6.............. ssl_tls.c:3426: |4| 00a0: c0 37 00 b2 c0 35 00 90 c0 90 c0 96 c0 9a c0 aa .7...5.......... ssl_tls.c:3426: |4| 00b0: 00 9d c0 9d 00 3d 00 35 c0 32 c0 2a c0 0f c0 2e .....=.5.2.*.... ssl_tls.c:3426: |4| 00c0: c0 26 c0 05 c0 a1 c0 7b 00 c0 00 84 c0 8d c0 79 .&.....{.......y ssl_tls.c:3426: |4| 00d0: c0 89 c0 75 00 9c c0 9c 00 3c 00 2f c0 31 c0 29 ...u.....<./.1.) ssl_tls.c:3426: |4| 00e0: c0 0e c0 2d c0 25 c0 04 c0 a0 c0 7a 00 ba 00 41 ...-.%.....z...A ssl_tls.c:3426: |4| 00f0: c0 8c c0 78 c0 88 c0 74 cc ae 00 ad 00 b7 00 95 ...x...t........ ssl_tls.c:3426: |4| 0100: c0 93 c0 99 00 ac 00 b6 00 94 c0 92 c0 98 cc ab ................ ssl_tls.c:3426: |4| 0110: 00 a9 c0 a5 00 af 00 8d c0 8f c0 95 c0 a9 00 a8 ................ ssl_tls.c:3426: |4| 0120: c0 a4 00 ae 00 8c c0 8e c0 94 c0 a8 00 ff 01 00 ................ ssl_tls.c:3426: |4| 0130: 00 80 00 00 00 34 00 32 00 00 2f 61 32 67 37 74 .....4.2../a2g7t ssl_tls.c:3426: |4| 0140: 77 6d 71 6f 37 68 67 38 32 2d 61 74 73 2e 69 6f wmqo7hg82-ats.io ssl_tls.c:3426: |4| 0150: 74 2e 61 70 2d 73 6f 75 74 68 2d 31 2e 61 6d 61 t.ap-south-1.ama ssl_tls.c:3426: |4| 0160: 7a 6f 6e 61 77 73 2e 63 6f 6d 00 0d 00 16 00 14 zonaws.com...... ssl_tls.c:3426: |4| 0170: 06 03 06 01 05 03 05 01 04 03 04 01 03 03 03 01 ................ ssl_tls.c:3426: |4| 0180: 02 03 02 01 00 0a 00 18 00 16 00 19 00 1c 00 18 ................ ssl_tls.c:3426: |4| 0190: 00 1b 00 17 00 16 00 1a 00 15 00 14 00 13 00 12 ................ ssl_tls.c:3426: |4| 01a0: 00 0b 00 02 01 00 00 16 00 00 00 17 00 00 00 23 ...............# ssl_tls.c:3426: |4| 01b0: 00 00 .. ssl_tls.c:2755: |2| => flush output ssl_tls.c:2774: |2| message length: 434, out_left: 434 ssl_tls.c:2779: |2| ssl->f_send() returned 434 (-0xfffffe4e) ssl_tls.c:2807: |2| <= flush output ssl_tls.c:3476: |2| <= write record ssl_tls.c:3320: |2| <= write handshake message ssl_cli.c:1106: |2| <= write client hello ssl_cli.c:3510: |2| client state: 2 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:1499: |2| => parse server hello ssl_tls.c:4311: |2| => read record ssl_tls.c:2536: |2| => fetch input ssl_tls.c:2697: |2| in_left: 0, nb_want: 5 ssl_tls.c:2721: |2| in_left: 0, nb_want: 5 ssl_tls.c:2722: |2| ssl->f_recv(_timeout)() returned -80 (-0x0050) ssl_tls.c:4973: |1| mbedtls_ssl_fetch_input() returned -80 (-0x0050) ssl_tls.c:4344: |1| ssl_get_next_record() returned -80 (-0x0050) ssl_cli.c:1506: |1| mbedtls_ssl_read_record() returned -80 (-0x0050) ssl_tls.c:8094: |2| <= handshake failed ! mbedtls_ssl_handshake returned -0x50 Last error was: -0x50 - NET - Connection was reset by peer ssl_tls.c:8934: |2| => free ssl_tls.c:8999: |2| <= free Regards, Srinivas. [cid:e050759f-7151-4fb6-8259-848135ad05b0] ________________________________ From: Hannes Tschofenig <Hannes.Tschofenig(a)arm.com> Sent: 19 June 2020 18:35 To: Srinivasa Rao Ragolu <srinivasa(a)alifsemi.com> Subject: RE: How to enable mbedtls complete debug logs? Hi Srinivas, Here is a good summary: https://tls.mbed.org/kb/development/debugging-tls If you just run the examples (such as ssl_client2 and ssl_server2) on the command line then you just need to use a command line parameter to set the debug level. Ciao Hannes From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Srinivasa Rao Ragolu via mbed-tls Sent: Friday, June 19, 2020 2:44 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] How to enable mbedtls complete debug logs? Hi All, Please help me with the procedure, how to enable complete debug logs in mbedtls. Regards, Srinivas. [cid:image001.jpg@01D6464B.1CC8C6E0] 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.

6 years

1
0
0 0

How to enable mbedtls complete debug logs?

by Srinivasa Rao Ragolu

Hi All, Please help me with the procedure, how to enable complete debug logs in mbedtls. Regards, Srinivas. [cid:42424919-ffb4-4795-981d-a54ca257f268]

6 years

1
0
0 0

Mutual Authentication in TLS handshake - No client certificate passed

by Abhilash Iyer

Hello, I am trying to incorporate Mutual Authentication TLS in my hardware. For testing the mutual authentication in TLS, I setup a demo service which would request a client certificate in the TLS handshake. I used MS Edge, Google Chrome to test whether the service requests a client certificate during the TLS 1.2 handshake. When I ping the website, I do receive a request for a client certificate as shown in the image below. On selecting a certificate, I am able to access the website. Link to the demo service: https://serviceforsomsecurity.azurewebsites.net/ [A screenshot of a cell phone Description automatically generated] The above validates that the service requires the client to provide the client certificate during the TLS handshake. Now, when I test this with the sample mbedTLS ssl_client2.c program: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client…, the client does not send a certificate at all. The following are the steps that I carry out to test the TLS connection with my service with the sample mbedTLS ssl_client2.exe : 1. Open the mbedTLS.sln and build the ssl_client2 project. This creates a ssl_client2.exe under the Debug folder. 2. ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 The above command to test whether the client sends the client certificate during handshake. Here's the log: [A screenshot of a computer Description automatically generated] As you can see, in 3025 client receives: got no certificate request and then followed by server hello done at 3157. And then at 2080 & 2094, client skips writing certificate; during this handshake. 3. Then I tried including renegotiation flag: ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 renegotiate=1 Even in this case, the client does not get the certificate and abruptly ends during renegotiation due to timeout. I have included both the log files below for complete handshake review. [ssl_client_without_renegotiation.txt and ssl_client_with_renegotiation.txt] Can you please let me know how to debug this client certificate problem? It will be really a great help! Million thanks in advance. Regards, Abhilash

6 years

1
0
0 0

About raising an issue on mbedTLS forum

by Aditya Patwardhan

Hello Sir/Madam, I work in Espressif Systems. I am currently working on providing an alternate hardware RSA sign implementation for mbedtls software sign for Espressif's new chip ESP32S2. I have gone through mbedTLS API in detail but I dont see any option where I can only replace mbedTLS software sign function with our hardware sign function . I have gone through the issue https://tls.mbed.org/discussions/generic/using-an-external-rsa-private-key I have seen that there is a function named `mbedtls_pk_setup_rsa_alt` where we only register private key related function to the ALT_CTX which mbedtls uses to perform RSA sign. but this is not supported for TLS connections. I have seen that there is MBEDTLS_RSA_ALT option in mbedTLS where we can provide alternate function to many of mbedTLS API, but we do not want to change any of the other functions, just provide alternate implementation of hardware sign. If we go with this way, there will be lot of duplicate code which will be needed to be maintained. can mbedTLS provide option to use mbedtls_rsa_alt context in its file `pkparse.c` so as to allow rsa sign using an extrnal private key. Thanks and Regards, Aditya P.S. - I raised the same issue yesterday, my issue was rejected stating I have not subscribed to the mailing-list. But I had already done that. I tried to subscribe again and it also said you are already subscribed.

6 years

1
0
0 0

Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"

by Janos Follath

These defines are needed when the platform doesn’t have standard functions like `calloc()` and `free()`. (You can find more details on the macros in `config.h`.) Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of songwei fu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: "songwei.fu(a)web.de" <songwei.fu(a)web.de> Date: Wednesday, 17 June 2020 at 13:41 To: "Kaul, Martin" <Martin.Kaul(a)leuze.com> Cc: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Thanks Martin. It solved my problem! By adding $(CHIBIOS)/os/various/syscalls.c in the makefile and removing following defines, the linker error is gone. #define MBEDTLS_PLATFORM_C #define MBEDTLS_PLATFORM_MEMORY #define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc #define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree Now I wonder when these defines are needed? I thought I need to port them to the OS-specific memory allocation. like in freeRTOS, it would be "pvPortCalloc", and for chibios it would be chHeapAlloc. Anybody can give me some hint? -- Songwei Gesendet: Mittwoch, 17. Juni 2020 um 12:12 Uhr Von: "Kaul, Martin" <Martin.Kaul(a)leuze.com> An: "songwei.fu(a)web.de" <songwei.fu(a)web.de> Betreff: AW: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Hi, _sbrk is need when you using heap memory, for example using malloc() – see following discussion in stackoverflow: https://stackoverflow.com/questions/32446814/undefined-reference-to-sbrk-in… Maybe that helps. Best regards Martin Von: mbed-tls [mailto:mbed-tls-bounces@lists.trustedfirmware.org] Im Auftrag von songwei fu via mbed-tls Gesendet: Mittwoch, 17. Juni 2020 11:49 An: mbed-tls(a)lists.trustedfirmware.org Betreff: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Hi guys, I am new to the list and also to mbedTLS. Now I am trying to port mbedTLS to chibiOS. And when I called altcp_tls_create_config_client(cert, sizeof(cert)), I got a link error like following: c:/chibistudio/tools/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m\libg.a(lib_a-sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk' And these are my settings: #define MBEDTLS_PLATFORM_C #define MBEDTLS_PLATFORM_MEMORY #define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc #define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree where chHeapAlloc and chHeapFree are the memory allocation functions from chibios. (1) Did I miss some settings? or i did something wrong? (2) I did not find much information about the porting from chibios side. Does anybody know where I can look for reference projects/docs? Any suggestion will be appreciated. Thanks. Songwei

6 years

2
1
0 0

Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"

by songwei.fu＠web.de

6 years

1
0
0 0

Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"

by Janos Follath

Hi Songwei, Welcome to the list and thank you for your interest in Mbed TLS! I found a similar issue on stack overflow: https://stackoverflow.com/questions/28895703/sbrk-function-not-found-when-p… Is this the same issue as yours? Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of songwei fu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: "songwei.fu(a)web.de" <songwei.fu(a)web.de> Date: Wednesday, 17 June 2020 at 10:49 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Hi guys, I am new to the list and also to mbedTLS. Now I am trying to port mbedTLS to chibiOS. And when I called altcp_tls_create_config_client(cert, sizeof(cert)), I got a link error like following: c:/chibistudio/tools/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m\libg.a(lib_a-sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk' And these are my settings: #define MBEDTLS_PLATFORM_C #define MBEDTLS_PLATFORM_MEMORY #define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc #define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree where chHeapAlloc and chHeapFree are the memory allocation functions from chibios. (1) Did I miss some settings? or i did something wrong? (2) I did not find much information about the porting from chibios side. Does anybody know where I can look for reference projects/docs? Any suggestion will be appreciated. Thanks. Songwei

6 years

1
0
0 0

Link error when calling "altcp_tls_create_config_client"

by songwei.fu＠web.de

6 years

1
0
0 0

mbedtls_ssh_handshake error -0X50 when connecting to AWS

by Srinivasa Rao Ragolu

Hi All, I am working on Renesas RZA2M embedded board with Linux. It has limited memory of 6MB flash(R-Only) I am using mbedtls version 2.16.5 for aws iot sdk for embedded c according to https://docs.aws.amazon.com/iot/latest/developerguide/iot-embedded-c-sdk.ht… When I run sample application, it is taking 15 secs for "Seeding random generator number..." and throwing below error $ ./subscribe_publish_sample AWS IoT SDK Version 3.0.1- DEBUG: main L#159 rootCA /root/../certs/AmazonRootCA1.pem DEBUG: main L#160 clientCRT /root/../certs/774a17950a-certificate.pem.crt DEBUG: main L#161 clientKey /root/../certs/774a17950a-private.pem.key Connecting... DEBUG: iot_tls_connect L#130 . Seeding the random number generator... DEBUG: iot_tls_connect L#138 . Loading the CA root certificate ... DEBUG: iot_tls_connect L#144 ok (0 skipped) DEBUG: iot_tls_connect L#146 . Loading the client cert. and key... DEBUG: iot_tls_connect L#159 ok DEBUG: iot_tls_connect L#161 . Connecting to a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443... DEBUG: iot_tls_connect L#180 ok DEBUG: iot_tls_connect L#182 . Setting up the SSL/TLS structure... DEBUG: iot_tls_connect L#223 SSL state connect : 0 DEBUG: iot_tls_connect L#226 ok DEBUG: iot_tls_connect L#228 SSL state connect : 0 DEBUG: iot_tls_connect L#229 . Performing the SSL/TLS handshake... ERROR: iot_tls_connect L#232 failed ! mbedtls_ssl_handshake returned -0x50 ERROR: main L#190 Error(-4) connecting to a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com:443 For detailed debug log using ssl_client2, go through https://pastebin.com/mNXhB0xj<https://github.com/ARMmbed/mbedtls/issues/url> https://pastebin.com/mNXhB0xj my client device specifications $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 1 (v7l) BogoMIPS : 1056.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x4 CPU part : 0xc09 CPU revision : 1 Hardware : Generic R7S9210 (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000 $ free total used free shared buffers cached Mem: 7544 4484 3060 40 0 304 -/+ buffers/cache: 4180 3364 Swap: 0 0 0 I am not getting any help to resolve this issue and spending days and days. I am suspecting the issue might be timing related (or) cpu clock related (or) memory footprint related (or) something else I need this forum help badly to resolve the issue. Please ping me if you need any other data. Thanks in advance, Srinivas. Regards, Srinivas. [cid:1eddf249-06f8-4cbd-a3e2-9c22437fd27f]

6 years

1
0
0 0

BLE and Mbed TLS

by Fatima, Fariya

Hi, I wanted to use TLS over BLE application. When I googled, I figured out that MbedTLS can work on BLE. If someone can share a sample application where-in MbedTLS APIs are used as part of a BT/BLE application, it will be of great help. Regards, Fariya

6 years

1
0
0 0

ASIO and mbed TLS

by Frank Bergmann

Hi, we have an application which uses ASIO. And now we want to add mbed TLS to provide a TLS layer. ASIO can be used with OpenSSL and wolfSSL. But how to do this with mbed TLS? Any hints on that? See also this question at SO: https://stackoverflow.com/questions/61875404/asio-c-with-mbed-tls-library best regards, Frank

6 years

1
0
0 0

DTLS handshake never ends successfully

by Xavier Del Campo Romero

I want to connect an ESP32 to a DTLS server using mbedtls' dtls_server demo. The code I used for the client is very similar to the dtls_client example, but is unable to finish the handshake process for some reason. According to Wireshark, the client is not responding to the "Server hello done" frame, causing a timeout that makes the server to send the certificate again and again until it gives up the connection. The dtls_client demo works correctly on the computer, but not on the ESP32. Has anyone tested DTLS on the ESP32? I have attached the following files for further reference: - dtls_esp32.pcapng: Wireshark file with the DTLS packets between client and server. - mbedtls.tar.bz2: compressed (> 7k lines) plain text log as reported by the board. On line 7131, where the last message from the server is received, it looks like the client never receives the whole message, so it never reaches the "Server hello done" state. Could anyone please confirm this? - dtls.c: client source code. Slightly modified from the dtls_client example. Thank you very much for your help. Xavi

6 years

1
0
0 0

Re: [mbed-tls] Feedback sought on a new PSA Crypto driver interface

by Quach, Brian

Hi, I was reviewing the proposal and had a few questions on usage of the new params. 1) When using plaintext keys, is the "attributes" param unused and should/could it be set to NULL? 2) If using key store (i.e. opaque), is the key ID the only attribute field which needs to be set? My assumption is attributes would be populated from the key store using the key ID? 3) If using key store, are the "key_buffer" and "key_buffer_size" params typically unused (i.e. can be set to null and zero respectively)? I do the proposal says the buffer content is up to the driver. Are there any usage cases in mind? 4) For drivers that support both opaque and transparent operation, which param would be used to determine the mode? (I had assumed key ID = 0 would be transparent, and non-zero is opaque) I'm unclear how persistent_state for opaque driver's is used. Could you elaborate on how it's used by the driver and core and why it isn't needed for transparent drivers? Key management with opaque drivers Transparent drivers may provide the following key management functions: Should this be "Opaque"? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

6 years

1
0
0 0

Re: [mbed-tls] mbedtls_x509write_crt_set_subject_name, mbedtls_x509_dn_gets fail to handle UTF8 multibyte properly

by Martin Man

> On 11 Jun 2020, at 12:09, Gilles Peskine via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> wrote: > > On 11/06/2020 11:24, Martin Man via mbed-tls wrote: >> >> I think this is a bug and the dn_gets should simply leave the UTF-8 >> multibyte untouched when parsing it out from a field tagged with ASN.1 >> tag 12 (utf-8). > > We are not going to do Unicode normalization in Mbed TLS: that would be > far too complex for a library that runs on systems with ~1e5 bytes > available for code. So Unicode strings would only be processed correctly > if the application passes normalized strings and CAs only generate > certificates with normalized strings. But that would be an improvement > on converting non-ASCII characters to '?'. Definitely agree that normalization is not needed. I think this problem could be split into two parts: 1) When a const char* is passed into mbedtls_x509write_crt_set_subject_name, the mbedtls will currently encode it into ASN tag 12 UTF8. Not sure what validation is done. But it could perhaps do at least a basic validation of what the C string passed in is to avoid generating a cert with crippled DN. Alternatively you can simply trust the developer to pass in correct UTF8 and document this. This is a API design decision of what input is allowed to be passed into the method and what validation is done on this. 2) When the mbedtls_x509_dn_gets extracts a C string from the ASN.1 tagged as 12, it could validate that it is indeed valid UTF-8, or just leave it as is and push it out. Again, this is about what we expect the library to do. I’m not an expert on whether this can in any way be used to trick MBEDLTS to do bad things when sending in a malformed certificate, say a one where DN is encoded as UTF-8 but contains illegal UTF-8 in the payload. thanks for listening, Martin

6 years

1
0
0 0

Re: [mbed-tls] mbedtls_x509write_crt_set_subject_name, mbedtls_x509_dn_gets fail to handle UTF8 multibyte properly

by Gilles Peskine

On 11/06/2020 11:24, Martin Man via mbed-tls wrote: > The code in mbedtls_x509_dn_gets fails to properly handle the UTF-8 > multibyte sequence 0xe2 0x80 0x99 and turns it into 0xe2 0x80 0x3f. > > There is a fix floating around development branch mentioned > here https://github.com/ARMmbed/mbedtls/pull/3326/files which > essentially replaces all control chars with question marks. > > I think this is a bug and the dn_gets should simply leave the UTF-8 > multibyte untouched when parsing it out from a field tagged with ASN.1 > tag 12 (utf-8). That code is from an earlier era (mid 2000s, I think) when most systems used an 8-bit encoding, but non-8-bit-clean systems were still common. A '\x80' in text might be transformed to '\x00' with disastrous consequences. But over a decade later, I don't think non-8-bit-clean systems are a concern anymore. Leaving all non-ASCII characters alone sounds reasonable to me. We are not going to do Unicode normalization in Mbed TLS: that would be far too complex for a library that runs on systems with ~1e5 bytes available for code. So Unicode strings would only be processed correctly if the application passes normalized strings and CAs only generate certificates with normalized strings. But that would be an improvement on converting non-ASCII characters to '?'. -- Gilles Peskine Mbed TLS developer

6 years

1
0
0 0

mbedtls_x509write_crt_set_subject_name, mbedtls_x509_dn_gets fail to handle UTF8 multibyte properly

by Martin Man

Hi guys, I’m new to the list and bringing the discussion over here from https://github.com/ARMmbed/mbedtls/issues/3413 <https://github.com/ARMmbed/mbedtls/issues/3413>. I’m creating a certificate using mbedtls and setting it’s issuer and and subject using the mbedtls_x509write_crt_set_subject_name, and mbedtls_x509write_crt_set_issuer_name. The name passed in is in UTF8 and contains a sequence 0xe2 0x80 0x99 (apostrophe) in the CN string. If I debugged this correctly, the underlying sequence of bytes is correctly encoded in ASN.1 and tagged as 12 (UTF-8). When I later parse the cert and try to extract its subject back using mbedtls_x509_dn_gets from crt.subject and crt.issuer the UTF-8 gets corrupted. The code in mbedtls_x509_dn_gets fails to properly handle the UTF-8 multibyte sequence 0xe2 0x80 0x99 and turns it into 0xe2 0x80 0x3f. There is a fix floating around development branch mentioned here https://github.com/ARMmbed/mbedtls/pull/3326/files <https://github.com/ARMmbed/mbedtls/pull/3326/files> which essentially replaces all control chars with question marks. I think this is a bug and the dn_gets should simply leave the UTF-8 multibyte untouched when parsing it out from a field tagged with ASN.1 tag 12 (utf-8). What’s your opinion? Martin

6 years

1
0
0 0

ERROR: mbedtls_ssl_handshake returned -0x50 (with AWS IOT SDK )

by Srinivasa Rao Ragolu

Hi All, I recently started working on mbedtls for AWS IoT SDK based applications. Issue: I am planning to run AWS IoT SDK sample applications on my memory constrained (6MB RAM) embedded hardware Usage: AWS IOT SDK(3.0.1 release version) and mbedtls (2.16.5) Note: This filesystem is Read-Only file system. I have tried on Ubuntu 18.04 setup first to make things clear. It was not working with "AmazonRootCA1.pem" and working perfectly fine with cross-signed "G2-RootCA1.pem". Ref: https://docs.aws.amazon.com/iot/latest/developerguide/iot-embedded-c-sdk.ht… So I have cross-compiled for my target board using ARM toolchain and copied the binary and certificates. I have downloaded device certificate, private key and RootCA from AWS IOT Core to my device. Nothing on my device except copying the above 3 files. On my Embedded platform, whenever run my application, mbedtls is throwing the error "mbedtls_ssl_handshake returned -0x50" So I have enabled the debug in mbedtls library and ran below command to dig into the problem. $ ./ssl_client2 server_name=a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com<http://a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/> serv er_port=443 ca_file=/certs/G2-RootCA1.pem crt_file=/certs/4960bd2f6b-certificate .pem.crt key_file=/certs/4960bd2f6b-private.pem.key Output: $ ./ssl_client2 server_name=a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com<http://a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/> serv er_port=443 ca_file=/certs/G2-RootCA1.pem crt_file=/certs/4960bd2f6b-certificate .pem.crt key_file=/certs/4960bd2f6b-private.pem.key . Seeding the random number generator... ok . Loading the CA root certificate ... ok (0 skipped) . Loading the client cert. and key... ok . Connecting to tcp/a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443.<http://a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443.>.. ok . Setting up the SSL/TLS structure...ssl_tls.c:0081: |3| set_timer to 0 ms ok . Performing the SSL/TLS handshake...ssl_tls.c:8084: |2| => handshake ssl_cli.c:3510: |2| client state: 0 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:3510: |2| client state: 1 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:0774: |2| => write client hello ssl_cli.c:0811: |3| client hello, max version: [3:3] ssl_cli.c:0703: |3| client hello, current time: 1540981791 ssl_cli.c:0821: |3| dumping 'client hello, random bytes' (32 bytes) ssl_cli.c:0821: |3| 0000: 5b d9 84 1f 2f 33 35 54 ea 0b 5d e1 dc 42 0c 99 [.../35T..]..B.. ssl_cli.c:0821: |3| 0010: d4 a1 25 72 6f 0f cf 8e 56 0d ab f5 10 e4 47 46 ..%ro...V.....GF ssl_cli.c:0874: |3| client hello, session id len.: 0 ssl_cli.c:0875: |3| dumping 'client hello, session id' (0 bytes) ssl_cli.c:0921: |3| client hello, add ciphersuite: cca8 ssl_cli.c:0921: |3| client hello, add ciphersuite: cca9 ssl_cli.c:0921: |3| client hello, add ciphersuite: ccaa ssl_cli.c:0921: |3| client hello, add ciphersuite: c02c ssl_cli.c:0921: |3| client hello, add ciphersuite: c030 ssl_cli.c:0921: |3| client hello, add ciphersuite: 009f ssl_cli.c:0921: |3| client hello, add ciphersuite: c0ad ssl_cli.c:0921: |3| client hello, add ciphersuite: c09f ssl_cli.c:0921: |3| client hello, add ciphersuite: c024 ssl_cli.c:0921: |3| client hello, add ciphersuite: c028 ssl_cli.c:0921: |3| client hello, add ciphersuite: 006b ssl_cli.c:0921: |3| client hello, add ciphersuite: c00a ssl_cli.c:0921: |3| client hello, add ciphersuite: c014 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0039 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0af ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a3 ssl_cli.c:0921: |3| client hello, add ciphersuite: c087 ssl_cli.c:0921: |3| client hello, add ciphersuite: c08b ssl_cli.c:0921: |3| client hello, add ciphersuite: c07d ssl_cli.c:0921: |3| client hello, add ciphersuite: c073 ssl_cli.c:0921: |3| client hello, add ciphersuite: c077 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00c4 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0088 ssl_cli.c:0921: |3| client hello, add ciphersuite: c02b ssl_cli.c:0921: |3| client hello, add ciphersuite: c02f ssl_cli.c:0921: |3| client hello, add ciphersuite: 009e ssl_cli.c:0921: |3| client hello, add ciphersuite: c0ac ssl_cli.c:0921: |3| client hello, add ciphersuite: c09e ssl_cli.c:0921: |3| client hello, add ciphersuite: c023 ssl_cli.c:0921: |3| client hello, add ciphersuite: c027 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0067 ssl_cli.c:0921: |3| client hello, add ciphersuite: c009 ssl_cli.c:0921: |3| client hello, add ciphersuite: c013 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0033 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0ae ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a2 ssl_cli.c:0921: |3| client hello, add ciphersuite: c086 ssl_cli.c:0921: |3| client hello, add ciphersuite: c08a ssl_cli.c:0921: |3| client hello, add ciphersuite: c07c ssl_cli.c:0921: |3| client hello, add ciphersuite: c072 ssl_cli.c:0921: |3| client hello, add ciphersuite: c076 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00be ssl_cli.c:0921: |3| client hello, add ciphersuite: 0045 ssl_cli.c:0921: |3| client hello, add ciphersuite: ccac ssl_cli.c:0921: |3| client hello, add ciphersuite: ccad ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ab ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a7 ssl_cli.c:0921: |3| client hello, add ciphersuite: c038 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00b3 ssl_cli.c:0921: |3| client hello, add ciphersuite: c036 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0091 ssl_cli.c:0921: |3| client hello, add ciphersuite: c091 ssl_cli.c:0921: |3| client hello, add ciphersuite: c09b ssl_cli.c:0921: |3| client hello, add ciphersuite: c097 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0ab ssl_cli.c:0921: |3| client hello, add ciphersuite: 00aa ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a6 ssl_cli.c:0921: |3| client hello, add ciphersuite: c037 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00b2 ssl_cli.c:0921: |3| client hello, add ciphersuite: c035 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0090 ssl_cli.c:0921: |3| client hello, add ciphersuite: c090 ssl_cli.c:0921: |3| client hello, add ciphersuite: c096 ssl_cli.c:0921: |3| client hello, add ciphersuite: c09a ssl_cli.c:0921: |3| client hello, add ciphersuite: c0aa ssl_cli.c:0921: |3| client hello, add ciphersuite: 009d ssl_cli.c:0921: |3| client hello, add ciphersuite: c09d ssl_cli.c:0921: |3| client hello, add ciphersuite: 003d ssl_cli.c:0921: |3| client hello, add ciphersuite: 0035 ssl_cli.c:0921: |3| client hello, add ciphersuite: c032 ssl_cli.c:0921: |3| client hello, add ciphersuite: c02a ssl_cli.c:0921: |3| client hello, add ciphersuite: c00f ssl_cli.c:0921: |3| client hello, add ciphersuite: c02e ssl_cli.c:0921: |3| client hello, add ciphersuite: c026 ssl_cli.c:0921: |3| client hello, add ciphersuite: c005 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a1 ssl_cli.c:0921: |3| client hello, add ciphersuite: c07b ssl_cli.c:0921: |3| client hello, add ciphersuite: 00c0 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0084 ssl_cli.c:0921: |3| client hello, add ciphersuite: c08d ssl_cli.c:0921: |3| client hello, add ciphersuite: c079 ssl_cli.c:0921: |3| client hello, add ciphersuite: c089 ssl_cli.c:0921: |3| client hello, add ciphersuite: c075 ssl_cli.c:0921: |3| client hello, add ciphersuite: 009c ssl_cli.c:0921: |3| client hello, add ciphersuite: c09c ssl_cli.c:0921: |3| client hello, add ciphersuite: 003c ssl_cli.c:0921: |3| client hello, add ciphersuite: 002f ssl_cli.c:0921: |3| client hello, add ciphersuite: c031 ssl_cli.c:0921: |3| client hello, add ciphersuite: c029 ssl_cli.c:0921: |3| client hello, add ciphersuite: c00e ssl_cli.c:0921: |3| client hello, add ciphersuite: c02d ssl_cli.c:0921: |3| client hello, add ciphersuite: c025 ssl_cli.c:0921: |3| client hello, add ciphersuite: c004 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a0 ssl_cli.c:0921: |3| client hello, add ciphersuite: c07a ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ba ssl_cli.c:0921: |3| client hello, add ciphersuite: 0041 ssl_cli.c:0921: |3| client hello, add ciphersuite: c08c ssl_cli.c:0921: |3| client hello, add ciphersuite: c078 ssl_cli.c:0921: |3| client hello, add ciphersuite: c088 ssl_cli.c:0921: |3| client hello, add ciphersuite: c074 ssl_cli.c:0921: |3| client hello, add ciphersuite: ccae ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ad ssl_cli.c:0921: |3| client hello, add ciphersuite: 00b7 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0095 ssl_cli.c:0921: |3| client hello, add ciphersuite: c093 ssl_cli.c:0921: |3| client hello, add ciphersuite: c099 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ac ssl_cli.c:0921: |3| client hello, add ciphersuite: 00b6 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0094 ssl_cli.c:0921: |3| client hello, add ciphersuite: c092 ssl_cli.c:0921: |3| client hello, add ciphersuite: c098 ssl_cli.c:0921: |3| client hello, add ciphersuite: ccab ssl_cli.c:0921: |3| client hello, add ciphersuite: 00a9 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a5 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00af ssl_cli.c:0921: |3| client hello, add ciphersuite: 008d ssl_cli.c:0921: |3| client hello, add ciphersuite: c08f ssl_cli.c:0921: |3| client hello, add ciphersuite: c095 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a9 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00a8 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a4 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ae ssl_cli.c:0921: |3| client hello, add ciphersuite: 008c ssl_cli.c:0921: |3| client hello, add ciphersuite: c08e ssl_cli.c:0921: |3| client hello, add ciphersuite: c094 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a8 ssl_cli.c:0934: |3| client hello, got 127 ciphersuites (excluding SCSVs) ssl_cli.c:0943: |3| adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_cli.c:0992: |3| client hello, compress len.: 1 ssl_cli.c:0993: |3| client hello, compress alg.: 0 ssl_cli.c:0068: |3| client hello, adding server name extension: a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com<http://a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/> ssl_cli.c:0186: |3| client hello, adding signature_algorithms extension ssl_cli.c:0271: |3| client hello, adding supported_elliptic_curves extension ssl_cli.c:0336: |3| client hello, adding supported_point_formats extension ssl_cli.c:0517: |3| client hello, adding encrypt_then_mac extension ssl_cli.c:0551: |3| client hello, adding extended_master_secret extension ssl_cli.c:0585: |3| client hello, adding session ticket extension ssl_cli.c:1070: |3| client hello, total extension length: 128 ssl_tls.c:3184: |2| => write handshake message ssl_tls.c:3343: |2| => write record ssl_tls.c:3420: |3| output record: msgtype = 22, version = [3:1], msglen = 429 ssl_tls.c:3425: |4| dumping 'output record sent to network' (434 bytes) ssl_tls.c:3425: |4| 0000: 16 03 01 01 ad 01 00 01 a9 03 03 5b d9 84 1f 2f ...........[.../ ssl_tls.c:3425: |4| 0010: 33 35 54 ea 0b 5d e1 dc 42 0c 99 d4 a1 25 72 6f 35T..]..B....%ro ssl_tls.c:3425: |4| 0020: 0f cf 8e 56 0d ab f5 10 e4 47 46 00 01 00 cc a8 ...V.....GF..... ssl_tls.c:3425: |4| 0030: cc a9 cc aa c0 2c c0 30 00 9f c0 ad c0 9f c0 24 .....,.0.......$ ssl_tls.c:3425: |4| 0040: c0 28 00 6b c0 0a c0 14 00 39 c0 af c0 a3 c0 87 .(.k.....9...... ssl_tls.c:3425: |4| 0050: c0 8b c0 7d c0 73 c0 77 00 c4 00 88 c0 2b c0 2f ...}.s.w.....+./ ssl_tls.c:3425: |4| 0060: 00 9e c0 ac c0 9e c0 23 c0 27 00 67 c0 09 c0 13 .......#.'.g.... ssl_tls.c:3425: |4| 0070: 00 33 c0 ae c0 a2 c0 86 c0 8a c0 7c c0 72 c0 76 .3.........|.r.v ssl_tls.c:3425: |4| 0080: 00 be 00 45 cc ac cc ad 00 ab c0 a7 c0 38 00 b3 ...E.........8.. ssl_tls.c:3425: |4| 0090: c0 36 00 91 c0 91 c0 9b c0 97 c0 ab 00 aa c0 a6 .6.............. ssl_tls.c:3425: |4| 00a0: c0 37 00 b2 c0 35 00 90 c0 90 c0 96 c0 9a c0 aa .7...5.......... ssl_tls.c:3425: |4| 00b0: 00 9d c0 9d 00 3d 00 35 c0 32 c0 2a c0 0f c0 2e .....=.5.2.*.... ssl_tls.c:3425: |4| 00c0: c0 26 c0 05 c0 a1 c0 7b 00 c0 00 84 c0 8d c0 79 .&.....{.......y ssl_tls.c:3425: |4| 00d0: c0 89 c0 75 00 9c c0 9c 00 3c 00 2f c0 31 c0 29 ...u.....<./.1.) ssl_tls.c:3425: |4| 00e0: c0 0e c0 2d c0 25 c0 04 c0 a0 c0 7a 00 ba 00 41 ...-.%.....z...A ssl_tls.c:3425: |4| 00f0: c0 8c c0 78 c0 88 c0 74 cc ae 00 ad 00 b7 00 95 ...x...t........ ssl_tls.c:3425: |4| 0100: c0 93 c0 99 00 ac 00 b6 00 94 c0 92 c0 98 cc ab ................ ssl_tls.c:3425: |4| 0110: 00 a9 c0 a5 00 af 00 8d c0 8f c0 95 c0 a9 00 a8 ................ ssl_tls.c:3425: |4| 0120: c0 a4 00 ae 00 8c c0 8e c0 94 c0 a8 00 ff 01 00 ................ ssl_tls.c:3425: |4| 0130: 00 80 00 00 00 34 00 32 00 00 2f 61 32 67 37 74 .....4.2../a2g7t ssl_tls.c:3425: |4| 0140: 77 6d 71 6f 37 68 67 38 32 2d 61 74 73 2e 69 6f wmqo7hg82-ats.io<http://wmqo7hg82-ats.io/> ssl_tls.c:3425: |4| 0150: 74 2e 61 70 2d 73 6f 75 74 68 2d 31 2e 61 6d 61 t.ap-south-1.ama ssl_tls.c:3425: |4| 0160: 7a 6f 6e 61 77 73 2e 63 6f 6d 00 0d 00 16 00 14 zonaws.com...... ssl_tls.c:3425: |4| 0170: 06 03 06 01 05 03 05 01 04 03 04 01 03 03 03 01 ................ ssl_tls.c:3425: |4| 0180: 02 03 02 01 00 0a 00 18 00 16 00 19 00 1c 00 18 ................ ssl_tls.c:3425: |4| 0190: 00 1b 00 17 00 16 00 1a 00 15 00 14 00 13 00 12 ................ ssl_tls.c:3425: |4| 01a0: 00 0b 00 02 01 00 00 16 00 00 00 17 00 00 00 23 ...............# ssl_tls.c:3425: |4| 01b0: 00 00 .. ssl_tls.c:2755: |2| => flush output ssl_tls.c:2773: |2| message length: 434, out_left: 434 ssl_tls.c:2779: |2| ssl->f_send() returned 434 (-0xfffffe4e) ssl_tls.c:2807: |2| <= flush output ssl_tls.c:3476: |2| <= write record ssl_tls.c:3320: |2| <= write handshake message ssl_cli.c:1106: |2| <= write client hello ssl_cli.c:3510: |2| client state: 2 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:1499: |2| => parse server hello ssl_tls.c:4311: |2| => read record ssl_tls.c:2536: |2| => fetch input ssl_tls.c:2696: |2| in_left: 0, nb_want: 5 ssl_tls.c:2720: |2| in_left: 0, nb_want: 5 ssl_tls.c:2722: |2| ssl->f_recv(_timeout)() returned -80 (-0x0050) ssl_tls.c:4973: |1| mbedtls_ssl_fetch_input() returned -80 (-0x0050) ssl_tls.c:4344: |1| ssl_get_next_record() returned -80 (-0x0050) ssl_cli.c:1506: |1| mbedtls_ssl_read_record() returned -80 (-0x0050) ssl_tls.c:8094: |2| <= handshake failed ! mbedtls_ssl_handshake returned -0x50 Last error was: -0x50 - NET - Connection was reset by peer ssl_tls.c:8934: |2| => free ssl_tls.c:8999: |2| <= free I request you to help me in resolving this issue. Regards, Srinivas. [cid:ef4e58a5-df1a-47f0-90b9-c467a93244c2]

6 years

1
0
0 0

Re: [mbed-tls] support mbedTLS no entropy source

by Dan Handley

Hi Palomo All the documentation we have to share is already available, either in the upstream codebase, the wiki (https://developer.trustedfirmware.org/w/mbed-tls/) or the legacy website (https://tls.mbed.org/). Some of the info on the latter is out of date. The core development team at Arm do not offer training. Arm has a Partner Enablement Group that does this kind of thing but I don't think they offer Mbed TLS specific training currently. I've asked them if they would consider this in future but I guess that's not going to help you in the short term. Good luck with your learning and we'll try to answer any specific questions you have. Regards Dan. From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Jesus Gualberto Palomo Garcia via mbed-tls Sent: 08 June 2020 04:46 To: Gilles Peskine <Gilles.Peskine(a)arm.com> Cc: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] support mbedTLS no entropy source Hi Gilles. Thanks for follow my questions and attend it, regarding trainings, I want to understand how the encryption works, how the algorithms works inside the library, I can read the code and google the concepts but I want to accelerate the knowledge transfer, maybe for implement some optimization, I don't if that is possible, at the moment my PoC using uClinux works perfectly and the TLS 1.2 ir running over 80Mhz, so that is pretty awesome, but I want to learn more about encryption, maybe if you can share me some literature regarding this point? Thank you very much and regards from Mexico! On Tue, Jun 2, 2020 at 6:21 PM Gilles Peskine <gilles.peskine(a)arm.com<mailto:gilles.peskine@arm.com>> wrote: Hi Palomo, I don't think there's any other way at the moment. The patch in my email is one possible solution, but I'm not sure if it's right, because not all platforms with a Linux kernel have /dev/urandom. I think the best solution would be to make the existence of /dev/urandom a platform configuration option. But platform options are a little messy already, between the MBEDTLS_HAVE_xxx options, the MBEDTLS_PLATFORM_STD_xxx options, the MBEDTLS_PLATFORM_xxx_MACRO options, the MBEDTLS_PLATFORM_xxx_ALT options. And this new option wouldn't behave like any of the existing ones since it should have three settings: guess (the default, identical to the current behavior of observing preprocessor symbols like __unix__), off and on. We should figure out what to do about platform options in 3.0 before making this even more complex. me.todo.add("collect my thoughts on simplifying platform customization and post them to the list") Regarding trainings, my team doesn't normally do that, but there are other teams in Arm that do. What topic are you interested in? -- Gilles Peskine Mbed TLS developer On 31/05/2020 20:06, Jesus Gualberto Palomo Garcia wrote: > Hello Gilles thanks for your support, yes finally I could compile the > library in the architecture that I used, I forced the compilation to > entry in the "if _unix_" conditional compilation, but I assume that > exist another way to do this. Do you have a example for enable that > conditional compilation flags? > > regarding to my dev/urandom, yes my platform has this feature, the > library runs very well, but I just have the point related to "force" > the compilation because the library doesn't recognize the unix > architecture. > > Thanks and we keep in touch! > > Regards from Mexico! > > BTW If I want to professional training, Do you offered this service? > > On Mon, May 25, 2020 at 11:07 AM Gilles Peskine via mbed-tls > <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>> wrote: > > Hi Palomo, > > You seem to be compiling for a system with a Linux kernel, but > with only > a partial Unix userland. The “Unix” code in the entropy_poll module > might work on your system, but it is only enabled if __unix__ or > __unix > (or a few others) is defined. > > Can you please try the attached patch? Does your runtime environment > have /dev/urandom ? > > Regarding the knowledge base article, you need to remove the "." > character at the end of the URL: > https://tls.mbed.org/kb/how-to/add-a-random-generator-- > > Gilles Peskine > Mbed TLS developer > > On 19/05/2020 21:43, Jesus Gualberto Palomo Garcia via mbed-tls wrote: > > Hello Hanno, Thanks for your thanks for you quickly replay. > > > > I have an error compilation, I'm using nios2-linux-uclibc for my > cross > > compilation and uclinux architecture, > > the linux kernel is 2.60 but I have this error when I try to compile > > the library, I want to use the library as a simple client using > TLS1.2 > > > > $ make static > > CC aes.c > > CC aesni.c > > CC arc4.c > > CC aria.c > > CC asn1parse.c > > CC asn1write.c > > CC base64.c > > CC bignum.c > > CC blowfish.c > > CC camellia.c > > CC ccm.c > > CC chacha20.c > > CC chachapoly.c > > CC cipher.c > > CC cipher_wrap.c > > CC cmac.c > > CC ctr_drbg.c > > CC des.c > > CC dhm.c > > CC ecdh.c > > CC ecdsa.c > > CC ecjpake.c > > CC ecp.c > > CC ecp_curves.c > > CC entropy.c > > CC entropy_poll.c > > entropy_poll.c:56:2: #error "Platform entropy sources only work on > > Unix and Windows, see MBEDTLS_NO_PLATFORM_ENTROPY in config.h" > > Makefile:285: recipe for target 'entropy_poll.o' failed > > make: *** [entropy_poll.o] Error 1 > > > > BTW the article is not > > found https://tls.mbed.org/kb/how-to/add-a-random-generator. > > <https://tls.mbed.org/kb/how-to/add-a-random-generator.> > > > > Many thanks!! > > > > > > On Tue, May 19, 2020 at 9:01 AM Hanno Becker > <Hanno.Becker(a)arm.com<mailto:Hanno.Becker@arm.com> <mailto:Hanno.Becker@arm.com<mailto:Hanno.Becker@arm.com>> > > <mailto:Hanno.Becker@arm.com<mailto:Hanno.Becker@arm.com> <mailto:Hanno.Becker@arm.com<mailto:Hanno.Becker@arm.com>>>> wrote: > > > > Hi Palomo, > > > > Please take a look at the recent > > > thread https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000069.html > > which should give you a better understanding of how Mbed TLS > > manages and uses entropy from the underlying system. > > > > Regards, > > Hanno > > > ------------------------------------------------------------------------ > > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org> > <mailto:mbed-tls-bounces@lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>> > > <mailto:mbed-tls-bounces@lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org> > <mailto:mbed-tls-bounces@lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>>>> on behalf of > > Jesus Gualberto Palomo Garcia via mbed-tls > > <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> > > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>>> > > *Sent:* Tuesday, May 19, 2020 2:56 PM > > *To:* mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> > > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>> > > <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> > > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>>> > > *Subject:* [mbed-tls] support mbedTLS no entropy source > > > > Hi all! > > > > I'm Palomo and I've been working with your library a few weeks > > ago, I'm using Linux kernel 2.60 but my embedded system has a > > limit entropy source, i now that this is a critical point, > but How > > can I use your library if I want to use a other entropy source? > > > > Thanks and waiting for you! > > > > -- > > *¡Saludos! Best wishes!* > > * > > * > > * > > /*Jesus** Palomo*/ > > > > México, D.F. > > > > * > > > > > > > > -- > > *¡Saludos! Best wishes!* > > * > > * > > * > > /*Jesus** Palomo*/ > > > > México, D.F. > > > > * > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > > -- > *¡Saludos! Best wishes!* > * > * > * > /*Jesus** Palomo*/ > > México, D.F. > > * -- ¡Saludos! Best wishes! Jesus Palomo México, D.F.

6 years

1
0
0 0

Re: [mbed-tls] support mbedTLS no entropy source

by Jesus Gualberto Palomo Garcia

Hello Gilles thanks for your support, yes finally I could compile the library in the architecture that I used, I forced the compilation to entry in the "if _unix_" conditional compilation, but I assume that exist another way to do this. Do you have a example for enable that conditional compilation flags? regarding to my dev/urandom, yes my platform has this feature, the library runs very well, but I just have the point related to "force" the compilation because the library doesn't recognize the unix architecture. Thanks and we keep in touch! Regards from Mexico! BTW If I want to professional training, Do you offered this service? On Mon, May 25, 2020 at 11:07 AM Gilles Peskine via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi Palomo, > > You seem to be compiling for a system with a Linux kernel, but with only > a partial Unix userland. The “Unix” code in the entropy_poll module > might work on your system, but it is only enabled if __unix__ or __unix > (or a few others) is defined. > > Can you please try the attached patch? Does your runtime environment > have /dev/urandom ? > > Regarding the knowledge base article, you need to remove the "." > character at the end of the URL: > https://tls.mbed.org/kb/how-to/add-a-random-generator-- > > Gilles Peskine > Mbed TLS developer > > On 19/05/2020 21:43, Jesus Gualberto Palomo Garcia via mbed-tls wrote: > > Hello Hanno, Thanks for your thanks for you quickly replay. > > > > I have an error compilation, I'm using nios2-linux-uclibc for my cross > > compilation and uclinux architecture, > > the linux kernel is 2.60 but I have this error when I try to compile > > the library, I want to use the library as a simple client using TLS1.2 > > > > $ make static > > CC aes.c > > CC aesni.c > > CC arc4.c > > CC aria.c > > CC asn1parse.c > > CC asn1write.c > > CC base64.c > > CC bignum.c > > CC blowfish.c > > CC camellia.c > > CC ccm.c > > CC chacha20.c > > CC chachapoly.c > > CC cipher.c > > CC cipher_wrap.c > > CC cmac.c > > CC ctr_drbg.c > > CC des.c > > CC dhm.c > > CC ecdh.c > > CC ecdsa.c > > CC ecjpake.c > > CC ecp.c > > CC ecp_curves.c > > CC entropy.c > > CC entropy_poll.c > > entropy_poll.c:56:2: #error "Platform entropy sources only work on > > Unix and Windows, see MBEDTLS_NO_PLATFORM_ENTROPY in config.h" > > Makefile:285: recipe for target 'entropy_poll.o' failed > > make: *** [entropy_poll.o] Error 1 > > > > BTW the article is not > > found https://tls.mbed.org/kb/how-to/add-a-random-generator. > > <https://tls.mbed.org/kb/how-to/add-a-random-generator.> > > > > Many thanks!! > > > > > > On Tue, May 19, 2020 at 9:01 AM Hanno Becker <Hanno.Becker(a)arm.com > > <mailto:Hanno.Becker@arm.com>> wrote: > > > > Hi Palomo, > > > > Please take a look at the recent > > thread > https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000069.html > > > which should give you a better understanding of how Mbed TLS > > manages and uses entropy from the underlying system. > > > > Regards, > > Hanno > > > ------------------------------------------------------------------------ > > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org > > <mailto:mbed-tls-bounces@lists.trustedfirmware.org>> on behalf of > > Jesus Gualberto Palomo Garcia via mbed-tls > > <mbed-tls(a)lists.trustedfirmware.org > > <mailto:mbed-tls@lists.trustedfirmware.org>> > > *Sent:* Tuesday, May 19, 2020 2:56 PM > > *To:* mbed-tls(a)lists.trustedfirmware.org > > <mailto:mbed-tls@lists.trustedfirmware.org> > > <mbed-tls(a)lists.trustedfirmware.org > > <mailto:mbed-tls@lists.trustedfirmware.org>> > > *Subject:* [mbed-tls] support mbedTLS no entropy source > > > > Hi all! > > > > I'm Palomo and I've been working with your library a few weeks > > ago, I'm using Linux kernel 2.60 but my embedded system has a > > limit entropy source, i now that this is a critical point, but How > > can I use your library if I want to use a other entropy source? > > > > Thanks and waiting for you! > > > > -- > > *¡Saludos! Best wishes!* > > * > > * > > * > > /*Jesus** Palomo*/ > > > > México, D.F. > > > > * > > > > > > > > -- > > *¡Saludos! Best wishes!* > > * > > * > > * > > /*Jesus** Palomo*/ > > > > México, D.F. > > > > * > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > -- *¡Saludos! Best wishes!* *Jesus PalomoMéxico, D.F.*

6 years

2
2
0 0

Feedback sought on a new PSA Crypto driver interface

by Gilles Peskine

Hello, Arm is seeking early feedback on a proposed interface for cryptographic drivers that can be plugged into an implementation of the PSA Cryptography API. A copy of the current specification is attached. You can find the current draft of the specification of this interface at https://github.com/gilles-peskine-arm/mbedtls/blob/psa-unified-driver-proto… Please note that this is work in progress. The document is not complete yet. At this stage, it is intended to offer a general overview of the design, not as an implementable specification. Our intention is to continue refining this design, however we may change it based on the feedback that we will receive and there is even a small chance that we will abandon it. The primary intent of this specification is to allow manufacturers of cryptographic hardware to distribute drivers that can be added to a pure-software, portable implementation of the PSA Cryptography API such as Mbed TLS. The interface was designed to support three types of hardware: * Cryptographic accelerators that operate on a key which is provided in cleartext at the beginning of the operation. This type of driver can also be used to plug in software engines. * Protected environments that operate on a wrapped key which is stored outside the protected environment. * Protected environments that have internal key storage and operate on keys designated by an identifier. Concretely, a driver manufacturer would distribute: * A JSON file specifying the driver's capabilities. * C headers declaring the types and functions provided by the driver. * The implementation of the functions provided by the driver, either in the form of C source code or in the form of compiled code. Then when an application uses a key: * If the key is in the memory or local storage of the PSA crypto subsystem and a driver is available for the requested cryptographic mechanism, the core (e.g. Mbed TLS) dispatches the cryptographic operation to the driver. * If the key is in local storage and no driver is available, the core performs the cryptographic operation itself. * If the key is in some other location (as specified by its lifetime), the core invokes the protected environment driver corresponding to that location. This proposal supersedes the previous drafts “PSA cryptographic accelerator interface” (psa_crypto_accel.h) and “PSA secure element driver interface” (crypto_se_driver.h). We intend to implement this specification in Mbed TLS in such a way that a platform distributor can combine drivers and distribute C source code, object files or a mixture of the two in their system development kit. In the long term, the accelerator interface defined here will replace the current MBEDTLS_xxx_ALT mechanism. Comments are welcome through the following venues: * Public email to the psa-crypto or mbed-tls mailing list at TrustedFirmware. * Public comments on GitHub on the pull request https://github.com/ARMmbed/mbedtls/pull/3313 . * Private email to <mbed-crypto(a)arm.com>. These emails will only be shared inside Arm. We may use your feedback to influence the design of PSA Crypto, but your identity and the specifics will be kept confidential. We do not have a specific deadline for feedback, however we intend to start implementing this interface in Mbed TLS in June 2020, so feedback received later will have a reduced chance of influencing the design if it would entail major changes. Best regards, -- Gilles Peskine Mbed TLS developer and PSA Cryptography architect

6 years

1
0
0 0

Re: [mbed-tls] support mbedTLS no entropy source

by Gilles Peskine

Hi Palomo, You seem to be compiling for a system with a Linux kernel, but with only a partial Unix userland. The “Unix” code in the entropy_poll module might work on your system, but it is only enabled if __unix__ or __unix (or a few others) is defined. Can you please try the attached patch? Does your runtime environment have /dev/urandom ? Regarding the knowledge base article, you need to remove the "." character at the end of the URL: https://tls.mbed.org/kb/how-to/add-a-random-generator-- Gilles Peskine Mbed TLS developer On 19/05/2020 21:43, Jesus Gualberto Palomo Garcia via mbed-tls wrote: > Hello Hanno, Thanks for your thanks for you quickly replay. > > I have an error compilation, I'm using nios2-linux-uclibc for my cross > compilation and uclinux architecture, > the linux kernel is 2.60 but I have this error when I try to compile > the library, I want to use the library as a simple client using TLS1.2 > > $ make static > CC aes.c > CC aesni.c > CC arc4.c > CC aria.c > CC asn1parse.c > CC asn1write.c > CC base64.c > CC bignum.c > CC blowfish.c > CC camellia.c > CC ccm.c > CC chacha20.c > CC chachapoly.c > CC cipher.c > CC cipher_wrap.c > CC cmac.c > CC ctr_drbg.c > CC des.c > CC dhm.c > CC ecdh.c > CC ecdsa.c > CC ecjpake.c > CC ecp.c > CC ecp_curves.c > CC entropy.c > CC entropy_poll.c > entropy_poll.c:56:2: #error "Platform entropy sources only work on > Unix and Windows, see MBEDTLS_NO_PLATFORM_ENTROPY in config.h" > Makefile:285: recipe for target 'entropy_poll.o' failed > make: *** [entropy_poll.o] Error 1 > > BTW the article is not > found https://tls.mbed.org/kb/how-to/add-a-random-generator. > <https://tls.mbed.org/kb/how-to/add-a-random-generator.> > > Many thanks!! > > > On Tue, May 19, 2020 at 9:01 AM Hanno Becker <Hanno.Becker(a)arm.com > <mailto:Hanno.Becker@arm.com>> wrote: > > Hi Palomo, > > Please take a look at the recent > thread https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000069.html > which should give you a better understanding of how Mbed TLS > manages and uses entropy from the underlying system. > > Regards, > Hanno > ------------------------------------------------------------------------ > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org > <mailto:mbed-tls-bounces@lists.trustedfirmware.org>> on behalf of > Jesus Gualberto Palomo Garcia via mbed-tls > <mbed-tls(a)lists.trustedfirmware.org > <mailto:mbed-tls@lists.trustedfirmware.org>> > *Sent:* Tuesday, May 19, 2020 2:56 PM > *To:* mbed-tls(a)lists.trustedfirmware.org > <mailto:mbed-tls@lists.trustedfirmware.org> > <mbed-tls(a)lists.trustedfirmware.org > <mailto:mbed-tls@lists.trustedfirmware.org>> > *Subject:* [mbed-tls] support mbedTLS no entropy source > > Hi all! > > I'm Palomo and I've been working with your library a few weeks > ago, I'm using Linux kernel 2.60 but my embedded system has a > limit entropy source, i now that this is a critical point, but How > can I use your library if I want to use a other entropy source? > > Thanks and waiting for you! > > -- > *¡Saludos! Best wishes!* > * > * > * > /*Jesus** Palomo*/ > > México, D.F. > > * > > > > -- > *¡Saludos! Best wishes!* > * > * > * > /*Jesus** Palomo*/ > > México, D.F. > > * >

6 years, 1 month

1
0
0 0

Re: [mbed-tls] support mbedTLS no entropy source

by Hanno Becker

Hi Palomo, Please take a look at the recent thread https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000069.html which should give you a better understanding of how Mbed TLS manages and uses entropy from the underlying system. Regards, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Jesus Gualberto Palomo Garcia via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, May 19, 2020 2:56 PM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] support mbedTLS no entropy source Hi all! I'm Palomo and I've been working with your library a few weeks ago, I'm using Linux kernel 2.60 but my embedded system has a limit entropy source, i now that this is a critical point, but How can I use your library if I want to use a other entropy source? Thanks and waiting for you! -- ¡Saludos! Best wishes! Jesus Palomo México, D.F.

6 years, 1 month

2
1
0 0

support mbedTLS no entropy source

by Jesus Gualberto Palomo Garcia

Hi all! I'm Palomo and I've been working with your library a few weeks ago, I'm using Linux kernel 2.60 but my embedded system has a limit entropy source, i now that this is a critical point, but How can I use your library if I want to use a other entropy source? Thanks and waiting for you! -- *¡Saludos! Best wishes!* *Jesus PalomoMéxico, D.F.*

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Psk tls with trustzone

by Gilles Peskine

Hello, If you enable the use PSA for cryptography in TLS (MBEDTLS_USE_PSA_CRYPTO) and configure the PSK with mbedtls_ssl_conf_psk_opaque(), the key derivation is done through the PSA API. You can then keep your key in the secure world. You'll need to have a PSA crypto implementation where the PSA crypto core is in the secure world and the frontend is in the application that performs the TLS handshake. PSA crypto is designed for this, but you or your TEE vendor will need to port the Mbed TLS code to your platform. -- Gilles Peskine Mbed TLS developer On 13/05/2020 11:10, mayuri janawad via mbed-tls wrote: > Hello, > > I am currently trying to establish pre shared key based tls handshake > using mbedtls. However, I want to store the pre shared key in the > trustzone and derive the session key inside the trustzone. Is it > possible using mbedtls? Can I provide alternate implementation for psk > based tls in mbedtls library? > > It would be really helpful if this could be answered as soon as > possible. Thank you in advance for your assistance. > > Regards, > Mayuri Janawad >

6 years, 1 month

1
0
0 0

Psk tls with trustzone

by mayuri janawad

Hello, I am currently trying to establish pre shared key based tls handshake using mbedtls. However, I want to store the pre shared key in the trustzone and derive the session key inside the trustzone. Is it possible using mbedtls? Can I provide alternate implementation for psk based tls in mbedtls library? It would be really helpful if this could be answered as soon as possible. Thank you in advance for your assistance. Regards, Mayuri Janawad

6 years, 1 month

1
0
0 0

Re: [mbed-tls] ECDH Computation on STM32 platform

by Manuel Pegourie-Gonnard

Hi Abhilash, > I am trying to do the ECDH shared secret computation using the mbedTLS > library. I am referring to multiple examples such as ecdh_curve25519.c > and ecdh_main.c. > Ok. You should probably know a few things about those examples: 1. They both perform what's known as "ephemeral ECDH" (or sometimes ECDHE). 2. They're both using the low-level part of our ECDH API. For ecdh_curve25519, that is because that curve is not supported by the higher-level API yet - for the other example, I don't know what the reason is. 3. Curve25519 is quite different from other curves regarding how public keys are represented. > In my case, in my application firmware, I already have a device _priv > key and I receive a server_public key; both generated using a curve > ECP_DP_SECP256R1 in the bootloader itself. So in the application > firmware, I would like to do generate a shared secret from here on and > preserve it for future use. > Ok, so you want to do what's known as "static ECDH". So the example ecdh_curve25519 is not a great example, due to points 1 and 3 above. Also, since the curve you're using supports it, you may want to use the higher-level part of our ECDH API (the functions that accept a context as an argument). > The following is the steps that I do: > > 1. Create a new client context, entropy context, ctr_drbg context variables. > 2. use mbedtls_"respective"_init() to initalize all the three variables > 3. Seed a random number using mbedtls_ctr_drbg_seed() function. > 4. load the P256 elliptic curve in client context using mbedtls_ecp_group_load() All this looks absolutely correct. > 5. Then use mbedtls_mpi_lset() to set Qp.Z =1 > 6. Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65); >From the 65 I assume that the server public key as encoded as an uncompressed point. Then you can read it with: mbedtls_ecp_point_read_binary(&ctx_cli.grp, &ctx_cli.Qp, server_pub, 65); (For Curve25519 mbedtls_ecp_point_read_binary() isn't implemented yet which is why the example does a direct call to an MPI function and accesses individual point coordinates, but Curve25519 and P-256 don't use the same coordinate systems.) > 7. Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using > mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ? That looks almost correct, except 50 does not look like a valid size for a private key for the curve you're using. > 8. Then I use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z. > That's correct, but you could also call mbedtls_ecdh_calc_secret( &ctx_cli, &olen, buf, blen, mbedtls_ctr_drbg_random, &ctr_drbg ); which also serializes the secret to a buffer. > Questions: > 1. Do I need to generate a keypair for client context using > mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, > mbedtls_ctr_drbg_random, &ctrDrbg)? And then set pvtkey as device priv > key and pub key as service pub key? > I'm not sure I understand the context of the question, so I'll distinguish two cases: - When provisioning the device, you need to generate a key pair for it, which can indeed be done as show. - Once the device is working, it doesn't need to generate new key pairs, just load the one that was provisioned as described below. > 2. I see that ctx_cli.Q has two components, Q.x and Q.y. How do I > extract these two values from a public key? Do I need to separately > initialize them? > I don't recommend you manipulate those directly, but use the `mbedtls_ecp_point_{read,write}_binary()` functions instead. > Please let me know if the flow is correct. In all the examples, they > generate a key pair and just update the public key part (Qp.X) of the > key. They do not touch the private key part (d) of the key. Please > confirm if I can upload my private key directly in my case. > Your flow looks correct, and the difference from the examples is that they're demonstrating ephemeral ECDH while it looks like you want to do static ECDH. > Also if my platform is a little endian, is there a recommended step > before using mbedtls_mpi_read_binary_le functions? Then endianness of your plaftorm should not matter, and you shouldn't need to use that function. Regards, Manuel.

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Edwards curve support (#3245): fixing mbedtls_ecp_get_type

by Manuel Pegourie-Gonnard

Hi Aurélien, > I have submitted PR#3245 in order to add Edwards curves support to Mbed > TLS, with the eventual goal to add support for the EdDSA algorithm. > There are still a few things to fix that require discussion. > Thank you very much for your contribution, and for opening this discussion! > Let's start the discussion with the first one. Adding a new curve type > requires to add a new entry to the mbedtls_ecp_curve_type enum. The > curve type used by a group is returned by the mbedtls_ecp_get_type > function. It currently uses the coordinates type of the base point to > determine the curve type. Montgomery curves are lacking the y > coordinate, and the Short Weierstrass curves use the three x, y and z > coordinates. > > The Edwards arithmetic implementation in this PR uses the projective > coordinates. As such it also uses the x, y and z coordinates and this > gives no way to differentiate a Short Weierstrass from an Edwards curve. > Indeed, the current implementation of `ecp_curve_type()` is a bit of a hack and needs changing now that you're adding Edwards curves. > I have currently implemented that by checking if the curves are the > Ed25519 or Ed448 ones using the group id [1]. I am not sure it's very > clean and it won't scale if more curves are added later. Another > alternative would be to add another entry to mbedtls_ecp_group to hold > the curve type. > > What do you think is the best option? Any other idea? Honestly I think both options are fine. In the medium term (in 3.0 or 3.x) I'd like to entirely rework the `ecp_group` structure, which currently potentially wastes memory by having multiple instances for the same curve around (for example, when verifying a chain of N certificates all signed with the same curve, we'll have N instances of the `ecp_group` structure for that curve in RAM, which is quite wasteful). So I think in the meantime we don't need to sweat it too much. I have a slight preference for the option you currently implemented (checking the group ID), for two reasons: 1. Lack of scaling is not an issue, as it's unlikely a large number of Edwards curves are going to be added soon (in particular, not before the rework of ecp_group), since these last few years the tendency seems to be to focus on a small number of trusted curves [1]. 2. Adding a new member to `mbedtls_ecp_group` would be an ABI break, and while we don't have a strict policy of ABI stability, it tends to cause pain to packagers if we change the ABI too often, so it's probably better to avoid it if we can. Thanks, Manuel. [1] For example, compare https://tools.ietf.org/html/rfc4492#section-5.1.1 to https://tools.ietf.org/html/rfc8422#section-5.1.1

6 years, 1 month

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Manuel Pegourie-Gonnard

Hi Simon, > I appreciate I'm coming very late to this discussion, but I want to make a > point and suggestion. > Well, I don't think we had reached a clear consensus yet, so it's not too late to explore more options! > These are very similar points to those Manuel was making to remove the feature > in the first place - however - short of investing the time in rewriting the > asymmetric functions, what we could do as a quick fix is to replace the > existing memory code with a block allocation scheme - which should be much > faster, speed up the asymmetric functions (in theory), avoid fragmentation, be > more deterministic, and a better fit for embedded applications. That could > then become the basis of the library for other projects too. > I think compared to our existing allocator, that would indeed be an improvement, and as you say possibly a "quick fix" for some of the performance issues of our asymmetric crypto (esp. ECC)... for people who use our allocator. I'm still under the impression they're a minority of users, even in the embedded world. I think it comes back to a point we touched on earlier in the thread: what other allocators are available, and how do they compare to the design you have in mind? If existing allocators in popular embedded libc implementations already handle small allocations efficiently, then people are probably better off using them. > I wouldn't mind contributing such a feature, as I had to write something very > similar last week anyway. > > If I do it - will you accept it? Thanks for the offer! Unfortunately I think it's hard to give you a clear yes or no answer at this point. Speaking only for myself (others in the team may disagree and are welcome to say so in reply), I'm a bit concerned that for a "quick fix" it would represent a significant review effort: there are obvious security implications, it would be a complete re-design of a whole module, and I'm not sure how many of the potential reviewers are very familiar with allocators (I know I'm not). Considering we already have a number of significant contributions that we just can't review as soon as we'd like, I'd be concerned adding another one. Adding to that concern is the fact that at this point it's still not clear to me if in the long-term we want to keep maintaining this, or use some existing allocator, or move it to a separate project possibly maintained by another team. Would your offer still stand in a couple of months, when the future of the module is perhaps a bit clearer, and when we've hopefully cleared a few of the long-standing large PR awaiting review? Thanks, Manuel.

6 years, 1 month

2
1
0 0

Re: [mbed-tls] Fwd: MBEDTLS never exits ecp_double_jac function call

by Gilles Peskine

Hi Sirjee, Does this fail systematically or randomly? Can you reproduce this with a very small program that only opens a TLS connection and nothing else, like programs/ssl/ssl_client1? At a guess, but this is only a guess, maybe this is the part of your program which uses the largest amount of stack, and there's a stack overflow that causes some variable to be overwritten. Please try increasing the stack size. -- Gilles Peskine Mbed TLS developer P.S. The config.h attachment didn't come through, but a graphical signature did. Please check your email settings when posting to the list. On 04/05/2020 10:50, Sirjee Rooplall via mbed-tls wrote: > > > Hi Support, > > I am using MBEDTLS and most of it works, except I have hit a snag > where I am trying to communicate to an https server, and it fails in > the ssl->handshake-step (ssl_write_client_key_exchange). > > My stack trace shows that it gets to the function ecp_double_jac and > never exits. It is looping at > MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &T, &P->X, &S ) ); > MOD_ADD( T );. > Stack trace: > test.elf! mbedtls_mpi_sub_abs (mbedtls_mpi * X, const mbedtls_mpi * A, > const mbedtls_mpi * B) Line: 1287 > test.elf! ecp_double_jac (const mbedtls_ecp_group * grp, > mbedtls_ecp_point * R, const mbedtls_ecp_point * P) Line: 1310 > test.elf! ecp_precompute_comb (const mbedtls_ecp_group * grp, > mbedtls_ecp_point * T, const mbedtls_ecp_point * P, unsigned char w, > size_t d, mbedtls_ecp_restart_ctx * rs_ctx) Line: 1702 > test.elf! ecp_mul_comb (mbedtls_ecp_group * grp, mbedtls_ecp_point * > R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, > unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx > * rs_ctx) Line: 2095 > test.elf! mbedtls_ecp_mul_restartable (mbedtls_ecp_group * grp, > mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point > * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, > mbedtls_ecp_restart_ctx * rs_ctx) Line: 2396 > test.elf! ecdh_gen_public_restartable (mbedtls_ecp_group * grp, > mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char > *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) > Line: 84 > test.elf! mbedtls_ecdh_gen_public (mbedtls_ecp_group * grp, > mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char > *, size_t) f_rng, void * p_rng) Line: 102 > test.elf! ecdh_make_public_internal (mbedtls_ecdh_context_mbed * > ctx, size_t * olen, int point_format, unsigned char * buf, size_t > blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, > int restart_enabled) Line: 514 > test.elf! mbedtls_ecdh_make_public (mbedtls_ecdh_context * ctx, > size_t * olen, unsigned char * buf, size_t blen, int (*)(void *, > unsigned char *, size_t) f_rng, void * p_rng) Line: 542 > test.elf! ssl_write_client_key_exchange (mbedtls_ssl_context * ssl) > Line: 3362 > test.elf! mbedtls_ssl_handshake_client_step (mbedtls_ssl_context * > ssl) Line: 4015 > test.elf! mbedtls_ssl_handshake_step (mbedtls_ssl_context * ssl) > Line: 9564 > test.elf! mbedtls_ssl_handshake (mbedtls_ssl_context * ssl) Line: 9588 > test.elf! https_do_tls_handshake (struct httpsConfigStr * client) > Line: 419 > test.elf! HttpsStateMachine Line: 366 > test.elf! HttpsTask (void * param) Line: 110 > test.elf! ?? Line: 110 > > MBEDTLS VERSION: mbed TLS 2.18.0 > PLATFORM: embedded microchip SAME70 micro controller. > > I have attached my config.h file. > > What am I doing wrong? > >

6 years, 1 month

1
0
0 0

Fwd: MBEDTLS never exits ecp_double_jac function call

by Sirjee Rooplall

Hi Support, I am using MBEDTLS and most of it works, except I have hit a snag where I am trying to communicate to an https server, and it fails in the ssl->handshake-step (ssl_write_client_key_exchange). My stack trace shows that it gets to the function ecp_double_jac and never exits. It is looping at MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &T, &P->X, &S ) ); MOD_ADD( T );. Stack trace: test.elf! mbedtls_mpi_sub_abs (mbedtls_mpi * X, const mbedtls_mpi * A, const mbedtls_mpi * B) Line: 1287 test.elf! ecp_double_jac (const mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_ecp_point * P) Line: 1310 test.elf! ecp_precompute_comb (const mbedtls_ecp_group * grp, mbedtls_ecp_point * T, const mbedtls_ecp_point * P, unsigned char w, size_t d, mbedtls_ecp_restart_ctx * rs_ctx) Line: 1702 test.elf! ecp_mul_comb (mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 2095 test.elf! mbedtls_ecp_mul_restartable (mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 2396 test.elf! ecdh_gen_public_restartable (mbedtls_ecp_group * grp, mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 84 test.elf! mbedtls_ecdh_gen_public (mbedtls_ecp_group * grp, mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng) Line: 102 test.elf! ecdh_make_public_internal (mbedtls_ecdh_context_mbed * ctx, size_t * olen, int point_format, unsigned char * buf, size_t blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, int restart_enabled) Line: 514 test.elf! mbedtls_ecdh_make_public (mbedtls_ecdh_context * ctx, size_t * olen, unsigned char * buf, size_t blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng) Line: 542 test.elf! ssl_write_client_key_exchange (mbedtls_ssl_context * ssl) Line: 3362 test.elf! mbedtls_ssl_handshake_client_step (mbedtls_ssl_context * ssl) Line: 4015 test.elf! mbedtls_ssl_handshake_step (mbedtls_ssl_context * ssl) Line: 9564 test.elf! mbedtls_ssl_handshake (mbedtls_ssl_context * ssl) Line: 9588 test.elf! https_do_tls_handshake (struct httpsConfigStr * client) Line: 419 test.elf! HttpsStateMachine Line: 366 test.elf! HttpsTask (void * param) Line: 110 test.elf! ?? Line: 110 MBEDTLS VERSION: mbed TLS 2.18.0 PLATFORM: embedded microchip SAME70 micro controller. I have attached my config.h file. What am I doing wrong?

6 years, 1 month

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Simon Butcher

Hi All, I appreciate I'm coming very late to this discussion, but I want to make a point and suggestion. The performance of the asymmetric functions is less than ideal, and whilst I think we can all agree that the ECC code should be rewritten at some point to be more competitive, one of the issues with the performance is that the MPI code uses malloc() a lot. There are competing crypto libraries out there that are faster and use a smaller RAM footprint and don't use dynamic memory allocation at all. Our memory allocation code is also kind of slow, and has a primitive and simplistic design of a linked list. These are very similar points to those Manuel was making to remove the feature in the first place - however - short of investing the time in rewriting the asymmetric functions, what we could do as a quick fix is to replace the existing memory code with a block allocation scheme - which should be much faster, speed up the asymmetric functions (in theory), avoid fragmentation, be more deterministic, and a better fit for embedded applications. That could then become the basis of the library for other projects too. I wouldn't mind contributing such a feature, as I had to write something very similar last week anyway. If I do it - will you accept it? Kind regards Simon On 09/04/2020, 12:07, "mbed-tls on behalf of Dan Handley via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Hi There has already been some discussion about a shared C standard library implementation, at least for TF-A and TF-M. So far there's been general agreement that this is a good idea but no actual commitment from anyone to make this happen, since each project is reasonably happy with what they've got. Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so removing this from the codebase would be an issue there. Memory allocators are probably not the core expertise of other Trusted Firmware projects either but it needs to be if they're going to use them! I propose that we move this allocator into a new shared TrustedFirmware.org standard C library project and work with the other projects to ensure it has the correct initial maintainers. This will probably have to be driven by the maintainers of whichever project is most motivated to make this happen. It sounds like that could be Mbed TLS and this will need to be done before any separation of the PSA Crypto implementation. In the short term, as we move C stdlib functionality out of the other projects and into this new project, we will need to support multiple implementations of some functions. Eventually we should move towards a common implementation, and I agree we should look at what security-oriented implementations are already available. I also agree it would make sense for Mbed TLS to not use the toolchain-provided stdlib implementation by default, but only once it uses a default implementation it trusts. Regards Dan. > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Ronald Cron via mbed-tls > Sent: 09 April 2020 08:47 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, I think this is related to the more general need for an implementation of > the C standard library for trusted firmware projects. As far as I know TF-A > and TF-M don't use the standard library provided by compilation toolchains. > The rationale is to have complete control over the trusted firmware code. > Currently they both have their own partial implementation of the parts of the > C standard library they need. > > This memory_buffer_alloc.c module in question here is another partial > implementation of the C standard library. Currently TF-A and TF-M don't > use/provide dynamic memory allocations but PSA-FF explicitly mentions that an > SPM implementation may support dynamic memory allocation. Thus it is possible > that TF-M at some point consider providing dynamic memory allocation support. > > All of this to say that a possible way forward may be to remove > memory_buffer_alloc.c from the code base when there is a C standard library > implementation common to trustedfirmware.org projects (is there already a > security oriented open source implementation out there ?). > > In Mbed TLS, it would also make sense to me to, by default, not use C > standard libraries provided by compilation toolchains > (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default). > > Thanks, Ronald. > > > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Manuel Pegourie-Gonnard via mbed-tls > Sent: 08 April 2020 12:42 > To: mbed-tls(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove memory_buffer_alloc.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > Currently the crypto library includes a module called memory_buffer_alloc.c, > disabled in the default build (config.h option MBEDTLS_MEMORY_BUFFER_ALLOC_C), > which provides implementations of calloc() and free() based on a user- > provided buffer (which could be static or on the stack), suitable for use in > the rest of the crypto, X.509 and TLS libraries as replacements to the > standard functions. > > In addition to providing replacement calloc() and free(), the module also > offers some facilities for measurement and debugging. > > We're considering dropping this module and removing it from the code base > entirely for the following reasons: > > - Memory allocators are not our core area of expertise. > > - This allocator is pretty basic and has a large allocation overhead. For > example for ECC computations, the overhead can be as large as the actual > memory used. > > - Using this allocator also tends to slow things down, so we don't run many > tests with it enabled. > > - In the future when we split between PSA Crypto on one side and Mbed TLS and > X.509 on the other, it's unclear on which side this allocator should fall. > Which can be taken as a sign that it doesn't really belong here. > > On the other hand, we're hesitating for the following reasons: > > - We know from bug reports and questions that some people are using it. > > - Unlike other modules we'd like to drop, there isn't a strong security > incentive to dropping this allocator, it's merely a matter of how we spend > our maintenance resources. > > What do you think? Should we keep maintaining this allocator as part of Mbed > TLS? Should we drop it and focus on our core instead? If you're using this > allocator, why did you pick it over other alternatives? > > Regards, > Manuel. > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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 mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Development environment: minimum tool versions

by Gilles Peskine

On 25/04/2020 23:44, Steffan Karger via mbed-tls wrote: > Hi, > > I maintain OpenVPN-NL (https://openvpn.fox-it.com), which uses mbedtls > as it's crypto library. > > On 24-04-2020 00:25, Gilles Peskine via mbed-tls wrote: >> 1. Is there any interest in the community for making sure that the build >> keeps (or starts) working on RHEL 6? > Yes, we support RHEL6 until it's retirement (30 November 2020). (…) > It would be nice if it's at least possible to build mbedtls on/for these > platforms until they go out of regular support. Preferably with their > default packages compilers. > All right, thanks for the feedback! I'm not going to promise that we'll add RHEL 6 to our CI. (Of course, in TrustedFirmware, it can happen if someone's motivated enough to contribute it and to keep maintaining it.) But let's at least not knowingly break support for CMake 2.8 yet (or GNU make 3.81 or older GCC and Clang but those are less likely to break). I expect that it will remain possible to build the library *for* ancient systems for a very long time, since all it really needs is a basic C runtime. But the tooling to build the library, or at least to do anything more than building the library (tuning the configuration, building and running tests, etc.) is slowly modernizing (the configuration script and the test building script have required Python 3 for a while now). -- Gilles Peskine Mbed TLS developer

6 years, 1 month

1
0
0 0

ECDH Computation on STM32 platform

by Abhilash Iyer

Hello, I am trying to do the ECDH shared secret computation using the mbedTLS library. I am referring to multiple examples such as ecdh_curve25519.c<https://github.com/ARMmbed/mbedtls/blob/development/programs/pkey/ecdh_curv…> and ecdh_main.c<https://github.com/SiliconLabs/peripheral_examples/blob/master/series2/se/s…>. In my case, in my application firmware, I already have a device _priv key and I receive a server_public key; both generated using a curve ECP_DP_SECP256R1 in the bootloader itself. So in the application firmware, I would like to do generate a shared secret from here on and preserve it for future use. The following is the steps that I do: 1. Create a new client context, entropy context, ctr_drbg context variables. 2. use mbedtls_"respective"_init() to initalize all the three variables 3. Seed a random number using mbedtls_ctr_drbg_seed() function. 4. load the P256 elliptic curve in client context using mbedtls_ecp_group_load() 5. Then use mbedtls_mpi_lset() to set Qp.Z =1 6. Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65); 7. Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ? 8. Then I use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z. Questions: 1. Do I need to generate a keypair for client context using mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, mbedtls_ctr_drbg_random, &ctrDrbg)? And then set pvtkey as device priv key and pub key as service pub key? 2. I see that ctx_cli.Q has two components, Q.x and Q.y. How do I extract these two values from a public key? Do I need to separately initialize them? Please let me know if the flow is correct. In all the examples, they generate a key pair and just update the public key part (Qp.X) of the key. They do not touch the private key part (d) of the key. Please confirm if I can upload my private key directly in my case. Also if my platform is a little endian, is there a recommended step before using mbedtls_mpi_read_binary_le functions? Thanks so much for your help in advance! Thanks, Abhilash From: Abhilash Iyer Sent: Monday, April 27, 2020 11:25 AM To: mbed-tls(a)lists.trustedfirmware.org Subject: Hello, I am trying to do the ECDH shared secret computation using the mbedTLS library. I am referring to multiple examples such as ecdh_curve25519.c<https://github.com/ARMmbed/mbedtls/blob/development/programs/pkey/ecdh_curv…> and ecdh_main.c<https://github.com/SiliconLabs/peripheral_examples/blob/master/series2/se/s…>. In my case, in my application firmware, I already have a device _priv key and I receive a server_public key; both generated using a curve ECP_DP_SECP256R1 in the bootloader itself. So in the application firmware, I would like to do generate a shared secret from here on and preserve it for future use. The following is the steps that I do: 1. Create a new client context, entropy context, ctr_drbg context variables. 2. use mbedtls_"respective"_init() to initalize all the three variables 3. Seed a random number using mbedtls_ctr_drbg_seed() function. 4. load the P256 elliptic curve in client context using mbedtls_ecp_group_load() 5. Then use mbedtls_mpi_lset() to set Qp.Z =1 6. Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65); 7. Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ? 8. Then I use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z. Questions: 1. Do I need to generate a keypair for client context using mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, mbedtls_ctr_drbg_random, &ctrDrbg)? And then set pvtkey as device priv key and pub key as service pub key? 2. I see that ctx_cli.Q has two components, Q.x and Q.y. How do I extract these two values from a public key? Do I need to separately initialize them? Please let me know if the flow is correct. In all the examples, they generate a key pair and just update the public key part (Qp.X) of the key. They do not touch the private key part (d) of the key. Please confirm if I can upload my private key directly in my case. Also if my platform is a little endian, is there a recommended step before using mbedtls_mpi_read_binary_le functions? Thanks so much for your help in advance! Thanks, Abhilash Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Random Number Generator module in mbed TLS

by ROSHINI DEVI

Perfect! Thanks everyone for your assistance. On Tue, Apr 28, 2020 at 1:48 PM Janos Follath via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi, > > > > Hanno described perfectly how it works and I just would like to add a > single remark. You mentioned that some of your platforms don’t have a > hardware entropy source. In cases like that, depending on your threat model > you might need to use the MBEDTLS_ENTROPY_NV_SEED feature to achieve > security. > > > > (This uses a stored secret value as a seed and on embedded systems without > a hardware entropy source it is more secure against a remote adversary than > trying to collect the entropy from the environment. On systems like that > NV_SEED can have an edge against physical attackers – compared to > attempting to collect entropy from the environment – if the seed is stored > in secure storage/internal flash.) > > > > Regards, > > Janos > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf > of Hanno Becker via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *Hanno Becker <Hanno.Becker(a)arm.com> > *Date: *Tuesday, 28 April 2020 at 07:55 > *To: *"mbed-tls(a)lists.trustedfirmware.org" < > mbed-tls(a)lists.trustedfirmware.org>, ROSHINI DEVI <roshinilachi(a)gmail.com> > *Subject: *Re: [mbed-tls] Random Number Generator module in mbed TLS > > > > Hi, > > > > Mbed TLS establishes variable-length access to random data in a three step > fashion: > > > > 1) At the bottommost layer, there is a variable number of *entropy > sources *external to the library. > > Such sources are supposed to provide some true randomness, though the > exact amount of > > entropy they contain isn't yet specified (at least to my knowledge). > > > > 2) Mbed TLS' entropy module mixes those entropy sources into a single > source of randomness. > > In contrast to the entropy sources themselves, the idea here is that, > ideally, the data obtained > > from the entropy module has full entropy. This is achieved by (a) > accumulating random data > > from available entropy sources and depending on the amount of entropy each > of them offers, > > and (b) 'mixing' them by a application of hash functions. > > > > 3) Based on true randomness, Mbed TLS' provides two implementations of > pseudo random > > number generators: CTR-DRBG and HMAC-DRBG. Those build on top of an > entropy context > > and expand the underlying randomness as standardized in NIST SP 800-90. > > > > Applications should use the PRNGs from step 3) as their actual source of > randomness, > > and not directly hook into the underlying TRNGs. > > > > Take a look at the example programs such as `ssl_client2` or `ssl_server2` > to see how this > > works practically. Also see > https://tls.mbed.org/kb/how-to/add-a-random-generator. > > > > Now specifically to your question: You should register your STM32 hardware > entropy > > as an entropy source via `mbedtls_entropy_add_source()` but not (need) to > change > > anything else in your code. In particular, steps 2) and 3) above are > entirely independent > > of the exact source of true randomness. > > > > Hope this helps, > > > > Hanno > > > ------------------------------ > > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf > of ROSHINI DEVI via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Sent:* Tuesday, April 28, 2020 6:06 AM > *To:* mbed-tls(a)lists.trustedfirmware.org < > mbed-tls(a)lists.trustedfirmware.org> > *Subject:* Re: [mbed-tls] Random Number Generator module in mbed TLS > > > > Hello, > > > > Can anyone confirm this? Its urgent. > > > > Thanks > > > > On Fri, Apr 17, 2020 at 4:50 PM ROSHINI DEVI <roshinilachi(a)gmail.com> > wrote: > > Hello, > > > > Is there any random number library available in mbedTLS? > > Right now, I am using hardware entropy in STM32 boards. > > If hardware platform changes and if there is no hardware entropy present, > then again we need to redefine the API. > > > > Thanks > > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Random Number Generator module in mbed TLS

by Janos Follath

Hi, Hanno described perfectly how it works and I just would like to add a single remark. You mentioned that some of your platforms don’t have a hardware entropy source. In cases like that, depending on your threat model you might need to use the MBEDTLS_ENTROPY_NV_SEED feature to achieve security. (This uses a stored secret value as a seed and on embedded systems without a hardware entropy source it is more secure against a remote adversary than trying to collect the entropy from the environment. On systems like that NV_SEED can have an edge against physical attackers – compared to attempting to collect entropy from the environment – if the seed is stored in secure storage/internal flash.) Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hanno Becker via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Hanno Becker <Hanno.Becker(a)arm.com> Date: Tuesday, 28 April 2020 at 07:55 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>, ROSHINI DEVI <roshinilachi(a)gmail.com> Subject: Re: [mbed-tls] Random Number Generator module in mbed TLS Hi, Mbed TLS establishes variable-length access to random data in a three step fashion: 1) At the bottommost layer, there is a variable number of entropy sources external to the library. Such sources are supposed to provide some true randomness, though the exact amount of entropy they contain isn't yet specified (at least to my knowledge). 2) Mbed TLS' entropy module mixes those entropy sources into a single source of randomness. In contrast to the entropy sources themselves, the idea here is that, ideally, the data obtained from the entropy module has full entropy. This is achieved by (a) accumulating random data from available entropy sources and depending on the amount of entropy each of them offers, and (b) 'mixing' them by a application of hash functions. 3) Based on true randomness, Mbed TLS' provides two implementations of pseudo random number generators: CTR-DRBG and HMAC-DRBG. Those build on top of an entropy context and expand the underlying randomness as standardized in NIST SP 800-90. Applications should use the PRNGs from step 3) as their actual source of randomness, and not directly hook into the underlying TRNGs. Take a look at the example programs such as `ssl_client2` or `ssl_server2` to see how this works practically. Also see https://tls.mbed.org/kb/how-to/add-a-random-generator. Now specifically to your question: You should register your STM32 hardware entropy as an entropy source via `mbedtls_entropy_add_source()` but not (need) to change anything else in your code. In particular, steps 2) and 3) above are entirely independent of the exact source of true randomness. Hope this helps, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of ROSHINI DEVI via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, April 28, 2020 6:06 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Random Number Generator module in mbed TLS Hello, Can anyone confirm this? Its urgent. Thanks On Fri, Apr 17, 2020 at 4:50 PM ROSHINI DEVI <roshinilachi(a)gmail.com<mailto:roshinilachi@gmail.com>> wrote: Hello, Is there any random number library available in mbedTLS? Right now, I am using hardware entropy in STM32 boards. If hardware platform changes and if there is no hardware entropy present, then again we need to redefine the API. Thanks 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.

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Random Number Generator module in mbed TLS

by Hanno Becker

Hi, Mbed TLS establishes variable-length access to random data in a three step fashion: 1) At the bottommost layer, there is a variable number of entropy sources external to the library. Such sources are supposed to provide some true randomness, though the exact amount of entropy they contain isn't yet specified (at least to my knowledge). 2) Mbed TLS' entropy module mixes those entropy sources into a single source of randomness. In contrast to the entropy sources themselves, the idea here is that, ideally, the data obtained from the entropy module has full entropy. This is achieved by (a) accumulating random data from available entropy sources and depending on the amount of entropy each of them offers, and (b) 'mixing' them by a application of hash functions. 3) Based on true randomness, Mbed TLS' provides two implementations of pseudo random number generators: CTR-DRBG and HMAC-DRBG. Those build on top of an entropy context and expand the underlying randomness as standardized in NIST SP 800-90. Applications should use the PRNGs from step 3) as their actual source of randomness, and not directly hook into the underlying TRNGs. Take a look at the example programs such as `ssl_client2` or `ssl_server2` to see how this works practically. Also see https://tls.mbed.org/kb/how-to/add-a-random-generator. Now specifically to your question: You should register your STM32 hardware entropy as an entropy source via `mbedtls_entropy_add_source()` but not (need) to change anything else in your code. In particular, steps 2) and 3) above are entirely independent of the exact source of true randomness. Hope this helps, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of ROSHINI DEVI via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, April 28, 2020 6:06 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Random Number Generator module in mbed TLS Hello, Can anyone confirm this? Its urgent. Thanks On Fri, Apr 17, 2020 at 4:50 PM ROSHINI DEVI <roshinilachi(a)gmail.com<mailto:roshinilachi@gmail.com>> wrote: Hello, Is there any random number library available in mbedTLS? Right now, I am using hardware entropy in STM32 boards. If hardware platform changes and if there is no hardware entropy present, then again we need to redefine the API. Thanks 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.

6 years, 1 month

1
0
0 0

Random Number Generator module in mbed TLS

by ROSHINI DEVI

Hello, Is there any random number library available in mbedTLS? Right now, I am using hardware entropy in STM32 boards. If hardware platform changes and if there is no hardware entropy present, then again we need to redefine the API. Thanks

6 years, 1 month

1
1
0 0

Edwards curve support (#3245): fixing mbedtls_ecp_get_type

by Aurelien Jarno

Hi all, I have submitted PR#3245 in order to add Edwards curves support to Mbed TLS, with the eventual goal to add support for the EdDSA algorithm. There are still a few things to fix that require discussion. Let's start the discussion with the first one. Adding a new curve type requires to add a new entry to the mbedtls_ecp_curve_type enum. The curve type used by a group is returned by the mbedtls_ecp_get_type function. It currently uses the coordinates type of the base point to determine the curve type. Montgomery curves are lacking the y coordinate, and the Short Weierstrass curves use the three x, y and z coordinates. The Edwards arithmetic implementation in this PR uses the projective coordinates. As such it also uses the x, y and z coordinates and this gives no way to differentiate a Short Weierstrass from an Edwards curve. I have currently implemented that by checking if the curves are the Ed25519 or Ed448 ones using the group id [1]. I am not sure it's very clean and it won't scale if more curves are added later. Another alternative would be to add another entry to mbedtls_ecp_group to hold the curve type. What do you think is the best option? Any other idea? Thanks, Aurelien [1] https://github.com/ARMmbed/mbedtls/pull/3245/commits/aa20cf122a1a54cfa23624… -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien(a)aurel32.net http://www.aurel32.net

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Development environment: minimum tool versions

by Steffan Karger

Hi, I maintain OpenVPN-NL (https://openvpn.fox-it.com), which uses mbedtls as it's crypto library. On 24-04-2020 00:25, Gilles Peskine via mbed-tls wrote: > 1. Is there any interest in the community for making sure that the build > keeps (or starts) working on RHEL 6? Yes, we support RHEL6 until it's retirement (30 November 2020). > 2. Is there any interest in the community for making sure that the build > keeps working on Ubuntu 16.04? Yes, we support all Ubuntu LTS versions until their standard support ends (April 2021 for 16.04). > 3. Are there any other "old" platforms that we should consider? All Debian and SLES versions that are still in regular maintance (ie, not including any "extended security maintenance" support). It would be nice if it's at least possible to build mbedtls on/for these platforms until they go out of regular support. Preferably with their default packages compilers. SLES/RHEL are the most demanding, with their 10 year support cycle. Thanks, -Steffan

6 years, 2 months

1
0
0 0

Re: [mbed-tls] RSA key generation issue

by Gilles Peskine

Hi Nazar, On 24/04/2020 10:22, Nazar Chornenkyy via mbed-tls wrote: > > On the PSoC6 device we are using mbedtls_rsa_gen_key function with a > good hardware TRNG passed FIPS 140-2 verification. > > This function verifies generated random pair and requests new pair if > they don’t follow FIPS 186-4 criteria. > > The number of verification loops is between 1 and 6 in worst case. > > Is it expected behavior? > > The arithmetic of one loop takes a lots of time. > > How can we improve the random number to have always pass FIPS 186-4 in > a one loop? > I'm not sure what you're doing. Are you calling mbedtls_rsa_gen_key() multiple times and rejecting the key if it doesn't pass additional checks? Or are you just calling it once? As far as I know, mbedtls_rsa_gen_key() follows the procedure described in FIPS 186-4 (which is compatible with previous versions of FIPS 186), and no additional checks should be needed. If you're calling it once and observing that it tries multiple values of p and q before finding a suitable one, this is expected behavior. There's no way to "improve" the random numbers to make it faster: the probability that a pair of (probabilistic) primes can work together as an RSA key is less than 1. I don't know the math off the top of my head, but 1–6 tries seems reasonable. Key generation is the slowest of the RSA operations. If that's a problem in your application, consider using elliptic curve cryptography instead. ECC has very fast key generation, faster private key operations (signature, decryption) than RSA, and smaller keys. The main benefit of RSA is that public key operations (verification, encryption) are faster. -- 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.

6 years, 2 months

1
0
0 0

Development environment: minimum tool versions

by Gilles Peskine

Hello, I'm starting this thread to get input from the community about what versions of compilers and other build tools Mbed TLS should support. We of course strive to remain compatible with the latest versions, so this discussion is about support for older versions. We currently don't really have an official version range for the build dependencies of Mbed TLS: * C compilers (GCC, Clang, Arm Compiler, IAR, Visual Studio) * Build tools (GNU make, CMake) * Scripting tools (shell, Perl, Python) In practice, for the past three years or so, most of our continuous integration has been running on Ubuntu 16.04, so we mostly test with GCC 5.4.0, Clang 3.8, GNU make 4.1, CMake 3.5.1 and Python 3.5. (For shell and Perl, even pretty ancient version should work.) For Arm Compiler (armcc/armclang) and IAR, we use the same version as Mbed OS. On Windows, we currently test Visual Studio 2013, 2015 and 2017, as well as a version of Mingw that's changed more quickly than most of the rest of our CI. We also run some tests on FreeBSD (a bit more recent that the Ubuntu machines). The top-level CMakeLists.txt has conditionals that detect much older versions of CMake, GCC and Clang, but we haven't tested those in ages and we don't really know if, for example, the library still builds with CMake 2.8 and GCC 4.2. As part of the move of the project from Arm to Trusted Firmware, we'll change our CI infrastructure, and this may or may not mean we end up testing with different versions. In https://github.com/ARMmbed/mbedtls/issues/2896 I looked at the software versions in some common "slow updating" operating systems: RHEL/Centos, Ubuntu LTS. 1. Is there any interest in the community for making sure that the build keeps (or starts) working on RHEL 6? 2. Is there any interest in the community for making sure that the build keeps working on Ubuntu 16.04? 3. Are there any other "old" platforms that we should consider? 4. Should we consider older compilers (maybe some platforms are stuck with older versions of GCC)? 5. On Windows, what's the oldest version of Visual Studio we should keep compatibility with? -- 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.

6 years, 2 months

1
0
0 0

RSA key generation issue

by Nazar Chornenkyy

Hi I found this email on ARM MBED support forum. Could you help to resolve our issue? On the PSoC6 device we are using mbedtls_rsa_gen_key function with a good hardware TRNG passed FIPS 140-2 verification. This function verifies generated random pair and requests new pair if they don't follow FIPS 186-4 criteria. The number of verification loops is between 1 and 6 in worst case. Is it expected behavior? The arithmetic of one loop takes a lots of time. How can we improve the random number to have always pass FIPS 186-4 in a one loop? Thanks Nazar This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move net.c out of the library

by Gilles Peskine

Like with timing (see my message in the timing thread, https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000061.html), I have a strong preference for the library to be usable out of the box on typical platforms. This means keeping the abstractions that are currently in the net_sockets module, or similar abstractions. This doesn't mean keeping the net_sockets module as such: these abstractions could be in platform.c. I lean towards having a platform_posix.c and a platform_windows.c (and any other we care to support), chosen at build time based on the target platform. I'm not sure exactly what they should look like. In particular, if you have an embedded platform that's sort of POSIX-like, but doesn't have every POSIX feature and does a few differently, should you be able to customize platform_posix.c through #defines, or should you copy it and modify it to suit your platform? -- Gilles Peskine Mbed TLS developer On 20/04/2020 11:52, Manuel Pegourie-Gonnard via mbed-tls wrote: > Hi all, > > [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] > > Currently the SSL/TLS library includes a module called net_sockets.c (formerly > net.c), enabled by default in config.h (but disabled by config.py baremetal), > that contains some networking functions based on POSIX or Windows sockets, > including functions suitable for use as I/O callbacks with our SSL/TLS > modules. > > Those functions are used only in example/testing programs, but nowhere in the > library itself. > > In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, > we're considering removing (parts of) this module from the library, and > moving its parts to a variety of other places, such as example programs (or > a library/file shared by them, like the current query_config mechanism). > > Reasons for removing this module from the library include: > > - overall the module is less portable and perhaps of lesser quality than the > rest of the library > - it's currently entirely untested on Windows (despite being very > platform-specific) > - there are often confusions about whether the module is meant to be a > general-purpose networking library, or just provide basic support for our > example and test, as well a simple prototypes > - it's not our core area of expertise, let's do one thing and to it well > > Reasons for keeping (parts of) it in the library include: > > - having mbedtls_net_recv{,_timeout}() and mbedtls_net_send() available right > in the library makes it easier to test and develop prototype > - this module is listed as a component in our high-level design document [2], > so perhaps removing it from the library can be seen as a bigger change? > > [2]: https://tls.mbed.org/high-level-design > > What do you think? Should we remove the entire module from the library, keep > it all, or just keep some parts? In that case, which parts and where? > > Regards, > Manuel. 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Gilles Peskine

I have a strong preference for the library, the tests and companion programs to build out of the box on officially supported platforms. On platforms that don't work out of the box, users should be able to drop in platform support code in the form of #defines or extra modules to link with. Ok, we don't have an official list of supported platforms. But inasmuch as we do have officially supported platforms, they include Linux and other modern Unix-like or POSIX environments, Windows, and Mbed OS. Mbed OS is a special case because Mbed TLS is part of the build tree there, so the mbedtls tree doesn't have to contain Mbed OS support. This doesn't mean that the library should have a timing module. I think the timing wrappers that the library needs, i.e. mbedtls_timing_{get,set}_delay, should be in platform.c. For platform features that are only used by test or sample programs, I think we should have a separate platform support file, and separate #defines so that you can build the library even if you can't build all the programs. For example, it makes sense to build DTLS support without having the timing functions used by the benchmark program. -- Gilles Peskine Mbed TLS developer On 21/04/2020 10:46, Manuel Pegourie-Gonnard via mbed-tls wrote: > Hi all, > > So personally I'm quite strongly inclined to remove timing.c from the > library, and move most of its content elsewhere, with one possible > exception: > >> - mbedtls_timing_set_delay() and mbedtls_timing_get_delay() are an example >> implementation (only for Unix and Windows) of timer callbacks for DTLS, only >> used in programs/ssl/*.c > Since timer callbacks are a hard requirement for using DTLS, and it seems > quite desirable to be able to support DTLS out of the box at least on > some platforms, I was thinking this pair of function (and the associated > context type) could be kept in the library, in a new module that would > be called something like ssl_dtls_timer.c. > > This would be somewhat similar to ssl_cookies.c, ssl_tickets.c and > ssl_cache.c: they all provide implementations of callbacks that can be > used with the main SSL/(D)TLS module, but users are obviously free to > compile them out and use their own implementation if the one we provide > does not meet their needs. > > As it happens, all three of these support modules work best if > MBEDTLS_HAVE_TIME is defined, but can work without it. > > For the new ssl_dtls_timer.c I'm suggesting, the situation would be > different: the module could have a hard dependency on MBEDTLS_HAVE_TIME, > but work better on selected platforms (say, C11, POSIX and > Windows) where we know how to access sub-second timing information. (Or > alternatively, have a hard dependency on C11-or-Posix-or-Windows.) > > For the record, mbedtls_ssl_conf_handshake_timeout() accepts timeout > values in milliseconds, but recommended values for use over the general > internet start at 1 second: > https://tools.ietf.org/html/rfc6347#section-4.2.4.1 > So it might make sense to provide this module even when we only have > second resolution - we'd just have to work out how the timer function > would behave when passed sub-second values. (My first thought it > rounding up to the next second would be quite OK.) > > What do you'all think? Personnally, I don't have a strong opinion > between the three following options, though I have a slight preference > for the first one: > > 1. Provide ssl_dtls_timer.c in the library with hard dep on HAVE_TIME > and enhanced features with C11/Posix/Windows. > 2. Provide ssl_dtls_timer.c in the library with hard dep on > C11/Posix/Windows. > 3. Move it all out of the library and let the thing live somewhere under > programs/ as it's only used by example/testing programs. > > Note though that we could also choose to go with option 3 for Mbed TLS > 3.0, see how it goes, and later switch to option 2 or 1 if we want, as > adding modules can be done at any time. (In the same vein, we could > start with 2 and switch to 1 at any time as well.) > > Regards, > Manuel. 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

Hi, > [I'm assuming didn't mean to reply on the list and not just to me, so I'm replying on the list.] Oops, I misinterpreted the information presented by my mail client, you did reply on the list. Sorry for the noise (and for breaking the thread by not replying to the correct email.) Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move net.c out of the library

by Manuel Pegourie-Gonnard

Hi again, In the first email of the thread I tried giving a fair exposition of the question, now I'm going to give my personal opinion. Similarly to what I suggested for timing.c, I'm inclined to remove net.c as such, move most of its content (net_bind(), net_accept(), etc.) out of the library (most probably into a new file in programs/ssl, shared by SSL examples), and keep in the library only the 3 functions that can be used as SSL callbacks (and a supporting context type), but in a new module named for example ssl_io_sockets.c. This would also be similar to the other SSL modules that provide a reference/example implementation of some SSL callback but can easily be disabled (or jsut disregarded) in favour of a custom implementation for custom needs or unsupported platforms. Just like the current net_sockets.c, this new reduced module would probably only be supported on platforms with sockets, which is Posix platforms and Windows. Advantages include: - Reduce the amount of code and API surface in the library. Things like binding and accepting are hardly related to (D)TLS so there is little justification for having them in the library. Also, things in the library are bound by API stability rules which are sometimes a constraint. - It would clarify that we're not providing a general-purpose socket abstraction, as general socket management would be out of the library, and only the bits for plugging a socket into our SSL layer would be in the library. - (By the way currently net_sockets.h includes ssl.h, so it's already quite specific to our SSL module rather than generic, but moving the remaining bits of it into the SSL namespace would make that clearer.) - User would still have the convenience (on supported platforms) of ready-for-use callbacks. If you have an application already working with sockets without TLS, then we provide all the bits needed to turn that into an application using TLS on top of those sockets. I think that would be a good compromise between convenience for users, and reduced surface for the library. Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move certs.c out of the library

by Hanno Becker

Hi, I support this. Could certs.c live in `tests/data_files`? We should also make sure this file is automatically synced with the actual CRT and key files in that directory. There is a script which does that, but IIRC it's not called as part of the CI, which lead to certs.c and the data files get out of sync multiple times in the past. Best Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Manuel Pegourie-Gonnard via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Monday, April 20, 2020 10:49 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [mbed-tls] 3.0 plans - move certs.c out of the library Hi all, In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we move certs.c out of the library? [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ Currently the X.509 library includes test certificates and keys, which are enabled by default in config.h - `MBEDTLS_CERTS_C`. These are used in the following places: - in library/x509.c in mbedtls_x509_self_test() - in tests/suites/test_suite_ssl.function - in programs/fuzz and programs/ssl In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we'd like to remove certs.h and the certificates it contains from the library (except perhaps one static cert for mbedtls_x509_self_test()). Tests and example programs that need built-in certificates could still get them using any mechanism, included a file certs.c similar to the current one - but this file would no longer live in library or be included when building libmbedx509. Reasons include: - Including test certificates and keys in the library provides little value, as users will want to use their own certificates and keys anyway. - Shipping private keys as part of the library is bad practice, even under the `mbedtls_test_` sub-namespace. There's a slight risk that some users could use them for prototyping and then inadvertently keep using unsafe private keys in production. If you disagree or have concerns, please speak up! Also, if want to suggest ideas for where the replacement to library/certs.c should live or how it could be maintained, now's a good time as well! Regards, Manuel. -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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.

6 years, 2 months

2
1
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

Hi all, So personally I'm quite strongly inclined to remove timing.c from the library, and move most of its content elsewhere, with one possible exception: > - mbedtls_timing_set_delay() and mbedtls_timing_get_delay() are an example > implementation (only for Unix and Windows) of timer callbacks for DTLS, only > used in programs/ssl/*.c Since timer callbacks are a hard requirement for using DTLS, and it seems quite desirable to be able to support DTLS out of the box at least on some platforms, I was thinking this pair of function (and the associated context type) could be kept in the library, in a new module that would be called something like ssl_dtls_timer.c. This would be somewhat similar to ssl_cookies.c, ssl_tickets.c and ssl_cache.c: they all provide implementations of callbacks that can be used with the main SSL/(D)TLS module, but users are obviously free to compile them out and use their own implementation if the one we provide does not meet their needs. As it happens, all three of these support modules work best if MBEDTLS_HAVE_TIME is defined, but can work without it. For the new ssl_dtls_timer.c I'm suggesting, the situation would be different: the module could have a hard dependency on MBEDTLS_HAVE_TIME, but work better on selected platforms (say, C11, POSIX and Windows) where we know how to access sub-second timing information. (Or alternatively, have a hard dependency on C11-or-Posix-or-Windows.) For the record, mbedtls_ssl_conf_handshake_timeout() accepts timeout values in milliseconds, but recommended values for use over the general internet start at 1 second: https://tools.ietf.org/html/rfc6347#section-4.2.4.1 So it might make sense to provide this module even when we only have second resolution - we'd just have to work out how the timer function would behave when passed sub-second values. (My first thought it rounding up to the next second would be quite OK.) What do you'all think? Personnally, I don't have a strong opinion between the three following options, though I have a slight preference for the first one: 1. Provide ssl_dtls_timer.c in the library with hard dep on HAVE_TIME and enhanced features with C11/Posix/Windows. 2. Provide ssl_dtls_timer.c in the library with hard dep on C11/Posix/Windows. 3. Move it all out of the library and let the thing live somewhere under programs/ as it's only used by example/testing programs. Note though that we could also choose to go with option 3 for Mbed TLS 3.0, see how it goes, and later switch to option 2 or 1 if we want, as adding modules can be done at any time. (In the same vein, we could start with 2 and switch to 1 at any time as well.) Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

Hi Torsten, [I'm assuming didn't mean to reply on the list and not just to me, so I'm replying on the list.] > On 20/04/2020 11:51, Manuel Pegourie-Gonnard via mbed-tls wrote: >> For reference, this module includes the following functions, which are used >> in the following places: >> >> - mbedtls_timing_hardclock() implements cycle counting (on selected >> architectures, not including M-class), used only in >> programs/test/benchmark.c > > I used mbedtls_timing_hardclock() for my own benchmarking experiments on > Linux and Windows, but couldn't get it to run on the target machine. So > I've use my own ms counter instead. So, it could be easily removed as > part of the library. > Good to know, thanks for sharing this data point. > Question: How do you want to do the benchmarking instead? With the same > code, but outside the library? > Yes, I was thinking that the functions that are only used in benchmark.c could be defined in benchmark.c, and the functions that are only used in udp_proxy.c could be defined in udp_proxy.c. (Or actually for the latter, we might want to start using them in ssl_client2.c and ssl_server2.c as well, as including millisecond timestamps in the debug output would be usefull to debug some issues. In that case, we'll probably put those functions in a new file, used by udp_proxy, ssl_client2 and ssl_server2 (just like query_config.c is currently used by ssl_client2, ssl_server2 and query_compile_time_config).) Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] Some thoughts towards mbed TLS 3.0

by Manuel Pegourie-Gonnard

Hi Torsten, > this will be a long mail. Sorry for that. > On the contrary, thank you so much for this extensive and well though-out feedback, that's very helpful! I'll try to complement Gilles's reply, and skip the points he already answered unless I have something to add, as I'm generally in full agreement with what he wrote. > 3. For certification and evaluation purposes I need some test vectors > for each crypto function on target. While I know about the > comprehensive self-test program I'm now talking about built-in > functions like mbedtls_sha512_self_test(), etc to be enabled with > #define MBEDTLS_SELF_TEST. > > These self-tests are very different in coverage. For SHA-384 and > SHA-512 they are fine, for HMAC-SHA-384 and HMAC-SHA-512 I couldn't > find any as well as for HKDF-HMAC-SHA-256 (in RFC 5869) or > HKDF-HMAC-SHA-384/512 (official test vectors difficult to find). > AES-CTR and AES-XTS are only tested with key length 128 bit, not with > 256 bit. AES-CCM is not tested with 256 bit and even for 128 bit, > the test vector from the standard NIST SP 800-38C with long > additional data is not used. > The builtin self-test for GCM is the best I've seen with mbedtls: > all three key lengths are tested as well as the IUF-interface and > the comfort function. Bravo! > Indeed so far we don't have clear guidelines on self-test functions, and we should try to have more consistency here. Since this is incremental, backwards-compatible improvements, it can be done at any time (unlike some API improvements that can only be done when preparing major versions). Contributions in this area are certainly welcome! > 7. While at Elliptic Curve Cryptography: I assume that some of you > know that projectives coordinates as outer interface to ECC are > dangerous, see David Naccache, Nigel P. Smart, Jacques Stern: > Projective Coordinates Leak, Eurocrypt 2004, pp. 257–267. Yes, and as it happens this was revisited recently by researchers, and brought back to our attention: https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi… > you have Jacobian coordinates, i.e. projective coordinates, as outer > interface. In the comment, its is noted that only the affine part is > used, but can this be assured? In all circumstances? > In practice, I'm pretty confident this is the case, because both ecp_normalize_jac() and ecp_normalize_mxz() set Z to 1, these functions are always called before returning data, and if we forgot to call those functions, we'd get incorrect X and Y coordinates and fail unit test and interop tests. But as a matter of principle, I agree that exposing Jacobian coordinates in the API was a poor decision. Fortunately, we already intended to start phasing out the existing ECP interface in 3.0 (to which extend exactly is still to be discussed), and in the future is should be fully removed in favour of the PSA Crypto API, which doesn't have this problem. > 8. In my personal opinion the definition > [...] > mbedtls_ecp_keypair; > > is dangerous. Why not differentiate between private and public key > and domain parameters? I agree, and I think it's a generally accepted opinion in the crypto implementation community that private and public keys should be clearly distinguished from one another, for example by using distinct types (in typed languages). This is by the way a long-standing problem that existed in the RSA module from the start, and when ECC was added it followed a similar pattern. Again, I think the transition of the PSA Crypto API is going to be the answer here, as it will provide much cleaner key management. > 9. Regarding ECC examples: I found it very difficult that there isn't > a single example with known test vectors as in the relevant crypto > standards, i.e. FIPS 186-4 and ANSI X9.62-2005, with raw public > keys. What I mean are (defined) curves, public key value Q=(Qx,Qy) > and known signature values r and s. In the example ecdsa.c you > generate your own key pair and read/write the signature in > serialized form. In the example programs/pkey/pk_sign.c and > pk_verify.c you use a higher interface pk.h and keys in PEM format. > > So, it took me a while for a program to verify (all) known answer > tests in the standards (old standards as ANSI X9.62 1998 have more > detailed known answer tests). One needs this interface with raw > public keys for example for CAVP tests, see The FIPS 186-4 Elliptic > Curve Digital Signature Algorithm Validation System (ECDSA2VS). > > 11. In the moment, there is no single known answer tests for ECDSA > (which could be activated with #define MBEDTLS_SELF_TEST). I > wouldn't say that you need an example for every curve and hash > combination, as it is done in ECDSA2VS CAVP, but one example for > one of the NIST curves and one for Curve25519 and - if I have a > wish free - one for Brainpool would be fine. And this would solve > #9 above. > I might be misunderstanding, but isn't the function ecdsa_prim_test_vectors() in tests/suites/test_suite_ecdsa.function close to what you're looking for? I mean, except for the fact that it's not in the self-test function, and that it's using data from RFCs rather than from NIST or ANSI? But I agree this is a bit messy and could be made cleaner. Also, if you ever feel like contributing your dream self-test function for ECDSA as PR, this will be a very welcome contribution! > 13. Feature request: Since it was irrelevant for my task (only > verification, no generation) I didn't have a detailed look a your > ECC side-channel countermeasures. But obviously you use the same > protected code for scalar multiplication in verify and sign, > right? Wouldn't it be possible to use Shamir's trick in > verification with fast unprotected multi-scalar multiplication. In > the moment, mbedtls_ecdsa_verify is a factor 4-5 slower than > mbedtls_ecdsa_sign, while OpenSSLs verify is faster than sign. > Yes, this was done to save both on code size and developer time, but I agree it's suboptimal for performance. As Gilles wrote, as a general rule we tend to favour code size and security/maintainability over performance, but in that instance if we provide an option for a verify-only ECDSA build (which I agree we should), then we're likely to reach smaller code size by having a standalone unprotected implementation of multi-scalar multiplication, so that would probably be a great option: better performance _and_ smaller code. Unfortunately we're already quite busy with other things, so this kind of optimisation will probably have to wait for a bit more, but we're taking good note of the suggestion and will try to implement it in the future. Again, thanks for this comprehensive and useful feedback. Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Torsten Schuetze

On 20/04/2020 11:51, Manuel Pegourie-Gonnard via mbed-tls wrote: > [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] > > Currently the crypto library includes a module called timing.c, enabled by > default in config.h (but disabled by config.py baremetal), containing various > functions related to timing (not to be confused with the time abstration > present in the platorm module). > > In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, > we're considering removing (parts of) this module from the library, and > moving its parts to a variety of other places, such as example programs (or > a library/file shared by them, like the current query_config mechanism). > > For reference, this module includes the following functions, which are used in > the following places: > > - mbedtls_timing_hardclock() implements cycle counting (on selected > architectures, not including M-class), used only in > programs/test/benchmark.c I used mbedtls_timing_hardclock() for my own benchmarking experiments on Linux and Windows, but couldn't get it to run on the target machine. So I've use my own ms counter instead. So, it could be easily removed as part of the library. Question: How do you want to do the benchmarking instead? With the same code, but outside the library? Torsten

6 years, 2 months

1
0
0 0

3.0 plans - move net.c out of the library

by Manuel Pegourie-Gonnard

Hi all, [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] Currently the SSL/TLS library includes a module called net_sockets.c (formerly net.c), enabled by default in config.h (but disabled by config.py baremetal), that contains some networking functions based on POSIX or Windows sockets, including functions suitable for use as I/O callbacks with our SSL/TLS modules. Those functions are used only in example/testing programs, but nowhere in the library itself. In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we're considering removing (parts of) this module from the library, and moving its parts to a variety of other places, such as example programs (or a library/file shared by them, like the current query_config mechanism). Reasons for removing this module from the library include: - overall the module is less portable and perhaps of lesser quality than the rest of the library - it's currently entirely untested on Windows (despite being very platform-specific) - there are often confusions about whether the module is meant to be a general-purpose networking library, or just provide basic support for our example and test, as well a simple prototypes - it's not our core area of expertise, let's do one thing and to it well Reasons for keeping (parts of) it in the library include: - having mbedtls_net_recv{,_timeout}() and mbedtls_net_send() available right in the library makes it easier to test and develop prototype - this module is listed as a component in our high-level design document [2], so perhaps removing it from the library can be seen as a bigger change? [2]: https://tls.mbed.org/high-level-design What do you think? Should we remove the entire module from the library, keep it all, or just keep some parts? In that case, which parts and where? Regards, Manuel.

6 years, 2 months

1
0
0 0

3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

[ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] Currently the crypto library includes a module called timing.c, enabled by default in config.h (but disabled by config.py baremetal), containing various functions related to timing (not to be confused with the time abstration present in the platorm module). In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we're considering removing (parts of) this module from the library, and moving its parts to a variety of other places, such as example programs (or a library/file shared by them, like the current query_config mechanism). For reference, this module includes the following functions, which are used in the following places: - mbedtls_timing_hardclock() implements cycle counting (on selected architectures, not including M-class), used only in programs/test/benchmark.c - mbedtls_timing_get_timer() is a millisecond counter (only for Unix and Windows), used only in programs/test/udp_proxy.c - mbedtls_set_alarm() is an abstraction of alarm() (only for Unix and Windows), used only in programs/test/benchmark.c - mbedtls_timing_set_delay() and mbedtls_timing_get_delay() are an example implementation (only for Unix and Windows) of timer callbacks for DTLS, only used in programs/ssl/*.c Reasons for removing this module from the library include: - overall the module is less portable and of lesser quality than the rest of the library - it's also very hard to test and we've lost a lot of time and energy to that, with very limited success - it doesn't really belong in libmbedcrypto - it's not our core area of expertise, let's do one thing and to it well Reasons for keeping (parts of) it in the library include: - for mbedtls_timing_set_delay() and mbedtls_timing_get_delay(): they're convenient to have for DTLS examples and prototyping, we could keep them in some place in libmbedtls (not libmbedcrypto). What do you think? Should we remove the entire module from the library, or keep some parts? In that case, which parts and where should they live? Regards, Manuel.

6 years, 2 months

1
0
0 0

3.0 plans - move certs.c out of the library

by Manuel Pegourie-Gonnard

Hi all, In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we move certs.c out of the library? [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ Currently the X.509 library includes test certificates and keys, which are enabled by default in config.h - `MBEDTLS_CERTS_C`. These are used in the following places: - in library/x509.c in mbedtls_x509_self_test() - in tests/suites/test_suite_ssl.function - in programs/fuzz and programs/ssl In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we'd like to remove certs.h and the certificates it contains from the library (except perhaps one static cert for mbedtls_x509_self_test()). Tests and example programs that need built-in certificates could still get them using any mechanism, included a file certs.c similar to the current one - but this file would no longer live in library or be included when building libmbedx509. Reasons include: - Including test certificates and keys in the library provides little value, as users will want to use their own certificates and keys anyway. - Shipping private keys as part of the library is bad practice, even under the `mbedtls_test_` sub-namespace. There's a slight risk that some users could use them for prototyping and then inadvertently keep using unsafe private keys in production. If you disagree or have concerns, please speak up! Also, if want to suggest ideas for where the replacement to library/certs.c should live or how it could be maintained, now's a good time as well! Regards, Manuel.

6 years, 2 months

1
0
0 0

Session resumption + PSKs in Mbed TLS 3.X

by Hanno Becker

Hi all, I would like to bring up the following: (How) Shall the APIs for PSKs and TLS session resumption be modified in Mbed TLS 3.0? The motivation for this question is the consolidation of PSKs, ticket-based resumption and session-id-based resumption in TLS 1.3. Now, while there will be no TLS 1.3 support in Mbed TLS 3.0 as it stands, I think it would be beneficial to make the API amenable to TLS 1.3 as much as possible already now. Finding the right API here is non-trivial, and I'll describe first how the current API works and how TLS 1.2 and 1.3 differ, before making suggestions on how the Mbed TLS 3 API might look like. The mail is therefore quite long, but I hope you'll bear with me. # Session Resumption in Mbed TLS 2.X Recall how resumption works in Mbed TLS 2.X on the client: 1. Establish a connection as usual 2. Store established session for later re-use `mbedtls_ssl_session_save()` saves connection parameters relevant for session resumption in an instance of `mbedtls_ssl_session`. Optional: 2.1: Serialize session for offline storage 2.2: Deserialize session 3. Loading a stored session `mbedtls_ssl_session_load()` is called on the stored session after initialization and before running the handshake via `mbedtls_ssl_handshake()`. 4. Connect using stored session Run `mbedtls_ssl_handshake()` as usual. To my knowledge, the following is transparent to the user: * The means by which resumption is achieved, which can be either id- or ticket-based. * Whether the session was resumed or not - there is a silent fallback to a full handshake when session resumption is rejected by the server. On the server, ticket- and id-based resumption are configured independently as follows: - ID-based resumption is controlled via `mbedtls_ssl_conf_session_cache()` - Ticket-based resumption is controlled via `mbedtls_ssl_conf_session_tickets_cb()`. # PSKs in Mbed TLS 2.X Coming to PSKs: First, recall that, under the hood, resumed connections establish a master secret purely on the basis of a previous master secret, without resorting to asymmetric crypto. The same is true for PSK-based connections, and this observation is embodied in TLS 1.3 which, as mentioned, consolidates resumption and PSKs. In TLS 1.2, though, PSKs and session resumption are different, and consequently Mbed TLS handles them through a separate API `mbedtls_ssl_conf_psk()`, which takes the PSK identifier and the PSK itself. Side-question: Should this apply to the SSL configuration or the SSL context? It seems to me that somebody might want to run multiple PSK-based connections with different PSKs, but same configuration otherwise. At the moment, this would require a configuration per connection. Maybe this decision of what belongs at the level of the config could be thoroughly discussed independently? # PSKs in TLS 1.3 In TLS 1.3, all kinds of resumptions are hanlded ander the umbrella of PSKs: The client offers PSK identities in its ClientHello, the server picks one or leaves it, and the master secret for the connection is derived from the PSK associated with the PSK identity. Underlying this is some form of translation `PSK-Identity -> PSK` on the server which allows to derive the PSK from the PSK identity. How this mapping is realized is entirely implementation-specific, but it can take at least the following forms, giving back all forms of session resumption: - 'PSK Identity -> PSK' via database lookup: This subsumes classical PSKs and ID-based resumption, since the data necessary to resume a session is stored on the server. - 'PSK Identity -> PSK' via AEAD: The PSK can be encoded in the PSK identity itself by using some authenticated encryption of the PSK as the PSK identity, the key for which resides on the server. This subsumes Ticket-based resumption. There are the following noteworthy differences, though: 1. In TLS 1.2, the server provides a 'PSK identity hint' and the client picks a particular PSK identity. In TLS 1.3, the client offers a _list_ of PSKs, and the server picks one or none. 2. In TLS 1.2, the server can issue only a single session ticket. In TLS 1.3, the server can issue as many session tickets as he wishes, and the client can use any of those for later session resumption. This has the following consequences for the API: 1. The PSK-configuration API must allow the configuration of multiple PSKs on the client. 2. There must be a means to export more than one session ticket for later resumption. # API considerations for Mbed TLS 3.X ## Part 1: Load/Save API In essence, keep the flow of `mbedtls_ssl_session_load/save()`, but make the following adjustments. Whether the target structure remains `mbedtls_ssl_session` and how it looks like internally isn't relevant at this point and is up to discussion. 1. It must be possible 'save' a session multiple times, which in TLS 1.3 amounts to exporting the tickets issued by the server one-by-one. This can be realized in a variety of ways, for example: - Allow calling `mbedtls_ssl_session_save()` multiple times, and modify its semantics from the idempotent nature of Mbed TLS 2.X to iterating through the available tickets, and returning an error when no more tickets are available. This has the benefit that it likely requires no code change for users migrating from Mbed TLS 2.X, since a change is needed only when an application stores a single session multiple times, which could be done by calling `mbedtls_ssl_session_save()` multiple times before, while now one would need to call it once and manually replicate the obtained session structure. On the negative side, this wastes memory for applications not interested in session resumption, or those that only need a single ticket. We don't want the server to be able to flood the client with arbitrarily many tickets. - Allow registering a callback that's triggered whenever a new ticket arrives. The drawback of this is that it is larger deviation from the Mbed TLS 2.X API. On the positive side, applications that don't need tickets, or only need a limited number of such, can simply drop further tickets and thereby prevent allocating RAM for them. 2. It must be possible to 'load' multiple sessions, meaning that the client should offer any of them to the server for resumption. ## Part 2: Consolidation with PSK Make it possible to setup an `mbedtls_ssl_session` (or whatever it will be called) structure manually from an externally PSK provisioned PSK, and allow loading this session for resumption as above, via one of potentially many calls to `mbedtls_ssl_session_load()`. There are multiple variants to this, for example: 1. Make `mbedtls_ssl_session` transparent so users can build it manually by filling the respective fields. 2. Provide a helper API to build a session from a PSK. The old API `mbedtls_ssl_conf_psk()` can then be _derived_ from this for convenience, building a session from the provided PSK and loading it, in a single API. Before going into further details and making the mail even longer: What do you think of this approach? Do you see alternatives? Best, Hanno 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] Some thoughts towards mbed TLS 3.0

by Gilles Peskine

Wow! First, thanks for this extensive feedback! That's very helpful, and appreciated. I'm going to reply to a few points. On a general note, you can see headlines for the main topics we're currently planning to work on in the Mbed TLS roadmap at https://developer.trustedfirmware.org/w/mbed-tls/roadmap/ . Please note that everything I write is based on current plans, which may change through the TrustedFirmware planning process or if real life shows that a current plan is not doable. Over time, we're transitioning the API for the crypto part of the library from the current mbedtls_xxx functions to psa_xxx, which have a somewhat different philosophy: less exposure of internals, more protection against misuse, no reliance on malloc. Mbed TLS 3.0 will start the transition. On 14/04/2020 21:10, Torsten Schuetze via mbed-tls wrote 1. I really missed an Initialize, Update, Finalize (IUF) interface for CCM. For GCM, we have mbedtls_gcm_init(), mbedtls_gcm_setkey(), mbedtls_gcm_starts(), mbedtls_gcm_update() iterated, mbedtls_gcm_finish(), mbedtls_gcm_free() or the comfort functions mbedtls_gcm_crypt_and_tag() and mbedtls_gcm_auth_decrypt(). For CCM, only mbedtls_ccm_init(), mbedtls_ccm_setkey(), mbedtls_ccm_encrypt_and_tag() or mbedtls_ccm_auth_decrypt() and mbedtls_ccm_free(). With this interface it was only possible to encrypt and tag 128 kByte on my target system, while with GCM I could encrypt much larger files. see Github issue #662 and my comment there In Mbed TLS 3.0, mbedtls_ccm_xxx() will not be a public interface anymore. We are planning to add support for multipart CCM in the psa_aead_xxx() interface (the prototypes are already in psa/crypto.h but their implementation is planned for some time in the next few months). We are not currently planning to add support for multipart CCM through mbedtls_cipher_xxx(), which in Mbed TLS 3 will be legacy functions. However, we would probably accept such support if it was contributed externally. 2. The next step, of course, is to integrate this into the higher mbedtls_cipher layer. Regarding higher, abstract layers: I often didn't understand which interface I was supposed to use. In general, I like to use the lowest available interface, for example, #include "mbedtls/sha512.h" when I want to use sha512. However, if I need HMAC-SHA-512 or HKDF-HMAC-SHA-512 then I have to use the interface in md.h. For hash functions this is fine. Almost all hash functions are supported via md.h. (I missed SHA-512/256 which is sometimes preferable to SHA-256 on 64bit systems). But with cipher.h, I can only access Chacha20Poly1305 and AES-GCM, not AES-CCM. In Mbed TLS 3, there will generally be a single public layer. Exposing lower layers helps with code size on resource-constrained devices, but it also has downsides, including locking down the APIs. 4. That I couldn't configure AES-256 only, i.e. without AES-128 and AES-192, was to be expected (and the code overhead is not that much). But in modern modes of operations nobody needs AES decryption, only the forward direction. Sometimes modern publications as Schwabe/Stoffelen "All the AES you need on Cortex-M3 and M4" provide only the forward direction. So, it would be fine if one could configure an AES (ECB) encryption only without decryption. Of course, this is only possible if we don't use CBC mode, etc. This wouldn't only save the AES decryption code but also the rather large T-tables for decryption. For information, there is a branch of Mbed TLS called "baremetal", forked from Mbed TLS 2.16, which you can find on GitHub: https://github.com/ARMmbed/mbedtls/blob/baremetal . This branch is optimized for small code size, sometimes at the expense of speed and often at the expense of features. It has build options MBEDTLS_AES_ONLY_ENCRYPT and MBEDTLS_AES_ONLY_128_BIT_KEY_LENGTH. However I would not recommend using it in production because Arm (who still maintain this branch even after Mbed TLS itself has moved to TrustedFirmware) does not make any promise of stability. A feature that you rely on may be removed without notice. I mention this branch because eventually, we do plan to port the improvements that don't sacrifice features to the Mbed TLS development branch. I can't give a timeline for this however. With the current Mbed TLS, if you don't use CBC, I think you can save some code in aes.o by defining MBEDTLS_AES_DECRYPT_ALT and MBEDTLS_AES_SETKEY_DEC_ALT and providing functions mbedtls_aes_setkey_dec() and mbedtls_internal_aes_decrypt() that do nothing. 5. Regarding AES or better the AES context-type definition [snip] 6. In general, the contexts of mbedTLS are rather full of implementation specific details. Most extreme is mbedtls_ecp_group in ecp.h. Wouldn't it be clearer if one separates the standard things (domain parameters in this case) from implementation specific details? As a general design principle, context types in Mbed TLS 3 will be opaque. This will let us, for example, redesign mbedtls_aes_context and mbedtls_cipher_context. 9. Regarding ECC examples: I found it very difficult that there isn't a single example with known test vectors as in the relevant crypto standards, i.e. FIPS 186-4 and ANSI X9.62-2005, with raw public keys. What I mean are (defined) curves, public key value Q=(Qx,Qy) and known signature values r and s. In the example ecdsa.c you generate your own key pair and read/write the signature in serialized form. In the example programs/pkey/pk_sign.c and pk_verify.c you use a higher interface pk.h and keys in PEM format. So, it took me a while for a program to verify (all) known answer tests in the standards (old standards as ANSI X9.62 1998 have more detailed known answer tests). One needs this interface with raw public keys for example for CAVP tests, see The FIPS 186-4 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS). 11. In the moment, there is no single known answer tests for ECDSA (which could be activated with #define MBEDTLS_SELF_TEST). I wouldn't say that you need an example for every curve and hash combination, as it is done in ECDSA2VS CAVP, but one example for one of the NIST curves and one for Curve25519 and - if I have a wish free - one for Brainpool would be fine. And this would solve #9 above. I don't get the point here. ECDSA is randomized, so you can't have a known answer test. The test suite does have known answer tests for deterministic ECDSA. 10. While debugging mbedtls_ecdsa_verify() in my example program, I found out, that the ECDSA, ECC and MPI operations are very, let's say, nested. So, IMHO there is a lot of function call overhead and special cases. It would be interesting to see what's the performance impact of a clean, straight-forward mbedtls_ecdsa_verify without restartable code, etc. to the current one. As far as I remember, the refactoring done to add the restartable code had no measurable impact on performance. What does have a significant impact on performance is that the bignum module uses malloc all the time. We would like to completely rewrite bignum operations at some point during the 3.x series, not only for performance but also because its design makes it hard not to leak information through side channels. 12. Just a minor issue: I only needed ECDSA signature verification, therefore I only included MBEDTLS_ASN1_PARSE_C. But it is not possible to compile without MBEDTLS_ASN1_WRITE_C needed for ECDSA signature generation. I'm not sure if I've written it down anywhere, but I'd like to remove the dependency of ECDSA on ASN1 altogether. Parsing and writing a SEQUENCE of two INTEGERs can be done with ad hoc code. Likewise for what little ASN1 the RSA module uses. And then asn1*.o can move out of libmbedcrypto and libpsacrypto, and into libmbedx509 where it belongs. Having only signature verification would be useful, indeed. That may happen with the bignum rewrite I mentioned above, if signature verification ends up using some faster non-constant-time code (this is also relevant for #13). 14. Design question: In the moment, both GCM and CCM use their own implementation of CTR encryption which is very simple. But then we have mbedtls_aes_crypt_ctr() in aes.h which is very simple, too. Let's assume at one day we have a performance optimized CTR encryption (for example from Schwabe & Stoffelen) with all fancy stuff like counter-mode caching etc. Then this would have to be replaced at three places at minimum. While isn't the code at this point more modularized? Is this a dedicated design decision? Having a single implementation of CTR is on the PSA roadmap because if there's a hardware accelerator that does it, we want to use it everywhere it's relevant. In Mbed TLS (or more precisely in its ancestor PolarSSL, if not _its_ ancestor XySSL), there was a conscious design decision to make each .c file as independent from the others as possible, which explains why camellia_ctr is completely independent from aes_ctr. But I don't know why ccm and gcm reimplement ctr. Why do I find at so many places for( i = 0; i < 16; i++ ) y[i] ^= b[i]; instead of a fast 128-bit XOR macro with 32bit aligned data? As a programmer who doesn't write compilers, I think this is the right way to xor 16 bytes, and it's the compiler's job to optimize it to word or vector operations if possible. Admittedly this does mean the compiler has to know that the data is well-aligned, which can be hard to guarantee and easy to forget. So, that's it for the moment. I hope I could give some hints for the further development of mbedTLS. Feel free to discuss any of the above points. It's clear to me that we cannot have both: clear and simple to understand code and performance records. Right. Also maintainable code and minimal code size, because minimal code size comes from letting the application developer #ifdef out everything that they don't care about, but this is a nightmare to test. It's one of the topics we're thinking about for Mbed TLS 3 and beyond. In general, Mbed TLS is primarily targeted at embedded systems, and is likely to privilege 1. security (including side channel resistance) and 2. code size. This doesn't mean that we don't care about performance, just that it isn't our top priority. That being said, we also do have some code that's optimized for performance (without compromising security) and not code size: the library already includes X25519 from Project Everest (https://project-everest.github.io/) (turn it on with MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED). This is code that's formally proven not only for functional correctness, but also for side channel resistance; the implementation has aggressive inlining which makes it very fast, but obviously also large in terms of code size. Hopefully other algorithms will follow soon. Ciao, Torsten Once again, thanks for the detailed feedback, and I hope we can improve Mbed TLS for everyone! -- 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.

6 years, 2 months

2
2
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Gilles Peskine

>From the perspective of an application developer whose platform doesn't have a native malloc, the advantage for Mbed TLS to include its own malloc is one less dependency to integrate (so one less source of potential incompatibilities, one less component to integrate into the build, one less set of parameters to configure, one less feed of security updates to keep up with, etc.). I expect that choosing the Mbed TLS allocator would give poorer performance and higher RAM consumption than choosing the best allocator that exists out there. But it gives better time to market, and potentially a better security posture (the highest-performance allocator may or may not turn out to be actively maintained). -- Gilles Peskine Mbed TLS developer On 16/04/2020 14:19, Janos Follath via mbed-tls wrote: > Hi, > > Thank you for sharing your view, it makes perfect sense. > > You mention that you would consider keeping the module internally for the sake of baremetal applications. How would this serve the user better than choosing a third party malloc implementation? (Assuming that there are better implementation out there than ours, which I haven't confirmed, but it is not hard to imagine that such exists.) > > Regards, > Janos > > > On 15/04/2020, 21:11, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: > > On 09/04/2020 13:17, Janos Follath via mbed-tls wrote: > > Hi, > > > > Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? > > Well, I disagree with this statement. I trust the toolchain to implement > the C standard library correctly, and with good performance for the > target platform. I do not want to provide my own implementation of > standard functions. > > I only trust the toolchain to be functionally correct. I don't know > about its security. I certainly can't rely on the toolchain to have > security characteristics that are not guaranteed by the language > definition. For example, I do trust memset_s() to zero out sensitive > memory if the toolchain provides it, but I don't trust memset() for this > task. > > On the topic at hand, my personal opinion of memory_buffer_alloc is that > it doesn't belong in Mbed TLS. I hope that when PSA crypto is a > standalone product, it won't use malloc internally, and so it certainly > won't provide a malloc implementation. I wouldn't necessarily say the > same thing of Mbed TLS 4.0: it's difficult to design an X.509 interface > that doesn't use malloc. But if we can do it, I think we should. > > I recognize that there are many bare-metal applications that don't use > malloc themselves, but use Mbed TLS. For their sake, it does make some > sense for Mbed TLS to have its own malloc implementation. But the focus > is for internal use, not on serving as a general-purpose allocator for > applications that also use malloc for non-mbedtls-related purposes. > > -- > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Janos Follath

Hi, Thank you for sharing your view, it makes perfect sense. You mention that you would consider keeping the module internally for the sake of baremetal applications. How would this serve the user better than choosing a third party malloc implementation? (Assuming that there are better implementation out there than ours, which I haven't confirmed, but it is not hard to imagine that such exists.) Regards, Janos On 15/04/2020, 21:11, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: On 09/04/2020 13:17, Janos Follath via mbed-tls wrote: > Hi, > > Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? Well, I disagree with this statement. I trust the toolchain to implement the C standard library correctly, and with good performance for the target platform. I do not want to provide my own implementation of standard functions. I only trust the toolchain to be functionally correct. I don't know about its security. I certainly can't rely on the toolchain to have security characteristics that are not guaranteed by the language definition. For example, I do trust memset_s() to zero out sensitive memory if the toolchain provides it, but I don't trust memset() for this task. On the topic at hand, my personal opinion of memory_buffer_alloc is that it doesn't belong in Mbed TLS. I hope that when PSA crypto is a standalone product, it won't use malloc internally, and so it certainly won't provide a malloc implementation. I wouldn't necessarily say the same thing of Mbed TLS 4.0: it's difficult to design an X.509 interface that doesn't use malloc. But if we can do it, I think we should. I recognize that there are many bare-metal applications that don't use malloc themselves, but use Mbed TLS. For their sake, it does make some sense for Mbed TLS to have its own malloc implementation. But the focus is for internal use, not on serving as a general-purpose allocator for applications that also use malloc for non-mbedtls-related purposes. -- 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 mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove pkcs11.c from the code base

by Manuel Pegourie-Gonnard

Hi Gilles, Thanks for this precision, as well as the reminder of the existing github issue. With no opposition here in a week, and none on github for nearly 3 months either, plus no opposition when we marked it as deprecated in 2.21 in February, I'm also moving this to the "Accepted" section on the wiki discussion tracking page: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ - but again, it's still time to voice concerns until we've actually removed it from the code base. Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove havege.c from the code base

by Manuel Pegourie-Gonnard

Hi Gilles, Thanks for your feedback and for providing a link to the existing issue, which I completely forgot about - I'll reference that in the wiki as well. Since it's been a week, with one agreement and no opposition, I'm also moving this to the "Accepted" section in the summary wiki page: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ - though again, it you have concerns it's still time to voice them. Regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove old TLS options from the code base entirely

by Manuel Pegourie-Gonnard

Hi all, Since this list of old options was probably not controversial in the first place and there has been no opposition in more than a week (a time that was sufficient for other thread in the same series to get several reactions), I'm moving this from "Under discussion" to "Accepted" in the summary wiki page: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ This is not meant to shut down discussion and if you disagree or have concerns it's still time to voice them - this is just to simplify tracking of the discussions. Best regards, Manuel.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Gilles Peskine

On 09/04/2020 13:17, Janos Follath via mbed-tls wrote: > Hi, > > Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? Well, I disagree with this statement. I trust the toolchain to implement the C standard library correctly, and with good performance for the target platform. I do not want to provide my own implementation of standard functions. I only trust the toolchain to be functionally correct. I don't know about its security. I certainly can't rely on the toolchain to have security characteristics that are not guaranteed by the language definition. For example, I do trust memset_s() to zero out sensitive memory if the toolchain provides it, but I don't trust memset() for this task. On the topic at hand, my personal opinion of memory_buffer_alloc is that it doesn't belong in Mbed TLS. I hope that when PSA crypto is a standalone product, it won't use malloc internally, and so it certainly won't provide a malloc implementation. I wouldn't necessarily say the same thing of Mbed TLS 4.0: it's difficult to design an X.509 interface that doesn't use malloc. But if we can do it, I think we should. I recognize that there are many bare-metal applications that don't use malloc themselves, but use Mbed TLS. For their sake, it does make some sense for Mbed TLS to have its own malloc implementation. But the focus is for internal use, not on serving as a general-purpose allocator for applications that also use malloc for non-mbedtls-related purposes. -- 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove havege.c from the code base

by Gilles Peskine

Yes, we should remove it. Unlike other features, I think we should remove HAVEGE _especially_ if someone is using it, because unlike the rest of the library, I cannot vouch for its security. I don't even know if our havege.c is implementing the HAVEGE specification correctly. And I cannot think of a platform where HAVEGE would give a useful amount of entropy, and where there isn't already a proper hardware RNG or an OS kernel with its own entropy gathering built with knowledge of the actual platform. (Also noted on https://github.com/ARMmbed/mbedtls/issues/2599 .) -- Gilles Peskine Mbed TLS developer On 08/04/2020 12:41, Manuel Pegourie-Gonnard via mbed-tls wrote: > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove havege.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > The crypto library currently includes an implementation of the HAVEGE entropy > gatherer [2], which is disabled in the default build (MBEDTLS_HAVEGE_C in > config.h), but used as a source by our entropy module if enabled. > > [2]: https://www.irisa.fr/caps/projects/hipsor/ > > We'd like to drop this module and remove it from the code base entirely for > the following reasons: > > - HAVEGE was designed for superscalar processors with high > microarchitectural complexity, and is unsuitable for microcontrollers (or > virtualized environments). We feel like when a complex enough CPU is used for > HAVEGE to stand a chance of being secure, it's very likely that an operating > system is also available, which probably already manages a random generator > better that what we can do in user space. > > - On a more practical note, our implementation relies on `timing_hardclock()` > provided by timing.c only for a limited number of architectures and > environments (funnily enough, not including any Arm architecture), with a > silent fallback to a definition relying on `gettimeofday()` which is clearly > not high-resolution enough to make HAVEGE secure. > > - As with any random source, it is very difficult to assess whether HAVEGE is > actually secure on any given platform. Further, the maintenance team > doesn't have any specific knowledge of HAVEGE and there hasn't been any > independent evaluation of our implementation of it. > > - As a result of the above points, we're afraid people using our HAVEGE > implementation on the wrong platforms, might be getting a false sense of > security, which might prevent them from using more secure options, such as the > OS RNG (when using an OS) or a hardware RNG (on microcontrollers). > > If you're using MBEDTLS_HAVEGE_C or know someone who does, or if for any other > reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now! > > Regards, > Manuel. 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove pkcs11.c from the code base

by Gilles Peskine

Hello, As noted in https://github.com/ARMmbed/mbedtls/issues/3006, I'm aware of only one project that is using Mbed TLS's pkcs11-helper support: OpenVPN. But this support has been removed from the development version. -- Gilles Peskine Mbed TLS developer On 08/04/2020 12:37, Manuel Pegourie-Gonnard via mbed-tls wrote: > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove pkcs11.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > The X.509 library currently includes a module called "pkcs11", excluded from > the default build, which provides a few wrappers around libpkcs11-helper [2], > a library that "simplifies the interaction with PKCS#11 providers for end-user > applications". In practice, it supports the use of X.509 certificates > associated with an RSA key (not ECDSA) managed by libpkcs11-helper. > > [2]: https://github.com/OpenSC/pkcs11-helper > > We'd like to drop this module and remove it from the code base entirely for > the following reasons: > > - It has limited functionality, and soon PSA Crypto will provide more flexible > support for secure management of private keys (not just RSA, and not just > associated with X.509 certificates). > > - It currently has not automated tests so we're not even sure if it still > works properly. > > - The documentation is scarce and no member of the current maintenance team > knows for sure how it's supposed to work. > > - We never receive any support request about it so we're not sure if anyone is > still using it. (As a weaker signal in the same direction, we deprecated it > in 2.21.0, released 2020-02-20, and nobody complained so far.) > > If you're using MBEDTLS_PKCS11_C or know someone who does, or if for any other > reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now! > > Regards, > Manuel. > 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.

6 years, 2 months

1
0
0 0

Running Mbed TLS unit tests on embedded targets

by Gilles Peskine

Hello, We're planning to make some changes to the way you can run Mbed TLS unit tests on embedded platforms. We want to make it easier to run the tests on platforms that have limited space for code and don't have a filesystem to read data from. At the moment, there are two ways to build the test suites. If you run 'make test', this builds one a host executable using host_test.function for each test_suite_*.function and one “compiled” data file for each test_suite_*.data, and the executable reads the compiled data file at runtime. It's also possible to build an executable with target_test.function, which includes calls to the Mbed-tools Greentea library to communicate over the serial port, and you can use the script mbedtls_test.py to run the tests with Greentea. Neither method works directly for embedded platforms other than Mbed OS. If you've run the Mbed TLS unit tests without reading the .datax file from the filesystem, and without using Mbed OS and Greentea, how did you do it? If you haven't run the unit tests but would like to do so, what changes would you like to see what Mbed TLS provides? I have a few more specific questions: • Does Mbed TLS need to include some abstraction for serial communication? If not, what would the interface of the test functions be? (Tests can currently take inputs that are zero-terminated text string, binary string with length, or int, and we'd like to add the possibility to add other integer types such as uint64_t, but nothing more complex. The outcome of a test is pass/fail/skip, and if fail/skip location information about the failure.) • Is it useful to have a way to build the test data into the executable, so that the only interaction that the executable needs is to write out the test results? It's more convenient but doesn't work everywhere (the biggest test suite has >200kB of test data). • Should test executables be self-contained in their reporting (including error messages)? Or should they minimize code size, and then you'd need an extra host-side script to make sense of results? • The current .function-to-.c transformation script (generate_test_code.py) generates a single C file with all of the test code (but not the test data). Is this a useful requirement? We welcome any thoughts you may have on the topic. -- 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Janos Follath

Hi Dan, Thank you for explaining, I see it now. I think we definitely should leave the choice open for Mbed TLS users and I agree that such a joint stdlib implementation project would be a much better place for a toolchain independent memory allocator. Regards, Janos On 09/04/2020, 14:31, "mbed-tls on behalf of Dan Handley via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Hi Janos It's not so much that the toolchain stdlib implementations are less trusted from a security point of view, it's that there is variation in their non-functional characteristics, e.g. * security * robustness * code size * performance * open-ness * ... If you remove this variation it's easier to reason about the non-functional characteristics of the code. This is perhaps more important for projects that build final executable images but may also be important for libraries, especially ones that export executable link libraries like Mbed TLS. On the other hand, Mbed TLS is deployed in many other places than Trusted Firmware and it may be hard to choose a stdlib implementation that works for all users. Perhaps the compromise is to create a shared stdlib implementation for Trusted Firmware deployments but leave the choice open for other Mbed TLS users? Regards Dan > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Janos Follath via mbed-tls > Sent: 09 April 2020 12:18 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, > > Based on what I read on this thread it seems an accepted point of view that > the toolchain provided C standard library implementations are less trusted > than the toolchains themselves. Can somebody please help me understand the > reasoning behind this distinction? > > Regards, > Janos > > On 09/04/2020, 12:07, "Dan Handley via mbed-tls" <mbed- > tls(a)lists.trustedfirmware.org> wrote: > > Hi > > There has already been some discussion about a shared C standard library > implementation, at least for TF-A and TF-M. So far there's been general > agreement that this is a good idea but no actual commitment from anyone to > make this happen, since each project is reasonably happy with what they've > got. > > Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so > removing this from the codebase would be an issue there. Memory allocators > are probably not the core expertise of other Trusted Firmware projects either > but it needs to be if they're going to use them! > > I propose that we move this allocator into a new shared > TrustedFirmware.org standard C library project and work with the other > projects to ensure it has the correct initial maintainers. This will probably > have to be driven by the maintainers of whichever project is most motivated > to make this happen. It sounds like that could be Mbed TLS and this will need > to be done before any separation of the PSA Crypto implementation. In the > short term, as we move C stdlib functionality out of the other projects and > into this new project, we will need to support multiple implementations of > some functions. Eventually we should move towards a common implementation, > and I agree we should look at what security-oriented implementations are > already available. > > I also agree it would make sense for Mbed TLS to not use the toolchain- > provided stdlib implementation by default, but only once it uses a default > implementation it trusts. > > Regards > > Dan. > > > -----Original Message----- > > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf > Of > > Ronald Cron via mbed-tls > > Sent: 09 April 2020 08:47 > > To: mbed-tls(a)lists.trustedfirmware.org > > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from > the code > > base > > > > Hi, I think this is related to the more general need for an > implementation of > > the C standard library for trusted firmware projects. As far as I know > TF-A > > and TF-M don't use the standard library provided by compilation > toolchains. > > The rationale is to have complete control over the trusted firmware > code. > > Currently they both have their own partial implementation of the parts > of the > > C standard library they need. > > > > This memory_buffer_alloc.c module in question here is another partial > > implementation of the C standard library. Currently TF-A and TF-M don't > > use/provide dynamic memory allocations but PSA-FF explicitly mentions > that an > > SPM implementation may support dynamic memory allocation. Thus it is > possible > > that TF-M at some point consider providing dynamic memory allocation > support. > > > > All of this to say that a possible way forward may be to remove > > memory_buffer_alloc.c from the code base when there is a C standard > library > > implementation common to trustedfirmware.org projects (is there already > a > > security oriented open source implementation out there ?). > > > > In Mbed TLS, it would also make sense to me to, by default, not use C > > standard libraries provided by compilation toolchains > > (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default). > > > > Thanks, Ronald. > > > > > > -----Original Message----- > > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf > Of > > Manuel Pegourie-Gonnard via mbed-tls > > Sent: 08 April 2020 12:42 > > To: mbed-tls(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the > code > > base > > > > Hi all, > > > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > > should we remove memory_buffer_alloc.c from the code base? > > > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > > > Currently the crypto library includes a module called > memory_buffer_alloc.c, > > disabled in the default build (config.h option > MBEDTLS_MEMORY_BUFFER_ALLOC_C), > > which provides implementations of calloc() and free() based on a user- > > provided buffer (which could be static or on the stack), suitable for > use in > > the rest of the crypto, X.509 and TLS libraries as replacements to the > > standard functions. > > > > In addition to providing replacement calloc() and free(), the module > also > > offers some facilities for measurement and debugging. > > > > We're considering dropping this module and removing it from the code > base > > entirely for the following reasons: > > > > - Memory allocators are not our core area of expertise. > > > > - This allocator is pretty basic and has a large allocation overhead. > For > > example for ECC computations, the overhead can be as large as the > actual > > memory used. > > > > - Using this allocator also tends to slow things down, so we don't run > many > > tests with it enabled. > > > > - In the future when we split between PSA Crypto on one side and Mbed > TLS and > > X.509 on the other, it's unclear on which side this allocator should > fall. > > Which can be taken as a sign that it doesn't really belong here. > > > > On the other hand, we're hesitating for the following reasons: > > > > - We know from bug reports and questions that some people are using it. > > > > - Unlike other modules we'd like to drop, there isn't a strong security > > incentive to dropping this allocator, it's merely a matter of how we > spend > > our maintenance resources. > > > > What do you think? Should we keep maintaining this allocator as part of > Mbed > > TLS? Should we drop it and focus on our core instead? If you're using > this > > allocator, why did you pick it over other alternatives? > > > > Regards, > > Manuel. > > -- > > mbed-tls mailing list > > mbed-tls(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > 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 mailing list > > mbed-tls(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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.

6 years, 2 months

1
0
0 0

Some thoughts towards mbed TLS 3.0

by Torsten Schuetze

Hi all, this will be a long mail. Sorry for that. In the past weeks I've been using mbedTLS 2.16.5 for implementing crypto on an ARM Cortex M4 (STM32F479). This was my first experience with mbedTLS, but I have some (almost 20 years) experience with applied and high-assurance crypto. So maybe the following thoughts fit into the discussion of plans for version 3.0 of Mbed TLS. In the end, I achieved everything that was required for my project with mbedTLS, but some things surprised me or it took a while to find out. I'll enumerate the following points for easier reference. Nothing of the following is meant to embarrass anyone, just my personal thoughts. 1. I really missed an Initialize, Update, Finalize (IUF) interface for CCM. For GCM, we have mbedtls_gcm_init(), mbedtls_gcm_setkey(), mbedtls_gcm_starts(), mbedtls_gcm_update() iterated, mbedtls_gcm_finish(), mbedtls_gcm_free() or the comfort functions mbedtls_gcm_crypt_and_tag() and mbedtls_gcm_auth_decrypt(). For CCM, only mbedtls_ccm_init(), mbedtls_ccm_setkey(), mbedtls_ccm_encrypt_and_tag() or mbedtls_ccm_auth_decrypt() and mbedtls_ccm_free(). With this interface it was only possible to encrypt and tag 128 kByte on my target system, while with GCM I could encrypt much larger files. see Github issue #662 and my comment there 2. The next step, of course, is to integrate this into the higher mbedtls_cipher layer. Regarding higher, abstract layers: I often didn't understand which interface I was supposed to use. In general, I like to use the lowest available interface, for example, #include "mbedtls/sha512.h" when I want to use sha512. However, if I need HMAC-SHA-512 or HKDF-HMAC-SHA-512 then I have to use the interface in md.h. For hash functions this is fine. Almost all hash functions are supported via md.h. (I missed SHA-512/256 which is sometimes preferable to SHA-256 on 64bit systems). But with cipher.h, I can only access Chacha20Poly1305 and AES-GCM, not AES-CCM. 3. For certification and evaluation purposes I need some test vectors for each crypto function on target. While I know about the comprehensive self-test program I'm now talking about built-in functions like mbedtls_sha512_self_test(), etc to be enabled with #define MBEDTLS_SELF_TEST. These self-tests are very different in coverage. For SHA-384 and SHA-512 they are fine, for HMAC-SHA-384 and HMAC-SHA-512 I couldn't find any as well as for HKDF-HMAC-SHA-256 (in RFC 5869) or HKDF-HMAC-SHA-384/512 (official test vectors difficult to find). AES-CTR and AES-XTS are only tested with key length 128 bit, not with 256 bit. AES-CCM is not tested with 256 bit and even for 128 bit, the test vector from the standard NIST SP 800-38C with long additional data is not used. The builtin self-test for GCM is the best I've seen with mbedtls: all three key lengths are tested as well as the IUF-interface and the comfort function. Bravo! 4. That I couldn't configure AES-256 only, i.e. without AES-128 and AES-192, was to be expected (and the code overhead is not that much). But in modern modes of operations nobody needs AES decryption, only the forward direction. Sometimes modern publications as Schwabe/Stoffelen "All the AES you need on Cortex-M3 and M4" provide only the forward direction. So, it would be fine if one could configure an AES (ECB) encryption only without decryption. Of course, this is only possible if we don't use CBC mode, etc. This wouldn't only save the AES decryption code but also the rather large T-tables for decryption. 5. Regarding AES or better the AES context-type definition typedef struct mbedtls_aes_context { int nr; /*!< The number of rounds. */ uint32_t *rk; /*!< AES round keys. */ uint32_t buf[68]; /*!< Unaligned data buffer. This buffer can hold 32 extra Bytes, which can be used for one of the following purposes: <ul><li>Alignment if VIA padlock is used.</li> <li>Simplifying key expansion in the 256-bit case by generating an extra round key. </li></ul> */ } mbedtls_aes_context; I really don't understand why we need additional 2176 bit in EVERY AES context. I would understand 128 bit (one block size) or even 512 bit (for example for CTR optimization which is not used!). But 2176 bit in every AES context? The VIA padlock is not very common, I suppose. But even if it were, this doesn't justify such memory overhead. How wasteful this is, one can see in the next type definition /** * \brief The AES XTS context-type definition. */ typedef struct mbedtls_aes_xts_context { mbedtls_aes_context crypt; /*!< The AES context to use for AES block encryption or decryption. */ mbedtls_aes_context tweak; /*!< The AES context used for tweak computation. */ } mbedtls_aes_xts_context; The tweak context is for the encryption of exactly 128 bit, not more. 6. In general, the contexts of mbedTLS are rather full of implementation specific details. Most extreme is mbedtls_ecp_group in ecp.h. Wouldn't it be clearer if one separates the standard things (domain parameters in this case) from implementation specific details? 7. While at Elliptic Curve Cryptography: I assume that some of you know that projectives coordinates as outer interface to ECC are dangerous, see David Naccache, Nigel P. Smart, Jacques Stern: Projective Coordinates Leak, Eurocrypt 2004, pp. 257–267. Therefore, the usual interface in ECC standards are either affine points or compressed affine points (Okay, with the modern curves Curve25519 and Curve 448 it's X only.). Now with /** * \brief The ECP point structure, in Jacobian coordinates. * * \note All functions expect and return points satisfying * the following condition: <code>Z == 0</code> or * <code>Z == 1</code>. Other values of \p Z are * used only by internal functions. * The point is zero, or "at infinity", if <code>Z == 0</code>. * Otherwise, \p X and \p Y are its standard (affine) * coordinates. */ typedef struct mbedtls_ecp_point { mbedtls_mpi X; /*!< The X coordinate of the ECP point. */ mbedtls_mpi Y; /*!< The Y coordinate of the ECP point. */ mbedtls_mpi Z; /*!< The Z coordinate of the ECP point. */ } mbedtls_ecp_point; you have Jacobian coordinates, i.e. projective coordinates, as outer interface. In the comment, its is noted that only the affine part is used, but can this be assured? In all circumstances? 8. In my personal opinion the definition /** * \brief The ECP key-pair structure. * * A generic key-pair that may be used for ECDSA and fixed ECDH, for example. * * \note Members are deliberately in the same order as in the * ::mbedtls_ecdsa_context structure. */ typedef struct mbedtls_ecp_keypair { mbedtls_ecp_group grp; /*!< Elliptic curve and base point */ mbedtls_mpi d; /*!< our secret value */ mbedtls_ecp_point Q; /*!< our public value */ } mbedtls_ecp_keypair; is dangerous. Why not differentiate between private and public key and domain parameters? How often does it happen by accident with this structure that you give the private key (unneeded and dangerous) together with the public key to ECDSA signature verification? Obviously this was known (and perhaps it happened) to the authors of programs\ecdsa.c with the following comment /* * Transfer public information to verifying context * * We could use the same context for verification and signatures, but we * chose to use a new one in order to make it clear that the verifying * context only needs the public key (Q), and not the private key (d). */ What is sometimes useful, is to have the public key at hand when you have performed a private key operation (as countermeasure against fault attacks, verify after signing). But for ECC the verification procedure if often too expensive (in contrast to cheap RSA verify). 9. Regarding ECC examples: I found it very difficult that there isn't a single example with known test vectors as in the relevant crypto standards, i.e. FIPS 186-4 and ANSI X9.62-2005, with raw public keys. What I mean are (defined) curves, public key value Q=(Qx,Qy) and known signature values r and s. In the example ecdsa.c you generate your own key pair and read/write the signature in serialized form. In the example programs/pkey/pk_sign.c and pk_verify.c you use a higher interface pk.h and keys in PEM format. So, it took me a while for a program to verify (all) known answer tests in the standards (old standards as ANSI X9.62 1998 have more detailed known answer tests). One needs this interface with raw public keys for example for CAVP tests, see The FIPS 186-4 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS). 10. While debugging mbedtls_ecdsa_verify() in my example program, I found out, that the ECDSA, ECC and MPI operations are very, let's say, nested. So, IMHO there is a lot of function call overhead and special cases. It would be interesting to see what's the performance impact of a clean, straight-forward mbedtls_ecdsa_verify without restartable code, etc. to the current one. 11. In the moment, there is no single known answer tests for ECDSA (which could be activated with #define MBEDTLS_SELF_TEST). I wouldn't say that you need an example for every curve and hash combination, as it is done in ECDSA2VS CAVP, but one example for one of the NIST curves and one for Curve25519 and - if I have a wish free - one for Brainpool would be fine. And this would solve #9 above. 12. Just a minor issue: I only needed ECDSA signature verification, therefore I only included MBEDTLS_ASN1_PARSE_C. But it is not possible to compile without MBEDTLS_ASN1_WRITE_C needed for ECDSA signature generation. 13. Feature request: Since it was irrelevant for my task (only verification, no generation) I didn't have a detailed look a your ECC side-channel countermeasures. But obviously you use the same protected code for scalar multiplication in verify and sign, right? Wouldn't it be possible to use Shamir's trick in verification with fast unprotected multi-scalar multiplication. In the moment, mbedtls_ecdsa_verify is a factor 4-5 slower than mbedtls_ecdsa_sign, while OpenSSLs verify is faster than sign. 14. Design question: In the moment, both GCM and CCM use their own implementation of CTR encryption which is very simple. But then we have mbedtls_aes_crypt_ctr() in aes.h which is very simple, too. Let's assume at one day we have a performance optimized CTR encryption (for example from Schwabe & Stoffelen) with all fancy stuff like counter-mode caching etc. Then this would have to be replaced at three places at minimum. While isn't the code at this point more modularized? Is this a dedicated design decision? Why do I find at so many places for( i = 0; i < 16; i++ ) y[i] ^= b[i]; instead of a fast 128-bit XOR macro with 32bit aligned data? So, that's it for the moment. I hope I could give some hints for the further development of mbedTLS. Feel free to discuss any of the above points. It's clear to me that we cannot have both: clear and simple to understand code and performance records. Ciao, Torsten

6 years, 2 months

1
0
0 0

Security Advisory and Release of Mbed TLS 2.16.6 and 2.7.15

by Janos Follath

Hi, An Mbed TLS Security Advisory has been issued to accompany the release of Mbed TLS versions 2.16.6 and 2.7.15, which have just been released. 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://tls.mbed.org/techupdates/releases/mbedtls-2.16.6-and-2.7.15-released> and in the 2020-04 security advisory<https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi…>. We recommend all users to consider whether they are impacted, and to upgrade appropriately. -- Janos Follath 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.

6 years, 2 months

1
0
0 0

mbedtls_base64_encode reports different olen's when used for size checking and when encoding

by Frederik Wedel-Heinen

Hi, I don't understand why mbedtls_base64_encode returns different olen's for the same source buffer. See example below: uint8_t s[10]; uint8_t d[17]; size_t sz; int ret; ret = mbedtls_base64_encode(NULL, 0, &sz, s, 10); // returns sz == 17 ret = mbedtls_base64_encode(d, 17, &sz, s, 10); // returns sz == 16 Shouldn't it be the same? Regards, Frederik

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Dan Handley

Hi Janos It's not so much that the toolchain stdlib implementations are less trusted from a security point of view, it's that there is variation in their non-functional characteristics, e.g. * security * robustness * code size * performance * open-ness * ... If you remove this variation it's easier to reason about the non-functional characteristics of the code. This is perhaps more important for projects that build final executable images but may also be important for libraries, especially ones that export executable link libraries like Mbed TLS. On the other hand, Mbed TLS is deployed in many other places than Trusted Firmware and it may be hard to choose a stdlib implementation that works for all users. Perhaps the compromise is to create a shared stdlib implementation for Trusted Firmware deployments but leave the choice open for other Mbed TLS users? Regards Dan > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Janos Follath via mbed-tls > Sent: 09 April 2020 12:18 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, > > Based on what I read on this thread it seems an accepted point of view that > the toolchain provided C standard library implementations are less trusted > than the toolchains themselves. Can somebody please help me understand the > reasoning behind this distinction? > > Regards, > Janos > > On 09/04/2020, 12:07, "Dan Handley via mbed-tls" <mbed- > tls(a)lists.trustedfirmware.org> wrote: > > Hi > > There has already been some discussion about a shared C standard library > implementation, at least for TF-A and TF-M. So far there's been general > agreement that this is a good idea but no actual commitment from anyone to > make this happen, since each project is reasonably happy with what they've > got. > > Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so > removing this from the codebase would be an issue there. Memory allocators > are probably not the core expertise of other Trusted Firmware projects either > but it needs to be if they're going to use them! > > I propose that we move this allocator into a new shared > TrustedFirmware.org standard C library project and work with the other > projects to ensure it has the correct initial maintainers. This will probably > have to be driven by the maintainers of whichever project is most motivated > to make this happen. It sounds like that could be Mbed TLS and this will need > to be done before any separation of the PSA Crypto implementation. In the > short term, as we move C stdlib functionality out of the other projects and > into this new project, we will need to support multiple implementations of > some functions. Eventually we should move towards a common implementation, > and I agree we should look at what security-oriented implementations are > already available. > > I also agree it would make sense for Mbed TLS to not use the toolchain- > provided stdlib implementation by default, but only once it uses a default > implementation it trusts. > > Regards > > Dan. > > > -----Original Message----- > > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf > Of > > Ronald Cron via mbed-tls > > Sent: 09 April 2020 08:47 > > To: mbed-tls(a)lists.trustedfirmware.org > > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from > the code > > base > > > > Hi, I think this is related to the more general need for an > implementation of > > the C standard library for trusted firmware projects. As far as I know > TF-A > > and TF-M don't use the standard library provided by compilation > toolchains. > > The rationale is to have complete control over the trusted firmware > code. > > Currently they both have their own partial implementation of the parts > of the > > C standard library they need. > > > > This memory_buffer_alloc.c module in question here is another partial > > implementation of the C standard library. Currently TF-A and TF-M don't > > use/provide dynamic memory allocations but PSA-FF explicitly mentions > that an > > SPM implementation may support dynamic memory allocation. Thus it is > possible > > that TF-M at some point consider providing dynamic memory allocation > support. > > > > All of this to say that a possible way forward may be to remove > > memory_buffer_alloc.c from the code base when there is a C standard > library > > implementation common to trustedfirmware.org projects (is there already > a > > security oriented open source implementation out there ?). > > > > In Mbed TLS, it would also make sense to me to, by default, not use C > > standard libraries provided by compilation toolchains > > (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default). > > > > Thanks, Ronald. > > > > > > -----Original Message----- > > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf > Of > > Manuel Pegourie-Gonnard via mbed-tls > > Sent: 08 April 2020 12:42 > > To: mbed-tls(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the > code > > base > > > > Hi all, > > > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > > should we remove memory_buffer_alloc.c from the code base? > > > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > > > Currently the crypto library includes a module called > memory_buffer_alloc.c, > > disabled in the default build (config.h option > MBEDTLS_MEMORY_BUFFER_ALLOC_C), > > which provides implementations of calloc() and free() based on a user- > > provided buffer (which could be static or on the stack), suitable for > use in > > the rest of the crypto, X.509 and TLS libraries as replacements to the > > standard functions. > > > > In addition to providing replacement calloc() and free(), the module > also > > offers some facilities for measurement and debugging. > > > > We're considering dropping this module and removing it from the code > base > > entirely for the following reasons: > > > > - Memory allocators are not our core area of expertise. > > > > - This allocator is pretty basic and has a large allocation overhead. > For > > example for ECC computations, the overhead can be as large as the > actual > > memory used. > > > > - Using this allocator also tends to slow things down, so we don't run > many > > tests with it enabled. > > > > - In the future when we split between PSA Crypto on one side and Mbed > TLS and > > X.509 on the other, it's unclear on which side this allocator should > fall. > > Which can be taken as a sign that it doesn't really belong here. > > > > On the other hand, we're hesitating for the following reasons: > > > > - We know from bug reports and questions that some people are using it. > > > > - Unlike other modules we'd like to drop, there isn't a strong security > > incentive to dropping this allocator, it's merely a matter of how we > spend > > our maintenance resources. > > > > What do you think? Should we keep maintaining this allocator as part of > Mbed > > TLS? Should we drop it and focus on our core instead? If you're using > this > > allocator, why did you pick it over other alternatives? > > > > Regards, > > Manuel. > > -- > > mbed-tls mailing list > > mbed-tls(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > 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 mailing list > > mbed-tls(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Janos Follath

Hi, Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? Regards, Janos On 09/04/2020, 12:07, "Dan Handley via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> wrote: Hi There has already been some discussion about a shared C standard library implementation, at least for TF-A and TF-M. So far there's been general agreement that this is a good idea but no actual commitment from anyone to make this happen, since each project is reasonably happy with what they've got. Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so removing this from the codebase would be an issue there. Memory allocators are probably not the core expertise of other Trusted Firmware projects either but it needs to be if they're going to use them! I propose that we move this allocator into a new shared TrustedFirmware.org standard C library project and work with the other projects to ensure it has the correct initial maintainers. This will probably have to be driven by the maintainers of whichever project is most motivated to make this happen. It sounds like that could be Mbed TLS and this will need to be done before any separation of the PSA Crypto implementation. In the short term, as we move C stdlib functionality out of the other projects and into this new project, we will need to support multiple implementations of some functions. Eventually we should move towards a common implementation, and I agree we should look at what security-oriented implementations are already available. I also agree it would make sense for Mbed TLS to not use the toolchain-provided stdlib implementation by default, but only once it uses a default implementation it trusts. Regards Dan. > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Ronald Cron via mbed-tls > Sent: 09 April 2020 08:47 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, I think this is related to the more general need for an implementation of > the C standard library for trusted firmware projects. As far as I know TF-A > and TF-M don't use the standard library provided by compilation toolchains. > The rationale is to have complete control over the trusted firmware code. > Currently they both have their own partial implementation of the parts of the > C standard library they need. > > This memory_buffer_alloc.c module in question here is another partial > implementation of the C standard library. Currently TF-A and TF-M don't > use/provide dynamic memory allocations but PSA-FF explicitly mentions that an > SPM implementation may support dynamic memory allocation. Thus it is possible > that TF-M at some point consider providing dynamic memory allocation support. > > All of this to say that a possible way forward may be to remove > memory_buffer_alloc.c from the code base when there is a C standard library > implementation common to trustedfirmware.org projects (is there already a > security oriented open source implementation out there ?). > > In Mbed TLS, it would also make sense to me to, by default, not use C > standard libraries provided by compilation toolchains > (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default). > > Thanks, Ronald. > > > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Manuel Pegourie-Gonnard via mbed-tls > Sent: 08 April 2020 12:42 > To: mbed-tls(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove memory_buffer_alloc.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > Currently the crypto library includes a module called memory_buffer_alloc.c, > disabled in the default build (config.h option MBEDTLS_MEMORY_BUFFER_ALLOC_C), > which provides implementations of calloc() and free() based on a user- > provided buffer (which could be static or on the stack), suitable for use in > the rest of the crypto, X.509 and TLS libraries as replacements to the > standard functions. > > In addition to providing replacement calloc() and free(), the module also > offers some facilities for measurement and debugging. > > We're considering dropping this module and removing it from the code base > entirely for the following reasons: > > - Memory allocators are not our core area of expertise. > > - This allocator is pretty basic and has a large allocation overhead. For > example for ECC computations, the overhead can be as large as the actual > memory used. > > - Using this allocator also tends to slow things down, so we don't run many > tests with it enabled. > > - In the future when we split between PSA Crypto on one side and Mbed TLS and > X.509 on the other, it's unclear on which side this allocator should fall. > Which can be taken as a sign that it doesn't really belong here. > > On the other hand, we're hesitating for the following reasons: > > - We know from bug reports and questions that some people are using it. > > - Unlike other modules we'd like to drop, there isn't a strong security > incentive to dropping this allocator, it's merely a matter of how we spend > our maintenance resources. > > What do you think? Should we keep maintaining this allocator as part of Mbed > TLS? Should we drop it and focus on our core instead? If you're using this > allocator, why did you pick it over other alternatives? > > Regards, > Manuel. > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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 mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Dan Handley

Hi There has already been some discussion about a shared C standard library implementation, at least for TF-A and TF-M. So far there's been general agreement that this is a good idea but no actual commitment from anyone to make this happen, since each project is reasonably happy with what they've got. Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so removing this from the codebase would be an issue there. Memory allocators are probably not the core expertise of other Trusted Firmware projects either but it needs to be if they're going to use them! I propose that we move this allocator into a new shared TrustedFirmware.org standard C library project and work with the other projects to ensure it has the correct initial maintainers. This will probably have to be driven by the maintainers of whichever project is most motivated to make this happen. It sounds like that could be Mbed TLS and this will need to be done before any separation of the PSA Crypto implementation. In the short term, as we move C stdlib functionality out of the other projects and into this new project, we will need to support multiple implementations of some functions. Eventually we should move towards a common implementation, and I agree we should look at what security-oriented implementations are already available. I also agree it would make sense for Mbed TLS to not use the toolchain-provided stdlib implementation by default, but only once it uses a default implementation it trusts. Regards Dan. > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Ronald Cron via mbed-tls > Sent: 09 April 2020 08:47 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, I think this is related to the more general need for an implementation of > the C standard library for trusted firmware projects. As far as I know TF-A > and TF-M don't use the standard library provided by compilation toolchains. > The rationale is to have complete control over the trusted firmware code. > Currently they both have their own partial implementation of the parts of the > C standard library they need. > > This memory_buffer_alloc.c module in question here is another partial > implementation of the C standard library. Currently TF-A and TF-M don't > use/provide dynamic memory allocations but PSA-FF explicitly mentions that an > SPM implementation may support dynamic memory allocation. Thus it is possible > that TF-M at some point consider providing dynamic memory allocation support. > > All of this to say that a possible way forward may be to remove > memory_buffer_alloc.c from the code base when there is a C standard library > implementation common to trustedfirmware.org projects (is there already a > security oriented open source implementation out there ?). > > In Mbed TLS, it would also make sense to me to, by default, not use C > standard libraries provided by compilation toolchains > (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default). > > Thanks, Ronald. > > > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Manuel Pegourie-Gonnard via mbed-tls > Sent: 08 April 2020 12:42 > To: mbed-tls(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove memory_buffer_alloc.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > Currently the crypto library includes a module called memory_buffer_alloc.c, > disabled in the default build (config.h option MBEDTLS_MEMORY_BUFFER_ALLOC_C), > which provides implementations of calloc() and free() based on a user- > provided buffer (which could be static or on the stack), suitable for use in > the rest of the crypto, X.509 and TLS libraries as replacements to the > standard functions. > > In addition to providing replacement calloc() and free(), the module also > offers some facilities for measurement and debugging. > > We're considering dropping this module and removing it from the code base > entirely for the following reasons: > > - Memory allocators are not our core area of expertise. > > - This allocator is pretty basic and has a large allocation overhead. For > example for ECC computations, the overhead can be as large as the actual > memory used. > > - Using this allocator also tends to slow things down, so we don't run many > tests with it enabled. > > - In the future when we split between PSA Crypto on one side and Mbed TLS and > X.509 on the other, it's unclear on which side this allocator should fall. > Which can be taken as a sign that it doesn't really belong here. > > On the other hand, we're hesitating for the following reasons: > > - We know from bug reports and questions that some people are using it. > > - Unlike other modules we'd like to drop, there isn't a strong security > incentive to dropping this allocator, it's merely a matter of how we spend > our maintenance resources. > > What do you think? Should we keep maintaining this allocator as part of Mbed > TLS? Should we drop it and focus on our core instead? If you're using this > allocator, why did you pick it over other alternatives? > > Regards, > Manuel. > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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.

6 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls