非对称加密与数字证书
文章目录
- 1 非对称加密
- 2 数字签名
- 3 数字证书
- 4 数字签名和数字证书的区别
- 5 CA 认证中心如何保证权威性
- 6 HTTPS 协议
- 7 HTTPS 与 SSL
- 8 为什么不一直使用HTTPS
1 非对称加密
非对称加密，是指不能从加密密钥推算出解密密钥。加密密钥不需要保密，可以公开，称之为公钥，只需要保守解密秘钥称之为私钥。公钥和私钥是成对的。常见的非对称加密算法有：RSA、Elgamal、背包算法、Rabin、D-H、ECC。
所谓“成对”的含义：如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
举例：甲乙两人通信，甲将他的加密密钥（公钥）公布，任何想与甲通信的人都可以使用这个加密密钥将要传送的信息（明文）加密成密文发送给甲，只有甲自己知道解密密钥（私钥），能够把密文还原为明文。任何第三方即使截获到密文也不可能知道密文所传递的信息。即用公钥加密，私钥解密。
非对称加密保证了乙向甲传递的数据的保密性。第三方由于没有私钥不能解密。但是第三方也能用公钥加密数据，如何保证甲得到的数据是乙发出的呢？这需要配合数字签名技术。数字签名主要是利用哈希函数对要传递的数据进行运算后得到一个运算结果，将该结果也加密发送给甲，甲获取后进行解密，得到运算结果，然后将收到的数据进行相同的哈希运算后的结果进行比较。这个加密解密过程与数据加密解密过程是相反的，乙用私钥加密数据，因此只有乙能加密，所有人都可以用乙的公钥解密，因此第三方无法对伪造的数据进行加密传输。由于哈希函数的单向性（不可逆），第三方无法根据公钥解密后的数据（明文的哈希运算结果）反推哈希运算之前的原数据。
总之，非对称加密保证数据安全，数字签名验证身份。
2 数字签名
假设有一天，Alice 收到了一份署名为 Bob 的文件。Alice 希望能够确认这份文件一定是来自 Bob；另外 Alice 希望能够确信，这份文件在传输过程中并没有被它人篡改。那么基于非对称密钥算法我们应该怎么做？
在信息安全中，文件的安全性有两方面的含义：一是不可抵赖性，即文件一定来自于发送者，也就是身份正确；二是不可篡改性，即确信文件并没有中途被篡改，也就是数据完好。
在非对称密钥算法中提到，公钥加密的内容使用私钥可以解密。同样的，私钥加密的内容使用公钥也可以解密。因此我们可以很容易想到。如果 Bob 利用自己手里的私钥对文件进行加密后，传输给 Alice。Alice 再通过公钥库中 Bob 的公钥进行解密，则可以证明文件一定是由 Bob 发出（由于只有Bob持有私钥）。另外，因为传输的是密文，如果能够使用公钥解密，同时也证明了文件并没有中途被篡改。这样的做法其实已经同时满足了不可抵赖性和不可篡改性。
然而，由于传输的文件可能很大， 为了证明文件的不可抵赖性和不可篡改性，需要对整个文件进行加密，由于非对称算法效率较低，这样做的代价太大。因此常规的做法是用到信息摘要和数字签名的方式。
所谓信息摘要，其实就是某种 Hash 算法，将信息明文转化为固定长
度的字符，它具有如下特点：
- 无论输入的消息有多长，计算出来的消息摘要的长度总是固定的；
- 用相同的摘要算法对相同的消息求两次摘要，其结果必然相同；
- 一般地，只要输入的消息不同，对其进行摘要以后产生的摘要消息也几乎不可能相同；
- 消息摘要函数是单向函数，即不可逆的，而无法从摘要中恢复出任何的消息；（当原文用公钥加密后，这一条能保证摘要的泄露（摘要可用公钥解密）不影响原文的安全性）
- 好的摘要算法，没有人能从中找到“碰撞”，虽然“碰撞”是肯定存在的。即对于给定的一个摘要，不可能找到一条信息使其摘要正好是给定的。或者说，无法找到两条消息，是它们的摘要相同。
一般的，我们将信息的摘要也称作信息的指纹。如同指纹的含义，相同的信息一定会得相同的指纹，而仅通过指纹又无法还原出原始信息。目前主要的摘要算法有 MD5（Message Digest-5）和 SHA1（Secure Hash Algorithm）。
当有了信息摘要技术以后，基于 Bob 向 Alice 发送文件的场景，我们可以进行如下的操作：
第一步：
① 用 Hash 计算摘要：Bob 将原始的信息进行一次信息摘要算法，得到原始信息的摘要值；
② 用密钥加密摘要：Bob 使用自己的私钥，对该摘要值进行加密。得到信息摘要的密文；
③ 打包发送：Bob 将原始文件和摘要值的密文一起发送给 Alice。
一般的，我们将原始文件和摘要密文放一起称作 Bob 对原始文件的签名结果。
第二步：
① 用公钥解密摘要：当 Alice 接收到 Bob 传输的信息（原始文件+信息摘要密文）后，使用 Bob 的公钥将摘要密文解密，得到信息摘要明文；
② 独立计算摘要：使用相同的信息摘要算法，对收到的原文进行计算，获取原始文件摘要信息；
③ 对比摘要：Alice 比较解密后的摘要信息和取得的摘要信息。如果相同，则可以证明文件一定由 Bob 发送，并且中途并没有经过任何篡改。一般将这个过程称作验签。
总之，所谓指纹、摘要，就是原始数据的Hash值；所谓数字签名，就是摘要的私钥加密。这样，即可保证文件的特征（摘要值）一定经过了私钥的加密；同时由于信息摘要的长度普遍不长（MD5为128位，SHA1主要为256位），也并没有带来太大的开销。
3 数字证书
基于非对称密钥算法，Bob 生成了一对公私钥。Bob 将公钥发布在公开的密钥库中。而 Alice 在向 Bob 发送加密文件或者验证 Bob 签名的文件时，均要从公钥库取到 Bob 的公钥。我们已经知道，一般来说公钥就是一段固定长度的字符串，并没有特定的含义。
为了让 Alice 能够方便的辨别公钥，我们可以考虑对给公钥附加一些信息，例如该公钥使用的算法，该公钥的所有者（主题），该公钥的有效期等一系列属性。这样的数据结构我们称作 PKCS#10 数据包（参考https://blog.csdn.net/shenyongjun1209/article/details/52781461 ）。即：
PKCS#10 数据包 = 公钥 + 算法(RSA) + 有效期 + 主题(持有者信息、公司、版本号等)
例如有一天一个叫做 Richard 的人想冒充 Bob，也生成一对公私钥，并且使用了相同的公钥主题封装为 PKCS#10 数据结构。Alice 其实并没有办法分辨哪个是真实 Bob 的公钥。
为了解决这个问题，就需要一个权威的第三方机构，对公钥信息进行认证。就如同对公钥信息文件盖上一个权威的章，防止仿照。这样的权威机构，我们称作 CA (Certificate Authority)，数字证书认证中心。CA 会通过一些手段对公钥持有者以及公钥附加信息进行验证，确保身份无误。
而 CA 如何为公钥信息盖章呢？非常简单，就是前文已经提到的数字签名技术。公钥及其附加信息作为证书的内容，CA 为此内容添加一个数字签名，就构成了一个数字证书。步骤如下：
① CA 机构也持有公钥私钥对（由根 CA 颁发）。CA 会对这份私钥进行特别的保护，严禁泄漏和盗用。
② Bob 将自己的公钥附加上一系列信息后，形成了 P10 数据包（请求包），并发送给 CA。
③ CA 机构通过其他一些手段认证 Bob 的身份，然后使用自己的私钥对P10 请求进行签名。（也可能会先对数据进行一些简单修改，如修改有效期或主题等），签名结果，就称作数字证书。
数字证书同样遵循一个格式标准，我们称作 X509 标准（参考上个超连接）。正如内容示例：
其中写明了 Hash 算法（SHA-1）和非对称加密算法（RSA），包含了持有人的身份信息及其公钥。最下面是 CA 的签名。
如何通过数字证书验证身份和文件信息呢？
第一步： Bob 除了对文件进行签名操作外，同时附加自己的数字证书。一同发给 Alice。
第二步： Alice 进行验签：首先使用 CA 的公钥，对证书进行验证。如果验证成功，提取证书中的公钥，对 Bob 发来的文件进行验签。如果验证成功，则证明文件的不可否认和不可篡改。
可以看到，基于数字证书后，Alice 不在需要一个公钥库维护 Bob（或其他人）的公钥证书，只要持有 CA 的公钥即可。
4 数字签名和数字证书的区别
有了数字签名，为什么还需要数字证书呢？数字签名的验证是在收到的文件中进行的，可以用来验证收到的文件是来源于密钥对（公钥+私钥）的持有者。但是，如何确保此密钥对的持有者就是真实的持有者呢？收到的文件可能来源于第三者。也就是说，如果密钥对被顶替，信息接收方获取的是被掉包的公钥，第三者使用此公钥对应的私钥对文件进行签名，加入冒充的信息发给接收者，那么接收者也能正常解密和验证签名，这就是一个漏洞。即，如何保证公钥是真正的公钥？这就需要数字证书了。
获取数字证书，就是把真正的公钥放到 CA 中，CA 会对公钥持有者进行验证。这样，只要 CA 的权威性得到保障，公钥的真实性也就得到了保障。
相当于把公钥的验证转移到了对 CA 的签名的检验上去了。CA 的签名得到验证后，发送者才能放心的用对方的公钥加密和解密信息。
5 CA 认证中心如何保证权威性
CA 作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。CA 中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA 机构的数字签名使得攻击者不能伪造和篡改证书。
CA 认证中心自己也有一个数字证书，和属于自己的公钥和私钥，这是他们的父 CA 认证中心颁发给他们的。根 CA 认证中心的证书称为根证书，根证书自己认证自己的有效性，根证书是整个证书体系安全的根本，如果根证书出了问题，他下面所有子证书都不可被信任，因为子证书都是依赖根证书证明自己的有效性的，从而形成证书信任链。
- CA 私钥：CA 认证中心/数字证书所有人自己保存，不公开。
- CA 公钥：CA 认证中心/数字证书所有人会把公钥存在父 CA 认证中心为他颁发的数字证书内。
当你要验证一个数字证书可信/合法性时，你需要找到上一层CA认证中心为它颁发的数字证书，并且从中获取公钥，由于一个数字证书是基于上层的数字证书作验证的，那么又怎么验证上层的数字证书是否合法呢？这就会出现一直递归上去的现象，也就是上面说的形成证书信任链。事实也是这样的，验证一个证书是否合法，需要验证到他的最顶层的根证书是否合法！所以上面说到根证书是整个证书体系安全的根本。
6 HTTPS 协议
下面，我们看一个应用 数字证书 的实例：HTTPS 协议。这个协议主要用于 HTTP 通信的加密。
HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport LayerSecurity，安全层传输协议）的组合使用，加密 HTTP 的通信内容。用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。
（1）首先，客户端（浏览器）发起 https 请求；
（2）服务器返回它的数字证书；
（3）客户端验证服务器的证书，以便确认是正确的服务器：浏览器通过 CA 的公钥对证书签名进行校验，检查证书是否有效。另外，客户端持有证书即可完成个人身份的确认。
客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。如果这张数字证书不是由受信任的机构颁发的，浏览器会发出警告：
如果数字证书内容中记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告：
（4）验证通过后，浏览器生成一个临时密钥（对称加密的密钥）并用服务器的公钥对它加密，然后将其发送给服务器；
（5）服务器用私钥解密，得到浏览器发送给它的密钥， 然后用该密钥对数据进行（对称）加密；
（6）浏览器得到加密数据，并用发给服务端的密钥进行解密。
7 HTTPS 与 SSL
HTTPS 是身披 SSL 外壳的 HTTP。HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）协议代替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的HTTP。
在采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全术。
HTTPS 采用混合加密机制。HTTPS 采用对称加密和非对称加密两者并用的混合加密机制。
由于非对称加密与对称加密相比，其处理速度要慢，所以实际应用中将多种方法组合起来用于通信。在交换对称密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称密钥加密方式。
为了更好地理解 HTTPS，我们来观察一下 HTTPS 的通信步骤。
- 步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
- 步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
- 步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
- 步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的SSL握手协商部分结束。
- 步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串（即对称密钥）。该报文已用步骤 3 中的公开密钥进行加密。
- 步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
- 步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
- 步骤 8： 服务器同样发送 Change Cipher Spec 报文。
- 步骤 9： 服务器同样发送 Finished 报文。
- 步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP请求。
- 步骤 11： 应用层协议通信，即发送 HTTP 响应。
- 步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。下图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。在以上流程中，应用层发送数据时会附加一种叫做 MAC（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。
8 为什么不一直使用HTTPS
既然 HTTPS 那么安全可靠，那为何所有的 Web 网站不一直使用 HTTPS？
其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多的 CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。
除此之外，想要节约购买证书的开销也是原因之一。要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不同。那些购买证书并不合算的服务以及一些个人网站，可能只会选择采用 HTTP 的通信方式。