- mbed-tls - lists.trustedfirmware.org

by Gilles Peskine

Hello, We intend to remove DES (including Triple-DES) in the next major version of Mbed TLS, i.e. Mbed TLS 4.0. We do not yet have a release date, but at the moment it seems likely that there will be a new major version in 2024. As usual, the Mbed TLS 3.x series will keep the current support for DES, and we intend to maintain the last 3.x minor release as a long-term support branch for 3 years. Rationale: Most security standards deprecate DES if they do not forbid it already. Tooling is widely available to switch to AES or other cipher. In particular, NIST will forbid Triple-DES except to decrypt legacy data after 31 December 2023 (following SP 800-131A <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf>). We would like to remove the last 64-bit block cipher from Mbed TLS to simplify some parts of the code and reduce the maintenance burden. If you wish for Mbed TLS to keep supporting DES longer, please let us know what your business case is, either by replying to this email or on the GitHub issue: https://github.com/Mbed-TLS/mbedtls/issues/7024 Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 10 months

2
1
0 0

Builtin keys and Opaque driver wrappers.

by Rehan Malak

Dear MbedTLS dev, I am writing an opaque driver (equivalent of PSA_CRYPTO_TEST_DRIVER_LOCATION/PSA_KEY_PERSISTENCE_READ_ONLY in the test suite) with the PSA API compiled with MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS. But I am not sure if I have to use "psa_import_key" before "psa_driver_wrapper_sign_message" or if I have to "read/generate" the builtin key on the fly, at each psa_driver_wrapper_* operation ? Would it be possible to add this example in the test suite ? Or explain how builtin key + opaque driver is supposed to be used with, for example, "psa_driver_wrapper_sign_message" ? I put more details below. Thank you in advance, Best regards, Rehan ############################################################################# I would like to write an example doing : I) psa_sign_message (ECDSA SECP256R1 SHA-256) II) psa_export_public_key III) psa_verify_message (with the public key from II) I am following the examples provided by the test suite, especially : 1) sign_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256 using the API : - psa_import_key - psa_sign_message with the attributes : - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) 2) PSA opaque driver builtin pubkey export: secp256r1 using the API : - psa_export_public_key with the attributes : - key_id = MBEDTLS_PSA_KEY_ID_BUILTIN_MIN + 1 - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) and the driver code : - platform_builtin_keys.c : mbedtls_psa_platform_get_builtin_key() (PSA_KEY_PERSISTENCE_READ_ONLY, PSA_CRYPTO_TEST_DRIVER_LOCATION) - test_driver_key_management.c : mbedtls_test_opaque_export_public_key() 3) verify_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256 using the API : - psa_import_key - psa_verify_message with the attributes : - key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) It seems to me that II)=2) and 3) should be pretty similar to III) because I assume that neither transparent vs opaque, nor PSA_KEY_TYPE_ECC_KEY_PAIR vs PSA_KEY_TYPE_ECC_PUBLIC_KEY_BASE, is gonna change much here. But the signature I) is less clear... Has the built-in key feature been thought such that the read-only key is read each time we call a different PSA API function ? Long story short, an "opaque driver + builtin keys" equivalent of the "sign_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256" example in the test-suite would be really helpful :)

2 years, 10 months

2
1
0 0

PSA crypto support for RH850 Microcontroller

by Tambe, Ujjwal (TCS)

Hello, Is it possible to use PSA crypto APIs for SHA256 and RSA signature verification for RH850F1KMS1 microcontroller from renesas which has G3KH cpu core. Let me know your thoughts. Thank you in advance. Regards, Ujjwal

2 years, 10 months

1
0
0 0

Mbed TLS support for Renesas RH850 microcontroller

by Tambe, Ujjwal (TCS)

Hello, I am writing this mail in order to get support. I am using RH850-F1KMS1 microcontroller from Renesas, and I need to integrate mbed to perform SHA256 and RSA-1024 digital signature verification. The controller is bare metal and does not have any OS like freeRTOS. Just want to understand how to integrate mbed code in our project. Thank you in advance for the help. Regards, Ujjwal

2 years, 10 months

1
0
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Dave, Please keep in mind that next Monday is a Federal Holiday in the US, so this may impact attendance. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 11 months

1
0
0 0

[Mbed-tls-announce] Coding style change in Mbed TLS

by Gilles Peskine via Mbed-tls-announce

Hello, You are concerned if: you contribute to Mbed TLS, or you maintain local patches to Mbed TLS. You are not concerned if: you just use Mbed TLS. We are going to change the C coding style in Mbed TLS. The new style is mostly what you'd find in The C Programming Language, 2nd edition, by Brian Kernighan and Dennis Ritchie (K&R2). The main changes compared to the current style are: * Spaces outside parentheses, not inside. No space in f(x). * Opening braces on the same line as if(), for(), etc., but on a separate line for functions. Indentation remains 4 spaces. The recommended maximum line length remains 80 columns. There are a few deviations from K&R2, documentation will be available shortly. The new code style will be enforced by the CI testing. This means that style that's rejected by the tool will not be merged, full stop. This also means that sometimes we'll have code that looks a bit less good to humans because the tool insists on it. We're doing this to avoid wasting reviewers' and contributors' time with style violations in code review. The tool we're using is uncrustify<https://github.com/uncrustify/uncrustify>. You can see how your code will look like by installing uncrustify 0.75.1 and running scripts/code_style.py from mbedtls-3.3.0 or mbedtls-2.28.2. There are previews of the rewritten branches at https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/development and https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/mbedtls-2.… (updated every few days until the real branches are rewritten). If you're now starting work on a new feature or bugfix, it will probably be easier to start from those branches, and do an easy rebase once they become official. If you've been working on a branch, we will provide a script to rebase the branch and rewrite it to the new style commit by commit. You'll need to have uncrustify 0.75.1. Concretely, when we change the code style: * If you've started to work on a branch but review has not started yet, we'll ask you to adapt your branch to the new code style. * If your work is under review, you'll need to adapt your branch to the new code style before it can be merged. Rebasing a branch is disruptive for reviews, so please synchronize with the reviewers to decide on a good time. We plan to do the switch during the first week of January 2023. Best regards, -- Gilles Peskine Mbed TLS developer 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 To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

2 years, 11 months

2
2
0 0

[Mbed-TLS/mbedtls] MS-MPPE-RECV key is not getting correct value in MBEDTLS

by Ajay Mishra

Hi All, I raised the issue below in the MBED-TLS github, as per suggestion from the moderator asking it in the mailing-list. Below are the details. https://github.com/Mbed-TLS/mbedtls/issues/6864 I am running Mbed TLS as a core security library(2.24.0), on an embedded platform. I am using the FreeRADIUS server for AAA authentication. I am able to get the PMK values correctly at the supplicant side, however while decrypting the MPPE key at the gateway side I see that the values are incorrect specially in the API(radius_client_sec_prot_ms_mppe_recv_key_pmk_decrypt) Below are my setup details: FreeRADIUS server setup on Ubuntu(3.2.1) openssl :1.1.1f Ubuntu version : 20.04.04LTS System information Client side setup Platform : Micro controller based platform OS : FreeRTOS Compiler gcc-arm-none-eabi-8-2019-q3-update Sample example MPPE KEY in clear at RADIUS Server Fri Dec 30 23:50:13 2022 : Debug: (209) MS-MPPE-Recv-Key = 0x2f6c3e7e748eb49a598c208af3ef520454f5aa6873bc72f7f32be1053914a566 Fri Dec 30 23:50:13 2022 : Debug: (209) MS-MPPE-Send-Key = 0xa04539819a272e94782af1818b05878bb0e420d08a51accd6c3cb75baaecbd75 PMK Key values at Supplicant(which is same as MPPE-RECV-KEY) PMK Key values at Supplicant(which is same as MPPE-RECV-KEY) 2022-12-30 23:50:07.313 #1 0000000000000000 <log> 0:28:21.215 [debug] [ tlsp] {Wi-SUN Ev}: >>>> PRINT THE KEY PMK >>>> 2022-12-30 23:50:07.313 #1 0000000000000000 <log> 0:28:21.224 [debug] [ tlsp] {Wi-SUN Ev}: EAP-TLS key material 2f:6c:3e:7e:74:8e:b4:9a:59:8c:20:8a:f3:ef:52:04:54:f5:aa:68:73:bc:72:f7:f3:2b:e1:05:39:14:a5:66 which is same as the value that we see at the RADIUS Server. Decrypted key Value at Authenticator(using the API radius_client_sec_prot_ms_mppe_recv_key_pmk_decrypt) 2022-12-30 23:51:34.763 #1 0000000000000000 <log> 3:09:17.919 [debug] [ hmac] {Wi-SUN Ev}: hmac_md key a9:69:02:e9:3a:1d:cd:05:31:b3:77:cd:d6:d7:c2:c7:2d:52:4b:0a:5b:b1:aa:81:20:67:dd:b8:1c:04:ef:63 Mbed TLS version (number or commit id): 2.24.0 Operating system and version: Configuration (if not default, please attach mbedtls_config.h): Compiler and options (if you used a pre-built binary, please indicate how you obtained it): Additional environment information: Expected behavior The key should be decrypted with the correct value. Actual behavior The key is not getting the correct value. Steps to reproduce Additional information Kindly let me know what is missing here ? Thanks in advance. With regards, Ajay. Brentwood, UK.

2 years, 11 months

1
1
0 0

Simultaneous accepts

by David Higton

With mbedTLS set up as a streaming server (e.g. https), can it deal with two attempts to connect that arrive in quick succession, so two handshakes are occurring simultaneously? David

2 years, 11 months

1
0
0 0

Non-Blocking HTTPS read/write using MbedTLS

by Sritam Paltasingh

I have a working Client code in which I use MbedTLS functions to send HTTPS GET request to my server. For sending data to the server, I use mbedtls_ssl_write(). But this call is blocking. My goal is to make this function call (mbedtls_ssl_write()) non-blocking. What is the correct way to do it ? I read the documentation and concluded that: 1. I have to set the bio callbacks using the mbedtls_ssl_set_bio() function where I have to pass the callback functions as parameters in this function call. 2. I have to set the SSL context as non-blocking using the mbedtls_net_set_nonblock() function call 3. I have used the default bio callbacks, named mbedtls_net_send and mbedtls_net_recv, which are defined in net_sockets.c My question is: After setting the default bio callbacks (mbedtls_net_send and mbedtls_net_recv) and setting the SSL context as non-blocking (mbedtls_net_set_nonblock) which function should I use for non-blocking write/read. Will it be mbedtls_ssl_write() and mbedtls_ssl_read() ? And will the call back functions (which are set using mbedtls_ssl_set_bio) be called when read/write completes? Please help me with advice on how to implement non-blocking write/read using MbedTLS functions. Thanks and Regards, Sritam Paltasingh.

2 years, 11 months

1
0
0 0

PSA Drivers and "add_entropy" interface.

by Ruchika Gupta

Hi, PSA driver interface specification talks about "add_entropy" entry point. Snippet pasted below. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv… *A driver can declare an entropy source by providing a "get_entropy" entry point. This entry point has the following prototype for a driver with the prefix "acme":* *psa_status_t acme_get_entropy(uint32_t flags, size_t *estimate_bits, uint8_t *output, size_t output_size);* However, in the current implementation of MbedTLS 3.x I don't see this implemented . With the psa_crypto-init() what I observe is that if the platform enables MBEDTLS_ENTROPY_HARDWARE_ALT then using " mbedtls_hardware_poll(), the entropy source can be provided. Can you please confirm if this observation is correct and also let us know if the <driver>_get_entropy() is planned to be implemented in near future ? Regards, Ruchika

2 years, 11 months

2
2
0 0

Canceled event: MBed TLS Technical Forum - Asia @ Mon Jan 2, 2023 3am - 3:50am (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been canceled. MBed TLS Technical Forum - Asia Monday Jan 2, 2023 ⋅ 3am – 3:50am Mountain Standard Time - Phoenix Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… 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 Guests Don Harbin - creator nnac123(a)gmail.com santosdanillo(a)gmail.com schoenle.thomas(a)googlemail.com kris.kwiatkowski(a)pqshield.com psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 11 months

1
0
0 0

Regarding implementation of MBED CRYPTO libraries without entropy source on baremetal

by PRASHANT TRIPATHI

Dear sir/madam I have following queries regarding implementation of MBED CRYPTO Libraries : 1) How crypto libraries files could be used on baremetal with no entropy source(cross compilation )? 2) How asymmetric cryptographic operations like RSA , RNG , EC ,DSA etc , could be implemented on baremetal without entropy , seed provisions ? 3) If i want to use some custom PRNG and entropy , then how the respective contexts structures could be filled ? Thanks & Regards, *Prashant Tripathi*

2 years, 11 months

2
3
0 0

[Mbed-tls-announce] Mbed TLS 3.3.0 and Mbed TLS 2.28.2

by Dave Rodgman via Mbed-tls-announce

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.3.0 and 2.28.2. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-3.3.0 and https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.28.2 ). We recommend all users to consider whether they are impacted, and to upgrade appropriately. The releases are available from https://github.com/Mbed-TLS/mbedtls/releases Dave Rodgman 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 To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

2 years, 11 months

1
0
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 11 months

1
0
0 0

About setting arbitrary RDN while generating a CSR with mbedtls

by Aditya Patwardhan

I am using mbedtls_x509write_csr_set_subject_name API from mbedtls to set the subject name. I wanted to set the arbitrary old value in my certificate for e.g. ffeBgt9jDHhBwPDANgtT7R/1.3.6.1.4.1.37244.2.1=FFF2/1.3.6.1.4.1.37244.2.2=8001 In this case ffeBgt9jDHhBwPDANgtT7R is the CN And 1.3.6.1.4.1.37244.2.1 is an arbitrary OID which has a value of FFF2 similar to the second arbitrary OID. I am able to do this through openssl commands, but while doing it through mbedtls, when I pass it as a string then mbedtls considers the whole string as CN which Is not my intention. Please fine the asn1 parsing of the CSR as below CSR generated through mbedtls: 18:d=5 hl=2 l= 3 prim: OBJECT :commonName 23:d=5 hl=2 l= 76 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R/1.3.7.1.4.1.37466.2.1=FFF2+1.3.7.1.4.1.37466.2.2=8001 101:d=3 hl=2 l= 11 cons: SET 103:d=4 hl=2 l= 9 cons: SEQUENCE Target CSR ( done thorough openssl): 14:d=4 hl=2 l= 29 cons: SEQUENCE 16:d=5 hl=2 l= 3 prim: OBJECT :commonName 21:d=5 hl=2 l= 22 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R 45:d=3 hl=2 l= 20 cons: SET 47:d=4 hl=2 l= 18 cons: SEQUENCE 49:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.1 61:d=5 hl=2 l= 4 prim: UTF8STRING :FFF2 67:d=3 hl=2 l= 20 cons: SET 69:d=4 hl=2 l= 18 cons: SEQUENCE 71:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.2 83:d=5 hl=2 l= 4 prim: UTF8STRING :8001 89:d=2 hl=2 l= 89 cons: SEQUENCE 91:d=3 hl=2 l= 19 cons: SEQUENCE 93:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 102:d=4 hl=2 l= 8 prim: OBJECT :prime256v1 Am I missing something here? Do I need to provide the CN in a different way to get the intended result? I found an open issue https://github.com/Mbed-TLS/mbedtls/issues/4886, could it be related to this? Any help would be appreciated. Thanks and Regards, Aditya

2 years, 11 months

2
1
0 0

MbedTLS crashes with some websites in mbedtls_mpi_free()

by Peter

Hi All, Some websites crash MbedTLS, in void mbedtls_ecp_point_free( mbedtls_ecp_point *pt ) { if( pt == NULL ) return; mbedtls_mpi_free( &( pt->X ) ); mbedtls_mpi_free( &( pt->Y ) ); mbedtls_mpi_free( &( pt->Z ) ); } It crashes in the last function call of the three above. Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap) HardFault_Handler() at stm32f4xx_it.c:103 0x8053c22 <signal handler called>() at 0xffffffed 0x3810180 mbedtls_ecp_point_free() at ecp.c:594 0x8029c7a 0x81030100 It crashes properly i.e. invalid opcodes etc. There is a fair bit on google with others having gone down the same road, never resolved. One site which does it is socata.org but quite a few others do it. Probably 10% of "major name" websites cause it to crash. It may have been undiscovered for a long time, or ever, because most MbedTLS clients are connecting to specific private servers only. People aren't using it to connect to microsoft.com (which doesn't actually crash but the handshake returns 0x2700 which can be investigated). There is a Windows build of MbedTLS (v2.16.2) which seems to work in the crashing cases. Stepping through this in Cube IDE (32F417) it looks like the crash is due to a buffer being filled with random numbers. The guy working on this is contactable only on Monday afternoons so I am a bit screwed :) He said he found something about that buffer, or maybe a corrupted function pointer. But as I said this issue has come up before according to numerous online searches and maybe someone can recognise it. Hardware AES is enabled but this occurs with software AES also. No other 32F417 hardware crypto features are used, other than its random number generator. TLS is v2.16.2. Thank you in advance for any pointers. Peter

2 years, 12 months

3
9
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Dec 5 at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. As usual, if anyone has any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years

1
0
0 0

RSA signature with Montgomery

by Prasad Hegde

Hi, Is there any API's available to convert the RSA signature to the Montgomery format. Thanks Prasad

3 years

1
0
0 0

Code style discussions

by David Horstmann

Hi All, Mbed TLS is planning to move to a new code style by the end of this year. The proposed new style is currently being discussed in the GitHub pull request: https://github.com/Mbed-TLS/mbedtls/pull/6591 If you have any feedback on this new style, or you think we should tweak it, feel free to comment on the pull request. We will take your thoughts into account when we decide on the final style. Discussions will continue until the evening of THIS FRIDAY (UK time). Many thanks, David Horstmann for the Mbed TLS Team

3 years

1
0
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years

1
0
0 0

Certificate Verify in Client Authentication does not work as expected

by Simon Nachtigall

Hello everyone, We observed a strange behavior in the mbedTLS client, when client authentication is requested by the TLS server. This behavior was observed in the newer version 3.0.0 as well as in older versions. The scenario is the following: The server selects a ciphersuite e.g. ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and sends a CertificateRequest message that only includes the ecdsa_secp256r1_sha256 signature algorithm. However, the mbedTLS client simply ignores the requested hash function and uses ecdsa_secp256r1_sha384 for the signature in the ClientVerify. Then, the server complains since the signature does not match with the requested signature algorithm and sends a handshake failure. It seems that mbedTLS does not store the requested signature algorithms/hash function from the CertificateRequest and always uses the hash function from the selected ciphersuite. In the ssl_write_certificate_verify function, we find the following comment: /* * digitally-signed struct { * opaque handshake_messages[handshake_messages_length]; * }; * * Taking shortcut here. We assume that the server always allows the * PRF Hash function and has sent it in the allowed signature * algorithms list received in the Certificate Request message. * * Until we encounter a server that does not, we will take this * shortcut. * * Reason: Otherwise we should have running hashes for SHA512 and * SHA224 in order to satisfy 'weird' needs from the server * side. */ Is this a known problem and is there any fix available? Cheers, Simon Nachtigall

3 years

2
1
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Nov 7 at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 1 month

1
0
0 0

Simple question about support of TLS1.2 and TLS1.3 on server side

by caoyxsh＠outlook.com

Is there a plan for adding support of TLS 1.2 and TLS 1.3 at same time on server side? According to : https://github.com/Mbed-TLS/mbedtls/blob/development/docs/architecture/tls1… only one version can be configured at runtime via `mbedtls_ssl_conf_{min,max}_tls_version` for a server endpoint.

3 years, 1 month

1
0
0 0

Get size of available application data without calling mbedtls_ssl_read()

by Bruckner, Jan

Hi all, I'd like to know if there is some way to retrieve the currently available number of bytes of application data without calling mbedtls_ssl_read()? I'm writing a "TLS socket" for higher layers to use and would like to notify them when new application data is available, tell them how much it is, but leave it up to them when and how much to retrieve. I'd like to prevent having to buffer all application data inside my TLS socket, because that would mean copying it once from mbedtls' buffer to my socket and then again from there to the application whenever it actually requests the data. After a quick look into the sources, it seems like, if at all, this might be possible for single records. But all related fields are private and I could not find any API for this. Issue #551 [1] seems related, but is more about peeking into the application data, while I would be fine with knowing just the size of available application data. Thanks for any hints on how I could achieve this. Best regards, Jan [1] https://github.com/Mbed-TLS/mbedtls/issues/551 ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

3 years, 1 month

1
1
0 0

Feedback requested: Mbed TLS builds with PSA and legacy implementations of the same algorithm with different characteristics

by Gilles Peskine

Hello, Summary: I am soliciting feedback about builds of Mbed TLS where *there is both a PSA implementation and the built-in software implementation of the same algorithm, by design, *and the PSA implementation isn't just calling the built-in implementation because the two have different characteristics, each desirable in some context. Please read this message if you are doing this or considering it. Feel free to ignore otherwise. For example, both MBEDTLS_SHA256_C and MBEDTLS_PSA_ACCEL_ALG_SHA_256 are enabled, so that calls to mbedtls_md_xxx() use the software implementation and calls to psa_hash_xxx() use the hardware accelerator via the PSA driver. And this is deliberate: there is a reason why mbedtls_md_xxx() must not call the PSA driver. In most cases, this is not desirable: if there's an accelerator, why not use it? And we're working to allow getting rid of the software implementation in more and more cases. Ultimately, PSA will be the only crypto interface in Mbed TLS, so all interfaces to calculate SHA-256 will go through psa_hash_xxx() and therefore will dispatch the call to the driver if there is one. This will be an API break, since it will require calling psa_crypto_init() before performing any cryptography. Currently we are planning to introduce this requirement in Mbed TLS 4.0. But it is currently possible to have dual algorithm support, and I can think of unusual cases where it might desirable. Scenario 1, with accelerator drivers: there is a driver, but it can only be used after some initialization. The application needs to use the algorithm before calling psa_crypto_init(), so it calls the legacy interface. After psa_crypto_init() has been called, the application would like to use the driver as much as possible. A typical use case is a bootloader which wants to verify a signature before initializing the random generator, so it calls mbedtls_md_xxx() and mbedtls_rsa_xxx(). Scenario 1 is clearly desirable, and for that we have a planned solution, which is staged initialization. The bootloader will be able to (1) initialize drivers, (2) perform a hash calculation, (3) initialize the keystore, (4) verify a signature, all without initializing the RNG. We won't make psa_crypto_init() mandatory until this feature is implemented. Scenario 2: with a cryptography service. This is a build of Mbed TLS with MBEDTLS_PSA_CRYPTO_CLIENT, so all psa_xxx() calls call the service. But, for some reason, there is also a local implementation of some cryptography algorithms. So you can call mbedtls_md() to calculate a hash even before the connection to the service has been established. Or maybe you want to call mbedtls_md() for short messages and psa_hash_compute() for long messages, because the crypto service has a faster implementation but the communication overhead offsets the gain for short messages. We are currently working on improving support for PSA drivers, and in particular, saving code size by eliminating more unnecessary code when a driver is present, and increasing the set of APIs that benefit from drivers. The obvious way to do that is to make all cryptography calls (especially from X.509 and TLS) go via the PSA interface, but we can't do that yet due to the need to have initialized the keystore and RNG. We are considering routing /certain/ crypto calls via PSA, in a way that would break scenario 2, and would also break scenario 1 in some cases, but not for hashes or signature verification. If, for example, in Mbed TLS 3.4, mbedtls_md() starts calling psa_hash_(), would this break your code? Are you in scenario 1, scenario 2, or some other variant I haven't thought of? If so, *please reply to this message and let us know what your needs are*. Feel free to reply to me in private if you don't want to discuss this publicly (I won't share directly outside Arm, but the eventual design might leak information about the unusual scenario). If we don't hear objections, there is a chance that a future Mbed TLS 3.x will break scenarios 1 and 2. If we do hear objections, we'll work to keep the current behavior or arrange a migration path. Best regards, -- Gilles Peskine Mbed TLS developer

3 years, 1 month

1
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls