Android網絡請求加密機制

密碼學的三大作用:加密(?Encryption)、認證(Authentication),鑒定(Identification)

加密:防止壞人獲取你的數據。?

鑒權:防止壞人假冒你的身份。

認證:防止壞人修改了你的數據而你卻并沒有發現。


Android網絡請求流程

1.URLEncode和URLDecoder作用:URLEncode就是將URL中特殊部分進行編碼。URLDecoder就是對特殊部分進行解碼。

為什么URL要encode原因呢?

url轉義其實也只是為了符合url的規范而已。因為在標準的url規范中中文和很多的字符是不允許出現在url中的。


2.Base64編碼

為什么要進行Base64編碼?

在計算機中任何數據都是按ascii碼存儲的,而ascii碼的128~255之間的值是不可見字符。而在網絡上交換數據時,比如說從A地傳到B地,往往要經過多個路由設備,由于不同的設備對字符的處理方式有一些不同,這樣那些不可見字符就有可能被處理錯誤,這是不利于傳輸的。所以就先把數據先做一個Base64編碼,統統變成可見字符,這樣出錯的可能性就大降低了。

應用場景:主要是對于二進制數據進行編碼,(文件、圖片、加密后的二進制數據)


3.消息認證算法

要確保加密的消息不是別人偽造的,需要提供一個消息認證碼(MAC,Message?authentication?code)。?

消息認證碼是帶密鑰的hash函數,基于密鑰和hash函數(單向散列函數)。

密鑰雙方事先約定,不能讓第三方知道。

消息發送者使用MAC算法計算出消息的MAC值,追加到消息后面一起發送給接收者。?

接收者收到消息后,用相同的MAC算法計算接收到消息MAC值,并與接收到的MAC值對比是否一樣。

消息認證碼的作用:檢查某段消息的完整性,以及作身份驗證。


mac.png

防止重放攻擊可以有 3 種方法:

序號

每條消息都增加一個遞增的序號,并且在計算 MAC 值的時候把序號也包含在消息中。這樣攻擊者如果不破解消息認證碼就無法計算出正確的 MAC 值。這個方法的弊端是每條消息都需要多記錄最后一個消息的序號。

時間戳

發送消息的時候包含當前時間,如果收到的時間與當前的不符,即便 MAC 值正確也認為是錯誤消息直接丟棄。這樣也可以防御重放攻擊。這個方法的弊端是,發送方和接收方的時鐘必須一致,考慮到消息的延遲,所以需要在時間上留下一定的緩沖余地。這個緩沖之間還是會造成重放攻擊的可趁之機。

nonce

在通信之前,接收者先向發送者發送一個一次性的隨機數 nonce。發送者在消息中包含這個 nonce 并計算 MAC 值。由于每次 nonce 都會變化,因此無法進行重放攻擊。這個方法的缺點會導致通信的數據量增加。


4.對稱加密算法

特點:加解密只有一個密鑰。優點:速度快、效率高。缺點:密鑰交換問題。算法:AES(256字節,主流)、DES(8字節,淘汰)。

密鑰交換問題如何解決,MAC同樣也有這個問題,可以使用非對稱加密傳輸,或者私下約定,密鑰管理中心。


5.非對稱加密

非對稱加密算法需要兩個密鑰:公開密鑰(publickey)和私有密鑰(privatekey)。公開密鑰與私有密鑰是一對,如果用公開密鑰對數據進行加密,只有用對應的私有密鑰才能解密;如果用私有密鑰對數據進行加密,那么只有用對應的公開密鑰才能解密(這個過程可以做數字簽名)非對稱加密主要使用的是RSA算法。

特點:公/私鑰機制。優點:只需要交換公鑰,安全。缺點:加解密速度慢,特別是解密。算法:RSA。應用:數字簽名。

數字簽名

簡單解釋:

A:將明文進行摘要運算后得到摘要(消息完整性),再將摘要用A的私鑰加密(身份認證),得到數字簽名,將密文和數字簽名一塊發給B。

B:收到A的消息后,先將密文用自己的私鑰解密,得到明文。將數字簽名用A的公鑰進行解密后,得到正確的摘要(解密成功說明A的身份被認證了)。

數字證書



6.Android端 AES+RSA結合實踐

基本流程

Android端

服務器端(server)分別生成自己的RSA密鑰對,并提供接口給Android客戶端獲取RSA公鑰(rsaPublicKey)

client生成AES密鑰(aesKey)

client使用自己的AES密鑰(aesKey)對轉換為json格式的請求明文數據(data)進行加密,得到加密后的請求數據encryptData

client提供server提供的接口獲取RSA公鑰(rsaPublicKey)

client使用獲取RSA公鑰(rsaPublicKey)對AES密鑰(aesKey)進行加密,得到encryptAesKey

client將encryptAesKey作為http請求頭參數,將加密后的請求數據encryptData作為請求體一起傳輸給服務器端

服務器端

server響應client的http請求,讀取http請求頭。獲得client傳過來的加密后的AES密鑰(encryptAesKey),讀取http請求體,獲得client傳過來的加密后的請求數據(encryptData)。

server使用自己的RSA私鑰(rsaPrivateKey)對加密后的AES密鑰(encryptAesKey)進行RSA解密,得到AES密鑰(aesKey)

使用解密后的AES密鑰(aesKey)對加密后的請求數據(encryptData),進行AES解密操作,得到解密后的請求數據(data),該數據為json格式

對解密后的請求數據(data)進行json解析,然后做相關的響應操作。

基本上如下圖所示的流程:


最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,197評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,415評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 176,104評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,884評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,647評論 6 408
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,130評論 1 323
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,208評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,366評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,887評論 1 334
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,737評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,939評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,478評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,174評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,586評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,827評論 1 283
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,608評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,914評論 2 372

推薦閱讀更多精彩內容