- mbed-tls - lists.trustedfirmware.org

by Frank Bergmann

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

3 years, 7 months

1
0
0 0

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

by Gilles Peskine

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

3 years, 7 months

1
0
0 0

Failures: all_sh-ubuntu-16.04-test_memory_buffer_allocator

by Gábor Tóth

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

3 years, 7 months

1
0
0 0

Requesting a sample code: adding two numbers using mbedtls_mpi_add_int?

by Shariful Alam

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

3 years, 7 months

1
0
0 0

Overring bignum, aka MBEDTLS_BIGNUM_ALT?

by Fabio Utzig

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

3 years, 7 months

1
0
0 0

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

by Gilles Peskine

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

3 years, 7 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

3 years, 7 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

3 years, 7 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 >

3 years, 7 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 >

3 years, 7 months

1
0
0 0

2024

2023

2022

2021

2020

mbed-tls