Google Cloud 上的机构比特币托管

为了保护机构比特币储备，同时避免单点泄露，您可以使用 Google Cloud 多方计算将签名密钥分布在硬件隔离的 enclave 中。本文档比较了 Cloud Key Management Service (Cloud KMS) 和 Cloud HSM 与多方计算，评估了这两种比特币托管安全模型，并提供了参考拓扑。

将比特币托管服务迁移到云端时，您可以在两种密钥管理架构之间进行选择：

  • 单密钥硬件安全模块 (HSM)：Cloud KMS 和 Cloud HSM 在物理 HSM 边界内管理静态加密密钥。
  • 分布式阈值签名：多方计算将密钥份额分布在由 HSM 信任根密钥支持的硬件隔离可信执行环境 (TEE) 中。

Cloud KMS 和 Cloud HSM 支持企业信封加密和 Web 公钥基础架构。不过，它们并非专为比特币托管原语而设计，例如比特币改进提案 32 (BIP32) 下的分层确定性 (HD) 密钥派生、BIP340 Schnorr 签名和精细的多方治理。

基于云的比特币托管面临的主要挑战

下表总结了在评估用于比特币托管的标准云密钥管理服务时遇到的三个主要挑战，以及多方计算如何满足每项要求。

要求 Cloud KMS 和 Cloud HSM 中的限制 多方计算如何满足此要求
BIP32 密钥派生

多租户 Cloud HSM 分区专为静态、扁平密钥管理（例如企业信封加密）而设计。为了在共享云环境中保持 hypervisor 级安全性，云服务商不允许使用自定义 HSM 固件模块，因此 Cloud HSM 无法以原生方式计算 BIP32 派生路径。

由于此限制，Cloud KMS 需要扁平密钥架构。应用必须跟踪离散密钥资源，或在未加密的主机内存中派生子密钥。

多方计算使用 DKLS23 单调跨度程序的线性同态来在本地计算非强化 BIP32 派生路径。每个节点独立计算公钥标量偏移调整 (IL)，并将该偏移应用于其本地密钥共享，无需进行网络通信。

在单密钥钱包中，如果父级扩展公钥 (xpub) 和一个非强化子级私钥同时泄露，攻击者就可以计算出父级私钥。多方计算消除了这种风险，因为子私钥 (kchild) 不会以明文形式组装。它们仅作为分布式、临时本地共享（s1'、s2'）存在于硬件加密的 TEE 内存中。
单点入侵

完整的私钥位于单个物理 HSM 边界内。授权凭据泄露或内部威胁会暴露整个钱包。

完整的私钥不会以明文形式存在于任何单个位置。密钥共享在数学上分布在独立的计算节点上。
算法敏捷性（Schnorr 和 Taproot）

物理 HSM 硬件周期较慢。在 secp256k1 曲线上添加对椭圆曲线或签名方案（例如 BIP340 Schnorr）的支持需要进行多年的硬件重新认证。

加密操作在硬件隔离的机密虚拟机安全区内运行，这使得多方计算能够采用协议更新，而无需修改物理 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 级边界交互，其中强化的子派生会在主机内存中公开父密钥。

此架构提供托管式 FIPS 140-2 3 级验证，并生成比特币网络接受的低 S 归一化 secp256k1 椭圆曲线数字签名算法 (ECDSA) 签名。不过，它也给比特币托管带来了两个架构限制：

  • 密钥管理碎片化：由于 Cloud HSM 无法计算 BIP32 派生路径，因此您的应用必须在 Cloud KMS 中跟踪数百万个离散的 CryptoKey 资源 ID，从而移除单根恢复工作流。
  • 内存泄露风险：为了执行强化派生，应用必须将根种子导出到主机内存中，这会破坏硬件安全边界。

分布式多方计算阈值模型

多方计算实现了 DKLS23 阈值 ECDSA 协议的强化扩展。在 AMD SEV-SNP 硬件加密安全区内的 Confidential Space 中运行的独立节点会生成并持有数学密钥共享，而不是生成单个完整密钥。如需详细了解该协议，请参阅 DKLS23 加密背景。

下图展示了多方计算如何跨由独立 HSM 密钥加密密钥支持的 TEE 节点分配签名：

比特币交易请求路由到两个 TEE 节点，这两个节点运行 DKLS23 协议，并通过 Cloud HSM 和 Cloud EKM 解封密钥共享。

这种分布式阈值模型具有三大主要安全优势：

  • 无完整私钥：任何单个实体设备、安全区或操作员都不持有完整私钥。
  • 基于硬件的信任根：密钥共享在静态时通过密钥加密密钥 (KEK) 进行加密，这些 KEK 受 FIPS 140-2 3 级 Cloud HSM 分区或通过 Cloud External Key Manager 连接的外部本地 HSM 保护。
  • 强制证明解密：仅当硬件证明报价确认节点运行经过验证、未篡改的多方计算容器映像时，Cloud KMS 才会将密钥共享解封装到安全区内存中。

BIP32 和 Taproot 的加密机制

在评估比特币托管的阈值签名时，请检查协议是否支持分层地址派生和 Taproot 调整，而无需添加节点间网络轮次。

非强化 BIP32 加法派生

BIP32 将非强化子私钥派生定义为模标量加法：

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

由于多方计算使用基于单调跨度程序的线性秘密共享方案，因此参与者节点可在本地派生子密钥共享，而无需进行网络通信。下图展示了这种零轮次本地派生流程：

节点 1 和节点 2 在本地独立计算 HMAC-SHA512 标量调整，更新份额 1，同时保持份额 2 不变，并运行在线 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 Contracts 进行交互，而无需重新生成或重新共享密钥。

架构比较

下表从核心托管维度对 Cloud KMS、Cloud HSM 与多方计算进行了比较。

建筑维度 Cloud KMS 和 Cloud HSM 多方计算
加密基元 secp256k1 曲线上的单签名 ECDSA Ed25519 曲线上的阈值 ECDSA (DKLS23) 和阈值 Edwards 曲线数字签名算法 (EdDSA)，可扩展到 secp256k1 曲线上的阈值 Schnorr
硬件边界 物理 PCIe HSM 卡 锚定到 Cloud HSM 信任根的 AMD SEV-SNP Confidential Space 隔离区
BIP32 HD 钱包支持 手动管理离散 Cloud KMS 密钥 零轮本地加法密钥共享调整
实体密钥保护 FIPS 140-2 3 级 FIPS 140-2 3 级，适用于封装密钥共享的 HSM 驻留 KEK
签名延迟时间 (p95) 20-50 毫秒 在分布式区域中，延迟时间不到 1,000 毫秒（亚秒级）
凭证泄露的影响范围 如果调用方凭据或 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 钱包允许个人备份一个助记词，并确定性地派生多个账号的地址。
  • 单点故障：根助记词种子代表一个完全的单点故障。如果攻击者破解了该助记词或物理备份，则所有账号中的每个派生子私钥都会暴露。

下图说明了单个根种子遭到入侵如何导致每个派生的子账号都暴露：

一个由 12 或 24 个单词组成的根助记词种子，分支到子密钥 1、子密钥 2 和子密钥 N，其中泄露种子会暴露所有派生的子私钥。

移除具有阈值签名的根种子

在零信任机构云架构中，不需要人类可读的根助记词种子。多方计算则完全消除了中央根私钥。由于任何单台机器或备份介质上都不存在明文形式的完整私钥，因此您无需使用单短语地址恢复。多方计算不会从一个密钥派生密钥树，而是在加密隔离的飞地之间分配独立的密钥共享。

比较多方计算中的 BIP32 派生路径

如果您的集成需要 BIP32 兼容性才能支持外部地址跟踪器或会计工作流，请比较下表中的两种技术实现路径。

实现流程 加密机制 安全和暴露情况 延迟时间和签名性能
采用多方计算的非强化 BIP32

局部加法调整：s1' = (s1 + IL) mod n。

每个节点都会独立计算公共标量偏移量 (IL)，并将该偏移量应用于其本地密钥共享。
  • 单密钥风险：在非 MPC 钱包中，如果父级公钥 (xpub) 和一个子级私钥同时泄露，攻击者便可反向计算出父级私钥。
  • MPC 缓解措施：子私钥 (kchild) 不会以明文形式组装，而是仅作为临时分布式密钥共享 (s1', s2') 存在于硬件加密的 TEE 内存中，从而防止子密钥到父密钥的恢复。
  • MPC 节点之间无需进行网络通信即可派生子密钥。
  • 在签名之前以本地 CPU 速度运行。
  • 支持通过加密的 gRPC 通道实现亚秒级签名延迟时间（p95 小于 1 秒）。
采用多方计算的强化 BIP32

通过秘密共享的父级密钥材料计算得出的交互式多方 HMAC-SHA512 哈希。
  • 通过对父私钥进行哈希处理来防止子密钥到父密钥的升级，这会增加协议的复杂性。
  • 在多方安全区环境中，父密钥已经过密钥共享并受到保护，不会外泄，因此不会提供额外的安全优势。
  • 需要 MPC 节点之间进行多轮交互式网络通信，才能通过秘密共享输入评估阈值 HMAC-SHA512 线路。
  • 增加签名延迟时间并造成交易处理瓶颈。

关于机构托管的建议

多方计算支持非强化 BIP32 加法派生，以便与现有系统和外部地址跟踪器兼容。对于专用机构托管，请考虑改用直接在多方计算中管理的独立阈值密钥：

  • 消除单根依赖项：在隔离的 enclave 中生成、轮替和备份独立的密钥共享，而不是从单个根密钥派生密钥作为数学偏移量。
  • 提高算法敏捷性：将编排层与比特币特定的 BIP32 派生路径分离，以便您可以在一个治理模型下采用非 ECDSA 签名方案，例如智能合约网络的 Ed25519 签名方案。
  • 降低签名复杂性：管理离散阈值密钥，以简化数据库查找、保持交易请求简洁，并最大限度地减少签名延迟。