1. Introduction

1.1. About Platform Security Architecture

This document is one of a set of resources provided by Arm that can help organizations develop products that meet the security requirements of PSA Certified on Arm-based platforms. The PSA Certified scheme provides a framework and methodology that helps silicon manufacturers, system software providers and OEMs to develop more secure products. Arm resources that support PSA Certified range from threat models, standard architectures that simplify development and increase portability, and open-source partnerships that provide ready-to-use software. You can read more about PSA Certified here at www.psacertified.org and find more Arm resources here at developer.arm.com/platform-security-resources.

1.2. About the Crypto API PAKE Extension

This document defines an extension to the PSA Certified Crypto API [PSA-CRYPT] specification, to provide support for Password-authenticated key exchange (PAKE) protocols, and specifically for the J-PAKE and SPAKE2+ protocols.

This extension API is now classed as Final, and it will be integrated into a future version of [PSA-CRYPT].

This specification must be read and implemented in conjunction with [PSA-CRYPT]. All of the conventions, design considerations, and implementation considerations that are described in [PSA-CRYPT] apply to this specification.

Note

This version of the document includes Rationale commentary that provides background information relating to the API design. This enables the reader to understand the wider context and alternative approaches that have been considered.

1.3. Objectives for the PAKE Extension

1.3.1. Scheme review

There are a number of PAKE protocols in circulation, but none of them are used widely in practice, and they are very different in scope and mechanics. The API proposed for the Crypto API focuses on schemes that are most likely to be needed by users. A number of factors are used to identify important PAKE algorithms.

Wide deployment

Considering PAKE schemes with already wide deployment allows users with existing applications to migrate to the Crypto API. Currently there is only one scheme with non-negligible success in the industry: Secure Remote Password (SRP).

Requests

Some PAKE schemes have been requested by the community and need to be supported. Currently, these are:

  • SPAKE2+ — used in Matter Specification, Version 1.2 [MATTER]

  • J-PAKE (in particular the Elliptic Curve based variant, sometimes known as ECJPAKE) — used in Thread Specification 1.3.0 [THREAD].

Standardization

There are PAKE schemes that are being standardized and will be recommended for use in future protocols. To ensure that the API is future proof, we need to consider these. The CFRG recommends CPace and OPAQUE for use in IETF protocols. These are also recommended for use in TLS and IKE in the future.

Applications

Some of these schemes are used in popular protocols. This information confirms the choices already made and can help to extend the list in future:

PAKE scheme

Protocols

J-PAKE

TLS, THREAD v1

SPAKE2+

MATTER

SRP

TLS

OPAQUE

TLS, IKE

CPace

TLS, IKE

Dragonfly

WPA3 (Before including the Dragonblood attack should be considered as well.)

SPAKE

Kerberos 5 v1.17

PACE

IKEv2

AugPAKE

IKEv2

1.3.2. Scope of the PAKE Extension

The following PAKE schemes are considered in the Crypto API design:

Balanced

Augmented

J-PAKE

SPAKE2

CPace

SRP

SPAKE2+

OPAQUE

Scope of this specification

The current API proposal provides the general interface for PAKE algorithms, and the specific interface for J-PAKE and SPAKE2+.

Out of scope

PAKE protocols that do not fit into any of the above categories are not taken into consideration in the proposed API. Such schemes include:

PAKE scheme

Specification

AMP

IEEE 1363.2, ISO/IEC 11770-4

BSPEKE2

IEEE 1363.2

PAKZ

IEEE 1363.2

PPK

IEEE 1363.2

SPEKE

IEEE 1363.2

WSPEKE

IEEE 1363.2

SPEKE

IEEE 1363.2

PAK

IEEE 1363.2, X.1035, RFC 5683

EAP-PWD

RFC 5931

EAP-EKE

RFC 6124

IKE-PSK

RFC 6617

PACE for IKEv2

RFC 6631

AugPAKE for IKEv2

RFC 6628

PAR

IEEE 1363.2

SESPAKE

RFC 8133

ITU-T

X.1035

SPAKE1

Dragonfly

B-SPEKE

PKEX

EKE

Augmented-EKE

PAK-X

PAKE

The exception is SPAKE2, because of it is related to SPAKE2+.