SPAKE2+ example (PSA library)

RE: SPAKE2+ example (PSA library)

dejans — Mon, 24 Feb 2025 09:29:09 GMT

Hi,

We mainly support Matter version of SPAKE2+ which is HMAC based. You could try to follow the logic in sdk-oberon-psa-crypto to change to CMAC-AES-128. For intermediate values, please note that PAKE is basically implementing APIs from PSA. You can look at this PSA API document.

Best regards,
Dejan

RE: SPAKE2+ example (PSA library)

dejans — Wed, 19 Feb 2025 09:44:13 GMT

Hi,

I will discuss your questions with our developers. I expect to get back to you by the end of the next week.

Best regards,
Dejan

RE: SPAKE2+ example (PSA library)

Portilha — Tue, 18 Feb 2025 10:17:07 GMT

I want to have something like this example:

Where the CMAC output (confirmP and confirmV) are both 16 bytes.

BR.

RE: SPAKE2+ example (PSA library)

Portilha — Mon, 17 Feb 2025 14:06:58 GMT

The second message exchange (different values for verifier and prover), before the final message that has the same K_shared. Also, I want to know if there is any way to adjust the example to use CMAC-AES-128.

BR.

RE: SPAKE2+ example (PSA library)

dejans — Mon, 17 Feb 2025 12:58:58 GMT

Hi,

[quote user="Portilha"]Next, I see that the following pair of messages consists of 32-byte messages. Could you clarify what exactly these intermediate messages represent?[/quote]

Which intermediate messages and 32-byte messages do you refer to?

Best regards,
Dejan

RE: SPAKE2+ example (PSA library)

Portilha — Mon, 17 Feb 2025 09:57:41 GMT

Hello,

Thank you for your response.

Does your example follow the RFC 9383 specification? In your example, the first two exchanged messages are both 65-byte messages (0x04 followed by 64 bytes), which I assume represent the X and Y coordinates - each 32 bytes. These first two messages should correspond to:

X = x * P + w₀ * M
Y = y * P + w₀ * N

Next, I see that the following pair of messages consists of 32-byte messages. Could you clarify what exactly these intermediate messages represent? I understand that both parties need to compute the shared secret curve points (Z and V) and then derive a shared secret from these points, but I’m unsure of the role of these intermediate messages.

Finally, the last set of messages should serve as confirmation or "evidence" that both parties possess the password and that the process was successful. In your example, this confirmation message is also 32 bytes long, but I was expecting (and require) a 16-byte message instead. Would it be possible to adjust this? Specifically, I need to use the last configuration from the table in the provided link:
G: P-256 and CMAC-AES-128 (I need CMAC instead of HMAC) to obtain a 16-byte confirmation value.

I appreciate your guidance on this.

Best regards.

RE: SPAKE2+ example (PSA library)

dejans — Mon, 17 Feb 2025 08:46:46 GMT

Hi,

Our PSA Crypto API Implementation implements the PSA Crypto API specification. You could consider opening discussion on specification there.

Here is relevant discussion on the use of public key.

Best regards,
Dejan

RE: SPAKE2+ example (PSA library)

Emil Lenngren — Fri, 14 Feb 2025 23:32:41 GMT

The SPAKE2+ algorithm itself does not operate on a password, but rather an already hashed password; where the first half of the hash is denoted w0 and the second half w1.

Typically, a nordic chip acts as the verifier and a smartphone/tablet/computer acts as the prover (typically with a user interface with a password field or qr code camera). The cpu at the prover is powerful enough to perform a slow hash operation such as scrypt or Argon2. The verifier only stores a pre-hashed verifier entry and thus does not perform any hashing. Therefore, you will not see any API function taking a password.

The API takes w0 concatenated by w1*P for the verifier instead of a password. The idea is to pre-hash this value on a different device and then transfer this data over to the verifier device and store it on flash. I suggest that you read RFC9383 to get familiar how the mechanism works.

The example code as well as the PSA API unfortunately calls the verifier "public_key". This is certainly not a public key but the password hash and should hence not be leaked, since an attacker in the possession of this can perform a brute force attack to recover the password. Remember that SPAKE2+ is designed to operate on passwords with low entropy.

RE: SPAKE2+ example (PSA library)

dejans — Fri, 14 Feb 2025 19:25:31 GMT

Hi,

RFC9383, mentions that w0 and w1 are obtained by hashing the password with identities of the participants. In the crypto spake2+ sample, you can see that w0||w1 is given in the key_pair[]. Some additional information about PAKE can be found in v2.7.0\modules\crypto\oberon-psa-crypto\include\psa\crypto_types.h and in v2.7.0\modules\crypto\oberon-psa-crypto\include\psa\crypto_extra.h. You can also look at ocrypto_spake2p_p256.h.

Best regards,
Dejan