從"嘿,今晚..."談消息安全傳輸中的技術點
和女/男票聊了一些私密的話,成天擔心消息會不會被泄漏,始終不放心,看完此文,消息傳輸安全性的來龍去脈,終于略知一二了。
一、初級階段:信息裸傳
特點:在網絡上傳遞明文
黑客定理一:網絡上傳遞的數(shù)據(jù)是不安全的,屬網絡于黑客公共場所,能被截取
結果:傳遞明文無異于不穿衣服裸奔
改進方案:先加密,再在網絡上傳輸
二、進階階段:傳輸密文
特點:
- 服務端和客戶端先約定好加密算法,加密密鑰
- 客戶端,傳輸前用約定好的密鑰加密
- 傳輸密文
- 服務端,收到消息后用約定好的密鑰解密
這么傳輸消息安全么?
黑客定理二:客戶端的代碼是不安全的,屬于黑客本地范疇,能被逆向工程,任何客戶端與服務端提前約定好的算法與密鑰都是不安全的
結果:任何客戶端的代碼混淆,二進制化都只能提高黑客的破解門檻,本質是不安全的
改進方案:不能固定密鑰
三、中級階段:服務端為每個用戶生成密鑰
特點:
- 客戶端和服務端提前約定好加密算法,在傳遞消息前,先協(xié)商密鑰
- 客戶端,請求密鑰
- 服務端,返回密鑰
- 然后用協(xié)商密鑰加密消息,傳輸密文
這么傳輸安全么?
結果:
- 如黑客定理一,網上傳輸?shù)膬热菔遣话踩模谑呛?,黑客能得到加密key=X
- 如黑客定理二,客戶端和服務端提前約定的加密算法是不安全的,于是乎,黑客能得到加密算法
- 于是乎,黑客截取后續(xù)傳遞的密文,可以用對應的算法和密鑰解密
改進方案:協(xié)商的密鑰不能在網絡上傳遞
四、再進階階段:客戶端確定密鑰,密鑰不再傳輸
特點:
- 協(xié)商的密鑰無需在網絡傳輸
- 使用“具備用戶特性的東西”作為加密密鑰,例如:用戶密碼的散列值
- 一人一密,每個人的密鑰不同
- 然后密鑰加密消息,傳輸密文
- 服務端從db里獲取這個“具備用戶特性的東西”,解密
這么傳輸安全么?
黑客定理三:用戶客戶端內存是安全的,屬于黑客遠端范疇,不能被破解
當然,用戶中了木馬,用戶的機器被控制的情況不在此列,如果機器真被控制,監(jiān)控用戶屏幕就好了,就不用搞得這么麻煩了
結果:使用“具備用戶特性的東西”作為加密密鑰,一人一密,是安全的。只是,當“具備用戶特性的東西”泄漏,就有潛在風險
五、高級階段:一次一密,密鑰協(xié)商
特點:每次通信前,進行密鑰協(xié)商,一次一密
密鑰協(xié)商過程,如下圖所述,需要隨機生成三次密鑰,兩次非對稱加密密鑰(公鑰,私鑰),一次對稱加密密鑰,簡稱安全信道建立的“三次握手”,在客戶端發(fā)起安全信道建立請求后:
- 服務端隨機生成公私鑰對(公鑰pk1,私鑰pk2),并將公鑰pk1傳給客戶端 (注意:此時黑客能截獲pk1)
- 客戶端隨機生成公私鑰對(公鑰pk11,私鑰pk22),并將公鑰pk22,通過pk1加密,傳給服務端,(注意:此時黑客能截獲密文,也知道是通過pk1加密的,但由于黑客不知道私鑰pk2,是無法解密的)服務端收到密文,用私鑰pk2解密,得到pk11
- 服務端隨機生成對稱加密密鑰key=X,用pk11加密,傳給客戶端 (注意:同理,黑客由密文無法解密出key),客戶端收到密文,用私鑰pk22解密,可到key=X
至此,安全信道建立完畢,后續(xù)通訊用key=X加密,以保證信息的安全性
六、總結
- 黑客定理一:網絡上傳遞的數(shù)據(jù)是不安全的,屬于黑客公共場所,能被截取
- 黑客定理二:客戶端的代碼是不安全的,屬于黑客本地范疇,能被逆向工程,任何客戶端與服務端提前約定好的算法與密鑰都是不安全的
- 黑客定理三:用戶客戶端內存是安全的,屬于黑客遠端范疇,不能被破解
對于不同加密方法明:
- 明文消息傳遞如同裸奔,不安全
- 客戶端和服務端提前約定加密算法和密鑰,不安全(好多公司都是這么實現(xiàn)的=_=)
- 服務端隨機生成密鑰,發(fā)送給客戶端,不安全
- 一人一密,客戶端使用“具備用戶特性的東西”作為加密密鑰,弱安全
- 一次一密,三次握手建立安全信道,安全
好了,這下明白了,可以放心的和女/男票發(fā)送“啪啪啪”“咻咻咻”“嘿嘿嘿”了
只要即時通訊公司有良知,不從服務端偷看,一切都是安全的。額,這個“只要”的假設,貌似不成立。
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件,轉載請聯(lián)系原作者】