Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 520, comments - 13, trackbacks - 0, articles - 1

2025年9月25日

1、前言

经常发现有开发者将密钥硬编码在Java代码、文件中,这样做会引起很大风险。

信息安全的基础在于密码学,而常用的密码学算法都是公开的,加密内容的保密依靠的是密钥的保密,密钥如果泄露,对于对称密码算法,根据用到的密钥算法和加密后的密文,很容易得到加密前的明文;对于非对称密码算法或者签名算法,根据密钥和要加密的明文,很容易获得计算出签名值,从而伪造签名。

密钥硬编码在代码中,而根据密钥的用途不同,这导致了不同的安全风险,有的导致加密数据被破解,数据不再保密,有的导致和服务器通信的加签被破解,引发各种血案,本文主要借用乌云上已公布的几个APP漏洞来讲讲这其中的潜在风险和危害。

技术交流:

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文已同步发布于:http://www.52im.net/thread-312-1-1.html)

2、风险案例(一):某互联网金融APP加密算法被破解导致敏感信息泄露

某P2P应用客户端,用来加密数据的DES算法的密钥硬编码在Java代码中,而DES算法是对称密码算法,既加密密钥和解密密钥相同。

反编译APP,发现DES算法:

1

发现DES算法的密钥,硬编码为“yrdAppKe”,用来加密手势密码:

2

将手势密码用DES加密后存放在本地LocusPassWordView.xml文件中:

3

知道了密文和加密算法以及密钥,通过解密操作,可以从文件中恢复出原始的手势密码。或者使用新的生成新的手势密码,而与服务器通信时接口中的Jason字段也用了DES算法和密钥硬编码为“yRdappKY”:

4

5

和服务器通信采用http传输,没有使用https来加密通信,如果采用中间人攻击或者路由器镜像,获得流量数据,可以破解出用户的通信内容。

3、风险案例(二):某租车APP加密算法被破解导致一些列风险

某租车APP与服务器通信的接口采用http传输数据,并且有对传输的部分参数进行了加密,加密算法采用AES,但是密钥硬编码在java代码中为“shenzhoucar123123”,可被逆向分析出来,导致伪造请求,结合服务器端的漏洞,引起越权访问的风险,如越权查看其它用户的订单等。

和服务器通信时的数据为:

6

q字段是加密后的内容。逆向APP,从登录Activity入手:

7

分析登录流程:

v1是用户名,v2是密码,v3是PushId,在用户名和密码不为空并且长度不小于11情况下,执行LoginOperate相关操作,追踪LoginOperate的实现,发现继承自BaseOperate,继续追踪BaseOperate的实现。

8

在BaseOperate的initUrl()方法中,找到了APP是怎么生成请求数据的:

9

继续追踪上图中的initJsonUrl()方法,发现其调用了AES加密:

10

继续追踪aes.onEncrypt()函数:

11

在onEncrypt()函数中调用了encrypt()函数用来加密数据,追踪encrypt()函数的实现:

发现其使用AES算法,并且密钥硬编码在java代码中为“shenzhoucar123123”。

12

构造{“id”:”11468061”}的请求:

到现在请求中的数据加密如何实现的就清晰了,另外由于服务器权限控制不严,就可以构造订单id的请求,达到越权访问到其他用户的订单。

13

其中uid设置为你自己的uid即可,可以成功看到其他人的订单:

14

攻击者完全可以做到使用其他脚本重新实现相同的加密功能并拼接出各个接口请求,批量的刷取订单信息和用户其他信息。

4、风险案例(三):某酒店APP加签算法被破解导致一系列风险

某酒店APP和服务器通信时接口采用http通信,数据进行了加密,并且对传输参数进行签名,在服务器端校验签名,以检查传输的数据是否被篡改,但是加签算法和密钥被逆向分析,可导致加签机制失效,攻击者可任意伪造请求包,若结合服务器端的权限控制有漏洞,则可引发越权风险等。

APP和服务器通信的原始包如下图,可以看到有加签字段sign:

15

逆向APP定位到加密算法的逻辑代码,com.htinns.biz.HttpUtils.class,其实现逻辑为:

16

原始数据是unSignData,使用RC4算法加密,密钥为KEY变量所代表的值,加密后的数据为signData,传输的数据时的data字段为signData。 加签字段signd的生成方法是用unsignData拼接时间戳time和resultkey,然后做md5,再进行base64编码。时间戳保证了每次请求包都不一样。 sendSign()算法是用c或c++写的,放入了so库,其他重要算法都是用java写的。

可以使用IDA逆向分析so库,找到sendSign()方法:

17

而乌云漏洞提交者采用的是分析sign和getSign(sign)的数据,做一个算法破解字典。其实还有种方法直接调用此so库,来生成字典。签名破解以后,就可以构造发送给服务器的数据包进行其他方面的安全测试,比如越权、重置密码等。

5、总结及建议

