密码学基础（下）：公钥基础设施（PKI）、证书链、信任根（Root of Trust）概念
好，咱们接着聊。上一节我们把哈希、对称加密、非对称加密这些基础工具过了一遍。这一节，我们要把这些工具串起来，搭一个真正能用的信任体系。
说白了，你光有非对称加密还不够。你拿到了 Bob 的公钥，你怎么确定这个公钥真的是 Bob 的？万一中间被调包了呢？这就是 PKI 要解决的核心问题。
公钥基础设施（PKI）是什么？
PKI 不是某个单一的算法，它是一整套策略、流程、硬件、软件的组合。它的目标就一个：让公钥的归属可验证。
我个人的理解，PKI 就像是一个数字世界的“公安局+公证处”。它负责发身份证（数字证书）、验证身份、以及挂失（证书吊销）。
PKI 的核心组件包括：
- 证书颁发机构（CA）：发证书的权威机构。它用自己的私钥给别人的公钥签名。
- 注册机构（RA）：负责审核申请者身份的“前台”。它不直接发证书，但负责核实你的信息。
- 证书库：存放已颁发证书的公共仓库，通常用 LDAP 协议访问。
- 证书吊销列表（CRL）：黑名单。记录那些还没到期但已经失效的证书。
核心要点：PKI 的本质是信任的传递。你信任 CA，CA 担保了 Bob 的公钥，所以你也信任 Bob 的公钥。
数字证书与 X.509 标准
数字证书就是 PKI 里的“身份证”。目前最通用的标准是 X.509 v3。我在做固件签名时，用的就是这种格式的证书。
一个典型的 X.509 证书包含以下字段：
| 字段 | 说明 | 我的备注 |
|---|---|---|
| 版本号 | 通常是 v3 | v3 支持扩展项，很重要 |
| 序列号 | CA 分配的唯一编号 | 吊销时靠这个查 |
| 签名算法 | CA 签名时用的算法，如 SHA256-RSA | 必须和签名值匹配 |
| 颁发者 | 签发该证书的 CA 名称 | DN 格式 |
| 有效期 | 起始和结束时间 | 别让固件证书过期了 |
| 主体 | 证书持有者的名称 | 可以是设备 ID 或公司名 |
| 公钥 | 持有者的公钥 | RSA 或 ECC 的密钥数据 |
| 扩展项 | 密钥用途、基本约束等 | 固件签名必须设置 digitalSignature |
| 签名值 | CA 用私钥对上述字段的签名 | 防篡改的关键 |
避坑指南：我曾经遇到过一个案例，固件签名证书的“密钥用途”扩展项没有设置 digitalSignature，结果在安全启动验证阶段直接报错。证书格式完全正确，但策略检查不通过。所以，生成证书时一定要检查扩展项。
证书链与信任根（Root of Trust）
你想想看，如果全世界只有一个 CA，那它一旦被攻破，整个体系就崩了。所以实际部署中，我们用的是证书链。
证书链的结构是分层的：
- 根 CA（Root CA）：自签名的证书。它是信任的起点，也叫信任根（Root of Trust）。
- 中间 CA（Intermediate CA）：由根 CA 签发，用于分担风险。可以有多级。
- 终端实体证书（Leaf Certificate）：由中间 CA 签发，用于具体的设备或代码签名。
验证过程是从叶子证书开始，逐级向上，直到你信任的根证书。只要链上任何一环被篡改，验证就会失败。
下面这张图展示了典型的证书链结构：
警告：信任根（Root of Trust）一旦被攻破，整个信任链就崩塌了。在嵌入式系统中，根证书的公钥通常被烧死在一次性可编程（OTP）存储器里，或者存储在硬件安全模块（HSM）中。软件层面无法修改，这是物理上的信任锚点。
固件签名中的 PKI 实践
好了，理论讲完了。咱们看看在固件签名里具体怎么用。
我习惯把 PKI 体系分成两个阶段：构建阶段和验证阶段。
构建阶段（在安全的生产环境中进行）
- 生成根 CA 密钥对，自签名根证书。这个私钥必须离线保存，最好放在 HSM 里。
- 用根 CA 签发中间 CA 证书。中间 CA 的私钥可以放在在线服务器上，但要做好访问控制。
- 用中间 CA 为每个固件版本签发终端证书。终端证书的公钥会嵌入到固件中。
- 用终端证书的私钥对固件镜像进行签名（生成签名值）。
验证阶段（在目标设备上进行）
- 设备上电，BootROM 加载固件头部。
- 从固件头部提取终端证书和签名值。
- 用预置在 OTP 中的根 CA 公钥验证终端证书的签名（确保证书链完整）。
- 用终端证书中的公钥验证固件镜像的签名（确保固件未被篡改）。
- 全部通过，才允许执行固件。
关键点：设备上只存储根 CA 的公钥（信任根）。中间 CA 和终端证书都随固件一起分发。这样做的好处是：如果中间 CA 的私钥泄露，只需要重新签发中间证书和终端证书，不需要更新设备上的信任根。
证书吊销：被遗忘的角落
嗯，这里要提一个容易被忽视的点——证书吊销。
假设你的中间 CA 私钥泄露了。你怎么办？你不可能去召回所有已经出厂的设备。这时候就需要证书吊销列表（CRL）或者在线证书状态协议（OCSP）。
但在嵌入式固件场景下，设备通常没有网络连接。所以常用的做法是：
- 固件更新时携带 CRL：在每次固件升级包中附带最新的 CRL 文件。
- 使用短有效期证书：让终端证书的有效期只有几个月甚至几周。这样即使私钥泄露，影响范围也有限。
- 硬件熔断机制：一旦检测到安全事件，通过硬件熔断永久禁用某个版本的信任链。
我的经验：我曾经参与过一个 IoT 项目，当时图省事，给所有设备用了同一个长期有效的终端证书。结果有一批设备的私钥被提取出来了。我们不得不紧急发布固件更新，在 OTP 中烧入新的根证书，整个流程非常痛苦。从那以后，我坚持使用短有效期证书+自动轮换机制。
小结一下
PKI 不是银弹，但它提供了目前最成熟的公钥信任方案。在固件签名中，我们重点关注：
- 信任根必须硬件保护，不可篡改。
- 证书链要分层设计，隔离风险。
- 证书吊销要有预案，不能忽略。
- 密钥管理是整个体系的命门，私钥泄露等于一切归零。