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

1、分析和攻擊私有協(xié)議中的密碼學(xué)安全漏洞 關(guān)于我上海交通大學(xué)密碼與計算機安全實驗室 Lab of Cryptology and Computer Security軟件安全小組GoSSIP Group of Software Security In Progress私有協(xié)議中的密碼學(xué)安全漏洞什么是協(xié)議網(wǎng)絡(luò)通信協(xié)議，為進行數(shù)據(jù)交換而建立的規(guī)則、標準或約定的集合它規(guī)定了通信時信息必須采用的格式和這些格式的意義應(yīng)用層： 0 x00 0 x26 0 xe5 0 x90 0 x83 0 xe4 0 xba 0 x86 0 xbc 0 x9f 標志位：采用何種壓縮算法，字符編碼方式，長度，網(wǎng)絡(luò)層： 源端口，目的

2、端口，傳輸層：源IP，目的IP，網(wǎng)絡(luò)接口層：MAC地址，私有協(xié)議中的密碼學(xué)安全漏洞我們關(guān)心的協(xié)議與相應(yīng)實體通信并完成特定功能的應(yīng)用層協(xié)議。HTTP、FTP、SMTP、也可以是更加應(yīng)用相關(guān)的協(xié)議，例如 手機APP與發(fā)送推送信息的服務(wù)器間的通信協(xié)議 即時消息應(yīng)用間及其與服務(wù)器的通信協(xié)議 網(wǎng)絡(luò)攝像頭與中心服務(wù)器的通信協(xié)議私有協(xié)議中的密碼學(xué)安全漏洞私有協(xié)議Proprietary protocol 非標準協(xié)議 微信、QQ；自定義格式的數(shù)據(jù)交換 可能缺少公開的、詳細的協(xié)議規(guī)范文檔 協(xié)議逆向 抓包分析 二進制反匯編反編譯 私有協(xié)議中的密碼學(xué)安全漏洞協(xié)議的關(guān)注點對于網(wǎng)絡(luò)攝像頭 每幀畫面是如何編碼的，畫面質(zhì)量與

3、清晰度的協(xié)商調(diào)整， 每幀畫面?zhèn)鬏斍笆欠裼袇f(xié)商某些安全機制，傳輸?shù)漠嬅媸欠窨赡鼙唤孬@或修改 對于即時消息消息的某幾個字節(jié)對應(yīng)系統(tǒng)內(nèi)部維護的序列號消息能否冒充、偽造私有協(xié)議中的密碼學(xué)安全漏洞協(xié)議的關(guān)注點對于推送協(xié)議 某個字段對應(yīng)標題，某個字段對應(yīng)推送消息點擊后跳轉(zhuǎn)的網(wǎng)頁 服務(wù)器推送來的消息本身是否在傳輸過程中可能被修改例如，谷歌云消息服務(wù)，曾經(jīng)因服務(wù)器沒有檢查客戶端提交的請求中兩個字段的一致性，導(dǎo)致原本推送到客戶端的消息會被攻擊者收到Ref2。這種協(xié)議中業(yè)務(wù)邏輯相關(guā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.在存在惡意中間人的情況下，通信的安全性 被動中間人：竊聽 主動中間人：篡改、重放 身份冒充私有協(xié)議中的密碼學(xué)安全

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

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

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