请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 8
通俗易懂:一篇掌握即时通讯的消息传输安全原理

1、前言


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

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

2、参考资料


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

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


1.png

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

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

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

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


2.png

此阶段的通信安全特点:

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

这么传输消息安全么?

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

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

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


3.png

此阶段的通信安全特点:

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

这么传输安全么?

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

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

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


4.png

此阶段的通信安全特点:

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

这么传输安全么?

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

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

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


5.png

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

密钥协商过程,如上图所述,需要随机生成三次密钥,两次非对称加密密钥(公钥,私钥),一次对称加密密钥,简称安全信道建立的“三次握手”,在客户端发起安全信道建立请求后:
  • 服务端随机生成公私钥对(公钥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的sdk是只需要开发一个就可以,还是不同端需要各自的sdk下一篇:[已回复] MobileIMSDK安卓版sdk中,如何判断退出成功!

本帖已收录至以下技术专辑

推荐方案
评论 8
果然是通俗易懂!
签名: 该会员没有填写今日想说内容.
先收藏,有时间了再仔细看,支持群主
签名: 天气变冷了!
文章中:
7、终级通信安全,描述的三次握手过程中有笔误
第2步:客户端随机生成公私钥对(公钥pk11,私钥pk22),并将公钥pk22,通过pk1加密,传给服务端:
应该是客户端随机生成公私钥对(公钥pk11,私钥pk22),并将公钥pk11,通过pk1加密,传给服务端:
签名: 该会员没有填写今日想说内容.
引用:。面向阳光. 发表于 2017-08-25 15:13
文章中:
7、终级通信安全,描述的三次握手过程中有笔误
第2步:客户端随机生成公私钥对(公钥pk11,私钥p ...

多谢勘误,已订正,抱歉!
签名: 《 WebSocket详解(六):刨根问底WebSocket与Socket的关系》http://www.52im.net/thread-1273-1-1.html
引用:JackJiang 发表于 2017-08-25 15:19
多谢勘误,已订正,抱歉!

感谢分享。一直在关注!辛苦!
签名: 该会员没有填写今日想说内容.
引用:。面向阳光. 发表于 2017-08-25 15:26
感谢分享。一直在关注!辛苦!

签名: 《 WebSocket详解(六):刨根问底WebSocket与Socket的关系》http://www.52im.net/thread-1273-1-1.html
学习了
签名: 哈哈哈哈
确实通俗易懂 学习了
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

Processed in 0.156251 second(s), 40 queries , Gzip On.

返回顶部