- psa-crypto - lists.trustedfirmware.org

Invitation: Mbed TLS Virtual Workshop @ Tue Nov 3, 2020 7am - 11am (MST) (psa-crypto@lists.trustedfirmware.org)

by Don Harbin

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

4 years, 7 months

1
0
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

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-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

4 years, 8 months

1
0
0 0

A new configuration mechanism for PSA crypto in Mbed TLS

by Gilles Peskine

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)

4 years, 9 months

1
0
0 0

Re: [psa-crypto] Persistent key storage ownership/access

by Jamie Fox

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

4 years, 11 months

1
0
0 0

Feedback sought on a new PSA Crypto driver interface

by Gilles Peskine

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

5 years

1
0
0 0

Request for feedback on a defect/inefficiency in PSA Crypto API 1.0.0

by Andrew Thoelke

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

5 years

1
0
0 0

Re: [psa-crypto] PEM exports of public/private keys?

by Gilles Peskine

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 >

5 years, 1 month

1
0
0 0

PEM exports of public/private keys?

by 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

5 years, 1 month

1
0
0 0

Re: [psa-crypto] [TF-M] Will TFM crypto service suppot national encryption algorithm in the future?

by Shebu Varghese Kuriakose

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

5 years, 1 month

1
0
0 0

Mbed TLS/PSA Crypto Roadmap

by Shebu Varghese Kuriakose

Hi All, Here is the link to the roadmap for Mbed TLS and PSA Crypto in the coming quarters. https://developer.trustedfirmware.org/w/mbed-tls/roadmap/ If you are interested in collaborating on any of the roadmap features or other features in the project, please let your interest known via. the mailing lists. Note that the expected quarter when a feature will be completed is based on very rough estimates of the effort involved and therefore might change. Roadmap will be reviewed and updated at the start of every quarter depending on progress made in previous quarter. Thanks, Shebu (Mbed TLS, PSA Crypto Technology Manager, Arm)

5 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

psa-crypto