- mbed-tls - lists.trustedfirmware.org

by Olivier Deprez

Hi Shripad, Cross-posting to mbed-tls ML. I noticed though you already sent the same query to this list. Regards, Olivier. ________________________________ From: shripad.nunjundarao--- via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 06 March 2024 05:39 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] mbedtls and PQC algorithms support Hi, Is there a plan for mbedtls to add support for PQC algorithms (Dilithium/Khyber)? regards, /Shripad -- TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org

1 year, 9 months

1
0
0 0

Handshake Fails Server Side error fatal:unexpected_message

by Satya Prakash Prasad

We are testing the HosatAP module integrated with MBedTLS version 2.19.1. But we are receiving an error during the SSL handshake. In Server side we are using hostapd daemon - we see the below error: SSL: SSL_accept:SSLv3/TLS write server done OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=21 (alert/) OpenSSL: Message - hexdump(len=2): [REMOVED] SSL: (where=0x4008 ret=0x20a) SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unexpected_message authsrv: local TLS alert: unexpected_message SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in error OpenSSL: openssl_handshake - SSL_connect error:141A20F4:SSL routines:ossl_statem_server_read_transition:unexpected message SSL: 7 bytes pending from ssl_out SSL: Failed - tls_out available to report error *EAP-TLS: CONTINUE -> FAILURE* OpenSSL: Session was not cached EAP: Session-Id - hexdump(len=0): [NULL] EAP: EAP entering state SELECT_ACTION EAP: getDecision: method failed -> FAILURE EAP: EAP entering state FAILURE EAP: Building EAP-Failure (id=134) In wireshark logs we see the below details: Frame 52: 226 bytes on wire (1808 bits), 226 bytes captured (1808 bits) on interface \Device\NPF_{87758CCA-2149-4961-9FDA-E59432A16D13}, id 0 Ethernet II, Src: DanfossDrive_00:8c:94 (00:1b:08:00:8c:94), Dst: Nearest-non-TPMR-bridge (01:80:c2:00:00:03) 802.1X Authentication Version: 802.1X-2004 (2) Type: EAP Packet (0) Length: 208 Extensible Authentication Protocol Code: Response (2) Id: 168 Length: 208 Type: TLS EAP (EAP-TLS) (13) EAP-TLS Flags: 0x00 0... .... = Length Included: False .0.. .... = More Fragments: False ..0. .... = Start: False Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 197 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 193 Version: TLS 1.2 (0x0303) Random: 259e9db9530f8afbc74536b9a963b4f1c4cb738bcea7403d4d606b6e074ec5d3 GMT Unix Time: Jan 1, 1990 05:30:57.000000000 India Standard Time Random Bytes: 530f8afbc74536b9a963b4f1c4cb738bcea7403d4d606b6e074ec5d3 Session ID Length: 0 Cipher Suites Length: 80 Cipher Suites (40 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM (0xc0ad) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM (0xc09f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (0xc0af) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM_8 (0xc0a3) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM (0xc0ac) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CCM (0xc09e) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xc0ae) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CCM_8 (0xc0a2) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_256_CCM (0xc09d) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_256_CCM_8 (0xc0a1) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_128_CCM (0xc09c) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_128_CCM_8 (0xc0a0) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 72 Extension: signature_algorithms (len=22) Type: signature_algorithms (13) Length: 22 Signature Hash Algorithms Length: 20 Signature Hash Algorithms (10 algorithms) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA224 ECDSA (0x0303) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: SHA224 RSA (0x0301) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ecdsa_sha1 (0x0203) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: RSA (1) Extension: supported_groups (len=24) Type: supported_groups (10) Length: 24 Supported Groups List Length: 22 Supported Groups (11 groups) Supported Group: secp521r1 (0x0019) Supported Group: brainpoolP512r1 (0x001c) Supported Group: secp384r1 (0x0018) Supported Group: brainpoolP384r1 (0x001b) Supported Group: secp256r1 (0x0017) Supported Group: secp256k1 (0x0016) Supported Group: brainpoolP256r1 (0x001a) Supported Group: secp224r1 (0x0015) Supported Group: secp224k1 (0x0014) Supported Group: secp192r1 (0x0013) Supported Group: secp192k1 (0x0012) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: encrypt_then_mac (len=0) Type: encrypt_then_mac (22) Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: session_ticket (len=0) Type: session_ticket (35) Length: 0 Session Ticket: <MISSING> [JA4: 12i400600_9479543b8654_7b0ba9b4cf08] [JA4_r [truncated]: 12i400600_002f,0033,0035,0039,003c,003d,0067,006b,009c,009d,009e,009f,00ff,c009,c00a,c013,c014,c023,c024,c027,c028,c02b,c02c,c02f,c030,c09c,c09d,c09e,c09f,c0a0,c0a1,c0a2,c0a3,c0ac,c0ad,c0ae,c0af,cca8,cca9,ccaa_000a,000b,] [JA3 Fullstring [truncated]: 771,52392-52393-52394-49196-49200-159-49325-49311-49188-49192-107-49162-49172-57-49327-49315-49195-49199-158-49324-49310-49187-49191-103-49161-49171-51-49326-49314-157-49309-61-53-49313-156-49308-60-47-49312-255] [JA3: fee1630eb5b7688c9f8303364702933f] As you can see the Session Ticket details are missing and that Length 0 field is the last byte in the message but still in Wireshark we see other details like JA4, JA4_r etc? Is the "Client Hello" response from the client in the correct format?

1 year, 9 months

1
0
0 0

Handshake Fails Server Side error fatal:unexpected_message

by Satya Prakash Prasad

Hi, We are testing the HosatAP module integrated with MBedTLS version 2.19.1. But we are receiving an error during the SSL handshake. In Server side we are using hostapd daemon - we see the below error: random: getrandom() support available Configuration file: data/eap/hostap-standalone/hostapd_newCrt.conf Opening raw packet socket for ifindex 4 BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits) Using existing control interface directory. eaptest1: IEEE 802.11 Fetching hardware channel/rate support not supported. Completing interface initialization hostapd_setup_bss(hapd=0x564a594121c0 (eaptest1), first=1) eaptest1: Flushing old station entries eaptest1: Deauthenticate all stations Using interface eaptest1 with hwaddr 02:11:11:11:11:11 and ssid "" TLS: Trusted root certificate(s) loaded OpenSSL: tls_use_private_key_file (PEM) --> loaded eaptest1: interface state UNINITIALIZED->ENABLED eaptest1: AP-ENABLED eaptest1: Setup of interface done. ctrl_iface not configured! Received EAPOL packet eaptest1: Event NEW_STA (22) received Data frame from unknown STA 00:1b:08:00:8c:94 - adding a new STA New STA ap_sta_add: register ap_handle_timer timeout for 00:1b:08:00:8c:94 (300 seconds - ap_max_inactivity) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: start authentication EAP: Server state machine created IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state IDLE IEEE 802.1X: 00:1b:08:00:8c:94 CTRL_DIR entering state FORCE_BOTH eaptest1: hostapd_new_assoc_sta: canceled wired ap_handle_timer timeout for 00:1b:08:00:8c:94 eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=1 length=0 ignoring 42 extra octets after IEEE 802.1X packet eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAPOL-Start from STA IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state DISCONNECTED eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: unauthorizing port IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state RESTART EAP: EAP entering state INITIALIZE eaptest1: CTRL-EVENT-EAP-STARTED 00:1b:08:00:8c:94 EAP: EAP entering state SELECT_ACTION EAP: getDecision: no identity known yet -> CONTINUE EAP: EAP entering state PROPOSE_METHOD EAP: getNextMethod: vendor 0 type 1 eaptest1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1 EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 124 EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state CONNECTING IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state AUTHENTICATING IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 124) IEEE 802.1X: 00:1b:08:00:8c:94 - (EAP) retransWhile --> 0 EAP: EAP entering state RETRANSMIT eaptest1: CTRL-EVENT-EAP-RETRANSMIT 00:1b:08:00:8c:94 EAP: EAP entering state IDLE EAP: retransmit timeout 6 seconds (from dynamic back off; retransCount=1) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 124) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=9 ignoring 33 extra octets after IEEE 802.1X packet EAP: code=2 identifier=124 length=9 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=124 len=9) from STA: EAP Response-Identity (1) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=124 respMethod=1 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE EAP-Identity: Peer identity - hexdump_ascii(len=4): 75 73 65 72 user EAP: EAP entering state SELECT_ACTION EAP: getDecision: another method available -> CONTINUE EAP: EAP entering state PROPOSE_METHOD EAP: getNextMethod: vendor 0 type 13 eaptest1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13 EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 125 EAP-TLS: START -> CONTINUE EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 125) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 212 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=208 EAP: code=2 identifier=125 length=208 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=125 len=208) from STA: EAP Response-TLS (13)IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=125 respMethod=13 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE SSL: Received packet(len=208) - Flags 0x00 SSL: Received packet: Flags 0x0 Message Length 0 SSL: (where=0x10 ret=0x1) SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:before SSL initialization OpenSSL: RX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:before SSL initialization OpenSSL: RX ver=0x304 content_type=22 (handshake/client hello) OpenSSL: Message - hexdump(len=197): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS read client hello OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/server hello) OpenSSL: Message - hexdump(len=61): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write server hello OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/certificate) OpenSSL: Message - hexdump(len=855): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write certificate OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/server key exchange) OpenSSL: Message - hexdump(len=401): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write key exchange OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/certificate request) OpenSSL: Message - hexdump(len=153): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write certificate request OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/server hello done) OpenSSL: Message - hexdump(len=4): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write server done SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in SSLv3/TLS write server done SSL: SSL_connect - want more data SSL: 1499 bytes pending from ssl_out SSL: Using TLS version TLSv1.2 EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 126 SSL: Generating Request SSL: Sending out 1393 bytes (106 more to send) EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 126) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=6 ignoring 36 extra octets after IEEE 802.1X packet EAP: code=2 identifier=126 length=6 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=126 len=6) from STA: EAP Response-TLS (13) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=126 respMethod=13 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE SSL: Received packet(len=6) - Flags 0x00 SSL: Received packet: Flags 0x0 Message Length 0 SSL: Fragment acknowledged EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 127 SSL: Generating Request SSL: Sending out 106 bytes (message sent completely) EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 127) IEEE 802.1X: 00:1b:08:00:8c:94 - (EAP) retransWhile --> 0 EAP: EAP entering state RETRANSMIT eaptest1: CTRL-EVENT-EAP-RETRANSMIT 00:1b:08:00:8c:94 EAP: EAP entering state IDLE EAP: retransmit timeout 6 seconds (from dynamic back off; retransCount=1) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 127) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=6 ignoring 36 extra octets after IEEE 802.1X packet EAP: code=2 identifier=127 length=6 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=127 len=6) from STA: EAP Response-TLS (13) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=127 respMethod=13 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE SSL: Received packet(len=6) - Flags 0x00 SSL: Received packet: Flags 0x0 Message Length 0 SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in SSLv3/TLS write server done SSL: SSL_connect - want more data SSL: 0 bytes pending from ssl_out SSL: Using TLS version TLSv1.2 EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 128 SSL: Generating Request SSL: Sending out 0 bytes (message sent completely) EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 128) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=6 ignoring 36 extra octets after IEEE 802.1X packet EAP: code=2 identifier=127 length=6 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=127 len=6) from STA: EAP Response-TLS (13) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=127 respMethod=13 respVendor=0 respVendorMethod=0 EAP: RECEIVED->DISCARD: rxResp=1 respId=127 currentId=128 respMethod=13 currentMethod=13 EAP: EAP entering state DISCARD EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state IGNORE IEEE 802.1X: 00:1b:08:00:8c:94 - (EAP) retransWhile --> 0 EAP: EAP entering state RETRANSMIT eaptest1: CTRL-EVENT-EAP-RETRANSMIT 00:1b:08:00:8c:94 EAP: EAP entering state IDLE EAP: retransmit timeout 6 seconds (from dynamic back off; retransCount=1) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 128) IEEE 802.1X: 00:1b:08:00:8c:94 - (EAP) retransWhile --> 0 EAP: EAP entering state RETRANSMIT eaptest1: CTRL-EVENT-EAP-RETRANSMIT 00:1b:08:00:8c:94 EAP: EAP entering state IDLE EAP: retransmit timeout 12 seconds (from dynamic back off; retransCount=2) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 128) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 212 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=208 EAP: code=2 identifier=128 length=208 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=128 len=208) from STA: EAP Response-TLS (13)IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=128 respMethod=13 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE SSL: Received packet(len=208) - Flags 0x00 SSL: Received packet: Flags 0x0 Message Length 0 OpenSSL: RX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write server done OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=21 (alert/) OpenSSL: Message - hexdump(len=2): [REMOVED] SSL: (where=0x4008 ret=0x20a) SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unexpected_message authsrv: local TLS alert: unexpected_message SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in error OpenSSL: openssl_handshake - SSL_connect error:141A20F4:SSL routines:ossl_statem_server_read_transition:unexpected message SSL: 7 bytes pending from ssl_out SSL: Failed - tls_out available to report error EAP-TLS: CONTINUE -> FAILURE OpenSSL: Session was not cached EAP: Session-Id - hexdump(len=0): [NULL] EAP: EAP entering state SELECT_ACTION EAP: getDecision: method failed -> FAILURE EAP: EAP entering state FAILURE EAP: Building EAP-Failure (id=128) eaptest1: CTRL-EVENT-EAP-FAILURE 00:1b:08:00:8c:94 IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state FAIL eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 128) IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state HELD eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: unauthorizing port eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: authentication failed - EAP type: 0 (unknown) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Supplicant used different EAP type: 13 (TLS) eaptest1: IEEE 802.1X: Force disconnection of 00:1b:08:00:8c:94 after EAP-Failure in 10 ms IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state IDLE eaptest1: IEEE 802.1X: Scheduled disconnection of 00:1b:08:00:8c:94 after EAP-Failure eaptest1: ap_sta_disconnect STA 00:1b:08:00:8c:94 reason=23 eaptest1: ap_sta_disconnect: reschedule ap_handle_timer timeout for 00:1b:08:00:8c:94 (5 seconds - AP_MAX_INACTIVITY_AFTER_DEAUTH) IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state INITIALIZE EAP: EAP entering state DISABLED eaptest1: Deauthentication callback for STA 00:1b:08:00:8c:94 eaptest1: Removing STA 00:1b:08:00:8c:94 from kernel driver eaptest1: STA 00:1b:08:00:8c:94 MLME: MLME-DEAUTHENTICATE.indication(00:1b:08:00:8c:94, 23) eaptest1: STA 00:1b:08:00:8c:94 MLME: MLME-DELETEKEYS.request(00:1b:08:00:8c:94) eaptest1: ap_handle_timer: 00:1b:08:00:8c:94 flags=0x40000000 timeout_next=3 eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.11: deauthenticated due to local deauth request ap_free_sta: cancel ap_handle_timer for 00:1b:08:00:8c:94 EAP: Server state machine removed In wireshark logs we see the below details: [image: image.png] As you can see the Session Ticket details are missing and that Length 0 field is the last byte in the message but still in Wireshark we see other details like JA4, JA4_r etc? Is the "Client Hello" response from the client in the correct format? Why does the Serve states: SSL: SSL_accept:SSLv3/TLS write server done OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=21 (alert/) OpenSSL: Message - hexdump(len=2): [REMOVED] SSL: (where=0x4008 ret=0x20a) SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unexpected_message authsrv: local TLS alert: unexpected_message SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in error OpenSSL: openssl_handshake - SSL_connect error:141A20F4:SSL routines:ossl_statem_server_read_transition:unexpected message SSL: 7 bytes pending from ssl_out SSL: Failed - tls_out available to report error *EAP-TLS: CONTINUE -> FAILURE* OpenSSL: Session was not cached EAP: Session-Id - hexdump(len=0): [NULL] EAP: EAP entering state SELECT_ACTION EAP: getDecision: method failed -> FAILURE EAP: EAP entering state FAILURE EAP: Building EAP-Failure (id=134) Regards, Prakash

