3、密码学基础（下）：公钥基础设施(PKI)、证书链、硬件安全模块(HSM)简介
上一节我们把非对称加密、哈希和签名的原理捋了一遍。但光有算法还不够——你想想看，你拿到了一个公钥，怎么确定它真的是某个设备或某家公司的？
这就是 PKI 要解决的问题。说白了，PKI 就是一套「谁来证明你是谁」的信任机制。我在做安全启动方案时，最头疼的往往不是签名算法选什么，而是证书链怎么设计、根证书怎么保护。这些坑，今天咱们一次性说清楚。
3.1 公钥基础设施（PKI）——信任的起点
PKI 不是一个软件，也不是一个协议。它是一整套角色、策略和流程的集合。核心目标就一个：让一个实体能够安全地获取另一个实体的公钥，并且相信这个公钥是真的。
PKI 里几个关键角色，我列个表，你对照着看：
| 角色 | 英文 | 干什么的 |
|---|---|---|
| 证书颁发机构 | CA | 签发证书，证明「这个公钥属于这个实体」 |
| 注册机构 | RA | 审核申请者的身份，把审核结果交给 CA |
| 证书持有者 | Subject | 拥有公私钥对，公钥被 CA 签名后形成证书 |
| 依赖方 | Relying Party | 拿到证书，验证签名，决定是否信任 |
| 证书吊销列表 | CRL | CA 发布的「已失效证书黑名单」 |
在安全启动场景里，设备固件就是依赖方。它拿到一个签名后的固件包，里面附带一张证书。设备要做的，就是验证这张证书是否由它信任的 CA 签发。
核心要点：PKI 的本质是「信任传递」。你不需要事先知道每个设备的公钥，你只需要信任一个根 CA，然后让根 CA 去担保其他所有公钥。
3.2 证书与X.509标准
证书长什么样？目前最通用的格式是 X.509 v3。我拆开给你看：
- 版本号：通常是 v3
- 序列号：CA 给每张证书的唯一编号
- 签名算法：CA 签名时用的哈希+非对称算法，比如 sha256WithRSAEncryption
- 颁发者：签发这张证书的 CA 名称
- 有效期：起止时间
- 主体：证书持有者的名称
- 主体公钥信息：持有者的公钥和算法
- 扩展：用途约束、密钥用法、CA 标志等
- 签名值：CA 用私钥对整个证书内容的签名
我在项目中遇到过一种情况：某款芯片的 bootrom 只支持解析 X.509 v3 证书，但固件打包工具生成的是 v1 格式。结果设备启动时直接卡死，连 log 都打不出来。嗯，这种低级错误排查起来最费时间。
实战建议：在固件签名工具里，一定要显式指定证书版本和扩展字段。不要依赖 OpenSSL 的默认行为，不同版本默认值可能不一样。
3.3 证书链——从根到叶子
单张证书不够用。你想，如果根 CA 的私钥泄露了，整个信任体系就崩了。所以实际部署时，我们通常用证书链。
证书链分三层：
- 根证书：自签名，最顶层的信任锚。私钥必须离线保存，极少使用。
- 中间证书：由根 CA 签发，用于日常签发叶子证书。即使中间 CA 私钥泄露，根 CA 可以吊销它，不影响整个体系。
- 叶子证书：由中间 CA 签发，绑定具体的设备或固件签名密钥。
验证流程是这样的：设备固件里预置了根证书的公钥。当它收到一个固件包，包里附带叶子证书和中间证书。设备先用根公钥验证中间证书的签名，再用中间证书的公钥验证叶子证书的签名。全部通过，才信任叶子证书里的公钥。
下面这张图把证书链的签发和验证流程画清楚了：
注意：证书链的验证顺序和签发顺序是相反的。我曾经见过有同事在代码里把验证顺序搞反了，先验叶子再验根，结果签名校验永远通不过。调试了两天才发现是逻辑顺序问题。
3.4 硬件安全模块（HSM）——私钥的保险柜
私钥放在哪里最安全？硬盘？不行，容易被偷。内存？也不行，能 dump。那放哪？HSM。
HSM 是一种专用的硬件设备，专门用来安全地生成、存储和使用密钥。它的核心特性：
- 密钥永不离开硬件：私钥在 HSM 内部生成，内部存储，签名操作也在内部完成。外部只能拿到公钥和签名结果。
- 防篡改：HSM 有物理防护，拆开外壳会触发自毁机制，密钥立即被擦除。
- 合规认证：FIPS 140-2 Level 3 或更高，满足金融、政府等高安全场景要求。
- 高性能：专用硬件加速，RSA-4096 签名每秒能跑几千次。
在安全固件签名场景里，HSM 通常用于保护根 CA 和中间 CA 的私钥。我参与过的一个汽车项目，客户的根 CA 私钥就放在一台 HSM 里，这台 HSM 锁在保险柜中，需要两个人同时刷卡才能操作。你说夸张不夸张？但想想看，如果根私钥泄露，所有已出货的百万台车都得召回，这个代价谁扛得住？
关键认知：HSM 不是用来加速的，是用来「锁死」私钥的。签名速度再快，如果私钥不安全，一切都是零。
3.5 在安全启动中如何落地
好了，理论说完了。咱们看看这些东西在安全启动里怎么配合：
- 产线阶段：HSM 生成根 CA 密钥对，签发中间 CA 证书。中间 CA 再签发每台设备的叶子证书。叶子证书和对应的私钥烧录进设备的 eFuse 或安全存储区。
- 开发阶段：开发人员用中间 CA 的私钥（通过 HSM 或受控的签名服务器）对固件进行签名。签名结果和叶子证书一起打包进固件镜像。
- 启动阶段：BootROM 读取固件包，提取证书链。用预置的根公钥验证中间证书，再用中间公钥验证叶子证书。最后用叶子公钥验证固件签名。全部通过，才跳转到固件代码执行。
这里有个细节：设备里预置的根公钥怎么放？我建议放在一次性可编程存储器（OTP）里，比如 eFuse。一旦写入，任何人都改不了，包括你自己。这样即使攻击者拿到了设备的完整控制权，也无法替换根公钥。
避坑指南：我曾经在一个项目里看到，工程师把根公钥放在 Flash 里，还加了 CRC 校验。结果攻击者直接替换了 Flash 内容，同时更新了 CRC。嗯，这种「防君子不防小人」的方案，在安全启动里是绝对不行的。
3.6 小结
这一节我们聊了 PKI 的信任模型、X.509 证书的结构、证书链的签发验证流程，还有 HSM 这个私钥保险柜。这些东西单独看都不难，但组合起来就是安全启动的信任基石。
你想想看，没有 PKI，设备怎么知道固件是谁签的？没有证书链，根私钥暴露风险多大？没有 HSM，私钥存哪里都不踏实。这三样东西，缺一个，安全启动就是空中楼阁。