- mbed-tls - lists.trustedfirmware.org

by stefano664

Hi all, I have some problems with mbedTLS during ECDSA signing process. I followed the example supplied with the source code and write this code: mbedtls_pk_init(&pk); mbedtls_pk_parse_key(&pk, (const unsigned char *) flash.flash_ver0.ecc_priv_key, strlen(flash.flash_ver0.ecc_priv_key) + 1, (const unsigned char *)CA_DEF_ISSUER_PWD, CA_DEF_ISSUER_PWD_LEN); mbedtls_md(mbedtls_md_info_from_type(MBEDTLS_MD_SHA256), msg, msg_len, hash); mbedtls_pk_sign(&pk, MBEDTLS_MD_SHA256, hash, 0, tmp, (size_t *)&len, mbedtls_ctr_drbg_random, &ctr_drbg); The private key is an ECC key with 384 bit. I have two issue: 1) In tmp variable I found the signature, but it is 72 byte, instead of 96 (384*2/87); 2) On this signature I try to make a verify, but fails. Where I'm wrong? Best regards, Stefano

4 years, 7 months

1
0
0 0

Re: [mbed-tls] TLS serialization

by Manuel Pegourie-Gonnard

Hi Jérémy, Thanks for your question! Indeed, the context (de)serialization feature only support DTLS so far. We've added an enhancement request to our backlog to extend it to TLS: https://github.com/ARMmbed/mbedtls/issues/4340 However, it may take some time before we get to it, as we're currently focused on preparing Mbed TLS 3.0. Also, this enhancement may very well turn out to be more complex that it might look initially: TLS is a reliable stream protocol (as opposed to DTLS which is an unreliable datagram protocol) and there will probably be some precautions to take and corner case to handle in order to make sure the full stream is preserved. If you or anyone else wants to open a PR for that, that would obviously help - though again, I'm afraid we'll have little review bandwidth until the end of June. (More generally, it's always a good idea to coordinate on the list before raising a large or complex PR.) Regards, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Jérémy Audiger via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 12 April 2021 18:39 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] TLS serialization Hi everyone, I'm currently trying to add the ability to serialize / deserialize a TLS security session using these APIs: * mbedtls_ssl_context_load() * mbedtls_ssl_context_save() I'm on TLS Server-side (so not talking about TLS Client here). After digging through the mailing list, I discovered this previous topic: https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000012.html and this Github repository: https://github.com/dimakuv/mbedtls-psk-example The scenario is the same here: using PSK with ciphersuite MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8 Once the handshake is done, I'm able to serialize the TLS session with the patch attached to this email. After that I'm able to decrypt one incoming packet and encrypt one ongoing packet. So, almost everything is fine. But, when the TLS Server is receiving another message from the TLS Client (message sent in two fragments), the Server is able to decrypt the first fragment but not the second one, getting this error: ssl_msg.c:5475: 0x7f9aa803d288: => read ssl_msg.c:4029: 0x7f9aa803d288: => read record ssl_msg.c:2012: 0x7f9aa803d288: => fetch input ssl_msg.c:2167: 0x7f9aa803d288: in_left: 0, nb_want: 5 ssl_msg.c:2192: 0x7f9aa803d288: in_left: 0, nb_want: 5 ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input ssl_msg.c:3763: 0x7f9aa803d288: dumping 'input record header' (5 bytes) ssl_msg.c:3763: 0x7f9aa803d288: 0000: 17 03 03 00 41 ....A ssl_msg.c:3765: 0x7f9aa803d288: input record: msgtype = 23, version = [3:3], msglen = 65 ssl_msg.c:2012: 0x7f9aa803d288: => fetch input ssl_msg.c:2167: 0x7f9aa803d288: in_left: 5, nb_want: 70 ssl_msg.c:2192: 0x7f9aa803d288: in_left: 5, nb_want: 70 ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 65 (-0xffffffbf) ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input ssl_msg.c:3874: 0x7f9aa803d288: dumping 'input record from network' (70 bytes) ssl_msg.c:3874: 0x7f9aa803d288: 0000: 17 03 03 00 41 00 00 00 00 00 00 00 03 27 9d 1a ....A........'.. ssl_msg.c:3874: 0x7f9aa803d288: 0010: 50 14 ff e1 14 8c b0 f5 de 06 1c f0 43 5c a0 91 P...........C\.. ssl_msg.c:3874: 0x7f9aa803d288: 0020: 46 23 3e 42 86 ed 3a 48 38 3d e8 b4 05 09 50 ac F#>B..:H8=....P. ssl_msg.c:3874: 0x7f9aa803d288: 0030: 94 6b 9c fb c6 22 7b 46 62 e0 af 08 ab 60 50 3c .k..."{Fb....`P< ssl_msg.c:3874: 0x7f9aa803d288: 0040: 6d c6 c8 7c cb 2c m..|., ssl_msg.c:1301: 0x7f9aa803d288: => decrypt buf ssl_msg.c:1414: 0x7f9aa803d288: dumping 'additional data used for AEAD' (13 bytes) ssl_msg.c:1414: 0x7f9aa803d288: 0000: 00 00 00 00 00 00 00 02 17 03 03 00 31 ............1 ssl_msg.c:1423: 0x7f9aa803d288: dumping 'IV used' (12 bytes) ssl_msg.c:1423: 0x7f9aa803d288: 0000: db 70 01 4b 00 00 00 00 00 00 00 03 .p.K........ ssl_msg.c:1424: 0x7f9aa803d288: dumping 'TAG used' (8 bytes) ssl_msg.c:1424: 0x7f9aa803d288: 0000: 50 3c 6d c6 c8 7c cb 2c P<m..|., ssl_msg.c:1437: 0x7f9aa803d288: mbedtls_cipher_auth_decrypt() returned -25344 (-0x6300) ssl_msg.c:3900: 0x7f9aa803d288: ssl_decrypt_buf() returned -29056 (-0x7180) Between each emission or reception of the fragment, the TLS security context is loaded and saved into a database. The use case here is really interesting, it seems to work well except when I receive or emit a message split into multiple fragments. Something is lost during the session backup. Maybe an interesting thing to add is when I'm loading a TLS session from the database, I'm following these steps: * Load the session into a buffer from the database * Init a security session with mbedtls_ssl_init() and mbedtls_ssl_setup() * Load the session from the buffer with mbedtls_ssl_context_load() Since I'm not an expert of mbed TLS code, I would like to know if someone could help me investigate this issue. TLS serialization/deserialization could be interesting to be part of the mbed TLS library. Regards, Jérémy Audiger

4 years, 7 months

2
1
0 0

3.0 Proposal: remove 3DES ciphersuites

by Manuel Pegourie-Gonnard

Hi all, We'd like to completely remove support for 3DES TLS ciphersuites in Mbed TLS 3.0. Those ciphersuites are vulnerable to the Sweet32 attack and 3DES has been deprecated by NIST. If we remove them from Mbed TLS 3.0, they will remain available in Mbed TLS 2.16 and 2.x, the latter being supported until 3 years after 3.0 has been released. As usual, if for any reason you need support for 3DES TLS ciphersuites in Mbed TLS 3.0, please speak up now and let use know about your use case! More context can be found at https://github.com/ARMmbed/mbedtls/issues/4367 Regards, Manuel.

4 years, 7 months

1
0
0 0

3.0 proposal: remove support for MD2, MD4, RC4, Blowfish and XTEA

by Ronald Cron

Hi, We consider removing the support for MD2, MD4, RC4, Blowfish and XTEA from Mbed TLS 3.0 (but the support will remain in the 2.16 and 2.2x LTS branches for the course of their lifetime). If you use one of those cryptographic primitives and think it should remain in Mbed TLS 3.0, please let us know and explain why. You can find more information in the following GitHub issue: https://github.com/ARMmbed/mbedtls/issues/4084. Best regards, Ronald Cron.

4 years, 7 months

1
0
0 0

SSL session cache API in Mbed TLS 3.0

by Hanno Becker

Hi Mbed TLS enthusiasts, For Mbed TLS 3.0, we're considering to modify the API around SSL sessions and server-side SSL session caches as follows: 1) The mbedtls_ssl_session structure becomes opaque, that is, its layout, fields, size is not part of the API and thus not subject to any stability promises. Instances of mbedtls_ssl_session may only be accessed through public function API. At the time of writing, this is mainly mbedtls_ssl_session_load()/save() for session serialization and deserialization. In particular, user code requiring access to specific fields of mbedtls_ssl_session won't be portable without further adjustments, e.g. the addition of getter functions. If you access fields of mbedtls_ssl_session in your code and would like to retain the ability to do so, now is the time to speak up and let us know about your use case. 2) The SSL session cache API gets modified as proposed in https://github.com/ARMmbed/mbedtls/issues/4333#issuecomment-820297322: int mbedtls_ssl_cache_get( void *data, unsigned char const *session_id, size_t session_id_len, mbedtls_ssl_session *dst_session ); int mbedtls_ssl_cache_set( void *data, unsigned char const *session_id, size_t session_id_len, mbedtls_ssl_session const *session ); In words: The session ID becomes an explicit parameter. This modification is necessary because the present session cache API requires custom implementations to peek into the mbedtls_ssl_session structure, at least to inspect the session ID. With the session ID being added as an explicit parameter, this is no longer necessary. We propose that custom session cache implementations treat mbedtls_ssl_session instances opaquely and only use them through the serialization and deserialization API mbedtls_ssl_session_load()/save(). The reason why the proposed API does not operate on serialized data directly is that this would enforce unnecessary copies. If you are using a custom SSL server-side session cache implementation which accesses fields other than the session ID and which can not be implemented based on session serialization, now is the time to speak up and let us know about your use case. Kind regards, Hanno

4 years, 8 months

1
0
0 0

3.0 proposal: remove support for Truncated HMAC

by Manuel Pegourie-Gonnard

Hi everyone, Truncated HMAC is a TLS extension that was originally created to reduce overhead in constrained environments. Nowadays, CCM-8 ciphersuites are an alternative that's superior both in terms of having even lower overhead and in terms of security. Consequently, recent RFCs have stated that the Truncated HMAC extensions must no longer be used. So, we would like to entirely remove support for this extension from Mbed TLS 3.0. (LTS branches would obviously retain support for it.) If you need support for Truncated HMAC extension in Mbed TLS 3.0, please speak up now! More context and details can be found in this github issue, which can also be used for discussion: https://github.com/ARMmbed/mbedtls/issues/4341 Regards, Manuel.

4 years, 8 months

1
0
0 0

TLS serialization

by Jérémy Audiger

Hi everyone, I'm currently trying to add the ability to serialize / deserialize a TLS security session using these APIs: * mbedtls_ssl_context_load() * mbedtls_ssl_context_save() I'm on TLS Server-side (so not talking about TLS Client here). After digging through the mailing list, I discovered this previous topic: https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000012.html and this Github repository: https://github.com/dimakuv/mbedtls-psk-example The scenario is the same here: using PSK with ciphersuite MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8 Once the handshake is done, I'm able to serialize the TLS session with the patch attached to this email. After that I'm able to decrypt one incoming packet and encrypt one ongoing packet. So, almost everything is fine. But, when the TLS Server is receiving another message from the TLS Client (message sent in two fragments), the Server is able to decrypt the first fragment but not the second one, getting this error: ssl_msg.c:5475: 0x7f9aa803d288: => read ssl_msg.c:4029: 0x7f9aa803d288: => read record ssl_msg.c:2012: 0x7f9aa803d288: => fetch input ssl_msg.c:2167: 0x7f9aa803d288: in_left: 0, nb_want: 5 ssl_msg.c:2192: 0x7f9aa803d288: in_left: 0, nb_want: 5 ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input ssl_msg.c:3763: 0x7f9aa803d288: dumping 'input record header' (5 bytes) ssl_msg.c:3763: 0x7f9aa803d288: 0000: 17 03 03 00 41 ....A ssl_msg.c:3765: 0x7f9aa803d288: input record: msgtype = 23, version = [3:3], msglen = 65 ssl_msg.c:2012: 0x7f9aa803d288: => fetch input ssl_msg.c:2167: 0x7f9aa803d288: in_left: 5, nb_want: 70 ssl_msg.c:2192: 0x7f9aa803d288: in_left: 5, nb_want: 70 ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 65 (-0xffffffbf) ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input ssl_msg.c:3874: 0x7f9aa803d288: dumping 'input record from network' (70 bytes) ssl_msg.c:3874: 0x7f9aa803d288: 0000: 17 03 03 00 41 00 00 00 00 00 00 00 03 27 9d 1a ....A........'.. ssl_msg.c:3874: 0x7f9aa803d288: 0010: 50 14 ff e1 14 8c b0 f5 de 06 1c f0 43 5c a0 91 P...........C\.. ssl_msg.c:3874: 0x7f9aa803d288: 0020: 46 23 3e 42 86 ed 3a 48 38 3d e8 b4 05 09 50 ac F#>B..:H8=....P. ssl_msg.c:3874: 0x7f9aa803d288: 0030: 94 6b 9c fb c6 22 7b 46 62 e0 af 08 ab 60 50 3c .k..."{Fb....`P< ssl_msg.c:3874: 0x7f9aa803d288: 0040: 6d c6 c8 7c cb 2c m..|., ssl_msg.c:1301: 0x7f9aa803d288: => decrypt buf ssl_msg.c:1414: 0x7f9aa803d288: dumping 'additional data used for AEAD' (13 bytes) ssl_msg.c:1414: 0x7f9aa803d288: 0000: 00 00 00 00 00 00 00 02 17 03 03 00 31 ............1 ssl_msg.c:1423: 0x7f9aa803d288: dumping 'IV used' (12 bytes) ssl_msg.c:1423: 0x7f9aa803d288: 0000: db 70 01 4b 00 00 00 00 00 00 00 03 .p.K........ ssl_msg.c:1424: 0x7f9aa803d288: dumping 'TAG used' (8 bytes) ssl_msg.c:1424: 0x7f9aa803d288: 0000: 50 3c 6d c6 c8 7c cb 2c P<m..|., ssl_msg.c:1437: 0x7f9aa803d288: mbedtls_cipher_auth_decrypt() returned -25344 (-0x6300) ssl_msg.c:3900: 0x7f9aa803d288: ssl_decrypt_buf() returned -29056 (-0x7180) Between each emission or reception of the fragment, the TLS security context is loaded and saved into a database. The use case here is really interesting, it seems to work well except when I receive or emit a message split into multiple fragments. Something is lost during the session backup. Maybe an interesting thing to add is when I'm loading a TLS session from the database, I'm following these steps: * Load the session into a buffer from the database * Init a security session with mbedtls_ssl_init() and mbedtls_ssl_setup() * Load the session from the buffer with mbedtls_ssl_context_load() Since I'm not an expert of mbed TLS code, I would like to know if someone could help me investigate this issue. TLS serialization/deserialization could be interesting to be part of the mbed TLS library. Regards, Jérémy Audiger

4 years, 8 months

1
0
0 0

3.0 proposal: remove support for TLS 1.0, TLS 1.1 and DTLS 1.0

by Manuel Pegourie-Gonnard

Hi everyone, The IETF has recently published RFC 8996, which formally deprecates TLS 1.0, TLS 1.1 and DTLS 1.0 (there is no DTLS 1.1). One of the stated goals of the RFC is to empower maintainers of (D)TLS stacks to remove them from their code base, reducing the maintenance cost and the attack surface at the same time. This RFC comes right during the time we're preparing a new major version, which is the only time we allow ourselves to remove features. We'd like to take advantage of this opportunity by entirely removing support for TLS 1.0, TLS 1.1 and DTLS 1.0 in Mbed TLS 3.0. (They would obviously stay in our long-term support branches.) If you find yourself needing support for these versions in Mbed TLS 3.0, now is the time to speak up! More details can be found in the following github issue: https://github.com/ARMmbed/mbedtls/issues/4286 Feel free to discuss this issue on the list or on github, whatever's more convenient for you. Best regards, Manuel.

4 years, 8 months

1
0
0 0

Mbed TLS 3.0 branching

by Dave Rodgman

Hello Mbed TLS users, As previously announced, we are going to switch the focus of Mbed TLS development onto the upcoming 3.0 release. * We have created the development_2.x branch, currently aligned with the tip of development * For the next two weeks, we will keep development and development_2.x in sync (daily) * On April 22, we will merge development_3.0 into development, and remove development_3.0 This means that after April 22: * development will contain API-breaking changes * new features will not normally be back-ported to development_2.x (unless there is a compelling reason to do so) * relevant bugfixes will be backported as normal Impact for users: * users of development should consider whether they should switch to using development_2.x * authors of PRs requiring backports may require an additional backport to development_2.x Regards Dave Rodgman

4 years, 8 months

1
0
0 0

3.0 proposal: remove MBEDTLS_CHECK_PARAMS

by Gilles Peskine

Hello, I propose to remove the MBEDTLS_CHECK_PARAMS feature from Mbed TLS 3.0. (As with everything else, it will of course remain in the 2.16 and 2.2x long-time support branches.) If you are using MBEDTLS_CHECK_PARAMS and you think it should remain, please let us know and explain why. If you are not using this feature, I personally think that you're making the right choice. But if you're curious what it is, you can read the documentation or my description in https://github.com/ARMmbed/mbedtls/issues/4313 . -- Gilles Peskine Mbed TLS developer

4 years, 8 months

1
0
0 0

Re: [mbed-tls] mbedtls_hmac_drbg_seed fails, returns MBEDTLS_ERR_ENTROPY_SOURCE_FAILED

by Gilles Peskine

Hi Jeff, It looks like you're using an old version of Mbed TLS. mbedtls_hmac_drbg_seed used to set ctx->entropy_len to entropy_len * 3 / 2, but this changed (https://github.com/ARMmbed/mbed-crypto/pull/238) to making a call to mbedtls_entropy_func for entropy_len and then one again for entropy_len / 2, precisely to avoid the scenario you're describing where the HMAC_DRBG module would request more entropy than the entropy can deliver in a single call. Please upgrade to the latest release of Mbed TLS, or the latest 2.16 release if you want a long-time support branch. The version you're using is old and has known vulnerabilities. -- Gilles Peskine Mbed TLS developer On 06/04/2021 13:59, Thompson, Jeff via mbed-tls wrote: > > ï¿½ > > The call flow is mbedtls_hmac_drbg -> mbedtls_hmac_drbg_reseed -> > mbedtls_entropy_func where the parameter, len, is 48 and > MBEDTLS_ENTROPY_BLOCK_SIZE is 32. I see that mbedtls_hmac_drbg_seed > sets ï¿½ctx->entropy_len = entropy_len * 3 / 2, which explains the size > difference. Iï¿½ve probably mis-configured (see attached) in order to > use TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA, because other ciphers take too > long. > > ï¿½ > > *Jeff Thompson*ï¿½| ï¿½Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com <www.invue.com> > > ï¿½ > >

4 years, 8 months

1
0
0 0

mbedtls_hmac_drbg_seed fails, returns MBEDTLS_ERR_ENTROPY_SOURCE_FAILED

by Thompson, Jeff

