3、密码学基础（下）：公钥基础设施(PKI)、证书链、X.509证书格式

上一讲我们把对称加密、非对称加密、哈希和签名聊透了。这一讲，咱们聊聊这些技术怎么组织起来，形成一个可信的体系。

说白了，你一个人会签名没用。你得让别人相信这个签名是你签的。怎么证明？这就引出了 PKI。

3.1 公钥基础设施（PKI）——信任的骨架

PKI 不是某个算法，是一整套规则、流程、软硬件的集合。它的目标就一个：让不认识的双方能建立信任。

我当年刚接触 UEFI Secure Boot 时，觉得这东西太绕了。后来想明白一个道理：PKI 就是现实世界的「公证处」搬到数字世界。

PKI 的核心角色有这几个：

• CA（证书颁发机构）——发证机关，类似公安局。它负责签发和吊销证书。
• RA（注册机构）——审核员，负责核实申请人的身份。大 CA 通常把 RA 独立出去。
• 证书持有者——拿着证书的人或设备。比如你的 BIOS 固件签名密钥。
• 依赖方——需要验证证书的人。比如 UEFI 固件在加载驱动前，要验证驱动签名。
• 仓库/目录服务——存放证书和 CRL（证书吊销列表）的地方。

3.2 证书链——信任的传递

你想想看，如果全世界几十亿设备都只认一个根 CA，那根 CA 的私钥一旦泄露，整个体系就崩了。所以实际用的是证书链。

证书链的结构像一棵树：

• 根 CA——自签名证书，信任的锚点。它给自己发证。
• 中间 CA——由根 CA 签发，用来分担风险。可以有好多级。
• 终端实体证书——由中间 CA 签发，给具体的设备或人用。

验证的时候，从终端证书往上追溯，直到你信任的那个根证书。只要链上每个环节都有效，信任就传递下来了。

下面这张图展示了典型的证书链结构：

3.3 X.509 证书格式——证书长什么样

X.509 是证书的标准格式。目前主流是 v3 版本。我拆开给你看：

字段	说明	我的备注
版本号	v1、v2、v3，现在都用 v3	v3 才支持扩展项
序列号	CA 分配的唯一编号	吊销时靠它定位
签名算法	CA 签名时用的算法，比如 sha256WithRSAEncryption	必须和签名值字段一致
颁发者	签发该证书的 CA 名称（DN）	链式验证的关键
有效期	notBefore 和 notAfter	过期证书直接拒绝
主体	证书持有者的名称（DN）	可以是个人、设备、域名
公钥	持有者的公钥，以及算法参数	核心数据
扩展项	v3 新增，包含关键用途约束	这里坑最多
签名值	CA 对整个证书的签名	防篡改

3.4 证书的信任模型

实际工程里，信任模型不止一种。我列几个常见的：

• 层次模型——就是上面说的树状结构。UEFI Secure Boot 用的就是这种。优点是管理清晰，缺点是根 CA 是单点故障。
• 网状模型——多个 CA 互相交叉认证。适合大型组织合并的场景。缺点是验证路径复杂。
• 桥接模型——通过一个桥 CA 连接不同的 PKI 体系。政府系统里常见。

在嵌入式世界里，层次模型是绝对主流。因为固件的存储空间有限，不可能存太多根证书。

3.5 证书吊销——信任的撤回

证书不是发了就永远有效。私钥泄露、人员离职、设备退役，都需要吊销证书。

吊销手段有两种：

1. CRL（证书吊销列表）——CA 定期发布一个黑名单。验证者下载后检查证书序列号是否在列表里。
2. OCSP（在线证书状态协议）——实时查询。验证者向 OCSP 服务器问：「这个证书还活着吗？」

3.6 在 UEFI Secure Boot 中看 PKI

咱们把 PKI 映射到 Secure Boot 的场景里，你就明白了：

PKI 角色	Secure Boot 中的对应
根 CA	平台密钥（PK），由 OEM 生成，烧死在固件里
中间 CA	密钥交换密钥（KEK），微软或 OEM 的签名证书
终端证书	固件签名证书、驱动签名证书
CRL	固件中存储的吊销列表，UEFI 变量
验证者	UEFI 固件中的签名验证模块

你看，整个 Secure Boot 的信任体系，就是 PKI 的一个具体实现。理解了 PKI，你就理解了 Secure Boot 的一半。