Google Cloud マルチパーティ コンピューティングは、機関投資家のデジタル アセット運用に暗号化による信頼インフラストラクチャを提供します。マルチシングル テナント アーキテクチャを使用します。作成する各インスタンスは、独自のネットワーク上り（内向き）、独自のストレージ、暗号オペレーション用の独自のハードウェア分離コンピューティングを備えた専用の分離環境です。
コア コンポーネント
各マルチパーティ コンピューティング インスタンスには、3 つの主要コンポーネントがあります。ガバナンス ロジック、リクエスト ルーティング、暗号計算は、別々のコンポーネントで実行されます。
MPC API
Multi-party Compute API は、次のリソースを管理します。
- ユーザーとチーム: インスタンスでロールを保持する ID と、鍵ポリシーが参照する署名者のグループ。
- KeyRing と KeyPolicy: 鍵をグループ化する KeyRing。各 KeyRing には、どのチームとユーザーが鍵共有を保持するか、署名を承認する必要がある鍵共有の数を決定する鍵ポリシーが関連付けられています。
- TransactionPolicies: トランザクションを許可または禁止する Cedar ルールと、それらを有効または無効にするポリシー作成者の承認。
- KeyLists: トランザクション ポリシーが参照できるアドレスの名前付きリスト。
マルチパーティ コンピューティング API は、各トランザクションの状態と、そこに記録された承認を追跡し、コーディネーターに鍵の生成と署名のオーケストレーションをリクエストします。Spanner は、リクエストと署名付きの承認を保存します。ワーカー TEE は、承認署名に基づいて処理を行う前に、承認署名自体を検証します。
コーディネーター
マルチパーティ コンピューティング API は、コントローラを参加者の TEE に接続します。
- 鍵共有の検出とリクエストのルーティング: 鍵の生成中に新しい鍵共有を保持する正常な TEE を割り当て、後でリクエストを適切な TEE にルーティングします。
- Health: 参加者の TEE の健全性をモニタリングし、署名付きリクエストのロードバランサとして機能します。
- 耐久性: 鍵共有の交換が必要な場合に、再共有を管理します。
コーディネーターはプロトコルのセキュリティに影響しません。鍵共有を保持せず、承認やポリシーの結果を検証しません。この検証は参加者の TEE 内で行われます。
ワーカー TEE
各ワーカーは、Confidential Space で実行される TEE です。ワーカー TEE は次の 2 つの部分を実行します。
- 暗号エンジン: 鍵シェアを保持し、他のワーカー TEE とともに安全なしきい値鍵生成プロトコルと署名プロトコルを実行します。
- ポリシー評価ツール: 有効なトランザクション ポリシーのセットに照らしてトランザクションを評価します。
トランザクション署名フロー
マルチパーティ コンピューティングでは、1 回の API 呼び出し CreateTransaction でペイロードに署名します。トランザクション ポリシーの評価、署名者の承認、しきい値署名はすべて、この呼び出しから始まります。固定順序のフローは次のとおりです。
- リクエスト。署名者が鍵に対して
CreateTransactionを呼び出します。リクエストには、署名者の承認鍵で署名された署名者自身の承認が含まれます。IAM は、呼び出し元がメソッドを呼び出せることを確認し、リクエストは Cloud Audit Logs に記録されます。 - ポリシーの評価。トランザクションは、アクティブなトランザクション ポリシーのセットに照らして評価されます。ポリシー評価では、
APPROVEDまたはREJECTEDのいずれかの判定ごとに、永続的な監査ログが生成されます。 - 開始者の承認。開始者の承認だけで鍵ポリシーのしきい値を満たしている場合、
CreateTransactionはすぐにステップ 5 に進みます。 - 署名者の承認。開始者の承認だけでは鍵ポリシーのしきい値を満たさない場合、トランザクションは
PENDING_AUTHORIZATION状態になります。鍵の鍵シェアを保持する他の署名者は、RecordSignerDecision呼び出しを使用してトランザクションを承認または拒否します。各署名者は、それぞれの承認鍵で署名します。トランザクションは、鍵ポリシーのしきい値を満たすのに十分な数の署名者が承認するまで、PENDING_AUTHORIZATION状態で待機します。十分な数の署名者が拒否し、しきい値を満たせなくなった場合、トランザクションはREJECTED状態に移行します。有効期限までに十分な承認が得られなかった場合は、EXPIREDになります。 しきい値署名。しきい値に達すると、鍵のシェアを保持する高信頼実行環境（TEE）がしきい値署名プロトコルを実行し、トランザクションの署名を生成します。
参加者の TEE は、鍵共有を使用する前に、署名を求められたペイロードがトランザクション ポリシーに照らして評価されたことを確認します。クライアント、オペレーター、その他のサービス コンポーネントは、評価されていないペイロードに署名するよう参加者に要求することはできません。
ユーザー、チーム、KeyRing、トランザクション ポリシーなどの関連リソースについては、マルチパーティ コンピューティングの概要をご覧ください。
セキュリティ モデル
- TEE に固定された鍵の共有。各鍵共有は、それを作成した TEE のみで読み取ることができます。鍵の持ち分は、コーディネーター、コントローラ、Google オペレーターなどの別のコンポーネントが読み取れる形式で TEE から流出することはありません。
- 顧客鍵の保管。お客様は、お客様の Google Cloud 組織で Cloud Key Management Service を使用することで、暗号鍵を常に完全に管理できます。
- ハードウェアの分離。参加者の TEE は Confidential Space で実行されます。Confidential Space は、ハードウェア メモリ暗号化を使用して、ホストと Google インフラストラクチャから使用中のデータを保護します。構成証明は、各 TEE を検証済みのコンテナ イメージにバインドします。
- E2E 暗号化。ワーカー TEE は、エンドツーエンドの暗号化された gRPC を介して直接通信します。
- 署名付きの承認。署名者、ポリシー作成者、管理者は、秘密鍵が外部に漏洩することのない認証鍵を使用して承認に署名します。参加者の TEE は、トランザクションへの署名、トランザクション ポリシーの承認、管理者またはポリシー作成者のロール変更の承認を行う前に、これらの署名を検証します。これにより、トランザクションの改ざんが防止され、耐久性のある監査ログが残ります。
- ポリシー作成者のクォーラム。新しいトランザクション ポリシー、またはポリシーを無効にするリクエストは、必要な数のポリシー作成者が承認した後にのみ有効になります。
- 管理クォーラム。管理者ロールまたはポリシー作成者ロールの付与または削除は、必要な数の管理者が承認した後にのみ有効になります。詳細については、ロール変更の管理者による承認をご覧ください。
ロードマップ
今後のリリースで、次の機能が予定されています。
- 外部 TEE: AWS Nitro Enclaves など、お客様が Google Cloudの外部で実行する TEE に保持される鍵共有。
- モバイル鍵共有: ユーザーのモバイル デバイスに保持される鍵共有。
- 再共有: 鍵を変更せずに、既存の鍵の共有を保持するユーザーを変更するか、失われた共有を置き換えます。
システム プロパティ
マルチパーティ コンピューティングの信頼インフラストラクチャは、次のシステム プロパティを維持します。
安全性（暗号化コンテキストにおける健全性）
いかなる状況でも、システムは許可されていない方法で動作してはなりません。たとえば、DKLS23 プロトコルにより、k 人未満の参加者のグループは署名を偽造できません。正確なセキュリティ定義は、文献の Universal Composable フレームワークで形式化されています。
暗号システムを実用的な実装に組み込む場合は、セキュリティ特性を損なうような前提に依存しないように注意する必要があります。たとえば、プロトコルの各当事者は独立している必要があります。つまり、侵害に対する脆弱性が独立している必要があります。
この特性を保証するため、マルチパーティ コンピューティングは、証明済みの TEE で各参加者を実行し、各鍵共有は、それを作成した TEE に固定されます。プロトコル内の 1 つの参加者が侵害されても、他の参加者には影響しません。
マルチパーティ コンピューティングに関する学術文献は、ほぼ例外なく健全性に焦点を当てており、関係者のセットが不変で、すべての関係者が常に利用可能であり、関係者が理想的で常に利用可能なポイントツーポイントの認証済みチャネルを使用して通信するという単純な世界を想定しています。実際のプロダクトでは、さらにいくつかの懸念事項に対処する必要があります。
ライブネス
システムは最終的に進行します。最も一般的なライブネス プロパティは、DKLS23 プロトコルで保持されるデッドロックの不在です。しきい値鍵は、鍵ポリシーのしきい値を満たすのに十分な数の TEE が利用可能であれば、署名に使用できます。たとえば、3 つのうち 2 つの鍵を使用する場合、3 つのシェアのうち任意の 2 つで署名を完了できます。
耐久性
永続的に失敗したパーティは置き換える必要があります。そうしないと、システムは最終的に共有シークレットを永続的に失います。たとえば、ハードウェアに障害が発生すると、そのハードウェアで実行されている参加者の状態が失われます。鍵の共有は TEE に固定されているため、コーディネーターは、各鍵の共有を保持している TEE を追跡します。v1beta では、鍵ポリシーのしきい値を満たすのに十分な数のシェアが残っている限り、鍵は使用可能な状態を維持します。失われた共有を置き換えるには、再共有が必要です。これは今後のリリースで計画されています。
構成の変更
ハードウェア障害（TEE がデータを失う）と組織の変更（新しい従業員が秘密鍵の共有でプロトコルに参加する）の両方で、鍵の共有を保持するユーザーを変更する必要があります。マルチパーティ コンピューティングでは、DKLS23 の健全性プロパティを維持する安全な再共有プロトコルを使用して、これをサポートする予定です。再共有に関与する悪意のある新しいパーティは、他の悪意のあるパーティと同様に、シークレットのシェアを最大 1 つ漏洩します。