通俗易懂：一篇掌握即时通讯的消息传输安全原理

1、前言

即时通讯（包括IM和消息推送服务）是互联网的重要应用形态之一，安全性一直是开发者需要优先考虑的基础问题，然而一款成功的应用到底要加密什么东西、怎么加密等都是需要在性能、体验和真正的安全性上做好权衡和规划，那么如何正确地理解即时通讯中的加密技术则是重中之中。

本文将通过通俗易懂的文字，引导你一步步理解为何一个即时通讯应用需要加密技术，以及需要何种方式的加密技术等，希望能为您的IM或消息推送服务的设计提供一些参考。

2、参考资料

《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《即时通讯安全篇（五）：对称加密技术在Android平台上的应用实践》
《即时通讯安全篇（六）：非对称加密技术的原理与应用实践》

3、零级通信安全：信息裸传

正如上图所示，很多即时通讯的初级开发者都很少注意到需要为他们的IM或推送服务进行通信加密——直接使用明文在socket中进行收发。

此阶段的通信安全性总结如下：

• 主要特点：在网络上传递明文；
• 安全评估：网络上传递的数据是不安全的，属网络于黑客公共场所，能被截取；
• 导致后果：传递明文无异于不穿衣服裸奔；
• 改进方案：先加密，再在网络上传输。
  

4、初级通信安全：传输密文

此阶段的通信安全特点：

• 服务端和客户端先约定好加密算法，加密密钥；
• 客户端，传输前用约定好的密钥加密；
• 传输密文；
• 服务端，收到消息后用约定好的密钥解密。
  

这么传输消息安全么？

此阶段的通信安全性总结如下：

• 安全评估：客户端的代码是不安全的，属于黑客本地范畴，能被逆向工程，任何客户端与服务端提前约定好的算法与密钥都是不安全的；
• 导致后果：任何客户端的代码混淆，二进制化都只能提高黑客的破解门槛，本质是不安全的；
• 改进方案：不能固定密钥。
  

5、中级通信安全：一人一密

此阶段的通信安全特点：

• 客户端和服务端提前约定好加密算法，在传递消息前，先协商密钥；
• 客户端，请求密钥；
• 服务端，返回密钥；
• 然后用协商密钥加密消息，传输密文。
  

这么传输安全么？

此阶段的通信安全性总结如下：

• 安全评估：首先，网上传输的内容是不安全的，于是乎，黑客能得到加密key=X。其次，客户端和服务端提前约定的加密算法是不安全的，于是乎，黑客能得到加密算法。于是乎，黑客截取后续传递的密文，可以用对应的算法和密钥解密；
• 改进方案：协商的密钥不能在网络上传递。
  

6、高级通信安全：客户端确定密钥、密钥不再传输

此阶段的通信安全特点：

• 协商的密钥无需在网络传输；
• 使用“具备用户特性的东西”作为加密密钥，例如：用户密码的散列值；
• 一人一密，每个人的密钥不同；
• 然后密钥加密消息，传输密文；
• 服务端从db里获取这个“具备用户特性的东西”，解密。
  

这么传输安全么？

此阶段的通信安全性总结如下：

• 安全评估：用户客户端内存是安全的，属于黑客远端范畴，不能被破解。当然，用户中了木马，用户的机器被控制的情况不在此列，如果机器真被控制，监控用户屏幕就好了，就不用搞得这么麻烦了；
• 导致后果：使用“具备用户特性的东西”作为加密密钥，一人一密，是安全的。只是，当“具备用户特性的东西”泄漏，就有潜在风险；
  

7、终级通信安全：一次一密、密钥协商

此阶段的通信安全特点：
每次通信前，进行密钥协商，一次一密。

密钥协商过程，如上图所述，需要随机生成三次密钥，两次非对称加密密钥（公钥，私钥），一次对称加密密钥，简称安全信道建立的“三次握手”，在客户端发起安全信道建立请求后：

• 服务端随机生成公私钥对(公钥pk1，私钥pk2)，并将公钥pk1传给客户端：
  (注意：此时黑客能截获pk1)；
• 客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk11，通过pk1加密，传给服务端：
  (注意：此时黑客能截获密文，也知道是通过pk1加密的，但由于黑客不知道私钥pk2，是无法解密的)；
• 服务端收到密文，用私钥pk2解密，得到pk11；
• 服务端随机生成对称加密密钥key=X，用pk11加密，传给客户端：
  (注意：同理，黑客由密文无法解密出key)；
• 客户端收到密文，用私钥pk22解密，可到key=X。
  

至此，安全信道建立完毕，后续通讯用key=X加密，以保证信息的安全性。

8、本文小结

评估应用安全性的基本原则：

• 网络上传递的数据是不安全的，属于黑客公共场所，能被截取；
• 客户端的代码是不安全的，属于黑客本地范畴，能被逆向工程，任何客户端与服务端提前约定好的算法与密钥都是不安全的；
• 用户客户端内存是安全的，属于黑客远端范畴，不能被破解。
  

加密技术的使用深度决定了最终的安全性：

• 零级安全：明文消息传递如同裸奔，不安全；
• 初始安全：客户端和服务端提前约定加密算法和密钥，不安全（好多公司都是这么实现的=_=）；
• 中级安全：服务端随机生成密钥，发送给客户端，不安全；
• 高级安全：一人一密，客户端使用“具备用户特性的东西”作为加密密钥，弱安全；
• 终级安全：一次一密，三次握手建立安全信道，安全。
  

9、更多即时通讯安全文章

《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《即时通讯安全篇（五）：对称加密技术在Android平台上的应用实践》
《即时通讯安全篇（六）：非对称加密技术的原理与应用实践》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《移动端安全通信的利器——端到端加密（E2EE）技术详解》
《Web端即时通讯安全：跨站点WebSocket劫持漏洞详解(含示例代码)》
>> 更多同类文章 ……

（原文链接：点此进入，有改动）

IM消息是通过tcp传输，是有自定义协议，base64编码传输，还需要进行哈希校验传输吗？会很不安全吗？如果不做哈希校验

引用：JackJiang 发表于 2021-09-08 10:41
这篇有没有去读一下：《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》，这篇在安全性和实用性上 ...

ok马上学习去

引用：登至必极 发表于 2021-09-08 08:04
其实第一步服务器传递pk1至客户端，存在中间人攻击，黑客可以此时可以将自己的公钥pk"传给客户端，然后客户 ...

这篇有没有去读一下：《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》，这篇在安全性和实用性上，比较不错

其实第一步服务器传递pk1至客户端，存在中间人攻击，黑客可以此时可以将自己的公钥pk"传给客户端，然后客户端用pk"加密pk11,此时黑客截获此密文用自己的公钥解开即可。因此最后的终极通信安全 ，如果再加上CA认证机制，确定服务器公钥的真实性就完美了。

http://www.52im.net/thread-2866-1-1.html   上面忘了贴链接地址

上面几位反馈的，方案7中的“为什么要对客户端发送的公钥进行加密”，我想应该是为了防止“中间人攻击”。黑客若明文的客户端公钥，那么可以在client和server之间伪造通信，client端无法发现。可以看看这篇文章的第6节，差不多的意思

通俗易懂，学习了！

3次握手好理解，但是如何保障第一次请求服务器时，服务器是合法的没有伪造，比如说DNS拦截，伪造服务端。

引用：Da.du.M_s28iT 发表于 2018-10-30 16:50
我想了一下，是不是如下更简洁一点：
1客户端生成公私钥，并把公钥传给服务端；
2服务端生成自己的公私 ...

你第一步就错了，从理论上来讲，客户端发起的东西都有可能是黑客伪造过的，所以肯定不能由以客户端为主发起整个过程。

引用：JackJiang 发表于 2018-01-04 15:16
其实是多重加密

我想了一下，是不是如下更简洁一点：
1客户端生成公私钥，并把公钥传给服务端；
2服务端生成自己的公私钥，并用客户公钥加密自己公钥，返回密文；
3.客户端用自己的私钥解密密文，得到服务公钥；
4.以后的请求数据，直接用解密的服务公钥加密传输
这样不就少了一个回路么？好像也没啥风险

引用：mw-im 发表于 2018-01-04 14:00
x每次连接都不同，模拟client拿到也没有用，不会造成伤害

拿到X不就相当于已经被破解了么，7这整个过程不就是为了让X不被泄露么，为什么不会造成伤害

引用：JackJiang 发表于 2018-01-04 15:16
其实是多重加密

为什么加密客户端的公钥呢，公钥被黑客获取有什么问题吗，为什么要多重加密？

引用：mw-im 发表于 2018-01-04 14:05
7 当中的

客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk11，通过pk1加密，传给服务端：
( ...

其实是多重加密

最后一种，如果黑客模拟Client,生成自己的pk11 pk12，那不就能获取X了么

确实通俗易懂 学习了

学习了

引用：。面向阳光. 发表于 2017-08-25 15:26
感谢分享。一直在关注！辛苦！

引用：JackJiang 发表于 2017-08-25 15:19
多谢勘误，已订正，抱歉！

感谢分享。一直在关注！辛苦！

引用：。面向阳光. 发表于 2017-08-25 15:13
文章中：
7、终级通信安全，描述的三次握手过程中有笔误
第2步：客户端随机生成公私钥对(公钥pk11，私钥p ...

多谢勘误，已订正，抱歉！

文章中：
7、终级通信安全，描述的三次握手过程中有笔误
第2步：客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk22，通过pk1加密，传给服务端：
应该是客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk11，通过pk1加密，传给服务端：