1. 引言
本文描述了在 Web Authentication (WebAuthn) 中實現無密碼認證（Passwordless authentication）的方法，該方法使用模塊格（Module-Lattice）為基礎的數字簽名標準（ML-DSA），即 FIPS 204 定義的后量子密碼學（PQC）數字簽名方案。
本文描述了如何將 [FIPS-204] 中描述的 ML-DSA 密鑰和簽名應用于 [WebAuthn]。
2. 后量子密碼學背景
本節描述了后量子密碼學（Post-Quantum Cryptography）、Web 認證（Web Authentication）及防釣魚機制（Phishing Resistance）的通用背景。后量子密碼學被定義為一組不易受到擁有大規模量子計算機的惡意攻擊者威脅的密碼算法。[FIPS-204] 描述了一種基于模塊格（Module-Lattice）的數字簽名算法，該算法不易受到涉及大規模量子計算機的攻擊。
2.1 在 WebAuthn 中使用 ML-DSA 的動機
隨著防釣魚的無密碼認證標準（如安全密鑰（Security Keys）、通行密鑰（Passkeys）和設備證明（Device attestation））根據 FIDO2 規范得到廣泛采用，用于認證的密碼標準主要為 ES256（橢圓曲線數字簽名算法與 SHA-256 組合）和 RS256（RSA 與 SHA-256 組合），這些標準定義于 [FIPS-186-5]。盡管大多數認證器也支持其他算法，但被廣泛使用的默認算法——ES256 和 RS256——被認為在面對使用大規模量子計算機的對手時是不安全的。
因此，在 WebAuthn 中采用 ML-DSA 對于保護數字身份和賬戶免受此類對手的攻擊是必要的。
3. ML-DSA 在 WebAuthn 中的集成
本節描述了基于 ML-DSA 的 WebAuthn 實現。
3.1 COSE 中的 ML-DSA 密鑰表示
[I-D.draft-ietf-cose-dilithium-05] 描述了用于 ML-DSA 的 CBOR 對象簽名與加密（COSE，CBOR Object Signing and Encryption）序列化。需要注意的是，WebAuthn 中僅使用 “公鑰” 或 “驗證密鑰” 的 COSE 表示。因此，私鑰的 COSE 表示超出了本文討論范圍。
ML-DSA 簽名方案通過參數化支持不同的安全級別。本文使用 ML-DSA-44、ML-DSA-65 和 ML-DSA-87 的縮寫，分別表示 FIPS-204 表 1 中給出的不同參數選擇下的 ML-DSA。
結合 [I-D.draft-ietf-cose-dilithium-05]，本文請求在 [IANA.cose] 中注冊以下算法：
| 名稱 | 值 | 描述 |
|---|---|---|
| ML-DSA-44 | TBD（請求分配 -48） | ML-DSA-44 的 CBOR 對象簽名算法 |
| ML-DSA-65 | TBD（請求分配 -49） | ML-DSA-65 的 CBOR 對象簽名算法 |
| ML-DSA-87 | TBD（請求分配 -50） | ML-DSA-87 的 CBOR 對象簽名算法 |
根據 [I-D.draft-ietf-cose-dilithium-05] 中算法密鑰對類型（Algorithm Key Paid Type）部分的說明，當出現在 AKP 密鑰中時，“pub” 參數具有以下約束：
- “pub” 參數是 ML-DSA 公鑰，如 FIPS-204 第 5.3 節所述。
這些算法的 “pub” 大小以及相關的簽名大小在 FIPS-204 表 2 中定義，為方便起見，這里再次列出：
| 算法 | 私鑰大小（字節） | 公鑰大小（字節） | 簽名大小（字節） |
|---|---|---|---|
| ML-DSA-44 | 2560 | 1312 | 2420 |
| ML-DSA-65 | 4032 | 1952 | 3309 |
| ML-DSA-87 | 4896 | 2592 | 4627 |
這些算法用于生成符合 FIPS-204 算法 2 描述的簽名。
簽名使用 FIPS-204 第 7.2 節定義的算法編碼為字節串。
3.2 簽名生成與驗證
簽名生成依據 FIPS-204 第 5.2 節執行，簽名驗證依據 FIPS-204 第 5.3 節執行。
如果需要較小的密鑰或簽名，ML-DSA 可能并非理想選擇。此外，在期望更快處理速度的使用場景下，ML-DSA-87 可能并非最佳選項。因此，建議在 WebAuthn 中使用 ML-DSA-44 和 ML-DSA-65。
4. 認證器行為
本節描述認證器（無論是漫游認證器還是平臺認證器）如何實現 ML-DSA。
認證器 必須 具有安全存儲，用于存儲加密機密，并且 不應 以未授權的方式導出這些機密。
4.1 憑證創建
+---------------+ +--------+ +-----------+| | | | | || Authenticator | | Client | | RP Server || | | | | |+-------+-------+ +---+----+ +-----+-----+| | || | || | || | || | Get Challenge || +--------------------------------------------->|| | || | || | || | Challenge || |<---------------------------------------------+| | || | || | || | || | || | || | || | || | || Credential Creation Request | ||<-------------------------------+ |
+----------------+ (Challenge) | |
| Generate | | |
| Keypair | | |
| | | |
| | | |
| | | |
+--------------->| | || | |
+----------------+ | |
| Sign challenge | | |
| | | |
| | | |
| | | |
| | | |
+--------------->| | || | || Assertion Response | |+------------------------------->| || (Signed Challenge) | Assertion || +--------------------------------------------->|| | || | +--------------------+| | | Verify || | | || | | || | | || | | || | |<-------------------+| | || | +--------------------+| | | Save public key || | | || | | || | | || | | || | | || | |<-------------------+| | Authentication response || |<---------------------------------------------+| | || | || | || | || | || | || | |
[WebAuthn] 定義了憑證創建 API。該 API 接收一個公鑰憑證創建對象，其中包含加密挑戰、依賴方 ID（RP ID，Relying Party ID）、用戶信息以及公鑰憑證參數。公鑰憑證參數定義了可接受的算法。
一個公鑰憑證創建對象的示例如下：
{ challenge: new Uint8Array([215, 150, 119, 213, 215, 247, 188, 15, 142, 10, 53, 135, 17, 205, 130, 133, 158, 32, 113, 0, 62, 67, 112, 191, 123, 180, 224, 151, 233, 114, 68, 225]), rp: { id: "example.com", name: "Example Corporation" }, user: { id: new Uint8Array([79, 252, 83, 72, 214, 7, 89, 26]), name: "johndoe", displayName: "John Doe", }, pubKeyCredParams: [{ type: "public-key", alg: -7 }, { type: "public-key", alg: -49 }],
}
Web 應用通過調用 Navigator.credentials.create() 函數并傳入公鑰憑證創建對象來發起憑證創建。客戶端 Web 瀏覽器或應用程序調用 KaTeX parse error: Expected 'EOF', got '#' at position 75: …ebauthn-00.html#?CTAP) 定義的認證器 API。
公鑰憑證創建對象會被 CBOR 編碼，并通過選定的傳輸方式（包括但不限于 USB HID、BLE 和 NFC）發送到認證器設備。
公鑰憑證創建對象的 CBOR 編碼示例如下：
h'A50158201637B26333915747DBDC6C630C0165405A64939AE8F6E4FC39414F853F702F1602A2626964696C6F63616C686F7374646E616D656B44656D6F2073657276657203A3626964504EC1D4219F294FB4A0BC0CD29D485AFC646E616D6566615F757365726B646973706C61794E616D6567412E20557365720481A263616C67382F64747970656A7075626C69632D6B657907A1627576F5'
認證器 必須 驗證公鑰憑證創建對象中 "excludeCredentials" 列表中提到的任何憑證是否已存在于認證器上。若已存在，則認證器應根據 [CTAP] 返回錯誤代碼。
此外，認證器 必須 執行涉及認證器 PIN、用戶存在性（User Presence）、用戶驗證（User Verification）等的所有附加檢查，符合 CTAP 第 5.1 節的規定。
當公鑰憑證參數中包含 alg -49 或 alg -48 時，認證器 應 分別使用 ML-DSA-65 或 ML-DSA-44 算法。
如果參數不存在，認證器 應 按照本文“向后兼容性考慮”部分的規定執行。
認證器根據 FIPS 204 第 5.1 節生成 ML-DSA 密鑰對及唯一的 Key ID。公鑰按照 [I-D.draft-ietf-cose-dilithium-05] 進行 COSE 編碼，并作為 attestedCredentialData 的一部分。
在按照 CTAP 第 5.1 節通過所有檢查后，認證器 應 生成認證聲明（attestation statement）。
authData 按照 WebAuthn 和 CTAP 規范創建，并附加 clientDataHash。然后使用生成的密鑰對的私鑰對其進行簽名。
認證聲明按照 CTAP 和 WebAuthn 生成。
ML-DSA 私鑰必須根據本文檔的“存儲安全和密鑰管理”部分進行存儲。
認證聲明采用 CBOR 編碼，并通過相同的傳輸方式返回給客戶端應用程序。
4.2 認證流程
+---------------+ +--------+ +-----------+| | | | | || Authenticator | | Client | | RP Server || | | | | |+-------+-------+ +---+----+ +-----+-----+| | || | || | || | || | Get Challenge || +--------------------------------------------->|| | || | || | || | Challenge || |<---------------------------------------------+| | || | || | || | || | || | || | || | || | || Assertion Request | ||<-------------------------------+ || (Challenge) | |
+-------------+ | |
|Sign | | |
|Challenge | | |
| | | |
| | | |
+------------>| | || Assertion Response | |+------------------------------->| || (Signed Challenge) | || | || | || | || | || | || | || | || | || | Assertion || +--------------------------------------------->|| | || | +--------------------+| | | Verify || | | || | | || | | || | | || | |<-------------------+| | Authentication response || |<---------------------------------------------+| | || | || | || | || | || | || | || | || | || | || | || | || | || | || | || | || | || | |
[WebAuthn] 定義了憑證請求 API。該 API 接收一個公鑰憑證請求對象，其中包含加密挑戰（cryptographic challenge）、依賴方 ID（RP ID），以及可選的允許憑證列表。
公鑰憑證請求對象示例如下：
{challenge: new Uint8Array([215, 150, 119, 213, 215, 247, 188, 15, 142, 10, 53, 135, 17, 205, 130, 133, 158, 32, 113, 0, 62, 67, 112, 191, 123, 180, 224, 151, 233, 114, 68, 225]),rpId: "example.com",
}
Web 應用通過 Navigator.credentials.get() 函數調用該公鑰憑證請求對象。
客戶端 Web 瀏覽器或應用程序調用 KaTeX parse error: Expected 'EOF', got '#' at position 75: …ebauthn-00.html#?CTAP) 中定義的認證器 API。
公鑰憑證請求對象會進行 CBOR 編碼，并通過所選的傳輸方式（包括但不限于 USB HID、BLE 和 NFC）發送至認證器設備。
如果提供了 allowedCredentials 列表，認證器 必須 查找綁定至相同 RP ID 的憑證，該憑證必須存在于列表中。若不存在此類憑證，認證器應根據 KaTeX parse error: Expected 'EOF', got '#' at position 75: …ebauthn-00.html#?CTAP) 返回錯誤代碼。
此外，認證器 必須 執行涉及認證器 PIN、用戶存在性（User Presence）、用戶驗證（User Verification）等的所有附加檢查，符合 CTAP 第 5.2 節的規定。
認證器在找到合適的憑證后 應 驗證其算法。
如果算法不是 ML-DSA，認證器 必須 按照本文檔“向后兼容性考慮”部分的規定執行。
憑證的檢索須符合本文檔“存儲安全與密鑰管理”部分的要求。
在通過 CTAP 第 5.2 節的所有檢查后，認證器 應 創建斷言（assertion）聲明。
authData 按照 WebAuthn 和 CTAP 規范創建，并將 clientDataHash 附加其后。
該數據使用解密后的 ML-DSA 私鑰簽名。
斷言響應（assertion response）按 CTAP 和 WebAuthn 規范生成。
斷言響應使用 CBOR 編碼，并通過相同的傳輸方式返回給客戶端應用。
所有用于處理 ML-DSA 私鑰的內存地址必須立即清零（zeroized）。
authenticator getNextAssertion() 函數的規范應根據 [CTAP] 進行類似實現。
4.3 向后兼容性考慮
如果依賴方（RP）不支持 ML-DSA，認證器 應 默認使用符合 FIPS-186-5 的 RS256 和 ES256 算法，
可通過檢查憑證創建過程中公共密鑰憑證參數字段（Public Key Credential Parameters）來驗證。
5. 客戶端與平臺考慮
本節描述客戶端和平臺的相關注意事項。
5.1 WebAuthn 客戶端中的 COSE 算法支持
客戶端的 CTAP 實現（如 Microsoft Windows 系統的 Windows Hello、Apple 系統的 iCloud 鑰匙串、Google Password Manager、Dashlane、OnePassword 以及其他基于瀏覽器的 Linux 實現） 應 根據 COSE 支持 ML-DSA 算法。
此外，推薦這些設備的平臺認證器支持 ML-DSA 密鑰生成和簽名，符合本文檔要求。
5.2 處理大尺寸簽名和密鑰
已考慮所選的傳輸方式（包括但不限于 USB HID、BLE 和 NFC）能夠傳輸 CBOR 編碼的數據，這些數據往往超過 2000 字節。
使用證明證書（attestation certificates）可能會進一步增加長度。
5.3 錯誤處理與回退機制
在涉及 ML-DSA 密鑰生成和簽名的錯誤情況下，認證器可以回退使用 ES256 或 RS256 算法。
在涉及與客戶端通信的錯誤情況下，認證器可根據 [CTAP] 進行處理。
6. 安全性考慮
[RFC9053] 的安全性考慮同樣適用于本規范。
ML-DSA 的詳細安全性分析超出本文范疇，更多細節參見 [FIPS-204]。
6.1 抗量子攻擊能力
有關抗量子攻擊能力的詳細信息，參見 [FIPS-204]。
6.2 存儲安全與密鑰管理
需要注意的是，在撰寫本文時，還沒有適用于 ML-DSA 的合適的硬件安全模塊（HSM）、可信平臺模塊（TPM）、安全元件（SE）或可信執行環境（TEE）能夠原生支持 ML-DSA。
因此，安全憑證存儲是一個挑戰。
為了解決這一問題，ML-DSA 密鑰（也稱憑證）必須使用高級加密標準（AES）進行加密，AES 是一種抗量子的對稱加密算法，采用 Galois/Counter 模式（GCM）并使用 256 位密鑰。
AES 密鑰必須在安全存儲中生成和存儲，該存儲可包括 HSM、TPM、SE 或 TEE。
ML-DSA 密鑰可以在標準計算環境（安全存儲之外）生成，但在寫入閃存或磁盤之前，必須使用上述 AES 加密進行加密。
相反，在使用前，必須在安全存儲中使用 AES 對其進行解密。
任何用于處理 ML-DSA 憑證的內存位置、指針或堆內存，在操作完成后必須立即清零。
當支持 ML-DSA 的安全存儲模塊廣泛可用時，本節將進行更新。
7.3 實現最佳實踐
如果安全存儲空間允許，建議每個 ML-DSA 私鑰使用唯一的 AES 密鑰加密：
- 存儲前，每個 ML-DSA 私鑰都應獨立使用不同的 AES 加密密鑰進行加密。
- 為確保強大的加密能力，AES 密鑰大小必須至少為 AES-256。
- 為防止未經授權的訪問，加密密鑰應保存在硬件安全模塊（HSM）、安全元件（SE）或可信平臺模塊（TPM）中。
- 密鑰管理應遵循 NIST SP 800-57 的建議，以提供安全的 AES 密鑰生命周期管理（創建、存儲、輪換和銷毀）。
- 私鑰僅應在可信執行環境（TEE）或安全隔離區中解密，以避免內存泄漏。
7. IANA 注意事項
7.1 現有注冊表的新增條目
結合 [I-D.draft-ietf-cose-dilithium-05]，
本文請求向 COSE 算法注冊表中注冊以下條目。
以下填寫完成的注冊模板根據 RFC9053 和 RFC9054 的說明提供。
7.1.1 待添加的算法
7.1.1.1 ML-DSA-44
- 名稱：ML-DSA-44
- 數值：待定（請求分配為 -48）
- 描述：ML-DSA-44 的 CBOR 對象簽名算法
- 能力：[kty]
- 參考文獻：RFC XXXX
- 推薦使用：是
7.1.1.2 ML-DSA-65
- 名稱：ML-DSA-65
- 數值：待定（請求分配為 -49）
- 描述：ML-DSA-65 的 CBOR 對象簽名算法
- 能力：[kty]
- 參考文獻：RFC XXXX
- 推薦使用：是
7.1.1.3 ML-DSA-87
- 名稱：ML-DSA-87
- 數值：待定（請求分配為 -50）
- 描述：ML-DSA-87 的 CBOR 對象簽名算法
- 能力：[kty]
- 參考文獻：RFC XXXX
- 推薦使用：是
7.1.2 新的 COSE 密鑰類型
請求 IANA 將以下條目添加到 COSE 密鑰類型注冊表中。以下為根據 RFC9053 提供的完整注冊模板。
7.1.2.1 AKP
- 名稱：AKP
- 數值：待定（請求分配為 7）
- 描述：用于算法密鑰對的 COSE 密鑰類型
- 能力：[kty(7)]
- 參考文獻：RFC XXXX
7.1.3 新的 COSE 密鑰類型參數
請求 IANA 將以下條目添加到 COSE 密鑰類型參數中。以下為根據 RFC9053 提供的完整注冊模板。
7.1.3.1 ML-DSA 公鑰
- 密鑰類型：待定（請求分配為 7）
- 名稱：pub
- 標簽：-1
- CBOR 類型：bstr
- 描述：公鑰
- 參考文獻：RFC XXXX
參考資料
[1] 2025年4月 ML-DSA for Web Authentication
)
![[AI8051U入門第十一步]W5500-服務端](http://pic.xiahunao.cn/[AI8051U入門第十一步]W5500-服務端)
