本文由融云技術(shù)團隊分享点寥，原題“互聯(lián)網(wǎng)通信安全之端到端加密技術(shù)”，內(nèi)容有較多修訂和改動汹买。
1汽煮、引言
在上篇《IM聊天系統(tǒng)安全手段之通信連接層加密技術(shù)》中，分享了關(guān)于通信連接層加密的相關(guān)技術(shù)和實踐睡毒，包括在傳輸即時通信消息時啟用 TLS 鏈路加密（保證消息在到達服務(wù)器前無法被竊聽和篡改）来惧、使用 CA 認證機制（杜絕中間人攻擊）等。
本篇將圍繞IM傳輸內(nèi)容的安全問題吕嘀，以實踐為基礎(chǔ)违寞，為你分享即時通訊應(yīng)用中的“端到端”加密技術(shù)。
（本文已同步發(fā)布于：http://www.52im.net/thread-4026-1-1.html）
2偶房、系列文章
本文是IM通訊安全知識系列文章中的第11篇，此系列總目錄如下：
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術(shù)在Android平臺上的應(yīng)用實踐》
《即時通訊安全篇（六）：非對稱加密技術(shù)的原理與應(yīng)用實踐》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理军浆，一篇就夠了》
《即時通訊安全篇（八）：你知道棕洋，HTTPS用的是對稱加密還是非對稱加密？》
《即時通訊安全篇（九）：為什么要用HTTPS乒融？深入淺出掰盘，探密短連接的安全性》
《即時通訊安全篇（十）：IM聊天系統(tǒng)安全手段之通信連接層加密技術(shù)》
《即時通訊安全篇（十一）：IM聊天系統(tǒng)安全手段之傳輸內(nèi)容端到端加密技術(shù)》（* 本文）
3、為什么需要端到端加密赞季？
上篇中提到的連接層加密技術(shù)愧捕，這是提升IM客戶端到服務(wù)器之間數(shù)據(jù)傳輸?shù)陌踩允侄危沁@并不能解決用戶間的通信隱私性以及安全性風險申钩。
因為在將數(shù)據(jù)傳輸?shù)椒?wù)器之后次绘，所有有權(quán)訪問此服務(wù)器的人，包括員工撒遣、供應(yīng)商及其他有關(guān)人員（甚至黑客）邮偎，都有可能讀取到用戶的數(shù)據(jù)。
有鑒于此义黎，端到端加密技術(shù)在即時通訊IM領(lǐng)域被廣泛應(yīng)用禾进，包括WhatsApp、Signal廉涕、Telegram 等國外即時通信軟件中都有使用泻云。
PS：有關(guān)端到端加密的基礎(chǔ)知識艇拍，可以從這兩篇里得到，建議詳讀：
《移動端安全通信的利器——端到端加密（E2EE）技術(shù)詳解》
4宠纯、端到端加密的技術(shù)設(shè)計思路
4.1 簡化版思路
說到端到端加密卸夕，我們首先想到的解決方案是：在發(fā)送端發(fā)送消息前對整個消息進行加密，接收端接收到消息后進行解密征椒。
如上這樣：消息中轉(zhuǎn)服務(wù)器就無法獲取我們的消息內(nèi)容了娇哆。
事實上：這確實是端到端加密中消息收發(fā)的簡化版解決方案，只是我們在實際應(yīng)用中要更加復(fù)雜勃救，效果也更加安全碍讨。
4.2 如何安全地傳遞用于消息加解密的密鑰
對于端到端加密，我們需要先解決的前置安全問題是：如何安全地傳遞用于消息加解密的密鑰蒙秒。
答案是：用非對稱加密的方式傳輸密鑰（與 SSL / TLS 中安全交換密鑰的方式類似）勃黍。
非對稱加密傳輸對稱加密密鑰的算法，一般歸結(jié)兩種方式：
1）一種是以 RSA晕讲、ECC 等為主（公鑰加密私鑰解密的方式覆获，本質(zhì)是加解密的算法）；
2）另一種是以 DH瓢省、ECDH 為主的生成共享密鑰的方式（本質(zhì)是通過計算協(xié)商一個共同的密鑰而不是加解密算法）弄息。
實際上：大部分即時通信軟件中的端到端加密都采用生成共享密鑰的方式來傳輸會話密鑰。這是為什么呢勤婚？
這就涉及到 DH 算法（即 Diffie-Hellman 密鑰交換算法）摹量，關(guān)于DH算法的資料，有興趣可以詳讀《Diffie-Hellman密鑰協(xié)商算法》馒胆，限于篇幅缨称，這里不專門討論。
Diffie-Hellman 密鑰交換算法的安全性依賴于這樣一個事實：雖然計算以一個素數(shù)為模的指數(shù)相對容易祝迂，但計算離散對數(shù)卻很困難睦尽。對于大的素數(shù)，計算出離散對數(shù)幾乎是不可能的型雳。
這里簡要描述一下 DH 共享密鑰的過程如下：
（其中“密鑰 S”即為最終的共享密鑰）
4.3 采用共享密鑰的原因
端到端加密采用共享密鑰的方式來傳輸會話密鑰有如下幾個原因：
1）如果采用 RSA当凡、ECC 等公鑰加密私鑰解密的方式傳輸密鑰，需要在創(chuàng)建會話時生成臨時密鑰四啰，并通過對方公鑰加密后傳輸?shù)浇邮斩恕?/p>
這就需要完全保證消息的可靠性宁玫，如果該消息在任何一個環(huán)節(jié)中丟失或損壞，則后續(xù)通信都無法進行柑晒∨繁瘢或者，需要采用更為可靠的傳輸方案匙赞，通常做法為需要接收端在線佛掖，通過各種確認來保證這個可靠性妖碉。
而采用共享密鑰的方式則只需要知道對方的公鑰，就可以完成生成共享密鑰芥被，并不一定需要對方在線欧宜。
2）如果已經(jīng)生成的臨時對稱密鑰丟失，則需要重新協(xié)商密鑰拴魄。而采用共享密鑰的方式則只需要知道對方的公鑰冗茸，就可以完成生成共享密鑰，不需要重新協(xié)商匹中。
3）采用公鑰加密私鑰解密的方式至少會比生成共享密鑰方式多一次交換對稱密鑰的通信過程夏漱。
4）密鑰協(xié)商方式，不僅僅可以完成兩個點之間的密鑰協(xié)商顶捷，還可以延展到多人之間的共同協(xié)商出相同的密鑰挂绰，這樣能滿足多人群體溝通的需求。
5服赎、端到端加密的初步實踐方案
我們結(jié)合對于 DH 算法（即 Diffie-Hellman 密鑰交換算法）這種共享密鑰方式的認知（即公鑰可隨意公開）葵蒂，先設(shè)計一個簡單的端到端消息加密的過程。
這個過程的邏輯流程如下：
1）在客戶端 APP 首次安裝時重虑，基于服務(wù)器公開的兩個全局的參數(shù)践付，生成自己的 DH 公鑰和私鑰；
2）將自己的公鑰上傳證書服務(wù)器缺厉，證書服務(wù)器上保存用戶標識與其公鑰的關(guān)系荔仁。私鑰則保存在客戶端上；
3）首次給對方發(fā)送消息或首次接收到對方消息時，便到證書服務(wù)器查詢對方的公鑰腥寇；
4）根據(jù)對方公鑰和自己的私鑰計算出共享密鑰研叫；
5）后續(xù)與對方所有的消息都基于這個密鑰和相同的對稱加解密算法進行加密解密操作。
端到端消息加密過程示意：
至此：我們完成了一個簡單的端到端消息加密方案诱告，在這個方案中我們引入了一個第三方的用于存儲用戶公鑰的角色，這個角色的存在可以讓任何一方都不用關(guān)心對方的在線狀態(tài)，隨時給對方發(fā)送加密過消息揖曾，而消息轉(zhuǎn)發(fā)服務(wù)器無法解密消息。
接下來亥啦，我們針對這個簡單方案存在的各種安全隱患問題炭剪，進行逐步分析和優(yōu)化。
6翔脱、端到端加密實踐方案的進一步優(yōu)化和演進
6.1 使用HMAC作為消息完整性認證算法
在消息傳輸過程中奴拦，雙方需要確認彼此消息的完整性，簡單的做法就是將消息進行 Hash届吁，得到的 Hash 值附加到消息后错妖，隨消息一起發(fā)送绿鸣；對端接收后，同樣進行 Hash暂氯，來驗證消息是否被篡改潮模。
關(guān)鍵點在于不同數(shù)據(jù)得到的 Hash 值一定不同，其中帶密鑰的 Hash 值就是 MAC算法痴施。
另外擎厢，為了避免使用同樣的 Hash 函數(shù)對相同數(shù)據(jù)進行操作總是得出同樣的值，額外加入一個密鑰辣吃，這樣使用不同密鑰就可以得出不同的 MAC动遭。當然，這個密鑰是兩個對端都知道的齿尽。
這樣沽损，我們就得到了基于加密 Hash 的消息完整性認證的算法——Hash-based MAC（簡稱HMAC）。
基礎(chǔ)知識1：什么是MAC算法循头？
全稱Message Authentication Code绵估，即消息認證碼（帶密鑰的Hash函數(shù)）。在密碼學(xué)中卡骂，MAC是通信實體雙方使用的一種驗證機制国裳，是保證消息數(shù)據(jù)完整性的一種工具。
MAC算法的安全性依賴于Hash函數(shù)全跨，故也稱帶密鑰的Hash函數(shù)缝左。消息認證碼是基于密鑰和消息摘要“hash”所獲得的一個值，可用于數(shù)據(jù)源發(fā)認證和完整性校驗浓若。
使用 MAC 驗證消息完整性的具體過程是：
1）假設(shè)通信雙方 A 和 B 共享密鑰 K渺杉，A用消息認證碼算法將 K 和消息 M 計算出消息驗證碼 Mac，然后將 Mac 和 M 一起發(fā)送給 B挪钓；
2）B 接收到 Mac 和 M 后是越，利用 M 和 K 計算出新的驗證碼 Mac*，若 Mac*和Mac 相等則驗證成功碌上，證明消息未被篡改倚评。
由于攻擊者沒有密鑰 K，攻擊者修改了消息內(nèi)容后無法計算出相應(yīng)的消息驗證碼馏予，因此 B 就能夠發(fā)現(xiàn)消息完整性遭到破壞天梧。
簡而言之就是：
1）發(fā)送者通過MAC算法計算出消息的MAC值，并和消息一起發(fā)給收信者霞丧；
2）收信者用同樣的MAC算法計算收到的消息的MAC值呢岗，并對比兩者。
下圖是原理示意：
基礎(chǔ)知識2：什么是HMAC算法？
HMAC是MAC算法中的一種敷燎，其基于加密HASH算法實現(xiàn)暂筝。任何加密HASH, 比如MD5、SHA256等硬贯，都可以用來實現(xiàn)HMAC算法焕襟，其相應(yīng)的算法稱為HMAC-MD5、HMAC-SHA256等饭豹。
6.2 使用ECDH算法替換DH算法
DH 算法是以離散對數(shù)的數(shù)學(xué)難題為基礎(chǔ)的鸵赖，隨著計算機計算能力逐步增強，我們要不停地使用更大的數(shù)以增加破解難度拄衰，目前業(yè)界普遍認為至少需要使用 2048 位 DH 算法才具備更好的安全性。
在此我們引入 ECDH 算法替換 DH 算法翘悉。ECDH 密鑰協(xié)商算法是 ECC 算法和 DH 密鑰交換原理結(jié)合使用茫打。ECC 是建立在基于橢圓曲線的離散對數(shù)問題上的密碼體制。在相同破解難度下妖混，ECC 具有更小長度的密鑰和更快的正向計算速度優(yōu)勢老赤。
我們系統(tǒng)上的 ECDH 可以直接采用目前公開的 sepc256kl 和 Curve25519 曲線，而無需服務(wù)再提供公開大數(shù)參數(shù)制市。
6.3 提升前向安全性
在消息傳輸過程中抬旺，如果協(xié)商好的密鑰泄露了，就意味著所有信息都將暴露于風險之下祥楣。
為了防止這種情況發(fā)生开财，我們需要每次加密使用的密鑰都與上一次不同，且不可以反向推導(dǎo)得出之前的密鑰误褪。
此處引入一個 Hash 算法：這個 Hash 算法可以通過輸入一個密鑰導(dǎo)出另外一個離散性更大的密鑰责鳍，每次發(fā)送消息時都是用上次的消息密鑰進行 Hash 運算得出本次密鑰，由于 Hash 算法具有單向不可逆的特性兽间，因此就無法通過本次的密鑰推導(dǎo)之前的密鑰薇搁。
從感觀上，這就像一個棘輪渡八，棘輪就是一種特殊的齒輪，他只能往一個方向轉(zhuǎn)下去传货，而不能往回轉(zhuǎn)屎鳍。
我們先來感性認識一下棘輪：
在技術(shù)上，做到"只能往一個方向轉(zhuǎn)下去问裕，而不能往回轉(zhuǎn)"逮壁，是達到前向安全的關(guān)鍵。這就保證了粮宛，如果某一輪的密鑰被破解出來窥淆，但前面的密鑰是無法計算出來的卖宠，也就是前面的消息無法被解密。
6.4 同時保證前向安全和后向安全性
出于極致的安全性要求忧饭，我們會同時考慮前向安全和后向安全扛伍。如何保證在某次通信中，被破解出來的密鑰词裤，不能破解出之前的消息刺洒，而且在一定周期內(nèi)，這個破解出來的密鑰將不會再起作用吼砂。
介于此我們再引入另外一個棘輪來保證其向后的安全性逆航。這就是大名鼎鼎的?Signal protocol?中的雙棘輪算法。
Signal protocol 是真正的端到端的通訊加密協(xié)議渔肩，號稱是世界上最安全的通訊協(xié)議因俐，任何第三方包括服務(wù)器都無法查看通訊內(nèi)容。
雙棘輪算法包含一個 KDF 棘輪和一個 DH 棘輪周偎。
KDF 全稱（Key derivation function） 密鑰導(dǎo)出函數(shù)抹剩，用于從一個原始的密鑰導(dǎo)出一個或多個密鑰。本質(zhì)上就是 Hash 函數(shù)栏饮，通常用來將短密碼變成長密碼吧兔。另外 KDF 需要加“鹽”（salt），用于防彩虹表袍嬉，出于 Hash 的特性境蔼，這個“鹽”的長度至少要大于 Hash 結(jié)果長度。
KDF (原密鑰伺通，鹽) = 導(dǎo)出密鑰
KDF 棘輪就是運用 KDF 算法箍土，設(shè)計出一種密鑰不斷變化的效果，流程如下：
首先：將初始密鑰使用 KDF 算法導(dǎo)出新的密鑰罐监，新密鑰被切成兩部分吴藻，前半部分作為下一次 KDF 計算的輸入，后半部分作為消息密鑰弓柱。
每迭代一次（也可以說棘輪步進一次）沟堡，就會生成新的消息密鑰。
由于 KDF 算法的單向性矢空，通過這條消息的密鑰無法倒推出上一條消息密鑰航罗，這就保證了密鑰的前向安全。但是如果 KDF 中的鹽被掌握屁药，那么它就可以按照這種算法計算出以后所有的消息密鑰粥血。
為了保證后向安全，就要設(shè)計一種方法，使每次迭代時引入的鹽是隨機的复亏，從而保證每次的消息密鑰是不可以向后推算的趾娃。
由前面介紹的 DH 算法得知：兩對密鑰對可以通過 DH 協(xié)議生成一個安全的協(xié)商密鑰，如果更換其中一個密鑰對缔御，新的協(xié)商密鑰也會變化抬闷。
根據(jù)這個方法：我們可以設(shè)計出一個安全更新鹽的方法。我們在證書服務(wù)器增加一個臨時公鑰證書刹淌，這個臨時證書是按照接收雙方標識構(gòu)建的臨時公鑰對饶氏，即每個人的每個單人會話都具備一個臨時公鑰。每進行一個消息輪回有勾，就更新一次己方的臨時公鑰疹启，同時根據(jù)另外一方的臨時公鑰和己方的私鑰進行協(xié)商，并將協(xié)商出的密鑰作為鹽蔼卡，使得 KDF 棘輪算法生成的消息密鑰具有后向安全性喊崖。
在初始時我們無法預(yù)測出每個人所有的新二人會話：那么我們就可以規(guī)定創(chuàng)建新的二人會話時，發(fā)起方首先生成一個新的臨時 DH 公私鑰對雇逞，并向服務(wù)器上傳自己的臨時 DH 公鑰荤懂；其次發(fā)送方用接收方公布的長期公鑰與自己的臨時私鑰協(xié)商出密鑰作為消息加密的密鑰，對消息進行加密塘砸；最后接收方首次接收到消息后用自己的長期公鑰和發(fā)送方的臨時私鑰計算得出消息密鑰节仿，并在首次回復(fù)消息時生成臨時公私鑰，同時上傳臨時公鑰掉蔬。
問題是：如果接收端不在線廊宪，而發(fā)送端每條消息都去更新己方的臨時公鑰證書，就會導(dǎo)致發(fā)出去的這些消息女轿，在接收端上線并收取后無法被正常解密箭启。
為了解決這個問題，我們需要規(guī)定：只有在發(fā)出消息并得到對方回復(fù)后才更新臨時證書蛉迹，若對方不回復(fù)消息則不去更新臨時證書傅寡。接收端能回復(fù)消息就表示其已經(jīng)上線并接收完消息，這樣就可以保證離線消息或者消息亂序也可以被對方正常解析北救。這種方法就是雙棘輪算法中的另外一個 DH 棘輪荐操。
6.5 更安全的密鑰交換協(xié)議—— X3DH
對比最初的方案，為了滿足消息的前向安全和后向安全珍策，我們增加了雙棘輪算法淀零，在原基礎(chǔ)方案上為每個人增加了一組會話級別臨時 DH 密鑰，每個人都擁有一個長期密鑰和一組臨時密鑰膛壹。
但是：由于長期密鑰無法被更換，所以方案依然存在著安全隱患。
因此：Signal protocol 設(shè)計了一種更為復(fù)雜和安全的 DH 密鑰交換過程模聋，稱之為?X3DH（即 DH 協(xié)議的 3 倍擴展版）肩民。
在 X3DH 協(xié)議里，每個人都要創(chuàng)建 3 種密鑰對链方，分別如下：
1）身份密鑰對（Identity Key Pair）：一個長期的符合 DH 協(xié)議的密鑰對持痰，用戶注冊時創(chuàng)建，與用戶身份綁定祟蚀；
2）已簽名的預(yù)共享密鑰（Signed Pre Key）：一個中期的符合 DH 協(xié)議的密鑰對工窍，用戶注冊時創(chuàng)建，由身份密鑰簽名前酿，并定期進行輪換患雏，此密鑰可能是為了保護身份密鑰不被泄露；
3）一次性預(yù)共享密鑰（One-Time Pre Keys）：一次性使用的?Curve25519?密鑰對隊列罢维，安裝時生成淹仑，不足時補充。
所有人都要將這 3 種密鑰對的公鑰上傳到服務(wù)器上肺孵，以便其他人發(fā)起會話時使用匀借。
假如 Alice 要給 Bob 發(fā)送消息，首先要和 Bob 確定消息密鑰平窘，流程大致如下：
1）Alice 要創(chuàng)建一個臨時密鑰對（ephemeral key）吓肋，我們設(shè)成 EPK-A，此密鑰對是為了后面棘輪算法準備瑰艘，在此處作用不大是鬼；
2）Alice 從服務(wù)器獲取 Bob 的三種密鑰對的公鑰：身份密鑰對IPK-B、已簽名的預(yù)共享密鑰 SPK-B磅叛、一次性預(yù)共享密鑰 OPK-B屑咳；
3）Alice 開始使用 DH 協(xié)議計算協(xié)商密鑰，要引入?yún)?shù)包括：自己創(chuàng)建的兩個密鑰對的私鑰弊琴，以及 Bob 的三個公鑰兆龙。然后用類似排列組合的方式，將自己的私鑰與對方的公鑰分別帶入 DH 算法計算敲董。
DH1 = DH(IPK-A, SPK-B)
DH2 = DH(EPK-A, IPK-B)
DH3 = DH(EPK-A, SPK-B)
DH4 = DH(IPK-A, OPK-B)
如圖所示：
然后將計算得到的四個值紫皇，前后連接起來，就得到了初始密鑰腋寨，如下：
DH = DH1 || DH2 || DH3 || DH4
注：“||”代表連接符聪铺，比如 456 || 123 = 456123
但是 DH 這個密鑰太長，不適合作為消息密鑰萄窜，所以對這個初始密鑰進行一次 KDF 計算铃剔，以衍生出固定長度的消息密鑰 S：
S = KDF（DH1 || DH2 || DH3 || DH4）
這一步撒桨，Alice 終于計算出了消息密鑰 S。
于是：
1）Alice 使用消息密鑰 S 對消息進行加密键兜，連同自己的身份公鑰 IPK-A 和臨時公鑰 EPK-A 一同發(fā)給 Bob凤类；
2）Bob 收到 Alice 的信息后，取出 Alice 的 2 個公鑰普气，連同自己的密鑰谜疤，使用與 Alice 相同的算法計算消息密鑰 S；
3）Bob 和 Alice 使用消息密鑰進行加密通訊现诀。
由上可知：X3DH 實際是復(fù)雜版的 DH 協(xié)議夷磕。
至此：我們簡單介紹了 Signal Protocol 中最為核心的 X3DH 協(xié)議與雙棘輪算法，基本上可以滿足前向安全和后向安全仔沿。當然坐桩，真實的處理過程會更為復(fù)雜和安全。
7于未、IM群聊的端到端加密方案
在即時通訊場景中撕攒，除了二人之間的聊天以外，還有一個重要的場景就是群聊烘浦，那么群聊時的多人消息如何做端到端加密呢抖坪？
我們再次回到 DH 密鑰協(xié)商算法上的推導(dǎo)過程：顯然，多方情況下依然可以繼續(xù)使用 DH 密鑰協(xié)商算法闷叉，這就是群聊中端到端加密的基礎(chǔ)擦俐。
而 Signal Protocol 在群組聊天中的設(shè)計與二人聊天又有所不同，由于群聊的保密性要求相對低一些握侧，只采用了 KDF 鏈棘輪+公鑰簽名來進行加密通訊以保障加密的前向安全蚯瞧。
群組聊天的加解密通訊流程如下：
1）每個群組成員都要首先生成隨機 32 字節(jié)的 KDF 鏈密鑰(Chain Key)，用于生成消息密鑰品擎，以保障消息密鑰的前向安全性埋合，同時還要生成一個隨機 Curve25519 簽名密鑰對，用于消息簽名萄传；
2）每個群組成員用向其它成員單獨加密發(fā)送鏈密鑰(Chain Key)和簽名公鑰甚颂。此時每一個成員都擁有群內(nèi)所有成員的鏈密鑰和簽名公鑰；
3）當一名成員發(fā)送消息時秀菱，首先用 KDF 鏈棘輪算法生成的消息密鑰加密消息振诬，然后使用私鑰簽名，再將消息發(fā)給服務(wù)器衍菱，由服務(wù)器發(fā)送給其它成員赶么；
4）其它成員收到加密消息后，首先使用發(fā)送人的簽名公鑰驗證脊串，驗證成功后辫呻，使用相應(yīng)的鏈密鑰生成消息密鑰清钥，并用消息密鑰解密；
5）當群組成員離開時放闺，所有的群組成員都清除自己鏈密鑰和簽名公鑰并重新生成循捺，再次單獨發(fā)給每一位成員。這樣操作雄人，離開的成員就無法查看群組內(nèi)的消息了。
由上可知：一個人在不同的群組里念赶，會生成不同的鏈密鑰和簽名密鑰對础钠，以保障群組之間的隔離。在每個群組中叉谜，每個成員還要存儲其它成員的 KDF 鏈和簽名公鑰旗吁，如果群組成員過多，加解密運算量非常大停局，會影響發(fā)送和接收速度很钓，同時密鑰管理數(shù)據(jù)庫也會非常大，讀取效率也會降低董栽。
所以：群組聊天使用?Signal Protocol 協(xié)議码倦，群人數(shù)不宜太多。
8锭碳、端到端加密方案的補充說明
上面我們介紹了即時通信中二人聊天和群組聊天的端到端加密全部過程袁稽。但是正常情況下端到端消息加密只是加密消息的實際負載部分（即只加密消息“體”部分），而消息的控制層則不會被加密擒抛，因為消息轉(zhuǎn)發(fā)服務(wù)器需要根據(jù)控制信息進行消息轉(zhuǎn)發(fā)或路由（否則肯定大大影響IM底層的路由和通信效率推汽，因為需要反復(fù)加密解密）。
為了防止消息被定向分析（分析用戶什么時間向誰發(fā)送了消息歧沪，或接收了誰的消息）歹撒，我們依然需要對整體即時通信的長連接鏈路進行加密保護（這說的就是上篇文章里的通信連接層加密技術(shù)了），防止信息被中間網(wǎng)絡(luò)設(shè)備截獲并分析诊胞。而且為了防止密鑰服務(wù)器被中間人攻擊暖夭，也需要開啟鏈路加密保護。
9厢钧、參考資料
[1]?移動端安全通信的利器——端到端加密（E2EE）技術(shù)詳解
[2]?簡述實時音視頻聊天中端到端加密（E2EE）的工作原理
[3]?HASH鳞尔、MAC、HMAC學(xué)習(xí)
[4]?一文了解加解密早直、哈希函數(shù)寥假、MAC、數(shù)字簽名霞扬、證書糕韧、CA等
[5]?雙棘輪算法：端對端加密安全協(xié)議枫振，原理以及流程詳解
[6]?Signal protocol 開源協(xié)議理解
[7]?X25519（Curve25519）橢圓曲線參考資料
（本文已同步發(fā)布于：http://www.52im.net/thread-4026-1-1.html）
