- psa-crypto - lists.trustedfirmware.org

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, 9 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

4 years, 11 months

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

4 years, 11 months

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 >

4 years, 11 months

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

4 years, 11 months

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
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

1
0
0 0

Welcome to PSA Crypto @ TrustedFirmware.org

by Dan Handley

Welcome to the PSA Crypto list @ TrustedFirmware.org! This mailing list is the primary channel for public discussion, questions and announcements about the PSA Crypto implementation at TrustedFirmware.org, which is currently part of the Mbed TLS project. Please use this where possible in preference to the GitHub issue tracker or private support channels. The GitHub issue tracker should still be used for raising bugs and enhancement requests (after first checking the issue doesn't already exist). For more general Mbed TLS project discussion, including about the non-PSA crypto functionality within Mbed TLS, please use mailto:mbed-tls@lists.trustedfirmware.org. Thanks and regards Dan.

5 years

1
0
0 0

Welcome to PSA Crypto @ TrustedFirmware.org

by Dan Handley

Welcome to the PSA Crypto list @ TrustedFirmware.org! This mailing list is the primary channel for public discussion, questions and announcements about the PSA Crypto implementation at TrustedFirmware.org, which is currently part of the Mbed TLS project. Please use this where possible in preference to the GitHub issue tracker or private support channels. The GitHub issue tracker should still be used for raising bugs and enhancement requests (after first checking the issue doesn't already exist). For more general Mbed TLS project discussion, including about the non-PSA crypto functionality within Mbed TLS, please use mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>. Thanks and regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years

1
0
0 0

2025

2024

2023

2022

2021

2020

psa-crypto