- mbed-tls - lists.trustedfirmware.org

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, 7 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, 7 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, 7 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls