Hi Frank,
Support for HSM keys in Mbed TLS is a work in progress. The way it will
work eventually is by plugging an HSM driver under the PSA crypto API,
which supports both transparent and opaque keys.
The TLS code can already use the PSA crypto API for some things,
including client signature. Enable MBEDTLS_USE_PSA_CRYPTO, call
mbedtls_pk_setup_opaque() to create a PK object for the key, and declare
the key to the TLS code with mbedtls_ssl_conf_own_cert() as usual.
To create the key, you will need to write a PKCS#11 secure element
driver. ("Secure element" = "HSM" for this purpose.) I think it would
make sense to have one in Mbed TLS, but I don't know when we might get
around to writing one.
There are two secure element driver interfaces in Mbed TLS right now:
MBEDTLS_PSA_CRYPTO_SE_C (dynamic secure element interface) and
MBEDTLS_PSA_CRYPTO_DRIVERS (unified driver interface). Both are still
experimental: we can't guarantee API stability at this stage.
MBEDTLS_PSA_CRYPTO_SE_C was the first proposal, and its development is
currently frozen and may be abandonned, so I don't recommend investing
any effort in it at the moment, but if you need something fast (e.g. for
a demo/proof-of-concept), it's your best bet. MBEDTLS_PSA_CRYPTO_DRIVERS
is the way of the future, but it's an active work in progress.
If you're creating the key from your application, just call
psa_generate_key. If the key was provisioned externally, it's
unfortunately not so easy. With MBEDTLS_PSA_CRYPTO_SE_C, you can
register a key that's already present in the secure element with
mbedtls_psa_register_se_key(). The corresponding facility in the
MBEDTLS_PSA_CRYPTO_DRIVERS interface is a "get_builtin_key" entry point,
but this is not implemented yet. (There's a prototype at
https://github.com/ARMmbed/mbedtls/pull/3822 but nobody is working on
it. The specification is in docs/proposed/psa-driver-interface.md.)
There's an example application with a MBEDTLS_PSA_CRYPTO_SE_C driver at
https://github.com/ARMmbed/mbed-os-example-atecc608a . We don't have
example code for MBEDTLS_PSA_CRYPTO_DRIVERS yet, or good documentation,
or an easy-to-use build system — those are still a few months in the future.
If you write a driver in the next few months, I recommend that you stay
in touch with the Mbed TLS development team and follow the development
branch of Mbed TLS closely, since it's a very active area of development
at the moment.
--
Gilles Peskine
Mbed TLS developer
On 06/02/2021 16:59, Frank Bergmann via mbed-tls wrote:
> Hi,
>
> I want to use PKCS#11 with mbed TLS...
>
> - cross platform: Windows, mobile device (e.g. Android), *nix
> - on *client* side
> - to create keys (for certs) and store private keys in an HSM (could also be e.g. softhsm as fallback)
>
> How to "integrate" PKCS#11 with mbed TLS and achieve those requirements?
>
>
> cheers,
> Frank
>
Dear Farhad,
Sure, the thing you need to do is to call mbedtls_ssl_conf_authmode( conf, MBEDTLS_SSL_VERIFY_REQUIRED ) where conf is the ssl_config of the server. For more details, see that function's documentation (in ssl.h). For an example, see the command-line option auth_mode in programs/ssl/ssl_server2.c.
Hope this helps!
Best regards,
Manuel
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of saghili via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Sent: 05 February 2021 17:34
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] DTLS Mutual authentication
Dear,
I would like to have mutual authentication using dtls_client.c and
dtls_server.c examples.
In the current version of the example, the client does not send his own
certificate and the server does not verify the certificate of the
client.
Could you please provide me the changes that I need to make in both
dtls_client.c and dtls_server.c examples?
Best regards,
Farhad
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi,
I want to use PKCS#11 with mbed TLS...
- cross platform: Windows, mobile device (e.g. Android), *nix
- on *client* side
- to create keys (for certs) and store private keys in an HSM (could also be e.g. softhsm as fallback)
How to "integrate" PKCS#11 with mbed TLS and achieve those requirements?
cheers,
Frank
Dear,
I would like to have mutual authentication using dtls_client.c and
dtls_server.c examples.
In the current version of the example, the client does not send his own
certificate and the server does not verify the certificate of the
client.
Could you please provide me the changes that I need to make in both
dtls_client.c and dtls_server.c examples?
Best regards,
Farhad
Hello,
We've now created the branch to allow Mbed TLS 3.0 development to begin.
Mbed TLS 3.0 development will take place on development_3.0 in the short term. Mbed TLS 2.x development will continue on development. We'll regularly merge changes to development into development_3.0 so that they stay aligned.
At the point of the release of Mbed TLS 2.26, we will rename development to become mbedtls-2.26 and rename development_3.0 to become development, so that the focus for new work becomes the upcoming Mbed TLS 3.0 release.
Regards,
Dave Rodgman
On 17/12/2020, 10:04, "Mbed-tls-announce on behalf of Dave Rodgman via Mbed-tls-announce" <mbed-tls-announce-bounces(a)lists.trustedfirmware.org on behalf of Mbed-tls-announce(a)lists.trustedfirmware.org> wrote:
Hello,
We are planning to release Mbed TLS 3.0 around June 2021, alongside an LTS release of Mbed TLS 2.x. Our major version numbers indicate API breaking changes, and this is no exception: Mbed TLS 3.0 will have changes that make it incompatible with 2.x (as an obvious example, functions that are deprecated in 2.x will be removed).
In setting a near-term release date, we have chosen some key areas that we want to focus on for 3.0. Some other API-breaking items (i.e., those requiring significant design time) won't make the cut and we will hold those back for a future major version, in order to have time to get them right. The main focus for 3.0 will be reduction in API surface, and changes that are low-impact for almost everyone.
Work towards 3.0 will start in late January, on the development branch which will contain a public work-in-progress view of Mbed TLS 3.0. Any work for 2.x in this timeframe will take place on a separate branch (provisionally named like "mbedtls-2.x").
During the 3.0 development period, bug fixes and security fixes will continue to be a priority, but we will have slightly less capacity for other features. While 3.0 is in development, any new features will by default be landed in 3.0 only, unless there is a strong case for back-porting to 2.x. The 2.x LTS branches will still be supported with bug fixes and security fixes for the normal three year lifetime (i.e., the final LTS release of 2.x in mid-2021 will be supported until mid-2024).
In terms of content, we are taking a cautious approach to what we plan for 3.0. In the past we've been ambitious here and as a result, have slipped on the release date; by being cautious on feature set we can be confident about hitting the mid-year release date. We won't try to make all of the changes that would be nice-to-have; instead, we will focus on tasks that reduce maintenance, unlock other improvements in a 3.x timeframe, are still valuable if only partially completed, and can fit within this time frame. Currently we're looking at the following areas for 3.0:
* Reduce the public surface of the API
* Clean-up existing APIs
* Changes to default options
Regards
Dave Rodgman
--
Mbed-tls-announce mailing list
Mbed-tls-announce(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce
Hi,
As suggested by @Gilles Peskine , I did try enabling MBEDTLS_ENTROPY_FORCE_SHA256 , but even after enabling this mbedtls_ctr_drbg_seed was still returning 0X0034 (MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED ), please note that I'm using NVRAM for Seeding. I'm attaching my config.h file along with this mail for you reference.
PFA
-----Original Message-----
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of mbed-tls-request(a)lists.trustedfirmware.org
Sent: Thursday, January 28, 2021 1:19 AM
To: mbed-tls(a)lists.trustedfirmware.org
Subject: mbed-tls Digest, Vol 11, Issue 7
This message is from an external sender. Be cautious, especially with links and attachments.
Send mbed-tls mailing list submissions to
mbed-tls(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
or, via email, send a message with subject or body 'help' to
mbed-tls-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
mbed-tls-owner(a)lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of mbed-tls digest..."
Today's Topics:
1. Re: ENTROPY_SOURCE_FAILED :0x0034 (Gilles Peskine)
2. Re: Reduce mbedTLS memory and storage footprint (Gilles Peskine)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Jan 2021 20:36:18 +0100
From: Gilles Peskine <gilles.peskine(a)arm.com>
To: mbed-tls(a)lists.trustedfirmware.org
Subject: Re: [mbed-tls] ENTROPY_SOURCE_FAILED :0x0034
Message-ID: <9fcd3d55-ad54-05cf-63f9-7f3d09f3ee0d(a)arm.com>
Content-Type: text/plain; charset=windows-1252
Hello,
The entropy module uses a hash to mix the entropy. It uses SHA-512 if present and SHA-256 otherwise. Depending on the hash function, the entropy module can return either up to 64 bytes (SHA-512) or 32 bytes (SHA-256). The CTR_DRBG module knows about this and requests only 32 bytes at a time if the entropy module only delivers 32 bytes at a time.
It looks like something goes wrong when CTR_DRBG tries to request 64 bytes. This could be, for example, because a buffer is too small somewhere, or because of a limitation of the entropy source. You would need to debug the call to mbedtls_entropy_func to know more.
As a workaround, you can enable MBEDTLS_ENTROPY_FORCE_SHA256. Then the entropy module will use SHA-256 (even if MBEDTLS_SHA512_C is enabled) and only return 32 bytes at a time, and CTR_DRBG understands this and will only request 32 bytes.
--
Gilles Peskine
Mbed TLS developer
On 27/01/2021 06:08, T V LIJIN (EXT) via mbed-tls wrote:
> Hi,
> After enabling *MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* ,
> /mbedtls_ctr_drbg_seed/ is returning *0x0034
> */(MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED)/
> But if I just enable *MBEDTLS_NO_PLATFORM_ENTROPY* and keep
> *MBEDTLS_SHA512_C* disabled, it does not return any error for
> /mbedtls_ctr_drbg_seed./ / / My project uses certificates with SHA384
> signature, so it requires***MBEDTLS_SHA512_C *to be enabled.
> /*MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* /both needs to be
> enabled in my project , but Iam facing issue with
> mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What
> might be the reason for mbedtls_ctr_drbg_seed to fail while
> enabling/////*MBEDTLS_SHA512_C.*/////
> How to overcome this issue?
>
>
> Thanks,
> LIJIN T V
>
------------------------------
Message: 2
Date: Wed, 27 Jan 2021 20:48:27 +0100
From: Gilles Peskine <gilles.peskine(a)arm.com>
To: mbed-tls(a)lists.trustedfirmware.org
Subject: Re: [mbed-tls] Reduce mbedTLS memory and storage footprint
Message-ID: <b59f3e91-ae60-fae6-5fca-402894b0a890(a)arm.com>
Content-Type: text/plain; charset=windows-1252
Hello,
The most important thing is to make sure you've disabled all the features you don't need in config.h. The default configuration enables most cryptographic mechanisms, but typical constrained systems usually only need a few.
If your toolchain supports it, use link-time optimization (e.g. gcc -Os -flto or clang -Oz -flto). I've seen that this makes a significant improvement for Mbed TLS (I got -30% on one build, obviously the numbers depend heavily on the configuration and the compiler). (In contrast LTO when optimizing for performance doesn't seem to improve anything.)
MBEDTLS_MPI_WINDOW_SIZE, MBEDTLS_MPI_MAX_SIZE and MBEDTLS_ECP_MAX_BITS only impact memory usage (stack and heap), not code size.
--
Gilles Peskine
Mbed TLS developer
On 27/01/2021 05:36, T V LIJIN (EXT) via mbed-tls wrote:
> Hi,
> I'm trying to optimize the size of my binary file by making the
> following changes in "*mbedtls/config.h*"
>
> #define MBEDTLS_MPI_WINDOW_SIZE 1
> #define MBEDTLS_MPI_MAX_SIZE 32
> #define MBEDTLS_ECP_MAX_BITS 256
> #define MBEDTLS_SHA256_SMALLER
>
> Even after making the above changes I couldn't see any change in the
> binary size.
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftls.
> mbed.org%2Fkb%2Fhow-to%2Freduce-mbedtls-memory-and-storage-footprint&a
> mp;data=04%7C01%7Clijin.tv%40kone.com%7C1a138332ca084342827b08d8c2fc9d
> b9%7C2bb82c642eb143f78862fdc1d2333b50%7C0%7C0%7C637473737538267015%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000&sdata=ql17fsSC0eX7Hq5ofrsWAe%2BEenOc2piLq
> 4jBix%2Bjr20%3D&reserved=0
> - This is the link I referred to follow the above-mentioned steps.
> Is there anything else I can try to reduce my final binary file size
> (ROM size) ?
>
>
> Thanks,
> LIJIN T V
>
------------------------------
Subject: Digest Footer
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
------------------------------
End of mbed-tls Digest, Vol 11, Issue 7
***************************************
Hello,
The most important thing is to make sure you've disabled all the
features you don't need in config.h. The default configuration enables
most cryptographic mechanisms, but typical constrained systems usually
only need a few.
If your toolchain supports it, use link-time optimization (e.g. gcc -Os
-flto or clang -Oz -flto). I've seen that this makes a significant
improvement for Mbed TLS (I got -30% on one build, obviously the numbers
depend heavily on the configuration and the compiler). (In contrast LTO
when optimizing for performance doesn't seem to improve anything.)
MBEDTLS_MPI_WINDOW_SIZE, MBEDTLS_MPI_MAX_SIZE and MBEDTLS_ECP_MAX_BITS
only impact memory usage (stack and heap), not code size.
--
Gilles Peskine
Mbed TLS developer
On 27/01/2021 05:36, T V LIJIN (EXT) via mbed-tls wrote:
> Hi,
> I'm trying to optimize the size of my binary file by making the
> following changes in "*mbedtls/config.h*"
>
> #define MBEDTLS_MPI_WINDOW_SIZE 1
> #define MBEDTLS_MPI_MAX_SIZE 32
> #define MBEDTLS_ECP_MAX_BITS 256
> #define MBEDTLS_SHA256_SMALLER
>
> Even after making the above changes I couldn't see any change in the
> binary size.
> https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint
> - This is the link I referred to follow the above-mentioned steps.
> Is there anything else I can try to reduce my final binary file size
> (ROM size) ?
>
>
> Thanks,
> LIJIN T V
>
Hello,
The entropy module uses a hash to mix the entropy. It uses SHA-512 if
present and SHA-256 otherwise. Depending on the hash function, the
entropy module can return either up to 64 bytes (SHA-512) or 32 bytes
(SHA-256). The CTR_DRBG module knows about this and requests only 32
bytes at a time if the entropy module only delivers 32 bytes at a time.
It looks like something goes wrong when CTR_DRBG tries to request 64
bytes. This could be, for example, because a buffer is too small
somewhere, or because of a limitation of the entropy source. You would
need to debug the call to mbedtls_entropy_func to know more.
As a workaround, you can enable MBEDTLS_ENTROPY_FORCE_SHA256. Then the
entropy module will use SHA-256 (even if MBEDTLS_SHA512_C is enabled)
and only return 32 bytes at a time, and CTR_DRBG understands this and
will only request 32 bytes.
--
Gilles Peskine
Mbed TLS developer
On 27/01/2021 06:08, T V LIJIN (EXT) via mbed-tls wrote:
> Hi,
> After enabling *MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* ,
> /mbedtls_ctr_drbg_seed/ is returning *0x0034
> */(MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED)/
> But if I just enable *MBEDTLS_NO_PLATFORM_ENTROPY* and keep
> *MBEDTLS_SHA512_C* disabled, it does not return any error for
> /mbedtls_ctr_drbg_seed./
> /
> /
> My project uses certificates with SHA384 signature, so it
> requires***MBEDTLS_SHA512_C *to be enabled.
> /*MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* /both needs to be
> enabled in my project , but Iam facing issue with
> mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What
> might be the reason for mbedtls_ctr_drbg_seed to fail while
> enabling/////*MBEDTLS_SHA512_C.*/////
> How to overcome this issue?
>
>
> Thanks,
> LIJIN T V
>
Hi,
After enabling MBEDTLS_NO_PLATFORM_ENTROPY and MBEDTLS_SHA512_C , mbedtls_ctr_drbg_seed is returning 0x0034 (MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED)
But if I just enable MBEDTLS_NO_PLATFORM_ENTROPY and keep MBEDTLS_SHA512_C disabled, it does not return any error for mbedtls_ctr_drbg_seed.
My project uses certificates with SHA384 signature, so it requires MBEDTLS_SHA512_C to be enabled.
MBEDTLS_NO_PLATFORM_ENTROPY and MBEDTLS_SHA512_C both needs to be enabled in my project , but Iam facing issue with mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What might be the reason for mbedtls_ctr_drbg_seed to fail while enabling MBEDTLS_SHA512_C.
How to overcome this issue?
Thanks,
LIJIN T V
Hi,
I'm trying to optimize the size of my binary file by making the following changes in "mbedtls/config.h"
#define MBEDTLS_MPI_WINDOW_SIZE 1
#define MBEDTLS_MPI_MAX_SIZE 32
#define MBEDTLS_ECP_MAX_BITS 256
#define MBEDTLS_SHA256_SMALLER
Even after making the above changes I couldn't see any change in the binary size.
https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint - This is the link I referred to follow the above-mentioned steps.
Is there anything else I can try to reduce my final binary file size (ROM size) ?
Thanks,
LIJIN T V
