Google、2027年に機関向け暗号資産保管プラットフォームを開始：MPC技術の仕組み
Google Cloudは、Google Multi-Party Compute（MPC）を導入しました。これは、グローバルな銀行、資産運用会社、規制対象の金融機関向けに設計されたデジタル資産の鍵管理および保管インフラストラクチャです。現在、招待制のプライベートプレビューを実施中であり、クラウドプロバイダーは2027年初頭に商業用一般提供（GA）を目標としています。広範な商業展開に先立ち、GoogleはEthereumおよびSolanaを含む主要なブロックチェーンエコシステムをサポートする内部本番環境でアーキテクチャを検証しています。
このイニシアチブは、機関向けWeb3クラウドインフラの顕著な拡張を示しています。数年間、主要なクラウドプロバイダーは、リモートプロシージャコール（RPC）ノードのホスティング、BigQueryでのパブリックブロックチェーンデータセットのインデックス作成、およびエンタープライズ決済ネットワークの検討にデジタル資産サービスを集中してきました。
Google CloudがネイティブなMPCインフラを導入することで、機関向けデジタル金融のセキュリティスタック、すなわち暗号鍵の分散生成、ポリシー検証、閾値署名の領域にさらに深く進出しています。規制を受けた金融機関がトークン化された預金、スポット取引型ETF（ETP）、およびリアルワールドアセット（RWA）の決済への関与を拡大する中で、クラウド統合型MPCは、従来の預託サービスプロバイダーおよびレガシーなハードウェアバンクとともに、モジュラーな技術的基盤を提供します。
デジタル資産への機関投資家の参加の拡大は、堅牢な鍵管理システムの重要性を浮き彫りにしています。DeFiLlamaなどのプラットフォームによる業界セキュリティの追跡によると、認証情報の漏洩や秘密鍵の悪用は、仮想通貨業界全体で資本損失の最大の要因の一つとなっており、近年の市場サイクルで累計数十億ドルの業界損失をもたらしています。
歴史的に、機関向けデジタル資産の保管は、商業金融機関にとってそれぞれ異なる運用上のトレードオフを伴う2つの主要なアーキテクチャモデルに依存してきました。
-
レガシーなハードウェアセキュリティモジュールとシングルポイントのリスク
従来の金融における鍵管理は、物理的なハードウェアセキュリティモジュール（HSM）と空気遮断されたコールドストレージ環境に大きく依存しています。HSMは暗号鍵を改ざん耐性のあるハードウェア内に隔離しますが、標準的なシングルキー構成では依然として構造的な単一障害点（SPOF）を引き起こす可能性があります。
従来のシングルシグネチャブロックチェーントランザクションを承認するには、署名生成中に完全なプライベートキーが単一のモジュールのメモリ境界内に存在しなければなりません。攻撃者がホスト管理レイヤーを侵害し、ファームウェアの脆弱性を悪用したり、管理アクセス制御を回避したりした場合、その単一のキーで管理される資産は即座に暴露されます。
-
オンチェーンマルチシグ制限
単一キーへの依存を避けるため、多くのWeb3プロトコルは、Safeのようなオンチェーンマルチシグ（Multi-Sig）スマートコントラクトを活用しています。標準的なM of Nマルチシグ構造では、複数の独立した秘密鍵がそれぞれ承認を提出し、スマートコントラクトの実行ルールを満たす必要があります。
分散型財政には非常に効果的ですが、オンチェーンマルチシグは従来の銀行ワークフローに次の3つの実用的な課題をもたらします：
クロスチェーン互換性の問題：スマートコントラクトのマルチシグロジックは、多様なLayer-1ブロックチェーン間で一貫していません。Ethereum仮想マシン（EVM）ネットワークでは広く標準化されていますが、BitcoinやSolanaなどの非EVMチェーンで同一のスマートコントラクトガバナンスを実装するには、異なるネイティブスクリプトと別々の運用パイプラインが必要です。
ネットワーク取引コストの増加：マルチシグ取引では、複数の暗号署名やコントラクト呼び出しがチェーン上で直接検証されるため、標準的なシングルシグネチャ振替と比較して、追加のブロックスペースとガス代を消費します。
ガバナンスルールの公開性：マルチシグルールはパブリックなスマートコントラクトを通じて実行されるため、機関のクォラム閾値、署名者アドレス、組織の承認パターンはパブリックな台帳上で確認できます。
これらの制約により、複数のブロックチェーンにわたってセキュリティポリシーを統一するオフチェーン閾値暗号技術に対する機関の需要が高まっています。
Google Cloud Multi-Party Computeは、マルチパーティ計算（MPC）に基づく閾値署名スキーム（TSS）を実装することで、単一ポイントキーのリスクに対応します。この暗号モデルでは、鍵生成、保存、トランザクション署名のどの段階においても、完全な秘密鍵はいずれのデバイス、サーバーメモリバス、またはデータセンターにも組み立てられることはありません。
ハードened DKLs23 閾値署名プロトコル
プラットフォームの技術仕様によると、GoogleのECDSA署名エンジンはDKLs23プロトコルの強化された実装を組み込んでいます。暗号学者Döttling、Komargodski、Lai、Shenの名前にちなんで名付けられたDKLs23は、通信オーバーヘッドを最小限に抑えながら、分散された複数の参加者間で楕円曲線署名を安全に計算することを目的とした現代的な閾値署名プロトコルです。
グーグルの実装は、以下の3つの運用優先事項に焦点を当てています：
-
悪意のある敵対者的耐性：プロトコルは、攻撃者が署名閾値以下の参加ノードを侵害した場合でも、偽造不可能性を維持するように設計されています。組み込みの整合性チェックが、署名セレモニー中に不正な暗号学的シェアを検出し、無効な署名が生成される前にセッションを自動的に中止します。
-
低遅延ラウンド最適化：初期のMPC実装では、複数回の双方向ネットワーク通信により署名時間が遅くなることがよくありました。DKLs23の簡素化されたラウンド構造を活用することで、ローカルの暗号計算がミリ秒単位で完了し、機関ポリシーのチェックを通過した後、エンドツーエンドの署名ワークフローを1秒未満で実現できます。
非同質なキー分割：2-of-3クオラムモデル
プラットフォームは、一度にプライベートキーを生成して後で分割するのではなく、分散鍵生成（DKG）を使用しています。これにより、独立したノードが数学的にそれぞれの鍵のシェアを計算し、どのノードも完全な鍵を一度も見ることはありません。
リスクを単一のクラウドベンダーに集中させないため、機関向けデプロイメントでは通常、非同質な2-of-3クorum構成を採用しています：
-
シェア1（クライアント制御環境）：金融機関のオンプレミスデータセンターまたは専用HSM環境に直接ホストされます。
-
Share 2（Google Cloud Enclave）：Google Cloudのハードウェア隔離されたConfidential Space環境にホストされています。
-
3つ目（独立復旧またはサードパーティクラウド）：外部クラウド環境（AWSやAzureなど）にホストされるか、独立した復旧受託者がオフラインで保管します。
この2-of-3閾値構造では、任意の2つの認可されたシェアがオフチェーンで協力して標準的な暗号署名を生成できます。基盤となるブロックチェーンにとっては、生成されたトランザクションは通常の単一鍵による振替と全く同じように見えます。
攻撃者が単一の環境を侵害した場合、得られるのは1つの分離された鍵のシェアのみであり、これは数学的に完全な秘密鍵について何の情報も明らかにせず、単独では取引を承認することはできません。逆に、機関のローカルワークステーションが侵害された場合でも、Google Cloudのエニクレが取引が事前設定されたセキュリティポリシーに準拠していることを独立して検証しない限り、攻撃者は資金を単独で移動することはできません。
クラウドホスト型鍵管理における歴史的な懸念は、ホストレベルの特権昇格です。クラウドサーバーのオペレーティングシステムやハイパーバイザーが侵害された場合、特権を持つ管理者がシステムメモリ（RAM）に保存されている暗号情報の確認を試みる可能性があります。
Googleは、機密計算ハードウェアをバックアップする信頼できる実行環境（TEE）であるGoogle Cloud Confidential Space内で、そのMPC署名ノードを実行することでこのリスクを軽減しています：
ハードウェアメモリ暗号化：Confidential Spaceは、プロセッサレベルのメモリ暗号化（AMD SEV-SNPなど）を活用し、キーのシャアと中間署名計算を、ホストオペレーティングシステムからアクセスできないハードウェアキーを使用してRAM内で暗号化したまま保持します。
暗号的証明：キーの一部にアクセスする前、または署名ラウンドを開始する前に、エニクレは、コンテナイメージとファームウェアのベースラインの正確な暗号ハッシュを検証するハードウェア由来の証明トークンを生成します。ソフトウェアイメージがいかなる形で変更された場合でも、証明チェックは失敗し、署名プロセスはブロックされます。
制限された管理アクセス：Confidential Spaceは、標準的なrootアクセスや対話型デバッグ機能を削除する厳格なワークロード隔離を実施し、クラウドインフラストラクチャの管理者ですらアクティブなエニグマ内にあるデータを閲覧できなくします。
鍵のシャアの抽出からの保護は、保管の課題の一部しか解決しません。実際には、多くの機関セキュリティインシデントは、 compromisされたAPI資格情報、フィッシング攻撃、または悪意のあるトランザクションに署名させるために有効なシステムをだます不正な内部承認に起因しています。
事前署名ポリシー検証エンジン
アプリケーション層での不正な振替を防ぐため、Google Cloudは、Confidential Spaceエニグマ内に決定論的なポリシー検証エンジンを組み込みます。GoogleのMPCノードが閾値署名ラウンドに参加する前に、提案されたトランザクションペイロードは、許可された送信先アドレス、最大取引額制限、速度制限、時間帯ウィンドウ、複数承認者クオラム署名などの機関が定義したガバナンスルールに照合されます。
コンピュータが侵害されたエンドポイント端末が、承認されていないアドレスへの振替、または許可されたしきい値を超える振替を要求した場合、エニグマは暗号的シェアの計算が行われる前に署名要求を拒否します。
積極的シークレットシェアリング（キー共有更新）
長期間にわたって高度な攻撃者が複数のノードを段階的に侵害するリスクを軽減するため、アーキテクチャはプロアクティブなシークレット共有（PSS）、すなわちキーシェアのローテーションまたはリフレッシュをサポートしています。
定期的なスケジュールに従うか、人員の変更に応じて、参加ノードは数学的リフレッシュプロトコルを実行します：
-
ノードが協力して、新しい暗号化シェアのセットを計算します。
-
以前のキーのシャアは永続的に無効化され、上書きされました。
-
基盤となるマスターパブリックキーとオンチェーンのウォレットアドレスは完全に変更されていません。
これにより、攻撃者が1か月以内に1つの鍵の一部を盗んだとしても、次の予定された鍵の更新が行われるとその断片は無効になります。これにより、機関は資金を新しいブロックチェーンアドレスに移動したり、オンチェーンのガス代を支払ったりすることなく、定期的に基盤となるセキュリティ情報をローテーションできます。
金融機関が複数年にわたる視野で保管インフラを評価する中、量子コンピューティングへの備えを含む長期的な暗号学的柔軟性が重要なアーキテクチャ上の考慮事項となっています。標準的な楕円曲線スキーム（secp256k1およびEd25519）は、十分に強力でフォールトトレラントな量子コンピューターによって将来的に脆弱になる可能性のある数学的問題に依存しています。
Google Cloudの初期のMPC導入は、資格情報の盗難、単一障害点、内部者との共謀などの即時の運用上の脅威の解決に焦点を当てていますが、プラットフォームは暗号学的モジュラリティを念頭に設計されています。ポリシー編成とAPIレイヤーを下層の署名プリミティブから分離することで、このアーキテクチャは、ブロックチェーンネットワークおよび国際標準化機関（NISTなど）が量子耐性署名仕様を最終決定した際に、将来的な量子耐性暗号（PQC）および量子安全な伝送標準に対応できるように構築されています。
Google Cloudによる機関向けマルチパーティ計算インフラの展開は、企業向けデジタル資産セキュリティの継続的な成熟を示している。DKLs23閾値署名プロトコルとハードウェア認証済みコンフィデンシャルスペースエニグマ、および非均質な2-of-3鍵分散を組み合わせることで、このプラットフォームは署名速度やマルチチェーン対応性を犠牲にすることなく、金融機関が鍵の単一障害点の脆弱性を軽減するのを支援する。2027年までの商業提供に向けたこのサービスは、クラウド統合型MPCが、銀行や資産運用会社がトークン化資産をスケールして安全に管理する方法において、今後ますます重要な役割を果たす可能性がある。
Google Cloud Multi-Party Computeとは何ですか？
Google Cloud マルチパーティコンピューティング（MPC）は、2027年初頭の商用リリースに向け現在プライベートプレビュー段階にある、機関向けデジタル資産の鍵管理および署名インフラストラクチャプラットフォームです。これは閾値暗号技術を使用して、プライベートキーの管理を複数の環境に分割し、ブロックチェーントランザクション署名時の単一障害点を排除します。
なぜGoogleは2027年に商業的提供をターゲットにしているのですか？
2026年末に招待制のプライベートプレビューを実施することで、パートナー銀行および機関資産運用者はセキュリティ監査、ポリシー統合、コンプライアンステストを実施できます。2027年初頭の一般提供目標は、EUのMiCA制度や銀行の暗号資産曝露に関する進化するバーゼ委員会の基準など、成熟した規制枠組みの下での機関の採用拡大と整合しています。
GoogleのMPCは、オンチェーンのマルチシグとどのように異なりますか？
オンチェーンのマルチシグスマートコントラクトは、複数の個別の署名をブロックチェーン上で直接検証するため、ガスコストが増加し、承認構造が公開され、ブロックチェーン固有のスマートコントラクト対応が必要です。GoogleのMPCは、強化されたDKLs23プロトコルを使用して、マルチパーティ承認と閾値計算をオフチェーンで実行し、複数のブロックチェーンで動作する単一の標準署名を出力します。これにより、手数料が低く、プライベートなガバナンスルールが実現されます。
MPCテクノロジーはすべての暗号資産保管リスクを排除しますか？
あらゆるセキュリティアーキテクチャも、すべてのリスクを排除することはできません。MPCは、完全な秘密鍵を1か所に保存することに伴う単一障害点を排除しますが、機関はフィッシング、エンドポイントの侵害、および不十分な内部ガバナンスに対しても引き続き対策を講じる必要があります。Googleの設計は、異種の分割鍵シェアをハードウェアで隔離されたConfidential Spaceエニクレーブと事前署名ポリシーチェックを組み合わせることで、これらの運用リスクを軽減します。
免責事項: このページは、お客様の便宜のためにAI技術を使用して翻訳されています。最も正確な情報については、元の英語版を参照してください。