数字签名与数字证书

3. 故事开始

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

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

3.1 第一回合

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

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

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

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

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

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

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

3.2 第二回合

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

对称加密中加密和解密的密钥相同，那么解密算法只需要是加密算法的逆操作就可以了。

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

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

为什么没办法篡改呢？

因为篡改后的数据必须使用密钥再次加密，Alice 才能正确解密。假设 Eve 试图使用自己的密钥加密然后发送给 Alice， 但是 Alice 使用 Bob的公钥进行解密时将会出错！Alice无法正确解密就会发现不是 Bob 发送的信息。

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

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

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

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

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

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

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

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

3.3 第三回合

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

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

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 公钥验签将会出错。

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

那么 Eve 可能篡改内容并冒充 Bob 的签名吗？

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

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

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

注意：

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

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

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

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

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

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

为什么「摘要」最好是不可逆转的？

因为既然 Alice 可以用 Bob 公钥解开签名，那么理论上其它人，比如 Eve 也可以使用 Bob 公钥解开签名拿到数据。

所以我们最好对「摘要」进行签名，这样，Eve 就算解开签名，拿到的也是「摘要」，如果摘要是不可逆转的，也就是无法从摘要反推出原文，也就达到了保密的作用。

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

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

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

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

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

3.5 这就够了吗？

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

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

什么意思呢？

试想，Eve 如果将自己的公钥冒充 Bob 发送给 Alice，然后 Alice 保存了下来，那以后凡是 Bob 发送的消息，反而会验证签名失败，被当做冒充者。

那你可能会问，为什么 Eve 可以将自己的公钥发送给 Alice，而 Alice 毫不知情呢？

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

因为 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 数字证书长啥样

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

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

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

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

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

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

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

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

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

3.8 证书不可信？

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

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

1、证书不是权威 CA 颁发

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

2、证书过期

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

3、证书部署错误

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

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

QA

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

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

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

2、什么是数字签名，数字签名的作用是什么？

• 数字签名就是使用私钥对数据摘要进行签名，并附带和数据一起发送。
• 可以起到防篡改、防伪装、防否认的作用。

3、为什么要对数据的摘要进行签名，而不是直接计算原始数据的数字签名？

• 数据可能比较大，签名是使用非对称加密算法，比较耗时
• 防止第三方使用公钥解开签名后，拿到原始数据

4、什么是数字证书，数字证书存在解决了什么问题？

• 数字证书就是由 CA 机构使用自己私钥，对证书申请者的公钥进行签名认证。

本篇文章全文来自于以下博客：

一文彻底搞懂加密、数字签名和数字证书，看不懂你打我！-CSDN博客

问题1：加密和签名各自是为了解决什么问题？

（1）首先数据传输过程中存在可能被第三方窃听的问题，那么如何解决呢？因此就提出了加密，将数据变为密文之后再进行传输。

（2）比如有这样一个过程：A向B发送一个信息，使用了加密的方式进行传输，A本来是使用B的公钥进行加密，但是中间人X将B的公钥给替换成了自己的公钥，让A误以为是B的公钥，A使用公钥进行加密，向B发送了消息之后X又进行了拦截，这样X就得到了A发送的信息，又伪造一个信息并使用B的公钥进行加密之后发给B，此时B得到的就是完全错误的信息。

可以发现有两个问题：A无法确定密钥来源和B无法确定密文来源。

那么如何解决这两个问题呢？

密文来源可使用数字签名。

数字签名的全过程分两大部分，即签名与验证。

       一侧为签名，一侧为验证。

       发方将原文用哈希算法求得数字摘要，用签名私钥对数字摘要加密得数字签名，发方将原文与数字签名一起发送给接受方；

      收方验证签名，即用发方公钥解密数字签名，得出数字摘要；收方将原文采用同样哈希算法又得一新的数字摘要，将两个数字摘要进行比较，如果二者匹配，说明经数字签名的电子文件传输成功。

密钥来源可使用数字证书。

数字证书是如何证明证书中的公钥是某个人的？

数字证书的原理是通过持有第三方认证中心颁发的数字证书，来证明持有证书的一方的身份属实。这些认证中心要具有一定的权威性，一般是由政府机构或者一些大型企业来担任。在数字证书的加持下，B想要将自己的公钥发送给A需要经过如下的步骤：

• B生成自己的密钥对，将公钥、个人资料和邮箱发送给认证中心CA。
• CA通过B的个人资料及邮箱验证B确实是B。
• CA生成自己的密钥对，使用自己的私钥对B的公钥、邮箱和个人资料进行签名。
• CA将签名和B的公钥、邮箱和个人资料打包成数字证书，发送给B。
• B得到数字证书之后将其发送给A。
• A获取CA的公钥，利用CA的公钥对B的数字证书进行验证。
• A对数字证书进行解密得到B的公钥。

问题2：加密和签名的区别？

最表象的区别就是加密是公钥加密私钥解密，签名是私钥加密公钥解密。

为什么这样呢？

因为公钥意味着所有人都知道，那么利用公钥进行的步骤就是所有人都可以进行的。

签名和加密都是将数据变为密文，只不过签名的数据是公开的，而加密的数据是保密的，不希望被别人知道的。
比如说 CA证书，CA证书本身信息是公开的：比如域名对应哪个公司，公司信息，等等。但CA证书会包含一个“签名”这个签名将证书信息进行 hash处理，然后用CA机构的私钥加密:这个加密结果就像一个“权威人士的签名认证”，告诉你这个CA是正确的。用户可以使用公钥将“签名”部分进行解密，然后得到CA的哈希，然后自己将CA进行一次哈希，然后对比两个哈希是否相同就可以知道证书是否正确。伪造证书只有2种可能:1伪造者用假证书+真签名。那么用户解密真签名发现这个签名包含