通过以上案例,并总结下自己平时发现密钥硬编码的主要形式有:

  • 1)密钥直接明文存在sharedprefs文件中,这是最不安全的。
  • 2)密钥直接硬编码在Java代码中,这很不安全,dex文件很容易被逆向成java代码。
  • 3)将密钥分成不同的几段,有的存储在文件中、有的存储在代码中,最后将他们拼接起来,可以将整个操作写的很复杂,这因为还是在java层,逆向者只要花点时间,也很容易被逆向。
  • 4)用ndk开发,将密钥放在so文件,加密解密操作都在so文件里,这从一定程度上提高了的安全性,挡住了一些逆向者,但是有经验的逆向者还是会使用IDA破解的。
  • 5)在so文件中不存储密钥,so文件中对密钥进行加解密操作,将密钥加密后的密钥命名为其他普通文件,存放在assets目录下或者其他目录下,接着在so文件里面添加无关代码(花指令),虽然可以增加静态分析难度,但是可以使用动态调式的方法,追踪加密解密函数,也可以查找到密钥内容。

保证密钥的安全确是件难事,涉及到密钥分发,存储,失效回收,APP防反编译和防调试,还有风险评估。可以说在设备上安全存储密钥这个基本无解,只能选择增大攻击者的逆向成本,让攻击者知难而退。而要是普通开发者的话,做妥善保护密钥这些事情这需要耗费很大的心血。

产品设计者或者开发者要明白自己的密钥是做什么用的,重要程度怎么样,密钥被逆向出来会造成什么风险,通过评估APP应用的重要程度来选择相应的技术方案。

6、参考资料

[1] https://www.zhihu.com/question/35136485/answer/84491440

[2] 传输层安全协议SSL/TLS的Java平台实现简介和Demo演示

[3] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

[4] 微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

[5] 来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享

[6] 简述实时音视频聊天中端到端加密(E2EE)的工作原理

[7] 移动端安全通信的利器——端到端加密(E2EE)技术详解

[8] Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)

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

[10] IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

[11] 快速读懂量子通信、量子加密技术

[12] 一分钟理解 HTTPS 到底解决了什么问题

[13] 一篇读懂HTTPS:加密原理、安全逻辑、数字证书等

[14] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

[15] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

[16] 微信技术分享:揭秘微信后台安全特征数据仓库的架构设计

[17] 即时通讯初学者必知必会的20个网络编程和通信安全知识点

[18] 零基础IM开发入门(五):什么是IM系统的端到端加密?

7、IM安全系列文章

本文是IM通讯安全知识系列文章中的第 3 篇,总目录如下:

即时通讯安全篇(一):正确地理解和使用Android端加密算法

即时通讯安全篇(二):探讨组合加密算法在IM中的应用

即时通讯安全篇(三):常用加解密算法与通讯安全讲解

即时通讯安全篇(四):实例分析Android中密钥硬编码的风险》(☜ 本文)

即时通讯安全篇(五):对称加密技术在Android上的应用实践

即时通讯安全篇(六):非对称加密技术的原理与应用实践

即时通讯安全篇(七):用JWT技术解决IM系统Socket长连接的身份认证痛点

即时通讯安全篇(八):如果这样来理解HTTPS原理,一篇就够了

即时通讯安全篇(九):你知道,HTTPS用的是对称加密还是非对称加密?

即时通讯安全篇(十):为什么要用HTTPS?深入浅出,探密短连接的安全性

即时通讯安全篇(十一):IM聊天系统安全手段之通信连接层加密技术

即时通讯安全篇(十二):IM聊天系统安全手段之传输内容端到端加密技术

即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法

即时通讯安全篇(十四):网络端口的安全防护技术实践

即时通讯安全篇(十五):详解硬编码密码的泄漏风险及其扫描原理和工具


(本文已同步发布于:http://www.52im.net/thread-312-1-1.html)

posted @ 2025-10-30 11:24 Jack Jiang 阅读(23) | 评论 (0)编辑 收藏

本文由宅小年分享,感谢原作者,下文有修订和重新排版。

1、引言     

你有没有想过,为什么 ChatGPT 能够像人类聊天一样,一个字一个字地"蹦"出来回答你的问题?为什么股票软件能够实时更新价格,而不需要你疯狂刷新页面?

答案就藏在今天我们要聊的技术里——SSE(Server-Sent Events)!

本文将带你快速认识SSE实时通信协议,包括它的技术原理、常见使用场景、与同类技术的对比以及简单的示例代码等。

cover_opti

技术交流:

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文已同步发布于:http://www.52im.net/thread-4872-1-1.html)

2、AI大模型实时通信技术专题

技术专题系列文章目录如下,本文是第 4 篇:

全民AI时代,大模型客户端和服务端的实时通信到底用什么协议?

大模型时代多模型AI网关的架构设计与实现

通俗易懂:AI大模型基于SSE的实时流式响应技术原理和实践示例

ChatGPT如何实现聊天一样的实时交互?快速读懂SSE实时“推”技术 》(☜ 本文)

《AI大模型时代爆火的SSE技术到底是什么?一文读懂SSE技术的方方面面(下期发布!)》

3、什么是SSE?

我们用一个饭店的比喻来解释:

1)轮询:你点了菜之后,每隔一会儿就跑去问服务员:“我的菜好了没?”

