数据传输安全

太过爱你忘了你带给我的痛 2022-05-19 13:26 253阅读 0赞

>  项目中遇到了解签解密，之前就曾经遇到过加密的问题，项目中也曾经遇到过这样的需求，但一直都没有系统的了解，正好这次一起把这块东西搞清楚。

## 数据传输安全的要求 ##

首先我们先明确我们在数据传输时对于安全到底有什么具体要求：

1.  消息的发送方能够确定消息只有预期的接收方可以解密(不保证第三方无法获得，但保证第三方无法解密)。
2.  消息的接收方可以确定消息是由谁发送的（消息的接收方可以确定消息的发送方）。
3.  消息的接收方可以确定消息在途中没有被篡改过（必须确认消息的完整性）。

## 关于加密 ##

针对安全三个要求中的第一个要求，我们可以通过加密的方式解决。那么加密大致又分为对称加密和非对称加密，那么什么是对称加密，什么有是非对称加密呢？

### （一）对称加密 ###

对称加密(也叫[私钥][Link 1]加密)指加密和解密使用相同[密钥][Link 2]的加密算法。有时又叫传统密码算法，就是加密[密钥][Link 2]能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而对称算法的安全性依赖于[密钥][Link 2]，泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信性至关重要。在1976年以前，所有的加密都采用对称加密。

对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。

不足之处是，交易双方都使用同样钥匙，安全性得不到保证。

具体算法：[DES算法][DES]，[3DES][]算法，TDEA算法，[Blowfish][]算法，[RC5][]算法，IDEA算法。

其中最经典的算法莫过于DES加密算法。DES加密采用的是分组加密的方法，使用56位密钥加密64位明文，最后产生64位密文。流程如下，大致了解即可。

![SouthEast][]

### （二）非对称加密 ###

在1976年有两位数学家提出了一个崭新的非对加密的概念：

> 1.A生成一对两把密钥（公钥和私钥）。公钥是公开的，任何人都可以获得，私钥则是保密的。
> 
> 2.B获取乙方的公钥，然后用它对信息加密。
> 
> 3.A得到加密后的信息，用私钥解密。

受这个思路的启发，三位数学家Rivest、Shamir 和 Adleman 设计了一种具体实现上面描述的非对称加密的算法，以他们三个人的名字命名，就是目前在计算机领域应用非常广泛的非对称加密算法[RSA加密算法][RSA]。想深入理解非对称加密解密的原理可以看[这里][Link 3]。

主要算法：RSA、Elgamal、背包算法、Rabin、HD,ECC（椭圆曲线加密算法）。

**虽然非对称加密很安全很强大，但是它也有缺点，相对于对称加密它计算量更大，计算时间更长。所以在大规模数据的安全通信场景中，普遍采用非对称加密技术来交换对称加密密钥，之后的通信都采用对称加密技术加密。**

## 关于签名 ##

利用加密我们满足了第一个要求，数据只有预期的接受方才能解密，但是在这个过程如何保证数据的完整性，保证数据是发送方发送的数据，而不是被第三方篡改后的数据，也就是第三点的要求，这时候就要用到签名。

> 在发送方加密明文之前，给明文取md5值，得到其信息的摘要（注：不能通过信息摘要反推明文）。然后用公钥分别给明文和明文的摘要加密发送到数据的接收方，数据的接收方接收到数据之后，用私钥对密文和摘要进行解密，然后对解密得到的明文取md5摘要，比对解密后的明文摘要和发送过来的摘要是否一致；一致就证明数据是原始的数据没有遭到篡改。

下面是图解过程：

![974749-20170417223347790-1768420464.png][]

## 关于认证模式 ##

讲到这里，其实非对称加密算法中信息的发送方和接收方都分别有两个密钥，其中分别为私钥和公钥（各自的私钥和彼此的公钥），私钥为数据的发送方持有，公钥可以公开。其中涉及到两种模式，它们分别为加密模式和认证模式。

> 在认证模式中，发送方用私钥加密数据，给接收方发送数据，接收方用公钥解密，因为私钥是唯一的，所以只要数据解析成功就可以知道数据发送方是谁。

这样第二点的要求也达成了。

## 总结 ##

结合以上，我们再来整理一下发送方和接收方所做的事情。

发送方：

1.  将消息进行散列运算，得到消息摘要。
2.  使用自己的私钥对消息摘要加密(认证模式：确保了接收方能够确认自己)。
3.  使用接收方的公钥对消息进行加密(加密模式：确保了消息只能由期望的接收方解密)。
4.  发送消息和消息摘要。

接收方：

1.  使用发送方的公钥对消息摘要进行解密(确认了消息是由谁发送的)。
2.  使用自己的私钥对消息进行解密(安全地获得了实际应获得的信息)。
3.  将消息进行散列运算，获得消息摘要。
4.  将上一步获得的消息摘要 和 第一步解密的消息摘要进行对比(确认了消息是否被篡改)。

## 证书机制 ##

与数字签名相关的一个概念就是证书机制了，证书是用来做什么呢？在上面的各种模式中，我们一直使用了这样一个假设，就是接收方或者发送方所持有的、对方的公钥总是正确的（确实是对方公布的）。而实际上除非对方手把手将公钥交给我们，否则如果不采取措施，双方在网络中传递公钥时，一样有可能被篡改。那么怎样解决这个问题呢？这时就需要证书机制了：可以引入一个**公正的**第三方，当某一方想要发布公钥时，它将自身的身份信息及公钥提交给这个第三方，第三方对其身份进行证实，如果没有问题，则将其信息和公钥打包成为**证书（Certificate)**。而这个公正的第三方，就是常说的**证书颁发机构（Certificate Authority）**。当我们需要获取公钥时，只需要获得其证书，然后从中提取出公钥就可以了。

## SSH SSL与HTTPS ##

谈完数据传输安全，不得不提到这几个具体应用的协议了。

### （一）SSH ###

> **Secure Shell**（缩写为**SSH**），由[IETF][]的网络工作小组（Network Working Group）所制定；SSH为一项创建在[应用层][Link 4]和[传输层][Link 5]基础上的安全协议，为计算机上的[Shell][]（壳层）提供安全的传输和使用环境。  
> 传统的网络服务程序，如[rsh][]、[FTP][]、[POP][]和[Telnet][]其本质上都是不安全的；因为它们在网络上用明文传送数据、用户帐号和用户口令，很容易受到[中间人][Link 6]（man-in-the-middle）攻击方式的攻击。就是存在另一个人或者一台机器冒充真正的[服务器][Link 7]接收用户传给服务器的数据，然后再冒充用户把数据传给真正的服务器。  
> 而SSH是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用SSH协议可以有效防止远程管理过程中的信息泄露问题。通过**SSH**可以对所有传输的数据进行加密，也能够防止[DNS][]欺骗和[IP][]欺骗。  
> SSH之另一项优点为其传输的数据可以是经过压缩的，所以可以加快传输的速度。SSH有很多功能，它既可以代替[Telnet][]，又可以为FTP、POP、甚至为[PPP][]提供一个安全的“通道”。

而ssh的数据传输就用到了非对称加密，但是仍存在一个问题，假设A与B之间通信，利用非对称机密，B生成了一对公钥私钥，但在B将公钥传输给A的过程中，出现了C，C假冒了B生成了一堆公钥私钥，然后把公钥传给A，和A建立了加密通道，获取了所有A要发送给B的信息。这就是著名的“中间人”攻击。

为解决这个问题，SSH协议采用由人工判断公钥的fingerprint是否可信的方式。当使用ssh命令连接服务器时，命令行会提示如下信息:

The authenticity of host '168.30.9.213 (<no hostip for proxy command>)' can't be established.
    RSA key fingerprint is 23:42:c1:e4:3f:d2:cc:37:1d:89:cb:e7:5d:be:5d:53.
    Are you sure you want to continue connecting (yes/no)?

输入yes之后才会连接到远程服务器，同时这个信息会存储到用户的.ssh/known\_hosts文件中，下次再登录的时候，会检查known\_host文件，如果存在相同的公钥信息，就不在提示用户确认了。

这种认证方式假设想登陆服务器的用户已经知道服务器公钥（作为服务器的用户他自然有渠道得知服务器公钥）。fingerprint其实就代表公钥，可以看成是公钥的一个压缩版。有了这个步骤，如果有中间人想冒充服务器B发送公钥给A，它不可能生成一对和B生成的一样的公私密钥，他发送给A的公钥必然与B服务器的不同，所以用户就可以根据printfinger判断所连接的服务器是否可信，有没有被中间人冒充。

具体的实现细节可参看[SSH原理简介][SSH]

### （二）SSL与TLS ###

SSH其实是专门为shell设计的一种通信协议，它垮了两个网络层（传输层和应用层）。通俗点讲就是只有SSH客户端，和SSH服务器端之间的通信才能使用这个协议，其他软件服务无法使用它。但是其实我们非常需要一个通用的，建立在应用层之下的一个传输层安全协议，它的目标是建立一种对上层应用协议透明的，不管是HTTP、FTP、还是电子邮件协议或其他任何应用层协议都可以依赖的底层的可安全通信的传输层协议。

网景公司于1994年为解决上面的问题，设计了SSL（Secure Sockets Layer）协议的1.0版本，但并未发布，直到1996年发布SSL3.0之后，开始大规模应用于互联网服务。

跟SSH相比SSL所面临的问题要更复杂一些，上面我们提到，SSH协议通过人工鉴别Public Key的printfinger来判断与之通信的服务器是否可信（不是伪装的中间人）。可是SSL是为了整个互联网上的所有客户端与服务器之间通信而设计的，他们彼此之间不可能自己判断通信的对方是否可信。那么如何解决这个问题呢？

这时候就要用到上述提到的证书机制，证书主要包含了

*  对象的公开密钥
 *  数字签名

如下图所示：

![700][]

因此，利用证书机制就完美了解决了信任问题。

### （三）HTTPS ###

读完上面内容，理解HTTPS就简单了，它的全称是 Hypertext Transfer Protocol Secure，也称为HTTP over SSL,其实就客户端与服务系之间的HTTP通信基于SSL协议。

对于HTTP协议和SSL协议本身没有任何特殊定制，因为SSL本身对HTTP协议就是透明的，HTTP在SSL上运作也不需要任何特殊处理。

### base64 ###

这边还要提下base64，起初以为这也是一种加密算法，其实不是，百度百科中对Base64有一个很好的解释：“Base64是网络上最常见的用于传输8Bit字节码的编码方式之一，Base64就是一种基于64个可打印字符来表示二进制数据的方法”。也就是说，它其实只是一种编码格式。

Base64一般用于在HTTP协议下传输二进制数据，由于HTTP协议是文本协议，所以在HTTP协议下传输二进制数据需要将二进制数据转换为字符数据。然而直接转换是不行的。因为网络传输只能传输可打印字符。什么是可打印字符？在ASCII码中规定，0~31、128这33个字符属于控制字符，32~127这95个字符属于可打印字符，也就是说网络传输只能传输这95个字符，不在这个范围内的字符无法传输。那么该怎么才能传输其他字符呢？其中一种方式就是使用Base64。

也就是说，如果将索引转换为对应的二进制数据的话需要至多6个Bit。然而ASCII码需要8个Bit来表示，那么怎么使用6个Bit来表示8个Bit的数据呢？6个Bit当然不能存储8个Bit的数据，但是4\*6个Bit可以存储3\*8个Bit的数据啊！如下表所示：

![70][]

可以看到“Son”通过Base64编码转换成了“U29u”。这是刚刚好的情况，3个ASCII字符刚好转换成对应的4个Base64字符。但是，当需要转换的字符数不是3的倍数的情况下该怎么办呢？Base64规定，当需要转换的字符不是3的倍数时，一律采用补0的方式凑足3的倍数，具体如下表所示：

![70 1][]

每6个Bit为一组，第一组转换后为字符“U”，第二组末尾补4个0转换后为字符“w”。剩下的使用“=”替代。即字符“S”通过Base64编码后为“Uw==”。这就是Base64的编码过程。

## 参考文献 ##

[SSH、SSL与HTTPS][SSH_SSL_HTTPS]

[签名、加密、证书的基本原理和理解][Link 8]

[什么是Base64？][Base64]

[Link 1]: http://baike.so.com/doc/5284811-5519118.html
[Link 2]: http://baike.so.com/doc/4918532-5137444.html
[DES]: http://baike.so.com/doc/5447735-5686103.html
[3DES]: http://baike.so.com/doc/5438357-5676675.html
[Blowfish]: http://baike.so.com/doc/7724882-7998977.html
[RC5]: http://baike.so.com/doc/2680275-2830191.html
[SouthEast]: /images/20220519/43a591f2e1054026a491ae30aaeaf3d8.png
[RSA]: https://link.jianshu.com/?t=https://zh.wikipedia.org/wiki/RSA%E5%8A%A0%E5%AF%86%E6%BC%94%E7%AE%97%E6%B3%95
[Link 3]: https://link.jianshu.com/?t=http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html
[974749-20170417223347790-1768420464.png]: /images/20220519/98ff2ce3187e4fa1a82d871440a7259e.png
[IETF]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/IETF
[Link 4]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/%E5%BA%94%E7%94%A8%E5%B1%82
[Link 5]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E5%B1%82
[Shell]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/Shell
[rsh]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/Rsh
[FTP]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/%E6%96%87%E4%BB%B6%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE
[POP]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/POP3
[Telnet]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/Telnet
[Link 6]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB
[Link 7]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/%E4%BC%BA%E6%9C%8D%E5%99%A8
[DNS]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/DNS
[IP]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/IP
[PPP]: https://link.jianshu.com?t=https://zh.wikipedia.org/wiki/%E7%82%B9%E5%AF%B9%E7%82%B9%E5%8D%8F%E8%AE%AE
[SSH]: https://link.jianshu.com/?t=http://erik-2-blog.logdown.com/posts/74081-ssh-principle
[700]: /images/20220519/ece7fd36c8dc4354a909472b863f8a22.png
[70]: /images/20220519/d0ace329b3484915a108380b3456e0c7.png
[70 1]: /images/20220519/094c15f1e8b34b87b776415e4f4cbd2f.png
[SSH_SSL_HTTPS]: https://www.jianshu.com/p/5e3f9dfd2cb4
[Link 8]: https://www.cnblogs.com/Caersi/p/6720789.html
[Base64]: https://blog.csdn.net/qq_20545367/article/details/79538530