November 2022 - mbed-tls - lists.trustedfirmware.org

by Subramanian Gopi Krishnan

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

8 months, 4 weeks

2
1
0 0

About setting arbitrary RDN while generating a CSR with mbedtls

by Aditya Patwardhan

I am using mbedtls_x509write_csr_set_subject_name API from mbedtls to set the subject name. I wanted to set the arbitrary old value in my certificate for e.g. ffeBgt9jDHhBwPDANgtT7R/1.3.6.1.4.1.37244.2.1=FFF2/1.3.6.1.4.1.37244.2.2=8001 In this case ffeBgt9jDHhBwPDANgtT7R is the CN And 1.3.6.1.4.1.37244.2.1 is an arbitrary OID which has a value of FFF2 similar to the second arbitrary OID. I am able to do this through openssl commands, but while doing it through mbedtls, when I pass it as a string then mbedtls considers the whole string as CN which Is not my intention. Please fine the asn1 parsing of the CSR as below CSR generated through mbedtls: 18:d=5 hl=2 l= 3 prim: OBJECT :commonName 23:d=5 hl=2 l= 76 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R/1.3.7.1.4.1.37466.2.1=FFF2+1.3.7.1.4.1.37466.2.2=8001 101:d=3 hl=2 l= 11 cons: SET 103:d=4 hl=2 l= 9 cons: SEQUENCE Target CSR ( done thorough openssl): 14:d=4 hl=2 l= 29 cons: SEQUENCE 16:d=5 hl=2 l= 3 prim: OBJECT :commonName 21:d=5 hl=2 l= 22 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R 45:d=3 hl=2 l= 20 cons: SET 47:d=4 hl=2 l= 18 cons: SEQUENCE 49:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.1 61:d=5 hl=2 l= 4 prim: UTF8STRING :FFF2 67:d=3 hl=2 l= 20 cons: SET 69:d=4 hl=2 l= 18 cons: SEQUENCE 71:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.2 83:d=5 hl=2 l= 4 prim: UTF8STRING :8001 89:d=2 hl=2 l= 89 cons: SEQUENCE 91:d=3 hl=2 l= 19 cons: SEQUENCE 93:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 102:d=4 hl=2 l= 8 prim: OBJECT :prime256v1 Am I missing something here? Do I need to provide the CN in a different way to get the intended result? I found an open issue https://github.com/Mbed-TLS/mbedtls/issues/4886, could it be related to this? Any help would be appreciated. Thanks and Regards, Aditya

2 years, 1 month

2
1
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Dec 5 at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. As usual, if anyone has any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 2 months

1
0
0 0

RSA signature with Montgomery

by Prasad Hegde

Hi, Is there any API's available to convert the RSA signature to the Montgomery format. Thanks Prasad

2 years, 2 months

1
0
0 0

Code style discussions

by David Horstmann

Hi All, Mbed TLS is planning to move to a new code style by the end of this year. The proposed new style is currently being discussed in the GitHub pull request: https://github.com/Mbed-TLS/mbedtls/pull/6591 If you have any feedback on this new style, or you think we should tweak it, feel free to comment on the pull request. We will take your thoughts into account when we decide on the final style. Discussions will continue until the evening of THIS FRIDAY (UK time). Many thanks, David Horstmann for the Mbed TLS Team

2 years, 2 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. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 2 months

1
0
0 0

Certificate Verify in Client Authentication does not work as expected

by Simon Nachtigall

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

2 years, 2 months

2
1
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

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

2 years, 2 months

1
0
0 0

Simple question about support of TLS1.2 and TLS1.3 on server side

by caoyxsh＠outlook.com

Is there a plan for adding support of TLS 1.2 and TLS 1.3 at same time on server side? According to : https://github.com/Mbed-TLS/mbedtls/blob/development/docs/architecture/tls1… only one version can be configured at runtime via `mbedtls_ssl_conf_{min,max}_tls_version` for a server endpoint.

2 years, 2 months

1
0
0 0

Get size of available application data without calling mbedtls_ssl_read()

by Bruckner, Jan

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.

2 years, 2 months

1
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls November 2022