-
@ yr
2025-05-12 12:23:54警惕：那些“帮你”保管密钥的人
—— 多签钱包中的隐形风险与逻辑陷阱
“我们可以帮您设置一个更安全的钱包。” 这句话，听上去就像是关心，其实却可能是一次有预谋的接管。
摘要
多签钱包被广泛视为提升数字资产安全性的“进阶方案”，尤其适用于不希望将所有信任寄托于单一点故障（如一把私钥）的人群。然而，在这些看似“民主化”、“抗单点失败”的技术结构背后，仍潜藏着极为隐秘且被低估的风险。
本文聚焦两类常见却高度隐蔽的逻辑攻击模型：
- 替换 xpub 并接管下一层级地址生成；
- 伪造
k-of-n多签结构，在形式上给予用户参与感，实则实现单人提款。
在未引入 Taproot 的传统多签结构下，这类攻击已能轻易完成。而即便在 Taproot 和 MuSig2 合约模型下，攻击者也可以借助合成结构进一步隐藏其篡改行为。
本报告不仅梳理攻击逻辑，更强调“人性中的信任误区”——攻击者不需要主动索取密钥，只需要维持友善形象，自会有用户主动递交钥匙。更令人警惕的是，在某些极端场景下，这类“被信任的服务商”甚至可能向受害者收取“保管密钥”的费用后再实施盗窃，形成双重获利。
Taproot 虽然在结构上增强了隐私与复杂性，但也使验证逻辑失去了可直观还原的优势。随着时间推移、服务厂商退出市场乃至私有恢复流程被锁死，用户极可能落入无法恢复的“密钥黑箱”中。
阅读本文，希望你能意识到：
真正的安全，从不是托付给别人帮你“多签”，而是你真正理解你签了什么、和谁签的、签名之后将通往哪一个脚本。
多签钱包的逻辑攻击向量分析
以 xpub 替换与伪造 k-of-n 结构为例
攻击模型一：替换 xpub 实现地址劫持
场景设定
攻击者假扮为友好的钱包初始化服务者，主动提出“免费帮你生成一个更安全的多签钱包”。表面上，他为你设置了标准的 HD 多签结构，实际上却在关键的派生路径中，悄悄将本应由你或另一个可信方持有的 xpub 替换为他自己的。
在 HD 钱包结构（例如 BIP45、BIP67）中，用户通常无法直观验证每一个新地址是否仍属于原来的签名组。这种设计让“看上去很安全”的地址，可能早已成为攻击者可完全支配的提款口袋。
攻击结构（逻辑表示）
- 假设多签参与者为
P1, P2, P3 - 攻击者控制伪造者身份
P1'，实际替代掉用户的P1 - 地址生成函数为：
Addr = f(xpub(P1'), xpub(P2), xpub(P3))- 用户未验证 xpub 时，成立：
∃ Addr_i ∈ wallet, spendable_by(attacker)换言之，钱包中的某些地址虽然看起来正常，但已可被攻击者花费。
人性陷阱提示
用户往往不认为“地址生成这件事”是需要人工检查的，特别是在使用 Ledger、Trezor 等硬件钱包时形成了“签名即安全”的错觉。而攻击者只需一次替换，就能悄悄监视整个钱包生命周期。
更重要的是，攻击者不需要向你“索取密钥”，他只需维持友善、专业甚至略带“为你好”的姿态。在 100 个用户中，总会有一部分人，在受到“信任感”与“他人看起来更专业”的影响下，主动提出将某个密钥托管给对方，甚至支付一定“密钥保管费”作为安全保障。这类行为并非愚蠢，而是人性的一部分。
这种松懈与依赖，背后深植着心理学上著名的「责任分散效应（diffusion of responsibility）」。当责任从“自己一人持有私钥”转变为“我们多人共同掌控”时，大脑会自动削弱“必须百分百保护密钥”的紧迫感；一旦密钥有三份或五份，人就会默认“即使我丢了一份也无所谓”，由此降低警惕，弱化加密习惯的执行力度。
尤其是在多签结构下，密钥不再是“唯一真理”。你开始认为：“我只是 n-of-m 的一员”，进而产生 安全责任稀释（safety dilution）。举个例子：如果你的 seed words 是唯一的，你很可能将其写在一张专用纸上，藏入防火袋，存放于密封保险箱中；但一旦你拥有的是 3-of-5 多签中的一份，你可能就只是把它存在 Evernote、存图于手机相册，或者发给自己 Telegram 备份——并自我安慰说：“这只是其中一把钥匙，又不怕。”
这正是攻击者渗透的最佳入口。他无需破解密码学算法，仅凭理解人性中的懒惰、依赖与责任下沉机制，就足以发起极具杀伤力的社会工程攻击。
提醒：没有人例外。你的安全不是由数学公式决定，而是由你是否对它持续保持敬畏与冷静判断所决定的。
Taproot 下的隐蔽性升级
在 Taproot + MuSig2 合约结构中：
- 合成公钥如：
P = H(P1 + P2 + P3) - 用户无法从地址推导出其组成
- 所有 pubkey 被掩盖，无任何可读性结构泄露
结果：攻击者替换某个 xpub 之后，哪怕是资深用户，也无法通过比对地址结构来发现任何异常。
攻击模型二：伪造 k-of-n 多签脚本结构
场景设定
攻击者承诺为你部署一个“非常安全”的
2-of-3多签钱包。然而他实际创建的却是一个1-of-3结构，并诱导你保留或交出其中一个密钥。用户一旦信任其脚本不可见性（或 UI 模糊性），资金注入该地址之后，攻击者即可单独提款。
攻击结构（逻辑描述）
- 正确脚本应为：
OP_2 <pk1> <pk2> <pk3> OP_3 OP_CHECKMULTISIG- 实际被构造为：
OP_1 <pk1> <pk2> <pk3> OP_3 OP_CHECKMULTISIG- 用户错误地相信：
user_believes(k=2) ∧ attacker_has(sk1) → safe- 但实际上：
real_k = 1 ∧ attacker_has(sk1) → attacker_can_spend成立条件
- 用户未能验证 redeem script
- 钱包界面（UI 或 PSBT）未明确标识 k 值与脚本结构
- 攻击者拥有脚本定义权，或 UI 权限
人性陷阱提示
这类攻击往往并非“高技术”，而是利用用户对脚本结构的无感。尤其是当攻击者扮演“技术专家”时，用户往往不具备审查 redeem script 的能力或意识。攻击者甚至可以用“给你设置一个冷备密钥”作为幌子，骗取部分 key，并收取额外费用。
多签攻击模型对比分析（无表格）
- 攻击类型一：xpub 替换
- 本质：公钥注入
- 隐蔽性：极高（生成地址完全正常）
- 关键条件：用户未验证每个 xpub
-
Taproot 是否能规避：否，反而更难发现
-
攻击类型二：伪造 k-of-n
- 本质：脚本结构欺骗
- 隐蔽性：中等（需查看 redeem script 才能识别）
- 关键条件：用户不懂脚本，UI 不展示结构
- Taproot 是否能规避：否，合约结构反而隐藏了更多细节
安全建议（基于当前攻击模型）
- 强制在 UI 中完整展示所有 xpub、合成地址派生路径与对应签名人列表
- 如 Coldcard 的二维码验证机制
- 用户必须自行保存每个 xpub，并可验证任一地址确实源自该集合派生
- 多签钱包必须提供可见 redeem script 的界面与 k 值校验提示
- 不接受“帮你配置好了”的 UI 黑箱
- Taproot 虽增强隐私，但也加剧验证障碍
- 若使用合签结构，应避免依赖第三方界面进行签名决策
- 始终优先使用硬件钱包本地签名流程，避免通过 Web 或中间服务生成交易
真实案例分析
1. Coldcard 硬件钱包的 xpub 替换漏洞
2021 年，安全研究员 benma 发现 Coldcard 硬件钱包在注册多签钱包时，未验证自身是否为多签钱包的一部分。这使得恶意计算机钱包可以用攻击者控制的 xpub 替换多签 xpub，同时仍通过所有用户验证。所有接收到此多签钱包的币随后可以随时转移到攻击者的钱包。
来源：benma.github.io2. Bybit 交易所的多签钱包被黑事件
2025 年 2 月，Bybit 交易所的多签冷钱包在一次例行转账中被黑，损失约 14.6 亿美元。该钱包使用 2-of-3 多签设置，意味着需要三位授权签名人中的两位批准交易。用户界面显示了合法的目标地址，并且 URL 与受信任的多签提供商 Safe 相关联。但这是一种欺骗。黑客利用硬件钱包中的“盲签名”漏洞，使设备只能显示交易的哈希，从而掩盖了一个更改，使攻击者控制了钱包的智能合约。
来源：certora.com3. Parity 多签钱包漏洞
2017 年，Parity 多签钱包版本 1.5+ 中发现了一个漏洞，允许攻击者窃取超过 150,000 ETH（约 3000 万美元）。攻击者向受影响的合约发送两个交易：第一个获取多签的独占所有权，第二个移动其所有资金。
来源：blog.openzeppelin.com
攻击流程图解
- 建立信任：攻击者以技术专家或受信任的服务提供商身份接近受害者，提出帮助设置多签钱包。
- 替换 xpub：在设置过程中，攻击者用自己控制的 xpub 替换原本应由用户或第三方控制的 xpub。
- 生成地址：攻击者生成看似正常的多签地址，并展示给用户，用户未进行验证。
- 资金注入：用户将资金转入这些地址，认为资金安全。
- 资金转移：攻击者利用控制的私钥，单方面将资金转出，用户无法察觉。
参考文献
附录：攻击面分析——为何 xpub 替换是多签特有的风险？
单签钱包是否存在 xpub 替换攻击？
答案：否。
在单签钱包结构中（如 BIP32/BIP39 衍生的标准钱包）：
- 钱包只依赖一个 xpub，并且这个 xpub 是从用户私钥派生而来；
- Coldcard、Trezor 等硬件钱包会自动根据本地 seed 派生地址，无需输入外部 xpub；
- 用户可以通过设备显示屏确认“这是我派生出来的地址”，不存在外部注入路径。
因此：xpub 替换在单签钱包中不存在攻击面，攻击路径被封死。
多签钱包为什么引入了 xpub 攻击面？
多签钱包（如 2-of-3、3-of-5）需要以下信息来生成地址：
- 所有参与者的 xpub；
- 公钥排序规则（如 BIP67）；
- 多签脚本模板（如 OP_2
OP_3 OP_CHECKMULTISIG）； - 每个 key 的派生路径（如 m/48'/0'/0'/2'/0/1）；
这就意味着，用户必须信任这些输入的 xpub 是来自真正的签名方。如果攻击者悄悄将其中某一份换成自己控制的 xpub，那他就自动成为地址共管人，甚至是单签人。
Coldcard 攻击案例回顾：
- 用户通过 PSBT 模板或 JSON 导入多签配置；
- 攻击者在其中替换了某一参与者的 xpub；
- Coldcard 在旧版本中未提示或验证该替换；
- 用户生成地址、发送资金，攻击者即可随时提取。
攻击面比较表
- 单签钱包
- 不接收外部 xpub，派生路径完全由设备掌控；
- 地址来源明确、签名单一；
-
xpub 替换攻击无效。
-
多签钱包
- 依赖多个外部 xpub 合成结构；
- 用户很难手动验证每一条 xpub 与 fingerprint；
- xpub 替换为高危攻击点。
Taproot 是否规避了 xpub 替换问题？
部分规避，但引入了新的验证难题。
Taproot + MuSig2 等结构通过将多个 pubkey 合成为一个点：
P = H(P1 + P2 + P3)
这确实可以隐藏合约结构，提升隐私，但也导致：
- 用户无法从地址还原参与者是谁；
- 如果其中一个公钥被攻击者替换，生成的地址仍然合法；
- 用户在链上看不到任何异常，但攻击者已取得合约控制权。
因此：Taproot 并未从根本上消除 xpub 替换的攻击面，反而因为其不可还原性使得攻击更加隐蔽。
总结
多签钱包之所以引入新的攻击面，不是因为它“更复杂”，而是因为它必须信任外部结构。一旦你的钱包要“与他人协作生成地址”，你就必须验证“这些人是谁”、“这些地址是怎么来的”——这就是攻击的入口。
单签保护的是私钥，
多签则要求你保护你的伙伴。