COMP3355 第 3 讲：公钥基础设施（PKI）

开场

上一讲已经讲到非对称加密、数字签名和哈希函数。它们解决了很多密码学问题，但还留下一个很现实的问题：我拿到的公钥，真的是对方的公钥吗？

公钥基础设施（Public Key Infrastructure，PKI）就是围绕这个问题建立起来的一整套制度和技术系统。它不只是一种算法，而是一组硬件、软件、人员、策略和流程，用来创建、管理、分发、使用、存储和吊销数字证书（Digital Certificate）。

中间人攻击为什么绕不开

先看一个最简单的密钥交换场景。Alice 想和 Bob 建立通信信道，双方最后需要得到一个对称密钥。问题在于，如果 Alice 只是从网络上收到一个“Bob 的公钥”，她本身并不知道这个公钥是否真的属于 Bob。

中间人攻击（Man-in-the-Middle Attack，MITM）的关键就在这里。Eve 控制通信信道后，可以对 Alice 说“我是 Bob，这是我的公钥”。如果 Alice 直接相信这把公钥，后续发给这把公钥的加密内容都会先落到 Eve 手里。Eve 解密、读取、重新加密，再转发给 Bob，Alice 和 Bob 可能都以为自己在和对方直接通信。

文件传输里的数字签名也会遇到同类问题。Alice 可以对文件摘要签名，Bob 可以用 Alice 的公钥验证签名。可是如果 Bob 手里的“Alice 公钥”本来就是 Eve 替换过的，那么 Eve 也可以用自己的私钥签一个新文件，再把自己的公钥冒充成 Alice 的公钥发给 Bob。签名本身没有失效，失效的是“公钥属于谁”这个前提。

所以，PKI 要解决的核心问题不是怎么生成密钥，而是怎么在数字世界里验证身份和公钥之间的绑定关系。

数字证书

数字证书是一份电子文档，用来标识个人、服务器、公司或其他实体，并把这个身份和一把公钥绑定起来。证书的作用可以简单理解为：它不是只给出一把公钥，而是给出“某个被命名的实体拥有这把公钥”的可验证声明。

常见证书会包含这些信息。

X.509 是定义公钥证书格式的 ITU 标准。现实里的 HTTPS 证书、学校 Wi-Fi 证书和许多企业证书都可以按 X.509 的思路理解。浏览器里查看网站证书时，通常能看到证书颁发者、有效期、公钥信息、证书用途和证书链等内容。

PKI 里的三个角色

PKI 不是只有一个“签证书的人”。课件把它拆成三类可信角色。

日常说“CA”时，很多时候会把 RA、CA 和 VA 这几个角色一起概括进去。但在理解流程时，最好先把它们分开：RA 负责申请者身份审核，CA 负责签发，VA 负责后续状态查询。

证书如何签发

一个典型证书签发流程可以拆成四步。

1. 申请者生成一对公私钥，并保管私钥。
2. 申请者把身份信息、公钥和证明自己持有私钥的签名请求提交给 RA 或 CA。
3. RA 检查申请者身份、组织信息和相关材料。
4. CA 用自己的私钥对证书核心内容生成数字签名，并签发证书。

这里的关键细节是“证明自己持有私钥”。如果 Alice 只把公钥交给 CA，CA 能知道这把公钥写在申请里，却不能自动知道 Alice 是否真的掌握对应私钥。更常见的做法是 Alice 提交一个带签名的证书签名请求（Certificate Signing Request，CSR），CA 验证这个请求，从而确认申请者掌握对应私钥。

另一种做法是 CA 替申请者生成密钥对，再把密钥交给申请者。这个方法在某些封闭系统里可能存在，但风险很明显：申请者必须相信 CA 没有保存、泄露或错误分发私钥。对 TLS 服务器证书这类场景来说，由实体自己生成密钥并提交 CSR 是更常见的做法。

证书如何被使用

当 Bob 收到 Peter 的证书时，他不能只看证书上写着“Peter Parker”就直接相信。一个基本验证过程包括以下几步。

1. Bob 读取证书里的主体、公钥、签发者、有效期和签名。
2. Bob 找到签发该证书的 CA 公钥。
3. Bob 用 CA 公钥验证证书签名，确认主体信息和公钥没有被篡改。
4. Bob 检查证书是否仍在有效期内。
5. Bob 检查证书是否已经被吊销。
6. 在 HTTPS 场景中，Bob 还要检查访问的域名是否和证书里的域名匹配。

课件里的直观图示会把验证过程画成“计算证书哈希，再用 CA 公钥处理证书签名，然后比较两个结果”。这有助于理解签名和哈希的关系。不过严格说，不同签名算法的验证细节不完全等同于“解密签名”。更稳妥的说法是：验证者用签发者的公钥运行签名验证算法，确认签名确实覆盖了证书里的核心内容。

CA 层级和信任链

如果全世界只有一个 CA，它既当根 CA，又直接给最终用户签发证书，这叫单层层级（Single-Tier Hierarchy）。它简单，但风险很集中。这个 CA 通常必须在线工作，一旦被攻破，整个体系很难快速恢复，因为根信任本身就出了问题。

更常见的做法是两层层级（Two-Tier Hierarchy）。根 CA（Root CA）保存在更严格的环境中，通常保持离线；中间 CA（Intermediate CA）负责在线签发终端实体证书。这样做提高了安全性、可扩展性和灵活性，但也增加了管理成本。

