Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Google Cloud での機関向けビットコインカストディ

単一の侵害ポイントを作成せずに機関のビットコイン準備金を保護するには、 Google Cloud マルチパーティコンピューティングを使用して、ハードウェア分離されたエンクレーブに署名鍵を分散します。このドキュメントでは、Cloud Key Management Service（Cloud KMS）と Cloud HSM をマルチパーティコンピューティングと比較し、ビットコインの保管に関する両方のセキュリティモデルを評価して、リファレンストポロジを示します。

ビットコインの保管をクラウドに移行する場合は、次の 2 つの鍵管理アーキテクチャのいずれかを選択します。

単一鍵ハードウェアセキュリティモジュール（HSM）: Cloud KMS と Cloud HSM は、物理 HSM 境界内で静的暗号鍵を管理します。
分散しきい値署名: マルチパーティコンピューティングは、HSM ルートオブトラスト鍵を基盤とするハードウェア分離された高信頼実行環境（TEE）に鍵共有を分散します。

Cloud KMS と Cloud HSM は、エンタープライズエンベロープ暗号化とウェブ公開鍵基盤をサポートしています。ただし、Bitcoin Improvement Proposal 32（BIP32）に基づく階層的決定的（HD）鍵導出、BIP340 シュノア署名、きめ細かいマルチパーティガバナンスなど、ビットコインのカストディプリミティブ向けには設計されていません。

クラウドベースのビットコインカストディにおける主な課題

次の表に、ビットコインカストディの標準的なクラウド鍵管理サービスを評価する際に直面する 3 つの主な課題と、マルチパーティコンピューティングが各要件にどのように対応するかをまとめます。

要件 Cloud KMS と Cloud HSM の制限事項マルチパーティコンピューティングがこの要件に対応する方法

BIP32 鍵導出

要件	Cloud KMS と Cloud HSM の制限事項	マルチパーティコンピューティングがこの要件に対応する方法
BIP32 鍵導出	マルチテナント Cloud HSM パーティションは、エンタープライズエンベロープ暗号化などの静的でフラットな鍵管理用に設計されています。共有クラウド環境でハイパーバイザレベルのセキュリティを維持するため、クラウドプロバイダはカスタム HSM ファームウェアモジュールを許可していません。そのため、Cloud HSM は BIP32 派生パスをネイティブに計算できません。この制約により、Cloud KMS ではフラットな鍵アーキテクチャが必要になります。アプリケーションは、個別の鍵リソースを追跡するか、暗号化されていないホストメモリで子鍵を導出する必要があります。	マルチパーティコンピューティングでは、DKLS23 単調スパンプログラムの線形準同型を使用して、非強化 BIP32 導出パスをローカルで計算します。各ノードは、公開スカラーオフセット調整（`I_L`）を個別に計算し、ネットワーク通信ラウンドなしで、そのオフセットをローカル鍵共有に適用します。単一鍵ウォレットでは、親の拡張公開鍵（`xpub`）と、強化されていない子の秘密鍵の両方が侵害されると、攻撃者は親の秘密鍵を計算できます。マルチパーティコンピューティングでは、子秘密鍵（`k_child`）が平文で組み立てられないため、このリスクが排除されます。これらは、ハードウェアで暗号化された TEE メモリ内に、分散された一時的なローカル共有（`s₁'`、`s₂'`）としてのみ存在します。
単一障害点	完全な秘密鍵は、単一の物理 HSM 境界内に存在します。認証情報が侵害されたり、内部脅威が発生したりすると、ウォレット全体が公開されます。	完全な秘密鍵は、どの場所にも平文で存在しません。鍵共有は、独立したコンピューティングノードに数学的に分散されます。
アルゴリズムの俊敏性（Schnorr と Taproot）	物理 HSM ハードウェアのサイクルは遅いです。`secp256k1` 曲線で BIP340 シュノアなどの楕円曲線または署名スキームのサポートを追加するには、複数年にわたるハードウェアの再認証が必要です。	暗号オペレーションは、ハードウェアで分離された Confidential VM エンクレーブ内で実行されます。これにより、マルチパーティコンピューティングは、物理 HSM 境界を変更せずにプロトコルの更新を採用できます。

マルチテナント Cloud HSM パーティションは、エンタープライズエンベロープ暗号化などの静的でフラットな鍵管理用に設計されています。共有クラウド環境でハイパーバイザレベルのセキュリティを維持するため、クラウドプロバイダはカスタム HSM ファームウェアモジュールを許可していません。そのため、Cloud HSM は BIP32 派生パスをネイティブに計算できません。

この制約により、Cloud KMS ではフラットな鍵アーキテクチャが必要になります。アプリケーションは、個別の鍵リソースを追跡するか、暗号化されていないホストメモリで子鍵を導出する必要があります。

マルチパーティコンピューティングでは、DKLS23 単調スパンプログラムの線形準同型を使用して、非強化 BIP32 導出パスをローカルで計算します。各ノードは、公開スカラーオフセット調整（I_L）を個別に計算し、ネットワーク通信ラウンドなしで、そのオフセットをローカル鍵共有に適用します。

単一鍵ウォレットでは、親の拡張公開鍵（xpub）と、強化されていない子の秘密鍵の両方が侵害されると、攻撃者は親の秘密鍵を計算できます。マルチパーティコンピューティングでは、子秘密鍵（k_child）が平文で組み立てられないため、このリスクが排除されます。これらは、ハードウェアで暗号化された TEE メモリ内に、分散された一時的なローカル共有（s₁'、s₂'）としてのみ存在します。

単一障害点

完全な秘密鍵は、単一の物理 HSM 境界内に存在します。認証情報が侵害されたり、内部脅威が発生したりすると、ウォレット全体が公開されます。

完全な秘密鍵は、どの場所にも平文で存在しません。鍵共有は、独立したコンピューティングノードに数学的に分散されます。

アルゴリズムの俊敏性（Schnorr と Taproot）

物理 HSM ハードウェアのサイクルは遅いです。secp256k1 曲線で BIP340 シュノアなどの楕円曲線または署名スキームのサポートを追加するには、複数年にわたるハードウェアの再認証が必要です。

暗号オペレーションは、ハードウェアで分離された Confidential VM エンクレーブ内で実行されます。これにより、マルチパーティコンピューティングは、物理 HSM 境界を変更せずにプロトコルの更新を採用できます。

Cloud KMS とマルチパーティコンピューティングを比較する

Google Cloudでデジタルアセット署名インフラストラクチャを設計する場合は、単一鍵 HSM モデルと分散しきい値モデルを評価できます。

単一鍵の Cloud KMS と Cloud HSM モデル

Cloud KMS のデプロイでは、Cloud HSM は、FIPS 140-2 レベル 3 検証済みの物理 HSM 内で EC_SIGN_SECP256K1_SHA256 アルゴリズムを直接使用する非対称署名鍵を生成します。次の図は、子鍵を導出するときにアプリケーションレイヤが Cloud HSM とどのようにやり取りするかを示しています。

Cloud HSM FIPS 140-2 レベル 3 境界とやり取りする 2 つの標準 VM アプリケーションレイヤ。強化された子派生により、ホストメモリ内の親鍵が公開されます。

このアーキテクチャは、マネージド FIPS 140-2 レベル 3 検証を提供し、ビットコインネットワークが受け入れる低 S 正規化 secp256k1 楕円曲線デジタル署名アルゴリズム（ECDSA）署名を生成します。ただし、ビットコインのカストディには、次の 2 つのアーキテクチャ上の制限があります。

鍵管理の断片化: Cloud HSM は BIP32 派生パスを計算できないため、アプリケーションは Cloud KMS で数百万の個別の CryptoKey リソース ID を追跡し、単一ルートの復元ワークフローを削除する必要があります。
メモリの露出リスク: 強化された派生を実行するには、アプリケーションがルートシードをホストメモリにエクスポートする必要があります。これにより、ハードウェアセキュリティ境界が破られます。

