如何分析和攻擊私有協(xié)議中的密碼學(xué)安全漏洞

1、分析和攻擊私有協(xié)議中的密碼學(xué)安全漏洞 劉慧關(guān)于我上海交通大學(xué)密碼與計(jì)算機(jī)安全實(shí)驗(yàn)室 Lab of Cryptology and Computer Security軟件安全小組GoSSIP Group of Software Security In Progress應(yīng)用密碼學(xué)研究 現(xiàn)實(shí)軟件中密碼系統(tǒng)的安全審計(jì)分析 烏云白帽子/烏云專欄作者 Gossip on SSL Security by GoSSIP_SJTU 私有協(xié)議中的密碼學(xué)安全漏洞什么是協(xié)議網(wǎng)絡(luò)通信協(xié)議，為進(jìn)行數(shù)據(jù)交換而建立的規(guī)則、標(biāo)準(zhǔn)或約定的集合它規(guī)定了通信時(shí)信息必須采用的格式和這些格式的意義應(yīng)用層： 0 x00 0 x26 0 xe

2、5 0 x90 0 x83 0 xe4 0 xba 0 x86 0 xbc 0 x9f 標(biāo)志位：采用何種壓縮算法，字符編碼方式，長(zhǎng)度，網(wǎng)絡(luò)層： 源端口，目的端口，傳輸層：源IP，目的IP，網(wǎng)絡(luò)接口層：MAC地址，吃了么？私有協(xié)議中的密碼學(xué)安全漏洞我們關(guān)心的協(xié)議與相應(yīng)實(shí)體通信并完成特定功能的應(yīng)用層協(xié)議。HTTP、FTP、SMTP、也可以是更加應(yīng)用相關(guān)的協(xié)議，例如 手機(jī)APP與發(fā)送推送信息的服務(wù)器間的通信協(xié)議 即時(shí)消息應(yīng)用間及其與服務(wù)器的通信協(xié)議 網(wǎng)絡(luò)攝像頭與中心服務(wù)器的通信協(xié)議 私有協(xié)議中的密碼學(xué)安全漏洞私有協(xié)議Proprietary protocol 非標(biāo)準(zhǔn)協(xié)議 微信、QQ；自定義格式的數(shù)據(jù)交

3、換 可能缺少公開(kāi)的、詳細(xì)的協(xié)議規(guī)范文檔 協(xié)議逆向 抓包分析 二進(jìn)制反匯編反編譯 私有協(xié)議中的密碼學(xué)安全漏洞協(xié)議的關(guān)注點(diǎn)對(duì)于網(wǎng)絡(luò)攝像頭 每幀畫(huà)面是如何編碼的，畫(huà)面質(zhì)量與清晰度的協(xié)商調(diào)整， 每幀畫(huà)面?zhèn)鬏斍笆欠裼袇f(xié)商某些安全機(jī)制，傳輸?shù)漠?huà)面是否可能被截獲或修改 對(duì)于即時(shí)消息消息的某幾個(gè)字節(jié)對(duì)應(yīng)系統(tǒng)內(nèi)部維護(hù)的序列號(hào)消息能否冒充、偽造 ref1 私有協(xié)議中的密碼學(xué)安全漏洞協(xié)議的關(guān)注點(diǎn)對(duì)于推送協(xié)議 某個(gè)字段對(duì)應(yīng)標(biāo)題，某個(gè)字段對(duì)應(yīng)推送消息點(diǎn)擊后跳轉(zhuǎn)的網(wǎng)頁(yè) 服務(wù)器推送來(lái)的消息本身是否在傳輸過(guò)程中可能被修改例如，谷歌云消息服務(wù)，曾經(jīng)因服務(wù)器沒(méi)有檢查客戶端提交的請(qǐng)求中兩個(gè)字段的一致性，導(dǎo)致原本推送到客戶端的消息會(huì)

4、被攻擊者收到Ref2。這種協(xié)議中業(yè)務(wù)邏輯相關(guān)的安全問(wèn)題不是我們討論的范圍Ref 1:/wp-content/uploads/2014/04/gcm_explained.pngRef2:Li, Tongxin, et al. Mayhem in the push clouds: Understanding and mitigating security hazards in mobile push-messaging services. Proceedings of the 2014 ACM SIGSAC Conference on Computer and Co

