原文: http://mrpeak.cn/blog/encrypt/

移動端App安全如果按CS結(jié)構(gòu)來劃分的話，主要涉及客戶端本身數(shù)據(jù)安全，Client到Server網(wǎng)絡(luò)傳輸?shù)陌踩?，客戶端本身安全又包括代碼安全和數(shù)據(jù)存儲安全。所以當(dāng)我們談?wù)揂pp安全問題的時候一般來說在以下三類范疇當(dāng)中。

App代碼安全，包括代碼混淆，加密或者app加殼。

App數(shù)據(jù)存儲安全，主要指在磁盤做數(shù)據(jù)持久化的時候所做的加密。

App網(wǎng)絡(luò)傳輸安全，指對數(shù)據(jù)從客戶端傳輸?shù)絊erver中間過程的加密，防止網(wǎng)絡(luò)世界當(dāng)中其他節(jié)點對數(shù)據(jù)的竊聽。

這一篇我們先聊下網(wǎng)絡(luò)傳輸?shù)陌踩?/p>

安全相關(guān)的基礎(chǔ)概念

網(wǎng)絡(luò)安全相關(guān)的概念非常之多，要在廣度和深度上都有所造詣很困難。但如果只是站在保障App通信基本安全這個維度上，做到合理使用安全算法，比大部分人所預(yù)期的都要簡單很多。以下這些基礎(chǔ)概念是必備知識：

對稱加密算法，代表算法AES

非對稱加密算法，代表算法RSA，ECC

電子簽名，用于確認(rèn)消息發(fā)送方的身份

消息摘要生成算法，MD5，SHA，用于檢測消息是否被第三方修改過

怎么樣算安全？

安全問題說白了是信任問題，談到信任一定要有一個可被信任的實體。假設(shè)某天A收到了一條“Message”，如果這個消息確實是來自B，消息就可以被信任，那么B就這安全問題當(dāng)中可被信任的實體。

對于A來說只要滿足三點就說明收到“Message”是安全的：

Message有B的電子簽名，表明消息確實是來自B。

Message沒有被篡改過。

Message被某種加密算法加密過，只有A和B知道如何解密。

A和B的交談如果放到網(wǎng)絡(luò)世界當(dāng)中，就是典型的Client－Server模式。和現(xiàn)實世界當(dāng)中聊天不同的是，A和B所說的任何話都可以輕而易舉的被其他人聽到，隔墻隨處有耳。

怎么去保證App網(wǎng)絡(luò)傳輸?shù)陌踩?/b>

為了保證傳輸數(shù)據(jù)的安全，需要使用加密算法。在決定什么樣的業(yè)務(wù)場景使用什么樣的加密算法之前，先要了解我們的工具箱里有哪些可用工具。加密算法的工具箱里其實就兩種工具：“對稱”加密算法和“非對稱”加密算法。清楚這兩個分類是合理設(shè)計加密算法使用場景的大前提，兩個分類里我們各挑選一個代表算法來研究，“對稱”加密挑選AES，“非對稱”加密選擇RSA。了解AES和RSA之后我們再針對一些特定業(yè)務(wù)場景設(shè)計安全模型。

對稱加密之AES

要深入了解像AES這種加密算法，對大部分初學(xué)的同學(xué)來說可能有些費時費力，但對算法掌握可以是個循序漸進(jìn)的過程。簡單來說可以分為以下幾個階段：

階段一：在AES誕生之前（1975年之前），早起的加密算法十分簡單，是一種類似“暗號”的機(jī)制。通信的雙方通過事先約定一種“加密機(jī)制”對明文進(jìn)行處理，只要“加密機(jī)制”不被泄漏，信息就算安全。后來無數(shù)的經(jīng)驗表明算法總是會被第三方得知，對算法本身進(jìn)行保密管理也不方便。

