4、密码学基础（下）：密钥管理、证书体系（PKI）、硬件安全模块（HSM）简介
好，咱们接着聊密码学。上一节我们把对称加密、非对称加密、哈希这些基本工具过了一遍。这一节，我们聊聊更实际的问题——密钥怎么管？怎么证明这把公钥就是你的？以及，怎么把密钥锁进保险柜里？
这三个问题，说白了就是密钥管理、PKI 和 HSM。在 OTA 升级里，它们直接决定了你的升级包会不会被篡改、你的设备会不会被冒充。我见过不少团队，算法选得挺高级，结果密钥直接硬编码在代码里，一拆机全暴露了。嗯，这节咱们就把这些坑填上。
4.1 密钥管理：不只是“存好密码”那么简单
很多人觉得密钥管理就是找个地方把密钥存起来。其实远不止这些。我个人习惯把密钥管理分成三个层面：生命周期、存储安全、访问控制。
4.1.1 密钥的生命周期
一把密钥从生到死，每个阶段都有讲究：
- 生成：必须用真随机数发生器（TRNG），不能用伪随机。我曾经见过有人用
rand()生成密钥，结果每次重启密钥都一样，那加密还有什么意义？ - 分发：生产阶段怎么把密钥灌进设备？是预置还是在线分发？这里最容易出问题。
- 使用：密钥在内存里停留多久？用完有没有清零？
- 更新：OTA 升级本身就需要更新密钥，这形成了“先有鸡还是先有蛋”的问题。
- 销毁：设备报废时，密钥必须物理销毁，不能只是删个文件。
核心原则：密钥的明文，永远不应该出现在非安全区域。包括日志、调试接口、文件系统。
4.1.2 密钥的分级保护
实际项目中，我们不会只用一把密钥。我习惯用三层密钥体系：
| 层级 | 名称 | 用途 | 存储位置 |
|---|---|---|---|
| 第一层 | 根密钥（Root Key） | 加密下级密钥 | HSM 或 eFuse |
| 第二层 | 设备密钥（Device Key） | 签名验证、会话加密 | 安全存储区 |
| 第三层 | 会话密钥（Session Key） | 单次通信加密 | 内存（用完即焚） |
为什么要分级？你想想看，如果每次通信都用根密钥加密，一旦泄露，所有设备都得报废。分级之后，即使会话密钥被截获，也只影响这一次通信。
避坑指南：我曾经在一个项目里发现，工程师把设备密钥直接写死在 Flash 的固定地址。结果用 readelf 一查，密钥明晃晃地躺在那里。正确的做法是：密钥必须经过加密存储，运行时再解密到安全内存。
4.2 证书体系（PKI）：解决“你是谁”的问题
非对称加密有个天然的问题：你拿到了 Bob 的公钥，怎么证明这把公钥真的是 Bob 的？不是 Eve 伪造的？这就是 PKI 要解决的事。
PKI 说白了就是一个信任链。根证书（CA）自签名，然后 CA 给中间证书签名，中间证书给设备证书签名。设备升级时，云端下发签名后的升级包，设备用预置的根证书去验证整个链条。
4.2.1 OTA 中的证书链验证
我举个例子，一个典型的 OTA 升级证书链是这样的：
根证书（自签名，预置在设备 ROM 中）
└── 中间证书（由根证书签名）
└── 代码签名证书（由中间证书签名）
└── 升级包（由代码签名证书签名）设备收到升级包后，会做以下验证：
- 用预置的根证书公钥，验证中间证书的签名
- 用中间证书的公钥，验证代码签名证书的签名
- 用代码签名证书的公钥，验证升级包的签名
只有三步全部通过，设备才信任这个升级包。为什么要搞这么复杂？因为如果根证书泄露，你只需要吊销中间证书，而不需要召回所有设备。
注意：证书是有有效期的！我见过一个项目，设备出厂时预置了证书，结果两年后证书过期，所有 OTA 升级都失败了。所以，证书有效期一定要覆盖设备的生命周期，或者设计好证书更新机制。
4.2.2 证书撤销
证书泄露了怎么办？PKI 提供了证书撤销列表（CRL）和在线证书状态协议（OCSP）。但在嵌入式设备上，这两个都不太好用——CRL 文件太大，OCSP 需要联网。
我个人习惯的做法是：在升级包中附带最新的 CRL 或黑名单。设备在验证升级包签名之前，先检查签名证书是否在黑名单中。这样既保证了实时性，又不需要设备一直联网。
4.3 硬件安全模块（HSM）：把密钥锁进保险柜
软件层面的保护再强，也挡不住物理攻击。攻击者可以用探针读总线、用激光打芯片、用电压毛刺干扰运行。这时候，就需要 HSM 出场了。
HSM 说白了就是一个独立的、物理隔离的安全芯片。它有自己的 CPU、存储、真随机数发生器，甚至还有传感器检测物理攻击。
4.3.1 HSM 能做什么？
- 安全存储：密钥永远不出 HSM 芯片。你需要签名？把数据送进 HSM，它在内部签名，然后把签名结果送出来。密钥本身你根本看不到。
- 加速运算：HSM 有硬件加速器，做 RSA、ECC 签名比主 CPU 快得多。
- 防物理攻击：检测到温度异常、电压毛刺、激光照射，HSM 会立即擦除所有密钥。
关键点：HSM 不是万能的。它保护的是“密钥不被读取”，但保护不了“合法操作被滥用”。比如，攻击者可以反复让 HSM 签名恶意数据。所以，HSM 必须配合访问控制策略使用。
4.3.2 实际项目中的选择
嵌入式 OTA 中，常见的 HSM 方案有：
| 方案 | 成本 | 安全等级 | 适用场景 |
|---|---|---|---|
| 独立 HSM 芯片（如 ATECC608） | 中 | 高 | 车规、工业设备 |
| SoC 内置安全单元（如 TrustZone） | 低 | 中 | 消费电子、IoT |
| 软件 HSM（如 OpenSSL Engine） | 免费 | 低 | 原型验证、低安全场景 |
我个人的建议是：只要产品涉及资金交易或人身安全，必须上独立 HSM 芯片。多花几块钱，能省掉后面无穷无尽的麻烦。
避坑指南：我曾经在一个车规项目里，客户为了省钱选了 SoC 内置安全单元。结果 EMC 测试时，电压波动导致安全单元复位，密钥被意外擦除，整批设备需要返厂。从那以后，我对车规项目一律推荐独立 HSM。
4.4 小结
这一节我们聊了三个关键点：
- 密钥管理：分级保护、生命周期管理、避免硬编码
- PKI：信任链验证、证书撤销、有效期管理
- HSM：物理隔离、安全存储、防物理攻击
下一节，我们会把这些知识串起来，讲一讲完整的 OTA 升级安全流程。从固件签名、加密传输、到设备端验证，每一步都会用到今天讲的内容。嗯，到时候你会发现，这些基础打得越扎实，后面的流程就越顺畅。