- mbed-tls - lists.trustedfirmware.org

mbedtls_ecp_gen_key vs mbedtls_ecdsa_genkey

by Tom Work

Hey All, I am trying to generate ECDSA public-private key pair for self-signed certificate, and came across these examples In gen_key.c <https://github.com/Mbed-TLS/mbedtls/blob/bee96566dac936e7fdfa7aa18b6a1f6767…>, "mbedtls_ecp_gen_key()" is used In ecdsa.c <https://github.com/Mbed-TLS/mbedtls/blob/bee96566dac936e7fdfa7aa18b6a1f6767…>, "mbedtls_ecdsa_genkey()" is used. My questions are: - Which function should be used? (It seems mbedtls_ecdsa_genkey() is just a wrapper of mbedtls_ecp_gen_key()?) - If using mbedtls_ecdsa_genkey(), what are the steps to write the public key into PEM format? (My understanding is that I define a mbedtls_pk_context, and convert its address into mbedtls_ecdsa_context *, and pass the pointer into mbedtls_ecdsa_genkey, and then call mbedtls_ecdsa_genkey(), is this correct?) Thanks, Tom

1 year, 4 months

1
0
0 0

Re: CA Unknown Certificate

by Janos Follath

Hi Satya, Is this issue related to the one described in your previous email “[mbed-tls] EAP TLS - TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA)”? Kind regards, Janos From: Satya Prakash Prasad <satyaprakash.developer.unix(a)gmail.com> Date: Friday, 12 April 2024 at 16:27 To: Janos Follath <Janos.Follath(a)arm.com> Subject: Re: [mbed-tls] CA Unknown Certificate Hi Janos, Kindly note that I have already provided the same in my initial email. Please refer the same for your reference: Please note that we need to give CN value different for Root and Server / Client (since I am trying got mutual trusted certificate. You can also verify the same in below way: First console : # openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err or -Verify 1 verify depth is 1, must return a certificate Using default temp DH parameters ACCEPT Second Console: #touch test.txt # openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err or -Verify 1 verify depth is 1, must return a certificate Using default temp DH parameters ACCEPT On First Console we receive: # openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err or -Verify 1 verify depth is 1, must return a certificate Using default temp DH parameters ACCEPT depth=1 C = US, ST = CA, L = Somewhere, O = Someone, CN = FoobarCA verify return:1 depth=0 C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar verify return:1 FILE:test.txt Root CA Key # openssl genrsa -des3 -out ca.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ..+++++ ....+++++ e is 65537 (0x010001) Enter pass phrase for ca.key.pem:^1234^ Verifying - Enter pass phrase for ca.key.pem:^1234^ Server Private Key # openssl genrsa -out server.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ........................................+++++ .................................................................................................+++++ e is 65537 (0x010001) Client Private Key # openssl genrsa -out client.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ...............................+++++ ..........................+++++ e is 65537 (0x010001) Root CA Certificate from Root CA Key # openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA Enter pass phrase for ca.key.pem:^1234^ Server CSR & Certificate from Server Private Key # openssl req -new -sha256 -key server.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr # openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out server.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ Client CSR & Certificate from Client Private Key # openssl req -new -sha256 -key client.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr # openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out client.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ Regards, Prakash On Fri, Apr 12, 2024 at 5:55 PM Janos Follath <Janos.Follath(a)arm.com<mailto:Janos.Follath@arm.com>> wrote: Hi Prakash, Thank you for sharing the details about how you generated the certificates. Could you please share the command line for the server and the client as well? Kind regards, Janos From: Satya Prakash Prasad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Date: Friday, 12 April 2024 at 05:03 To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Subject: [mbed-tls] CA Unknown Certificate Hi, Please note that while using MBedTLS 3.6.0, when we are trying to verify server / client connection using self-signed mutually trusted certificates we are always getting a CA Unknown Certificate error code 46 alert message. Root CA Key # openssl genrsa -des3 -out ca.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ..+++++ ....+++++ e is 65537 (0x010001) Enter pass phrase for ca.key.pem:^1234^ Verifying - Enter pass phrase for ca.key.pem:^1234^ Server Private Key # openssl genrsa -out server.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ........................................+++++ .................................................................................................+++++ e is 65537 (0x010001) Client Private Key # openssl genrsa -out client.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ...............................+++++ ..........................+++++ e is 65537 (0x010001) Root CA Certificate # openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA Enter pass phrase for ca.key.pem:^1234^ Server CSR & Certificate # openssl req -new -sha256 -key server.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr # openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out server.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ Client CSR & Certificate # openssl req -new -sha256 -key client.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr # openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out client.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ So we have used Root CA Certificatet as trusted certificate but during handshake steps we see client reporting "Certificate Unknown'' alert error message 46? TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown) Description: Certificate Unknown (46) Can you please let us know the issue we are doing in creating the certificates or it can also be some wrong steps / configuration while compiling the 3.6.0 release? Regards, Prakash -- mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org<mailto:mbed-tls-leave@lists.trustedfirmware.org> 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.

1 year, 4 months

2
1
0 0

CA Unknown Certificate

by Satya Prakash Prasad

Hi, Please note that while using MBedTLS 3.6.0, when we are trying to verify server / client connection using self-signed mutually trusted certificates we are always getting a CA Unknown Certificate error code 46 alert message. Root CA Key # openssl genrsa -des3 -out ca.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ..+++++ ....+++++ e is 65537 (0x010001) Enter pass phrase for ca.key.pem:^1234^ Verifying - Enter pass phrase for ca.key.pem:^1234^ Server Private Key # openssl genrsa -out server.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ........................................+++++ .................................................................................................+++++ e is 65537 (0x010001) Client Private Key # openssl genrsa -out client.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ...............................+++++ ..........................+++++ e is 65537 (0x010001) Root CA Certificate # openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA Enter pass phrase for ca.key.pem:^1234^ Server CSR & Certificate # openssl req -new -sha256 -key server.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr # openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out server.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ Client CSR & Certificate # openssl req -new -sha256 -key client.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr # openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out client.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ So we have used Root CA Certificatet as trusted certificate but during handshake steps we see client reporting "Certificate Unknown'' alert error message 46? TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown) Description: Certificate Unknown (46) Can you please let us know the issue we are doing in creating the certificates or it can also be some wrong steps / configuration while compiling the 3.6.0 release? Regards, Prakash

1 year, 4 months

1
0
0 0

Public key from certificate?

by Christian Huitema

Public key operations like "psa_verify_message" use a "key-id" argument to represent the public key. Is there a simple way to obtain or register that key-id using the "cert->pk" member of a parsed certificate? -- Christian Huitema

1 year, 4 months

2
1
0 0

Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Ruchika Gupta

Hi All, Apologies for the long email. I am adding all the 3 projects (TF-M, mbedTLS and Zephyr) to the mail chain because the issues I discuss below are inter-connected and affect all the three projects. From mbedtls 3.5.0 version, the mbedtls project has migrated to auto-generated psa_crypto_driver_wrappers.h file. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/psa-driver-exampl… https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv… On TF-M, mbed-crypto, there are 2 patches for the drivers given below which are still hardcoding their changes and not following the above approach. 1. PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY_LOADER (0001-Add-TF-M-Builtin-Key-Loader-driver-entry-points.patch) 2. PSA_CRYPTO_DRIVER_CC3XX (0005-Hardcode-CC3XX-entry-points.patch) We at NXP, have migrated our psa crypto wrappers to the above approach using auto-generation. We want to maintain same code base for mbedtls for our SDK's, TFM mbed-crypto as well as align mbedTLS fork in Zephyr. We are increasingly finding it difficult to migrate to newer versions of mbedtls because of hardcoding of above drivers. The problem is specially on the Zephyr front, where in the mbedTLS fork in zephyr these patches from tfm are applied by default. I have queries for all the 3 projects listed below : TF-M --> Can you please let us know what are the plans to migrate these 2 drivers in tfm to the auto-generation approach. If these patches can be migrated to make changes in jinja files rather than hardcoding in psa_crypto_driver_wrappers , things would be much easier to integrate. Is somebody already working on it ? Are you open to accept patches for this change ? mbedTLS --> What is the long term strategy from mbedTLS on this auto-generation ? We still have a lot of hard-coding in .jinja file rather than using drivers.json. Would mbedTLS/new PSA crypto repository start accepting patches for psa wrappers from platforms ? Can the patches which TF-M project maintains be merged in the mbedTLS ? Zephyr --> On Zephyr front, what are the plans to align to this auto-generation approach ? Regards, Ruchika

1 year, 4 months

2
2
0 0

Why is mbedtls 3.x faster than 2.x?

by Work Only

I recently updated an embedded HTTPs web service using mbedtls from 2.22.0 to 3.2.1, and noticed the performance is about 30% better/faster. This is good for sure, but I am curious, what are the changes contributing to this improvement? Thanks!

1 year, 4 months

2
2
0 0

MbedTLS 3.6.0 Compilation Error

by Satya Prakash Prasad

Hi, It seems that in latest MbedTLS 3.6.0 following declarations have been deleted: MBEDTLS_ERR_SSL_CERTIFICATE_REQUIRED MBEDTLS_ERR_SSL_PEER_VERIFY_FAILED The below function implementation is not there mbedtls_ssl_conf_export_keys_ext_cb Regards, Prakash

1 year, 4 months

1
1
0 0

MbedTLS 3.6.0 Compilation Error

by Satya Prakash Prasad

Hi, We are trying to compile the MBedTLS 3.6.0 version using nios2-elf-gcc compiler for an embedded product. We are receiving following compilation error- Compiling /mbedtls/library/platform_util.c ---------------------------------------------------- mbedtls/library/platform_util.c:261:2: #error "No mbedtls_ms_time available" Makefile:622: recipe for target '.mbedtls/library/platform_util.o' failed make: *** [mbedtls/library/platform_util.o] Error 1 I see the code in platform_util.c [snapshot below] - we have enabled MBEDTLS_HAVE_TIME and not MBEDTLS_PLATFORM_MS_TIME_ALT #if defined(MBEDTLS_HAVE_TIME) && !defined(MBEDTLS_PLATFORM_MS_TIME_ALT) #include <time.h> #if !defined(_WIN32) && \ // Note - Since we are compiling for embedded device this block gets disabled (defined(unix) || defined(__unix) || defined(__unix__) || \ (defined(__APPLE__) && defined(__MACH__)) || defined(__HAIKU__) || defined(__midipix__)) #include <unistd.h> #endif \ /* !_WIN32 && (unix || __unix || __unix__ || (__APPLE__ && __MACH__) || __HAIKU__ || __midipix__) */ #if (defined(_POSIX_VERSION) && _POSIX_VERSION >= 199309L) || defined(__HAIKU__) //// Note - Since we are compiling for embedded device this block gets disabled mbedtls_ms_time_t mbedtls_ms_time(void) { int ret; struct timespec tv; mbedtls_ms_time_t current_ms; #if defined(__linux__) && defined(CLOCK_BOOTTIME) || defined(__midipix__) ret = clock_gettime(CLOCK_BOOTTIME, &tv); #else ret = clock_gettime(CLOCK_MONOTONIC, &tv); #endif if (ret) { return time(NULL) * 1000; } current_ms = tv.tv_sec; return current_ms*1000 + tv.tv_nsec / 1000000; } #elif defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__) || \ // Note - Since we are compiling for embedded device this block gets disabled defined(__MINGW32__) || defined(_WIN64) #include <windows.h> mbedtls_ms_time_t mbedtls_ms_time(void) { FILETIME ct; mbedtls_ms_time_t current_ms; GetSystemTimeAsFileTime(&ct); current_ms = ((mbedtls_ms_time_t) ct.dwLowDateTime + ((mbedtls_ms_time_t) (ct.dwHighDateTime) << 32LL))/10000; return current_ms; } #else #error "No mbedtls_ms_time available" //--> compilation error propagated from here #endif Regards, Prakash

1 year, 4 months

1
0
0 0

Generate a self-signed trusted certificate for server / client

by Satya Prakash Prasad

Hi, Referring to https://mbed-tls.readthedocs.io/en/latest/kb/how-to/generate-a-self-signed-… I am trying to create mutual certificates for server / client self signed certificates. As I derive from the web page the following steps need to be followed: Generic gen_key type=rsa rsa_keysize=2048 filename=ca.key format=pem cert_write selfsign=1 issuer_key=ca.key issuer_name=CN=myserver,O=myorganization,C=NL not_before=20130101000000 not_after=20251231235959 is_ca=1 max_pathlen=0 output_file=my_crt.crt Server Side: What steps to do to create the following files where server.crt is server side certificate, sever.key is the server private key and trusted.pem is the CA that it trusts. server.crt, server.key, trusted.pem[trusted.pem==>is it my_crt.crt] Do we need to create new server keys and certificates then do we need to bundle them - I am not sure how and what steps to do? Client Side What steps to do to create the following file where client.crt is client side certificate, client.key is the client private key and trusted.pem is the CA that it trusts. client.crt, client.key, trusted.pem[trusted.pem==>is it my_crt.crt] Do we need to create new client keys and certificates then do we need to bundle them - I am not sure how and what steps to do? Objective: Objective is that client and server should be able to connect securely successfully using their certs Request to provide help related to the generation of self-signed client / server certs that can be used for SSL handshake using MBedTLS library. Regards, Prakash

1 year, 4 months

1
0
0 0

Support SM2, SM3, SM4

by Zhi Liu

Hi all, Given TLS 1.3 has added two new cipher suites in RFC 8998 ( https://datatracker.ietf.org/doc/html/rfc8998), it would be useful to add these algorithms and ciphersuites in Mbedtls. CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 }; CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 }; There are some posts in this topic, https://github.com/Mbed-TLS/mbedtls/pull/4091, https://github.com/Mbed-TLS/mbedtls/pull/1620. But SM2/3/4 have not been added in recent versions(e.g., 3.6). I have implemented SM3, SM4 as standalone code( https://github.com/zliucd/cryptoshark), and want to port the code to Mbedtls while supporting SM2. However, to fully support the two new cipher suites, we need to add lots of other code. The first step is to add SM2, SM3 and SM as standalone ciphers. Thanks for any comments. Zhi

1 year, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls