- mbed-tls - lists.trustedfirmware.org

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

by Gilles Peskine

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

4 years, 2 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

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

4 years, 2 months

2
2
0 0

Failing CI tests, Generating coverage report

by Gábor Tóth

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

4 years, 2 months

1
0
0 0

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

by Gábor Tóth

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

4 years, 2 months

1
0
0 0

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

by Gilles Peskine

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

4 years, 2 months

1
0
0 0

X509 V3 - AuthorityKeyId extraction (pull-4117)

by Gábor Tóth

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

4 years, 2 months

1
0
0 0

mbedtls_rsa_private execution time on stm32f417

by Dmitry X

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

4 years, 2 months

1
0
0 0

3.0 plans: remove the RSA key mutex

by Gilles Peskine

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

4 years, 2 months

1
0
0 0

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

by Gilles Peskine

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

4 years, 2 months

1
0
0 0

Re: [mbed-tls] DTLS Mutual authentication

by Manuel Pegourie-Gonnard

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

4 years, 2 months

1
0
0 0

Use PKCS#11 and mbed TLS

by Frank Bergmann

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

4 years, 2 months

1
0
0 0

DTLS Mutual authentication

by saghili

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

4 years, 2 months

1
0
0 0

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

by Dave Rodgman

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

4 years, 2 months

1
0
0 0

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

by T V LIJIN (EXT)

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

4 years, 2 months

1
0
0 0

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

by Gilles Peskine

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

4 years, 3 months

1
0
0 0

Re: [mbed-tls] ENTROPY_SOURCE_FAILED :0x0034

by Gilles Peskine

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

4 years, 3 months

1
0
0 0

ENTROPY_SOURCE_FAILED :0x0034

by T V LIJIN (EXT)

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

4 years, 3 months

1
1
0 0

Reduce mbedTLS memory and storage footprint

by T V LIJIN (EXT)

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

4 years, 3 months

1
0
0 0

Devices acting as Both Client and Server

by saghili

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

4 years, 3 months

1
0
0 0

Re: [mbed-tls] PKCS#7

by Gilles Peskine

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

4 years, 3 months

1
0
0 0

PKCS#7

by Subramanian Gopi Krishnan

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

4 years, 3 months

1
0
0 0

Mbed TLS 2.7 end of support

by Dave Rodgman

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

4 years, 3 months

1
0
0 0

Add support to delegate cert verification to application

by Junqi Wang

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

4 years, 3 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

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

4 years, 3 months

1
0
0 0

Re: [mbed-tls] MBEDTLS issue I found

by Manuel Pegourie-Gonnard

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

4 years, 3 months

2
1
0 0

Re: [mbed-tls] MBEDTLS issue I found

by Manuel Pegourie-Gonnard

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

4 years, 4 months

1
0
0 0

MBEDTLS issue I found

by Xiao, Nian Jun

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

4 years, 4 months

1
0
0 0

Mbed TLS 3.0 plans

by Dave Rodgman

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

4 years, 4 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

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

4 years, 4 months

2
2
0 0

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

by Janos Follath via Mbed-tls-announce

Mbed TLS versions 2.25.0, 2.16.9 and 2.7.18 have just been released. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/v2.25.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.9, https://github.com/ARMmbed/mbedtls/releases/tag/v2.7.18 ). We recommend all users to consider whether they are impacted, and to upgrade appropriately. -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

4 years, 4 months

1
0
0 0

"Reordering" in DTLS

by saghili

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

4 years, 4 months

1
0
0 0

"packets lost" in DTLS in "Record" layer

by saghili

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

4 years, 4 months

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

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

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

4 years, 4 months

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

by Gilles Peskine

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

4 years, 4 months

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

by Gilles Peskine

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

4 years, 4 months

1
0
0 0

mbedtls undefined behaviour

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

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

4 years, 4 months

1
0
0 0

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

by Gilles Peskine

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

4 years, 4 months

1
0
0 0

Implementing MbedTLS on "xilinx zu7 zynq ultrascale+soc"

by saghili

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

4 years, 4 months

1
0
0 0

Mbed TLS on ESP32

by Radim Kohout

Hello, I am using ESP32 Dev Module, which supports MbedTLS. I have two questions, but I can't find the answer on the forum: 1.Is there any way to import RSA keys from string(ideally from PEM format) to mbedtls_pk context? 2.How to encrypt with RSA private key and decrypt with RSA public key? Thanks Radim Kohout

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Invalid ECDSA signature created

by ROSHINI DEVI

Thanks Gilles. I have use mbedtls_ecdsa_sign and got the raw buffer output of R & S values. On Sun, Nov 22, 2020, 9:26 PM Gilles Peskine via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi Roshini, > > Mathematically, an ES256 (ECDSA over the curve P256R1) signature is a > pair of numbers (r,s) between 1 and an upper bound which is very > slightly less than 2^256. There are two common representations for this > signature. JWA uses the “raw” representation: two big-endian numbers > represented each with exactly 32 bytes, concatenated together. > mbedtls_ecdsa_write_signature uses the ASN.1 DER representation, which > as you noticed represents each number in a type+length+value format. > > The DER format removes leading zeros from the number, then adds a > leading 0 bit to each number which is a sign bit (the numbers in an > ECDSA signature are always positive, but DER can also represent negative > numbers). Therefore each number has a roughly 1/2 chance of using 33 > value bytes with a leading 0 byte (1 sign bit + 7 value bits, all 0), a > 63/128 chance of using 32 value bytes, and a 1/128 chance of using 31 > value bytes or less because the 7 most significant bits of the number > were 0. A shorter number in an ECDSA signature is not invalid, it's a > 1/128 chance (independently for each of r and s). > > To get the signature in raw format with Mbed TLS, the easiest way is to > use the PSA API, where the output of psa_sign_hash() for ECDSA is the > raw format. With the classic Mbed TLS API, the easiest way is to call > mbedtls_ecdsa_sign() or mbedtls_ecdsa_sign_det_ext() to get r and s as > bignums, then use mbedtls_mpi_write_binary() to write r and s with their > exact size into the output buffer. You can find an example in the > internal function psa_ecdsa_sign(): > > https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/library/psa_crypto.c… > > Hope this helps, > > -- > Gilles Peskine > Mbed TLS developer > > On 22/11/2020 10:12, ROSHINI DEVI via mbed-tls wrote: > > Hello all, > > > > I need to sign the message using ES256 algorithm. After doing > > necessary initializations, I called API > > - mbedtls_ecdsa_write_signature() API and it gave me signature in ASN1 > > encoded form and there was no error generated by this API. > > After getting the signature, I need the r & s values to create JWT > > Token. So, I wrote my custom function to parse the signature buffer > > and get the R & S values of it. > > It was working fine. Sometimes, I am getting an invalid signature as > > shown below signature DER buffer - > > > > 30 43 02 1f 31 92 8d 22 10 41 86 25 68 7f 42 81 26 0f 37 bc 7f 38 b7 > > d5 1a 6b 69 31 07 34 11 a6 04 e5 90 02 20 23 26 f8 b9 80 cf 2c 25 c8 > > 04 b4 ac 43 51 6a 04 a6 af 8f 94 36 f8 cf 35 c2 94 cc df de db 92 b2 > > > > The reason for invalid is - > > 1st byte represents ASN1 sequence, followed by length and 3rd byter > > indicates it is an integer. > > Ideally, 4th byte indicates length of r-value, it should have been 32 > > or 33 bytes ( in case of padding with 00 ). You can see in the above > > buffer it is 0x1F ( 31 bytes ). It is really weird how it is possible > > to get the signature length of 31 bytes. > > > > It is blocking me for generation of JWT token, where in RFC 7518 > > - https://tools.ietf.org/html/rfc7518#page-9 , it says R & S must be > > 32 bytes long. And, the generation is failing. > > > > It is of high priority for me. If anyone can provide your suggestions > > on this issue, it would be really great. Thanks in advance > > > > Thanks, > > Roshini > > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

4 years, 5 months

1
0
0 0

-0x7180 - SSL - Verification of the message MAC failed

by Михаил Азанов

The SSL server is the one from the examples https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_server… It is configured on port 8080. The server runs on the linux operating system Linux commands give the following: uname -a Linux termv7 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux On the client side, the sim800 module is used. Log files attached to the email. File contents TermV-terminals-server.key: subject=/C=RU/ST=Sample/L=Sample/O=Sample/OU=Sample/CN=localhost issuer=/C=RU/ST=Sample/L=Sample/O=Sample/OU=Sample/CN=Sample -----BEGIN CERTIFICATE----- MIIDTjCCAjYCFBhhDBE3BeiTMD0dzFYOGILO8yq0MA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlJVMQ8wDQYDVQQIDAZTYW1wbGUxDzANBgNVBAcMBlNhbXBsZTEP MA0GA1UECgwGU2FtcGxlMQ8wDQYDVQQLDAZTYW1wbGUxDzANBgNVBAMMBlNhbXBs ZTAeFw0yMDAxMTgxODA5MDlaFw0yNDAxMTcxODA5MDlaMGUxCzAJBgNVBAYTAlJV MQ8wDQYDVQQIDAZTYW1wbGUxDzANBgNVBAcMBlNhbXBsZTEPMA0GA1UECgwGU2Ft cGxlMQ8wDQYDVQQLDAZTYW1wbGUxEjAQBgNVBAMMCWxvY2FsaG9zdDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQSjObDf16fv02qH+3FtI4eX2tPfj+u XsSF8KK6OpcNNfHv17LB9NRUGbZdeikvL5mjB1qd8Qt5YBzSYvvNmuQqn/ZZhEhg 9zqDd+j6dsl03OSW42qSP59M22plqhHZv1ZpkbpHSnEbbwbIVhgx1GuJvMHbQKxw et3UobG9M7q0/6Z2hlvbiuQgZWpc6+vnGGFUzVFjJhsUMgewU1UwTtfahOVegv9v ocuj+AOHzzH2+l72ybpKIFKZ6eXjr3sVp1lIPXm+gUNLqkReNV2QVk4H/j2ow3xu hdHjiPQ+6o6dgbCHeCvbf7Qs35S8YlQH/Mn2bik2NIMKucdq7S35AEsCAwEAATAN BgkqhkiG9w0BAQsFAAOCAQEAhANjStGtYfPJ2Ibkbn6ct4bWLPe6sFBvbwYow3Fd lBz0oxBukhJDOrPa4OqJDpnWenXkEcUrulI2JG5sIylOg3QlwlmgPoJU9fkpmr+u xNVlTxBSh1BVp0sccC+LxNRyDMl4C89R1TjPpPjoRU4cciY9N0oygPjTj0c26qBU iqwtyJTeeJYJUdplCMvXFOt8deqi/NBpBGnEfo8P/IeM/iCWLD5VtloHX/R0C+au q6803qd1/Gd0pIdsELQKrR6mBz6sWukg2f25GheLQVV7Wz/elZD8MwYwjYLoCtIP 65Ae3Eb6S2KlsVPzMj09u6kQ+KPfZtKu8tiUSc+11hurRw== -----END CERTIFICATE----- File contents TermV-terminals-server.crt: -----BEGIN PRIVATE KEY----- MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQC0Eozmw39en79N qh/txbSOHl9rT34/rl7EhfCiujqXDTXx79eywfTUVBm2XXopLy+ZowdanfELeWAc 0mL7zZrkKp/2WYRIYPc6g3fo+nbJdNzkluNqkj+fTNtqZaoR2b9WaZG6R0pxG28G yFYYMdRribzB20CscHrd1KGxvTO6tP+mdoZb24rkIGVqXOvr5xhhVM1RYyYbFDIH sFNVME7X2oTlXoL/b6HLo/gDh88x9vpe9sm6SiBSmenl4697FadZSD15voFDS6pE XjVdkFZOB/49qMN8boXR44j0PuqOnYGwh3gr23+0LN+UvGJUB/zJ9m4pNjSDCrnH au0t+QBLAgMBAAECggEBAKWbKdpQkSME53sVqqeR26uYY0jdos4OHzm9tMDzZE7m 52XJniXYGsHrVnpRHbginTQ+qtS7zKMwzSO0mTPas0iDqvl0+iNWighWQEETl4tO 3peb7Spltf1bQa9oMDCagU2HaW5Xgi7jfAhQ1l0J9sGvutjOO3xbNaQtmUdNKfXa VRaof94/YKcbTPIn588orxfumgeiYwQ8exhA7yg1WLl2iSy9jj+8WrxaKvy4vR45 nXrb2tXletRoZZY/FC/NZNMgXsGTmYHl6blTEZVz7Zu0XPHKJo42tHnKHW46/ccJ vkXQNjUsu0JN95+lWBA5Yne8xddhiLNKv3DZ3iwXRAECgYEA17YaIbtlgSLd5hJJ OuS9n9XNUCEx1YLhDRzhHggPNTZkVxSnxnWVGpbubtWN/OggRtJyk+mLFV+aHLCa R224ofSPWWE1HtoSdtLcL5oLgp6RDoM61h1p1glFS7BpbYzBegAcbMJa1IvAMspx 5lsYowBUJLNHAEcqUrXzQ88gu2ECgYEA1bRugqLGXqz1E0z6o/MuGXfmJaGQEmJg 833As5jzsyd6pyznsB0TKUAJkcf0RmZrr1EDVigA9aLcwq4qThjGEL2FpGkOvXPC bY0c2pLnsZJetNmXnky/w+W127V+LbDjjQaYl/7c9Fp4hoomoykt7d1YW7lRZ2Le wo8muiGF5ysCgYEAlYHahMysop926tJ7vPzzTMfT4JjRQGnQ79S3VqhBWiFT1GM1 kcDHUkGQCnOrUMHWNSABV/FDe9HiL8Zbd+xdTqsBe/J67eI5b+/fuoJrPeIHKebc rbB/PWD5jWc8+zfWlWdkTCE88RnXYZyc6wryfW9p4nH7YP7yH5eKftIdnqECgYBl aWY33/661uDF8/XM742k0F0K5oxz7PONGNPlZmPfVJDD3G9mB6YcISNpZrXo4pmf bJZkwD8UUeDpEbVJsj/rmcRdrO0twk01p41Vu/jvL0J6F/f3SvyFffC6/nmOPS7+ sW6gUnWQD466abzEGLqO8kcH3/1dTnHfagc6tMXSWQKBgQCZjWzyLtEUxvWI2PSe B6/osxlYDyCkXrJDIT1LuepM/54Kre9YMUy2UZBVC42DR6paEbkAAqHdTsLNlKhV s+6/JGnEDR1e/L7ks0dBY8jow04r0mKG1M91SMLr5OeBTk6SRMnR7GAKewjeLmJD ULgsqyHSTh/4r6tDQ7Gayci2vQ== -----END PRIVATE KEY----- Server sources: #include <stdio.h> /* * SSL server demonstration program * * Copyright The Mbed TLS Contributors * SPDX-License-Identifier: Apache-2.0 * * Licensed under the Apache License, Version 2.0 (the "License"); you may * not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ #if !defined(MBEDTLS_CONFIG_FILE) #include "mbedtls/config.h" #else #include MBEDTLS_CONFIG_FILE #endif #if defined(MBEDTLS_PLATFORM_C) #include "mbedtls/platform.h" #else #include <stdio.h> #include <stdlib.h> #define mbedtls_time time #define mbedtls_time_t time_t #define mbedtls_fprintf fprintf #define mbedtls_printf printf #define mbedtls_exit exit #define MBEDTLS_EXIT_SUCCESS EXIT_SUCCESS #define MBEDTLS_EXIT_FAILURE EXIT_FAILURE #endif #if !defined(MBEDTLS_BIGNUM_C) || !defined(MBEDTLS_CERTS_C) || \ !defined(MBEDTLS_ENTROPY_C) || !defined(MBEDTLS_SSL_TLS_C) || \ !defined(MBEDTLS_SSL_SRV_C) || !defined(MBEDTLS_NET_C) || \ !defined(MBEDTLS_RSA_C) || !defined(MBEDTLS_CTR_DRBG_C) || \ !defined(MBEDTLS_X509_CRT_PARSE_C) || !defined(MBEDTLS_FS_IO) || \ !defined(MBEDTLS_PEM_PARSE_C) int main( void ) { mbedtls_printf("MBEDTLS_BIGNUM_C and/or MBEDTLS_CERTS_C and/or MBEDTLS_ENTROPY_C " "and/or MBEDTLS_SSL_TLS_C and/or MBEDTLS_SSL_SRV_C and/or " "MBEDTLS_NET_C and/or MBEDTLS_RSA_C and/or " "MBEDTLS_CTR_DRBG_C and/or MBEDTLS_X509_CRT_PARSE_C " "and/or MBEDTLS_PEM_PARSE_C not defined.\n"); mbedtls_exit( 0 ); } #else #include <stdlib.h> #include <string.h> #if defined(_WIN32) #include <windows.h> #endif #include "mbedtls/entropy.h" #include "mbedtls/ctr_drbg.h" #include "mbedtls/certs.h" #include "mbedtls/x509.h" #include "mbedtls/ssl.h" #include "mbedtls/net_sockets.h" #include "mbedtls/error.h" #include "mbedtls/debug.h" #if defined(MBEDTLS_SSL_CACHE_C) #include "mbedtls/ssl_cache.h" #endif #define HTTP_RESPONSE \ "HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n" \ "<h2>mbed TLS Test Server</h2>\r\n" \ "<p>Successful connection using: %s</p>\r\n" #define DEBUG_LEVEL 5 static void my_debug( void *ctx, int level, const char *file, int line, const char *str ) { ((void) level); mbedtls_fprintf( (FILE *) ctx, "%s:%04d: %s", file, line, str ); fflush( (FILE *) ctx ); } int main( void ) { int ret, len; mbedtls_net_context listen_fd, client_fd; unsigned char buf[1024]; const char *pers = "ssl_server"; mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; mbedtls_ssl_context ssl; mbedtls_ssl_config conf; mbedtls_x509_crt srvcert; mbedtls_pk_context pkey; #if defined(MBEDTLS_SSL_CACHE_C) mbedtls_ssl_cache_context cache; #endif mbedtls_net_init( &listen_fd ); mbedtls_net_init( &client_fd ); mbedtls_ssl_init( &ssl ); mbedtls_ssl_config_init( &conf ); #if defined(MBEDTLS_SSL_CACHE_C) mbedtls_ssl_cache_init( &cache ); #endif mbedtls_x509_crt_init( &srvcert ); mbedtls_pk_init( &pkey ); mbedtls_entropy_init( &entropy ); mbedtls_ctr_drbg_init( &ctr_drbg ); #if defined(MBEDTLS_DEBUG_C) mbedtls_debug_set_threshold( DEBUG_LEVEL ); #endif /* * 1. Load the certificates and private RSA key */ mbedtls_printf( "\n . Loading the server cert. and key..." ); fflush( stdout ); /* * This demonstration program uses embedded test certificates. * Instead, you may want to use mbedtls_x509_crt_parse_file() to read the * server and CA certificates, as well as mbedtls_pk_parse_keyfile(). */ ret = mbedtls_x509_crt_parse_file( &srvcert,"/etc/minpay/cert/TermV-terminals-server.crt"); if( ret != 0 ) { mbedtls_printf( " failed\n ! mbedtls_x509_crt_parse returned %d\n\n", ret ); goto exit; } ret = mbedtls_pk_parse_keyfile( &pkey,"/etc/minpay/cert/TermV-terminals-server.key", NULL ); if( ret != 0 ) { mbedtls_printf( " failed\n ! mbedtls_x509_crt_parse returned %d\n\n", ret ); goto exit; } mbedtls_printf( " ok\n" ); /* * 2. Setup the listening TCP socket */ mbedtls_printf( " . Bind on https://localhost:8080/ ..." ); fflush( stdout ); if( ( ret = mbedtls_net_bind( &listen_fd, NULL, "8080", MBEDTLS_NET_PROTO_TCP ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_net_bind returned %d\n\n", ret ); goto exit; } mbedtls_printf( " ok\n" ); /* * 3. Seed the RNG */ mbedtls_printf( " . Seeding the random number generator..." ); fflush( stdout ); if( ( ret = mbedtls_ctr_drbg_seed( &ctr_drbg, mbedtls_entropy_func, &entropy, (const unsigned char *) pers, strlen( pers ) ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_ctr_drbg_seed returned %d\n", ret ); goto exit; } mbedtls_printf( " ok\n" ); /* * 4. Setup stuff */ mbedtls_printf( " . Setting up the SSL data...." ); fflush( stdout ); if( ( ret = mbedtls_ssl_config_defaults( &conf, MBEDTLS_SSL_IS_SERVER, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_ssl_config_defaults returned %d\n\n", ret ); goto exit; } mbedtls_ssl_conf_rng( &conf, mbedtls_ctr_drbg_random, &ctr_drbg ); mbedtls_ssl_conf_dbg( &conf, my_debug, stdout ); #if defined(MBEDTLS_SSL_CACHE_C) mbedtls_ssl_conf_session_cache( &conf, &cache, mbedtls_ssl_cache_get, mbedtls_ssl_cache_set ); #endif mbedtls_ssl_conf_ca_chain( &conf, srvcert.next, NULL ); if( ( ret = mbedtls_ssl_conf_own_cert( &conf, &srvcert, &pkey ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_ssl_conf_own_cert returned %d\n\n", ret ); goto exit; } if( ( ret = mbedtls_ssl_setup( &ssl, &conf ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_ssl_setup returned %d\n\n", ret ); goto exit; } mbedtls_printf( " ok\n" ); reset: #ifdef MBEDTLS_ERROR_C if( ret != 0 ) { char error_buf[100]; mbedtls_strerror( ret, error_buf, 100 ); mbedtls_printf("Last error was: %d - %s\n\n", ret, error_buf ); } #endif mbedtls_net_free( &client_fd ); mbedtls_ssl_session_reset( &ssl ); /* * 3. Wait until a client connects */ mbedtls_printf( " . Waiting for a remote connection ..." ); fflush( stdout ); if( ( ret = mbedtls_net_accept( &listen_fd, &client_fd, NULL, 0, NULL ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_net_accept returned %d\n\n", ret ); goto exit; } mbedtls_ssl_set_bio( &ssl, &client_fd, mbedtls_net_send, mbedtls_net_recv, NULL ); mbedtls_printf( " ok\n" ); /* * 5. Handshake */ mbedtls_printf( " . Performing the SSL/TLS handshake..." ); fflush( stdout ); while( ( ret = mbedtls_ssl_handshake( &ssl ) ) != 0 ) { if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { mbedtls_printf( " failed\n ! mbedtls_ssl_handshake returned %d\n\n", ret ); goto reset; } } mbedtls_printf( " ok\n" ); /* * 6. Read the HTTP Request */ mbedtls_printf( " < Read from client:" ); fflush( stdout ); do { len = sizeof( buf ) - 1; memset( buf, 0, sizeof( buf ) ); ret = mbedtls_ssl_read( &ssl, buf, len ); if( ret == MBEDTLS_ERR_SSL_WANT_READ || ret == MBEDTLS_ERR_SSL_WANT_WRITE ) continue; if( ret <= 0 ) { switch( ret ) { case MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY: mbedtls_printf( " connection was closed gracefully\n" ); break; case MBEDTLS_ERR_NET_CONN_RESET: mbedtls_printf( " connection was reset by peer\n" ); break; default: mbedtls_printf( " mbedtls_ssl_read returned -0x%x\n", (unsigned int) -ret ); break; } break; } len = ret; mbedtls_printf( " %d bytes read\n\n%s", len, (char *) buf ); if( ret > 0 ) break; } while( 1 ); /* * 7. Write the 200 Response */ mbedtls_printf( " > Write to client:" ); fflush( stdout ); len = sprintf( (char *) buf, HTTP_RESPONSE, mbedtls_ssl_get_ciphersuite( &ssl ) ); while( ( ret = mbedtls_ssl_write( &ssl, buf, len ) ) <= 0 ) { if( ret == MBEDTLS_ERR_NET_CONN_RESET ) { mbedtls_printf( " failed\n ! peer closed the connection\n\n" ); goto reset; } if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { mbedtls_printf( " failed\n ! mbedtls_ssl_write returned %d\n\n", ret ); goto exit; } } len = ret; mbedtls_printf( " %d bytes written\n\n%s\n", len, (char *) buf ); mbedtls_printf( " . Closing the connection..." ); while( ( ret = mbedtls_ssl_close_notify( &ssl ) ) < 0 ) { if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { mbedtls_printf( " failed\n ! mbedtls_ssl_close_notify returned %d\n\n", ret ); goto reset; } } mbedtls_printf( " ok\n" ); ret = 0; goto reset; exit: #ifdef MBEDTLS_ERROR_C if( ret != 0 ) { char error_buf[100]; mbedtls_strerror( ret, error_buf, 100 ); mbedtls_printf("Last error was: %d - %s\n\n", ret, error_buf ); } #endif mbedtls_net_free( &client_fd ); mbedtls_net_free( &listen_fd ); mbedtls_x509_crt_free( &srvcert ); mbedtls_pk_free( &pkey ); mbedtls_ssl_free( &ssl ); mbedtls_ssl_config_free( &conf ); #if defined(MBEDTLS_SSL_CACHE_C) mbedtls_ssl_cache_free( &cache ); #endif mbedtls_ctr_drbg_free( &ctr_drbg ); mbedtls_entropy_free( &entropy ); #if defined(_WIN32) mbedtls_printf( " Press Enter to exit this program.\n" ); fflush( stdout ); getchar(); #endif mbedtls_exit( ret ); } #endif /* MBEDTLS_BIGNUM_C && MBEDTLS_CERTS_C && MBEDTLS_ENTROPY_C && MBEDTLS_SSL_TLS_C && MBEDTLS_SSL_SRV_C && MBEDTLS_NET_C && MBEDTLS_RSA_C && MBEDTLS_CTR_DRBG_C && MBEDTLS_X509_CRT_PARSE_C && MBEDTLS_FS_IO && MBEDTLS_PEM_PARSE_C */ Regards, Michael.

4 years, 5 months

1
0
0 0

Re: [mbed-tls] -0x7180 - SSL - Verification of the message MAC failed

by Manuel Pegourie-Gonnard

Hi Michael, I'm not sure I understand what library/program you're using on each side: you posted the source code of a server based on Mbed TLS, and an invocation of openssl as a server - 2 servers and no client, surely that's not your entire setup. Also, even with the full details, this is a considerable amount of things to go over, so instead of trying to pinpoint the issue, I'd like to suggest a strategy that would help you debug things. For the side of the connection that's based on Mbed TLS, I suggest you start with one of the example programs located in programs/ssl? in our source tree. Hopefully those should work. If they don't, please come back to us with details on how you're invoking them and what's on the other side. If they work, I suggest you gradually modify them to adapt them to your needs, and after each change check if things still work. That way, if things break at one point, it should be easier to pinpoint the source of the issue. Hope that will help! Regards, Manuel. PS: I had a quick look at the logs, and I'm not sure what software is on the client side, but its ClientHello.random doesn't look random. Also, the location of the errors suggests the the client and server didn't compute the same session keys - so something probably went wrong computing the pre-master secret or deriving the master secret and session keys from it. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Михаил Азанов via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 21 November 2020 05:17 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] -0x7180 - SSL - Verification of the message MAC failed Clients connect to my server over SSL and an error "-0x7180 - SSL - Verification of the message MAC failed" occurs when creating a secure connection. Linux commands give the following: uname -a Linux termv7 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux openssl s_server -key /etc/minpay/cert/TermV-terminals-server.key -cert /etc/minpay/cert/TermV-terminals-server.crt -accept 8080 -state Using default temp DH parameters ACCEPT SSL_accept:before SSL initialization SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS read client hello SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write certificate SSL_accept:SSLv3/TLS write server done SSL_accept:SSLv3/TLS write server done SSL_accept:SSLv3/TLS read client key exchange SSL_accept:SSLv3/TLS read change cipher spec SSL_accept:SSLv3/TLS read finished SSL_accept:SSLv3/TLS write change cipher spec SSL_accept:SSLv3/TLS write finished -----BEGIN SSL SESSION PARAMETERS----- MHUCAQECAgMBBAIALwQgNbcRsh26hMujwXcoa5ZlBGihMY+GFhkTscR4Ds8fppwE MHAJs/h2ldK+C7Sm2fpNGbzYMycfUPGq4Ydg9PtnHPt1Mn9eH68tnQsT2nuTwGRq zqEGAgRftlMXogQCAhwgpAYEBAEAAAA= -----END SSL SESSION PARAMETERS----- Shared ciphers:AES128-SHA --- No server certificate CA names sent CIPHER is AES128-SHA Secure Renegotiation IS NOT supported Source content: File contents TermV-terminals-server.key: subject=/C=RU/ST=Sample/L=Sample/O=Sample/OU=Sample/CN=localhost issuer=/C=RU/ST=Sample/L=Sample/O=Sample/OU=Sample/CN=Sample -----BEGIN CERTIFICATE----- MIIDTjCCAjYCFBhhDBE3BeiTMD0dzFYOGILO8yq0MA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlJVMQ8wDQYDVQQIDAZTYW1wbGUxDzANBgNVBAcMBlNhbXBsZTEP MA0GA1UECgwGU2FtcGxlMQ8wDQYDVQQLDAZTYW1wbGUxDzANBgNVBAMMBlNhbXBs ZTAeFw0yMDAxMTgxODA5MDlaFw0yNDAxMTcxODA5MDlaMGUxCzAJBgNVBAYTAlJV MQ8wDQYDVQQIDAZTYW1wbGUxDzANBgNVBAcMBlNhbXBsZTEPMA0GA1UECgwGU2Ft cGxlMQ8wDQYDVQQLDAZTYW1wbGUxEjAQBgNVBAMMCWxvY2FsaG9zdDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQSjObDf16fv02qH+3FtI4eX2tPfj+u XsSF8KK6OpcNNfHv17LB9NRUGbZdeikvL5mjB1qd8Qt5YBzSYvvNmuQqn/ZZhEhg 9zqDd+j6dsl03OSW42qSP59M22plqhHZv1ZpkbpHSnEbbwbIVhgx1GuJvMHbQKxw et3UobG9M7q0/6Z2hlvbiuQgZWpc6+vnGGFUzVFjJhsUMgewU1UwTtfahOVegv9v ocuj+AOHzzH2+l72ybpKIFKZ6eXjr3sVp1lIPXm+gUNLqkReNV2QVk4H/j2ow3xu hdHjiPQ+6o6dgbCHeCvbf7Qs35S8YlQH/Mn2bik2NIMKucdq7S35AEsCAwEAATAN BgkqhkiG9w0BAQsFAAOCAQEAhANjStGtYfPJ2Ibkbn6ct4bWLPe6sFBvbwYow3Fd lBz0oxBukhJDOrPa4OqJDpnWenXkEcUrulI2JG5sIylOg3QlwlmgPoJU9fkpmr+u xNVlTxBSh1BVp0sccC+LxNRyDMl4C89R1TjPpPjoRU4cciY9N0oygPjTj0c26qBU iqwtyJTeeJYJUdplCMvXFOt8deqi/NBpBGnEfo8P/IeM/iCWLD5VtloHX/R0C+au q6803qd1/Gd0pIdsELQKrR6mBz6sWukg2f25GheLQVV7Wz/elZD8MwYwjYLoCtIP 65Ae3Eb6S2KlsVPzMj09u6kQ+KPfZtKu8tiUSc+11hurRw== -----END CERTIFICATE----- File contents TermV-terminals-server.crt: -----BEGIN PRIVATE KEY----- MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQC0Eozmw39en79N qh/txbSOHl9rT34/rl7EhfCiujqXDTXx79eywfTUVBm2XXopLy+ZowdanfELeWAc 0mL7zZrkKp/2WYRIYPc6g3fo+nbJdNzkluNqkj+fTNtqZaoR2b9WaZG6R0pxG28G yFYYMdRribzB20CscHrd1KGxvTO6tP+mdoZb24rkIGVqXOvr5xhhVM1RYyYbFDIH sFNVME7X2oTlXoL/b6HLo/gDh88x9vpe9sm6SiBSmenl4697FadZSD15voFDS6pE XjVdkFZOB/49qMN8boXR44j0PuqOnYGwh3gr23+0LN+UvGJUB/zJ9m4pNjSDCrnH au0t+QBLAgMBAAECggEBAKWbKdpQkSME53sVqqeR26uYY0jdos4OHzm9tMDzZE7m 52XJniXYGsHrVnpRHbginTQ+qtS7zKMwzSO0mTPas0iDqvl0+iNWighWQEETl4tO 3peb7Spltf1bQa9oMDCagU2HaW5Xgi7jfAhQ1l0J9sGvutjOO3xbNaQtmUdNKfXa VRaof94/YKcbTPIn588orxfumgeiYwQ8exhA7yg1WLl2iSy9jj+8WrxaKvy4vR45 nXrb2tXletRoZZY/FC/NZNMgXsGTmYHl6blTEZVz7Zu0XPHKJo42tHnKHW46/ccJ vkXQNjUsu0JN95+lWBA5Yne8xddhiLNKv3DZ3iwXRAECgYEA17YaIbtlgSLd5hJJ OuS9n9XNUCEx1YLhDRzhHggPNTZkVxSnxnWVGpbubtWN/OggRtJyk+mLFV+aHLCa R224ofSPWWE1HtoSdtLcL5oLgp6RDoM61h1p1glFS7BpbYzBegAcbMJa1IvAMspx 5lsYowBUJLNHAEcqUrXzQ88gu2ECgYEA1bRugqLGXqz1E0z6o/MuGXfmJaGQEmJg 833As5jzsyd6pyznsB0TKUAJkcf0RmZrr1EDVigA9aLcwq4qThjGEL2FpGkOvXPC bY0c2pLnsZJetNmXnky/w+W127V+LbDjjQaYl/7c9Fp4hoomoykt7d1YW7lRZ2Le wo8muiGF5ysCgYEAlYHahMysop926tJ7vPzzTMfT4JjRQGnQ79S3VqhBWiFT1GM1 kcDHUkGQCnOrUMHWNSABV/FDe9HiL8Zbd+xdTqsBe/J67eI5b+/fuoJrPeIHKebc rbB/PWD5jWc8+zfWlWdkTCE88RnXYZyc6wryfW9p4nH7YP7yH5eKftIdnqECgYBl aWY33/661uDF8/XM742k0F0K5oxz7PONGNPlZmPfVJDD3G9mB6YcISNpZrXo4pmf bJZkwD8UUeDpEbVJsj/rmcRdrO0twk01p41Vu/jvL0J6F/f3SvyFffC6/nmOPS7+ sW6gUnWQD466abzEGLqO8kcH3/1dTnHfagc6tMXSWQKBgQCZjWzyLtEUxvWI2PSe B6/osxlYDyCkXrJDIT1LuepM/54Kre9YMUy2UZBVC42DR6paEbkAAqHdTsLNlKhV s+6/JGnEDR1e/L7ks0dBY8jow04r0mKG1M91SMLr5OeBTk6SRMnR7GAKewjeLmJD ULgsqyHSTh/4r6tDQ7Gayci2vQ== -----END PRIVATE KEY----- File contents ssl_server.h: #ifndef SSL_SERVER_H #define SSL_SERVER_H #define DEBUG_LEVEL 5 #if DEBUG_LEVEL > 0 #include "mbedtls/debug.h" #endif //#define MBEDTLS_SSL_CIPHERSUITES MBEDTLS_TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 #include "mbedtls/entropy.h" #include "mbedtls/ctr_drbg.h" #include "mbedtls/certs.h" #include "mbedtls/x509.h" #include "mbedtls/ssl.h" #include "mbedtls/net_sockets.h" #include "mbedtls/error.h" #include "mbedtls/ssl_cache.h" #include "packet_handler/packet_handler.h" #include "thread_pool_ssl.h" #include "queue_ssl.h" extern pthread_mutex_t listen_fd1_mutex; extern mbedtls_net_context listen_fd1; extern void* runSSLServer(void *arg); #endif // SSL_SERVER_H File contents ssl_server.c: #include "ssl_server.h" mbedtls_net_context listen_fd1; pthread_mutex_t listen_fd1_mutex=PTHREAD_MUTEX_INITIALIZER; static mbedtls_ssl_config *config; #if DEBUG_LEVEL > 0 static void my_debug( void *ctx, int level, const char *file, int line, const char *str ) { ((void) level); char s[1000]; snprintf(s,sizeof(s),"%s:%04d: %s", file, line, str ); trace(s); } #endif void * runSSLServer(void *arg) { (void)(arg); int ret; char s[100]; int n = atoi(config_list[SSL_SERVER_NUM_THREADS].value); createThreadPoolSSLArray(n); mbedtls_net_context listen_fd, client_socket_ssl; const char pers[] = "ssl_pthread_server"; mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; mbedtls_ssl_config conf; mbedtls_x509_crt srvcert; mbedtls_x509_crt cachain; mbedtls_pk_context pkey; mbedtls_ssl_cache_context cache; mbedtls_ssl_cache_init( &cache ); mbedtls_x509_crt_init( &srvcert ); mbedtls_x509_crt_init( &cachain ); mbedtls_ssl_config_init( &conf ); mbedtls_ctr_drbg_init( &ctr_drbg ); mbedtls_net_init( &listen_fd ); mbedtls_net_init( &client_socket_ssl ); config = &conf; /* * We use only a single entropy source that is used in all the threads. */ mbedtls_entropy_init( &entropy ); #if DEBUG_LEVEL > 0 mbedtls_debug_set_threshold(DEBUG_LEVEL); #endif /* * 1. Load the certificates and private RSA key */ trace( "[SSL Server] Loading the server cert. and key..." ); ret = mbedtls_x509_crt_parse_file( &srvcert,"/etc/minpay/cert/TermV-terminals-server.crt"); if( ret != 0 ) { snprintf(s,sizeof(s), "[SSL Server] failed\n ! mbedtls_x509_crt_parse_file returned %d\n\n", ret ); trace(s); goto thread_exit; } mbedtls_pk_init( &pkey ); ret = mbedtls_pk_parse_keyfile( &pkey,"/etc/minpay/cert/TermV-terminals-server.key" , NULL ); if( ret != 0 ) { snprintf(s,sizeof(s), "[SSL Server] failed\n ! mbedtls_pk_parse_keyfile returned %d\n\n", ret ); trace(s); goto thread_exit; } trace( "[SSL Server] ok\n" ); /* * 1b. Seed the random number generator */ trace( "Seeding the random number generator..." ); if( ( ret = mbedtls_ctr_drbg_seed( &ctr_drbg, mbedtls_entropy_func, &entropy, (const unsigned char *) pers, strlen( pers ) ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL Server] failed: mbedtls_ctr_drbg_seed returned -0x%04x\n", -ret ); trace(s); goto thread_exit; } trace( "[SSL Server] ok\n" ); /* * 1c. Prepare SSL configuration */ trace( "[SSL Server] Setting up the SSL data...." ); if( ( ret = mbedtls_ssl_config_defaults( &conf, MBEDTLS_SSL_IS_SERVER, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL Server] failed: mbedtls_ssl_config_defaults returned -0x%04x\n", -ret ); trace(s); goto thread_exit; } mbedtls_ssl_conf_rng( &conf, mbedtls_ctr_drbg_random, &ctr_drbg ); #if DEBUG_LEVEL > 0 mbedtls_ssl_conf_dbg( &conf, my_debug, NULL ); #endif /* mbedtls_ssl_cache_get() and mbedtls_ssl_cache_set() are thread-safe if * MBEDTLS_THREADING_C is set. */ mbedtls_ssl_conf_session_cache( &conf, &cache, mbedtls_ssl_cache_get, mbedtls_ssl_cache_set ); mbedtls_ssl_conf_ca_chain( &conf, &cachain, NULL ); if( ( ret = mbedtls_ssl_conf_own_cert( &conf, &srvcert, &pkey ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL Server] failed\n ! mbedtls_ssl_conf_own_cert returned %d\n\n", ret ); trace(s); goto thread_exit; } trace( "[SSL Server] ok\n" ); /* * 2. Setup the listening TCP socket */ snprintf(s,sizeof(s),"[SSL Server] Bind on localhost: %s ...","8080"); trace(s); fflush( stdout ); if( ( ret = mbedtls_net_bind( &listen_fd, NULL, "8080", MBEDTLS_NET_PROTO_TCP ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL Server] failed\n ! mbedtls_net_bind returned %d\n\n", ret ); trace(s); goto thread_exit; } trace( "[SSL Server] ok\n" ); pthread_mutex_lock(&listen_fd1_mutex); listen_fd1 = listen_fd; pthread_mutex_unlock(&listen_fd1_mutex); while(true) { //reset: if(ret!=0) { char error_buf[100]; mbedtls_strerror( ret, error_buf, 100 ); snprintf(s,sizeof(s),"[SSL Server] Last error was: -0x%04x - %s\n", -ret, error_buf ); trace(s); } /* * 3. Wait until a client connects */ trace( "[SSL Server] Waiting for a remote connection\n" ); int ret =mbedtls_net_accept(&listen_fd,&client_socket_ssl,NULL,0,NULL); if(ret != 0) { snprintf(s,sizeof(s), "[SSL Server] failed: mbedtls_net_accept returned -0x%04x\n", ret); trace(s); break; } trace( "[SSL Server] ok\n" ); //do whatever we do with connections. //put the connection somewhere so that an available thread //can find it. mbedtls_net_context *pclient = malloc(sizeof(mbedtls_net_context)); *pclient = client_socket_ssl; pthread_mutex_lock(&client_socket_ssl_mutex); enqueue_ssl(pclient); pthread_cond_signal(&condition_var_ssl); pthread_mutex_unlock(&client_socket_ssl_mutex); ret = 0; } thread_exit: mbedtls_x509_crt_free( &srvcert ); mbedtls_pk_free( &pkey ); mbedtls_ssl_cache_free( &cache ); mbedtls_ctr_drbg_free( &ctr_drbg ); mbedtls_entropy_free( &entropy ); mbedtls_ssl_config_free( &conf ); mbedtls_net_free( &listen_fd ); deleteThreadPoolSSLArray(); return NULL; } static void *handleConnectionSSL(mbedtls_net_context *p_net_context) { int ret, len; char s[100]; struct packet_handler handler={}; handler.net_context = *p_net_context; free(p_net_context);// we really don't need this anymore unsigned char buf[1024]; /* Make sure memory references are valid */ mbedtls_ssl_init( &handler.ssl ); snprintf(s,sizeof(s),"[SSL client_socket=%d] Setting up SSL/TLS data\n", handler.net_context.fd ); trace(s); /* * 4. Get the SSL context ready */ if( ( ret = mbedtls_ssl_setup( &handler.ssl, config ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL client_socket=%d] failed: mbedtls_ssl_setup returned -0x%04x\n",handler.net_context.fd, -ret ); trace(s); goto thread_exit; } mbedtls_ssl_set_bio( &handler.ssl, (mbedtls_net_context*)&handler.net_context, mbedtls_net_send, mbedtls_net_recv, NULL ); /* * 5. Handshake */ snprintf(s,sizeof(s),"[SSL client_socket=%d] Performing the SSL/TLS handshake\n", handler.net_context.fd); trace(s); while( ( ret = mbedtls_ssl_handshake( &handler.ssl ) ) != 0 ) { if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { snprintf(s,sizeof(s),"[SSL client_socket=%d] failed: mbedtls_ssl_handshake returned -0x%04x\n", handler.net_context.fd, -ret ); trace(s); goto thread_exit; } } snprintf(s,sizeof(s),"[SSL client_socket=%d] ok\n", handler.net_context.fd ); trace(s); ret = runPacketHandler(&handler); snprintf(s,sizeof(s), "[SSL client_socket=%d] . Closing the connection...", handler.net_context.fd ); trace(s); while( ( ret = mbedtls_ssl_close_notify( &handler.ssl ) ) < 0 ) { if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { snprintf(s,sizeof(s), "[SSL client_socket=%d] failed: mbedtls_ssl_close_notify returned -0x%04x\n", handler.net_context.fd, ret); trace(s); goto thread_exit; } } trace( " ok\n" ); ret = 0; thread_exit: if( ret != 0 ) { char error_buf[100]; mbedtls_strerror( ret, error_buf, 100 ); snprintf(s,sizeof(s), "[SSL client_socket=%d] Last error was: -0x%04x - %s\n\n", handler.net_context.fd, -ret, error_buf ); trace(s); } mbedtls_net_free((mbedtls_net_context*)&handler.net_context); mbedtls_ssl_free(&handler.ssl); return NULL; } void *threadFunctionSSL(void *arg) { (void)(arg); while(true) { mbedtls_net_context *pclient; pthread_mutex_lock(&client_socket_ssl_mutex); if((pclient=dequeue_ssl())==NULL) { pthread_cond_wait((pthread_cond_t *)&pclient,&client_socket_ssl_mutex); //try again pclient = dequeue_ssl(); } pthread_mutex_unlock(&client_socket_ssl_mutex); if(pclient!=NULL) { //we have a connection handleConnectionSSL(pclient); } } } File contents thread_pool_ssl.h: #ifndef SSL_THREAD_POOL_H #define SSL_THREAD_POOL_H #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdbool.h> #include <pthread.h> #include "mbedtls/net_sockets.h" extern pthread_t *thread_pool_ssl; extern pthread_mutex_t client_socket_ssl_mutex; extern pthread_cond_t condition_var_ssl; void createThreadPoolSSLArray(int n); void deleteThreadPoolSSLArray(); extern void *handleSSLConnection(int* p_client_socket); extern void *threadFunctionSSL(void *arg); #endif // SSL_THREAD_POOL_H File contents thread_pool_ssl.c: #include "thread_pool_ssl.h" pthread_t *thread_pool_ssl=NULL; pthread_mutex_t client_socket_ssl_mutex = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t condition_var_ssl = PTHREAD_COND_INITIALIZER; void *threadFunctionSSL(void *arg); void createThreadPoolSSLArray(int n) { thread_pool_ssl = (pthread_t*)malloc(n); //first off create a bunch of threads to handle future connections for(int i=0; i<n;i++) { pthread_create(&thread_pool_ssl[i],NULL,threadFunctionSSL,NULL); } } void deleteThreadPoolSSLArray() { free(thread_pool_ssl); } File contents main.c: #include <stdio.h> #include "log.h" #include "ssl_server.h" #include <signal.h> void catchSigterm(); void catchSigint(); void runPortListening(); int main() { catchSigterm(); catchSigint(); runPortListening(); return 0; } void runPortListening() { trace("Starting port listening..."); pthread_t handleID; pthread_create(&handleID,NULL,runSSLServer,NULL); trace("Port listening started."); pthread_join(handleID,NULL); trace("Port listening complete."); } void closeServer() { trace("Shutdown SSL Server..."); pthread_mutex_lock(&listen_fd1_mutex); mbedtls_net_free(&listen_fd1); pthread_mutex_unlock(&listen_fd1_mutex); } void sigTermHandler(int signum, siginfo_t *info, void *ptr) { (void)signum; (void)info; (void)ptr; closeServer(); } void catchSigterm() { static struct sigaction _sigact; memset(&_sigact, 0, sizeof(_sigact)); _sigact.sa_sigaction = sigTermHandler; _sigact.sa_flags = SA_SIGINFO; sigaction(SIGTERM, &_sigact, NULL); } void sigIntHandler(int signum, siginfo_t *info, void *ptr) { (void)signum; (void)info; (void)ptr; closeServer(); } void catchSigint() { static struct sigaction _sigact; memset(&_sigact, 0, sizeof(_sigact)); _sigact.sa_sigaction = sigIntHandler; _sigact.sa_flags = SA_SIGINFO; sigaction(SIGINT, &_sigact, NULL); } Log files attached to the email. Regards, Michael.

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Provide a crypto utility to verify mbedtls quickly

by Sawyer Liu

Hello everyone, Due to the pic link, cannot download the tool. I attach the link again. http://esctech.cn/wp-content/uploads/2020/04/Crypto%20UtilityV2.0.zip Best Regards Sawyer Liu

4 years, 5 months

1
0
0 0

Provide a crypto utility to verify mbedtls quickly

by Sawyer Liu

Hello everyone, I found many people need to verify the result of mbedtls, so I can provide a tool to help more people to verify their own code quickly. See http://esctech.cn/wp-content/uploads/2020/04/Crypto%20UtilityV2.0.zip<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fesctech.cn…>. [cid:image001.jpg@01D6C1C0.7C525360] Best Regards Sawyer Liu

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Invalid ECDSA signature created

by Gilles Peskine

Hi Roshini, Mathematically, an ES256 (ECDSA over the curve P256R1) signature is a pair of numbers (r,s) between 1 and an upper bound which is very slightly less than 2^256. There are two common representations for this signature. JWA uses the “raw” representation: two big-endian numbers represented each with exactly 32 bytes, concatenated together. mbedtls_ecdsa_write_signature uses the ASN.1 DER representation, which as you noticed represents each number in a type+length+value format. The DER format removes leading zeros from the number, then adds a leading 0 bit to each number which is a sign bit (the numbers in an ECDSA signature are always positive, but DER can also represent negative numbers). Therefore each number has a roughly 1/2 chance of using 33 value bytes with a leading 0 byte (1 sign bit + 7 value bits, all 0), a 63/128 chance of using 32 value bytes, and a 1/128 chance of using 31 value bytes or less because the 7 most significant bits of the number were 0. A shorter number in an ECDSA signature is not invalid, it's a 1/128 chance (independently for each of r and s). To get the signature in raw format with Mbed TLS, the easiest way is to use the PSA API, where the output of psa_sign_hash() for ECDSA is the raw format. With the classic Mbed TLS API, the easiest way is to call mbedtls_ecdsa_sign() or mbedtls_ecdsa_sign_det_ext() to get r and s as bignums, then use mbedtls_mpi_write_binary() to write r and s with their exact size into the output buffer. You can find an example in the internal function psa_ecdsa_sign(): https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/library/psa_crypto.c… Hope this helps, -- Gilles Peskine Mbed TLS developer On 22/11/2020 10:12, ROSHINI DEVI via mbed-tls wrote: > Hello all, > > I need to sign the message using ES256 algorithm. After doing > necessary initializations, I called API > - mbedtls_ecdsa_write_signature() API and it gave me signature in ASN1 > encoded form and there was no error generated by this API. > After getting the signature, I need the r & s values to create JWT > Token. So, I wrote my custom function to parse the signature buffer > and get the R & S values of it. > It was working fine. Sometimes, I am getting an invalid signature as > shown below signature DER buffer - > > 30 43 02 1f 31 92 8d 22 10 41 86 25 68 7f 42 81 26 0f 37 bc 7f 38 b7 > d5 1a 6b 69 31 07 34 11 a6 04 e5 90 02 20 23 26 f8 b9 80 cf 2c 25 c8 > 04 b4 ac 43 51 6a 04 a6 af 8f 94 36 f8 cf 35 c2 94 cc df de db 92 b2 > > The reason for invalid is - > 1st byte represents ASN1 sequence, followed by length and 3rd byter > indicates it is an integer. > Ideally, 4th byte indicates length of r-value, it should have been 32 > or 33 bytes ( in case of padding with 00 ). You can see in the above > buffer it is 0x1F ( 31 bytes ). It is really weird how it is possible > to get the signature length of 31 bytes. > > It is blocking me for generation of JWT token, where in RFC 7518 > - https://tools.ietf.org/html/rfc7518#page-9 , it says R & S must be > 32 bytes long. And, the generation is failing. > > It is of high priority for me. If anyone can provide your suggestions > on this issue, it would be really great. Thanks in advance > > Thanks, > Roshini >

4 years, 5 months

1
0
0 0

Invalid ECDSA signature created

by ROSHINI DEVI

Hello all, I need to sign the message using ES256 algorithm. After doing necessary initializations, I called API - mbedtls_ecdsa_write_signature() API and it gave me signature in ASN1 encoded form and there was no error generated by this API. After getting the signature, I need the r & s values to create JWT Token. So, I wrote my custom function to parse the signature buffer and get the R & S values of it. It was working fine. Sometimes, I am getting an invalid signature as shown below signature DER buffer - 30 43 02 1f 31 92 8d 22 10 41 86 25 68 7f 42 81 26 0f 37 bc 7f 38 b7 d5 1a 6b 69 31 07 34 11 a6 04 e5 90 02 20 23 26 f8 b9 80 cf 2c 25 c8 04 b4 ac 43 51 6a 04 a6 af 8f 94 36 f8 cf 35 c2 94 cc df de db 92 b2 The reason for invalid is - 1st byte represents ASN1 sequence, followed by length and 3rd byter indicates it is an integer. Ideally, 4th byte indicates length of r-value, it should have been 32 or 33 bytes ( in case of padding with 00 ). You can see in the above buffer it is 0x1F ( 31 bytes ). It is really weird how it is possible to get the signature length of 31 bytes. It is blocking me for generation of JWT token, where in RFC 7518 - https://tools.ietf.org/html/rfc7518#page-9 , it says R & S must be 32 bytes long. And, the generation is failing. It is of high priority for me. If anyone can provide your suggestions on this issue, it would be really great. Thanks in advance Thanks, Roshini

4 years, 5 months

1
0
0 0

-0x7180 - SSL - Verification of the message MAC failed

by Михаил Азанов

Clients connect to my server over SSL and an error "-0x7180 - SSL - Verification of the message MAC failed" occurs when creating a secure connection. Linux commands give the following: uname -a Linux termv7 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux openssl s_server -key /etc/minpay/cert/TermV-terminals-server.key -cert /etc/minpay/cert/TermV-terminals-server.crt -accept 8080 -state Using default temp DH parameters ACCEPT SSL_accept:before SSL initialization SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS read client hello SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write certificate SSL_accept:SSLv3/TLS write server done SSL_accept:SSLv3/TLS write server done SSL_accept:SSLv3/TLS read client key exchange SSL_accept:SSLv3/TLS read change cipher spec SSL_accept:SSLv3/TLS read finished SSL_accept:SSLv3/TLS write change cipher spec SSL_accept:SSLv3/TLS write finished -----BEGIN SSL SESSION PARAMETERS----- MHUCAQECAgMBBAIALwQgNbcRsh26hMujwXcoa5ZlBGihMY+GFhkTscR4Ds8fppwE MHAJs/h2ldK+C7Sm2fpNGbzYMycfUPGq4Ydg9PtnHPt1Mn9eH68tnQsT2nuTwGRq zqEGAgRftlMXogQCAhwgpAYEBAEAAAA= -----END SSL SESSION PARAMETERS----- Shared ciphers:AES128-SHA --- No server certificate CA names sent CIPHER is AES128-SHA Secure Renegotiation IS NOT supported Source content: File contents TermV-terminals-server.key: subject=/C=RU/ST=Sample/L=Sample/O=Sample/OU=Sample/CN=localhost issuer=/C=RU/ST=Sample/L=Sample/O=Sample/OU=Sample/CN=Sample -----BEGIN CERTIFICATE----- MIIDTjCCAjYCFBhhDBE3BeiTMD0dzFYOGILO8yq0MA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlJVMQ8wDQYDVQQIDAZTYW1wbGUxDzANBgNVBAcMBlNhbXBsZTEP MA0GA1UECgwGU2FtcGxlMQ8wDQYDVQQLDAZTYW1wbGUxDzANBgNVBAMMBlNhbXBs ZTAeFw0yMDAxMTgxODA5MDlaFw0yNDAxMTcxODA5MDlaMGUxCzAJBgNVBAYTAlJV MQ8wDQYDVQQIDAZTYW1wbGUxDzANBgNVBAcMBlNhbXBsZTEPMA0GA1UECgwGU2Ft cGxlMQ8wDQYDVQQLDAZTYW1wbGUxEjAQBgNVBAMMCWxvY2FsaG9zdDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQSjObDf16fv02qH+3FtI4eX2tPfj+u XsSF8KK6OpcNNfHv17LB9NRUGbZdeikvL5mjB1qd8Qt5YBzSYvvNmuQqn/ZZhEhg 9zqDd+j6dsl03OSW42qSP59M22plqhHZv1ZpkbpHSnEbbwbIVhgx1GuJvMHbQKxw et3UobG9M7q0/6Z2hlvbiuQgZWpc6+vnGGFUzVFjJhsUMgewU1UwTtfahOVegv9v ocuj+AOHzzH2+l72ybpKIFKZ6eXjr3sVp1lIPXm+gUNLqkReNV2QVk4H/j2ow3xu hdHjiPQ+6o6dgbCHeCvbf7Qs35S8YlQH/Mn2bik2NIMKucdq7S35AEsCAwEAATAN BgkqhkiG9w0BAQsFAAOCAQEAhANjStGtYfPJ2Ibkbn6ct4bWLPe6sFBvbwYow3Fd lBz0oxBukhJDOrPa4OqJDpnWenXkEcUrulI2JG5sIylOg3QlwlmgPoJU9fkpmr+u xNVlTxBSh1BVp0sccC+LxNRyDMl4C89R1TjPpPjoRU4cciY9N0oygPjTj0c26qBU iqwtyJTeeJYJUdplCMvXFOt8deqi/NBpBGnEfo8P/IeM/iCWLD5VtloHX/R0C+au q6803qd1/Gd0pIdsELQKrR6mBz6sWukg2f25GheLQVV7Wz/elZD8MwYwjYLoCtIP 65Ae3Eb6S2KlsVPzMj09u6kQ+KPfZtKu8tiUSc+11hurRw== -----END CERTIFICATE----- File contents TermV-terminals-server.crt: -----BEGIN PRIVATE KEY----- MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQC0Eozmw39en79N qh/txbSOHl9rT34/rl7EhfCiujqXDTXx79eywfTUVBm2XXopLy+ZowdanfELeWAc 0mL7zZrkKp/2WYRIYPc6g3fo+nbJdNzkluNqkj+fTNtqZaoR2b9WaZG6R0pxG28G yFYYMdRribzB20CscHrd1KGxvTO6tP+mdoZb24rkIGVqXOvr5xhhVM1RYyYbFDIH sFNVME7X2oTlXoL/b6HLo/gDh88x9vpe9sm6SiBSmenl4697FadZSD15voFDS6pE XjVdkFZOB/49qMN8boXR44j0PuqOnYGwh3gr23+0LN+UvGJUB/zJ9m4pNjSDCrnH au0t+QBLAgMBAAECggEBAKWbKdpQkSME53sVqqeR26uYY0jdos4OHzm9tMDzZE7m 52XJniXYGsHrVnpRHbginTQ+qtS7zKMwzSO0mTPas0iDqvl0+iNWighWQEETl4tO 3peb7Spltf1bQa9oMDCagU2HaW5Xgi7jfAhQ1l0J9sGvutjOO3xbNaQtmUdNKfXa VRaof94/YKcbTPIn588orxfumgeiYwQ8exhA7yg1WLl2iSy9jj+8WrxaKvy4vR45 nXrb2tXletRoZZY/FC/NZNMgXsGTmYHl6blTEZVz7Zu0XPHKJo42tHnKHW46/ccJ vkXQNjUsu0JN95+lWBA5Yne8xddhiLNKv3DZ3iwXRAECgYEA17YaIbtlgSLd5hJJ OuS9n9XNUCEx1YLhDRzhHggPNTZkVxSnxnWVGpbubtWN/OggRtJyk+mLFV+aHLCa R224ofSPWWE1HtoSdtLcL5oLgp6RDoM61h1p1glFS7BpbYzBegAcbMJa1IvAMspx 5lsYowBUJLNHAEcqUrXzQ88gu2ECgYEA1bRugqLGXqz1E0z6o/MuGXfmJaGQEmJg 833As5jzsyd6pyznsB0TKUAJkcf0RmZrr1EDVigA9aLcwq4qThjGEL2FpGkOvXPC bY0c2pLnsZJetNmXnky/w+W127V+LbDjjQaYl/7c9Fp4hoomoykt7d1YW7lRZ2Le wo8muiGF5ysCgYEAlYHahMysop926tJ7vPzzTMfT4JjRQGnQ79S3VqhBWiFT1GM1 kcDHUkGQCnOrUMHWNSABV/FDe9HiL8Zbd+xdTqsBe/J67eI5b+/fuoJrPeIHKebc rbB/PWD5jWc8+zfWlWdkTCE88RnXYZyc6wryfW9p4nH7YP7yH5eKftIdnqECgYBl aWY33/661uDF8/XM742k0F0K5oxz7PONGNPlZmPfVJDD3G9mB6YcISNpZrXo4pmf bJZkwD8UUeDpEbVJsj/rmcRdrO0twk01p41Vu/jvL0J6F/f3SvyFffC6/nmOPS7+ sW6gUnWQD466abzEGLqO8kcH3/1dTnHfagc6tMXSWQKBgQCZjWzyLtEUxvWI2PSe B6/osxlYDyCkXrJDIT1LuepM/54Kre9YMUy2UZBVC42DR6paEbkAAqHdTsLNlKhV s+6/JGnEDR1e/L7ks0dBY8jow04r0mKG1M91SMLr5OeBTk6SRMnR7GAKewjeLmJD ULgsqyHSTh/4r6tDQ7Gayci2vQ== -----END PRIVATE KEY----- File contents ssl_server.h: #ifndef SSL_SERVER_H #define SSL_SERVER_H #define DEBUG_LEVEL 5 #if DEBUG_LEVEL > 0 #include "mbedtls/debug.h" #endif //#define MBEDTLS_SSL_CIPHERSUITES MBEDTLS_TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 #include "mbedtls/entropy.h" #include "mbedtls/ctr_drbg.h" #include "mbedtls/certs.h" #include "mbedtls/x509.h" #include "mbedtls/ssl.h" #include "mbedtls/net_sockets.h" #include "mbedtls/error.h" #include "mbedtls/ssl_cache.h" #include "packet_handler/packet_handler.h" #include "thread_pool_ssl.h" #include "queue_ssl.h" extern pthread_mutex_t listen_fd1_mutex; extern mbedtls_net_context listen_fd1; extern void* runSSLServer(void *arg); #endif // SSL_SERVER_H File contents ssl_server.c: #include "ssl_server.h" mbedtls_net_context listen_fd1; pthread_mutex_t listen_fd1_mutex=PTHREAD_MUTEX_INITIALIZER; static mbedtls_ssl_config *config; #if DEBUG_LEVEL > 0 static void my_debug( void *ctx, int level, const char *file, int line, const char *str ) { ((void) level); char s[1000]; snprintf(s,sizeof(s),"%s:%04d: %s", file, line, str ); trace(s); } #endif void * runSSLServer(void *arg) { (void)(arg); int ret; char s[100]; int n = atoi(config_list[SSL_SERVER_NUM_THREADS].value); createThreadPoolSSLArray(n); mbedtls_net_context listen_fd, client_socket_ssl; const char pers[] = "ssl_pthread_server"; mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; mbedtls_ssl_config conf; mbedtls_x509_crt srvcert; mbedtls_x509_crt cachain; mbedtls_pk_context pkey; mbedtls_ssl_cache_context cache; mbedtls_ssl_cache_init( &cache ); mbedtls_x509_crt_init( &srvcert ); mbedtls_x509_crt_init( &cachain ); mbedtls_ssl_config_init( &conf ); mbedtls_ctr_drbg_init( &ctr_drbg ); mbedtls_net_init( &listen_fd ); mbedtls_net_init( &client_socket_ssl ); config = &conf; /* * We use only a single entropy source that is used in all the threads. */ mbedtls_entropy_init( &entropy ); #if DEBUG_LEVEL > 0 mbedtls_debug_set_threshold(DEBUG_LEVEL); #endif /* * 1. Load the certificates and private RSA key */ trace( "[SSL Server] Loading the server cert. and key..." ); ret = mbedtls_x509_crt_parse_file( &srvcert,"/etc/minpay/cert/TermV-terminals-server.crt"); if( ret != 0 ) { snprintf(s,sizeof(s), "[SSL Server] failed\n ! mbedtls_x509_crt_parse_file returned %d\n\n", ret ); trace(s); goto thread_exit; } mbedtls_pk_init( &pkey ); ret = mbedtls_pk_parse_keyfile( &pkey,"/etc/minpay/cert/TermV-terminals-server.key" , NULL ); if( ret != 0 ) { snprintf(s,sizeof(s), "[SSL Server] failed\n ! mbedtls_pk_parse_keyfile returned %d\n\n", ret ); trace(s); goto thread_exit; } trace( "[SSL Server] ok\n" ); /* * 1b. Seed the random number generator */ trace( "Seeding the random number generator..." ); if( ( ret = mbedtls_ctr_drbg_seed( &ctr_drbg, mbedtls_entropy_func, &entropy, (const unsigned char *) pers, strlen( pers ) ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL Server] failed: mbedtls_ctr_drbg_seed returned -0x%04x\n", -ret ); trace(s); goto thread_exit; } trace( "[SSL Server] ok\n" ); /* * 1c. Prepare SSL configuration */ trace( "[SSL Server] Setting up the SSL data...." ); if( ( ret = mbedtls_ssl_config_defaults( &conf, MBEDTLS_SSL_IS_SERVER, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL Server] failed: mbedtls_ssl_config_defaults returned -0x%04x\n", -ret ); trace(s); goto thread_exit; } mbedtls_ssl_conf_rng( &conf, mbedtls_ctr_drbg_random, &ctr_drbg ); #if DEBUG_LEVEL > 0 mbedtls_ssl_conf_dbg( &conf, my_debug, NULL ); #endif /* mbedtls_ssl_cache_get() and mbedtls_ssl_cache_set() are thread-safe if * MBEDTLS_THREADING_C is set. */ mbedtls_ssl_conf_session_cache( &conf, &cache, mbedtls_ssl_cache_get, mbedtls_ssl_cache_set ); mbedtls_ssl_conf_ca_chain( &conf, &cachain, NULL ); if( ( ret = mbedtls_ssl_conf_own_cert( &conf, &srvcert, &pkey ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL Server] failed\n ! mbedtls_ssl_conf_own_cert returned %d\n\n", ret ); trace(s); goto thread_exit; } trace( "[SSL Server] ok\n" ); /* * 2. Setup the listening TCP socket */ snprintf(s,sizeof(s),"[SSL Server] Bind on localhost: %s ...","8080"); trace(s); fflush( stdout ); if( ( ret = mbedtls_net_bind( &listen_fd, NULL, "8080", MBEDTLS_NET_PROTO_TCP ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL Server] failed\n ! mbedtls_net_bind returned %d\n\n", ret ); trace(s); goto thread_exit; } trace( "[SSL Server] ok\n" ); pthread_mutex_lock(&listen_fd1_mutex); listen_fd1 = listen_fd; pthread_mutex_unlock(&listen_fd1_mutex); while(true) { //reset: if(ret!=0) { char error_buf[100]; mbedtls_strerror( ret, error_buf, 100 ); snprintf(s,sizeof(s),"[SSL Server] Last error was: -0x%04x - %s\n", -ret, error_buf ); trace(s); } /* * 3. Wait until a client connects */ trace( "[SSL Server] Waiting for a remote connection\n" ); int ret =mbedtls_net_accept(&listen_fd,&client_socket_ssl,NULL,0,NULL); if(ret != 0) { snprintf(s,sizeof(s), "[SSL Server] failed: mbedtls_net_accept returned -0x%04x\n", ret); trace(s); break; } trace( "[SSL Server] ok\n" ); //do whatever we do with connections. //put the connection somewhere so that an available thread //can find it. mbedtls_net_context *pclient = malloc(sizeof(mbedtls_net_context)); *pclient = client_socket_ssl; pthread_mutex_lock(&client_socket_ssl_mutex); enqueue_ssl(pclient); pthread_cond_signal(&condition_var_ssl); pthread_mutex_unlock(&client_socket_ssl_mutex); ret = 0; } thread_exit: mbedtls_x509_crt_free( &srvcert ); mbedtls_pk_free( &pkey ); mbedtls_ssl_cache_free( &cache ); mbedtls_ctr_drbg_free( &ctr_drbg ); mbedtls_entropy_free( &entropy ); mbedtls_ssl_config_free( &conf ); mbedtls_net_free( &listen_fd ); deleteThreadPoolSSLArray(); return NULL; } static void *handleConnectionSSL(mbedtls_net_context *p_net_context) { int ret, len; char s[100]; struct packet_handler handler={}; handler.net_context = *p_net_context; free(p_net_context);// we really don't need this anymore unsigned char buf[1024]; /* Make sure memory references are valid */ mbedtls_ssl_init( &handler.ssl ); snprintf(s,sizeof(s),"[SSL client_socket=%d] Setting up SSL/TLS data\n", handler.net_context.fd ); trace(s); /* * 4. Get the SSL context ready */ if( ( ret = mbedtls_ssl_setup( &handler.ssl, config ) ) != 0 ) { snprintf(s,sizeof(s),"[SSL client_socket=%d] failed: mbedtls_ssl_setup returned -0x%04x\n",handler.net_context.fd, -ret ); trace(s); goto thread_exit; } mbedtls_ssl_set_bio( &handler.ssl, (mbedtls_net_context*)&handler.net_context, mbedtls_net_send, mbedtls_net_recv, NULL ); /* * 5. Handshake */ snprintf(s,sizeof(s),"[SSL client_socket=%d] Performing the SSL/TLS handshake\n", handler.net_context.fd); trace(s); while( ( ret = mbedtls_ssl_handshake( &handler.ssl ) ) != 0 ) { if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { snprintf(s,sizeof(s),"[SSL client_socket=%d] failed: mbedtls_ssl_handshake returned -0x%04x\n", handler.net_context.fd, -ret ); trace(s); goto thread_exit; } } snprintf(s,sizeof(s),"[SSL client_socket=%d] ok\n", handler.net_context.fd ); trace(s); ret = runPacketHandler(&handler); snprintf(s,sizeof(s), "[SSL client_socket=%d] . Closing the connection...", handler.net_context.fd ); trace(s); while( ( ret = mbedtls_ssl_close_notify( &handler.ssl ) ) < 0 ) { if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { snprintf(s,sizeof(s), "[SSL client_socket=%d] failed: mbedtls_ssl_close_notify returned -0x%04x\n", handler.net_context.fd, ret); trace(s); goto thread_exit; } } trace( " ok\n" ); ret = 0; thread_exit: if( ret != 0 ) { char error_buf[100]; mbedtls_strerror( ret, error_buf, 100 ); snprintf(s,sizeof(s), "[SSL client_socket=%d] Last error was: -0x%04x - %s\n\n", handler.net_context.fd, -ret, error_buf ); trace(s); } mbedtls_net_free((mbedtls_net_context*)&handler.net_context); mbedtls_ssl_free(&handler.ssl); return NULL; } void *threadFunctionSSL(void *arg) { (void)(arg); while(true) { mbedtls_net_context *pclient; pthread_mutex_lock(&client_socket_ssl_mutex); if((pclient=dequeue_ssl())==NULL) { pthread_cond_wait((pthread_cond_t *)&pclient,&client_socket_ssl_mutex); //try again pclient = dequeue_ssl(); } pthread_mutex_unlock(&client_socket_ssl_mutex); if(pclient!=NULL) { //we have a connection handleConnectionSSL(pclient); } } } File contents thread_pool_ssl.h: #ifndef SSL_THREAD_POOL_H #define SSL_THREAD_POOL_H #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdbool.h> #include <pthread.h> #include "mbedtls/net_sockets.h" extern pthread_t *thread_pool_ssl; extern pthread_mutex_t client_socket_ssl_mutex; extern pthread_cond_t condition_var_ssl; void createThreadPoolSSLArray(int n); void deleteThreadPoolSSLArray(); extern void *handleSSLConnection(int* p_client_socket); extern void *threadFunctionSSL(void *arg); #endif // SSL_THREAD_POOL_H File contents thread_pool_ssl.c: #include "thread_pool_ssl.h" pthread_t *thread_pool_ssl=NULL; pthread_mutex_t client_socket_ssl_mutex = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t condition_var_ssl = PTHREAD_COND_INITIALIZER; void *threadFunctionSSL(void *arg); void createThreadPoolSSLArray(int n) { thread_pool_ssl = (pthread_t*)malloc(n); //first off create a bunch of threads to handle future connections for(int i=0; i<n;i++) { pthread_create(&thread_pool_ssl[i],NULL,threadFunctionSSL,NULL); } } void deleteThreadPoolSSLArray() { free(thread_pool_ssl); } File contents main.c: #include <stdio.h> #include "log.h" #include "ssl_server.h" #include <signal.h> void catchSigterm(); void catchSigint(); void runPortListening(); int main() { catchSigterm(); catchSigint(); runPortListening(); return 0; } void runPortListening() { trace("Starting port listening..."); pthread_t handleID; pthread_create(&handleID,NULL,runSSLServer,NULL); trace("Port listening started."); pthread_join(handleID,NULL); trace("Port listening complete."); } void closeServer() { trace("Shutdown SSL Server..."); pthread_mutex_lock(&listen_fd1_mutex); mbedtls_net_free(&listen_fd1); pthread_mutex_unlock(&listen_fd1_mutex); } void sigTermHandler(int signum, siginfo_t *info, void *ptr) { (void)signum; (void)info; (void)ptr; closeServer(); } void catchSigterm() { static struct sigaction _sigact; memset(&_sigact, 0, sizeof(_sigact)); _sigact.sa_sigaction = sigTermHandler; _sigact.sa_flags = SA_SIGINFO; sigaction(SIGTERM, &_sigact, NULL); } void sigIntHandler(int signum, siginfo_t *info, void *ptr) { (void)signum; (void)info; (void)ptr; closeServer(); } void catchSigint() { static struct sigaction _sigact; memset(&_sigact, 0, sizeof(_sigact)); _sigact.sa_sigaction = sigIntHandler; _sigact.sa_flags = SA_SIGINFO; sigaction(SIGINT, &_sigact, NULL); } Log files attached to the email. Regards, Michael.

4 years, 5 months

1
0
0 0

Info regarding Mbedtls architecture

by Eikansh Gupta

Hi everyone, I am a Mtech student from Indian Institute of Science, Bangalore(India). Currently, I am crediting computer security course. As the course project, the professor has asked us to rewrite Mbedtls using Rust language. The entire class will work on the single project with each person working on a single module. I am having trouble finding information regarding Mbedtls architecture, its modules and their working. I don't even know all the right resources I need to work on the project. It would save a lot of time if someone could point me to the right resources regarding Mbedtls needed for this project. Sincerely, Eikansh Gupta

4 years, 5 months

1
0
0 0

Re: [mbed-tls] PKCS7 compliance

by Gilles Peskine

I forgot to mention that there is a work in progress to add PKCS#7 parsing: https://github.com/ARMmbed/mbedtls/pull/3431 This is an external contribution so its addition to Mbed TLS depends not only on us maintainers' review bandwidth, but also on the availability of the kind contributor. I'm not familiar with .p7* formats so I don't know whether the support added by this pull request is sufficient to cover all of those. -- Gilles Peskine Mbed TLS developer On 06/11/2020 13:50, Alvaro Gonzalez via mbed-tls wrote: > > Hello mbed-tls mailing list. > > ï¿½ > > Does mbed-tls comply PKCS7? Can handle .p7, .p7b and/or .p7a extension > files? > > ï¿½ > > Best Regards. > > ï¿½ > >

4 years, 5 months

1
0
0 0

Re: [mbed-tls] PKCS7 Generation Contribution

by Gilles Peskine

Hi Nick, It would be great to have even partial support of PKCS#7 in Mbed TLS and we would welcome your contribution! You can find some guidance in CONTRIBUTING.md (https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md). Feel free to ask on the mailing list if anything is unclear. Note that there is a work in progress for adding PKCS#7 parsing: https://github.com/ARMmbed/mbedtls/pull/3431 . It may help to see what it does, but also note the review comments that point out some remaining issues. If you and naynajain work on parsing and generation at the same time, you'll need to synchronize since both sides will need to create pkcs7.[hc]. -- Gilles Peskine Mbed TLS developer On 10/11/2020 17:28, Nick Child via mbed-tls wrote: > Hello, > > For one of my projects, I had to create a PKCS7 generation/builder. I > noticed mbedtls currently has no support for PKCS7. After much trial > and error, I was able to use mbedtls functions to create a PKCS7 > structure for Signed Data. I was wondering if this something that > might be useful in later versions of mbedtls? The code currently has a > long way to go until it meets mbedtls coding standards, but I figured > I would ask if it is even possible and worth the efforts before > getting into it. I am also a rookie when it comes to open source > contributions, so I was hoping for some guidance regarding merging > upstream. > > Thanks for your time, > > Nick Child >

4 years, 5 months

1
0
0 0

PKCS7 Generation Contribution

by Nick Child

Hello, For one of my projects, I had to create a PKCS7 generation/builder. I noticed mbedtls currently has no support for PKCS7. After much trial and error, I was able to use mbedtls functions to create a PKCS7 structure for Signed Data. I was wondering if this something that might be useful in later versions of mbedtls? The code currently has a long way to go until it meets mbedtls coding standards, but I figured I would ask if it is even possible and worth the efforts before getting into it. I am also a rookie when it comes to open source contributions, so I was hoping for some guidance regarding merging upstream. Thanks for your time, Nick Child

4 years, 5 months

1
0
0 0

Re: [mbed-tls] PKCS7 compliance

by Gilles Peskine

Hello, No, unfortunately Mbed TLS does not support the PKCS#7 CMS format. Contributions would be welcome. -- Gilles Peskine Mbed TLS developer On 06/11/2020 13:50, Alvaro Gonzalez via mbed-tls wrote: > > Hello mbed-tls mailing list. > > ï¿½ > > Does mbed-tls comply PKCS7? Can handle .p7, .p7b and/or .p7a extension > files? > > ï¿½ > > Best Regards. > > ï¿½ > >

4 years, 5 months

1
0
0 0

Re: [mbed-tls] TLS-SRP Support

by Gilles Peskine

Hello, Mbed TLS does not currently support SRP and it is not on our roadmap (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/). Arm does not intend to work on it, but support can be added if someone else contributes it. If you are interested in contributing SRP support, please discuss it on this list first to settle some potential issues: conflicts with other work (in particular TLS 1.3 preparation, which involves some refactoring of existing TLS code), review bandwidth schedule, test plan. -- Gilles Peskine Mbed TLS developer On 09/11/2020 14:01, Gijs Peskens via mbed-tls wrote: > > For an Open Source project we started using Mbed-TLS to do AES > encryption and, in a future version, will use Mbed-TLS for DTLS. > Part of the protocol we support requires TLS-SRP (either via DTLS or > via EAP), I’m unable to find anything relating to TLS-SRP support. > > Does Mbed-TLS support TLS-SRP currently? And if not is there intention > to add it in a future release? > > Br, > > Gijs Peskens > >

4 years, 5 months

1
0
0 0

Re: [mbed-tls] TLS-SRP Support

by Janos Follath

Hi Gijs, I am not sure what TLS-SRP support is, could you please point me to the standard defining it? Best regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Gijs Peskens via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Gijs Peskens <gijsje(a)heteigenwijsje.nl> Date: Monday, 9 November 2020 at 13:02 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] TLS-SRP Support For an Open Source project we started using Mbed-TLS to do AES encryption and, in a future version, will use Mbed-TLS for DTLS. Part of the protocol we support requires TLS-SRP (either via DTLS or via EAP), I’m unable to find anything relating to TLS-SRP support. Does Mbed-TLS support TLS-SRP currently? And if not is there intention to add it in a future release? Br, Gijs Peskens

4 years, 5 months

2
1
0 0

TLS-SRP Support

by Gijs Peskens

For an Open Source project we started using Mbed-TLS to do AES encryption and, in a future version, will use Mbed-TLS for DTLS. Part of the protocol we support requires TLS-SRP (either via DTLS or via EAP), I’m unable to find anything relating to TLS-SRP support. Does Mbed-TLS support TLS-SRP currently? And if not is there intention to add it in a future release? Br, Gijs Peskens

4 years, 5 months

1
0
0 0

PKCS7 compliance

by Alvaro Gonzalez

Hello mbed-tls mailing list. Does mbed-tls comply PKCS7? Can handle .p7, .p7b and/or .p7a extension files? Best Regards.

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Chinese characters garbled after calling mbedtls_x509_crt_info() or mbedtls_x509_dn_gets()

by Janos Follath

Hi Newt, This is normal and happens not just to Chinese characters, but to all non-ASCII characters. This supposed to be a feature of Mbed TLS, to ensure that we return something printable whether the platform can handle the original encoding or not. Of course we can consider providing a way to add an option to disable this feature: if you would like to submit a PR, please let us discuss first what can be done. If you wouldn't like to submit a PR, then please raise an issue on github for this feature request. Until this feature is implemented, you can access the original encoding in the `val` field of the `mbedtls_x509_name` parameter you would be passing to `mbedtls_x509_dn_gets()`. Regards, Janos On 06/11/2020, 03:54, "mbed-tls on behalf of 马瑞宜 via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Hello everyone, I have this certificate blob and I'm using mbedtls to read this, but after called mbedtls_x509_crt_info() or mbedtls_x509_dn_gets(), the chinese characters got garbled. I have googled this, read the mbedtls knowledge base and searched the issues and got no luck. The field i want to parse is the subject field and the issuer field. and currently I cannot provide the certificate blob due to security reasons. Any help would be much appreciated. Sincerely, Newt Ma -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 5 months

2
1
0 0

Chinese characters garbled after calling mbedtls_x509_crt_info() or mbedtls_x509_dn_gets()

by 马瑞宜

Hello everyone, I have this certificate blob and I'm using mbedtls to read this, but after called mbedtls_x509_crt_info() or mbedtls_x509_dn_gets(), the chinese characters got garbled. I have googled this, read the mbedtls knowledge base and searched the issues and got no luck. The field i want to parse is the subject field and the issuer field. and currently I cannot provide the certificate blob due to security reasons. Any help would be much appreciated. Sincerely, Newt Ma

4 years, 5 months

1
0
0 0

Re: [mbed-tls] About mbedtls CVE

by Janos Follath

Hi Sawyer, After looking at the issues in more detail I would like to be more precise about CVE-2018-1000520: * It is not a security issue in the context of TLS 1.2 * It can be a security issue if TLS 1.0 or TLS 1.1 is used * The severity is so low that we decided not fixing it ourselves, but to open it up for community contributions * The corresponding issue has been closed down by mistake, I am reopening it now: https://github.com/ARMmbed/mbedtls/issues/1561 (Many thanks to Simon Butcher for noticing this and pointing it out.) Please let me know if I you would like to know more about this issue. Best regards, Janos (Mbed TLS developer) From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Janos Follath via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Janos Follath <Janos.Follath(a)arm.com> Date: Wednesday, 28 October 2020 at 09:42 To: Sawyer Liu <sawyer.liu(a)nxp.com> Cc: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] About mbedtls CVE Hi Sawyer, Thank you for your interest in Mbed TLS. Currently the status of these CVE’s is: - CVE-2020-16150 has been fixed in the latest Mbed TLS release - CVE-2018-1000520 is not a security issue, it had been studied and rejected - CVE-2016-3739 is a vulnerability in an application using Mbed TLS but not in Mbed TLS itself, also it too had been fixed. Does this answer your question? (Also, I would like to make a minor clarification: we are not Arm Support. As far as I know Arm does not offer official support for Mbed TLS. Arm only contributes engineers to the Mbed TLS project, and at the moment these engineers are the maintainers of Mbed TLS. We are on this mailing list and try to answer questions, but we are not doing that as official support provided by Arm, but as members of the community. Mbed TLS is supported by the community and this mailing list is indeed the right place to get that support. I apologise for the nitpick, I just wanted to make sure that we are not giving the wrong impressions.) Best regards, Janos (Mbed TLS developer) From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Sawyer Liu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Sawyer Liu <sawyer.liu(a)nxp.com> Date: Wednesday, 28 October 2020 at 01:59 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] About mbedtls CVE Hello ARM Support, About below CVEs, any update? Thanks. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16150<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre…> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000520 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3739 Best Regards Sawyer Liu Microcontrollers, NXP Semiconductors

4 years, 5 months

2
1
0 0

Re: [mbed-tls] Questions about PSA Crypto API and mbed TLS

by Gilles Peskine

Hello, On 05/11/2020 17:49, François Beerten via mbed-tls wrote: > Hi, > > Thank you Gilles for the detailed reply. > > Do you prefer that discussion about PSA Crypto API spec go on mailing > list instead of here ? Is there some room for evolution or is the spec > already in a frozen released state ? Please use the psa-crypto list since there may be participants there who don't care about Mbed TLS. Version 1.0 of the PSA Crypto API is official so we won't make incompatible changes unless there is a compelling reason. We can, and will, add features in 1.x versions of the specification. Among planned features are: more algorithm declarations, key wrapping, key stretching, and a better treatment of key establishment (including password-based key establishment). > > For new algorithms, it's of course preferable that they're defined in > the spec itself. But does the mbedtls project want to supports all > algorithms that will be used with PSA Crypto API ? Mbed TLS intends to be a reference implementation of the PSA crypto API. However it isn't clear whether this means that Mbed TLS will eventually support all algorithms that the API declares: we intend to support all methods, but not necessarily all algorithms. A conforming implementation of the API is allowed to support any subset of the algorithms. We (here meaning Arm, not Mbed TLS) don't have a formal policy to decide whether to include a declaration for an algorithm, but here are some criteria that we're likely to follow: * There should be a public specification. (This can be a document that's only for purchase, such as an ISO standard.) * The algorithm should either be in good standing, or in current use in legacy protocols. * The bar is low for adding an algorithm that just requires a #define. It's a lot higher if a new function is needed. * Availability in Mbed TLS is not required. > > For pure ED25519 and ED448 with scattered data, there's one big > gotcha. You need to generate twice a hash that includes the message. > Thus the implementation needs to be able to access the buffers of the > message twice. With a piece of the message given only once as in the > init-update-finish scheme, that does not work well. > > From reading the document on the PSA Crypto driver API, a transparent > driver benefits from the management of keys done by the mbedtls > implementation. But what benefit is there for a driver working with > opaque keys which has to fully handle the protections and restrictions > of keys internally ? > One of the driving goals of PSA is to make security unobtrusive, and to facilitate security improvements. A unified interface to key management makes it easy to upgrade from having all keys inside, to using a single-chip application separation technology (MMU, MPU, secure enclave, …), to wrapping keys in a secure element and storing the wrapped key externally, to storing keys in a secure element (which protects against undeletion). When an application uses a key, it doesn't need to care where the key is stored. Best regards, -- Gilles Peskine > Best, > > François. > > > On 11/2/20 11:01 PM, Gilles Peskine via mbed-tls wrote: >> Hello, >> >> Thank you for your interest in the PSA crypto API. >> >> On 28/10/2020 15:20, François Beerten via mbed-tls wrote: >>> Hi everybody, >>> >>> After reading the PSA Crypto API specs (as on >>> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) >>> and looking at the mbed TLS library, a few questions came up. >>> >>> Is there some repository with the sources of the PSA Crypto API specs >>> where one can follow the evolution and eventually send proposals and >>> patches ? >>> >> The PSA specification drafts are not public. You can send feedback about >> the PSA Crypto application and driver interfaces on the psa-crypto >> mailing list (psa-crypto(a)lists.trustedfirmware.org, >> https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you >> prefer to send confidential feedback, you can email mbed-crypto(a)arm.com >> (feedback at this address will only be discussed inside Arm). An issue >> in the Mbed TLS repository will also reach PSA Crypto architects. >> >>> A note says "Hash suspend and resume is not defined for the SHA3 >>> family of hash algorithms". Why are they not defined for SHA3 ? >>> >> The hash suspend/resume operations marshall the internal state of the >> hash operation. They mimic an existing JavaCard API >> (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…). >> >> There is a de facto standard representation of the internal state for >> common Merkle-Damgård constructions, which covers all the currently >> defined hash algorithms except SHA3. If there's interest in this >> functionality, we could standardize a representation for SHA3. >> >>> How can or should one add support in PSA Crypto AP for not yet defined >>> algorithms (for example a KDF) ? >>> >> Answer from a PSA Crypto architect: preferably by requesting an encoding >> for this KDF as a PSA_ALG_xxx value (as well as new >> PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do >> that, use an encoding in the vendor range (most significant bit set). >> >> The world of key derivation functions is unfortunately messy: there are >> many similar, but not functionally equivalent constructions (such as >> hashing a secret together with a nonce, formatted in all kinds of >> different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set >> required for the TLS protocol. We expect 1.0.x updates to define more >> KDF algorithms. >> >> Answer from an Mbed TLS maintainer: contributing an implementation would >> be appreciated (but not required). >> >>> In multipart operations, can the user reuse the input buffers >>> immediately after doing an 'update' (for example after >>> psa_hash_update()) ? And can he reuse the input buffers immediately >>> after some "setup" functions like psa_cipher_set_iv() or >>> psa_aead_set_nonce() ? >>> >> Yes. PSA crypto API functions that take a buffer as a parameter never >> take ownership of that buffer. Once the function returns, you can do >> whatever you want with the buffer. >> >> The PSA specification even guarantees that you can use the same buffer, >> or overlapping buffers, as inputs and outputs to the same function call. >> However beware that the Mbed TLS implementation does not always support >> such overlap (https://github.com/ARMmbed/mbedtls/issues/3266). >> >>> Do you plan to support (pure) ED25519 and ED448 only via >>> psa_sign_message() and psa_verify_message() ? What about messages in >>> multiple chunks ? >>> >> We plan to add a multi-part message signature interface, both for the >> sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I >> expect the design to be “what you'd expect” but I haven't yet verified >> that there aren't any gotchas. >> >>> In psa_asymmetric_encrypt(), why is the salt provided explicitely. >>> Shouldn't it be generated randomly internally when needed ? >>> >> Some applications use a fixed or deterministic salt which they check on >> decryption. Note that this parameter is what PKCS#1 calls “label”. >> >>> With PSA Crypto API, you define a flexible API for cryptographic >>> operations. Apparently, other providers could make their own >>> implementation of PSA Crypto API. Will mbed TLS then be able to use >>> those alternate PSA Crypto API implementations ? How would that work >>> practically ? >>> >> The X.509 and TLS layer of Mbed TLS are currently designed to use the >> mbedtls_xxx crypto API. We have already added partial support for the >> psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet >> possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto >> implementation. (I think this is already possible for a small set of >> cipher suites, but it isn't something that we've tried or currently >> actively support.) Before this can happen, some Mbed TLS APIs need to >> change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan >> to decouple the PSA crypto reference implementation (Mbed TLS's current >> crypto implementation) from the X.509/TLS layer (which will remain “Mbed >> TLS”). Our plans >> (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far >> into the future are still vague and may change. >> >> Note that for the most common case of wanting a different implementation >> of cryptography, which is to leverage hardware such as accelerators and >> secure elements, PSA is defining a driver interface which is currently >> being implemented in Mbed TLS >> (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…). >> >> The driver interface lets you combine mechanisms supported by your >> hardware with Mbed TLS's implementation for mechanisms without hardware >> support. >>

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi Francois, The workshop slides and recordings are now available here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Regards, Shebu From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of François Beerten via mbed-tls Sent: Thursday, November 5, 2020 4:52 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] Mbed TLS Virtual Workshop Tomorrow Hi Shebu, Will you post the slides of the presentations of the workshop ? Thanks, François. On 11/2/20 9:01 PM, Shebu Varghese Kuriakose via mbed-tls wrote: Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com><mailto:linaro.org_havjv2figrh5egaiurb229pd8c@group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>; Don Harbin; psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org>; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Mbed TLS Virtual Workshop Tomorrow

