SPECIFICATION

第 7 章安全與加密

7.1 安全模型

DTP 實作必須提供端對端加密。安全模型必須滿足以下不變量：

僅目標 iFay 實例必須能夠解密接收到的 Payload。
FayGer 執行階段環境不得在任何情況下存取明文資料。
中間網路節點不得讀取 Payload 明文。
DTP 實作不得自行管理加密金鑰。

7.2 加密範圍

加密範圍必須嚴格限定於 LogicalFrame 的 Payload。

7.2.1 必須加密的內容

以下資料必須加密：

LogicalFrame 的 payload 欄位（即 Fragment 的 data 欄位以及（若以 Frame 方式承載的）RequestFrame、ResponseFrame、ControlFrame 的內容）。

7.2.2 不得加密的內容

以下資料不得加密，必須以明文傳輸：

LogicalFrame 的 header（包括 protocolVersion、frameType、fragmentId、agreementId、originTimestamp、dagDependencies、encryptionMetadata、sequenceNumber）。

加密中繼資料本身不得加密，以使接收方能在解密前確定解密參數。

7.3 金鑰管理

7.3.1 金鑰來源

DTP 實作必須使用 CAP 預協商的金鑰。具體要求：

CAP 必須在連線建立階段完成身分驗證與金鑰交換。
DTP 實作必須使用 CAP 提供的 sessionKey 進行 Payload 加密/解密。
DTP 實作不得自行產生、協商或交換加密金鑰。

7.3.2 CAPContext 介面

DTP 實作必須透過以下介面接收 CAP 提供的上下文：

interface CAPContext {
  identity: string;
  sessionKey: Uint8Array;
  verified: boolean;
}

欄位	規範性要求
`identity`	必須為對端身分標識
`sessionKey`	必須為 CAP 協商出的會話金鑰的位元組序列
`verified`	必須反映 CAP 驗證狀態

7.3.3 CAP 前置條件

DTP 實作必須在開始資料傳輸前驗證 CAPContext：

如 verified === false，必須拒絕傳送任何資料訊框並返回 KEY_NOT_READY 錯誤（2002）。
如 sessionKey 為空或長度無效，必須返回 KEY_NOT_READY 錯誤。
協商訊框（Request_Frame、Response_Frame）的傳輸同樣受此前置條件約束。

7.4 加密中繼資料

每個 LogicalFrame 的訊框標頭必須攜帶 EncryptionMetadata：

interface EncryptionMetadata {
  algorithm: string;
  keyVersion: number;
}

7.4.1 演算法識別碼

algorithm 欄位必須為加密演算法的識別字串。應使用以下標準化命名之一：

識別碼	演算法	狀態
`"AES-256-GCM"`	AES-256 in Galois/Counter Mode	推薦
`"ChaCha20-Poly1305"`	ChaCha20 with Poly1305	推薦
`"AES-128-GCM"`	AES-128 in Galois/Counter Mode	可使用

實作必須至少支援 AES-256-GCM 與 ChaCha20-Poly1305 中的一種。推薦同時支援兩種以增強互通性。

實作不得使用：

ECB 模式（不安全）
無認證的加密模式（CBC、CTR 不帶 MAC）
已知存在弱點的演算法（DES、3DES、RC4）

7.4.2 金鑰版本號

keyVersion 必須為非負整數，用於支援金鑰輪替：

當 CAP 觸發金鑰輪替時，新金鑰的 keyVersion 必須嚴格大於上一個版本。
接收方必須使用 keyVersion 選擇對應的解密金鑰。
實作應維護至少一個舊金鑰版本以支援飛行中（in-flight）的 Fragment。

7.5 加密往返一致性

實作必須滿足以下加密往返一致性屬性：

使用正確金鑰（與傳送方使用的金鑰相符）加密後再解密，必須產生與原始 Payload 位元組級相同的輸出。
使用錯誤金鑰解密必須失敗，必須返回 DECRYPTION_FAILED 錯誤（2001）。
解密失敗時，實作不得返回部分解密結果或損壞的資料。

7.6 終端側解密

當終端作為接收方時（資料注入情境）：

DTP_Slave 必須使用終端在 CAP 連線建立階段提交的金鑰進行解密。
該金鑰必須與終端在 CAP 中提交的私鑰/會話金鑰對應。
終端不得接受任何其他金鑰的解密結果。

7.7 解密失敗處理

實作必須按以下規則處理解密失敗：

單次解密失敗：丟棄訊框，傳送 DECRYPTION_FAILED 錯誤通知（2001）。
連續解密失敗超過閾值（實作定義，推薦為 3 次）： a. 應觸發 CAP 重新金鑰交換。 b. 應通知上層應用安全異常。
實作不得在多次解密失敗後無限重試同一訊框。

7.8 安全威脅防護

實作必須透過協定設計防護以下威脅：

威脅	防護機制
中間人竊聽	Payload 端對端加密
FayGer 窺探	Payload 加密，FayGer 僅可見密文
金鑰洩漏	金鑰版本號機制支援金鑰輪替
身分偽造	委派給 CAP 驗證
重放攻擊	序列號單調遞增 + 會話繫結
訊框竄改	使用認證加密（AEAD）演算法

7.9 重放保護

實作必須透過以下機制防護重放攻擊：

序列號單調遞增：接收方必須拒絕序列號小於或等於已確認最高序列號的訊框（除非處於續傳情境）。
會話繫結：序列號空間必須與具體會話繫結。新會話必須重置序列號。
AEAD 認證：加密演算法必須提供訊息認證（GCM、Poly1305 等）。

7.10 中繼資料隱私

實作應注意：訊框標頭中的明文中繼資料可能洩漏以下資訊：

通訊對端身分（透過 agreementId 關聯）
通訊時間模式（透過 originTimestamp 與 sequenceNumber）
資料傳輸頻率（透過訊框之間的時間差）

實作可透過以下方式增強中繼資料隱私：

啟用流量填充（實作定義）。
使用混淆傳輸層（如基於 TLS 1.3 的 ECH）。

但本規範 不要求 實作提供中繼資料隱私保護。

第 7 章 安全與加密