Hello everyone,
I have this certificate blob and I'm using mbedtls to read this, but after called mbedtls_x509_crt_info() or mbedtls_x509_dn_gets(), the chinese characters got garbled. I have googled this, read the mbedtls knowledge base and searched the issues and got no luck. The field i want to parse is the subject field and the issuer field. and currently I cannot provide the certificate blob due to security reasons.
Any help would be much appreciated.
Sincerely,
Newt Ma
Hi Sawyer,
After looking at the issues in more detail I would like to be more precise about CVE-2018-1000520:
* It is not a security issue in the context of TLS 1.2
* It can be a security issue if TLS 1.0 or TLS 1.1 is used
* The severity is so low that we decided not fixing it ourselves, but to open it up for community contributions
* The corresponding issue has been closed down by mistake, I am reopening it now: https://github.com/ARMmbed/mbedtls/issues/1561
(Many thanks to Simon Butcher for noticing this and pointing it out.)
Please let me know if I you would like to know more about this issue.
Best regards,
Janos
(Mbed TLS developer)
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Janos Follath via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: Janos Follath <Janos.Follath(a)arm.com>
Date: Wednesday, 28 October 2020 at 09:42
To: Sawyer Liu <sawyer.liu(a)nxp.com>
Cc: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: Re: [mbed-tls] About mbedtls CVE
Hi Sawyer,
Thank you for your interest in Mbed TLS. Currently the status of these CVE’s is:
- CVE-2020-16150 has been fixed in the latest Mbed TLS release
- CVE-2018-1000520 is not a security issue, it had been studied and rejected
- CVE-2016-3739 is a vulnerability in an application using Mbed TLS but not in Mbed TLS itself, also it too had been fixed.
Does this answer your question?
(Also, I would like to make a minor clarification: we are not Arm Support. As far as I know Arm does not offer official support for Mbed TLS. Arm only contributes engineers to the Mbed TLS project, and at the moment these engineers are the maintainers of Mbed TLS. We are on this mailing list and try to answer questions, but we are not doing that as official support provided by Arm, but as members of the community. Mbed TLS is supported by the community and this mailing list is indeed the right place to get that support. I apologise for the nitpick, I just wanted to make sure that we are not giving the wrong impressions.)
Best regards,
Janos
(Mbed TLS developer)
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Sawyer Liu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: Sawyer Liu <sawyer.liu(a)nxp.com>
Date: Wednesday, 28 October 2020 at 01:59
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] About mbedtls CVE
Hello ARM Support,
About below CVEs, any update? Thanks.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16150<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre…>
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000520https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3739
Best Regards
Sawyer Liu
Microcontrollers, NXP Semiconductors
Hello,
On 05/11/2020 17:49, François Beerten via mbed-tls wrote:
> Hi,
>
> Thank you Gilles for the detailed reply.
>
> Do you prefer that discussion about PSA Crypto API spec go on mailing
> list instead of here ? Is there some room for evolution or is the spec
> already in a frozen released state ?
Please use the psa-crypto list since there may be participants there who
don't care about Mbed TLS.
Version 1.0 of the PSA Crypto API is official so we won't make
incompatible changes unless there is a compelling reason. We can, and
will, add features in 1.x versions of the specification. Among planned
features are: more algorithm declarations, key wrapping, key stretching,
and a better treatment of key establishment (including password-based
key establishment).
>
> For new algorithms, it's of course preferable that they're defined in
> the spec itself. But does the mbedtls project want to supports all
> algorithms that will be used with PSA Crypto API ?
Mbed TLS intends to be a reference implementation of the PSA crypto API.
However it isn't clear whether this means that Mbed TLS will eventually
support all algorithms that the API declares: we intend to support all
methods, but not necessarily all algorithms. A conforming implementation
of the API is allowed to support any subset of the algorithms.
We (here meaning Arm, not Mbed TLS) don't have a formal policy to decide
whether to include a declaration for an algorithm, but here are some
criteria that we're likely to follow:
* There should be a public specification. (This can be a document that's
only for purchase, such as an ISO standard.)
* The algorithm should either be in good standing, or in current use in
legacy protocols.
* The bar is low for adding an algorithm that just requires a #define.
It's a lot higher if a new function is needed.
* Availability in Mbed TLS is not required.
>
> For pure ED25519 and ED448 with scattered data, there's one big
> gotcha. You need to generate twice a hash that includes the message.
> Thus the implementation needs to be able to access the buffers of the
> message twice. With a piece of the message given only once as in the
> init-update-finish scheme, that does not work well.
>
> From reading the document on the PSA Crypto driver API, a transparent
> driver benefits from the management of keys done by the mbedtls
> implementation. But what benefit is there for a driver working with
> opaque keys which has to fully handle the protections and restrictions
> of keys internally ?
>
One of the driving goals of PSA is to make security unobtrusive, and to
facilitate security improvements. A unified interface to key management
makes it easy to upgrade from having all keys inside, to using a
single-chip application separation technology (MMU, MPU, secure enclave,
…), to wrapping keys in a secure element and storing the wrapped key
externally, to storing keys in a secure element (which protects against
undeletion). When an application uses a key, it doesn't need to care
where the key is stored.
Best regards,
--
Gilles Peskine
> Best,
>
> François.
>
>
> On 11/2/20 11:01 PM, Gilles Peskine via mbed-tls wrote:
>> Hello,
>>
>> Thank you for your interest in the PSA crypto API.
>>
>> On 28/10/2020 15:20, François Beerten via mbed-tls wrote:
>>> Hi everybody,
>>>
>>> After reading the PSA Crypto API specs (as on
>>> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html)
>>> and looking at the mbed TLS library, a few questions came up.
>>>
>>> Is there some repository with the sources of the PSA Crypto API specs
>>> where one can follow the evolution and eventually send proposals and
>>> patches ?
>>>
>> The PSA specification drafts are not public. You can send feedback about
>> the PSA Crypto application and driver interfaces on the psa-crypto
>> mailing list (psa-crypto(a)lists.trustedfirmware.org,
>> https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you
>> prefer to send confidential feedback, you can email mbed-crypto(a)arm.com
>> (feedback at this address will only be discussed inside Arm). An issue
>> in the Mbed TLS repository will also reach PSA Crypto architects.
>>
>>> A note says "Hash suspend and resume is not defined for the SHA3
>>> family of hash algorithms". Why are they not defined for SHA3 ?
>>>
>> The hash suspend/resume operations marshall the internal state of the
>> hash operation. They mimic an existing JavaCard API
>> (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…).
>>
>> There is a de facto standard representation of the internal state for
>> common Merkle-Damgård constructions, which covers all the currently
>> defined hash algorithms except SHA3. If there's interest in this
>> functionality, we could standardize a representation for SHA3.
>>
>>> How can or should one add support in PSA Crypto AP for not yet defined
>>> algorithms (for example a KDF) ?
>>>
>> Answer from a PSA Crypto architect: preferably by requesting an encoding
>> for this KDF as a PSA_ALG_xxx value (as well as new
>> PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do
>> that, use an encoding in the vendor range (most significant bit set).
>>
>> The world of key derivation functions is unfortunately messy: there are
>> many similar, but not functionally equivalent constructions (such as
>> hashing a secret together with a nonce, formatted in all kinds of
>> different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set
>> required for the TLS protocol. We expect 1.0.x updates to define more
>> KDF algorithms.
>>
>> Answer from an Mbed TLS maintainer: contributing an implementation would
>> be appreciated (but not required).
>>
>>> In multipart operations, can the user reuse the input buffers
>>> immediately after doing an 'update' (for example after
>>> psa_hash_update()) ? And can he reuse the input buffers immediately
>>> after some "setup" functions like psa_cipher_set_iv() or
>>> psa_aead_set_nonce() ?
>>>
>> Yes. PSA crypto API functions that take a buffer as a parameter never
>> take ownership of that buffer. Once the function returns, you can do
>> whatever you want with the buffer.
>>
>> The PSA specification even guarantees that you can use the same buffer,
>> or overlapping buffers, as inputs and outputs to the same function call.
>> However beware that the Mbed TLS implementation does not always support
>> such overlap (https://github.com/ARMmbed/mbedtls/issues/3266).
>>
>>> Do you plan to support (pure) ED25519 and ED448 only via
>>> psa_sign_message() and psa_verify_message() ? What about messages in
>>> multiple chunks ?
>>>
>> We plan to add a multi-part message signature interface, both for the
>> sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I
>> expect the design to be “what you'd expect” but I haven't yet verified
>> that there aren't any gotchas.
>>
>>> In psa_asymmetric_encrypt(), why is the salt provided explicitely.
>>> Shouldn't it be generated randomly internally when needed ?
>>>
>> Some applications use a fixed or deterministic salt which they check on
>> decryption. Note that this parameter is what PKCS#1 calls “label”.
>>
>>> With PSA Crypto API, you define a flexible API for cryptographic
>>> operations. Apparently, other providers could make their own
>>> implementation of PSA Crypto API. Will mbed TLS then be able to use
>>> those alternate PSA Crypto API implementations ? How would that work
>>> practically ?
>>>
>> The X.509 and TLS layer of Mbed TLS are currently designed to use the
>> mbedtls_xxx crypto API. We have already added partial support for the
>> psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet
>> possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto
>> implementation. (I think this is already possible for a small set of
>> cipher suites, but it isn't something that we've tried or currently
>> actively support.) Before this can happen, some Mbed TLS APIs need to
>> change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan
>> to decouple the PSA crypto reference implementation (Mbed TLS's current
>> crypto implementation) from the X.509/TLS layer (which will remain “Mbed
>> TLS”). Our plans
>> (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far
>> into the future are still vague and may change.
>>
>> Note that for the most common case of wanting a different implementation
>> of cryptography, which is to leverage hardware such as accelerators and
>> secure elements, PSA is defining a driver interface which is currently
>> being implemented in Mbed TLS
>> (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…).
>>
>> The driver interface lets you combine mechanisms supported by your
>> hardware with Mbed TLS's implementation for mechanisms without hardware
>> support.
>>
Hi Francois,
The workshop slides and recordings are now available here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/
Regards,
Shebu
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of François Beerten via mbed-tls
Sent: Thursday, November 5, 2020 4:52 PM
To: mbed-tls(a)lists.trustedfirmware.org
Subject: Re: [mbed-tls] Mbed TLS Virtual Workshop Tomorrow
Hi Shebu,
Will you post the slides of the presentations of the workshop ?
Thanks,
François.
On 11/2/20 9:01 PM, Shebu Varghese Kuriakose via mbed-tls wrote:
Hi All,
Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT.
See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/
Thanks,
Shebu
-----Original Appointment-----
From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com><mailto:linaro.org_havjv2figrh5egaiurb229pd8c@group.calendar.google.com>
Sent: Friday, October 23, 2020 12:32 AM
To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>; Don Harbin; psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org>; Dave Rodgman
Subject: Mbed TLS Virtual Workshop
When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London.
Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
You have been invited to the following event.
Mbed TLS Virtual Workshop
When
Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
Where
Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>)
Calendar
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
Who
•
Don Harbin - creator
•
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
•
mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>
•
psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org>
•
dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com>
more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Hi,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop.
The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss
* The future direction of the project and
* Ways to improve community collaboration
Here is the agenda for the workshop.
Topic Time (in GMT)
Welcome 2.00 - 2.10pm
Constant-time code 2.10 – 2.30pm
Processes - how does work get scheduled? 2.30 – 2.50pm
PSA Crypto APIs 2.50 – 3.20pm
PSA Crypto for Silicon Labs Wireless
MCUs - Why, What, Where and When 3.20 – 3.50pm
Break
Roadmap, TLS1.3 Update 4.10 – 4.30pm
Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm
How do I contribute my first review
and be an effective Mbed TLS reviewer 5.00 – 5.30pm
Regards,
Don Harbin
Trusted Firmware Community Manager
==============Zoom details below:====================
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: Mbed TLS Virtual Workshop
Time: Nov 3, 2020 02:00 PM Greenwich Mean Time
Join Zoom Meeting
https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…>
Meeting ID: 953 1520 0315
Passcode: 143755
One tap mobile
+16699009128,,95315200315# US (San Jose)
+12532158782,,95315200315# US (Tacoma)
Dial by your location
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 953 1520 0315
Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…>
Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Invitation from Google Calendar<https://www.google.com/calendar/>
You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.
Hi Shebu,
Will you post the slides of the presentations of the workshop ?
Thanks,
François.
On 11/2/20 9:01 PM, Shebu Varghese Kuriakose via mbed-tls wrote:
>
> Hi All,
>
> Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday,
> November 3^rd ) from 2 to 6pm GMT.
>
> See agenda and zoom link here -
> https://www.trustedfirmware.org/meetings/mbed-tls-workshop/
> <https://www.trustedfirmware.org/meetings/mbed-tls-workshop/>
>
> Thanks,
>
> Shebu
>
> -----Original Appointment-----
> *From:* Trusted Firmware Public Meetings
> <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>
> *Sent:* Friday, October 23, 2020 12:32 AM
> *To:* Trusted Firmware Public Meetings; Shebu Varghese Kuriakose;
> mbed-tls(a)lists.trustedfirmware.org; Don Harbin;
> psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman
> *Subject:* Mbed TLS Virtual Workshop
> *When:* Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin,
> Edinburgh, Lisbon, London.
> *Where:* Zoom:
> https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
>
>
> *You have been invited to the following event.*
>
>
> Mbed TLS Virtual Workshop
>
> When
>
>
>
> Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
>
> Where
>
>
>
> Zoom:
> https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
> (map
> <https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>)
>
> Calendar
>
>
>
> shebu.varghesekuriakose(a)arm.com <mailto:shebu.varghesekuriakose@arm.com>
>
> Who
>
>
>
> •
>
>
>
> Don Harbin- creator
>
> •
>
>
>
> shebu.varghesekuriakose(a)arm.com <mailto:shebu.varghesekuriakose@arm.com>
>
> •
>
>
>
> mbed-tls(a)lists.trustedfirmware.org
> <mailto:mbed-tls@lists.trustedfirmware.org>
>
> •
>
>
>
> psa-crypto(a)lists.trustedfirmware.org
> <mailto:psa-crypto@lists.trustedfirmware.org>
>
> •
>
>
>
> dave.rodgman(a)arm.com <mailto:dave.rodgman@arm.com>
>
> *more details »
> <https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>***
>
> Hi,
> Trustedfirmware.org community project would like to invite you to the
> Mbed TLS Virtual Workshop.
>
> The purpose of the workshop is to bring together the Mbed TLS
> community including maintainers, contributors and users to discuss
>
> * The future direction of the project and
> * Ways to improve community collaboration
>
> Here is the agenda for the workshop.
>
> *Topic Time (in GMT)*
> Welcome 2.00 - 2.10pm
> Constant-time code 2.10 – 2.30pm
> Processes - how does work get scheduled? 2.30 – 2.50pm
> PSA Crypto APIs 2.50 – 3.20pm
> PSA Crypto for Silicon Labs Wireless
> MCUs - Why, What, Where and When 3.20 – 3.50pm
>
> *Break *
>
> Roadmap, TLS1.3 Update 4.10 – 4.30pm
> Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm
> How do I contribute my first review
> and be an effective Mbed TLS reviewer 5.00 – 5.30pm
>
> Regards,
>
> Don Harbin
> Trusted Firmware Community Manager
>
>
> ==============Zoom details below:====================
> Trusted Firmware is inviting you to a scheduled Zoom meeting.
>
> Topic: Mbed TLS Virtual Workshop
> Time: Nov 3, 2020 02:00 PM Greenwich Mean Time
>
> Join Zoom Meeting
> https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
> <https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…>
>
> Meeting ID: 953 1520 0315
> Passcode: 143755
> One tap mobile
> +16699009128,,95315200315# US (San Jose)
> +12532158782,,95315200315# US (Tacoma)
>
> Dial by your location
> +1 669 900 9128 US (San Jose)
> +1 253 215 8782 US (Tacoma)
> +1 346 248 7799 US (Houston)
> +1 646 558 8656 US (New York)
> +1 301 715 8592 US (Germantown)
> +1 312 626 6799 US (Chicago)
> 888 788 0099 US Toll-free
> 877 853 5247 US Toll-free
> Meeting ID: 953 1520 0315
> Find your local number: https://linaro-org.zoom.us/u/apL3hgti4
> <https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…>
>
> Going (shebu.varghesekuriakose(a)arm.com
> <mailto:shebu.varghesekuriakose@arm.com>)? *Yes
> <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>**-
> **Maybe
> <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>**-
> **No
> <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>*more
> options »
> <https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
>
> Invitation from Google Calendar <https://www.google.com/calendar/>
>
> You are receiving this courtesy email at the account
> shebu.varghesekuriakose(a)arm.com
> <mailto:shebu.varghesekuriakose@arm.com> because you are an attendee
> of this event.
>
> To stop receiving future updates for this event, decline this event.
> Alternatively you can sign up for a Google account at
> https://www.google.com/calendar/ and control your notification
> settings for your entire calendar.
>
> Forwarding this invitation could allow any recipient to send a
> response to the organizer and be added to the guest list, or invite
> others regardless of their own invitation status, or to modify your
> RSVP. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
>
Hi,
Thank you Gilles for the detailed reply.
Do you prefer that discussion about PSA Crypto API spec go on mailing
list instead of here ? Is there some room for evolution or is the spec
already in a frozen released state ?
For new algorithms, it's of course preferable that they're defined in
the spec itself. But does the mbedtls project want to supports all
algorithms that will be used with PSA Crypto API ?
For pure ED25519 and ED448 with scattered data, there's one big gotcha.
You need to generate twice a hash that includes the message. Thus the
implementation needs to be able to access the buffers of the message
twice. With a piece of the message given only once as in the
init-update-finish scheme, that does not work well.
From reading the document on the PSA Crypto driver API, a transparent
driver benefits from the management of keys done by the mbedtls
implementation. But what benefit is there for a driver working with
opaque keys which has to fully handle the protections and restrictions
of keys internally ?
Best,
François.
On 11/2/20 11:01 PM, Gilles Peskine via mbed-tls wrote:
> Hello,
>
> Thank you for your interest in the PSA crypto API.
>
> On 28/10/2020 15:20, François Beerten via mbed-tls wrote:
>> Hi everybody,
>>
>> After reading the PSA Crypto API specs (as on
>> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html)
>> and looking at the mbed TLS library, a few questions came up.
>>
>> Is there some repository with the sources of the PSA Crypto API specs
>> where one can follow the evolution and eventually send proposals and
>> patches ?
>>
> The PSA specification drafts are not public. You can send feedback about
> the PSA Crypto application and driver interfaces on the psa-crypto
> mailing list (psa-crypto(a)lists.trustedfirmware.org,
> https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you
> prefer to send confidential feedback, you can email mbed-crypto(a)arm.com
> (feedback at this address will only be discussed inside Arm). An issue
> in the Mbed TLS repository will also reach PSA Crypto architects.
>
>> A note says "Hash suspend and resume is not defined for the SHA3
>> family of hash algorithms". Why are they not defined for SHA3 ?
>>
> The hash suspend/resume operations marshall the internal state of the
> hash operation. They mimic an existing JavaCard API
> (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…).
> There is a de facto standard representation of the internal state for
> common Merkle-Damgård constructions, which covers all the currently
> defined hash algorithms except SHA3. If there's interest in this
> functionality, we could standardize a representation for SHA3.
>
>> How can or should one add support in PSA Crypto AP for not yet defined
>> algorithms (for example a KDF) ?
>>
> Answer from a PSA Crypto architect: preferably by requesting an encoding
> for this KDF as a PSA_ALG_xxx value (as well as new
> PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do
> that, use an encoding in the vendor range (most significant bit set).
>
> The world of key derivation functions is unfortunately messy: there are
> many similar, but not functionally equivalent constructions (such as
> hashing a secret together with a nonce, formatted in all kinds of
> different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set
> required for the TLS protocol. We expect 1.0.x updates to define more
> KDF algorithms.
>
> Answer from an Mbed TLS maintainer: contributing an implementation would
> be appreciated (but not required).
>
>> In multipart operations, can the user reuse the input buffers
>> immediately after doing an 'update' (for example after
>> psa_hash_update()) ? And can he reuse the input buffers immediately
>> after some "setup" functions like psa_cipher_set_iv() or
>> psa_aead_set_nonce() ?
>>
> Yes. PSA crypto API functions that take a buffer as a parameter never
> take ownership of that buffer. Once the function returns, you can do
> whatever you want with the buffer.
>
> The PSA specification even guarantees that you can use the same buffer,
> or overlapping buffers, as inputs and outputs to the same function call.
> However beware that the Mbed TLS implementation does not always support
> such overlap (https://github.com/ARMmbed/mbedtls/issues/3266).
>
>> Do you plan to support (pure) ED25519 and ED448 only via
>> psa_sign_message() and psa_verify_message() ? What about messages in
>> multiple chunks ?
>>
> We plan to add a multi-part message signature interface, both for the
> sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I
> expect the design to be “what you'd expect” but I haven't yet verified
> that there aren't any gotchas.
>
>> In psa_asymmetric_encrypt(), why is the salt provided explicitely.
>> Shouldn't it be generated randomly internally when needed ?
>>
> Some applications use a fixed or deterministic salt which they check on
> decryption. Note that this parameter is what PKCS#1 calls “label”.
>
>> With PSA Crypto API, you define a flexible API for cryptographic
>> operations. Apparently, other providers could make their own
>> implementation of PSA Crypto API. Will mbed TLS then be able to use
>> those alternate PSA Crypto API implementations ? How would that work
>> practically ?
>>
> The X.509 and TLS layer of Mbed TLS are currently designed to use the
> mbedtls_xxx crypto API. We have already added partial support for the
> psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet
> possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto
> implementation. (I think this is already possible for a small set of
> cipher suites, but it isn't something that we've tried or currently
> actively support.) Before this can happen, some Mbed TLS APIs need to
> change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan
> to decouple the PSA crypto reference implementation (Mbed TLS's current
> crypto implementation) from the X.509/TLS layer (which will remain “Mbed
> TLS”). Our plans
> (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far
> into the future are still vague and may change.
>
> Note that for the most common case of wanting a different implementation
> of cryptography, which is to leverage hardware such as accelerators and
> secure elements, PSA is defining a driver interface which is currently
> being implemented in Mbed TLS
> (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…).
> The driver interface lets you combine mechanisms supported by your
> hardware with Mbed TLS's implementation for mechanisms without hardware
> support.
>
Hi Mate,
I had a look and I couldn’t find such a feature implemented either. I don’t think that Mbed TLS supports that at the moment.
Best regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Z.Máté via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org>
Reply to: "Z.Máté" <enleszekakalozkiraly(a)gmail.com>
Date: Monday, 2 November 2020 at 21:01
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Write private key into buffer using encrypted PEM format
Dear mbedtls list members!
Sorry if this is the second time I ask, I'm not sure the previous question is still on the list.
I'm asking if there's a way to export a private key into a buffer in an encrypted format. So that mbedtls_pk_parse_key() has to be called with a password.
In the example program key_app.c (I hope that's how it's called) I can see there are password encrypted PEM formatted keys. But how to generate one?
For clarity, this is the type of header I'm looking for.
—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,AB8E2B5B2D989271273F6730B6F9C687
……………………………………………….
……………………………………………….
………………………………………
—–END RSA PRIVATE KEY—–
I was only able to generate something like this by, using command line openssl. But I'd like a better solution, in code, using mbedtls.
Yours
Zombor Máté
Hello,
Thank you for your interest in the PSA crypto API.
On 28/10/2020 15:20, François Beerten via mbed-tls wrote:
>
> Hi everybody,
>
> After reading the PSA Crypto API specs (as on
> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html)
> and looking at the mbed TLS library, a few questions came up.
>
> Is there some repository with the sources of the PSA Crypto API specs
> where one can follow the evolution and eventually send proposals and
> patches ?
>
The PSA specification drafts are not public. You can send feedback about
the PSA Crypto application and driver interfaces on the psa-crypto
mailing list (psa-crypto(a)lists.trustedfirmware.org,
https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you
prefer to send confidential feedback, you can email mbed-crypto(a)arm.com
(feedback at this address will only be discussed inside Arm). An issue
in the Mbed TLS repository will also reach PSA Crypto architects.
> A note says "Hash suspend and resume is not defined for the SHA3
> family of hash algorithms". Why are they not defined for SHA3 ?
>
The hash suspend/resume operations marshall the internal state of the
hash operation. They mimic an existing JavaCard API
(https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…).
There is a de facto standard representation of the internal state for
common Merkle-Damgård constructions, which covers all the currently
defined hash algorithms except SHA3. If there's interest in this
functionality, we could standardize a representation for SHA3.
> How can or should one add support in PSA Crypto AP for not yet defined
> algorithms (for example a KDF) ?
>
Answer from a PSA Crypto architect: preferably by requesting an encoding
for this KDF as a PSA_ALG_xxx value (as well as new
PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do
that, use an encoding in the vendor range (most significant bit set).
The world of key derivation functions is unfortunately messy: there are
many similar, but not functionally equivalent constructions (such as
hashing a secret together with a nonce, formatted in all kinds of
different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set
required for the TLS protocol. We expect 1.0.x updates to define more
KDF algorithms.
Answer from an Mbed TLS maintainer: contributing an implementation would
be appreciated (but not required).
> In multipart operations, can the user reuse the input buffers
> immediately after doing an 'update' (for example after
> psa_hash_update()) ? And can he reuse the input buffers immediately
> after some "setup" functions like psa_cipher_set_iv() or
> psa_aead_set_nonce() ?
>
Yes. PSA crypto API functions that take a buffer as a parameter never
take ownership of that buffer. Once the function returns, you can do
whatever you want with the buffer.
The PSA specification even guarantees that you can use the same buffer,
or overlapping buffers, as inputs and outputs to the same function call.
However beware that the Mbed TLS implementation does not always support
such overlap (https://github.com/ARMmbed/mbedtls/issues/3266).
> Do you plan to support (pure) ED25519 and ED448 only via
> psa_sign_message() and psa_verify_message() ? What about messages in
> multiple chunks ?
>
We plan to add a multi-part message signature interface, both for the
sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I
expect the design to be “what you'd expect” but I haven't yet verified
that there aren't any gotchas.
> In psa_asymmetric_encrypt(), why is the salt provided explicitely.
> Shouldn't it be generated randomly internally when needed ?
>
Some applications use a fixed or deterministic salt which they check on
decryption. Note that this parameter is what PKCS#1 calls “label”.
> With PSA Crypto API, you define a flexible API for cryptographic
> operations. Apparently, other providers could make their own
> implementation of PSA Crypto API. Will mbed TLS then be able to use
> those alternate PSA Crypto API implementations ? How would that work
> practically ?
>
The X.509 and TLS layer of Mbed TLS are currently designed to use the
mbedtls_xxx crypto API. We have already added partial support for the
psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet
possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto
implementation. (I think this is already possible for a small set of
cipher suites, but it isn't something that we've tried or currently
actively support.) Before this can happen, some Mbed TLS APIs need to
change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan
to decouple the PSA crypto reference implementation (Mbed TLS's current
crypto implementation) from the X.509/TLS layer (which will remain “Mbed
TLS”). Our plans
(https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far
into the future are still vague and may change.
Note that for the most common case of wanting a different implementation
of cryptography, which is to leverage hardware such as accelerators and
secure elements, PSA is defining a driver interface which is currently
being implemented in Mbed TLS
(https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…).
The driver interface lets you combine mechanisms supported by your
hardware with Mbed TLS's implementation for mechanisms without hardware
support.
--
Gilles Peskine
PSA Cryptography architect and Mbed TLS developer
> Thank you for your attention,
>
> François.
>
>
>
Dear mbedtls list members!
Sorry if this is the second time I ask, I'm not sure the previous question
is still on the list.
I'm asking if there's a way to export a private key into a buffer in an
encrypted format. So that mbedtls_pk_parse_key() has to be called with a
password.
In the example program key_app.c (I hope that's how it's called) I can see
there are password encrypted PEM formatted keys. But how to generate one?
For clarity, this is the type of header I'm looking for.
—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,AB8E2B5B2D989271273F6730B6F9C687
……………………………………………….
……………………………………………….
………………………………………
—–END RSA PRIVATE KEY—–
I was only able to generate something like this by, using command line
openssl. But I'd like a better solution, in code, using mbedtls.
Yours
Zombor Máté
Hi All,
Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT.
See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/
Thanks,
Shebu
-----Original Appointment-----
From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>
Sent: Friday, October 23, 2020 12:32 AM
To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman
Subject: Mbed TLS Virtual Workshop
When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London.
Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
You have been invited to the following event.
Mbed TLS Virtual Workshop
When
Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
Where
Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>)
Calendar
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
Who
•
Don Harbin - creator
•
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
•
mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>
•
psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org>
•
dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com>
more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Hi,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop.
The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss
* The future direction of the project and
* Ways to improve community collaboration
Here is the agenda for the workshop.
Topic Time (in GMT)
Welcome 2.00 - 2.10pm
Constant-time code 2.10 – 2.30pm
Processes - how does work get scheduled? 2.30 – 2.50pm
PSA Crypto APIs 2.50 – 3.20pm
PSA Crypto for Silicon Labs Wireless
MCUs - Why, What, Where and When 3.20 – 3.50pm
Break
Roadmap, TLS1.3 Update 4.10 – 4.30pm
Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm
How do I contribute my first review
and be an effective Mbed TLS reviewer 5.00 – 5.30pm
Regards,
Don Harbin
Trusted Firmware Community Manager
==============Zoom details below:====================
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: Mbed TLS Virtual Workshop
Time: Nov 3, 2020 02:00 PM Greenwich Mean Time
Join Zoom Meeting
https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…>
Meeting ID: 953 1520 0315
Passcode: 143755
One tap mobile
+16699009128,,95315200315# US (San Jose)
+12532158782,,95315200315# US (Tacoma)
Dial by your location
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 953 1520 0315
Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…>
Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Invitation from Google Calendar<https://www.google.com/calendar/>
You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.
