3、密码学基础（下）：公钥基础设施（PKI）、证书链、硬件安全模块（HSM）简介

上一讲我们聊了对称与非对称加密、哈希和签名。这些算法单独拿出来，其实都挺「裸」的——你拿着一个公钥，怎么知道它真的是对方的？你收到一个签名，怎么确认签发者没被冒名顶替？

这就是今天要聊的核心：公钥基础设施（PKI）。说白了，PKI 就是一套让公钥变得可信的管理框架。没有它，安全启动就是空中楼阁。

3.1 公钥基础设施（PKI）——信任的起点

PKI 不是某个算法，而是一整套角色、策略和流程的组合。我习惯把它理解成「数字世界的身份证系统」。

3.1.1 PKI 的核心角色

角色	职责	类比
证书颁发机构（CA）	签发、吊销证书	公安局
注册机构（RA）	验证申请者身份	派出所
证书持有者	拥有公私钥对，使用证书	持证人
依赖方	验证证书有效性	查身份证的人
证书库 / 吊销列表（CRL）	存储和发布证书状态	公安系统数据库

你想想看，如果每个设备都自己签自己的证书，那跟「自说自话」有什么区别？PKI 的核心就是引入一个大家都信任的第三方——CA。

3.1.2 X.509 证书结构

实际项目中，我们最常打交道的就是 X.509 证书。它长什么样？我拆开给你看：

证书 = {
  版本号（V3 最常见）
  序列号（唯一标识）
  签名算法（如 SHA256-RSA）
  颁发者（Issuer）
  有效期（Not Before / Not After）
  主体（Subject，即证书持有者）
  主体公钥信息（算法 + 公钥值）
  扩展字段（如密钥用途、基本约束）
  签名（CA 对上述内容的签名）
}

嗯，这里要注意：扩展字段在安全启动里特别重要。比如 Basic Constraints 标记这个证书能不能当 CA 用，Key Usage 限制这个密钥只能签名不能加密。我在项目中就遇到过，有人把代码签名证书配成了 SSL 服务器证书，结果启动验证死活过不了——就是 Key Usage 没设对。

3.2 证书链——信任的传递

单靠一个根 CA 签所有设备，风险太大。根 CA 私钥一旦泄露，整个体系就崩了。所以实际部署中，我们几乎都用证书链。

3.2.1 链式信任模型

证书链的结构，说白了就是一层层授权：

• 根 CA：自签名，离线保存。只用来签发中间 CA。
• 中间 CA：由根 CA 签发，负责签发终端实体证书。
• 终端实体证书：签给具体的设备或固件。

验证的时候，从终端证书开始，逐级向上，直到信任的根证书。只要链上任何一个证书有问题，验证就失败。

3.2.2 证书链验证流程

我画了一张图，帮你理清这个流程：

3.2.3 证书吊销

证书不是永久的。私钥泄露、员工离职、设备退役——这些情况都需要吊销证书。常用的方式有两种：

• CRL（证书吊销列表）：CA 定期发布一个黑名单。缺点是列表会越来越大。
• OCSP（在线证书状态协议）：实时查询单个证书状态。响应快，但需要网络。

3.3 硬件安全模块（HSM）——密钥的保险柜

PKI 体系里，最脆弱的就是私钥。软件里存私钥？反汇编一下就能读到。所以，真正严肃的安全启动方案，都会引入硬件安全模块（HSM）。

3.3.1 HSM 是什么

HSM 是一个专用的硬件设备，专门用来：

• 安全生成密钥对（真随机数发生器）
• 安全存储私钥（物理防篡改）
• 安全执行密码运算（签名、解密）
• 密钥生命周期管理（备份、销毁、轮换）

说白了，私钥一旦进了 HSM，就再也出不来了。你只能告诉 HSM「帮我用私钥签个名」，它签完把结果给你，私钥本身绝不暴露。

3.3.2 HSM 的层级

层级	典型设备	用途	安全等级
L1 - 软件 TPM	PC 上的 fTPM	普通用户身份	低
L2 - 独立安全芯片	ATECC608A, SLM9670	IoT 设备身份	中
L3 - 板载 HSM	TPM 2.0 芯片	PC/服务器启动	高
L4 - 机架式 HSM	Thales Luna, Utimaco	CA 根密钥、代码签名	极高

在安全启动里，根 CA 的私钥必须放在 L4 级别的机架式 HSM 里，物理隔离、多人授权才能操作。而设备端的私钥，可以用 L2 或 L3 的安全芯片来保护。

3.3.3 HSM 在安全启动中的角色

我参与过的一个车载项目，整个安全启动的密钥体系就是围绕 HSM 设计的：

1. 产线阶段：HSM 生成设备唯一密钥对，公钥导出到证书请求，私钥永远留在 HSM 内。
2. 签名阶段：固件镜像的哈希值送入 HSM，HSM 用私钥签名，输出签名值。
3. 验证阶段：BootROM 用预置的公钥验证签名。如果 HSM 支持，验证也可以在 HSM 内部完成。
4. 更新阶段：新固件同样需要 HSM 签名，旧固件验证通过后才允许升级。

3.4 三者如何协同工作

PKI、证书链、HSM 不是孤立的。在实际的安全启动方案里，它们是这样配合的：

你看，HSM 保护了最底层的私钥，PKI 提供了信任框架，证书链实现了信任的传递。三者缺一不可。

3.5 实际部署中的几个坑

最后，分享几个我在项目中踩过的坑：

• 证书有效期别设太长：我见过有人把设备证书设成 20 年。结果算法升级了，证书没法换，整批设备都得召回。建议最长 5 年，配合 OTA 更新。
• HSM 备份要谨慎：HSM 里的私钥一旦丢失，所有已签发的设备都废了。但备份方案本身也可能成为攻击面。我们当时用了 Shamir 秘密共享，把私钥碎片分给 5 个人保管，需要 3 个人同时在场才能恢复。
• 别忘了 CRL 分发点：证书扩展里有个 CRL Distribution Points，很多人在测试环境不填，结果上线后设备找不到吊销列表，验证失败。这个小字段，坑过不少人。