ARM PSA crypto 1.4.0: Implement WPA3-SAE support #709

New issue

Open

opened 2026-03-11 04:34:45 -05:00 by krish2718 · 2 comments

krish2718 commented

2026-03-11 04:34:45 -05:00

(Migrated from github.com)

Suggested enhancement

Implement support for WPA3-SAE recently added to ARM PSA Crypto API in 1.4.0: https://arm-software.github.io/psa-api/crypto/1.4/appendix/history.html#:~:text=Added%20support%20for%20the%20WPA3%2DSAE%20PAKE%3A

Also from: https://github.com/Mbed-TLS/mbedtls-docs/blob/main/project/20251125-psa-spec-vs-implementation.pdf

Justification

Mbed TLS needs this because WPA3-SAE is widely used in Wi-Fi and in fact becoming de-facto security standard. So, its essential that MbedTLS implements this PSA crypto API. Any Embedded IoT vendor including the ZephyrRTOS project that uses Wi-Fi will need this, multiple vendors like Nordic, NXP are interested in this feature.

### Suggested enhancement Implement support for WPA3-SAE recently added to ARM PSA Crypto API in 1.4.0: https://arm-software.github.io/psa-api/crypto/1.4/appendix/history.html#:~:text=Added%20support%20for%20the%20WPA3%2DSAE%20PAKE%3A Also from: https://github.com/Mbed-TLS/mbedtls-docs/blob/main/project/20251125-psa-spec-vs-implementation.pdf <img width="594" height="103" alt="Image" src="https://github.com/user-attachments/assets/d7534314-49eb-43fe-8bf5-46633ea96e8a" /> ### Justification Mbed TLS needs this because WPA3-SAE is widely used in Wi-Fi and in fact becoming de-facto security standard. So, its essential that MbedTLS implements this PSA crypto API. Any Embedded IoT vendor including the ZephyrRTOS project that uses Wi-Fi will need this, multiple vendors like Nordic, NXP are interested in this feature.

👍 3

MaochenWang1 commented

2026-03-12 22:28:13 -05:00

(Migrated from github.com)

+1 from NXP.
WPA3-SAE support in PSA Crypto API is important for our wireless connectivity product portfolio. We would appreciate seeing this feature implemented in the TF-PSA-Crypto library.

+1 from NXP. WPA3-SAE support in PSA Crypto API is important for our wireless connectivity product portfolio. We would appreciate seeing this feature implemented in the TF-PSA-Crypto library.

krish2718 commented

2026-07-12 15:40:01 -05:00

(Migrated from github.com)

I've opened #837 with a Phase 0 design proposal for WPA3-SAE
(docs/proposed/wpa3-sae.md) — a design note only, no implementation
code, so we can agree the approach before any code is written.

Scope: hash-to-element only; ECC groups 19/20/21; FFDH via
PSA_DH_FAMILY_RFC3526; the FIXED and GDH variants and the
WPA3_SAE_H2E KDF. Protocol-level concerns (anti-clogging, group
negotiation, SAE-PK, mesh) are out of scope — they belong in the Wi-Fi stack.
The note also covers the 1.4 API surface (with spec citations), the new
primitives required (RFC 9380 hash-to-curve, a constant-time modular square
root, the SAE engine), a per-step constant-time strategy, a test plan, and a
proposed P1–P5 PR phasing.

I'd especially value maintainer input on three questions before proceeding:

FFDH group set — the 1.4 spec only defines PSA_DH_FAMILY_RFC3526
(IANA groups 15–18) for SAE FFDH tokens. Is that the intended set?
Looping variant — I propose not implementing it (no constant-time
PWE; H2E supersedes it) and returning PSA_ERROR_NOT_SUPPORTED. OK?
Built-in vs driver-only — I propose a full built-in implementation
(SPAKE2+ is currently API-encoding-only). Is that the preferred direction?

Separately, a few errata in the PSA 1.4 PAKE example code that I hit while
writing this are filed upstream as GlobalPlatform/psa-api#372.

I've opened #837 with a **Phase 0 design proposal** for WPA3-SAE (`docs/proposed/wpa3-sae.md`) — a design note only, no implementation code, so we can agree the approach before any code is written. **Scope**: hash-to-element only; ECC groups 19/20/21; FFDH via `PSA_DH_FAMILY_RFC3526`; the `FIXED` and `GDH` variants and the `WPA3_SAE_H2E` KDF. Protocol-level concerns (anti-clogging, group negotiation, SAE-PK, mesh) are out of scope — they belong in the Wi-Fi stack. The note also covers the 1.4 API surface (with spec citations), the new primitives required (RFC 9380 hash-to-curve, a constant-time modular square root, the SAE engine), a per-step constant-time strategy, a test plan, and a proposed P1–P5 PR phasing. I'd especially value maintainer input on three questions before proceeding: 1. **FFDH group set** — the 1.4 spec only defines `PSA_DH_FAMILY_RFC3526` (IANA groups 15–18) for SAE FFDH tokens. Is that the intended set? 2. **Looping variant** — I propose *not* implementing it (no constant-time PWE; H2E supersedes it) and returning `PSA_ERROR_NOT_SUPPORTED`. OK? 3. **Built-in vs driver-only** — I propose a full built-in implementation (SPAKE2+ is currently API-encoding-only). Is that the preferred direction? Separately, a few errata in the PSA 1.4 PAKE example code that I hit while writing this are filed upstream as GlobalPlatform/psa-api#372.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#709

No description provided.

Rows
Columns