📚 课程目录第3章 TRNG后处理技术

3. TRNG后处理技术：数字去偏算法与健康测试

真随机数发生器（TRNG）的原始输出，说白了就是一堆模拟噪声经过采样后的比特流。但这里有个坑——你拿到的原始数据往往不是均匀分布的。我刚开始做硬件安全时，天真地以为只要噪声源够好，出来的比特就能直接用。结果呢？统计测试一跑，偏置大到吓人。

为什么会这样？因为物理噪声源本身就有系统性偏差。温度漂移、工艺偏差、电源纹波，这些都会让0和1的出现概率不相等。所以我们需要后处理——把有偏的原始比特流，变成密码学可用的均匀随机数。

3.1 数字去偏算法：从简单到实用

去偏算法有很多种，我按自己的经验把它们分成三类：轻量级、标准级、密码级。咱们一个一个说。

3.1.1 Von Neumann 去偏器

这是最经典的算法，简单到令人发指。它的核心思想：把原始比特流按对分组，遇到"01"输出0，遇到"10"输出1，遇到"00"或"11"直接丢弃。

// Von Neumann 去偏器伪代码
input: raw_bit_stream
output: debiased_bit_stream

while (raw_bit_stream has at least 2 bits) {
    bit1 = read_next_bit()
    bit2 = read_next_bit()
    
    if (bit1 == 0 && bit2 == 1) {
        output(0)
    } else if (bit1 == 1 && bit2 == 0) {
        output(1)
    }
    // 00 和 11 直接丢弃，不输出
}

这个算法的好处是：不管原始偏置有多大，只要比特之间独立，输出就是完全无偏的。我在一个低功耗IoT项目里用过它，资源开销几乎为零。

我的经验： Von Neumann 去偏器有个致命弱点——吞吐率低。如果原始比特流偏置严重，丢弃率可能高达75%以上。你想想看，采集4个比特可能只输出1个。所以它只适合低速场景，比如密钥生成频率不高的设备。

3.1.2 SHA-256 与 SM3 哈希去偏

当吞吐率要求高时，我建议用哈希函数做去偏。原理很简单：把原始比特流分成固定长度的块，对每个块做哈希运算，取哈希值的一部分作为输出。

为什么哈希能去偏？因为哈希函数有雪崩效应——输入哪怕只变一个比特，输出也会完全改变。原始比特流中的偏置，经过哈希后会被均匀化。说白了，哈希函数就像一个搅拌机，把有偏的原料搅匀了。

算法	输出长度	安全强度	硬件开销	适用场景
SHA-256	256 bit	128 bit	中等（约10K门）	通用密码协议
SM3	256 bit	128 bit	中等（约12K门）	国密合规场景
Von Neumann	可变	取决于输入	极低（约100门）	超低功耗设备

我个人习惯用SHA-256做通用去偏，因为它的硬件实现已经很成熟了。但如果你做的是国密产品，必须用SM3——这是合规要求，没得选。

注意： 哈希去偏不是万能的。如果原始噪声源的熵不够，哈希也救不了你。我曾经见过一个方案，用SHA-256去偏后统计测试全过，但实际随机数周期只有2^16——因为原始噪声源本身就是一个伪随机序列。哈希只能均匀化，不能增加熵。

3.2 健康测试：TRNG的体检报告

健康测试，说白了就是给TRNG做体检。你得确保它一直在正常工作，而不是偷偷摸摸输出一些可预测的序列。

3.2.1 在线监测 vs 离线测试

这两个概念容易混淆，我简单区分一下：

离线测试： 设备出厂前，用NIST SP 800-22或GM/T 0008做全套统计测试。这是"体检"，一次性的。
在线监测： 设备运行时，实时检查TRNG状态。这是"心电监护"，持续不断。

密码协议要求的是在线监测。因为TRNG可能在运行中出问题——温度突变、电压跌落、老化退化，这些都会让噪声源失效。离线测试只能证明出厂时是好的，不能保证现在也是好的。

3.2.2 常见的在线监测指标

我参与过几个FIPS 140-3认证项目，总结下来，在线监测主要看这几个指标：

重复计数测试（Repetition Count Test）： 检查连续相同的比特数。如果连续出现32个0，大概率出问题了。
自适应比例测试（Adaptive Proportion Test）： 检查某个窗口内1的比例是否在合理范围内。比如1024比特中，1的个数应该在480~544之间。
熵估计： 实时估算每比特的熵值。如果低于阈值（比如0.5），立即告警。

关键点： 在线监测的阈值设置很讲究。设得太严，误报率高，设备频繁告警；设得太松，漏报风险大。我一般建议：告警阈值取理论值的±3σ，这样误报率控制在0.3%以内。

3.3 后处理与健康测试的协同设计

这里有个容易被忽视的问题：健康测试应该放在去偏前还是去偏后？

我的建议是：两边都要放。

去偏前监测： 直接看原始噪声源的输出。如果原始信号就有问题，说明物理源坏了，必须立即停机。
去偏后监测： 看最终输出的随机数质量。这是给密码协议用的，必须保证它通过所有统计测试。

我曾经在一个项目中只做了去偏后监测，结果原始噪声源已经退化到输出全0了，但SHA-256去偏后居然还能通过部分测试——因为哈希函数把全0序列映射成了看似随机的值。但熵呢？早就没了。从那以后，我坚持做两级监测。

3.4 本章知识体系

下面这张图是我自己画的，把后处理技术的整体框架梳理了一遍。你仔细看看，应该能对本章内容有个全局认识。

嗯，这张图把整个流程串起来了。从原始噪声源开始，先做第一级在线监测，然后进入去偏算法（根据场景选Von Neumann、SHA-256或SM3），再做第二级监测，最后输出给密码协议使用。

避坑指南： 我曾经在选型时犯过一个错误——为了省资源，只用了Von Neumann去偏器，结果吞吐率不够，导致密钥生成延迟超标。后来换成SHA-256，问题才解决。所以我的建议是：先评估你的吞吐率需求，再选去偏算法。低速场景用Von Neumann，高速场景用哈希。

最后说一句：后处理不是万能的，但没有后处理是万万不能的。TRNG的原始输出就像一块璞玉，需要经过雕琢才能成为密码学可用的宝石。去偏算法是雕琢的刀，健康测试是检查的尺，两者缺一不可。