2)SSE:你点了菜,安心坐着。饭做好了,服务员主动来告诉你:“上菜啦!”

3)WebSocket:你和服务员之间装了个对讲机,随时可以互相说话;

4)SSE(Server-Sent Events):一种基于HTTP的单向通信协议,允许服务器主动向浏览器推送数据。它就像一根从服务器连到浏览器的“数据水管”,打开后服务器可以随时通过这根管子“浇水”(推送数据)。

SSE核心技术特点:

1)单向通信:服务器 → 浏览器(像广播电台)

2)基于HTTP:无需特殊协议

3)自动重连:网络中断会自动恢复

4)轻量级:原生浏览器支持,无需额外库

5)低延迟:数据实时到达(毫秒级)。

4、SSE与其他实时通信技术的对比

我们来看一张直观的对比表:


 

场景选择指南:

1)选SSE:当只需要服务器单向推送时(如新闻推送、监控仪表盘),SSE 是最简单省事的选择。

2)选WebSocket:需要双向实时通信(如在线游戏),那就请 WebSocket 登场。

3)选轮询/长轮询:如果只是偶尔有数据变化,使用轮询也许更简单粗暴。

精妙比喻:

1)SSE 像收音机(只能接收信号)

2)WebSocket 像电话(双向通话)

3)轮询 像不断翻信箱查信

4)长轮询 像守在信箱旁等邮差

关于SSE跟其它Web端实时通信技术的详细介绍,可以深入学习以下文章:

Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE

使用WebSocket和SSE技术实现Web端消息推送

详解Web端通信方式的演进:从Ajax、JSONP 到 SSE、Websocket

使用WebSocket和SSE技术实现Web端消息推送

一文读懂前端技术演进:盘点Web前端20年的技术变迁史

网页端IM通信技术快速入门:短轮询、长轮询、SSE、WebSocket

搞懂现代Web端即时通讯技术一文就够:WebSocket、socket.io、SSE

5、SSE技术原理

我们用一个图来简单描绘 SSE 的工作过程:


 

关键要素解析

1)HTTP 请求头:客户端发送 Accept: text/event-stream 告诉服务器"我要接收事件流"

2)响应格式:服务器返回 Content-Type: text/event-stream,然后持续发送数据

3)事件格式:每个事件以 data: 内容\n\n 结束,两个换行符表示事件结束

4)自动重连:连接断开后,浏览器会自动发起新的连接请求

6、SSE的常见应用场景

SSE 已经在很多产品中落地,以下是几个典型场景.

ChatGPT 的回答显示机制:


 

ChatGPT 在回答你问题时,是一句一句“打字式”输出的,没错!就是用了 SSE 来流式传输生成的内容。

后台系统消息提醒,比如:

1)有新的订单;

2)用户提交了新评论;

3)后台工单更新了状态。

4)这些提醒都可以用 SSE 来实时推送。

实时数据面板:

1)股票价格变动

2)区块链交易动态

3)设备温湿度更新

4)只需要后端每隔几秒推送一次,前端就能不断展示最新数据。

7、示例代码(前端+后端)

前端代码(浏览器 JS):

<script>

  const eventSource = new EventSource('/sse/stream');

 

  eventSource.onmessage = function(event) {

    console.log('收到消息:', event.data);

    // 可更新到页面上

  };

 

  eventSource.onerror = function(err) {

    console.error('连接出错', err);

    // 可以展示连接断开的提示

  };

</script>

后端代码示例(Java,使用 Spring Boot 示例):

@RestController

publicclass SseController {

    privatestaticfinal Map<string, sseemitter=""> emitters = new ConcurrentHashMap<>();

 

    // 浏览器连接入口

    @GetMapping("/sse-connect")

    public SseEmitter connect(@RequestParam String userId) {

        SseEmitter emitter = new SseEmitter(30 * 60 * 1000L); // 30分钟超时

        emitters.put(userId, emitter);

 

        // 发送欢迎消息

        try {

            emitter.send(SseEmitter.event()

                    .name("welcome")

                    .data("🎉 连接成功!欢迎使用 SSE 服务"));

        } catch (IOException e) {

            System.err.println("发送欢迎消息失败: " + e.getMessage());

        }

 

        emitter.onCompletion(() -> emitters.remove(userId));

        emitter.onTimeout(() -> emitters.remove(userId));

 

        return emitter;

    }

 

    // 模拟推送服务

    @Scheduled(fixedRate = 2000)

    public void pushData() {

        emitters.forEach((userId, emitter) -> {

            try {

                String json = String.format(

                        "{\"time\": \"%s\", \"value\": %.2f}",

                        LocalTime.now(), Math.random() * 100

                );

 

                // 构建符合SSE格式的消息

                emitter.send(SseEmitter.event()

                        .id(UUID.randomUUID().toString())

                        .name("system-metrics")

                        .data(json));

            } catch (IOException e) {

                emitters.remove(userId);

            }

        });

    }

}

