安全通信|数据加密的由来|加密算法简介|中间人攻击与证书认证|身份验证

👈️下一篇

计算机网络-专栏👈️

数据加密的由来|加密算法简介|中间人攻击与证书认证

引言

在这里插入图片描述

在客户端(client)-服务器(server)模式下，客户端与服务器间通信，如果明文传输数据，在传输过程被劫持，内容直接泄露了，非常不安全；再者，攻击者不仅劫持了数据还篡改了，这样就可能有更大的风险。

于是，为了防止数据泄露，我们很容易想到的是，数据传输前，对数据进行加密，不要明文传输。

那么，就有一个疑问：如何加密？能否解密？如何解密？

于是就有了如何对数据加密的问题。

另外，如果加密的机制被中间人得知，中间人劫持了整个通信过程，而客户端与服务器无感知，这又是一个很大的风险。这时的通信链路就成了：客户端<=>中间人<=>服务端。

于是就有了使用身份验证（如证书认证）来解决中间人攻击的问题。

加密算法

加密算法的分类

加密算法主要有对称加密、非对称加密和哈希算法。

哈希算法

首先，我们来看下哈希算法，它是一种将任意长度的输入数据通过特定算法转换为固定长度输出（哈希值）的算法。

它的典型特点是单向性，即无法通过哈希值反推出原始数据，也就是说它只能加密数据，不能被解密。

主要用于验证数据的完整性和一致性，确保数据在传输或存储过程中未被篡改。

它可以理解为一个函数运算过程，f-就是哈希函数用来对明文x加密，得到一个固定长度的输出-哈希值y。
$y = f (x)$

应用

验证文件完整性

我们下载一些软件的时候常常在它的官网可以看到除了软件包外还提供了哈希值（如官方可能提供了软件包对应的sha512文件，里面包含了软件包sha512哈希运算后的哈希值，其中，sha512是一种哈希算法），它的作用就是用来帮助用户验证下载下来的软件文件完整性，

因为经过网络传输下载到用户本地的文件可能文件损坏——

比如有时候重新下载软件，重装软件就不再有先前的某个问题，可能就是由于软件包下载损坏导致的，

那么如何验证文件是否损坏，是否与官网提供的软件包完全一致？

那就要用到官方提供的这个哈希值验证。

如何验证文件完整性呢？

这个简单，我们已经直到哈希算法不可逆，也就是不能被解密，那我们下载下来的软件包文件重新在我们本地使用同样的哈希算法计算下哈希值，然后与官方提供的哈希值比对，

一致，就表示下载下来的文件是完整的；不一致，就表示我们下载下来的软件包有问题，可能在网络传输中软件包损坏了，那就需要重新下载了。

密码非明文存储

密码常常持久化到数据库系统，

我们已经听说过很多关于数据库泄露的事件，

那么，如果发生了数据库泄露，那么密码也就能泄露了，

而如果密码明文存储，无疑是有很大风险的。

于是，我们非常有必要非明文存储密码，这样即使数据库泄露，密码非明文存储，在不了解加密算法的情况下，也无法晓得密码原文是什么；甚至使用无法解密的算法（比如哈希算法）那自然更无法晓得密码原文是什么。

此种场景使用哈希算法简直再合适不过了，因为哈希算法天然不可逆，密码通过哈希算法加密后无法被还原回原文，即使数据泄露了，也无法得知密码原文是什么，只有用户自己知道密码原文，这样安全性会更高。

至于数据库存储密码哈希值，如何验证登录密码呢？

这个也很简单，和上面我们刚刚分析的文件完整性验证方法类似，当用户密码登录时候，我们对输入的密码进行哈希运算，得到的值与数据库中存储的哈希值比对，一致就表示输入的密码正确。

局限

正如哈希算法本身天然的特点-单向性，被加密后的数据无法解密，无法还原回原文，

因此在很多场景有局限，比如：我们将数据加密传输给服务器，服务器需要解密出请求参数才行，于是哈希算法就不适用了。

对称加密

刚刚我们了解了一种简单的加密算法-哈希算法，它具有单向性，不可逆，即无法还原明文。

于是我们有必要了解下其他的算法，具备可加密、可解密特点的加密算法。

对称加密和非对称加密都能满足这种需求。

首先，我们一起来看对称加密。

对称加密是指在加密和解密过程中使用相同的密钥。发送方使用密钥对数据进行加密，接收方则使用相同的密钥对数据进行解密。

简单了解下原理：在加密过程中，将明文（原始数据）划分为固定长度的块，然后通过密钥和加密算法将这些块转换成对应的密文块。解密过程则是加密过程的逆操作，即使用相同的密钥和解密算法，将密文块还原为明文块。

特点

效率高：由于加密和解密使用相同的密钥，且算法相对简单，因此对称加密通常比非对称加密更快速，适合加密大量的数据。
实现简单：对称加密算法的实现相对简单，不需要大量的计算和存储资源。

缺点

但是，它也有一些安全隐患，主要体现在加密解密使用相同密钥，密钥一旦泄露，就相当于明文传输了，失去了加密的作用；

同时，对称加密本身并未提供身份验证，也就是如果密钥泄露了，可能遭受中间人拦截、篡改数据，有很大风险，

因为客户端无法通过对称加密得知是否是和服务器通信还是在和中间人通信，

同样，服务器无法得知请求是直接来自客户端还是被中间人篡改后转发而来的。

而且对称加密，如果涉及到密钥交换，如何保证在交换密钥过程中密钥不被泄露是个很大的问题。

通常来说，使用对称加密的话，前端后端约定好密钥写死在自己代码中，然后进行加密、解密，但是可能存在前端代码泄露的问题(加载到浏览器中运行，可能发生前端代码泄露)，也无法完全保证密钥不丢失。

对于这些缺点，就要来看下非对称加密了，它解决了密钥交换问题，提供了一定程度的身份验证。以及通过证书认证进行身份验证，来表明响应来自服务端，而非中间攻击者。

非对称加密

公钥和私钥是成对出现的，它们通过一种算法得到，形成一个密钥对。公钥是密钥对中公开的部分，而私钥则是非公开的部分。

公钥公开，那就不存在泄露的问题了，因为它本身就是公开的，不怕泄露。

公钥是发给客户端的，客户端用公钥加密数据，而公钥加密的数据只能被私钥解密，因此即使数据泄露，或者公钥泄露，只要保证服务端私钥未被泄露，就无法获取原文数据。

非对称加密的优势

安全性高：非对称加密算法的安全性基于数学难题，如大素数分解或离散对数问题，使得攻击者难以通过公钥计算出私钥。
提供一定的身份验证和数据完整性保护：非对称加密可以实现身份验证和数字签名（下面会介绍），从而一定程度上确保数据的来源和完整性。

注意事项

效率问题：相对于对称加密，非对称加密的加密和解密过程更加复杂，需要更多的计算资源和时间。因此，在处理大规模数据时，非对称加密可能不是最高效的选择。
密钥管理：私钥的安全托管是非对称加密的关键。私钥必须严格保密，以防止数据泄漏和安全问题。

一定程度解决了身份验证问题

非对称加密在一定程度上解决了身份验证问题，但依旧存在中间人攻击的风险。

数字签名：数字签名是一种使用私钥对数据进行加密（签名）的技术，用于验证数据的完整性和发送者(server)的身份。

发送者（server）使用自己的私钥对数据的摘要（通常是原始数据的哈希值）进行加密，生成数字签名，并将该签名与原始数据一起发送给接收者(client)。

接收者(client)使用发送者的公钥解密数字签名得到数据的摘要（通常是原始数据的哈希值），并对原始数据进行相同的哈希运算，然后将结果与解密后的摘要进行比较。如果两者一致，则表明数据在传输过程中未被篡改，且确实由声称的发送者(server)发送。
中间人无法伪造发送者的私钥来生成有效的数字签名。因此，即使中间人篡改了数据，也无法生成与原始数据相匹配的数字签名。当接收者使用发送者的公钥验证数字签名时，会发现签名无效，从而揭示出潜在的中间人攻击（注意此种场景是客户端已经拿到了服务端提供的公钥）。
但是，有可能在公钥被发送到客户端前就遭受了中间人攻击，中间人拦截了服务端发送给客户端的公钥，它做了客户端同样的工作——获取公钥，验证服务器身份。然后，中间人将自己的密钥对的公钥发送给客户端。

于是，整个通信链路就变作了：客户端<=>中间人<=>服务端，而且客户端和服务器毫无感知。

也就是在传输公钥时遭到中间人攻击，那么整个握手阶段就开始被中间人劫持了，而且客户端和服务端都无感知。[详细分析见：SSL/TSL如何保证安全通信?]

防范中间人攻击

由于缺少身份验证，在握手阶段，服务端发送公钥给客户端的时候，中间人就劫持了服务端公钥，然后将自己的公钥发送给客户端，从而形成客户端<=>中间人<=>服务端这样一个链路，然而客户端与服务端没有机制进行身份验证的话，他们对中间人完全无感知，对当前的通信被劫持就无感。因此，得有一种机制能够让客户端能够识别出拿到的公钥确实是来自请求的服务端，而非中间人.[中间人攻击详细过程分析见：SSL/TSL如何保证安全通信?]

为了防范中间人攻击，可以采取以下措施：

证书认证：通信双方可以通过证书认证机构（CA）来获取和验证对方的公钥。证书认证机构会对公钥进行签名，并将其包含在数字证书中。通信双方通过验证数字证书的有效性来确认公钥的真实性。这样，即使中间人拦截了公钥，也无法伪造有效的数字证书。
使用安全协议(相当于上述内容的组合应用)：如SSL/TLS等安全协议结合了非对称加密、数字签名和证书认证等多种技术，以提供全面的安全保护。这些协议能够确保通信双方的身份验证、数据的机密性和完整性。
定期更新密钥和证书：定期更新密钥和证书可以降低被破解的风险，并增加攻击者的难度。

加密算法、证书认证的应用：SSL/TLS安全性保证

https基于SSL/TLS，保证安全通信保证数据完整性、未篡改，就是利用了证书认证服务器身份，避免了中间人伪装成服务端劫持整个通信过程问题的发生，因为中间人没有服务器证书。

在SSL/TLS握手阶段，服务端将自己的SSL/TLS证书（包含公钥）发送给客户端，

客户端验证服务端证书，确定证书的确是服务器发来的（因为服务端证书私自保管，中间人无法发送服务端的证书过来，中间人发送自己的证书过来也会被客户端识别出来–不是服务端，从而给用户提示当前请求存在风险）。

证书中含有公钥，然后客户端通过公钥来约定会话密钥，因为只有服务端持有私钥可以解密，得到会话密钥。

然后双方通过会话密钥，使用对称加密算法加密、解密，因为对称加密算法效率更高。

这整个过程，避免了中间人攻击，中间人无法伪造成服务端，这是由证书机制保证的；协定会话密钥的数据传输，中间人无法获取、篡改数据，因为只有服务端的私钥才能解密数据；得到的会话密钥就只有客户端和服务端知道，因为它是通过安全的方式传递计算得到的；之后使用对称加密算法，使用会话密钥加密、解密通信，从而确保高效、快速加密解密，从而保证数据在传输过程中的安全性和完整性。

因此SSL/TLS是安全通信机制，https基于SSL/TLS，因此确保了通信的安全性。

【完整的过程分析见后续文章】