微信加密與安全通信流程分析

背景

? 微信漸漸已經成為了大多數中國人日常會話的通訊工具，微信的通信安全，很大程度上保證了普通民眾的資料安全，也因此顯得十分重要，

? 本文主要在其他對微信研究的基礎上，進行了微信加密與驗證的總結與分析，以便對微信的加密、驗證安全有更加全面的接觸與認識，

? 本文主要從加密演算法、驗證流程分析、安全通信協議三方面進行介紹，主要對微信使用的mmtls進行了詳細的分析，

加密演算法

? 我們首先將從最基本的加密演算法出發，研究微信的加密方式，在通信中微信用到的加密演算法主要用RSA公鑰加密演算法，AES隨機密鑰加密演算法，這兩個演算法加密等級比較高，也因此難以破解，

RSA加密演算法

? RSA加密演算法是目前一個普遍使用且比較安全的公鑰加密演算法，公鑰加密也叫做非對稱加密，它有著一對加密密鑰（公鑰）和解密密鑰（私鑰），只有私鑰才能解密，并且如果知道了其中一個，不能計算出另一個密鑰，

? RSA允許選擇公鑰的大小，公鑰越長其安全性也越高，但是512位的密鑰是被視作不安全的；1024位的密鑰幾乎是安全的，一般推薦使用1024位的密鑰，

? RSA的加密流程：

• 首先，加密方產生明文字串，獲取CER認證公鑰，
• 加密機制通過Encoding指定不同的代碼頁，把字串轉換為不同頁碼對應的編碼，為byte[]形式，再將byte[]位元組流明文發送
• 使用CER證書的公鑰對byte[]位元組流明文進行加密操作，以密文形式發送，

? RSA解密流程：

• 將公鑰轉換為PFX證書的私鑰，使用PFX證書的私鑰對byte[]密文進行解密，還原為byte[]明文位元組流，

• 使用加密時Encoding使用的代碼頁，把byte[]形式的明文轉換成是字串明文并發送，

  流程圖示如下：

AES隨機密鑰加密演算法

? 微信的通信傳輸，全部基于AES隨機密鑰加密，AES是一個迭代的、對稱密鑰分組密碼，它的密鑰長度可以是128,192和256位，同時，使用128蚊分組加密和解密資料，

? 與公鑰加密相比，使用對稱密鑰加密速度比公鑰快，因此在大多數的應用中，都是先使用如RSA加密演算法來協商對稱加密密鑰，接著在之后的通信中使用對稱加密來加密訊息，微信也是如此，

? 微信中使用的是129位AES隨機密鑰，它的強度是56位DES花奴強度的1000+倍，破解128位的AES密碼需要的時間也很長，可以達到億萬年計，

? 對稱密鑰加解密流程相似，每輪的AES加密回圈均有如下四個步驟：

• 位元組替換：對資料的每一位元組應用一個非線性變換
• 行移位：對每一行的位元組回圈重新排序
• 列混合：對矩陣的列應用一個線性變換
• 輪密鑰加：把輪密鑰混合到中間資料

? 不同的是最后一輪省略了列混合變換，

HKDF密鑰擴展

? HKDF的主要用來使用原始的密鑰資訊來派生出一個或者更多個可以達到密碼學強度的密鑰——將較短的密鑰材料擴展成較長的密鑰材料，程序中需要保證隨機性，在微信通信協議mmtls中，微信使用了HKDF來擴展密鑰，

? HKDF主要包含兩個基本模塊，分別是

• 提取 Extract：使用原始的密鑰來派生出一個符合密碼學強度的偽隨機密鑰；
• 擴展 Expand：使用上一步的偽隨機密鑰，擴展出指定長度的密鑰，

Extract

? 他有三個輸入分別是：

• HAMC使用的Hash函式H，對應的輸出長度是hashlen；
• 原始密鑰
• 隨機元salt，如果沒有組默認是hashlen長度的0串

? 輸出：

• hasklen長度的偽隨機密鑰

Expand

? 他有四個輸入分別是：

• HAMC使用的hash函式H，H輸出長度是hashlen
• 第一步生成的隨機密鑰PRK
• 另外的隨機元info，可以為空
• 期望生成的密鑰長度L

? 輸出：

• L長度的輸出密鑰OKM

流程及說明如下：

? T(0) = 空
? T(1) = HMAC-Hash(PRK, T(0) || info || 0x01)
? T(2) = HMAC-Hash(PRK, T(1) || info || 0x02)
? T(3) = HMAC-Hash(PRK, T(2) || info || 0x03)
…

安全通信協議

? 微信通信系統選用了Protocl Buffer作為通信協議，同時微信也自研出了mmtls作為他們的通信協議，我們將對這兩個協議進行介紹，

Protocol Buffer

? Protocol Buffer用于結構化的資料描述、傳輸和存盤，它是由谷歌公司開發的一種資料描述語言，基于二進制，因此比xml,json短小、高效，

