- mbed-tls - lists.trustedfirmware.org

Could memory leak or heap fragmentation be the issue?

by Alan Chen

I posted the question on the mbedTLS forum, only to realized that mbedTLS is now maintained by the project's mailing list. Here is the copy of what I wrote: *Occasionally* I am getting MBEDTLS_ERR_SSL_ALLOC_FAILED from mbedtls_ssl_setup() during repeated HTTP partial content download. Since this problem happens very rarely, it is a bit difficult to troubleshoot. I am running mbedTLS on a Microchip PIC32MZ MCU, connected to a LTE-M/NB-IoT modem. I have 128K static memory reserved for the library with MBEDTLS_PLATFORM_MEMORY defined in the config.h file. The MCU runs two main tasks - MQTT client, talking to the AWS MQTT broker, and HTTPS client, for downloading new firmware image from the AWS S3 bucket over the air. Due to the slowness and limited bandwidth of the LTE-M and NB-IoT technologies, the HTTP file download has to use the partial content GET, basically 2KB per request, until all ~700KB of data are received. During the course of the file download, one can see as many as 30 disconnect and reconnect, and each time the TLS session would close down and re-open once the cell network is established. Here are some of my functions: ``` #define MBEDTLS_MAX_MEMORY_ALLOCATED (1024 * 128) static uint8_t tls_memory_buf[MBEDTLS_MAX_MEMORY_ALLOCATED]; // called in main() void mbedtls_mem_init(void) { mbedtls_memory_buffer_alloc_init(tls_memory_buf, sizeof tls_memory_buf); } void HTTPS_TLS_CLOSE(void) { if (server_fd_https.fd != -1) { mbedtls_entropy_free(&entropy_https); mbedtls_x509_crt_free(&cacert_https); mbedtls_ctr_drbg_free(&ctr_drbg_https); mbedtls_ssl_config_free(&conf_https); mbedtls_ssl_free(&ssl_https); server_fd_https.fd = -1; } } bool HTTPS_TLS_OPEN(void) { int ret; const char *pers = "https_tls_wrapper"; server_fd_https.fd = 1; mbedtls_debug_set_threshold(1); mbedtls_ssl_init(&ssl_https); mbedtls_ssl_config_init(&conf_https); mbedtls_ctr_drbg_init(&ctr_drbg_https); mbedtls_x509_crt_init(&cacert_https); mbedtls_entropy_init(&entropy_https); mbedtls_entropy_add_source(&entropy_https, my_https_entropy, NULL, sizeof my_https_random, MBEDTLS_ENTROPY_SOURCE_STRONG); ret = mbedtls_ctr_drbg_seed(&ctr_drbg_https, mbedtls_entropy_func, &entropy_https, (const unsigned char *)pers, strlen(pers)); if (ret != 0) { printf("%s: mbedtls_ctr_drbg_seed ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } ret = mbedtls_x509_crt_parse(&cacert_https, TRUSTED_ROOT_CA, TRUSTED_ROOT_CA_SIZE); if (ret != 0) { printf("%s: mbedtls_x509_crt_parse cacert ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } ret = mbedtls_ssl_config_defaults(&conf_https, MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT); if (ret != 0) { printf("%s: mbedtls_ssl_config_defaults ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } mbedtls_ssl_conf_verify(&conf_https, NULL, NULL); mbedtls_ssl_conf_authmode(&conf_https, MBEDTLS_SSL_VERIFY_REQUIRED); mbedtls_ssl_conf_rng(&conf_https, mbedtls_ctr_drbg_random, &ctr_drbg_https); mbedtls_ssl_conf_dbg(&conf_https, my_https_debug, stdout); mbedtls_ssl_conf_ca_chain(&conf_https, &cacert_https, NULL); mbedtls_ssl_conf_read_timeout(&conf_https, TLS_TIMEOUT_MS); HTTPS_SetHostname(); /* calling mbedtls_ssl_set_hostname */ ret = mbedtls_ssl_setup(&ssl_https, &conf_https); if (ret != 0) { printf("%s: mbedtls_ssl_setup ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } mbedtls_ssl_set_bio(&ssl_https, &server_fd_https, mbedtls_https_send, mbedtls_https_recv, NULL); return true; } ``` Can someone please tell me if I am doing something inappropriate here? I am speculating that perhaps there is a memory leak or the heap becomes so fragmented that it fails on mbedtls_calloc(). The exact error message in my case is: > ../mbedtls_lib/ssl_tls.c:5661: alloc(16717 bytes) failed Thanks. Alan Chen ________________________________ [https://secureimages.mcafee.com/common/affiliateImages/mfe/logo.png]<https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> Scanned by McAfee<https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> and confirmed virus-free.

3 years, 11 months

1
0
0 0

Re: [mbed-tls] Mbed TLS: long term support versions

by Dave Rodgman

Sorry, just realised that myself! Gilles is correct, I should have said 2.28. Thanks Dave On 29/07/2021, 14:25, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Off-by-one error! The current 2.x release is 2.27.0. Most development work is happening on 3.x but there will be at least one more 2.x release: 2.28.0. The last 2.x release will become an LTS. -- Gilles Peskine Mbed TLS developer On 29/07/2021 15:05, Dave Rodgman via mbed-tls wrote: > > Hi Matteo, > > > > We expect to release an LTS later this year. It’s likely to be 2.27, > and very likely will be supported for the usual LTS period of 3 years. > > > > So if you are considering updating to a new LTS, you could use 2.26 > for prototyping in the short term until the LTS becomes available. The > upcoming LTS will be API-compatible with 2.26. > > > > Hope this helps, > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of "matteo.cogi--- via mbed-tls" > <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *"matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> > *Date: *Tuesday, 27 July 2021 at 07:44 > *To: *"mbed-tls(a)lists.trustedfirmware.org" > <mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Mbed TLS: long term support versions > > > > Dear all, > I wish to know which are the future LTS (Long Term Support) versions > for Mbed TLS. > In these last years I have been working with the 2.16.x, but I read it > will be maintained until at least the end of 2021 ( > https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… > <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> > ), so I am considering an update to a newer LTS version. > However I don’t find which are the next LTS version and for how much > time they will be maintained. > Thanks in advance. > Regards, > Matteo > > -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

3 years, 11 months

1
0
0 0

Re: [mbed-tls] Mbed TLS: long term support versions

by Gilles Peskine

Off-by-one error! The current 2.x release is 2.27.0. Most development work is happening on 3.x but there will be at least one more 2.x release: 2.28.0. The last 2.x release will become an LTS. -- Gilles Peskine Mbed TLS developer On 29/07/2021 15:05, Dave Rodgman via mbed-tls wrote: > > Hi Matteo, > > > > We expect to release an LTS later this year. It’s likely to be 2.27, > and very likely will be supported for the usual LTS period of 3 years. > > > > So if you are considering updating to a new LTS, you could use 2.26 > for prototyping in the short term until the LTS becomes available. The > upcoming LTS will be API-compatible with 2.26. > > > > Hope this helps, > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of "matteo.cogi--- via mbed-tls" > <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *"matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> > *Date: *Tuesday, 27 July 2021 at 07:44 > *To: *"mbed-tls(a)lists.trustedfirmware.org" > <mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Mbed TLS: long term support versions > > > > Dear all, > I wish to know which are the future LTS (Long Term Support) versions > for Mbed TLS. > In these last years I have been working with the 2.16.x, but I read it > will be maintained until at least the end of 2021 ( > https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… > <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> > ), so I am considering an update to a newer LTS version. > However I don’t find which are the next LTS version and for how much > time they will be maintained. > Thanks in advance. > Regards, > Matteo > >

3 years, 11 months

1
0
0 0

Re: [mbed-tls] Mbed TLS: long term support versions

by Dave Rodgman

Hi Matteo, We expect to release an LTS later this year. It’s likely to be 2.27, and very likely will be supported for the usual LTS period of 3 years. So if you are considering updating to a new LTS, you could use 2.26 for prototyping in the short term until the LTS becomes available. The upcoming LTS will be API-compatible with 2.26. Hope this helps, Dave From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "matteo.cogi--- via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> Date: Tuesday, 27 July 2021 at 07:44 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Mbed TLS: long term support versions Dear all, I wish to know which are the future LTS (Long Term Support) versions for Mbed TLS. In these last years I have been working with the 2.16.x, but I read it will be maintained until at least the end of 2021 ( https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… ), so I am considering an update to a newer LTS version. However I don’t find which are the next LTS version and for how much time they will be maintained. Thanks in advance. Regards, Matteo

3 years, 11 months

1
0
0 0

Mbed TLS: long term support versions

by matteo.cogi＠alice.it

Dear all, I wish to know which are the future LTS (Long Term Support) versions for Mbed TLS. In these last years I have been working with the 2.16.x, but I read it will be maintained until at least the end of 2021 ( https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> ), so I am considering an update to a newer LTS version. However I don’t find which are the next LTS version and for how much time they will be maintained. Thanks in advance. Regards, Matteo

3 years, 11 months

1
0
0 0

Re: [mbed-tls] May I know why SHA224 is mandatory with SH256?

by Gilles Peskine

Hello, Mbed TLS has never supported a build with SHA-256 but not SHA-224. In Mbed TLS 2.x, enabling MBEDTLS_SHA256_C enables both SHA-256 and SHA-224. Likewise, MBEDTLS_SHA512_C enables both SHA-512 and SHA-384. The reason for this design is that SHA-256 and SHA-224 have essentially the same code but different constants, and likewise for SHA-512 and SHA-384. What changed in Mbed TLS 3.0 is that there are now separate configuration options for each of the four SHA2 variants. It is not possible yet to enable SHA-384 without SHA-512, SHA-224 without SHA-256 or SHA-256 without SHA-224. These are implementation limitations due to missing #ifdef in various places. We expect to lift these limitations in one of the next 3.x releases. Best regards, -- Gilles Peskine Mbed TLS developer On 19/07/2021 14:50, David Hu via mbed-tls wrote: > > Hi, > > ï¿½ > > It seems that SHA224 is mandatory if SHA256 is selected, in Mbed TLS > latest version, according to this new check below: > > ï¿½ > > #if defined(MBEDTLS_SHA256_C) && !defined(MBEDTLS_SHA224_C) > > #error "MBEDTLS_SHA256_C defined without MBEDTLS_SHA224_C" > > #endif > > ï¿½ > > May I know why SHA224 must be enabled with SHA256? > > Could you please point me to any reference/document? > > ï¿½ > > Best regards, > > Hu Ziji > >

3 years, 11 months

2
3
0 0

Re: [mbed-tls] How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Shariful Alam

Hi Gilles, Thank you very much, for your reply. Sorry to bother you again. I am trying to follow your instructions. I have a question regarding your suggestions. You said "applications call mbedtls_memory_buffer_alloc_init() in the startup code of the initial thread, before creating other threads. The alloc/free functions are thread-safe, but the initialization and deinitialization functions aren't." I'm a little confused here. Say, if I call mbedtls_memory_buffer_alloc_init() with a buffer in the main thread, how did all other threads use this memory (or how do all the threads know which memory block to use)? After calling mbedtls_memory_buffer_alloc_init() in the main thread, I can get the address of the buffer and pass it to the threads, do I have to call mbedtls_memory_buffer_alloc_init() again inside each thread? Thanks, Shariful On Mon, Jul 19, 2021 at 3:48 AM Gilles Peskine via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi Shariful, > > First, please note that the library called PolarSSL with functions like > rsa_private() and memory_buffer_alloc_init() has not been supported for > several years. You should upgrade to Mbed TLS, with functions like > mbedtls_rsa_private() and mbedtls_memory_buffer_alloc_init(). That being > said, the memory_buffer_alloc module works in the same way. > > Normally, applications call mbedtls_memory_buffer_alloc_init() in the > startup code of the initial thread, before creating other threads. The > alloc/free functions are thread-safe, but the initialization and > deinitialization functions aren't. If you must call > mbedtls_memory_buffer_alloc_init() after creating other threads, make > sure that no thread calls mbedtls_calloc until > mbedtls_memory_buffer_alloc_init() has returned. > > The same principle applies to other parts of Mbed TLS that are > thread-safe. For example, only the RSA operations (encryption, > decryption, signature, verification, and also the low-level functions > mbedtls_rsa_public() and mbedtls_rsa_private()) are protected. So you > must finish setting up the RSA key inside one thread before you pass a > pointer to other threads. Similarly, only mbedtls_xxx_drbg_random() is > thread-safe, and the RNG setup (including mbedtls_xxx_drgb_seed()) > should be done as part of the initial application startup. > > Finally, note that mbedtls_rsa_private() alone cannot decrypt a message: > all it does it to apply the private key operation. To decrypt a simple > message encrypted with RSA-OAEP, call mbedtls_rsa_rsaes_oaep_decrypt() > or mbedtls_rsa_pkcs1_decrypt() with a key set up for > MBEDTLS_RSA_PKCS_V21 encoding. To use the legacy PKCS#1v1.5 mechanism, > call mbedtls_rsa_rsaes_pkcs1_v15_decrypt() or > mbedtls_rsa_pkcs1_decrypt() with a key set up for .MBEDTLS_RSA_PKCS_V15. > To decrypt a message using a RSA FDH hybrid scheme, you do need to call > mbedtls_rsa_private() since Mbed TLS doesn't support it natively, but > what this gives you is the intermediate secret from which you then need > to derive a symmetric key, not the message itself. > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > On 18/07/2021 07:16, Shariful Alam via mbed-tls wrote: > > Hello, > > I have a simple example code to decrypt an encrypted message using > > *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use > > a static memory for the computation. I want to run my code > > concurrently. My code works with a single pthread. However, when I try > > to run more than one thread my program fails to decrypt. > > > > ** I check the same code without *memory_buffer_alloc_init(), *it > > works concurrently, without any issues at all. > > > > Therefore, I believe, the issue that I'm facing is coming from the use > > of static memory(e.g. *memory_buffer_alloc_init()*). The documentation > > of memorry_buffer_alloc.h shows, > > > > /** > > > > * \brief Initialize use of stack-based memory allocator. > > > > * The stack-based allocator does memory management > > inside the > > > > * presented buffer and does not call malloc() and free(). > > > > * It sets the global polarssl_malloc() and > > polarssl_free() pointers > > > > * to its own functions. > > > > * (Provided polarssl_malloc() and polarssl_free() are > > thread-safe if > > > > * POLARSSL_THREADING_C is defined) > > > > * > > > > * \note This code is not optimized and provides a > straight-forward > > > > * implementation of a stack-based memory allocator. > > > > * > > > > * \param buf buffer to use as heap > > > > * \param len size of the buffer > > > > * > > > > * \return 0 if successful > > > > */ > > > > > > So, I added the following configuration to the *config.h* file > > > > 1. #define POLARSSL_THREADING_PTHREAD > > 2. #define POLARSSL_THREADING_C > > > > But I'm still getting errors while decrypting. Any help on how to fix > > this? or what else should I add into the config.h file to > > make *memory_buffer_alloc_init() *thread-safe? Here is my sample > > code: https://pastebin.com/uyW3vknt <https://pastebin.com/uyW3vknt> > > > > Thanks, > > Shariful > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

