Abo

关于密码学里面那些绕来绕去的概念

发表于 | 分类于 | 热度 ℃
字数统计 5.2k | 阅读时长 17

非对称（私钥）算法、对称（公钥）算法、RSA算法、数字签名、数字证书及https协议、TLS/SSL


52533640_p0

密码学真香真好玩

公钥算法与私钥算法

私钥算法

私钥加密算法，又称 对称加密算法，因为这种算法解密密钥和加密密钥是相同的。也正因为同一密钥既用于加密又用于解密，所以这个密钥是不能公开的。常见的有《DES加密算法》、《AES加密算法》。

常见的对称加密算法有DES、3DES、AES、Blowfish、IDEA、RC5、RC6。

公钥算法

RSA算法一直是最广为使用的非对称加密算法

公钥加密算法，也就是 非对称加密算法，这种算法加密和解密的密码不一样，一个是公钥，另一个是私钥：

  • 公钥和私钥成对出现
  • 公开的密钥叫公钥，只有自己知道的叫私钥
  • 用公钥加密的数据只有对应的私钥可以解密
  • 用私钥加密的数据只有对应的公钥可以解密
  • 如果可以用公钥解密，则必然是对应的私钥加的密
  • 如果可以用私钥解密，则必然是对应的公钥加的密

公钥和私钥是相对的，两者本身并没有规定哪一个必须是公钥或私钥。

31704456_p0

实现数据的安全传输

要实现数据的安全传输，当然就要对数据进行加密了。

如果使用对称加密算法，加解密使用同一个密钥，除了自己保存外，对方也要知道这个密钥，才能对数据进行解密。如果你把密钥也一起传过去，就存在密码泄漏的可能。所以我们使用非对称算法，过程如下：

  1. 首先 接收方 生成一对密钥，即私钥和公钥；
  2. 然后，接收方 将公钥发送给 发送方；
  3. 发送方用收到的公钥对数据加密，再发送给接收方；
  4. 接收方收到数据后，使用自己的私钥解密。

由于在非对称算法中，公钥加密的数据必须用对应的私钥才能解密，而私钥又只有接收方自己知道，这样就保证了数据传输的安全性。

20191104191547

划重点：上图即是RSA算法

RSA加密算法是一种非对称加密算法，在公开密钥加密和电子商业中被广泛使用。RSA是1977年由罗纳德·李维斯特、阿迪·萨莫尔和伦纳德·阿德曼一起提出的。当时他们三人都在麻省理工学院工作。RSA就是他们三人姓氏开头字母拼在一起组成的。

图中关于cer证书跟pfx证书以后再说

对信息进行数字签名

除了保证数据的安全传输之外，公钥体系的另一个用途就是对数据进行签名。通常“数字签名”是用来验证发送方的身份并帮助保护数据的完整性。

例如：一个发送者 A 想要传些资料给大家，用自己的私钥对资料加密，即签名。这样一来，所有收到资料的人都可以用发送者的公钥进行验证，便可确认资料是由 A 发出来的了。（因为只有Ａ使用私钥签名得到的信息，才能用这个公钥来解） 采用数字签名，可以确认两点：

  1. 保证信息是由签名者自己签名发送的，签名者不能否认或难以否认。
  2. 保证信息自签发后到收到为止未曾作过任何修改。

之所以可以确认这两点，是因为用公钥可以解密的必然是用对应的私钥加的密，而私钥只有签名者持有。

公钥算法的缺点

现实中，公钥机制也有它的缺点，那就是效率非常低，比常用的私钥算法（如 DES 和 AES）慢上一两个数量级都有可能。所以它不适合为大量的原始信息进行加密。为了同时兼顾安全和效率，我们通常结合使用公钥算法和私钥算法：

  1. 首先，发送方使用对称算法对原始信息进行加密。
  2. 接收方通过公钥机制生成一对密钥，一个公钥，一个私钥。
  3. 接收方 将公钥发送给 发送方。
  4. 发送方用公钥对对称算法的密钥进行加密，并发送给接收方。
  5. 接收方用私钥进行解密得到对称算法的密钥。
  6. 发送方再把已加密的原始信息发送给接收方。
  7. 接收方使用对称算法的密钥进行解密。

数字签名跟数字证书

数字签名

鲍勃给苏珊回信，决定采用”数字签名”。他写完后先用Hash函数，生成信件的摘要（digest）。鲍勃使用私钥，对这个摘要加密，生成”数字签名”（signature）。鲍勃将这个签名，附在信件下面，一起发给苏珊。

苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的

对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。

注意区分数字签名跟数字证书

数字证书

复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成”数字签名”，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。

后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找”证书中心”（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成”数字证书”（Digital Certificate）。

鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。

苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明”数字签名”是否真的是鲍勃签的。

数字证书的实例：https协议

这个协议主要用于网页加密

img

下面，我们看一个应用”数字证书”的实例：https协议。这个协议主要用于网页加密。

img

首先，客户端向服务器发出加密请求。

img

服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端。

img

客户端（浏览器）的”证书管理器”，有”受信任的根证书颁发机构”列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。

img

如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。

img

如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告。

img

如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。

我们就拿segmentfault为例。

2019

我们可以看到这里显示sf安装了证书，并且显示是valid，证明：

1
2
- sf是sf，我没有被劫持到其他站点
- 我和sf之前的通信是加密的，安全的，其他人窃取不到

那么浏览器是怎么验证的sf的证书的呢？还记得上面我提了一句“根证书”么？因为一般我们去申请证书都是通过CA机构，同时大家都信任CA机构比如digicert，verisign，那么我们就可以事先将这些CA机构的证明安装到我们的电脑上，也就是这些CA机构的”公钥”，我们也称它们为“根证书”。（CA把张三的“个人信息”以及“公钥信息”用他的私钥加密成“密文”，把这个密文当做“电子签名”签在了证书上，然后这个证书就被称为“电子证书”，最后再把自己的公钥送给了用户）这些根证书是预先安装在我们电脑上的，所以每当我们访问segmentfault的时候，如果segmentfault服务器上安装了证书，他想和我们建立安全通信，就好比上面例子中，张三直接把公钥发给李四一样，在这里：

1
2
3
segmentfault说：“hi，我们建立安全通信吧，这是我的公钥”
你的浏览器：“你怎么证明你的公钥是你的呢？”
segmentfault说：“这是我的证书，请查看”

然后segmentfault就把安装在服务器上的证书传给你的浏览器，因为你的浏览器已经有一些神器“根证书”的存在，所以这些根证书（CA机构的公钥）就可以来“解密”sf发过来的证书上的签名，然后对比一下解密后的信息和sf证书中所呈现的信息是否一致，如果一致，就ok拉！

最后上一个截图：

2019

大家注意，最上面“DigiCert Global Root CA”，说明我们使用digicert这个CA组织的根证书来进行认证sf的证书，然后digicert替我们证明了sf证书的合理性：“This certificate is valid”，同时给我列出来证书中的一些详细信息，比如：证书的持有者，证书的过期时间，证书中所携带的“公钥”信息（用来验证你得到的公钥确实是sf的）

TLS/SSL协议

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。

（2） 篡改风险（tampering）：第三方可以修改通信内容。

（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

（1） 所有信息都是加密传播，第三方无法窃听。

（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。

（3） 配备身份证书，防止身份被冒充。

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

但是，这里有两个问题。

（1）如何保证公钥不被篡改？

解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

（2）公钥加密计算量太大，如何减少耗用的时间？

解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：

（1） 客户端向服务器端索要并验证公钥。

（2） 双方协商生成”对话密钥”。

（3） 双方采用”对话密钥”进行加密通信。

上面过程的前两步，又称为”握手阶段”（handshake）。

握手阶段的详细过程

img

“握手阶段”涉及四次通信，我们一个个来看。需要注意的是，”握手阶段”的所有通信都是明文的。

客户端发出请求（ClientHello）

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。

在这一步，客户端主要向服务器提供以下信息。

（1） 支持的协议版本，比如TLS 1.0版。

（2） 一个客户端生成的随机数，稍后用于生成”对话密钥”。

（3） 支持的加密方法，比如RSA公钥加密。

（4） 支持的压缩方法。

这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。

服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。

（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2） 一个服务器生成的随机数，稍后用于生成”对话密钥”。

（3） 确认使用的加密方法，比如RSA公钥加密。

（4） 服务器证书。

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。

（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。

至于为什么一定要用三个随机数，来生成”会话密钥”：

“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。

（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。

img

大白话

SSL(secure sockets layer)是TLS(transport layer security)的前身，为什么将他们合起来的，大家可以理解成都属于同一东西的不同阶段吧，比如该协议之前叫SSL后来改名成TLS了。

为什么要有这种协议呢？因为HTTP是使用明文传输，随着网络的发展，安全性越来越重要，所以大家就要想办法让传输更加安全，同时使用密码学的成果，利用“非对称加密算法”的思想以及OSI模型，来对HTTP的信息进行加密。

根据OSI模型，如果向外传输信息就是要从上到下挨个层进行，TLS/SSL也是位于应用层，所以为了加密HTTP的内容，那么TLS/SSL必须位于HTTP下面，可以看成这样：

1
2
3
4
5
HTTP
TLS/SSL
TCP
Ip
..

信息从HTTP经过TLS/SSL非对称加密后传出去，而在接收方，接收到信息是需要一层层向上进行，经过每层的“解包/解密”，最终通过HTTP转换成超文本信息。

所以HTTPS 就是 “HTTP内容向下传输的时候加了一层TLS/SSL加密”，仅此而已，这样，我们就可以实现，使用HTTP协议进行互联网信息传播的时候，对信息进行加密处理了，相信大家已经对非对称加密算法有一定了解了。比如说我们通过HTTPS连接某银行网站，这样我们就可以将我们的密码通过银行给我们的公钥进行加密后发送给银行，而避免了在传输过程中被他人偷看的可能，因为即使他们讲我们的密文盗走，也无法解密，只有银行网站可以解密，为什么？因为只有银行拥有与我们使用“公钥”加密相对的那个“私钥”。

但是同样的问题，就是我们怎么知道我们使用的公钥就是银行给我们的呢？即使我们所访问的域名和银行的域名一致，因为黑客完全可以通过修改我们本地的hosts文件，或者入侵dns，将域名映射到黑客的服务器。所以，这就是CA(certificate authority)，数字证书，数字签名，公钥基础设施(PKI)的作用了

公开密钥基础建设（英语：Public Key Infrastructure，缩写：PKI），又称公开密钥基础架构、公钥基础建设、公钥基础设施、公开密码匙基础建设或公钥基础架构，是一组由硬件、软件、参与者、管理政策与流程组成的基础架构，其目的在于创造、管理、分配、使用、存储以及撤销数字证书。

总结

  1. 每个用户都有一对私钥和公钥。
    • 私钥用来进行解密和签名，是给自己用的。
    • 公钥由本人公开，用于加密和验证签名，是给别人用的。
  2. 当该用户发送文件时，用私钥签名，别人用他给的公钥解密，可以保证该信息是由他发送的。即数字签名。
  3. 当该用户接受文件时，别人用他的公钥加密，他用私钥解密，可以保证该信息只能由他看到。即安全传输。