七夕之夜,如何保證私密信息不泄露?
七夕之夜,想和另一半聊一些私密的話,如何保證聊天內容不被黑客窺探,看完此文,終于略知一二了。
一、初級階段:信息裸傳
特點:在網絡上傳遞明文;
黑客定理一:網絡上傳遞的數據是不安全的,網絡屬于黑客公共場所,能被截取。
如何改進呢?很容易想到,先加密,再傳輸。
二、進階階段:傳輸密文
特點:
- 服務端和客戶端先約定好加密算法,加密密鑰;
- 客戶端,傳輸前用約定好的密鑰加密;
- 傳輸密文;
- 服務端,收到消息后用約定好的密鑰解密;
黑客定理二:
客戶端是不安全的,屬于黑客本地范疇,能被逆向工程。
任何客戶端與服務端提前約定好的算法與密鑰都是不安全的,那如何改進呢?不能固定密鑰,一個用戶一個密鑰。
三、中級階段:一人一密,服務端生成密鑰
特點:
- 客戶端和服務端提前約定好加密算法,在傳遞消息前,先協商密鑰;
- 客戶端,請求密鑰;
- 服務端,返回密鑰;
- 然后用協商密鑰加密消息,傳輸密文;
這么傳輸安全么?
答案是否定的。
- 根據黑客定理一,網上傳輸的內容是不安全的,于是乎,黑客能得到加密key=X;
- 根據客定理二,客戶端和服務端提前約定的加密算法是不安全的,于是乎,黑客能得到加密算法;
- 于是乎,黑客截取后續傳遞的密文,可以用對應的算法和密鑰解密;
應該如何優化呢?
根本上,密鑰不能在網絡上直接傳輸。
四、再進階階段:一人一密,客戶端確定密鑰,密鑰不再傳輸
特點:
- 協商的密鑰無需在網絡傳輸;
- 使用“具備用戶特性的東西”作為加密密鑰,例如:用戶密碼的散列值;
- 一人一密,每個人的密鑰不同;
- 然后密鑰加密消息,傳輸密文;
- 服務端從db里獲取這個“具備用戶特性的東西”,解密;
黑客定理三:用戶客戶端內存是安全的,屬于黑客遠端范疇,認為是安全的。
畫外音:中了木馬,電腦被控制了另說。
使用“具備用戶特性的東西”作為加密密鑰,一人一密,是安全的。但這仍不是最優方案。
五、高級階段:一次一密,密鑰協商
每次通信前,都進行密鑰協商,一次一密。
密鑰協商過程,如下圖所述,需要隨機生成三次動態密鑰:
- 兩次非對稱加密密鑰(公鑰,私鑰);
- 一次對稱加密密鑰;此稱為,安全信道建立的“三次握手”,安全信道建立之后,再進行密文發送。
密鑰交換的步驟為:
(1) 服務端隨機生成公私鑰對(公鑰pk1,私鑰pk2),并將公鑰pk1傳給客戶端;
畫外音:此時黑客能截獲pk1。
(2) 客戶端隨機生成公私鑰對(公鑰pk11,私鑰pk22),并將公鑰pk11,通過pk1加密,傳給服務端,服務端收到密文,用私鑰pk2解密,得到pk11;
畫外音:此時黑客能截獲密文,也知道是通過pk1加密的,但由于黑客不知道私鑰pk2,是無法解密的。
(3) 服務端隨機生成對稱加密密鑰key=X,用pk11加密,傳給客戶端,客戶端收到密文,用私鑰pk22解密,可到key=X;
畫外音:同理,黑客由密文無法解密出key。
至此,安全信道建立完畢,后續通訊用key=X加密,以保證信息的安全性。
六、總結
信息安全方案設計三大假設:
- 網絡上傳遞的數據是不安全的,能被截取;
- 用戶客戶端是不安全的,屬于黑客本地范疇,能被逆向工程;
- 客戶端內存是安全的,屬于黑客遠端范疇,可以認為是安全的;
對于信息安全傳輸的不同階段:
- 明文消息傳遞如同裸奔,不安全;
- 客戶端和服務端提前約定加密算法和密鑰,不安全;畫外音:好多公司都是這么實現的=_=。
- 一人一密,服務端隨機生成密鑰,發送給客戶端,不安全;
- 一人一密,客戶端使用“具備用戶特性的東西”作為加密密鑰,安全;
- 一次一密,三次握手建立安全信道,安全;
好了,這下可以嘿嘿嘿了。
對了,很多公司說,我們絕不存儲,絕不窺探用戶聊天記錄,你信不?
【本文為51CTO專欄作者“58沈劍”原創稿件,轉載請聯系原作者】