3 years, 11 months

2
1
0 0

May I know why SHA224 is mandatory with SH256?

by David Hu

Hi, It seems that SHA224 is mandatory if SHA256 is selected, in Mbed TLS latest version, according to this new check below: #if defined(MBEDTLS_SHA256_C) && !defined(MBEDTLS_SHA224_C) #error "MBEDTLS_SHA256_C defined without MBEDTLS_SHA224_C" #endif May I know why SHA224 must be enabled with SHA256? Could you please point me to any reference/document? Best regards, Hu Ziji

3 years, 11 months

1
0
0 0

Re: [mbed-tls] How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Gilles Peskine

Hi Shariful, First, please note that the library called PolarSSL with functions like rsa_private() and memory_buffer_alloc_init() has not been supported for several years. You should upgrade to Mbed TLS, with functions like mbedtls_rsa_private() and mbedtls_memory_buffer_alloc_init(). That being said, the memory_buffer_alloc module works in the same way. Normally, applications call mbedtls_memory_buffer_alloc_init() in the startup code of the initial thread, before creating other threads. The alloc/free functions are thread-safe, but the initialization and deinitialization functions aren't. If you must call mbedtls_memory_buffer_alloc_init() after creating other threads, make sure that no thread calls mbedtls_calloc until mbedtls_memory_buffer_alloc_init() has returned. The same principle applies to other parts of Mbed TLS that are thread-safe. For example, only the RSA operations (encryption, decryption, signature, verification, and also the low-level functions mbedtls_rsa_public() and mbedtls_rsa_private()) are protected. So you must finish setting up the RSA key inside one thread before you pass a pointer to other threads. Similarly, only mbedtls_xxx_drbg_random() is thread-safe, and the RNG setup (including mbedtls_xxx_drgb_seed()) should be done as part of the initial application startup. Finally, note that mbedtls_rsa_private() alone cannot decrypt a message: all it does it to apply the private key operation. To decrypt a simple message encrypted with RSA-OAEP, call mbedtls_rsa_rsaes_oaep_decrypt() or mbedtls_rsa_pkcs1_decrypt() with a key set up for MBEDTLS_RSA_PKCS_V21 encoding. To use the legacy PKCS#1v1.5 mechanism, call mbedtls_rsa_rsaes_pkcs1_v15_decrypt() or mbedtls_rsa_pkcs1_decrypt() with a key set up for .MBEDTLS_RSA_PKCS_V15. To decrypt a message using a RSA FDH hybrid scheme, you do need to call mbedtls_rsa_private() since Mbed TLS doesn't support it natively, but what this gives you is the intermediate secret from which you then need to derive a symmetric key, not the message itself. Best regards, -- Gilles Peskine Mbed TLS developer On 18/07/2021 07:16, Shariful Alam via mbed-tls wrote: > Hello, > I have a simple example code to decrypt an encrypted message using > *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use > a static memory for the computation. I want to run my code > concurrently. My code works with a single pthread. However, when I try > to run more than one thread my program fails to decrypt. > > ** I check the same code without *memory_buffer_alloc_init(), *it > works concurrently, without any issues at all. > > Therefore, I believe, the issue that I'm facing is coming from the use > of static memory(e.g. *memory_buffer_alloc_init()*). The documentation > of memorry_buffer_alloc.h shows, > > /** > > * \brief Initialize use of stack-based memory allocator. > > * The stack-based allocator does memory management > inside the > > * presented buffer and does not call malloc() and free(). > > * It sets the global polarssl_malloc() and > polarssl_free() pointers > > * to its own functions. > > * (Provided polarssl_malloc() and polarssl_free() are > thread-safe if > > * POLARSSL_THREADING_C is defined) > > * > > * \note This code is not optimized and provides a straight-forward > > * implementation of a stack-based memory allocator. > > * > > * \param buf buffer to use as heap > > * \param len size of the buffer > > * > > * \return 0 if successful > > */ > > > So, I added the following configuration to the *config.h* file > > 1. #define POLARSSL_THREADING_PTHREAD > 2. #define POLARSSL_THREADING_C > > But I'm still getting errors while decrypting. Any help on how to fix > this? or what else should I add into the config.h file to > make *memory_buffer_alloc_init() *thread-safe? Here is my sample > code: https://pastebin.com/uyW3vknt <https://pastebin.com/uyW3vknt> > > Thanks, > Shariful >

3 years, 11 months

1
0
0 0

How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Shariful Alam

Hello, I have a simple example code to decrypt an encrypted message using *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use a static memory for the computation. I want to run my code concurrently. My code works with a single pthread. However, when I try to run more than one thread my program fails to decrypt. ** I check the same code without *memory_buffer_alloc_init(), *it works concurrently, without any issues at all. Therefore, I believe, the issue that I'm facing is coming from the use of static memory(e.g. *memory_buffer_alloc_init()*). The documentation of memorry_buffer_alloc.h shows, /** * \brief Initialize use of stack-based memory allocator. * The stack-based allocator does memory management inside the * presented buffer and does not call malloc() and free(). * It sets the global polarssl_malloc() and polarssl_free() > pointers * to its own functions. * (Provided polarssl_malloc() and polarssl_free() are thread-safe > if * POLARSSL_THREADING_C is defined) * * \note This code is not optimized and provides a straight-forward * implementation of a stack-based memory allocator. * * \param buf buffer to use as heap * \param len size of the buffer * * \return 0 if successful */ So, I added the following configuration to the *config.h* file 1. #define POLARSSL_THREADING_PTHREAD 2. #define POLARSSL_THREADING_C But I'm still getting errors while decrypting. Any help on how to fix this? or what else should I add into the config.h file to make *memory_buffer_alloc_init() *thread-safe? Here is my sample code: https://pastebin.com/uyW3vknt Thanks, Shariful

3 years, 11 months

1
1
0 0

question about sslv3 alert certificate unknown

by Ron Eggler

Hi, I'm working on a client application that will connect to an FTPS server (vsftpd) to download files. Now, I have ca-cert, cert and key files all setup to work with curl like: curl -3 -k -v --ftp-ssl --tlsv1.2 --ftp-ssl-reqd --ftp-pasv --verbose \ --ssl \ --cert ./en-cert.pem \ --cert-type PEM \ --key ./en-cert.key \ --key-type PEM \ --cacert ./ca-cert \ ftp://user:pass@10.10.100.1/test.txt -O Now, I use the same cert, key & ca-cert with mbedtls but am unable to handshake, mbedtls_ssl_handshake() keeps giving me an error, what is done in order: - init cert, ca-cert, key, entropy, drbg, ssl, config - parse ca-cert, cert & key - seed RNG - mbedtls_ctr_drbg_seed with mbedtls_hardware_poll - set config defaults MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT - mbedtls_ssl_conf_ca_chain - mbedtls_ssl_conf_rng with mbedtls_ctr_drbg_random - mbedtls_ssl_conf_dbg - mbedtls_ssl_conf_own_cert - mbedtls_ssl_setup - mbedtls_ssl_set_bio - mbedtls_ssl_handshake which up to the handshake all seems to go through without any issues. When I look at it with wireshark, I see something like: Response: 234 Proceed with negotiation. Request:looks like the certificate jumbled up Response 500 OOPS: Response :SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown Any hints on how I best go about troubleshooting this? I have confirmed that ca-cert, cert & key are identical to the ones that are used for the above curl command. Thanks,

3 years, 11 months

1
0
0 0

Re: [mbed-tls] Question about dynamic linking, versioning and API/ABI stability

by Janos Follath

Hi, Semantic versioning applies only to API compatibility but not for ABI. When we break the ABI we increase the SO version for that part of the library and this is how linux distributions normally track our ABI compatibility. Additionally, we try very hard not to break ABI at all in LTS versions. You can find a detailed description what Mbed TLS promises regarding API/ABI compatibility: https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hugues De Valon via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Wednesday, 14 July 2021 at 17:09 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Question about dynamic linking, versioning and API/ABI stability Hello, We are using Mbed Crypto in our Parsec project through the psa-crypto Rust crate (https://github.com/parallaxsecond/rust-psa-crypto). We currently have Mbed Crypto through Mbed TLS 2.25.0 which we build statically from scratch by default. We also offer the option to dynamically link with an Mbed Crypto library available on the system. Ideally, this would offer an easy and simple way to patch bug fixes without having to recompile everything. However, as we observed API (and probably ABI) breaking changes over the past versions of Mbed TLS we were wondering if this (dynamic linking) was a model we should promote at all. Is there a semantic versioning process currently applied in Mbed TLS? If we use Mbed TLS 3.0.0 in our crate, can we be sure than 3.x.y versions won’t contain any API/ABI breaking changes or is there nothing of the sort? I believe that Mbed Crypto is catching up to be fully compliant with PSA Crypto 1.0.1. Once that will be the case, will its API/ABI be stable and follow the PSA Crypto semantic versioning? It might be that the good solution is that we shouldn’t dynamically link with Mbed Crypto but always compile it from scratch as we do by default. I am just sending this email so that we follow the good approach! Kind regards, Hugues

3 years, 11 months

2
2
0 0

Question about dynamic linking, versioning and API/ABI stability

by Hugues De Valon

Hello, We are using Mbed Crypto in our Parsec project through the psa-crypto Rust crate (https://github.com/parallaxsecond/rust-psa-crypto). We currently have Mbed Crypto through Mbed TLS 2.25.0 which we build statically from scratch by default. We also offer the option to dynamically link with an Mbed Crypto library available on the system. Ideally, this would offer an easy and simple way to patch bug fixes without having to recompile everything. However, as we observed API (and probably ABI) breaking changes over the past versions of Mbed TLS we were wondering if this (dynamic linking) was a model we should promote at all. Is there a semantic versioning process currently applied in Mbed TLS? If we use Mbed TLS 3.0.0 in our crate, can we be sure than 3.x.y versions won't contain any API/ABI breaking changes or is there nothing of the sort? I believe that Mbed Crypto is catching up to be fully compliant with PSA Crypto 1.0.1. Once that will be the case, will its API/ABI be stable and follow the PSA Crypto semantic versioning? It might be that the good solution is that we shouldn't dynamically link with Mbed Crypto but always compile it from scratch as we do by default. I am just sending this email so that we follow the good approach! Kind regards, Hugues

3 years, 11 months

1
0
0 0

serial communication in FTP

by Sunil Jain

Hello, we are using the mbed-tls for secure communication for FTP. FTP server is handling the client hello serially one at a time, one communication is blocking other clients to communicate. What could be the reason and how to solve this issue. -- Thanks and Regards, Sunil Jain

3 years, 11 months

1
0
0 0

Mbed TLS: Release of Mbed TLS 3.0.0, 2.27.0, and 2.16.11

by Dave Rodgman

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.0.0, 2.27.0 and 2.16.11. These releases of Mbed TLS address several security issues, and provide bug fixes and enhancements. Mbed TLS 3.0.0 also brings many API-breaking changes. Full details, including security advisories, are available in the release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.27.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

3 years, 11 months

1
0
0 0

Mbed TLS: Release of Mbed TLS 3.0.0, 2.27.0, and 2.16.11

by Dave Rodgman

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.0.0, 2.27.0 and 2.16.11. These releases of Mbed TLS address several security issues, and provide bug fixes and enhancements. Mbed TLS 3.0.0 also brings many API-breaking changes. Full details, including security advisories, are available in the release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.27.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

3 years, 11 months

1
0
0 0

Re: [mbed-tls] mbedtls_x509_crt_parse returned -0x2180

by Danny Backx

Gilles, Thanks for getting me to try to read DER files. There must definitely be something wrong in that area. I am speficying support for PEM in the build but reading DER gets me past that error. Searching further :-) Again, thanks Danny On 05/07/2021 20:27, Gilles Peskine via mbed-tls wrote: > Hello, > > The first thing when you see an unexpected error code is to look up the > corresponding error message. Mbed TLS comes with a utility for that: > > programs/util/strerror 0x2180 > Last error was: -0x2180 - X509 - The CRT/CRL/CSR format is invalid, > e.g. different type expected > > You can also search the error code in the source code: > > grep 0x2180 include/mbedtls/*.h > include/mbedtls/x509.h:#define > MBEDTLS_ERR_X509_INVALID_FORMAT -0x2180 /**< The > CRT/CRL/CSR format is invalid, e.g. different type expected. */ > > At first glance it looks like there's only one case for which CRT > parsing return MBEDTLS_ERR_X509_INVALID_FORMAT as opposed to > (MBEDTLS_ERR_X509_INVALID_FORMAT + low_level_error_code), and that's if > the certificate doesn't parse like a DER format at the top level. A > plausible reason for that is that the certificate is in PEM format and > your build has PEM support turned off. If that's the case, convert the > certifcate to DER when you copy it to the device. You can use the Mbed > TLS utility programs/util/pem2der for that. > > Best regards, > -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

3 years, 11 months

1
0
0 0

SHA NI support in mbedtls

by Lu, Jingdong

Hi, mbedtls experts I note that there is AES NI support (aesni.c) on x86 platform. I'm wondering why there is no SHA NI support for SHA1 and SHA256? How can I get SHA NI support? Should I choose another crypto library? Thanks, Jingdong

3 years, 11 months

1
0
0 0

Re: [mbed-tls] mbedtls_x509_crt_parse returned -0x2180

by Gilles Peskine

Hello, The first thing when you see an unexpected error code is to look up the corresponding error message. Mbed TLS comes with a utility for that: programs/util/strerror 0x2180 Last error was: -0x2180 - X509 - The CRT/CRL/CSR format is invalid, e.g. different type expected You can also search the error code in the source code: grep 0x2180 include/mbedtls/*.h include/mbedtls/x509.h:#define MBEDTLS_ERR_X509_INVALID_FORMAT -0x2180 /**< The CRT/CRL/CSR format is invalid, e.g. different type expected. */ At first glance it looks like there's only one case for which CRT parsing return MBEDTLS_ERR_X509_INVALID_FORMAT as opposed to (MBEDTLS_ERR_X509_INVALID_FORMAT + low_level_error_code), and that's if the certificate doesn't parse like a DER format at the top level. A plausible reason for that is that the certificate is in PEM format and your build has PEM support turned off. If that's the case, convert the certifcate to DER when you copy it to the device. You can use the Mbed TLS utility programs/util/pem2der for that. Best regards, -- Gilles Peskine Mbed TLS developer On 05/07/2021 18:10, Danny Backx via mbed-tls wrote: > > Hi, > > I must be missing something obvious but my code (on an ESP32) fails to > accept an incoming connection. > > I tried the same certificate on an ESP32 sample, and it appears to > work there. > > Does anyone have a clue where to look next ? > > Danny > > I (16:06:51.481) esp_https_server: performing session handshake > E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180 > E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert > 0x3ffdb924, len 5750 -> ret 0x2180 > E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180 > E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context > E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations > E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed > E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed > W (16:06:51.528) httpd: httpd_accept_conn: session creation failed > W (16:06:51.538) httpd: httpd_server: error accepting new connection > > -- > Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info >

3 years, 11 months

1
0
0 0

mbedtls_x509_crt_parse returned -0x2180

by Danny Backx

Hi, I must be missing something obvious but my code (on an ESP32) fails to accept an incoming connection. I tried the same certificate on an ESP32 sample, and it appears to work there. Does anyone have a clue where to look next ? Danny I (16:06:51.481) esp_https_server: performing session handshake E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180 E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert 0x3ffdb924, len 5750 -> ret 0x2180 E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180 E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed W (16:06:51.528) httpd: httpd_accept_conn: session creation failed W (16:06:51.538) httpd: httpd_server: error accepting new connection -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

3 years, 11 months

1
0
0 0

Hardware CCM decrypt failure

by Navin Reddy

Hello everyone, I am currently evaluating SSL with a local server and an STM32 device. I'm unable to figure out why the decryption fails with CCM as the cipher suite. FYI: I am using MbedTLS *v2.14.1.* *Setup*: I'm using *x86 local server* with *STM32* device as a client. Here is what happens- 1. Software CCM implementation on the client: When I use the *software* implementation of the CCM. Handshake and decryption is *successful*. Therefore, I can stream the data from STM32 and read it on the local server. 2. Hardware CCM implementation with MBEDTLS_CCM_ALT: I have used ccm_alt.c provided from STM32Cube v1.9.0. Here, the handshake is successful. But *decrypting* the message *fails*. The errors are: ssl_decrypt_buf() returned -29056 (-0x7180) mbedtls_ssl_read_record() returned -29056 (-0x7180) Checks performed: - Same certificates are used for SW and HW implementations. - CCM self test returns '0' for both HW and SW CCM implementations. - I have reserved enough heap, no memory issues. Please find all the necessary data in the attachment provided. I have added the logs from the server and the client. I have added the certificates and the code files as well. It would be of great help if somebody could point at what might be going wrong. Thank you! Best regards, Navin

3 years, 11 months

1
0
0 0

Re: [mbed-tls] Is the a version that can use the EdDSA signature algorithm currently?

by Janos Follath

Hi Shudong, Mbed TLS currently does not provide EdDSA. The contribution by @aurel32 is a first step in this direction. The work leading up to a fully functional EdDSA implementation is tracked here: https://github.com/ARMmbed/mbedtls/projects/2#column-11150355 Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Shudong Zhang via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Wednesday, 30 June 2021 at 07:28 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Is the a version that can use the EdDSA signature algorithm currently? Hello, I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question? Thanks and kind regards, Shudong

3 years, 12 months

1
0
0 0

Is the a version that can use the EdDSA signature algorithm currently?

by Shudong Zhang

Hello, I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question? Thanks and kind regards, Shudong

3 years, 12 months

1
0
0 0

How to include alternate name in CSR

by Danny Backx

Hi, I have an ACME client library for esp32, and I try to extend it to support multiple host names. First step is to include alternate names in the CSR. After I tried the ARMmbed issues forum, I was pointed to this list. My code is in http://svn.code.sf.net/p/esp32-acme-client/code/trunk/libraries/acmeclient/… <http://svn.code.sf.net/p/esp32-acme-client/code/trunk/libraries/acmeclient/…> (see function Acme::CreateAltUrlList) , the function below is an attempt to do what I described, but doesn't work. Can anyone help ? Danny int Acme::CreateAltUrlList(mbedtls_x509write_csr req) { int l = 20; int ret; for (int i=0; alt_urls[i]; i++) { l += strlen(alt_urls[i]) + 20; } unsigned char *buf = (unsigned char *)malloc(l), *p = buf + l; int len = 0; for (int i=0; alt_urls[i]; i++) { MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_raw_buffer(&p, buf, (const unsigned char *)alt_urls[i], strlen(alt_urls[i]))); MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_len(&p, buf, strlen(alt_urls[i]))); MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_tag(&p, buf, MBEDTLS_ASN1_CONTEXT_SPECIFIC | 2)); } MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_len(&p, buf, len)); MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_tag(&p, buf, MBEDTLS_ASN1_CONSTRUCTED | MBEDTLS_ASN1_SEQUENCE)); if ((ret = mbedtls_x509write_csr_set_extension(&req, MBEDTLS_OID_SUBJECT_ALT_NAME, MBEDTLS_OID_SIZE(MBEDTLS_OID_SUBJECT_ALT_NAME), (const unsigned char *)p, len)) != 0) { char errbuf[80]; mbedtls_strerror(ret, errbuf, sizeof(errbuf)); ESP_LOGE(acme_tag, "%s: mbedtls_x509write_csr_set_extension failed %s (0x%04x)", *__FUNCTION__*, errbuf, -ret); } free(buf); ESP_LOGD(acme_tag, "%s: ret %d", *__FUNCTION*__, ret); return ret; } -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

3 years, 12 months

1
0
0 0

Re: [mbed-tls] List archive?

by Shebu Varghese Kuriakose

Hi David, Archive can be found here https://lists.trustedfirmware.org/pipermail/mbed-tls/ https://lists.trustedfirmware.org/pipermail/psa-crypto/ Regards, Shebu -----Original Message----- From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of David Higton via mbed-tls Sent: Friday, June 25, 2021 2:51 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] List archive? Hi everybody, I've just joined the list. The first thing I did was to try to find an archive of list postings, but I haven't found one. Is there one, and, if so, where do I find it? The information may have been staring me in the face; if that's the case, I apologise. David -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years

1
1
0 0

List archive?

by David Higton

Hi everybody, I've just joined the list. The first thing I did was to try to find an archive of list postings, but I haven't found one. Is there one, and, if so, where do I find it? The information may have been staring me in the face; if that's the case, I apologise. David

4 years

1
0
0 0

Re: [mbed-tls] Is TCP integrated in mbed-TLS?

by Janos Follath

Hi Anasasija, Mbed TLS is entirely agnostic of the communication channel or protocol. You can configure it to use any underlying layer, like TCP, UDP or even just a local buffer. That said, we have a module that makes it more convenient to use Mbed TLS with TCP (or UDP) on common platforms: https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/net_soc… You can see an example for using the module in several sample applications, for example: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client… and https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_server… Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of 1637062--- via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Friday, 25 June 2021 at 09:27 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Is TCP integrated in mbed-TLS? Hello, I am a Student and for my bachelor thesis I am working on a tool that is able to detect whether a server is vulnerable regarding Bleichenbacher's attack or not, testing multiple side channels. For this I am looking for a TLS implementation that has the TCP protocol integrated and generates the TCP messages. I was wondering if mbed-tls has the TCP integrated in the implementation or not. If so, I could make use of this information, too. Thanks and kind regards, Anastasija -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years

1
0
0 0

Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12

by Janos Follath

Hi Lijin, It still can be the endianness of the keys. If the key is reversed, there won’t be any discernible pattern or relationship between the derived secrets. Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of T V LIJIN (EXT) via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Friday, 25 June 2021 at 09:15 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12 Hello, We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness. Could you please confirm that the code used for ECDHE key exchange is proper? SHARED_SECRET (Computed on Client): 11 36 F7 DB 2B 14 BB 86 1C A0 FC DF 6D 4D 17 70 BE 4F D8 58 C2 11 67 10 42 D7 47 EB 14 4B 10 5E SHARED_SECRET(Computed on Sever): c6 96 d9 f0 ec 37 be 9e 1a 60 a4 5f 88 f2 13 d3 bb 98 15 3f 3b d9 81 37 c6 10 12 85 e5 8b 49 16 Thanks, LIJIN T V ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: Friday, June 25, 2021 4:52 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: mbed-tls Digest, Vol 16, Issue 12 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. ECDHE Shared Secret is computed differently (T V LIJIN (EXT)) 2. Re: ECDHE Shared Secret is computed differently (Brian D.) 3. How does the bignum.c works? (Shariful Alam) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Jun 2021 13:35:03 +0000 From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com> To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] ECDHE Shared Secret is computed differently Message-ID: <AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" Hello , We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. We have tested the same source code on Visual studio and found working. I have attached the source files Could you please comment on why the computed shared secret are different on both the ends? Thanks, LIJIN T V

4 years

1
0
0 0

Is TCP integrated in mbed-TLS?

by 1637062＠uni-wuppertal.de

Hello, I am a Student and for my bachelor thesis I am working on a tool that is able to detect whether a server is vulnerable regarding Bleichenbacher's attack or not, testing multiple side channels. For this I am looking for a TLS implementation that has the TCP protocol integrated and generates the TCP messages. I was wondering if mbed-tls has the TCP integrated in the implementation or not. If so, I could make use of this information, too. Thanks and kind regards, Anastasija

4 years

1
0
0 0

Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12

by T V LIJIN (EXT)

Hello, We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness. Could you please confirm that the code used for ECDHE key exchange is proper? SHARED_SECRET (Computed on Client): 11 36 F7 DB 2B 14 BB 86 1C A0 FC DF 6D 4D 17 70 BE 4F D8 58 C2 11 67 10 42 D7 47 EB 14 4B 10 5E SHARED_SECRET(Computed on Sever): c6 96 d9 f0 ec 37 be 9e 1a 60 a4 5f 88 f2 13 d3 bb 98 15 3f 3b d9 81 37 c6 10 12 85 e5 8b 49 16 Thanks, LIJIN T V ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: Friday, June 25, 2021 4:52 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: mbed-tls Digest, Vol 16, Issue 12 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. ECDHE Shared Secret is computed differently (T V LIJIN (EXT)) 2. Re: ECDHE Shared Secret is computed differently (Brian D.) 3. How does the bignum.c works? (Shariful Alam) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Jun 2021 13:35:03 +0000 From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com> To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] ECDHE Shared Secret is computed differently Message-ID: <AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" Hello , We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. We have tested the same source code on Visual studio and found working. I have attached the source files Could you please comment on why the computed shared secret are different on both the ends? Thanks, LIJIN T V

4 years

1
0
0 0

How does the bignum.c works?

by Shariful Alam

Hello, Can someone please briefly explain how does the bignum.c library works in terms of RSA? I understand that this is too broad a question to ask. but If someone can briefly explain the basic working mechanism it will be a great help. Thanks, Shariful

4 years

1
0
0 0

Re: [mbed-tls] ECDHE Shared Secret is computed differently

by Brian D.

Hi Linjin, I am not part of the mbed-tls staff but I developed a lot with mbed library and I had your same problem. Try to check the byte order, I had issues when computing the shared secret because I had the little endian from the other side but mbed uses big endian. Try to do a quick test and this could resolve your problem, let me know! Bye, Brian 24 giu 2021, 15:35 da mbed-tls(a)lists.trustedfirmware.org: > Hello , > We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] > Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. > We have tested the same source code on Visual studio and found working. > I have attached the source files > > Could you please comment on why the computed shared secret are different on both the ends? > > Thanks, > LIJIN T V >

4 years

1
0
0 0

ECDHE Shared Secret is computed differently

by T V LIJIN (EXT)

Hello , We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. We have tested the same source code on Visual studio and found working. I have attached the source files Could you please comment on why the computed shared secret are different on both the ends? Thanks, LIJIN T V

4 years

1
0
0 0

Re: [mbed-tls] Please help regarding [ERR ][TLSx]: mbedtls_ssl_handshake() failed: -0x7780 (-30592): SSL

by Gilles Peskine

