I am trying to build *https://github.com/ithewei/libhv
<https://github.com/ithewei/libhv>* with MBEDTLS on Windows but it doesn't
have include and library define options on *CMake*. When I ask them with an
issue on *GitHub*, they said I need to use *"Default Search Path"*. I
installed it with *cmake --build . --config Release --target INSTALL *and I
can see it in *Program Files/MBed TLS. *I think I need to define an
environment variable. But what is correct names for includes and libraries ?
Hi Team,
Need support on one the below query. I had previously raised this in issue #9116 : Client certificate verify · Issue #9116 · Mbed-TLS/mbedtls · GitHub<https://github.com/Mbed-TLS/mbedtls/issues/9116> .However I was asked to redirect the query to the mbedTLS support.
Q#1 : I have a client certificate chain (end entity cert, intermediate cert and root cert) and I have got 1 public key (extracted from root CA cert) on my server. Is there any way in mbedTLS where I can validate the client certificate using just the public key of the root CA and not the whole root CA certificate on my server?
As per my understanding of CA and certificate validation we would need a whole CA cert and not just the public key of the root certificate. However, I would like to know if there are any API's in mbedTLS for this validation?
Thanks,
Sushma
________________________________
Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version.
________________________________
I am testing a test program in an Ubuntu VM, and I have an issue.
I started by configuring MbedTLS in "full" mode (scripts/config.py
full), but in that case the linker fails, "in function
`psa_load_builtin_key_into_slot`, psa_crypto_slot_management.c:
undefined reference to 'mbedtls_psa_platform_get_builtin_key`.
I can suppress the error by editing `include\mbedtls\mbedtls_config.h`
and removing the option `MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS`. The compile
succeeds, but the call to `psa_crypto_init` fails when initializing the
RNG module.
I am struggling. I must be making some mistake, I will keep trying to
understand, but I would appreciate a little bit of help!
-- Christian Huitema
Hello Mbed TLS team,
Mbed TLS 3.6 introduced the first UTF-8 characters “±” in source code, see mbedtls_config.h, line 4179:
* at the same pace. The typical accuracy of an RTC crystal is ±100 to ±20 parts
Is this intended?
Thanks
Stephan
The specification of the "psa_verify_message" function is simple enough:
pass a key ID, an algorithm ID, the data that were signed, the signature
received from the peer, and receive a status. There is just one tiny
problem: in the application, the algorithm ID is specified as a 16 bit
TLS SignatureScheme
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-si…),
which is not quite the same as "psa_algorithm_t". Is there a simple way
to covert from TLS SignatureScheme to PSA ALgorithm identifier? Maybe a
two columns table?
-- Christian Huitema
Hi,
I have an inhouse developed secure authentication program that uses certificate for authentication. I have used mbedtls library for the x.509 certificate verification purpose. In our custom PKI we have only three level of certificates, Root-CA -> Intermediate-CA -> Device-Cert.
The embedded device has very limited memory, so instead of sending whole certificate chain, the devices communicates intermediate_CA and device cert (in der format base64 encoded) in separate packet. Root-CA will be available on node as trusted-ca. Intermediate is verified against Root; then device cert is verified against intermediate.
The problem is, the poc developed on linux platform is working fine - but on embedded platform I encounter either 0x3b00(parsing failed) or 0x2700(with flag 8). Also the error code are inconsistent.
I verified the integrity of packet with certificate using crc16. So no chance of certificate getting corrupted. Also verified the certificate's base64 format integrity using crc16.
All certificates are sha256WithRSAEncryption; RSA Public-Key: (4096 bit)
Attached config.h on target platform for reference - could you help me if anything wrong with configuration.
While trying to trace, the flag was set from x509_crt.c from below code.
/* No parent? We're done here */
if( parent == NULL )
{
printf("NO_PARENT\r\n");
*flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED;
return( 0 );
}
Any clue would be helpful.
Thanks,
Gopi Krishnan
Hi, I'm having an issue with some code using Mbed TLS and I was pointed to this mailing list as the correct place to ask for support. Please let me know if I should ask somewhere else. I'm trying to connect to my local government's website via a Raspberry Pi Pico, using a TLS client based on lwIP and altcp_tls. It's based off of the example from the Raspberry Pi team here: https://github.com/raspberrypi/pico-examples/tree/master/pico_w/wifi/tls_cl… . My Mbed TLS config is the same as what they have there, aside from some extra defines I added for debugging. The issue I am facing is that while various hosts work fine (e.g. postman-echo.com for testing), when I attempt to connect to my local council's website I get a TLS handshake error. My client has TLS verification disabled for the moment, but I have tried with the correct root certificates as well. The error I receive is mbedtls_ssl_handshake failed: -30592 I cloned down the mbed_tls repo, and had a similar issue with ssl_client1 -- i.e. works on postman-echo, not for my government, with mbedtls_ssl_handshake returning the error. Notably however, the error code in that instance was -31488. Interestingly, ssl_client2 works flawlessly with both hosts. I wasn't quite sure what part of ssl_client2 would cause it to work with my government host, as it's several thousand lines long, but I'm sure the answer is in there somewhere. I've attached a trace taken with debug logging level 4 on my Pico which shows where the TLS handshake is failing. I'd really appreciate any guidance of areas to troubleshoot next. Thanks, Jay
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)