階段二：到上世紀(jì)70年代，公眾和政府意識到加密算法的重要性，由美國政府機(jī)構(gòu)NBS牽頭組織業(yè)界專家設(shè)計了DES算法。DES算法本身公開，但算法的安全全依賴于一個密鑰。后來DES統(tǒng)治加密算法長達(dá)二十多年。不過DES從誕生到逐步退出歷史舞臺，一直都伴隨著陰謀的論調(diào)。DES原本是由IBM提出，針對已有算法Lucifer改造而成，但DES制定的過程一直都有美國另一政府機(jī)構(gòu)NSA的影子。

DES的兩大特點是短密鑰（short key）和結(jié)構(gòu)復(fù)雜的s-box。有研究表明，是NSA當(dāng)時勸說IMB短密鑰足夠安全，而且NSA也直接參與了s-box的設(shè)計。后來就一直有傳言說NSA似乎有辦法能輕易破解DES加密后的秘文。

到1990年，劇情出現(xiàn)反轉(zhuǎn)。第三方獨立研究者Eli Biham和Adi

Shamir發(fā)布了破解塊加密方式的通用破解方法differential

cryptanalysis。出人意料的是按照NSA建議設(shè)計的s-box對這種破解方法有更好的免疫性，NSA的參與似乎更加提高了DES的安全性。

到1994年，劇情進(jìn)一步升華。公開文件披露，早在1974年IBM的研究者就已經(jīng)發(fā)現(xiàn)了differential

cryptanalysis這種破解方式，不過這項研究被NSA禁止公開，理由是會威脅到國家安全，對，就是現(xiàn)在美劇里經(jīng)常提到的national

security。不僅如此，NSA還針對DES做了一些改造加強(qiáng)安全性。至此，NSA已經(jīng)全身都掛滿了節(jié)操，被業(yè)界質(zhì)疑忍辱負(fù)重二十多年一聲沒吭，比24小時男主角Jack

Bauer形象更加高大光輝。

階段三：后來陸陸續(xù)續(xù)有一些針對DES破解的攻防戰(zhàn)，DES最終演化成Triple DES的形態(tài)，不過在性能上已經(jīng)出現(xiàn)明顯問題，催生了今天對稱加密的王者算法AES。AES在安全性，實現(xiàn)難度，運算性能上都有更好的表現(xiàn)。在全面了解AES之前，首先明確下好的加密算法必須符合哪些條件，這些條件是經(jīng)過數(shù)十年加密破解攻防戰(zhàn)所總結(jié)出來的。

條件一，Confusion。對原文以最小的粒度(按字節(jié))進(jìn)行混淆生成秘文。最簡單的confusion可以是A+3=D.

條件二，Deffusion。對原文所包含的位置信息進(jìn)行打亂排布,比如將第一個字節(jié)與第四個字節(jié)的位置對換.

條件三，Secret Key。最終的秘文與Secret Key相關(guān)，只要持有Secret Key就可以對數(shù)據(jù)解密，將安全性的管理歸于一個密鑰的管理。

AES也是屬于Cipher Block的一種，對于數(shù)據(jù)的加密都是已block為單位進(jìn)行處理。針對需要加密的數(shù)據(jù)AES會先把數(shù)據(jù)分成一個個的block，每個block為16字節(jié)，可以排布成4x4的表格（又名矩陣）。如下圖所示：

如果最后一塊不足16字節(jié)，用0補齊（padding）。后續(xù)的加密行為都是以block為單位進(jìn)行處理，這個處理過程必須滿足上述所說三個條件。加密的流程如下圖：

每一個block都會被單獨依次處理，橙色方框表示加密的過程，這個過程包括兩個方面，一方面是block本身數(shù)據(jù)的運算處理，二是與round key（也就是我們所說的對稱加密算法密鑰）進(jìn)行運算處理。流程示意圖如下：

每一個block會依次經(jīng)過Confusion（條件一），Difussion（條件二），Mix

Data（可以看作再一次的Confusion）。最后一步是和我們的round

key進(jìn)行位運算得到最后的block秘文，這樣一個完整的來回稱為一個round，重復(fù)10次round就完成了block加密，當(dāng)然每個round當(dāng)中所使用的round

key也會發(fā)生變化，以保證每次block加密所使用的key都不同。

針對每個block都重復(fù)上述處理過程就完成了AES加密過程，是不是so

easy。當(dāng)然這是被我高度抽象簡化后的流程示意圖，當(dāng)中每一步都有很多的細(xì)節(jié)可以深入。密鑰越長，每個block處理的round次數(shù)越多，AES就越安全，不過安全性和計算性能不可兼得，一般來說，我們使用128bit的Key就可以保證算法的安全性了。對了，解密的過程就是把上面加密的過程反過來做一遍。。

階段四：明白了AES的流程，還需要了解正確的使用姿勢。AES有兩個經(jīng)典的使用姿勢，ECB模式和CBC模式。ECB模式可以用下圖表示：

ECB模式很簡單，就是針對每一個block單獨進(jìn)行AES運算，每個block的處理結(jié)果之間沒有任何關(guān)系。使用這種方式單個block都是安全的，但對包含大量block的數(shù)據(jù)來說，沒有能夠隱藏data

pattern，因為相同的原文會產(chǎn)生相同的秘文，這對圖片文件來說比較致命：

相同的色塊產(chǎn)生相同的秘文，這樣相同顏色在圖片當(dāng)中出現(xiàn)的規(guī)律就和原始數(shù)據(jù)一樣一目了然。

CBC模式針對ECB模式的缺陷做了處理，使得每個block的AES運算結(jié)果都依賴于之前的block秘文。如下圖所示：

每一個block在加密之前都會與上個block產(chǎn)生的秘文進(jìn)行抑或運算，這樣相同的數(shù)據(jù)也會產(chǎn)生不同的秘文，data pattern得以隱藏。第一個block沒有刻可以或處理的秘文，就傳入一個IV（初始化向量）。很明顯，IV不同，AES運算的結(jié)果也不同。

非對稱加密之RSA

對稱加密的安全性全系于加密密鑰的管理，在非對稱加密算法出現(xiàn)之前，如何動態(tài)的協(xié)商密鑰一直是個難題，大部分的應(yīng)用場景都是采用通信雙方通過其他手段預(yù)先交流密鑰的方式。一旦密鑰泄漏，就會導(dǎo)致嚴(yán)重的安全事故。直到1976年Diffie

Hellman算法出現(xiàn)解決了密鑰協(xié)商的問題，1977年RSA誕生同時提供了密鑰協(xié)商方案和電子簽名方案。

RSA的使用已經(jīng)相當(dāng)廣泛，也有很多優(yōu)秀的教程解釋其原理，推薦其中一篇。

關(guān)于RSA這種非對稱加密算法，在App的使用當(dāng)中，需要明白其主要作用有2個：

信息加密：通信雙方可以在公開的網(wǎng)絡(luò)環(huán)境下，“安全”的商量對稱加密算法所使用的密鑰。

電子簽名：為了防止中間人攻擊，通信雙方在商量密鑰之前可以通過簽名算法確認(rèn)對方的身份。

非對稱加密算法本身是一種加密算法，但由于RSA本身加解密的性能在現(xiàn)在的計算機(jī)硬件條件下存在一定瓶頸，同時對加密數(shù)據(jù)的“安全長度”也有限制，被加密數(shù)據(jù)的長度一般要求不超過公鑰的長度。所以RSA更多的是被用來商量一個密鑰，如果密鑰是安全的，那么后續(xù)的通信都可以使用上面提到的AES來完成，AES在性能上不存在瓶頸。

RSA算法最經(jīng)典也是最廣泛的應(yīng)用場景是HTTPS，HTTPS的安全握手流程完整的闡釋了“加密”和“簽名”這兩個概念。推薦一篇文章詳細(xì)的分析HTTPS的握手流程。