Hi Victor, Looking through the ciphersuites your client sends, I think you've only enabled ECDHE ciphersuites, not DHE ciphersuites, which makes perfect sense, especially on an embedded device, since DH(E) is a lot slower than ECDH(E) for the same security level. So on the server you need to enable ECDHE ciphersuites. Best regards, -- Gilles Peskine Mbed TLS developer On 09/06/2021 23:03, victor Wolff via mbed-tls wrote: > > Hello > > I am relatively new to mbedTLS, but I'm trying to develop an MQTT > client running on an STM32 board connected to an ESP8266 MCU/WiFi > module. The client should publish messages to a local broker/server > where I am using Mosquitto for that purpose. > I want to test different Cipher suites but when I limiting the Server > to only accept one particle Cipher suite I receive an error from the > server point of view ï¿½1622667145: OpenSSL Error[0]: error:1417A0C1:SSL > routines:tls_post_process_client_hello:*no shared cipher*" > Which I find is strange because when I read through the debug list > presented below it says ï¿½[DBG ][TLSx]: ssl_cli.c:0884: |3| client > hello, add ciphersuite: c02cï¿½. > > ï¿½ > > I ï¿½thinkï¿½ I have enabled the "MBEDTLS_SHA256_C" in the config file > (mbed_lib.json) for the TLSsocket, and the cipher suites I have tested > so far to limit it for is: DHE-RSA-AES128-SHA |AES128-SHA | > DHE-RSA-AES128-SHA256. > > ï¿½ > > Could you please look at the debug list presented below to see if > anything looks suspicious, or if you have any ideas? > because I am truly lost and I am shooting in the dark trying to find > the answer online... > > Thank you sincerely in advance > Best regards Victor > > ï¿½ > > ï¿½ > > --------Debug list -------- > > ï¿½ > > AT< WIFI CONNECTED > > AT< WIFI GOT IP > > AT< > > AT= OK > > AT> AT+CIFSR > > AT< > > AT< AT+CIFSR > > AT< +CIFSR:APIP,"192.168.4.1" > > AT< +CIFSR:APMAC,"da:bf:c0:0d:c5:d8" > > AT= +CIFSR:STAIP,"192.168.10.103" > > AT< > > AT< +CIFSR:STAMAC,"d8:bf:c0:0d:c5:d8" > > AT< > > AT= OK > > Network interface opened successfully. > > ï¿½ > > Connecting to host 192.168.10.165:8883 ... > > Hello > > [INFO][TLSx]: Connecting to 192.168.10.165:8883 > > AT> AT+CIPSTART=0,"TCP","192.168.10.165",8883 > > AT< > > AT< AT+CIPSTART=0,"TCP","192.168.10.165",8883 > > AT< 0,CONNECT > > AT< > > AT= OK > > [INFO][TLSx]: Connected. > > [INFO][TLSx]: Starting the TLS handshake... > > [DBG ][TLSx]: ssl_tls.c:6335: |2| => handshake > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 0 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 1 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0717: |2| => write client hello > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0754: |3| client hello, max version: [3:3] > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0693: |3| client hello, current time: 14712 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0764: |3| dumping 'client hello, random bytes' > (32 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0764: |3| 0000:ï¿½ 00 00 39 78 00 7d 4e 7a c5 43 > 7f d9 5b 0c cd 3fï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ..9x.}Nz.C..[..? > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0764: |3| 0010:ï¿½ 01 a0 2f 60 8e a5 c1 54 1c 0e > 58 6a a3 da c0 7aï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ../`...T..Xj...z > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0817: |3| client hello, session id len.: 0 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0818: |3| dumping 'client hello, session id' > (0 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02c > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c030 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ad > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c024 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c028 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0af > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02b > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02f > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ac > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c023 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c027 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ae > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c038 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c037 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00a9 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a5 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00af > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a9 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00a8 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a4 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00ae > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a8 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0918: |3| client hello, got 23 ciphersuites > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0949: |3| client hello, compress len.: 1 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0950: |3| client hello, compress alg.: 0 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0071: |3| client hello, adding server name > extension: > 192.168.10ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ .165 > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0178: |3| client hello, adding > signature_algorithms extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0263: |3| client hello, adding > supported_elliptic_curves extensiï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½on > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0326: |3| client hello, adding > supported_point_formats extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0507: |3| client hello, adding > encrypt_then_mac extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0541: |3| client hello, adding > extended_master_secret extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:0575: |3| client hello, adding session ticket > extension > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1022: |3| client hello, total extension length: 73 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2701: |2| => write record > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2835: |3| output record: msgtype = 22, version > = [3:1], msglen =ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½164 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| dumping 'output record sent to > network' (169 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0000:ï¿½ 16 03 01 00 a4 01 00 00 a0 03 > 03 00 00 39 78 00ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .............9x. > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0010:ï¿½ 7d 4e 7a c5 43 7f d9 5b 0c cd > 3f 01 a0 2f 60 8eï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > }Nz.C..[..?../`. > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0020:ï¿½ a5 c1 54 1c 0e 58 6a a3 da c0 > 7a 00 00 2e c0 2cï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½..T..Xj...z...., > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0030:ï¿½ c0 30 c0 ad c0 24 c0 28 c0 af > c0 2b c0 2f c0 acï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .0...$.(...+./.. > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0040:ï¿½ c0 23 c0 27 c0 ae c0 38 c0 37 > 00 a9 c0 a5 00 afï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .#.'...8.7...... > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0050:ï¿½ c0 a9 00 a8 c0 a4 00 ae c0 a8 > 00 ff 01 00 00 49ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½...............I > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0060:ï¿½ 00 00 00 13 00 11 00 00 0e 31 > 39 32 2e 31 36 38ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .........192.168 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0070:ï¿½ 2e 31 30 2e 31 36 35 00 0d 00 > 12 00 10 06 03 06ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > .10.165......... > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0080:ï¿½ 01 05 03 05 01 04 03 04 01 03 > 03 03 01 00 0a 00ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ................ > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 0090:ï¿½ 06 00 04 00 18 00 17 00 0b 00 > 02 01 00 00 16 00ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½................ > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2840: |4| 00a0:ï¿½ 00 00 17 00 00 00 23 00 > 00ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ......#.. > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2434: |2| message length: 169, out_left: 169 > > ï¿½ > > AT> AT+CIPSEND=0,169 > > AT< > > AT< AT+CIPSEND=0,169 > > AT< > > AT< OK > > AT= > > > [DBG ][TLSx]: ssl_tls.c:2441: |2| ssl->f_send() returned 169 (-0xffffff57) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2460: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2850: |2| <= write record > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1049: |2| <= write client hello > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 2 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1410: |2| => parse server hello > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3728: |2| => read record > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 0, nb_want: 5 > > ï¿½ > > AT< > > AT< Recv 169 bytes > > AT< > > AT< SEND OK > > AT< > > AT! +IPD > > AT= ,0,7: > > AT< 0,CLOSED > > [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 0, nb_want: 5 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:6345: |2| <= handshake > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:6335: |2| => handshake > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 2 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1410: |2| => parse server hello > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3728: |2| => read record > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 0, nb_want: 5 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 0, nb_want: 5 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2391: |2| ssl->f_recv(_timeout)() returned 5 > (-0xfffffffb) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2403: |2| <= fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3479: |4| dumping 'input record header' (5 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3479: |4| 0000:ï¿½ 15 03 03 00 > 02ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½..... > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3485: |3| input record: msgtype = 21, version > = [3:3], msglen =ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 2 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 5, nb_want: 7 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 5, nb_want: 7 > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2391: |2| ssl->f_recv(_timeout)() returned 2 > (-0xfffffffe) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:2403: |2| <= fetch input > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3656: |4| dumping 'input record from network' > (7 bytes) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3656: |4| 0000:ï¿½ 15 03 03 00 02 02 > 28ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½......( > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3960: |2| got an alert message, type: [2:40] > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3968: |1| is a fatal alert message (msg 40) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:3744: |1| mbedtls_ssl_handle_message_type() > returned -30592 (-0xï¿½ï¿½ï¿½ > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½7780) > > ï¿½ > > [DBG ][TLSx]: ssl_cli.c:1416: |1| mbedtls_ssl_read_record() returned > -30592 (-0x7780) > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:6345: |2| <= handshake > > ï¿½ > > [ERR ][TLSx]: mbedtls_ssl_handshake() failed: -0x7780 (-30592): SSL > > AT> AT+CIPCLOSE=0 > > AT< AT+CIPCLOSE=0 > > AT< UNLINK > > AT< > > AT< ERROR > > AT> AT+CIPCLOSE=0 > > AT< AT+CIPCLOSE=0 > > AT< UNLINK > > AT< > > AT< ERROR > > ERROR: rc from TCP connect is -30592 > > [DBG ][TLSx]: ssl_tls.c:7055: |2| => free > > ï¿½ > > [DBG ][TLSx]: ssl_tls.c:7120: |2| <= free > > ï¿½ > > AT> AT+CWQAP > > AT< AT+CWQAP > > AT< > > AT= OK > >

4 years

1
0
0 0

Re: [mbed-tls] export keys in pkcs8. plain or encrypted

by Gilles Peskine

Hi Andrey, Thank you for your interest in Mbed TLS! In general we welcome contributions to the project. Unfortunately, our limiting factor is bandwidth for review. In 2021 the Mbed TLS team has grown, so we have more time for reviews, but we are still struggling to catch up with the large backlog. There is already an old attempt to add unencrypted PKCS#8 writing support (https://github.com/ARMmbed/mbedtls/issues/1695 <https://github.com/ARMmbed/mbedtls/issues/1695>). There is a long pending request for encrypted PKCS#8 writing support (https://github.com/ARMmbed/mbedtls/issues/1372 <https://github.com/ARMmbed/mbedtls/issues/1372>) but I'm not aware of any prior implementation. We would be glad to have your contribution, but I must be honest and say it might take us several months to get around to it. Best regards, -- Gilles Peskine Mbed TLS developer On 09/06/2021 22:46, Андрей Макаров via mbed-tls wrote: > Recently I used mbedtls library in my working project. In accordance > with the needs of the project, I added some functions to mbedtls for > saving and loading keys in plain and encrypted pem and der forms. > The changes are still raw and should be brought up to pull request > requirements - there are no tests, since the functions tested as part > of a working project which uses mbedtls. I can, over time, finalize > the changes to a pull request, but it will take some time and effort > that you don't want to waste unnecessarily — this will have to be done > at my home time. > If there is an interest for this work, then I will try to do it, but > if few people need it or do not coincide with the general direction of > development of the project, then I would not bother. > To be done: 1) added mbedtls_pk_write_key_pkcs8_der() write > non-encrypted pkcs8 der key 2) added mbedtls_pk_write_key_pkcs8_pem() > write non-encrypted pkcs8 pem key 3) added > mbedtls_pk_write_key_encrypted_pem() write legacy encryped pem file > with DEK-Info header 4) added > mbedtls_pk_write_key_pkcs8_encrypted_der() write to encrypted pkcs8 > der key; pkcs5 pbes1, pkcs12 and pbes2 schemes are supported 5) added > mbedtls_pk_write_key_pkcs8_encrypted_pem() same as above but pem key > 6) changed mbedtls_pem_read_buffer() which reads legacy encrypted pem > formats (with DEK-Info header) now it uses mbedtls_cipher_… functions > which allow to use any supported cipher rather than four enforced (was > limited to des-cbc, des-ede3-cbc, ars-128-cbc and aes-256-cbc) 7) > changed pk_parse_key_pkcs8_encrypted_der() 7.1) added pkcs5 pbes1 > support MD5-DES-CB CpbeWithMD5AndDES-CBC) and SHA1-DES-CBC > (pbeWithSHA1AndDES-CBC) 7.2) changed pkcs12 pbe (use same cipher for > all SHA1-DES2-EDE-CBC (pbeWithSHAAnd2-KeyTripleDES-CBC), > SHA1-DES3-EDE-CBC (pbeWithSHAAnd3-KeyTripleDES-CBC) and SHA1-RC4-128 > (pbeWithSHA1And128BitRC4); (the special > mbedtls_pkcs12_pbe_sha1_rc4_128() is not used now and may be removed) > 7.3) changed pkcs5 pbes2 support: added AES-128-CBC and AES-256-CBC > ciphers Some «preview» is available at fork > https://github.com/loafer-mka/mbedtls > <https://github.com/loafer-mka/mbedtls>, branch ‘dev_clean’ Of course, > many changes relate to obsolete formats, and may be undesirable … also > I do not touch PSK at all. > Please, give me some feedback — try to finish this with tests, pull > request, etc or not. ----------- Regards, Andrey >

4 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

Just finishing off this thread: The issue appeared due to an invalid pointer access else where in the application that coincided with the mbedtls_ssl_set_bio function. Working on resolution now. Thanks for all the help, pointers & hints from the list! On 2021-06-08 2:27 p.m., Ron Eggler via mbed-tls wrote: > > Yes, there's some kind of "memory magic" going on here: > > The task got terminated due to "Load from invalid memory" > > and I see: > > |Instruction at 0x6310604d is trying to load data at 0x4, which is an > invalid memory area. You are probably dereferencing a NULL pointer.| > > |and i got some trace back addresses that point to:| > > * > > mbedtls_aes_crypt_ecb > > * > > mbedtls_ctr_drbg_random_with_add > > * > > mbedtls_ssl_handshake_step > > * > > mbedtls_ssl_handshake > > > || > > On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote: >> Hi Ron, >> >> This behavior can't be explained by the library code and the code you >> posted alone. There has to be something wrong elsewhere. >> >> Check that you aren't exceeding a limitation such as the stack size or >> the size of executable and data sections. If it can be an issue on your >> platform, check that load addresses are correct and sections don't >> overlap. Make sure there's no overlap with any device memory mapping either. >> >> Make sure that the whole binary is compiled with consistent settings. >> The layout of mbedtls_ssl_context can be influenced by the Mbed TLS >> configuration, so make sure that there's a single copy of >> mbedtls/config.h and both Mbed TLS itself and your application were >> built against that copy. The layout of mbedtls_ssl_context can also be >> influenced by compiler settings on some platforms (e.g. structure >> packing options), so make sure those are consistent across your build. >> >> That's all I can think of for now. It may help to add a lot of printf >> debugging with %p on various addresses, and compare these addresses with >> what you know about memory mappings on that platform. Good luck! >> >

4 years

1
0
0 0

export keys in pkcs8. plain or encrypted

by Андрей Макаров

Recently I used mbedtls library in my working project. In accordance with the needs of the project, I added some functions to mbedtls for saving and loading keys in plain and encrypted pem and der forms. The changes are still raw and should be brought up to pull request requirements - there are no tests, since the functions tested as part of a working project which uses mbedtls. I can, over time, finalize the changes to a pull request, but it will take some time and effort that you don't want to waste unnecessarily — this will have to be done at my home time. If there is an interest for this work, then I will try to do it, but if few people need it or do not coincide with the general direction of development of the project, then I would not bother. To be done: 1) added mbedtls_pk_write_key_pkcs8_der() write non-encrypted pkcs8 der key 2) added mbedtls_pk_write_key_pkcs8_pem() write non-encrypted pkcs8 pem key 3) added mbedtls_pk_write_key_encrypted_pem() write legacy encryped pem file with DEK-Info header 4) added mbedtls_pk_write_key_pkcs8_encrypted_der() write to encrypted pkcs8 der key; pkcs5 pbes1, pkcs12 and pbes2 schemes are supported 5) added mbedtls_pk_write_key_pkcs8_encrypted_pem() same as above but pem key 6) changed mbedtls_pem_read_buffer() which reads legacy encrypted pem formats (with DEK-Info header) now it uses mbedtls_cipher_… functions which allow to use any supported cipher rather than four enforced (was limited to des-cbc, des-ede3-cbc, ars-128-cbc and aes-256-cbc) 7) changed pk_parse_key_pkcs8_encrypted_der() 7.1) added pkcs5 pbes1 support MD5-DES-CB CpbeWithMD5AndDES-CBC) and SHA1-DES-CBC (pbeWithSHA1AndDES-CBC) 7.2) changed pkcs12 pbe (use same cipher for all SHA1-DES2-EDE-CBC (pbeWithSHAAnd2-KeyTripleDES-CBC), SHA1-DES3-EDE-CBC (pbeWithSHAAnd3-KeyTripleDES-CBC) and SHA1-RC4-128 (pbeWithSHA1And128BitRC4); (the special mbedtls_pkcs12_pbe_sha1_rc4_128() is not used now and may be removed) 7.3) changed pkcs5 pbes2 support: added AES-128-CBC and AES-256-CBC ciphers Some «preview» is available at fork https://github.com/loafer-mka/mbedtls, branch ‘dev_clean’ Of course, many changes relate to obsolete formats, and may be undesirable … also I do not touch PSK at all. Please, give me some feedback — try to finish this with tests, pull request, etc or not. ----------- Regards, Andrey

4 years

1
0
0 0

session resumption and renegotiation queries

by hardik dave

Dear All, I am having multiple queries regarding session resumption and renegotiation. I understand that normally session resumption is used at every new connection and session renegotiation is used on live connection. Our domain standards recommends to use session resumption to change session key ( or keyblock key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); ) at regular intervals without closing connection and session renegotiation to change master key at regular interval using session renegotiation. This is due to the fact that the connection will be long lasting. Query 1: I understand that mbedtls currently does not support session resumption on live connection. Is there any plan to include it in the near future? ( may be similar to openssl SSL_renegotiate_abbreviated api) Query 3: If the application wants to know if session renegotiation has happened as part of mbedtls_tls_read and mbedtls_tls_write, is there any callback/API for that? --> I am only thinking of using session->start comparison in application to know if session is renegotiated. Is there any better method? Query 4: Our requirement is to understand and log security event in case failure due to certificate verification fail (revoked/expired etc..) currently we use mbedtls_ssl_get_verify_result api for same There is a case when certificate becomes expired/revoked while doing session renegotiation, mbedtls_ssl_get_verify_result api returns value 0 in above case I am thinking in case of session renegotiation, a valid session will always be available (it will not be NULL in the method below) and session renegotiation failure information will be available with session_negotiate pointer instead of session pointer in the below function. uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl ) { if( ssl->session != NULL ) return( ssl->session->verify_result ); if( ssl->session_negotiate != NULL ) return( ssl->session_negotiate->verify_result ); return( 0xFFFFFFFF ); } Am I using the right API to get certificate verify_result? should mbedtls_ssl_get_verify_result api checks give priority to session_negotiate then session? I think when there is a failure, the result will always be with session_negotiate, when success session_negotiate becomes NULL and session_negotiate pointers will be assigned to session pointers. uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl ) { if( ssl->session_negotiate != NULL ) return( ssl->session_negotiate->verify_result ); if( ssl->session != NULL ) return( ssl->session->verify_result ); return( 0xFFFFFFFF ); } Kind request to guide me Thanks in advance Regards Hardik Dave

4 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

Yes, there's some kind of "memory magic" going on here: The task got terminated due to "Load from invalid memory" and I see: |Instruction at 0x6310604d is trying to load data at 0x4, which is an invalid memory area. You are probably dereferencing a NULL pointer.| |and i got some trace back addresses that point to:| * mbedtls_aes_crypt_ecb * mbedtls_ctr_drbg_random_with_add * mbedtls_ssl_handshake_step * mbedtls_ssl_handshake || On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote: > Hi Ron, > > This behavior can't be explained by the library code and the code you > posted alone. There has to be something wrong elsewhere. > > Check that you aren't exceeding a limitation such as the stack size or > the size of executable and data sections. If it can be an issue on your > platform, check that load addresses are correct and sections don't > overlap. Make sure there's no overlap with any device memory mapping either. > > Make sure that the whole binary is compiled with consistent settings. > The layout of mbedtls_ssl_context can be influenced by the Mbed TLS > configuration, so make sure that there's a single copy of > mbedtls/config.h and both Mbed TLS itself and your application were > built against that copy. The layout of mbedtls_ssl_context can also be > influenced by compiler settings on some platforms (e.g. structure > packing options), so make sure those are consistent across your build. > > That's all I can think of for now. It may help to add a lot of printf > debugging with %p on various addresses, and compare these addresses with > what you know about memory mappings on that platform. Good luck! >

4 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Gilles Peskine

Hi Ron, This behavior can't be explained by the library code and the code you posted alone. There has to be something wrong elsewhere. Check that you aren't exceeding a limitation such as the stack size or the size of executable and data sections. If it can be an issue on your platform, check that load addresses are correct and sections don't overlap. Make sure there's no overlap with any device memory mapping either. Make sure that the whole binary is compiled with consistent settings. The layout of mbedtls_ssl_context can be influenced by the Mbed TLS configuration, so make sure that there's a single copy of mbedtls/config.h and both Mbed TLS itself and your application were built against that copy. The layout of mbedtls_ssl_context can also be influenced by compiler settings on some platforms (e.g. structure packing options), so make sure those are consistent across your build. That's all I can think of for now. It may help to add a lot of printf debugging with %p on various addresses, and compare these addresses with what you know about memory mappings on that platform. Good luck! -- Gilles Peskine Mbed TLS developer On 08/06/2021 19:16, Ron Eggler via mbed-tls wrote: > > On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote: >> On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote: >>> Hi Ron, >>> >>> The code you've shown so far only consists of setup functions that >>> populate fields in the configuration structure, then in the context >>> structure. Communication has not started yet. mbedtls_ssl_set_bio in >>> particular is a very simple setter function. >>> >>> Where does the code actually hang? Have some messages already been >>> exchanged on the network at that point? Can you get a stack trace? >>> >>> Best regards, >>> >> Hi Gilles, >> >> Thank you for the response! >> >> I've inserted print statements after each of the setup functions and >> can see that it never gets past mbedtls_ssl_set_bio. The messages >> that have been exchanged, include the complete bring up and login of >> the control channel, on the data channel, I call >> mbedtls_x509_crt_init >> mbedtls_pk_init >> mbedtls_entropy_init >> mbedtls_ctr_drbg_init >> mbedtls_ssl_init >> mbedtls_ssl_config_init >> followed by the certificate and key file got parsing, seeding of the >> RNG and that's where the previously mentioned procedure with >> mbedtls_ssl_config_defaults() starts. >> I unfortunately do not have a debugger available on that platform and >> hence getting a stack trace won't be so straight forward. Do you have >> any pointers as to what could be the issue potentially? >> >> Thank you, >> >> Ron > > Okay, I've made some further findings: > > I changed the mbedtls_ssl_set_bio funmction so that I inserted a print > statement on entry and after every set line, like so: > > void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl, > void *p_bio, > mbedtls_ssl_send_t *f_send, > mbedtls_ssl_recv_t *f_recv, > mbedtls_ssl_recv_timeout_t *f_recv_timeout ) > { > iprintf("mbedtls_ssl_set_bio::entry\n"); > ssl->p_bio = p_bio; > iprintf("mbedtls_ssl_set_bio::p_bio set\n"); > ssl->f_send = f_send; > iprintf("mbedtls_ssl_set_bio::f_send set\n"); > ssl->f_recv = f_recv; > iprintf("mbedtls_ssl_set_bio::f_recv set\n"); > ssl->f_recv_timeout = f_recv_timeout; > iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n"); > } > > and turns out, that I only see the very first print on > "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me > to the believe that my *ssl is invalid which is odd as that variable > is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is > initialized at the beginning of the function with mbedtls_ssl_init( > &ssl_d ); > >

4 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote: > On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote: >> Hi Ron, >> >> The code you've shown so far only consists of setup functions that >> populate fields in the configuration structure, then in the context >> structure. Communication has not started yet. mbedtls_ssl_set_bio in >> particular is a very simple setter function. >> >> Where does the code actually hang? Have some messages already been >> exchanged on the network at that point? Can you get a stack trace? >> >> Best regards, >> > Hi Gilles, > > Thank you for the response! > > I've inserted print statements after each of the setup functions and > can see that it never gets past mbedtls_ssl_set_bio. The messages that > have been exchanged, include the complete bring up and login of the > control channel, on the data channel, I call > mbedtls_x509_crt_init > mbedtls_pk_init > mbedtls_entropy_init > mbedtls_ctr_drbg_init > mbedtls_ssl_init > mbedtls_ssl_config_init > followed by the certificate and key file got parsing, seeding of the > RNG and that's where the previously mentioned procedure with > mbedtls_ssl_config_defaults() starts. > I unfortunately do not have a debugger available on that platform and > hence getting a stack trace won't be so straight forward. Do you have > any pointers as to what could be the issue potentially? > > Thank you, > > Ron Okay, I've made some further findings: I changed the mbedtls_ssl_set_bio funmction so that I inserted a print statement on entry and after every set line, like so: void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl, void *p_bio, mbedtls_ssl_send_t *f_send, mbedtls_ssl_recv_t *f_recv, mbedtls_ssl_recv_timeout_t *f_recv_timeout ) { iprintf("mbedtls_ssl_set_bio::entry\n"); ssl->p_bio = p_bio; iprintf("mbedtls_ssl_set_bio::p_bio set\n"); ssl->f_send = f_send; iprintf("mbedtls_ssl_set_bio::f_send set\n"); ssl->f_recv = f_recv; iprintf("mbedtls_ssl_set_bio::f_recv set\n"); ssl->f_recv_timeout = f_recv_timeout; iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n"); } and turns out, that I only see the very first print on "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me to the believe that my *ssl is invalid which is odd as that variable is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is initialized at the beginning of the function with mbedtls_ssl_init( &ssl_d );

4 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote: > Hi Ron, > > The code you've shown so far only consists of setup functions that > populate fields in the configuration structure, then in the context > structure. Communication has not started yet. mbedtls_ssl_set_bio in > particular is a very simple setter function. > > Where does the code actually hang? Have some messages already been > exchanged on the network at that point? Can you get a stack trace? > > Best regards, > Hi Gilles, Thank you for the response! I've inserted print statements after each of the setup functions and can see that it never gets past mbedtls_ssl_set_bio. The messages that have been exchanged, include the complete bring up and login of the control channel, on the data channel, I call mbedtls_x509_crt_init mbedtls_pk_init mbedtls_entropy_init mbedtls_ctr_drbg_init mbedtls_ssl_init mbedtls_ssl_config_init followed by the certificate and key file got parsing, seeding of the RNG and that's where the previously mentioned procedure with mbedtls_ssl_config_defaults() starts. I unfortunately do not have a debugger available on that platform and hence getting a stack trace won't be so straight forward. Do you have any pointers as to what could be the issue potentially? Thank you, Ron

4 years

1
0
0 0

FW: How to map PSA method to openssl method

by Gyorgy Szing

Hi, Can you please help Jun to find an answer to is question? (See below.) /George ---------- Forwarded message --------- 发件人： Jun Nie <jun.nie(a)linaro.org> Date: 2021年6月7日周一下午2:31 Subject: How to map PSA method to openssl method To: <mbed-tls(a)lists.trustedfirmware.org> Hi, I want to sign a data on PC with openssl, and verifiy it with PSA-RoT on board. Does anybody know how to map PSA method to openssl method? Such as: psa_sign_hash(key_handle, PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256), hash, hash_len, sig, sizeof(sig), sig_len); Regards, Jun

4 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Gilles Peskine

Hi Ron, The code you've shown so far only consists of setup functions that populate fields in the configuration structure, then in the context structure. Communication has not started yet. mbedtls_ssl_set_bio in particular is a very simple setter function. Where does the code actually hang? Have some messages already been exchanged on the network at that point? Can you get a stack trace? Best regards, -- Gilles Peskine Mbed TLS developer On 08/06/2021 02:30, Ron Eggler via mbed-tls wrote: > > On 2021-06-07 5:00 p.m., Ron Eggler via mbed-tls wrote: >> Hi, >> >> >> i'm in the process of wrioting an FTPS client for a system running on >> uCOS. >> >> I've been able to setup the control channel fine and working on >> setting up the data channel for a simple list command execution. >> >> It seems like I seem able to setup everything fine but the call to >> mbedtls_ssl_set_bio() hangs even though I set it to execute the >> timeout function like: >> >> mbedtls_ssl_set_bio( &ssl_d, >> &data_fd, >> mbedtls_tls_send, >> NULL, >> mbedtls_tls_recv_timeout); >> >> Where the mbed_tls_recv_timeout looks like: >> >> https://pastebin.com/Jw3iLc0x >> >> The current connection uses ipv4, i.e. the select () branch is >> active. I never see the timed out message. Any idea what may be going >> on here? >> >> Thank you, >> >> Ron >> > A bit more detail: as for what comes before the mbedtls_ssl_set_bio() > call: > > ret = mbedtls_ssl_config_defaults(&conf_d, > MBEDTLS_SSL_IS_CLIENT, > MBEDTLS_SSL_TRANSPORT_STREAM, > MBEDTLS_SSL_PRESET_DEFAULT); > > mbedtls_ssl_conf_authmode( &conf_d, MBEDTLS_SSL_VERIFY_OPTIONAL); > mbedtls_ssl_conf_ca_chain( &conf_d, &cacert_d, NULL ); > mbedtls_ssl_conf_rng(&conf_d, mbedtls_ctr_drbg_random, &ctr_drbg_d ); > mbedtls_ssl_conf_dbg(&conf_d, mydebug, stdout); > ret = mbedtls_ssl_conf_own_cert( &conf_d, &clicert_d, &pkey_d); > > ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); > > mbedtls_ssl_set_bio( &ssl_d, > &data_fd, > mbedtls_tls_send, > NULL, > mbedtls_tls_recv_timeout); >

4 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

On 2021-06-07 5:00 p.m., Ron Eggler via mbed-tls wrote: > Hi, > > > i'm in the process of wrioting an FTPS client for a system running on > uCOS. > > I've been able to setup the control channel fine and working on > setting up the data channel for a simple list command execution. > > It seems like I seem able to setup everything fine but the call to > mbedtls_ssl_set_bio() hangs even though I set it to execute the > timeout function like: > > mbedtls_ssl_set_bio( &ssl_d, > &data_fd, > mbedtls_tls_send, > NULL, > mbedtls_tls_recv_timeout); > > Where the mbed_tls_recv_timeout looks like: > > https://pastebin.com/Jw3iLc0x > > The current connection uses ipv4, i.e. the select () branch is active. > I never see the timed out message. Any idea what may be going on here? > > Thank you, > > Ron > A bit more detail: as for what comes before the mbedtls_ssl_set_bio() call: ret = mbedtls_ssl_config_defaults(&conf_d, MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT); mbedtls_ssl_conf_authmode( &conf_d, MBEDTLS_SSL_VERIFY_OPTIONAL); mbedtls_ssl_conf_ca_chain( &conf_d, &cacert_d, NULL ); mbedtls_ssl_conf_rng(&conf_d, mbedtls_ctr_drbg_random, &ctr_drbg_d ); mbedtls_ssl_conf_dbg(&conf_d, mydebug, stdout); ret = mbedtls_ssl_conf_own_cert( &conf_d, &clicert_d, &pkey_d); ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); mbedtls_ssl_set_bio( &ssl_d, &data_fd, mbedtls_tls_send, NULL, mbedtls_tls_recv_timeout);

4 years

1
0
0 0

mbedtls_ssl_set_bio hangs

by Ron Eggler

