Hi All,
This is going out to all the primary TF maillists.
It's a gentle reminder that a TF Discord channel has been created for all
chat communications in the TF ecosystem. All TF participants are
encouraged to join.
Instructions on how to join can be found here:
https://www.trustedfirmware.org/faq/ <https://www.trustedfirmware.org/faq/>
[image: Screenshot 2024-04-17 at 7.08.01 AM.png]
Please let me know if you have any questions,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello,
I am trying to add TLS 1.3 support to a curl project
(https://github.com/MAntoniak/curl). As a result, it has two questions.
The first refers to the error code
MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET. This suggests an error
receiving a new session ticket. I couldn't find anything else in the
documentation. However, in the ssl_cllient2.c example application (line
2638), this code is used as a message to the application about a new
session ticket. This makes me unsure whether it would be correct to
continue receiving application data normally.
The second question relates to the receipt of tickets. The curl project
does not store session tickets, so it uses the
MBEDTLS_SSL_SESSION_TICKETS_DISABLED flag. If this is the case, why do
we nevertheless receive a new ticket from the server?
Thank you for your reply.
Michał Antoniak
Hello,
I have an implementation in OpenSSL and am trying to recreate it using
MbedTLS. One of the differences in these two I have yet to overcome is
the following:
Is there a way to treat mbedtls_x509_crt simply as a certificate store?
Say I have some PEM data, parse it into a temporary mbedtls_x509_crt and
then I would like to append this certificate to said mbedtls_x509_crt
certificate store.
The following is stated in the docs of mbedtls_x509_crt:
> struct mbedtls_x509_crt *next
Next certificate in the linked list that constitutes the CA chain.
NULL indicates the end of the list. Do not modify this field directly.
Is there a way to achieve this if it's advised not to modify the field
directly?
Thank you in advance,
Roman.
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
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.
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
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
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
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!
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
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
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
Hi Mbed TLS users,
We have released Mbed TLS versions 3.6.0 LTS and 2.28.8.
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/v3.6.0, https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.8).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
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
Hello Mbed-TLS team,
I am reaching out for guidance on an issue I've encountered while integrating MbedTLS for HTTPS requests using the coreHTTP stack alongside FreeRTOSplusTCP on an STM32F4 device. Although I have successfully implemented an HTTP client, moving to HTTPS has presented some challenges.
My approach has included several adjustments to the mbedtls_config file, such as:
- Integrating a Random Number Generator (RNG) from STM32 within the mbed_Entropy_poll function.
- Utilizing the calloc and free functions provided by FreeRTOS.
- Modifying the search algorithm to correctly handle null-terminated PEM certificates.
Despite these efforts, I am unable to establish a connection to the server, with the process consistently failing during the TLS handshake phase. Specifically, the client hello message is transmitted from my device, but no response is received from the server, resulting in an MBEDTLS_INTERNAL_ERROR.
Enclosed with this email are my mbedtls_config file and a detailed account of the issue as posted on the FreeRTOS forum<https://forums.freertos.org/t/integration-of-ssl-in-corehttp/19561/11>. While I do not expect a full code review<https://github.com/AshvajitP/Eth_FreeRTOS_F4>, any insights into potential causes for this type of handshake failure would be greatly appreciated.
Thank you for your time and assistance.
Regards,
Ashvajit Prasad
I saw the following comment when configuring Record Size Limit Extension (RFC 8449) in `mbedtls_config.h` [1]:
> This extension is currently in development and must NOT be used except for testing purposes.
Is this still accurate? What functionality is missing for full RFC 8449 support? Is this feature planned for a specific date?
[1] https://github.com/Mbed-TLS/mbedtls/blob/611f899c0c9d397baedfaec34ea0861ad2…
Hi,
We are integrating https://github.com/prplfoundation/hostap code into
our project that makes uses of crypto and SSL functionality. Their
code is so written that they have interfaces defined where crypto and
SSL 3rd party algorithms can be called and implemented.
We are stuck implementing those APIs interfaces using MBedTLS and in
need of help for its implementation. Referring to the below set of
interfaces as defined in
https://github.com/prplfoundation/hostap/blob/master/src/crypto/tls_none.c
we need to implement required code for MBedTLS.
I am in need help implementing below API:
struct tls_connection * tls_connection_init(void *tls_ctx) where
tls_connection is below defined type [user defined type - hope is
correct implementation]:
struct tls_connection {
mbedtls_ssl_context *ssl;
keyman_creds *cr;
};
We have made the below implementation
struct tls_connection * tls_connection_init(void *ssl_ctx)
{
mbedtls_ssl_context *mssl_ctx = ssl_ctx;
struct tls_connection *conn;
conn = os_zalloc(sizeof(*conn));
if (conn == NULL) {
return NULL;
}
conn->ssl = mssl_ctx ;
conn->cr = NULL;
mbedtls_ssl_set_bio(ssl_ctx, NULL, net_send, net_recv, NULL);
return conn;
}
If my above implementation is correct please let me know how to
implement our own net_send and net_recv function. There are many
buffer declaration in mbedtls_ssl_context I am not sue what algorithm
to use to read complete / remaining bytes using internal data
structure :
int net_recv(void *ctx, unsigned char *buf, size_t len)
{
/* how to implement */
}
int net_send(void *ctx, const unsigned char *buf, size_t len)
{
/* how to implement */
}
Thanks in advance.
Regards,
Prakash
Hi,
Please also let me know the features of PSA in MbedTLS. I found this
related document -
https://mbed-tls.readthedocs.io/en/latest/getting_started/psa/.
Is PSA related to Platform Security Architecture or is related to TLS security?
How will the inclusion and non-inclusion of PSA will differ in terms
of security?
Thanks in advance.
Regards,
Prakash
Hello,
Bignum is a very useful feature in Mbedtls, which is a part to
libmbedcrypto.a. I want to build this module only as a standalone static
library. However, I find it's difficult to modify CMakelists.txt to do
this.
I appreciate your suggestions.
Blade
Hi,
I am trying to compile MbedTLS 3.5.2 release without PSA but get below
error message:
mbedtls/check_config.h:62:2: #error "MBEDTLS_ECP_DP_BP256R1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:66:2: #error "MBEDTLS_ECP_DP_BP384R1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:70:2: #error "MBEDTLS_ECP_DP_BP512R1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:74:2: #error "MBEDTLS_ECP_DP_CURVE25519_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:78:2: #error "MBEDTLS_ECP_DP_CURVE448_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:82:2: #error "MBEDTLS_ECP_DP_SECP192R1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:86:2: #error "MBEDTLS_ECP_DP_SECP224R1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:90:2: #error "MBEDTLS_ECP_DP_SECP256R1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:94:2: #error "MBEDTLS_ECP_DP_SECP384R1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:98:2: #error "MBEDTLS_ECP_DP_SECP521R1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:102:2: #error "MBEDTLS_ECP_DP_SECP192K1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:111:2: #error "MBEDTLS_ECP_DP_SECP256K1_ENABLED
defined, but not its PSA counterpart"
mbedtls/check_config.h:391:2: #error
"MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA_ENABLED defined, but not all
prerequisites"
mbedtls/check_config.h:397:2: #error
"MBEDTLS_KEY_EXCHANGE_ECDH_RSA_ENABLED defined, but not all
prerequisites"
mbedtls/check_config.h:406:2: #error
"MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED defined, but not all
prerequisites"
mbedtls/check_config.h:418:2: #error
"MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED defined, but not all
prerequisites"
mbedtls/check_config.h:425:2: #error
"MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED defined, but not all
prerequisites"
mbedtls/check_config.h:481:2: #error "MBEDTLS_LMS_C requires
MBEDTLS_PSA_CRYPTO_C and PSA_WANT_ALG_SHA_256"
mbedtls/check_config.h:725:2: #error "MBEDTLS_PLATFORM_NV_SEED_ALT
defined, but not all prerequisites"
mbedtls/check_config.h:879:2: #error
"MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_EPHEMERAL_ENABLED defined, but
not all prerequisites"
mbedtls/check_config.h:885:2: #error
"MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_PSK_EPHEMERAL_ENABLED defined,
but not all prerequisites"
Regards,
Prakash
Hi,
I am trying to build MbedtLS 3.5.2 and get the below error:
mbedtls/library/psa_crypto_storage.c:23:23: psa/error.h: No such file
or directory
mbedtls/library/psa_crypto_storage.c:24:42:
psa/internal_trusted_storage.h: No such file or directory
I searched all thru the directories and found error.h in mbetls
directory but could not find internal_trusted_storage.h header file?
#if defined(MBEDTLS_PSA_ITS_FILE_C)
#include "psa_crypto_its.h"
#else /* Native ITS implementation */
#include "psa/error.h"
#include "psa/internal_trusted_storage.h"
#endif
Regards,
Prakash