- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] mbed-tls Digest, Vol 11, Issue 7 ENTROPY_SOURCE_FAILED :0x0034

by T V LIJIN (EXT)

Hi, As suggested by @Gilles Peskine , I did try enabling MBEDTLS_ENTROPY_FORCE_SHA256 , but even after enabling this mbedtls_ctr_drbg_seed was still returning 0X0034 (MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED ), please note that I'm using NVRAM for Seeding. I'm attaching my config.h file along with this mail for you reference. PFA -----Original Message----- From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of mbed-tls-request(a)lists.trustedfirmware.org Sent: Thursday, January 28, 2021 1:19 AM To: mbed-tls(a)lists.trustedfirmware.org Subject: mbed-tls Digest, Vol 11, Issue 7 This message is from an external sender. Be cautious, especially with links and attachments. Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… or, via email, send a message with subject or body 'help' to mbed-tls-request(a)lists.trustedfirmware.org You can reach the person managing the list at mbed-tls-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mbed-tls digest..." Today's Topics: 1. Re: ENTROPY_SOURCE_FAILED :0x0034 (Gilles Peskine) 2. Re: Reduce mbedTLS memory and storage footprint (Gilles Peskine) ---------------------------------------------------------------------- Message: 1 Date: Wed, 27 Jan 2021 20:36:18 +0100 From: Gilles Peskine <gilles.peskine(a)arm.com> To: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] ENTROPY_SOURCE_FAILED :0x0034 Message-ID: <9fcd3d55-ad54-05cf-63f9-7f3d09f3ee0d(a)arm.com> Content-Type: text/plain; charset=windows-1252 Hello, The entropy module uses a hash to mix the entropy. It uses SHA-512 if present and SHA-256 otherwise. Depending on the hash function, the entropy module can return either up to 64 bytes (SHA-512) or 32 bytes (SHA-256). The CTR_DRBG module knows about this and requests only 32 bytes at a time if the entropy module only delivers 32 bytes at a time. It looks like something goes wrong when CTR_DRBG tries to request 64 bytes. This could be, for example, because a buffer is too small somewhere, or because of a limitation of the entropy source. You would need to debug the call to mbedtls_entropy_func to know more. As a workaround, you can enable MBEDTLS_ENTROPY_FORCE_SHA256. Then the entropy module will use SHA-256 (even if MBEDTLS_SHA512_C is enabled) and only return 32 bytes at a time, and CTR_DRBG understands this and will only request 32 bytes. -- Gilles Peskine Mbed TLS developer On 27/01/2021 06:08, T V LIJIN (EXT) via mbed-tls wrote: > Hi, > After enabling *MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* , > /mbedtls_ctr_drbg_seed/ is returning *0x0034 > */(MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED)/ > But if I just enable *MBEDTLS_NO_PLATFORM_ENTROPY* and keep > *MBEDTLS_SHA512_C* disabled, it does not return any error for > /mbedtls_ctr_drbg_seed./ / / My project uses certificates with SHA384 > signature, so it requires***MBEDTLS_SHA512_C *to be enabled. > /*MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* /both needs to be > enabled in my project , but Iam facing issue with > mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What > might be the reason for mbedtls_ctr_drbg_seed to fail while > enabling/////*MBEDTLS_SHA512_C.*///// > How to overcome this issue? > > > Thanks, > LIJIN T V > ------------------------------ Message: 2 Date: Wed, 27 Jan 2021 20:48:27 +0100 From: Gilles Peskine <gilles.peskine(a)arm.com> To: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] Reduce mbedTLS memory and storage footprint Message-ID: <b59f3e91-ae60-fae6-5fca-402894b0a890(a)arm.com> Content-Type: text/plain; charset=windows-1252 Hello, The most important thing is to make sure you've disabled all the features you don't need in config.h. The default configuration enables most cryptographic mechanisms, but typical constrained systems usually only need a few. If your toolchain supports it, use link-time optimization (e.g. gcc -Os -flto or clang -Oz -flto). I've seen that this makes a significant improvement for Mbed TLS (I got -30% on one build, obviously the numbers depend heavily on the configuration and the compiler). (In contrast LTO when optimizing for performance doesn't seem to improve anything.) MBEDTLS_MPI_WINDOW_SIZE, MBEDTLS_MPI_MAX_SIZE and MBEDTLS_ECP_MAX_BITS only impact memory usage (stack and heap), not code size. -- Gilles Peskine Mbed TLS developer On 27/01/2021 05:36, T V LIJIN (EXT) via mbed-tls wrote: > Hi, > I'm trying to optimize the size of my binary file by making the > following changes in "*mbedtls/config.h*" > > #define MBEDTLS_MPI_WINDOW_SIZE 1 > #define MBEDTLS_MPI_MAX_SIZE 32 > #define MBEDTLS_ECP_MAX_BITS 256 > #define MBEDTLS_SHA256_SMALLER > > Even after making the above changes I couldn't see any change in the > binary size. > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftls. > mbed.org%2Fkb%2Fhow-to%2Freduce-mbedtls-memory-and-storage-footprint&a > mp;data=04%7C01%7Clijin.tv%40kone.com%7C1a138332ca084342827b08d8c2fc9d > b9%7C2bb82c642eb143f78862fdc1d2333b50%7C0%7C0%7C637473737538267015%7CU > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLCJXVCI6Mn0%3D%7C1000&sdata=ql17fsSC0eX7Hq5ofrsWAe%2BEenOc2piLq > 4jBix%2Bjr20%3D&reserved=0 > - This is the link I referred to follow the above-mentioned steps. > Is there anything else I can try to reduce my final binary file size > (ROM size) ? > > > Thanks, > LIJIN T V > ------------------------------ Subject: Digest Footer mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ End of mbed-tls Digest, Vol 11, Issue 7 ***************************************

5 years

1
0
0 0

Re: [mbed-tls] Reduce mbedTLS memory and storage footprint

by Gilles Peskine

Hello, The most important thing is to make sure you've disabled all the features you don't need in config.h. The default configuration enables most cryptographic mechanisms, but typical constrained systems usually only need a few. If your toolchain supports it, use link-time optimization (e.g. gcc -Os -flto or clang -Oz -flto). I've seen that this makes a significant improvement for Mbed TLS (I got -30% on one build, obviously the numbers depend heavily on the configuration and the compiler). (In contrast LTO when optimizing for performance doesn't seem to improve anything.) MBEDTLS_MPI_WINDOW_SIZE, MBEDTLS_MPI_MAX_SIZE and MBEDTLS_ECP_MAX_BITS only impact memory usage (stack and heap), not code size. -- Gilles Peskine Mbed TLS developer On 27/01/2021 05:36, T V LIJIN (EXT) via mbed-tls wrote: > Hi, > I'm trying to optimize the size of my binary file by making the > following changes in "*mbedtls/config.h*" > > #define MBEDTLS_MPI_WINDOW_SIZE 1 > #define MBEDTLS_MPI_MAX_SIZE 32 > #define MBEDTLS_ECP_MAX_BITS 256 > #define MBEDTLS_SHA256_SMALLER > > Even after making the above changes I couldn't see any change in the > binary size. > https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint > - This is the link I referred to follow the above-mentioned steps. > Is there anything else I can try to reduce my final binary file size > (ROM size) ? > > > Thanks, > LIJIN T V >

5 years

1
0
0 0

Re: [mbed-tls] ENTROPY_SOURCE_FAILED :0x0034

by Gilles Peskine

Hello, The entropy module uses a hash to mix the entropy. It uses SHA-512 if present and SHA-256 otherwise. Depending on the hash function, the entropy module can return either up to 64 bytes (SHA-512) or 32 bytes (SHA-256). The CTR_DRBG module knows about this and requests only 32 bytes at a time if the entropy module only delivers 32 bytes at a time. It looks like something goes wrong when CTR_DRBG tries to request 64 bytes. This could be, for example, because a buffer is too small somewhere, or because of a limitation of the entropy source. You would need to debug the call to mbedtls_entropy_func to know more. As a workaround, you can enable MBEDTLS_ENTROPY_FORCE_SHA256. Then the entropy module will use SHA-256 (even if MBEDTLS_SHA512_C is enabled) and only return 32 bytes at a time, and CTR_DRBG understands this and will only request 32 bytes. -- Gilles Peskine Mbed TLS developer On 27/01/2021 06:08, T V LIJIN (EXT) via mbed-tls wrote: > Hi, > After enabling *MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* , > /mbedtls_ctr_drbg_seed/ is returning *0x0034 > */(MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED)/ > But if I just enable *MBEDTLS_NO_PLATFORM_ENTROPY* and keep > *MBEDTLS_SHA512_C* disabled, it does not return any error for > /mbedtls_ctr_drbg_seed./ > / > / > My project uses certificates with SHA384 signature, so it > requires***MBEDTLS_SHA512_C *to be enabled. > /*MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* /both needs to be > enabled in my project , but Iam facing issue with > mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What > might be the reason for mbedtls_ctr_drbg_seed to fail while > enabling/////*MBEDTLS_SHA512_C.*///// > How to overcome this issue? > > > Thanks, > LIJIN T V >

5 years

1
0
0 0

ENTROPY_SOURCE_FAILED :0x0034

by T V LIJIN (EXT)

Hi, After enabling MBEDTLS_NO_PLATFORM_ENTROPY and MBEDTLS_SHA512_C , mbedtls_ctr_drbg_seed is returning 0x0034 (MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED) But if I just enable MBEDTLS_NO_PLATFORM_ENTROPY and keep MBEDTLS_SHA512_C disabled, it does not return any error for mbedtls_ctr_drbg_seed. My project uses certificates with SHA384 signature, so it requires MBEDTLS_SHA512_C to be enabled. MBEDTLS_NO_PLATFORM_ENTROPY and MBEDTLS_SHA512_C both needs to be enabled in my project , but Iam facing issue with mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What might be the reason for mbedtls_ctr_drbg_seed to fail while enabling MBEDTLS_SHA512_C. How to overcome this issue? Thanks, LIJIN T V

5 years

1
1
0 0

Reduce mbedTLS memory and storage footprint

by T V LIJIN (EXT)

Hi, I'm trying to optimize the size of my binary file by making the following changes in "mbedtls/config.h" #define MBEDTLS_MPI_WINDOW_SIZE 1 #define MBEDTLS_MPI_MAX_SIZE 32 #define MBEDTLS_ECP_MAX_BITS 256 #define MBEDTLS_SHA256_SMALLER Even after making the above changes I couldn't see any change in the binary size. https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint - This is the link I referred to follow the above-mentioned steps. Is there anything else I can try to reduce my final binary file size (ROM size) ? Thanks, LIJIN T V

5 years

1
0
0 0

Devices acting as Both Client and Server

by saghili

Dear, In our project, our device should act as both client and server. Is it possible for both TLS and DTLS? If yes, how about the certificate? Do we need only 2 certs for this divice (one for the server role and one for the client role)? Best regards, Farhad

5 years

1
0
0 0

Re: [mbed-tls] PKCS#7

by Gilles Peskine

Hello, There is work in progress by community members to implement PKCS#7 SignedData parsing and generation. https://github.com/ARMmbed/mbedtls/pull/3970 https://github.com/ARMmbed/mbedtls/pull/3431 Arm has no particular plans in this area, but if you need other parts of PKCS#7, we'd be happy to accept more contributions. We'll can't commit to doing any development, but we'll assist with submissions and review code as usual. -- Gilles Peskine Mbed TLS developer On 13/01/2021 07:31, Subramanian Gopi Krishnan via mbed-tls wrote: > > Hi, > > > > Is there a plan to support PKCS#7 Certificate in > future? We are work with rfc7030 service, which issues certificate in > PKCS#7 format. > > > > Thanks, > > Gopi Krishnan > >

5 years

1
0
0 0

PKCS#7

by Subramanian Gopi Krishnan

Hi, Is there a plan to support PKCS#7 Certificate in future? We are work with rfc7030 service, which issues certificate in PKCS#7 format. Thanks, Gopi Krishnan

5 years

1
0
0 0

Mbed TLS 2.7 end of support

by Dave Rodgman

This is a notice that Mbed TLS 2.7 will no longer be supported or maintained after February 5th 2021. Mbed TLS 2.7.0 was released on February 5th 2018 with a three year support period. The current version of Mbed TLS 2.7 is 2.7.18, which was released on December 11th 2020. There are no pending bug or security fixes, so unless new issues arise during the next month, there will not be another release of 2.7. We do not plan to merge any non-critical backports to 2.7 in the next month. We recommend that where practical, users upgrade to either 2.16, which will be supported until the end of 2021, or to the development branch, which will be released as an LTS in mid 2021, with an expected support period until mid 2024. Dave Rodgman

5 years

1
0
0 0

Add support to delegate cert verification to application

by Junqi Wang

Hi, Hanno suggested me to post our discussion here: We use mbedtls in Facebook family apps. One of missing features is the ability to delegate cert verification to application. Hanno has pointed us to a similar ask in https://github.com/ARMmbed/mbedtls/pull/2091 We implemented cert verification process in Android/java and iOS/objective-C. Having this feature enables us to use the OS module for cert verification. The motivation is reduced maintenance cost. Some mobile APPs use OS TLS stack (rather than bundle mbedtls or openssl in the binary), so we have to maintain our OS-specific cert verification modules anyways. It’ll be ideal if we only keep the Android and iOS implementations as source of truth. Any thoughts on supporting this? Thanks, Junqi

5 years, 1 month

1
0
0 0

DTLS Connection-ID update - potential issue for large-scale deployments

by Manuel Pegourie-Gonnard