Hi, i'm in the process of wrioting an FTPS client for a system running on uCOS. I've been able to setup the control channel fine and working on setting up the data channel for a simple list command execution. It seems like I seem able to setup everything fine but the call to mbedtls_ssl_set_bio() hangs even though I set it to execute the timeout function like: mbedtls_ssl_set_bio( &ssl_d, &data_fd, mbedtls_tls_send, NULL, mbedtls_tls_recv_timeout); Where the mbed_tls_recv_timeout looks like: https://pastebin.com/Jw3iLc0x The current connection uses ipv4, i.e. the select () branch is active. I never see the timed out message. Any idea what may be going on here? Thank you, Ron

4 years

1
0
0 0

Re: [mbed-tls] Signing without explicit private key

by Gilles Peskine

Hi Stefano, The pk module has limited support for opaque RSA keys, by using the RSA_ALT functionality (https://tls.mbed.org/kb/cryptography/use-external-rsa-private-key <https://tls.mbed.org/kb/cryptography/use-external-rsa-private-key>). There's no support for opaque EC keys. For a TLS server, you can use the asynchronous callback feature to use an opaque key. See https://tls.mbed.org/kb/how-to/ssl_async <https://tls.mbed.org/kb/how-to/ssl_async> The PSA crypto API supports opaque keys. On the application side, you need to use functions like psa_asymmetric_sign instead of mbedtls_pk_sign. On the hardware side, you need to implement a secure element driver for your crypto chip. Driver support is work in progress, and documentation and tooling are still sparse. The driver specifications are in https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed <https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed> . To add driver support, you currently need to edit library/psa_crypto_driver_wrappers.c and replace calls to the test driver by calls to your real driver. Best regards, -- Gilles Peskine Mbed TLS developer and PSA Crypto architect On 03/06/2021 17:20, stefano664 via mbed-tls wrote: > Hi all, > I'm using mbedTLS libraries with an OPTIGA cryptochip. At the > moment, when I call the sign function: > > err = mbedtls_pk_sign(&priv_key, MBEDTLS_MD_SHA384, hash, 0, sign, > &olen, mbedtls_ctr_drbg_random, &ctr_drbg); > > I need to pass it a valid private key else if it isn't used, because > alternative sign routine use the one into cryptochip. > > It is possible to avoid passing this key? > > Best regards, > Stefano Mologni >

4 years

1
0
0 0

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

by Gilles Peskine

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

4 years

1
0
0 0

How to map PSA method to openssl method

by Jun Nie

Hi, I want to sign a data on PC with openssl, and verifiy it with PSA-RoT on board. Does anybody know how to map PSA method to openssl method? Such as: psa_sign_hash(key_handle, PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256), hash, hash_len, sig, sizeof(sig), sig_len); Regards, Jun

4 years

1
0
0 0

Re: [mbed-tls] NV_SEED read working and write not working

by Janos Follath

Hi Gopi, FN_NV_SEED_WR supposed to be called the first time the entropy context is used to retrieve some entropy. This is tracked by the `initial_entropy_run` member in the `mbedtls_entropy_context` structure (on the initial run it is zero, non-zero otherwise). FN_NV_SEED_WR not being called might mean that your “Entropy” variable hasn’t been properly initialised or that it has been used before the callbacks are set. Please note that Mbed TLS 2.16.2 has known bugs and vulnerabilities. You should upgrade to the latest bug-fixing version of the 2.16 branch, 2.16.10. Best regards, Janos (Mbed TLS developer) From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Friday, 4 June 2021 at 05:50 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Cc: T V LIJIN (EXT) <lijin.tv(a)kone.com> Subject: Re: [mbed-tls] NV_SEED read working and write not working Hi, I am working on a embedded platform, that does not has any entropy source except system ticks. To improve the randomness, I am trying to utilize NV_SEED operations. The version of mbedtls version 2.16.2 is being used. Configuration file I have enabled: #define MBEDTLS_ENTROPY_NV_SEED #define MBEDTLS_PLATFORM_NV_SEED_ALT After initializing and before seeding random number generator, I assign functions of nv seed read and write to platform seeding function as below. if( r = mbedtls_platform_set_nv_seed(FN_NV_SEED_RD, FN_NV_SEED_WR) ) { return( r ); } if( r = mbedtls_ctr_drbg_seed( &CtrDrbg, mbedtls_entropy_func, &Entropy, (const unsigned char *) u8SeedingString, (size_t)Length ) ) { return ( r ); } Later functions to generate random and free context. While running, I could see only the FN_NV_SEED_RD function is getting called. And, FN_NV_SEED_WR function is not getting called. I tried to add some print statements in mbedtls library function, mbedtls_entropy_update_nv_seed(). But it looks like, this function was never called by the library. 1. Anything else to be done? 2. someone could help me ensure NV_SEED is properly incorporated 3. How to trace the issue. Thanks, Gopi Krishnan

4 years

2
1
0 0

NV_SEED read working and write not working

by Subramanian Gopi Krishnan

Hi, I am working on a embedded platform, that does not has any entropy source except system ticks. To improve the randomness, I am trying to utilize NV_SEED operations. Configuration file I have enabled: #define MBEDTLS_ENTROPY_NV_SEED #define MBEDTLS_PLATFORM_NV_SEED_ALT After initializing and before seeding random number generator, I assign functions of nv seed read and write to platform seeding function as below. if( r = mbedtls_platform_set_nv_seed(FN_NV_SEED_RD, FN_NV_SEED_WR) ) { return( r ); } if( r = mbedtls_ctr_drbg_seed( &CtrDrbg, mbedtls_entropy_func, &Entropy, (const unsigned char *) u8SeedingString, (size_t)Length ) ) { return ( r ); } Later functions to generate random and free context. While running, I could see only the FN_NV_SEED_RD function is getting called. And, FN_NV_SEED_WR function is not getting called. Could anyone suggest how to trace the issue. I do not have debugger on for my platform. I could debug only with print statements. Thanks, Gopi Krishnan

4 years

1
1
0 0

Signing without explicit private key

by stefano664

Hi all, I'm using mbedTLS libraries with an OPTIGA cryptochip. At the moment, when I call the sign function: err = mbedtls_pk_sign(&priv_key, MBEDTLS_MD_SHA384, hash, 0, sign, &olen, mbedtls_ctr_drbg_random, &ctr_drbg); I need to pass it a valid private key else if it isn't used, because alternative sign routine use the one into cryptochip. It is possible to avoid passing this key? Best regards, Stefano Mologni

4 years

1
0
0 0

Please help regarding [ERR ][TLSx]: mbedtls_ssl_handshake() failed: -0x7780 (-30592): SSL

by victor Wolff

Hello I am relatively new to mbedTLS, but I'm trying to develop an MQTT client running on an STM32 board connected to an ESP8266 MCU/WiFi module. The client should publish messages to a local broker/server where I am using Mosquitto for that purpose. I want to test different Cipher suites but when I limiting the Server to only accept one particle Cipher suite I receive an error from the server point of view "1622667145: OpenSSL Error[0]: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher" Which I find is strange because when I read through the debug list presented below it says "[DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02c". I "think" I have enabled the "MBEDTLS_SHA256_C" in the config file (mbed_lib.json) for the TLSsocket, and the cipher suites I have tested so far to limit it for is: DHE-RSA-AES128-SHA |AES128-SHA | DHE-RSA-AES128-SHA256. Could you please look at the debug list presented below to see if anything looks suspicious, or if you have any ideas? because I am truly lost and I am shooting in the dark trying to find the answer online... Thank you sincerely in advance Best regards Victor --------Debug list -------- AT< WIFI CONNECTED AT< WIFI GOT IP AT< AT= OK AT> AT+CIFSR AT< AT< AT+CIFSR AT< +CIFSR:APIP,"192.168.4.1" AT< +CIFSR:APMAC,"da:bf:c0:0d:c5:d8" AT= +CIFSR:STAIP,"192.168.10.103" AT< AT< +CIFSR:STAMAC,"d8:bf:c0:0d:c5:d8" AT< AT= OK Network interface opened successfully. Connecting to host 192.168.10.165:8883 ... Hello [INFO][TLSx]: Connecting to 192.168.10.165:8883 AT> AT+CIPSTART=0,"TCP","192.168.10.165",8883 AT< AT< AT+CIPSTART=0,"TCP","192.168.10.165",8883 AT< 0,CONNECT AT< AT= OK [INFO][TLSx]: Connected. [INFO][TLSx]: Starting the TLS handshake... [DBG ][TLSx]: ssl_tls.c:6335: |2| => handshake [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 0 [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 1 [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output [DBG ][TLSx]: ssl_cli.c:0717: |2| => write client hello [DBG ][TLSx]: ssl_cli.c:0754: |3| client hello, max version: [3:3] [DBG ][TLSx]: ssl_cli.c:0693: |3| client hello, current time: 14712 [DBG ][TLSx]: ssl_cli.c:0764: |3| dumping 'client hello, random bytes' (32 bytes) [DBG ][TLSx]: ssl_cli.c:0764: |3| 0000: 00 00 39 78 00 7d 4e 7a c5 43 7f d9 5b 0c cd 3f ..9x.}Nz.C..[..? [DBG ][TLSx]: ssl_cli.c:0764: |3| 0010: 01 a0 2f 60 8e a5 c1 54 1c 0e 58 6a a3 da c0 7a ../`...T..Xj...z [DBG ][TLSx]: ssl_cli.c:0817: |3| client hello, session id len.: 0 [DBG ][TLSx]: ssl_cli.c:0818: |3| dumping 'client hello, session id' (0 bytes) [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02c [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c030 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ad [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c024 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c028 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0af [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02b [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02f [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ac [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c023 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c027 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ae [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c038 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c037 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00a9 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a5 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00af [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a9 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00a8 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a4 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00ae [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a8 [DBG ][TLSx]: ssl_cli.c:0918: |3| client hello, got 23 ciphersuites [DBG ][TLSx]: ssl_cli.c:0949: |3| client hello, compress len.: 1 [DBG ][TLSx]: ssl_cli.c:0950: |3| client hello, compress alg.: 0 [DBG ][TLSx]: ssl_cli.c:0071: |3| client hello, adding server name extension: 192.168.10 .165 [DBG ][TLSx]: ssl_cli.c:0178: |3| client hello, adding signature_algorithms extension [DBG ][TLSx]: ssl_cli.c:0263: |3| client hello, adding supported_elliptic_curves extensi on [DBG ][TLSx]: ssl_cli.c:0326: |3| client hello, adding supported_point_formats extension [DBG ][TLSx]: ssl_cli.c:0507: |3| client hello, adding encrypt_then_mac extension [DBG ][TLSx]: ssl_cli.c:0541: |3| client hello, adding extended_master_secret extension [DBG ][TLSx]: ssl_cli.c:0575: |3| client hello, adding session ticket extension [DBG ][TLSx]: ssl_cli.c:1022: |3| client hello, total extension length: 73 [DBG ][TLSx]: ssl_tls.c:2701: |2| => write record [DBG ][TLSx]: ssl_tls.c:2835: |3| output record: msgtype = 22, version = [3:1], msglen = 164 [DBG ][TLSx]: ssl_tls.c:2840: |4| dumping 'output record sent to network' (169 bytes) [DBG ][TLSx]: ssl_tls.c:2840: |4| 0000: 16 03 01 00 a4 01 00 00 a0 03 03 00 00 39 78 00 .............9x. [DBG ][TLSx]: ssl_tls.c:2840: |4| 0010: 7d 4e 7a c5 43 7f d9 5b 0c cd 3f 01 a0 2f 60 8e }Nz.C..[..?../`. [DBG ][TLSx]: ssl_tls.c:2840: |4| 0020: a5 c1 54 1c 0e 58 6a a3 da c0 7a 00 00 2e c0 2c ..T..Xj...z...., [DBG ][TLSx]: ssl_tls.c:2840: |4| 0030: c0 30 c0 ad c0 24 c0 28 c0 af c0 2b c0 2f c0 ac .0...$.(...+./.. [DBG ][TLSx]: ssl_tls.c:2840: |4| 0040: c0 23 c0 27 c0 ae c0 38 c0 37 00 a9 c0 a5 00 af .#.'...8.7...... [DBG ][TLSx]: ssl_tls.c:2840: |4| 0050: c0 a9 00 a8 c0 a4 00 ae c0 a8 00 ff 01 00 00 49 ...............I [DBG ][TLSx]: ssl_tls.c:2840: |4| 0060: 00 00 00 13 00 11 00 00 0e 31 39 32 2e 31 36 38 .........192.168 [DBG ][TLSx]: ssl_tls.c:2840: |4| 0070: 2e 31 30 2e 31 36 35 00 0d 00 12 00 10 06 03 06 .10.165......... [DBG ][TLSx]: ssl_tls.c:2840: |4| 0080: 01 05 03 05 01 04 03 04 01 03 03 03 01 00 0a 00 ................ [DBG ][TLSx]: ssl_tls.c:2840: |4| 0090: 06 00 04 00 18 00 17 00 0b 00 02 01 00 00 16 00 ................ [DBG ][TLSx]: ssl_tls.c:2840: |4| 00a0: 00 00 17 00 00 00 23 00 00 ......#.. [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2434: |2| message length: 169, out_left: 169 AT> AT+CIPSEND=0,169 AT< AT< AT+CIPSEND=0,169 AT< AT< OK AT= > [DBG ][TLSx]: ssl_tls.c:2441: |2| ssl->f_send() returned 169 (-0xffffff57) [DBG ][TLSx]: ssl_tls.c:2460: |2| <= flush output [DBG ][TLSx]: ssl_tls.c:2850: |2| <= write record [DBG ][TLSx]: ssl_cli.c:1049: |2| <= write client hello [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 2 [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output [DBG ][TLSx]: ssl_cli.c:1410: |2| => parse server hello [DBG ][TLSx]: ssl_tls.c:3728: |2| => read record [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 0, nb_want: 5 AT< AT< Recv 169 bytes AT< AT< SEND OK AT< AT! +IPD AT= ,0,7: AT< 0,CLOSED [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 0, nb_want: 5 [DBG ][TLSx]: ssl_tls.c:6345: |2| <= handshake [DBG ][TLSx]: ssl_tls.c:6335: |2| => handshake [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 2 [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output [DBG ][TLSx]: ssl_cli.c:1410: |2| => parse server hello [DBG ][TLSx]: ssl_tls.c:3728: |2| => read record [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 0, nb_want: 5 [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 0, nb_want: 5 [DBG ][TLSx]: ssl_tls.c:2391: |2| ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) [DBG ][TLSx]: ssl_tls.c:2403: |2| <= fetch input [DBG ][TLSx]: ssl_tls.c:3479: |4| dumping 'input record header' (5 bytes) [DBG ][TLSx]: ssl_tls.c:3479: |4| 0000: 15 03 03 00 02 ..... [DBG ][TLSx]: ssl_tls.c:3485: |3| input record: msgtype = 21, version = [3:3], msglen = 2 [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 5, nb_want: 7 [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 5, nb_want: 7 [DBG ][TLSx]: ssl_tls.c:2391: |2| ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) [DBG ][TLSx]: ssl_tls.c:2403: |2| <= fetch input [DBG ][TLSx]: ssl_tls.c:3656: |4| dumping 'input record from network' (7 bytes) [DBG ][TLSx]: ssl_tls.c:3656: |4| 0000: 15 03 03 00 02 02 28 ......( [DBG ][TLSx]: ssl_tls.c:3960: |2| got an alert message, type: [2:40] [DBG ][TLSx]: ssl_tls.c:3968: |1| is a fatal alert message (msg 40) [DBG ][TLSx]: ssl_tls.c:3744: |1| mbedtls_ssl_handle_message_type() returned -30592 (-0x 7780) [DBG ][TLSx]: ssl_cli.c:1416: |1| mbedtls_ssl_read_record() returned -30592 (-0x7780) [DBG ][TLSx]: ssl_tls.c:6345: |2| <= handshake [ERR ][TLSx]: mbedtls_ssl_handshake() failed: -0x7780 (-30592): SSL AT> AT+CIPCLOSE=0 AT< AT+CIPCLOSE=0 AT< UNLINK AT< AT< ERROR AT> AT+CIPCLOSE=0 AT< AT+CIPCLOSE=0 AT< UNLINK AT< AT< ERROR ERROR: rc from TCP connect is -30592 [DBG ][TLSx]: ssl_tls.c:7055: |2| => free [DBG ][TLSx]: ssl_tls.c:7120: |2| <= free AT> AT+CWQAP AT< AT+CWQAP AT< AT= OK

