RSA+AES的下发过程，可算看明白了

知道HTTPS的都知道它是安全传输协议的代表，涉及的SSL等等就不介绍了

这里重点说下最基本的安全通信过程原理RSA+AES，也就是对称加密和非对称加密结合使用的具体过程

这是一次我在公司内部分享的文稿内容，可作为复习使用

---

需要介绍一下 ，对称加密AES比较快，密钥短，安全性略低；而非对称加密RSA速度慢，密钥长，安全性高。

• 对称加密中，一旦客户端密钥泄露，整个传输内容就会发生泄密

• 非对称加密中，公私钥成对出现，公钥通常在客户端，私钥在服务器端。

  • 这过程中不存在传输密钥的情况，不会造成密钥丢失
  • 服务器向客户端发送数据，私钥加密，客户端公钥解密；客户端向服务器发数据，公钥加密，私钥解密。

• 服务器会发布自己的公钥给客户端，非对称加密算法大家都知道，服务器自己保存好私钥。

  • 刚才提到数据传输过程不存在传输密钥的情况，但公钥始终要下发到客户端的，这怎么安全实现？可以先看一下这张图

密钥下发交互

步骤解读跳转：
数字证书 ====》
字符串验证 ====》
对称密钥下发 ====》

---

• 此时还要用到数字证书表示发布公钥的确实是服务器且公钥没被改过。那么数字证书是什么？

数字证书

• 回到交互图
  

• 数字证书，就是服务器要发布的公钥后面带有一串数字签名

• 数字签名，是服务器使用私钥对消息摘要1进行一次加密得到的

• 消息摘要1，是服务器经过hash算法对公钥进行的一次计算得到的

• 使用hash算法，可以确保仅仅有消息摘要1是无法推算出公钥的，而且只要计算前内容与原来公钥不一致，得到的消息摘要就一定会不一样

• 客户端收到这样一份数字证书后，就可以拿证书里的公钥内容对数字签名进行解密，不出意外就能拿到消息摘要1，这时客户端拿hash算法对证书里的公钥内容进行一次计算得到新的消息摘要2，两个消息摘要一对比就可以知道证书的真伪了。

---

字符串验证

• 回到交互图

• 客户端拿到了公钥，可以证明是个真实服务器给过来的公钥了

• 现在要认证对方就是我要通信的那台服务器

• 于是客户端发出一个随机字符串给服务器，服务器收到后用自己的私钥加密发送客户端

• 客户端用刚才证明过有效的公钥进行解密得到字符串，如果和自己生成的随机字符串匹配，那么这就是对的服务器了。

这里存在的问题是：

• 如果黑客也发送自己的伪随机/有规律的字符串给服务器套取私钥的内容，服务器就危险了。
• 所以服务器会给随机字符串进行hash计算得到hash值，然后使用私钥对hash值加密发送给客户端，客户端公钥解密后，自己计算一遍发出去随机字符串的hash值，对比即可。

---

对称密钥下发

• 回到交互图

• 客户端再次随机生成自己的对称加密算法和密钥，放心地使用公钥加密后发送给服务器

• 只有服务器有私钥所以可以拿到对称算法和密钥，往后双方就使用约定好的对称算法和密钥对称加密通信就可以了

这里存在的问题是：

1. 虽然黑客无法解密内容，但他可以捣乱，例如多发几次数据，扰乱通信过程

• 此时可以给通信内容加上序号或随机值，如果任何一方同样的序号或随机值有出现过，那么立即停止通信。———— 如果有人控制了你的路由器就确实可以这样针对你，所以这时必须停止通信。而军方或政府的内容网络不是我们平时用的这种，一般人也破坏不到。

2. 还有可能有人篡改密文，扰乱通信过程，碰碰运气

• 于是发送端在发送消息之前，对明文内容进行hash计算，然后把hash值和明文内容一起加密发出去，接收端收到后解密得到明文和hash值，对明文进行一次hash计算再对比解密出的hash就可以知道是否有篡改密文的情况，从而终止通信等等后续处理。

我们可以发现，一旦需要验证消息有没有被修改过就可以使用hash计算，类似数字证书的用法来验证。