一、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 的技术文章《真「芯」,真随机》里,把「随机数好不好」拆成了三个标准:
-
随机性(statistics)
- 在统计意义上看不出偏差,每个可能的数出现的频率都差不多。
-
不可预测性(unpredictability)
- 给你前半段序列和算法,你也推不出后半段是什么。
-
不可重复性(non-repeatability)
- 在不刻意保存种子的前提下,系统没法再生成完全一样的一串数。
能满足 1+2 的叫伪随机数生成器(PRNG);
满足 1+2+3 才配叫真随机数发生器(TRNG)。
对棋牌游戏、抽卡手游来说,PRNG 足够——它的任务是看起来公平,体验顺滑;
对管理高价值资产的私钥来说,只能是 TRNG,因为对手不是玩家情绪,而是带着脚本和算力来的攻击者。
三、随机性一旦塌方,攻击者是在查漏,不是撞运气
Lubian 事件真正恐怖的地方在于:黑客不是在 2²⁵⁶ 的宇宙里盲目乱试,而是在一个被算法缺陷压扁成极小子空间的钓鱼池里打转。
这类事故,在行业里已经不是第一次出现:
-
Blockchain Bandit(2015 起)
攻击者扫描全网,专门寻找弱私钥,最终锁定了 70 多万个安全性不足的钱包地址,盗走了其中超过 5 万枚 ETH。 -
Milk Sad & 其它弱随机事件
有的钱包在生产环境里沿用了测试代码,把随机源收缩到了 32 位的时间戳或类似参数——本来应该是宇宙级的 256 位空间,被压缩成几乎可以穷举的小范围,黑客只要顺着这个空间扫一遍,就能批量找出可用私钥。
这类漏洞的共同点是:
- 协议层(Bitcoin / Ethereum)没有错;
- 算法层(椭圆曲线、哈希)没有错;
- 出问题的是 随机性来源 ——
- 种子选得太简单、可预测(时间戳、递增计数器等);
- 或者把明明只允许在测试环境使用的简化 RNG 带上了生产;
- 又或者在实现中粗暴截断熵源,把原本高质量的随机数削薄。
一旦随机源出问题,所谓黑客攻击更像是一场批量找错别字的脚本工作。
而 Lubian、Blockchain Bandit 等案子,就是脚本跑出来的一长串错别字私钥的惨痛样本。
四、PRNG vs TRNG:为什么硬件钱包要执着于物理噪声?
理论很简单:要想让私钥真正随机,就得从物理世界的混沌里取熵。
1. PRNG:工程上方便,却永远是假随机
计算机世界里常见的伪随机做法是:
- 先有一个种子(seed),比如时间、进程 ID、硬件计数器等等;
- 再用一个确定性的算法(线性同余、CSPRNG 等)去搅拌,生成一长串看起来没有规律的数字。
只要:
- 种子空间够大、够难猜;
- 算法经过密码学审计(比如基于 AES、SHA2/3 之类的安全构件);
那么这种 CSPRNG(密码学安全伪随机数生成器) 在大多数软件钱包场景下是可接受的。
问题在于,它有两个天然弱点:
-
种子一旦可预测,整个序列就被锁死了:
- 你如果只用 32 位时间戳做种子,攻击者可以直接枚举完。
-
很难给出物理世界层面的安全证明:
- 操作系统 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 等级要求,并用于密钥生成等安全功能。
这背后至少有几层含义:
-
真随机 + 物理熵源
- 熵来自芯片内部基于物理噪声的电路,而非简单的时间戳或计数器。
-
通过独立机构评估
- AIS 31 PTG.2 不只是跑一遍统计测试那么简单,还包含熵建模、故障检测、在线健康监测等要求。
-
整体平台通过 CC EAL6+ / EMVCo 等权威认证
- 这意味着芯片本身在抗侧信道攻击、抗探测/篡改、电压/时钟/温度异常下的应对等方面,都达到了金融乃至军工级标准。
简而言之,这不是一颗便宜 MCU,而是一颗专门为放很值钱的秘密设计的保险箱。
2. 生成流程:从 TRNG 到主私钥,全程不出芯片安全边界
在工程实践上,imKey 把这颗 TRNG 用到了整个产品生命周期的关键环节:
- 设备唯一证书密钥对的产生;
- 设备与 App 建立安全通道所需的会话密钥、授权码;
- 创建钱包时,用于生成熵 → 助记词 → 主私钥;
- 存储加密密钥的生成;
- 椭圆曲线签名(如 secp256k1)中临时随机值 k 的生成;
- 与后台管理系统建立 SCP11C 等安全通道。
更关键的一点是:
这一切都在安全芯片内部完成,私钥和关键随机数永远不出 SE 的安全边界。
当你按下 「创建钱包」的那一刻:
- imKey 会在安全芯片内触发 TRNG,采集熵并生成随机数;
- 通过芯片内的安全算法生成助记词和主私钥;
- 最终只把助记词以人能抄写的形式展示在屏幕上,而私钥本身从不暴露给主机系统。
这和软件钱包依赖 OS RNG 的模式有两个本质区别:
-
攻击面缩小
- 攻击者不能通过感染主机操作系统、控制钱包 App 来换掉 RNG,因为随机数根本不在主机生成。
-
安全性可证明
- TRNG 的熵质量有 AIS 31 等第三方评估文档背书,而不是纯靠我们写的代码应该没问题这种自我感觉。
3. 行业合规视角:为什么在 SE 里生成密钥更容易过审计?
从监管与合规角度(尤其是涉及托管、机构客户、长期资产管理时),审计方通常会问三个问题:
-
密钥在哪里生成?
- 如果答案是 「操作系统 + 软件 RNG」,你需要给出大量内部设计、日志与测试报告才能说服审计方。
- 如果答案是 「通过 CC EAL6+ 安全芯片内的 TRNG 生成」,则可以直接引用芯片厂商的 CC / AIS 31 / EMVCo 等公开证据。
-
密钥是否曾经出过安全边界?
- 对 imKey 而言,主私钥自始至终在 SE 内部,仅以签名结果形式对外暴露。
-
随机性故障时是否有检测与应对机制?
- 安全芯片 TRNG 的在线健康检测(上电自检 + 运行时监控),可以显著降低静悄悄地生成了一堆弱私钥的风险。
这就是为什么,在面对机构客户和审计场景时,在安全芯片内用 TRNG 直接生成私钥会被视为一种更稳妥、也更容易被监管接受的做法。
六、为什么那么多团队会在随机性上翻车?
从业者视角回看 Lubian 事件,其实有几层残酷的现实值得同行警醒:
-
随机数通常被视为底层库的事情
- 很多团队默认系统 API 肯定安全,或者直接用示例代码里的 RNG,而不会认真追溯熵源质量和安全证明。
-
测试代码/ Demo 很容易“顺手”带进生产
- 为了方便调试,有些人会用简单的 PRNG 替代复杂的 TRNG,再加几行 「TODO: replace in production」。真正上线时,这行注释就被时代的尘埃掩埋了。
-
安全性与可运维性经常被对立起来
- 有的团队会为了可重现某个用户的钱包状态,在后台做更多日志和种子记录,而这往往直接违反了不可重现性的原则。
从这个角度看,使 Lubian 这类世纪大案成为现实的,并不是某个超级天才黑客,而往往是团队里的一个又一个小妥协:
- 先用这个随机库吧,之后再换更安全的
- 测试用的 seed 先不改了,没时间
- 反正用户是矿池自己,攻击面不大
直到有一天,链上安静躺着十几万枚 BTC,变成了任何一个认真看你代码的人都忍不住要尝试扫一遍的诱饵。
七、写在最后:每一个好好睡觉的夜晚,背后都是认真对待随机数的人
从用户的视角,创建钱包不过是:
- 下载 App / 拿起一台硬件钱包;
- 点「创建钱包」;
- 抄一串看不懂的助记词。
但在产品和工程团队的视角,那一刻其实在回答三连问:
- 我愿不愿意把几十万、几百万、甚至一辈子的积蓄,押在这一串随机数上?
- 十年后、二十年后,当密码学算法仍然可靠时,这一串随机数是不是依然站得住脚?
- 当某一天出事上新闻时,我能不能坦然地说:我们在随机性上,真的做到行业能做到的最好?
Lubian 事件、Blockchain Bandit、Milk Sad……这些故事都在提醒我们:
加密世界的很多灾难,并不是密码学不够强,而是人类在把随机性落到实处这件事上偷过懒。
从 imKey 的角度,我们选择了一条看上去更笨的路:
- 不在主机上生成主私钥,而是把它交给一颗通过 AIS 31 PTG.2 / CC EAL6+ 认证的安全芯片;
- 不简单相信库应该没问题,而是用公开的安全目标文档、认证报告,为 TRNG 的熵质量背书;
- 不把随机数当作一个可以随便替换的黑盒,而是把它当成整个资产安全体系最核心的地基。
这条路没有戏剧性的标题,也很难在社交媒体上收获太多关注,但它换来的是另一种价值——
让用户在关掉屏幕、放下硬件钱包之后,可以踏实睡一个好觉。
而在我看来,这种踏实睡觉的权利,才是 Web3 所有技术栈、所有安全细节,最终要交出的那份答卷。
重要声明:imKey 仅销售实体安全硬件产品,不提供任何虚拟资产交易、托管或资金相关服务。网站中提及的第三方钱包、交易所或去中心化应用仅用于说明产品可配合使用,相关功能与服务均由第三方独立提供。
0 条评论
文章评论已关闭。