学习100篇 Web3 安全文章 | 区块链运营私钥安全 ③ | 第三篇：区块链运营中的私钥安全现状——私钥存储与签名模块

原创

nccgroup
nccgroup

Ice ThirdSpace

2026年10月21日 10:00
广东

去阅读

原文地址：

www.nccgroup.com/research/state-of-the-art-of-private-key-security-in-blockchain-ops-3-private-key-storage-and-signing-module

本系列包括：

1. 概念、钱包类型与签名策略。
2. 常见托管方案架构。
3. 私钥存储与签名模块，即本文。
4. 审批与策略。

自行实现热钱包或运营密钥管理方案的项目，必须回答一个主要问题：私钥存在哪里？

不过，在讨论存储之前，我们先看看唯一应该有权使用这些密钥的组件。

签名模块

中心化区块链项目架构中的一个常见错误，是没有专门的签名组件。

更糟糕的情况是，将明文私钥分散到多个微服务，让所有服务都可以签名。只要其中一个组件被外部攻击者或内部人员攻陷，项目私钥就会泄露。

签名模块能够使用私钥签署区块链交易，但不一定能访问私钥明文。

具体方式取决于实现：它可以获得调用 HSM 或 KMS 中密钥的权限，也可以在安全 Enclave 内部解密和使用密钥。

多数情况下，签名模块应作为独立服务，运行在专门加固的环境中，遵循最小权限原则，并尽量减少攻击面。

为了减少甚至避免暴露服务端接口，也可以让签名模块主动连接另一个服务，并使用双向认证。

作为有权使用密钥的组件，它是整个区块链运营架构中最关键的部分之一。在中心化托管环境中，它属于单点故障位置。其设计或实现漏洞可能危及私钥；如果模块被攻陷，私钥保护的所有资产或能力都可能受到影响。

签名模块至少包含两个部分：

1. 签名业务逻辑：接收交易，并使用私钥签名的自定义代码。
2. 私钥存储：安全保存签名所需密钥的位置。

签名业务逻辑

最基本的签名服务，是从可信来源接收交易或消息，再使用私钥完成签名。

根据实现方式，它可能只连接 HSM 或云 KMS 请求签名，也可能直接获取私钥进行签名。其中一个最重要的要求，是正确验证签名请求。

例如，系统规定交易必须先通过不同参与者或策略的链下审批，那么签名模块就需要确认交易已经正确获得批准，避免对任意送达服务的未审批交易签名。

可以通过验证请求确实来自审批模块，或由审批模块对请求进行密码学签名来实现。

下面的例子中，审批模块将待签交易放入消息队列。签名模块取出交易后，先验证审批模块的签名，再签署交易。

警告：如果有人能够向消息队列注入待签消息，会发生什么？如果操作缺乏密码学签名保护，就可能绕过审批。

运营密钥的存储方式

明确签名模块之后，再介绍一些基于硬件的私钥保护方式，以及签名模块如何使用它们。

以下示例经过简化，用于突出主要架构模式。

实际托管方案通常组合多种方式，同时保护私钥机密性和操作完整性。例如，将云 KMS 与 Enclave 连接，或结合 HSM、Enclave 和 MPC 签名。

硬件安全模块：HSM

HSM 是专门的抗篡改设备，可以配置为密钥不能离开设备，只能用于签名请求。

配置 HSM 时，最重要的是确保没有允许导出私钥的选项。私钥应在 HSM 内部生成，并且不可导出。

HSM 也支持不同形式的备份与恢复操作。

安全 Enclave

安全 Enclave 是硬件隔离的执行环境，通常用于在不暴露私钥的情况下执行密钥操作。

常见例子包括 Intel SGX，以及 AWS Nitro Enclaves 等云端方案。下图展示了 SGX Enclave 内的签名服务。

但不能盲目信任 Enclave 一定能保护密钥。近期的 WireTap 和 Battering RAM 漏洞，再次提醒了我们这一风险。

如果某个漏洞允许攻击者从 Enclave 提取秘密，会发生什么？

如果这意味着你的环境彻底失守，就说明还需要额外缓解措施。

一种有效方式，是要求多个物理分散的 Enclave 共同签署操作，例如通过 MPC 实现。

这样，即使某个 Enclave 被攻陷，攻击者仍需要控制其他多个 Enclave；理想情况下，它们位于不同且相互隔离的位置。

Enclave 没有持久化存储，因此其保护的秘密需要安全保存在外部。

典型做法是：在 Enclave 内生成私钥，随后进行密封，即使用硬件密钥加密，再保存至外部，确保只有在 Enclave 内才能解封、解密。

下图简化展示了 Enclave 内签名模块解封外部密钥并签署交易的过程。

云密钥管理系统：KMS

云 KMS 在底层 HSM 之上增加软件服务层，便于集成、扩展，并由提供商管理安全更新，但也引入了对第三方提供商的依赖，以及潜在的监管合规问题。

专用 HSM 提供更强的控制与隔离，但维护和安全管理投入也更高。

有时，签名模块在 Enclave 内执行，同时连接 HSM 或 KMS。

例如，作者介绍了 AWS Nitro Enclaves 与 AWS KMS 的结合方式：通过密码学证明机制限制只有符合指定配置的 Enclave 才能执行相应 KMS 操作。Nitro Enclave 内的签名模块可以借助 KMS 安全保护私钥。

应该避免的存储位置

危险：作者不建议使用以下方式保存私钥，认为它们相比前面的方案具有更高的固有风险。

软件存储：

• 秘密管理服务：通常用于保存 API Key 等秘密，但由于其中的秘密可以被取回，作者不建议用其保存私钥。
• 本地加密 Keystore：例如 Ethereum Keystore 格式，仍然依赖解密口令。如果口令较弱，可能遭受暴力破解。

其他不安全的位置：

• 环境变量：没有秘密管理服务时经常采用，但服务器被攻陷或内部人员滥用权限时，密钥可能暴露。
• 配置文件：许多 GitHub 项目要求将私钥写进 .env。将私钥明文保存在容易被提交至代码仓库的位置，非常危险；遗憾的是，这种要求在开源项目中相当常见。
• 数据库：明文保存私钥时，SQL 注入或内部访问可能导致泄露。
• 源码硬编码：开发者可能只是“临时”写入私钥，直到代码被意外上传至公开仓库。

MPC 与多签架构中的密钥存储

除了上述位置，参与交易签名的密钥还可能保存在其他地方。这对 MPC、多签钱包尤其重要。

某些中心化方案也会在需要人工审批时，使用额外私钥保护审批过程。

硬件钱包：例如 Ledger、Trezor。个人或小团队经常用其管理冷钱包、温钱包，也常见于 MPC 或多签方案。

浏览器钱包：更多用于用户主动发起的操作，而不是机构运营钱包。MetaMask、Rabby 是常见例子。浏览器扩展钱包可以直接与 Web3 应用交互，也可以连接硬件钱包，或通过 WalletConnect 连接托管方案。

移动钱包：作者介绍，现代 Android、iOS 设备可借助安全芯片、Android KeyStore 或 iOS KeyChain 等能力保护设备上的密钥，并结合生物识别。

移动设备随身携带且持续联网，因此常用于签名和审批。作者以 Fireblocks 应用为例，说明用户如何通过移动设备安全环境保存密钥材料，并批准操作。

其他软件方案：自动化或无人值守操作，也可能需要额外设备参与门限签名。例如 Fireblocks Co-Signer 持有参与签名的密钥材料，可以在签名前执行额外检查。

我们已经介绍了密钥存放在哪里、签名模块如何使用它们，以及需要避免的常见问题。

下一篇将讨论审批、多方授权和策略检查，也就是决定哪些操作应该被签名的控制机制。

本篇总结

• 将签名能力集中到独立、加固的模块，减少私钥在微服务间扩散。
• 签名模块必须验证审批，不能因为请求来自内网或消息队列就直接签名。
• HSM、KMS、Enclave 保护的是不同层面的能力，需要结合业务逻辑设计。
• 应分别检查两件事：攻击者能否取走私钥，以及能否调用私钥完成恶意签名。
• 单个安全硬件失陷后的影响，也应纳入威胁建模。
• .env

、环境变量和数据库中的私钥，容易把普通应用入侵升级为资金事件。