4 years

1
0
0 0

Parsing PKCS12 file

by Sunil Jain

Hello, We have requirements of parsing PKCS12 file in our project to import the certificate. I have seen the code and am not able to find the related API which can be used to parse the PKCS12 file. Do you have some sample example code which does this work? Thanks for your help. -- Regards, Sunil Jain

4 years

1
0
0 0

FTP Data connection handshake is failing

by Sunil Jain

Hello, We are porting MbedTLS 2.16 for FTP server. There are 2 connection in FTP communication, Control and data. For control communication we are ok with handshake but data communication handshake is having issue. We have observed with FTP Client (FileZilla) our earlier implementation of FTP server with Mocana secure library, we used to send certificate and server key exchange in control communication handshake only, for Data communication handshake ServerHello and change cipher spec was sent. But in case of MbedTLS, we are sending certificate and server key exchange in data communication handshake also. FTP Client (FileZilla) is rejecting the handshake after receiving the server certificate server key exchange and from the FTP server as I believe it is expecting session resumption and FTP Server is waiting for client key exchange in handshake. In attached wireshark trace, packet number 1570 is having issue. When we tested this server with another FTP client (WinSCP), its working fine as this client is not expecting session resumption. As I go through the code documentation of MbedTLS, I found that we cannot set the session resumption at server side, only client side we can do this setting. How can we make FTP server ready with session resumption? Please support us. Thanks and Regards, Sunil

4 years, 1 month

1
0
0 0

ECDSA signature verification failure

by Nassim Eddequiouaq

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

4 years, 1 month

1
0
0 0

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

by Selin Chris

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

4 years, 1 month

1
0
0 0

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

by Vaibhav Sathye

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

4 years, 1 month

1
0
0 0

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

by Gilles Peskine

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

4 years, 1 month

1
0
0 0

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

by Selin Chris

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

4 years, 1 month

1
0
0 0

Re: [mbed-tls] Query for TLS 1.3

by Shebu Varghese Kuriakose

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

4 years, 1 month

1
0
0 0

Query for TLS 1.3

by Manoj Srivastava

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

4 years, 1 month

1
0
0 0

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

by brian_d＠tutanota.com

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

4 years, 1 month

1
0
0 0

Not sure if the TLS implementation is correct or not

by Younes Boulahya

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

4 years, 1 month

1
0
0 0

mbedTLS -entropy source issue

by Pandurangan, Devi

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

4 years, 1 month

1
0
0 0

Re: [mbed-tls] URGENT PLEASE

by Frank Bergmann

Hello Younes, I assume that you recently joined the list here. In that case: Please welcome! Since ole times of Usenet it is a common behaviour to first subscribe a list/channel and listen to the posts. After some time write your own first email to the list, introduce yourself quickly and write about your problem. But please do never start with an email carrying "URGENT" in subject. This is not politely. See, the people maintaining this list do this without any fees. The spent their time to answer questions "from the community" for free. And they do it well! Hence please avoid galopping in here. ;-) You want https and sftp implementations, which are layer 7 and actually mostly on a different/higher layer then mbed TLS. And they are not trivial - there is NO SIMPLE implementation! Please compare it to projects like e.g. Apache or OpenSSH: The people required months/years to get an implementation. Regarding the C code you sent: Obviously it is at least partly coming from STM and it has a size of more than 50 KiB. Why did you sent that? This is not just a code snippet of a few lines. Did you actually expect that anyone would analyze it? Maybe someone is on this list who knows the code and can give you some hints. But don't expect a "working example of https and sftp". Hence my personal answer: - Basic examples like "client" and "server" are already provided by mbed TLS! You just need to extend them with https and sftp protocol. - If you want to use a SIMPLE implementation then please use Python or Java/Groovy. Because then you don't need to know most of the technical details of https and sftp. - If you are looking for many "working examples" of code then you should also think about using a lib like OpenSSL which is mostly used. And please be politely. Please remember that the people here are giving support for free. Great support for free. cheers, Frank On 03.05.21 21:11, Younes Boulahya via mbed-tls wrote: > I am using STM32F303RCT6 and W5500, I want to upgrade to HTTPS and > SFTP, but I can't find any working example that I can use, can you > provide me a simple one PLEASE, of both HTTPS and SFTP. > > I attach my current c code, thank you so much 🌷 > -- 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, 1 month

1
0
0 0

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

by Gilles Peskine

Hi Brian, It's not clear to me what you're trying to do. Mbed TLS supports Curve25519 arithmetic for X25519, accessible through the mbedtls_ecdh_xxx interface. If you want to use Curve25519 for some other purpose, this may or may not be supported via direct access to the mbedtls_ecp_xxx interface. The curve arithmetic code only supports predefined groups, it does not support changing the generator without patching the library. For Curve25519, the generator is the point (X,Z)=(9,1). Isn't this the generator you want? Best regards, -- Gilles Peskine Mbed TLS developer On 30/04/2021 17:39, Brian via mbed-tls wrote: > Hi all, > I'm trying to set the generator g to a value of 9 for the Curve25519 with mbedtls_ecp_gen_key function. However I cannot find any way to accomplish that. > Could anyone help me? > Thank you, have a nice day,Brian

4 years, 1 month

1
0
0 0

URGENT PLEASE

by Younes Boulahya

<mbed-tls(a)lists.trustedfirmware.org>I am using STM32F303RCT6 and W5500, I want to upgrade to HTTPS and SFTP, but I can't find any working example that I can use, can you provide me a simple one PLEASE, of both HTTPS and SFTP. I attach my current c code, thank you so much 🌷

4 years, 1 month

1
0
0 0

Support for ECDH key generation with Curve25519

by brian_d＠tutanota.com

Hi all, I'm trying to set the generator g to a value of 9 for the Curve25519 with mbedtls_ecp_gen_key function. However I cannot find any way to accomplish that. Could anyone help me? Thank you, have a nice day,Brian

4 years, 1 month

1
0
0 0

Problems during certificate verifing

by stefano664

Good morning, I'm testing a routine that verify the validity of an intermediate certificate, against my root certificate. Both certificates are generated on my machine. The code to do this is here: https://wtools.io/paste-code/b4OL I can do the verify with openSSL and works fine. When I pass certificates tombedTLS it returns these errors: The certificate is signed with an unacceptable hash. The certificate is signed with an unacceptable PK alg (eg RSA vs ECDSA). The certificate is signed with an unacceptable key (eg bad curve, RSA too short). Can someone help me to find the mistakes? Thanks for your help. ROOT CERTIFICATE: -----BEGIN CERTIFICATE----- MIIB8TCCAXagAwIBAgIBATAMBggqhkjOPQQDAgUAMDkxCzAJBgNVBAMMAkNBMR0w GwYDVQQKDBRDb21lbGl0IEdyb3VwIFMucC5BLjELMAkGA1UEBhMCSVQwHhcNMDEw MTAxMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjA5MQswCQYDVQQDDAJDQTEdMBsGA1UE CgwUQ29tZWxpdCBHcm91cCBTLnAuQS4xCzAJBgNVBAYTAklUMHYwEAYHKoZIzj0C AQYFK4EEACIDYgAE/u9D/9E9S8kmJ5W75GwaZxUuXYuCYfszCsjNEuylVMj8N1r6 Ce+FJ3eSKQGgh2/H2Pd5Ck7TENQSuVBZIVsUcUv5q/MGGJWUNLCSZm2b5kadVKXQ 6Cn6t7RDFQ0IvRoLo1AwTjAMBgNVHRMEBTADAQH/MB8GA1UdIwQYMBaAFOzrPv2f Rkotop0JzDEg/9CtjcRjMB0GA1UdDgQWBBTs6z79n0ZKLaKdCcwxIP/QrY3EYzAM BggqhkjOPQQDAgUAA2cAMGQCMAxEjQOUP2hC3yhGIkz04Y9fFR6WWH8kUqQEutfb 57Q9ADRFsmAVtJgOZEsVhnZ6ugIwcRK7dngvNozV9Uu4ifhDCLF7qQhAH4XyQ/WI GgKtCIBIps/H+JQNqjpwsVs8zlER -----END CERTIFICATE----- INTERMEDIATE CERTIFICATE: -----BEGIN CERTIFICATE----- MIIDDDCCAo+gAwIBAgIBATAMBggqhkjOPQQDAgUAMDkxCzAJBgNVBAMMAkNBMR0w GwYDVQQKDBRDb21lbGl0IEdyb3VwIFMucC5BLjELMAkGA1UEBhMCSVQwHhcNMDEw MTAxMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBozE+MDwGA1UEAww1Q29tZWxpdCBD bG91ZCBBcyBEZXYgS2ZHWUFjWHg5U3NvMnlic3plcDRQTjZjR295R1BMaTAxJjAk BgNVBAsMHUNvbWVsaXQgR3JvdXAgU3BhIC0gQ2xvdWQgTGFiMRowGAYDVQQKDBFD b21lbGl0IEdyb3VwIFNwYTEQMA4GA1UECAwHQmVyZ2FtbzELMAkGA1UEBhMCSVQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCfGrKbFRgC5o8REbcYdRzW FXS772+CC15nXCJR67gWL1wmKzrCekkFNlOnQrsPhe4iYnkhLuBYNWaVvSaHt9dS X/ZBbJ3bRnGAarw7QnirLZJFYSRRBhMw6xi91nt8kIvcA6kACFcooaRmg/jQzCyb eXO1skJhDv13TxwDB8UTtRkfOTFl23FekMPWmJpqU1YxjAAYRtcY4jGAtV4D7T3V 3WjZ0eaIjl9n2g9/slG6p3ZSjONIRmyTiBRQNynKCxy1Q9Px1ohDCcS2SsK0smy6 0EzCghEz8QjAWs7U9Ilh3OTCdCpV9clp1DQrjbDZky1rMEd7mRmTp8Fmd2c3ld0F AgMBAAGjUDBOMB0GA1UdDgQWBBT3OOc7ZPbeOBTkeYPBFQcQTLhECDAfBgNVHSME GDAWgBTs6z79n0ZKLaKdCcwxIP/QrY3EYzAMBgNVHRMEBTADAQH/MAwGCCqGSM49 BAMCBQADaQAwZgIxAJvrL0kIeB4mvRJT1MRA0Kc/mw5ZVVv0ErOQqLhQShECw6+K s5DL9V/tHf72iCCivAIxANfBJ2IMLzSZCOrSmr9fOCQktM6mFC5PyAuZX+3OGPfU UuJwph7GaoWW+fw1IxQm2Q== -----END CERTIFICATE----- Thanks a lot, Stefano

4 years, 1 month

1
0
0 0

Mbed TLS 3.0 branch transition

by Dave Rodgman

Hi, Today we are switching our branches around, so that the development branch focuses on Mbed TLS 3.0, to be released mid-year. This will include API-breaking changes. 2.x development work will continue on the development_2.x branch. After merging development_3.0 onto development, the development_3.0 branch will be removed. There is no change to the process for submitting PRs: new PRs should continue to target development, with backports to 2.x and 2.16 as needed. (The exception would be a bug-fix that only affects older branches, which would only need ports to the affected branches and not to development). As part of the 3.0 work, we are looking at various things that can be removed from the library. For some of these, we’ve notified the mailing list – please let us know in the next week if you have a good reason for retaining the feature in question. - Remove support for TLS 1.0, TLS 1.1 and DTLS 1.0 https://github.com/ARMmbed/mbedtls/issues/4286 - Remove support for the "Truncated HMAC" (D)TLS extension https://github.com/ARMmbed/mbedtls/issues/4341 - Remove support for 3DES ciphersuites in (D)TLS https://github.com/ARMmbed/mbedtls/issues/4367 - Remove support for RC4, Blowfish, XTEA, MD2 and MD4 https://github.com/ARMmbed/mbedtls/issues/4084 - Remove support for pre-v3 X.509 certificates with extensions https://github.com/ARMmbed/mbedtls/issues/4386 - Remove the RSA key mutex https://github.com/ARMmbed/mbedtls/issues/4124 - Remove MBEDTLS_CHECK_PARAMS https://github.com/ARMmbed/mbedtls/issues/4313 - 3.0 and 2.x :- Minimum development environment: is it OK to require Python >= 3.6 and/or CMake >= 3.5.2? https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-March/000319.html Dave Rodgman

4 years, 2 months

1
0
0 0

Removal of generated source and build files from the development branch

by Gilles Peskine

