SPECIFICATION

第 8 章：密碼學與簽章

本章定義 CAP 協議使用的簽章演算法、金鑰格式、金鑰生命週期管理和分發要求。本章中的密碼學要求是規範性的——任何符合 CAP 協議的實作 MUST 按本章定義實施。

8.1 演算法集

CAP v1 定義兩套強制實作的簽章演算法和金鑰格式：

演算法 ID演算法公鑰長度簽章長度狀態
ed25519Ed25519（RFC 8032）32 位元組64 位元組必須實作
ecdsa-p256-sha256ECDSA P-256 + SHA-256（RFC 6979）65 位元組（未壓縮）/ 33 位元組（壓縮）64 位元組（DER 編碼或 raw）必須實作

所有 CAP 實作 MUST 同時支援這兩套演算法。Trusted_Ticket 使用 JWS 時，對應演算法名稱為：

CAP 演算法 IDJWS alg 欄位
ed25519EdDSA
ecdsa-p256-sha256ES256

8.1.1 演算法選擇建議

  • 優先使用 ed25519：效能更好、簽章更短、金鑰管理更簡單
  • ecdsa-p256-sha256：在 FIPS 140-3 等監管要求下使用

簽發方 SHOULD 在所有新簽發的憑證中預設使用 ed25519，除非有明確合規要求。

8.1.2 不允許的演算法

CAP v1 實作 MUST NOT 使用以下演算法簽發或接受新憑證：

  • 任何 RSA 簽章變體（效能不佳，金鑰更大）
  • ECDSA secp256k1（非 FIPS 標準曲線）
  • ECDSA P-384 / P-521（v1 不強制，未來版本可能加入）
  • 任何 SHA-1 衍生簽章演算法

8.2 金鑰格式

8.2.1 Ed25519

公鑰按 RFC 8032 §5.1.5 編碼：

  • 32 位元組小端序的壓縮 Edwards 曲線點

DescriptorPayload 中 signature.signature_value 為 64 位元組原始簽章（不含 ASN.1 編碼）。

JWS 中簽章按 RFC 8037 編碼，64 位元組原始簽章 base64url 編碼。

8.2.2 ECDSA P-256

公鑰按 RFC 5480 編碼：

  • 未壓縮格式：65 位元組（0x04 || X || Y）
  • 壓縮格式：33 位元組（0x02/0x03 || X）

實作 MUST 同時接受未壓縮和壓縮格式公鑰。

簽章格式：

  • DescriptorSignature 中：64 位元組原始簽章（R || S，每部分 32 位元組大端序），不使用 DER
  • JWS 中：按 RFC 7518 §3.4 編碼（64 位元組 R || S）

8.2.3 金鑰的二進位表示

VerificationKey.key_material 欄位直接儲存上述格式的位元組序列：

  • ed25519 → 32 位元組
  • ecdsa-p256-sha256（未壓縮） → 65 位元組
  • ecdsa-p256-sha256（壓縮） → 33 位元組

8.3 簽章輸入建構

8.3.1 Authorization_Descriptor 簽章輸入

按以下步驟建構簽章輸入：

  1. 取 AuthorizationDescriptor.payload（DescriptorPayload 結構）
  2. 按 RFC 8949 CBOR 確定性編碼（Deterministic Encoding）序列化為位元組序列
  3. 該位元組序列即為簽章演算法的輸入

CBOR 確定性編碼的關鍵約束（來自 RFC 8949 §4.2）：

  • map 中的鍵按字典序排序
  • 數值使用最短編碼
  • 字串和位元組串使用最短長度編碼
  • 不使用不確定長度編碼（indefinite-length encoding）

實作 MUST 嚴格遵守這些約束以確保跨實作的簽章驗證一致性。

8.3.2 Trusted_Ticket 簽章輸入

按 RFC 7515 §5.1 建構 JWS 簽章輸入：

Signing Input = base64url(UTF8(Header)) + "." + base64url(UTF8(Payload))

其中：

  • Header 和 Payload 按 RFC 7159 序列化為 UTF-8 JSON
  • JSON 欄位順序：實作 SHOULD 按字典序排序鍵，但嚴格的欄位順序要求由 base64url 編碼的位元組決定

8.3.3 RevocationStatement 簽章輸入

撤銷聲明的簽章輸入建構與 Authorization_Descriptor 相同：

  1. 移除 signature 欄位，保留其餘 RevocationStatement 欄位
  2. CBOR 確定性編碼序列化
  3. 位元組序列作為簽章輸入

8.4 金鑰分發

8.4.1 分發模式

終端 MUST 支援以下兩種 Verification_Key 分發模式：

離線預置（Pre-installed）

終端出廠或部署時預置初始 Verification_Key。預置金鑰：

  • 在 VerificationKey 結構中標記 source = "pre-installed"
  • MUST 在製造或部署階段透過實體或受控的安全通道寫入
  • 通常對應根級 Descriptor_Issuer（如裝置廠商認證 Issuer）

線上分發（RA-distributed）

Registration_Authority 透過線上介面分發新的 Verification_Key：

  • 在 VerificationKey 結構中標記 source = "ra-distributed"
  • MUST 透過 TLS/mTLS 通道傳輸（參見 §1.3.4）
  • 終端 MUST 驗證傳輸方為已信任的 Registration_Authority

8.4.2 信任錨配置

終端的 Registration_Authority 公鑰（用於驗證 RA 推送訊息的簽章）作為信任錨：

  • MUST 在終端製造或初次部署時預置
  • 僅可透過實體或受控管道更換
  • 不透過 CAP 協議執行時機制更新

8.4.3 分發訊息

Registration_Authority 推送的金鑰分發訊息：

VerificationKeyDistribution {
  required version       : uint32 (= 1)
  required key           : VerificationKey
  required ra_signature  : DescriptorSignature       // 由 Registration_Authority 簽章
}

終端處理流程：

  1. 驗證 ra_signature 是否由信任錨 Registration_Authority 簽發
  2. 驗證 key.algorithm 在 §8.1 允許的演算法集合內
  3. 驗證 key.valid_from 與終端目前時間合理（如不超過目前時間 +24 小時）
  4. 寫入終端金鑰儲存
  5. 向 Registration_Authority 返回確認（確認機制不在本規範範圍內）

8.5 金鑰儲存

終端 MUST 安全儲存所有 Verification_Key 和本地簽章金鑰（參見 §4.4.3）。

8.5.1 儲存要求

終端 MUST：

  1. 加密儲存所有金鑰的私鑰部分（公鑰可明文儲存）
  2. 私鑰存取受 OS 程序權限保護，僅 Protocol_Engine 可讀取
  3. SHOULD 將私鑰保存在硬體安全元件（如 TPM、Secure Enclave、TEE）中

終端 MUST NOT：

  1. 以明文形式將私鑰寫入持久化媒介
  2. 將私鑰透過 CAP 協議訊息傳輸
  3. 在偵錯日誌或錯誤輸出中暴露私鑰內容

8.5.2 金鑰外洩處理

若終端偵測到金鑰可能外洩（如安全儲存被攻擊）：

  1. 立即停止使用該金鑰
  2. 透過 §8.6 流程向 Registration_Authority 報告
  3. 在新金鑰分發完成前，相關憑證的校驗全部拒絕（保守策略）

8.6 金鑰更新與輪替

8.6.1 平滑過渡

Registration_Authority 在輪替 Verification_Key 時 MUST 提供平滑過渡：

  1. 新金鑰分發到所有終端
  2. 在過渡期內（預設 30 天），新舊金鑰並存有效
  3. 過渡期結束後，舊金鑰的 valid_until 到期，自動失效

終端在過渡期內 MUST 同時維護新舊金鑰，並按 key_id 選擇對應金鑰進行校驗。

8.6.2 緊急撤銷

VerificationKeyRevocation {
  required version          : uint32 (= 1)
  required key_id           : string
  required revocation_time  : timestamp
  required reason           : enum["compromised", "superseded", "ra_decision"]
  required ra_signature     : DescriptorSignature
}

終端收到撤銷訊息後 MUST：

  1. 驗證簽章來自信任錨 Registration_Authority
  2. 立即將該 key_id 標記為已撤銷
  3. 後續校驗請求中使用該 key_id 的憑證全部拒絕（返回 E_VERIFICATION_KEY_INVALID）
  4. 主動檢查所有活躍 Session：使用該 key_id 簽發憑證的 Session 強制終止（參見 §5.5）

8.6.3 終端本地簽章金鑰的輪替

終端為支援 §4.4 轉換流程持有的本地簽章金鑰：

  • 每 90 天 SHOULD 自動輪替一次
  • 輪替時由終端產生新金鑰對，舊金鑰繼續用於已簽發憑證的校驗直至全部過期
  • 終端 MAY 同時持有最多 4 個本地簽章金鑰（涵蓋最長有效期 + 平滑過渡）

8.7 密碼學要求總結

要求範圍
簽章演算法 MUST 在 ed25519 / ecdsa-p256-sha256 中選擇所有簽章場景
私鑰 MUST 安全儲存所有簽發方與終端
公鑰分發 MUST 透過加密通道Registration_Authority → 終端
信任錨 MUST 透過實體或受控管道預置所有終端
CBOR 確定性編碼用於離線憑證簽章輸入Authorization_Descriptor、RevocationStatement
JWS Compact Serialization 用於線上票據Trusted_Ticket