RSA有另一個競爭者ECC，ECC現(xiàn)在使用也越來越廣泛。二者在安全性上都不存在問題。不過ECC額外的優(yōu)勢，公鑰私鑰的生成速度快于RSA，在需要大量生產(chǎn)密鑰對的業(yè)務(wù)場景下ECC會是更好的選擇。ECC的最短安全公鑰也比RSA要短的多，224bits的ECC公鑰就已經(jīng)足夠安全，而同等級別的RSA公鑰需要長達(dá)2048bits。RSA由于實現(xiàn)簡單，出現(xiàn)較早，可以預(yù)見在很長一段時間內(nèi)都將和ECC共存。

App網(wǎng)絡(luò)應(yīng)用場景

現(xiàn)在絕大部分的App都在使用http和https，少部分會有自己的tcp長連接通道，更少部分的app搭配udp通道或者類似QUIC這種reliable

UDP協(xié)議來提升體驗。不管是什么協(xié)議，只要涉及客戶端和服務(wù)器的通信，就必然要實現(xiàn)類似https安全握手的流程，部分或者全部，開發(fā)者總是在性能和安全性之間取舍。有實力的大廠可以魚與熊掌兼得，初創(chuàng)型企業(yè)往往會避開性能優(yōu)化，直接跳過安全問題。

使用http，不做任何加密相當(dāng)于裸奔，初級工程師都可以輕易窺探你全部的業(yè)務(wù)數(shù)據(jù)。

使用http，但所有的流量都通過預(yù)埋在客戶端的key進(jìn)行AES加密，流量基本安全，不過一旦客戶端代碼被反編譯竊取key，又會回到裸奔狀態(tài)。

使用http，但AES使用的key通過客戶端以GUID的方式臨時生成，但為了保證key能安全的送達(dá)服務(wù)器，勢必要使用服務(wù)器的公鑰進(jìn)行加密，所以要預(yù)埋服務(wù)器證書，又涉及到證書過期更新機(jī)制。而且無法動態(tài)協(xié)商使用的對稱加密算法，安全性還是有暇疵。

所以要做到真正的安全，最后還是會回歸到https的流程上來，https在身份驗證，密鑰協(xié)商，解密算法選擇，證書更新等方面都已經(jīng)做了最合適的選擇。

對于App開發(fā)者來說，到底選擇什么樣的安全策略，是在全盤了解現(xiàn)有安全模型的前提下，在投入，產(chǎn)出，風(fēng)險三者之間去平衡而做出最優(yōu)的選擇。

App網(wǎng)絡(luò)安全實戰(zhàn)

在App安全上的投入再多也不會過，不過安全問題上所投入的開發(fā)資源應(yīng)該根據(jù)開發(fā)團(tuán)隊技術(shù)積累，產(chǎn)品發(fā)布deadline，用戶規(guī)模及產(chǎn)品關(guān)注度等綜合因素考量。結(jié)合這些因素我把App分為三類，各類App對安全級別的要求不同，投入產(chǎn)出也不同。

第一類，作坊式創(chuàng)業(yè)App

這些年伴隨著移動互聯(lián)網(wǎng)的創(chuàng)業(yè)潮，各式各樣的app出現(xiàn)在用戶的手機(jī)端。對于創(chuàng)業(yè)初期的團(tuán)隊來說，能把業(yè)務(wù)模型盡快實現(xiàn)上線當(dāng)然是重中之重。但很多創(chuàng)業(yè)團(tuán)隊在安全上的投入幾乎為零，所導(dǎo)致的安全問題比想象中的要嚴(yán)重。我見過不少使用http明文傳輸用戶名密碼的app，其中甚至包括一些知名傳統(tǒng)企業(yè)。其實只要照顧到一些基礎(chǔ)方面就能過濾掉大部分的安全漏洞了。這里提供一些小tip供創(chuàng)業(yè)初期團(tuán)隊參考：

Tip 1:盡量使用https

https可以過濾掉大部分的安全問題。https在證書申請，服務(wù)器配置，性能優(yōu)化，客戶端配置上都需要投入精力，所以缺乏安全意識的開發(fā)人員容易跳過https，或者拖到以后遇到問題再優(yōu)化。https除了性能優(yōu)化麻煩一些以外其他都比想象中的簡單，如果沒精力優(yōu)化性能，至少在注冊登錄模塊需要啟用https，這部分業(yè)務(wù)對性能要求比較低。

Tip 2:不要傳輸密碼

不知道現(xiàn)在還有多少app后臺是明文存儲密碼的。無論客戶端，server還是網(wǎng)絡(luò)傳輸都要避免明文密碼，要使用hash值?？蛻舳瞬灰鋈魏蚊艽a相關(guān)的存儲，hash值也不行。存儲token進(jìn)行下一次的認(rèn)證，而且token需要設(shè)置有效期，使用refresh

token去申請新的token。

Tip 3:Post并不比Get安全

事實上，Post和Get一樣不安全，都是明文。參數(shù)放在QueryString或者Body沒任何安全上的差別。在Http的環(huán)境下，使用Post或者Get都需要做加密和簽名處理。

Tip 4:不要使用301跳轉(zhuǎn)

301跳轉(zhuǎn)很容易被Http劫持攻擊。移動端http使用301比桌面端更危險，用戶看不到瀏覽器地址，無法察覺到被重定向到了其他地址。如果一定要使用，確保跳轉(zhuǎn)發(fā)生在https的環(huán)境下，而且https做了證書綁定校驗。

Tip 5:http請求都帶上MAC

所有客戶端發(fā)出的請求，無論是查詢還是寫操作，都帶上MAC（Message Authentication

Code）。MAC不但能保證請求沒有被篡改（Integrity），還能保證請求確實來自你的合法客戶端（Signing）。當(dāng)然前提是你客戶端的key沒有被泄漏，如何保證客戶端key的安全是另一個話題。MAC值的計算可以簡單的處理為hash（request

params＋key）。帶上MAC之后，服務(wù)器就可以過濾掉絕大部分的非法請求。MAC雖然帶有簽名的功能，和RSA證書的電子簽名方式卻不一樣，原因是MAC簽名和簽名驗證使用的是同一個key，而RSA是使用私鑰簽名，公鑰驗證，MAC的簽名并不具備法律效應(yīng)。

Tip 6:http請求使用臨時密鑰

高延遲的網(wǎng)絡(luò)環(huán)境下，不經(jīng)優(yōu)化https的體驗確實會明顯不如http。在不具備https條件或?qū)W(wǎng)絡(luò)性能要求較高且缺乏https優(yōu)化經(jīng)驗的場景下，http的流量也應(yīng)該使用AES進(jìn)行加密。AES的密鑰可以由客戶端來臨時生成，不過這個臨時的AES

key需要使用服務(wù)器的公鑰進(jìn)行加密，確保只有自己的服務(wù)器才能解開這個請求的信息，當(dāng)然服務(wù)器的response也需要使用同樣的AES

key進(jìn)行加密。由于http的應(yīng)用場景都是由客戶端發(fā)起，服務(wù)器響應(yīng)，所以這種由客戶端單方生成密鑰的方式可以一定程度上便捷的保證通信安全。

Tip 7:AES使用CBC模式

不要使用ECB模式，原因前面已經(jīng)分析過，記得設(shè)置初始化向量，每個block加密之前要和上個block的秘文進(jìn)行運算。

第二類，正規(guī)軍App

All Traffic HTTPS

全站使用HTTPS，而且是強(qiáng)制使用。baidu到今天（2016.04.13）還沒有強(qiáng)制使用HTTPS。所有的流量都應(yīng)該在HTTPS上產(chǎn)生，沒有人可以決定哪些流量是可以不用考慮安全問題的。如果自建長連接使用tcp，udp或者其他網(wǎng)絡(luò)協(xié)議，也應(yīng)該實現(xiàn)類似HTTPS的密鑰協(xié)商流程。

Certificate Pinning

RSA的簽名機(jī)制雖然看著安全，一旦出現(xiàn)上游證書頒發(fā)機(jī)構(gòu)私鑰泄漏，或者簽名流程發(fā)現(xiàn)漏洞等情況，中間人攻擊還是會導(dǎo)致數(shù)據(jù)被第三方破解甚至被釣魚。Certificate

Pinning是一種與服務(wù)器證書強(qiáng)綁定的機(jī)制，要么綁定證書本身，需要證書更新機(jī)制配合加強(qiáng)安全性，要么使用公鑰綁定，這樣更新證書的時候只要保證私鑰不變即可。現(xiàn)在流行的HTTP

framework，iOS端如AFNetworking，Android端如OKHttp都支持Certificate Pinning。

Perfect Forward Secrecy

很多人會覺得非對稱加密算法足夠安全，只要使用了RSA或者AES，加密過后的數(shù)據(jù)就認(rèn)為安全。但沒有絕對的安全，無論是RSA或者AES算法本身都有可能在未來某一天被破解，正如當(dāng)年的DES，甚至有傳言NSA正如當(dāng)年掌握了differential

cryptanalysis一樣，現(xiàn)在已經(jīng)獲取了某種方法來破解當(dāng)前互聯(lián)網(wǎng)當(dāng)中的部分網(wǎng)絡(luò)流量，至于到底是RSA還是AES就不得而知了。

未來計算機(jī)的計算能力是個未知數(shù)，或許某一天brute force能夠暴力破解的密鑰長度會遠(yuǎn)超128bits（現(xiàn)階段上限應(yīng)該在80bits）。

2014年1月3日，美國國家安全局（NSA）正在研發(fā)一款用于破解加密技術(shù)的量子計算機(jī)，希望破解幾乎所有類型的加密技術(shù)。

即使算法本身沒有被破解，密鑰也有可能被泄漏，技術(shù)上的原因或者政策上的因素都可能導(dǎo)致RSA或者ECC的私鑰被泄漏。所以盡可能針對不同的session使用不同的key能夠使的我們的數(shù)據(jù)更佳安全。

Forward

Secrecy就是為了避免某個私鑰的泄漏或者被破解而導(dǎo)致歷史數(shù)據(jù)一起泄漏?，F(xiàn)在google的https配置所使用的是TLS_ECDHE_RSA算法，每次對稱密鑰的協(xié)商都是使用ECC生成臨時的公鑰私鑰對（之前提到過ECC在快速生成密鑰對上有優(yōu)勢），身份驗證使用RSA算法進(jìn)行簽名。

每天跟蹤信息安全動態(tài)

安全的攻防戰(zhàn)不會有窮盡的一天，算法的更替會伴隨著人類對知識的無盡渴望延綿至不可預(yù)知的未來。AES說不定哪天被破解了，openSSL可能又出現(xiàn)新的漏洞了，google又提倡新的安全模型了，NSA的量子計算機(jī)說不準(zhǔn)已經(jīng)在悄悄解密google的流量了，每天跟蹤八卦最新業(yè)界動態(tài)才是碼農(nóng)避免因bug而背黑鍋的不二法寶。

第三類，帶節(jié)操正規(guī)軍App

現(xiàn)在互聯(lián)網(wǎng)早已滲入每個人的平常生活當(dāng)中，當(dāng)我們的行為越來越多的遷移到互聯(lián)網(wǎng)這個媒介當(dāng)中之后，行為本身及所產(chǎn)生的關(guān)聯(lián)數(shù)據(jù)都將被滴水不漏的記錄起來，特別是在大數(shù)據(jù)研究興起的當(dāng)下，服務(wù)提供商總是希望盡可能多的記錄用戶所有的行為數(shù)據(jù)。每個互聯(lián)網(wǎng)產(chǎn)品的使用者都成了樣本，你的購物記錄，商品瀏覽歷史，搜索引擎搜索記錄，打車記錄，租房記錄，股票記錄，甚至聊天記錄等等都是樣本，毫不夸張的說，如果將淘寶，微信，支付寶，快滴，美團(tuán)等等高頻次產(chǎn)品數(shù)據(jù)統(tǒng)一分析，基本上可以將你的身高，性別，年齡，三維，家庭住址，戀愛史，家庭成員，甚至是個人喜好，性格等等完美的呈現(xiàn)出來，其后果遠(yuǎn)不是一個騷擾電話帶來的隱私泄漏那么簡單。

移動互聯(lián)網(wǎng)的大部分使用者還不具備強(qiáng)烈的安全意識，當(dāng)你用手機(jī)號作為登錄id方便記憶的同時，騷擾電話就可能隨時來臨，你在百度輸入租房關(guān)鍵字，下一秒中介就已經(jīng)電話打上門。當(dāng)你允許app上傳通訊錄匹配可能認(rèn)識的好友同時，你認(rèn)識哪些人就變得一清二楚，你p2p借貸未及時歸還時，你的親朋好友第二天就收到了催債電話。我們在享受移動互聯(lián)網(wǎng)的便利同時，付出的是個人隱私這種隱形成本。下一次，當(dāng)我們感嘆新app好用便利的同時，靜思三分鐘，好好想想我們的哪些隱私又被當(dāng)白菜賣了。

在互聯(lián)網(wǎng)受眾的安全意識普遍覺醒之前，只能靠app開發(fā)商，服務(wù)提供商的節(jié)操來保證用戶信息隱私安全。

帶節(jié)操的App在打算記錄用戶行為或者數(shù)據(jù)之前會考慮下是不是真的有需要，用戶的確會有需要查詢歷史購買記錄，但有多少人會在意自己幾年前花幾個小時瀏覽了杜蕾斯的產(chǎn)品。

服務(wù)器作為數(shù)據(jù)存儲或者轉(zhuǎn)發(fā)的媒介是不是真的需要了解真實的數(shù)據(jù)為何？現(xiàn)在WhatsApp，Telegram都已經(jīng)支持端到端的加密聊天方式，服務(wù)器本身看到的都是秘文，只做秘文轉(zhuǎn)發(fā)處理，帶著這樣的節(jié)操設(shè)計產(chǎn)品，用戶才會覺得安全。

WhatsApp的端到端加密安全模型是怎么樣實現(xiàn)的呢？非常值得學(xué)習(xí)。

簡單來說是嚴(yán)格遵循forward secrecy。每個用戶在注冊成功之后會在服務(wù)器存一對永久的Identity

Key，一對臨時的Signed Pre Key（Signed Pre Key由Identity

Key簽名，每隔一段時間變化一次），n對臨時的One-Time Pre Key（每次建立session消耗一個）。

每次session開始建立的時候使用Identity Key，Signed Pre Key， One Time Key生成Master

Secret。Master Secret再通過HKDF算法生成對稱加密使用的Root Key，Chain Key，Message Key。

Forward Secrecy體現(xiàn)在每次sender發(fā)送的消息被ack后，都會交換新的臨時ECC Key對，并更新Root

Key，Chain Key，Message Key。這樣網(wǎng)絡(luò)中的流量即使被第三方緩存起來，而且某一天某個Key

Pair的私鑰被破解，也不會對之前的流量產(chǎn)生安全影響。ECC

Key對會隨著消息的發(fā)送不停的“Ratcheting”。這是屬于非對稱加密的Forward Secrecy。

在sender的消息被ack之前，也就是新的ECC Key對交換成功之前，Message Key也會通過HKDF算法不停的“Ratcheting”，確保每條消息所使用的對稱密鑰也不相同。這是屬于對稱加密的Forward Secrecy。

有興趣深入了解的同學(xué)可以自己google：WhatsApp Security WhitePaper。