如何分析和攻擊私有協(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私有協(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 xe5 0 x90 0 x83 0 xe4 0 xba 0 x86 0 xbc 0 x9f 標(biāo)志位：采用何種壓縮算法，字符編碼方式，長(zhǎng)度，網(wǎng)絡(luò)層： 源端口，目的

2、端口，傳輸層：源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ù)交換 可能缺少公開(kāi)的、詳細(xì)的協(xié)議規(guī)范文檔 協(xié)議逆向 抓包分析 二進(jìn)制反匯編反編譯 私有協(xié)議中的密碼學(xué)安全漏洞協(xié)議的關(guān)注點(diǎn)對(duì)于網(wǎng)絡(luò)攝像頭 每幀畫(huà)面是如何編碼的，畫(huà)面質(zhì)量與

3、清晰度的協(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)消息能否冒充、偽造私有協(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)有檢查客戶(hù)端提交的請(qǐng)求中兩個(gè)字段的一致性，導(dǎo)致原本推送到客戶(hù)端的消息會(huì)被攻擊者收到Ref2。這種協(xié)議中業(yè)務(wù)邏輯相關(guān)的安全問(wèn)題不是我們討論的范圍Ref 1:/wp-content/uploads/2014/04/gcm

4、_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 Communications Security. ACM, 2014.在存在惡意中間人的情況下，通信的安全性 被動(dòng)中間人：竊聽(tīng) 主動(dòng)中間人：篡改、重放 身份冒充私有協(xié)議中的密碼學(xué)安全

5、漏洞What we really focus on信息傳送的通道是否安全吃了么？私有協(xié)議中的密碼學(xué)安全漏洞網(wǎng)絡(luò)通信協(xié)議Communications Protocol 分析私有協(xié)議中的密碼學(xué)問(wèn)題時(shí)我們要關(guān)注什么我正在跟我想要的人講話(huà) 講話(huà)的內(nèi)容不想讓別人知道 講話(huà)的內(nèi)容別人不知道也不能亂改 身份認(rèn)證確認(rèn)通信對(duì)象身份 基于密碼的身份認(rèn)證 基于密碼的身份認(rèn)證HTTPS， HTTPS with Pinning 依托下層通道的安全性 基于密碼的身份認(rèn)證簡(jiǎn)單編碼(Base64/Base32) 簡(jiǎn)單哈希(MD5/SHA1/SHA256/) 加鹽、多次哈希 依托對(duì)密碼的變換 簡(jiǎn)單編碼(Base64/Base3

6、2) 簡(jiǎn)單哈希(MD5/SHA1/SHA256/) 多次哈希 基于密碼的身份認(rèn)證單純依賴(lài)對(duì)密碼的變換無(wú)法保證用戶(hù)身份認(rèn)證的安全性 身份認(rèn)證硬編碼密鑰 a.c = h.MD5(2989d4f8dcda393d1c1ca3c021f0cb10 + arg2.getPackageName().getBytes(); 由可預(yù)測(cè)的數(shù)據(jù)生成 String v0 = 134e3265829ff82daf16e7b740a600b5; if(this.b = null) byte v1 = v0.getBytes(); byte v2 = new byte16; 身份認(rèn)證RSA/ECB/NoPadding 沒(méi)

7、有隨機(jī)性 RSA/ECB/PKCS1Padding 除不能抵抗重放攻擊外，安全性較高 身份認(rèn)證Google Play 100個(gè)APP 大陸安卓應(yīng)用市場(chǎng)200個(gè)APP 密碼發(fā)送通道分布情況 身份認(rèn)證密碼變換種類(lèi)的使用情況 密鑰協(xié)商雙方共享的密鑰硬編碼在程序中 某通信云提供商的SDK，逆向難度較大，但仍可以提取到密鑰 通信密鑰由一方直接發(fā)送給另一方 另一即時(shí)通信云提供商的SDK，在客戶(hù)端每次登錄成功或者斷網(wǎng)重連后 服務(wù)器會(huì)將密鑰發(fā)給客戶(hù)端 密鑰協(xié)商通信時(shí)協(xié)商 盡管攻擊者可以通過(guò)作為中間人分別與雙方協(xié)商密鑰，但避免了攻擊者只要獲取網(wǎng)絡(luò)流量就可解密獲得消息的情況，增大了攻擊難度。 數(shù)據(jù)加密考慮到通信效率，采用對(duì)稱(chēng)加密算法 避免使用非標(biāo)準(zhǔn)算法 線(xiàn)性分析、差分分析、滑動(dòng)攻擊、 避免使用ECB模式 CBC模式中IV一定要隨機(jī) 案例分析不正確的共享密鑰 生成密鑰的材料隨密文數(shù)據(jù)一同發(fā)送 不需要維護(hù)Session 不需要狀態(tài)切換 任意數(shù)據(jù)包可解 案例分析泄露用戶(hù)隱私 MAC地址、wifi名稱(chēng)、IMEI等 任意篡改、偽造推送消息 點(diǎn)擊打開(kāi)任意網(wǎng)址 點(diǎn)擊下載任意app 認(rèn)證消息構(gòu)建認(rèn)證消息 保證消息不被篡改 使用簡(jiǎn)單