1 year, 9 months

1
0
0 0

MbedTLS (2.25.0) TLS handshake on FreeRTOS - PSA Crypto enabled (SE) but not used during client step 8

by hippolyte.einfalt＠viveris.fr

Greetings, ## The Setup Greetings, ## The Setup I have a RENESAS board that has an integrated crypto processor and uses MbedTLS 2.25.0. I have a SE (secure element) connected to it. I am allowing hardware acceleration and PSA crypto API inside mbedtls_config.h I registered my SE driver before calling psa_crypto_init(). The board connects to a web server and performs TLS handshake with the forced cipher `MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`. ## The issue The handshake fails during the step 8 when generating EC private key for ECDHE exchange. I have tracked the issue through debug and it unfolded as follows inside `ssl_write_client_key_exchange()`: - We enter the PSA crypto code from the pre-processor directives. - We set the key attributes after initializing them to 0. (here usage_flags, algorithm, type and bits field are set but lifetime is still 0 from init at this point, this will count later on) - The next function `psa_generate_key()` fails. ## In depth When inside the `psa_generate_key()` function, we start the key creation inside `psa_start_key_creation()`. But here, when validating the attributes of the key in `psa_validate_key_attributes()`, we are not able to rely on the SE to store the key due to it being volatile (lifetime is still 0), the driver is never called. From there the program keeps going until trying to generate the key with the crypto processor from the board which does not support this type of key and returns unsupported error. ## Main question Since the lifetime is forced to be representing a volatile key and since the driver for the SE is not called except for persistent ones, i cannot do this cryptographic step using the SE. Is the generation of the volatile key at this step meant to be handled by the MbedTLS library (software or hardware alt) and not by the PSA Crypto API (SE) due to the key being volatile ? If not, how is the Se supposed to be called in the handshake and what am i missing ? ## Discussion I can pass the handshake when disabling hardware acceleration and using the software for cryptographic steps, but in this case i am not using the SE for them. Should the SE only be used to store the client certificate for mTLS case ? ## Note I must use the MbedTLS version 2.25.0 since the SE driver I am using relies on this version.

1 year, 9 months

2
5
2 0

Release all memory held by mbedtls_ssl_context

by Satya Prakash Prasad

Hi, We are writing a client code which can accept or decline connection to the server - so for each connection I understand there is a mbedtls_ssl_context data established. Once the same is closed or not required we need to do deinitialize or free memory allocated to its member variables like - we need to free all memory allocated since we need it back else our application will run out of memory like: os_free(mbed_ctx->handshake); os_free(mbed_ctx->transform_negotiate); os_free(mbed_ctx->session_negotiate); os_free(mbed_ctx->in_buf); os_free(mbed_ctx->out_buf); But there are many member variables which also need to free memory if allocated and assigned to it. Is there a function / method that can free all memory for mbedtls_ssl_context instance variable? Thanks in advance. Regards, Prakash

1 year, 9 months

3
3
0 0

Reminder: MBed TLS Tech Forum - Asia/Europe

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next Monday at 10:00am 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

1 year, 9 months

1
3
0 0

Building mbedtls-2.19.1

by Satya Prakash Prasad

Hi, Please note that I needed to compile and work with MBed TLS version 2.19.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.19.1 However I am unable to compile the code / examples in it - i get below error: *$ cmake .CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required): Compatibility with CMake < 2.8.12 will be removed from a future version of CMake. Update the VERSION argument <min> value or use a ...<max> suffix to tell CMake that the project does not need compatibility with older versions.-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.22631.CMake Error at CMakeLists.txt:192 (add_subdirectory): add_subdirectory given source "crypto/3rdparty" which is not an existing directory.CMake Error at CMakeLists.txt:199 (add_subdirectory): add_subdirectory given source "crypto/library" which is not an existing directory.CMake Error at CMakeLists.txt:200 (add_subdirectory): add_subdirectory given source "crypto/include" which is not an existing directory.CMake Warning (dev) at programs/ssl/CMakeLists.txt:37 (target_sources): Policy CMP0076 is not set: target_sources() command converts relative paths to absolute. Run "cmake --help-policy CMP0076" for policy details. Use the cmake_policy command to set the policy and suppress this warning. An interface source of target "ssl_client2" has a relative path.This warning is for project developers. Use -Wno-dev to suppress it.CMake Warning (dev) at programs/ssl/CMakeLists.txt:44 (target_sources): Policy CMP0076 is not set: target_sources() command converts relative paths to absolute. Run "cmake --help-policy CMP0076" for policy details. Use the cmake_policy command to set the policy and suppress this warning. An interface source of target "ssl_server2" has a relative path.This warning is for project developers. Use -Wno-dev to suppress it.CMake Warning (dev) at programs/test/CMakeLists.txt:31 (target_sources): Policy CMP0076 is not set: target_sources() command converts relative paths to absolute. Run "cmake --help-policy CMP0076" for policy details. Use the cmake_policy command to set the policy and suppress this warning. An interface source of target "query_compile_time_config" has a relative path.This warning is for project developers. Use -Wno-dev to suppress it.* I tried removing the errors from the CmakeFile.txt but now get below error: *$ cmake --build .Microsoft (R) Build Engine version 16.11.2+f32259642 for .NET FrameworkCopyright (C) Microsoft Corporation. All rights reserved.MSBUILD : error MSB1009: Project file does not exist.Switch: ALL_BUILD.vcxproj* Also make all Makefile:84: ../crypto/3rdparty/Makefile.inc: No such file or directory make[1]: *** No rule to make target '../crypto/3rdparty/Makefile.inc'. Stop. Makefile:19: recipe for target 'lib' failed make: *** [lib] Error 2 Please let me know how to resolve them and compile MBedTLS version 2.19.1 code? Thanks in advance. Regards, Prakash

1 year, 9 months

1
0
0 0

EAP TLS

by Satya Prakash Prasad

Hi, I am working on an issue related to memory leak in MBedTLS. We have integrated MBedTLS code for below 3rd party HostAPD code integration . https://github.com/prplfoundation/hostap [Hostapd] Please refer to the Hostapd peer code implementation as provided in the link below: https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… The main function code snippet is provided below: https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… if (eap_example_peer_init() < 0 || eap_example_server_init() < 0) return -1; do { printf("---[ server ]--------------------------------\n"); res_s = eap_example_server_step(); printf("---[ peer ]----------------------------------\n"); res_p = eap_example_peer_step(); } while (res_s || res_p); Since we are implementing code for peers hence we have removed the server step. Now we need to keep monitoring for new connections / failed connections and act accordingly we have modified the code to something like below - if (eap_example_peer_init() < 0 || eap_example_server_init() < 0) return -1; do { res_p = eap_example_peer_step(); if (eap_ctx.eapNoResp || eap_ctx.eapFail) { eap_client_peer_deinit(); eap_client_peer_init(); } } while (1); We have modified the loop such that it will keep iterating for new connections and in case of failure, re-initialization is required. Is my understanding correct? The issue I am facing is that the client peer deinit method is not releasing all memory allocated during eap_example_peer_step() function ( I understand while processing the EAP TLS server request). The deinit is purely implemented to deallocate memory initially allocated for a new connection using TLS? void eap_client_peer_deinit(void) { eap_peer_sm_deinit(eap_ctx.eap); eap_peer_unregister_methods(); wpabuf_free(eap_ctx.eapReqData); os_free(eap_ctx.eap_config.identity); os_free(eap_ctx.eap_config.password); os_free(eap_ctx.eap_config.cert.ca_cert); os_free(eap_ctx.eap_config.cert.client_cert); os_free(eap_ctx.eap_config.cert.private_key); } where void eap_peer_sm_deinit(struct eap_sm *sm) { if (sm == NULL) return; eap_deinit_prev_method(sm, "deinit"); eap_sm_abort(sm); if (sm->ssl_ctx2) tls_deinit(sm->ssl_ctx2); tls_deinit(sm->ssl_ctx); eap_peer_erp_free_keys(sm); os_free(sm); } Can you please let me know whether we are deallocating memory correctly? Thanks in advance. Regards, Prakash

1 year, 9 months

1
0
0 0

Handshake is successful if the intermediate CA is revoked.

by singaravelu Balasubramani

I am checking the certificate revocation with below scenario. I have Root CA, Intermediate CA and device certificate is signed by Intermediate CA. I am makeing chain certificate by combining Root CA, Intermediate CA and this chain certificate is my active CA certificate and loaded this and device certificate to the drive. From client, I am creating client certificate which is signed by same intermeidate CA. Making ssl handshake. Handshake is success as expected. Now i am revoking the intermediate CA and creating the crl which is signed by the Root CA. This crl has the serial number of intermediate CA. Now loading the CRL to the drive and setting the crl in "mbedtls_ssl_conf_ca_chain". Now i am establishing the ssl connection with the same client ceritificate and expecting the ssl handshake failure due to intermediate CA revoked. But i get handshake is success. Is my understanding right about intermediate CA revocation? I did little background debug, and my obervation is During handshake , it goes to static int x509_crt_verify_chain function in mbedtls. Its trying to find the parent using x509_crt_find_parent for the client certificate and get intermediate CA. During this time, parent_is_trusted is set as true. after this x509_crt_verifycrl is called with client certificate (child), intermediate CA (parent) and crl(has the intermediate CA serial number-issued by Root CA). During x509_crt_verifycrl check, it check for CRL issuer with ca subject and return 0, as its not matching. now in x509_crt_verify_chain , /* prepare for next iteration */ ., they are marking child_is_trusted = parent_is_trusted and child = parent, parent = NULL; and while loop continues, in loop, x509_crt_verify_chain checks for child_is_trusted is true and return as 0. But its not checking that intermediate CA is revoked or not. /* Stop here for trusted roots (but not for trusted EE certs) */ if( child_is_trusted ) return( 0 );

1 year, 9 months

2
2
0 0

Question about mbedtls_x509_parse_subject_alt_name

by Roman Janota

Hello, I would like to parse certificate's SAN fields in my application. In the documentation of the struct mbdetls_x509_crt for its member subject_alt_names the following is stated: "Optional list of raw entries of Subject Alternative Names extension. These can be later parsed by mbedtls_x509_parse_subject_alt_name.". I was using the latest development branch and tried to call the function, however, I found out I can not, because it is defined in the x509_internal.h private header. I later found out that the definition was moved from the public to the private header in the commit 25b282e <https://github.com/Mbed-TLS/mbedtls/commit/25b282ebfe5cb84e73d6194e83dc8d6c…> (partly thanks to the issue #459 <https://github.com/Mbed-TLS/mbedtls/issues/459>). So I switched to the 3.5.2 release and everything worked fine. Why was this change made? Will it be kept so that I'd have to implement my own parsing? Or was it a mistake? Thank you for clarifying, Roman.

1 year, 10 months

1
0
0 0

SHA-256 mismatch for mbedtls-3.5.2.tar.gz

by Wojtek Porczyk

Hello, list, Release notes for Mbed TLS 3.5.2 [0] have this: The SHA256 hashes for the archives are: 35890edf1a2c7a7e29eac3118d43302c3e1173e0df0ebaf5db56126dabe5bb05 mbedtls-3.5.2.tar.gz 55c1525e7d5de18b84a1d1e5540950b4a3bac70e02889cf309919b2877cba63b mbedtls-3.5.2.zip However, attempting to download mbedtls-3.5.2.tar.gz yields a file with hash: eedecc468b3f8d052ef05a9d42bf63f04c8a1c50d1c5a94c251c681365a2c723 What's going on with those hashes? [0]: https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.5.2 https://web.archive.org/web/20240126105153/https://github.com/Mbed-TLS/mbed… -- pozdrawiam / best regards Wojtek Porczyk Gramine / Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov

1 year, 10 months

3
7
0 0

Question about fix of "Timing side channel in private key RSA operations"

by Yuxiang Cao

Hi folks, This is a question about understanding changes in recent new release. I want to understand how new release e.g. 2.28.7 fix the vulnerable described in https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-secur…. Want to check that if following commits in new release, for example 2.28.7, are the actual commits for fixing the vulnerable above: 42175031ca48e2fba62b97fc802e5df33d5221ff 4fe396f1e1aa84346e23b89435a251624c205035 aa6760d7b5d9a218eaf072f4155974f58b00986b 601bffc4cec7c78cfc6b64048379172578fce13c In short, they are first 4 commits in I found https://github.com/Mbed-TLS/mbedtls/compare/v2.28.6...v2.28.7 Thank you for any help you can provide! Best, Yuxiang

1 year, 10 months

2
2
0 0

Public And Private Keys

by Satya Prakash Prasad

Hi, I need some clarification on Public and Private keys that a server maintains its own side. All documents say that the client will use the server's public key to encrypt the data while the server will make use of its private keys to decrypt. Is it not that the data can be decrypted using the public key itself? How and what is encryption logic implemented in such a case? Please do provide some logical explanation for the same - how does this encryption / decryption work? Regards, Prakash

1 year, 10 months

1
0
0 0

Mbed TLS 3.5.2 and 2.28.7

by Dave Rodgman

Hi Mbed TLS users, We have released Mbed TLS versions 3.5.2 and 2.28.7. These releases contain security fixes for: a timing side channel in private key RSA operations; and a buffer overflow in mbedtls_x509_set_extension. Full details are available in the release notes. https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.7 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.5.2 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks. Dave

1 year, 10 months

1
0
0 0

ECDH - establish shared secret key with X509 certificate + private key

by Tilen MAJERLE

Dear community, My target is to establish a shared secret key between the PC application (master) and (various, different, but always limited to 1 at a time) peripheral devices. *Each device has*: - Device specific ECC 256-bit private key, in PEM format, well parsed with mbedtls_pk_parse_key function when required. - Device specific certificate that belongs to the private key. Certificate is signed by the *TrustCA*. Parsing works well with mbedtls_x509_crt_parse - TrustCA’s certificate, used to validate the master device during communication, also used to check firmware signature in a secure boot part of the application *PC application has*: - Master application certificate, signed by *TrustCA* - Private key of the PC application that belongs to master application certificate, in PEM format - *TrustCA*’s certificate, used to validate device certificate during communication Aim is to establish AES shared secret, by doing: - Master sends authentication requests, random challenge, device performs hash + signs with private key. Returns certificate + signature of the challenge. - Master uses *TrustCA*'s certificate to check device's certificate and then checks the signature of the hash(challenge) - Master sends its certificate to the slave, now both hold X509 certificates. At this point, device could also request authentication of the PC application - A computation with its respective private key is needed on both sides, and we have common secret. What is the correct way in mbedTLS, to get a public key from *X509*, that can be used in the ECDH module? The way the ECDH module inside mbedTLS seems to be designed, there is no straight-forward way to export X5090’s public key, get its parameters and use them in ECDH module. Instead, ECDH expects that random keypair will be generated every-time we want key exchange. Doing this, we risk *man in the middle* attack, since the other party doesn’t know where the key is actually coming from. For the moment, the solution I see (which is not THAT elegant, or is it?), and to avoid man in the middle attack:: - Devices still exchange certificates, but only for authentication reason + certificate verification - Every message that is sent between devices (for instance public keys exchange), must also be hashed & signed, so that another party can be sure message is coming from the device which shared the certificate just before (and certificate is signed by TrustCA) - We need one exchange more to get shared secret. Is this the *proposed* solution in this case? Is there a more elegant solution with the mbedTLS library for this problem? Thanks -- Tilen Majerle, mag.inž.el. Tušev Dol 11 8340 Črnomelj Slovenia www: http://majerle.eu e-mail: tilen(a)majerle.eu Mobile: +386 40 167 724 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#m_-5461752537485879190_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 year, 10 months

1
0
0 0

Dropping support for Visual Studio 2015

by Gilles Peskine

Hello, We are considering dropping support for Visual Studio 2013 and Visual Studio 2015 from Mbed TLS 3.6 onwards. This would make Mbed TLS 3.6 require Visual Studio 2017 or newer. (Mbed TLS 2.28 LTS is not affected.) Per the Visual Studio product lifecycle <https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing#old…>, VS 2013 and 2015 are currently on extended support, but their support will end during the lifetime of Mbed TLS 3.6 LTS. Our reasons are: * We prefer not to support products that are not supported upstream, such as VS 2013 and 2015 will be during the lifetime of 3.6 LTS. * Older versions of Visual Studio tend to require workarounds due to their incomplete support for C99, and we would like to reduce those. We may drop support for older versions of MinGW as well for this reason. * The development branch of Mbed TLS is currently triggering an internal compiler error in VS 2015 <https://github.com/Mbed-TLS/mbedtls/issues/8735>. If you want to keep support for VS 2013 and 2015 in Mbed TLS 3.6, please let us know as soon as possible and tell us why it's important. Assistance with the internal compiler error would be appreciated. Best regards, -- Gilles Peskine Mbed TLS developer

1 year, 10 months

1
0
0 0

.MBed TLS - Transport / Network Level Implementation

by Satya Prakash Prasad

Hi, Please let me know if MBed TLS is designed for Security level at Transport / Network Level Implementation of OSI model - at network socket connection level. Please let us know if MBed TLS routines can be used at DataLink Layer specifically for 802.1x protocols. Referring to the example as provided in tutorial - https://mbed-tls.readthedocs.io/en/latest/kb/how-to/mbedtls-tutorial/ What would be setup / config accordingly for non socket dependent implementation. Thanks in advance. Regards, Prakash

1 year, 10 months

1
0
0 0

MBed TLS

by Satya Prakash Prasad

Hi, I was referring to below URLs for understanding key exchange using certificate in TLS framework: https://tls12.xargs.org/ https://tls13.xargs.org/ I have some confusion related to above TLS 1.2 and 1.3 flows and require guidance from your side accordingly. I understand the key exchange using certificates highly depends on configuration and capabilities setup. But then how do we know what goes on a TLS connection based on configuration and setup capabilities? What are the different configurations and when should we set them? I need the same details with reference to a TLS connection setup from a client in our codebase while other for EAP TLS using the below example available in the url below: https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… Firstly in the above code we do see a lot of configuration and initialization like below: eap_cb.get_config = peer_get_config; eap_cb.get_bool = peer_get_bool; eap_cb.set_bool = peer_set_bool; eap_cb.get_int = peer_get_int; eap_cb.set_int = peer_set_int; eap_cb.get_eapReqData = peer_get_eapReqData; eap_cb.set_config_blob = peer_set_config_blob; eap_cb.get_config_blob = peer_get_config_blob; eap_cb.notify_pending = peer_notify_pending; Whereas our client code which connects to the cloud using certificates to obtain some data in below mentioned way: keyman_creds_for_purpose() - get the creds read and parse the crt.pem, key.pem and trusted_ca.pem files. It make uses of below APis:readfile() - read the file from key storageparse_private_key() & mbedtls_pk_parse_key() - I believe it is for parsing the keys read from file Setup MBed TLS mbedtls_ssl_config_init() - Initialize mbedtls_ssl_configmbedtls_ctr_drbg_init() - CTR_DRBG context initialization mbedtls_ctr_drbg_seed() mbedtls_ssl_conf_rng() mbedtls_ssl_conf_ca_chain() mbedtls_ssl_conf_own_cert() mbedtls_ssl_conf_authmode() t_socket() I am quite new to this code so could have missed or provided wrong info - but I hope I give the overall picture of code implementation - note that this client code is a working code with no issues. My queries are mentioned below: 1) Does the same TLS message flow occur in both cases - our client code and EAP TLS? If not then what's the difference in-between them? 2) How do we understand exact implementation and message flows? 3) What are the different ways to implement TLS connection using certs? 4) Any additional information that can helpful to me like - some references to tutorials / examples / guide would be an added advantage Thanks in advance. Regards, Prakash

1 year, 11 months

1
0
0 0

Optimized swap and endianness macros (MBed TLS 2.28.x)

by jojwoos

Hi, when upgrading MBed TLS from 2.16.x to the LTS 2.28.x version on an ARM 32 bit system, I realized that the byte-order macros were collected to one file (common.h) with the possibility to replace them. After writing ARM optimized macros, I checked this topic in the 3.5.x version where it was implemented in a similar way in alignment.h. With this input the following solution was made for the 2.28.x branch: https://github.com/jojwoos/MbedTLS_wrapper A bit late, but maybe someone can still use it:) Perhaps the 64 bit swap, build from two optimized 32bit swaps, can provide some input for the actual 3.5.x version. You can find it at: "// general 64 bit optimization if only 32 bit optimization is available" (32bit ARM systems usually don't have optimized 64bit swap functions) Best regards, Jürgen

1 year, 11 months

1
0
0 0

MBed TLS Tutorial

by Satya Prakash Prasad

Hi, Referring to the example as in https://mbed-tls.readthedocs.io/en/latest/kb/how-to/mbedtls-tutorial/ (secure connection) does the secret key exchange takes place in-between server and client. Is there any flowchart / diagram that states what happens during the server client connection - how the keys are exchanged and what types of certs are exchanged, I mean like .pem, X.509 etc? Can we take this way that be it any type of certificate the code implementation is the same for all TLS communication? Thanks in advance. Regards, Prakash

1 year, 11 months

2
1
0 0

Unable to Read Encrypted Private Key

by jtrauntvein＠gmail.com

1 year, 11 months

2
1
0 0

Apt error for invalid key ID

by S Krishnan, Archanaa

Hello, In psa_validate_key_attributes(), when the key ID is invalid for persistent keys the function returns PSA_ERROR_INVALID_ARGUMENT. See https://github.com/Mbed-TLS/mbedtls/blob/development/library/psa_crypto.c#L…. The comments for PSA_ERROR_INVALID_ARGUMENT explicitly states that this error should not be returned when key identifier is invalid, instead PSA_ERROR_INVALID_HANDLE should be returned. For the above psa_validate_key_attributes() usecase, which is the correct return code - PSA_ERROR_INVALID_ARGUMENT or PSA_ERROR_INVALID_HANDLE? Regards, Archanaa

1 year, 11 months

2
1
0 0

Built-in keys for transparent driver

by S Krishnan, Archanaa

Hello, The mbedtls docs (psa_driver_interface.md) mention that only opaque driver supports the use of built-in keys with PSA APIs. Why does a transparent driver not support built-in key feature? Regards, Archanaa

2 years

1
0
0 0

Request for comments on adding more MBEDTLS_PRIVATE accessors.

by Minos Galanakis

Hi all. We are currently planning on improving our coverage and adding accessor functionality for members marked as MBEDTLS_PRIVATE. I have created an issue ( #8529 )<https://github.com/Mbed-TLS/mbedtls/issues/8529> to consolidate all the information and design-review the task. It would really help to hear from the community as to which members they are still using, and what is their use-case. Feel free to comment on the issue, or discuss it here. There may be members that we have decided not to include and are essential to your integration or are completely missing/not being considered. Best Regards, Minos Galanakis

2 years

1
0
0 0

MbedTLS Code 3.5.1

by Satya Prakash Prasad

Hi, We need to integrate the TLS Code in our codebase. I have downloaded Mbed TLS 3.5.1 @ https://github.com/Mbed-TLS/mbedtls/releases and compiled it. I understand that we can just use the code in mbedtls-3.5.1\library directory for the TLS functionality - can anyone please confirm. Are there any other directories where TLS Code exists in the MbedTLS 3.5.1 repo? Please confirm how we can only integrate MbedTLS TLS functionality code in other applications / repo. There are so many other directories in MbedTLS 3.5.1 repo - how is the code in repo organized? Do we need all the code in MbedTLS 3.5.1 repo? Your valid input will help me to integrate the MbedTLS Code in our codebase? Please provide all other details as required or will be helpful for the same. Thanks in advance. Regards, Prakash

2 years

1
0
0 0

Mbed TLS 3.5.1

by Satya Prakash Prasad

Hi, I downloaded Mbed TLS 3.5.1 @ https://github.com/Mbed-TLS/mbedtls/releases. Please let me know how to configure and compile the same. Also please let me know how to run some sample tests there or manually to verify. Thanks in advance. Regards, Prakash

2 years

1
0
0 0

Code samples for psa_import_key and ECC?

by Christian Huitema

I am trying to use psa_import_key() after loading private keys from PEM files. I am succeeding when parsing an "RSA PRIVATE KEY", but no such luck for "EC PRIVATE KEY". I assume that I am not setting attributes correctly. A code sample would be nice! Or, maybe I could just use mbedtls_pk_parse_keyfile(), but then I would need to "import" a PSA key from the "mbedtls" context, ad I did not find sample code for that either. -- Christian Huitema

2 years

2
4
0 0

Mbed TLS 3.5.1 and 2.28.6

by Dave Rodgman

Hi Mbed TLS users, We have released Mbed TLS versions 3.5.1 and 2.28.6. These releases of Mbed TLS are made under a dual Apache-2.0 OR GPL-2.0-or-later license. Mbed TLS 3.5.1 also contains a bugfix for CMake builds. They are otherwise identical to the previous releases, 2.28.5 and 3.5.0. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.6, https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.5.1)<https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.5.0)>. We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many Thanks. Dave

2 years, 1 month

1
0
0 0

[Mbed-tls-announce] New Mbed TLS releases : 3.5.0 and 2.28.5

by Minos Galanakis via Mbed-tls-announce

We have released Mbed TLS versions 3.5.0 and 2.8.5. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.5, https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.5.0). We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many Thanks. 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

2 years, 1 month

3
2
0 0

Mbed TLS license change

by Dave Rodgman

Hi Mbed TLS users, We are planning to change the license for Mbed TLS shortly, from Apache 2.0 to a dual license Apache 2.0 / GPLv2-0-or-later license. This will allow GPL-licensed projects to take Mbed TLS under a GPL license. Projects which currently take Mbed TLS under an Apache 2.0 license may continue to do so, and therefore should not be affected by this change. The inbound license, under which we accept contributions, is already a dual-license. There is therefore no impact for contributors, and no impact on PRs that are currently in review, or those that have previously been integrated into the library. We hope that this will enable more projects to make use of Mbed TLS. Dave Rodgman

2 years, 1 month

1
0
0 0

TF-PSA-Crypto publication

by Ronald Cron

We are happy to announce the publication in GitHub of the TF-PSA-Crypto repository: https://github.com/Mbed-TLS/TF-PSA-Crypto. The TF-PSA-Crypto repository provides an implementation of the PSA Cryptography API (https://arm-software.github.io/psa-api). This encompasses the on-going extensions to the PSA Cryptography API (e.g. PAKE). The PSA Cryptography API implementation is organized around the PSA Cryptography driver interface aiming to ease the support of cryptographic accelerators and processors. This is a significant milestone on the journey to split the PSA Cryptography API implementation and its development out of the Mbed TLS repository into TF-PSA-Crypto. This is early days though and the TF-PSA-Crypto repository should be considered as a prototype: it is read-only and mostly a mirror of the PSA Cryptography API implementation of Mbed TLS. But we believe it is a good illustration of what we are aiming at. Thanks, Ronald Cron on behalf of the Mbed TLS team.

2 years, 1 month

2
2
0 0

How to implement Opaque driver API

by Jiamei Xie

Hi experts, I wanted to forward some crypto operations to an external driver that provides psa_call APIs. The mbedtls version I am using 3.4.0. Take psa_asymmetric_encrypt as an example, The mbedtls api is psa_status_t psa_asymmetric_encrypt(mbedtls_svc_key_id_t key, psa_algorithm_t alg, const uint8_t *input, size_t input_length, const uint8_t *salt, size_t salt_length, uint8_t *output, size_t output_size, size_t *output_length) It gets attribute, key.data and key.byte from key_id. Then call function psa_driver_wrapper_asymmetric_encrypt without key_id as its argument: status = psa_driver_wrapper_asymmetric_encrypt( &attributes, slot->key.data, slot->key.bytes, alg, input, input_length, salt, salt_length, output, output_size, output_length); In psa_driver_wrapper_asymmetric_encrypt, it will use different implementations according to the location value in https://github.com/Mbed-TLS/mbedtls/blob/d69d3cda34c400a55220352518e37d3d2c…. I define a new location definition(RSS_PSA_LOCATION. When the location is RSS_PSA_LOCATION, making it call psa_status_t crypto_psa_asymmetric_encrypt(psa_key_id_t key, psa_algorithm_t alg, const uint8_t *input, size_t input_length, const uint8_t *salt, size_t salt_length, uint8_t *output, size_t output_size, size_t *output_length) This API require key_id. Is it possible to get key_id from attribute and key_slot? Regards, Jiamei Xie

2 years, 1 month

3
3
0 0

Driver only build option

by Ruchika Gupta

Hi, I am trying to use the MACRO's defined at - https://github.com/Mbed-TLS/mbedtls/blob/development/docs/driver-only-build… to enable driver only build. As mentioned on the page I tried to do this for SHA256. However, the code in sha256.c isn't ifdefed by "MBEDTLS_PSA_ACCEL_ALG_SHA_256" so still gets compiled ? Can you point me to what I am missing here ? Regards, Ruchika

2 years, 1 month

1
1
0 0

How can I encrypt with a private key?

by 克坚马

Hi all, I have been using the old version(2.28) for a very long time, and updated to version 3.4.0 recently. When using rsa encryption, there is a parameter 'mode' that allows to choose whether to use a public key or a private key. Why is it canceled in the new version? And how can I use the private key to perform an encryption operation? Thank you for your help!

2 years, 1 month

4
6
0 0

For enabling TLS 1.3

by Sankalp Raj Singh

Can you please provide the proper steps and file name where we have to make changes in order to enable TLS 1.3

2 years, 1 month

1
0
0 0

PSA crypto driver - KEY LOCATIONS

by Ruchika Gupta

Hi, For the crypto accelerator, we are developing for our SoC, we have a use-case where the same driver can support multiple/range of KEY LOCATIONS. We want a mechanism such that, the a common function in driver is called which can then take the necessary option based on the key location. The way jsons are currently structured, what I understand is that for every key location, we will need to create a separate json with a different driver prefix. This would lead to a lot of code duplication for us. For eg { to define 3 locations X, Y and Z , I need to create 3 json files -> these all refer to same crypto sub-system I my case} #define TEST_DRIVER_X_OPAQUE_DRIVER_ID #define TEST_DRIVER_Y_OPAQUE_DRIVER_ID #define TEST_DRIVER_Z_OPAQUE_DRIVER_ID Switch (key_location) Case x: Test_driver_x_ opaque_import_key(); break; Case y: Test_driver_y_ opaque_import_key(); break; Case z: Test_driver_z_ opaque_import_key(); break; This is resulting in a lot of code duplication and overhead. What we want to have the flexibility to achieve is : #define TEST_DRIVER_OPAQUE_DRIVER_ID Switch (key_location) Case x: Case y: Case z: Test_driver_opaque_import_key(); If we can support multiple locations from a driver json file for a given driver, this issue would be resolved. This would give the driver writers flexibility on how and where they want to handle the locations. Please let us know your views on the same. Regards, Ruchika

2 years, 1 month

2
1
0 0

Re: [Mbed-tls-announce] New Mbed TLS releases : 3.5.0 and 2.28.5

by Oubaid AKRMI

Hi, Is the SHA-3 impacted by the vulnerability reported in NIST vulnerability database (link below) ? https://nvd.nist.gov/vuln/detail/CVE-2022-37454 "Description The Keccak XKCP SHA-3 reference implementation before fdc6fef has an integer overflow and resultant buffer overflow that allows attackers to execute arbitrary code or eliminate expected cryptographic properties. This occurs in the sponge function interface. " Best regards, [Shape, rectangle Description automatically generated] Oubaid AKRMI | Mobile: +33 7 53 06 08 49 GPM | Application Security Engineer [Icon Description automatically generated]<https://www.facebook.com/STMicroelectronics.NV/> [cid:image003.png@01D9FD35.14D24980] <https://twitter.com/st_world> [Icon Description automatically generated] <https://www.linkedin.com/company/stmicroelectronics/> [Icon Description automatically generated] <https://www.instagram.com/stmicroelectronics.nv/> [Icon Description automatically generated] <https://www.youtube.com/user/STonlineMedia> ST online: www.st.com<https://stmicroelectronics-my.sharepoint.com/personal/oubaid_akrmi_st_com/D…>

2 years, 2 months

2
1
0 0

Link to MBed TLS Tech Forum - Asia/Europe

by Daniel Morris

Just in case others are struggling to join/had a bad bookmark for the meeting which started a few minutes ago, the right one is: https://linaro-org.zoom.us/j/95471735908?pwd=WStaaWhEVXNqcWx1S2pEQU13cHU2UT… Also handily listed here: https://www.trustedfirmware.org/meetings/ Daniel %<---------------------------------------------------------------------- Daniel Morris eCosCentric - The eCos experts Tel: +44 1223 245 571 - info(a)eCosCentric.com

2 years, 2 months

1
0
0 0

psa_raw_key_agreement does not like PSA_ALG_ECDSA(PSA_ALG_SHA_256)

by Christian Huitema

I am not sure I completely understand the PSA API for key exchange. I have been creating a private key, exporting the public key, passing that successfully to the peer, obtaining the peer's public key, and I want to use psa_raw_key_agreement to obtain the shared secret. But it fails in: if (!PSA_ALG_IS_KEY_AGREEMENT(alg)) { status = PSA_ERROR_INVALID_ARGUMENT; goto exit; } The value of "alg" is 0x06000609, computed as PSA_ALG_ECDSA(PSA_ALG_SHA_256). That's probably wrong, but I do not know why... -- Christian Huitema

2 years, 3 months

1
1
0 0

Output format of mbedtls_ecdh_make_params does not play well with TLS 1.3

by Christian Huitema

In TLS 1.3, one half of an ECDH exchange is defined as a "key entry", coded as: struct { NamedGroup group; opaque key_exchange<1..2^16-1>; } KeyShareEntry; The opaque data is typically encoded as a one byte format (e.g., 0x04, no compression), and then the encoding of either one or two points: 32 bytes for one point with CURVE25519, 64 bytes for two points with SECP256R1. The encoding for the "public key" output of mbedtls_ecdh_make_params is different: 1 byte of length, followed by 2 bytes of curve ID, followed by the raw encoding of the point or points. The related encoding of the server public key output of mbedtls_ecdh_make_public is also different: 1 byte of length, followed by 2 bytes of curve ID, followed by the raw encoding of the point or points. To make that work, I need some reformatting: strip out 3 bytes for the client public key, write a single 0x04 byte instead; strip out one byte from the key-exchange data received at the server and write 3 bytes of length and curve ID instead. Also, make sure to reset the strings to the unmodified value before calling mbedtls_ecdh_calc_secret, which probably means maintaining two copies, thus twice the memory. This is a bit messy, and probably unnecessary. The extra parameters "length" is already passed through the API (the &olen argument) and the "group_id" could easily be passed as well. Or maybe I am looking at the wrong API... -- Christian Huitema

2 years, 3 months

3
7
0 0

TLS handshake with AWS IoT MQTT broker seems to succeed and then is terminated by the broker

by Roger Sala

I am developing an AWS IoT MQTT client on STM32H723 using FreeRTOS 10.3.1, LwIP 2.1.2 and MbedTLS. My first attempt used MbedTLS 2.16.2 and it mostly works except that sometimes, seemingly related to the timing of the network I'm using, it fails when my client fails to send out anything after the Client Key Exchange message and then the server responds with a Close Notify as follows: "Time","Source","Destination","Protocol","Length","Info" "0.000000","10.24.108.94","54.157.158.237","TLSv1.2","418","Client Hello" "0.016460","54.157.158.237","10.24.108.94","TLSv1.2","150","Server Hello" "0.002777","54.157.158.237","10.24.108.94","TLSv1.2","685","Certificate" "0.000000","54.157.158.237","10.24.108.94","TLSv1.2","438","Server Key Exchange, Certificate Request, Server Hello Done" "0.976521","10.24.108.94","54.157.158.237","TLSv1.2","1006","Certificate, Client Key Exchange" "0.014853","54.157.158.237","10.24.108.94","TLSv1.2","61","Alert (Level: Warning, Description: Close Notify)" When it works it looks like this: "Time","Source","Destination","Protocol","Length","Info" "0.000000000","10.0.0.11","54.84.254.130","TLSv1.2","418","Client Hello" "0.017495225","54.84.254.130","10.0.0.11","TLSv1.2","150","Server Hello" "0.001743255","54.84.254.130","10.0.0.11","TLSv1.2","685","Certificate" "0.000022282","54.84.254.130","10.0.0.11","TLSv1.2","392","Server Key Exchange" "0.000004428","54.84.254.130","10.0.0.11","TLSv1.2","100","Certificate Request, Server Hello Done" "2.606030441","10.0.0.11","54.84.254.130","TLSv1.2","1326","Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message" "0.027421478","54.84.254.130","10.0.0.11","TLSv1.2","105","Change Cipher Spec, Encrypted Handshake Message" "0.000971482","10.0.0.11","54.84.254.130","TLSv1.2","193","Application Data" "0.075384354","54.84.254.130","10.0.0.11","TLSv1.2","87","Application Data" The last two "Application Data" messages are the MQTT connect and connect ACK, So before I filed a bug report, I upgraded to MbedTLS 2.28.4. The good news is that this client always (seems) to successfully negotiate the TLS handshake, but after receiving the first encrypted "Application Data" (connect), the broker immediately sends and "Encrypted Alert", which I'm taking to be a Close Notify because a TCP FIN follows shortly thereafter. The Wireshark capture of the 2.28.4 handshake looks almost exactly like the successful 2.16.2 handshake: "Time","Source","Destination","Protocol","Length","Info" "0.000000000","10.0.0.11","44.195.98.16","TLSv1.2","336","Client Hello" "0.018450117","44.195.98.16","10.0.0.11","TLSv1.2","150","Server Hello" "0.000524146","44.195.98.16","10.0.0.11","TLSv1.2","685","Certificate" "0.000003168","44.195.98.16","10.0.0.11","TLSv1.2","392","Server Key Exchange" "0.000002995","44.195.98.16","10.0.0.11","TLSv1.2","100","Certificate Request, Server Hello Done" "2.517148776","10.0.0.11","44.195.98.16","TLSv1.2","1329","Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message" "0.016572792","44.195.98.16","10.0.0.11","TLSv1.2","60","Change Cipher Spec" "0.000007326","44.195.98.16","10.0.0.11","TLSv1.2","99","Encrypted Handshake Message" "0.001500778","10.0.0.11","44.195.98.16","TLSv1.2","193","Application Data" "0.031014646","44.195.98.16","10.0.0.11","TLSv1.2","85","Encrypted Alert" ... except for the "Encrypted Alert" from the broker that leads to the closing of the session. I'm hoping someone has an explanation of the behavior I'm seeing and can suggest a path forward for me. Another data point is the fact that the client with MbedTLS 2.28.4 can successfully authentic and negotiate a TLS handshake with a mosquitto broker I'm running locally using self signed certificates. ====================================================================== The information contained in this e-mail, including all of its attachments, is confidential and proprietary information of IPG Photonics and its affiliates and intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by telephone or e-mail, and destroy this communication and all copies. Thank you. ======================================================================= This Email has been scanned for all viruses by IPG Photonics Email Scanning Services.

2 years, 3 months

1
0
0 0

Reminder: MBed TLS Tech Forum - Asia/Europe

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is *next Monday at 10:00am 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 ReplyReply to allForward

2 years, 3 months

2
2
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 3 months

1
0
0 0

New TrustedFirmware Discord Server

by don.harbin＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

2 years, 3 months

1
0
0 0

Does mbedtls support x509 certificates signed wih ED448 algorithm?

by Bahadır Maktav

Hi, I am trying to use a certificate with its public key algorithm is NIST P-384 and its signature algorithm is ED448. I am working on ESP board with IDF framework which supports mbedtls. But when I am trying to use that certificate, I got error message about 'MBEDTLS_ERR_X509_UNKOWN_SIG_ALG'. So, I thought that maybe mbedtls does not support certificates which signed with ED448.

2 years, 3 months

2
1
0 0

Does mbedtls support x509 certificates signed wih ED448 algorithm?

by Bahadır Maktav

Hi, I am trying to use a certificate with its public key algorithm is NIST P-384 and its signature algorithm is ED448. I am working on ESP board with IDF framework which supports mbedtls. But when I am trying to use that certificate, I got error message about 'MBEDTLS_ERR_X509_UNKOWN_SIG_ALG'. So, I thought that maybe mbedtls does not support certificates which signed with ED448.

2 years, 3 months

1
0
0 0

Example of AEAD decrypt?

by Christian Huitema

The example of AEAD encryption in "aead_demo" is very useful. Is there a similar example for decryption? -- Christian Huitema

2 years, 3 months

2
1
0 0

Does mbedTLS TLS1.3 only support PSK?

by Thompson, Jeff

I've got mbedTLS 3.1.4 and want to use TLS 1.3. My handshake fails very early because I don't have any Pre-Shared Keys. Does mbedTLS TLS1.3 only support PSKs, or can I still use generated session keys as does TLS 1.2? If so, how? Jeff Thompson | Senior Electrical Engineer - Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D9D729.620C6230]

2 years, 3 months

2
2
0 0

Silly python problem when building on MacOS

by Christian Huitema

Hello, I am trying to build MbedTLS on a Mac, as part of a project to support MbedTLS in the "picoquic" implementation of QUIC. I have a small problem, probably something of my making. I have cloned the repo on an "mbedtls" directory, created a "build" subdirectory, and from there run"cmake ..", which worked fine, and then tried to run "make", which fails in "generating psa_crypto_driver_wrapper.c" when trying the python script "generate_driver_wrappers.py" because it cannot find the python module "jsonschema". I tried to solve that by installing that module using "pip", and test programs running python3 do find the "jsonschema". Calling print(jsonschema.__file__) shows the module is installed in my user directory: /users/christianhuitema/Library/python3.9/lib/python/... Is there a simple way to fix that? -- Christian Huitema

2 years, 3 months

2
4
0 0

Certificate Revocation

by ahmed bouzid

Hello, I'm currently engaged in a project where I'm utilizing mbedtls for the management of certificates. Within this project, I'm aiming to integrate a revocation feature using Certificate Revocation Lists (CRLs). However, my search for resources on how to effectively implement a comprehensive certificate revocation process using mbedtls has unfortunately yielded no productive outcomes. I am concerned about how to first create a crl file and sign it using my self-signed CA, how to revocate a certificate if we need to revocate it, and how to update the CRL, then when parsing the cert how to detect that this certificate has been revocated. ( I am using LPCXpresso55S16 as a client and raspberry pi as a server and I am doing all with coding). Thank you in advance for your support. Best regards, Ahmed.

2 years, 3 months

2
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls