SPECIFICATION

第 10 章：セキュリティ考慮事項

本章は CAP プロトコルの脅威モデル、既知のリスクおよび緩和策を記述する。本章は非規範的内容（MUST/SHOULD/MAY 等のキーワードを使用しない）であるが、本章で記述するリスクと緩和策は SHOULD 実装者により真摯に取り扱われる。

10.1 脅威モデル

CAP プロトコルの脅威モデルは以下の前提と考慮に基づく。

10.1.1 信頼前提

CAP プロトコルは以下のエンティティを信頼可能と仮定する：

  1. Registration_Authority：信頼アンカー、その鍵配布能力はプロトコルセキュリティの基礎
  2. プリインストールされた信頼アンカー鍵：端末製造または配備時にプリインストールされた RA 公開鍵
  3. 端末の安全保管：Verification_Key とローカル署名鍵を保管するハードウェア/ソフトウェアセキュリティモジュール

CAP プロトコルは以下のエンティティを信頼可能と仮定しない：

  1. Fay インスタンス：Fay は悪意あるプログラミングまたは攻撃者の制御を受ける可能性
  2. iFay_Runtime：バグが存在するか置き換えられる可能性
  3. ネットワークチャネル：盗聴、改ざん、遮断される可能性
  4. 未認可アプリケーションプロセス：端末上の他のプロセスが CAP 制御をバイパス試行する可能性

10.1.2 攻撃者能力

以下の能力を持つ攻撃者を考慮する：

攻撃者種別能力
ネットワーク攻撃者ネットワークメッセージの盗聴、改ざん、遮断、リプレイ
不正 Fay合法クレデンシャルを保有するが行動異常
クレデンシャル窃取者他チャネルで他人のクレデンシャル副本を取得
内部脅威Descriptor_Issuer 自身が陥落
物理攻撃者端末デバイスに物理接触

CAP プロトコルは前 4 種の攻撃者に対し保護メカニズムを提供する。物理攻撃者への防護は端末のハードウェアセキュリティメカニズムに依存する（プロトコル層では解決しない）。

10.2 既知のリスクと緩和

10.2.1 クレデンシャル漏洩リスク

リスク：Authorization_Descriptor ファイルが攻撃者により窃取された後、クレデンシャルを保有する Fay 以外のエンティティから端末に提出可能。

緩和策：

  • Authorization_Descriptor の subject_fay_id は具体的な Fay にバインドされ、端末は §3.3.2 ステップ 4 で主体マッチングを検証
  • 攻撃者は対象 Fay のランタイムを同時に制御する必要があり（つまり Fay 自身を攻撃する必要がある）、クレデンシャル漏洩自体では攻撃を構成するに足りない
  • クレデンシャル保管は MUST 暗号化される（§3.2.3）、オフライン抽出を防止
  • Trusted_Ticket は短い有効期間（最長 7 日）とリアルタイム失効照会で損害ウィンドウを制限

残存リスク：攻撃者が Fay プロセス（鍵を含む）を完全制御した場合、クレデンシャルは依然濫用され得る。本プロトコルは「完全に陥落した Fay」の問題を解決できない——これはより上位の Fay 完全性保護問題である。

10.2.2 失効遅延リスク

リスク：クレデンシャル失効から失効声明が端末に到達するまでに遅延ウィンドウが存在し、その間失効済みクレデンシャルは依然検証通過可能。

緩和策：

  • 端末持続オンライン時、失効声明はデフォルトで 1 時間以内に同期（§3.4.5）
  • Trusted_Ticket 使用時、端末は MAY リアルタイム失効照会で遅延を解消（§4.3.2 ステップ 5）
  • クレデンシャル有効期間上限（オフライン 90 日 / オンライン 7 日）が最長遅延を制限
  • 発行者は高機微シナリオで SHOULD より短い有効期間（1 日等）を使用

残存リスク：長期オフラインの端末は数日あるいはそれ以上の期間、失効済みクレデンシャルを受け入れる可能性がある。これはオフライン認可メカニズムの固有のトレードオフ——可用性と失効時効性の間で可用性優先を選択。

10.2.3 リプレイ攻撃リスク

リスク：攻撃者が合法なプロトコルメッセージをキャプチャ後、端末にリプレイする。

緩和策：

  • AuthRequest は message_id（UUID v7、時間関連）を含み、端末は MAY 短期既見 ID キャッシュを維持してリプレイを拒否できる
  • Heartbeat の sequence_number は単調増加し、リプレイは検出される（§5.4.2）
  • TLS チャネルは基礎的なリプレイ保護を提供（各 TLS セッションは独立）
  • 失効声明の revocation_id は一意、リプレイ無効

残存リスク：TLS セッション内部で攻撃者が既に TLS 暗号化を突破している場合、メッセージリプレイ可能。これは TLS 層の脅威であり、CAP プロトコルの範囲ではない。

10.2.4 時計攻撃リスク

リスク：攻撃者が端末時計を改変し、有効期間チェックをバイパスまたは時計関連脆弱性を露出させる。

緩和策：

  • 端末時計の出所は信頼可能であるべき（システム時計、NTP 同期）
  • §3.6 が時計ドリフト検出を定義：顕著な時計ジャンプ時に検証を拒否
  • 長期オフライン時間の端末は SHOULD ユーザーに時計再同期を促す

残存リスク：端末を物理制御する攻撃者は時計を操作できる可能性。物理セキュリティは端末ハードウェアの責任。

10.2.5 Descriptor_Issuer 陥落リスク

リスク：Descriptor_Issuer が攻撃者により完全制御され、任意のクレデンシャルを発行可能。

緩和策：

  • §8.6.2 が緊急鍵失効メカニズムを定義
  • Registration_Authority は Descriptor_Issuer の Verification_Key を失効させることでそのすべての発行クレデンシャルを失効化できる
  • 端末は Verification_Key 失効受領後、関連 Session を直ちに終了（§5.5）
  • 信頼ルート（Registration_Authority）のセキュリティが鍵——その陥落は信頼チェーン全体の崩壊を招く

残存リスク：Verification_Key 失効前に既に発行されたクレデンシャルは濫用される可能性がある。失効ウィンドウ期間は不可避。

10.2.6 リソース枯渇攻撃リスク

リスク：悪意ある Fay が大量要求で端末リソース（接続数、Session 数、保管）を枯渇させる。

緩和策：

  • §5.8 が Session 数量制限を定義
  • §3.2.3 がクレデンシャル保管上限を定義
  • ハートビートタイムアウトで失効 Session を回収しリソース解放
  • 端末は SHOULD fay_id ベースのレート制限を実施（§7.4.2 頻度制約以外）

残存リスク：合法発行された複数のクレデンシャルが共謀してリソースを枯渇させる可能性。端末ポリシーは単一 Fay の総配額を制限すべき。

10.2.7 ハンドオーバー競合リスク

リスク：攻撃者がハンドオーバーフローの中間状態（§6.5.1 [T2] の「アクティブ Session なし」状態等）を利用してリソースを横取り。

緩和策：

  • ハンドオーバー過程中リソースは事前占有状態（handover_pending）にあり、他の Session 要求を受け入れない（§6.5.3）
  • [T2] と [T3] の間で失敗が発生しても、リソースは明示的に「アイドル」状態に進入し、後続要求が公平に競合する（§6.5.2）
  • ハンドオーバータイムアウトによりリソースが長期間 pending 状態にならない

残存リスク：[T3]–[T4] 失敗の極端ケースでは、元 Fay のセッションは復元不可——AuthRequest を再発信する必要がある。これは必要な代価であり、「自動復元」がもたらすより複雑なセキュリティ分析を回避する。

10.2.8 デグレード攻撃リスク

リスク：攻撃者が端末と Ticket_Issuer の接続を遮断し、端末をデグレードモード（§4.5）に強制し、リアルタイム失効チェックをバイパス。

緩和策：

  • 端末はデグレードモードでデフォルトで新しい Trusted_Ticket の受け入れを拒否
  • 既にローカル Authorization_Descriptor に変換されたチケットの有効期間は短い（最長 7 日）
  • 端末は SHOULD iFay_Runtime に現在デグレードモードであることを示唆し、機微操作が主動拒否できるようにする

残存リスク：デグレード期間中既に変換されたローカルクレデンシャルは依然使用可能。これはオフライン優先設計の固有トレードオフ。

10.2.9 サイドチャネル攻撃リスク

リスク：CAP プロトコル応答時間またはエラーコード詳細を観察して機微情報（有効クレデンシャルの存在性等）を推測。

緩和策：

  • エラーコードは内部詳細を露出しない（§9.9）
  • 実装は SHOULD 検証失敗の異なる分岐で近似した応答時間を維持
  • エラー応答で鍵フィンガープリント、内部 ID 等を漏洩しない

残存リスク：サイドチャネル攻撃を完全に排除するのは極めて困難。本プロトコル層は基礎措置を提供し、深層防御は実装品質に依存。

10.3 配備セキュリティ推奨

CAP プロトコルを実装する配備者は以下のセキュリティ実践を考慮すべき：

10.3.1 鍵管理

  • 秘密鍵保管はハードウェアセキュリティモジュール（HSM、TPM、Secure Enclave）を使用
  • 鍵ローテーション周期は 90 日以下（端末ローカル鍵）/ 365 日以下（Issuer 鍵）
  • 鍵漏洩緊急対応フローを確立
  • 重要署名操作は複数人承認またはハードウェア PIN を要求

10.3.2 監視と監査

  • すべての認可検証失敗イベントを記録しアラート
  • 異常な失効要求頻度を監視（Descriptor_Issuer 陥落の指標である可能性）
  • 監査ログは独立した永続化保管を使用、改ざん防止
  • 高機微リソース（configure モード、require_human_confirmation 制約）のすべての操作を完全監査

10.3.3 端末強化

  • OS 強制アクセス制御（SELinux、AppArmor）を有効化
  • サンドボックスで iFay_Runtime と他のプロセスを分離
  • 不要なシステムサービスを停止し、攻撃面を削減
  • 定期的にシステムパッチを更新

10.3.4 ネットワークセグメンテーション

  • Registration_Authority の配備ネットワークを公網と分離
  • Descriptor_Issuer を管理された環境に配備
  • 端末から Issuer への通信を必要なポート/プロトコルに制限
  • mTLS（双方向認証）で重要通信を保護

10.4 プロトコル限界

本仕様は明示的に以下のセキュリティ問題を解決しない：

  1. Fay 完全性：CAP プロトコルは Fay インスタンス自身のコードと行動完全性が他のメカニズム（コード署名、ランタイム完全性測定等）で保証されると仮定
  2. 物理セキュリティ：端末が物理攻撃者により完全制御された場合、ソフトウェア層では保護を提供できない
  3. 監査ログ形式：v1 は監査ログ形式を規範化しない（ブループリント §3.2 除外項）
  4. 端末横断アイデンティティフェデレーション：v1 は端末横断の統一アイデンティティ管理をサポートしない、各端末は独立して Registration_Authority を信頼

10.5 後続バージョンのセキュリティ進化

将来バージョン（v2+）で導入予定のセキュリティ強化：

  1. 分散失効合意（ブループリント §3.2 除外項）
  2. 監査ログ標準形式（ブループリント §3.2 除外項）
  3. 耐量子暗号アルゴリズム（NIST PQC 標準を追跡）
  4. ゼロトラスト原則のより深い統合
  5. 形式化されたプロトコルセキュリティ証明