默认
打赏 发表评论 25
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
通俗易懂:一篇掌握即时通讯的消息传输安全原理
阅读(257541) | 评论(25 收藏8 淘帖1 3
微信扫一扫关注!

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中,如何判断退出成功!

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

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

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

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

学习了
签名: 哈哈哈哈
确实通俗易懂 学习了
最后一种,如果黑客模拟Client,生成自己的pk11 pk12,那不就能获取X了么
引用:mw-im 发表于 2018-01-04 14:05
7 当中的
  • 客户端随机生成公私钥对(公钥pk11,私钥pk22),并将公钥pk11,通过pk1加密,传给服务端:
    ( ...

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

    为什么加密客户端的公钥呢,公钥被黑客获取有什么问题吗,为什么要多重加密?
    引用:mw-im 发表于 2018-01-04 14:00
    x每次连接都不同,模拟client拿到也没有用,不会造成伤害

    拿到X不就相当于已经被破解了么,7这整个过程不就是为了让X不被泄露么,为什么不会造成伤害
    引用:JackJiang 发表于 2018-01-04 15:16
    其实是多重加密

    我想了一下,是不是如下更简洁一点:
    1客户端生成公私钥,并把公钥传给服务端;
    2服务端生成自己的公私钥,并用客户公钥加密自己公钥,返回密文;
    3.客户端用自己的私钥解密密文,得到服务公钥;
    4.以后的请求数据,直接用解密的服务公钥加密传输
    这样不就少了一个回路么?好像也没啥风险
    引用:Da.du.M_s28iT 发表于 2018-10-30 16:50
    我想了一下,是不是如下更简洁一点:
    1客户端生成公私钥,并把公钥传给服务端;
    2服务端生成自己的公私 ...

    你第一步就错了,从理论上来讲,客户端发起的东西都有可能是黑客伪造过的,所以肯定不能由以客户端为主发起整个过程。
    3次握手好理解,但是如何保障第一次请求服务器时,服务器是合法的没有伪造,比如说DNS拦截,伪造服务端。
    通俗易懂,学习了!
    上面几位反馈的,方案7中的“为什么要对客户端发送的公钥进行加密”,我想应该是为了防止“中间人攻击”。黑客若明文的客户端公钥,那么可以在client和server之间伪造通信,client端无法发现。可以看看这篇文章的第6节,差不多的意思
    http://www.52im.net/thread-2866-1-1.html   上面忘了贴链接地址
    其实第一步服务器传递pk1至客户端,存在中间人攻击,黑客可以此时可以将自己的公钥pk"传给客户端,然后客户端用pk"加密pk11,此时黑客截获此密文用自己的公钥解开即可。因此最后的终极通信安全 ,如果再加上CA认证机制,确定服务器公钥的真实性就完美了。
    打赏楼主 ×
    使用微信打赏! 使用支付宝打赏!

    返回顶部