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 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.
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 :)