- mbed-tls - lists.trustedfirmware.org

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>

2 years

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

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

2
1
0 0

Unable to Read Encrypted Private Key

by jtrauntvein＠gmail.com

2 years, 1 month

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

2 years, 1 month

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, 2 months

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, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls