- psa-crypto - lists.trustedfirmware.org

Re: [psa-crypto] What are the rules for driver calls to the PSA crypto interface?

by Gilles Peskine

Hi Beat, This is still an open point in the design. It's clear that some back-and-forth is needed. An accelerator needing a source of randomness is a good example. In some cases, it's possible to have the core call a deterministic function in the driver, for example accelerated RSA-PSS can often be broken down into the RSA exponentiation (accelerated) and PSS padding (unaccelerated except maybe for the hash calculations, done by the core). This kind of scenario calls for additional entry points in the driver, which has the advantage of not requiring any control inversion. These additional entry points are evoked under “substitution points” in the specification draft. However, other cases cannot be done this way, for example if a driver needs a random generator to perform blinding. Other examples include an opaque driver using a local cipher to encrypt communication with a secure element over an insecure bus, or a driver loading an auxiliary firmware image and verifying its signature. These cases are varied enough that I think it must be possible for drivers to call any API function. But as you note this may cause reentrancy problems, so there should be some limitations. It's not clear to me at this stage what the limitations should be. For example, what rules would facilitate static bounds on stack usage? Can the rules be enforced cheaply at runtime, and are violations likely to be detected by unit tests? Can the rules realistically be validated by static analysis? The exact manner in which drivers might call core functions is also open. Are there additional auxiliary functions that the core should expose (for example, might a driver prefer to have the core expose rsa_pss_pad())? The functions that the driver sees are not necessarily the same that the functions that applications see (at the very least, they're different on platforms where applications run in their own memory space and PSA API calls are remote procedure calls, whereas drivers live in the crypto service's memory space). So they can't be guaranteed to have the same symbol name. Types like psa_key_id_t and psa_key_attributes_t may be different in applications and in drivers as well. I expect it's going to take a while to converge on all of these open questions. As the use cases are diverse, feedback is very welcome. -- Gilles Peskine PSA Crypto architect and Mbed TLS developer On 07/05/2021 10:55, Beat Heeb via psa-crypto wrote: > Hi, > > It is unclear whether drivers are allowed to call functions of the outer PSA crypto interface. > If this is allowed, strict rules are needed to avoid hard to find recursive invocation and reentrancy problems. > Such problems are not necessarily detected at development time because they may be caused by a combination of several drivers developed by different vendors. > The easiest and most secure way would be to prohibit such calls completely. > However, at least in one case they are unavoidable: > Several driver functions need a source of randomness to fill some random values (cipher_encrypt, RSA_PSS, non-deterministic ECDSA, ..). > Getting randomness is non-trivial and involves special hardware in most cases which is usually not accessible to any driver (in particular accelerators). > So drivers must be allowed to call at least psa_generate_random(). > The only alternative would be to split up all affected functions to separate randomness generation from cryptographic calculations. > Regards > Beat >

3 years, 11 months

1
0
0 0

What are the rules for driver calls to the PSA crypto interface?

by Beat Heeb

Hi, It is unclear whether drivers are allowed to call functions of the outer PSA crypto interface. If this is allowed, strict rules are needed to avoid hard to find recursive invocation and reentrancy problems. Such problems are not necessarily detected at development time because they may be caused by a combination of several drivers developed by different vendors. The easiest and most secure way would be to prohibit such calls completely. However, at least in one case they are unavoidable: Several driver functions need a source of randomness to fill some random values (cipher_encrypt, RSA_PSS, non-deterministic ECDSA, ..). Getting randomness is non-trivial and involves special hardware in most cases which is usually not accessible to any driver (in particular accelerators). So drivers must be allowed to call at least psa_generate_random(). The only alternative would be to split up all affected functions to separate randomness generation from cryptographic calculations. Regards Beat

3 years, 11 months

1
0
0 0

Re: [psa-crypto] Which checks are needed in a driver?

by Gilles Peskine

Hello, There is no security boundary between the crypto core and drivers, so you can assume that all pointers are valid (including the fact that they're non-null, except possibly for 0-size buffers). You can also assume that the multipart operations follow a valid sequence (setup-update-update...-finish, or whatever is suitable for the operation type), and that every operation is eventually finished or aborted. Do however keep in mind that different operations can be interspersed (setup(op1); setup(op2); update(op1); update(op2); ...). The validity of buffer sizes and cryptographic data is less clear-cut. It's definitely one of the areas that needs to be clarified before this specification reaches a final stage. In general, it's better if the core validates everything it can: it saves effort overall since there are far fewer core implementers than driver implementers, it allows the validation to be tested generically, it guarantees that the behavior is the same everywhere. However, there are also integration reasons to have the driver do validation. If the core is responsible for validation then yo can't have a driver for an algorithm that the core doesn't support, which is useful especially with secure elements. There's also some validation that benefits from acceleration, for example checking that the public key is a curve point before performing an ECDH operation. The driver specification should be explicit as to who checks what (we definitely must not end up with each side thinking that the other side will do it). But at this stage I don't know yet where the limit must be. Best regards, -- Gilles Peskine PSA crypto architect and Mbed TLS developer On 06/05/2021 13:39, Beat Heeb via psa-crypto wrote: > Hi, > > The Unified Driver Specification should state which precondition checks are needed in a driver function. > It would be redundant to do all validity checks in both the core and the drivers. > From the samples it seems to be safe to assume all pointer arguments are non-null. > What about sizes? > Is it safe to assume only valid key sizes are delivered to a driver? > (For instance only 192, 224, 256, 384 or 521 for PSA_ECC_CURVE_SECP_R1.) > Is it guaranteed that the key_length is always correct for the given bit size of the key? > (For instance key_length is always 32 for a 256 bit SECP_R1 secret key.) > What about the sequence of function calls for a multi-part interface? > Is a driver expected to check for out-of-sequence calls and return PSA_ERROR_BAD_STATE? > > Thanks for clarifications. > Regards > Beat Heeb

3 years, 11 months

1
0
0 0

Which checks are needed in a driver?

by Beat Heeb

Hi, The Unified Driver Specification should state which precondition checks are needed in a driver function. It would be redundant to do all validity checks in both the core and the drivers. >From the samples it seems to be safe to assume all pointer arguments are non-null. What about sizes? Is it safe to assume only valid key sizes are delivered to a driver? (For instance only 192, 224, 256, 384 or 521 for PSA_ECC_CURVE_SECP_R1.) Is it guaranteed that the key_length is always correct for the given bit size of the key? (For instance key_length is always 32 for a 256 bit SECP_R1 secret key.) What about the sequence of function calls for a multi-part interface? Is a driver expected to check for out-of-sequence calls and return PSA_ERROR_BAD_STATE? Thanks for clarifications. Regards Beat Heeb

3 years, 11 months

1
0
0 0

Proposed random generator driver interface

by Gilles Peskine

Hello, Arm is soliciting feedback on a proposed interface to random generator drivers for a PSA cryptography library or service. In a nutshell, this is the interface between portable code that implements cryptographic operations and keystore functionality, and drivers for hardware that provide an entropy source, acceleration of a random generation algorithm, or both. The current specification draft is attached to this email in markdown and HTML formats. Comments are welcome through the following venues: * Public email to the psa-crypto list at TrustedFirmware. * 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 would appreciate it if any major issues were raised before 31 January 2021. Best regards, -- Gilles Peskine Mbed TLS developer and PSA crypto architect

4 years, 4 months

1
0
0 0

Re: [psa-crypto] [mbed-tls] Questions about PSA Crypto API and mbed TLS

by Gilles Peskine

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

4 years, 5 months

1
0
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

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

4 years, 5 months

1
0
0 0

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, 6 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, 6 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, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

psa-crypto