App安全之網絡傳輸安全

移動端App安全若是按CS結構來劃分的話，主要涉及客戶端自己數據安全，Client到Server網絡傳輸的安全，客戶端自己安全又包括代碼安全和數據存儲安全。因此當咱們談論App安全問題的時候通常來講在如下三類範疇當中。

• App代碼安全，包括代碼混淆，加密或者app加殼。
• App數據存儲安全，主要指在磁盤作數據持久化的時候所作的加密。
• App網絡傳輸安全，指對數據從客戶端傳輸到Server中間過程的加密，防止網絡世界當中其餘節點對數據的竊聽。

這一篇咱們先聊下網絡傳輸的安全。

安全相關的基礎概念

網絡安全相關的概念很是之多，要在廣度和深度上都有所造詣很困難。但若是隻是站在保障App通訊基本安全這個維度上，作到合理使用安全算法，比大部分人所預期的都要簡單不少。如下這些基礎概念是必備知識：

• 對稱加密算法，表明算法AES
• 非對稱加密算法，表明算法RSA，ECC
• 電子簽名，用於確認消息發送方的身份
• 消息摘要生成算法，MD5，SHA，用於檢測消息是否被第三方修改過

怎麼樣算安全？

安全問題說白了是信任問題，談到信任必定要有一個可被信任的實體。假設某天A收到了一條「Message」，若是這個消息確實是來自B，消息就能夠被信任，那麼B就這安全問題當中可被信任的實體。

對於A來講只要知足三點就說明收到「Message」是安全的：

• Message有B的電子簽名，代表消息確實是來自B。
• Message沒有被篡改過。
• Message被某種加密算法加密過，只有A和B知道如何解密。

A和B的交談若是放到網絡世界當中，就是典型的Client－Server模式。和現實世界當中聊天不一樣的是，A和B所說的任何話均可以垂手可得的被其餘人聽到，隔牆隨處有耳。

怎麼去保證App網絡傳輸的安全？

爲了保證傳輸數據的安全，須要使用加密算法。在決定什麼樣的業務場景使用什麼樣的加密算法以前，先要了解咱們的工具箱裏有哪些可用工具。加密算法的工具箱裏其實就兩種工具：「對稱」加密算法和「非對稱」加密算法。清楚這兩個分類是合理設計加密算法使用場景的大前提，兩個分類裏咱們各挑選一個表明算法來研究，「對稱」加密挑選AES，「非對稱」加密選擇RSA。瞭解AES和RSA以後咱們再針對一些特定業務場景設計安全模型。

對稱加密之AES

要深刻了解像AES這種加密算法，對大部分初學的同窗來講可能有些費時費力，但對算法掌握能夠是個按部就班的過程。簡單來講能夠分爲如下幾個階段：

階段一：
在AES誕生以前（1975年以前），早起的加密算法十分簡單，是一種相似「暗號」的機制。通訊的雙方經過事先約定一種「加密機制」對明文進行處理，只要「加密機制」不被泄漏，信息就算安全。後來無數的經驗代表算法老是會被第三方得知，對算法自己進行保密管理也不方便。

階段二：
到上世紀70年代，公衆和政府意識到加密算法的重要性，由美國政府機構NBS牽頭組織業界專家設計了DES算法。DES算法自己公開，但算法的安全全依賴於一個密鑰。後來DES統治加密算法長達二十多年。不過DES從誕生到逐步退出歷史舞臺，一直都伴隨着陰謀的論調。DES本來是由IBM提出，針對已有算法Lucifer改造而成，但DES制定的過程一直都有美國另外一政府機構NSA的影子。

DES的兩大特色是短密鑰（short key）和結構複雜的s-box。有研究代表，是NSA當時勸說IMB短密鑰足夠安全，並且NSA也直接參與了s-box的設計。後來就一直有傳言說NSA彷佛有辦法能輕易破解DES加密後的祕文。

到1990年，劇情出現反轉。第三方獨立研究者Eli Biham和Adi Shamir發佈了破解塊加密方式的通用破解方法differential cryptanalysis。出人意料的是按照NSA建議設計的s-box對這種破解方法有更好的免疫性，NSA的參與彷佛更加提升了DES的安全性。

到1994年，劇情進一步昇華。公開文件披露，早在1974年IBM的研究者就已經發現了differential cryptanalysis這種破解方式，不過這項研究被NSA禁止公開，理由是會威脅到國家安全，對，就是如今美劇裏常常提到的national security。不只如此，NSA還針對DES作了一些改造增強安全性。至此，NSA已經全身都掛滿了節操，被業界質疑忍辱負重二十多年一聲沒吭，比24小時男主角Jack Bauer形象更加高大光輝。

階段三：
後來陸陸續續有一些針對DES破解的攻防戰，DES最終演化成Triple DES的形態，不過在性能上已經出現明顯問題，催生了今天對稱加密的王者算法AES。AES在安全性，實現難度，運算性能上都有更好的表現。在全面瞭解AES以前，首先明確下好的加密算法必須符合哪些條件，這些條件是通過數十年加密破解攻防戰所總結出來的。

• 條件一，Confusion。對原文以最小的粒度(按字節)進行混淆生成祕文。最簡單的confusion能夠是A+3=D.
• 條件二，Deffusion。對原文所包含的位置信息進行打亂排布,好比將第一個字節與第四個字節的位置對換.
• 條件三，Secret Key。最終的祕文與Secret Key相關，只要持有Secret Key就能夠對數據解密，將安全性的管理歸於一個密鑰的管理。

AES也是屬於Cipher Block的一種，對於數據的加密都是已block爲單位進行處理。針對須要加密的數據AES會先把數據分紅一個個的block，每一個block爲16字節，能夠排布成4×4的表格（又名矩陣）。以下圖所示：

若是最後一塊不足16字節，用0補齊（padding）。後續的加密行爲都是以block爲單位進行處理，這個處理過程必須知足上述所說三個條件。加密的流程以下圖：

每個block都會被單獨依次處理，橙色方框表示加密的過程，這個過程包括兩個方面，一方面是block自己數據的運算處理，二是與round key（也就是咱們所說的對稱加密算法密鑰）進行運算處理。流程示意圖以下：

每個block會依次通過Confusion（條件一），Difussion（條件二），Mix Data（能夠看做再一次的Confusion）。最後一步是和咱們的round key進行位運算獲得最後的block祕文，這樣一個完整的來回稱爲一個round，重複10次round就完成了block加密，固然每一個round當中所使用的round key也會發生變化，以保證每次block加密所使用的key都不一樣。

針對每一個block都重複上述處理過程就完成了AES加密過程，是否是so easy。固然這是被我高度抽象簡化後的流程示意圖，當中每一步都有不少的細節能夠深刻。密鑰越長，每一個block處理的round次數越多，AES就越安全，不過安全性和計算性能不可兼得，通常來講，咱們使用128bit的Key就能夠保證算法的安全性了。對了，解密的過程就是把上面加密的過程反過來作一遍。。

階段四：
明白了AES的流程，還須要瞭解正確的使用姿式。AES有兩個經典的使用姿式，ECB模式和CBC模式。ECB模式能夠用下圖表示：

ECB模式很簡單，就是針對每個block單獨進行AES運算，每一個block的處理結果之間沒有任何關係。使用這種方式單個block都是安全的，但對包含大量block的數據來講，沒有可以隱藏data pattern，由於相同的原文會產生相同的祕文，這對圖片文件來講比較致命：

相同的色塊產生相同的祕文，這樣相同顏色在圖片當中出現的規律就和原始數據同樣一目瞭然。

CBC模式針對ECB模式的缺陷作了處理，使得每一個block的AES運算結果都依賴於以前的block祕文。以下圖所示：

每個block在加密以前都會與上個block產生的祕文進行抑或運算，這樣相同的數據也會產生不一樣的祕文，data pattern得以隱藏。第一個block沒有刻能夠或處理的祕文，就傳入一個IV（初始化向量）。很明顯，IV不一樣，AES運算的結果也不一樣。

非對稱加密之RSA

對稱加密的安全性全繫於加密密鑰的管理，在非對稱加密算法出現以前，如何動態的協商密鑰一直是個難題，大部分的應用場景都是採用通訊雙方經過其餘手段預先交流密鑰的方式。一旦密鑰泄漏，就會致使嚴重的安全事故。直到1976年Diffie Hellman算法出現解決了密鑰協商的問題，1977年RSA誕生同時提供了密鑰協商方案和電子簽名方案。