The call flow is mbedtls_hmac_drbg -> mbedtls_hmac_drbg_reseed -> mbedtls_entropy_func where the parameter, len, is 48 and MBEDTLS_ENTROPY_BLOCK_SIZE is 32. I see that mbedtls_hmac_drbg_seed sets ctx->entropy_len = entropy_len * 3 / 2, which explains the size difference. I've probably mis-configured (see attached) in order to use TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA, because other ciphers take too long. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D72ABA.56C4A310]

4 years, 8 months

1
0
0 0

Re: [mbed-tls] Mbed TLS mbedtls_ssl_config (struct) Question

by Manuel Pegourie-Gonnard

Hi Keith, Those are good questions, and the short answer is everything should work in a multi-threaded environment if Mbed TLS was built with threading support (for example, enabling MBEDTLS_THREADING_C and MBEDTLS_THREADING_PTHREAD in config.h). Now for some more details: regarding mbedtls_ssl_config, it is indeed treated as read-only by all function in the SSL/TLS module, except of course those functions that are explicitly meant to modify it (those whose name starts with mbedtls_ssl_conf_). So, if you set it up in the main thread and then use it in other threads, everything will be fine regarding the top-level structure itself (for sub-structures see below), regardless of whether threading support is enabled. For the DRBG contexts, you're right that each time we draw from them, they need to update their state. However, this is protected by a mutex if threading support was enabled at compile-time. A similar thing goes for private keys : RSA private keys are protected by a mutex if threading support is enabled (using them mutates state used for side-channel countermeasures), and ECDSA private keys are safe too. X.509 structures are always treated as read-only. Regarding documentation: we did recently expand the documentation on DRBGs: https://github.com/ARMmbed/mbedtls/commit/f305d92480c81c6eb02934a4e1af58152… Regarding SSL, I agree this should be better documented. If you'd like to open a PR to add documentation that would have answered your question, that would be very welcome. Regards, Manuel ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Keith Cancel via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 02 April 2021 06:43 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Mbed TLS mbedtls_ssl_config (struct) Question Hello, I hope this a simple question regarding mbedtls_ssl_config. So it seems this structure is meant to be shared/used for multiple connections. However, if I have multiple threads is it treated as a read only structure by all the library code, or does it update some state at times? Similar thing regarding the mbedtls_x509_crt struct and mbedtls_ctr_drbg_context which also seem to be added to the config when I setup the config. I was hoping that once set I don’t have to worry about any mutexs/locks being used by the library under the hood. Mainly, that once the configuration is set in the main thread it state is never updated again. What made me curious about this is the fact the RNG seems to be part of the configuration and a CPRNG will generally have state that needs to change. Moreover, I can’t really find a clear answer looking at the docs. Thanks, Keith Cancel -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 8 months

1
0
0 0

Mbed TLS mbedtls_ssl_config (struct) Question

by Keith Cancel

Hello, I hope this a simple question regarding mbedtls_ssl_config. So it seems this structure is meant to be shared/used for multiple connections. However, if I have multiple threads is it treated as a read only structure by all the library code, or does it update some state at times? Similar thing regarding the mbedtls_x509_crt struct and mbedtls_ctr_drbg_context which also seem to be added to the config when I setup the config. I was hoping that once set I don’t have to worry about any mutexs/locks being used by the library under the hood. Mainly, that once the configuration is set in the main thread it state is never updated again. What made me curious about this is the fact the RNG seems to be part of the configuration and a CPRNG will generally have state that needs to change. Moreover, I can’t really find a clear answer looking at the docs. Thanks, Keith Cancel

4 years, 8 months

1
0
0 0

MbedTLS handshark faild "The certificate is not correctly signed bythe trusted CA"

by chen

Hello, I run a client that has been ported MbedTLS, but the client connect server faild. I check the debug log, the end client state is 15. In the client state 3, the client receive only one certificate from server, and the log printing "Certificate verification flags 8". Here are part of logs: ..\MbedTLS\library\ssl_tls.c:4232: dumping 'input record from network' (4467 bytes) ..\MbedTLS\library\ssl_tls.c:4232: 0000: 16 03 03 11 6e 0b 00 11 6a 00 11 67 00 05 c2 30 ....n...j..g...0 ..\MbedTLS\library\ssl_tls.c:4232: 0010: -------- omit some network input data -------- ..\MbedTLS\library\ssl_tls.c:4232: 0ff0: 38 a0 36 a0 34 86 32 68 74 74 70 3a 2f 2f 63 72 8.6.4.2http://cr ..\MbedTLS\library\ssl_tls.c:3624: handshake message: msglen = 4462, type = 11, hslen = 4462 ..\MbedTLS\library\ssl_tls.c:4385: <= read record ..\MbedTLS\library\ssl_tls.c:5606: peer certificate #1: ..\MbedTLS\library\ssl_tls.c:5606: cert. version : 3 ..\MbedTLS\library\ssl_tls.c:5606: serial number : F0:57:5F:65:80:A9:70:B4:F9:8E:42:91:AE:D0:70:27 ..\MbedTLS\library\ssl_tls.c:5606: issuer name : C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA ..\MbedTLS\library\ssl_tls.c:5606: subject name : CN=*.xxxxxxxx.com ..\MbedTLS\library\ssl_tls.c:5606: issued on : 2020-06-01 00:00:00 ..\MbedTLS\library\ssl_tls.c:5606: expires on : 2021-05-26 23:59:59 ..\MbedTLS\library\ssl_tls.c:5606: signed using : RSA with SHA-256 ..\MbedTLS\library\ssl_tls.c:5606: RSA key size : 2048 bits ..\MbedTLS\library\ssl_tls.c:5606: basic constraints : CA=false ..\MbedTLS\library\ssl_tls.c:5606: subject alt name : *.xxxxxxxx.com, xxxxxxxx.com ..\MbedTLS\library\ssl_tls.c:5606: key usage : Digital Signature, Key Encipherment ..\MbedTLS\library\ssl_tls.c:5606: ext key usage : TLS Web Server Authentication, TLS Web Client Authentication ..\MbedTLS\library\ssl_tls.c:5606: value of 'crt->rsa.N' (2048 bits) is: ..\MbedTLS\library\ssl_tls.c:5606: af b7 73 1a f9 8a 2d 5e a2 e8 0f fd 89 5d 60 1d ..\MbedTLS\library\ssl_tls.c:5606: -------- omit some bits -------- ..\MbedTLS\library\ssl_tls.c:5606: e6 8e f8 3e ed ec 8e dd ec 46 48 85 9a b4 c8 71 ..\MbedTLS\library\ssl_tls.c:5606: value of 'crt->rsa.E' (17 bits) is: ..\MbedTLS\library\ssl_tls.c:5606: 01 00 01 ..\MbedTLS\library\ssl_tls.c:5757: x509_verify_cert() returned -9984 (-0x2700) ..\MbedTLS\library\ssl_tls.c:5851: ! Certificate verification flags 8 ..\MbedTLS\library\ssl_tls.c:5863: <= parse certificate At the client side, I download certificate of server, and get CA and root CA base on this certificate. Loading any one of these certificates into the client can't connect server. I did a test with another server. The different of the handshark is that the server issued two certificates, one is server's cert and another is CA cert. Loading CA or root CA into the client both can connect server successfully. problems: 1. Must the server send CA certificate in handshake phase? 2. The client holds CA certificate, dose MbedTLS client support downloading CA base on server's certificate? 3. In the source code, the certificate chain only contains the certificate issued by the server during handshake, not the CA certificate downloaded by the client according to the server certificate? Thank you very much for the answers. Best regards, berry chen

4 years, 8 months

1
0
0 0

Re: [mbed-tls] C/assembly option

by Gilles Peskine

Hi Raoul, Do I understand correctly that the problem with Mbed TLS as it is now is that you need MBEDTLS_HAVE_ASM enabled for AESNI and disabled for bignum? Would you want even more granularity? In principle, we could create a new compile-time option MBEDTLS_MPI_ASM, defaulting to what it does now (enabled if MBEDTLS_HAVE_ASM if the platform is one of the known ones) but overridable in either direction. However I don't like it much because we're trying to cut down on compilation options to reduce the maintenance burden: each compilation option adds complexity which makes it harder to understand all interactions between different parts of the library, and adds some testing burden. Symmetric and asymmetric crypto are mostly decoupled, so this one wouldn't be too bad, but it all adds up. In the long term, I expect that the different cryptographic algorithms will become more decoupled, with a possibility to treat each one as a black box that could be implemented by a hardware driver, and with a uniform mechanism to select drivers (or maybe they should be called engines). The evolution of the crypto part of the library to PSA is going in this direction. But we aren't there yet. Sorry that I don't have a more satisfying answer here. -- Gilles Peskine Mbed TLS developer On 31/03/2021 09:13, Raoul Strackx via mbed-tls wrote: > Hi all, > > We have a product that requires very strong security measures. When > compiling the mbedtls library, we face the following issue: Compiling C > code with LVI-mitigations is often much faster than relying on automatic > LVI mitigations on assembly code. The MPI functions are a good example > where we wish to rely on C source code. For other functions, we need to > rely on assembly code in order to mitigate other vulnerabilities (e.g., > we require AESNI assembly instructions over C implementations of AES). > Currently there isn't an option to choose between C/assembly per function. > > What would be an acceptable solution for this? > > greetings, > > Raoul > > >

4 years, 8 months

1
0
0 0

Minimum development environment: 2021 edition

by Gilles Peskine