Hello, A number of files in the Mbed TLS source tree are automatically generated from other files, with a content that does not depend on the platform or configuration. We are considering removing the generated files from the development branch in Git, at least during the work towards Mbed TLS 3.0. This would affect at least the development branch until the 3.0 release, and may affect the development_2.x branch and the development branch after the 3.0 release. Long-time support branches and official releases will continue to have these source files in the Git tree. The reason to remove the generated files is to facilitate development, especially with the restructuring that is happening as we prepare a new major version of the library. This is an experimental change; depending on how effective it is, we may or may not wish to restore the generated files on the development branch when 3.0 stabilizes. It's also still possible that we will not go ahead with this change, depending on the impact on our CI and on the feedback we receive. The affected files are: * Two library source files: library/error.c and library/version_features.c. * Parts of some test programs: programs/test/query_config.c and programs/psa/psa_constant_names_generated.c. * The Visual Studio project files. * Some unit test data files. What does this change for you? **If you were using a long-time support branch or an official release**: no change. **If you were using the supplied GNU Makefile**: there should be no effective change. **If you were using CMake, Visual Studio or custom build scripts** on the development branch: Perl (>=5.8) will be required to generate some library sources and to generate the Visual Studio project files. Python (>=3.4) was already required to run config.py and to build the unit tests. Note that the generated files are independent of the Mbed TLS configuration, so if your deployment has a pre-configuration step, you can generate the files at this step: no new tool is required after the library is configured. The ongoing work (not complete yet as I write) is at https://github.com/ARMmbed/mbedtls/pull/4395 if you want to see what this change means concretely. We are aware that the additional dependencies are a burden in some environments, which is why we will definitely not change anything to releases or to current and future long-time support branches. If you are building Mbed TLS from the development branch and this change affects you, please let us know what constraints apply to your environment. Best regards, -- Gilles Peskine Mbed TLS developer

4 years, 2 months

1
0
0 0

Re: [mbed-tls] Uninitialized variable in rsa_prepare_blinding

by Gilles Peskine

Hello, The macro MBEDTLS_MPI_CHK sets ret, so this particular case is safe. That being said, we do have a hygiene rule to initialize ret variables, to avoid accidentally having uninitialized variables in edge cases. I'll file an issue to fix those. Thanks for reaching out! -- Gilles Peskine Mbed TLS developer On 21/04/2021 17:33, momo 19 via mbed-tls wrote: > Hello, > > I would like to report a possible bug in rsa_prepare_blinding function > in rsa.c > (https://github.com/ARMmbed/mbedtls/blob/v2.26.0/library/rsa.c > <https://github.com/ARMmbed/mbedtls/blob/v2.26.0/library/rsa.c>). I am > not sure if it is a real issue, but I think that there is a > possibility to use uninitialized variable ret: > > static int rsa_prepare_blinding( mbedtls_rsa_context *ctx, > int (*f_rng)(void *, unsigned char *, size_t), void > *p_rng ) > { > int ret, count = 0; <--- uninitialized variable ret > mbedtls_mpi R; > > mbedtls_mpi_init( &R ); > > if( ctx->Vf.p != NULL ) > { > /* We already have blinding values, just update them by > squaring */ > MBEDTLS_MPI_CHK( mbedtls_mpi_mul_mpi( &ctx->Vi, &ctx->Vi, > &ctx->Vi ) ); > MBEDTLS_MPI_CHK( mbedtls_mpi_mod_mpi( &ctx->Vi, &ctx->Vi, > &ctx->N ) ); > MBEDTLS_MPI_CHK( mbedtls_mpi_mul_mpi( &ctx->Vf, &ctx->Vf, > &ctx->Vf ) ); > MBEDTLS_MPI_CHK( mbedtls_mpi_mod_mpi( &ctx->Vf, &ctx->Vf, > &ctx->N ) ); > > goto cleanup; <--- going to cleanup without setting a value of ret > } > > (Skipping lines for readability) > > cleanup: > mbedtls_mpi_free( &R ); > > return( ret ); <--- returning uninitialized variable ret > } > > Best regards, > grapix121 > >

4 years, 2 months

1
0
0 0

Uninitialized variable in rsa_prepare_blinding

by momo 19

Hello, I would like to report a possible bug in rsa_prepare_blinding function in rsa.c (https://github.com/ARMmbed/mbedtls/blob/v2.26.0/library/rsa.c). I am not sure if it is a real issue, but I think that there is a possibility to use uninitialized variable ret: static int rsa_prepare_blinding( mbedtls_rsa_context *ctx, int (*f_rng)(void *, unsigned char *, size_t), void *p_rng ) { int ret, count = 0; <--- uninitialized variable ret mbedtls_mpi R; mbedtls_mpi_init( &R ); if( ctx->Vf.p != NULL ) { /* We already have blinding values, just update them by squaring */ MBEDTLS_MPI_CHK( mbedtls_mpi_mul_mpi( &ctx->Vi, &ctx->Vi, &ctx->Vi ) ); MBEDTLS_MPI_CHK( mbedtls_mpi_mod_mpi( &ctx->Vi, &ctx->Vi, &ctx->N ) ); MBEDTLS_MPI_CHK( mbedtls_mpi_mul_mpi( &ctx->Vf, &ctx->Vf, &ctx->Vf ) ); MBEDTLS_MPI_CHK( mbedtls_mpi_mod_mpi( &ctx->Vf, &ctx->Vf, &ctx->N ) ); goto cleanup; <--- going to cleanup without setting a value of ret } (Skipping lines for readability) cleanup: mbedtls_mpi_free( &R ); return( ret ); <--- returning uninitialized variable ret } Best regards, grapix121

4 years, 2 months

1
0
0 0

Re: [mbed-tls] Signing messages with ECDSA

by stefano664

Excuse me, I replied to your e-mail without note that I'm replying to your address instead of mailing-list address. Now I'll do some other tests, starting from a blank project. I can't send a fully compilable FW because my target is an ESP32 with an OPTIGA crypto chip connected,. than it is necessary to have my hardware to run it. But attached I put my mbedtls configuration. Thank you, Stefano Il giorno mer 21 apr 2021 alle ore 14:36 Gilles Peskine < gilles.peskine(a)arm.com> ha scritto: > I adjusted your code to compile and added the missing definitions and > declarations, and this version works for me. I've attached my code. Here's > the output I get (Mbed TLS , default configuration): > > Message: PLUTOxPLUTOxPLUTOxPLUTOxPLUTOxxx > Private key: -----BEGIN EC PRIVATE KEY----- > MIGkAgEBBDCv5Vq0yRsOKLkkaI0lR32vByL9MB+4O0f+bhVErb8Fd0W1XFhN1897 > iAtnV/DeXDygBwYFK4EEACKhZANiAARgYE9uzG+nXYDoydWyDE6wrlgxiRKqm6kg > si00tFa0KD//vCemOAoYAmmbtFd9RvE6tNOw+Ze5eRtVvosmvYl5IoWx4Jda+Wv9 > ftRXkUk3nRzcAmXnG7bGmgwNC2iC73s= > -----END EC PRIVATE KEY----- > > Hash: yrmtrgMb4WzvHD5XWwb00yAE13RCi934x2ySjcWup5g= > Signature: MGQCMD8pezXqUF6v01b0WQiIUZWuuvxPR1tT15YnN9atogKR2pBPizBYbbhjAIz+ftm78AIwDogKWZVxDk5r6I38oIn0JALO7h8EcTCwjUsulYS5BRl8iyITAC42Xx+HlRPofwbr > Public key: -----BEGIN PUBLIC KEY----- > MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEYGBPbsxvp12A6MnVsgxOsK5YMYkSqpup > ILItNLRWtCg//7wnpjgKGAJpm7RXfUbxOrTTsPmXuXkbVb6LJr2JeSKFseCXWvlr > /X7UV5FJN50c3AJl5xu2xpoMDQtogu97 > -----END PUBLIC KEY----- > > > I don't think I can be of any more help unless you post code to reproduce > the problem that can be compiled and run a popular platform (preferably > Linux) without modifications, and also your library configuration > (mbedtls/config.h). Preferably post those on the mailing list, because I > personally have limited time and I'm not sure when I'll next be able to > take a look. > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > > On 21/04/2021 14:14, stefano664 wrote: > > I'm sure that the problem isn't here. > > 1) mbedtls_base64_encode is used only to generate human readable data in > this case, and to print it. The chain have the same behaviour without these. > > 2) I changed len_b64 and olen type to size_t and removed casting. I have > the same result and verify fails... > > Here the new code: https://wtools.io/paste-code/b4Hy > > Here the new output: https://wtools.io/paste-code/b4H0 > > Do you have some other idea? > Thanks a lot for your help! > > Stefano > > > Il giorno mer 21 apr 2021 alle ore 13:36 Gilles Peskine < > gilles.peskine(a)arm.com> ha scritto: > >> Ok, I found the problem: >> >> mbedtls_base64_encode(hash_b64, sizeof(hash_b64), (size_t *) &len_b64, hash, 32); >> >> >> &len_b64 is a pointer to uint16_t. Casting the pointer to size_t* doesn't >> give you a pointer to a size_t object, it gives you an invalid pointer >> since it isn't pointing to a size_t object. When mbedtls_base64_encode >> writes through that pointer, it overwrites whatever is next on the stack. >> Other calls with a size_t* cast have the same problem. Depending on exactly >> how your compiler lays out the stack, this might part of the message, or >> part of the pk structure, or part of the result... >> >> I found this problem because I massaged your code until it ran on Linux, >> and it crashed during mbedtls_pk_sign because the pk structure had been >> corrupted. Other potential ways to find such problems include static >> analysis (Coverity is good but very expensive), AddressSanitizer (if you >> can build your code on a platform that has enough space), and of course >> code review (any cast is suspicious: most of the times, when a compiler >> complains about something, a cast will silence the compiler but not >> actually fix the problem). >> >> Best regards, >> >> -- >> Gilles Peskine >> Mbed TLS developer >> >> On 21/04/2021 09:43, stefano664 wrote: >> >> Hi Gilles, >> thanks for your reply. >> >> The posted code is without error checks to be smaller. The complete code >> is here: >> >> https://wtools.io/paste-code/b4Hi >> >> All error checks pass true than all functions seems ok. >> >> In this version I added also the verify, that fail. >> >> Here you can find the output with all prints, messages and datas: >> >> https://wtools.io/paste-code/b4Hj >> >> As you can see my signature is 71 byte wide, a bit too little even after >> zeroes removing. The same made with openSSL is 104 byte wide. >> I've checked my keys, and I confirm it is 384 bit. You can check, it is >> printed during process. >> >> Thanks a lot for your help! >> >> Best regards, >> Stefano >> >> >> Il giorno mar 20 apr 2021 alle ore 21:48 Gilles Peskine via mbed-tls < >> mbed-tls(a)lists.trustedfirmware.org> ha scritto: >> >>> Hi Stefano, >>> >>> Assuming that the key is in PEM format and that the buffers (hash, tmp) >>> are large enough, I don't see anything wrong in the part of the code you >>> posted. >>> >>> You posted code without error checking. Can you confirm that all >>> functions return 0? >>> >>> mbedtls_pk_sign produces ECDSA signatures in ASN.1 format. The size of >>> the signature can be up to 104 bytes, and is often a few bytes shorter >>> because it consists of numbers in which leading zeros are omitted. Make >>> sure the tmp buffer is large enough. You can use >>> MBEDTLS_ECDSA_MAX_SIG_LEN(384) or MBEDTLS_ECDSA_MAX_LEN (from >>> mbedtls/ecdsa.h) as the signature buffer size. >>> >>> 72 bytes is the maximum size of a signature for a 256-bit key, reached >>> about 25% of the time. Are you sure you're signing with the key you >>> intended? >>> >>> People may be able to help more if you post complete code that we can >>> run on our machine. >>> >>> Best regards, >>> >>> -- >>> Gilles Peskine >>> Mbed TLS developer >>> >>> On 20/04/2021 16:49, stefano664 via mbed-tls wrote: >>> > 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 >>> > >>> >>> -- >>> mbed-tls mailing list >>> mbed-tls(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >>> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> > > 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, 2 months

1
0
0 0

3.0 proposal: remove support for pre-v3 X.509 certificate with extensions

by Manuel Pegourie-Gonnard

Hi all, Version 3 of X.509 was published in 1997 and introduced extensions. However, in the years that followed, some implementations did generate certificates with extensions and a declared version less than 3. Such certs were never compliant and are rejected by default, however we have a compile-time option to no reject them for that reason: MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3 Since this is 2021 and pre-v3 certificates are unlikely to still be used, we'd like to remove this option in Mbed TLS 3.0. (It would remain in 2.16 and the upcoming 2.x LTS branch.) As usual, more details can be found in the github issue: https://github.com/ARMmbed/mbedtls/issues/4386 If you need this option to still be available in Mbed TLS 3.0, please speak up now, here on on github! Regards, Manuel.

4 years, 2 months

1
0
0 0

Re: [mbed-tls] SSL session cache API in Mbed TLS 3.0

by Jérémy Audiger

Hi Hanno, Regarding your first point, I'm not against having the structure mbedtls_ssl_session as opaque on the application side, at least, it ensures the application is not modifying something that it shouldn't. Having said that, on my side, I access three fields of this structure: * sslContext.state * sslContext.own_cid_len * sslContext.own_cid The first one is used to retrieve the current state, mainly MBEDTLS_SSL_HANDSHAKE_OVER, MBEDTLS_SSL_SERVER_HELLO_VERIFY_REQUEST_SENT. Finally, the match between an incoming LwM2M Client encrypted message using CID and the structure mbedtls_ssl_session is done by accessing own_cid / own_cid_len. But I think this one could be done using mbedtls_ssl_get_peer_cid(). Regards, Jérémy ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hanno Becker via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, April 16, 2021 06:37 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] SSL session cache API in Mbed TLS 3.0 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, 2 months

2
1
0 0

Re: [mbed-tls] Signing messages with ECDSA

by Gilles Peskine

Hi Stefano, Assuming that the key is in PEM format and that the buffers (hash, tmp) are large enough, I don't see anything wrong in the part of the code you posted. You posted code without error checking. Can you confirm that all functions return 0? mbedtls_pk_sign produces ECDSA signatures in ASN.1 format. The size of the signature can be up to 104 bytes, and is often a few bytes shorter because it consists of numbers in which leading zeros are omitted. Make sure the tmp buffer is large enough. You can use MBEDTLS_ECDSA_MAX_SIG_LEN(384) or MBEDTLS_ECDSA_MAX_LEN (from mbedtls/ecdsa.h) as the signature buffer size. 72 bytes is the maximum size of a signature for a 256-bit key, reached about 25% of the time. Are you sure you're signing with the key you intended? People may be able to help more if you post complete code that we can run on our machine. Best regards, -- Gilles Peskine Mbed TLS developer On 20/04/2021 16:49, stefano664 via mbed-tls wrote: > 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, 2 months

1
0
0 0

Signing messages with ECDSA

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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 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, 3 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, 3 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, 4 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, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls