FIPS 140-2/140-3 标准解读：密码模块安全要求、合规级别与认证流程
密码模块的安全标准，说白了就是告诉厂商“你的加密芯片或软件该怎么做才算达标”。我自己做安全产品好几年，从 FIPS 140-2 做到 140-3，最大的感受是：老标准够用，但新标准更较真。今天咱们就聊聊这两个版本的核心变化、合规级别怎么选，以及认证流程里哪些坑能提前绕开。
1. 核心变化：从 140-2 到 140-3，到底改了啥？
FIPS 140-2 是 2001 年发布的，用了快二十年。140-3 在 2019 年正式生效，ISO 19790 打底。别以为只是换个编号——我做过一个项目，从 140-2 迁移到 140-3，安全策略文档几乎重写。
| 对比项 | FIPS 140-2 | FIPS 140-3 |
|---|---|---|
| 发布标准 | NIST SP 800-140 | ISO 19790 + NIST SP 800-140A/B/C |
| 安全级别 | Level 1 ~ 4 | Level 1 ~ 4（但判定更严格） |
| 物理安全要求 | 粗粒度 | 新增显式篡改保护、环境失效保护 |
| 密码算法 | 使用 FIPS 180 等 | 强制废除 DES、RC2 等，只允许 NIST 批准算法 |
| 自测试（POST） | 校验固件/算法测试 | 增加不可拒绝的自测试、条件测试（如 DRBG 健康测试） |
| 角色与服务 | 选型模糊 | 明确区分用户角色、密码服务、关键输入/输出 |
| 接口定义 | 仅说明逻辑接口 | 强制区分关键与不关键端口，且物理接口必须映射 |
我个人的体会： FIPS 140-3 对“文档一致性”抓得特别紧。有一次我在安全策略里写“物理边界是金属外壳”，测试员当场拿游标卡尺量壁厚——因为 140-3 要求明确界定“可接受的机械强度”。
还有一个容易被忽略的变化：140-3 取消了“软件加密模块”的豁免，所有纯软件实现也必须满足 非侵入式自测试。说白了，你的动态库每次加载必须跑一遍完整性校验，否则直接判不通过。
2. 合规级别：Level 1 ~ 4 怎么选？
合规级别不是越高越好，而是看你的产品场景。我见过不少厂商一上来就冲 Level 3，结果成本翻三倍，市场根本用不上。你想想看，一个 USB 加密狗要做到 Level 4，得配防拆卸封装、温度/电压传感器……划得来吗？
- Level 1：基本密码要求，不涉及物理防护。适合纯软件库、实验平台。
- Level 2：增加防篡改涂层或密封。大部分商用硬件加密卡停在这个级别。
- Level 3：主动篡改检测与响应（如 tamper switch），且密钥必须从模块内部销毁。适合支付终端、HSM。
- Level 4：环境故障保护、完整物理自毁。常见于军事/政府绝密系统。
避坑指南： 我曾经帮一个客户评估，他们按 Level 3 设计产品，结果 140-3 把“显式篡改检测”从建议改成了必须——他们的产品只有防拆涂层，没有传感器，只好返工。
合规级别的选择，直接决定你的 认证时间和预算。这里我给个参考表（基于 CMVP 实际统计）：
| 合规级别 | 典型认证周期 | 预估费用范围 |
|---|---|---|
| Level 1 | 3-6 个月 | $10,000 – $30,000 |
| Level 2 | 6-12 个月 | $30,000 – $80,000 |
| Level 3 | 12-18 个月 | $80,000 – $150,000 |
| Level 4 | 18-24 个月 | $150,000 – $300,000+ |
3. 认证流程：从提交到拿证，关键的 5 个步骤
认证由 NIST 和加拿大 CSE 共同管理的 CMVP（密码模块验证计划） 执行。我记得第一次送测 140-3，光申请表就填了 3 遍，因为每个接口的输入/输出必须画成状态图。
- 准备安全策略：定义边界、角色、服务、关键参数。这一步是核心，CMVP 退返最多。
- 模块研发 & 文档自检：按照 FIPS 186、SP 800-90 等要求实现算法。我建议做一次预审，找授权实验室做 pre-assessment。
- 提交到 CMVP 认可的实验室：比如 UL、Intertek、atsec。实验室会跑算法测试、文档审核、物理/逻辑检查。
- 正式测试 & 外部评审：实验室出具测试报告，CMVP 指派审核员交叉检查。这阶段常需要补充“为什么你的 DRBG 种子不重复”。
- 证书签发 & 维护：通过后获得认证编号。注意，每季度要报产品变更，否则证书作废。
这里有一个很多人忽视的细节：140-3 要求 认证有效期与模块版本绑定。你改一行代码，哪怕只是日志格式，也必须重新测评（或提交变更通知）。
警告： 别信“软模块不需要物理测试”。140-3 对软件实施同样要求逻辑边界清晰。我见过一个案例，软件模块运行在 RTOS 上，但 RTOS 本身没做 FIPS 认证，结果整个项目被要求重做架构分割。
4. 一些实战中的常见误区
做 FIPS 认证，很多坑是共通的。我挑三个最常见的说给你听。
- 误以为“软件版本升级不需要重测”：140-3 绑定模块版本，升级后必须走 变更通知，严重变更要重新认证。我曾经有客户改了动态库的编译选项，结果哈希变了——CMVP 直接判违规。
- 忽略“熵源”的测试：140-3 要求 DRBG 必须经过 NIST SP 800-90B 健康测试。很多公司直接用 /dev/random，自认为没问题，结果实验室一测，发现熵值不够，重做。
- 文档描述含糊：安全策略里写“密钥在安全区域内存储”，140-3 要求明确“哪个存储单元”“如何防止未授权访问”。我见过测试员问“你说的安全区域是 PCA 还是 SoC 的内部总线？”，答不上来就退单。
我自己的一点经验： 开始设计前，先花两周写好安全策略草稿。别急着写代码。策略定了，所有接口、角色、边界都画清楚了，再动手实现。这样后期返工最少。
好了，FIPS 140-2 和 140-3 的对比、级别选择、认证流程大致就这些。下回你拿到一个密码模块需求，可以先用今天的内容快速定位它该走哪个版本、哪个级别、大概多少周期。核心还是那句：文档先行，测试后跟，别省预审的钱。