将来のTEEによる保護強化
Seamsでは、Deriver AとDeriver Bを別々の信頼実行環境（TEE）に配置し、クラウドアカウントと管理権限を分離する構成が考えられます。TEEは、定義された脅威モデルの範囲で、ハードウェアによる隔離を使って実行中のコードとデータを保護します。
構成案
このページは、将来の保護強化の候補を説明します。サポート済みのデプロイ手順や、現在の本番環境の保護を示すものではありません。
celldにはGoogle Confidential VMと通常のAWS EC2での検証記録があります。Nitro Enclavesへの対応と、アテステーションに基づく鍵の提供には、別途実装と検証が必要です。現在の検証範囲はホスティング先を参照してください。
2者間の境界を維持する
この構成案は、既存の2つのプロトコル境界を維持します。
- Deriver AとDeriver Bは、プロビジョニング、復元、その他の導出処理で協力します。
- クライアントとSigningWorkerは通常の署名で協力します。Deriverは通常の署名経路には入りません。
構成例として、AをGoogle Confidential Space、BをAWS Nitro Enclaveに配置できます。各環境はcelldで自分のロールを実行します。
| 境界 | Deriver A | Deriver B |
|---|---|---|
| 実行環境 | Google Confidential Space | AWS Nitro Enclave |
| 管理 | 独立したGoogleのIDとハードウェアセキュリティキー | 独立したAWSのIDとハードウェアセキュリティキー |
| 秘密情報へのアクセス | Aのテナントルートシェアとラッピング鍵 | Bのテナントルートシェアとラッピング鍵 |
| 永続化 | A専用の暗号化済み状態とバックアップ | B専用の暗号化済み状態とバックアップ |
| 相手との通信 | 認証・暗号化されたプロトコルメッセージ | 認証・暗号化されたプロトコルメッセージ |
SigningWorkerをTEEで保護する場合は、別の拡張として扱います。Deriverの保護だけでは、SigningWorkerやクライアントの保護は確立しません。
既存のロール分担はRouter A/Bを参照してください。
期待する効果と制約
アカウントの分離は、認証情報が侵害された場合の影響範囲を制限します。異なるプロバイダーと隔離技術は、一部の共通障害要因を減らせます。アテステーションを使うと、承認済みのワークロードに秘密情報へのアクセスを制限できます。効果は、選択した基盤と設定に依存します。
別々のメールアカウントとYubiKeyなどのハードウェアセキュリティキーは、管理アクセスの保護に役立ちます。アカウント復旧、デプロイ認証情報、鍵提供ポリシーの管理権限も分離する必要があります。両方を同じ人が管理する場合、その人は共通の管理主体として残ります。
この構成は、2者間プロトコルの小さな調整範囲を維持します。3-of-5の可用性は得られません。どちらかのDeriverが利用できないと、新しい導出が停止する場合があります。両方の秘密情報の結合や、共通のアプリケーションコードのすべての脆弱性にも対応できません。
特定の攻撃に対しては、強化した2者の構成が、分離の弱い多者構成より優れる場合があります。ただし、2つのTEEと3-of-5の構成の安全性を一律には比較できません。管理権限、ハードウェアの前提、復元権限、侵害耐性、可用性を個別に評価します。
ランタイムの対応
Google Confidential SpaceはLinuxコンテナを実行し、明示的に指定した受信ポートを公開できます。celldと承認済みWorker成果物をまとめて配置する方式が候補です。Confidential VM上で動作するだけでは、ゲスト管理者からの保護は確立しません。Googleのワークロードの説明とセキュリティモデルを参照してください。
AWS Nitro Enclavesには外部ネットワーク接続と永続ストレージがありません。親EC2インスタンスへのソケット接続であるvsockを使う通信と、外部への暗号化済み永続化が必要です。親は暗号文を中継できます。秘密情報の処理と認証済み通信の終端はEnclave内に保持します。通常のNitroベースのEC2だけでは、この境界は確立しません。Nitro Enclavesの概要とアテステーションによる鍵提供を参照してください。
秘密情報へのアクセスを承認済みコードに結び付ける
アテステーションは、ワークロードの識別情報と状態に関する証拠を提供します。秘密情報を提供する前に、その証拠を承認済みポリシーに照らして検証します。
celldの実行ファイルだけを測定しても、その後に置換可能なJavaScript、WASM、セキュリティ設定を読み込む場合は不十分です。秘密情報の使用に影響するすべての成果物を、承認対象に含める必要があります。
候補は、成果物を測定対象のイメージに含める方式と、測定済みランタイムが承認済みダイジェストを検証してから秘密情報を提供する方式です。承認内容の更新にも権限制御が必要です。アテステーションは、承認済みコードに脆弱性がないことを保証しません。
障害と復元でも分離を維持する
実行担当が切り替わっても、ロール分離を維持します。Aのオブジェクトと秘密情報へのアクセスは、Aの承認済み境界内に残す必要があります。BのホストがAの秘密情報を引き継げる構成にしてはいけません。逆方向も同様です。
フリートのストレージ、デプロイマニフェスト、認証情報、バックアップへのアクセスで、この制限を強制します。共有フリートを通じたロール間アクセスは、アカウント分離の効果を弱めます。
外部ストレージには、暗号化に加えて状態の鮮度を検証する仕組みが必要です。古い暗号化済みレコードの再送で、消費済みプロトコル素材、失効済み権限、古い所有権を復活させてはいけません。エポック、使用不可となった操作の記録、所有権フェンスは、新しいホスト脅威モデルでも保証を維持する必要があります。ホストが制御するスナップショットだけを、鮮度の根拠にはできません。
復元と鍵提供でも同じ分離を維持します。テナントルートのバックアップと復元と移行を参照してください。
性能と検証
常時稼働するインスタンスでは、配置とランタイム初期化をより制御できます。ただし、クラウド間の遅延と転送費用は導出処理に影響します。近いリージョンは有効な場合がありますが、プロトコル全体の測定が必要です。Deriver通信は通常の署名経路には入りません。SigningWorkerをTEEに対応させる場合は、署名性能を別途測定します。
サポート済み構成とする前に、次を検証します。
- 各ロールのワークロードが、意図した保護環境内で実行されること。
- 改変されたランタイム、Worker、WASM、セキュリティ設定では秘密情報を取得できないこと。
- 1つのアカウントで、両方のシェアの提供・復元や、それらにアクセスするコードのデプロイができないこと。
- 再起動、引き継ぎ、通信分断、古い状態の再送でも、ロール境界と一度限りの使用制約を維持すること。
- 承認済みの更新と復元がウォレットの識別情報を維持し、古い権限を失効させること。
- 通常稼働、再起動、相手の障害を含む、導出処理全体の測定があること。
正確な成果物、アテステーションポリシー、プロバイダー設定、測定した操作について、再現可能な証拠を保持します。ランタイム互換性だけでは、これらの安全性や性能は確認できません。