数字签名及数字证书

假设 Alice 要向 Bob 借款 100 万，双方需通过网络完成借贷。核心问题是：如何保证数据在传输中不被篡改，且能证明是 Alice 本人发出、事后无法抵赖。

起初考虑用非对称加密：Bob 生成公钥和私钥，把公钥给 Alice。Alice 用 Bob 的公钥加密数据发送，这样黑客就算中途截获数据，没有 Bob 的私钥也改不了内容。但这里有两个大问题：

1. 真假数据难分辨：如果黑客拿到 Bob 的公钥，也能伪造数据加密后发给 Bob，Bob 无法知道哪份是 Alice 真发的。

2. 抵赖和伪造风险：要是 Bob 自己偷偷改数据金额（比如把 100 万写成 200 万），Alice 无法证明这不是自己签的。

非对称加密只能解决数据传输中的防篡改问题，那如何保证抗抵赖性呢？这里就需要非对称加密除数据加密外的另一个应用 —— 数字签名。

先介绍下何为数字签名：数字签名就像现实中用印章签字一样，是一种在数字世界里证明 “这份信息确实由我发出，且内容没被改过” 的技术。它的核心作用是解决电子信息的身份认证、内容完整性验证和不可抵赖性。

• 私钥与公钥的关系：

每个人有一对 “电子钥匙” —— 私钥（只有自己知道，相当于个人专属印章）和 公钥（可以公开给所有人，相当于印章的 “样式模板”）。私钥和公钥是一一对应的，用私钥 “盖章” 的内容，只能用对应的公钥验证是否有效。

• 签名过程：

比如 Alice 要发送消息给 Bob，她会用自己的私钥给消息 “盖章”，生成一个数字签名。这个签名就像附在消息上的 “电子指纹”，只有 Alice 的私钥能生成，别人无法伪造。

• 验证过程：

Bob 收到消息和签名后，用 Alice 的公钥检查签名是否正确。如果验证通过，就说明：

1. 消息确实是 Alice 发的（因为只有她的私钥能生成这个签名）；

2. 消息在传输中没被篡改过（如果内容被改，签名会失效）。

利用数字签名如何解决上述场景中的问题呢？

• Alice 操作：

① 写好数据内容，用哈希函数生成指纹码；

② 用自己的私钥给指纹码 “盖章”（签名），把数据和签名一起发给 Bob。

• Bob 验证：

① 用 Alice 的公开 “电子公章”（公钥）检查签名是否有效，确认这是 Alice 亲手 “盖章” 的；

② 对收到的数据再生成一次指纹码，和 Alice 附带的指纹码对比，看内容是否一致。

这样一来：

• 若内容被篡改过，指纹码对不上，篡改行为会直接被识破；

• 签名验证通过，说明数据确实是 Alice 用自己的私钥签发的，她事后不能赖账；

• Bob 也没法伪造 Alice 的签名，因为私钥只有 Alice 才有。

在数字签名应用时，很多人会忽略一个致命漏洞：如何确保你拿到的公钥真的属于对方？

公钥同样是通过网络传输给对方的，假设 Alice 想给 Bob 发送签名消息，正常流程是：

1. Alice 需要 Bob 的公钥来验证 Bob 的回复（或 Bob 需要 Alice 的公钥来验证 Alice 的签名）；

2. 但如果黑客 Eve 中途拦截了公钥传输过程，偷偷把自己的公钥伪装成 Bob 的公钥发给 Alice。

后果会有多严重？

• Alice 以为用的是 Bob 的公钥，但实际用的是 Eve 的公钥，结果 Alice 用了 Eve 的公钥对数据进行了加密传输，过程中 Eve 可以随意解密 Alice 的数据并进行篡改。

• 更危险的是，Eve 还能拦截 Alice 发给 Bob 的真实签名消息，用自己的公钥替换后再发给 Bob，Bob 会误以为消息被 Alice 篡改了（因为签名验证不通过）。

![[Pasted image 20250619095042.png]]

数字证书本质是由权威第三方机构（CA，Certificate Authority）签发的 “公钥身份证”，核心功能是绑定公钥与身份的对应关系，流程如下：

1. CA 的公信力基础

CA 就像 “数字世界的公安局”，其自身身份通过物理安全、法律合规性等方式被广泛信任（比如银行、政府认可的 CA）。

2. 证书签发流程

• Bob 向 CA 提交身份信息（如营业执照、身份证）和自己的公钥；

• CA 人工或自动验证 Bob 的身份真实性，确认无误后，用 CA 自己的私钥给 Bob 的公钥 “盖章”，生成数字证书（包含 Bob 的身份信息、公钥、有效期等）。

3. 证书解决公钥信任的逻辑

• Alice 收到 Bob 的公钥时，会同时收到 Bob 的数字证书；

• Alice 用 CA 的公开公钥（内置在操作系统、浏览器中，默认被信任）验证证书上的 CA 签名：

✅ 若验证通过，说明证书是 CA 签发的，Bob 的公钥确实属于他本人；

❌ 若验证不通过，说明公钥可能被篡改或证书是伪造的。

• 没有证书时的信任断层：数字签名只能保证 “签名动作真实”，但无法保证 “公钥对应的身份真实”，就像有人拿着假身份证盖章，签名本身再真实也失去意义。

• 有证书时的闭环验证：

Alice 的验证逻辑：  收到 Bob 的公钥 → 用 CA 公钥验证 Bob 的证书有效性 → 确认公钥与 Bob 身份绑定 → 用该公钥验证 Bob 的签名  

这相当于通过 CA 的 “权威背书”，在数字世界建立了 “身份→公钥→签名” 的完整信任链条。

我们常用的 HTTPS 网站（网址以 https:// 开头）就是数字证书的典型应用：

• 当浏览器访问 HTTPS 网站时：

1. 服务器发送自己的数字证书（由 DigiCert、Let's Encrypt 等 CA 签发）；

2. 浏览器用内置的 CA 公钥验证证书，确认服务器身份（比如确认访问的确实是银行官网，而非钓鱼网站）；

3. 验证通过后，才会用服务器公钥建立加密连接，防止数据被中间人篡改或窃取。

数字签名解决了 “消息是否被篡改、是否由本人发送” 的问题，但缺少数字证书，就无法解决 “公钥对应的身份是否真实” 的问题。两者的关系就像：

• 数字签名是 “电子印章”，负责签内容；

• 数字证书是 “印章的备案证明”，负责证明 “这枚印章确实属于某人”。

只有两者结合，才能在开放的网络环境中构建真正安全的信任体系，避免 “假公钥 + 真签名” 的欺诈风险。