Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is tomorrow (Monday) at 4:30 PM UK time.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi,
We have some feedback to the proposed PSA PAKE interface, see below.
Regards
Beat
Reference: "PSA Cryptography API 1.1 PAKE Extension" 10/02/2022.
https://armmbed.github.io/mbed-crypto/1.1_PAKE_Extension.0-bet.0/psa_crypto…
Issue 1
It is impossible to derive multiple keys from the common secret.
The suggested PAKE interface passes the resulting raw common secret directly to a key derivation operation. This is good to avoid direct usage of the secret but it makes it impossible to derive more than one key from the secret because the key derivation operation can only be used once. Deriving multiple keys is mandatory for some protocols for instance to get a session key for the rest of the pairing phase and in addition a long term key to establish further sessions.
It would be better to return the raw secret as a key which can only be used as input to a key derivation operation. This would be easy to use and allows for multiple derived keys.
The same problem exists for the key agreement interface which is also directly coupled to a key derivation operation. Again there exists protocols where multiple keys are needed, for instance one for outgoing and one for incoming messages. In the case of key agreement, the psa_raw_key_agreement() function can often be used as a workaround but returning a derivation only key instead of the coupling to a key derivation operation would be a more general and cleaner solution.
Issue 2
The suggested interface cannot be implemented in an opaque driver.
Opaque drivers are selected based on the key attributes provided. For a multi part operation the driver has to be selected by the first function called. For PAKE this is psa_pake_setup(). However, no key is passed to this function. The only key involved is passed to the psa_pake_set_password_key() function which is called later and cannot be used for driver selection because the driver cannot be changed during a multi part operation.
Unfortunately, the problem is not easy to solve. A change in the interface of the psa_pake_setup() function would work fine in most cases:
psa_status_t psa_pake_setup(
psa_pake_operation_t *operation,
const psa_pake_cipher_suite_t *cipher_suite,
psa_key_id_t password,
const uint8_t *user_id, size_t user_id_len,
const uint8_t *peer_id, size_t peer_id_len,
psa_pake_role_t role);
(role, user_id, and peer_id are included because they are often needed to interpret the password value).
However, for some protocols the password hash cannot be calculated before some data is exchanged. In a variant of SRP-6 for instance the client first sends its public key to the server, the server then responds with the password salt and its own public key. The client therefore needs to calculate the public key before it receives the salt needed to calculate the password hash.
Issue 3
Missing support for 'out of band' setup calculations.
The suggested PAKE interface deliberately does not contain functions for setup calculation not directly involved in the PAKE protocol. This might be a good idea to keep things simple and easy to use. However, there must be a way to do calculations like the password hash somehow. Otherwise the whole PAKE interface turns out to be useless in many situations. In most PAKE protocols a password hash or password verifier is not just a hash but needs field or group calculations related to the main PAKE operation. To allow an implementation of all parts of a PAKE key exchange without relying on a second crypto library, it is mandatory to provide these functions somehow in PSA, in special PAKE functions or in another interface.
Issue 4
PAKE SIZE macros need more arguments.
The PAKE input and output size macro are defined with the argument list (alg, primitive, output_step). However, some input/output values depend on the digest size of the selected hash algorithm. This holds for instance for a SPAKE2+ confirmation key or the SRP client/server proofs.
It is therefore mandatory to include either the hash algorithm or the hash size in the argument list of the two macros.
Hello,
TF-M's mbedTLS roadmap mentions supporting PSA Crypto API v1.0 - https://developer.trustedfirmware.org/w/mbed-tls/roadmap/
The latest version of PSA Crypto API corresponds to v1.1. Will that be supported by TF-M (and mbed TLS)?
Regards,
Archanaa
This event has been cancelled.
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: United Kingdom Time
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
* santosdanillo(a)gmail.com
* schoenle.thomas(a)googlemail.com
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 organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding