数字签名与"公钥制作者之谜"：信任从何而来
网络安全技术随笔 · 密码学基础篇
摘要
数字签名是现代信息安全体系的基石技术，广泛应用于软件分发、电子合同、HTTPS 传输、代码签名等场景。然而一个常被忽视却至关重要的问题是：数字签名在密码学层面只能证明"消息由持有对应私钥者签署"，却无法证明"公钥归属于声称的那个人"。本文从数字签名的工作原理出发，剖析"无法确认公开密钥的制作者"这一经典问题的成因，并介绍 PKI/CA 体系与信任网络等主流解决方案。
一、数字签名能做什么
数字签名基于非对称密码体制（如 RSA、ECDSA、EdDSA）。一对密钥由两部分组成：
- 私钥：由签名者秘密保管，用于生成签名；
- 公钥：公开发布，用于验证签名。
签名与验证的流程可以简化为：
- 签名：发送方用私钥对消息（通常是消息摘要）进行签名运算，得到签名值；
- 验证：接收方用发送方的公钥对签名值进行验算，判断签名是否与消息匹配。
通过这一机制，数字签名提供三个核心安全性质：
| 性质 | 含义 | 依赖条件 |
|---|---|---|
| 完整性 | 消息在传输中未被篡改 | 公钥真实可靠 |
| 认证性 | 消息确实来自私钥持有者 | 私钥未被泄露 |
| 不可否认性 | 签名者难以否认自己的签名行为 | 上述条件同时成立 |
关键点在于：这三个性质都建立在一个隐含前提之上------验证方手中的公钥确实是签名者的公钥。
二、"无法确认公开密钥的制作者"是什么意思
公钥本身是公开数据，可以自由复制、传播、存储。公钥上不携带任何与真实身份绑定的信息------它只是一串比特，没有"身份证"。
因此，当我们验证一份签名时，密码学只能告诉我们：
这份签名是用某个特定公钥对应的私钥生成的。
它无法告诉我们：
这个公钥背后站着的是谁？它的主人是真实可信的个人、组织，还是一个冒充者？
这就是"无法确认公开密钥的制作者"的准确含义：签名算法保证密钥对的数学对应关系，却保证不了公钥与真实身份之间的归属关系。
三、攻击场景：公钥替换
为了直观理解问题的严重性，考虑如下攻击流程：
假设攻击者 Mallory 想要冒充合法用户 Alice 向 Bob 发送伪造的签名消息：
- Mallory 自行生成一对全新的密钥对（公钥 K_M、私钥 K'_M）；
- Mallory 将 K_M 伪称为"Alice 的公钥"发布或传递给 Bob；
- Mallory 用 K'_M 对伪造内容进行签名并发送给 Bob；
- Bob 用手中那份"声称是 Alice 的公钥"（实为 K_M）验证签名------验证通过；
- Bob 据此误认为消息确实来自 Alice。
整个过程没有任何密码学环节被"破解"，纯粹是信任链条在密钥分发环节被切断。可见：验证通过只能证明签名与所用公钥匹配，无法证明公钥主人的身份可信。
这类攻击在密码学中被称为**中间人攻击（Man-in-the-Middle Attack）**的一种典型形态：攻击者在通信双方之间插入自己的密钥材料，使双方都误以为在与对方直接通信。
四、解决方案：PKI 与 CA
既然公钥本身无法自证身份，业界的主流解法是引入可信第三方来完成"公钥---身份"绑定，这就是 PKI（Public Key Infrastructure，公钥基础设施）。
4.1 数字证书
数字证书（Digital Certificate）是 PKI 的核心载体，本质上是 CA 对"公钥 + 身份信息"的签名背书。一张典型的 X.509 证书包含：
- 主体（Subject）的身份信息：姓名、域名、组织名称等；
- 主体的公钥；
- 证书有效期、序列号等元数据；
- CA 对上述内容的数字签名。
证书的公信力来自 CA 的签名：只要 CA 可信，且证书未被篡改（可用 CA 公钥验证），就可以认为证书中绑定的"公钥---身份"关系是可信的。
4.2 证书链与信任锚
现实世界的 PKI 采用分层结构：
- 根 CA（Root CA）：处于信任金字塔顶端，其自签名证书通常预置于操作系统、浏览器等信任库中，作为"信任锚（Trust Anchor）"；
- 中间 CA（Intermediate CA）：由根 CA 签发证书，负责向下签发实体证书，降低根 CA 私钥的使用频率与泄露风险；
- 终端实体证书：签发给具体的网站、软件厂商或个人。
验证一张终端证书时，验证方沿证书链逐级向上验证签名，最终追溯到已受信任的根证书。只要信任锚可信，整条链上的信任关系就可以被继承。
4.3 CA 体系解决的核心问题
| 问题 | CA 体系的应对 |
|---|---|
| 公钥与身份如何绑定 | CA 通过签发证书完成绑定 |
| 如何防止公钥被替换 | 证书由 CA 签名，篡改即失效 |
| 信任从何开始 | 操作系统/浏览器内置根证书作为信任锚 |
需要强调的是：PKI 并没有消除信任问题，而是把分散的信任集中到了 CA 身上。CA 的安全运营、证书签发审核、吊销机制（CRL/OCSP）等，都是整个信任体系的重要组成部分。历史上曾发生过 CA 被入侵或违规签发证书的事件，这也正是证书透明度（Certificate Transparency）等机制被引入的原因。
五、替代方案：信任网络（Web of Trust）
在没有统一 CA 体系的场景（如 PGP/GPG 邮件加密）中，采用了另一种思路------信任网络（Web of Trust）：
- 每个用户自行签发并分发自己的公钥；
- 用户之间通过见面核验等方式互相为对方的公钥签名背书；
- 信任不是来自单一权威，而是来自"我信任的人信任的人......"的传递关系。
信任网络的哲学与 PKI 不同：PKI 是中心化权威背书 ，Web of Trust 是去中心化的熟人担保 。但二者殊途同归------都在回答同一个问题：公钥到底是谁的？
六、现实中的应用场景
理解这一机制后，很多日常安全现象就豁然开朗：
- HTTPS 证书：浏览器验证网站证书链，防止中间人替换网站公钥进行窃听；
- 软件/驱动签名：操作系统验证发布者签名，防止恶意程序伪装成官方软件；
- 电子邮件 S/MIME：验证邮件发送者的身份与内容完整性；
- 代码提交签名：Git 提交的 GPG 签名，证明提交来自声称的开发者；
- 电子合同/电子政务：基于可信数字证书实现不可否认的法律效力。
七、总结
- 数字签名在密码学上保证密钥对的数学对应关系，这是坚实的；
- 但公钥与真实身份之间的归属关系属于信任问题，密码学本身无法解决；
- "无法确认公开密钥的制作者"正是对这一信任缺口的准确概括；
- 工业界的标准答案是 PKI/CA 证书体系，通过可信第三方的签名背书，把"公钥---身份"绑定关系固化下来；
- 无论采用何种方案，信任总需要一个起点：要么是预置的根证书，要么是熟人之间的相互担保。
理解这一点，是正确使用和评估数字签名、PKI 及其他信任机制的前提。
本文为技术原理科普文章，内容基于公开的密码学与 PKI 标准知识整理，仅供参考。