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
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
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.
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
I have port mbedtls 2.28.0 into my platform and am able to connect to a few websites in PKI mode. But after enabling MBEDTLS_USE_PSA_CRYPTO & MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG, with everything else stay the same, I can't connect to the same websites anymore. in the working case (no MBEDTLS_USE_PSA_CRYPTO), after the client (my app) sends "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message", the server responds with "Change Cipher Spec, Encrypted Handshake Message". In the broken case (with MBEDTLS_USE_PSA_CRYPTO), after the client (my app) sends "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message", the server doesn't respond with "Change Cipher Spec, Encrypted Handshake Message". I don't know how to debug the issue, any suggestion what my cause the server to drop off at the last step?
I may need TLS 1.3 support which I believe arrived in 2.28, or maybe a
bit later.
I don't want to change to TLS 3 just yet. It looks like many changes.
My target is "OK" on FLASH (150k of the 350k total code size) but is
tight on RAM (after allocating 50k for the MbedTLS heap, we have just
20k RAM left).
Ideally I would like the very last version of v2.
The problem just found is that Cloudflare is asking for TLS 1.3 which
MbedTLS 2.16 does not support. But it may be that Cloudflare can fall
back and the problem is elsewhere.
Many thanks for any input.
Hi,
This is an updated post from https://github.com/Mbed-TLS/mbedtls/issues/6464,
which should be posted in mbedtls mail list.
My question is how to significantly improve SHA256 performance on big files
(regardless of architectures).
*=== Updates*
I use same code with mbedtls-3.1.0 to run tests in x86, and performance is
still downgraded.
Mbed TLS version (number or commit id): *3.1.0*
Operating system and version: * Centos-8.5, CPU 11900K*
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): *gcc/g++ 8.5*
Additional environment information:
*Test files and performance*
CentOS-8.5.2111-x86_64-boot.iso (827.3 MB): sha256 *5 sec*
CentOS-8.5.2111-x86_64-boot.iso (10.79 GB): sha256 *66 sec*
Also, as advised I try to turn on "MBEDTLS_SHA256_USE_A64_CRYPTO_IF_PRESENT
" and "MBEDTLS_SHA512_USE_A64_CRYPTO_IF_PRESENT" using mbedtls-3.2.0 in M1,
but compiler reported the following error:
CMake Error at library/CMakeLists.txt:257 (add_library):
Cannot find source file:
psa_crypto_driver_wrappers.c
Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h
.hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc
CMake Error at library/CMakeLists.txt:257 (add_library):
No SOURCES given to target: mbedcrypto
Thanks for your help.
*=== Original message at github*
Summary
sha256() and sha1() incurs significant overhead on big files(~1G above). *This
might not be an issue*, and I'm looking for an efficient way to calculate
hash on big files.
System information
Mbed TLS version (number or commit id): 3.1.0
Operating system and version: M1 OSX
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): Clang++
Additional environment information:
Expected behavior
Fast calculation of big files in less than 1 second
Actual behavior
Test files:
CentOS-8.5.2111-x86_64-boot.iso (827.3 MB): sha1 *3.3 sec*, sha256 *5.9
sec*
CentOS-8.5.2111-x86_64-boot.iso (10.79 GB): sha1 *40 sec*, sha256 *78
sec*
Steps to reproduce
ISO files can be downloaded at:
http://ftp.iij.ad.jp/pub/linux/centos-vault/8.5.2111/isos/x86_64/
Make sure use fast disk, say nvme, to store ISO files, or else loading big
files could take lots of time. Also use user from time command to measure
performance.
Workable code of sha256:
string test_sha256(string file_path)
{
mbedtls_sha256_context ctx;
FILE *fp;
string output;
int BUFFER_SIZE = 4096;
uint8_t buffer[BUFFER_SIZE];
size_t read, k_bytes;
uint8_t hash[32];
mbedtls_sha256_init(&ctx);
mbedtls_sha256_starts(&ctx, 0);
fp = fopen(file_path.c_str(), "r");
if (fp == NULL)
{
mbedtls_sha256_free(&ctx);
return output;
}
while ((read = fread(buffer, 1, BUFFER_SIZE, fp)))
{
mbedtls_sha256_update(&ctx, buffer, read);
}
mbedtls_sha256_finish(&ctx, hash);
mbedtls_sha256_free(&ctx);
fclose(fp);
// update hash string, omit here
return output;
}
Hi All,
There are machines out there for testing servers but I don't know of
one which can be used for testing a client.
This is a tricky area. For example I have a board running, LWIP and
MbedTLS, uploading little test files to two sites.
One was running EC and AES256. It worked fine.
The other was running RSA and AES256 but didn't work, and after some
work it was found that its certificate chain was running SHA-1 on the
top level certificate, dated 2006. This is actually a major name on
the internet! And we didn't have SHA-1 enabled because it is supposed
to be deprecated.
I wonder if there is some practical way to test out all this. We can
probably enable all the MbedTLS crypto options (TLS is taking up 150k
out of 350k of code for the whole product, but we can probably throw
in some more) but testing them is something else.
There is a test suite in TLS but it needs to be embedded in the
product itself. Has someone implemented that code on a server
somewhere?
Thank you in advance for any pointers.
Peter
I meet a problem when I call function `psa_crypto_init`, it return error code -148 that was PSA_ERROR_INSUFFICIENT_ENTROPY.
I track this function step by step and found it caused by MBEDTLS_ERR_ENTROPY_NO_SOURCES_DEFINED. Code in entropy.c, if( ctx->source_count == 0 ), return this error.
My question:
I run code on Ubuntu, it runs well. But in some arm board, it returns this error. Why this count will be 0 sometimes? What is the root cause of this error.
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
Hi,
I have developed a TLS and EST client application. Where the EST server issues the certificate in PKCS#7 format. It seems mbedtls library not support certificates in PKCS#7 format.
Is there any plan to support PKCS#7 in future?
Thanks,
Gopi Krishnan
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next *Monday, Oct 10 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
Hello
Please note that this is a repost from my previous message from yesterday
as it seemd to have bugged (empty text + html attachement) when viewed
from the archive. Apologies.
Short question :
how do i output an in-memory mbedtls_x509_crt chain to PEM text ?
Context :
I have a project where the user provides a PEM bundle to be used for HTTPS
As it is provided by a user, may be incomplete or malformed :
- no private key
- more than 1 private key
- no certificate at all
- duplicate certificates
- no certificate matching the private key
- broken chain
- extraneous certificates not part of the chain…
So i want to full validate user input.
Here is what i have succeeded so far :
- parse the bundle into atomic parts, based on « BEGIN/END » labels
- try to mbedtls_x509_crt_parse / mbedtls_pk_parse_key each part (no chain)
- check that i only have one private key in the bundle
- search for the certificat C matching the private key
- starting from that atomic certificate, verify it against each other
candidate certificate
- if it validates, add it to the chain of C, and repeat until no
candidate validates
- then check that there are no remaining certificate (which never
validated anything)
- finally print and store the chain (as it’s now deemed correct and minimal)
Now i want to store it in PEM format for later use.
But i do not understand the way to do it :
- there are no write functions for mbedtls_x509_crt
- the mbedtls_x509write_cert structure shares few members with mbedtls_x509_crt
- i have not found yet how to get/convert many of the missing members
- as memory is tight i have have cleaned the « atomic parts » text buffers
(but if there is no other way, i'll keep and reuse them)
I guess it should be pretty simple, but i cannot wrap my head around it.
Thanks in advance for your help
Nicolas
PS : if steps 1-8 could be done more elegantly, please do not
hesitate to point me in the right direction.
Hi,
In mbedTLS road map, there is a future task to remove legacy cipher API (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/). Does that mean all existing mbedtls crypto APIs will not be supported anymore?
mbedTLS is used for both its TLS and crypto library. I am curious how the planned changes will affect both set of users.
* Are the crypto library users expected to only use PSA crypto APIs and key IDs?
* Are the TLS library users expected to see API changes to TLS functions to support key IDs?
Thank,
Archanaa
Hi guys,
I use mbedtls for years (since 2.10 IIRC) upgrading to latest available as time goes by. For DTLS that is.
I remember a case in the past where a link would have a small MTU (around 500 bytes) and I had to tune ssl_context.handshake.mtu to a lower value to successfully complete handshakes.
I do not remember exactly why, but I did not want to actually restrict maximum value via mbedtls_ssl_set_mtu, maybe it was even ignored back then for handshakes… but
Now when working on migration to 3.2.1 (gave some time to 3x releases to stabilize) I noticed that the whole ssl_context.handshake member is now private and inaccessible, which I guess is fine.
Could somebody with more knowledge of the code recommend what is the best strategy for DTLS app where MTU may not always be 1400?
thanks a lot for your time,
Martin
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
We're seeing pretty much the same issue on 3.0.0 ARM. However, if I build the ssh_client2 tool on my host machine (x64) and try to mimic the config as close as possible, it works just fine.
Do you think we're seeing the same problem? Will try with a newer version next week.
Hello,
I am wondering if there are APIs for Hmac and Cmac verification?
from md.h and cmac.h, Hmac and Cmac generation functionalities are provided
in a single and streaming approach. But is there a plan to add verification
APIs for future releases maybe?
Kind regards,
Ahmed Mohammed
Hello,
What is the difference between these two macros in
include/mbedtls/build_info.h:
MBEDTLS_CONFIG_FILE
MBEDTLS_USER_CONFIG_FILE
In other words, why would I have two different user configuration files? Or
I misunderstand the difference between such files.
Kind regards,
Ahmed Mohammed
I am verifying a signature generated using ecdsa secp256r1. The signature is getting verified but the time taken by the verification step is too long. It takes 4-5 seconds to verify the signature. The implementation is bare metal i.e. no RTOS (one realizes the use of RTOS but still the time is too long). Can you please guide a way around for this issue. How to make it work faster , the ideal verification time would be 30ms - 60ms.
Here is a gist of my code
mbedtls_ecp_curve_info *curve_info = NULL;
mbedtls_ecdsa_context ecdsa_context;
/// Initialization
mbedtls_ecdsa_init(&ecdsa_context);
curve_info = mbedtls_ecp_curve_info_from_tls_id(23); /// 23 is tls_id of secp256r1
mbedtls_ecp_group_load(&ecdsa_context.grp, curve_info->grp_id);
/// Processing
result = mbedtls_ecp_point_read_binary(
&ecdsa_context.grp,
&ecdsa_context.Q,
public_key_data, // public key data in uncompressed format i.e. including leading 0x04
sizeof(public_key_data)
);
/// 32 /// 71
status_verify_signature = mbedtls_ecdsa_read_signature(&ecdsa_context, hash, sizeof(hash), signature, sizeof(sig)); /// converts the signature data to ASN1, verifies the signature
Thank you :)
Hello,
Can please provide me with any example on "how to achieve Mutual
authentication(Client and server certificate validation)" in mbed-tls.
Please help me with this.It is a little urgent.
Thank you
Regards
Anupma Jain
Hi all,
Apologies for the website outage. We have now restored the majority of the old content, which is reachable via our Trusted Firmware website (the old website address will redirect here). The new location for our documentation, including the knowledge base and security advisories, is:
https://mbed-tls.readthedocs.io/en/latest/
Please let us know (on the mailing list, via the Tech Forum, or raise a GitHub issue or PR) if you find any issues or missing documentation. The source repository for the docs is here:
https://github.com/Mbed-TLS/mbedtls-docs
Community contributions to the docs are welcome!
Regards
Dave Rodgman
Hi,
We have developed a propriety protocol that authenticate node using certificate. In our PKI, we have four level of certificates as ROOT_CA, PROXY_CA, LOCAL_CA, and DEVICE_CERTIFICATE. Parsing of trusted CA certificate is getting success. However, verifying PROXY_CA against ROOT_CA fails with below error code.
MBEDTLS_ERR_X509_UNKNOWN_SIG_ALG + MBEDTLS_ERR_OID_NOT_FOUND
I have viewed the certificates transacted using OpenSSL command, the ASN1 OID is ECDSA_SHA384. Though, I have enabled the algorithm, it is failing. Any support would be appreciated. Attached the config.h for your reference.
Thanks,
Gopi Krishnan
After recently updating mbedtls I noticed a considerable slowdown (over 70% on my cortex-m7 board) in the sha256 implementation, and after some digging I found the offending commit:
https://github.com/Mbed-TLS/mbedtls/commit/76749aea784cfec245390d0d6f0ab0a2…
I understand the motivation behind the commit, but I think it may not be relevant to all use cases.
So my question is if an option to disable the clearing of internal buffers in mbedtls_config.h would be a reasonable improvement? Or would that be considered to much of a foot gun?
Regards,
Joel Petersson
Hi,
In Embed tls version 2.28, is there any support to validate
client certificate fields like for example: validity of certificate, CA
validation or role extraction ?
If support is present then, how can we enable that ?
Please help me with this.Thanks in advance.
Regards
Anupma
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
hello, we are testing a secure communication and got example code that uses the mbed-tls library. i am using the online keil studio with mbed.org: created a new project (compiles fine) and added in the mbed-tls library but this already gives compile errors. see below. i am using the latest greatest versions (mbed-os 6.16.0 and mbedtls-3.2.1) and tried some older versions. all seem to give the same problems. see below.
i have tried commenting out MBEDTLS_HAVE_TIME in mbedtls_config.h but that does not seem to make any difference
tried different target boards, also no difference
any help is greatly appreciated!
thanks
frank
Build started
Using toolchain ARMC6 profile {'ENV': {'ARMLMD_LICENSE_FILE': '8224@10.10.101.194:8224@10.10.109.222'}, 'PATHS': {'ARMC6_PATH': '/opt/ARMCompiler6.15.13/bin/', 'ARM_PATH': '/opt/armcc5_06_u6/'}, 'common': ['-c', '--gnu', '-O3', '-Otime', '--split_sections', '--apcs=interwork'], 'cxx': ['--cpp', '--no_rtti'], 'COMPILE_C_AS_CPP': False, 'NEW_SCAN_RESOURCES': True}
scan /tmp/chroots/ch-59110c86-ee99-44c4-9ef0-79f3efde74a7/src
scan /tmp/chroots/ch-59110c86-ee99-44c4-9ef0-79f3efde74a7/extras/mbed-os.lib
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Config/RTX_Config.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/TOOLCHAIN_ARM/TARGET_RTOS_M4_M7/irq_cm4f.S
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_evflags.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_lib.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_mempool.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Library/cmsis_os1.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_evr.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_memory.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_delay.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_msgqueue.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_kernel.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_mutex.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_semaphore.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_system.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/Source/os_systick.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/TARGET_CORTEX_M/Source/mbed_tz_context.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_timer.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/Source/os_tick_ptim.c
compile mbed-os/cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_thread.c
"time.h included in a configuration without MBEDTLS_HAVE_TIME"
unknown type name 'time_t'; did you mean 'size_t'?
unknown type name 'time_t'; did you mean 'size_t'?
unknown type name 'time_t'; did you mean 'size_t'?
compile mbed-os/cmsis/device/rtos/source/mbed_rtos_rtx.c
In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23:
In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21:
In file included from /extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:107:
/src/mbedtls/tests/include/baremetal-override/time.h:18:2: error: "time.h included in a configuration without MBEDTLS_HAVE_TIME"
#error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
^
In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23:
In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21:
/extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:669:5: error: unknown type name 'time_t'; did you mean 'size_t'?
time_t st_atime; ///< Time of last access
^~~~~~
size_t
/opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here
typedef unsigned int size_t; /* see <stddef.h> */
^
In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23:
In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21:
/extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:670:5: error: unknown type name 'time_t'; did you mean 'size_t'?
time_t st_mtime; ///< Time of last data modification
^~~~~~
size_t
/opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here
typedef unsigned int size_t; /* see <stddef.h> */
^
In file included from /extras/mbed-os.lib/cmsis/device/rtos/source/mbed_rtos_rtx.c:23:
In file included from /extras/mbed-os.lib/platform/include/platform/mbed_error.h:21:
/extras/mbed-os.lib/platform/include/platform/mbed_retarget.h:671:5: error: unknown type name 'time_t'; did you mean 'size_t'?
time_t st_ctime; ///< Time of last status change
^~~~~~
size_t
/opt/ARMCompiler6.15.13/bin/../include/stdio.h:53:26: note: 'size_t' declared here
typedef unsigned int size_t; /* see <stddef.h> */
^
4 errors generated.
Internal error.
Build failed
Build failed
Hi all,
I have some questions.
1) If you have an established TLS connection (mbed TLS 3.x) and while the
connection is up the (server-) certificate expires: Will the connection stay
up? Or is a new handshake (with valid cert) REQUIRED?
2) Related to question 1: CAN mbed TLS switch to a new cert on an existing
TLS connection? (e.g. by doing another handshake from server OR client side)
3) With 3.x some struct members are now "private". Even if you can allow
private access by a define it would be better to use a getter. But for ssl
context's "state" I am missing this and also for "p_bio" (to access fd). Is
there a chance to get this implemented?
BTW - a big "LIKE" for 3.x! I really appreciate the changes. Thank you!
kind regards,
Frank
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is tomorrow (Monday) at 4:30 PM UK time.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi Mbed TLS users,
We have released Mbed TLS version 3.2.1.
This release is functionally identical to 3.2.0, but includes a file that was missing from the 3.2.0 release (see https://github.com/Mbed-TLS/mbedtls/issues/6084).
Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.2.1).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Many thanks,
Mbed TLS Team.
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
Hi Mbed TLS users,
We have released Mbed TLS versions 3.2.0 and 2.28.1.
These releases of Mbed TLS address several security issues, provide bug fixes, and for 3.2.0, add various features. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.2.0, https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.1).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Dave Rodgman
Hi mbed-tls Team,
I notice that https://tls.mbed.org has been directed to https://www.trustedfirmware.org/projects/mbed-tls/. However, I does not see any link to the old Mbed TLS knowledge base. It is a good resource for learning Mbed TLS. What is the URL to access it?
Thanks,
Max Peng
Hi all,
it feels like the state of documentation has deteriorated since the last
time I've used mbedtls (a couple of months ago). I'm not sure if the google
index hasn't fully been updated yet, or I don't understand the new
structure of the docs or ...
Also, is this the proper forum to make suggestions? Should I raise an issue
on Github?
1.) a lot of previously linked, useful information now redirects here:
https://www.trustedfirmware.org/projects/mbed-tls/ which (please excuse my
frankness) feels like an utterly useless abomination that only marketing
people could love.
- Some examples of previously useful links: from the wiki (
https://developer.trustedfirmware.org/w/mbed-tls/) :
> Old Mbed TLS website
> Documentation: Mbed TLS API Reference; Knowledge base; Dev corner
all redirect to trustedfirmware.org ! As do nearly all the links in
https://github.com/Mbed-TLS/mbedtls/blob/development/SUPPORT.md
2.) there is no longer an doxygen generated API documentation anywhere
only. I could generate it myself, but then I'd need to get and install
Doxygen, figure how to use it, etc. It would be great if this were
restored. It can't be that expensive to host :)
Anyway, it feels like I've been running around for hours trying to find
_anything_ useful, but I just realized everything is redirected to
trustedfirmware.org ... Is there any way to still access the old, useful
docs?
Thanks & sorry that this post is so negative,
-tim
Hello Sir/Madam,
I am developing TI's EFM32 series micro controller based IOT device. This
device will connect to mqtt broker and publish/ subscribes to/from data.
In my application, I am trying to connect to AWS using mbedtls library over
lwIP (no rtos mode). While my device is in debug mode (i.e. JTAG programmer
connected) then it gets connected to AWS successfully. But when I remove
JTAG programmer and operate device in normal running mode, then it failed to
get connect to broker (i.e. AWS).
I observe following errors occured while performing TLS handshaking stage:
SSL - The connection indicated an EOF
X509 - Certificate verification failed, e.g. CRL, CA or signatur
SSL - Processing of the ServerHello handshake message failed
Hi all,
First of all apologies if this is not the right place for this topic. For my master thesis I am using the mbedtls library to analyze it using side channel analysis.
My objective was to use it as a starting point to analyze the resistance of different exponentiation algorithms.
With this objective I am trying to set up a environment where I can call the function "mbedtls_mpi_exp_mod" https://github.com/Mbed-TLS/mbedtls/blob/f5b7082f6e8af72868966b6ea99eae228f… and debug it. I have been trying for at least two weeks but I couldn't be able to succeed.
I believe that when If I can get a debugging environment for that function I will be able to adapt it and use other exponentiation algorithms such as the Left-to-right k-ary (HAC 14.82).
I am using VScode and the code is located in WLS Ubuntu 20.04. So far I been able to compile the full library and run all the tests.
Anyone here could give mean indication on how to set up the environment to debug this function?
Thanks!
Victor.
Hello,
Currently, we are evaluating the MbedLib to be eventually used in small and midsized automotive ECUs.
* Since we have to follow the UNECE Regulation R155, R156, and ISO/SAE 21434 I need some information regarding the long-term support of the library and how the communication of bugs is organized?
* I also do not understand the involvement and responsibility of ARM company?
* Furthermore, I'm not sure if I understood the terms PSA and MbedTls and their mutual dependencies as well as the technical meaning?
I checked the web for I but did not find anything about it yet.
It would be just great if somebody can give me some hints or links to the information I am looking for.
Regards Heico
I have an application using mbedTls 2.9.0 that's been running successfully for a few years. It secures connections for the AWS MQTT broker, for https GET/PUT transfers, and for SSL/TLS email servers - But only one secure connection at a time. I need to add support for an FTPS client. This requires opening/securing a control channel on port 21, then opening/securing a second port for data transfer.
Opening/securing the control channel works as expected. Then, when the client calls connect() for the data transfer socket, the server log shows messages indicating it is preparing for a TLS handshake.
Now, here's where I may be missing something... The client calls the same code as for the control connection: Allocates a second mbedtls_ssl_context, mbedtls_ssl_config, mbedtls_x509_crt, et.al, and calls some mbedtls_ssl_*() functions which were copy/pasted from example code several years ago. The server name and root cert are the same. I think the only difference in the second negotiation is the underlying socket descriptor allocated by the IP stack for the data channel.
When mbedtls_ssl_handshake() is called, both the filezilla log and client log show a successful handshake. The filezilla log then shows it trying to establish yet another secure data connection, which fails, and reports "TLS session of data connection not resumed."
Questions:
-- Is the above sequence correct for opening and securing a second connection?
-- In searching through ssl.h I see mbedtls_ssl_get_session() and mbedtls_ssl_set_session(). Are these relevant to the situation? I cannot tell from their one-sentence descriptions.
Hi
I just needed to use rsa.c but its a little complicated.
Can anyone help me or give me any document about how i can use it without use of tls.
I just saw a doc on tls.mbed.org but the site is not working anymore.
Hello,
currently, I am evaluating the mbed-tls. I already created some smaller demos regarding AES and RSA. I do so on a PC with cygwin and with Keil micro vision for a NXP S32K144.
One demo is just validating some data with a signature and an existing public key. Here is the point that puzzles me a bit. As far as I understand this cybersecurity stuff entropy is not needed for the above use case. Some of my colleagues would agree with me.
Once psa_crypto_init() is called on a target NXP S32K144 the function returns PSA_ERROR_INSUFFICIENT_ENTROPY.
So far so good
https://os.mbed.com/docs/mbed-os/v6.15/porting/entropy-sources.html
gives the hints on how to handle this in general but I did not find any information on how to disable the "request for entropy" in a save way once your use case does not need any new secrets.
Can you give me a hint why psa_crypto_init() is implemented that way?
It may also be that I still have a conceptual understanding problem!?
Regards
Heico
Hi mbed-tls Team,
PSA crypto API for HW acceleration seems pretty new.
Question1: is there some reference code or project I could poke around to see how it is being used?
Currently I have added (locally) a set of driver to make use of our HW crypto using the *_ALT way (the old way?) and for what I understand, the PSA API is the "new way" to do things.
But It is still unclear how vendor do upstream there HW acceleration drivers.
If this part is kept in another repo, then the mbedTLS build does not have any "hooks" to pull-in the vendor specific code to build the mbedTLS library with.
The current implementation seems to be agnostic to any vendor specific HW so I am wondering if there is a "standard" way for vendor to upstream their mbedTLS HW acceleration code that would be built as part of mbedTLS library.
I have posted a similar thread to the "issue" ticket of the mbedtls repo for reference: https://github.com/Mbed-TLS/mbedtls/issues/5975
Thanks for any feedback/pointers/ideas.
Regards,
-Mathieu
Hi All,
My target has 128k SRAM which has about 60k spare, and 64k CCM which
is allocated whole to FreeRTOS stacks etc (its private heap, memory
model #4).
I am running a simplified HTTP server (for local config etc), which
uses fairly minimal RAM (a few k), and an HTTPS/TLS client which uses
about 50k (for its private heap).
So if both of the above are running concurrently, there is only ~10k
RAM left, but it does work, but when TLS is doing its
handshake/negotiation (which on a 168MHz 32F417 takes 2-3 seconds) the
HTTP server temporarily hangs.
Investigating this, it appears that LWIP is running out of buffers
during TLS and is rejecting incoming packets.
I don't really want to change the CPU to the next one up which has
another 64k RAM, because a) I have stock of the 417 and this took
about a year to get, b) the design is rock solid and I don't want to
tempt fate (there is a lot of subtle hardware usage e.g. DAC ADC DMA
timers) even though in theory it should be just alternate function pin
changes, c) some versions of the product may not need TLS at all.
I have an option of an 8 megabyte SPI-attached RAM
https://www.eevblog.com/forum/microcontrollers/lyontek-ly68l6400-8-megabyte…
which does work and is not bad at $3 (there are cheaper 128kbyte
versions too), but obviously cannot be addressed as normal RAM. The
ESP32 can do that but the 32F4 can't.
Does anyone know enough about the internals of MbedTLS, or even LWIP,
to know whether the memory usage structure lends itself to this kind
of "overlay" memory? One can read or write say 1k bytes in 400us, in
my target (21MHz SPI with DMA). Obviously this would be horribly
inefficient for a byte at a time emulation but perhaps one can switch
buffers in and out...
Thank you in advance. If somebody knows of a concrete route, I am
happy to pay for the time.
Regards,
Peter
Hi All, This is a gentle reminder that the next MBed TLS Tech forum is next
Monday 4:30 PM UK time. If you have any topics, please let Dave Rodgman
know. :) Best regards, Don
MBed TLS Technical Forum
Monday Jul 4, 2022 ⋅ 8:30am – 9:30am
Mountain Standard Time - Phoenix
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: MBed TLS Technical Forum
Time: Oct 25, 2021 04:30 PM London
Every 4 weeks on Mon, 20 occurrence(s)
Oct 25, 2021 04:30 PM
Nov 22, 2021 04:30 PM
Dec 20, 2021 04:30 PM
Jan 17, 2022 04:30 PM
Feb 14, 2022 04:30 PM
Mar 14, 2022 04:30 PM
Apr 11, 2022 04:30 PM
May 9, 2022 04:30 PM
Jun 6, 2022 04:30 PM
Jul 4, 2022 04:30 PM
Aug 1, 2022 04:30 PM
Aug 29, 2022 04:30 PM
Sep 26, 2022 04:30 PM
Oct 24, 2022 04:30 PM
Nov 21, 2022 04:30 PM
Dec 19, 2022 04:30 PM
Jan 16, 2023 04:30 PM
Feb 13, 2023 04:30 PM
Mar 13, 2023 04:30 PM
Apr 10, 2023 04:30 PM
Please download and import the following iCalendar (.ics) files to your
calendar system.
Weekly:
https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics…
Join Zoom Meeting
https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT…
Meeting ID: 959 6263 5632
Passcode: 018366
One tap mobile
+13462487799,,95962635632# US (Houston)
+16699009128,,95962635632# US (San Jose)
Dial by your location
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Washington DC)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 959 6263 5632
Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y
Guests
psa-crypto(a)lists.trustedfirmware.org
mbed-tls(a)lists.trustedfirmware.org
nnac123(a)gmail.com
Hi all,
We're seeking feedback on our plans regarding support for Finite-Field DHE (also known as FFDH(E), as opposed to the Elliptic Curve version, ECDH(E)).
Currently the PSA Crypto API only supports FFDH with named groups, which aligns well with modern cryptographic practice and the needs of TLS 1.3, but less well with TLS 1.2 where arbitrary parameters can be chosen by the server, leading to various interoperability and security issues (see the introduction of RFC 7919, hence the general move to named groups).
Some data suggests that FFDH is already seeing very little use (less than 1% of TLS 1.2 traffic) on major websites, and presumably this would be even less when constrained devices are involved, since ECDH is less resource-intensive.
So, we are currently planning on removing support for DHE-RSA and DHE-PSK key exchanges in TLS 1.2 in the next major version of Mbed TLS. We would retain support of ECDHE in TLS 1.2, and of DHE (in addition to ECDHE) in TLS 1.3. (Support for FFDH in TLS 1.2 would also be present in the LTS version released around the same time as the next major version.)
If you have any objection to this plan, please let us know about your use case and motivations, either by responding to this email, or by commenting on the corresponding github issue: https://github.com/Mbed-TLS/mbedtls/issues/5278 Thank you!
Best regards,
Manuel for the Mbed TLS team.
Hi,
I have one root ca, intermediate ca, and device certificate in der format.
While am trying to verify one by one as intermediate-ca with root-ca and device cert with intermediate-ca; things work fine.
But if I tried to verify like having two context one for ca and one chain. I parse root ca on CA context and intermediate ca and device cert on chain context. Now verification fails with flag 8 error code -0x2700.
I have attached verify_der_one_by_one.c it is working without any issue; but verify_der_chain.c is causing the issue stated above.
Any help would be appreciated.
Thanks,
Gopi Krishnan
Hello,
Mbed TLS supports AES acceleration with VIA Padlock (MBEDTLS_PADLOCK_C).
We do not have the hardware to test it, so this should be considered
strictly community-maintained.
We are making a patch to the AES module which has a small risk of
breaking VIA padlock support:
https://github.com/Mbed-TLS/mbedtls/pull/5896 . If you are using VIA
padlock, please test this change and let us know if something's wrong.
On a related note, we intend to drop the Padlock code in the next major
version of Mbed TLS (https://github.com/Mbed-TLS/mbedtls/issues/5903).
If you care about this feature, please let us know.
Best regards,
--
Gilles Peskine
Mbed TLS developer