3. HSM 硬件架构：安全芯片、物理防护、随机数发生器
HSM 说白了就是一台“锁在保险柜里的专用计算机”。它跟普通服务器最大的区别在于：硬件上得防拆、防侧信道、防物理攻击。这一章我们就看看，它到底硬在哪儿，里面的几个核心部件是怎么配合的。
3.1 安全芯片：HSM 的大脑
安全芯片是整个 HSM 的根。它的设计思路是：关键操作一律不出片，密钥材料见光死。我最早接触这块时，还觉得“不就是个单片机吗”，后来踩了坑才明白，普通 MCU 跟安全芯片的差距太大了。
安全芯片通常具备以下几个核心特性：
- 密钥隔离：密钥永远锁在片内存储区，任何软件层都无法直接读取。你能用的只有密码运算接口。
- 零知识证明支持：部分高端芯片内置了 POK（Proof of Ownership）逻辑，配合国密 SM2 签名可以实现密钥不可输出但可验真。
- 安全边界防护：芯片内部有独立的电源域、时钟域，普通 CPU 核的 DMA 无法访问密码引擎寄存器。
我在项目中遇到过：某厂商声称其芯片支持“国密算法本地运行”，但实测时发现私钥竟然可以被上层读取。后来拆机检查，发现芯片根本没有做密钥寄存器的访问控制——这其实是颗通用安全MCU，不是真正的安全芯片。
安全芯片的典型内部结构可以拆成这样：
| 模块 | 作用 | 我个人的习惯建议 |
|---|---|---|
| CPU（受限） | 运行 Firmware，但不执行密码运算 | 尽量选择 RISC-V 核，方便做指令级裁剪 |
| 密码引擎（Crypto Engine） | 硬件加速 SM2/SM3/SM4/SM9 | 确认引擎支持多路并发，国密场景下多路签名很重要 |
| 密钥存储器 | OTP + SRAM + 易失性备份区 | 不建议用纯EEPROM，容易被探针攻击 |
| 安全监控 | 电压、温度、频率检测 | 阈值设定不能太死，否则误触发会直接锁死整机 |
| 随机数发生器 | 硬件熵源 + 后处理 | 后面会单独聊，优先级很高 |
你想想看，如果这个芯片内部任何一步被攻破，整台 HSM 就等于是裸奔。所以我建议选型时，优先看这几点：是否通过 CC EAL5+ / EAL6+、是否有国密型号备案、是否支持主动屏蔽层（Active Shield）。
3.2 物理防护：从外到内的层层关卡
HSM 的物理防护，说白了就一句话：让攻击者要么进不去，要么进去后什么都拿不到。
我记得有一次去客户现场调试国密网关，对方问：“你们这台 HSM 如果被人硬撬，密钥会不会丢？”我说：“会丢，但丢的是垃圾。”因为我们的方案设计是：一旦物理入侵传感器触发，安全芯片立即擦除所有密钥区和内部状态寄存器，整个过程在几十微秒内完成。
3.2.1 被动防护
- 封装灌胶：整个电路板用特殊环氧树脂浇注，攻击者想用热风枪拆芯片，得先花几小时磨胶，而且很容易损坏内部走线。
- 多层 PCB 走线迷宫：关键信号线走在内层，盲孔和埋孔混合使用，普通探针根本找不到测试点。
- 屏蔽罩：防止电磁侧信道泄露。我之前测试过，不加屏蔽罩的 HSM 可以通过采集 SM4 加密时的电磁辐射反推出部分轮密钥。
3.2.2 主动防护
- Active Shield：芯片顶层有一层动态变化的金属网格，任何切割或钻孔都会破坏网格的电容特性，触发告警并擦除密钥。
- 光传感器 + 震动传感器：一旦检测到外壳开启或者强光照射，立即启动紧急销毁流程。
我曾经踩过一个坑：某个项目里，产品经理要求 HSM 支持“热插拔密钥卡”，但物理防护触发逻辑写成了“只要检测到开盖信号，就擦除所有密钥”。结果测试时发现，每次插拔密钥卡都会触发开盖感应，整台设备不断自毁——代码里根本没有做去抖和状态机跳转。从那以后，我要求所有物理防护逻辑必须支持“安全锁存 + 硬件超时确认”，软件只能配阈值，不能改流程。
3.3 随机数发生器：安全的“种子”不能假
这个点很多人会忽略。你以为只要调用系统自带 /dev/random 就够了？在 HSM 里不行。国密标准对随机数有明确要求，只能用硬件真随机数发生器，而且必须做实时健康测试。
这里需要先区分两个概念：
| 类型 | 来源 | 是否适合HSM |
|---|---|---|
| 物理真随机数（TRNG） | 热噪声、量子噪声、混沌电路 | 是，国标强制要求 |
| 伪随机数（PRNG） | 数学算法 + 种子 | 仅限用于非密钥场景，不能做密钥生成 |
| 混合随机数 | TRNG 种子 + PRNG 扩展 | 可接受，但必须保证种子熵源质量 |
我个人习惯是，只用纯硬件 TRNG。因为伪随机数本质上是一个确定性的流，一旦种子被泄露或者初始化状态被预测，整条密钥链都会崩掉。我记得有家厂商的 HSM 在 FIPS 认证时被查出随机数发生器输出有 0.1% 的偏差，直接被要求整改——这在国密商用密码产品认证里几乎是一票否决。
硬件随机数发生器通常包含这几个阶段：
- 熵源采集：常见的方案有环形振荡器抖动采样、反相器热噪声放大、二极管雪崩噪声。
- 在线健康测试：每采集一定量样本就做一次 Repetition Count Test（重复计数测试）、Adaptive Proportion Test（自适应比例测试）。
- 去偏处理：通常用 Von Neumann 校正或者加密哈希（SM3）做后处理，把原始熵的偏置抹掉。
- 熵池管理：多源熵混合，防止某一路熵源失效导致输出降级。
这里有一个容易被坑的点：很多 HSM 芯片的 TRNG 输出速率很低，比如只有几十 kbps。如果你上层应用频繁调用随机数做 SM2 密钥对生成，可能会因为等待随机数积累而卡住——我建议在系统设计时就预留一个“随机数预取”缓冲区，由硬件自动填充，避免软件层等待。
用代码来表示一次从 HSM 读取物理随机数的调用，大致是这样：
// 伪代码：从 HSM 获取物理真随机数
uint8_t entropy[64];
int ret = hsm_trng_request(entropy, 64,
TRNG_FLAG_BLOCKING | TRNG_FLAG_HEALTH_CHECK);
if (ret != HSM_OK) {
// 健康测试失败或熵源耗尽
hsm_self_destruct(HSM_ERR_ENTROPY_DEPLETED);
return;
}
// 现在 entropy 中包含了64字节的真随机数
sm3_hash(entropy, 64, session_key); // 用SM3压缩后作为AES/SM4密钥嗯，这里要注意，如果真的遇到 TRNG 健康测试连续失败，HSM 必须自我销毁。不能绕过，不能软降级——否则整个系统的安全性就变成了空谈。