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>.
You have been invited to the following event.
Title: Mbed TLS Virtual Workshop
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 discussThe future direction of the project andWays to improve
community collaborationHere is the agenda for the workshop.Topic
Time (in GMT)Welcome
2.00 - 2.10pmConstant-time code
2.10
– 2.30pmProcesses - how does work get scheduled? 2.30 –
2.50pmPSA Crypto APIs
2.50 –
3.20pmPSA Crypto for Silicon Labs Wireless MCUs
- Why, What, Where and When 3.20 –
3.50pmBreak
Roadmap,
TLS1.3 Update
4.10
– 4.30pmMbed TLS 3.0 Plans, Scope
4.30 – 5.00pmHow do I contribute my first review
and be an effective Mbed TLS reviewer
5.00 – 5.30pmRegards,Don Harbin Trusted Firmware Community
Manager==============Zoom details below:====================Trusted
Firmware is inviting you to a scheduled Zoom meeting.Topic: Mbed TLS
Virtual WorkshopTime: Nov 3, 2020 02:00 PM Greenwich Mean TimeJoin Zoom
Meetinghttps://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT09Meeting
ID: 953 1520 0315Passcode: 143755One 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-freeMeeting ID: 953 1520 0315Find your local number:
https://linaro-org.zoom.us/u/apL3hgti4
When: Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
Where: Zoom:
https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
Calendar: psa-crypto(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* shebu.varghesekuriakose(a)arm.com
* mbed-tls(a)lists.trustedfirmware.org
* psa-crypto(a)lists.trustedfirmware.org
* dave.rodgman(a)arm.com
Event details:
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
psa-crypto(a)lists.trustedfirmware.org 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 at
https://support.google.com/calendar/answer/37135#forwarding
Hi All,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT.
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
The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days.
Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community
* Constant-time code
* How to be an effective Mbed TLS reviewer
* Processes - how does work get scheduled?
* Roadmap, Mbed TLS3.0
* PSA Crypto APIs
* How Do I contribute my first review.
Thanks,
Shebu
(TrustedFirmware.org Co-Chair,
Mbed TLS Technology Manager)
* https://lists.trustedfirmware.org/mailman/listinfo/mbed-tlshttps://lists.trustedfirmware.org/mailman/listinfo/psa-crypto
Hello,
As you may be aware, there is work in progress to implement support for
hardware drivers in Mbed TLS when using the PSA API. These are direct
calls from the PSA frontend layer to driver code, without going through
mbedtls_xxx APIs and the ALT implementations. The specifications are the
psa-driver-*.md files in
https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed and
you can watch the work in progress in the “Unified driver interface: API
design and prototype” epic
https://github.com/ARMmbed/mbedtls/projects/2#column-8543266 .
When an algorithm is implemented in hardware, in most cases, it is
unnecessary to include a software implementation, and it should be
possible to exclude the software implementation from the build to keep
the code size down. Unfortunately the current Mbed TLS configuration
mechanism does not support this, because it does not distinguish “I want
AES” from “I want mbedtls_aes_xxx”. So we need new compile-time options
to convey “I want PSA_KEY_TYPE_AES in my application but I don't care
whether it's done in hardware or mbedtls_aes_xxx”.
We are going to implement a configuration mechanism to select which
cryptographic algorithms are included in the PSA interface in a build of
Mbed TLS. It will rely on #define statements, like the existing
config.h, but with different naming conventions for PSA. You can see the
specification proposal at https://github.com/ARMmbed/mbedtls/pull/3628 .
Feedback is welcome. We're likely to merge this pull request soon, but
even after it's merged I'll keep watching comments, or you can post
feedback on the mailing list, or raise an issue on GitHub if you have a
specific feature request.
A major difference between the current MBEDTLS_xxx_C configuration and
the new PSA_WANT_xxx configuration is that PSA_WANT_xxx is additive: if
PSA_WANT_xxx depends on some other feature, enabling PSA_WANT_xxx will
automatically enable that feature in most cases (the exception being
when there's more than one way to enable the dependent feature, e.g.
when a hash algorithm is needed but it doesn't matter which hash). This
is in contrast with the current strict mechanism where enabling
MBEDTLS_xxx_C is an error if it depends on some other feature that isn't
enabled. We haven't decided yet, but we're thinking of changing to an
additive mechanism for the whole Mbed TLS configuration in Mbed TLS 3.0.
If you want to watch the implementation work in progress, it will be
under the “Driver Interface: Removing unused code” epic
https://github.com/ARMmbed/mbedtls/projects/2#column-9449707 .
Note that the #define-based mechanism is somewhat experimental and we
won't commit yet about its long-term stability in Mbed TLS. It is likely
to be complemented by a JSON-based mechanism in the future. This JSON
mechanism would be similar to the proposed mechanism for drivers and
would allow finer granularity (for example, RSA verification without RSA
signature). Arm is considering standardizing the (as yet non-existent)
JSON mechanism as a PSA specification.
Best regards,
--
Gilles Peskine
Mbed TLS developer (and PSA crypto architect)
Hi Brian,
It is true that each persistent key has only one owner who can access it, the partition that created it.
But note that even if the driver partition could be given permission to access the key, then it wouldn't immediately fix the issue. The driver partition would then need to implement another layer of access control, otherwise partitions would be able to use it as a conduit to access keys that they don't themselves own.
I think a more expected flow would look like:
1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID).
2. NS application calls an AES crypto function in the PSA Crypto partition and provides the key ID.
3. PSA Crypto partition retrieves the key from ITS for use. Client ID = -1.
4. PSA Crypto partition calls an AES crypto function in the driver partition and provides the key material.
But I assume you discarded this approach because it didn't give you the level of concurrency between PSA Crypto and the crypto driver that you wanted.
I am adding the psa-crypto mailing list to this, as people on there may have more/better input.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M
Sent: 10 July 2020 06:18
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Persistent key storage ownership/access
Hi,
I see that keys can only be accessed/modified by their owning secure partition.
File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be:
| 32 -bits | 32 -bits | 32 -bits |
==========================================
PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1)
Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3.
However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work.
Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the
32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be:
| 32 -bits | 32 -bits | 32 -bits |
==========================================
PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver
The file ID would not match what the App imported and the key would not be found.
Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated?
Another explanation of the scenario if the above was not clear:
1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID).
2. NS application calls an AES crypto function and provides the key ID.
3. AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition.
RoT Partition 1:
* PSA Crypto (with keystore)
RoT Partition 2:
- AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators)
RoT Partition 3:
* ITS
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hello,
Arm is seeking early feedback on a proposed interface for cryptographic
drivers that can be plugged into an implementation of the PSA
Cryptography API. A copy of the current specification is attached. You
can find the current draft of the specification of this interface at
https://github.com/gilles-peskine-arm/mbedtls/blob/psa-unified-driver-proto…
Please note that this is work in progress. The document is not complete
yet. At this stage, it is intended to offer a general overview of the
design, not as an implementable specification. Our intention is to
continue refining this design, however we may change it based on the
feedback that we will receive and there is even a small chance that we
will abandon it.
The primary intent of this specification is to allow manufacturers of
cryptographic hardware to distribute drivers that can be added to a
pure-software, portable implementation of the PSA Cryptography API such
as Mbed TLS. The interface was designed to support three types of hardware:
* Cryptographic accelerators that operate on a key which is provided in
cleartext at the beginning of the operation. This type of driver can
also be used to plug in software engines.
* Protected environments that operate on a wrapped key which is stored
outside the protected environment.
* Protected environments that have internal key storage and operate on
keys designated by an identifier.
Concretely, a driver manufacturer would distribute:
* A JSON file specifying the driver's capabilities.
* C headers declaring the types and functions provided by the driver.
* The implementation of the functions provided by the driver, either in
the form of C source code or in the form of compiled code.
Then when an application uses a key:
* If the key is in the memory or local storage of the PSA crypto
subsystem and a driver is available for the requested cryptographic
mechanism, the core (e.g. Mbed TLS) dispatches the cryptographic
operation to the driver.
* If the key is in local storage and no driver is available, the core
performs the cryptographic operation itself.
* If the key is in some other location (as specified by its lifetime),
the core invokes the protected environment driver corresponding to that
location.
This proposal supersedes the previous drafts “PSA cryptographic
accelerator interface” (psa_crypto_accel.h) and “PSA secure element
driver interface” (crypto_se_driver.h).
We intend to implement this specification in Mbed TLS in such a way that
a platform distributor can combine drivers and distribute C source code,
object files or a mixture of the two in their system development kit. In
the long term, the accelerator interface defined here will replace the
current MBEDTLS_xxx_ALT mechanism.
Comments are welcome through the following venues:
* Public email to the psa-crypto or mbed-tls mailing list at
TrustedFirmware.
* Public comments on GitHub on the pull request
https://github.com/ARMmbed/mbedtls/pull/3313 .
* Private email to <mbed-crypto(a)arm.com>. These emails will only be
shared inside Arm. We may use your feedback to influence the design of
PSA Crypto, but your identity and the specifics will be kept confidential.
We do not have a specific deadline for feedback, however we intend to
start implementing this interface in Mbed TLS in June 2020, so feedback
received later will have a reduced chance of influencing the design if
it would entail major changes.
Best regards,
--
Gilles Peskine
Mbed TLS developer and PSA Cryptography architect
Hi,
There is an issue in version 1.0.0 of the PSA Crypto API, that can result in severe inefficiency in key generation in some circumstances. It is also possible that the definition could be interpreted differently in different implementations, which is a major interoperability issue for key derivation algorithms.
As a result, Arm would like to clarify this operation, ideally in a way that eliminates the inefficiency. Please let me know if you have an implementation of the PSA Crypto API, and whether this proposed change would affect it.
In section 10.5.3, the definition of psa_key_derivation_output_key() for several key types is inefficient for Weierstrass elliptic curves and Diffie-Hellman groups whose size is not a multiple of 8. The definition does not follow the cited NIST specifications (although this is not a compliance issue since these NIST specifications apply to random generation, not to deterministic derivation).
The current specification states:
> this function draws a byte string of length ceiling(bits/8) bytes. If the resulting byte string is acceptable, it becomes the key, otherwise the drawn bytes are discarded. This process is repeated until an acceptable byte string is drawn.
This is secure, but it is inefficient if some bits are always 0 (or always 1) in acceptable results. In practice, for L-bit curves where L is not a multiple of 8 (for example sec521r1), this leads to rejecting many candidates because their most significant bits are not 0.
The NIST process (e.g. https://doi.org/10.6028/NIST.SP.800-56Ar3 §5.6.1.2.2 step 4) is similar, but involves drawing L bits from the RNG, not ceiling(L/8).
The input to this function is a byte stream generator. It wouldn't make sense to consume a number of bits that isn't a whole number of bytes. However, forcing top bits to 0 would make sense, and would be more efficient and closer to the NIST process.
Arm proposes to modify the definition to require that the tops bits (ceiling(bits/8)*8 - bits) are set to zero when drawing bytes from the generated stream, prior to the byte string being tested for acceptability. This would be an incompatible change for any implementation that had support for deriving affected keys, which discarded byte strings that had any of the top bits set to one.
Regards,
Andrew Thoelke
Software Systems Architect | Arm
. . . . . . . . . . . . . . . . . . . . . . . . . . .
m. +44 7766 990101
Arm.com
Hi Kevin,
The separation between the secure and non-secure world is designed to
keep the code in the secure world as small as possible. I don't think
there'll ever be enough justification to include base64 encoding in the
secure world.
The current PSA crypto API was designed to be mostly simple wrappers
around calls to the secure world. We (Arm) are considering extending it
with some higher-level functions designed to remain in the normal world.
This would include key formats such as SubjectPublicKeyInfo, and PEM
encoding. I can't make any promises as to when or even if this will
happen. At the moment, all we have to offer is the existing mbedtls
functions.
--
Gilles Peskine
Mbed TLS developer and PSA crypto API designer
P.S. When I'm working on Mbed TLS and using a shell prompt to calculate
or verify values (usually with openssl or python/cryptodome), I usually
use hex/binary conversion, and DER to encode asymmetric keys.
On 14/05/2020 13:56, Kevin Townsend via psa-crypto wrote:
> Hi,
>
> Working on some cryptography demos for Zephyr, now that TF-M support
> was fully merged in for the upcoming 2.3 release, I've put some test
> code together that:
>
> - Generates a permanent persistent key (prime256v1)
> - Displays the public key based on the private key above (in hex format)
> - Calculates the SHA256 hash of a payload
> - Signs the hash with the persistent key
> - Verifies the signature using the public key
> - Destroys the key
>
> https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05
>
> An important part of the hash/sign/verify workflow is of course
> verifying the signature on the receiving end, which requires access to
> the public key generated on the device (perhaps a new key was randomly
> generated when the device first boots, etc.).
>
> We can currently derive the public key in DER format with the existing
> API, but it seems like a helper function to convert to PEM would make
> this export process easier, since you could then just copy and paste
> the text output directly for provisioning or debug purposes.
> mbedcrypto 3.1.0 already has a library/pem.c utility function for this
> that could be exposed: mbedtls_pem_write_buffer
>
> In general, I think enabling the import and export of PEM data, not
> just DER, would make the process of dealing with keys during
> provisioning easier.
>
> I didn't find any references to PEM in the PSA Cryptography API, but
> perhaps I'm missing some obvious already existing means to convert to
> PEM, or is this something other people see any value in having?
>
> Being able to copy and paste PEM data (versus DER which can't be
> copy/pasted), then save it as a file, for example, would make working
> with openssl easier, such as the commands described here where we
> could use the extracted PEM data to verify the signed data from the
> command line:
> https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-…
>
> Any thoughts on the idea, or perhaps it's already been added and I'm
> simply missing it?
>
> It's easy to add this at the NS application level as well, of course,
> but it does seem like a useful enough operation that it should be
> available in S world when requesting key data.
>
> Best regards,
> Kevin Townsend
>
Hi,
Working on some cryptography demos for Zephyr, now that TF-M support was
fully merged in for the upcoming 2.3 release, I've put some test code
together that:
- Generates a permanent persistent key (prime256v1)
- Displays the public key based on the private key above (in hex format)
- Calculates the SHA256 hash of a payload
- Signs the hash with the persistent key
- Verifies the signature using the public key
- Destroys the key
https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05
An important part of the hash/sign/verify workflow is of course verifying
the signature on the receiving end, which requires access to the public key
generated on the device (perhaps a new key was randomly generated when the
device first boots, etc.).
We can currently derive the public key in DER format with the existing API,
but it seems like a helper function to convert to PEM would make this
export process easier, since you could then just copy and paste the text
output directly for provisioning or debug purposes. mbedcrypto 3.1.0
already has a library/pem.c utility function for this that could be
exposed: mbedtls_pem_write_buffer
In general, I think enabling the import and export of PEM data, not just
DER, would make the process of dealing with keys during provisioning easier.
I didn't find any references to PEM in the PSA Cryptography API, but
perhaps I'm missing some obvious already existing means to convert to PEM,
or is this something other people see any value in having?
Being able to copy and paste PEM data (versus DER which can't be
copy/pasted), then save it as a file, for example, would make working with
openssl easier, such as the commands described here where we could use the
extracted PEM data to verify the signed data from the command line:
https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-…
Any thoughts on the idea, or perhaps it's already been added and I'm simply
missing it?
It's easy to add this at the NS application level as well, of course, but
it does seem like a useful enough operation that it should be available in
S world when requesting key data.
Best regards,
Kevin Townsend
Hi Matt,
TF-M plans to continue using Mbedcrypto in the crypto service. Mbed Crypto implements the PSA Crypto APIs and is also now part of trustedfirmware.org community project alongside TF-M.
However, it is possible with some effort for a platform using TF-M to use another crypto library in the TF-M crypto service. Of course the library will need to support PSA Crypto APIs to be PSA compliant.
There is support for ARIA, Camellia in Mbed TLS. There has already been a PR for SM4 support sometime back - https://github.com/ARMmbed/mbedtls/pull/1165. SM2/SM3 algorithm support
can be contributed to MbedTLS project (Mbed Crypto is now merged to Mbed TLS project). The maintainers will have to review and integrate the contribution as their bandwidth permits
while finding time to review several contributions that the project is receiving.
I am adding psa-crypto mailing list which is used for Mbedcrypto/PSA Crypto discussions.
Regards,
Shebu
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt via TF-M
Sent: Thursday, April 16, 2020 8:24 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Will TFM crypto service suppot national encryption algorithm in the future?
Hi All TFM experts,
TFM crypto service is based on mbedcrypto and there is no national encryption algorithm support in current mbedcrypto implementation.
The Chinese market has a strong demand for national encryption algorithms, such as SM2/SM3/SM4, will TFM crypto service change to other crypto implementation to support the national encryption algorithm in the future?
Thanks,
-Matt