curl --location 'localhost:18500/sse-connect?userId=1' \

--header 'Key: Accept' \

--header 'Value: text/event-stream'


 

8、本文小结

SSE 就像一个贴心的"消息推送员",让服务器能够主动把最新消息送到你面前,而不需要你频繁地去"敲门询问"。它简单易用,特别适合那些需要服务器主动推送数据的场景。

虽然 SSE 没有 WebSocket 那么"全能"(不能双向通信),但正是这种专一性让它在特定场景下变得格外实用。就像专门的快递员虽然只负责送货,但在送货这件事上做得特别专业一样。

如果你正在开发一个需要实时推送但通信不需要太复杂的应用,SSE 是一个轻量又可靠的选择,特别适合现代网页、后台系统、数据展示等场景。

写在最后:Web 开发永远不止一种解决方案。选择最合适的技术,而不是最“酷”的技术,才是工程师的智慧体现。

9、参考资料

[1] Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE

[2] SSE技术详解:一种全新的HTML5服务器推送事件技术

[3] 使用WebSocket和SSE技术实现Web端消息推送

[4] 详解Web端通信方式的演进:从Ajax、JSONP 到 SSE、Websocket

[5] 使用WebSocket和SSE技术实现Web端消息推送

[6] 一文读懂前端技术演进:盘点Web前端20年的技术变迁史

[7] WebSocket从入门到精通,半小时就够!

[8] 网页端IM通信技术快速入门:短轮询、长轮询、SSE、WebSocket

[9] 搞懂现代Web端即时通讯技术一文就够:WebSocket、socket.io、SSE

[10] 大模型时代多模型AI网关的架构设计与实现

[11] 全民AI时代,大模型客户端和服务端的实时通信到底用什么协议?

[12] 通俗易懂:AI大模型基于SSE的实时流式响应技术原理和实践示例

[13] Web端实时通信技术SSE在携程机票业务中的实践应用

(本文已同步发布于:http://www.52im.net/thread-4872-1-1.html)

posted @ 2025-10-23 10:33 Jack Jiang 阅读(31) | 评论 (0)编辑 收藏

1、MobileIMSDK开源工程

1

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOS、Android、H5、小程序、Uniapp、标准Java平台,服务端基于Netty编写。

工程同步开源地址:

2、关于RainbowChat

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题。RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP、WebSocket三种通信协议的IM产品。与姊妹产品RainbowTalkRainbowChat-Web 技术同源,历经考验。

APP_Store_v10.2

3、v10.2 更新内容

此版更新内容更多历史更新日志):

  • 1)[优化] 修改了首页中网络断开提示ui的显示方式;
  • 2)[优化] 修改了世界频道中“免打扰”按钮;
  • 3)[优化] 修改了首页中“一键已读按钮”;
  • 4)[优化] 将世界频道改为首页列表中显示而不是独立的浮动层;
  • 5)[优化] 解决了iOS 26下聊天界面中因topLayoutGuide.length返回值异常导致的ui问题;
  • 6)[优化] 解决了iOS 26下聊天界面下方更多面板显示时会多出一个17像素的系统自带的圆角效果;
  • 7)[优化] 优化了iOS 26下聊天界面中的消息列表顶部会多出10个像素的空白;
  • 8)[优化] 给各种按钮增加了iOS 26液态玻璃点击效果;
  • 9)[优化] 其它适配iOS 26的各种细节优化。

v10.2_vs_v10

4、iOS 26上的运行效果概览

v10.2_ios26

5、iOS 26上的真机实拍概览

5

6、部分功能运行截图预览

(☞ 更多截图点此查看 ☜)

v10.2拼合总图-pct75-size50

posted @ 2025-10-16 10:54 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

     摘要: 本文来自小白debug的原创分享,原题“【修正版】动图图解!代码执行send成功后,数据就发出去了吗?”,下文有修订和排版优化。1、引言回复过很多IM初学者关于MobileIMSDK  通信层代码的疑问,最基础的问题就是“明明用的是TCP协议,而TCP协议也被称为可靠的通信协议,那为什么TCP代码中明确能知道数据是否发送成功,为什么仍然需要应...  阅读全文

posted @ 2025-10-15 14:59 Jack Jiang 阅读(37) | 评论 (0)编辑 收藏

1、引言

平时开发工作中,我们会经常接触加密、解密的技术。尤其在今天移动互联网时代,越来越多的用户会将数据存储在云端,或使用在线的服务处理信息。这些数据有些涉及用户的隐私,有些涉及用户的财产,要是没有一套的方案来解决用户的数据安全问题的话,这将是一个多么可怕的事儿。

作为开发者,也会经常遇到用户对数据安全的需求,当我们碰到了这些需求后如何解决,如何何种方式保证数据安全,哪种方式最有效,这些问题经常困惑着我们。52im社区本次着重整理了常见的通讯安全问题和加解密算法知识与即时通讯/IM开发同行们一起分享和学习。

技术交流:

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

本文已同步发布于:http://www.52im.net/thread-219-1-1.html

2、通讯安全性威胁

一般的,我们在网络中传输的数据,都可以认为是存在这潜在的风险的。用一句话来概括就是:“任何在网络中传输的明文数据都存在安全性威胁。

下面就列举下我们通信中面临的四种威胁:

  • 1)中断:攻击者有意破坏和切断他人在网络上的通信,这是对可用性的攻击;
  • 2)截获:属于被动攻ji,攻击者从网络上qie听他人的通信内容,破坏信息的机密性;
  • 3)篡改:攻击者故意篡改网络上传送的报文,这是对完整性的攻击;
  • 4)伪造:攻击者伪造信息在网络传送,这是对真实性的攻击。
1

我们经常说加密解密算法是数据安全领域里的“剑”,是一种主动的防护,对数据进行必要的加密处理,以保证其在数据传输、存储中的安全。接下来讲着重讲解加解密算法知识。

3、Base64算法介绍

3.1 原理

严谨的说,base64并不是加密算法,这里提到他是因为他的实现比较简单,通过他的实现,我们可以更好的理解加密解密的过程。

下面看下他是如何“加密”的。假设我们要对“BC”字符串进行加密。现将其转换为二进制表达方式,并连起来:01000010 01000011,接下来对二进制按6位分组,不够6位补0,得到010000、100100、001100(最后两位补0)。下面查表,找到对应的值“QKM”。那么“QKM”就是“BC”用base64“加密”后的值了。

2

从上面的base64算法,我们可以窥视部分加密的本质:将一段有意义的信息,通过某种方式,映射为一段看不懂的信息。

使用函数表达即为:

public Ciphertext encrypted(Plaintext text);

值得注意的是:base64里有一张映射表,如果改变映射表的顺序,最终得到的结果就会跟着改变。有点类似烹调,在相同原料、相同烹调方式下,我们改变加入的调料,最终做出的东西将会也不一样。这里的映射表,我们叫之为“密钥”。

3.2 小结

通过base64算法可以看出,一个加密算法会有两部分组成:

  • 1)密钥;
  • 2)算法。

两者不能都公开,都公开的话,就可以被人逆向运算,进行解密。

一般的:我们将密钥进行保密,将算法进行公开。算法的公开,有利于算法的推广,普及,更有利于寻找算法中的漏洞。也就是因为base64同时公开了算法、密钥,所以我们说他并不是真正的加密算法。当然如果你调整了上面映射表,那么也能做到加密算法的目的,不过base64加密的强度比较差,所以不建议在实际应用中作为加密算法使用。

4、摘要算法介绍

4.1 基本

我们在平时的工作中经常听到MD5算法。比如在一些下载页面里会给出一个md5的作为文件验证串,在迅雷下载中作为文件的唯一标识。

这类算法严格上来说也不是加密算法,是一种叫做摘要算法的算法,不过在平时的使用中,我们经常将摘要算法混合使用,所以在广义上来说也可以将他叫为加密算法。

4.2 摘要长度

摘要算法的特点是可以将任意长度的字符串,给转换为定长的字符串。

可以意料的是,在这个转换过程中,一定是一共单向的过程。打个比方,我们将一个256长度的字符串转换为128长度的字符串,转换前有N^256种可能,转换后有N^128种可能,这一定不可能是1对1的对应关系。

所以我们只要保证摘要串(转换后的串)位数只够的长,使得“给定一个字符串A,经过摘要算法处理后的串B,很难找到一个字符串C,其摘要后的串和串B相同” 即可。所以目前主流的摘要算法MD/SHA的摘要串长度都在128位以上。而正是出于这个原因,美国还对长摘要串的加密算法进行了出口的限制。

4.3 通讯模型

摘要算法在平时的使用中,经常以如下的形式进行:

假设客户端需要传输一段信息data给服务器端,为了data在网络中数据的完整性,或者说防止信息data被恶意的用户篡改,可以始终这种安全通信模型:客户端与服务器端实现确定了加密密钥key,一段任意的字符串,客户端将key与数据data拼接在一起,进行摘要得到摘要串C,将data、C传给服务器端,服务器端得到data和C后,同样使用与客户端相同的方法,计算摘要串S,如果S等于C的话,就说明A在传输中,没有被人篡改。

流程如下图:

3

对于我们在通信的面临的四种威胁,摘要算法是否能防范呢:

  • 1)截获:由于网络中传输的数据依然的明文的,对于攻击者来说暴露无遗,所以摘要算法对于这种威胁,没什么办法。
  • 2)中断:摘要算法,是对数据的验证,对整个网络的可用性方面的攻击,无法防范。
  • 3)篡改:客户端发出的数据,中途被攻击者进行了修改,由于攻击者并不知道密钥key,将无法生成正确的摘要串。所以,摘要算法可以防范篡改威胁。
  • 4)伪造:攻击者伪造成客户端,给服务器端发数据,但由于拿不到密钥key,伪造不出摘要串。所以,在这种情况下,摘要算法是有一定的防范作用的。但是,在伪造威胁中,还有一种是重放攻击,攻击者事先将客户端发给服务器端的包截下来,然后重复发送。例如:客户端发给服务器端密码时,被攻击者记录了下来,当下次,服务器端再向客户端询问密码时,攻击者只需将记录下来的包发给服务器端即可。所以摘要算法对于伪造威胁的防范是不彻底的,其只可以辨别伪造的内容,不能辨别伪造的发送方。
4

常见的摘要算法有MD5/MD4/SHA-1/SHA-2等,其摘要串长度也不尽相同。现在MD4/MD5/SHA-1等一些摘要串长度128比特的摘要算法已不再安全,山东大学的王小云教授已经证明MD4/MD5/SHA-1已经可以快速生成“碰撞”。所以在真正的对安全性要求极高的场所还是使用长摘要串的摘要算法来的靠谱一些。

5

5、对称加密算法介绍

5.1 基本

理论上说对称加密算法,才是我们真正说的加密算法。

所谓对称加密算法,通俗的讲,就是使用密钥加密,再使用密钥解密的加密算法的总称。也就是平时我们说到加密算法,脑子里第一个跳出来的加密方式一般都是对称加密算法。上面将的base64其实也是一种“对称加密算法”,只是其密钥公开了而已。

5.2 通讯模型

同样的场景:客户端要将数据data发给服务器端。客户端对使用密钥key,对数据data加密,生成加密串C,通过网络将C传输为服务器端,服务器端,使用密钥key对C解密,获取数据data,做自己的业务逻辑。

6

简单直接的一种加密方式,与摘要算法不同的地方是,加密过程其是双向的,C由data加密而来,同样可以解密获得data,前提条件是加密解密时的key相同。而摘要算法无法从C解密得到data。

加密过程简单,那么其在对抗通信中面临的四种威胁的作用有怎么样呢:

  • 1)截获:这么在网络中传输的内容为密文,即使攻击者截获了报文,由于没有密钥,也无法解析。所以,这次对称加密算法在防范截获威胁方面有这很大的优势;
  • 2)中断:和摘要算法一样,无法防范;
  • 3)篡改:由于数据是密文传输的,攻击者,无法解析,更无法伪造了。所以,可以防范;
  • 4)伪造:对于数据的伪造,和摘要算法一样,可以防范,但对于伪造的发送方,对称加密算法和摘要算法一样,比较的无力。
7

5.3 算法优缺点

对称加密算法有着很多的好处,比较加密速度快,算法简单,安全模型的安全性较高等,但在正式中使用时,却不得不解决一个问题:密钥如何传递。如果将密钥在网络中传递,势必有被截获的风险。由于这个问题的存在,导致单纯的使用对称加密算法的通讯模型,并不是一个通用的模型,只在一些特殊的场合中使用,例如:客户端/服务器端为同一端点,或者线下合作的场景——双方将密钥写入合同中,线下传递。

不过对于密钥,还是建议经常的更换,密钥的po解是一个耗时的过程,长时间不变的密钥,无遗对攻击者创造了po解的机会,当有一天攻击者po解了密钥,灭顶之灾也就来到。

说了这么多的对称加密算法,还没有说对称加密算法有哪些,比较常用的对称加密算法有DES/3DES/AES/IDEA/RC4/RC2等。其加密强度,可以从其支持的密钥长度看出,密钥越长,加密强度越好;同时,加密过程越慢。

8

6、非对称加密算法介绍

6.1 基本

对称加密算法指加密解密用同一密钥,那么非对称加密就是加密解密用不同的密钥。

加密算法一次生成两个密钥,一个叫做公钥,一个较为密钥。公钥加密的数据,用密钥解密;密钥加密的数据,用公钥来解密(有些非对称加密算法,只能用密钥加密,公钥解密,或只能用密钥加密,公钥解密)。

非对称加密算法的确神奇,其理论的基础来自于数论。例如RSA算法建立在数论中的“大数分解和素数检测”的理论基础上。而ElGamal和ECC算法基于的则是数论中的“离散对数问题”。数学中的最后一个未找到应用场景的分支学科——数论,终于在加密学领域,找到了应用场景,这不得不说是个奇迹。

非对称加密算法的加入,使得加密算法得以真正的完整,他有这举足轻重的作用。他很好的解决了对称加密算法的缺陷。

6.2 通讯模型

客户端要将数据data发送给服务器端,客户端向服务器端发起对话请求,服务器端生成一对密钥——公钥Gkey和私钥Skey。将Gkey发送给客户端,客户端使用Gkey对数据data进行加密,获得密文C,将C发给服务器端,服务器端使用自己的Skey解密,获得数据data,完成后续业务逻辑。

9

从上面的通讯模型中可以看到,在网络中传输的只有密文C、和公钥Gkey。而私钥Skey不会在网络中传输,攻击者只能获取到公钥,无法对解密密文C,也就保证了数据的安全性。

详细的分析下通讯中面临的四种威胁:

  • 1)截获:同样网络中传输的是密文,即时被截获,攻击者没有私钥,也无法解析密文。所以可以很好的防范截获威胁;
  • 2)中断:对于针对可用性的攻击,由于一般都是基于底层协议的攻击,所以一般很难防范;
  • 3)篡改:由于数据是密文传输的,攻击者没有私钥,无法解析,更无法伪造了;
  • 4)伪造:对于数据的伪造,和摘要算法一样,可以防范,但对于伪造的发送方,对称加密算法和摘要算法一样,比较的无力。
10

和对称加密算法一样,只能对通信中的截获、篡改有防范作用,对其他两个中断、伪造威胁都无法防范。而由于非对称加密算法,很好的解决了对称加密算法中密钥交换的问题,所以其有着很不错的应用场景,可以说是一种通用的加密模型。

6.3 算法优缺点

那么非对称加密算法就没有缺点吗?

也不是。首先,我们看上面的通讯模型,他比对称加密算法的通讯模型来的复杂,存在着两次请求/响应。此外,非对称加密算法的计算可能会很慢,比对称加密算法来慢得多。所以,非对称加密算法在解决了对称加密算法的缺陷后,存在着一些性能问题,比较通用的解决办法是将两种加密算法进行结合——先使用非对称加密算法传递临时的对称加密算法的密钥,密钥传递完成后,再使用更快的对称加密算法来进行真正的数据通信。

典型的非对称加密算法有RSA/ElGamal/ECC算法,除了这两个算法外,还有一个DH算法,其比较的另类,其设计的初衷就是解决对称加密算法中密钥安全交换的问题。

其通讯模型如下:

所有客户端生成一堆公钥CGkey和私钥CSkey,将AGkey发给服务器端。服务器端通过AGkey生成服务器端的公钥SGkey和私钥SSkey,并将SGkey发还给客户端。客户端通过CSkey与SGkey生成对称加密算法的密钥key,服务器端通过CGkey和SSkey生成相同的密钥key。后续客户端和服务器端都是用各自的密钥key来通信。

11

不得不说,这又是一个多么神奇的算法。但是他的确存在。并且早于其他的非对称加密算法。

7、数字签名介绍

7.1 基本

以上三种算法都有防篡改的功能,但摘要算法、和对称加密算法若要防篡改,则需要交换密钥,这又是一件麻烦事儿。所以一般在单纯的防篡改的需求上,都是使用非对称加密算法。但若是对整个明文进行加密的话,加密过程势必消耗大量时间,所以就诞生了数字签名。

数字签名,本质上就是非对称加密算法,但出于解密运行效率的考虑,并是不对明文进行加密,而是对明文的摘要加密,生成“数字串”,并将“数字串”附在明文之后。

数字签名实际上是非对称加密算法的一个妥协方案,为了提高加解密的效率,舍弃了非对称加密算法对截获威胁的优势。

7.2 通讯模型

先来看非对称加密算法的第一种通讯模型,由客户端生成一堆密钥——公钥Gkey和私钥Skey,并使用Skey对明文data进行加密,获得密文C。将C与Gkey发送给服务器端,服务器端使用Gkey对C进行解密。

12

这种通讯模型,只需要一次请求/响应过程,但却无法防范截获威胁,由于最后的密文C的解密用的是公钥Gkey,而Gkey在通过网络传递,所以攻击者可以很方便的对数据进行截获、解密,获得明文data。但这种通讯模型,对于数字签名的场景正合适,数字签名的场景并不准备防范“截获”威胁。

那么下面来看下完整的数字签名的通讯模型:服务器端生成一堆密钥,公钥Gkey和私钥Skey,在将明文data进行摘要,获得摘要串Z1,使用私钥对Z1加密,获得密文C,将C,data,Gkey发给服务器端,服务器端使用Gkey解密后获得Z1,重新根据data计算出摘要Z2,通过比较Z1是否等于Z2来判断数据是否被篡改。

13

以上的模型主要由两个步骤组成,摘要与非对称加密算法的应用。

平常我们经常用到的签名算法,也是这两种算法的组合,比如:

  • 1)SHA1wthRSA,使用SHA1来做摘要,RSA做未对称加密;
  • 2)MD5withRSA,使用MD5做摘要算法,RSA做未对称加密;
  • 3)SHA1withDSA,DSA是ElGamal算法的一种改进。

8、数字证书介绍

8.1 基本

上面说了这么多算法,又是摘要算法,又是对称加密算法,又是非对称加密算法的。但是对于通讯中的四种威胁——截获、中断、篡改、伪造最多也就只能解决其中的两个,对于中断、和伪造威胁,只能干瞪眼。难道,就没有其他办法了吗。

对于中断,一般是网络拓扑或协议级别要解决的问题,已经超出了我们的范畴,暂时不表,我们只能做到的是当网络不可用时,传输的数据出现丢包或异常时可以进行及时的建设,这里就需要用到数据完整性的验证了。

至于,要对付攻击者“伪造”的威胁,这不仅仅是单一算法层面可以解决的问题了。

8.2 通讯模型

正如上面几节所说,伪造分为两种,一种是数据伪造,只要做好防篡改的工作,数据伪造都可以很好的防范。另外一种是伪装成某一网站,与用户进行交互,盗取用户的一些信。比较常见的如钓yu网站、黑代理服务器等。

哪非对称加密算法的通讯模型来举个例子。客户端A在获得给自己公钥时,并没有怀疑与公钥发出方的身份,客户端A以为发给他的依然B,实际上,B发出的公钥已经被攻击者C拦截并丢弃了,C重新生成公钥伪装为B发给了客户端,后续的流程实际上都是攻击者C在于客户端A通讯,而客户端A则以为与自己通讯的是服务器B。

14

这个伪造的过程在平时我们的生活中也经常会碰见,比如:在实名制以前,张三买到火车票后,半路被人da劫,车票被抢。这就有点类似于遭遇了攻击者的攻击,攻击者抢走了张三的火车票(公钥Gkey),并伪造了一张可以以将乱真的车票,(重新生成公钥Gkey)使用这张车票上火车。整个过程看似天衣无缝,攻击者获得了一张免费的车票,张三损失了一张火车票。

当然,现在这种火车票qiang劫的事件已经不太会发生了,因为已经实行了实名制。实名制的引入,给我们解决上面的“伪造”威胁提供了一个方案。火车票实名制,使用了身份证作为验证用户身份的一个证明。那么我们在网络通讯中是否也可以引入这么个“网站身份证”呢。回答是肯定的,目前也正是这么做的,我们叫他“数字证书”。

8.3 CA

正如我们身份证是由可信任的gong an 局办发。数字证书也是由权威机构签发,我们叫做CA,CA会保证证书的确是发给了应该得到该证书的的人。CA也属于一个机构,他也有被人伪造的风险。所以CA一般是分级的,顶层的叫做RootCA,由他保证下面的CA的身份。

所以我们的机器里,保存着有限的几个RootCA的机构的公钥。打个比方,张三有个数字证书,是由A这个CA机构颁发的,A的身份由RootCA来保证。当浏览器与张三的网站进行通讯时,获取到了张三的数字证书,实际上这个数字证书是个嵌套的证书,里面包含着两个子证书:RootCA颁发给A的证书,和A颁发给张三网站的证书。在浏览器中保存着有限个着RootCA的公钥。使用RootCa的公钥对A证书进行验证,验证通过,使用A证书里的公钥对张三网站的证书进行验证,只有再次验证通过后,才能说张三网站的证书得到了确认。

整个验证过程是一个信任链。

15

数字证书里主要包含着两样东西:数字证书所有者的身份信息,数字证书所有者的公钥。为了保证证书在网络中通信不被篡改,证书里会带上这些信息的数字签名。那么对数字证书的验证就是对数字签名的验证,这就是上图中每次证书的验证都要使用到公钥的原因了。

9、参考资料

[1] 传输层安全协议SSL/TLS的Java平台实现简介和Demo演示

[2] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

[3] 微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

[4] 来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享

[5] 简述实时音视频聊天中端到端加密(E2EE)的工作原理

[6] 移动端安全通信的利器——端到端加密(E2EE)技术详解

[7] Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)

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

[9] IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

[10] 快速读懂量子通信、量子加密技术

[11] 一分钟理解 HTTPS 到底解决了什么问题

[12] 一篇读懂HTTPS:加密原理、安全逻辑、数字证书等

[13] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

[14] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

[15] 微信技术分享:揭秘微信后台安全特征数据仓库的架构设计

[16] 即时通讯初学者必知必会的20个网络编程和通信安全知识点

[17] 零基础IM开发入门(五):什么是IM系统的端到端加密?

10、IM安全系列文章

本文是IM通讯安全知识系列文章中的第 3 篇,总目录如下:

即时通讯安全篇(一):正确地理解和使用Android端加密算法

即时通讯安全篇(二):探讨组合加密算法在IM中的应用

即时通讯安全篇(三):常用加解密算法与通讯安全讲解》(本文)

即时通讯安全篇(四):实例分析Android中密钥硬编码的风险

即时通讯安全篇(五):对称加密技术在Android上的应用实践

即时通讯安全篇(六):非对称加密技术的原理与应用实践

即时通讯安全篇(七):用JWT技术解决IM系统Socket长连接的身份认证痛点

即时通讯安全篇(八):如果这样来理解HTTPS原理,一篇就够了

即时通讯安全篇(九):你知道,HTTPS用的是对称加密还是非对称加密?

即时通讯安全篇(十):为什么要用HTTPS?深入浅出,探密短连接的安全性

即时通讯安全篇(十一):IM聊天系统安全手段之通信连接层加密技术

即时通讯安全篇(十二):IM聊天系统安全手段之传输内容端到端加密技术

即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法

即时通讯安全篇(十四):网络端口的安全防护技术实践

即时通讯安全篇(十五):详解硬编码密码的泄漏风险及其扫描原理和工具


(本文已同步发布于:http://www.52im.net/thread-219-1-1.html)

posted @ 2025-09-25 11:58 Jack Jiang 阅读(54) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang