七夕之夜,想和另外一半聊一些私密的話,如何保證聊天內容不被***窺探,看完此文,終於略知一二了。算法
1、初級階段:信息裸傳安全
特色:在網絡上傳遞明文;網絡
***定理一:網絡上傳遞的數據是不安全的,網絡屬於***公共場所,能被截取。ide
如何改進呢?很容易想到,先加密,再傳輸。優化
2、進階階段:傳輸密文人工智能
特色:加密
服務端和客戶端先約定好加密算法,加密密鑰;spa
客戶端,傳輸前用約定好的密鑰加密;設計
傳輸密文;3d
服務端,收到消息後用約定好的密鑰解密;
***定理二:
客戶端是不安全的,屬於***本地範疇,能被逆向工程。
任何客戶端與服務端提早約定好的算法與密鑰都是不安全的,那如何改進呢?不能固定密鑰,一個用戶一個密鑰。
3、中級階段:一人一密,服務端生成密鑰
特色:
客戶端和服務端提早約定好加密算法,在傳遞消息前,先協商密鑰;
客戶端,請求密鑰;
服務端,返回密鑰;
而後用協商密鑰加密消息,傳輸密文;
這麼傳輸安全麼?
答案是否認的。
根據***定理一,網上傳輸的內容是不安全的,因而乎,***能獲得加密key=X;
根據客定理二,客戶端和服務端提早約定的加密算法是不安全的,因而乎,***能獲得加密算法;
因而乎,***截取後續傳遞的密文,能夠用對應的算法和密鑰解密;
應該如何優化呢?
根本上,密鑰不能在網絡上直接傳輸。
4、再進階階段:一人一密,客戶端肯定密鑰,密鑰再也不傳輸
特色:
協商的密鑰無需在網絡傳輸;
使用「具有用戶特性的東西」做爲加密密鑰,例如:用戶密碼的散列值;
一人一密,每一個人的密鑰不一樣;
而後密鑰加密消息,傳輸密文;
服務端從db裏獲取這個「具有用戶特性的東西」,解密;
***定理三:用戶客戶端內存是安全的,屬於***遠端範疇,認爲是安全的。
畫外音:中了***,電腦被控制了另說。
使用「具有用戶特性的東西」做爲加密密鑰,一人一密,是安全的。但這仍不是最優方案。
5、高級階段:一次一密,密鑰協商
每次通訊前,都進行密鑰協商,一次一密。
密鑰協商過程,以下圖所述,須要隨機生成三次動態密鑰:
兩次非對稱加密密鑰(公鑰,私鑰);
一次對稱加密密鑰;此稱爲,安全信道創建的「三次握手」,安全信道創建以後,再進行密文發送。
密鑰交換的步驟爲:
(1) 服務端隨機生成公私鑰對(公鑰pk1,私鑰pk2),並將公鑰pk1傳給客戶端;
畫外音:此時***能截獲pk1。
(2) 客戶端隨機生成公私鑰對(公鑰pk11,私鑰pk22),並將公鑰pk11,經過pk1加密,傳給服務端,服務端收到密文,用私鑰pk2解密,獲得pk11;
畫外音:此時***能截獲密文,也知道是經過pk1加密的,但因爲***不知道私鑰pk2,是沒法解密的。
(3) 服務端隨機生成對稱加密密鑰key=X,用pk11加密,傳給客戶端,客戶端收到密文,用私鑰pk22解密,可到key=X;
畫外音:同理,***由密文沒法解密出key。
至此,安全信道創建完畢,後續通信用key=X加密,以保證信息的安全性。
6、總結
信息安全方案設計三大假設:
網絡上傳遞的數據是不安全的,能被截取;
用戶客戶端是不安全的,屬於***本地範疇,能被逆向工程;
客戶端內存是安全的,屬於***遠端範疇,能夠認爲是安全的;
對於信息安全傳輸的不一樣階段:
明文消息傳遞如同裸奔,不安全;
客戶端和服務端提早約定加密算法和密鑰,不安全;畫外音:好多公司都是這麼實現的=_=。
一人一密,服務端隨機生成密鑰,發送給客戶端,不安全;
一人一密,客戶端使用「具有用戶特性的東西」做爲加密密鑰,安全;
一次一密,三次握手創建安全信道,安全;
好了,這下能夠嘿嘿嘿了。
對了,不少公司說,咱們毫不存儲,毫不窺探用戶聊天記錄,你信不?
【本文爲51CTO專欄做者「58沈劍」原創稿件,轉載請聯繫原做者】
【編輯推薦】
【責任編輯:趙寧寧 TEL:(010)68476606】