前言：第一階段 (理論與設計) 總結

本週，我們完成了專案的第一階段：技術理論研究與系統設計。此階段的目標是為後續的開發工作奠定堅實的基礎，確保所有團隊成員對核心協議、系統架構及安全模型有深入且一致的理解。

我們從「零信任 (Zero Trust)」的資安原則出發，確立了採用 FIDO/WebAuthn 作為核心認證機制的技術選型。在此基礎上，我們完成了以下關鍵工作：

1. 協議分析：深入解析了 WebAuthn 的註冊 (Attestation) 與驗證 (Assertion) 流程。
2. 架構定義：確定了系統的宏觀架構，包含客戶端 (Web/Flutter)、應用後端 (Firebase Functions) 和資料庫 (Firestore)。
3. 資料建模：設計了 Firestore 中 users 與 credentials 集合的詳細 Schema。
4. 安全審查：應用 STRIDE 模型對設計進行了初步的威脅分析。
5. 介面規格：產出了四個核心後端 API 的請求/回應規格。

本文旨在對第一週的技術成果進行系統性回顧與整理，作為進入第二階段（後端實作）前的最終校驗點。

章節一：第一週進度技術回顧

以下是每日進度的技術要點摘要：

• Day 01: 需求與動機

  • 背景：面對日益增長的網路釣魚威脅及合規性要求，「零信任」成為主流資安模型。
  • 結論：傳統密碼及部分 MFA 機制已無法滿足零信任對「強認證」的要求。FIDO/WebAuthn 作為業界標準，能有效抵抗釣魚攻擊，是實現此目標的理想方案。

• Day 02: 核心技術棧

  • 技術棧：FIDO2 包含 WebAuthn (W3C 標準化的 JavaScript API) 和 CTAP (客戶端與驗證器通訊協定)。
  • 運作原理：基於非對稱加密（公鑰密碼學）。私鑰被安全地儲存在使用者端的驗證器中，永不離開設備。伺服器端（RP）僅儲存公鑰，透過驗證數位簽章來確認使用者身分，徹底消除了伺服器端共享秘密（密碼）洩漏的風險。

• Day 03: 協議參與者與流程

  • 系統角色：信賴方 (Relying Party, RP)、驗證器 (Authenticator)、客戶端 (Client)。
  • 核心流程：定義了註冊 (Attestation) 和 驗證 (Assertion) 兩個標準化流程，作為所有互動的基礎。

• Day 04: 註冊流程 (Attestation) 深度解析

  • 後端職責：生成 PublicKeyCredentialCreationOptions 物件，其中包含用於防止重放攻擊的 challenge。
  • 驗證邏輯：在收到 AuthenticatorAttestationResponse 後，後端必須嚴格驗證 clientDataJSON 中的 challenge、origin，以及 authData 中的 rpIdHash 等多個欄位，以確保請求的完整性與合法性。

• Day 05: 驗證流程 (Assertion) 深度解析

  • 後端職責：生成 PublicKeyCredentialRequestOptions 物件。
  • 驗證邏輯：在收到 AuthenticatorAssertionResponse 後，使用預存的公鑰驗證簽章。關鍵步驟是驗證簽章計數器 (signCount)，必須確保新的計數值大於資料庫中記錄的值，以防禦憑證複製和重放攻擊。

• Day 06: 系統設計規格

  • 產出：完成了系統架構圖、Firestore Schema、STRIDE 威脅模型分析報告，以及註冊/驗證流程的 API 規格書，將所有理論研究轉化為可執行的開發藍圖。

章節二：關鍵詞彙表 (Glossary)

• Zero Trust (零信任): 一種資安模型，其核心原則是消除隱含信任，並在每次存取請求時都進行嚴格的身分驗證和授權。
• WebAuthn: 一個 W3C Web API 標準，允許伺服器應用程式使用公鑰密碼學進行使用者認證，而非傳統密碼。
• CTAP (Client to Authenticator Protocol): 用於客戶端平台（如作業系統、瀏覽器）與漫遊驗證器（如安全金鑰）之間通訊的協定。
• Relying Party (RP): 在 WebAuthn 流程中，指代需要對使用者進行身分驗證的伺服器應用程式。
• Authenticator: 負責生成金鑰對並執行數位簽章的實體，可以是平台內建的（如 Windows Hello）或漫遊的（如 YubiKey）。
• Challenge: 由 RP 生成的、高熵的隨機位元組序列，用於確保每次註冊或驗證操作的唯一性，以防止重放攻擊。
• Attestation: 註冊流程，驗證器向 RP 證明它已為特定 RP ID 生成了一個新的金鑰對。
• Assertion: 驗證流程，使用者透過驗證器向 RP 證明其擁有先前註冊的私鑰。
• signCount: 一個單調遞增的計數器，由驗證器維護並包含在每次驗證的簽章資料中，用於偵測和阻止憑證複製攻擊。

章節三：系統分層概念模型

為釐清各技術概念間的關係，可透過以下分層模型進行理解：

1. 第一層 (戰略層): 零信任 (Zero Trust) - 驅動專案的資安指導原則。
2. 第二層 (密碼學層): 公鑰密碼學 (Public-Key Cryptography) - 構成系統安全的底層技術基礎。
3. 第三層 (協議層): WebAuthn (API) + CTAP (通訊) - FIDO2 標準化的核心協議。
4. 第四層 (流程層): 註冊 (Attestation) & 驗證 (Assertion) - 由協議層定義的具體執行流程。
5. 第五層 (實現層): Firebase Functions (RP), Firestore (DB), Web/Flutter (Client) - 我們專案中用於實現上述各層的具體技術選型。

結論與下階段預告

第一週結束時，我們已產出一份完整且經過審查的系統設計規格。所有後續開發工作都將以此為依據，確保了專案方向的明確性與技術可行性。

下一階段（第二週）的目標是後端服務的實現。我們將進入開發週期，主要任務如下：

• 環境建置：初始化 Firebase 專案，設定 Firebase Functions 與 Firestore。
• API 開發：根據 Day 06 的 API 規格，使用 TypeScript 開發註冊與驗證流程的四個核心 HTTP 端點。
• 資料庫整合：實現 API 邏輯與 Firestore 資料庫的互動，包括使用者和憑證資料的寫入與讀取操作。

下週的工作將是將設計文檔轉化為實際、可運行的程式碼。