安全的即时通讯软件原理与设计的调研报告

安全的即时通讯软件原理与设计目录摘要1. 选题背景及意义1.1 即时通讯的发展与安全现状1.2 常见安全原理及技术背景1.3 选题意义2. 问题提出与分析2.1 数据泄露风险2.2 窃听与监控威胁2.3 身份冒充问题2.4 安全漏洞与实现缺陷2.5 元数据泄露隐患3. 设计目标3.1 消息机密性3.2 身份真实性3.3 消息完整性3.4 前向安全性与后向安全性3.5 系统可用性与合规性4. 解决方案4.1 系统总体架构设计4.2 基于国密算法的端到端加密方案4.2.1 混合加密体系4.2.2 密钥派生函数KDF4.2.3 消息加密的完整流程4.3 密钥协商与生命周期管理4.3.1 X3DH异步密钥协商4.3.2 双棘轮会话密钥管理4.3.3 密钥全生命周期管理4.4 身份认证与访问控制4.4.1 多层次身份认证4.4.2 访问控制4.5 消息完整性保障与数字签名4.5.1 AEAD认证加密4.5.2 SM2数字签名4.6 安全传输与存储4.6.1 传输信道安全4.6.2 数据存储安全4.7 安全审计与持续改进4.7.1 SDL安全开发生命周期4.7.2 密码学敏捷性4.7.3 用户安全教育5. 总结参考文献摘要即时通讯软件已经渗透到日常生活的方方面面但大多数IM系统在安全方面做得并不好——消息在服务器端是明文的传输过程的加密也往往只是装装样子。这次课程设计选了”安全的即时通讯软件原理与设计”这个题目想弄清楚一个问题怎么才能让两个人聊天时中间的任何人都看不到内容包括提供服务的厂商围绕这个问题报告分析了IM面临的主要安全威胁讨论了端到端加密是怎么工作的重点看了椭圆曲线加密ECC、国密SM2/SM3/SM4这一套算法还有Signal协议里的X3DH密钥协商和双棘轮机制。在这些基础上试着设计了一个混合国密算法和Signal协议思路的IM安全方案。1. 选题背景及意义1.1 即时通讯的发展与安全现状从ICQ、MSN到现在的微信、WhatsApp、Signal、Telegram即时通讯软件二十多年的变化很大。最早只能发文字后来能传图片、语音、视频再后来有了端到端加密。到2026年全球IM用户大概超过40亿了不光个人在用公司办公、政府沟通也离不开[1]。但安全一直是个大问题。陆志浩在企业级IM系统设计的研究里提到企业用IM传商业信息时数据安全是绕不开的硬需求[1]。闫海波对IM软件的整体设计做过比较全面的讨论从架构到协议到存储都有涉及[2]。现实情况是大量IM软件在安全上做得远远不够。赵芳霞专门研究了社交平台和IM工具的隐私泄露问题发现泄露途径还挺多的——服务商内部有人违规看数据、第三方SDK偷偷收集信息、数据库本身就没加密、传输过程也没保护好[9]。这些年动不动就有几亿用户的聊天记录被泄露的新闻已经不是偶发事件了。李阳春这边做了更有意思的工作——他用Android逆向的方法拆解了好几款主流IM软件看它们到底怎么实现端到端加密的。结果发现问题一大堆有的把私钥明文存在SharedPreferences里有的用java.util.Random线性同余那种来生成密钥而不是用SecureRandom有的对称加密竟然用ECB模式还有的在TLS实现里根本不验证证书。这说明一件事就算软件宣传自己有端到端加密实际实现上可能漏洞百出[3]。1.2 常见安全原理及技术背景搞安全的IM系统大概需要这几样密码学工具对称加密。 加解密用同一个密钥速度很快适合加密消息正文。常用的AES和国密SM4都属于这类。实际使用的时候一般选GCM这种认证加密模式加密的同时还能检查消息有没有被篡改[6][7]。非对称加密。 公钥加密、私钥解密或者私钥签名、公钥验签。密钥协商和身份认证都靠它。常逢佳的研究专门讲了椭圆曲线加密ECCECC的安全性建立在椭圆曲线离散对数问题ECDLP上——给你椭圆曲线上两个点P和QkP让你求k这个计算上基本做不动。有意思的是256位的ECC密钥跟3072位的RSA密钥安全强度差不多这对手机这种计算能力有限的设备来说优势很大[5]。国密算法。 国家密码管理局推的SM系列有三个核心算法SM2是基于256位椭圆曲线的公钥算法能签名、能密钥交换、能加密SM3是输出256位的哈希算法SM4是128位分组的对称加密。这一套的好处是自己控制不依赖国外的算法标准[6][7]。X3DH密钥协商。 这是Signal协议里的东西全称是Extended Triple Diffie-Hellman。它解决了一个很实际的问题我想给你发加密消息但你这时候不在线怎么办X3DH的做法是让你提前把一些公钥材料放在服务器上发送方拿这些材料做多次ECDH计算就能协商出一个共享密钥[10]。数字签名和TLS。 SM2签名算法用来验证消息来源和完整性。TLS保护客户端到服务器这一段传输但管不了服务器端能不能看到明文——那个要靠端到端加密解决[4]。1.3 选题意义选这个题主要有几层考虑。从学习的角度密码学课上学了那么多算法——AES、RSA、ECC、SM2、哈希、签名——但都是单独学的真要把它们拼在一起做一个能用的系统中间还有不少坑。这次调研正好能把这些知识串起来[5][6][10]。从实用的角度现在大部分IM软件在设计时重点放在功能和体验上安全往往是后来打补丁加上去的。很多免费IM根本没有端到端加密聊天记录对服务器完全透明。孔席元的研究也说了端到端加密方案最难的地方是密钥协商的安全性、身份怎么认证、还有前向安全和后向安全怎么做[4]。这些才是实际工程中卡住的地方。如果能搞出一套把国密算法和国际上成熟的协议框架结合起来的设计对以后真的动手做开发是有参考价值的[6][7]。2. 问题提出与分析2.1 数据泄露风险传统的IM系统是客户端-服务器架构消息都要经过服务器中转。这意味着什么服务器能看到所有消息。用户的数据安全完全建立在”服务商不会乱来”这个假设上。问题是这个假设经常不成立[4][9]。赵芳霞把隐私泄露的途径梳理得比较清楚一是数据库被攻击SQL注入之类的拖库二是内部运维人员越权翻看用户数据三是集成的第三方SDK偷偷往外传数据四是备份文件管理不严导致泄露[9]。这几条基本覆盖了大部分的泄露场景。2.2 窃听与监控威胁没有端到端加密的话消息在传输的几个环节都可能被截获公司局域网里做ARP欺骗就能抓包路由器、网关这些中间节点可以监控流量运营商本身就有深度包检测DPI的能力公共WiFi更是重灾区。攻击者拿到了数据包如果消息是明文或者只做了TLS服务器端能解开那内容就等于直接暴露了[4]。TLS的问题在于它只加密客户端到服务器这一段到了服务器端消息就解密了。所以TLS是防不了服务商自己偷看或者服务器被黑的。真正要保密——比如谈商业合作、律师跟客户沟通——光靠TLS不够得让服务器也只能转发密文而不能解密。2.3 身份冒充问题即时通讯里的身份冒充有好几种玩法[4]中间人攻击MITM是最经典的。攻击者插在通信双方的网络中间对Alice假装是Bob对Bob假装是Alice。双方都以为在和对方直接通信实际上每条消息都被攻击者先解密看一遍可能还改了再加密发出去。账号盗用。密码被撞库了、Session被劫持了、凭证泄露了攻击者就能直接登你的号假装是你去跟别人聊天。重放攻击。攻击者把之前截获的合法加密消息原样再发一遍试图触发某个操作。这些问题说到底都是因为缺少可靠的身份验证。门凯旋他们研究X3DH协议的时候提到X3DH把通信双方的身份密钥绑进了共享秘密的推导过程里从协议层面就堵住了一部分身份冒充的路[10]。2.4 安全漏洞与实现缺陷李阳春的逆向分析工作是这方面很有价值的参考。他扒了几款主流IM软件的实现发现了一些挺基础但很致命的问题[3]密钥存储。 有应用把私钥以明文存在SharedPreferences或者外部存储里手机root之后随便什么恶意程序都能读到。随机数。 密码学操作非常依赖好的随机数——生成密钥、初始化向量、临时私钥都靠它。但有些应用居然用的是Java的java.util.Random线性同余生成器不是java.security.SecureRandom。线性同余产生的”随机数”是可预测的这意味着生成的密钥也可能被预测。加密模式。 ECB模式是个坑——相同的明文块加密后得到相同的密文块消息的结构信息会泄露。应该用CBC或者GCM。证书验证。 TLS实现里不验证服务器证书或者接受自签名证书却不检查主机名中间人攻击在传输层就能轻松实施。硬编码密钥。 有些应用直接把加密密钥写在代码里。逆向之后密钥就出来了加密等于没加。2.5 元数据泄露隐患就算消息内容加密了元数据谁和谁在什么时候通信、通信频次、消息长度、IP地址还是会泄露大量信息[9]。通过分析这些元数据能推断出一个人的社交圈子、作息习惯甚至政治倾向。目前端到端加密主要集中在消息内容的保护元数据保护这个问题还没解决好。3. 设计目标根据前面分析的那些问题一个安全的IM系统至少要满足下面几个目标3.1 消息机密性只有收发双方能看到消息明文其他人——服务器、网络中间节点、系统管理员——全不行[4][7]。要做到这一点加密必须在用户自己的设备上完成服务器只能看到密文、转发密文。这是安全IM最基本的一条。3.2 身份真实性通信双方要能确认对方的身份不是伪造的防冒充、防MITM[10]。靠一层的认证不够得在协议层密钥协商时绑定身份、密钥层预密钥要签名和用户层安全号码比对都有检查点。3.3 消息完整性收到消息之后能验证它在传输中有没有被改过、删过、重放过[6]。用GCM这类AEAD模式可以在解密的同时做完整性校验关键消息再加SM2签名提供更强的保障和不可否认性。每条消息带一个递增的序号收到重复序号的消息就直接丢掉。3.4 前向安全性与后向安全性这两个指标是衡量端到端加密系统好不好用的关键[10]。前向安全指的是就算长期密钥将来哪天泄露了之前的聊天记录照样解不开。这是通过对称棘轮的KDF单向推进实现的——消息密钥用完就扔从当前状态没法往回推。后向安全是说某次会话密钥不小心泄露之后系统能自己恢复。靠的是DH棘轮——每轮通信都引入新的ECDH协商注入新的随机熵让攻击者手里的旧密钥慢慢”过期”。3.5 系统可用性与合规性安全归安全但也不能影响正常使用。加密解密的延迟得控制在用户感觉不到的程度100ms以内[7]。系统架构上安全功能和业务功能要分开这样以后想换算法或者升级安全策略的时候不会动到业务代码[8]。算法选择上优先用国密系列符合国家密码管理的要求[6]。用户界面上应该清楚地显示当前的加密状态——比如这个会话是不是端到端加密的安全号码是多少——让用户有办法自己确认安全状况。4. 解决方案针对上面说的问题和目标这部分试着设计了一套方案——把国密算法和Signal协议的思路揉在一起用。4.1 系统总体架构设计参考陆志浩的企业级IM设计和闫海波对IM架构的分析方案分了四层从下往上是[1][2]存储层。 最底下一层。本地的消息记录用SQLite存但存的是密文数据库本身还可以用SQLCipher再加密一层。服务器端存的也是密文密钥服务器单独部署只存公钥材料不存任何私钥。传输层。 客户端和服务器之间走TLS 1.3开了证书固定Certificate Pinning不认来路不明的证书。过时的协议版本和弱密码套件全禁掉。TLS在这里是外层防护真正的消息保护靠的是上面端到端加密那层。安全层。 这层是方案的核心独立于上面的应用逻辑专注于密码学运算。里面有SM2引擎签名、密钥交换、公钥加密、SM3哈希引擎、SM4对称加密国际互操作场景可切到AES-256-GCM、X3DH/SM2密钥协商、双棘轮会话管理、身份认证这些模块。把这些东西单独放一层思路来自软件定义安全SDS——安全功能模块化以后要升级或者换算法的时候不用大改[8]。应用层。 最上面一层用户交互和业务逻辑。消息收发、联系人管理、会话管理、文件传输都在这里。但应用层自己不碰密码学的东西加密解密全调安全层的API。图1 系统总体分层架构图4.2 基于国密算法的端到端加密方案4.2.1 混合加密体系这套方案用的是”非对称协商密钥、对称加密消息”的混合路子跟主流的做法一样[6][7]密钥协商层用SM2来做。双方都在线的时候可以直接走SM2标准的密钥交换如果有人不在线异步场景就用X3DH协议——但椭圆曲线参数换成SM2推荐的这样既保留了X3DH的异步协商能力又用的是国密曲线[6][10]。消息加密层用SM4。128位分组、128位密钥、32轮非线性迭代。对外的场景可以换成AES-256-GCM两个算法在设计上是平行的[7]。完整性保护层用SM3来做MAC或者SM4-GCM的认证标签同时提供加密和完整性。对于密钥材料交换、设备变更确认这些关键操作额外加SM2签名[6]。4.2.2 密钥派生函数KDFKDF负责从ECDH协商出来的共享秘密中安全地派生出几个用途互不相同的密钥。方案里的KDF参考了HKDF标准框架底层用的是SM3[7]DeriveKeys(sharedSecret, salt, info):PRK SM3-HMAC(salt, sharedSecret)EK SM3-HMAC(PRK, info || 0x01) # 加密密钥MK SM3-HMAC(PRK, info || 0x02) # MAC密钥IV SM3-HMAC(PRK, info || 0x03)[0:12] # 初始向量return (EK, MK, IV)这样从一个共享秘密派生出来的EK、MK、IV互相独立——拿到其中一个导不出另外两个。4.2.3 消息加密的完整流程一次消息加密走下面这几步[7]发送方先查到跟对方当前的会话状态拿到发送链密钥Sending Chain Key和消息序号。然后对称棘轮推进一步MessageKey SM3-HMAC(ChainKey, 0x01)新ChainKey SM3-HMAC(ChainKey, 0x02)。用这个MessageKey和IV对消息明文做SM4-GCM认证加密输出密文和认证标签。如果这一轮需要推进DH棘轮比如是在回复对方就生成新的临时ECDH密钥对公钥附在消息里一起发。把密文、标签、DH公钥如果有、消息序号等打包好经TLS信道发给服务器。服务器以密文形式转发给接收方。接收方拿到消息后根据里面的会话信息找到对应状态和链密钥同样的棘轮推导出消息密钥解密、验证标签。标签对得上就接受对不上说明消息可能被动了手脚丢掉并告警。图2 端到端加密消息流程图4.3 密钥协商与生命周期管理4.3.1 X3DH异步密钥协商有时候想给人发消息但对方不在线X3DH就是为这种场景设计的[10]。协议里用到四种密钥材料IK是用户的长期身份密钥注册时生成并上传公钥SPK是中期预密钥一般7到30天轮换一次公钥上传前要先用IK签名OPK是一次性预密钥用户批量生成上传每次会话消耗一个EK是发送方临时生成的密钥只用这一次。以Alice给Bob发起会话为例Alice先从服务器拿Bob的IK公钥、SPK公钥和一个OPK公钥如果还有的话然后做四次ECDH[10]·DH1 ECDH(EK_A_private, IK_B_public)·DH2 ECDH(IK_A_private, SPK_B_public)·DH3 ECDH(EK_A_private, SPK_B_public)·DH4 ECDH(EK_A_private, OPK_B_public)OPK可用时共享秘密 SK KDF(DH1 || DH2 || DH3 || DH4)门凯旋他们的研究里分析了一个有意思的点这四次DH计算每一项绑定了不同生命周期的密钥。就算其中某个密钥材料被泄露比如OPK被破了攻击者也凑不齐完整的共享秘密[10]。图3 X3DH密钥协商协议时序图4.3.2 双棘轮会话密钥管理协商出初始密钥之后后面的每条消息不能都用一个密钥——那样一旦某条消息的密钥泄露整个会话全完了。双棘轮解决了这个问题[10]。它分两层。DH棘轮管”宏观”每轮通信发一条、回一条算一轮引入一次新的ECDH协商注入新的随机熵。对称棘轮管”微观”每条消息用一个独立的密钥由链密钥经单向KDF推出来用后即弃。两层配合的效果是每次消息交互都有新熵进来DH棘轮 → 后向安全每条消息密钥用完就扔且无法反推对称棘轮 → 前向安全。常逢佳的研究表明ECDH运算在手机上就几毫秒的事所以频繁推DH棘轮不用担心性能问题[5]。图4 双棘轮算法机制示意图4.3.3 密钥全生命周期管理密钥从生成到销毁走一个完整的闭环[3][7]生成全部在用户设备本地完成用CSPRNG密码学安全的随机数生成器私钥绝不离开设备。分发阶段公钥走服务器的公钥目录预密钥必须用身份密钥签名后上传服务器改不了内容。更新方面SPK定期轮换OPK用完了自动补充DH棘轮的公钥跟着消息交互走。存储时私钥进Android Keystore或iOS Keychain这类硬件安全模块。会话结束后相关的Root Key、Chain Key、Message Key立即从内存擦掉OPK用完即删不重复用。4.4 身份认证与访问控制4.4.1 多层次身份认证身份认证从底层协议到上层用户界面都有布置[4][10]协议层X3DH/SM2密钥协商的时候双方身份密钥参与了共享秘密的计算MITM攻击者要同时替换两边公钥还能生成有效签名这个计算上做不动[10]。密钥层SPK的公钥上传前必须用IK签名。接收方拿到SPK之后先验签确认这个预密钥确实是声称的那个人生成的不是服务器伪造的[6]。用户层提供Security Number安全号码比对。双方的身份密钥拼起来做一次SM3取前12位十六进制数字。用户可以用语音通话等带外方式核对这个号码是不是一致。如果对上了可以确定中间没有人在搞MITM[10]。应用层登录时做口令/生物特征认证支持开双因素认证2FA。4.4.2 访问控制用基于角色的访问控制RBAC普通用户、群组管理员、系统管理员各司其职。服务器端对数据的访问操作记录日志定期审计[8]。4.5 消息完整性保障与数字签名4.5.1 AEAD认证加密所有消息都用AEAD模式SM4-GCM或AES-256-GCM一条消息同时搞定加密和完整性保护。密文只要被改过一个bit解密时认证标签就对不上[7]。4.5.2 SM2数字签名对于密钥材料交换、设备变更这类不能出任何差错的操作额外加SM2数字签名。SM2签名的生成过程[6]先算ZA用户的可辨别标识的哈希值然后e SM3(ZA || M)。选随机数k算(x₁, y₁) kG。r (e x₁) mod n。如果r是0或者rkn重新选k。s ((1dA)⁻¹·(k-r·dA)) mod n输出(r, s)。验证的时候拿到(r, s)和消息M、公钥PA检查r和s是不是在范围内然后算t (rs) mod n(x₁, y₁) sG tPA看 R (e x₁) mod n 等不等于r。等于就验证通过。张龙在保密通信系统的文章里测过SM2签名在手机上的运算速度完全可以满足实时签名验证的需求[6]图5a SM2数字签名生成流程图5b SM2数字签名验证流程4.6 安全传输与存储4.6.1 传输信道安全用TLS 1.3且只开支持前向安全的密码套件ECDHE AEAD。证书固定不能少不可信的证书直接拒绝连接。TLS 1.0/1.1和RC4、3DES这些东西全关掉。有一点值得特别说一下TLS只加密客户端到服务器的传输端到端加密才是消息内容不被服务器看到的保障。两个东西是互补的[4]。4.6.2 数据存储安全客户端这边消息数据库用SQLCipher做透明加密密钥由用户口令派生。私钥材料放Android Keystore或iOS Keychain。服务器端只存消息密文和公钥私钥和明文消息一律不存。服务器数据库自己也要有透明数据加密TDE、严格的访问控制和审计日志[9]。4.7 安全审计与持续改进4.7.1 SDL安全开发生命周期安全不是开发完了再补的事得从头到尾贯穿[8]。需求阶段就把威胁模型和安全需求明确下来编码阶段遵守安全编码规范用SAST工具扫测试阶段加渗透测试、模糊测试和DAST上线后定期请外部安全团队做独立审计建好漏洞报告和应急响应机制。4.7.2 密码学敏捷性所谓密码学敏捷性就是系统设计上不能让某一个具体算法跟整个架构绑死。万一某个算法被发现弱点、出了新标准、或者有新的合规要求比如将来要迁移到后量子算法应该能比较方便地替换[8]。4.7.3 用户安全教育软件里给用户展示清晰的安全状态——这个会话是不是端到端加密的、安全号码是多少。定期推送一些安全知识帮用户理解端到端加密到底在保护什么、安全号码对比有什么用。毕竟用户自己的安全意识是整个防护链条上少不了的一环[9]。5. 总结这次课程设计围绕”安全的即时通讯软件原理与设计”做了一圈调研和方案设计主要干了这么几件事把IM面临的安全威胁梳理了一遍——数据泄露、窃听、身份冒充、实现层面的缺陷、元数据泄露。这些问题不是孤立的很多时候是叠加在一起的。明确了安全IM该做到什么——消息只有收发双方能看、身份能验证、内容不能被篡改、密钥泄露之后历史消息解不开前向安全、泄露之后系统还能恢复后向安全同时不能影响正常使用体验。基于这些目标设计了一套混合方案。核心思路是把国密算法SM2/SM3/SM4和Signal协议的成熟框架拼在一起用。方案覆盖了系统四层架构、混合加密、X3DH异步密钥协商加双棘轮的密钥管理、多层次的认证、AEAD加密加SM2签名保障完整性、传输和存储的安全、以及SDL和密码学敏捷性这些持续改进的机制。我自己觉得方案里比较有意思的地方一个是把SM系列的算法跟X3DH、双棘轮这些经过大量实际检验的协议设计结合起来不是简单的”国密替代”思路而是在协议层面做了融合[6][7][10]另一个是借鉴了软件定义安全的模块化做法安全功能不跟业务逻辑搅在一起以后升级维护都方便[8]。当然这个方案也有很多不足。比如群组通信下的端到端加密怎么做MLS协议可能是方向元数据保护怎么搞量子计算来了现有算法怎么办——这些都是值得继续往下研究的问题。参考文献[1] 陆志浩. 企业级即时通讯APP及系统设计与实现[J]. 中国安全防范技术与应用, 2023, (3): 64-67.[2] 闫海波. 网络即时通讯软件的设计与实现[D]. 沈阳工业大学, 2008.[3] 李阳春. 基于Android逆向的即时通讯软件端到端加密算法分析[D]. 哈尔滨工业大学, 2020. DOI: 10.27061/d.cnki.ghgdu.2020.002443.[4] 孔席元. 端到端加密聊天方案的设计与研究[D]. 华中师范大学, 2019. DOI: 10.27159/d.cnki.ghzsu.2019.002789.[5] 常逢佳. 椭圆曲线加密算法研究及其在即时通讯系统中的应用[D]. 南京理工大学, 2008.[6] 张龙. 基于国密SM2/SM3算法的保密即时通信系统设计[J]. 网络安全技术与应用, 2024, (7): 25-27.[7] 孟文胜. 基于国密算法的端到端加密即时通信系统设计与实现[J]. 电脑编程技巧与维护, 2026, (4): 174-176. DOI: 10.16184/j.cnki.comprg.2026.04.023.[8] 赵瑞. 基于软件定义安全架构的安全服务编排系统设计与开发[D]. 北京邮电大学, 2017.[9] 赵芳霞. 社交媒体用户隐私泄露、侵犯与保护研究[D]. 兰州财经大学, 2019.[10] 门凯旋, 李天昊, 王广硕, 等. X3DH密钥协商协议演示系统的设计与实现[J]. 数字技术与应用, 2022, 40(2): 228-231. DOI: 10.19695/j.cnki.cn12-1369.2022.02.74.