RSA的使用已經至關普遍，也有不少優秀的教程解釋其原理，推薦其中一篇。

關於RSA這種非對稱加密算法，在App的使用當中，須要明白其主要做用有2個：

• 信息加密：通訊雙方能夠在公開的網絡環境下，「安全」的商量對稱加密算法所使用的密鑰。
• 電子簽名：爲了防止中間人攻擊，通訊雙方在商量密鑰以前能夠經過簽名算法確認對方的身份。

非對稱加密算法自己是一種加密算法，但因爲RSA自己加解密的性能在如今的計算機硬件條件下存在必定瓶頸，同時對加密數據的「安全長度」也有限制，被加密數據的長度通常要求不超過公鑰的長度。因此RSA更多的是被用來商量一個密鑰，若是密鑰是安全的，那麼後續的通訊均可以使用上面提到的AES來完成，AES在性能上不存在瓶頸。

RSA算法最經典也是最普遍的應用場景是HTTPS，HTTPS的安全握手流程完整的闡釋了「加密」和「簽名」這兩個概念。推薦一篇文章詳細的分析HTTPS的握手流程。

RSA有另外一個競爭者ECC，ECC如今使用也愈來愈普遍。兩者在安全性上都不存在問題。不過ECC額外的優點，公鑰私鑰的生成速度快於RSA，在須要大量生產密鑰對的業務場景下ECC會是更好的選擇。ECC的最短安全公鑰也比RSA要短的多，224bits的ECC公鑰就已經足夠安全，而同等級別的RSA公鑰須要長達2048bits。RSA因爲實現簡單，出現較早，能夠預見在很長一段時間內都將和ECC共存。

App網絡應用場景

如今絕大部分的App都在使用http和https，少部分會有本身的tcp長鏈接通道，更少部分的app搭配udp通道或者相似QUIC這種reliable UDP協議來提高體驗。無論是什麼協議，只要涉及客戶端和服務器的通訊，就必然要實現相似https安全握手的流程，部分或者所有，開發者老是在性能和安全性之間取捨。有實力的大廠能夠魚與熊掌兼得，初創型企業每每會避開性能優化，直接跳過安全問題。

使用http，不作任何加密至關於裸奔，初級工程師均可以輕易窺探你所有的業務數據。

使用http，但全部的流量都經過預埋在客戶端的key進行AES加密，流量基本安全，不過一旦客戶端代碼被反編譯竊取key，又會回到裸奔狀態。

使用http，但AES使用的key經過客戶端以GUID的方式臨時生成，但爲了保證key能安全的送達服務器，勢必要使用服務器的公鑰進行加密，因此要預埋服務器證書，又涉及到證書過時更新機制。並且沒法動態協商使用的對稱加密算法，安全性仍是有暇疵。

因此要作到真正的安全，最後仍是會迴歸到https的流程上來，https在身份驗證，密鑰協商，解密算法選擇，證書更新等方面都已經作了最合適的選擇。

對於App開發者來講，到底選擇什麼樣的安全策略，是在全盤瞭解現有安全模型的前提下，在投入，產出，風險三者之間去平衡而作出最優的選擇。

App網絡安全實戰

在App安全上的投入再多也不會過，不過安全問題上所投入的開發資源應該根據開發團隊技術積累，產品發佈deadline，用戶規模及產品關注度等綜合因素考量。結合這些因素我把App分爲三類，各種App對安全級別的要求不一樣，投入產出也不一樣。

第一類，做坊式創業App

這些年伴隨着移動互聯網的創業潮，各式各樣的app出如今用戶的手機端。對於創業初期的團隊來講，能把業務模型儘快實現上線固然是重中之重。但不少創業團隊在安全上的投入幾乎爲零，所致使的安全問題比想象中的要嚴重。我見過很多使用http明文傳輸用戶名密碼的app，其中甚至包括一些知名傳統企業。其實只要照顧到一些基礎方面就能過濾掉大部分的安全漏洞了。這裏提供一些小tip供創業初期團隊參考：

Tip 1:儘可能使用https

https能夠過濾掉大部分的安全問題。https在證書申請，服務器配置，性能優化，客戶端配置上都須要投入精力，因此缺少安全意識的開發人員容易跳過https，或者拖到之後遇到問題再優化。https除了性能優化麻煩一些之外其餘都比想象中的簡單，若是沒精力優化性能，至少在註冊登陸模塊須要啓用https，這部分業務對性能要求比較低。

Tip 2:不要傳輸密碼

不知道如今還有多少app後臺是明文存儲密碼的。不管客戶端，server仍是網絡傳輸都要避免明文密碼，要使用hash值。客戶端不要作任何密碼相關的存儲，hash值也不行。存儲token進行下一次的認證，並且token須要設置有效期，使用refresh token去申請新的token。

Tip 3:Post並不比Get安全

事實上，Post和Get同樣不安全，都是明文。參數放在QueryString或者Body沒任何安全上的差異。在Http的環境下，使用Post或者Get都須要作加密和簽名處理。

Tip 4:不要使用301跳轉

301跳轉很容易被Http劫持攻擊。移動端http使用301比桌面端更危險，用戶看不到瀏覽器地址，沒法察覺到被重定向到了其餘地址。若是必定要使用，確保跳轉發生在https的環境下，並且https作了證書綁定校驗。

Tip 5:http請求都帶上MAC

全部客戶端發出的請求，不管是查詢仍是寫操做，都帶上MAC（Message Authentication Code）。MAC不但能保證請求沒有被篡改（Integrity），還能保證請求確實來自你的合法客戶端（Signing）。固然前提是你客戶端的key沒有被泄漏，如何保證客戶端key的安全是另外一個話題。MAC值的計算能夠簡單的處理爲hash（request params＋key）。帶上MAC以後，服務器就能夠過濾掉絕大部分的非法請求。MAC雖然帶有簽名的功能，和RSA證書的電子簽名方式卻不同，緣由是MAC簽名和簽名驗證使用的是同一個key，而RSA是使用私鑰簽名，公鑰驗證，MAC的簽名並不具有法律效應。

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

高延遲的網絡環境下，不經優化https的體驗確實會明顯不如http。在不具有https條件或對網絡性能要求較高且缺少https優化經驗的場景下，http的流量也應該使用AES進行加密。AES的密鑰能夠由客戶端來臨時生成，不過這個臨時的AES key須要使用服務器的公鑰進行加密，確保只有本身的服務器才能解開這個請求的信息，固然服務器的response也須要使用一樣的AES key進行加密。因爲http的應用場景都是由客戶端發起，服務器響應，因此這種由客戶端單方生成密鑰的方式能夠必定程度上便捷的保證通訊安全。

Tip 7:AES使用CBC模式

不要使用ECB模式，緣由前面已經分析過，記得設置初始化向量，每一個block加密以前要和上個block的祕文進行運算。

第二類，正規軍App

All Traffic HTTPS

全站使用HTTPS，並且是強制使用。baidu到今天（2016.04.13）尚未強制使用HTTPS。全部的流量都應該在HTTPS上產生，沒有人能夠決定哪些流量是能夠不用考慮安全問題的。若是自建長鏈接使用tcp，udp或者其餘網絡協議，也應該實現相似HTTPS的密鑰協商流程。

Certificate Pinning

RSA的簽名機制雖然看着安全，一旦出現上游證書頒發機構私鑰泄漏，或者簽名流程發現漏洞等狀況，中間人攻擊仍是會致使數據被第三方破解甚至被釣魚。Certificate Pinning是一種與服務器證書強綁定的機制，要麼綁定證書自己，須要證書更新機制配合增強安全性，要麼使用私鑰綁定，這樣更新證書的時候只要保證私鑰不變便可。如今流行的HTTP framework，iOS端如AFNetworking，Android端如OKHttp都支持Certificate Pinning。

Perfect Forward Secrecy

不少人會以爲非對稱加密算法足夠安全，只要使用了RSA或者AES，加密事後的數據就認爲安全。但沒有絕對的安全，不管是RSA或者AES算法自己都有可能在將來某一天被破解，正如當年的DES，甚至有傳言NSA正如當年掌握了differential cryptanalysis同樣，如今已經獲取了某種方法來破解當前互聯網當中的部分網絡流量，至於究竟是RSA仍是AES就不得而知了。

將來計算機的計算能力是個未知數，或許某一天brute force可以暴力破解的密鑰長度會遠超128bits（現階段上限應該在80bits）。

2014年1月3日，美國國家安全局（NSA）正在研發一款用於破解加密技術的量子計算機，但願破解幾乎全部類型的加密技術。

即便算法自己沒有被破解，密鑰也有可能被泄漏，技術上的緣由或者政策上的因素均可能致使RSA或者ECC的私鑰被泄漏。因此儘量針對不一樣的session使用不一樣的key可以使的咱們的數據更佳安全。

Forward Secrecy就是爲了不某個私鑰的泄漏或者被破解而致使歷史數據一塊兒泄漏。如今google的https配置所使用的是TLS_ECDHE_RSA算法，每次對稱密鑰的協商都是使用ECC生成臨時的公鑰私鑰對（以前提到過ECC在快速生成密鑰對上有優點），身份驗證使用RSA算法進行簽名。

天天跟蹤信息安全動態

安全的攻防戰不會有窮盡的一天，算法的更替會伴隨着人類對知識的無盡渴望延綿至不可預知的將來。AES說不定哪天被破解了，openSSL可能又出現新的漏洞了，google又提倡新的安全模型了，NSA的量子計算機說不許已經在悄悄解密google的流量了，天天跟蹤八卦最新業界動態纔是碼農避免因bug而背黑鍋的不二法寶。

第三類，帶節操正規軍App

如今互聯網早已滲入每一個人的日常生活當中，當咱們的行爲愈來愈多的遷移到互聯網這個媒介當中以後，行爲自己及所產生的關聯數據都將被滴水不漏的記錄起來，特別是在大數據研究興起的當下，服務提供商老是但願儘量多的記錄用戶全部的行爲數據。每一個互聯網產品的使用者都成了樣本，你的購物記錄，商品瀏覽歷史，搜索引擎搜索記錄，打車記錄，租房記錄，股票記錄，甚至聊天記錄等等都是樣本，絕不誇張的說，若是將淘寶，微信，支付寶，快滴，美團等等高頻次產品數據統一分析，基本上能夠將你的身高，性別，年齡，三維，家庭住址，戀愛史，家庭成員，甚至是我的喜愛，性格等等完美的呈現出來，其後果遠不是一個騷擾電話帶來的隱私泄漏那麼簡單。

移動互聯網的大部分使用者還不具有強烈的安全意識，當你用手機號做爲登陸id方便記憶的同時，騷擾電話就可能隨時來臨，你在百度輸入租房關鍵字，下一秒中介就已經電話打上門。當你容許app上傳通信錄匹配可能認識的好友同時，你認識哪些人就變得一清二楚，你p2p借貸未及時歸還時，你的親朋好友次日就收到了催債電話。咱們在享受移動互聯網的便利同時，付出的是我的隱私這種隱造成本。下一次，當咱們感嘆新app好用便利的同時，靜思三分鐘，好好想一想咱們的哪些隱私又被當白菜賣了。

在互聯網受衆的安全意識廣泛覺醒以前，只能靠app開發商，服務提供商的節操來保證用戶信息隱私安全。

帶節操的App在打算記錄用戶行爲或者數據以前會考慮下是否是真的有須要，用戶的確會有須要查詢歷史購買記錄，但有多少人會在乎本身幾年前花幾個小時瀏覽了杜蕾斯的產品。

服務器做爲數據存儲或者轉發的媒介是否是真的須要瞭解真實的數據爲什麼？如今WhatsApp，Telegram都已經支持端到端的加密聊天方式，服務器自己看到的都是祕文，只作祕文轉發處理，帶着這樣的節操設計產品，用戶纔會以爲安全。

WhatsApp的端到端加密安全模型是怎麼樣實現的呢？很是值得學習。

簡單來講是嚴格遵循forward secrecy。每一個用戶在註冊成功以後會在服務器存一對永久的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體如今每次sender發送的消息被ack後，都會交換新的臨時ECC Key對，並更新Root Key，Chain Key，Message Key。這樣網絡中的流量即便被第三方緩存起來，並且某一天某個Key Pair的私鑰被破解，也不會對以前的流量產生安全影響。ECC Key對會隨着消息的發送不停的「Ratcheting」。這是屬於非對稱加密的Forward Secrecy。

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

有興趣深刻了解的同窗能夠本身google：WhatsApp Security WhitePaper。