Hello, In a nutshell: 1. Must Mbed TLS support Python 3.4 to configure and test, or can 3.6 be enough? 2. Must the supplied CMake scripts support 2.8.12.2, or can 3.5.2 be enough? This thread is about minimum tool versions to configure, build and test Mbed TLS (excluding TLS interoperability testing and some maintainer scripts) on Linux and similar (Unix-like) platforms. (This is not about the set of platforms where Mbed TLS will _run_, which is as close to “anything with CHAR_BIT==8 and sizeof(size_t) >= 4” as we can make it.) Our general guideline is that Mbed TLS should build out of the box on supported versions of major desktop and server operating systems. In practice, this has tended to mean supporting tool versions from RHEL/CentOS, SLES and Ubuntu LTS releases (but not necessarily extended security maintenance releases). Last year (https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/thread.html) we concluded that we should support the following minimum versions, which will remain supported in the Mbed TLS 2.16 long-time support (LTS) branch: clang 3.8 cmake 2.8.12.2 gcc 4.4 make 3.81 python 3.4 (in 2.16: only to build the unit tests, not to configure) Since then, RHEL 6 and Ubuntu 16.04 have reached their end of life, the CentOS world has changed considerably. Looking at maintained platforms after April 2021 (https://github.com/ARMmbed/mbedtls/issues/2896#issuecomment-603471273), our current goal for the upcoming Mbed TLS 2.x LTS (last release before 3.0) is: clang 6.0 cmake 2.8.12.2 (or 3.5.2? or 3.10.2?) gcc 4.8 make 3.82 python 3.6 (or 3.4.10?) Regarding Python: is there any demand for supporting Python versions older than 3.6? Python 3 is required to fine-tune the library configuration (it is not needed if you use the default config.h or a handwritten one) and build the unit tests. Regarding CMake: it is increasingly problematic for us to support CMake 2.8.12, which is only required for RHEL 7: other distributions under consideration have at least CMake 3.5. There is an ongoing effort to improve our CMake scripts to make it easier to integrate Mbed TLS into a larger project, but it is difficult to preserve backward compatibility with 2.8.12. Would it be acceptable to require CMake >= 3.5? CMake >= 3.10.2? If you have any constraints that are not captured here or if you have an opinion regarding Python and CMake versions, please let us know quickly. -- Gilles Peskine Mbed TLS developer

4 years, 8 months

1
0
0 0

C/assembly option

by Raoul Strackx

Hi all, We have a product that requires very strong security measures. When compiling the mbedtls library, we face the following issue: Compiling C code with LVI-mitigations is often much faster than relying on automatic LVI mitigations on assembly code. The MPI functions are a good example where we wish to rely on C source code. For other functions, we need to rely on assembly code in order to mitigate other vulnerabilities (e.g., we require AESNI assembly instructions over C implementations of AES). Currently there isn't an option to choose between C/assembly per function. What would be an acceptable solution for this? greetings, Raoul

4 years, 8 months

1
0
0 0

Mbed TLS releases: 2.26.0, 2.16.10 and 2.7.19

by Dave Rodgman

Hi Mbed TLS users, We have released Mbed TLS versions 2.7.19, 2.16.10 and 2.26.0. 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/mbedtls-2.26.0, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.10, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.7.19). We recommend all users to consider whether they are impacted, and to upgrade appropriately. Please note that there will be no further releases on the 2.7 branch, as this is now out of the three year support period. Dave Rodgman

4 years, 9 months

1
0
0 0

OCSP

by Giuseppe Modugno

Is there any support for OCSP stapling in mbedTLS? Is there any roadmap for implementing it?

4 years, 9 months

1
0
0 0

Re: [mbed-tls] Use PKCS#11 and mbed TLS

by Gilles Peskine

Also, if you're looking for a hardware platform with PSA Crypto drivers, Silicon Labs has one available. They've been participating in Mbed TLS development recently and a large part of the driver support code added in the past few months comes from them. You can see the documentation of their development kit at https://docs.silabs.com/mbed-tls/latest/ . (If you want to know about getting sample hardware and driver code … I'm not the right person to ask.) -- Gilles Peskine On 24/02/2021 22:26, Gilles Peskine via mbed-tls wrote: > Hi Frank, > > I'm not sure what you're looking for. Do you mean open source projects > like Curl and Hiawatha that can use Mbed TLS as a cryptography provider? > Those are generally using the classic API, and so can't make generic use > of secure elements. I am aware of private projects using the limited > features available today (for example, TLS servers can use async private > key operations to put the key in an HSM — see > https://tls.mbed.org/kb/how-to/ssl_async). > > I've used SoftHSM in the past as a way to test portable PKCS#11 client > code without hardware. It did the job well. I can't speak for the > quality of its cryptography since I was only using it for testing. > > If you're looking for a generic interface between applications and > secure elements, then I would recommend PSA crypto over PKCS#11. We did > try to make PSA Crypto a better PKCS#11. Obviously I'm biased :) But of > course PKCS#11 is old and venerable, whereas PSA is new and the support > for hardware secure elements is still a work in progress. >

4 years, 9 months

1
0
0 0

Re: [mbed-tls] Use PKCS#11 and mbed TLS

by Gilles Peskine

Hi Frank, I'm not sure what you're looking for. Do you mean open source projects like Curl and Hiawatha that can use Mbed TLS as a cryptography provider? Those are generally using the classic API, and so can't make generic use of secure elements. I am aware of private projects using the limited features available today (for example, TLS servers can use async private key operations to put the key in an HSM — see https://tls.mbed.org/kb/how-to/ssl_async). I've used SoftHSM in the past as a way to test portable PKCS#11 client code without hardware. It did the job well. I can't speak for the quality of its cryptography since I was only using it for testing. If you're looking for a generic interface between applications and secure elements, then I would recommend PSA crypto over PKCS#11. We did try to make PSA Crypto a better PKCS#11. Obviously I'm biased :) But of course PKCS#11 is old and venerable, whereas PSA is new and the support for hardware secure elements is still a work in progress. -- Gilles Peskine Mbed TLS developer and PSA Crypto architect On 21/02/2021 17:11, Frank Bergmann via mbed-tls wrote: > Hi Gilles, > > thank you for your detailled answer. > Honestly I was in fear that your answer would look like this. ;-) > > Do you maybe know of any plans of any software project to use mbed TLS > together with a secure element? > > I asked SoftHSM because it looks much promising for our goals but they > answered that they don't have any plans to use different ssl libs. > > > cheers, > Frank > > > On 08.02.21 23:07, Gilles Peskine via mbed-tls wrote: >> Hi Frank, >> >> Support for HSM keys in Mbed TLS is a work in progress. The way it will >> work eventually is by plugging an HSM driver under the PSA crypto API, >> which supports both transparent and opaque keys. >> >> The TLS code can already use the PSA crypto API for some things, >> including client signature. Enable MBEDTLS_USE_PSA_CRYPTO, call >> mbedtls_pk_setup_opaque() to create a PK object for the key, and declare >> the key to the TLS code with mbedtls_ssl_conf_own_cert() as usual. >> >> To create the key, you will need to write a PKCS#11 secure element >> driver. ("Secure element" = "HSM" for this purpose.) I think it would >> make sense to have one in Mbed TLS, but I don't know when we might get >> around to writing one. >> >> There are two secure element driver interfaces in Mbed TLS right now: >> MBEDTLS_PSA_CRYPTO_SE_C (dynamic secure element interface) and >> MBEDTLS_PSA_CRYPTO_DRIVERS (unified driver interface). Both are still >> experimental: we can't guarantee API stability at this stage. >> MBEDTLS_PSA_CRYPTO_SE_C was the first proposal, and its development is >> currently frozen and may be abandonned, so I don't recommend investing >> any effort in it at the moment, but if you need something fast (e.g. for >> a demo/proof-of-concept), it's your best bet. MBEDTLS_PSA_CRYPTO_DRIVERS >> is the way of the future, but it's an active work in progress. >> >> If you're creating the key from your application, just call >> psa_generate_key. If the key was provisioned externally, it's >> unfortunately not so easy. With MBEDTLS_PSA_CRYPTO_SE_C, you can >> register a key that's already present in the secure element with >> mbedtls_psa_register_se_key(). The corresponding facility in the >> MBEDTLS_PSA_CRYPTO_DRIVERS interface is a "get_builtin_key" entry point, >> but this is not implemented yet. (There's a prototype at >> https://github.com/ARMmbed/mbedtls/pull/3822 but nobody is working on >> it. The specification is in docs/proposed/psa-driver-interface.md.) >> >> There's an example application with a MBEDTLS_PSA_CRYPTO_SE_C driver at >> https://github.com/ARMmbed/mbed-os-example-atecc608a . We don't have >> example code for MBEDTLS_PSA_CRYPTO_DRIVERS yet, or good documentation, >> or an easy-to-use build system — those are still a few months in the future. >> >> If you write a driver in the next few months, I recommend that you stay >> in touch with the Mbed TLS development team and follow the development >> branch of Mbed TLS closely, since it's a very active area of development >> at the moment. >>

4 years, 9 months

1
0
0 0

Re: [mbed-tls] PR-4161-merge TLS Testing — Failures: ABI-API-checking

by Janos Follath

Hi Gábor, Yes, it is ready for review, I have added the corresponding labels. Now there is nothing else to do just to wait for the reviews. Best regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Tuesday, 23 February 2021 at 06:29 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] PR-4161-merge TLS Testing — Failures: ABI-API-checking Hello Guys! AFter a week of debugging yesterday I was able to solve the issues on my PR, but the ABI-API failure is still on. I was told that based on my changes it is OK, I should not worry. Does this mean that my PR is ready for review or it should have disappeared by now? In the second case could someone provide me the jenkins reports and some idea where should I start searching? This is my PR: https://github.com/ARMmbed/mbedtls/pull/4161 Thank you in advance! BR, Gábor

4 years, 9 months

1
0
0 0

PR-4161-merge TLS Testing — Failures: ABI-API-checking

by Gábor Tóth

Hello Guys! AFter a week of debugging yesterday I was able to solve the issues on my PR, but the ABI-API failure is still on. I was told that based on my changes it is OK, I should not worry. Does this mean that my PR is ready for review or it should have disappeared by now? In the second case could someone provide me the jenkins reports and some idea where should I start searching? This is my PR: https://github.com/ARMmbed/mbedtls/pull/4161 Thank you in advance! BR, Gábor

4 years, 9 months

1
0
0 0

Re: [mbed-tls] Failing signoff (DCO) on: https://github.com/ARMmbed/mbedtls/pull/4140

by Gábor Tóth

Helló János! Yes I tried that one (and plenty of other stuff). Finally I just reset the branch and recommited the changes solving this particular issue. Unfortunately I had to create a new PR, because git did not let me reopen it, but that is another topic. Thank you for the help! BR, Gábor Janos Follath <Janos.Follath(a)arm.com> ezt írta (időpont: 2021. febr. 22., H, 13:17): > Hi Gábor, > > > > Have you tried running `git commit --amend` (without --no-edit --signoff) > and adding the “Signed-off-by: toth92g <toth92g(a)gmail.com>" line by hand? > > > > Best regards, > > Janos > > > > *From: *Gábor Tóth <toth92g(a)gmail.com> > *Date: *Monday, 22 February 2021 at 11:44 > *To: *Janos Follath <Janos.Follath(a)arm.com> > *Subject: *Re: [mbed-tls] Failing signoff (DCO) on: > https://github.com/ARMmbed/mbedtls/pull/4140 > > Helló János! > > > > Yes, I know which one, but I do not know how to change the commit message > in git. I have used the provided commands (amend), but it did not correct > the error. > > > > Do you know how to change it manually? > > > > BR, > > Gábor > > > > Janos Follath <Janos.Follath(a)arm.com> ezt írta (időpont: 2021. febr. 22., > H, 12:38): > > Hi Gábor, > > > > If you click on the “details” link on the DCO check it will tell you which > commits are missing the sign-off: > > https://github.com/ARMmbed/mbedtls/pull/4140/checks?check_run_id=1950600200 > > > > In this case you have one commit that is not signed off: > > > https://github.com/ARMmbed/mbedtls/pull/4140/commits/fdd3c65ee47ab80f69cfa4… > > > > Best regards, > > Janos > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf > of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Date: *Monday, 22 February 2021 at 11:05 > *To: *mbed-tls(a)lists.trustedfirmware.org < > mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Failing signoff (DCO) on: > https://github.com/ARMmbed/mbedtls/pull/4140 > > Hello Guys! > > > > I know it is a newbie question, but I am not able to pass this freaking > DCO test...I have used the provided commands to signoff all the commits and > as I see all of them has signoff, but it still failes on one. Do you have > any idea what's wrong or how could I correct it? > > > > Till now I was able to correct it, but now it seems to be bugged. > > > > Thank you! > > > > BR? > Gábor > > 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. >

4 years, 9 months

1
0
0 0

Re: [mbed-tls] Failing signoff (DCO) on: https://github.com/ARMmbed/mbedtls/pull/4140

by Janos Follath

Hi Gábor, If you click on the “details” link on the DCO check it will tell you which commits are missing the sign-off: https://github.com/ARMmbed/mbedtls/pull/4140/checks?check_run_id=1950600200 In this case you have one commit that is not signed off: https://github.com/ARMmbed/mbedtls/pull/4140/commits/fdd3c65ee47ab80f69cfa4… Best regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Monday, 22 February 2021 at 11:05 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Failing signoff (DCO) on: https://github.com/ARMmbed/mbedtls/pull/4140 Hello Guys! I know it is a newbie question, but I am not able to pass this freaking DCO test...I have used the provided commands to signoff all the commits and as I see all of them has signoff, but it still failes on one. Do you have any idea what's wrong or how could I correct it? Till now I was able to correct it, but now it seems to be bugged. Thank you! BR? Gábor

4 years, 9 months

1
0
0 0

Failing signoff (DCO) on: https://github.com/ARMmbed/mbedtls/pull/4140

by Gábor Tóth

Hello Guys! I know it is a newbie question, but I am not able to pass this freaking DCO test...I have used the provided commands to signoff all the commits and as I see all of them has signoff, but it still failes on one. Do you have any idea what's wrong or how could I correct it? Till now I was able to correct it, but now it seems to be bugged. Thank you! BR? Gábor

4 years, 9 months

1
0
0 0

Re: [mbed-tls] Use PKCS#11 and mbed TLS

by Frank Bergmann

Hi Gilles, thank you for your detailled answer. Honestly I was in fear that your answer would look like this. ;-) Do you maybe know of any plans of any software project to use mbed TLS together with a secure element? I asked SoftHSM because it looks much promising for our goals but they answered that they don't have any plans to use different ssl libs. cheers, Frank On 08.02.21 23:07, Gilles Peskine via mbed-tls wrote: > Hi Frank, > > Support for HSM keys in Mbed TLS is a work in progress. The way it will > work eventually is by plugging an HSM driver under the PSA crypto API, > which supports both transparent and opaque keys. > > The TLS code can already use the PSA crypto API for some things, > including client signature. Enable MBEDTLS_USE_PSA_CRYPTO, call > mbedtls_pk_setup_opaque() to create a PK object for the key, and declare > the key to the TLS code with mbedtls_ssl_conf_own_cert() as usual. > > To create the key, you will need to write a PKCS#11 secure element > driver. ("Secure element" = "HSM" for this purpose.) I think it would > make sense to have one in Mbed TLS, but I don't know when we might get > around to writing one. > > There are two secure element driver interfaces in Mbed TLS right now: > MBEDTLS_PSA_CRYPTO_SE_C (dynamic secure element interface) and > MBEDTLS_PSA_CRYPTO_DRIVERS (unified driver interface). Both are still > experimental: we can't guarantee API stability at this stage. > MBEDTLS_PSA_CRYPTO_SE_C was the first proposal, and its development is > currently frozen and may be abandonned, so I don't recommend investing > any effort in it at the moment, but if you need something fast (e.g. for > a demo/proof-of-concept), it's your best bet. MBEDTLS_PSA_CRYPTO_DRIVERS > is the way of the future, but it's an active work in progress. > > If you're creating the key from your application, just call > psa_generate_key. If the key was provisioned externally, it's > unfortunately not so easy. With MBEDTLS_PSA_CRYPTO_SE_C, you can > register a key that's already present in the secure element with > mbedtls_psa_register_se_key(). The corresponding facility in the > MBEDTLS_PSA_CRYPTO_DRIVERS interface is a "get_builtin_key" entry point, > but this is not implemented yet. (There's a prototype at > https://github.com/ARMmbed/mbedtls/pull/3822 but nobody is working on > it. The specification is in docs/proposed/psa-driver-interface.md.) > > There's an example application with a MBEDTLS_PSA_CRYPTO_SE_C driver at > https://github.com/ARMmbed/mbed-os-example-atecc608a . We don't have > example code for MBEDTLS_PSA_CRYPTO_DRIVERS yet, or good documentation, > or an easy-to-use build system — those are still a few months in the future. > > If you write a driver in the next few months, I recommend that you stay > in touch with the Mbed TLS development team and follow the development > branch of Mbed TLS closely, since it's a very active area of development > at the moment. > -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

4 years, 9 months

1
0
0 0

Re: [mbed-tls] Failures: all_sh-ubuntu-16.04-test_memory_buffer_allocator

by Gilles Peskine