by François Beerten

Hi Shebu, Will you post the slides of the presentations of the workshop ? Thanks, François. On 11/2/20 9:01 PM, Shebu Varghese Kuriakose via mbed-tls wrote: > > Hi All, > > Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, > November 3^rd ) from 2 to 6pm GMT. > > See agenda and zoom link here - > https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ > <https://www.trustedfirmware.org/meetings/mbed-tls-workshop/> > > Thanks, > > Shebu > > -----Original Appointment----- > *From:* Trusted Firmware Public Meetings > <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> > *Sent:* Friday, October 23, 2020 12:32 AM > *To:* Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; > mbed-tls(a)lists.trustedfirmware.org; Don Harbin; > psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman > *Subject:* Mbed TLS Virtual Workshop > *When:* Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, > Edinburgh, Lisbon, London. > *Where:* Zoom: > https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… > > > *You have been invited to the following event.* > > > Mbed TLS Virtual Workshop > > When > > > > Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix > > Where > > > > Zoom: > https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… > (map > <https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) > > Calendar > > > > shebu.varghesekuriakose(a)arm.com <mailto:shebu.varghesekuriakose@arm.com> > > Who > > > > • > > > > Don Harbin- creator > > • > > > > shebu.varghesekuriakose(a)arm.com <mailto:shebu.varghesekuriakose@arm.com> > > • > > > > mbed-tls(a)lists.trustedfirmware.org > <mailto:mbed-tls@lists.trustedfirmware.org> > > • > > > > psa-crypto(a)lists.trustedfirmware.org > <mailto:psa-crypto@lists.trustedfirmware.org> > > • > > > > dave.rodgman(a)arm.com <mailto:dave.rodgman@arm.com> > > *more details » > <https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>*** > > Hi, > Trustedfirmware.org community project would like to invite you to the > Mbed TLS Virtual Workshop. > > The purpose of the workshop is to bring together the Mbed TLS > community including maintainers, contributors and users to discuss > > * The future direction of the project and > * Ways to improve community collaboration > > Here is the agenda for the workshop. > > *Topic Time (in GMT)* > Welcome 2.00 - 2.10pm > Constant-time code 2.10 – 2.30pm > Processes - how does work get scheduled? 2.30 – 2.50pm > PSA Crypto APIs 2.50 – 3.20pm > PSA Crypto for Silicon Labs Wireless > MCUs - Why, What, Where and When 3.20 – 3.50pm > > *Break * > > Roadmap, TLS1.3 Update 4.10 – 4.30pm > Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm > How do I contribute my first review > and be an effective Mbed TLS reviewer 5.00 – 5.30pm > > Regards, > > Don Harbin > Trusted Firmware Community Manager > > > ==============Zoom details below:==================== > Trusted Firmware is inviting you to a scheduled Zoom meeting. > > Topic: Mbed TLS Virtual Workshop > Time: Nov 3, 2020 02:00 PM Greenwich Mean Time > > Join Zoom Meeting > https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… > <https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> > > Meeting ID: 953 1520 0315 > Passcode: 143755 > One tap mobile > +16699009128,,95315200315# US (San Jose) > +12532158782,,95315200315# US (Tacoma) > > Dial by your location > +1 669 900 9128 US (San Jose) > +1 253 215 8782 US (Tacoma) > +1 346 248 7799 US (Houston) > +1 646 558 8656 US (New York) > +1 301 715 8592 US (Germantown) > +1 312 626 6799 US (Chicago) > 888 788 0099 US Toll-free > 877 853 5247 US Toll-free > Meeting ID: 953 1520 0315 > Find your local number: https://linaro-org.zoom.us/u/apL3hgti4 > <https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> > > Going (shebu.varghesekuriakose(a)arm.com > <mailto:shebu.varghesekuriakose@arm.com>)? *Yes > <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>**- > **Maybe > <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>**- > **No > <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>*more > options » > <https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this courtesy email at the account > shebu.varghesekuriakose(a)arm.com > <mailto:shebu.varghesekuriakose@arm.com> because you are an attendee > of this event. > > To stop receiving future updates for this event, decline this event. > Alternatively you can sign up for a Google account at > https://www.google.com/calendar/ and control your notification > settings for your entire calendar. > > Forwarding this invitation could allow any recipient to send a > response to the organizer and be added to the guest list, or invite > others regardless of their own invitation status, or to modify your > RSVP. Learn More > <https://support.google.com/calendar/answer/37135#forwarding>. > >

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Questions about PSA Crypto API and mbed TLS

by François Beerten

Hi, Thank you Gilles for the detailed reply. Do you prefer that discussion about PSA Crypto API spec go on mailing list instead of here ? Is there some room for evolution or is the spec already in a frozen released state ? For new algorithms, it's of course preferable that they're defined in the spec itself. But does the mbedtls project want to supports all algorithms that will be used with PSA Crypto API ? For pure ED25519 and ED448 with scattered data, there's one big gotcha. You need to generate twice a hash that includes the message. Thus the implementation needs to be able to access the buffers of the message twice. With a piece of the message given only once as in the init-update-finish scheme, that does not work well. From reading the document on the PSA Crypto driver API, a transparent driver benefits from the management of keys done by the mbedtls implementation. But what benefit is there for a driver working with opaque keys which has to fully handle the protections and restrictions of keys internally ? Best, François. On 11/2/20 11:01 PM, Gilles Peskine via mbed-tls wrote: > Hello, > > Thank you for your interest in the PSA crypto API. > > On 28/10/2020 15:20, François Beerten via mbed-tls wrote: >> Hi everybody, >> >> After reading the PSA Crypto API specs (as on >> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) >> and looking at the mbed TLS library, a few questions came up. >> >> Is there some repository with the sources of the PSA Crypto API specs >> where one can follow the evolution and eventually send proposals and >> patches ? >> > The PSA specification drafts are not public. You can send feedback about > the PSA Crypto application and driver interfaces on the psa-crypto > mailing list (psa-crypto(a)lists.trustedfirmware.org, > https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you > prefer to send confidential feedback, you can email mbed-crypto(a)arm.com > (feedback at this address will only be discussed inside Arm). An issue > in the Mbed TLS repository will also reach PSA Crypto architects. > >> A note says "Hash suspend and resume is not defined for the SHA3 >> family of hash algorithms". Why are they not defined for SHA3 ? >> > The hash suspend/resume operations marshall the internal state of the > hash operation. They mimic an existing JavaCard API > (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…). > There is a de facto standard representation of the internal state for > common Merkle-Damgård constructions, which covers all the currently > defined hash algorithms except SHA3. If there's interest in this > functionality, we could standardize a representation for SHA3. > >> How can or should one add support in PSA Crypto AP for not yet defined >> algorithms (for example a KDF) ? >> > Answer from a PSA Crypto architect: preferably by requesting an encoding > for this KDF as a PSA_ALG_xxx value (as well as new > PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do > that, use an encoding in the vendor range (most significant bit set). > > The world of key derivation functions is unfortunately messy: there are > many similar, but not functionally equivalent constructions (such as > hashing a secret together with a nonce, formatted in all kinds of > different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set > required for the TLS protocol. We expect 1.0.x updates to define more > KDF algorithms. > > Answer from an Mbed TLS maintainer: contributing an implementation would > be appreciated (but not required). > >> In multipart operations, can the user reuse the input buffers >> immediately after doing an 'update' (for example after >> psa_hash_update()) ? And can he reuse the input buffers immediately >> after some "setup" functions like psa_cipher_set_iv() or >> psa_aead_set_nonce() ? >> > Yes. PSA crypto API functions that take a buffer as a parameter never > take ownership of that buffer. Once the function returns, you can do > whatever you want with the buffer. > > The PSA specification even guarantees that you can use the same buffer, > or overlapping buffers, as inputs and outputs to the same function call. > However beware that the Mbed TLS implementation does not always support > such overlap (https://github.com/ARMmbed/mbedtls/issues/3266). > >> Do you plan to support (pure) ED25519 and ED448 only via >> psa_sign_message() and psa_verify_message() ? What about messages in >> multiple chunks ? >> > We plan to add a multi-part message signature interface, both for the > sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I > expect the design to be “what you'd expect” but I haven't yet verified > that there aren't any gotchas. > >> In psa_asymmetric_encrypt(), why is the salt provided explicitely. >> Shouldn't it be generated randomly internally when needed ? >> > Some applications use a fixed or deterministic salt which they check on > decryption. Note that this parameter is what PKCS#1 calls “label”. > >> With PSA Crypto API, you define a flexible API for cryptographic >> operations. Apparently, other providers could make their own >> implementation of PSA Crypto API. Will mbed TLS then be able to use >> those alternate PSA Crypto API implementations ? How would that work >> practically ? >> > The X.509 and TLS layer of Mbed TLS are currently designed to use the > mbedtls_xxx crypto API. We have already added partial support for the > psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet > possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto > implementation. (I think this is already possible for a small set of > cipher suites, but it isn't something that we've tried or currently > actively support.) Before this can happen, some Mbed TLS APIs need to > change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan > to decouple the PSA crypto reference implementation (Mbed TLS's current > crypto implementation) from the X.509/TLS layer (which will remain “Mbed > TLS”). Our plans > (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far > into the future are still vague and may change. > > Note that for the most common case of wanting a different implementation > of cryptography, which is to leverage hardware such as accelerators and > secure elements, PSA is defining a driver interface which is currently > being implemented in Mbed TLS > (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…). > The driver interface lets you combine mechanisms supported by your > hardware with Mbed TLS's implementation for mechanisms without hardware > support. >

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Write private key into buffer using encrypted PEM format

by Janos Follath

Hi Mate, I had a look and I couldn’t find such a feature implemented either. I don’t think that Mbed TLS supports that at the moment. Best regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Z.Máté via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Z.Máté" <enleszekakalozkiraly(a)gmail.com> Date: Monday, 2 November 2020 at 21:01 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Write private key into buffer using encrypted PEM format Dear mbedtls list members! Sorry if this is the second time I ask, I'm not sure the previous question is still on the list. I'm asking if there's a way to export a private key into a buffer in an encrypted format. So that mbedtls_pk_parse_key() has to be called with a password. In the example program key_app.c (I hope that's how it's called) I can see there are password encrypted PEM formatted keys. But how to generate one? For clarity, this is the type of header I'm looking for. —–BEGIN RSA PRIVATE KEY—– Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,AB8E2B5B2D989271273F6730B6F9C687 ………………………………………………. ………………………………………………. ……………………………………… —–END RSA PRIVATE KEY—– I was only able to generate something like this by, using command line openssl. But I'd like a better solution, in code, using mbedtls. Yours Zombor Máté

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Questions about PSA Crypto API and mbed TLS

by Gilles Peskine

Hello, Thank you for your interest in the PSA crypto API. On 28/10/2020 15:20, François Beerten via mbed-tls wrote: > > Hi everybody, > > After reading the PSA Crypto API specs (as on > https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) > and looking at the mbed TLS library, a few questions came up. > > Is there some repository with the sources of the PSA Crypto API specs > where one can follow the evolution and eventually send proposals and > patches ? > The PSA specification drafts are not public. You can send feedback about the PSA Crypto application and driver interfaces on the psa-crypto mailing list (psa-crypto(a)lists.trustedfirmware.org, https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you prefer to send confidential feedback, you can email mbed-crypto(a)arm.com (feedback at this address will only be discussed inside Arm). An issue in the Mbed TLS repository will also reach PSA Crypto architects. > A note says "Hash suspend and resume is not defined for the SHA3 > family of hash algorithms". Why are they not defined for SHA3 ? > The hash suspend/resume operations marshall the internal state of the hash operation. They mimic an existing JavaCard API (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…). There is a de facto standard representation of the internal state for common Merkle-Damgård constructions, which covers all the currently defined hash algorithms except SHA3. If there's interest in this functionality, we could standardize a representation for SHA3. > How can or should one add support in PSA Crypto AP for not yet defined > algorithms (for example a KDF) ? > Answer from a PSA Crypto architect: preferably by requesting an encoding for this KDF as a PSA_ALG_xxx value (as well as new PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do that, use an encoding in the vendor range (most significant bit set). The world of key derivation functions is unfortunately messy: there are many similar, but not functionally equivalent constructions (such as hashing a secret together with a nonce, formatted in all kinds of different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set required for the TLS protocol. We expect 1.0.x updates to define more KDF algorithms. Answer from an Mbed TLS maintainer: contributing an implementation would be appreciated (but not required). > In multipart operations, can the user reuse the input buffers > immediately after doing an 'update' (for example after > psa_hash_update()) ? And can he reuse the input buffers immediately > after some "setup" functions like psa_cipher_set_iv() or > psa_aead_set_nonce() ? > Yes. PSA crypto API functions that take a buffer as a parameter never take ownership of that buffer. Once the function returns, you can do whatever you want with the buffer. The PSA specification even guarantees that you can use the same buffer, or overlapping buffers, as inputs and outputs to the same function call. However beware that the Mbed TLS implementation does not always support such overlap (https://github.com/ARMmbed/mbedtls/issues/3266). > Do you plan to support (pure) ED25519 and ED448 only via > psa_sign_message() and psa_verify_message() ? What about messages in > multiple chunks ? > We plan to add a multi-part message signature interface, both for the sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I expect the design to be “what you'd expect” but I haven't yet verified that there aren't any gotchas. > In psa_asymmetric_encrypt(), why is the salt provided explicitely. > Shouldn't it be generated randomly internally when needed ? > Some applications use a fixed or deterministic salt which they check on decryption. Note that this parameter is what PKCS#1 calls “label”. > With PSA Crypto API, you define a flexible API for cryptographic > operations. Apparently, other providers could make their own > implementation of PSA Crypto API. Will mbed TLS then be able to use > those alternate PSA Crypto API implementations ? How would that work > practically ? > The X.509 and TLS layer of Mbed TLS are currently designed to use the mbedtls_xxx crypto API. We have already added partial support for the psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto implementation. (I think this is already possible for a small set of cipher suites, but it isn't something that we've tried or currently actively support.) Before this can happen, some Mbed TLS APIs need to change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan to decouple the PSA crypto reference implementation (Mbed TLS's current crypto implementation) from the X.509/TLS layer (which will remain “Mbed TLS”). Our plans (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far into the future are still vague and may change. Note that for the most common case of wanting a different implementation of cryptography, which is to leverage hardware such as accelerators and secure elements, PSA is defining a driver interface which is currently being implemented in Mbed TLS (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…). The driver interface lets you combine mechanisms supported by your hardware with Mbed TLS's implementation for mechanisms without hardware support. -- Gilles Peskine PSA Cryptography architect and Mbed TLS developer > Thank you for your attention, > > François. > > >

4 years, 5 months

1
0
0 0

Write private key into buffer using encrypted PEM format

by Z.Máté

Dear mbedtls list members! Sorry if this is the second time I ask, I'm not sure the previous question is still on the list. I'm asking if there's a way to export a private key into a buffer in an encrypted format. So that mbedtls_pk_parse_key() has to be called with a password. In the example program key_app.c (I hope that's how it's called) I can see there are password encrypted PEM formatted keys. But how to generate one? For clarity, this is the type of header I'm looking for. —–BEGIN RSA PRIVATE KEY—– Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,AB8E2B5B2D989271273F6730B6F9C687 ………………………………………………. ………………………………………………. ……………………………………… —–END RSA PRIVATE KEY—– I was only able to generate something like this by, using command line openssl. But I'd like a better solution, in code, using mbedtls. Yours Zombor Máté

4 years, 5 months

1
0
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 5 months

1
0
0 0

Exporting private key in encrypted PEM format

by Z.Máté

Dear mbedtls list members! Is there a way to write a private key into a buffer, in PEM format, by using a password for encryption? Mbedtls is able to parse encrypted PEM files so can I write one? I couldn't really find any info regarding it, only an older, unfinished github issue ... Yours Zombor Máté

4 years, 5 months

1
0
0 0

Re: [mbed-tls] Questions about PSA Crypto API and mbed TLS

by Levi Schuck

Hello François, The following is my understanding, I am not a maintainer but a user of mbedtls. My response below only addresses a few of your questions. PSA appears to be bound to what mbedtls currently supports, this does not include Ed25519 or Ed448 at this time. A pull request is currently open for this feature development https://github.com/ARMmbed/mbedtls/pull/3245 Further development may be necessary to include those in PSA. The only implementation of PSA that I know of is one that wraps around mbedtls. Best, Levi On Wed, Oct 28, 2020 at 9:20 AM François Beerten via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi everybody, > > After reading the PSA Crypto API specs (as on > https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) > and looking at the mbed TLS library, a few questions came up. > > Is there some repository with the sources of the PSA Crypto API specs > where one can follow the evolution and eventually send proposals and > patches ? > > A note says "Hash suspend and resume is not defined for the SHA3 family of > hash algorithms". Why are they not defined for SHA3 ? > > How can or should one add support in PSA Crypto AP for not yet defined > algorithms (for example a KDF) ? > > In multipart operations, can the user reuse the input buffers immediately > after doing an 'update' (for example after psa_hash_update()) ? And can > he reuse the input buffers immediately after some "setup" functions like > psa_cipher_set_iv() or psa_aead_set_nonce() ? > > Do you plan to support (pure) ED25519 and ED448 only via > psa_sign_message() and psa_verify_message() ? What about messages in > multiple chunks ? > > In psa_asymmetric_encrypt(), why is the salt provided explicitely. > Shouldn't it be generated randomly internally when needed ? > > With PSA Crypto API, you define a flexible API for cryptographic > operations. Apparently, other providers could make their own implementation > of PSA Crypto API. Will mbed TLS then be able to use those alternate PSA > Crypto API implementations ? How would that work practically ? > > Thank you for your attention, > > François. > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

4 years, 6 months

2
2
0 0

JITR is not working in case CA is created using BouncyCastle in mbedtls

by 박현웅

I make a CA certificate for JITR using BouncyCastle lib in the android app as the below example And a device certificate is generated by this certificate in mbed_tls. At this time, JITR is not working. Namely, a device certificate is not registered in AWS. But In the case of making a ca certificate using OPENSSL, JITR works normally. Below is CA certificate based BouncyCastle lib. -----BEGIN CERTIFICATE----- MIIB8jCCAZegAwIBAgIVAK0ct2HFXVdS/k2NblxYGoxyuabfMAoGCCqGSM49BAMC MDIxCzAJBgNVBAYTAktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdh em9uZTAeFw0yMDEwMjcwMDAwMDBaFw0zNTAxMDEwMDAwMDBaMDIxCzAJBgNVBAYT AktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdhem9uZTBZMBMGByqG SM49AgEGCCqGSM49AwEHA0IABEknYdqI3CdVlmMkTmqKS63HnHc5PbyBff1RokGG 6NE6z31ilA8Yt2fGFHIln1kQtx//6stBA1bIqiqsSo8wad6jgYkwgYYwHQYDVR0O BBYEFBHaQtHvagaDPkpWxQurErTekm2cMB8GA1UdIwQYMBaAFBHaQtHvagaDPkpW xQurErTekm2cMA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQDAgAHMAsG A1UdDwQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDAzAKBggqhkjOPQQDAgNJADBG AiEA9HSXn3FpGUYLagsI3qaHz3VicMSuADUz/QBYEKN9STkCIQC+8BX/TPADpPOy ClmBIkjxdDt0Fh7HTDn9UwBUxYA3/g== -----END CERTIFICATE----- -----BEGIN EC PRIVATE KEY----- MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgU9pUZUfplZyhC+mH Pt8pthLItdpbJ+Qy47r7gJKTNvCgCgYIKoZIzj0DAQehRANCAARJJ2HaiNwnVZZj JE5qikutx5x3OT28gX39UaJBhujROs99YpQPGLdnxhRyJZ9ZELcf/+rLQQNWyKoq rEqPMGne -----END EC PRIVATE KEY----- BRs. Hyunung Park

4 years, 6 months

1
0
0 0

Questions about PSA Crypto API and mbed TLS

by François Beerten

Hi everybody, After reading the PSA Crypto API specs (as on https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) and looking at the mbed TLS library, a few questions came up. Is there some repository with the sources of the PSA Crypto API specs where one can follow the evolution and eventually send proposals and patches ? A note says "Hash suspend and resume is not defined for the SHA3 family of hash algorithms". Why are they not defined for SHA3 ? How can or should one add support in PSA Crypto AP for not yet defined algorithms (for example a KDF) ? In multipart operations, can the user reuse the input buffers immediately after doing an 'update' (for example after psa_hash_update()) ? And can he reuse the input buffers immediately after some "setup" functions like psa_cipher_set_iv() or psa_aead_set_nonce() ? Do you plan to support (pure) ED25519 and ED448 only via psa_sign_message() and psa_verify_message() ? What about messages in multiple chunks ? In psa_asymmetric_encrypt(), why is the salt provided explicitely. Shouldn't it be generated randomly internally when needed ? With PSA Crypto API, you define a flexible API for cryptographic operations. Apparently, other providers could make their own implementation of PSA Crypto API. Will mbed TLS then be able to use those alternate PSA Crypto API implementations ? How would that work practically ? Thank you for your attention, François.

4 years, 6 months

1
0
0 0

Re: [mbed-tls] Availability of 2.16.7 in download archive

by Janos Follath

Hi Frank, The issue exists because you are downloading a tag and not the release. The 2.16.8 release is available here: https://github.com/ARMmbed/mbedtls/archive/v2.16.8.tar.gz Best regards, Janos On 28/10/2020, 12:15, "mbed-tls on behalf of Frank Bergmann via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Hi Gilles, I noticed that the "double name" does still exist in some archive files: $ wget -q -O - https://github.com/ARMmbed/mbedtls/archive/mbedtls-2.16.8.tar.gz|tar tzf -|head mbedtls-mbedtls-2.16.8/ mbedtls-mbedtls-2.16.8/.github/ mbedtls-mbedtls-2.16.8/.github/issue_template.md mbedtls-mbedtls-2.16.8/.github/pull_request_template.md mbedtls-mbedtls-2.16.8/.gitignore mbedtls-mbedtls-2.16.8/.globalrc mbedtls-mbedtls-2.16.8/.pylintrc mbedtls-mbedtls-2.16.8/.travis.yml mbedtls-mbedtls-2.16.8/CMakeLists.txt mbedtls-mbedtls-2.16.8/CONTRIBUTING.md cheers, Frank On Tue, Aug 04, 2020 at 09:18:56PM +0000, Gilles Peskine via mbed-tls wrote: [...] > The naming with mbedtls-mbedtls- must be a bug in our release script. [...] -- 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 -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 6 months

2
1
0 0

Re: [mbed-tls] Availability of 2.16.7 in download archive

by Frank Bergmann

Hi Gilles, I noticed that the "double name" does still exist in some archive files: $ wget -q -O - https://github.com/ARMmbed/mbedtls/archive/mbedtls-2.16.8.tar.gz|tar tzf -|head mbedtls-mbedtls-2.16.8/ mbedtls-mbedtls-2.16.8/.github/ mbedtls-mbedtls-2.16.8/.github/issue_template.md mbedtls-mbedtls-2.16.8/.github/pull_request_template.md mbedtls-mbedtls-2.16.8/.gitignore mbedtls-mbedtls-2.16.8/.globalrc mbedtls-mbedtls-2.16.8/.pylintrc mbedtls-mbedtls-2.16.8/.travis.yml mbedtls-mbedtls-2.16.8/CMakeLists.txt mbedtls-mbedtls-2.16.8/CONTRIBUTING.md cheers, Frank On Tue, Aug 04, 2020 at 09:18:56PM +0000, Gilles Peskine via mbed-tls wrote: [...] > The naming with mbedtls-mbedtls- must be a bug in our release script. [...] -- 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, 6 months

1
0
0 0

Re: [mbed-tls] About mbedtls CVE

by Janos Follath

Hi Sawyer, Thank you for your interest in Mbed TLS. Currently the status of these CVE’s is: - CVE-2020-16150 has been fixed in the latest Mbed TLS release - CVE-2018-1000520 is not a security issue, it had been studied and rejected - CVE-2016-3739 is a vulnerability in an application using Mbed TLS but not in Mbed TLS itself, also it too had been fixed. Does this answer your question? (Also, I would like to make a minor clarification: we are not Arm Support. As far as I know Arm does not offer official support for Mbed TLS. Arm only contributes engineers to the Mbed TLS project, and at the moment these engineers are the maintainers of Mbed TLS. We are on this mailing list and try to answer questions, but we are not doing that as official support provided by Arm, but as members of the community. Mbed TLS is supported by the community and this mailing list is indeed the right place to get that support. I apologise for the nitpick, I just wanted to make sure that we are not giving the wrong impressions.) Best regards, Janos (Mbed TLS developer) From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Sawyer Liu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Sawyer Liu <sawyer.liu(a)nxp.com> Date: Wednesday, 28 October 2020 at 01:59 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] About mbedtls CVE Hello ARM Support, About below CVEs, any update? Thanks. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16150<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre…> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000520 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3739 Best Regards Sawyer Liu Microcontrollers, NXP Semiconductors

4 years, 6 months

2
2
0 0

Re: [mbed-tls] JITR in mbedtls

by 박현웅

From: 박현웅 <hupark(a)ictk.com> Sent: Wednesday, October 28, 2020 6:21 PM To: 'mbed-tls(a)lists.trustedfirmware.org.' <mbed-tls(a)lists.trustedfirmware.org.> Subject: JITR in mbedtls Hi I make a certificate using BouncyCastle lib in android app as the below. JITR is not working. Namely a device certificate is not registered in aws iot. In case of making ca certificate using openssl, JITR works normally. Could you please help me? -----BEGIN CERTIFICATE----- MIIB8jCCAZegAwIBAgIVAK0ct2HFXVdS/k2NblxYGoxyuabfMAoGCCqGSM49BAMC MDIxCzAJBgNVBAYTAktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdh em9uZTAeFw0yMDEwMjcwMDAwMDBaFw0zNTAxMDEwMDAwMDBaMDIxCzAJBgNVBAYT AktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdhem9uZTBZMBMGByqG SM49AgEGCCqGSM49AwEHA0IABEknYdqI3CdVlmMkTmqKS63HnHc5PbyBff1RokGG 6NE6z31ilA8Yt2fGFHIln1kQtx//6stBA1bIqiqsSo8wad6jgYkwgYYwHQYDVR0O BBYEFBHaQtHvagaDPkpWxQurErTekm2cMB8GA1UdIwQYMBaAFBHaQtHvagaDPkpW xQurErTekm2cMA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQDAgAHMAsG A1UdDwQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDAzAKBggqhkjOPQQDAgNJADBG AiEA9HSXn3FpGUYLagsI3qaHz3VicMSuADUz/QBYEKN9STkCIQC+8BX/TPADpPOy ClmBIkjxdDt0Fh7HTDn9UwBUxYA3/g== -----END CERTIFICATE----- -----BEGIN EC PRIVATE KEY----- MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgU9pUZUfplZyhC+mH Pt8pthLItdpbJ+Qy47r7gJKTNvCgCgYIKoZIzj0DAQehRANCAARJJ2HaiNwnVZZj JE5qikutx5x3OT28gX39UaJBhujROs99YpQPGLdnxhRyJZ9ZELcf/+rLQQNWyKoq rEqPMGne -----END EC PRIVATE KEY----- BRs. Hyunung Park

4 years, 6 months

1
0
0 0

About mbedtls CVE

by Sawyer Liu

Hello ARM Support, About below CVEs, any update? Thanks. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16150<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre…> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000520 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3739 Best Regards Sawyer Liu Microcontrollers, NXP Semiconductors

4 years, 6 months

1
0
0 0

Re: [mbed-tls] Availability of GPLv2 releases in the future

by Gilles Peskine

Hi Fabian, Unfortunately https://tls.mbed.org/how-to-get is out of date. As indicated on https://tls.mbed.org/download, newer releases (since 2.17) are distributed under Apache license only. Only the long-time support branches (2.7.x and 2.16.x) still have GPL releases. -- Gilles Peskine Mbed TLS developer On 20/10/2020 14:19, Fabian Keil via mbed-tls wrote: > Hi, > > tls.mbed.org currently sends mixed signals regarding > the license of future MbedTLS releases. > > Quoting https://tls.mbed.org/download: > | In packaged form, mbed TLS 2.1.0 to mbed TLS 2.16 are > | available in both an Apache 2.0 licensed version (our > | primary open source license) and in a GPL 2.0 licensed version. > | > | Newer versions will be available under the Apache 2.0 license. > > Quoting https://tls.mbed.org/how-to-get: > | All the current versions of the mbed TLS library are distributed > | under the Apache 2.0 license and available from our Download area. > | In addition there are packaged versions of the mbed TLS library > | that are distributed with the GNU Public License Version 2.0 (GPL v2.0). > | > | The Apache-licensed and GPL-licensed versions of mbed TLS are > | identical in source code (with the exception of the license > | headers at the top of files). > | > | We plan to keep both licensed versions around. > > Can anyone estimate when "newer releases" will no longer > be dual licensed? > > We recently added MbedTLS support for Privoxy and a > MbedTLS license switch from dual license to Apache 2.0 > complicates the license terms. > > Thanks > Fabian >

4 years, 6 months

1
0
0 0

Re: [mbed-tls] Clarification regarding the mbedtls_pk_context object and the PEM format, an a question about the example TLS server

by Gilles Peskine

Hi Máté, On 26/10/2020 12:04, Z.Máté via mbed-tls wrote: > Dear mbedtls mailing list members! > > I hope you recieve my message now, previously I had problems posting > to this list. :( > > My first question is actually about the PEM format. As far as I'm > aware the PEM format either contains the Private key (signalled by the > ---- BEGIN PRIVATE KEY ---- header) or a public key (---- BEGIN PUBLIC > KEY -----). In my application I have to work on an app that stores key > pairs in a special, secure storage solution (Secure Storage of OPTEE > if you've heard about it). I decided to export the keys in PEM format, > so that reading and handling them is equal to moving a large string > buffer around. Using the PEM format, is there a way to store both > private and public keys in the same "file"? Does mbedtls allow for > such a solution (does such a solution even exist?). There are actually several PEM formats. Some private key formats actually store both the private key and the public key, while others only store the private key. However, it is always possible to calculate the public key from the private key. So if you want to have the whole key pair, just write the private key in any format. If you have a private key file, you can extract the public key with the Mbed TLS sample program key_app_writer (untested command line, typed directly into my mail client): programs/pkey/key_app_writer mode=private filename=my_private_key.pem output_mode=public output_file=my_public_key.pem or with OpenSSL: openssl pkey -in my_private_key.pem -pubout -out my_public_key.pem > > If not, is there a simple way to get the public key from a private key > object? Does the mbedtls_pk_context, (that parsed up with a private > key) contain the information needed to export the public key into a > PEM buffer? As far as I know mbedtls allows for exporting the private > key and the public key with the functions mbedtls_write_key_pem and > ...write_pubkey_pem (or something along those lines) does that mean I > can only export one at a time and there's no way to save the > information for both into one PEM buffer? > > If there's a way to save both private and public keys into one PEM > file, do I have to parse the private key and public key into separate > objects then? With parse_key and parse_pubkey? This isn't really a > problem just clarifying. Once you have an mbedtls_pk_context, if you want to export both keys to a file, use mbedtls_write_key_pem(). If you want to have a separate file that only contains the public key, call mbedtls_write_pubkey_pem() on the same mbedtls_pk_context. > > If you can point me to an actually good description of the PEM format > and what CAN be stored inside of it, I'd be very grateful! :) PEM is just an encoding: base64 data between a header and footer. The base64-encoded data can have several different formats depending on the header. It can represent a private key (several formats depending on the header), a public key or a certificate. A complete description is spread across about half a dozen RFC. Fortunately, I don't think you need to dig into those. > > I also have a question regarding the example SSL server program. In > it, the server needs a private key and a certificate for obvious > reasons. It also loads a certificate and as far as I know, the > certificate has to be tied to a known CA for it to be valid. > > I would like to test the program with a self generated key pair, do I > need to change the Certificate and CAs to a new one as well? To > authenticate the new keypair? Does the mbedtls ssl_client1 example > program work with self signed certs? Or do I need to take care of the > CA validation myself (that would probably beyond the scope of the > project I'm working on). The sample program ssl_server does not check the client certificate. The test program ssl_server2 can check the client certificate: pass the command line options "auth_mode=required ca_file=my_ca.crt". If you have a self-signed client certificate, you can pass it as the ca_file. -- Gilles Peskine Mbed TLS developer > > Thank you in advance! > > Yours truly, > Máté Zombor >

4 years, 6 months

1
0
0 0

Clarification regarding the mbedtls_pk_context object and the PEM format, an a question about the example TLS server

by Z.Máté

Dear mbedtls mailing list members! I hope you recieve my message now, previously I had problems posting to this list. :( My first question is actually about the PEM format. As far as I'm aware the PEM format either contains the Private key (signalled by the ---- BEGIN PRIVATE KEY ---- header) or a public key (---- BEGIN PUBLIC KEY -----). In my application I have to work on an app that stores key pairs in a special, secure storage solution (Secure Storage of OPTEE if you've heard about it). I decided to export the keys in PEM format, so that reading and handling them is equal to moving a large string buffer around. Using the PEM format, is there a way to store both private and public keys in the same "file"? Does mbedtls allow for such a solution (does such a solution even exist?). If not, is there a simple way to get the public key from a private key object? Does the mbedtls_pk_context, (that parsed up with a private key) contain the information needed to export the public key into a PEM buffer? As far as I know mbedtls allows for exporting the private key and the public key with the functions mbedtls_write_key_pem and ...write_pubkey_pem (or something along those lines) does that mean I can only export one at a time and there's no way to save the information for both into one PEM buffer? If there's a way to save both private and public keys into one PEM file, do I have to parse the private key and public key into separate objects then? With parse_key and parse_pubkey? This isn't really a problem just clarifying. If you can point me to an actually good description of the PEM format and what CAN be stored inside of it, I'd be very grateful! :) I also have a question regarding the example SSL server program. In it, the server needs a private key and a certificate for obvious reasons. It also loads a certificate and as far as I know, the certificate has to be tied to a known CA for it to be valid. I would like to test the program with a self generated key pair, do I need to change the Certificate and CAs to a new one as well? To authenticate the new keypair? Does the mbedtls ssl_client1 example program work with self signed certs? Or do I need to take care of the CA validation myself (that would probably beyond the scope of the project I'm working on). Thank you in advance! Yours truly, Máté Zombor

4 years, 6 months

1
0
0 0

Invitation: Mbed TLS Virtual Workshop @ Tue Nov 3, 2020 7am - 11am (MST) (mbed-tls@lists.trustedfirmware.org)

by Don Harbin

You have been invited to the following event. Title: Mbed TLS Virtual Workshop Hi,Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discussThe future direction of the project andWays to improve community collaborationHere is the agenda for the workshop.Topic                                                                         Time (in GMT)Welcome                                                                   2.00 - 2.10pmConstant-time code                                                2.10 – 2.30pmProcesses - how does work get scheduled?      2.30 – 2.50pmPSA Crypto APIs                                                     2.50 – 3.20pmPSA Crypto for Silicon Labs Wireless         MCUs - Why, What, Where and When          3.20 – 3.50pmBreak                                                                          Roadmap, TLS1.3 Update                                      4.10 – 4.30pmMbed TLS 3.0 Plans, Scope                                   4.30 – 5.00pmHow do I contribute my first review         and be an effective Mbed TLS reviewer      5.00 – 5.30pmRegards,Don Harbin Trusted Firmware Community Manager==============Zoom details below:====================Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: Mbed TLS Virtual WorkshopTime: Nov 3, 2020 02:00 PM Greenwich Mean TimeJoin Zoom Meetinghttps://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT09Meeting ID: 953 1520 0315Passcode: 143755One tap mobile+16699009128,,95315200315# US (San Jose)+12532158782,,95315200315# US (Tacoma)Dial by your location        +1 669 900 9128 US (San Jose)        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 646 558 8656 US (New York)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 953 1520 0315Find your local number: https://linaro-org.zoom.us/u/apL3hgti4 When: Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * shebu.varghesekuriakose(a)arm.com * mbed-tls(a)lists.trustedfirmware.org * psa-crypto(a)lists.trustedfirmware.org * dave.rodgman(a)arm.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 6 months

1
0
0 0

Availability of GPLv2 releases in the future

by Fabian Keil

Hi, tls.mbed.org currently sends mixed signals regarding the license of future MbedTLS releases. Quoting https://tls.mbed.org/download: | In packaged form, mbed TLS 2.1.0 to mbed TLS 2.16 are | available in both an Apache 2.0 licensed version (our | primary open source license) and in a GPL 2.0 licensed version. | | Newer versions will be available under the Apache 2.0 license. Quoting https://tls.mbed.org/how-to-get: | All the current versions of the mbed TLS library are distributed | under the Apache 2.0 license and available from our Download area. | In addition there are packaged versions of the mbed TLS library | that are distributed with the GNU Public License Version 2.0 (GPL v2.0). | | The Apache-licensed and GPL-licensed versions of mbed TLS are | identical in source code (with the exception of the license | headers at the top of files). | | We plan to keep both licensed versions around. Can anyone estimate when "newer releases" will no longer be dual licensed? We recently added MbedTLS support for Privoxy and a MbedTLS license switch from dual license to Apache 2.0 complicates the license terms. Thanks Fabian

4 years, 6 months

1
0
0 0

Fwd: Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

Hi Dave, Thanks for your reply. The particular reasons for bringing up 2.7 and 2.16 first is that my employer is currently using 2.7 and would prefer using a small increment. Having said that, if adding features to LTS is not advisable (especially given that 2.7 has less than 6 months of projected life), I think I can present the arguments against using the 2.7. Additional consideration is the timing. My employer needs fragmentation support as soon as possible, with the intent of running it on a desktop environment. Historically, when the engineers are able to provide my employer with what is needed now, they are allowed more time for incremental improvements. The third consideration involves the MPS project by Hanno Becker. I've been collaborating with Hanno, and with Hannes Tschofenig and Thomas Fosetti on the project of adding QUIC support to mbedTLS. This goal depends on TLS 1.3 support (Hannes has written a prototype, which I was able to add QUIC in an internal version), and on MPS. I would like to avoid putting a duplicate effort into non-MPS fragmentation support. Unfortunately, if I want to meet the timing requirements of my employer, I will not be able to use MPS, since it needs more maturing. Because of the above considerations, I would like to suggest the following plan of actions: As the first step, I would like to add the MVP (minimal viable product) fragmentation to the development version. The MVP takes the following assumptions: 1. The RAM footprint is not a concern for the MVP (my employer is going to run it in the desktop environment). 2. Unification of the fragmentation between TLS and DTLS is not a concern for the MVP 3. LTS is not a concern for the MVP (potentially not at all) Because of the above simplifying assumptions, I believe that the change can be small and focused. I think I can have code ready for review in a couple of weeks. As the second step, I would like to put my effort into helping Hanno Becker with his MPS system. Once sufficiently mature, the MPS will supersede the MVP fragmentation, and will open the doors for adding support for QUIC. The simplifying assumptions 1. (RAM) and 2. (TLS <=> DTLS) will be addressed by MPS. Addressing the last assumption may not be required. What are your thoughts? On Wed, Oct 14, 2020 at 10:28 AM Dave Rodgman <dave.rodgman(a)arm.com> wrote: > Hi Omer, > > > > Thanks for offering to help us with this feature. > > > > Normally, we wouldn’t add new features directly to an older branch, for a > few reasons. 2.7 is quite old and is in fact only guaranteed to be > supported until Feb 21, so it’s not the ideal place to spend effort on new > features. Introducing new features here would also create the situation > where 2.7 has features not in development, and vice-versa, creating an > upgrade dilemma for users (unless we were to port the feature to all > supported branches). And adding significant new features to LTS branches > can always introduce some risk of destabilising it. > > > > So for these reasons, we would normally recommend targeting the > development branch for new features (with backports only where there is a > strong reason to do so), and then picking up the next stable release that > contains the new feature. > > > > Is there a particular reason you’re focusing on 2.7, rather than > development, or would it be viable for you to add this to development and > pick up the next release? > > > > Thanks > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf > of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *Omer Shapira <omer.shapira(a)gmail.com> > *Date: *Monday, 12 October 2020 at 20:04 > *To: *"mbed-tls(a)lists.trustedfirmware.org" < > mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Working on TLS handshake record fragmentation > (#1840) > > > > Hello, > > My employer (Facebook) is willing to give me some time to TLS handshake > fragmentation support to MbedTLS 2.7 [0] . This would be my first > contribution to MbedTLS, and I have several novice questions: > > 1. What is the best way to add the feature to MbedTLS 2.7? > 2. Trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. > > > Question 1: Best way to add the feature to MbedTLS 2.7 > > One constraint that I am facing is the code must be added to the upstream > branch that is as close as possible to the 2.7.xx. My understanding of the > Contribution Guidelines[1] is that while the LTS branches are mostly meant > for the bug fixes, backporting of the new features is welcomed as long as > the API/ABI compatibility is maintained and the disruption to the users is > minimized. > > If adding support to the LTS branches is not advisable, are there any > other possibilities of contributing the code to an upstream branch that is > very close to the 2.7.xx? > > Question 2: Trade-off between the consistency of the fragmentation code > across the branches, vs. the consistency of the branches. > > Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a > trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. The `development` branch > supports variable-length buffers[2] . Variable messages sizes would make > the fragmentation easier in the development branch. In addition, there is > the MPS effort by Hanno Becker which would make the fragmentation support > even easier in the development branch. None of that is present in the 2.7 > or the 2.16 branches. > > What is the preferable trade-off in such a situation: > a. Minimizing the change to the "host" version (2.7 or 2.16), on the > expense the implementation of the feature differ between 2.7 and > `development`, or > b. Minimizing the differences in the implementation of the feature, on > the expense of more intrusive changes to the earlier versions? > > > [0] https://github.com/ARMmbed/mbedtls/issues/1840 > [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md > [2] > https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… > > -- > > Sincerely Yours, > Omer Shapira > -- Sincerely Yours, Omer Shapira -- Sincerely Yours, Omer Shapira

4 years, 6 months

1
0
0 0

Re: [mbed-tls] Working on TLS handshake record fragmentation (#1840)

by Dave Rodgman

Hi Omer, Thanks for offering to help us with this feature. Normally, we wouldn’t add new features directly to an older branch, for a few reasons. 2.7 is quite old and is in fact only guaranteed to be supported until Feb 21, so it’s not the ideal place to spend effort on new features. Introducing new features here would also create the situation where 2.7 has features not in development, and vice-versa, creating an upgrade dilemma for users (unless we were to port the feature to all supported branches). And adding significant new features to LTS branches can always introduce some risk of destabilising it. So for these reasons, we would normally recommend targeting the development branch for new features (with backports only where there is a strong reason to do so), and then picking up the next stable release that contains the new feature. Is there a particular reason you’re focusing on 2.7, rather than development, or would it be viable for you to add this to development and pick up the next release? Thanks Dave From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Omer Shapira <omer.shapira(a)gmail.com> Date: Monday, 12 October 2020 at 20:04 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Working on TLS handshake record fragmentation (#1840) Hello, My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions: 1. What is the best way to add the feature to MbedTLS 2.7? 2. Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Question 1: Best way to add the feature to MbedTLS 2.7 One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized. If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx? Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches. What is the preferable trade-off in such a situation: a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions? [0] https://github.com/ARMmbed/mbedtls/issues/1840 [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md [2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… -- Sincerely Yours, Omer Shapira

4 years, 6 months

1
0
0 0

Re: [mbed-tls] Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

While waiting for opinions regarding the question of adding features to the LTS versions, I have written a draft design doc. I discussed the "design review process" with Hanno Becker, and we decided to try and use GitHub for the design review. I have created PR #3783 [0], which includes `docs/proposed/hs_fragmentation.md` [1]. I will appreciate your comments, and will update the design doc following the feedback. Once there is clarity on the approach, I will proceed with the implementation PRs. [0] https://github.com/ARMmbed/mbedtls/pull/3783 [1] https://github.com/ARMmbed/mbedtls/pull/3783/commits/8be34f22237ee3cd3c1db2… On Mon, Oct 12, 2020 at 12:04 PM Omer Shapira via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hello, > > My employer (Facebook) is willing to give me some time to TLS handshake > fragmentation support to MbedTLS 2.7 [0] . This would be my first > contribution to MbedTLS, and I have several novice questions: > > 1. What is the best way to add the feature to MbedTLS 2.7? > 2. Trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. > > Question 1: Best way to add the feature to MbedTLS 2.7 > > One constraint that I am facing is the code must be added to the upstream > branch that is as close as possible to the 2.7.xx. My understanding of the > Contribution Guidelines[1] is that while the LTS branches are mostly meant > for the bug fixes, backporting of the new features is welcomed as long as > the API/ABI compatibility is maintained and the disruption to the users is > minimized. > > If adding support to the LTS branches is not advisable, are there any > other possibilities of contributing the code to an upstream branch that is > very close to the 2.7.xx? > > Question 2: Trade-off between the consistency of the fragmentation code > across the branches, vs. the consistency of the branches. > > Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a > trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. The `development` branch > supports variable-length buffers[2] . Variable messages sizes would make > the fragmentation easier in the development branch. In addition, there is > the MPS effort by Hanno Becker which would make the fragmentation support > even easier in the development branch. None of that is present in the 2.7 > or the 2.16 branches. > > What is the preferable trade-off in such a situation: > a. Minimizing the change to the "host" version (2.7 or 2.16), on the > expense the implementation of the feature differ between 2.7 and > `development`, or > b. Minimizing the differences in the implementation of the feature, on > the expense of more intrusive changes to the earlier versions? > > > [0] https://github.com/ARMmbed/mbedtls/issues/1840 > [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md > [2] > https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… > > -- > Sincerely Yours, > Omer Shapira > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > -- Sincerely Yours, Omer Shapira

4 years, 6 months

1
0
0 0

Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

Hello, My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions: 1. What is the best way to add the feature to MbedTLS 2.7? 2. Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Question 1: Best way to add the feature to MbedTLS 2.7 One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized. If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx? Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches. What is the preferable trade-off in such a situation: a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions? [0] https://github.com/ARMmbed/mbedtls/issues/1840 [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md [2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… -- Sincerely Yours, Omer Shapira

4 years, 6 months

1
0
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

4 years, 6 months

1
0
0 0

Re: [mbed-tls] Official bug list

by Janos Follath

Hi Innocenti, The official list of defects is available on github: https://github.com/ARMmbed/mbedtls/issues?q=is%3Aissue+is%3Aopen+label%3Abug The revision of fixing is in the Bugfix sections of the ChangeLog file in the source. Eg. for the latest release: https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/ChangeLog The entries here usually reference the issue number they fixed. Is this something that you can use for your evaluation? Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Innocenti, Michele via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Innocenti, Michele" <michele_innocenti(a)baxter.com> Date: Thursday, 1 October 2020 at 14:04 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Official bug list Hi, We are evaluating Mbed TLS library and we need to know if it’s available an official list of defects and revision of fixing. I’m not looking for CVEs but for bugs in the library. Thanks! Michele

4 years, 6 months

1
0
0 0

Official bug list

by Innocenti, Michele

Hi, We are evaluating Mbed TLS library and we need to know if it's available an official list of defects and revision of fixing. I'm not looking for CVEs but for bugs in the library. Thanks! Michele

4 years, 6 months

1
0
0 0

Re: [mbed-tls] FIPS

by Janos Follath

Hi, There is no FIPS validated/certified version of Mbed TLS. In general most of the components should be very close to FIPS/NIST standards, but I don’t know of any that would have undergone a validation/certification process. 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> Reply to: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com> Date: Thursday, 1 October 2020 at 07:38 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] FIPS Hi, Do we have FIPS compliant for mbedtls; similar to openssl fips? Thanks, Gopi Krishnan

4 years, 6 months

1
0
0 0

FIPS

by Subramanian Gopi Krishnan

Hi, Do we have FIPS compliant for mbedtls; similar to openssl fips? Thanks, Gopi Krishnan

4 years, 6 months

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Frank Bergmann

Hi Gilles, actually I meant that the creator of the PR tries to make a first estimation. Maybe even this could be helpful. :-) Frank On Wed, Sep 30, 2020 at 09:47:41AM +0000, Gilles Peskine via mbed-tls wrote: > Hi Frank, > > Thanks for the suggestion. Sorry for not replying earlier. A time > estimate can help with scheduling, but our problem isn't so much > scheduling as a lack of bandwidth. Also we've found it very difficult to > estimate the time a review will take: some innocuous-looking patches end > up raising time-consuming questions about security or compatibility, > while some large patches turn out to be easy because they don't affect > risky areas much. > > The way we currently work is to schedule large contributions as part of > our sprint planning, but for most reviews we put them in a queue > (https://github.com/orgs/ARMmbed/projects/3). We've found that for our > team, having people pull from that queue works better than designating > reviewers a priori. > > -- > Gilles Peskine > Mbed TLS developer > > On 21/09/2020 07:35, Frank Bergmann via mbed-tls wrote: > > Hi Gilles, > > > > when I ask in our team to review a PR I usually provide an estimation about > > it. Of course a time base estimation and not an agile one in values of > > complexity. ;-) > > One could also provide an estimation about priority. > > Maybe these tiny rules may help somewhat. At least it can provide a better > > overview if you have tons of PRs. > > > > sincerely, > > Frank > > > > On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: > >> Hello, > >> > >> Historically, Mbed TLS has been maintained by Arm as an open-source > >> project, accepting external contributions, but with with priorities and > >> plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an > >> open governance project under the umbrella of TrustedFirmware, with the > >> objective of making it a community led project, allowing community to > >> contribute and collaborate on the design and development of the project. > >> In practice, however, the project effectively still has some barriers of > >> entry. We would like to lift these barriers. > >> > >> The Mbed TLS team at Arm have already identified some concrete actions, > >> filed on the Mbed TLS epic board > >> https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 > >> under “Facilitating community contributions”. A few more should be up > >> soon as the result of some internal brainstorming. > >> > >> We've also identified some problem areas which we're tracking as > >> separate topics. > >> > >> * Probably the biggest topic: review was and is a bottleneck. We are > >> working to streamline the review process where possible, without > >> lowering the quality bar, and to prioritize reviews better over new > >> work. (Having personally often been on both sides of the coin, I can > >> confirm that having a pull request sit around for years without getting > >> reviews is frustrating, and so is seeing all these pull request and not > >> having the time to review them all.) We would also like to enable, > >> encourage and value reviews from people who are not project maintainers. > >> > >> * We will migrate the CI to a publicly available platform hosted by > >> TrustedFirmware. However this platform will not be available until 2021. > >> > >> * We are working on a new documentation platform, where we'll transfer > >> both the information available on the current website and information > >> that is currently recorded in an Arm internal wiki. > >> > >> To all of you who have contributed to Mbed TLS, who have tried, or who > >> are considering it, what difficulties have you encountered? What else > >> can we do to make contributing easier? > >> > >> Best regards, > >> > >> -- > >> Gilles Peskine > >> Mbed TLS developer > >> > >> > >> -- > >> mbed-tls mailing list > >> mbed-tls(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- 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, 6 months

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Gilles Peskine

Hi Frank, Thanks for the suggestion. Sorry for not replying earlier. A time estimate can help with scheduling, but our problem isn't so much scheduling as a lack of bandwidth. Also we've found it very difficult to estimate the time a review will take: some innocuous-looking patches end up raising time-consuming questions about security or compatibility, while some large patches turn out to be easy because they don't affect risky areas much. The way we currently work is to schedule large contributions as part of our sprint planning, but for most reviews we put them in a queue (https://github.com/orgs/ARMmbed/projects/3). We've found that for our team, having people pull from that queue works better than designating reviewers a priori. -- Gilles Peskine Mbed TLS developer On 21/09/2020 07:35, Frank Bergmann via mbed-tls wrote: > Hi Gilles, > > when I ask in our team to review a PR I usually provide an estimation about > it. Of course a time base estimation and not an agile one in values of > complexity. ;-) > One could also provide an estimation about priority. > Maybe these tiny rules may help somewhat. At least it can provide a better > overview if you have tons of PRs. > > sincerely, > Frank > > On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: >> Hello, >> >> Historically, Mbed TLS has been maintained by Arm as an open-source >> project, accepting external contributions, but with with priorities and >> plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an >> open governance project under the umbrella of TrustedFirmware, with the >> objective of making it a community led project, allowing community to >> contribute and collaborate on the design and development of the project. >> In practice, however, the project effectively still has some barriers of >> entry. We would like to lift these barriers. >> >> The Mbed TLS team at Arm have already identified some concrete actions, >> filed on the Mbed TLS epic board >> https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 >> under “Facilitating community contributions”. A few more should be up >> soon as the result of some internal brainstorming. >> >> We've also identified some problem areas which we're tracking as >> separate topics. >> >> * Probably the biggest topic: review was and is a bottleneck. We are >> working to streamline the review process where possible, without >> lowering the quality bar, and to prioritize reviews better over new >> work. (Having personally often been on both sides of the coin, I can >> confirm that having a pull request sit around for years without getting >> reviews is frustrating, and so is seeing all these pull request and not >> having the time to review them all.) We would also like to enable, >> encourage and value reviews from people who are not project maintainers. >> >> * We will migrate the CI to a publicly available platform hosted by >> TrustedFirmware. However this platform will not be available until 2021. >> >> * We are working on a new documentation platform, where we'll transfer >> both the information available on the current website and information >> that is currently recorded in an Arm internal wiki. >> >> To all of you who have contributed to Mbed TLS, who have tried, or who >> are considering it, what difficulties have you encountered? What else >> can we do to make contributing easier? >> >> Best regards, >> >> -- >> Gilles Peskine >> Mbed TLS developer >> >> >> -- >> mbed-tls mailing list >> mbed-tls(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 6 months

1
0
0 0

Re: [mbed-tls] Proposed change: no longer credit contributors in the ChangeLog file

by Gilles Peskine

Hello, We're going ahead with this new process. For changes made since the last release (2.24.0 and corresponding updates to long-time support branches), the ChangeLog file will only record user-visible changes, and entries will not be used to credit contributors. We're updating ChangeLog.d/00README.md accordingly (https://github.com/ARMmbed/mbedtls/pull/3726). -- Gilles Peskine Mbed TLS developer On 20/09/2020 23:41, Gilles Peskine via mbed-tls wrote: > Hello, > > The Mbed TLS team is soliciting feedback on a proposed change of our > contributor acknowledgement policy. > > Background: our current policy is to acknowledge all contributors who > are not Arm employees in the ChangeLog files. This is a tradition that > dates back from when the version control history of Mbed TLS (then > PolarSSL) was not public. > > Proposed change: the ChangeLog file will no longer mention who > contributed a patch (“Contributed by …”). A patch will require a > ChangeLog entry only if it makes a user-visible changes, regardless of > who contributed it. We will still credit reporters in the ChangeLog > file, at least for security issues. > > Rationale: the ChangeLog file had a dual purpose: informing users, and > acknowledging contributors. It will now have the single purpose of > informing users. There are better ways of acknowledging contributors > nowadays: the Git history is public, and your contributions are visible > from your GitHub profile. (Note that we don't squash commits, and > attempt to preserve authorship as much as possible when we have to > rebase a patch.) Furthermore, writing a good ChangeLog entry often turns > out to require some back-and-forth, so lessening this requirement will > make it easier to accept contributions and to merge them faster (this is > in fact our primary motivation for the change). > > We are also thinking of creating an acknowledgement page out-of-tree. It > isn't clear yet what its scope would be, but it would include > acknowledging contributions in the form of reviews, which we wish to > encourage. (Please stay tuned for future announcements and discussions > regarding the Mbed TLS review process.) > > Question to potential contributors, or people who have participated in > other open-source projects: do you think that there is any value in > keeping acknowledgements in a file that is distributed with Mbed TLS? Is > there any value in maintaining an exhaustive list of contributors in a > form other than the Git history? > > Best regards, >

4 years, 6 months

1
0
0 0

Information about CI failures on pull requests to Mbed TLS

by Gilles Peskine

Hello, If you've made a pull request to Mbed TLS, you've noticed that some of the continuous integration happens on a private server run by Arm. For jobs that ran since yesterday, if there are failures, you can now see the name of the failed tasks next to “PR-NNN-head TLS Testing” or “PR-NNN-merge TLS Testing”. See https://developer.trustedfirmware.org/w/mbed-tls/testing/ci/#identifying-je… for more details. If this isn't enough, an Arm employee can copy the logs from the server. Please ask in a comment. We hope to post logs automatically (https://github.com/ARMmbed/mbedtls/issues/3633) but I can't give a due date for that. We are planning to move to a public server run by TrustedFirmware, but this can't happen until some time in 2021. Please bear with us in the meantime, and thank you for your contributions. -- Gilles Peskine Mbed TLS developer

4 years, 6 months

1
0
0 0

MbedTLS Webserver

by Thomas Schwarz

Hello everyone, I want to set up a webserver on my ESP32 Dev Module based von MbedTLS. Therefore I view the ssl_server example on github. Now my question: How can I connect the ssl_server to my local WIFI-network. What extra code do I need? And where is the SSID and the password configurable? Thanks for your help! Best regards Thomas Tel.: +49833460134418 MULTIVAC Info Box MULTIVAC Sepp Haggenmüller SE & Co. KG - Bahnhofstr. 4 - D-87787 Wolfertschwenden - Germany Tel.: +49(0)8334/601-0 - Fax: +49(0)8334/601-199 - multivac(a)multivac.de Kommanditgesellschaft Sitz: 87787 Wolfertschwenden Amtsgericht: Memmingen HRA 8040 USt-IdNr.: DE 129082475 - Steuer-Nr.: 138/169/51105 - WEEE-Reg.-Nr.: DE 16576440 Persönlich haftende Gesellschafterin: MULTIVAC Sepp Haggenmüller Verwaltungs SE Sitz: 87787 Wolfertschwenden Amtsgericht: Memmingen HRB 16659 Geschäftsführende Direktoren: Guido Spix, Christian Traumann Verwaltungsratsvorsitzender: Elmar Fischer Bankverbindung: Deutsche Bank Memmingen . IBAN: DE 31 7337 0008 0123 6330 00 . BIC: DEUT DE MM 733 Banner

4 years, 7 months

1
0
0 0

DTLS server

by Mehdi Karimi

I am using v16 of the mbedTLS library to setup DTLS server. However, I observe that the handshake does not work well and there are several issues starting with the cookie exchange. Do I necessarily have to update to the latest version of mbedTLS? Are there known issues with DTLS server setup using previous versions (as far as I could tell from the ChangeLog). Thanks Mehdi

4 years, 7 months

1
0
0 0

Re: [mbed-tls] Proposed change: no longer credit contributors in the ChangeLog file

by Frank Bergmann

Hi Gilles, as you said: Git is public. As long as it is kept public there's no reason to "duplicate details". My 2 cents. sincerely, Frank On Sun, Sep 20, 2020 at 09:41:26PM +0000, Gilles Peskine via mbed-tls wrote: > Hello, > > The Mbed TLS team is soliciting feedback on a proposed change of our > contributor acknowledgement policy. > > Background: our current policy is to acknowledge all contributors who > are not Arm employees in the ChangeLog files. This is a tradition that > dates back from when the version control history of Mbed TLS (then > PolarSSL) was not public. > > Proposed change: the ChangeLog file will no longer mention who > contributed a patch (“Contributed by …”). A patch will require a > ChangeLog entry only if it makes a user-visible changes, regardless of > who contributed it. We will still credit reporters in the ChangeLog > file, at least for security issues. > > Rationale: the ChangeLog file had a dual purpose: informing users, and > acknowledging contributors. It will now have the single purpose of > informing users. There are better ways of acknowledging contributors > nowadays: the Git history is public, and your contributions are visible > from your GitHub profile. (Note that we don't squash commits, and > attempt to preserve authorship as much as possible when we have to > rebase a patch.) Furthermore, writing a good ChangeLog entry often turns > out to require some back-and-forth, so lessening this requirement will > make it easier to accept contributions and to merge them faster (this is > in fact our primary motivation for the change). > > We are also thinking of creating an acknowledgement page out-of-tree. It > isn't clear yet what its scope would be, but it would include > acknowledging contributions in the form of reviews, which we wish to > encourage. (Please stay tuned for future announcements and discussions > regarding the Mbed TLS review process.) > > Question to potential contributors, or people who have participated in > other open-source projects: do you think that there is any value in > keeping acknowledgements in a file that is distributed with Mbed TLS? Is > there any value in maintaining an exhaustive list of contributors in a > form other than the Git history? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- 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, 7 months

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Frank Bergmann

Hi Gilles, when I ask in our team to review a PR I usually provide an estimation about it. Of course a time base estimation and not an agile one in values of complexity. ;-) One could also provide an estimation about priority. Maybe these tiny rules may help somewhat. At least it can provide a better overview if you have tons of PRs. sincerely, Frank On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: > Hello, > > Historically, Mbed TLS has been maintained by Arm as an open-source > project, accepting external contributions, but with with priorities and > plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an > open governance project under the umbrella of TrustedFirmware, with the > objective of making it a community led project, allowing community to > contribute and collaborate on the design and development of the project. > In practice, however, the project effectively still has some barriers of > entry. We would like to lift these barriers. > > The Mbed TLS team at Arm have already identified some concrete actions, > filed on the Mbed TLS epic board > https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 > under “Facilitating community contributions”. A few more should be up > soon as the result of some internal brainstorming. > > We've also identified some problem areas which we're tracking as > separate topics. > > * Probably the biggest topic: review was and is a bottleneck. We are > working to streamline the review process where possible, without > lowering the quality bar, and to prioritize reviews better over new > work. (Having personally often been on both sides of the coin, I can > confirm that having a pull request sit around for years without getting > reviews is frustrating, and so is seeing all these pull request and not > having the time to review them all.) We would also like to enable, > encourage and value reviews from people who are not project maintainers. > > * We will migrate the CI to a publicly available platform hosted by > TrustedFirmware. However this platform will not be available until 2021. > > * We are working on a new documentation platform, where we'll transfer > both the information available on the current website and information > that is currently recorded in an Arm internal wiki. > > To all of you who have contributed to Mbed TLS, who have tried, or who > are considering it, what difficulties have you encountered? What else > can we do to make contributing easier? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- 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, 7 months

1
0
0 0

Building a collaborative Mbed TLS community

by Gilles Peskine

Hello, Historically, Mbed TLS has been maintained by Arm as an open-source project, accepting external contributions, but with with priorities and plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an open governance project under the umbrella of TrustedFirmware, with the objective of making it a community led project, allowing community to contribute and collaborate on the design and development of the project. In practice, however, the project effectively still has some barriers of entry. We would like to lift these barriers. The Mbed TLS team at Arm have already identified some concrete actions, filed on the Mbed TLS epic board https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 under “Facilitating community contributions”. A few more should be up soon as the result of some internal brainstorming. We've also identified some problem areas which we're tracking as separate topics. * Probably the biggest topic: review was and is a bottleneck. We are working to streamline the review process where possible, without lowering the quality bar, and to prioritize reviews better over new work. (Having personally often been on both sides of the coin, I can confirm that having a pull request sit around for years without getting reviews is frustrating, and so is seeing all these pull request and not having the time to review them all.) We would also like to enable, encourage and value reviews from people who are not project maintainers. * We will migrate the CI to a publicly available platform hosted by TrustedFirmware. However this platform will not be available until 2021. * We are working on a new documentation platform, where we'll transfer both the information available on the current website and information that is currently recorded in an Arm internal wiki. To all of you who have contributed to Mbed TLS, who have tried, or who are considering it, what difficulties have you encountered? What else can we do to make contributing easier? Best regards, -- Gilles Peskine Mbed TLS developer

4 years, 7 months

1
0
0 0

Proposed change: no longer credit contributors in the ChangeLog file

by Gilles Peskine

Hello, The Mbed TLS team is soliciting feedback on a proposed change of our contributor acknowledgement policy. Background: our current policy is to acknowledge all contributors who are not Arm employees in the ChangeLog files. This is a tradition that dates back from when the version control history of Mbed TLS (then PolarSSL) was not public. Proposed change: the ChangeLog file will no longer mention who contributed a patch (“Contributed by …”). A patch will require a ChangeLog entry only if it makes a user-visible changes, regardless of who contributed it. We will still credit reporters in the ChangeLog file, at least for security issues. Rationale: the ChangeLog file had a dual purpose: informing users, and acknowledging contributors. It will now have the single purpose of informing users. There are better ways of acknowledging contributors nowadays: the Git history is public, and your contributions are visible from your GitHub profile. (Note that we don't squash commits, and attempt to preserve authorship as much as possible when we have to rebase a patch.) Furthermore, writing a good ChangeLog entry often turns out to require some back-and-forth, so lessening this requirement will make it easier to accept contributions and to merge them faster (this is in fact our primary motivation for the change). We are also thinking of creating an acknowledgement page out-of-tree. It isn't clear yet what its scope would be, but it would include acknowledging contributions in the form of reviews, which we wish to encourage. (Please stay tuned for future announcements and discussions regarding the Mbed TLS review process.) Question to potential contributors, or people who have participated in other open-source projects: do you think that there is any value in keeping acknowledgements in a file that is distributed with Mbed TLS? Is there any value in maintaining an exhaustive list of contributors in a form other than the Git history? Best regards, -- Gilles Peskine Mbed TLS developer

4 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls