Change the PAKE output function to return a key #114

athoelke · 2023-10-30T21:11:30Z

Replace psa_pake_get_implicit_key() with psa_pake_get_shared_key()
Add key confirmation attribute to the PAKE cipher suite

Fixes #100
Fixes #86

athoelke · 2023-10-30T21:19:23Z

Some feedback would be very welcome from @silabs-Kusumit, @silabs-hannes, @oberon-sk, and @yanesca; given your involvement in the PAKE API development.

oberon-sk · 2023-10-31T11:33:11Z

Replace psa_pake_get_implicit_key() with psa_pake_get_shared_key()

Add key confirmation attribute to the PAKE cipher suite

lgtm

Should the entire secret be contained in a single key output, or can it be split across multiple output keys?

As far as we understand, the goal of this PR is to export a shared secret and defer any key derivation of one or multiple keys into subsequent calls independent from the PAKE APIs. Then, the entire secret needs to be exported.

Which position should the key attributes parameter take in psa_pake_get_shared_key()? - there is no ideal answer as the precedents in the API are not consistent.

The operation should always be the first parameter, we regard psa_key_derivation_output_key() as an outlier.

athoelke · 2023-10-31T12:12:54Z

Replace psa_pake_get_implicit_key() with psa_pake_get_shared_key()

Add key confirmation attribute to the PAKE cipher suite

lgtm

Thank you for your review

Should the entire secret be contained in a single key output, or can it be split across multiple output keys?

As far as we understand, the goal of this PR is to export a shared secret and defer any key derivation of one or multiple keys into subsequent calls independent from the PAKE APIs. Then, the entire secret needs to be exported.

The concern is whether there are protocols, or PAKEs that expect the output to be split into two or more pieces as keys. For example, the way that SPAKE2+-draft02 splits the output of Hash(TT) into Ka and Ke. Note that is not a use case we need to support, and Matter's use of SPAKE2+ only uses the entire confirmed PAKE output as a key derivation key.

Which position should the key attributes parameter take in psa_pake_get_shared_key()? - there is no ideal answer as the precedents in the API are not consistent.

The operation should always be the first parameter, we regard psa_key_derivation_output_key() as an outlier.

We have come to the same conclusion.

oberon-sk · 2023-10-31T12:42:02Z

The concern is whether there are protocols, or PAKEs that expect the output to be split into two or more pieces as keys. For example, the way that SPAKE2+-draft02 splits the output of Hash(TT) into Ka and Ke. Note that is not a use case we need to support, and Matter's use of SPAKE2+ only uses the entire confirmed PAKE output as a key derivation key.

We are not aware of a use case where this would be required either.

athoelke · 2023-10-31T13:14:01Z

What key types should we permit or deny? - it seems that this is not appropriate for extracting keys that can require a variable amount of keying material (e.g. any DES, FFDH key pairs, Weierstrass ECC key pairs, RSA key pairs)

We would like to make this 'derivation keys only' (similar to the psa_key_agreement() PR #101), but need confidence that there are no use cases where the output is used directly for encryption, key wrapping (might need block-cipher-key), or AES-CMAC-based key derivation (would need an AES key).

Should the default key confirmation be: 'unconfirmed', 'confirmed', or 'whatever the default is for the selected algorithm'?

Currently leaning towards a preference of 'confirmed' by default (following a 'secure by default' principle), which means that algorithms like J-PAKE, without a confirmation phase, would require the application to explicitly request an unconfirmed key.

athoelke · 2023-10-31T17:32:59Z

Added a missing update to the J-PAKE graphic, and reversed the definition of the key confirmation constants, so PSA_PAKE_CONFIRMED_KEY is now the default.

silabs-Kusumit · 2023-11-01T06:15:28Z

doc/ext-pake/api/pake.rst

-A PAKE algorithm uses a specific cryptographic primitive for key establishment, specified using a `PAKE primitive <pake-primitive>`. PAKE algorithms also require a cryptographic hash algorithm, which is agreed between the participants.
+Most PAKE algorithms have parameters that must be specified by the application. These parameters include:
+
+*   The cryptographic primitive used for for key establishment, specified using a `PAKE primitive <pake-primitive>`.


Sorry, I can't seem to see the problem. What am I missing?

The cryptographic primitive used for for key establishment

Small thing

Thank you! The hardest to see error in things you have written yourself....

silabs-Kusumit · 2023-11-01T06:23:04Z

Should the entire secret be contained in a single key output, or can it be split across multiple output keys?

If the key type of the output will be derivation only then multiple output keys are not needed.

Added a missing update to the J-PAKE graphic, and reversed the definition of the key confirmation constants, so PSA_PAKE_CONFIRMED_KEY is now the default.

lgtm

2. Related to (1): Do we need to provide something that evaluates the size of the shared key output?

If we are returning only a single output key then this may not be needed.

athoelke · 2023-11-01T10:33:57Z

What key types should we permit or deny? - it seems that this is not appropriate for extracting keys that can require a variable amount of keying material (e.g. any DES, FFDH key pairs, Weierstrass ECC key pairs, RSA key pairs)

Even if we expect that the output should be for derivation only: we should permit implementations to output AES keys (as long as they use all of the shared secret?), as we expect some implementations will provide AES-CMAC based KDFs (see #106).

yanesca · 2023-11-06T12:13:51Z

doc/ext-pake/api.db/psa/crypto-pake.h

-                                       psa_key_derivation_operation_t *output);
+psa_status_t psa_pake_get_shared_key(psa_pake_operation_t *operation,
+                                     const psa_key_attributes_t * attributes,
+                                     psa_key_id_t * key);


The situation here is very similar to the case of key agreement schemes. There we have two APIs: psa_raw_key_agreement() and psa_key_derivation_key_agreement(). Outputing a key derivation object achieves the same as the latter. Outputing a key instead is somewhere between the two: the Crypto API implementation doesn't have full control over the use of the output, but doesn't release the output to the user either.

Outputting a key derivation object has the advantage that the implementation knows about the PAKE when inputting the key to the derivation object and can prevent misuse better or even adjust serialisation format if needed. If the PAKE output is released as a key, the only information the implementation can rely on is the length.

Why do we need to switch to outputting a key?

Why do we need to switch to outputting a key?

See #86. Use cases that use separate derivations to create multiple keys from the output of the PAKE. The existing API cannot be used in such systems, and maintaining the existing API alongside a new one to return a key does not appear to deliver substantial benefit for the application or implementation.

The situation here is very similar to the case of key agreement schemes. There we have two APIs: psa_raw_key_agreement() and psa_key_derivation_key_agreement().

But see also the recent discussions: #85 and #101. One of the conclusions there is that with more time and review when v1.0 was published, psa_key_agreement() would probably be the only key agreement interface, enabling access (via export) to the raw material, but defaulting to keeping the output protected, for use in one (or more) KDF operations. This would also have reduced the algorithm identifier complexity created by combined key agreement and key derivation algorithms.

yanesca · 2023-11-10T15:07:28Z

Even if we expect that the output should be for derivation only: we should permit implementations to output AES keys (as long as they use all of the shared secret?), as we expect some implementations will provide AES-CMAC based KDFs (see #106).

I think we should permit implementations to output any type of key that we might need for key derivation. If I understand the proposal in #106 correctly, this would mean PSA_KEY_TYPE_DERIVE, PSA_KEY_TYPE_HMAC, PSA_KEY_TYPE_AES and for the last two the key policy would be set to PSA_ALG_SP800_108_COUNTER_HMAC and PSA_ALG_SP800_108_COUNTER_CMAC respectively.

yanesca · 2023-11-10T15:16:03Z

Should the entire secret be contained in a single key output, or can it be split across multiple output keys?

I think most of the PAKEs arrive at one shared secret and the output should be a single key. If a higher level protocol splits that before deriving keys, the partitioning of the key material should be part of the key derivation algorithm. For PAKEs that output several keys (like OPAQUE) we should either add a new API or require the application to call the key output function once more (and define which call produces which key), but we shouldn't output a concatenated key.

Related to (1): Do we need to provide something that evaluates the size of the shared key output?

If we put the output in a key, the caller doesn't need to know the size upfront and can get it from the key attributes later, so I don't think we need to provide anything extra here.

athoelke · 2023-11-10T18:50:28Z

I think most of the PAKEs arrive at one shared secret and the output should be a single key. If a higher level protocol splits that before deriving keys, the partitioning of the key material should be part of the key derivation algorithm.

That is also my opinion, all other things considered.

For PAKEs that output several keys (like OPAQUE) we should either add a new API or require the application to call the key output function once more (and define which call produces which key), but we shouldn't output a concatenated key.

If I understand you correctly, you suggest that for algorithms like OPAQUE, we might decide that the application must call psa_pake_get_shared_key() twice. However, the application does not control how the output is split between those two calls: that is a product of the algorithm itself; in contrast to the idea in (1) where the application could control the splitting of the PAKE output into multiple key objects.

athoelke · 2023-11-14T11:58:13Z

Rebased (following merge of #115), and updated the specification of key types that psa_pake_get_shared_key() can output (see 9d4f2c0).

Some PAKEs (e.g. J-PAKE) produce biased output, that is not suitable for use as an encryption key. Therefore:

Only require that PSA_KEY_TYPE_DERIVE and PSA_KEY_TYPE_HMAC (see Add support for KDFs based on SP 800-108 recommendations #123) are valid for all PAKE algorithms
Permit additional key types (block-cipher keys) for PAKE algorithms that produce a pseudo-random shared secret.

yanesca · 2023-11-21T16:08:02Z

doc/ext-pake/api/pake.rst

+        *   The key type is required.
+            All PAKE algorithms can output a key of type :code:`PSA_KEY_TYPE_DERIVE` or :code:`PSA_KEY_TYPE_HMAC`.
+            PAKE algorithms that produce a pseudo-random shared secret, can also output block-cipher key types, for example :code:`PSA_KEY_TYPE_AES`.
+


Is this empty line intentional?

In this case, I think not, it was probably an artefact of cut and pasting the text below the blank line.

yanesca

LGTM.

silabs-Kusumit · 2023-11-22T06:35:26Z

LGTM

* Replace psa_pake_get_implicit_key() with psa_pake_get_shared_key() * Add key confirmation attribute to the PAKE cipher suite

* The shared secret is always output as a single key * Removed the input key size, key size is determined by operation * Removed key-size helper macro as unnecessary

* Recognise that not all PAKE algorithms produce a secret that is suitable for use as an encryption key * Encourage the use of PAKE output as a key-derivation key

athoelke · 2023-11-29T18:55:45Z

Rebased and merged.

athoelke added enhancement New feature or request Crypto API Issue or PR related to the Cryptography API DO NOT MERGE labels Oct 30, 2023

athoelke added this to the Crypto API 1.2 PAKE Extension milestone Oct 30, 2023

athoelke requested a review from gilles-peskine-arm October 30, 2023 21:11

athoelke self-assigned this Oct 30, 2023

athoelke mentioned this pull request Oct 31, 2023

Overview of updates to the PAKE API #111

Closed

8 tasks

athoelke force-pushed the pake-get-shared-key branch from be944b0 to a14846d Compare October 31, 2023 17:46

silabs-Kusumit reviewed Nov 1, 2023

View reviewed changes

yanesca reviewed Nov 6, 2023

View reviewed changes

athoelke mentioned this pull request Nov 8, 2023

Add support for KDFs based on SP 800-108 recommendations #123

Merged

athoelke requested review from yanesca and silabs-Kusumit November 13, 2023 15:24

athoelke force-pushed the pake-get-shared-key branch from 70a3047 to 9d4f2c0 Compare November 14, 2023 11:53

athoelke removed the DO NOT MERGE label Nov 14, 2023

athoelke mentioned this pull request Nov 15, 2023

[DRAFT v1] Define the SPAKE2+ algorithms #126

Closed

yanesca reviewed Nov 21, 2023

View reviewed changes

yanesca approved these changes Nov 21, 2023

View reviewed changes

silabs-Kusumit approved these changes Nov 22, 2023

View reviewed changes

athoelke added 10 commits November 29, 2023 18:48

pake: change the key output function

ad7ef6a

* Replace psa_pake_get_implicit_key() with psa_pake_get_shared_key() * Add key confirmation attribute to the PAKE cipher suite

Update J-PAKE flow graphic

6478ed5

Reversed the definitions for PAKE key confirmation values

bcc76cf

Fix typo

311ae2c

Tidy up resolved issues.

79c0d7c

Removed uncertainty about behavior or psa_pake_get_shared_key()

ad84a2b

* The shared secret is always output as a single key * Removed the input key size, key size is determined by operation * Removed key-size helper macro as unnecessary

Removed redundant (legacy) paragraph

91e841b

Specify key types output by psa_pake_get_shared_key()

cdf041c

* Recognise that not all PAKE algorithms produce a secret that is suitable for use as an encryption key * Encourage the use of PAKE output as a key-derivation key

Remove unwanted blank line

afeddf7

Correct statement about cipher suite attributes

1be1896

athoelke force-pushed the pake-get-shared-key branch from 7b762a8 to 1be1896 Compare November 29, 2023 18:55

athoelke merged commit 80ea731 into ARM-software:main Nov 29, 2023

athoelke deleted the pake-get-shared-key branch November 29, 2023 18:55

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Change the PAKE output function to return a key #114

Change the PAKE output function to return a key #114

athoelke commented Oct 30, 2023 •

edited

Loading

athoelke commented Oct 30, 2023

oberon-sk commented Oct 31, 2023

athoelke commented Oct 31, 2023

oberon-sk commented Oct 31, 2023

athoelke commented Oct 31, 2023

athoelke commented Oct 31, 2023

silabs-Kusumit Nov 1, 2023

athoelke Nov 1, 2023

silabs-Kusumit Nov 1, 2023

athoelke Nov 1, 2023

silabs-Kusumit commented Nov 1, 2023

athoelke commented Nov 1, 2023

yanesca Nov 6, 2023

athoelke Nov 6, 2023

athoelke Nov 6, 2023

yanesca commented Nov 10, 2023

yanesca commented Nov 10, 2023

athoelke commented Nov 10, 2023

athoelke commented Nov 14, 2023

yanesca Nov 21, 2023

athoelke Nov 21, 2023

yanesca left a comment

silabs-Kusumit commented Nov 22, 2023

athoelke commented Nov 29, 2023

Change the PAKE output function to return a key #114

Change the PAKE output function to return a key #114

Conversation

athoelke commented Oct 30, 2023 • edited Loading

athoelke commented Oct 30, 2023

oberon-sk commented Oct 31, 2023

athoelke commented Oct 31, 2023

oberon-sk commented Oct 31, 2023

athoelke commented Oct 31, 2023

athoelke commented Oct 31, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

silabs-Kusumit commented Nov 1, 2023

athoelke commented Nov 1, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yanesca commented Nov 10, 2023

yanesca commented Nov 10, 2023

athoelke commented Nov 10, 2023

athoelke commented Nov 14, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yanesca left a comment

Choose a reason for hiding this comment

silabs-Kusumit commented Nov 22, 2023

athoelke commented Nov 29, 2023

athoelke commented Oct 30, 2023 •

edited

Loading