我终于搞懂了 数字签名 和 数字证书！
考点：数字签名，数字证书
⭐️ 数字签名的概念、原理
---
title: 明文传输
---
graph LR
subgraph server [B]
B(["响应正文"])
end
subgraph browser [A]
A(["请求正文"])
end
browser -- 请求 --> server
server -- 响应 --> browser
假设现在 A 和 B 互相通信，A 会遇到这么几个问题：
问题一：请求正文被人偷看了怎么办？
问题二：如何确定响应正文是 B 回复的，而不是 C？
问题三：响应正文被 C 篡改了怎么办？
这个时候就需要加密通信的内容了，非对称加密中，会有私钥和公钥，他们有如下特点：
- 私钥加密的内容，只有公钥才能解开，同样地，公钥加密的内容，只有私钥才能解开
- 公钥是公开的，任意人都可以拿到
现在 A 持有公钥，B 持有私钥：
---
title: 加密传输
---
graph LR
subgraph server [B]
B(["私钥 + 响应正文 → 加密内容"])
end
subgraph browser [A]
A(["公钥 + 请求正文 → 加密内容"])
end
browser -- 请求 --> server
server -- 响应 --> browser
假设 C 截获 A 请求的加密内容，由于没有私钥，所以无法确定解开内容。 问题一被解决 ❌
但是，如果 C 截获 B 响应的加密内容，C 持有公钥，就能解开并篡改该内容。问题二和问题三还没有被解决
此时 B 需要给响应正文加上签名。
1️⃣ 响应正文 + Hash 算法 → 摘要
生成的摘要是一段短的乱码，比如：
Hk9yfy1nGXdhi06EDvvTvd/Lq1xsFjxoSYkWm8MmAkkqYXZLraSEzyxxxu4c，只要正文不变，摘要也就不变
2️⃣ 摘要 + 私钥 → 签名
摘要本身很短，加密之后的签名也会更短
3️⃣ 签名 + 响应正文 → 返回给 A
4️⃣ A 摘要 + 公钥 → 原摘要
5️⃣ 响应正文 + Hash 算法 → 新摘要
6️⃣ 对比 原摘要和新摘要
匹配成功，证明响应正文没有被篡改过，解决问题三 ❌
graph LR
subgraph 签名过程
direction RL
subgraph server [B]
direction TB
A(["响应正文 + Hash 算法 → 摘要"])-->B
B(["摘要 + 私钥 → 签名"]) --> C(["签名 + 响应正文"])
end
subgraph browser [A]
direction TB
D(["A 摘要 + 公钥 "]) --> E
E(["响应正文 + Hash 算法 → 新摘要"]) --> F(["对比 原摘要和新摘要"])
end
server -- 响应 --> browser
end
⭐️ 数字证书的概念、原理
可以看到，上述过程中，只解决了内容没有被篡改（即问题一和问题三），但是没有解决内容确实来自于 B（问题二），因为 C 也可以自己生成一对私钥和公钥，让 A 去验证整个解密过程。
如何确定响应正文来自于私钥拥有者，这就涉及到了数字证书：
1️⃣ 私钥拥有者，必然是公钥的拥有者，证明公钥拥有者，也就是间接证明了私钥拥有者
2️⃣ B 把公钥和个人信息发送给证书机构（Certification Authority）
3️⃣ CA 机构颁发一个证书，证书包含 B 的公钥和个人信息
4️⃣ B 把公钥分发到互联网上，也就是验证了 B 公钥来源的可靠性
问题二解决 ❌
加分点 新的问题产生了，如何确定数字证书不是 C 伪造的？
首先 CA 机构也会维护自己的公钥 + 私钥
其次，证书上除了 B 的公钥和个人信息，还有加上 CA 机构对其的数字签名。
B 用 CA 机构的公钥就可以验证数字证书的可靠性
加分点 又是新的问题，如何证明 CA 机构公钥不是 C 伪造的？
这看起来又回到了原点，目前的方案是证书链+预装根证书。
证书链： CA 机构证书是一个树形结构，下层证书的验证依靠上层。
预装根证书：一些操作系统、浏览器或者应用程序在出厂的时候，会预先安装根证书，这些证书会被认为是可信的，也就是信任的终点，走出验证的死循环。
这是我的文章地址：https://wukaipeng.com/technique/interview/digital-signature-and-ca