我终于搞懂了 数字签名 和 数字证书!

👨‍🏫 考点:数字签名,数字证书

⭐️ 数字签名的概念、原理

--- 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 公钥来源的可靠性

graph TB subgraph ca [数字证书生成过程] direction TB A(["B 生成公钥🔑 + 私钥🔑"])-->B(["B 的公钥 🔑 + 个人信息"]) B--发送-->C(["CA 机构生成数字证书,包含公钥🔑 + B个人信息"]) C --> D(["数字证书 🥇"]) end E(["A 获取数字证书,证明 B 可靠性"])-->D

问题二解决 ❌

🌟 加分点 新的问题产生了,如何确定数字证书不是 C 伪造的?

首先 CA 机构也会维护自己的公钥 🔑 + 私钥 🔑

其次,证书上除了 B 的公钥和个人信息,还有加上 CA 机构对其的数字签名。

B 用 CA 机构的公钥就可以验证数字证书的可靠性

🌟 加分点 又是新的问题,如何证明 CA 机构公钥不是 C 伪造的?

这看起来又回到了原点,目前的方案是证书链+预装根证书

证书链: CA 机构证书是一个树形结构,下层证书的验证依靠上层。

graph TB A(根证书)-->B(证书) A-->C(证书) B-->D(证书) B-->E(证书) C-->F(证书) C-->G(证书) D-->H(...) E-->I(...) F-->J(...) G-->K(...)

预装根证书:一些操作系统、浏览器或者应用程序在出厂的时候,会预先安装根证书,这些证书会被认为是可信的,也就是信任的终点,走出验证的死循环。

🔗 这是我的文章地址:wukaipeng.com/technique/i...

相关推荐
拾光拾趣录8 分钟前
for..in 和 Object.keys 的区别:从“遍历对象属性的坑”说起
前端·javascript
sx24369415 分钟前
day33:零基础学嵌入式之网络——TCP并发服务器
网络·网络协议·http
OpenTiny社区19 分钟前
把 SearchBox 塞进项目,搜索转化率怒涨 400%?
前端·vue.js·github
编程猪猪侠1 小时前
Tailwind CSS 自定义工具类与主题配置指南
前端·css
qhd吴飞1 小时前
mybatis 差异更新法
java·前端·mybatis
YGY Webgis糕手之路1 小时前
OpenLayers 快速入门(九)Extent 介绍
前端·经验分享·笔记·vue·web
患得患失9491 小时前
【前端】【vueDevTools】使用 vueDevTools 插件并修改默认打开编辑器
前端·编辑器
ReturnTrue8681 小时前
Vue路由状态持久化方案,优雅实现记住表单历史搜索记录!
前端·vue.js
UncleKyrie1 小时前
一个浏览器插件帮你查看Figma设计稿代码图片和转码
前端
遂心_1 小时前
深入解析前后端分离中的 /api 设计:从路由到代理的完整指南
前端·javascript·api