图解 | 数字签名和数字证书的前世今生

男娘i 2022-12-09 15:56 258阅读 0赞

点击上方“**五分钟学算法**”，选择“星标”公众号

重磅干货，第一时间送达![format_png][]

![format_png 1][]

前言

#  #

这是 2020 年一个平平无奇的周末，小北在家里刷着 B 站，看着喜欢的 up 主视频。

在一旁玩手机的女朋友突然问”你知道数字证书是来干啥的不，为啥浏览器提示证书不可信？”

你要问这个，那我可来劲了，于是乎从加密、数字签名一直讲到了数字证书。。。终于把女朋友讲睡着了，独自写下这篇文章。

# 正文 #

如果你能**非常清晰**的回答出以下问题，可以直接拉到最下面帮我点个赞~，把时间用去陪陪女朋友：

1.  非对称加密中公私钥都可以加密，那么什么时候用公钥加密，什么时候用私钥“加密” ？
2.  什么是数字签名，数字签名的作用是什么？
3.  为什么要对数据的摘要进行签名，而不是直接计算原始数据的数字签名？
4.  什么是数字证书，数字证书解决了什么问题？

这篇文章，主要围绕**数字签名**和**数字证书**的原理以及它们的作用展开。

争取做到让不具备任何密码学基础知识的同学都能听懂，所以在这里需要先对齐一些加密相关的概念 。

## 1. 什么是加密 ##

加密就是**对明文数据按某种特殊算法进行处理，使其成为不可读的一段代码，通常称为“密文“，** 密文通过”密钥“解密后还原出原来的明文，通过这样的途径可以达到保护数据不被非法人窃取、阅读的目的。

定义简单吧？那来看个题，考虑以下哪些属于加密方法：

*  AES
 *  RSA
 *  MD5
 *  BASE64
 *  SM4

这几种都是日常开发中常用的数据编码技术，但是只有 AES、RSA、SM4 才能算是加密方法。

为什么呢？**一个区分的简单方法就是看编码后的数据是否还能还原，能还原的是加密。**

MD5 实际上是对数据进行有损压缩，无论数据有多长，1KB、1Mb 还是 1G，都会生成固定 128 位的散列值，并且 MD5 理论上是不可能对编码后的数据进行还原的，即不可逆。

MD5 因为其具有不可逆性、单向恒定性（相同的数据多次计算值不变）被广泛应用于文件完整性验证、口令加密以及接下来会讲到的数字签名中。

至于 BASE64 是否算做加密方法，仁者见仁。在这里不下结论，因为 BASE64 编码不需要密钥，且编码后的字符串任何人都可以解码出原串，所以一般不认为是加密方法。BASE64 常用来做转码，把二进制字节序列转化为 ASCII 字符序列。

## 2. 加密算法的分类 ##

加密算法按照加解密使用的密钥是否相同，可分为：

*  **对称加密（Symmetric Cryptography）**
 *  **非对称加密（Asymmetric Cryptography）**

#### 1. 对称加密 ####

对称加密是指加密和解密时使用同一个密钥。

![format_png 2][]

### 2. 非对称加密 ###

非对称加密是指加密和解密使用不同的密钥，这两个密钥分别叫做「公钥」、「私钥」。

公钥是可以公开给所有人的，而私钥需要自己保密的。

公钥加密的数据只能用私钥解密：

![format_png 3][]

同理，私钥“加密”的数据只能用公钥“解密”：

![format_png 4][]

大家注意到没，我对 **私钥“加密”** 这里打了引号，为什么呢？

因为私钥不是用来加密的，准确的说法应该是 **「私钥签名，公钥验签」**。

这个问题很多同学都存在误解，认为公私钥都可以用于加密。

实际上不是的，至于为什么，后面讲完签名我会解释的。

## 3. 故事开始 ##

为了讲这个故事，小北请来了密码学中常用的学术情侣，Alice 和 Bob，以及窃听者代表 Eve。

我们从 Alice、Bob 约会的故事展开，来讲讲其中暗藏着哪些危机，又是如何一步步化解的。

### 3.1 第一回合 ###

九月，一个夜黑风高的晚上，Bob 想约 Alice 出来玩，于是给 Alice 发了一封邮件：![format_png 5][]

但我们都知道网络是不可信的，并且由于消息在网络中是明文传输的，所以黑客可以轻易的截获、篡改甚至冒充 Bob。

来，我们看看黑客 Eve 是怎么干的：

![format_png 6][] 黑客窃听伪造

瞧，Eve 轻易的拿到了邮件内容 **（窃听）**，并且修改了邮件内容 **（篡改）**，甚至说他可以随时冒充 Bob 给 Alice 发送邮件 **（伪装）**。

如果上图中 Eve 伪造的内容被 Alice 接收到了，那么后果可想而知。

现实世界中，我们每天都在通过网络进行聊天、转账、浏览不存在网站。

如果都是这样明文传输数据，显然毫无安全感。

#### 3.2 第二回合 ####

既然我们不能明文传输，那么 Bob 和 Alice 提前商量好密钥，使用对称加密对邮件内容加密不就好了~

![format_png 7][] 对称加密

现在 Bob 发送的邮件都使用和 Alice 提前商量好的密钥加密后再传输。

由于没有密钥，Eve 就算截获到数据也无法获取邮件的内容，也没法篡改和冒充 Bob。

因为篡改后的数据必须使用密钥再次加密 Alice 才能正确解密。

那么只要 Bob 和 Alice 能够保证 密钥不泄露，整个通信就是安全的。

如果密钥泄露，被中间人截获，那么就等同于明文通信。

所以我们不能把安全性寄托在人上面。

并且这里也存在一个问题，如果两个人不能线下见面， 如何在网上安全的交换密钥呢？

这似乎是无解的，因为**交换密钥的时候我们必须明文通信，不然对方根本看不懂。但是明文交换即意味着可能泄露。**

但是别忘了我们的密码学工具箱里还有一个好东西— **「非对称加密」**。

Bob 和 Alice 各自生成一对公私钥，因为公钥本来就是公开的，即可以被任何人获取，所以可以通过网络明文交换公钥。

然后使用公钥加密邮件内容后发送给对方，接收者使用自己的私钥即可解密。完美~

#### 3.3 第三回合 ####

来看看，在非对称加密体系下，Bob 如何给 Alice 发消息的。

首先 Alice 需要先生成一对公私钥，私钥只能 Alice 自己知道，公钥是可以让任何人都知道的，因此可将公钥直接发送给 Bob，就算被截获也无所谓。

![format_png 8][] 非对称加密

Bob 使用 Alice 的公钥加密邮件内容，加密后的内容只能由 Alice 的私钥解密，所以就算 Eve 截获也是徒劳。

反之，如果 Alice 想给 Bob 回信，就需要用 Bob 的公钥加密后发送。

这就解决了密钥交换问题，也保证了邮件内容不会泄露。也就是说现在可以**防窃听**。

#### 3.4 如何证明 Bob 是 Bob ####

不知道你注意到没有，这里也存在另外一个问题：

**Eve 也可以使用 Alice 的公钥冒充 Bob 给 Alice 发邮件啊，因为 Alice 的公钥本来就是公开的，任何人都可以获得。**

由于 Eve 也可以获得 Alice 公钥，所以没法防止 Eve **伪造**和**篡改**，并且对于 Alice 而言，她无法分辨出邮件到底是 Eve 发的还是 Bob。

所以这个问题的本质就是 **「Alice 如何确认邮件来自于 Bob」**。

那么在生活中，我们如何做这件事呢？

那就是让 Bob 在纸上**签名**并且**按手印**，因为指纹和字迹是 Bob 独有的，其它人很难伪造。

所以我们需要在计算机中引入类似的机制：

