2. 评估标准体系：AIS-31标准详解（Class P1/P2要求）、NIST SP 800-22/90B标准、FIPS 140-3对RNG的要求、Common Criteria认证

做硬件随机数发生器这么多年，我最大的感触就是：没有标准，你做的RNG就是一堆没人信的比特流。客户问你怎么证明你的熵源够好？你说“我觉得挺随机的”——没人会买账。

所以这一章，咱们把主流的评估标准捋一遍。我按自己的理解，把它们分成两类：一类是组件级测试（盯着RNG本身测），另一类是系统级认证（把RNG放到整个产品里看）。

核心观点：AIS-31和NIST SP 800-22是“体检报告”，FIPS 140-3和Common Criteria是“毕业证书”。前者告诉你RNG有没有病，后者告诉别人你的产品值得信赖。

2.1 AIS-31标准：德国人的严谨

AIS-31是德国联邦信息安全局（BSI）出的标准。说实话，这是我见过最较真的RNG评估标准。我在一个安全芯片项目里被它折腾过整整三个月——但事后回头看，那些测试确实把问题都揪出来了。

AIS-31把RNG分成两个等级：Class P1和Class P2。P1是基础级，P2是高级。区别在哪？我直接给你画个表：

对比项 Class P1（基础级） Class P2（高级）
适用场景 一般安全应用 高安全需求（如加密密钥生成）
测试项目数 6项统计测试 9项统计测试 + 物理熵源评估
熵源要求 不强制评估物理熵源 必须评估物理噪声源
在线测试 可选 强制（T0/T1/T2三级）
失败容忍度 允许一定比例的失败 几乎零容忍

P1要求：六项统计测试

P1说白了就是“你的RNG看起来像随机数吗”。它包含六项统计测试：

  1. 单比特频数测试——0和1的数量不能差太多
  2. 块内频数测试——每m个比特里，0和1的比例要均衡
  3. 游程测试——连续的0或1不能太长
  4. 块内最长游程测试——每个块里最长的连续串不能离谱
  5. 二元矩阵秩测试——检查比特之间的线性相关性
  6. 非重叠模板匹配测试——找特定模式出现的次数是否异常

嗯，这里要注意：P1测试只针对后处理后的输出。也就是说，你拿一个很烂的熵源，只要后处理算法够强，也能过P1。但这样安全吗？不，所以有了P2。

P2要求：从源头抓起

P2比P1多了三样东西：

  • 物理噪声源评估——你得证明你的熵源（比如环形振荡器抖动、热噪声）确实有足够的物理随机性
  • 在线测试（T0/T1/T2）——芯片运行时实时监测RNG状态，一旦发现异常立刻报警
  • 更严格的统计测试——多了三项：离散傅里叶变换测试、重叠模板匹配测试、通用统计测试

我的经验：做P2认证时，最难的不是统计测试，而是物理熵源建模。你得用数学证明你的噪声源满足熵率要求。我曾经在一个项目里，因为环形振荡器的相位噪声模型不够精确，被BSI打回来三次。最后我们不得不重新设计测试芯片，专门提取噪声参数。

2.2 NIST SP 800-22：业界最常用的“体检套餐”

NIST SP 800-22，全称是“A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications”。名字很长，但说白了就是一套15项的统计测试工具包。

我个人习惯把NIST测试分成三组：

  • 频率类测试（3项）——检查比特分布是否均匀
  • 模式类测试（8项）——检查是否存在异常模式
  • 相关性类测试（4项）——检查比特之间是否独立

每个测试都会输出一个P-value。如果P-value > 0.01，就算通过。但注意：一次通过不代表永远通过。NIST建议你至少跑1000组序列，每组100万比特，然后看通过率。

避坑指南：我曾经见过一个团队，他们的RNG跑NIST测试全部通过，但上线后第三天就出问题了。为什么？因为他们只测了理想条件下的输出。温度一变、电压一抖，熵源特性就变了。所以我现在做测试，一定加温度循环和电压扫描。

2.3 NIST SP 800-90B：熵源评估的“硬骨头”

800-90B跟800-22不一样。800-22是测输出好不好，800-90B是测熵源本身有多好。说白了，它要回答一个问题：你的噪声源每比特到底能提供多少熵？

800-90B的评估流程大致如下：

  1. 采集原始数据——直接从熵源采样，不经过后处理
  2. IID测试——判断数据是否独立同分布
  3. 熵估计——用10种不同的方法估算最小熵
  4. 健康测试——设计在线监测机制

这里有个坑：很多团队拿后处理后的数据去做800-90B评估，结果熵值虚高。记住，800-90B要的是原始熵源数据，不是最终输出。

2.4 FIPS 140-3：美国政府的“入场券”

FIPS 140-3是美国国家标准与技术研究院（NIST）发布的加密模块安全标准。它对RNG的要求，说白了就是一句话：你的RNG必须符合NIST SP 800-90A/B/C。

具体来说，FIPS 140-3要求：

  • DRBG（确定性随机比特生成器）必须使用NIST批准的算法（如CTR_DRBG、HMAC_DRBG、HASH_DRBG）
  • 熵源必须通过800-90B评估
  • 健康测试必须在每次上电时执行，运行中也要周期性执行
  • 种子生命周期管理——种子必须安全生成、存储、更新

关键点：FIPS 140-3不要求你的物理熵源有多强，但它要求你的整个RNG链路（熵源→健康测试→DRBG→输出）是完整且可审计的。我见过一些产品，物理熵源做得很好，但DRBG实现有bug，结果FIPS认证没过。

2.5 Common Criteria认证：全球互认的“安全护照”

Common Criteria（CC）跟前面几个标准不一样。它不是专门针对RNG的，而是整个产品的安全评估框架。RNG只是其中的一个评估对象（TOE的一部分）。

CC认证里跟RNG相关的部分，主要是安全功能要求（SFR）中的FCS_RNG类。它定义了：

  • FCS_RNG.1——随机数生成的基本要求（质量、熵源、测试）
  • FCS_RNG.2——随机数生成的增强要求（物理不可克隆功能等）

做CC认证时，评估师会要求你提供：

  • RNG的设计文档（包括熵源原理、后处理算法）
  • 测试报告（AIS-31或NIST测试结果）
  • 源代码审计（特别是DRBG实现）
  • 侧信道攻击防护措施

我的建议：如果你的产品目标是欧洲市场，优先做AIS-31 P2认证。如果目标是北美市场，优先做FIPS 140-3。如果两个市场都要，那就做好心理准备——两套标准都要过，而且它们的测试要求不完全重叠。

2.6 知识体系总览

下面这张图是我自己整理的评估标准体系框架，帮你理清它们之间的关系：

RNG评估标准体系框架 RNG评估标准体系框架 硬件随机数发生器（RNG）评估 组件级测试 系统级认证 AIS-31（Class P1/P2） NIST SP 800-22（统计测试） NIST SP 800-90B（熵源评估） FIPS 140-3（加密模块） Common Criteria（FCS_RNG） 说明 组件级测试：评估RNG本身的质量和安全性 系统级认证：将RNG置于产品中，评估整体安全合规性 AIS-31 P2 ↔ FIPS 140-3 互认

这张图你看懂了吗？左边是组件级测试，右边是系统级认证。实际项目中，我通常建议先过组件级测试（AIS-31或NIST），再做系统级认证（FIPS或CC）。因为组件级测试能帮你尽早发现RNG本身的问题，避免到系统级认证时才发现，那时候改起来成本就高了。

2.7 我的选择建议

最后，给你一个实际的选择路径：

  • 做消费级产品（如智能卡、物联网设备）：过AIS-31 P1就够了，成本低、周期短
  • 做安全芯片（如TPM、HSM）：必须过AIS-31 P2 + FIPS 140-3 Level 2以上
  • 做军用/政府项目：Common Criteria EAL4+是标配，RNG部分至少AIS-31 P2
  • 做开源项目：至少跑一遍NIST SP 800-22，把测试报告公开，这是建立信任的基础

最后提醒一句：标准是死的，RNG是活的。不要为了过标准而“优化”你的测试数据。我见过有人为了过NIST测试，在后处理里加了一个“如果测试失败就重采样”的逻辑——这完全违背了随机性的本质。记住，标准是用来发现问题的，不是用来掩盖问题的。

← 上一章 📖 返回目录 下一章 →