「比特币世纪大案」启示：真随机才能真安全

一、12.7 万枚 BTC 的罗生门：真相究竟是什么？

2020 年 12 月，比特币矿池 Lubian 在短短两小时内被扫走约 127,000 枚 BTC，超过其持币的九成，这批币此后在链上沉寂数年，被视为史上最大矿池黑客案之一。

2025 年 10 月，美国司法部宣布查扣约 127,000 BTC，认定其为某东南亚诈骗集团通过 Lubian 矿池洗白的赃款，并在民事没收诉讼中列出若干关联地址。链上分析机构的比对结果显示，这些地址与当年 Lubian 被盗的路径高度重合。

一石激起千层浪。围绕「Lubian 矿池被黑的真相」和「我的钱包还安全吗」，整个行业的目光都被牢牢吸引，讨论愈演愈烈，仿佛一场大型罗生门：

• 一边是行业内对这起「史上最大矿池黑客案是否另有隐情」的反复追问，以及普通用户对钱包安全性的担忧；
• 另一边则是安全研究者们逐渐形成的共识：无论最终是谁盗取并控制了这批 BTC，本质问题都出在 Lubian 当年采用了存在严重缺陷的私钥生成算法——一个熵值不足、可被预测的伪随机数方案。

不管真正的黑客是谁，矿池被盗的技术真相其实很简单：

这不是比特币协议的问题，而是实现层在「随机性」上栽了大跟头。

从 Lubian 到更早的 Blockchain Bandit（利用弱随机私钥批量扫走数十万脆弱地址）、再到 Milk Sad 事件（钱包实现把随机源范围缩到可枚举的小池子），行业已经一次次证明：
只要私钥不是真正随机的，2²⁵⁶ 这种「天文级安全空间」会瞬间塌缩成一个可以被脚本扫完的小水坑。

二、私钥背后的「宇宙级数字」：随机性到底在保什么？

对普通用户来说，「随机」通常意味着：每次点「创建钱包」，屏幕上那串助记词都不一样，看起来很乱。但密码学里的「随机性」，比这个严苛得多。

1. 私钥是什么？

在比特币、以太坊这类公链中，私钥本质是一串 256 位二进制数，也就是从 0 到 2²⁵⁶−1 里的某一个数字。这个空间有多大？

• 2²⁵⁶ ≈ 1.16 × 10⁷⁷，远大于估算中的宇宙原子数量。

这意味着，只要这个数字是真随机选出来的，暴力猜对你这一个的概率，接近拿着一根针在整个银河系里捞到那一粒特定尘埃。

2. “好随机”在密码学里的三条铁律

imKey 的技术文章《真「芯」，真随机》里，把「随机数好不好」拆成了三个标准：

1. 随机性（statistics）
   • 在统计意义上看不出偏差，每个可能的数出现的频率都差不多。
2. 不可预测性（unpredictability）
   • 给你前半段序列和算法，你也推不出后半段是什么。
3. 不可重复性（non-repeatability）
   • 在不刻意保存种子的前提下，系统没法再生成完全一样的一串数。

能满足 1+2 的叫伪随机数生成器（PRNG）；

满足 1+2+3 才配叫真随机数发生器（TRNG）。

对棋牌游戏、抽卡手游来说，PRNG 足够——它的任务是看起来公平，体验顺滑；
对管理高价值资产的私钥来说，只能是 TRNG，因为对手不是玩家情绪，而是带着脚本和算力来的攻击者。

三、随机性一旦塌方，攻击者是在查漏，不是撞运气

Lubian 事件真正恐怖的地方在于：黑客不是在 2²⁵⁶ 的宇宙里盲目乱试，而是在一个被算法缺陷压扁成极小子空间的钓鱼池里打转。

这类事故，在行业里已经不是第一次出现：

• Blockchain Bandit（2015 起）
  攻击者扫描全网，专门寻找弱私钥，最终锁定了 70 多万个安全性不足的钱包地址，盗走了其中超过 5 万枚 ETH。  
• Milk Sad & 其它弱随机事件
  有的钱包在生产环境里沿用了测试代码，把随机源收缩到了 32 位的时间戳或类似参数——本来应该是宇宙级的 256 位空间，被压缩成几乎可以穷举的小范围，黑客只要顺着这个空间扫一遍，就能批量找出可用私钥。

这类漏洞的共同点是：

1. 协议层（Bitcoin / Ethereum）没有错；
2. 算法层（椭圆曲线、哈希）没有错；
3. 出问题的是 随机性来源 ——
   • 种子选得太简单、可预测（时间戳、递增计数器等）；
   • 或者把明明只允许在测试环境使用的简化 RNG 带上了生产；
   • 又或者在实现中粗暴截断熵源，把原本高质量的随机数削薄。

一旦随机源出问题，所谓黑客攻击更像是一场批量找错别字的脚本工作。
而 Lubian、Blockchain Bandit 等案子，就是脚本跑出来的一长串错别字私钥的惨痛样本。

四、PRNG vs TRNG：为什么硬件钱包要执着于物理噪声？

理论很简单：要想让私钥真正随机，就得从物理世界的混沌里取熵。

1. PRNG：工程上方便，却永远是假随机

计算机世界里常见的伪随机做法是：

• 先有一个种子（seed），比如时间、进程 ID、硬件计数器等等；
• 再用一个确定性的算法（线性同余、CSPRNG 等）去搅拌，生成一长串看起来没有规律的数字。

只要：

• 种子空间够大、够难猜；
• 算法经过密码学审计（比如基于 AES、SHA2/3 之类的安全构件）；

那么这种 CSPRNG（密码学安全伪随机数生成器） 在大多数软件钱包场景下是可接受的。

问题在于，它有两个天然弱点：

1. 种子一旦可预测，整个序列就被锁死了：
   • 你如果只用 32 位时间戳做种子，攻击者可以直接枚举完。
2. 很难给出物理世界层面的安全证明：
   • 操作系统 RNG 更多依赖工程经验，很少有像 AIS 31 这样的独立熵评估报告支撑。

对于资产价值巨大、生命周期极长的主私钥来说，只依赖 OS RNG 实在不够放心——这也是为什么行业普遍推荐：热钱包用 OS RNG 没问题，但冷钱包/硬件钱包，最好上 TRNG + 安全芯片。

2. TRNG：把噪声当成安全资产

真随机数发生器（TRNG）做的是另一件事：

直接从物理噪声取熵，然后通过专门的电路和算法，把它榨成安全随机数。

以安全芯片为例，一个典型的 TRNG 架构包括：

• 熵源（Entropy Source）
  • 基于热噪声、抖动、亚稳态电路等物理现象；
• 采样与后处理
  • 对模拟噪声进行采样、放大、均衡，去除偏差；
• 在线健康检测
  • 每次上电、运行期间持续监控熵源状态，一旦熵质量异常立即报警或停用。

国际上，NIST SP 800-90B、德国 BSI AIS 20/31 等标准，就是专门用来衡量这种物理 TRNG 是不是真的足够随机的。

只有通过这类标准认证的 TRNG，才有资格承担生成主私钥这种长周期、不可逆、风险极高的任务。

五、回到 imKey：一颗通过 AIS 31 PTG.2 的 TRNG，改变了哪些安全边界？

imKey 在硬件钱包里做的事，其实很朴素：

把「随机性」这件事，从依赖操作系统和应用开发者的自觉，
变成交给一颗通过严格安全认证的安全芯片来兜底。

1. 芯片级别：SLE 78 平台 + AIS 31 PTG.2

imKey Pro 使用的是英飞凌 SLE 78CLUFX5000PH 安全芯片，属于 SLE78 安全控制器家族。公开资料和安全目标（Security Target）文档中明确写到：该平台内置的 TRNG 满足 BSI AIS 31 PTG.2 等级要求，并用于密钥生成等安全功能。

这背后至少有几层含义：

1. 真随机 + 物理熵源
   • 熵来自芯片内部基于物理噪声的电路，而非简单的时间戳或计数器。
2. 通过独立机构评估
   • AIS 31 PTG.2 不只是跑一遍统计测试那么简单，还包含熵建模、故障检测、在线健康监测等要求。
3. 整体平台通过 CC EAL6+ / EMVCo 等权威认证
   • 这意味着芯片本身在抗侧信道攻击、抗探测/篡改、电压/时钟/温度异常下的应对等方面，都达到了金融乃至军工级标准。

简而言之，这不是一颗便宜 MCU，而是一颗专门为放很值钱的秘密设计的保险箱。

2. 生成流程：从 TRNG 到主私钥，全程不出芯片安全边界

在工程实践上，imKey 把这颗 TRNG 用到了整个产品生命周期的关键环节：

• 设备唯一证书密钥对的产生；
• 设备与 App 建立安全通道所需的会话密钥、授权码；
• 创建钱包时，用于生成熵 → 助记词 → 主私钥；
• 存储加密密钥的生成；
• 椭圆曲线签名（如 secp256k1）中临时随机值 k 的生成；
• 与后台管理系统建立 SCP11C 等安全通道。

更关键的一点是：

这一切都在安全芯片内部完成，私钥和关键随机数永远不出 SE 的安全边界。

当你按下 「创建钱包」的那一刻：

• imKey 会在安全芯片内触发 TRNG，采集熵并生成随机数；
• 通过芯片内的安全算法生成助记词和主私钥；
• 最终只把助记词以人能抄写的形式展示在屏幕上，而私钥本身从不暴露给主机系统。

这和软件钱包依赖 OS RNG 的模式有两个本质区别：

1. 攻击面缩小
   • 攻击者不能通过感染主机操作系统、控制钱包 App 来换掉 RNG，因为随机数根本不在主机生成。
2. 安全性可证明
   • TRNG 的熵质量有 AIS 31 等第三方评估文档背书，而不是纯靠我们写的代码应该没问题这种自我感觉。

3. 行业合规视角：为什么在 SE 里生成密钥更容易过审计？

从监管与合规角度（尤其是涉及托管、机构客户、长期资产管理时），审计方通常会问三个问题：

1. 密钥在哪里生成？
   • 如果答案是 「操作系统 + 软件 RNG」，你需要给出大量内部设计、日志与测试报告才能说服审计方。
   • 如果答案是 「通过 CC EAL6+ 安全芯片内的 TRNG 生成」，则可以直接引用芯片厂商的 CC / AIS 31 / EMVCo 等公开证据。
2. 密钥是否曾经出过安全边界？
   • 对 imKey 而言，主私钥自始至终在 SE 内部，仅以签名结果形式对外暴露。
3. 随机性故障时是否有检测与应对机制？
   • 安全芯片 TRNG 的在线健康检测（上电自检 + 运行时监控），可以显著降低静悄悄地生成了一堆弱私钥的风险。

这就是为什么，在面对机构客户和审计场景时，在安全芯片内用 TRNG 直接生成私钥会被视为一种更稳妥、也更容易被监管接受的做法。

六、为什么那么多团队会在随机性上翻车？

从业者视角回看 Lubian 事件，其实有几层残酷的现实值得同行警醒：

1. 随机数通常被视为底层库的事情
   • 很多团队默认系统 API 肯定安全，或者直接用示例代码里的 RNG，而不会认真追溯熵源质量和安全证明。
2. 测试代码/ Demo 很容易“顺手”带进生产
   • 为了方便调试，有些人会用简单的 PRNG 替代复杂的 TRNG，再加几行 「TODO: replace in production」。真正上线时，这行注释就被时代的尘埃掩埋了。
3. 安全性与可运维性经常被对立起来
   • 有的团队会为了可重现某个用户的钱包状态，在后台做更多日志和种子记录，而这往往直接违反了不可重现性的原则。

从这个角度看，使 Lubian 这类世纪大案成为现实的，并不是某个超级天才黑客，而往往是团队里的一个又一个小妥协：

• 先用这个随机库吧，之后再换更安全的
• 测试用的 seed 先不改了，没时间
• 反正用户是矿池自己，攻击面不大

直到有一天，链上安静躺着十几万枚 BTC，变成了任何一个认真看你代码的人都忍不住要尝试扫一遍的诱饵。

七、写在最后：每一个好好睡觉的夜晚，背后都是认真对待随机数的人

从用户的视角，创建钱包不过是：

• 下载 App / 拿起一台硬件钱包；
• 点「创建钱包」；
• 抄一串看不懂的助记词。

但在产品和工程团队的视角，那一刻其实在回答三连问：

1. 我愿不愿意把几十万、几百万、甚至一辈子的积蓄，押在这一串随机数上？
2. 十年后、二十年后，当密码学算法仍然可靠时，这一串随机数是不是依然站得住脚？
3. 当某一天出事上新闻时，我能不能坦然地说：我们在随机性上，真的做到行业能做到的最好？

Lubian 事件、Blockchain Bandit、Milk Sad……这些故事都在提醒我们：

加密世界的很多灾难，并不是密码学不够强，而是人类在把随机性落到实处这件事上偷过懒。

从 imKey 的角度，我们选择了一条看上去更笨的路：

• 不在主机上生成主私钥，而是把它交给一颗通过 AIS 31 PTG.2 / CC EAL6+ 认证的安全芯片；
• 不简单相信库应该没问题，而是用公开的安全目标文档、认证报告，为 TRNG 的熵质量背书；
• 不把随机数当作一个可以随便替换的黑盒，而是把它当成整个资产安全体系最核心的地基。

这条路没有戏剧性的标题，也很难在社交媒体上收获太多关注，但它换来的是另一种价值——
让用户在关掉屏幕、放下硬件钱包之后，可以踏实睡一个好觉。

而在我看来，这种踏实睡觉的权利，才是 Web3 所有技术栈、所有安全细节，最终要交出的那份答卷。

重要声明：imKey 仅销售实体安全硬件产品，不提供任何虚拟资产交易、托管或资金相关服务。网站中提及的第三方钱包、交易所或去中心化应用仅用于说明产品可配合使用，相关功能与服务均由第三方独立提供。