**即只有 Bob 自己能够产生的独一无二的标志，并且其它人能够验证这个标志确实是属于 Bob的。**

这就是我们今天要讲的主题—**「数字签名」。**

还记得什么是 Bob 独有的吗？

对，就是 Bob 自己的私钥，Bob 用自己的私钥对邮件内容计算一个「签名」，将「签名」和邮件内容一起发送出去，接受者 Alice 可以使用 Bob 的公钥验证这个签名是否正确，这就叫「验签」。

如果不是 Bob 的私钥计算的签名，那么 Alice 用 Bob 公钥验签将会出错。

![format_png 9][]

可以看到， Eve 试图使用自己的私钥计算签名然后发送给 Alice， 但是 Alice 使用 Bob的公钥进行验签时将会出错！

那么 Eve 可能篡改内容并冒充 Bob 的签名吗？不可能！因为内容发生改变时，对应的签名也需要重新计算，而签名的生成依赖于私钥，只要 Bob 的私钥不泄露，签名就不会被冒充。

啊啥？你说万一私钥泄露了怎么办？那就当我没说......

所以使用数字签名，我们能够鉴别消息的发送者，也就是说黑客无法伪装发送者进行发送数据，也无法篡改。

> **注意：**
> 
> 可以看出我们这里数据是明文传输的，存在窃听风险。但是我们为了阐述数字签名机制是如何运转的，故意将保证信息机密性的机制省略了。
> 
> 如果想要保证数据的机密性，我们常见的做法是，通信双方通过非对称加密安全交换对称加密的密钥，后续通信过程的数据都使用对称加密保证数据机密性。
> 
> 并且「签名」的作用本身也不是用来保证数据的机密性，而是用于验证数据来源的防止数据被篡改的，也就是确认发送者的身份。

一般而言，我们不会直接对数据本身直接计算数字签名，为什么呢？

因为数字签名属于非对称加密，非对称加密依赖于复杂的数学运算，包括大数乘法、大数模等等，耗时比较久。

如果数据量大的时候计算数字签名将会比较耗时，所以一般做法是先将原数据进行 Hash 运算，得到的 Hash 值就叫做「摘要」。

「摘要」就像人的指纹一样，可以代表一个人，只要内容发生了改变，计算出来的摘要也应该变化。

「摘要」最好是不可逆转的，一般使用开头提到的 MD5 作为 Hash 函数，MD5 输出的结果固定位 128 位。

> **为什么「摘要」最好是不可逆转的？**
> 
> 因为既然 Alice 可以用 Bob 公钥解开签名，那么理论上其它人，比如 Eve 也可以使用 Bob 公钥解开签名拿到数据。
> 
> 所以我们最好对数据的「摘要」进行签名，这样，Eve 就算解开签名，拿到的也是「摘要」，如果摘要是不可逆转的，也就是无法从摘要反推出原文，也就达到了保密的作用。

发送者使用私钥对「摘要」计算数字签名。那么接收者如何验证呢？

![format_png 10][]

接受者 Alice 收到后，取下数字签名，同时用 Bob 的公钥解密，得到「摘要1」，**证明确实是 Bob 发的**。

*( 画外音：如果使用 Bob 的公钥验证签名出错，那么签名一定不是 Bob 的私钥生成的）*

再对邮件内容使用相同的散列函数计算「摘要2」，与上面得到的「摘要1」进行对比，**两者一致就说明信息未被篡改。**

这样两步分证明发送者身份和保证数据未被篡改。

#### 3.5 这就够了吗？ ####

Bob 和 Alice 现在可以依赖于对称加密进行保密通信，也可以依赖于数字签名验证消息是否是对方发送的。

**但是这一切的根基是建立在 Alice 持有的公钥确实是 Bob的，反之亦然。**

什么意思呢？

试想，**Eve 如果将自己的公钥冒充 Bob 发送给 Alice，然后 Alice 保存了下来，那以后凡是 Bob 发送的消息，反而会验证签名失败，被当做冒充者。**那你可能会问，为什么 Eve 可以将自己的公钥发送给 Alice，而 Alice 毫不知情呢？![format_png 11][]

看！我们又回到了最初的起点，只不过这次被篡改的是公钥，之前是消息本身。

因为 Bob 的公钥是直接通过网络发送给 Alice的，所以 Eve 才可以在这一步做手脚，进行篡改，将自己的公钥冒充 Bob 发送给 Alice，也就是发送公钥这一步没有做到：

*  防篡改
 *  防冒充

防篡改怎么和防冒充怎么实现的呢？

我们前面讲了，就是靠数字签名！但是数字签名需要接受者持有发送者公钥，才能进行验签。

**而我们现在处理的是分发公钥这一步，所以.......死锁了。这像是先有鸡还是先有蛋的问题**

现在的问题就是「Bob 无法证明它自己是 Bob」。

这个是不是似曾相识，以前去办事的时候经常被要求出具「我妈是我妈」这类证明。但是我们自己说“我妈就是我妈”，人家根本不会信呀，需要一个可信第三方出具证明，比如派出所。

那么「Alice 如何才能确认 Bob 发送给自己的公钥确实是 Bob 的，而没有被篡改？」

在只有 Alice 和 Bob 两人的情况下是没法验证的。

所以，我们这里也需要一个第三方帮 Bob证明 「Bob 的公钥就是 Bob 的公钥」，有点绕口令那感觉了~

#### 3.6 数字证书 ####

为了解决这个问题，就引入了「数字证书」，什么叫数字证书呢？

百度百科：

> 数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。
> 
> 因此数字证书又称为数字标识。数字证书对网络用户在交流中的信息和数据等以加密或解密的形式保证了信息和数据的完整性和安全性。

看了这个描述，是不是感觉还是云里雾里，还是我用大白话来说吧~

**只要你理解了前面的数字签名，就能理解这里的数字证书，因为我把数字证书叫做「公钥的数字签名」。**

为什么呢？我们引入数字证书的目的是为了保证公钥不被篡改，即使被篡改了也能识别出来。

而防篡改的方法就是数字签名，但是这个签名不能我们自己做，原因说过了，因为我们的公钥还没分发出去，别人无法验证。

所以只能找可信的第三方来帮我们签名，即证书颁布机构（CA），CA 会将：证书的颁布机构、有效期、公钥、持有者(subject)等信息用 CA 的私钥进行签名。

并且将签名结果和这些信息放在一起，这就叫做「数字证书」。

这样，Bob 就可以去 CA 申请一个证书，然后将自己的证书发给 Alice，那么 Alice 如何验证这个证书确实是 Bob的呢？

当然是使用 CA 的公钥进行验签。

> **注意：**
> 
> CA 的公钥也是需要使用证书来分发的，所以 Alice 的电脑必须安装 CA 的证书，证书里包含了 CA 的公钥。

收到 Bob 发过来的数字证书后，Alice 使用 CA 的公钥进行验证，验证通过即证明这确实是 Bob 证书，也就可以使用证书中包含的 Bob 的公钥，按照之前讨论的流程进行通信。

那么 Eve 是否可以在中途篡改 Bob 的证书呢？

答案是不行，因为证书的信息使用 CA 的私钥进行签名，只要 Eve 修改了任何一个 Bit 都会导致最后签名验证不通过。

那 Eve 可不可以修改证书信息后自己重新计算一次证书的数字签名呢？

也不行，因为证书的数字签名计算依赖于 CA 的私钥，Eve 是拿不到 CA 的私钥的。

如果拿到了，说明什么？整个世界都是不可信的。

#### 3.7 数字证书长啥样 ####

这是我电脑中的自带的证书：

![format_png 12][] 电脑自带证书

可以看到，包含了证书持有人的公钥和证书的签名。

另外，证书颁发机构是有层级关系的，下级 CA 的证书是需要由上级 CA 签名的。

换句话说一定存在根证书颁发机构，那么他们的证书是由谁签名的呢？

答案是自签，自己给自己认证。

这是我电脑中的一个自签的根证书颁发机构：

![format_png 13][] 自签的根证书机构

为什么根证书可以自签，谁来保证安全？

你把钱存在银行，你会担心吗？我们基于对国家的信任，才信任银行，这就是信任链的基础！我们思考问题应该是分层的，如果不认可一个统一的基础，一直套娃下去，那么问题就无解。

那还有个问题，如何保证根证书的可靠性？这是操作系统和浏览器预装的，由微软、苹果等操作系统厂商来选择根证书。

#### 3.8 证书不可信？ ####

那么什么情况下浏览器会提示 “证书不可信” 呢？

根据我们上面的分析，下面是可能的原因：

1.  证书不是权威 CA 颁发

有些企业为了贪图便宜使用盗版的证书，没有经过 CA 认证。也就是无法使用浏览器内置 CA 公钥进行验证。

1.  证书过期

上面说了，证书里有一项就是有效期，一般就是一年或者两年的时间。如果证书过期，那么浏览器就会提示“证书不可信”

1.  证书部署错误

可能是服务器证书部署出错，比如证书与域名不匹配，因为证书里有一项是持有人信息的。

好了，饶了一大圈，Bob 终于可以安全的向 Alice 发出前往红树林的邀请了~

# 附录 #

## QA ##

现在我们来回答文章开头提出的一些问题：

1.  非对称加密中公私钥都可以加密，那么什么时候用公钥加密，什么时候用私钥“加密” ？

*  加密场景，那么肯定希望只有我才能解密，别人只能加密。即**公钥加密，私钥解密。**
 *  签名场景，既然是签名，就希望只能我才能签名，别人只能验证。即**私钥签名，公钥验签**

*  什么是数字签名，数字签名的作用是什么？
 *   *  数字签名就是使用私钥对数据摘要进行签名，并附带和数据一起发送。可以起到防篡改、防伪装、防否认的作用。
 *  为什么要对数据的摘要进行签名，而不是直接计算原始数据的数字签名？
 *   *  数据可能比较大，签名是使用非对称加密算法，比较耗时
     *  防止第三方使用公钥解开签名后，拿到原始数据
 *  什么是数字证书，数字证书存在解决了什么问题？
 *   *  数字证书就是由 CA 机构使用自己私钥，对证书申请者的公钥进行签名认证。
     *  数字证书解决了如何安全分发公钥的问题，也奠定了信任链的基础。

[format_png]: /images/20221123/485699d6b6a947599dea650ab6aea35e.png
[format_png 1]: /images/20221123/142b41901d7a4b1287913d6bb8faa413.png
[format_png 2]: /images/20221123/7163ef9325644ce0aa5c01d6776d8587.png
[format_png 3]: /images/20221123/8cd72d384e5b47b681c11fae2eae9d55.png
[format_png 4]: /images/20221123/23141f6e8c9044ff9d745faedfc1b380.png
[format_png 5]: /images/20221123/f34c7d481e4d4defb72c296e3d2a249c.png
[format_png 6]: /images/20221123/c27eedb600c649d8b65a6293317cd176.png
[format_png 7]: /images/20221123/3c9293412ed54449853af8fbc010c320.png
[format_png 8]: /images/20221123/7fd29318abed4998b12b519386979638.png
[format_png 9]: /images/20221123/ecc1349b21e04731aee28b010fa8b2cf.png
[format_png 10]: /images/20221123/b4865088350248fe91f524da69864d09.png
[format_png 11]: /images/20221123/a4224e6839734c6dbf4091ca8946b12a.png
[format_png 12]: /images/20221123/24d852d91e16498cb2354c3bb6f391c5.png
[format_png 13]: /images/20221123/de46a90dd4ff4689a6f9a1a85da2ce22.png