5、mmunications Security. ACM, 2014.在存在惡意中間人的情況下，通信的安全性 被動(dòng)中間人：竊聽(tīng) 主動(dòng)中間人：篡改、重放 身份冒充私有協(xié)議中的密碼學(xué)安全漏洞What we really focus on信息傳送的通道是否安全吃了么？吃了么？我喜歡你真實(shí)性：來(lái)自真實(shí)的的發(fā)送方 Authenticity 機(jī)密性：未授權(quán)不能讀 Confidentiality完整性：未授權(quán)不能修改 Integrity安全傳輸三大愿望私有協(xié)議中的密碼學(xué)安全漏洞網(wǎng)絡(luò)通信協(xié)議Communications Protocol 數(shù)據(jù)安全傳輸Secure Data Transmission 密碼學(xué)誤用Cr

6、yptographic Misuse 分析私有協(xié)議中的密碼學(xué)問(wèn)題時(shí)我們要關(guān)注什么我正在跟我想要的人講話 講話的內(nèi)容不想讓別人知道 講話的內(nèi)容別人不知道也不能亂改 身份 認(rèn)證 消息 認(rèn)證 密鑰 協(xié)商 數(shù)據(jù) 加密 身份認(rèn)證確認(rèn)通信對(duì)象身份 基于密碼的身份認(rèn)證 密碼認(rèn)證協(xié)議(PAP) Password Authentication Protocol 基于密碼的身份認(rèn)證HTTPS， HTTPS with Pinning 依托下層通道的安全性 基于密碼的身份認(rèn)證簡(jiǎn)單編碼(Base64/Base32) 簡(jiǎn)單哈希(MD5/SHA1/SHA256/) 加鹽、多次哈希 依托對(duì)密碼的變換 對(duì)稱密碼加密(AES/R

7、C4/) 非對(duì)稱密碼加密(RSA) 簡(jiǎn)單編碼(Base64/Base32) 簡(jiǎn)單哈希(MD5/SHA1/SHA256/) 多次哈希 基于密碼的身份認(rèn)證單純依賴對(duì)密碼的變換無(wú)法保證用戶身份認(rèn)證的安全性 對(duì)稱加密(AES/RC4/) 非對(duì)稱加密(RSA) 身份認(rèn)證硬編碼密鑰 a.c = h.MD5(2989d4f8dcda393d1c1ca3c021f0cb10 + arg2.getPackageName().getBytes(); 由可預(yù)測(cè)的數(shù)據(jù)生成 String v0 = 134e3265829ff82daf16e7b740a600b5; if(this.b = null) byte v1 =

8、 v0.getBytes(); byte v2 = new byte16; this.b = new SecretKeySpec(v2, AES); 身份認(rèn)證RSA/ECB/NoPadding 沒(méi)有隨機(jī)性 RSA/ECB/PKCS1Padding 除不能抵抗重放攻擊外，安全性較高 身份認(rèn)證Google Play 100個(gè)APP 大陸安卓應(yīng)用市場(chǎng)200個(gè)APP 密碼發(fā)送通道分布情況 身份認(rèn)證密碼變換種類的使用情況 密鑰協(xié)商雙方共享的密鑰硬編碼在程序中 某通信云提供商的SDK，逆向難度較大，但仍可以提取到密鑰 通信密鑰由一方直接發(fā)送給另一方 另一即時(shí)通信云提供商的SDK，在客戶端每次登錄成功或者斷

9、網(wǎng)重連后 服務(wù)器會(huì)將密鑰發(fā)給客戶端 攻擊者只需獲取到網(wǎng)絡(luò)流量，即可解密獲得消息內(nèi)容 數(shù)據(jù)包get = 消息裸奔 Diffie-Hellman密鑰協(xié)商 密鑰協(xié)商通信時(shí)協(xié)商 盡管攻擊者可以通過(guò)作為中間人分別與雙方協(xié)商密鑰，但避免了攻擊者只要獲取網(wǎng)絡(luò)流量就可解密獲得消息的情況，增大了攻擊難度。 數(shù)據(jù)加密考慮到通信效率，采用對(duì)稱加密算法 避免使用非標(biāo)準(zhǔn)算法 線性分析、差分分析、滑動(dòng)攻擊、 避免使用ECB模式 CBC模式中IV一定要隨機(jī) 案例分析不正確的共享密鑰 生成密鑰的材料隨密文數(shù)據(jù)一同發(fā)送 不需要維護(hù)Session 不需要狀態(tài)切換 任意數(shù)據(jù)包可解 案例分析泄露用戶隱私 MAC地址、wifi名稱、IMEI等 任意篡改、偽造推送消息 點(diǎn)擊打開(kāi)任意網(wǎng)址 點(diǎn)擊下載任意app 認(rèn)證消息構(gòu)建認(rèn)證消息 保證消息