加密支付的密钥管理与操作安全

2025-2026年大多数重大安全事件，最终都可以追溯到密钥或签名——一个被攻陷的签名工具、一个泄露的管理员密钥，或一个被网络钓鱼攻击的操作员。（我们在近期加密支付攻击案例分析中对这些案例进行了单独拆解。）问题的共同线索往往在于密钥的授权方式、存储方式，以及如何用其签名。

问题在于，多签、MPC、热/冷钱包和HSM常被当作同一层面的可选方案来讨论，混淆它们会让选型陷入混乱。实际上，它们是三个相互独立的维度，一套真正的密钥管理方案是三者的组合。本文逐一梳理每个维度，然后介绍将它们整合在一起的混合架构、签名基础设施与操作规范，以及更广泛的运营层面——API与基础设施隔离、人员与供应商管理、域名与身份安全，以及最新也最容易被忽视的风险：能够访问资金的AI智能体。

私钥、助记词，以及"在我设备上"不等于安全

这一切的核心是私钥：一串密码学随机数。持有私钥的人可以签署交易，转移对应地址上的资金。它是对一个地址资金的终极控制权，也是终极的单点风险所在。

助记词（通常为12或24个单词，即BIP-39标准）是私钥的人类可读编码。"分层确定性"（HD）规则可以从一个助记词派生出数千个私钥和地址。这意味着助记词至少与单个私钥同等敏感，甚至更甚：泄露一个私钥，你会损失一个地址；泄露助记词，你会损失整个钱包。

有一个常见误解值得直接点明：有些人认为，只要签名设备和钱包在自己手中，密钥处于离线状态，就不会出什么问题。问题在于，普通软件和硬件钱包中的私钥和助记词是可以被导出的。任何拥有设备内部访问权限或备份的人，都可以导出并复制私钥，然后在任何地方控制资金——而无需接触那台"自己的"设备。

因此，"密钥在我自己的设备上"并不等于"没有人可以拿走它"。真正重要的是私钥能否被导出。正如下文所示，HSM是唯一在硬件层面阻止导出的选项。

三个独立维度，而非一个连续谱

在选择方案之前，先厘清你实际上在回答的三个问题会很有帮助。

授权模型：单签、多签还是MPC/TSS

单签意味着一个私钥控制一切——是最简单的方案，也是最大的单点故障。

多签需要N个独立私钥中的M个共同签名（例如3-of-5），每个签名者持有一个完整的、独立的私钥。在支持智能合约的链上，合约多签（Safe是事实标准）将这一逻辑实现在合约中，签名和阈值规则可在链上公开验证——代价是每笔交易消耗更高的Gas，且每次更换签名者都需要修改合约配置。这里还有一个容易被忽视的弱点：合约多签的签名基础设施仍不够成熟。Safe的execTransaction调用在硬件钱包上往往显示为一长串calldata，签名者难以看清自己实际批准的内容，而生态系统对Clear Signing和交易解析的支持仍然有限。这正是Bybit事件中被利用的攻击面，也正因如此，采用合约多签的公司往往需要引入第三方交易解析和交叉验证来弥补这一缺口。相比之下，比特币等链在脚本层原生支持多签，无需依赖合约。

**MPC（阈值签名，TSS）**并非"将一个完整私钥切成碎片"。真正的MPC使用分布式密钥生成（DKG）：密钥从创建之初就是分布式的，每一方持有一个独立的密钥份额，完整的私钥在任何时刻都不存在。每一方从其份额计算出部分签名，这些部分签名通过密码学协议合并为一个标准签名——这是一种计算，而非字节串的拼接——因此链上的结果与普通单签无法区分。Gas成本正常，跨链兼容性良好，更换签名者或调整阈值无需触碰合约。

值得将MPC/TSS与一种更古老、容易混淆的方法加以区分：Shamir秘密分享（SSS）。SSS将已经存在的完整私钥切分为n个碎片；签名时，收集足够数量的碎片，在内存中重建完整私钥后再签名——而这个重建时刻就是单点故障所在。TSS从不重建；完整私钥永远不会出现。这正是它比SSS更安全的原因。

多签和MPC都消除了单点风险，只是机制不同。多签是多个完整密钥加链上验证：透明，但轮换签名者成本高且繁琐。MPC是多个密钥份额加链下部分签名合并：灵活且成本低，但协调依赖于你的基础设施。

硬件保护：软件、硬件钱包、TEE还是HSM

软件存储将私钥保存在服务器或软件中——最便捷，也最脆弱。硬件钱包（Ledger、Trezor等）将密钥保存在安全芯片中，在设备内部签名，密钥永不离开设备。

TEE（可信执行环境）——如Intel SGX、AWS Nitro或Apple Secure Enclave——在通用CPU上划分出一块隔离的加密内存区域，密钥和签名计算在其中进行，即便拥有操作系统root权限的攻击者也无法访问。它介于软件和HSM之间：强大的逻辑隔离，良好的性能，能够运行任意代码（包括MPC协议），但其物理抗篡改能力和合规认证不及HSM。这也是存储MPC密钥份额最常见的方式——由DKG在enclave内部生成，且从不被移出。例如，Fireblocks将MPC密钥份额分布在多个云的SGX enclave中。

**HSM（硬件安全模块）**是企业级抗篡改硬件，符合FIPS 140-2/3等认证标准，具备物理抗篡改能力和入侵自动清除机制。其最强保证：私钥在硬件内部生成，被标记为不可导出，并且在物理上无法离开设备。这从根本上将HSM与软件和硬件钱包区分开来，也正是HSM适合托管高价值完整私钥的原因。

这一维度与上述授权模型是正交的：多签中的每个完整密钥可以存储在硬件钱包或HSM中，而每个MPC份额通常存储在TEE enclave中。

资金温度：热钱包、温钱包还是冷钱包

这一维度不关心密钥如何存储——只关心私钥对互联网的暴露程度，即资金能以多快的速度、多自动化的方式被转移。

热钱包始终在线，用于即时支付和自动化出款——速度最快，风险最高，通常仅持有总资金的个位数百分比。温钱包在线，但私钥被隔离在受保护的环境中（专用签名服务或HSM），签名流程需要人工参与；用于日常运营结算。冷钱包完全离线且物理隔离，用于大额储备的长期存储——安全性最高，使用最慢，通常持有大部分资金。

需要明确的是，温度从根本上衡量的是私钥的在线暴露程度以及资金的转移便利性；转账频率和资金占比是其结果，而非定义本身。这一维度同样与前两个维度正交：冷钱包可以使用多签加HSM，热钱包也可以使用MPC。

将三者结合，你就得到了完整的视图：授权模型、硬件保护和资金温度相互独立，一套真正的密钥管理方案将三者组合在一起。

常见密钥管理方案

以下是业界通常如何组合这三个维度：

选型的要点在于按资金温度分层，并在每个层级使用最优组合。热钱包需要速度，优先选择MPC。冷钱包需要稳定性和可审计性，优先选择多签加HSM。治理和合约权限需要透明度和可问责性，优先选择合约多签加时间锁。

BlockSec推荐的混合架构

BlockSec推荐按温度分层的混合架构。

热/温钱包：MPC签名。 消除私钥单点故障，保持低签名延迟，适合高频支付。份额应分散在不同的物理位置和安全域中。

冷钱包：多方控制加链上可审计性，适合大额储备。采用哪种实现方式取决于你的团队在链上运营方面的成熟度——共有两条路径：

• 追求最大透明度，且链上运营成熟的团队： 使用合约多签（如Safe的3-of-5），阈值规则和每个签名均可在链上公开验证。在比特币上，使用脚本层原生多签，每个签名者用HSM或硬件钱包保护各自的密钥。需要注意的是，合约多签的签名解析工具链仍不成熟，团队必须自行添加交叉验证——这里的运营工作并不轻松。
• 对链上执行不够熟悉、希望降低运营复杂度的团队： 使用MPC阈值签名，份额存储于TEE，同时引入独立第三方作为共签人，在每次签名前进行交易安全检查。这一方案绕开了合约多签的工具缺口，并将独立第三方验证直接内嵌于签名阈值中。

合约升级和策略变更：多签加时间锁。 任何涉及权限变更的操作都需要多人审批和时间延迟。

无论选择哪条路径，有几个参数始终重要。使用至少3个签名者，阈值至少为总数的50%但低于总数——避免N-of-N，因为一个不可达的签名者将阻塞签名并锁定资金；如果每个签名者都不可或缺，每个人都会成为胁迫或绑架的高价值目标。低于总数的阈值保留了冗余，并降低了针对任何单一签名者的价值。每个签名者还应在每个多签中使用全新的专用地址，永远不与其他多签或个人钱包共用，签名者在地理位置、组织角色和法律实体上应多元化——随着钱包风险等级的提升，分散程度也应相应提高。

风险等级应通过正式评级来确定：根据每个钱包对业务的财务影响、协议依赖程度和声誉风险进行评级，并将每个等级映射到不同的阈值、审批流程和监控密度。每6个月复审一次评级，并在TVL大幅变化、合约升级或安全事件发生后立即复审。

盲签与签名环境隔离

盲签是指你的签名工具只显示calldata哈希，而不显示交易实际执行的内容。这不是一个假设性风险：签名时，签名者无法从界面中理解交易的真实含义，这一缺口是Bybit事件的直接原因之一——用于签名的前端或后端被攻陷，签名者在合约本身没有任何漏洞的情况下批准了一笔恶意交易。

锁定上述三个维度的前提是，围绕它们的签名流程同样经过充分加固。以下几项规范适用于所有方案：

• 强制使用签名硬件。 所有生产环境的多签操作均应使用硬件钱包，要求屏幕足够大以显示完整的交易摘要，支持Clear Signing，具备PIN保护和固件完整性验证，且供应链仅限于制造商或授权经销商——收货时验证真伪。
• 物理隔离的签名环境。 签名应在气隙设备上运行，不与日常办公网络共享；高价值操作需使用专用签名设备。将签名服务部署在独立的安全域中，与业务逻辑和前端物理隔离。签名节点不应直接暴露于公共互联网——仅通过VPN或专线连接。签名操作日志应单独存储，业务系统无法修改。
• 独立交易验证。 签名前通过独立渠道验证交易内容——专用终端、硬件设备或第三方交易模拟/风险服务。这项检查最好由独立第三方完成，而不仅仅依靠自己的前端或后端——仅信任内部系统本身就是一个单点故障。一旦内部前端或后端被攻陷（如Bybit事件），签名者在屏幕上看到的是被篡改的虚假信息，自己验证自己等于没有验证。出款路径尤其需要这条独立的防线。
• Clear Signing与交叉验证。 使用能解析交易语义的工具，让签名者看到"向0x1234...转账1,000 USDC"，而非一串calldata，并通过至少两个独立工具或界面交叉核验关键参数——链ID、目标地址、calldata、金额、nonce和操作类型——确保一致。
• 人工与自动化双重检查。 自动化规则引擎进行初步筛查，大额交易由人工在发出前确认。
• 零信任与备份。 将签名服务、业务逻辑和前端界面部署在不同的安全域中，并为主签名界面、RPC和区块链浏览器保留备用方案，确保单一供应商或服务故障不会阻塞紧急签名。

多签操作规范

密钥和阈值的选择只能解决一部分问题。以下几项操作规范同样至关重要。

多签台账。 维护一份涵盖所有多签的统一记录，每条记录至少包括：地址、链、签名阈值、风险等级、用途、签名者地址、所控合约、链上角色和上次审查日期。安全敏感变更应在24小时内更新台账，常规变更在3天内完成。

签名者生命周期管理。 在入职前通过让候选地址签署特定消息来验证地址，并使用独立工具进行核查。按风险等级设定移除离职或被撤销签名者权限的SLA——紧急情况48-72小时内，关键情况7天内，其他情况14天内。每季度进行一次访问审查，确认每位签名者仍控制其密钥，并至少每年对签名者进行一次培训更新，内容涵盖交易验证、应急程序以及社会工程/钓鱼防御，培训后进行实操评估。

助记词与备份保护。 严禁任何形式的数字存储——不得存入云盘、相册或文档。将备份分散存储在不同地理位置，能够在自然灾害、盗窃和操作员失联的情况下恢复。任何单个地点都不应持有完整的恢复信息。

安全通信。 签名者之间使用主备两套通信渠道，部署在不同平台上，各自强制执行MFA、端对端加密和仅限受邀成员访问。签名前通过独立渠道验证签名者身份——视频通话、口令和经认证的第二渠道——以防被劫持的IM账号冒充签名者。

应急响应SLA。 按事件严重程度设定签名者响应时间，例如紧急情况2小时内，时效性情况2-12小时，常规情况24-48小时。每季度对签名者的可达性进行实测（而非仅停留在文件层面），并每年至少进行一次端到端应急演练，覆盖密钥泄露、签名者不可达、通信渠道被攻陷以及应急协议操作等场景。

多签链上监控。 监控签名者/阈值变更、超阈值转账、nonce跳跃、与未知地址的交互、失败交易、Module/Guard变更，以及异常的提案人钱包余额。监控基础设施本身需要具备抗篡改能力。

API安全

API安全是支付后端的第一道防线。这意味着：通过API密钥加HMAC签名或FIDO2/WebAuthn进行身份验证；限速以防止暴力破解和滥用；通过CDN/WAF服务进行DDoS防护；对每个输入参数进行严格验证以防止注入攻击；以及日志审计，确保每次API调用都产生完整的审计追踪。

签名环境需要与上述所有措施相隔离，而不仅仅受其保护——这也是为什么签名服务应部署在独立安全域中，如上文所述。

运营安全：人员、供应商与独立审计

2026年的多起重大事件涉及社会工程攻击——包括虚假招聘、IT支持冒充以及AI换脸等手段。防御需要三个层面协同发挥作用。

培训与评估是第一位的：所有接触签名系统、生产凭证或敏感操作的人员，须在入职时完成安全培训，每年更新一次，且在流程发生变更后30天内更新培训内容。

职责分离同样重要：发起、审批和执行不能由同一人完成，管理员账户不能直接进行出款操作。签名等高敏感操作应使用专用设备——全盘加密、自动锁屏——硬件钱包在不使用时存放于保险箱，所有远程访问均通过VPN进行。

第三方需要同等的纪律要求。在选择供应商前进行尽职调查，每年重新审查关键供应商的合规和安全状态，并为第三方访问设定明确的范围、用途和有效期——到期或项目结束后立即撤销。在授予任何访问权限前，独立核实第三方人员身份。

上述措施都不应仅依赖内部自查。定期进行独立第三方安全评估，至少涵盖渗透测试、红队演练以及代码和智能合约审计。逐项修复发现的问题，并在下一轮评估中核实整改情况。

开发与基础设施安全

近年来多起重大支付和加密货币事件追溯到被攻陷的开发流程——而合约和签名逻辑本身完全没有问题。这意味着开发和基础设施层需要与签名层同等重视，涵盖四个方面。

开发环境隔离要求将开发账户与特权账户（签名、云管理）分开，使生产凭证不可被开发环境访问，并将开发工具和扩展列入审批名单。

代码仓库和供应链需要分支保护、签名提交和主分支多人审查。仅从官方仓库拉取依赖，锁定版本并进行错字抢注检查，同时运行自动密钥扫描，一旦发现密钥暴露立即撤销并轮换。

在CI/CD方面，流水线配置变更需要多方审批和版本控制，并实现可复现构建。密钥通过专用管理器（如Vault或云KMS）管理——生产密钥不应直接对人类可访问——SAST和依赖扫描是部署的前提条件，而非可选项。

在基础设施和云方面，通过即时供应、多方审批和时间限制授予特权访问。为紧急情况保留"应急账户"，但每次使用均触发告警。保持完整的审计日志和管理员操作实时告警，并定期演练备份和灾难恢复。

域名、DNS与身份：被低估的攻击面

域名和DNS是加密货币领域中被严重低估的攻击面——许多钓鱼事件和盗窃事件都可以追溯到被攻陷的注册商账户或被劫持的DNS。保护用户发起资金操作的域名，与保护签名环境同等重要。

将注册商账户视为高权限账户进行管理：强制执行硬件密钥MFA，并对转移、删除或更换域名服务器等关键变更要求带外二次确认。在DNS和邮件方面，为关键域名启用DNSSEC，使用CAA限制哪些CA可以签发证书，并为所有发信域名配置SPF/DKIM/DMARC（p=reject）——同时将不发信的域名也设为明确拒绝，以防伪造。

持续监控DNS记录变更、域名服务器委托变更以及证书透明度日志中的异常签发，使用不依赖于被监控域名的监控基础设施。记录域名劫持和未授权转移的处置流程，每年演练一次，并设置分级到期预警和自动续费，以防过期域名成为入侵入口。

身份和账户几乎是所有横向移动的起点。组织账户的完整清单加上严格的MFA标准，比任何单点防御都更有效。

从账户清单入手：注册每一个组织账户——社交媒体、电子邮件、SSO/IdP、注册商、托管平台、代码仓库、云根账户、关键SaaS——明确所有者，并定期审查。对高权限账户强制执行具备抗钓鱼能力的MFA（FIDO2/WebAuthn硬件密钥），绝不以短信或语音作为主要因素——SIM卡劫持、SS7攻击和语音钓鱼均可绕过这些方式。这是防范账户接管最有效的单项措施。

强制使用密码管理器和唯一强密码，禁止共用登录凭证，将恢复邮件和手机号限制在组织域名范围内——将恢复码存储在安全存储中，而非个人邮件或云端。人员离职时，在24小时内撤销其所有访问权限，并轮换其接触过的任何共享凭证，同时对高权限账户持续运行行为监控和凭证泄露监控。

AI智能体的架构为何在设计上本身不安全

支付公司越来越多地使用AI工具和智能体来提升开发和运营效率——但这开辟了一个新的攻击面，若处理不当，将直接威胁资金安全。

有一点容易被忽视：AI智能体不只是一个回答问题的模型，它是一台能够读取外部内容、调用工具、持有凭证并执行动作的机器。风险的根源在于：它将从不可信内容中读取的文本视为需要执行的指令。

这意味着攻击者不需要任何漏洞，也不需要盗取账户。在文档、网页、代码注释或PR描述中隐藏一句话，就能劫持智能体的行为，使其泄露数据或执行未授权操作。这被称为提示注入攻击，到2026年已被证明可以直接升级为远程代码执行——微软演示了一个单一提示在运行智能体的机器上启动程序，GitHub Copilot、Cursor和MCP基础设施也各自披露了CVSS评分9.6或更高的RCE漏洞。

对于任何特权场景，情况更为严峻。开发或运营智能体默认继承其操作员的文件访问权限、shell权限和数据库密钥。2026年一项涵盖主流编码智能体的研究发现，所有智能体都可以被提示注入攻破，自适应攻击成功率超过85%。任何处理不可信输入的智能体，都应被视为持有你凭证的潜在内鬼——供应链也是高风险环节：2026年3月，一个被投毒的AI网关依赖包在公共仓库上存在了3小时，被下载了近47,000次。

如何在不失去资金控制权的前提下获得AI智能体的效率

方法是对智能体施加与不可信代码相同的约束，体现在五项控制措施上：

• 隔离执行 — 在沙箱中运行智能体的工具执行，使提示注入无法触及真实的shell、生产密钥或签名环境。
• 最小权限 — 仅授予智能体的工具、数据库密钥和MCP服务单次操作所需的最低权限，绝不使用"完全访问"凭证。
• 资金操作的人工审批关卡 — 对于涉及转账、签名或权限变更的任何操作，智能体只能提议，绝不能自动执行。这里同样适用独立人工审批原则，与上文签名验证的原则一脉相承。
• 在架构层面将可信指令与不可信数据分离 — 不要期望模型"自行区分"。
• 供应链锁定 — 对AI相关依赖采用与常规代码仓库相同的版本锁定和来源验证措施。

这些约束不必停留在理论层面。BlockSec的开源项目Web3 Companion是一个安全智能体钱包的参考实现（MIT许可证，研究预览版）。它允许AI智能体协助用户准备链上交易，同时将私钥和最终授权完全置于智能体的访问范围之外。其威胁模型将智能体本身视为不可信方——整个系统必须保证，即使智能体被完全攻陷，也无法转移用户的资金。

该架构依托三个核心点。密钥隔离意味着只有一个独立的签名模块（一个独立的Go进程）能够接触私钥——智能体获得交易意图ID，可以请求签名，但永远看不到密钥。密钥使用信封加密存储（AWS KMS或本地AES-256），明文仅在签名瞬间存在于内存中，随后立即清零。

在广播之前，交易依次通过四个层级，每个层级都假设前一个层级已经失效：交易模拟（解码calldata，预测回滚）、交易对手风险评分、纯Go硬性策略限制（单笔上限、每日预算、白名单——智能体均无法修改），以及最终的通行密钥人工确认（WebAuthn指纹或人脸识别，纯软件攻击无法伪造）。密钥、策略和通行密钥构成三个独立的信任边界，突破其中一个，另外两个仍然完好。

AI智能体确实能够切实提升效率，但它不能对资金和签名拥有单独控制权。将其作为助手置于最小权限沙箱中运行，让人类对资金和签名操作做出最终决策。

总结

密钥管理不是一个决策，而是三个相互独立的决策，然后加以组合：谁必须签名、密钥或份额实际存储在哪里，以及它对互联网的暴露程度。针对每个资金层级选择正确的组合，以加固的签名基础设施为支撑，并以上述操作规范将其整合在一起——这是BlockSec应对2025-2026年大多数密钥和签名相关事件背后缺口的框架。由于攻击面现在已经超出密钥本身的范畴——延伸至API、人员、供应商、代码流水线、域名、身份和AI智能体——每个层面都需要同等的处理方式：假设前一个层面已经失效，并在资金可以移动的任何环节保留人工参与。

如需了解密钥管理与运营安全在支付系统完整合规体系中的全貌，请下载我们的加密支付安全与合规手册（PDF）。

常见问题

MPC与多签的实际区别是什么？ 多签是多个完整私钥，每个在链上单独验证——透明，但轮换签名者成本高且繁琐。MPC（阈值签名）是多个密钥份额，生成方式决定了完整私钥永远不会存在；部分签名在链下合并为一个签名——灵活且成本低，但依赖于你的协调基础设施。

Shamir秘密分享（SSS）与MPC是一回事吗？ 不是。SSS将已经存在的完整私钥切分成碎片，签名时在内存中重建完整密钥，这使得重建时刻成为单点故障。真正的MPC（TSS）永远不会重建完整私钥——每一方只从自己的份额计算出部分签名。

TEE与HSM有什么区别？ TEE（如Intel SGX、AWS Nitro或Apple Secure Enclave）是通用CPU上一块隔离的加密区域，可以运行任意代码（包括MPC协议）——逻辑隔离强，但物理抗篡改能力和认证级别不及HSM。HSM是专用的抗篡改硬件，私钥在其内部生成，被标记为不可导出，并且在物理上无法离开。

温钱包是什么，它与热钱包或冷钱包有何不同？ 温钱包在线，但将私钥隔离在受保护的环境中（专用签名服务或HSM），签名流程需要人工参与，用于日常结算——介于始终在线、全自动的热钱包与完全离线、物理隔离的冷钱包之间。

BlockSec对冷存储的具体建议是什么？ 这取决于团队的链上运营成熟度：链上运营成熟的团队可以使用合约多签（如Safe的3-of-5），每位签名者的密钥存储于HSM或硬件钱包；希望降低运营复杂度的团队可以使用MPC阈值签名（份额存储于TEE），并引入独立第三方共签人进行交易安全检查。

什么是盲签，为什么危险？ 盲签是指签名界面只显示calldata哈希，而不显示交易实际执行的内容。签名者无法验证自己正在批准的真实含义，这是Bybit事件的直接原因之一。

AI智能体可以被信任用于加密支付操作吗？ 不能给予其单独控制权。AI智能体只应被允许提议资金操作，绝不能自动执行——转账、签名和权限变更均需要独立的人工审批，智能体应在最小权限沙箱中运行。

什么是提示注入，严重程度如何？ 提示注入将指令隐藏在不可信内容中——文档、网页、代码注释或PR描述——从而劫持AI智能体的行为。到2026年，它已在主流编码工具的已披露漏洞中升级为远程代码执行，CVSS评分达到9.6或更高。

防范账户接管最有效的单项措施是什么？ 具备抗钓鱼能力的MFA——对高权限账户强制执行FIDO2/WebAuthn硬件密钥，并且绝不以短信或语音作为主要因素，因为SIM卡劫持、SS7攻击和语音钓鱼均可绕过这些渠道。