Hi Gábor, To reproduce locally, the correct invocation would be tests/scripts/all.sh test_memory_buffer_allocator Specifically, the failing tests are SSL tests. To reproduce those tests, build the right configuration and run tests/ssl-opt.sh -f 'DTLS fragmenting: proxy MTU, * renego' I've posted the relevant logs on the GitHub issue. It's unusual for the memory_buffer tests to fail when memory sanitizers are passing, so I don't know what's going on. -- Gilles Peskine Mbed TLS developer On 16/02/2021 11:13, Gábor Tóth via mbed-tls wrote: > Hello Guys! > > I have an error related to test_memory_buffer_allocator on the server > in my PR (https://github.com/ARMmbed/mbedtls/pull/4140). Tried to find > the issue locally on both the latest Ubuntu and on version 16.04 (same > as on the server), but without success. > All the tests pass if I run "make test" command (of course I changed > config.h based on the component in all.sh).. > I have also tried: > "./tests/scripts/all.sh component_test_memory_buffer_allocator", but > it does not do anything, just lists some tools. Maybe I am not using > it right... > > The memory allocation/freeing mechanism was not touched by my changes > except that in the function that frees a CRT I added a small part to > free the new dynamic field. > > Do you have any idea what's wrong with my PR, how could I solve it or > find out the cause? > > Thank you guys! > > BR, > Gábor >

4 years, 10 months

1
0
0 0

Failures: all_sh-ubuntu-16.04-test_memory_buffer_allocator

by Gábor Tóth

Hello Guys! I have an error related to test_memory_buffer_allocator on the server in my PR (https://github.com/ARMmbed/mbedtls/pull/4140). Tried to find the issue locally on both the latest Ubuntu and on version 16.04 (same as on the server), but without success. All the tests pass if I run "make test" command (of course I changed config.h based on the component in all.sh).. I have also tried: "./tests/scripts/all.sh component_test_memory_buffer_allocator", but it does not do anything, just lists some tools. Maybe I am not using it right... The memory allocation/freeing mechanism was not touched by my changes except that in the function that frees a CRT I added a small part to free the new dynamic field. Do you have any idea what's wrong with my PR, how could I solve it or find out the cause? Thank you guys! BR, Gábor

4 years, 10 months

1
0
0 0

Requesting a sample code: adding two numbers using mbedtls_mpi_add_int?

by Shariful Alam

Hello, Sorry to bother with a noob question. I am trying to understand how bignum.c works. For that, I'm trying to write a program to add two numbers. Here is what I have https://pastebin.com/mbRaE5i5, I'm not sure if this is the correct approach. I use the following to compile the code, * gcc -o mpi_example mpi_example.c bignum.c* But get the following error, /tmp/ccMo7DMW.o: In function `main': mpi_example.c:(.text+0x2d): undefined reference to `mbedtls_mpi_init' mpi_example.c:(.text+0x39): undefined reference to `mbedtls_mpi_init' mpi_example.c:(.text+0x45): undefined reference to `mbedtls_mpi_init' mpi_example.c:(.text+0x6c): undefined reference to `mbedtls_mpi_add_int' mpi_example.c:(.text+0x9a): undefined reference to `mbedtls_mpi_free' mpi_example.c:(.text+0xa6): undefined reference to `mbedtls_mpi_free' mpi_example.c:(.text+0xb2): undefined reference to `mbedtls_mpi_free' collect2: error: ld returned 1 exit status Any help what I'm doing wrong here? Or any sample code and how to compile it? Thanks, ~ Shariful

4 years, 10 months

1
0
0 0

Overring bignum, aka MBEDTLS_BIGNUM_ALT?

by Fabio Utzig

Hi, I am working on adding HW acceleration to a NXP Kinetis MCU, but the HW accelerator happens to implement many operations which are defined in bignum.c, like "mbedtls_mpi_exp_mod", "mbedtls_mpi_gcd", "mbedtls_mpi_inv_mod" and so on. The bignum clients for me would be ecp.c and ecp_curves.c (as well as ecdh and ecdsa), and while I can override some of those using _ALT macros, for bignum it seems not possible to do so, short of not defining MBEDLTS_BIGNUM_C and all associated dependency issues. Also bignum itself also has other call paths that happen to use the functions I am trying to accelerate, which are themselves called by other files. Since I am using an open-source OSS and can't just override stuff in a fork, so I would like to know if there is some technical reason for an option like "MBEDTLS_BIGNUM_ALT" not being available and if such change would be acceptable? Fabio

4 years, 10 months

1
0
0 0

Re: [mbed-tls] MBEDTLS_ENTROPY_HARDWARE_ALT, mbedtls_ctr_drbg_seed() freezes ?

by Gilles Peskine

Hi Manu, f_entropy is the argument passed to mbedtls_ctr_drbg_seed, which is mbedtls_entropy_func. This function obtains entropy from all configured sources, which depends on the library configuration. Check if it might be calling other sources (see what sources are added in mbedtls_entropy_init in library/entropy.c). I think there's a bug in your mbedtls_hardware_poll implementation. It's receiving a buffer ent_buf with room for count BYTES, but you're filling it with count WORDS. You need to pass the exact number of bytes. In practice, unless the library is configured in a weird way, count will be a multiple of 4, which can make your code a bit simpler. -- Gilles Peskine Mbed TLS developer On 17/08/2020 19:16, Manu Abraham via mbed-tls wrote: > Greetings, > > I am new to the list, please do excuse me, in case of any list > specific etiquette issues. > > Trying to use a 1.6.1 release with a Cortex M7 port, specifically a STM32H7. > > After enabling MBEDTLS_ENTROPY_HARDWARE_ALT, did implement > mbedtls_hardware_poll() > > It looks thus, and it does appear to work from a hardware perspective: > > /** > * mbedtls_hardware_poll() > * Read random data from the Hardware RNG for entropy applications > */ > int mbedtls_hardware_poll(void *arg, > unsigned char *ent_buf, > size_t count, > size_t *ent_len) > { > register uint8_t i = 0; > uint32_t rand; > > if (!LL_RNG_IsEnabled(RNG)) > LL_RNG_Enable(RNG); /* Enable Random Number Generator */ > > for (i = 0; i < count; i++) { > while (!LL_RNG_IsActiveFlag_DRDY(RNG)) { } /* Wait for DRDY > flag to be raised */ > if ((LL_RNG_IsActiveFlag_CECS(RNG)) || > (LL_RNG_IsActiveFlag_SECS(RNG))) { /* Check error, if any */ > > /* Clock or Seed Error detected. Set Error */ > printf(" (%d) %s: Clock/Seed Error!\r\n", __LINE__, __FUNCTION__); > } > rand = LL_RNG_ReadRandData32(RNG); /* Read RNG data */ > memcpy(&(ent_buf[i * 4]), &rand, 4); /* *ent_len += 4 */ > } > LL_RNG_Disable(RNG); /* Stop random numbers generation */ > *ent_len = ((i + 1) * 4); > printf(" (%d) %s: Random Words: %d Word: %04d\r\n", > __LINE__, > __FUNCTION__, > count, > rand); > > return 0; > } > > The code which causes the problem is this, in my tls_init() > > int tls_init(void) > { > int ret; > > /* inspired by https://tls.mbed.org/kb/how-to/mbedtls-tutorial */ > const char *pers = "SYS-LWH7"; > > printf(" (%d) %s: Initializing\r\n", __LINE__, __FUNCTION__); > /* initialize descriptors */ > > mbedtls_ssl_init(&ssl); > printf(" (%d) %s: SSL initialize\r\n", __LINE__, __FUNCTION__); > > mbedtls_ssl_config_init(&conf); > printf(" (%d) %s: SSL Config initialized\r\n", __LINE__, __FUNCTION__); > > mbedtls_x509_crt_init(&cacert);work > printf(" (%d) %s: x509 CRT initialized\r\n", __LINE__, __FUNCTION__); > > mbedtls_ctr_drbg_init(&ctr_drbg); > printf(" (%d) %s: DRBG initialized\r\n", __LINE__, __FUNCTION__); > > mbedtls_entropy_init(&entropy); > printf(" (%d) %s: Entropy initialized\r\n", __LINE__, __FUNCTION__); > > > ret = mbedtls_ctr_drbg_seed(&ctr_drbg, > mbedtls_entropy_func, > &entropy, > (const unsigned char *) pers, > strlen(pers)); > if (ret) { > > LWIP_DEBUGF(MQTT_APP_DEBUG_TRACE, > ("failed !\n mbedtls_ctr_drbg_seed returned %d\n", > ret)); > > printf(" (%d) %s: DRBG seed failed, ret=%d\r\n", __LINE__, > __FUNCTION__, ret); > return -1; > } > printf(" (%d) %s: DRBG seed returned:%d\r\n", __LINE__, __FUNCTION__, ret); > > /** > * The transport type determines if we are using > * TLS (MBEDTLS_SSL_TRANSPORT_STREAM) or > * DTLS (MBEDTLS_SSL_TRANSPORT_DATAGRAM). > */ > ret = mbedtls_ssl_config_defaults(&conf, > MBEDTLS_SSL_IS_CLIENT, > MBEDTLS_SSL_TRANSPORT_STREAM, > MBEDTLS_SSL_PRESET_DEFAULT); > if (ret) { > LWIP_DEBUGF(MQTT_APP_DEBUG_TRACE, > ("failed !\n mbedtls_ssl_config_defaults returned %d\n\n", > ret)); > > printf("(%d) %s: SSL config defaults failed, ret=%d\r\n", > __LINE__, __FUNCTION__, ret); > return -1; > } > printf("(%d) %s: SSL config defaults returned:%d\r\n", __LINE__, > __FUNCTION__, ret); > > ret = mbedtls_x509_crt_parse(&cacert, > (const unsigned char *)test_ca_crt, > test_ca_crt_len); > if (ret) > printf(" (%d) %s: failed!\n mbedtls_x509_crt_parse returned > %d\r\n", __LINE__, __FUNCTION__, ret); > else > printf(" (%d) %s: mbedtls_x509_crt_parse returned %d\r\n", > __LINE__, __FUNCTION__, ret); > > mbedtls_ssl_conf_ca_chain(&conf, &cacert, NULL); > mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_REQUIRED); > > /** > * The library needs to know which random engine > * to use and which debug function to use as callback. > */ > mbedtls_ssl_conf_rng(&conf, mbedtls_ctr_drbg_random, &ctr_drbg); > mbedtls_ssl_conf_dbg(&conf, my_debug, stdout); > mbedtls_ssl_setup(&ssl, &conf); > } > > > The output of which looks thus, in a serial terminal: > > (1217) print_dhcp_state: Try connect to Broker > (174) tls_init: Initializing > (178) tls_init: SSL initialize > (181) tls_init: SSL Config initialized > (184) tls_init: x509 CRT initialized > (187) tls_init: DRBG initialized > (190) tls_init: Entropy initialized > (1027) mbedtls_hardware_poll: Random Words: 128 Word: -558876895 > > > Any thoughts/ideas, what could be wrong ? > Any kind soul in here ? > > Thanks, > Manu

4 years, 10 months

1
0
0 0

Re: [mbed-tls] Failing CI tests, Generating coverage report

by Manuel Pegourie-Gonnard

Hi Gábor, Congrats on fixing the previous issues and getting Travis to pass. Unfortunately, the complete logs of the Jenkins part of the CI can only be accessed by Arm employees so far. We have plans to move to a fully-public CI system, but this won't happen before the second half of this year. In the meantime I'm afraid you'll have to ask a team member to get you the results. > continuous-integration/jenkins/pr-head — This commit cannot be built > continuous-integration/jenkins/pr-merge — This commit cannot be buil Note: this can be ignore, these are the results of the parent jobs that spawn the other jobs. > PR-4117-head TLS Testing — Failures: all_sh-ubuntu-16.04-test_m32_o1 all_sh-ubuntu-16.04-test_memory_buffer_allocator > PR-4117-merge TLS Testing — Failures: ABI-API-checking all_sh-ubuntu-16.04-test_memory_buffer_allocator Note: this is a partial list of failed components (truncated due to limits in the Github notifications API). Most of them as components of tests/scripts/all.sh - if you have access to a Linux/Unix machine with the proper dependencies, you can run them locally, for example here the first one would be tests/scripts/all.sh test_m32_o1, the second one tests/scripts/all.sh test_memory_buffer_allocator. Regarding your question about coverage: I _think_ it should work on Windows if you exclude ssl-opt.sh and compat.sh. As your work is related to X.509, excluding those SSL-related scripts should not affect coverage of the areas of interest. I'm not sure if lcov (the programs that turns gcov's raw data to human-readable form) works on Windows, I'm sure your favourite search engine will have more information than me about this 🙂 Note however that most of the development/testing tools are made with Linux in mind, so you might have an easier time running a Linux VM to use them. As a last resort, one of the reviewers of the PRs can measure coverage on their machine - that's something I often do for PRs adding features, especially when some form of parsing is involved. Thanks for paying attention to coverage, by the way, that's really appreciated! Best regards, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 11 February 2021 11:39 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Failing CI tests, Generating coverage report Hello Guys! I have a branch that has been successfully built, but 4/10 tests are failing. Unfortunately I am not even able to read a log, because if I click on the details button I am redirected to a "This site can't be reached" page. Could you help me how to check the logs regarding the Jenkins CI builds? This is the pull request https://github.com/ARMmbed/mbedtls/pull/4117 These are the failing tests: continuous-integration/jenkins/pr-head — This commit cannot be built continuous-integration/jenkins/pr-merge — This commit cannot be buil PR-4117-head TLS Testing — Failures: all_sh-ubuntu-16.04-test_m32_o1 all_sh-ubuntu-16.04-test_memory_buffer_allocator PR-4117-merge TLS Testing — Failures: ABI-API-checking all_sh-ubuntu-16.04-test_memory_buffer_allocator I am also working on tests to cover the new functionality, but can not run coverage report. In the makefile of the base directory of mbedtls I have found this part: ifndef WINDOWS # note: for coverage testing, build with: # make CFLAGS='--coverage -g3 -O0' covtest: $(MAKE) check programs/test/selftest tests/compat.sh tests/ssl-opt.sh So am I right, that coverage check is only supported ot linux platform? Do I need to use that one or are there any solutions on windows? Thank you in advance! BR, Gábor

4 years, 10 months

2
2
0 0

Failing CI tests, Generating coverage report

by Gábor Tóth

Hello Guys! I have a branch that has been successfully built, but 4/10 tests are failing. Unfortunately I am not even able to read a log, because if I click on the details button I am redirected to a "This site can't be reached" page. Could you help me how to check the logs regarding the Jenkins CI builds? This is the pull request https://github.com/ARMmbed/mbedtls/pull/4117 These are the failing tests: *continuous-integration/jenkins/pr-head *— This commit cannot be built *continuous-integration/jenkins/pr-merge *— This commit cannot be buil *PR-4117-head TLS Testing *— Failures: all_sh-ubuntu-16.04-test_m32_o1 all_sh-ubuntu-16.04-test_memory_buffer_allocator *PR-4117-merge TLS Testing *— Failures: ABI-API-checking all_sh-ubuntu-16.04-test_memory_buffer_allocator I am also working on tests to cover the new functionality, but can not run coverage report. In the makefile of the base directory of mbedtls I have found this part: ifndef WINDOWS # note: for coverage testing, build with: # make CFLAGS='--coverage -g3 -O0' covtest: $(MAKE) check programs/test/selftest tests/compat.sh tests/ssl-opt.sh So am I right, that coverage check is only supported ot linux platform? Do I need to use that one or are there any solutions on windows? Thank you in advance! BR, Gábor

4 years, 10 months

1
0
0 0

Re: [mbed-tls] X509 V3 - AuthorityKeyId extraction (pull-4117)

by Gábor Tóth

Hello Gilles! Thank you for your helpful answer! Unfortunately this solution to find memory leakage problems is not working under windows (as I read), but fortunately I was able to locate the source and now my changes are green on the server. Thank you, again :) BR, Gábor Gilles Peskine via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> ezt írta (időpont: 2021. febr. 10., Sze, 12:03): > Hi Gábor, > > Thank you for contributing to Mbed TLS! > > For the memory leaks, compile with ASan(+UBSan): > export ASAN_OPTIONS='symbolize=1' > # also export ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer if it's not > found automatically > export ASAN_FLAGS='-O2 -fsanitize=address,undefined > -fno-sanitize-recover=all' > make CFLAGS="$ASAN_FLAGS" LDFLAGS="$ASAN_FLAGS" > > The SSL test scripts depend on precise versions of OpenSSL and GnuTLS. > Versions that are too old are missing some features and recent versions > have removed some features. Even some versions from Linux distributions > have removed obsolete algorithms that we're still testing. If you want > to pass all the tests on your machine, I recommend that you install them > from source. There's a list of the versions we use on our CI at > https://developer.trustedfirmware.org/w/mbed-tls/testing/ci/ . > > When you're debugging, it's useful to run a single test case or a small > number of test cases with ssl-opt -f 'regexp' . The logs are in > tests/o-cli-<number>.log and tests/o-srv-<number>.log . > > Hope this helps. > > -- > Gilles Peskine > Mbed TLS developer > > On 10/02/2021 10:17, Gábor Tóth via mbed-tls wrote: > > Hello Guys! > > > > I am working on an update of MBEDTLS that will support AuthorityKeyId > > and SubjetKeyId V3 extensions of X509. I have created a pull request, > > but I have not been able to solve the issues on Travis: > > https://github.com/ARMmbed/mbedtls/pull/4117 > > > > As I see the problems are: memory leakage and the failure of two tests > > suites. > > I tried to run these suites and a memory leakage check on my host > > machine, but the .sh scripts are just flashing once and disappearing > > in a few seconds after catching some kind of exception. > > > > I have Python2, Perl, Mingw64 (with gcc) installed and added to the > > Path. These commands are working: > > - make CC=gcc > > - make tests > > All the 87 tests pass. > > > > Tried running ssl-opt.sh without arguments and with "-m", but it exits > > after a few lines. > > > > Do you have any idea what I am missing? It would make the work much > > easier if I could run the testsuites reproducing the error and if I > > could find the memory leaks. > > > > Thank you in advance! > > > > BR, > > Gábor > > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

4 years, 10 months

1
0
0 0

Re: [mbed-tls] X509 V3 - AuthorityKeyId extraction (pull-4117)

by Gilles Peskine

Hi Gábor, Thank you for contributing to Mbed TLS! For the memory leaks, compile with ASan(+UBSan): export ASAN_OPTIONS='symbolize=1' # also export ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer if it's not found automatically export ASAN_FLAGS='-O2 -fsanitize=address,undefined -fno-sanitize-recover=all' make CFLAGS="$ASAN_FLAGS" LDFLAGS="$ASAN_FLAGS" The SSL test scripts depend on precise versions of OpenSSL and GnuTLS. Versions that are too old are missing some features and recent versions have removed some features. Even some versions from Linux distributions have removed obsolete algorithms that we're still testing. If you want to pass all the tests on your machine, I recommend that you install them from source. There's a list of the versions we use on our CI at https://developer.trustedfirmware.org/w/mbed-tls/testing/ci/ . When you're debugging, it's useful to run a single test case or a small number of test cases with ssl-opt -f 'regexp' . The logs are in tests/o-cli-<number>.log and tests/o-srv-<number>.log . Hope this helps. -- Gilles Peskine Mbed TLS developer On 10/02/2021 10:17, Gábor Tóth via mbed-tls wrote: > Hello Guys! > > I am working on an update of MBEDTLS that will support AuthorityKeyId > and SubjetKeyId V3 extensions of X509. I have created a pull request, > but I have not been able to solve the issues on Travis: > https://github.com/ARMmbed/mbedtls/pull/4117 > > As I see the problems are: memory leakage and the failure of two tests > suites. > I tried to run these suites and a memory leakage check on my host > machine, but the .sh scripts are just flashing once and disappearing > in a few seconds after catching some kind of exception. > > I have Python2, Perl, Mingw64 (with gcc) installed and added to the > Path. These commands are working: > - make CC=gcc > - make tests > All the 87 tests pass. > > Tried running ssl-opt.sh without arguments and with "-m", but it exits > after a few lines. > > Do you have any idea what I am missing? It would make the work much > easier if I could run the testsuites reproducing the error and if I > could find the memory leaks. > > Thank you in advance! > > BR, > Gábor >

4 years, 10 months

1
0
0 0

X509 V3 - AuthorityKeyId extraction (pull-4117)

by Gábor Tóth

Hello Guys! I am working on an update of MBEDTLS that will support AuthorityKeyId and SubjetKeyId V3 extensions of X509. I have created a pull request, but I have not been able to solve the issues on Travis: https://github.com/ARMmbed/mbedtls/pull/4117 As I see the problems are: memory leakage and the failure of two tests suites. I tried to run these suites and a memory leakage check on my host machine, but the .sh scripts are just flashing once and disappearing in a few seconds after catching some kind of exception. I have Python2, Perl, Mingw64 (with gcc) installed and added to the Path. These commands are working: - make CC=gcc - make tests All the 87 tests pass. Tried running ssl-opt.sh without arguments and with "-m", but it exits after a few lines. Do you have any idea what I am missing? It would make the work much easier if I could run the testsuites reproducing the error and if I could find the memory leaks. Thank you in advance! BR, Gábor

4 years, 10 months

1
0
0 0

mbedtls_rsa_private execution time on stm32f417

by Dmitry X

Hi, im using mbedtls 2.7.17 in my project on stm32f417 (168Mhz) with config similar to config-mini-tls1_1.h for server HTTPS support (Keil). mbedtls_rsa_private is executed ~19seconds on key_exchange phase on browser connection. I’m use default embedded test RSA ca, cert and pkey. Compilation with speed optimization and without not signaficantly reduces this time. Is it normal time of caclulation or something wrong with my platform? I’m expected about 1-2s, not 19..How can i reduce execution time as an expected? Thanks. #ifndef MBEDTLS_CONFIG_H #define MBEDTLS_CONFIG_H /* System support */ #define MBEDTLS_HAVE_ASM #define MBEDTLS_HAVE_TIME /* mbed TLS feature support */ #define MBEDTLS_CIPHER_MODE_CBC #define MBEDTLS_PKCS1_V15 #define MBEDTLS_KEY_EXCHANGE_RSA_ENABLED #define MBEDTLS_SSL_PROTO_TLS1_1 /* mbed TLS modules */ #define MBEDTLS_AES_C #define MBEDTLS_ASN1_PARSE_C #define MBEDTLS_ASN1_WRITE_C #define MBEDTLS_BIGNUM_C #define MBEDTLS_CIPHER_C #define MBEDTLS_CTR_DRBG_C #define MBEDTLS_DES_C #define MBEDTLS_ENTROPY_C #define MBEDTLS_MD_C #define MBEDTLS_MD5_C //#define MBEDTLS_NET_C #define MBEDTLS_OID_C #define MBEDTLS_PK_C #define MBEDTLS_PK_PARSE_C #define MBEDTLS_RSA_C #define MBEDTLS_SHA1_C #define MBEDTLS_SHA256_C //#define MBEDTLS_SSL_CLI_C #define MBEDTLS_SSL_SRV_C #define MBEDTLS_SSL_TLS_C #define MBEDTLS_X509_CRT_PARSE_C #define MBEDTLS_X509_USE_C /* For test certificates */ #define MBEDTLS_BASE64_C #define MBEDTLS_CERTS_C #define MBEDTLS_PEM_PARSE_C /* For testing with compat.sh */ //#define MBEDTLS_FS_IO #define MBEDTLS_NO_PLATFORM_ENTROPY #include "mbedtls/check_config.h" #endif /* MBEDTLS_CONFIG_H */ -- Dmitry X

4 years, 10 months

1
0
0 0

3.0 plans: remove the RSA key mutex

by Gilles Peskine

Hello, RSA key objects include a mutex. `mbedtls_rsa_private` locks the mutex because it caches some auxiliary values used for blinding in the key object. (`mbedtls_rsa_public` also locks the mutex but it seems pointless.) This allows applications to create a key (this must be done in a single-threaded way), then use that key concurrently. This feature has a number of downsides. From a high-level architectural perspective, the RSA module is a low-level part of the code dedicated to peforming calculations; managing concurrency is outside its scope. The presence of the mutex complicates the lifecycle of RSA contexts, leading to unmet expectations (https://github.com/ARMmbed/mbedtls/issues/2621) and bugs on certain platforms (https://github.com/ARMmbed/mbedtls/pull/4104). ECC contexts do not have a mutex, even though they would need one, so a multithreaded application that works with RSA keys can't easily be changed to ECC keys. As a consequence, I propose to remove mutexes from RSA keys in Mbed TLS 3.0. Applications that currently rely on the mutex should either migrate to the PSA API or wrap an RSA object (or a pk object, which would allow algorithm agility) in a mutex. This proposal is also recorded with more details at https://github.com/ARMmbed/mbedtls/issues/4124 . -- Gilles Peskine Mbed TLS developer

4 years, 10 months

1
0
0 0

Re: [mbed-tls] Use PKCS#11 and mbed TLS

by Gilles Peskine

Hi Frank, Support for HSM keys in Mbed TLS is a work in progress. The way it will work eventually is by plugging an HSM driver under the PSA crypto API, which supports both transparent and opaque keys. The TLS code can already use the PSA crypto API for some things, including client signature. Enable MBEDTLS_USE_PSA_CRYPTO, call mbedtls_pk_setup_opaque() to create a PK object for the key, and declare the key to the TLS code with mbedtls_ssl_conf_own_cert() as usual. To create the key, you will need to write a PKCS#11 secure element driver. ("Secure element" = "HSM" for this purpose.) I think it would make sense to have one in Mbed TLS, but I don't know when we might get around to writing one. There are two secure element driver interfaces in Mbed TLS right now: MBEDTLS_PSA_CRYPTO_SE_C (dynamic secure element interface) and MBEDTLS_PSA_CRYPTO_DRIVERS (unified driver interface). Both are still experimental: we can't guarantee API stability at this stage. MBEDTLS_PSA_CRYPTO_SE_C was the first proposal, and its development is currently frozen and may be abandonned, so I don't recommend investing any effort in it at the moment, but if you need something fast (e.g. for a demo/proof-of-concept), it's your best bet. MBEDTLS_PSA_CRYPTO_DRIVERS is the way of the future, but it's an active work in progress. If you're creating the key from your application, just call psa_generate_key. If the key was provisioned externally, it's unfortunately not so easy. With MBEDTLS_PSA_CRYPTO_SE_C, you can register a key that's already present in the secure element with mbedtls_psa_register_se_key(). The corresponding facility in the MBEDTLS_PSA_CRYPTO_DRIVERS interface is a "get_builtin_key" entry point, but this is not implemented yet. (There's a prototype at https://github.com/ARMmbed/mbedtls/pull/3822 but nobody is working on it. The specification is in docs/proposed/psa-driver-interface.md.) There's an example application with a MBEDTLS_PSA_CRYPTO_SE_C driver at https://github.com/ARMmbed/mbed-os-example-atecc608a . We don't have example code for MBEDTLS_PSA_CRYPTO_DRIVERS yet, or good documentation, or an easy-to-use build system — those are still a few months in the future. If you write a driver in the next few months, I recommend that you stay in touch with the Mbed TLS development team and follow the development branch of Mbed TLS closely, since it's a very active area of development at the moment. -- Gilles Peskine Mbed TLS developer On 06/02/2021 16:59, Frank Bergmann via mbed-tls wrote: > Hi, > > I want to use PKCS#11 with mbed TLS... > > - cross platform: Windows, mobile device (e.g. Android), *nix > - on *client* side > - to create keys (for certs) and store private keys in an HSM (could also be e.g. softhsm as fallback) > > How to "integrate" PKCS#11 with mbed TLS and achieve those requirements? > > > cheers, > Frank >

4 years, 10 months

1
0
0 0

Re: [mbed-tls] DTLS Mutual authentication

by Manuel Pegourie-Gonnard

Dear Farhad, Sure, the thing you need to do is to call mbedtls_ssl_conf_authmode( conf, MBEDTLS_SSL_VERIFY_REQUIRED ) where conf is the ssl_config of the server. For more details, see that function's documentation (in ssl.h). For an example, see the command-line option auth_mode in programs/ssl/ssl_server2.c. Hope this helps! Best 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: 05 February 2021 17:34 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] DTLS Mutual authentication Dear, I would like to have mutual authentication using dtls_client.c and dtls_server.c examples. In the current version of the example, the client does not send his own certificate and the server does not verify the certificate of the client. Could you please provide me the changes that I need to make in both dtls_client.c and dtls_server.c examples? Best regards, Farhad -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 10 months

1
0
0 0

Use PKCS#11 and mbed TLS

by Frank Bergmann

Hi, I want to use PKCS#11 with mbed TLS... - cross platform: Windows, mobile device (e.g. Android), *nix - on *client* side - to create keys (for certs) and store private keys in an HSM (could also be e.g. softhsm as fallback) How to "integrate" PKCS#11 with mbed TLS and achieve those requirements? cheers, Frank

4 years, 10 months

1
0
0 0

DTLS Mutual authentication

by saghili

Dear, I would like to have mutual authentication using dtls_client.c and dtls_server.c examples. In the current version of the example, the client does not send his own certificate and the server does not verify the certificate of the client. Could you please provide me the changes that I need to make in both dtls_client.c and dtls_server.c examples? Best regards, Farhad

4 years, 10 months

1
0
0 0

Re: [mbed-tls] [Mbed-tls-announce] Mbed TLS 3.0 plans

by Dave Rodgman

Hello, We've now created the branch to allow Mbed TLS 3.0 development to begin. Mbed TLS 3.0 development will take place on development_3.0 in the short term. Mbed TLS 2.x development will continue on development. We'll regularly merge changes to development into development_3.0 so that they stay aligned. At the point of the release of Mbed TLS 2.26, we will rename development to become mbedtls-2.26 and rename development_3.0 to become development, so that the focus for new work becomes the upcoming Mbed TLS 3.0 release. Regards, Dave Rodgman On 17/12/2020, 10:04, "Mbed-tls-announce on behalf of Dave Rodgman via Mbed-tls-announce" <mbed-tls-announce-bounces(a)lists.trustedfirmware.org on behalf of Mbed-tls-announce(a)lists.trustedfirmware.org> wrote: 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 -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

4 years, 10 months

1
0
0 0

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 ***************************************

4 years, 10 months

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 >

4 years, 10 months

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 >

4 years, 10 months

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

4 years, 10 months

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

4 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls