超越安全存储，第 1 部分：设计安全的支付与签名流程

Binance 对其 2026年10月30日 事件的初步说明称，被盗的部署令牌使攻击者得以访问内部签名服务，并在正常出金流程之外发起交易 [1]。按照披露的这条攻击路径，攻击者无需先读取钱包私钥，就能请求签名。

在这里，攻击者针对的是系统的签名能力。包括加密和硬件隔离在内的安全存储可以保护密钥，却无法判断一笔付款是否获得有效的业务授权。这引出了一个问题：未经授权的操作如何获得有效签名？

要回答这个问题，需要追踪业务请求如何变成已签名并执行的交易。通过钱包执行的付款会经过业务授权、交易构建、签名，以及执行与结算等阶段 [2, 3]。下图将对这一工作流程的滥用，与另一条获得签名能力的路径并列展示：利用密码学实现缺陷恢复密钥。

Beyond Secure Storage 系列从真实事件中提炼应对这些风险的设计与实现原则。第 1 部分 Designing Secure Payment and Signing Workflows 探讨攻击者如何在未取得原系统私钥的情况下滥用其签名能力。第 2 部分 Implementing Wallet Cryptography Securely 探讨使攻击者能够恢复密钥并独立签名的实现缺陷。这两条路径都不要求直接窃取受保护的秘密信息。

第 1 节结合真实事件，分析付款流程中的风险和容易被忽略的假设，并据此提出设计与实现方面的检查要点。第 2 节假设这些检查未能阻止未经授权的操作，探讨如何限制由此造成的损失。第 3 节说明如何通过设计审查、审计、渗透测试和演练，验证预防措施与损失控制措施。

1. 通过设计防止未经授权的操作

同一付款流程可以服务于不同的业务目的。下图展示了三种有代表性的托管业务操作：入金确立账户权益，出金依据客户指令进行，资金库转账则执行机构的资金调拨决策。

经过验证的入金会形成账户入账记录，而不会自动产生付款指令。出金需要单独的客户请求和批准；资金库转账则始于机构的资金调拨决策。两者随后都要经过交易构建、签名、执行和结算。在资金池式托管中，账本记录客户权益，无需将每位客户的资产保留在各自的专用地址中。

三种有代表性的托管业务操作。职能分离本身并不意味着身份或权限边界相互独立。

这些操作转移资金的原因各不相同。其他业务操作可能经过相同的阶段，但需要不同的证据或批准。在每个阶段，关键的安全问题都是：付款依据、交易、签名权限的使用以及结算，是否仍与预期操作一致。

这些阶段中的任何一个，都可能成为攻击者影响签名或执行内容的切入点。伪造的请求可能制造出表面上的付款义务；交易构建环节可能将未经批准的操作替换进去；权限遭到侵害可能使签名服务可被访问；执行或结算环节的失误则可能使不应继续有效的权限仍可使用，或触发没有正当依据的付款。

下表将风险对应到工作流程的各个阶段，并列出用于分析这些风险的案例。

1.1 付款依据与授权

在付款进入交易构建和签名阶段之前，机构必须确认请求真实存在、请求方有权转移这笔资金，且指定操作已获得有效批准。仅有客户余额或经过身份验证的内部请求，并不能同时证明这三点。

失效案例：伪造付款依据

在 Bitget 的 2026年9月24日 事件中，攻击者利用一款第三方安全产品获取了高权限内部凭证。根据 Bitget 的官方说明，攻击者利用这些凭证向钱包系统发送欺诈性出金指令，促成了绕过现有风控措施的转账 [4]。这些指令通过内部访问途径进入付款流程，但这种访问权限并不能证明存在合法的客户指令或资金库决策。

BigONE 披露，其热钱包于 2025年7月16日 发生未经授权的资金转移，并表示私钥仍然安全。BigONE Eurasia 将其全球平台的这一事件归因于生产环境中的账户及风控逻辑遭到修改 [5, 6]。这指向一个相关问题：用于证明付款正当性的记录和规则本身也可能被篡改。公开说明没有披露详细的请求记录或签名 API，因此无法据此认定其攻击机制与 Bitget 事件相同。

这些案例揭示了将内部访问权限或账户记录视为充分付款依据的风险：攻击者可能篡改付款决策所依赖的凭证、记录或规则。

需要核查的控制措施

因此，设计与实现审查应检查每项请求是否都能追溯到真实的业务依据，以及提交请求的一方是否也能伪造支持该请求的记录或自行批准该请求。

• 核实请求的来源、完整性与授权。 每笔付款都必须能追溯到真实的客户指令、业务事件或机构决策，并有资金支配权和批准的证据。核实对请求及其支持记录所作的修改是否仍可追踪，并确保伪造或篡改的证据不会仅因来自内部服务或与账户余额相符，就被视为有效授权。
• 使验证和批准独立于请求创建。 提交请求的一方不能同时有能力伪造支持该请求的证据或自行批准请求。在操作权限和管理权限上都要保持这种分离。核查对记录、批准规则或角色分配的修改——包括人工例外处理和恢复程序——是否可能让一方同时控制请求，以及本应否决该请求的检查环节。

在付款依据经过独立确认后，下一个问题是交易是否表达了获批的操作。

1.2 交易构建与验证

付款请求获批后，交易构建器会将其转换为提交签名的未签名数据。完整的交易载荷——包括目标地址、金额、操作以及对钱包控制权的任何更改——必须表达获批的请求。批准一笔转账并不等于授权额外操作；验证时必须检查实际待签名的数据，而不能只看界面中对其所作的描述。

失效案例：已签名操作偏离获批内容

Bybit 原计划将 ETH 从冷钱包转入温钱包。其官方更新将此次入侵归因于 Safe 开发者凭据遭到泄露；攻击者借此进入服务提供商的基础设施，并误导了签名者 [7]。Safe 通过 execTransaction 验证涵盖 to、value、data 和 operation 等交易字段的签名 [15]。但遭到入侵的界面保留了预期转账的外观，却在签名前替换了恶意字段。签名对这些替换后的字节是有效的 [7]。

最终的交易使用 DELEGATECALL 更改了钱包的实现，使攻击者无须原所有者重新批准即可转走资产 [7, 8]。获批的业务操作是转账；实际签署的操作却改变了谁能控制钱包。只检查显示的收款方或交易的即时转账金额，无法确定完整操作是否与批准内容一致。

Kiln/SwissBorg 事件表明，恶意交易也可以通过修改正在运行的交易构建服务引入。Kiln 报告称，一个遭到泄露的 GitHub 令牌使攻击者经由 CI 工作流取得了生产环境凭据。攻击者在不更改已部署镜像的情况下修改了一个正在运行的 Kubernetes pod，使其在返回一笔合法的 Solana 质押停用交易时，一并返回一笔更改提款权限的交易。客户的托管签名者批准了新增的交易；Kiln 称签名发生在 8 月 31 日，事件于 2025年9月8日 被发现 [9]。SwissBorg 也将交易遭篡改归因于服务提供商的基础设施。双方对于当时可用的交易解码工具是否易于使用、是否得到集成存在分歧 [10]。

需要验证的控制措施

Bybit 和 Kiln/SwissBorg 的案例表明，一笔交易可能偏离签名者原本打算批准的内容。设计上必须将批准与完整操作绑定，验证时也必须独立于构建或显示交易的服务，对实际交易进行检查。

• 将批准与完整操作绑定。 批准必须涵盖交易的全部效果，包括资产控制权的任何变更或执行权限的委托 [16]。超出这一范围的变更须重新获得批准。应验证被替换或新增的操作不能沿用合法付款的批准，也不能通过重试重复使用同一项批准来授权额外付款。
• 独立验证交易及其效果。 将实际提交签名的数据与获批的业务操作进行比较，涵盖批次中的每笔交易及其对资产和权限的影响。验证必须独立于构建或显示交易的服务。应检查该服务能否修改验证器或绕过其检查，以及具有误导性的显示内容或被修改的交易是否会被拒绝。

上述检查针对的是交易是否与获批请求一致。签名阶段还带来另一个问题：是否有人能在缺乏必要业务授权的情况下，直接使用密钥，或通过更改访问权限来使用密钥？

1.3 签名授权与密钥使用

经过验证的交易必须由获授权的调用方送达签名服务。密钥策略和管理角色决定谁能使用相关密钥，以及谁能更改这一访问权限。拥有调用签名功能的权限，并不意味着有权批准每笔交易；管理服务的权限也不应形成一条不受检查的签名路径。因此，这一阶段既涵盖对获批操作使用密钥，也涵盖对密钥访问权限的控制权。

失效案例：签名访问权限遭到入侵

Resolv 于 2026年3月22日 发生的事件表明，更改密钥访问策略如何打开一条签名路径。其铸造流程要求用户存入抵押品，并由获授权的链下服务完成发行。官方事后分析追溯了从代码仓库和云环境访问权限，到一个更高权限角色的入侵路径：此前的访问尝试遭拒后，该角色更改了签名密钥的访问策略。这一变更使攻击者在一项同时要求身份级权限和密钥级访问策略授权的云密钥管理服务中获得了签名权限 [11]。

通过改变谁能签名，攻击者无须说服原签名者，便能授权不符合预期抵押关系的发行。这份事件说明证实的是攻击者取得了签名权限的控制权，而非提取了原始私钥材料。

Binance 关于其 2026年10月30日 事件的初步更新描述了另一条取得签名权限的路径。据 Binance 称，遭到入侵的员工设备和一个内部 AI 工具使攻击者得以访问钱包工程师的设备；随后，攻击者使用窃取的容器部署令牌部署容器并运行恶意脚本。攻击者未经授权访问了内部钱包签名服务，并发起了正常出金流程之外的交易 [1]。这一说法将部署权限与签名服务访问权限联系起来，但并未披露被绕过的具体内部权限检查。与 Resolv 报告的密钥策略变更不同，此处披露的切入点是签名服务的运行环境。

需要验证的控制措施

这些案例揭示了在预期业务工作流之外取得或使用签名访问权限的风险。审查应检查每条签名路径是否都强制执行了业务授权，包括通过策略变更或部署权限打开的路径。

• 在每条签名路径上强制执行业务授权。 拥有密钥使用权限，并不等于某项具体操作已获得授权 [17, 18, 19]。应将密钥使用限制在获批的业务范围内，并验证其他调用方或直接访问方式不能绕过这一限制。授权检查必须独立于能够提交任意签名请求的调用方。对于无法强制执行这一要求的路径，应记录这一缺口，并依据第 2 节评估其后果。
• 控制签名权限的变更。 即使某个身份最初无法签名，管理权限和部署权限也可能使其获得签名访问权限 [20, 21, 22]。应将密钥使用权限与更改签名策略、身份或已部署代码的权限分开，并要求对此类变更进行独立批准。应验证任何一方都不能利用其组合权限授予自身签名访问权限，或移除约束该访问权限的业务检查。

授权检查不能在签名签发时就结束：交易仍须在获批条件内执行，其结果也必须得到正确结算。

1.4 执行与结算

签名之后，授权约束仍须贯穿广播、执行，以及相关业务记录和余额预留的结算。签名并不能证明付款已经完成。执行必须始终处于授权范围和有效条件之内；结算必须确定哪项义务已得到履行，以及是否确实还需进一步付款。仅凭已有签名或观察到的一笔转账，不能确立新的付款义务。

失效案例：已签署权限遭滥用与结算反馈

Drift 的案例说明，具有误导性的签名请求如何留下可供日后使用的权限。在其 2026年4月1日 事件中，预先取得的批准被保存在 Solana 持久 nonce 交易中，随后这些交易被提交，用以接管管理权限 [12]。持久 nonce 控制交易的有效性；它不同于密码学签名中使用的秘密 nonce。它使交易能够离线提交或延迟提交，而不受通常的近期区块哈希过期限制，但账户或程序状态的变化仍可能阻止交易执行。推进持久 nonce 会使绑定旧值的交易失效 [23]。

Drift 于 4 月 16 日发布的恢复进展更新提出，使用专用签名设备、在主要签名界面之外进行验证、对关键管理操作设置时间锁，以及为签名者禁用持久 nonce [24]。这些措施既针对签名者批准的内容，也针对已签署操作何时能够执行。它们是作为恢复计划宣布的；该更新并未证实这些措施当时已经部署。

Chainflip 区分客户兑换、流动性提供者（LP）出金，以及称为 fetch 的内部入金归集操作 [25]。在 Tron 上，交易的 memo 字段可以承载兑换指令。Chainflip 在 9 月 15 日对其 2026年9月12日 事件的说明中称，攻击者提交了一笔由验证者签名的 fetch 操作，其中包含由攻击者控制的畸形 memo。见证层误将其上下文解读为兑换失败，除正常的 LP 出金外又发起退款，导致六笔出金被重复支付 [13, 14]。

这一错误将内部资产转移当成了新增客户付款义务的依据。此前，即使转入 Chainflip 金库的转账被封装在其他合约调用中，Chainflip 也会解读其中的 memo。其修复措施将兑换 memo 的解读范围限制为普通 TRX 转账或直接 TRC-20 转账，排除了封装调用 [14]。有效签名的 fetch 操作有其自身目的；执行该操作并不能成为额外退款的依据。

需要核验的控制措施

已签名交易可能在超出预期的时间内仍可执行，执行反馈也可能被误认为新的付款义务。因此，审查应核验执行条件是否得到实际强制执行，以及每笔付款或退款是否对应真实且尚未结清的义务。

• 强制执行已批准的执行条件。 已签名交易仍须受已批准的范围、有效期和取消条件约束。核验旧交易在到期、取消或授权变更后是否仍能执行。将相关条件绑定到已签名操作，并核验链上规则或钱包执行逻辑是否强制执行这些条件；仅有业务系统中的记录并不足够。
• 只结清真实且尚未结清的义务。 每笔付款或退款都必须对应一项真实且尚未结清的义务。保留原始业务事件、付款尝试与已确认结果之间的关联。核验重试、重复通知、结果不确定的操作或内部转账是否会产生无正当依据的付款，并核验用于解读执行证据的规则是否可能被修改以绕过这些检查。

2. 通过设计限制损失并支持事件响应

第 1 节利用事件证据识别了工作流程风险，以及应对这些风险所需的设计和实施检查。在这里，我们假设这些检查未能阻止未经授权的操作，原因可能是遗漏、实施错误或控制措施被绕过。此时，系统设计必须限制攻击者能够转移的金额，核算仍面临风险的资金，并保留检测滥用行为和阻止进一步资金流出的能力。这些损失控制措施必须与预防性控制措施一起，在事件发生前完成设计和测试。

下表概述了限制损失和支持事件响应的三个设计目标。

2.1 独立强制执行的支出限额

即使未经授权的付款通过了前述检查，系统仍应限制该笔及后续付款能够转出的金额。这需要在假定攻击者控制范围之外强制执行预算，同时约束单笔交易和累计支出。如果遭入侵的审批服务或签名方能够停用或绕过已配置的限额，该限额就无法形成这样的约束。

• 独立于付款审批强制执行限额。 通过授权检查的付款仍必须受到在假定攻击者控制范围之外强制执行的支出限额约束。核验所有签名和执行路径（包括替代执行路径 [26, 27]）是否都遵守这些限额，以及攻击者是否无法更改或停用限额的强制执行。无法独立强制执行限额时，不应将已配置的预算称为损失上限。
• 限制累计支出，而不只是单笔付款。 明确每项预算的适用范围、周期和估值依据，并对已完成付款和预留金额进行一致核算。核验重复请求、并发操作和重试是否会导致累计支出超过预算，或使预留金额被过早释放。如果限额取决于资产价格，还应核验被操纵、过时或无法获取的价格是否会抬高允许支出的金额。

2.2 资金存量、补充资金与尚未执行的已签名交易

接下来的问题是，在机构检测并遏制攻击期间，哪些资金仍面临风险。钱包余额、补充资金和尚未失效的签名授权共同决定了这一风险范围，其中包括事件开始后流入的资金。应将这些因素与第 2.1 节所述可强制执行的限额一并评估；仅凭当前余额无法估计损失。

• 限制攻击者可动用的资金。 评估受影响签名权限所能触及的全部资产，包括其他钱包、区块链和合约中的资产。既要计入现有余额，也要计入后续流入的资金。补充资金必须经过独立授权，并受到累计限额约束。核验反复发生的资金流出是否会触发资金库持续补充资金，以及能否在不忽略仍会到账的入金的情况下，改变新资金的流向或停止注资。
• 计入尚未失效的签名授权所涉及的风险资金。 停止新的签名不一定会使已签发的交易或授权失效。识别这些交易或授权仍能转移的资金，同时避免重复计算同一资产。核验已确认的付款是否记为已支出、相应预留金额是否完成核对；未执行交易对应的预留金额则应保留，直到有可靠证据证明其无法再执行。仅凭本地超时或取消请求，不得降低记录中的风险金额。

2.3 独立监控与事件响应

限额和资金控制措施约束潜在损失；监控和响应则决定攻击者能持续操作多久。即使付款服务将操作视为有效，机构仍需有能够揭示滥用行为的证据；即使常规运行环境不可用或遭到入侵，也需保有可用的响应路径。

Binance 的初步说明表明，仅关闭应用程序为何可能达不到这一目的：关闭应用程序并未清除现有的 EIP-7702 委托。撤销该委托需要链上交易；在其 MPC 部署中，还需要单独设计的流程 [1]。这是该部署的约束，并非 MPC 天生无法撤销授权。因此，检测与遏制需要分别验证：可靠证据必须能促成真正切断损失路径的行动。

• 利用受到独立保护的证据检测未经授权的活动。 对照业务审批、签名活动和执行结果，并监控权限及控制规则的变更。受影响的服务不得改写监控所依赖的证据。核验即使本地记录缺失或被篡改，工作流程接受的操作在与业务授权不符时是否仍能触发可据以采取行动的告警。
• 确保响应控制措施可用且有效。 保留独立权限，以停止新的签名和资金补充，并在支持的情况下使尚未执行的交易失效或撤销持续有效的授权。核验常规操作权限不可用或遭到入侵时是否仍能采取响应措施，以及这些措施是否确实阻止进一步的资金流出。识别剩余风险和外部协调需求；停止应用程序本身不会撤销已签名的授权，也不能假定资产一定能够追回。

3. 验证设计与实现

前文讨论了工作流程中的检查能否防止未经授权的操作，以及在未能防止时能否限制损失。验证工作必须在已部署的系统中考察这两个目标，包括各项控制措施如何在整个资金流转过程中相互配合。以下方法可以提供相互补充的证据：

• 架构与安全设计评估 检查资金流转、权限边界和控制措施之间的依赖关系能否支持预期的预防和损失控制目标。评估应明确说明控制措施独立性及损失上限所依据的假设。
• 代码与配置审计 核实已部署的代码、配置和权限是否落实预期的检查，包括可能绕过检查的例外情况和替代路径。
• 渗透测试 考察攻击者能否利用应用和基础设施中的多处弱点，绕过授权检查或损失控制措施。测试范围应覆盖完整的资金流转路径，而不能止于单个组件。
• 攻防与响应演练 验证监控能否促成及时行动，以及支出限额、暂停机制和权限撤销能否协同发挥作用。演练应确定仍面临风险的资金，以及实现有效遏制需要多长时间。

对于每个验证场景，都应明确应被拒绝的操作或应被控制的损失，以及假设的攻击者能力。记录观察到的结果、任何剩余风险敞口，以及所声称的损失上限成立的条件。在代码、配置或权限发生重大变更后，重复相关检查。

第三方安全团队或专家可以在这些评估、审计、测试和演练中对内部团队形成补充。他们的审查应涵盖支付逻辑、签名基础设施和运营权限如何相互作用，并为系统的预防和损失控制能力提供证据。

4. 结论

本文考察的攻击揭示了从最初的支付请求，经交易构建、签名和执行，直至结算各环节的授权失效问题。这些攻击也表明，攻击者一旦突破防线，系统需要具备哪些能力来限制损失。由此得出的设计原则涵盖预防、遏制，以及在实践中评估这两方面所需的测试。

核心结论是，仅靠保护私钥，并不能确保已签名的操作获得授权。实际执行的操作必须与真实的业务决策一致；当工作流程中的检查未能阻止未经授权的操作时，独立的控制措施必须限制其后果。这要求审查完整的工作流程，包括能够更改其中检查机制的权限，以及检测并阻止进一步损失所需的工具。

本分析聚焦于原系统签名能力遭滥用的情况。第 2 部分 安全地实现钱包密码学机制 将讨论另一条路径：攻击者利用实现缺陷，在不直接窃取受保护秘密的情况下预测或恢复私钥，随后在原有工作流程之外进行签名。

参考资料

• [1] Binance，中文版：2026年10月30日安全事件：初步调查结果与应对进展（2026年11月3日）；英文版：2026年10月30日安全事件：初步调查结果与应对进展（2026年11月3日）。
• [2] BlockSec，加密货币支付中的密钥管理与运营安全。
• [3] BlockSec，加密货币支付系统架构：6 个层级及资金如何在其中流转。
• [4] Bitget，Bitget 黑客攻击解析：时间线、影响与安全响应（更新于 2026年10月20日）。
• [5] BigONE，关于 2025年7月16日 BigONE 安全事件的公告。
• [6] BigONE Eurasia，平台临时维护（2025年7月16日）。
• [7] Bybit，确认 Safe{Wallet} 事件发生后系统仍然安全（2025年2月26日）。
• [8] BlockSec，Bybit 15亿 USD 黑客攻击：恶意 Safe 钱包升级攻击深度分析。
• [9] Kiln，Kiln 服务重新启用及安全事件信息（2025年10月7日）。
• [10] SwissBorg，关于 2025 年 9 月 8 日 Kiln 遭入侵事件及其对 SwissBorg 影响的安全信息。
• [11] Resolv，Resolv 事件复盘：2026年3月22日事件（2026年4月4日）。
• [12] BlockSec，Drift Protocol 事件：利用持久 nonce 攻陷多签治理。
• [13] Chainflip，Tron USDT 漏洞利用事件：发生了什么，接下来会怎样（2026年9月13日）。
• [14] Chainflip，恢复 Chainflip 运行（2026年9月15日）。
• [15] Safe，execTransaction。
• [16] Ethereum，EIP-7702：为 EOA 设置代码。
• [17] AWS KMS，Sign API。
• [18] Google Cloud KMS，cryptoKeyVersions.asymmetricSign。
• [19] Azure Key Vault，Sign API。
• [20] Google Cloud KMS，职责分离。
• [21] Google Cloud IAM，用于服务账号身份验证的角色。
• [22] AWS IAM，授予向 AWS 服务传递角色的权限。
• [23] Solana，使用 nonce 进行持久化及离线交易签名。
• [24] Drift，事件恢复进展（2026年4月16日）。
• [25] Chainflip，EVM（以太坊）金库设计。
• [26] Safe，守卫机制。
• [27] Safe，模块。