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

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

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

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

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

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

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

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

對(duì)稱(chēng)加密算法，代表算法AES

非對(duì)稱(chēng)加密算法，代表算法RSA，ECC

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

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

怎么樣算安全？

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

對(duì)于A(yíng)來(lái)說(shuō)只要滿(mǎn)足三點(diǎn)就說(shuō)明收到“Message”是安全的：

Message有B的電子簽名，表明消息確實(shí)是來(lái)自B。

Message沒(méi)有被篡改過(guò)。

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

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

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

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

對(duì)稱(chēng)加密之AES

要深入了解像AES這種加密算法，對(duì)大部分初學(xué)的同學(xué)來(lái)說(shuō)可能有些費(fèi)時(shí)費(fèi)力，但對(duì)算法掌握可以是個(gè)循序漸進(jìn)的過(guò)程。簡(jiǎn)單來(lái)說(shuō)可以分為以下幾個(gè)階段：

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

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

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

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

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

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

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

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

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

Bauer形象更加高大光輝。

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

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

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

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

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

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

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

每一個(gè)block會(huì)依次經(jīng)過(guò)Confusion（條件一），Difussion（條件二），Mix

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

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

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

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

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

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

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

pattern，因?yàn)橄嗤脑臅?huì)產(chǎn)生相同的秘文，這對(duì)圖片文件來(lái)說(shuō)比較致命：

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

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

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

非對(duì)稱(chēng)加密之RSA

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

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

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

關(guān)于RSA這種非對(duì)稱(chēng)加密算法，在A(yíng)pp的使用當(dāng)中，需要明白其主要作用有2個(gè)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tip 1:盡量使用https

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

Tip 2:不要傳輸密碼

不知道現(xiàn)在還有多少app后臺(tái)是明文存儲(chǔ)密碼的。無(wú)論客戶(hù)端，server還是網(wǎng)絡(luò)傳輸都要避免明文密碼，要使用hash值?？蛻?hù)端不要做任何密碼相關(guān)的存儲(chǔ)，hash值也不行。存儲(chǔ)token進(jìn)行下一次的認(rèn)證，而且token需要設(shè)置有效期，使用refresh

token去申請(qǐng)新的token。

Tip 3:Post并不比Get安全

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

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

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

Tip 5:http請(qǐng)求都帶上MAC

所有客戶(hù)端發(fā)出的請(qǐng)求，無(wú)論是查詢(xún)還是寫(xiě)操作，都帶上MAC（Message Authentication

Code）。MAC不但能保證請(qǐng)求沒(méi)有被篡改（Integrity），還能保證請(qǐng)求確實(shí)來(lái)自你的合法客戶(hù)端（Signing）。當(dāng)然前提是你客戶(hù)端的key沒(méi)有被泄漏，如何保證客戶(hù)端key的安全是另一個(gè)話(huà)題。MAC值的計(jì)算可以簡(jiǎn)單的處理為hash（request

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

Tip 6:http請(qǐng)求使用臨時(shí)密鑰

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

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

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

Tip 7:AES使用CBC模式

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

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

All Traffic HTTPS

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

Certificate Pinning

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

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

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

Perfect Forward Secrecy

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

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

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

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

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

Forward

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

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

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

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

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

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

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

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

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

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

簡(jiǎn)單來(lái)說(shuō)是嚴(yán)格遵循forward secrecy。每個(gè)用戶(hù)在注冊(cè)成功之后會(huì)在服務(wù)器存一對(duì)永久的Identity

Key，一對(duì)臨時(shí)的Signed Pre Key（Signed Pre Key由Identity

Key簽名，每隔一段時(shí)間變化一次），n對(duì)臨時(shí)的One-Time Pre Key（每次建立session消耗一個(gè)）。

每次session開(kāi)始建立的時(shí)候使用Identity Key，Signed Pre Key， One Time Key生成Master

Secret。Master Secret再通過(guò)HKDF算法生成對(duì)稱(chēng)加密使用的Root Key，Chain Key，Message Key。

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

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

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

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

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

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