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