マルチパーティ コンピューティングと Confidential Space によってデジタル アセットを保護する方法
Google Cloud Japan Team
※この投稿は米国時間 2023 年 4 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
以前のブログ投稿で、マルチパーティ コンピューティング（MPC）によって単一侵害点に起因するリスクを減らし、ポリシーに準拠した即時のデジタル アセット トランザクションを促進できる理由を説明しました。こうした MPC ソリューションを迅速かつ簡単に実装する方法の一つとして、企業は Google Cloud の Confidential Space を利用できます。このソリューションには、アセットをオンライン状態に維持してリアルタイムのトランザクションに対応できるというメリットがあります。また、プライバシーが保護された方法で、複数の関係者が連携してポリシー準拠のトランザクションを処理できます。
この記事では、Confidential Space を使用して MPC 準拠のブロックチェーン署名機能を実装するためのリファレンス アーキテクチャを紹介します。このアーキテクチャについて説明するためのシナリオとして、A 社がデジタル アセットを B 社に転送する必要があるとします。どちらの会社も個々の秘密鍵を使用するのではなく MPC 準拠のモデルを採用しているため、トランザクションの署名において、共同で所有する分散鍵を使用して連携できます。この仕組みのメリットとして、A 社は自社で保管する秘密鍵の制御を維持しながら、ユーザー エクスペリエンスを簡素化し、運用を効率化できます。
Wells Fargo でブロックチェーン プラットフォームのアドバンスド テクノロジー担当シニア バイス プレジデントを務める Vitaliy Dorum 氏は次のように語ります。「Wells Fargo は常に、フィンテックの新たな機会を探し求めており、未来のカスタマー エクスペリエンスを再定義する新しい傾向を注視しています。たとえば Web3 テクノロジーが主流になりつつあるなか、Wells Fargo では次世代のデジタル プロダクトへの安全なアクセスを可能にするソリューションを探しています。そのために、Google Cloud のデジタル アセット チームと連携して、さまざまな Google Cloud サービスをテストしています。その一つが、マルチパーティ コンピューティングと組み合わせた Confidential Space です。Confidential Space は明らかに、Web3 環境での安全なソリューションに不可欠な要素となるでしょう。」
このアーキテクチャを実現するために不可欠な要素を理解していただくために、技術的な設定を説明したうえで、A 社から B 社へのデジタル アセットの転送をトリガーする承認および署名プロセスの概要を説明します。
このアーキテクチャは、図 1 のようになっています。
このアーキテクチャは分散された次の環境からなります。
1 つの MPC オペレーター用環境（図の右側）: この環境を使用して、ブロックチェーン トランザクションの署名プロセスをオーケストレートする機密性の高いワークロードを実行します。このワークロードは、管理インフラストラクチャ プロバイダが操作できます（この例では、A 社が直接操作します）。この環境でオペレーターが書式なしテキストのシークレット マテリアルにアクセスできるチャンスはどこにもありません（オペレーターが署名プロセスに影響を与えることもできません）。
N 個の共同署名者用環境（図の左側）: 共同署名者はこれらの環境を使用して、承認ステップとトランザクション署名ステップに連携して対処します。ここに示されているすべての共同署名者用環境は Google Cloud 内で実行されていますが、他の環境で実行することもできます（例: モバイル デバイス、オンプレミス システム、Google Cloud 以外のクラウド）。
MPC オペレーター用環境は、次の要素で構築されています。
Confidential Space - ここにある Confidential Space 仮想マシン（VM）上で機密性の高いワークロードが実行されます。Confidential Space は次の 2 つの中核的な要素を使用します。
1 - 強化されたベースイメージ。機密性の高いコンテナ化されたワークロードを、Confidential Computing の高信頼実行環境（TEE）内でリスクを最小限に軽減した状態で実行します。
2 - 証明書サービス。運用環境を認証し、ワークロードの整合性を検証するとともに、これらの保証（クレーム）を MPC ポリシー ロジックで使用できるようにします。
脆弱性分析機能が組み込まれた、（ブロックチェーン トランザクションに署名する）機密性の高いワークロードのイメージを保管するセキュアなストレージです。
ノード ホスティング - Ethereum（または他の）ブロックチェーン ノードをホストするために使用します。GCP 内でホストすることも、ブロックチェーン ノード エンジンを使用してホストすることもできます。
共同署名者用環境には、さまざまな形式があります。このリファレンス アーキテクチャでは次の構成要素を使用しています。
部分的な署名を発行するための Cloud KMS / HSM。
Cloud KMS と Cloud HSM は、さまざまなアルゴリズム（ECDSA を含む）で署名を生成するために使用されます。いずれのアルゴリズムでもシンプルな統合 API が使用されるので、カスタムコードは不要で、HSM アプライアンスを管理する必要もありません。
署名者が Cloud KMS または Cloud HSM サービスで生成された署名を使用しないユースケースの場合、他の場所で生成されたシークレット マテリアルをラップするために、これらのサービスが使用されることになります。
Cloud IAM（Workload Identity プール）
Workload Identity プールで、（Confidential Space 証明書サービスで規定された）属性の条件が満たされていることを確認してから、Cloud KMS / HSM 内の鍵へのアクセスが認可された ID にアクセス権を付与します。
アーキテクチャの概要を説明したところで、次は、MPC 署名プロセスを実行するために必要なステップを見ていきましょう。まずは、設定のステップです。
最初に、ワークロード イメージを取得します。このイメージには、MPC 署名アプリケーションと、トランザクションの署名プロセスをトリガーするために必要となる関連ポリシー ロジックが含まれています。
アプリケーション イメージは Google Artifact Registry でホストされています（Confidential Space VM が接続可能である限り、他のリモート レジストリを使用することもできます）。
次に、Cloud KMS / HSM で鍵を生成し、認可されたワークロードにこれらの鍵へのアクセス権を付与する Cloud IAM ポリシーを作成します。
最後に、ワークロード イメージを Confidential Space VM にデプロイします。
設定が完了したら、次はトランザクションです。トランザクションのステップは次のとおりです（図 2 に示すステップが、署名リクエストごとに繰り返されます）。
署名されていないトランザクション リクエストが MPC 署名アプリケーションに取り込まれます。
証明書サービスによって、Confidential Space 運用環境とワークロード イメージの整合性が検証されます。検証に合格すると、証明書サービスにより（検証に基づいて）クレームが生成されます。このクレームは、MPC 署名アプリケーションが上記で作成された鍵にアクセスするときに使用します。
MPC 署名アプリケーション（ワークロード）は、必要な数の承認を受け取ると、共同署名者の KMS にアクセスし、署名付きトランザクションの作成をリクエストします。
すべての共同署名者の署名が集まった時点で、ワークロードがブロックチェーン トランザクションに署名して、それをローカルのブロックチェーン ノードに送信します。
*注: 実装ごとに固有のメカニズムが使用されることを踏まえ、ここではこのステップを大幅に単純化して説明しています。
MPCVault の CEO を務める Jason Li 氏は、「Google Cloud の Confidential Computing を使用すれば、最小限のコード変更で、当社のマルチパーティ コンピューティング（MPC）用の TEE ランタイムに AMD の SEV をシームレスに統合できます。このインテグレーションにより、ソリューションのセキュリティがさらに強化されるので、機関投資家の暗号資産を大きな確信をもって大規模に保護できるようになります」と語ります。
代替手段や補完的なアプローチもあります。たとえば、Google Cloud 以外のサービスを使用して共同署名を生成したり、共同署名者が交代で、それぞれの環境でブロックチェーン署名を作成したりするといったアプローチです（より分散型のアーキテクチャ）。このブログ投稿が、Google Cloud での MPC に対するさまざまなアプローチの発想のきっかけとなることを願います。
TEE に対する脅威を防ぐ方法を含め、Confidential Space の構成要素について詳しく確認したい場合は、セキュリティ管理の検証について説明しているブログ投稿と Google の How-To ドキュメントをご覧ください。また、Google Cloud の他の Web3 プロダクトおよびソリューションもご確認ください。
この投稿に貢献してくれた、プロダクト マネージャーの Nelly Porter と Rene Kolga、カスタマー エンジニアの Devon Yarbrough に感謝の言葉を贈ります。
- Google Cloud、セキュリティ アーキテクト Chris Diya
- Google Cloud、デジタル アセット担当プリンシパル Bertrand Portier
