Hi all,
We have a product that requires very strong security measures. When
compiling the mbedtls library, we face the following issue: Compiling C
code with LVI-mitigations is often much faster than relying on automatic
LVI mitigations on assembly code. The MPI functions are a good example
where we wish to rely on C source code. For other functions, we need to
rely on assembly code in order to mitigate other vulnerabilities (e.g.,
we require AESNI assembly instructions over C implementations of AES).
Currently there isn't an option to choose between C/assembly per function.
What would be an acceptable solution for this?
greetings,
Raoul
Also, if you're looking for a hardware platform with PSA Crypto drivers,
Silicon Labs has one available. They've been participating in Mbed TLS
development recently and a large part of the driver support code added
in the past few months comes from them. You can see the documentation of
their development kit at https://docs.silabs.com/mbed-tls/latest/ . (If
you want to know about getting sample hardware and driver code … I'm not
the right person to ask.)
--
Gilles Peskine
On 24/02/2021 22:26, Gilles Peskine via mbed-tls wrote:
> Hi Frank,
>
> I'm not sure what you're looking for. Do you mean open source projects
> like Curl and Hiawatha that can use Mbed TLS as a cryptography provider?
> Those are generally using the classic API, and so can't make generic use
> of secure elements. I am aware of private projects using the limited
> features available today (for example, TLS servers can use async private
> key operations to put the key in an HSM — see
> https://tls.mbed.org/kb/how-to/ssl_async).
>
> I've used SoftHSM in the past as a way to test portable PKCS#11 client
> code without hardware. It did the job well. I can't speak for the
> quality of its cryptography since I was only using it for testing.
>
> If you're looking for a generic interface between applications and
> secure elements, then I would recommend PSA crypto over PKCS#11. We did
> try to make PSA Crypto a better PKCS#11. Obviously I'm biased :) But of
> course PKCS#11 is old and venerable, whereas PSA is new and the support
> for hardware secure elements is still a work in progress.
>
Hi Frank,
I'm not sure what you're looking for. Do you mean open source projects
like Curl and Hiawatha that can use Mbed TLS as a cryptography provider?
Those are generally using the classic API, and so can't make generic use
of secure elements. I am aware of private projects using the limited
features available today (for example, TLS servers can use async private
key operations to put the key in an HSM — see
https://tls.mbed.org/kb/how-to/ssl_async).
I've used SoftHSM in the past as a way to test portable PKCS#11 client
code without hardware. It did the job well. I can't speak for the
quality of its cryptography since I was only using it for testing.
If you're looking for a generic interface between applications and
secure elements, then I would recommend PSA crypto over PKCS#11. We did
try to make PSA Crypto a better PKCS#11. Obviously I'm biased :) But of
course PKCS#11 is old and venerable, whereas PSA is new and the support
for hardware secure elements is still a work in progress.
--
Gilles Peskine
Mbed TLS developer and PSA Crypto architect
On 21/02/2021 17:11, Frank Bergmann via mbed-tls wrote:
> Hi Gilles,
>
> thank you for your detailled answer.
> Honestly I was in fear that your answer would look like this. ;-)
>
> Do you maybe know of any plans of any software project to use mbed TLS
> together with a secure element?
>
> I asked SoftHSM because it looks much promising for our goals but they
> answered that they don't have any plans to use different ssl libs.
>
>
> cheers,
> Frank
>
>
> On 08.02.21 23:07, Gilles Peskine via mbed-tls wrote:
>> 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.
>>
Hi Gábor,
Yes, it is ready for review, I have added the corresponding labels. Now there is nothing else to do just to wait for the reviews.
Best regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Tuesday, 23 February 2021 at 06:29
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] PR-4161-merge TLS Testing — Failures: ABI-API-checking
Hello Guys!
AFter a week of debugging yesterday I was able to solve the issues on my PR, but the ABI-API failure is still on. I was told that based on my changes it is OK, I should not worry.
Does this mean that my PR is ready for review or it should have disappeared by now? In the second case could someone provide me the jenkins reports and some idea where should I start searching?
This is my PR:
https://github.com/ARMmbed/mbedtls/pull/4161
Thank you in advance!
BR,
Gábor
Hello Guys!
AFter a week of debugging yesterday I was able to solve the issues on my
PR, but the ABI-API failure is still on. I was told that based on my
changes it is OK, I should not worry.
Does this mean that my PR is ready for review or it should have disappeared
by now? In the second case could someone provide me the jenkins reports and
some idea where should I start searching?
This is my PR:
https://github.com/ARMmbed/mbedtls/pull/4161
Thank you in advance!
BR,
Gábor
Helló János!
Yes I tried that one (and plenty of other stuff). Finally I just reset the
branch and recommited the changes solving this particular issue.
Unfortunately I had to create a new PR, because git did not let me reopen
it, but that is another topic.
Thank you for the help!
BR,
Gábor
Janos Follath <Janos.Follath(a)arm.com> ezt írta (időpont: 2021. febr. 22.,
H, 13:17):
> Hi Gábor,
>
>
>
> Have you tried running `git commit --amend` (without --no-edit --signoff)
> and adding the “Signed-off-by: toth92g <toth92g(a)gmail.com>" line by hand?
>
>
>
> Best regards,
>
> Janos
>
>
>
> *From: *Gábor Tóth <toth92g(a)gmail.com>
> *Date: *Monday, 22 February 2021 at 11:44
> *To: *Janos Follath <Janos.Follath(a)arm.com>
> *Subject: *Re: [mbed-tls] Failing signoff (DCO) on:
> https://github.com/ARMmbed/mbedtls/pull/4140
>
> Helló János!
>
>
>
> Yes, I know which one, but I do not know how to change the commit message
> in git. I have used the provided commands (amend), but it did not correct
> the error.
>
>
>
> Do you know how to change it manually?
>
>
>
> BR,
>
> Gábor
>
>
>
> Janos Follath <Janos.Follath(a)arm.com> ezt írta (időpont: 2021. febr. 22.,
> H, 12:38):
>
> Hi Gábor,
>
>
>
> If you click on the “details” link on the DCO check it will tell you which
> commits are missing the sign-off:
>
> https://github.com/ARMmbed/mbedtls/pull/4140/checks?check_run_id=1950600200
>
>
>
> In this case you have one commit that is not signed off:
>
>
> https://github.com/ARMmbed/mbedtls/pull/4140/commits/fdd3c65ee47ab80f69cfa4…
>
>
>
> Best regards,
>
> Janos
>
>
>
> *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf
> of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
> *Date: *Monday, 22 February 2021 at 11:05
> *To: *mbed-tls(a)lists.trustedfirmware.org <
> mbed-tls(a)lists.trustedfirmware.org>
> *Subject: *[mbed-tls] Failing signoff (DCO) on:
> https://github.com/ARMmbed/mbedtls/pull/4140
>
> Hello Guys!
>
>
>
> I know it is a newbie question, but I am not able to pass this freaking
> DCO test...I have used the provided commands to signoff all the commits and
> as I see all of them has signoff, but it still failes on one. Do you have
> any idea what's wrong or how could I correct it?
>
>
>
> Till now I was able to correct it, but now it seems to be bugged.
>
>
>
> Thank you!
>
>
>
> BR?
> Gábor
>
> 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 Gábor,
If you click on the “details” link on the DCO check it will tell you which commits are missing the sign-off:
https://github.com/ARMmbed/mbedtls/pull/4140/checks?check_run_id=1950600200
In this case you have one commit that is not signed off:
https://github.com/ARMmbed/mbedtls/pull/4140/commits/fdd3c65ee47ab80f69cfa4…
Best regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Monday, 22 February 2021 at 11:05
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Failing signoff (DCO) on: https://github.com/ARMmbed/mbedtls/pull/4140
Hello Guys!
I know it is a newbie question, but I am not able to pass this freaking DCO test...I have used the provided commands to signoff all the commits and as I see all of them has signoff, but it still failes on one. Do you have any idea what's wrong or how could I correct it?
Till now I was able to correct it, but now it seems to be bugged.
Thank you!
BR?
Gábor
Hello Guys!
I know it is a newbie question, but I am not able to pass this freaking DCO
test...I have used the provided commands to signoff all the commits and as
I see all of them has signoff, but it still failes on one. Do you have any
idea what's wrong or how could I correct it?
Till now I was able to correct it, but now it seems to be bugged.
Thank you!
BR?
Gábor