Hello,
I am referencing the Mbed TLS (v3.5) implementation for key slots & how they interact with the PSA key management APIs. In the PSA documentation<https://arm-software.github.io/psa-api/crypto/1.1/overview/implementation.h…>, sections 6.3.3 and 6.3.4 describe that persistent keys (that are handled according to the Memory cleanup rule) would have to be loaded from NVM on each use of the key, unless PSA_KEY_USAGE_CACHE is set.
However, I'm not certain I see this followed in the Mbed TLS code. 'psa_export_key()' is the simplest example. This function retrieves and locks the key slot for the requested key ID using 'psa_get_and_lock_key_slot_with_policy()' - this function may retrieve the persistent key material from NVM if necessary (it seems to return sooner if it finds that persistent key in a slot already). The remainder of psa_export_key() copies the key material from the slot directly to the output buffer, but it never removes the key material from the slot.
My understanding was that the key material should be removed from the slot unless PSA_KEY_USAGE_CACHE was set. Can anyone clear this up for me? Does this just mean that the reference implementation does not follow the memory cleanup rule, or is the slot buffer cleared at some later point for the persistent key?
Thank you,
Kevin Zak
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
Dear Mbed TLS users,
We recently announced the release of Mbed TLS 3.6.0, starting the 3.6 long-term support branch. We intend for this to be the last 3.x feature release. Mbed TLS 3.6.x will as usual receive bug fixes (including security improvements), but no new features. This will allow the Mbed TLS team to focus on preparing the next major release, Mbed TLS 4.0, planned for 2025 (expect further updates when the timeline becomes more precise).
The main focus of Mbed TLS 4.0 is to complete the migration to PSA crypto APIs. This means that most mbedtls_xxx cryptography APIs will be removed. We expect mbedtls_x509 and mbedtls_ssl to change in relatively minor, but sometimes incompatible ways. Alongside this technical change, the crypto APIs will be published as a separate product, TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> (very early preview so far), while the X.509 and TLS libraries will continue to be called Mbed TLS.
The work on 4.0 will happen on the development branch in the mbedtls repository, so you can expect more instability than usual on that branch. The mbedtls-3.6<https://github.com/Mbed-TLS/mbedtls/tree/mbedtls-3.6> branch is available if you want the latest patches on Mbed TLS 3.6 LTS.
As usual, you can see our high-level plans in the roadmap<https://mbed-tls.readthedocs.io/en/latest/project/roadmap/>, and in more detail on GitHub<https://github.com/Mbed-TLS/mbedtls/issues>. Look for issues labeled api-break<https://github.com/Mbed-TLS/mbedtls/issues?q=is%3Aissue+is%3Aopen+label%3Aa…> (note that we haven't filed issues on all topics yet).
We will launch some consultations on the mbed-tls mailing list<https://lists.trustedfirmware.org/mailman3/lists/mbed-tls.lists.trustedfirm…> soon, to gather community input on some topics.
Many Thanks,
Nathan Sircombe
(On behalf of the Mbed TLS development team)
Hi Mbed TLS list,
I’d just like to introduce myself to the wider Mbed TLS community.
I’ve recently joined the Mbed TLS team as the Engineering Manager for the Arm team. Although I’m new to this project, I’m not new to Arm having worked here for a while on a number of closed and open source library projects.
I look forward to working with you, and meeting some of you on our regular community calls.
Cheers,
Nathan.
p.s. my GitHub usid is nSircombe (https://github.com/nSircombe)
hello:
Recently, I am transplanting mbedtls from a 32-bit system to a 64-bit system. The compilation operating system is ubuntu20.4. The screenshot below is the code I use mbedtls(version number: 2.24.0). In the API mbedtls_rsa_gen_key implementation, there is a line of code that is ""MBEDTLS_MPI_CHK( mbedtls_mpi_lset( &ctx ->E, exponent ) );"", the program crashed at the memset in mbedtls_mpi_set during execution. This has not happened on 32-bit platforms before, so I would like to ask whether it has something to do with the platform used or whether I call the API. It’s a question about how to use it, thank you very much
Hi, I am trying to identify the API available by looking up exported symbols from the built shared libraries libmbedcrypto.so ,libmbedtls.so and libmbedx509.so. I noticed that many of the exported functions are not documented here https://mbed-tls.readthedocs.io/projects/api/en/development/ . My question really is, are those functions exported through the shared libraries intended to be so ? For example, function mbedtls_mpi_core_add does not seem to be part of the API but it is exported. Is this intentional ? It's not uncommon that functions would be exported but not part of the API, I just wanted to get some clarification if possible regarding the reasons for doing so in the case of MbedTLS. Thanks Ahmed
Hi,
I am sorry but I need to know test case scenarios to verify what is
supported in the recent MBedTLS stack - what should be tested.
Objective is that we cover MBedTLS code the maximum.
Since I am a new learner, I need to build the test cases from
scratch. So I thought to first find from stack what TLS ciphers suites
/ digest it supports, what are the different keysize, and protocols -
TLSvX (where x=1,2 or 3). Then build certificates related to the same
and verify the data as found. Are there other ways to find different
features in the current MBedTLs stack and verify each one of them?
Is this approach the right way - do we have known test case scenarios
to verify? Any other additional help will aid us out.
Thanks in advance.
Regards,
Prakash
Hi All,
This is going out to all the primary TF maillists.
It's a gentle reminder that a TF Discord channel has been created for all
chat communications in the TF ecosystem. All TF participants are
encouraged to join.
Instructions on how to join can be found here:
https://www.trustedfirmware.org/faq/ <https://www.trustedfirmware.org/faq/>
[image: Screenshot 2024-04-17 at 7.08.01 AM.png]
Please let me know if you have any questions,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello,
I am trying to add TLS 1.3 support to a curl project
(https://github.com/MAntoniak/curl). As a result, it has two questions.
The first refers to the error code
MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET. This suggests an error
receiving a new session ticket. I couldn't find anything else in the
documentation. However, in the ssl_cllient2.c example application (line
2638), this code is used as a message to the application about a new
session ticket. This makes me unsure whether it would be correct to
continue receiving application data normally.
The second question relates to the receipt of tickets. The curl project
does not store session tickets, so it uses the
MBEDTLS_SSL_SESSION_TICKETS_DISABLED flag. If this is the case, why do
we nevertheless receive a new ticket from the server?
Thank you for your reply.
Michał Antoniak