BLUEPRINT
第7章 セキュリティと暗号化
7.1 エンドツーエンド暗号化設計
DTP はエンドツーエンド暗号化を実装し、データが伝送中に信頼できない中間環境(FayGer ランタイムなど)を経由しても、窃取や改ざんされないことを保証します。
コア保証:対象の iFay インスタンスのみが受信したペイロードデータを復号でき、FayGer ランタイム環境は平文にアクセスできない。
iFay がパブリッククラウドの FayGer インスタンス上で動作している場合でも、クラウドサービスプロバイダーはユーザーの健康データ、位置情報、消費記録を読み取ることができません。
7.2 暗号化範囲
┌─────────────────────────────────────┐
│ Logical_Frame │
├─────────────────────────────────────┤
│ Header(フレームヘッダー)── 平文伝送 │
│ ┌─────────────────────────────────┐│
│ │ ... ││
│ │ encryptionMetadata ── 平文 ││
│ │ algorithm: "AES-256-GCM" ││
│ │ keyVersion: 3 ││
│ └─────────────────────────────────┘│
├─────────────────────────────────────┤
│ Payload(ペイロード)── 暗号化伝送 │
│ ┌─────────────────────────────────┐│
│ │ ████████████████████████████ ││
│ │ ████████ 暗号化データ ██████████ ││
│ │ ████████████████████████████ ││
│ └─────────────────────────────────┘│
└─────────────────────────────────────┘
- フレームヘッダー:平文伝送、ルーティングと処理に必要なメタ情報を含む
- 暗号化メタデータ:平文伝送、暗号化アルゴリズム識別子と鍵バージョン番号を含み、受信側が復号方法を判断できるようにする
- ペイロード:暗号化伝送、実際のデータ内容を含む
7.3 鍵管理
DTP は自身で鍵を管理せず、CAP(Control Authorization Protocol)で事前にネゴシエーションされた鍵に依存します:
- CAP が接続確立フェーズで身分認証と鍵交換を完了
- DTP は CAP が提供する鍵を使用して Payload の暗号化/復号を実行
- 鍵バージョン番号(keyVersion)は現在使用中の鍵を識別するために使用
CAP 前提条件
DTP はデータ伝送を開始する前に、CAP が身分認証と鍵交換フローを完了していることを必ず検証する必要があります。CAP の鍵交換がまだ完了していない場合、DTP_Engine はデータ送信を拒否し「鍵未準備」(KEY_NOT_READY)エラーを返します。
7.4 暗号化メタデータ
各 Logical_Frame のフレームヘッダーは暗号化メタデータを携帯します:
| フィールド | 説明 |
|---|---|
| algorithm | 暗号化アルゴリズム識別子、例:"AES-256-GCM" |
| keyVersion | 鍵バージョン番号、どのバージョンの鍵を使用するかを示す |
暗号化メタデータ自体は暗号化されず、受信側が復号前に復号パラメータを取得できることを保証します。
7.5 暗号化ラウンドトリップ一貫性
DTP は暗号化のラウンドトリップ一貫性を保証します:
- 正しい鍵で暗号化した後に復号すると、元のデータと等価な Payload が生成される
- 誤った鍵で復号すると、失敗して DECRYPTION_FAILED エラーを返す
7.6 端末側復号
端末が受信側の場合(データ注入シナリオ)、DTP_Engine は端末が CAP 接続確立フェーズで提出した鍵を使用して復号します。
7.7 セキュリティ脅威防護
| 脅威 | DTP 防護措置 |
|---|---|
| 中間者盗聴 | Payload エンドツーエンド暗号化、中間ノードは平文を読み取り不可 |
| FayGer 窃視 | FayGer は暗号化後の Payload のみ参照可能、復号不可 |
| 鍵漏洩 | 鍵バージョン番号メカニズムにより鍵ローテーションをサポート |
| 身分偽装 | CAP の身分認証メカニズムに依存 |
| リプレイ攻撃 | シーケンス番号の単調増加 + セッションバインディング |