? 它的一個重要優點是可以保證同一訊息報文新舊版本之間的兼容性，

mmtls

? 為了保證安全隱私，以及快速的聊天體驗，微信基于TLS1.3研發出了mmtls協議，并在微信中使用，

特點

? mmtls的特點是：

1. 安全，主要體現在防竊聽，防篡改，防重放，防偽造，

2. 低延遲、低資源消耗，資料在傳輸程序中不會增加明顯的延遲；后臺負載增加在可接受范圍，

3. 可用性，在一些極端情況下（如server負載過高），后臺能夠控制提供降級服務，且不被攻擊者利用，進行降級攻擊，

4. 可擴展性，mmtls協議可擴展、可升級，方便添加安全強度更高的密碼學組件，方便禁止過時的密碼學組件，

   mmtls總體架構如下：

? 進入mmtls內部，它包含三個子協議：Record協議、Handshake協議、Alert協議，他們的關系如下所示：

? Handshake協議用于完成Client與Server的握手協商，協商出一個對稱加密密鑰Key以及其他密碼材料，用于后續資料加密，Alert協議用于通知對端發生錯誤，希望對端關閉連接，目前mmtls為了避免server存在過多TCP Time-Wait狀態，Alert訊息只會server發送給client，由client主動關閉連接，而Record協議則使用對稱加密密鑰進行安全的通信，

? 結合具體的使用場景，mmtls在TLS1.3的基礎上主要做了以下幾方面的作業：

1. 輕量級，砍掉了客戶端認證相關的內容；直接內置簽名公鑰，避免證書交換環節，減少驗證時網路交換次數，

2. 安全性，選用的基礎密碼組件均是TLS1.3推薦、安全性最高的密碼組件；0-RTT防重放由proxy層和logic框架層協同控制，

3. 高性能，使用0-RTT握手方式沒有增加原有Client和Server的互動次數；和TLS1.3比，優化了握手方式和密鑰擴展方式，

4. 高可用性，服務器的過載保護，確保服務器能夠在容災模式下提供安全級別稍低的有損服務，

   下面我們將具體的分析mmtls協議：

Handshake協議——安全地協商出對稱加密密鑰

? Handshake協議其實做的最主要的事情就是完成加密密鑰的協商，即讓通信雙方安全地獲得一致的對稱密鑰，以進行加密資料傳輸，在此基礎上，還完成了一些優化作業，如復用session以減少握手時間，

? mmtls結合微信的特點，在保證安全性和性能的前提下，只保留了三種密鑰協商方式（1-RTT ECDHE, 1-RTT PSK, 0-RTT PSK），并做了一些優化，

? 微信目前有兩個資料傳輸信道：

• 基于HTTP協議的短連接
• 基于私有協議的長鏈接

? 微信在其長鏈接中，建立好TCP連接之后，會先發一個nooping包，驗證長鏈接的連通性，因此長鏈接在建立時候第一個資料報不會發送資料，因此采用1-RTT的握手方式，用第一個握手包取代nooping包，因此長鏈接之下使用1-RTT ECDHE和1-RTT PSK這兩種密鑰協商方式，

? 為了防止中間人攻擊，在mmtls中采用ECDSA的數字簽名演算法，在進行密鑰協商時候，雙方密鑰協商時，再分別運行簽名演算法對自己發出的公鑰進行簽名，收到資訊后，首先驗證簽名，如果簽名正確，則繼續進行密鑰協商，攻擊者沒有辦法阻止別人獲取公鑰，除非完全掐斷發送方的通信，這樣一來，中間人攻擊就不存在了，

? 為了優化通信程序，在微信中，mmtls就是只對Server做認證，不對Client做認證，因為微信客戶端發布出去后，任何人都可以獲得，只要能夠保證客戶端程式本身的完整性，就相當于保證了客戶端程式是由官方發布的，而客戶端程式本身的完整性不是mmtls協議保護的范疇，

? 接著進行PSK密鑰協商，Client將PSK的ticket{key}部分發送給Server，由于只有Server才知道ticket_key，因此key是不會被竊聽的，Server拿到ticket后，使用ticket_key解密得到key，然后Server用基于協商得到的密鑰key，對協商資料計算訊息認證碼來認證，這樣就完成了PSK認證密鑰協商，PSK認證密鑰協商使用的都是對稱演算法，性能上比ECDH認證密鑰協商要好很多，

? 下圖為PSK密鑰協商的流程示意：

? 在mmtls中，為了節約公鑰派發的時間，將verify_key直接內置在客戶端，這樣就避免證書鏈驗證帶來的時間消耗以及證書鏈傳輸帶來的帶寬消耗，

? 上面的密鑰協商方式都額外需要一個RTT去獲取對稱加密key，但是還存在著一種密鑰協商方式可以在握手協商程序中安全地將業務資料傳遞給對端，即0-RTT密鑰協商，

? 在微信中，預先生成一對公私鑰(static_svr_pub_key, static_svr_pri_key)并將static_svr_pub_key預置在Client中，那么Client可以在發起握手前就通過static_svr_pub_ke和cli_pub_key生成一個對稱密鑰SS(Static Secret)，然后用SS加密第一個業務資料包（實際上是通過SS衍生的密鑰對業務資料進行加密，后面詳述），這樣將SS加密的業務資料包和cli_pub_key一起傳給Server，Server通過cli_pub_key和static_server_private_key算出SS，解密業務資料包，這樣就達到了0-RTT密鑰協商的效果，

?

Record協議——使用對稱加密密鑰進行安全的通信

? 經過上面的Handshake程序，此時Client和Server已經協商出了一致的對稱加密密鑰pre_master_key，那么接下來就可以直接用這個pre_master_key作為密鑰，選擇一種對稱加密演算法（如常用的AES-CBC）加密業務資料，將密文發送給Server，實際上如果真的按這個程序進行加密通信是有很多安全漏洞，

? mmtls經過綜合考慮，選擇了使用AES-GCM這種AEAD類演算法，作為協議的認證加密組件，而且AES-GCM也是TLS1.3要求必須實作的演算法，

? AES演算法的初始化向量IV一旦用錯會有安全漏洞，因此handshake協議協商得到的pre_master_secret不能直接作為對稱加密密鑰，而是需要經過擴展變換，得到六個對稱加密引數，

• Client Writer MAC Key：用于客戶端計算訊息認證碼，及服務端驗證；
• Server Writer MAC Key：用于服務端計算訊息驗證碼，及客戶端驗證；
• Client Write Encryption Key：用作客戶端加密，及服務端解密；
• Server Write Encryption Key：用作服務端加密，及客戶端解密；
• Client Write IV：客戶端加密時候的初始化向量；
• Server Write IV：服務端加密時候的初始化向量，

? 實際上MAC Key和Encryption Key只需要一個就可以了，握手生成的pre_master_secret只有48位元組，mmtls使用HKDF做密鑰擴展生成上述引數，

? 為了防范重放攻擊，微信為每一個業務包編一個遞增的sequence number，mmtls的做法是將sequence number作為構造AES-GCM演算法引數nonce的一部分，利用AES-GCM的演算法特性，只要AES-GCM認證解密成功就可以確保sequence number符合預期，

? 為了保證資料來源的可靠性（認證），mmtls經過綜合考慮，選擇了使用AES-GCM這種AEAD類演算法，作為協議的認證加密組件，而且AES-GCM也是TLS1.3要求必須實作的演算法，

流程分析

登錄認證分析

? 實際上微信對登陸程序分了兩種情況，分別是設備第一次登陸和設備之后的登陸，

? 若某臺設備首次登陸微信，那么微信就會在登陸程序中向設備回傳一些組態檔，之后除非卸載微信，那么這些組態檔就不需要更改，

• 首先客戶端向服務器發送登陸請求報文，報文中包含了賬戶、密碼、MD5加密資訊、隨機AES密鑰，并使用RSA公鑰加密登錄包，發送給服務器，
• 服務器收到登錄包后，使用RSA私鑰解密，獲取包中資訊，對用戶的賬戶密碼進行核驗，將最后生成的驗證包使用AES密鑰加密發送給客戶端，
• 客戶端收到驗證包，使用AES解密后獲取驗證資訊，之后的通信就使用AES進行加密了，
• 登錄驗證成功后，客戶端還會基于HTTP協議向服務器獲取系統配置資訊，
• 在整個登錄程序，資料都是按照Protocol Buffer進行構造決議，

通信互動分析

? 對于微信的會話加密，由于登錄程序中已經使用了AES密鑰，之后的通信都是基于此AES密鑰的，但是在通信程序中，服務器會隨機生成會話密鑰，且會話密鑰的生命周期不長，會時長改變，之后的通信都是在會話密鑰加密下進行的，

? 這里的具體互動協議則可以參考上面所介紹的mmtls協議，

總結

? 由上述分析可見，為了保證安全性，一方面，微信使用了RSA與AES等安全的加密方式，另一方面，也根據業務需求制定了適合微信的通信協議，以mmtls為例，他在TLS基礎上做了一定的刪減以及完善，從而達到了安全的密鑰協商以及加密作業，同時為了減少通信量，微信也使用了HKDF密鑰拓展，以及將服務端的某些密鑰資訊內嵌在程式中，微信中所使用的通信協議設計，對于我們也有著很大的參考意義，

?

參考文獻

[1]瞿曉海,薛質.微信加密通信原理分析[J].資訊安全與技術,2014,5(01):13-16.

[2]萬園春,顧旸鋮,邱衛東.微信互動協議和加密模式研究[J].微型電腦應用,2015,31(02):31-34.

[3]基于TLS1.3的微信安全通信協議mmtls介紹 https://mp.weixin.qq.com/s/tvngTp6NoTZ15Yc206v8fQ；

[4] RFC5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF)