第三章 HSM认证与标准：FIPS 140-2/3、Common Criteria、PCI HSM要求
聊HSM，绕不开三大认证标准。坦白说，我刚入行时觉得这些标准就是一堆条条框框，后来吃过亏才明白——它们才是HSM安全的底线。本章我把三个核心标准掰开揉碎讲清楚，附上我这些年踩过的坑。
3.1 FIPS 140-2/3：美国的加密模块安全标准
FIPS 140系列由NIST发布，是全球最权威的加密模块安全标准。目前主流是140-2，140-3已经在逐步替代中。
3.1.1 安全级别划分
FIPS 140-2定义了4个安全级别，从低到高递增：
| 级别 | 核心要求 | 典型应用 |
|---|---|---|
| Level 1 | 基本加密算法正确性验证 | 软件加密库 |
| Level 2 | 加防篡改涂层或封条 | 零售POS终端 |
| Level 3 | 物理拆解后密钥自动销毁 | 银行网银HSM |
| Level 4 | 极端环境防护（温度/电压攻击） | 军用/政府核心HSM |
我的经验：银行场景通常选Level 3，因为同时兼顾安全与运维便利性。Level 4的HSM一旦检测到环境异常就锁死模块，维护代价太高。
3.1.2 FIPS 140-2与140-3的主要差异
140-3在2019年发布，与ISO 19790完全对齐。差异点很实际：
- 算法要求更新：140-3禁止使用3DES、SHA-1等老旧算法，强制使用AES-256、SHA-256以上。
- 生命周期管理：140-3明确要求密钥生成与销毁的审计日志必须不可篡改。
- 物理安全测试：140-3引入更严谨的破坏性分析测试（如探针攻击防护）。
避坑指南：我曾遇到过客户采购标称“FIPS 140-2 Level 3”的HSM，结果发现是2009年的老款，不支持SHA-256。到监管部门审核时直接亮红灯。记住：140-2证书也有有效期，通常5年更新一次。
3.1.3 认证测试的关键环节
FIPS认证由CMVP（加密模块验证计划）执行，流程很严格：
- 算法验证：使用NIST指定的测试向量，验证AES、RSA、ECC等算法的实现正确性。
- 物理安全测试：模拟攻击者尝试拆解模块，验证防篡改机制是否生效。
- 安全策略文档审查：检验HSM的安全策略（Security Policy）是否与实际实现一致。
// 示例：FIPS测试向量验证AES-256 ECB模式
// 密钥: 256-bit all-zero key
// 明文: 16字节递增序列
// 预期密文: NIST指定向量
测试结果：通过 → 模块通过算法验证
核心要点：FIPS 140-2/3认证只证明模块在“当前硬件版本”下安全。厂商升级固件后，必须重新提交认证——这也是很多HSM固件更新慢的原因。
3.2 Common Criteria：国际通用的安全评估框架
Common Criteria（简称CC）是ISO 15408标准，比FIPS更全面。它不光看加密模块，还评估整个系统的安全架构。
3.2.1 评估保证级别（EAL）
CC的EAL从1到7，数字越高级别越高：
| EAL级别 | 评估深度 | HSM常见级别 |
|---|---|---|
| EAL1 | 功能测试 | 极少用于HSM |
| EAL2 | 结构测试 | 入门级HSM |
| EAL3 | 方法设计和测试 | 部分商用HSM |
| EAL4 | 方法设计、测试和审查 | 银行级HSM主流 |
| EAL5 | 半形式化设计和测试 | 高安全场景 |
| EAL6-7 | 形式化验证 | 军事/政府核心 |
我个人观察，金融行业PCI HSM通常要求CC EAL4+，因为EAL4的评估深度能覆盖密钥管理、审计日志、物理防护等关键域。你想想看，如果一个HSM连设计方法都不做审查，你敢把根密钥放进去吗？
3.2.2 CC认证与FIPS的取舍
很多人问我：到底选FIPS还是CC？我的建议是看场景：
- 美国国内系统：FIPS 140-2/3是强制要求，CC作为加分项。
- 跨国金融机构：CC EAL4+更受国际监管认可，尤其是欧盟地区。
- 高安全场景：两者都过才是真稳妥——我见过不少银行招标同时要求FIPS 140-2 Level 3和CC EAL4+。
重要提示：CC认证的Security Target（安全目标）文档是公开的。我建议采购前下载厂商的ST文档，仔细核对每个安全功能是否满足你的业务需求——有些厂商会故意把ST写得很宽泛，实际防护能力可能缩水。
3.3 PCI HSM要求：支付行业的强制标准
PCI HSM标准由PCI安全标准委员会制定，核心关注支付密钥的全生命周期安全。说白了，就是管住那些能产生支付卡PIN、密钥的HSM。
3.3.1 PCI HSM v3.0核心要求
目前最新版本是v3.0，我拆几个关键点：
| 要求编号 | 内容 | 实施要点 |
|---|---|---|
| 2.1 | HSM必须通过FIPS 140-2 Level 3或CC EAL4+认证 | 认证证书必须在有效期内 |
| 3.2 | 密钥生成必须使用FIPS批准的算法 | 禁止使用厂商自定义的随机数生成器 |
| 4.1 | HSM必须支持双人控制（Dual Control） | 管理员与操作员权限分离 |
| 5.3 | 密钥存储必须加密 | 主密钥（KEK）由多个密钥分量保护 |
| 6.1 | 审计日志必须至少保留3年 | 支持日志导出到校外系统 |
我遇到过最典型的PCI HSM违规案例：某支付机构HSM的审计日志存储在本地文件系统，且没有做写保护。攻击者进入系统后直接删除了所有密钥操作记录。这违反了PCI HSM 6.1的“tamper-evident audit trail”要求。
3.3.2 PCI HSM认证流程
认证由PCI SSC认可的实验室执行，流程比FIPS更复杂：
- 硬件评估：验证HSM的物理防篡改机制是否符合Level 3要求。
- 密钥管理功能检测：包括生成、存储、备份、恢复、销毁全流程。
- 安全策略文档审查：确保厂商的Security Policy覆盖PCI HSM所有要求。
- 现场测试：实验室人员在HSM上执行攻击测试，如电源扰动、探针尝试。
避坑指南：PCI HSM v3.0要求HSM支持“Key Block”格式（如TR-31、TR-34）。我见过有厂商号称支持PCI HSM，但实际只能导出明文密钥。切记在采购合同里明确写明支持哪些密钥封装格式。
3.4 三类标准的协同关系
画一张图帮大家理清逻辑：
三者关系：FIPS保底线（加密算法正确性）→ CC保架构（系统级安全设计）→ PCI保业务（支付场景合规）
最后说句实在话：别指望一个证书解决所有问题。我见过最稳的做法是——选HSM时拉一张对比表，把FIPS级别、CC EAL等级、PCI HSM版本、支持的功能清单横向比对，再结合自己的业务场景做决策。证书是门槛，不是终点。