三层层级（Three-Tier Hierarchy）会在根 CA 和签发 CA 之间再加入策略 CA（Policy CA）或其他中间层。它适合更复杂的组织和政策要求，但同样会让证书路径、运维和审计变得更复杂。

证书路径（Certificate Path）就是从终端实体证书一路追溯到受信任根证书的路径。以网站证书为例，验证者通常会看到这样的链条。

网站证书 -> 中间 CA 证书 -> 根 CA 证书

验证时，浏览器或操作系统会用中间 CA 的公钥验证网站证书，再用根 CA 的公钥验证中间 CA 证书。根证书通常是自签名证书（Self-Signed Certificate），它本身不能靠更高层 CA 来证明，而是因为已经被预置在操作系统或浏览器的信任存储（Trust Store）里才被信任。

这也解释了为什么“根证书自签名”和“普通网站使用自签名证书”不是同一回事。根 CA 自签名是信任锚的形式；普通网站随手生成自签名证书，用户设备通常不会默认信任。

CA 自身如何被保护

PKI 的安全性最终会压到 CA 的私钥和签发流程上。如果 CA 私钥被盗，攻击者就可能签发看起来合法的证书；如果 CA 审核流程失控，也可能把证书发给错误的人。

课件列出的防护手段包括物理安全、多因素门禁、服务器隔离、视频监控、硬件安全模块（Hardware Security Module，HSM）、多人控制（Multiple Person Control），以及让根 CA 和高层 CA 尽量保持离线。它们共同指向一个原则：任何单个人、单台机器或单个流程环节，都不应该轻易拿到最敏感的签发能力。

密钥仪式（Key Ceremony）也是这个原则的集中体现。它通常会把关键操作拆成多人参与、可审计、可记录的步骤，避免某一个人单独生成或启用根密钥。

DigiNotar 案例

课件用 DigiNotar 事件说明 CA 失守的后果。2011 年，DigiNotar 被攻击者入侵，攻击者签发了伪造证书，其中包括用于冒充 Google 服务的证书。Fox-IT 的公开调查报告显示，相关伪造证书被用于针对伊朗用户的大规模中间人攻击，OCSP 日志中识别出约 30 万个访问 Google 的唯一请求 IP 地址，其中超过 99% 来自伊朗。

这个案例的重点不在于某张证书本身，而在于 CA 一旦失去可信性，影响会沿着整个信任体系扩散。浏览器和操作系统可以移除对某个 CA 的信任，但这等于让该 CA 签发的大量证书一起失去基础。对 CA 来说，信任不是抽象声誉，而是业务能否继续存在的前提。

证书吊销

证书会过期，但过期和吊销是两件事。过期时间写在证书里，验证者可以直接检查。吊销（Revocation）则表示证书还没到期，但因为某些原因已经不应该继续使用。

常见吊销原因包括这些情况。

• 私钥泄露
• CA 误签或被攻破
• 证书内容有错误
• 相关实体、域名或组织状态发生变化

吊销有一个麻烦之处：已经发出去的证书本身不会自动改变。系统只能另外发布“这张证书已经不能用了”的状态信息，再让验证者去查询。

CRL 和 OCSP

证书吊销列表（Certificate Revocation List，CRL）是一份由 CA 定期发布的吊销清单。验证者可以下载 CRL，然后查找当前证书的序列号是否在列表里。

CRL 的优点是可以离线检查，只要已经拿到最新列表，就不必每次都访问 CA 的在线服务。缺点也很明显：列表可能很大，下载和查询成本高；发布是周期性的，所以吊销状态可能滞后。

在线证书状态协议（Online Certificate Status Protocol，OCSP）换了一种方式。验证者把某张证书的状态查询发给 OCSP 响应者，返回结果通常有三类。

OCSP 的优点是信息通常更新、更细粒度，查询也比下载大型 CRL 更轻。问题是它依赖在线服务，OCSP 服务器不可用时验证会变复杂；同时，OCSP 请求会暴露用户正在检查哪些站点的证书，带来隐私风险。

把完整流程串起来

从使用者视角看，带 PKI 的公钥通信可以这样理解。

1. Bob 生成一对公私钥。
2. CA 在审核后为 Bob 的公钥签发证书。
3. Alice 获取 Bob 的证书。
4. Alice 沿着证书路径验证 Bob 的证书。
5. Alice 检查证书有效期和吊销状态。
6. Alice 从通过验证的证书中取出 Bob 的公钥。
7. Alice 用 Bob 的公钥加密消息，或用它建立后续安全通信。
8. Bob 用自己的私钥完成解密或协议中的私钥操作。

这里最重要的顺序是，先验证证书，再使用公钥。只要跳过前面的验证，公钥密码学就会退回到“我在网络上看到一把公钥，所以我相信它”的脆弱状态。

小结

PKI 把公钥、身份、签名、证书、CA 层级和吊销机制连成一个系统。它的价值在于让用户不用提前认识每一个服务器，也能通过受信任的 CA 和证书路径判断一把公钥是否属于目标实体。

同时，PKI 的代价也很清楚。信任会集中到 CA、根证书存储和吊销服务上。CA 的私钥保护、签发审核、证书路径验证和吊销检查，任何一环松动，都可能让攻击者把一把错误的公钥包装成看起来可信的身份。

参考资料

• COMP3355 Cyber Security, Public Key Infrastructure (PKI) lecture slides
• Fox-IT 对 DigiNotar 事件的公开调查报告

返回目录

• 回到 COMP3355 课程笔记目录