| 收录 | 六起以"密钥/基础设施失守"为根因的事故 |
| 合计 | ⚠️ 超过 $8 亿（不含另计的 Ronin、Bybit） |
| 共同点 | ⭐ 没有一起涉及智能合约漏洞 |
| 类别 | C7 密钥与签名流程 |
一、为什么把它们合并成一篇
⭐ 前面 25 篇每一篇都有一个可以拆解的技术机制。
这六起没有 —— 它们的根因都能写在三行以内。
⚠️ 但正因为如此，它们更值得被放在一起看：
① 合计损失超过本档案里所有合约漏洞的总和
② ⭐ 每一起的防御手段都是【已知的、成熟的、便宜的】
③ 而它们仍然反复发生
⭐⭐ 这一篇要回答的问题不是"怎么防"——那部分早就有答案了。 而是"为什么明明有答案，还是一直在发生"。
二、六个变体
① Mt. Gox（2014-02） 约 85 万 BTC
形态：托管资产的长期流失，直到无法兑付才暴露。
交易可延展性一度被用作对外解释。
⭐ 教训：
□ 交易所不是链的一部分 ——
链上的"不可篡改"对交易所内部账本毫无约束力
□ ⚠️ "储备证明"这个概念就是从这次事故之后才被普遍讨论的
□ ⭐ 长期的、缓慢的流失，比一次性的盗窃更难发现
② Bitfinex（2016-08） 约 12 万 BTC
形态：多签托管方案的配置与授权边界出问题，热钱包被批量提走。
⭐ 教训：
□ ⚠️ "用了多签"不等于"多签配置正确"
□ 第三方托管方案的安全边界必须被自己重新验证，
⭐ 而不是相信供应商的宣传
□ 与[第 22 篇](https://blog.ifcalm.org/posts/security/blockchain/22-ronin-bridge/)、[第 23 篇](https://blog.ifcalm.org/posts/security/blockchain/23-wazirx/)是同一个主题的早期版本
③ Harmony Horizon Bridge（2022-06） 约 $1 亿
形态：桥采用 2/5 多签，攻破两把私钥即可放行任意提款。
⭐ 教训：
□ ⚠️⚠️ 门槛设置本身就是一个安全参数
—— 2/5 意味着攻破 40% 的密钥就够了
□ ⭐ 一座锁着上亿美元的桥，
它的门槛应该由【资金规模】决定，而不是由运维便利决定
□ 门槛越低，运维越顺畅 —— ⚠️ 这个诱惑始终存在
④ Mixin Network（2023-09） 约 $2 亿
形态：云服务商的【数据库】被攻破。
⭐ 教训：
□ ⚠️ 和合约无关、和密码学无关、和链无关
□ ⭐ 一个"去中心化"的产品，
它的关键状态可能存在一个中心化数据库里
□ 判据：把你系统里【所有存储状态的地方】列出来 ——
有几个不在链上？那几个的安全等级是多少？
⑤ HTX / Heco 跨链桥（2023-11） 约 $1 亿+
形态：桥的签名密钥失守。同一时期同一批基础设施连续出事。
⭐ 教训：
□ ⚠️ 同一个团队维护的多个系统，往往共享同一套密钥管理实践
⟹ 一处失守，全部失守
□ ⭐ "我们的另一个产品也用同样的方案" ——
这句话应该引起警觉，而不是安心
⑥ DMM Bitcoin（2024-05） 约 $3 亿
形态：私钥失窃。后被归因于有国家背景的攻击组织。
⭐ 教训：
□ ⚠️ 当资产规模足够大，对手的类型会自动升级（[第 25 篇](https://blog.ifcalm.org/posts/security/blockchain/25-bybit/)）
□ 经济性威胁模型（"攻击成本 > 收益 ⟹ 安全"）不再适用
□ ⭐ 防御必须假设对手有长期潜伏能力和充足资源
三、⭐ 六起共有的三个结构性原因
① 防御手段都是"运维"，而运维没有交付物
⭐ 一次合约审计有：报告、编号、结论、签字。
⟹ 它是一个【可以被展示的成果】。
⚠️ 而"密钥管理做得好"没有交付物：
· 没有报告可以贴在官网上
· 没有一个数字可以写进融资材料
· ⭐ 做得好的唯一表现是【什么都没发生】
⟹ 于是它在资源竞争中永远输给看得见的东西。
② 它的失效是"离散"的，不是"渐进"的
⭐ 大多数工程问题会先给你信号：
性能变慢、错误率上升、告警增多。
⚠️ 密钥管理不会。
它在失效前的表现，和做得完美时【完全一样】。
⟹ 所以"我们一直没出事"提供不了任何信息 ——
⭐ 它既可能意味着做得好，
也可能意味着攻击者还没来，或者【已经在了但还没动手】。
③ 责任分散在组织里，而不是在一个团队里
□ 谁负责密钥轮换？ —— 运维？还是安全？
□ 谁负责撤销离职员工权限？—— HR 通知了，但谁执行？
□ 谁负责审查多签成员独立性？—— ⭐ 通常没有人
□ 谁负责资金监控告警？ —— 有人配了，但谁值班？
□ ⚠️ 谁负责在凌晨三点按下暂停键？—— ⭐ 这个问题几乎从不被回答
⟹ 而攻击者只需要找到【最没人负责的那一环】。
四、⭐ 一份最小可行的密钥安全基线
这六起事故，任何一条都能被下面的某一项拦住。
【密钥存储】
□ 生产密钥只存在硬件安全模块或硬件钱包里
□ ⭐ 任何时刻，没有【一个人或一台机器】
能接触到达到门槛数量的密钥
□ 密钥的生成过程有见证、有记录、可审计
□ 备份是分片的（Shamir），分片存放在不同地点
【门槛与独立性】
□ ⭐ 门槛由【保护的资金规模】决定，不由运维便利决定
□ 成员跨组织、跨地域、跨设备品牌
□ ⚠️ 逐条检查有没有"代签/委托/备用"旁路（[第 22 篇](https://blog.ifcalm.org/posts/security/blockchain/22-ronin-bridge/)）
【权限生命周期】
□ ⭐ 所有授权【默认带过期时间】
□ 季度权限复核，输出一张表，逐行签字
□ 离职流程包含密钥轮换，且有人验证已完成
【操作流程】
□ 签名在专用隔离设备上进行
□ ⭐ calldata 用独立通道校验（[第 23 篇](https://blog.ifcalm.org/posts/security/blockchain/23-wazirx/)）
□ 大额操作带外确认
□ ⚠️ 任何计划外事件必须被记录和解释（[第 24 篇](https://blog.ifcalm.org/posts/security/blockchain/24-radiant-capital/)）
【结构性限制】—— ⭐ 最重要的一组
□ 冷钱包只能转白名单地址
□ ⭐⭐ 禁止 delegatecall（[第 25 篇](https://blog.ifcalm.org/posts/security/blockchain/25-bybit/)）
□ 单笔 / 单日限额
□ 大额转出走时间锁
【监控与响应】
□ ⭐ 资金余额每分钟核对（[第 22 篇](https://blog.ifcalm.org/posts/security/blockchain/22-ronin-bridge/)的六天）
□ 监控跑在【独立的】基础设施上
□ 告警能叫醒人（电话，不是邮件）
□ ⭐ 有一个不需要多签就能按的暂停键
□ ⚠️ 每季度演练一次 —— 没演练过的流程等于不存在
五、⭐ 举一反三
核心命题一：安全预算与损失分布的错配
⭐ 把本档案的损失按类别加总：
合约之外（C6 工具链 + C7 密钥与签名） ≈ $3.5 亿 × 10
合约之内（C1–C5） ≈ 这个数的一半多
⚠️ 且其中多起被全额归还
⟹ 而典型的安全预算分布【恰好相反】。
⭐ 这不是说合约审计不重要 ——
它是唯一你能靠写代码消除的那部分。
⚠️ 但它只覆盖了风险的一半，而消耗了九成的预算。
核心命题二：“什么都没发生"不是证据
⭐ 在密钥安全上，缺乏负面结果不构成正面证据。
⟹ 判断做得好不好，不能看"有没有出事"，
只能看【流程本身】：
□ 上面那份基线，你能勾掉几条？
□ ⭐ 上一次演练是什么时候？结果如何？
□ 上一次权限复核撤销了几条？
□ ⚠️ 如果现在有一台开发机器被入侵，
你多久能发现？
⟹ 这四个问题的答案，比"我们从没被黑过"信息量大得多。
核心命题三：给"没有交付物的工作"造一个交付物
⭐ 既然运维安全在资源竞争中总是输给看得见的东西，
那就【让它变得看得见】：
□ 把上面那份基线做成一张【清单】，
每季度过一遍，输出勾选结果
□ ⭐ 把"检测时间"变成一个【指标】并跟踪它：
"如果现在发生一笔异常转账，我们多久发现？"
⟹ 这个数字应该像 SLA 一样被公布和考核
□ 把演练结果写成报告，和审计报告放在一起
□ ⚠️ 把"未撤销的权限数量"做成一个仪表盘上的数字
⟹ ⭐ 能被度量的东西，才会被改善。
六、本篇小结
- 六起事故的根因都能写在三行以内，没有精巧的技术机制——但它们合计的损失超过本档案里所有合约漏洞的总和。
- ⭐ 每一起的防御手段都是已知的、成熟的、便宜的，而它们仍然反复发生。
- Mt. Gox：长期缓慢的流失比一次性盗窃更难发现；交易所不是链的一部分，链上的不可篡改对它的内部账本毫无约束力。
- Bitfinex：⚠️ “用了多签"不等于"多签配置正确”；第三方托管方案的安全边界必须自己重新验证。
- Harmony（2/5）：⭐ 门槛本身就是一个安全参数——2/5 意味着攻破 40% 的密钥就够了。门槛应由资金规模决定，而不是由运维便利决定。
- Mixin：一个"去中心化"的产品，关键状态可能存在一个中心化数据库里。把所有存储状态的地方列出来，看有几个不在链上。
- HTX/Heco：⚠️ “我们的另一个产品也用同样的方案"应该引起警觉，而不是安心——同一团队往往共享同一套密钥实践，一处失守全部失守。
- DMM：资产规模足够大时，对手类型会自动升级，经济性威胁模型不再适用。 -⭐ 三个结构性原因：① 运维安全没有交付物，做得好的唯一表现是"什么都没发生”，于是永远输给看得见的东西；② 它的失效是离散的——失效前的表现和做得完美时完全一样，所以"我们一直没出事"提供不了任何信息；③ 责任分散，而攻击者只需要找到最没人负责的那一环。 -⭐ “凌晨三点谁按暂停键"这个问题几乎从不被回答。
- 对策：给没有交付物的工作造一个交付物——把基线做成季度清单、把"检测时间"变成像 SLA 一样被公布和考核的指标、把演练写成报告、把"未撤销权限数"做成仪表盘。能被度量的东西才会被改善。
思考题
- 为什么说"交易所不是链的一部分”？储备证明解决了什么、没解决什么？
- Harmony 用 2/5 门槛。请论证：一座锁着 1 亿美元的桥，门槛应该怎么定？
- 把你系统里所有"存储状态的地方"列出来。有几个不在链上？它们的安全等级分别是多少？
- “我们的另一个产品也用同样的方案"为什么应该引起警觉？请举一个具体的连锁失守场景。
- 为什么说"密钥管理的失效是离散的”？这对"我们一直没出事"这句话的信息量意味着什么？
- 逐条回答本篇那份安全基线，你能勾掉几条？把勾不掉的排个优先级。
- “凌晨三点谁按暂停键？"——请对你的团队认真回答，包括这个人怎么被叫醒、他需要什么权限、多久能完成。
- 把"检测时间"设计成一个可度量的指标：怎么定义？怎么测量？目标值是多少？
- 设计一次密钥安全演练：模拟什么场景、参与者是谁、成功标准是什么？
- 本档案的损失分布与典型的安全预算分布恰好相反。请为你的项目重新分配一次安全预算，并说明依据。