]> VIT-AP University

adityamitra5102@gmail.com

VIT-AP University

chakkaravarthy.sibi@vitap.ac.in

VIT-AP University

ghoshanisha2002@gmail.com

VIT-AP University

priya.21phd7042@vitap.ac.in

PQC COSE WebAuthn ML-DSA CBOR Passwordless Phishing-resistant This document describes implementation of Passwordless authentication in Web Authentication (WebAuthn) using Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204.

Introduction This document describes how to use ML-DSA keys and signature as described in with .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Some examples in this specification are truncated with "..." for readability.

Background on Post-Quantum Cryptography This section describes a generic backround of Post-Quantum Cryptography, Web Authentication and Phishing Resistance. Post-Quantum Cryptography is defined to be a set of cryptographic algorithms that are not vulnerable against a malicious actor in possession of a large scale Quantum Computer. has described Module-Lattice-Based Digital Signature Algorithm which is not vulnerable to attacks involving a large-scale quantum computer.

Motivation for ML-DSA in WebAuthn With the wide range adoption of phishing-resistant passwordless authentication standard like Security Keys, Passkeys and Device attestation following the FIDO2 Specifications, the adopted cryptographic standards for authentication have been primarily ES256 (Elliptic Curve Digital Signature Algorithm with SHA-256) and RS256 (RSA with SHA-256) as defined in . Though most authenticators support other algorithms as well, the widely used default algorithms- ES256 and RS256 are deemed to be insecure against adversaries employing large-scale quantum computers. Hence, the adoption of ML-DSA for WebAuthn would be necessary to secure digital identities and accounts from such adversaries.

ML-DSA Integration in WebAuthn This section describes the implementation of WebAuthn with ML-DSA.

ML-DSA Key Representation in COSE describes CBOR Object Signing and Encryption (COSE) Serialization for ML-DSA. It is to be noted that the COSE representation of only 'Public key' or 'Verifying key' is used in WebAuthn. Hence, the COSE Representation of private keys are beyond the scope of this document. ML-DSA Signature Scheme is parameterized to support different security levels. In this document, the abbreviations of ML-DSA-44, ML-DSA-65 and ML-DSA-87 are used to refer to ML-DSA with the parameter choices given in Table 1 of FIPS-204. This document requests the registration of the ML-DSA algorithms in as mentioned in as : Name value Description ML-DSA-44 TBD (requested assignment -48) CBOR Object Signing Algorithm for ML-DSA-44 ML-DSA-65 TBD (requested assignment -49) CBOR Object Signing Algorithm for ML-DSA-65 ML-DSA-87 TBD (requested assignment -50) CBOR Object Signing Algorithm for ML-DSA-87 In accordance with the Algorithm Key Paid Type section of , when present in AKP Keys, the "pub" parameter has the following constraints: The "pub" parameter is the ML-DSA public key, as described in Section 5.3 of FIPS-204. The size of "pub", and the associated signature for each of these algorithms is defined in Table 2 of FIPS-204, and repeated here for convenience: Algorithm Private Key Public Key Signature Size ML-DSA-44 2560 1312 2420 ML-DSA-65 4032 1952 3309 ML-DSA-87 4896 2592 4627 These algorithms are used to produce signatures as described in Algorithm 2 of FIPS-204. Signatures are encoded as bytestrings using the algorithms defined in Section 7.2 of FIPS-204.

Signature Generation and Verification Signature generation is done in accordance with Section 5.2 of FIPS-204. Signature Verification is done in accordance with Section 5.3 of FIPS-204. If small keys or signature is needed, ML-DSA might not be the ideal option. Furthermore, in usage scenarios expecting swifter processing, ML-DSA-87 might not be the best option. Therefore, using ML-DSA-44 and ML-DSA-65 with WebAuthn is advised.

Authenticator Behavior This section describes how an authenticator, roaming or platform would implement ML-DSA. The authenticator MUST have a secure storage for storing cryptographic secrets which SHOULD NOT be able to export the secrets in an unauthorized manner.

Credential Creation

| | | | | | | | | | | | Challenge | | |<---------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Credential Creation Request | | |<-------------------------------+ | +----------------+ (Challenge) | | | Generate | | | | Keypair | | | | | | | | | | | | | | | +--------------->| | | | | | +----------------+ | | | Sign challenge | | | | | | | | | | | | | | | | | | | +--------------->| | | | | | | Assertion Response | | +------------------------------->| | | (Signed Challenge) | Assertion | | +--------------------------------------------->| | | | | | +--------------------+ | | | Verify | | | | | | | | | | | | | | | | | | | |<-------------------+ | | | | | +--------------------+ | | | Save public key | | | | | | | | | | | | | | | | | | | | | | | |<-------------------+ | | Authentication response | | |<---------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | ]]>

defines the credential creation API. This API takes a public key credential creation object, containing a cryptographic challenge, the Relying Party ID (RP ID), User details, and public key credential parameters. The public key credential parameters define the accepted algorithms. An example of public key credential creation object is:

The web application invokes the Navigator.credentials.create() function with the Public Key Credential Creation Object. The client web browser, or an application invokes the authenticator API defined in . The public key credential creation object is CBOR encoded and sent to the authenticator device over a chosen transport method which includes but is not limited to USB HID, BLE and NFC. An example of CBOR Encoded Public Key Credential Creation object is:

The authenticator MUST verify whether any credential mentioned in the list of "excludeCredentials" in the public key credential creation object is already present on the authenticator, and in such cases it will return the error code in accordance with . Further authenticator MUST perform all additional checks involving authenticator PIN, User presence, user verification etc in accordance with Section 5.1 of CTAP. The authenticator generates ML-DSA keypair in accordance with Section 5.1 of FIPS 204 and unique Key ID. The public key is COSE encoded following and is a part of the attestedCredentialData. After passing all checks in accordance with section 5.1 of CTAP, the authenticator SHOULD create the attestation statement. The authData is created in accordance with WebAuthn and CTAP specifications and the clientDataHash is appended to it. This is signed with the private key of the generated keypair. The attestation statement is generated in accordance with CTAP and WebAuthn. The ML-DSA private key is to be stored in accordance with the "Storage security and Key management" section of this document. The attestation statement is encoded in CBOR and returned to the client application via the same transport method.

Authentication Flow

| | | | | | | | | | | | Challenge | | |<---------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assertion Request | | |<-------------------------------+ | | (Challenge) | | +-------------+ | | |Sign | | | |Challenge | | | | | | | | | | | +------------>| | | | Assertion Response | | +------------------------------->| | | (Signed Challenge) | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assertion | | +--------------------------------------------->| | | | | | +--------------------+ | | | Verify | | | | | | | | | | | | | | | | | | | |<-------------------+ | | Authentication response | | |<---------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ]]>

defines the credential request API. This API takes a public key credential request object, containing a cryptographic challenge, the Relying Party ID (RP ID) and optionally a list of allowed credentials. An example of public key credential request object is:

The web application invokes the Navigator.credentials.get() function with the Public Key Credential Request Object. The client web browser, or an application invokes the authenticator API defined in . The public key credential request object is CBOR encoded and sent to the authenticator device over a chosen transport method which includes but is not limited to USB HID, BLE and NFC. If a list of allowedCredentials is present, the authenticator must discover credentials bound to the same RP ID which is present in the list. If no such credential is present, it will return the error code in accordance with . Further authenticator MUST perform all additional checks involving authenticator PIN, User presence, user verification etc in accordance with Section 5.2 of CTAP. The authenticator, on discovering a suitable credential for authentication SHOULD verify the algorithm. If it is not ML-DSA, the authenticator SHALL behave in accordance with the "Backward Compatibility Considerations" section of this document. The credential is retrieved in accordance with the "Storage security and Key management" section of this document. After passing all checks in accordance with section 5.2 of CTAP, the authenticator SHOULD create the assertion statement. The authData is created in accordance with WebAuthn and CTAP specifications and the clientDataHash is appended to it. This is signed with the decrypted ML-DSA private key. The assertion response is generated in accordance with CTAP and WebAuthn. The assertion response is encoded in CBOR and returned to the client application via the same transport method. All memory addresses used to handle the ML-DSA private key is immediately zeroized. The authenticator getNextAssertion() function specification is to be similarly implemented in accordance with .

Backward Compatibility Consideration The authenticator SHOULD choose the algorithm to be used in accordance with CTAP, and hence not choose ML-DSA if not supported by the RP.

Client and Platform Considerations This section describes the considerations about the Client and Platform.

COSE Algorithm Support in WebAuthn Clients The CTAP implementations on client, for example Windows Hello for Microsoft Windows based systems, iCloud Keychain for Apple systems, Google Password Manager, Dashlane, OnePassword and other browser based implementations for Linux SHOULD have support for ML-DSA Algorithms in accordance with COSE. Further, Platform Authenticators for such devices are RECOMMENDED to have support for ML-DSA Key Generation and signing in accordance with this document.

Handling large signatures and keys It is considered that the chosen transport methods including but not limited to USB HID, BLE and NFC are able to perform exchanges of the CBOR encoded data which may be often over 2000 bytes. The use of attestion certificates may increase the length even more.

Error Handling and Fallback mechanisms In case of errors involving ML-DSA key generation and signing, the authenticator may fallback to using ES256 or RS256 algoritms. In case of errors involving communication with the client, the authenticator may handle it in accordance with .

Attestation Considerations Using Post Quantum Crptography for creating attestation certificates for credentials implies the presence of additional ML-DSA signatures and public keys in the x.509 certificate, depending upon the attestation format, defined in the flow. A second ML-DSA-44 Signature size is around 2420 bytes and a public key is around 1312 bytes, and bigger for others. On the other hand, using a 7-bit sequence continuation packet numbers for CTAP-HID constrains it to have a maximum of 129 frames only. CTAP-HID frame can be of size 64 bytes at max. A makeCredential response with a valid attestation certificate would contain atleast 1312+2420+1312+2420=7464 bytes. The first frame has 7 bytes of header (4 byte channel identifier, 1 byte CMD, 2 bytes BCNT), while continuation frames have 5 bytes of header (4 bytes of channel identifier, 1 byte of sequence number). Further, the first frame will have one byte of status code. The makeCredential response will contain the authData. This further contains 32 bytes of RP ID Hash, 1 byte of flags, 4 bytes of sign count and variable length attestedCredential data. The attestedCredential data further contains 16 bytes of AAGUID, 2 bytes of credential ID length. The credential ID is to be atleast 16 bytes, followed by the public key. This covers a total of 8182 bytes, leaving only 74 bytes for CBOR encoding, and the full x.509 certificate, including fields like the version, subjects, certificate chain and so on. Further, when other algorithms like ML-DSA-65 or higher is used, the available bytes in CTAP-HID would not suffice for the attestation certificate.

WebAuthn Considerations Due to the attestation certificate size limitations, Web Authentication standard is requested to recognize an attestation format 'minimal'. The syntax of Minimal Attestation is defined by:

sig here is a signature over the authenticatorData and clientDataHash. The authenticator produces the sig by concatenating authenticatorData and clientDataHash, and signing the result using an attestation private key selected through an authenticator-specific mechanism. keyid is an Identifier that identifies the key used to sign. It is a 16-byte unique identifier.

Verification and FIDO MDS Database Considerations The FIDO MDS database is requested to maintain the set of Public Key/ Verifying key certificates, identifiable by the AAGUID and the KeyId together. The RP may verify the attestation signature with the public key identified by the AAGUID and KeyID from the FIDO MDS database. Enterprise based implementations or implementations requiring self-attestation without FIDO MDS database MAY maintain their on keystores instead of the FIDO MDS database.

Security Considerations The security considerations of applies to this specification as well. A detailed security analysis of ML-DSA is beyond the scope of this specification, see for additional details.

Resistance to Quantum Attacks See for details on resistance to quantum attacks.

Storage security and Key management It is to be noted that at the time of writing this draft, there is no suitable hardware security module (HSM), trusted platform module (TPM), Secure Element (SE), Trusted Execution Environment (TEE) with native support for ML-DSA. Hence, secure credential storage is a challenge. To overcome the same, the ML-DSA keys, also referred to as credentials, MUST be encrypted with Advanced Ecnryption Standard (AES), which is a Post Quantum Symmetric encryption algorithm in Galosis Counter Mode (GCM) with 256-bit keys. The AES Keys MUST be generated and stored in secure storage, which may include a HSM, TPM, SE or TEE. The ML-DSA Keys may be generated on the standard computing environment, outside the secure storage. The ML-DSA Credential MUST be encrypted by AES as described above before being written to the Flash memory or Disk. Conversely, the same MUST be decrypted by AES in the secure storage before being used. Any memory location, pointer or heap that has been used to handle the ML-DSA Credentials MUST be zeroized immediately after the operation is performed. This section is to be updated when suitable secure storage modules supporting ML-DSA becomes widely available.

Implementation Best Practices If the amount of space in the secure storage permits, each ML-DSA Private key is RECOMMENDED to be encrypted with unique AES keys. * Prior to storage, each ML-DSA private key is to be encrypted independently using a distinct AES encryption key. * To guarantee robust encryption, the AES key size must be at least AES-256. * To avoid unwanted access, encrypted keys ought to be kept in Hardware Security Modules (HSMs), Secure Elements (SEs), or Trusted Platform Modules (TPMs). * NIST SP 800-57 recommendations should be followed by key management to provide secure AES key lifecycle management (creation, storage, rotation, and disposal). * Only in a trusted execution environment (TEE) or secure enclave should the private key be decrypted in order to avoid memory leakage.

IANA Considerations

Additions to Existing Registries This document requests the registration of the ML-DSA entries to the COSE Algorithm Registry as mentioned in .

IANA Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. mesur.io Transmute Google IBM NXP This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. SECOM CO., LTD. University of Applied Sciences Bonn-Rhein-Sieg Transmute This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint," can be used to identify or select the corresponding key. AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described.

Acknowledgments We express our sincere gratitude to Dr. S. V. Kota Reddy, Vice Chancellor, VIT-AP University, for his unwavering support and encouragement throughout this research. We also extend our heartfelt thanks to Dr. Jagadish Chandra Mudiganti, Registrar, VIT-AP University, for facilitating a conducive research environment. Our appreciation goes to Dr. Hari Seetha, Director, Centre of Excellence, Artificial Intelligence and Robotics (AIR), VIT-AP University, for her invaluable guidance and insightful discussions that significantly contributed to this work. We also acknowledge Indominus Labs Private Limited and Digital Fortress Private Limited for their generous support, which played a crucial role in the successful execution of this research.