- psa-crypto - lists.trustedfirmware.org

Updated invitation: MBed TLS Technical Forum @ Every 4 weeks from 9:30am to 10:30am on Monday 17 times (MST) (psa-crypto@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been changed. Title: MBed TLS Technical Forum Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum Time: Oct 25, 2021 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Oct 25, 2021 04:30 PM Nov 22, 2021 04:30 PM Dec 20, 2021 04:30 PM Jan 17, 2022 04:30 PM Feb 14, 2022 04:30 PM Mar 14, 2022 04:30 PM Apr 11, 2022 04:30 PM May 9, 2022 04:30 PM Jun 6, 2022 04:30 PM Jul 4, 2022 04:30 PM Aug 1, 2022 04:30 PM Aug 29, 2022 04:30 PM Sep 26, 2022 04:30 PM Oct 24, 2022 04:30 PM Nov 21, 2022 04:30 PM Dec 19, 2022 04:30 PM Jan 16, 2023 04:30 PM Feb 13, 2023 04:30 PM Mar 13, 2023 04:30 PM Apr 10, 2023 04:30 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT… Meeting ID: 959 6263 5632 Passcode: 018366 One tap mobile +13462487799,,95962635632# US (Houston) +16699009128,,95962635632# US (San Jose) Dial by your location +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 301 715 8592 US (Washington DC) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 959 6263 5632 Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y When: Every 4 weeks from 9:30am to 10:30am on Monday 17 times Mountain Standard Time - Phoenix Calendar: psa-crypto(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWdhMWpuZ2ZpdWNp… Invitation from Google Calendar: https://calendar.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://calendar.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, 5 months

1
0
0 0

Invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 3am to 3:50am on Monday 17 times (MST) (psa-crypto@lists.trustedfirmware.org)

by don.harbin＠linaro.org

You have been invited to the following event. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 3am to 3:50am on Monday 17 times Mountain Standard Time - Phoenix Joining info: Join with Google Meet https://meet.google.com/fwh-srqw-rgf?hs=224 Join by phone (US) +1 304-397-0314 (PIN: 358348986) More phone numbers: https://tel.meet/fwh-srqw-rgf?pin=6539665554630&hs=0 Calendar: psa-crypto(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.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://calendar.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, 5 months

1
0
0 0

Invitation: MBed TLS Technical Forum @ Every 4 weeks from 9:30am to 10:30am on Monday 17 times (MST) (psa-crypto@lists.trustedfirmware.org)

by don.harbin＠linaro.org

You have been invited to the following event. Title: MBed TLS Technical Forum Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum Time: Oct 25, 2021 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Oct 25, 2021 04:30 PM Nov 22, 2021 04:30 PM Dec 20, 2021 04:30 PM Jan 17, 2022 04:30 PM Feb 14, 2022 04:30 PM Mar 14, 2022 04:30 PM Apr 11, 2022 04:30 PM May 9, 2022 04:30 PM Jun 6, 2022 04:30 PM Jul 4, 2022 04:30 PM Aug 1, 2022 04:30 PM Aug 29, 2022 04:30 PM Sep 26, 2022 04:30 PM Oct 24, 2022 04:30 PM Nov 21, 2022 04:30 PM Dec 19, 2022 04:30 PM Jan 16, 2023 04:30 PM Feb 13, 2023 04:30 PM Mar 13, 2023 04:30 PM Apr 10, 2023 04:30 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT… Meeting ID: 959 6263 5632 Passcode: 018366 One tap mobile +13462487799,,95962635632# US (Houston) +16699009128,,95962635632# US (San Jose) Dial by your location +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 301 715 8592 US (Washington DC) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 959 6263 5632 Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y When: Every 4 weeks from 9:30am to 10:30am on Monday 17 times Mountain Standard Time - Phoenix Joining info: Join with Google Meet https://meet.google.com/ofy-jxph-boy?hs=224 Join by phone (US) +1 704-705-7047 (PIN: 141276187) More phone numbers: https://tel.meet/ofy-jxph-boy?pin=3695767709143&hs=0 Calendar: psa-crypto(a)lists.trustedfirmware.org Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWdhMWpuZ2ZpdWNp… Invitation from Google Calendar: https://calendar.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://calendar.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, 5 months

1
0
0 0

Adding lists to the MBed TLS Tech Forum invite

by Don Harbin

Hi All, FYI, per Shebu, I'm adding both mbed-tls(a)lists.trustedfirmware.org and psa-crypto(a)lists.trustedfirmware.org to the MBed TLS Tech Forum invites. Please look for this in your inbox and accept it if you would like the series added to your calendar. - Note that this is a monthly meeting but you will see two invites, one that is for Asia timezones and one for Europe/US. Just delete the series that isn't timezone friendly for you. - FYI, recall that this and other tech forums can be found in the meeting calendar on the TF website <https://www.trustedfirmware.org/meetings/>. If you see a meeting in that calendar, click on the entry and an option comes up saying "copy to my calendar." It will import that single instance into your personal calendar from there if you wish. I wasn't able to test this feature with outlook, but it worked fine for google calendar. Please let me know if you have any questions. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

4 years, 5 months

1
0
0 0

PSA Key Attestation APIs

by Cedric Neveux

Hello, Working on a Secure SW architecture requiring to support key attestation, I would like to know if there is a plan to add APIs to do Asymmetric key attestation in the same manner there are API to attest a token? We would like to propose the following APIs: Calculate the size of a Key Attestation buffer. psa_status_t psa_attest_key_get_size(psa_key_id_t key, size_t auth_challenge_size, size_t *cert_size) Retrieve the Key Attestation buffer. psa_status_t psa_attest_key(psa_key_id_t key, const uint8_t *auth_challenge, size_t auth_challenge_size, uint8_t *cert_buf, size_t cert_buf_size, size_t *cert_size) Concerning the certificate buffer, we are thinking about a TLV format containing metadata + public key buffer + signature but in order to standardize these APIs like the PSA initial attestation token, we are open to any advice. Do you think that adding it in the Attestation API standard is possible or do we have to add it as custom API? Thanks and Regards, Cedric Neveux

4 years, 8 months

3
2
0 0

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 >

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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

5 years, 6 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

psa-crypto