分散型マルチパーティコンピューティングしきい値モデル

マルチパーティコンピューティングは、DKLS23 しきい値 ECDSA プロトコルの強化された拡張機能を実装しています。単一の完全な鍵を生成する代わりに、AMD SEV-SNP ハードウェア暗号化エンクレーブの Confidential Space 内で実行される独立したノードが、数学的な鍵共有を生成して保持します。プロトコルの詳細については、DKLS23 の暗号化の背景をご覧ください。

次の図は、マルチパーティコンピューティングが、独立した HSM 鍵暗号鍵を基盤とする TEE ノードに署名を分散する方法を示しています。

ビットコイントランザクションリクエストが、DKLS23 プロトコルを実行し、Cloud HSM と Cloud EKM を介して鍵共有をラップ解除する 2 つの TEE ノードにルーティングされます。

この分散しきい値モデルには、主に 3 つのセキュリティ上のメリットがあります。

完全な秘密鍵がない: 完全な秘密鍵を保持する実機、エンクレーブ、オペレーターは存在しません。
ハードウェアアンカーのルートオブトラスト: 鍵共有は、FIPS 140-2 レベル 3 の Cloud HSM パーティションまたは Cloud External Key Manager を介して接続された外部オンプレミス HSM によって保護された鍵暗号鍵（KEK）で保存時に暗号化されます。
証明書による復号: Cloud KMS は、ハードウェア証明書の見積もりで、ノードが検証済みの改ざんされていないマルチパーティコンピューティングコンテナイメージを実行していることが確認された場合にのみ、鍵共有をエンクレーブメモリにラップ解除します。

BIP32 と Taproot の暗号化メカニズム

ビットコインカストディのしきい値署名を評価する際は、プロトコルが階層アドレス導出と Taproot の調整をサポートしていることを確認してください。ノード間のネットワークラウンドを追加する必要はありません。

非強化 BIP32 加算導出

BIP32 では、非強化子秘密鍵の導出をモジュラースカラー加算として定義しています。

\[ k_{\text{child} } = (k_{\text{par} } + \text{parse}_{256}(I_L)) \bmod n \]

マルチパーティコンピューティングでは、単調スパンプログラムに基づいて構築された線形秘密分散スキームを使用するため、参加ノードはネットワーク通信ラウンドなしで子鍵共有をローカルに導出します。次の図は、このゼロラウンドのローカル導出フローを示しています。

ノード 1 とノード 2 が、HMAC-SHA512 スカラー調整をローカルで個別に計算し、シェア 2 を変更せずにシェア 1 を更新して、オンライン DKLS23 署名セッションを実行します。

BIP341 Taproot キーの調整

この線形プロパティは、基盤となる鍵共有の分散を変更することなく、BIP341 Taproot 鍵の調整もサポートします。

\[ Q = P + t \cdot G \quad \text{where} \quad t = H_{\text{TapTweak} }(P \parallel \text{MerkleRoot}) \]

しきい値署名セレモニーに参加する前に、参加者ノードはスカラー調整（t）をローカル鍵共有に直接適用します。この機能により、鍵を再生成または再共有することなく、Taproot スクリプトツリー、Ordinals、Discreet Log Contract を操作できます。

アーキテクチャの比較

次の表は、Cloud KMS と Cloud HSM を、コアカストディディメンション全体でマルチパーティコンピューティングと比較したものです。

アーキテクチャのディメンション	Cloud KMS と Cloud HSM	マルチパーティコンピューティング
暗号プリミティブ	`secp256k1` 曲線上のシングル署名 ECDSA	`Ed25519` 曲線上のしきい値 ECDSA（DKLS23）としきい値エドワード曲線デジタル署名アルゴリズム（EdDSA）。`secp256k1` 曲線上のしきい値 Schnorr に拡張可能
ハードウェア境界	物理 PCIe HSM カード	Cloud HSM ルートオブトラストにアンカーされた AMD SEV-SNP Confidential Space エンクレーブ
BIP32 HD ウォレットのサポート	個別の Cloud KMS 鍵の手動管理	ゼロラウンドのローカル加算鍵共有の調整
物理キーの保護	FIPS 140-2 レベル 3	鍵共有をラップする HSM 常駐 KEK の FIPS 140-2 レベル 3
署名のレイテンシ（p95）	20 ～ 50 ミリ秒	分散リージョン間で 1,000 ミリ秒（1 秒未満）
認証情報侵害の影響範囲	呼び出し元の認証情報または Identity and Access Management（IAM）ポリシーが侵害された場合、鍵が完全に公開される	攻撃者が独立したエンクレーブと KEK のしきい値を同時に侵害しない限り、不正な署名は行われません。
監査可能性	Cloud Audit Logs	Cloud Audit Logs と Key Access Justifications のハードウェア認証ログ

BIP32 からしきい値鍵管理への進化

社内のデジタルアセットカストディプラットフォームを設計する場合は、個々のハードウェアウォレット用に作成された派生標準と、機関ガバナンス用に設計された分散鍵管理を区別します。BIP32 はアドレストラッキングに広く使用されていますが、マルチパーティコンピューティング（MPC）アーキテクチャ内のセキュリティを BIP32 派生ツリーに依存することは冗長であり、運用が複雑になる可能性があります。

単一シード BIP32 ウォレットの歴史的背景

BIP32 は、しきい値暗号とハードウェアエンクレーブが広く利用可能になる前に、個人の自己管理の制約を考慮して設計されました。

ルートシードの依存関係: 初期のビットコインカストディは、12 語または 24 語の人が読める単一のニーモニックフレーズを物理的に保護することに依存していました。
単一バックアップの復元: BIP32 HD ウォレットを使用すると、1 つのシードフレーズをバックアップし、複数のアカウントにわたってアドレスを決定論的に導出できます。
単一障害点: ルートニーモニックシードは、完全な単一障害点を表します。攻撃者がそのフレーズまたは物理バックアップを侵害すると、すべてのアカウントの派生した子秘密鍵がすべて公開されます。

次の図は、1 つのルートシードが侵害されると、派生したすべてのお子様用アカウントがどのように公開されるかを示しています。

12 語または 24 語のルートニーモニックシードが子キー 1、子キー 2、子キー N に分岐し、シードが侵害されると、派生したすべての子秘密鍵が公開されます。

しきい値署名を使用してルートシードを削除する

ゼロトラストの機関向けクラウドアーキテクチャでは、人間が読めるルートニーモニックシードは必要ありません。マルチパーティコンピューティングでは、中央のルート秘密鍵が完全に排除されます。完全な秘密鍵が平文で単一のマシンまたはバックアップメディアに存在しないため、単一フレーズのアドレス復元は必要ありません。マルチパーティコンピューティングでは、1 つのシークレットから鍵ツリーを導出するのではなく、暗号的に分離されたエンクレーブに独立した鍵シェアを分散します。

マルチパーティコンピューティングにおける BIP32 導出パスの比較

統合で外部アドレストラッカーまたは会計ワークフローに BIP32 互換性が必要な場合は、次の表で 2 つの技術的な実装パスを比較してください。

実装パス暗号化メカニズムセキュリティと露出のプロファイルレイテンシと署名のパフォーマンス

マルチパーティコンピューティングを使用した非強化 BIP32

実装パス	暗号化メカニズム	セキュリティと露出のプロファイル	レイテンシと署名のパフォーマンス
マルチパーティコンピューティングを使用した非強化 BIP32	ローカルの加算調整: `s₁' = (s₁ + I_L) mod n`。各ノードは、公開スカラーオフセット（`I_L`）を個別に計算し、そのオフセットをローカル鍵共有に適用します。	単一鍵のリスク: MPC 以外のウォレットでは、親公開鍵（`xpub`）と 1 つの子秘密鍵の両方が侵害されると、攻撃者は親秘密鍵を逆算できます。 MPC 緩和策: 子秘密鍵（`k_child`）は平文で組み立てられず、ハードウェア暗号化された TEE メモリ内にエフェメラルな分散鍵共有（`s₁'`、`s₂'`）としてのみ存在するため、子から親への鍵の復元を防ぐことができます。	子鍵を導出するために、MPC ノード間のネットワーク通信ラウンドがゼロである必要があります。署名前にローカル CPU 速度で実行されます。暗号化された gRPC チャネルを介して、1 秒未満の署名レイテンシ（p95 が 1 秒未満）をサポートします。
マルチパーティコンピューティングによる強化された BIP32	秘密共有された親鍵マテリアルに対して計算された、インタラクティブなマルチパーティ `HMAC-SHA512` ハッシュ。	親の秘密鍵をハッシュ化することで、子から親への鍵の昇格を防ぎます。これにより、プロトコルの複雑さが大幅に増します。親鍵がすでに秘密分散され、引き出しから保護されているマルチパーティエンクレーブ環境では、セキュリティ上のメリットは追加されません。	秘密分散入力に対してしきい値 `HMAC-SHA512` 回路を評価するには、MPC ノード間で複数のインタラクティブネットワークラウンドが必要です。署名のレイテンシが増加し、トランザクション処理のボトルネックが発生します。

ローカルの加算調整: s₁' = (s₁ + I_L) mod n。

各ノードは、公開スカラーオフセット（I_L）を個別に計算し、そのオフセットをローカル鍵共有に適用します。

単一鍵のリスク: MPC 以外のウォレットでは、親公開鍵（xpub）と 1 つの子秘密鍵の両方が侵害されると、攻撃者は親秘密鍵を逆算できます。
MPC 緩和策: 子秘密鍵（k_child）は平文で組み立てられず、ハードウェア暗号化された TEE メモリ内にエフェメラルな分散鍵共有（s₁'、s₂'）としてのみ存在するため、子から親への鍵の復元を防ぐことができます。

子鍵を導出するために、MPC ノード間のネットワーク通信ラウンドがゼロである必要があります。
署名前にローカル CPU 速度で実行されます。
暗号化された gRPC チャネルを介して、1 秒未満の署名レイテンシ（p95 が 1 秒未満）をサポートします。

マルチパーティコンピューティングによる強化された BIP32

秘密共有された親鍵マテリアルに対して計算された、インタラクティブなマルチパーティ HMAC-SHA512 ハッシュ。

親の秘密鍵をハッシュ化することで、子から親への鍵の昇格を防ぎます。これにより、プロトコルの複雑さが大幅に増します。
親鍵がすでに秘密分散され、引き出しから保護されているマルチパーティエンクレーブ環境では、セキュリティ上のメリットは追加されません。

秘密分散入力に対してしきい値 HMAC-SHA512 回路を評価するには、MPC ノード間で複数のインタラクティブネットワークラウンドが必要です。
署名のレイテンシが増加し、トランザクション処理のボトルネックが発生します。

機関投資家向けカストディに関する推奨事項

マルチパーティコンピューティングは、既存のシステムや外部アドレストラッカーとの互換性を確保するため、非強化 BIP32 加算導出をサポートしています。専用の機関カストディの場合は、マルチパーティコンピューティングで直接管理される独立したしきい値鍵への移行を検討してください。

単一ルートの依存関係を排除する: 単一のルートキーから数学的なオフセットとして鍵を導出するのではなく、分離されたエンクレーブ内で独立した鍵共有を生成、ローテーション、バックアップします。
アルゴリズムの俊敏性を高める: オーケストレーションレイヤをビットコイン固有の BIP32 派生パスから切り離し、1 つのガバナンスモデルで、スマートコントラクトネットワークの Ed25519 署名スキームなどの非 ECDSA 署名スキームを採用できるようにします。
署名の複雑さを軽減する: 個別のしきい値鍵を管理して、データベース検索を簡素化し、トランザクションリクエストを簡潔に保ち、署名のレイテンシを最小限に抑えます。