Hi all, Back in June 2019, we added support for the experimental DTLS Connection ID extension in Mbed TLS 2.18.0. This extension makes it possible to keep a connection alive even when the client's connectivity changes (eg new IP address). Since this was based on a draft rather than an established standard, it is disabled in the default config, and the option to enable it comes with a warning about us not being able to make any stability promises. As it turns out, a couple of months ago an extension number was assigned by IANA for this extension, which is different from the one we picked up when implementing the draft, so we'll have to change that in a future version of Mbed TLS. This change is trivial to do but would break compatibility in the following sense: and old client and a new server (or a new client and a new server) would no longer be able to negotiate this extension; only old-old and new-new would work. (Thanks to Achim Kraus for bringing that to our attention by the way: https://github.com/ARMmbed/mbedtls/issues/3892 ) One obvious solution to that issue would be to make sure all users upgrade all the clients and the servers at the same time. This can probably be managed in a development/testing environment as well as some tightly controlled production environments, but is probably less suitable for large-scale deployments where clients and servers might not even be manged by the same party. So, before we plan this changed, we'll like to know if anyone already has a production deployment relying on Connection ID where updating all the clients and servers at the same time would not be an option. If that is the case, we may consider implementing a compatibility mode that would allow a server to negotiate use of the extension with both old and new clients. However, such compatibility code would be non-standard and a testing burden (not to mention, significantly more work that just updating the relevant #define), so that's something we'd like to avoid doing unless we know that there is an actual need for it. Please let us know what you think by replying to this email either on-list, or privately if you'd rather not share deployment information publicly (in that case, please mention it explicitly so that we know you didn't just forget to Cc the list). Thanks, Manuel

5 years, 1 month

1
0
0 0

Re: [mbed-tls] MBEDTLS issue I found

by Manuel Pegourie-Gonnard

Dear Xiao Nian Jun, Thanks for your response! Knowing the practical impact of the issue will help us prioritize it. Best regards, Manuel ________________________________ From: Xiao, Nian Jun <nianjun.xiao(a)siemens.com> Sent: 29 December 2020 02:43 To: Manuel Pegourie-Gonnard <Manuel.Pegourie-Gonnard(a)arm.com> Cc: He, Shu Shan <shushan.he(a)siemens.com>; Xia, Juan <juan.xia(a)siemens.com> Subject: RE: MBEDTLS issue I found Dear Manuel, Really appreciate for your quick and detail feedback. We think this is more like an interoperability issue, we found this issue during we developing webserver feature using MBEDTLS. Google Chrome treat such certificate as invalid. Follow below steps will reproduce this issue. 1. Generate a self-signed root certificate with ECC256 key.(using genKey and certWrite program of MBEDTLS) 2. Using above root certificate to sign a device certificate which also using ECC256 as its private key. (using genKey and certWrite program of MBEDTLS) 3. Install root certificate so Chrome can see it. 4. using Nginx or some other opensource web server, modify its configuration so it will use the device certificate and corresponding private key as the ciphers to setup TLS communication. 5. Open Chrome and visit default Nginx web page(or some other web server tools’ default web page), you can see Chrome won’t let user to continue because it treat the device certificate as invalid. 6. According to our test, Chrome has this issue, fire fox, IE, etc. doesn’t have this issue. 7. If I modify function mbedtls_asn1_write_algorithm_identifier like I said yesterday, Chrome will accept it and other browser also will accept it, happy life back again. Have a good day and looking for your feedback again! B.R. Xiao Nian Jun. From: Manuel Pegourie-Gonnard <Manuel.Pegourie-Gonnard(a)arm.com> Sent: Monday, December 28, 2020 9:23 PM To: mbed-tls(a)lists.trustedfirmware.org; Xiao, Nian Jun (RC-CN DI FA BL CTR-SL PRC2) <nianjun.xiao(a)siemens.com> Cc: He, Shu Shan (RC-CN DI FA BL CTR-SL PRC2) <shushan.he(a)siemens.com> Subject: Re: MBEDTLS issue I found Dear Xiao Nian Jun, Thanks for your kind words and for reporting this issue you found. I checked RFC 7427 and indeed while parameters must be present and NULL for all RSA algorithms, appendix A.3 is clear that they must be absent for ECDSA. Since RFC 7427 is about IKEv2 rather than about X.509 certificates, I also checked RFC 5480 (updating RFC 3279 which defines the X.509 profile used by the IETF), and it concurs: for ECDSA, parameters are absent (appendix A). Our behaviour is not conformant, and this should be fixed. Just to help us evaluate the severity of the issue, I'd like to know if this is something you found by inspecting the generated certificate yourself, or if it caused the generate certificate to be rejected by some other X.509 implementation or verification tool. Said otherwise, is this only a compliance issue, or also an interoperability issue? Regarding your fix, I think it works as long as you are only generating ECC-signed X.509 certificates, but as you suggest, I'm afraid it only fixes the problem by creating another one: it would suppress the NULL parameters for RSA as well, but unfortunately, they're mandatory there (I wish the standards were more consistent). So, we'll probably have to do something similar, but only for ECDSA. I was going to create a ticket for that in our bug tracker when I noticed we already have a ticket tracking that: https://github.com/ARMmbed/mbedtls/issues/2924 - Ill add a link to your message in the ticket. Thanks again for your report. Best regards, Manuel ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>> on behalf of Xiao, Nian Jun via mbed-tls <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Sent: 28 December 2020 03:24 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>> Cc: He, Shu Shan <shushan.he(a)siemens.com<mailto:shushan.he@siemens.com>> Subject: [mbed-tls] MBEDTLS issue I found Dear MBEDTLS team, I’m a developer at SIEMENS, my name is Xiao Nian Jun. Please accept my sincere gratitude for your excellent work and to spend extra time to read my email. We are using MBEDTLS to generate ECC key and certificates, we found an issue regarding algorithm identifier in the final ASN.1 certificate. For certificate signed by ECC key, the algorithm identifier is “NULL” which doesn’t conforms to RFC7427 specification. [cid:image001.png@01D6DDC1.DCE8CFC0] You can see the “NULL” string in the certificate, Chrome will treat this kind of certificate as invalid. This issue has blocked us for a while, and after some investigation, we found an easy fix –- probably immature fix --- to make it works right--- we just commented out this line of code “MBEDTLS_ASN1_CHK_ADD( len, mbedtls_asn1_write_null( p, start ) )" in function mbedtls_asn1_write_algorithm_identifier. To be honesty, we’ve been using MBEDTLS for very short time, probably this is not an issue, probably our fix will end up break up something…currently, it’s just looks correct. Please check if my fix works or not, if not, please do not hesitate to correct me. B.R. Xiao Nian Jun.

5 years, 1 month

2
1
0 0

Re: [mbed-tls] MBEDTLS issue I found

by Manuel Pegourie-Gonnard

Dear Xiao Nian Jun, Thanks for your kind words and for reporting this issue you found. I checked RFC 7427 and indeed while parameters must be present and NULL for all RSA algorithms, appendix A.3 is clear that they must be absent for ECDSA. Since RFC 7427 is about IKEv2 rather than about X.509 certificates, I also checked RFC 5480 (updating RFC 3279 which defines the X.509 profile used by the IETF), and it concurs: for ECDSA, parameters are absent (appendix A). Our behaviour is not conformant, and this should be fixed. Just to help us evaluate the severity of the issue, I'd like to know if this is something you found by inspecting the generated certificate yourself, or if it caused the generate certificate to be rejected by some other X.509 implementation or verification tool. Said otherwise, is this only a compliance issue, or also an interoperability issue? Regarding your fix, I think it works as long as you are only generating ECC-signed X.509 certificates, but as you suggest, I'm afraid it only fixes the problem by creating another one: it would suppress the NULL parameters for RSA as well, but unfortunately, they're mandatory there (I wish the standards were more consistent). So, we'll probably have to do something similar, but only for ECDSA. I was going to create a ticket for that in our bug tracker when I noticed we already have a ticket tracking that: https://github.com/ARMmbed/mbedtls/issues/2924 - Ill add a link to your message in the ticket. Thanks again for your report. Best regards, Manuel ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Xiao, Nian Jun via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 28 December 2020 03:24 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Cc: He, Shu Shan <shushan.he(a)siemens.com> Subject: [mbed-tls] MBEDTLS issue I found Dear MBEDTLS team, I’m a developer at SIEMENS, my name is Xiao Nian Jun. Please accept my sincere gratitude for your excellent work and to spend extra time to read my email. We are using MBEDTLS to generate ECC key and certificates, we found an issue regarding algorithm identifier in the final ASN.1 certificate. For certificate signed by ECC key, the algorithm identifier is “NULL” which doesn’t conforms to RFC7427 specification. [cid:image001.png@01D6DD01.C51C7290] You can see the “NULL” string in the certificate, Chrome will treat this kind of certificate as invalid. This issue has blocked us for a while, and after some investigation, we found an easy fix –- probably immature fix --- to make it works right--- we just commented out this line of code “MBEDTLS_ASN1_CHK_ADD( len, mbedtls_asn1_write_null( p, start ) )" in function mbedtls_asn1_write_algorithm_identifier. To be honesty, we’ve been using MBEDTLS for very short time, probably this is not an issue, probably our fix will end up break up something…currently, it’s just looks correct. Please check if my fix works or not, if not, please do not hesitate to correct me. B.R. Xiao Nian Jun.

5 years, 1 month

1
0
0 0

MBEDTLS issue I found

by Xiao, Nian Jun

Dear MBEDTLS team, I’m a developer at SIEMENS, my name is Xiao Nian Jun. Please accept my sincere gratitude for your excellent work and to spend extra time to read my email. We are using MBEDTLS to generate ECC key and certificates, we found an issue regarding algorithm identifier in the final ASN.1 certificate. For certificate signed by ECC key, the algorithm identifier is “NULL” which doesn’t conforms to RFC7427 specification. [cid:image001.png@01D6DD01.C51C7290] You can see the “NULL” string in the certificate, Chrome will treat this kind of certificate as invalid. This issue has blocked us for a while, and after some investigation, we found an easy fix –- probably immature fix --- to make it works right--- we just commented out this line of code “MBEDTLS_ASN1_CHK_ADD( len, mbedtls_asn1_write_null( p, start ) )" in function mbedtls_asn1_write_algorithm_identifier. To be honesty, we’ve been using MBEDTLS for very short time, probably this is not an issue, probably our fix will end up break up something…currently, it’s just looks correct. Please check if my fix works or not, if not, please do not hesitate to correct me. B.R. Xiao Nian Jun.

5 years, 1 month

1
0
0 0

Mbed TLS 3.0 plans

by Dave Rodgman

Hello, We are planning to release Mbed TLS 3.0 around June 2021, alongside an LTS release of Mbed TLS 2.x. Our major version numbers indicate API breaking changes, and this is no exception: Mbed TLS 3.0 will have changes that make it incompatible with 2.x (as an obvious example, functions that are deprecated in 2.x will be removed). In setting a near-term release date, we have chosen some key areas that we want to focus on for 3.0. Some other API-breaking items (i.e., those requiring significant design time) won't make the cut and we will hold those back for a future major version, in order to have time to get them right. The main focus for 3.0 will be reduction in API surface, and changes that are low-impact for almost everyone. Work towards 3.0 will start in late January, on the development branch which will contain a public work-in-progress view of Mbed TLS 3.0. Any work for 2.x in this timeframe will take place on a separate branch (provisionally named like "mbedtls-2.x"). During the 3.0 development period, bug fixes and security fixes will continue to be a priority, but we will have slightly less capacity for other features. While 3.0 is in development, any new features will by default be landed in 3.0 only, unless there is a strong case for back-porting to 2.x. The 2.x LTS branches will still be supported with bug fixes and security fixes for the normal three year lifetime (i.e., the final LTS release of 2.x in mid-2021 will be supported until mid-2024). In terms of content, we are taking a cautious approach to what we plan for 3.0. In the past we've been ambitious here and as a result, have slipped on the release date; by being cautious on feature set we can be confident about hitting the mid-year release date. We won't try to make all of the changes that would be nice-to-have; instead, we will focus on tasks that reduce maintenance, unlock other improvements in a 3.x timeframe, are still valuable if only partially completed, and can fit within this time frame. Currently we're looking at the following areas for 3.0: * Reduce the public surface of the API * Clean-up existing APIs * Changes to default options Regards Dave Rodgman

5 years, 1 month

1
0
0 0

Re: [mbed-tls] "Reordering" in DTLS

by Manuel Pegourie-Gonnard

Hi Farhad, I think for this question as well as the "packets lost" question, it's important to distinguish two phases of a DTLS connection: initially there's a handshake (to negotiate and establish security parameters and session keys), and then application data can be exchanged. Application data is what's passed to `mbedtls_ssl_write()` or written by `mbedtls_ssl_read()` (depending on whether you're the sender or receiver) - this can only happen once the handshake is completed. During the handshake, there are indeed mechanisms to re-order packets that were received out of order and also retransmit packets that were lost. But that's only during the handshake (because it's a lockstep process where everything needs to happen in order), and only for data that's purely internal to the DTLS protocol and never seen by the application. Once the handshake is completed and application data starts to be exchanged, there is no longer any kind of re-ordering or retransmission mechanism. The reason is, as you guessed, DTLS aims to provide similar properties to UDP - with cryptographic security in addition. So, if you send something with `mbedtls_ssl_write()` and the record gets lost, the DTLS protocol won't even know about it, and no retransmission will happen. If record N+1 arrives before record N, the DTLS protocol will know but do nothing, and just deliver the records in the order they arrived. Again, as you said, doing otherwise would introduce latency and be contrary to the goals of DTLS - people who want reliability at the expense of latency should use TLS. The main exception to that principle that you can expect DTLS to behave like UDP is duplicated records: the DTLS protocol provide optional replay protection (that is, if record N arrives twice, the second occurrence is dropped). In Mbed TLS, this mechanism is enabled by default but can be disabled at compile-time by not defining MBEDTLS_SSL_DTLS_ANTI_REPLAY in config.h, or at runtime by calling mbedtls_ssl_conf_dtls_anti_replay(). I hope this answers your questions. Regards, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of saghili via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 10 December 2020 18:31 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] "Reordering" in DTLS Hello, I have a question about DTLS. One thing that is not entirely clear to me from the RFC is this: suppose 2 records are received within a "short" period, e.g. seq# N+1 followed by seq# N. In this case, what does DTLS do? My understanding is that it will pass on packets in the order it was received (i.e. out of order). But it can (should?) re-order at the DTLS layer and pass them on to the upper layer in the right order. HOWEVER, this implies that the DTLS "wait" for a certain window to see if the seq#=N packet arrives or not. But doing so introduces additional delay at DTLS layer and also contradicts with the UDP principle (i.e. no concept of order). Could you please give me a hint regarding this issue? Best regards, Farhad -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 1 month

2
2
0 0

[Mbed-tls-announce] Mbed TLS: Release of Mbed TLS 2.25.0, 2.16.9 and 2.7.18

by Janos Follath via Mbed-tls-announce

Mbed TLS versions 2.25.0, 2.16.9 and 2.7.18 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://github.com/ARMmbed/mbedtls/releases/tag/v2.25.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.9, https://github.com/ARMmbed/mbedtls/releases/tag/v2.7.18 ). 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, 1 month

1
0
0 0

"Reordering" in DTLS

by saghili

Hello, I have a question about DTLS. One thing that is not entirely clear to me from the RFC is this: suppose 2 records are received within a "short" period, e.g. seq# N+1 followed by seq# N. In this case, what does DTLS do? My understanding is that it will pass on packets in the order it was received (i.e. out of order). But it can (should?) re-order at the DTLS layer and pass them on to the upper layer in the right order. HOWEVER, this implies that the DTLS "wait" for a certain window to see if the seq#=N packet arrives or not. But doing so introduces additional delay at DTLS layer and also contradicts with the UDP principle (i.e. no concept of order). Could you please give me a hint regarding this issue? Best regards, Farhad

5 years, 1 month

1
0
0 0

"packets lost" in DTLS in "Record" layer

by saghili

Hello, I have a question about DTLS. Because of the latency, I need to disable the "packets lost" feature. Does MbedTLS provide the flag that we can disable resending the packet in case of the packet lost? For instance, if I have 3 packets 42, 43, and 44, is it possible to decrypt packet 44 without receiving packets 42 and 43? It will be in the "Record" layer. Thank you. Best regards, Farhad

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

by Сысоев Андрей

Thank you for quick response. > Are you using blocking or non-blocking I/O? Non-blocking IO I've preset bio_send/recv callbacks I have pair of buffers, transport buffer and application buffer, for reading and writing (4 buffers total). Application buffers are protected by mutexes. Transport buffers are written/read in bio_send/recv (if no async op pending, otherwise WANT_READ/WRITE). mbedtls_ssl_xxx work with application buffers. > Are you using TLS or DTLS? What protocol version, what cipher suite and what extensions are negotiated? TLS (over tcp, no lossy channel involved) version 1.2 > Does your application call mbedtls_ssl_write() and mbedtls_ssl_read() again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or MBEDTLS_ERR_SSL_WANT_WRITE? Well, actually, no. AND it's quite possible, that application outgoing buffer (std::vector) has been relocated between mbedtls_ssl_write calls, because app could push data several times while async op was pending and bio_send returned WANT_WRITE, causing these buffers to resize. So buf.data() will not be equal to that from previous mbedtls_ssl_write call. Is this what causes trouble? It's somehow connected to partial sends? I do call ssl_write inside while-loop, counting sent and unsent bytes - thought this was enough. But if mbedtls somehow remembers addresses from previos calls - that might cause problems. > Do you close the TLS connection if mbedtls_ssl_xxx() returns an error other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)? Yes, but that never happens (from handshake to until problem appears) > What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)? Not defined in config, looks like both 16834 >What operating system are you using? Ubuntu 20, Kali 20 > Is this a client or a server? What TLS stack does the other side run? Both are written same way, both using same library. I'll try to prepare test-case code, that reproduces the problem, and logs, but that will require some time. 10.12.2020 1:07, Gilles Peskine via mbed-tls пишет: > Hi Андрей, > > The behavior you describe is a bug. But there isn't enough information > to tell whether the bug is in Mbed TLS, in asio-standalone, in some > other third-party code, or in your application. > > Some things to consider: > > * Are you using blocking or non-blocking I/O? > * Are you using TLS or DTLS? What protocol version, what cipher suite > and what extensions are negotiated? > * Does your application call mbedtls_ssl_write() and mbedtls_ssl_read() > again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or > MBEDTLS_ERR_SSL_WANT_WRITE? > * Do you close the TLS connection if mbedtls_ssl_xxx() returns an error > other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)? > * What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or > MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)? > * What operating system are you using? > * Is this a client or a server? What TLS stack does the other side run? > > You'll give others the most chance to help you if you post small, > complete code to reproduce the problem. I realize this may be difficult. > A good intermediate way to see what is going on would be to post debug > logs. To get debug logs, make sure that MBEDTLS_DEBUG_C is enabled and > call these functions before opening the TLS connection: > > mbedtls_ssl_conf_dbg(&ssl_conf, my_debug, stdout); > mbedtls_debug_set_threshold(2); > > See https://tls.mbed.org/kb/how-to/mbedtls-tutorial for a sample version > of my_debug(). > > Calls to bio_send() are shown in the logs as > > => flush output > message length: %d, out_left: %d > ssl->f_send() returned %d > <= flush output > > If they don't show expected numbers, the rest of the logs should give a > clue as to why. > > Hope this helps, >

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

by Gilles Peskine

By the way, I notice you're using Mbed TLS 2.16.3. This version has known bugs, including security issues. Please upgrade to the latest Mbed TLS 2.16.x (currently 2.16.8, very soon 2.16.9) which is a security and bugfix update, or to the latest release (2.24.0, soon 2.25.0) which has all the latest bugfixes and features. Looking at the changelog, I don't see any mention of a bug that could explain your problem, but I might have missed something. -- Gilles Peskine Mbed TLS developer On 09/12/2020 22:17, Сысоев Андрей via mbed-tls wrote: > Hello. > > I need a little help with mbedtls 2.16.3. > I'm using it under x86-64 with asio-standalone. > > Here's a standard situation: > - I call mbedtls_ssl_write() to write let's say 8192 bytes of payload > - it calls my own bio_send() with (8192+21) bytes as len parameter > - bio_send() returns len=(8192+21), indicating transport data > correctly written > - mbedtls_ssl_write() returns 8192, indicating payload send > GOOD: next I use this value to shift application buffer (erase first > 8192 bytes), then send next chunk > > BUT after some time of running this situation happens: > - once again, a call to mbedtls_ssl_write() to write let's say 8192 > bytes of payload > - it calls bio_send() with smaller number, about 5500 bytes as len > parameter (?? but OK) > - bio_send() returns len=5500, indicating transport data correctly > written > - mbedtls_ssl_write() returns 8192 (??? why not 5500 ???), indicating > payload send > BAD: next I use this value to shift application buffer (erase first > 8192 bytes), this leads to data loss of (8192-5500)=2692 bytes and > ruins protocol > > As you can see, mbedtls_ssl_write() incorrectly reports about sent > application data (8192 instead of 5500) - is this a bug? How can such > situation happen under normal operation? > > Thanks in advance. >

5 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

by Gilles Peskine

Hi Андрей, The behavior you describe is a bug. But there isn't enough information to tell whether the bug is in Mbed TLS, in asio-standalone, in some other third-party code, or in your application. Some things to consider: * Are you using blocking or non-blocking I/O? * Are you using TLS or DTLS? What protocol version, what cipher suite and what extensions are negotiated? * Does your application call mbedtls_ssl_write() and mbedtls_ssl_read() again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or MBEDTLS_ERR_SSL_WANT_WRITE? * Do you close the TLS connection if mbedtls_ssl_xxx() returns an error other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)? * What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)? * What operating system are you using? * Is this a client or a server? What TLS stack does the other side run? You'll give others the most chance to help you if you post small, complete code to reproduce the problem. I realize this may be difficult. A good intermediate way to see what is going on would be to post debug logs. To get debug logs, make sure that MBEDTLS_DEBUG_C is enabled and call these functions before opening the TLS connection: mbedtls_ssl_conf_dbg(&ssl_conf, my_debug, stdout); mbedtls_debug_set_threshold(2); See https://tls.mbed.org/kb/how-to/mbedtls-tutorial for a sample version of my_debug(). Calls to bio_send() are shown in the logs as => flush output message length: %d, out_left: %d ssl->f_send() returned %d <= flush output If they don't show expected numbers, the rest of the logs should give a clue as to why. Hope this helps, -- Gilles Peskine Mbed TLS developer On 09/12/2020 22:17, Сысоев Андрей via mbed-tls wrote: > Hello. > > I need a little help with mbedtls 2.16.3. > I'm using it under x86-64 with asio-standalone. > > Here's a standard situation: > - I call mbedtls_ssl_write() to write let's say 8192 bytes of payload > - it calls my own bio_send() with (8192+21) bytes as len parameter > - bio_send() returns len=(8192+21), indicating transport data > correctly written > - mbedtls_ssl_write() returns 8192, indicating payload send > GOOD: next I use this value to shift application buffer (erase first > 8192 bytes), then send next chunk > > BUT after some time of running this situation happens: > - once again, a call to mbedtls_ssl_write() to write let's say 8192 > bytes of payload > - it calls bio_send() with smaller number, about 5500 bytes as len > parameter (?? but OK) > - bio_send() returns len=5500, indicating transport data correctly > written > - mbedtls_ssl_write() returns 8192 (??? why not 5500 ???), indicating > payload send > BAD: next I use this value to shift application buffer (erase first > 8192 bytes), this leads to data loss of (8192-5500)=2692 bytes and > ruins protocol > > As you can see, mbedtls_ssl_write() incorrectly reports about sent > application data (8192 instead of 5500) - is this a bug? How can such > situation happen under normal operation? > > Thanks in advance. >

5 years, 1 month

1
0
0 0

mbedtls undefined behaviour

by Сысоев Андрей

Hello. I need a little help with mbedtls 2.16.3. I'm using it under x86-64 with asio-standalone. Here's a standard situation: - I call mbedtls_ssl_write() to write let's say 8192 bytes of payload - it calls my own bio_send() with (8192+21) bytes as len parameter - bio_send() returns len=(8192+21), indicating transport data correctly written - mbedtls_ssl_write() returns 8192, indicating payload send GOOD: next I use this value to shift application buffer (erase first 8192 bytes), then send next chunk BUT after some time of running this situation happens: - once again, a call to mbedtls_ssl_write() to write let's say 8192 bytes of payload - it calls bio_send() with smaller number, about 5500 bytes as len parameter (?? but OK) - bio_send() returns len=5500, indicating transport data correctly written - mbedtls_ssl_write() returns 8192 (??? why not 5500 ???), indicating payload send BAD: next I use this value to shift application buffer (erase first 8192 bytes), this leads to data loss of (8192-5500)=2692 bytes and ruins protocol As you can see, mbedtls_ssl_write() incorrectly reports about sent application data (8192 instead of 5500) - is this a bug? How can such situation happen under normal operation? Thanks in advance.

5 years, 1 month

1
0
0 0

Re: [mbed-tls] Implementing MbedTLS on "xilinx zu7 zynq ultrascale+soc"

by Gilles Peskine

Hi Farhad, Mbed TLS currently supports hardware acceleration through alternative implementations of the corresponding modules or functions. See https://tls.mbed.org/kb/development/hw_acc_guidelines . This mechanism is available for symmetric cryptography and partially for RSA and ECC. There is some work in progress on a new mechanism for hardware acceleration through the psa_xxx() API, which will be available for all algorithms. You can follow the work in progress on the “Unified driver interface: API design and prototype” epic at https://github.com/ARMmbed/mbedtls/projects/2#column-8543266 . Hope this helps, -- Gilles Peskine Mbed TLS developer On 04/12/2020 11:20, saghili via mbed-tls wrote: > Dear Sir/Madam, > > Our platform is a quad core Cortex A53 running PetaLinux. > In our hardware, "AF_ALG" module has performance accelerations > available through the Linux crypto drivers. > Is it possible that we have "AF_ALG" for offloading crypto operations? > > Best regards, > Farhad

5 years, 2 months

1
0
0 0

Implementing MbedTLS on "xilinx zu7 zynq ultrascale+soc"

by saghili

Dear Sir/Madam, Our platform is a quad core Cortex A53 running PetaLinux. In our hardware, "AF_ALG" module has performance accelerations available through the Linux crypto drivers. Is it possible that we have "AF_ALG" for offloading crypto operations? Best regards, Farhad

5 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls