- mbed-tls - lists.trustedfirmware.org

Help troubleshooting mbedtls_pk_sign() returned -17280 (-0x4380)

by Martin Man

Hi guys, I have a mbetls based server client application (DTLS) written in Apple Swift language, wrapping the mbedtls C api, running just fine for many years now on iOS, Android, and Linux. We have been compiling the code with Swift 5.0, 5.1, 5.2, 5.3, 5.4 in both release and debug mode. Recently I just recompiled my code with Swift 5.5 in release mode, and my handshakes started failing on the Linux server with cryptic mbedtls_pk_sign() returned -17280 (-0x4380). When I take the same code and recompile in debug mode (-Onone) it works as expected. The same code compiled with Swift+C for iOS and macOS still works in both debug and release mode on both client/server. If I understand the compilation process correctly, the Swift Package Manager that we use to wrap mbedtls simply uses CMakeLists.txt to compile mbedtls and pick up the right flags. I am attaching excerpt from the log where the server part of the handshake fails (in release mode) and succeeds (in debug mode). I am certain this is probably caused by my code and how I wrap C mbedtls sources in Swift, but I can not yet rule out a bug in Swift/C compiler part for Linux which from time to time does have bugs related to code optimization. Could any good soul who understands the parts of the code below point me in the direction where to look and why would the mbedtls_pk_sign fail this way? What parts of the SSL context does it use? I will deep dive into the code to see whether this can be caused by memory corruption or anything else. It’s on LTS mbedtls-2.16.11. Could I run some tests to perhaps verify that mbedtls is compiled and working correctly? thanks for any help, Martin — failing handshake — Dec 7 15:54:53 ssl_srv.c:3296 => write server key exchange Dec 7 15:54:53 ssl_srv.c:3074 ECDHE curve: secp521r1 Dec 7 15:54:53 ssl_srv.c:3100 value of 'ECDH: Q(X)' (521 bits) is: Dec 7 15:54:53 ssl_srv.c:3100 01 d0 5f 4a fa 12 f8 46 75 fb 3e 38 db ba 88 ff Dec 7 15:54:53 ssl_srv.c:3100 73 72 79 78 21 dd 9f ac ac 02 db e7 7e 91 6e 5c Dec 7 15:54:53 ssl_srv.c:3100 06 ed 77 19 42 f1 11 6a f5 75 04 20 d8 51 50 a5 Dec 7 15:54:53 ssl_srv.c:3100 8f 5a 3d 8c b3 c0 15 df cc d7 5b e5 eb 04 2e b6 Dec 7 15:54:53 ssl_srv.c:3100 2f e7 Dec 7 15:54:53 ssl_srv.c:3100 value of 'ECDH: Q(Y)' (518 bits) is: Dec 7 15:54:53 ssl_srv.c:3100 26 c1 52 f0 b6 20 4c aa 53 7c aa 27 12 5f 72 7f Dec 7 15:54:53 ssl_srv.c:3100 11 ea a9 34 9a f5 ef 63 28 76 d8 52 4e 31 a3 13 Dec 7 15:54:53 ssl_srv.c:3100 52 a5 c9 52 5f 6b 41 b6 7e 47 0e 2a 68 c5 e5 80 Dec 7 15:54:53 ssl_srv.c:3100 14 27 ad aa 96 5b 89 41 55 5b d5 52 61 66 8c 06 Dec 7 15:54:53 ssl_srv.c:3100 4b Dec 7 15:54:53 ssl_srv.c:3163 pick hash algorithm 8 for signing Dec 7 15:54:53 ssl_srv.c:3201 dumping 'parameters hash' (64 bytes) Dec 7 15:54:53 ssl_srv.c:3201 0000: 55 c8 d2 5c 83 d8 6b e3 9f 9c b2 f4 e7 f7 4d 26 U..\..k.......M& Dec 7 15:54:53 ssl_srv.c:3201 0010: b4 ce c9 df c2 ae 7a 60 cb e8 02 13 d5 6d d8 ec ......z`.....m.. Dec 7 15:54:53 ssl_srv.c:3201 0020: 48 72 77 9f e2 69 4e f5 b4 1d db 9a 75 2a 5e c7 Hrw..iN.....u*^. Dec 7 15:54:53 ssl_srv.c:3201 0030: e1 1b 66 fc a6 ff 37 c6 6d 42 9b b3 cf 63 bb 0e ..f...7.mB...c.. Dec 7 15:54:53 ssl_srv.c:3274 mbedtls_pk_sign() returned -17280 (-0x4380) Dec 7 15:54:53 ssl_tls.c:8219 <= handshake — successful handshake — Dec 7 16:13:52 ssl_srv.c:3296 => write server key exchange Dec 7 16:13:52 ssl_srv.c:3074 ECDHE curve: secp521r1 Dec 7 16:13:52 ssl_srv.c:3100 value of 'ECDH: Q(X)' (519 bits) is: Dec 7 16:13:52 ssl_srv.c:3100 52 5f 4e 78 48 bd be 6a e4 98 21 30 ce 1c ba 08 Dec 7 16:13:52 ssl_srv.c:3100 b7 ae 88 d3 ff c9 c4 a5 8c 13 1e 73 5b 1f 08 60 Dec 7 16:13:52 ssl_srv.c:3100 7c 51 a7 ec 91 54 d7 52 f3 55 6a 34 92 cf 92 e8 Dec 7 16:13:52 ssl_srv.c:3100 c8 39 33 5e d3 46 3d 89 e7 6d 8f 41 d9 e0 67 e6 Dec 7 16:13:52 ssl_srv.c:3100 7c Dec 7 16:13:52 ssl_srv.c:3100 value of 'ECDH: Q(Y)' (520 bits) is: Dec 7 16:13:52 ssl_srv.c:3100 87 48 29 20 93 8e f8 9a a9 54 70 26 58 79 9d 67 Dec 7 16:13:52 ssl_srv.c:3100 8c ec 0f 06 ae 73 13 40 72 58 fe c1 6e 14 b4 48 Dec 7 16:13:52 ssl_srv.c:3100 55 a1 27 74 9d 63 36 aa db 80 29 f8 ab 9c 64 ba Dec 7 16:13:52 ssl_srv.c:3100 f9 0a 19 af 9a 65 6f 02 96 c6 53 4d 49 4f b4 f5 Dec 7 16:13:52 ssl_srv.c:3100 46 Dec 7 16:13:52 ssl_srv.c:3163 pick hash algorithm 8 for signing Dec 7 16:13:52 ssl_srv.c:3201 dumping 'parameters hash' (64 bytes) Dec 7 16:13:52 ssl_srv.c:3201 0000: e1 65 f4 f0 a6 a3 67 7d 32 55 ed 2a 13 08 71 8a .e....g}2U.*..q. Dec 7 16:13:52 ssl_srv.c:3201 0010: 7e 13 f6 30 85 ed c3 c9 10 e8 b2 43 75 bc 6c 24 ~..0.......Cu.l$ Dec 7 16:13:52 ssl_srv.c:3201 0020: 8f fb d8 90 cb 53 7f 13 53 13 1b f4 eb bd 38 5c .....S..S.....8\ Dec 7 16:13:52 ssl_srv.c:3201 0030: ec 46 c2 0c a9 93 5b 60 5e 5d 81 f2 b3 b0 b5 a8 .F....[`^]...... Dec 7 16:13:52 ssl_srv.c:3361 dumping 'my signature' (256 bytes) Dec 7 16:13:52 ssl_srv.c:3361 0000: 7a a7 0f 17 79 33 36 b7 0c 17 84 5b cc ca 1c 0c z...y36....[.... Dec 7 16:13:52 ssl_srv.c:3361 0010: cb f5 56 80 ea 5d 7f cf ab 86 d5 f9 91 36 0e 68 ..V..].......6.h Dec 7 16:13:52 ssl_srv.c:3361 0020: 76 c6 c0 4b 77 bf 28 e7 b8 c0 a7 de ea d8 a0 30 v..Kw.(........0 Dec 7 16:13:52 ssl_srv.c:3361 0030: 3a b3 4e 24 ea e0 c8 0b e7 ad ba 4d 35 30 c0 39 :.N$.......M50.9 Dec 7 16:13:52 ssl_srv.c:3361 0040: a8 ff f0 6d 8f 28 db fc 5e c3 fb 21 fe 76 dd 07 ...m.(..^..!.v.. Dec 7 16:13:52 ssl_srv.c:3361 0050: 1b 2c 58 fe 7b 0a f5 72 49 d9 d1 9a 10 af 29 21 .,X.{..rI.....)! Dec 7 16:13:52 ssl_srv.c:3361 0060: 7a d9 01 a4 99 01 de 6e ae fd 76 ce b9 64 84 49 z......n..v..d.I Dec 7 16:13:52 ssl_srv.c:3361 0070: 96 97 2d 3a 15 ed 5b de d5 99 9d 1b eb 4c 1a aa ..-:..[......L.. Dec 7 16:13:52 ssl_srv.c:3361 0080: a8 e6 36 29 bd 67 b0 50 91 6e b8 cb 0a 42 4a 79 ..6).g.P.n...BJy Dec 7 16:13:52 ssl_srv.c:3361 0090: 4a 65 ae 95 d0 bc 5a e1 e7 75 2a f9 ba 51 1c 2c Je....Z..u*..Q., Dec 7 16:13:52 ssl_srv.c:3361 00a0: ff 67 e3 df eb a0 d7 6c d2 cf 71 d2 ea 24 7c 16 .g.....l..q..$|. Dec 7 16:13:52 ssl_srv.c:3361 00b0: f8 5b 72 83 56 a9 48 e1 b6 cd d0 bd dd 20 23 d5 .[r.V.H...... #. Dec 7 16:13:52 ssl_srv.c:3361 00c0: 80 c4 bd 6e 42 1c 61 b2 e4 41 01 ce c8 85 26 21 ...nB.a..A....&! Dec 7 16:13:52 ssl_srv.c:3361 00d0: b4 0a 5e fe 50 0d 6f 45 a8 fe 15 18 87 e3 ae b3 ..^.P.oE........ Dec 7 16:13:52 ssl_srv.c:3361 00e0: ac 46 c5 c6 bb bc 70 1b 32 b7 15 c5 3d fb 09 1e .F....p.2...=... Dec 7 16:13:52 ssl_srv.c:3361 00f0: 8f 69 f7 e7 a8 86 4d 0b 87 ea 4b fe 08 7e 00 0b .i....M...K..~.. Dec 7 16:13:52 ssl_tls.c:3289 => write handshake message Dec 7 16:13:52 ssl_tls.c:2917 => ssl_flight_append Dec 7 16:13:52 ssl_tls.c:2953 <= ssl_flight_append Dec 7 16:13:52 ssl_tls.c:3425 <= write handshake message Dec 7 16:13:52 ssl_srv.c:3380 <= write server key exchange

4 years, 4 months

2
2
0 0

Benchmark on esp32

by Marco Portoni

Hi, Is it possible to run the benchmark of all cyphers natively on a ESP32 board? I have already run them on laptop but my goal is to run them on esp32, using for example tool like espifd.

4 years, 4 months

1
0
0 0

lists.trustedfirmware.org

by Philip Colmer

Hello You are receiving this email because you are subscribed to one or more mailing lists on lists.trustedfirmware.org. The purpose of this email is to let you know that the software on the server is being upgraded between Wednesday 29th December and Friday 31st December. During that time, the server will be unavailable and any email sent to a list on the server will be queued for later delivery. After the upgrade has been completed, you will receive a follow-up email from me to confirm that the upgrade has been completed and to provide you with instructions on how to set up your account on the new server. With the new software, you have one account regardless of how many mailing lists you are subscribed to. Regards Philip Colmer Director, Information Services Linaro

4 years, 4 months

1
0
0 0

Output a mbedtls_x509_crt?

by Felipe Gasper

Hello, Is it possible to output a mbedtls_x509_crt as PEM or DER? I’ve been combing the API docs but don’t see how I can do this export. I see controls for exporting a newly-built cert, but not one that comes from, e.g., mbedtls_ssl_get_peer_cert(). Thank you! Cheers, -Felipe Gasper

4 years, 4 months

2
3
0 0

What am I doing wrong?

by Felipe Gasper

https://gist.github.com/FGasper/43758d13e987518009d18ec8951ffcbb ^^ With 3.0.0 this prints: seeded entropy mbedtls connected trust loaded ok SNI set ok handshake tried handshake: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed … but if I switch to the development branch, it works. Same trust chain, same code … but the production code fails while the dev one works … Am I just “holding it wrong”? Thank you in advance! -FG

4 years, 4 months

1
1
0 0

MbedTLS - which protocols are advisable to support, and memory usage

by Peter

Hi All, I am new here. With a colleague, I am working on a product which previously used PolarSSL but was later changed to MbedTLS which, in the ST ARM 32F417 implementation, is believed to be less buggy. It is working ok as far as we have got, but we are finding that as well as needing some 100k more FLASH, it needs nearly 50k of RAM, which on the 32F417 (128k RAM) would normally be OK but due to other required functionality it leaves us just 10k. The architecture we are using for MbedTLS is a 48k (48k was found to be the smallest that works) static buffer within which TLS runs its own heap. I am aware that in the most generic case one has to have enough for one 16k buffer (plus a bit) for HTTPS, but what concerns me is that there appears to be no way to determine the worst case memory usage, across various usage scenarios. It would also be great to reduce this 48k to say 30k. Some of the protocols we know we don't need (e.g. PPP) but within any of them there is the question of which cipher suite needs supporting. What is the minimum cipher suite required to be able to use MbedTLS as an HTTPS client for use with typical current cloud-based file storage or data logging APIs such as Dropbox, Google Drive, Loggly etc? And what is the recommended minimum cipher suite required to implement an HTTPS server that would be able to negotiate a session with most current web-browsers? The goal is to ideally reduce both RAM and code size requirements for use in an embedded device that needs to work both as a general purpose server and client, without requiring support for multiple concurrent sessions. The other thing is that even the ST port of MbedTLS doesn't appear to make use of ST CPU hardware features such as AES256, DES, etc, which the 32F417 has in hardware. This speeds things up hugely but much more importantly in our case, saves a lot of RAM. For example AES256 can use about 10k if done in software. Thank you very much in advance for any input on what can be done. Peter

4 years, 4 months

1
0
0 0

Question about a research project: ESP32 mbed-tls

by Marco Portoni

Hello, I am Marco Portoni and I am working on a thesis research for the University of Study of Milan. It is focused on cryptographic libraries in the IoT world, and my question is: is it possible to run the benchmark on a ESP32? I have already runned the benchmark on 2 of my laptops to test and collected the results, but my ultimate goal is to make the benchmark run on the ESP. Is it possible to do it? Thanks for every help! Marco

4 years, 4 months

1
0
0 0

Build shared on macOS?

by Felipe Gasper

Hello, I’m trying to build shared from git on macOS and having no luck. I’m doing: > mkdir build; cd build > cmake DUSE_SHARED_MBEDTLS_LIBRARY=On .. … > make … > ls -la library total 2944 drwxr-xr-x 10 felipe staff 320 Dec 1 08:49 . drwxr-xr-x 15 felipe staff 480 Dec 1 08:49 .. drwxr-xr-x 8 felipe staff 256 Dec 1 08:49 CMakeFiles -rw-r--r-- 1 felipe staff 92755 Dec 1 08:49 Makefile -rw-r--r-- 1 felipe staff 2942 Dec 1 08:49 cmake_install.cmake -rw-r--r-- 1 felipe staff 34055 Dec 1 08:49 error.c -rw-r--r-- 1 felipe staff 916112 Dec 1 08:49 libmbedcrypto.a -rw-r--r-- 1 felipe staff 315856 Dec 1 08:49 libmbedtls.a -rw-r--r-- 1 felipe staff 104072 Dec 1 08:49 libmbedx509.a -rw-r--r-- 1 felipe staff 26265 Dec 1 08:49 version_features.c Am I just missing something? It seems like I’m following what the README says to do; I also did `export SHARED=1` just in case, but that made no difference. Thank you in advance! -FG

4 years, 4 months

3
3
0 0

Re: [mbed-tls] End of Life of LTS branch 2.16

by Dave Rodgman

Hi Radhika, We do not plan to extend support for Mbed TLS 2.16 beyond the three year support period. We do plan to release a 2.x LTS (probably 2.28) alongside the final 2.16 release, so that we always have an LTS available. Regards Dave Rodgman From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Radhika Jandhyala via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Radhika Jandhyala <radhikaj(a)microsoft.com> Date: Monday, 22 November 2021 at 10:50 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] End of Life of LTS branch 2.16 Hi, I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project. Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022? https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this? We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes. Thank you very much! Radhika

4 years, 4 months

2
2
0 0

Mbed TLS long term support release plans

by Dave Rodgman

Hi, Mbed TLS 2.16 LTS is approaching the end of its support period – it was originally announced that it would be maintained for at least 3 years up until the end of 2021 – and currently there is no other LTS branch. To ensure that there is no period of time without a supported LTS branch, we plan to release 2.28 LTS in the near future (which will have the usual 3 year support period). We will continue supporting 2.16 LTS until this is available. The expectation is that as 2.28 will be API-compatible with 2.16, users of 2.16 LTS will be able to upgrade to 2.28 very easily. Progress towards 2.28 LTS can be followed here: https://github.com/orgs/ARMmbed/projects/18#column-15836286 Dave Rodgman

4 years, 4 months

1
0
0 0

End of Life of LTS branch 2.16

by Radhika Jandhyala

Hi, I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project. Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022? https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this? We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes. Thank you very much! Radhika

4 years, 5 months

1
0
0 0

PSA Crypto non-optional in Mbed TLS 3.1

by Manuel Pegourie-Gonnard

Hi, We'd like to announce a change we intend to make: starting with Mbed TLS 3.1, it will no longer be possible to build with TLS, X.509, or PK without support for PSA Crypto. Details: currently, use of PSA Crypto APIs from the TLS, X.509 and PK layers is controlled by the option MBEDTLS_USE_PSA_CRYPTO. When this option is disabled (which is the default), it's possible to build without MBEDTLS_PSA_CRYPTO_C. Starting with 3.1, we intend to start making TLS, X.509 and PK use PSA Crypto unconditionally, so MBEDTLS_PSA_CRYPTO_C will be automatically enabled in the build as soon as TLS, X.509 or PK is enabled. Impact: for users who already build with PSA Crypto enabled (the default), no impact. For users who currently disable MBEDTLS_PSA_CRYPTO_C in their configuration, starting with 3.1 there will be no functional changes, but the size of the built library will increase due to the additional features enabled. The increase depends on the configuration, application, platform, and toolchain, but the order of magnitude currently ranges from about 9 KB for a minimal TLS configuration with LTO (link-time optimisation) to about 30 KB for a full configuration without link-time garbage collection (though size-constrained devices are very unlikely to use such a configuration); we aim to reduce this overhead in the future. Rationale: maintaining two versions of every cryptographic operation in upper layers (one PSA, one non-PSA) imposes a significant burden on new developments. By removing that burden, we hope to progress faster on things that are more important in the long run, including better integration of PSA Crypto in TLS and X.509, and future code size optimisation of PSA Crypto. We realise the impact on users who were excluding PSA Crypto is significant. We're going to release Mbed TLS 2.28 in the coming months, which is not affected by this change and will receive bug fixes and security fixes for at least 3 years; we hope it provides an acceptable fall-back solution to affected users. In the long run, PSA Crypto will become the only Crypto API we offer; we want to make its footprint as small as possible considering its feature set and we hope this change will enable us to make faster progress towards that goal. Best regards, Manuel Pégourié-Gonnard for the Mbed TLS team.

4 years, 5 months

1
0
0 0

About `MBEDTLS_ALLOW_PRIVATE_ACCESS`

by Aditya Patwardhan

Hi, While working on updating mbedtls to v3.0, I saw that the internal fields in MBEDTLS have been made private. ( ref- here<https://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guid…>). It says there and I quote "As a last resort, you can access the field foo of a structure bar by writing bar.MBEDTLS_PRIVATE(foo). Note that you do so at your own risk, since such code is likely to break in a future minor version of Mbed TLS.” I just wanted to know if there is any alternative solution to this, rather than using `MBEDTLS_PRIVATE` everywhere. I know the next release of mbedtls probably plans to fix this with appropriate solution. But we wanted to push out our feature branch As early as possible. I saw in the PR<https://github.com/zephyrproject-rtos/zephyr/pull/37753> in zephyr RTOS about updating to mbedtls-3.0. They have just added this line<https://github.com/ceolin/zephyr/blob/5bf3128a9703561e578651218f5bcdafb96f8…> #if !defined(MBEDTLS_ALLOW_PRIVATE_ACCESS) #define MBEDTLS_ALLOW_PRIVATE_ACCESS # endif Is this an alternative solution to using `MBEDTLS_PRIVATE` for accessing a private field. If yes, can somebody please point me to respective document as this would greatly reduce our code-changes. I understand there is some discussion going on in mbedtls about this change, and appropriate getter-setter functions shall be provided. But we wanted to push out out feature branch for early testing. Thanks and Regards, Aditya

4 years, 5 months

2
2
0 0

Mbed TLS Tech Forum

by Dave Rodgman

Hi, On Monday 8th we will have the next Mbed TLS Tech Forum. Please reply to the list if you have any agenda topics to raise. As a starter for the agenda, we will likely discuss: https://github.com/ARMmbed/mbedtls/pull/5067 Proposal for driver dispatch code gen Dave Rodgman Zoom details below. The call will be recorded and made available on the TF website : https://www.trustedfirmware.org/meetings/ Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt

4 years, 5 months

1
0
0 0

mbedtls client: TLS 1.2 Client Hello triggers a -0x7780 fatal internal server error...?

by secretimap＠nickpelling.com

Hi everyone, The company I’m working for uses mbedtls to drive an embedded TLS server (for HTTPS): but now needs the same device to also act as a TLS client for logging in to remote servers (e.g. for LDAP etc). My embedded test code tries (but fails) to connect to a remote HTTPS server on port 443: I can connect to the same server via openssl on a desktop command line, so it seems to be working. Basically, the client hello message goes out fine (for brevity, I’ve skipped all the ciphersuites, but note that the list does contain the 0xC030 ciphersuite that desktop openssl is able to connect to OK): .ssl_cli.c:934: client hello, got 25 ciphersuites (excluding SCSVs) .ssl_cli.c:943: adding EMPTY_RENEGOTIATION_INFO_SCSV .ssl_cli.c:992: client hello, compress len.: 1 .ssl_cli.c:994: client hello, compress alg.: 0 .ssl_cli.c:186: client hello, adding signature_algorithms extension .ssl_cli.c:271: client hello, adding supported_elliptic_curves extension .ssl_cli.c:336: client hello, adding supported_point_formats extension .ssl_cli.c:518: client hello, adding encrypt_then_mac extension .ssl_cli.c:552: client hello, adding extended_master_secret extension .ssl_cli.c:585: client hello, adding session ticket extension .ssl_cli.c:1071: client hello, total extension length: 52 0000: 16 03 01 00 95 01 00 00 91 03 03 16 e9 7a ea aa 0010: 31 81 60 b6 a8 d3 32 93 a4 50 ca f3 e0 66 f8 47 0020: 56 95 0c cd a0 db b6 0e ae a7 d4 00 00 34 c0 30 0030: 00 9f c0 ad c0 9f c0 24 c0 28 00 6b c0 0a c0 14 0040: 00 39 c0 af c0 a3 c0 2b c0 2f 00 9e c0 ac c0 9e 0050: c0 23 c0 27 00 67 c0 09 c0 13 00 33 c0 ae c0 a2 0060: 00 ff 01 00 00 34 00 0d 00 16 00 14 06 03 06 01 0070: 05 03 05 01 04 03 04 01 03 03 03 01 02 03 02 01 0080: 00 0a 00 04 00 02 00 17 00 0b 00 02 01 00 00 16 0090: 00 00 00 17 00 00 00 23 00 00 However, the server hello that comes back is both unhappy and unhelpful: .ssl_tls.c:2721: in_left: 5, nb_want: 7 .ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) .ssl_tls.c:2742: <= fetch input .ssl_tls.c:4233: dumping 'input record from network' (7 bytes) .ssl_tls.c:4233: 0000: 15 03 03 00 02 02 50 ......P .ssl_tls.c:5170: got an alert message, type: [2:80] .ssl_tls.c:5178: is a fatal alert message (msg 80) .ssl_tls.c:4369: mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) .ssl_cli.c:1506: mbedtls_ssl_read_record() returned -30592 (-0x7780) Putting the ciphersuites to one side, I suspect that what is happening here is that the (remote) server is complaining about a TLS extension the mbedtls client is either including or omitting. (I’ve already disabled the max fragment extension). But because I can’t see inside the remote server, I can’t tell. ☹ Might the mbedtls TLS client need the supported_versions extension (43) to work with many remote TLS servers? Is this a known issue? I’ve gone through loads of mailing list archive messages here, but haven’t found anything that matches this. Thanks, Nick PS: when OpenSSL connects to the server, the client hello message (that works fine) looks like this in Wireshark: Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 358 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 354 Version: TLS 1.2 (0x0303) Random: [SNIP] GMT Unix Time: Jan 21, 2095 20:50:07.000000000 GMT Standard Time Random Bytes: [SNIP] Session ID Length: 32 Session ID: [SNIP] Cipher Suites Length: 90 Cipher Suites (45 suites) [SNIP!] Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 191 Extension: status_request (len=5) Type: status_request (5) Length: 5 Certificate Status Type: OCSP (1) Responder ID list Length: 0 Request Extensions Length: 0 Extension: supported_groups (len=22) Type: supported_groups (10) Length: 22 Supported Groups List Length: 20 Supported Groups (10 groups) Supported Group: x25519 (0x001d) Supported Group: secp256r1 (0x0017) Supported Group: secp384r1 (0x0018) Supported Group: secp521r1 (0x0019) Supported Group: x448 (0x001e) Supported Group: ffdhe2048 (0x0100) Supported Group: ffdhe3072 (0x0101) Supported Group: ffdhe4096 (0x0102) Supported Group: ffdhe6144 (0x0103) Supported Group: ffdhe8192 (0x0104) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: signature_algorithms (len=34) Type: signature_algorithms (13) Length: 34 Signature Hash Algorithms Length: 32 Signature Hash Algorithms (16 algorithms) [SNIP!] Extension: signature_algorithms_cert (len=34) Type: signature_algorithms_cert (50) Length: 34 Signature Hash Algorithms Length: 32 Signature Hash Algorithms (16 algorithms) [SNIP!] Extension: status_request_v2 (len=9) Type: status_request_v2 (17) Length: 9 Certificate Status List Length: 7 Certificate Status Type: OCSP Multi (2) Certificate Status Length: 4 Responder ID list Length: 0 Request Extensions Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: supported_versions (len=5) Type: supported_versions (43) Length: 5 Supported Versions length: 4 Supported Version: TLS 1.3 (0x0304) Supported Version: TLS 1.2 (0x0303) Extension: psk_key_exchange_modes (len=2) Type: psk_key_exchange_modes (45) Length: 2 PSK Key Exchange Modes Length: 1 PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1) Extension: key_share (len=38) Type: key_share (51) Length: 38 Key Share extension Client Key Share Length: 36 Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 9f8e83a6859e6b4c6c3e43b524b81e6f63cc409c5757692a2343a2929c681c17

4 years, 5 months

1
0
0 0

Compact public ECC key representation

by Hristozov, Stefan

Hi all, For an IETF protocol that I am currently implementing a compact representation [1] of ECDH public keys needs to be sent over the network and be used on the receiving side for deriving a shared secret. With psa_export_public_key() I can export the public key form a psa_key_id_t object. The exported key is 65 bytes long (I am working with P256) which has the format 04|x|y as documented in [2]. It is easy to compress the public key before sending it -> just send the x part. How to decompress the x part back to the representation 04|x|y. As far I understand the psa_raw_key_agreement() function the public key must be encoded "in the same format that psa_import_key() accepts", that is 04|x|y [3]. Is there a function for that? [1]: https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#appendix-B draft-ietf-lake-edhoc-12<https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#appendix-B> Network Working Group G. Selander Internet-Draft J. Preuß Mattsson Intended status: Standards Track F. Palombini Expires: 23 April 2022 Ericsson 20 October 2021 Ephemeral Diffie-Hellman Over COSE (EDHOC) draft-ietf-lake-edhoc-12 Abstract This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. datatracker.ietf.org [2]: https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b… [https://opengraph.githubassets.com/aee6bf8d395880d12a54b66dd4188b9fd92064a1…]<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> An open source, portable, easy to use, readable and flexible SSL library - mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls github.com [3]: https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b… [https://opengraph.githubassets.com/aee6bf8d395880d12a54b66dd4188b9fd92064a1…]<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls<https://github.com/ARMmbed/mbedtls/blob/f660c7c92308b6080f8ca97fa1739370d1b…> An open source, portable, easy to use, readable and flexible SSL library - mbedtls/crypto.h at f660c7c92308b6080f8ca97fa1739370d1b2fab5 · ARMmbed/mbedtls github.com Br, Stefan

4 years, 5 months

1
0
0 0

Using mbedtls with a CA chain

by Loren Rogers

I need to use mbedtls (bundled with Nordic SDK, and unsure of version) to do some cloud-based functionality (AWS cloud, using OpenAM with a CA chain containing 4 certs). According to something I read, I need to use a pkcs7 container? If so, it seems that mbedtls does not support pkcs7? I did hand-copy some code from a PR, but as I was looking through the pkcs7.c, it seems that it still only supports the CA Root. Is this true? Is there anyone that can give me a hand in solving what I am attempting to do? Thank you /Loren Rogers

4 years, 5 months

1
0
0 0

password for the files root.cer, client1.cer and client1-key.pem

by lekshmi g

Dear Sir,/Madam We need to convert the files - root.cer,client1.cer and client1-key.pem to jks using the tool keystore explorer. For that, the password for the files are needed.Please provide passwords.We need to establish connection between java client and mbedtls c server.Kindly provide help. Regards Lekshmi G

4 years, 5 months

1
0
0 0

TLS connection establishment between OpenMUC java client and mbedtls server

by lekshmi g

Dear Madam/Sir, We are working on a project which requires IEC 62351 standards. For that we had developed a TLS server in C language and we had the requirement of developing a TLS client in Java language. We had used the *mbedTLS library for server* and *OpenMUC libraries for client*. But we are getting exception while certificate exchange phase and all. We had attached the listed exceptions and errors. Kindly provide necessary support for the same. Also please confirm whether we can develop above specified architecture, ie TLS based server in C language and client in Java. If available please share some sample programs also. Please reply ASAP. We have debugged the code and the following are the messages we have got in mbedtls java server and OPENMUC java tls client . During certificate exchange from client to server (MBEDTLS_SSL_CLIENT_CERTIFICATE case in server), the function returns a nonzero value and the alert shows in server is 49 (ie, MBEDTLS_SSL_ALERT_MSG_ACCESS_DENIED). *Please check Fig 1 and Fig 2* for the messages displayed during connection establishment.Kindly help us to solve the issues. [image: image.png] Fig 1- case:MBEDTLS_SSL_CLIENT_CERTIFICATE fails [image: image.png] Fig 2-OPENMUC java client error when connecting to mbedtlsserver ReplyForward <https://drive.google.com/u/0/settings/storage?hl=en&utm_medium=web&utm_sour…> <https://www.google.com/intl/en/policies/terms/> <https://www.google.com/intl/en/policies/privacy/> <https://www.google.com/gmail/about/policy/>

4 years, 5 months

1
0
0 0

[Mbed-tls-announce] Mbed TLS Tech Forum

by Dave Rodgman via Mbed-tls-announce

Hi, I would like to announce the Mbed TLS Tech Forum, a regular engineering call to discuss topics of interest to the Mbed TLS community. The call is currently planned to take place every two weeks, alternating between US-friendly and China-friendly times (16:30 and 10:00 UK time), starting on the 25th October at 16:30 BST. Please reply to the list if you have any agenda topics to raise. As a starting point, we will cover: Format – check if times & cadence are suitable TLS 1.3 – high-level update on progress & direction PSA Cryptoprocessor Driver Interface – code generation for driver dispatch as per https://github.com/ARMmbed/mbedtls/pull/5067 Zoom details below. The call will be recorded and made available on the TF website: https://www.trustedfirmware.org/meetings/ Dave Rodgman Mbed TLS tech lead -- Dave Rodgman is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://armltd.zoom.us/j/93259847316?pwd=N0d4Z0o5RXRLKzZFaE1sd044bm14dz09&f… Meeting ID: 932 5984 7316 Passcode: 991642 One tap mobile +442034815240,,93259847316#,,,,*991642# United Kingdom Dial by your location +44 203 481 5240 United Kingdom +1 346 248 7799 US (Houston) +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +91 116 480 2722 India +91 224 879 8012 India +91 406 480 2722 India +91 806 480 2722 India +852 5803 3730 Hong Kong SAR +46 8 4468 2488 Sweden +972 3 978 6688 Israel +353 1 536 9320 Ireland +36 1 408 8456 Hungary +33 1 7037 2246 France +358 3 4109 2129 Finland +45 32 70 12 06 Denmark +1 438 809 7799 Canada +65 3158 7288 Singapore +27 87 550 3946 South Africa +32 1579 5132 Belgium +48 22 307 3488 Poland +386 1600 3102 Slovenia +60 3 3099 2229 Malaysia +886 (2) 7741 7473 Taiwan Meeting ID: 932 5984 7316 Passcode: 991642 Find your local number: https://armltd.zoom.us/u/adTMafG7oQ Join by SIP 93259847316(a)zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 209.9.211.110 (Hong Kong SAR) 149.137.40.110 (Singapore) 64.211.144.160 (Brazil) 69.174.57.160 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 932 5984 7316 Passcode: 991642 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

4 years, 5 months

3
2
0 0

switching from libressl to MbedTLS

by LM

I'm hoping to make the switch from libressl to MbedTLS. I'm working on a Linux from scratch style project. Curl works fine with MbedTLS and most of the utilities I work with use libcurl. I'm also using libtomcrypt for some of its hash and cryptographic functionality. The only place I'm having a problem making the switch at present is when I follow the LFS logic to make certificates (make-ca). There's a openssl/libressl command in the script that looks like the following: openssl x509 -hash -noout -in "$1" Is there a way to replace this functionality with a command or procedure or function from another program so that libressl or openssl isn't needed to perform this step? Thanks.

4 years, 5 months

1
0
0 0

Mbedtls Client Key Exchange Time

by Duygu D.

Hello, I'm using mbedTLS on baremetal lwip+stm32f4 system as a Server. TLS working successfully with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 but when I receive the Client Hello message than my receive proccess function in ethernetif_input: err = netif->input(p, netif); takes 300ms time. This function normaly takes 1ms. I need to reduce this time. How Can I do that ? This is my config file: https://paste.ofcode.org/Bdt4FapskKY7M5ggm3uViJ Best Regards. -- Embeded System Engineer

4 years, 6 months

1
0
0 0

passing jks format client certificate

by lekshmi g

Dear Madam/Sir We need to establish connection with security between MMS client application in java(OPENMUC java client) and MMS server (tls_server_example in mbedtls).The java client application uses keystore.jks and truststore.jks (*jks format* ) instead of certificate in *cer *format.Is it possible to establish connection between OPENMUC java mms client and libiec61850 1.5 with mbedtls-2.16.6* ?* . We have added the *root.cer details *(certificate in the sample mbedtls server program ) to * truststore.jks* in client (openmuc java) and *client1.cer details* (client1 certificate in the sample mbedtls server program ) *to keystore.jks* .When trying to establish connection server hello messages are completed ,but showing the following error: *MBEDTLS_ERR_SSL_NO_CLIENT_CERTIFICATE.* * Please help...* *Regards* *Lekshmi G*

4 years, 6 months

1
0
0 0

Re: [mbed-tls] [TF-M] Adding platform specific functions to Crypto Service.

by Fabian Schmidt

Hi Roman, My understanding is that you would like to add features to the Crypto service API, but the features which you would like to add are not cryptographic in nature. Have you considered creating your own service for those features, instead of modifying the Crypto service? Or is there anything makes this not a viable option? If you are thinking about adding hardware acceleration for some Crypto features, that's indeed covered in Shebu's link. Greetings, Fabian Schmidt From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: Dienstag, 12. Oktober 2021 11:46 To: David Hu <David.Hu(a)arm.com>; Roman.Mazurak(a)infineon.com; tf-m(a)lists.trustedfirmware.org; mbed-tls(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] Adding platform specific functions to Crypto Service. Caution: EXT Email Hi Roman, I also might not have understood the question completely. As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver -interface.md <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2FARMmbed%2Fmbedtls%2Fblob%2Fdevelopment%2Fdocs%2Fproposed%2Fpsa-driver-in terface.md&data=04%7C01%7Cfabian.schmidt%40nxp.com%7C17489158b6384ef5caa308d 98d654ead%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637696288543072051%7C Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC JXVCI6Mn0%3D%7C1000&sdata=uKX4sUH37jNx1%2BvACuN8tBQl05OaXPPnMT9FqMwbhdU%3D&r eserved=0> Also adding mbed-tls mailing list as the thread is crypto related.. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org <mailto:tf-m-bounces@lists.trustedfirmware.org> > On Behalf Of David Hu via TF-M Sent: Tuesday, October 12, 2021 4:18 AM To: Roman.Mazurak(a)infineon.com <mailto:Roman.Mazurak@infineon.com> ; tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com <mailto:nd@arm.com> > Subject: Re: [TF-M] Adding platform specific functions to Crypto Service. Hi Roman, Are you asking about adding platform specific HAL API to implement PSA Crypto API function? Please correct me if I misunderstand your question. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org <mailto:tf-m-bounces@lists.trustedfirmware.org> > On Behalf Of Roman Mazurak via TF-M Sent: Monday, October 11, 2021 9:45 PM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Adding platform specific functions to Crypto Service. Hi all, We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions? Best regards, Roman.

4 years, 6 months

3
3
0 0

Re: [mbed-tls] Adding platform specific functions to Crypto Service.

by Shebu Varghese Kuriakose

Hi Roman, I also might not have understood the question completely. As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive… Also adding mbed-tls mailing list as the thread is crypto related.. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, October 12, 2021 4:18 AM To: Roman.Mazurak(a)infineon.com; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Adding platform specific functions to Crypto Service. Hi Roman, Are you asking about adding platform specific HAL API to implement PSA Crypto API function? Please correct me if I misunderstand your question. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Roman Mazurak via TF-M Sent: Monday, October 11, 2021 9:45 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Adding platform specific functions to Crypto Service. Hi all, We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions? Best regards, Roman.

4 years, 6 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls