3、密码学基础（下）：公钥基础设施（PKI）、证书链与根证书、密钥管理与安全存储（HSM/SE）
上一讲我们把非对称加密、哈希和签名的原理过了一遍。但光有算法还不够——你怎么知道手里的公钥真的是张三的？怎么保证签名没被篡改？
这就是 PKI 要解决的问题。说白了，PKI 就是一套“信任的骨架”。我做了这么多年固件安全，见过太多团队算法选得挺强，结果在证书链和密钥存储上翻了车。今天咱们就把这几个坑填上。
3.1 公钥基础设施（PKI）——信任从哪来？
PKI 的核心就一句话：用数字证书把公钥和实体身份绑死。它由几个角色组成：
- 证书颁发机构（CA）：发证书、吊销证书的权威角色。
- 注册机构（RA）：帮你审核身份，然后把申请转给 CA。
- 证书库：存证书和吊销列表（CRL）的地方。
- 终端实体：拿着证书干活儿的设备或人。
我在一个 IoT 项目里遇到过：产品经理说“咱们用自签名证书吧，省事”。我直接否了。自签名证书没法撤销，一旦私钥泄露，你连补救的机会都没有。生产环境必须走正规 PKI 体系。
3.2 证书链与根证书——层层背书
证书链长什么样？我画个图你就明白了。
验证的时候，从设备证书开始，逐级往上找签发者，直到你信任的根证书。中间任何一环出问题——过期、被吊销、签名对不上——整条链就断了。
3.3 密钥管理——最容易被忽视的环节
算法再强，密钥守不住等于零。密钥管理有几个基本原则：
- 最小权限：每个密钥只干一件事。签名密钥、加密密钥、身份认证密钥分开用。
- 生命周期管理：生成、分发、使用、轮换、吊销、销毁，每一步都要有记录。
- 安全存储：密钥不能明文躺在文件系统里。
我曾经审计过一个客户的项目，他们把固件签名私钥硬编码在编译脚本里，还提交到了 Git 仓库。嗯，后果可想而知——攻击者拿到源码就能给任意固件签名。这种坑，踩一次就够了。
3.4 硬件安全模块（HSM）与安全元件（SE）
软件存储密钥终究不安全——内存能 dump，文件能拷贝。所以有了硬件方案。
| 特性 | HSM | SE（安全元件） |
|---|---|---|
| 形态 | 独立设备或 PCIe 卡 | 芯片内部独立硬件区域 |
| 性能 | 高（支持大量并发签名） | 中低（适合单设备） |
| 典型用途 | CA 签名、代码签名服务器 | 设备身份、安全启动 |
| 密钥导出 | 禁止导出（密钥永远不出设备） | 禁止导出 |
| 防物理攻击 | 强（有防篡改外壳） | 强（有主动屏蔽层） |
HSM 和 SE 的共同点：密钥在硬件内部生成，永远不离开硬件。你要签名，把数据送进去，它签完把结果给你，私钥你摸都摸不到。
3.5 实战中的密钥轮换与吊销
密钥不是永久的。我见过一个项目用了同一套签名密钥五年没换，后来发现私钥可能泄露了，但所有已出货的设备都没法更新信任锚——因为固件里写死了根证书。
正确的做法：
- 证书有效期设短：设备证书 1-2 年，中间 CA 3-5 年，根 CA 10 年。
- 支持 OTA 更新信任锚：固件里别写死根证书，留个安全更新通道。
- 吊销列表（CRL）要能下发：设备得能收到“某某证书已吊销”的消息。
# 用 OpenSSL 生成自签名根 CA（仅用于开发测试）
openssl req -x509 -newkey rsa:4096 -keyout rootCA.key -out rootCA.crt \
-days 3650 -nodes -subj "/CN=MyRootCA"
# 生成设备证书请求
openssl req -newkey rsa:2048 -keyout device.key -out device.csr \
-nodes -subj "/CN=device001"
# 用根 CA 签发设备证书
openssl x509 -req -in device.csr -CA rootCA.crt -CAkey rootCA.key \
-CAcreateserial -out device.crt -days 3653.6 小结
PKI 不是理论，是工程。证书链让你能追溯信任，HSM/SE 帮你守住底线。密钥管理没有银弹，但做好生命周期管理和硬件隔离，大部分攻击者就绕道了。
下次你拿到一块开发板，先看看它的密钥是怎么存的——是写在 Flash 里，还是藏在 SE 里。这个选择，决定了你的固件签名到底靠不靠谱。