- 聲明
- 基本概念
- 1 中間人攻擊
- 2 機密性
- 3 完整性
- 4 身份驗證
- 5 抗抵賴性
- 6 怎麼樣才算安全的通信
- 單向加密
- 1 特征
- 2 常見算法
- 3 滿足哪些安全特性
- 對稱加密
- 1 特征
- 2 常見算法
- 3 滿足哪些安全特性
- IKE
- 1 秘鑰交換過程
- 2 特征
- 非對稱加密算法
- 1 特征
- 2 身份認證
- 3 常見算法
- 4 滿足哪些安全特性
- 5 引入的問題
- CACertification Authority
- 1 簡單介紹
- 2 PKI
- 3 引入的問題
- 如何安全通信呢
- 1 方式一
- 2 方式二
聲明
* 本篇文章隻是記錄一些加密類型和常見算法,所用的并不是嚴謹的術語,而是使用日常用語以友善了解,當然都是參考各種資料後自己的了解,是以難免有了解偏差之處,歡迎指正。大神請繞路。不喜勿噴。 *
本篇文章将記錄總結常見的加密類型及其算法,并最終得出常用的安全通信的方式
1 基本概念
這裡隻指出各個名稱的關鍵點,具體的名詞解釋就不談了……
1.1 中間人攻擊
中間人攻擊(Man-in-the-Middle Attack, MITM)就是通過攔截正常的網絡通信資料,并進行資料篡改和嗅探,而通信的雙方卻毫不知情。
1.2 機密性
機密性針對的是防止對資訊進行”未授權”的”讀”。
- 比如,傳輸的資訊即便被中間人竊取了,中間人拿到的資訊也是對他來說不可了解的密文。
- 另外,就算是中間人花時間能解密密文,隻是待他解密之後資訊早就沒有了當時的價值,這種情況也可以算作保證了機密性。
1.3 完整性
完整性要面對的是防止或者至少是檢測出”未授權”的”寫”(對資料的改變)。
比如:
- A對B發消息說下午兩點見面,結果中間人C截取了消息并篡改消息為下午四點見面。這時候可以認為違背了完整性。
1.4 身份驗證
簡言之就是确認消息發送方的身份是否真的是他所聲稱的身份。
比如:
- 常常聽說的釣魚網站,例如冒充某個銀行的頁面等你輸入賬戶密碼等,這種情況就算是違背了身份驗證。
1.5 抗抵賴性
本人認為抗抵賴性可以歸結到身份驗證中去。當然,隻是個人觀點了。
1.6 怎麼樣才算安全的通信???
一般而言,同時滿足了
機密性
(資訊不被洩露,或洩露後對别人來說并沒實際價值)、
完整性
(資訊不被非法篡改或被篡改後可以檢測到)和
身份驗證
(和自己通信的人确實就是我認為和我正在通信的人)。就可以認為是安全通信了。
此處将抗抵賴性歸結到身份驗證中。
下面就來看看常見的一些加密類型滿足哪些安全要素。
2 單向加密
2.1 特征
- 輸入一緻 ==> 特征碼一緻
- 特征碼一緻 ==> 輸入不一定一緻(碰撞)
- 雪崩效應
- 特征碼定長
- 不可逆(無法根據特征碼還原資料)
2.2 常見算法
- MD5(Message Digest algorithm 5):消息摘要算法
- SHA(Secure Hash Algorithm):安全雜湊演算法
- HMAC(Hash Message Authentication Code):散列消息驗證碼
- CRC(Cyclical Redundancy Check):循環備援碼校驗
2.3 滿足哪些安全特性?
機密性 | 完整性 | 身份驗證 |
---|---|---|
不滿足 | 滿足(特征碼不一緻可以檢測出資料被篡改過) | 不滿足 |
3 對稱加密
雙向加密是加密算法中最常用的,它将我們可以直接了解的明文資料加密為我們不可直接了解的密文資料,然後,在需要的時候,可以使用一定的算法将這些加密以後的密文解密為原來可以了解的明文。
3.1 特征
- 優點
- 加/解密速度快
- 密鑰管理簡單
- 适宜一對一的資訊加密傳輸
- 缺點
- 加密算法簡單
- 密鑰長度有限
- 加密強度不高
- 密鑰分發困難
- 不适宜一對多的加密資訊傳輸
3.2 常見算法
- DES(Data Encryption Standard):資料加密标準
- AES(Advanced Encryption Standard):進階加密标準
3.3 滿足哪些安全特性?
- 機密性:滿足
- 完整性:不滿足
- 對稱密鑰可能洩露或被破解
- 無法保證解密後的資料沒被修改過
- 身份驗證:不滿足
- 對稱密鑰可能洩露或被破解
- 無法保證能正常解密的資料不是中間人發的
4 IKE
Internet Key Exchange(IKE) 網際網路秘鑰交換。此處簡單提一下Diffie-Hellman-key-exchange。
http,ftp,smtp,telnet這些常見的協定本身并不直接支援加密傳輸資料。
4.1 秘鑰交換過程
此處假設A和B雙方要生成秘鑰,秘鑰交換的大緻過程如下:
雙方協商好一個大素數p和一個生成數g,p和g是真正在網際網路上傳輸的。雙方協商好p和g之後計算如下:
) A生成一個随機數x
B生成一個随機數y
) A計算g^x%p 記為M,将M傳輸給B
B計算g^y%p 記為N,将N傳輸給A
) A計算N^x==(g^y%p)^x==g^xy%p 記為C1
B計算M^y==(g^x%p)^y==g^xy%p 記為C2
) C1和C2就是秘鑰,并且C1==C2
4.2 特征
- 在整個過程中,隻有p、g、M、N四個數字在網際網路上傳輸。
- 真正的秘鑰是雙方計算出來的,并不需要在網際網路上直接傳輸。
- 隻憑借這四個數字來推算出真正的秘鑰幾乎是不可能的。
- 可以友善的更換秘鑰
5 非對稱加密算法
5.1 特征
- 非對稱加密,機密解密使用不同的秘鑰
- 秘鑰對兒
- 私鑰(s):很長的一段密碼,比如1024位、2048位或者更長
- 公鑰(p):利用一定的機制從公鑰中提取
- 用自己的私鑰加密的密文隻能用與之配對的公鑰解密(簽名、身份驗證)
- 用對方的公鑰加密的密文隻能用與之配對的私鑰解密(機密性)
5.2 身份認證
- 公鑰加密解密代價太高,所有很少直接用來解密傳輸資料的機密性
- 主要用途就是身份認證
此處以A向B發送資料為例:
此處暫且認為公鑰私鑰已經拿到并且可靠
) A用自己的私鑰加密明文資料的特征碼,并傳輸消息體(明文資料+私鑰加密後的特征碼)
) B用A的公鑰解密特征碼
解密出錯===>無法用A的公鑰解密===>消息不是由A發送的
解密成功
B重新計算特征碼并和解密之後的特征碼比較
一緻===>則認為資料沒被篡改并且是由A發送的
不一緻===>則認為資料是由A發送的,但是傳輸的明文資料被篡改過了
整個過程中:
- 中間人若是隻修改明文資料===>B計算的兩次特征碼不一緻
- 中間人若是修改了特征碼===>B無法用A的公鑰解密
5.3 常見算法
- RSA(設計者的名字命名-Ron Rivest, AdiShamir、Leonard Adleman)
- DSA(Digital Signature Algorithm):數字簽名
5.4 滿足哪些安全特性?
- 機密性:不滿足
- 資料是明文的
- 完整性:滿足
- 資訊被修改後無法通過對應的公鑰或私鑰解密
- 身份驗證:滿足
- 私鑰加密的資料隻能用對應的公鑰解密
5.5 引入的問題
- 公鑰、私鑰去哪裡擷取呢?
- 怎麼确定公鑰、私鑰的可靠性呢?
通信雙方找一個雙方都信可的機構,作為公正方。
這就類似于現實生活中的警察局頒發身份證,你認可警察局就得認可警察局發的身份證了。
這裡的公正方就是CA(Certification Authority)了。請看下文:
6 CA(Certification Authority)
6.1 簡單介紹
上面說了既然CA是通信雙方都信任的公正機構,那麼找CA驗證和自己通信的對方的證書的真僞就可以了。
CA将使用者的基本資訊和使用者公鑰生成特征碼并用CA自己的私鑰加密作為使用者的證書。另一個使用者想要辨識該證書真僞,隻需用CA的公鑰解密該證書,并對比特征碼即可。
![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsISN3UjMwUjM2ETNwETM2EDMy8CX0Vmbu4GZzNmLn9Gbi1yZtl2Lc9CX6MHc0RHaiojIsJye.jpg)
以下是來自百度百科對CA的描述:
- CA 也擁有一個證書(内含公鑰和私鑰)。任何都可以使用者通過驗證 CA 的簽字進而信任 CA ,任何人都可以得到 CA 的證書(含公鑰),用以驗證它所簽發的證書。
- 如果使用者想得到一份屬于自己的證書,他應先向 CA 提出申請。在 CA 稽核通過後,為申請者配置設定一個公鑰,并且 CA 将該公鑰與申請者的身份資訊綁在一起,并為之簽字後,便形成證書發給申請者。
- 如果一個使用者想鑒别另一個證書的真僞,可以用 CA 的公鑰對那個證書上的簽字進行驗證,一旦驗證通過,該證書就被認為是有效的。證書實際是由證書簽證機關(CA)簽發的對使用者的公鑰的認證。
- 證書的内容包括:電子簽證機關的資訊、公鑰使用者資訊、公鑰、權威機構的簽字和有效期等等。目前,證書的格式和驗證方法普遍遵循X.509 國際标準。
6.2 PKI
PKI(Public Key Infrastructure)—-公鑰基礎設施,其核心就是CA了。關于具體的嚴謹的術語定義請自行科普。
6.3 引入的問題
難題一:
- 去哪裡獲得CA自己的證書呢?
- 怎麼確定自己獲得的就是真正的CA的證書呢?
- 怎麼確定CA不是冒名頂替的?
感覺又跳坑裡了……
- 一般情況獲得證書都是通過網絡傳輸的
其實,到這一步就真的沒什麼能保證的了……
網際網路這麼大,計算機這麼多,誰知道和你網上談話的是人還是計算機呢?
不扯了……
如果你非要保證萬無一失,那麼CA當然也提供付費服務來盡力為你保證安全了:
- CA上門來把你的公鑰通過安全的存儲媒體複制到CA自己的伺服器上……
- 做成證書用安全的存儲媒體給你複制到你自己的伺服器上……
- ……
難題二:
自己辛辛苦苦搞到手的私鑰丢失怎麼辦,被人竊取怎麼辦?
- 可以借助于秘鑰管理工具
- 但是秘鑰管理工具被攻擊了呢?
-
一個标準的CA應該有CRL(證書吊銷清單)
………………………………
………………………………
這樣一層一層想下去……會瘋掉的………………
總之,還是有風險的……目前大概沒有什麼可以萬無一失的政策吧……
7 如何安全通信呢?
以上的加密類型并沒有一種同時滿足了機密性、完整性和身份驗證這三個安全特征的?
這麼多加密算法、加密類型。怎麼確定通信是“安全的”的呢?
以下所說都是基于CA以及CA自己的證書是可信的基礎之上的。還是以A和B通信為例:
7.1 方式一
) A和B拿到對方的公鑰
A的公鑰、私鑰分别記為:pa,sa
B的公鑰、私鑰分别記為:pb,sb
) A和B通過IKE協定生成一個對稱秘鑰,記為m
) A===>B發送資訊
A将消息體用中生成的對稱秘鑰m加密
消息體包括:
明文資料(plantext)
sa加密的plantext的特征碼
) B解密資料
B用m解密整個消息體(m是通過IKE生成的,可以認為隻有AB雙方知曉)
解密出錯===>消息不可信
正常解密===>繼續下面步驟
B用pa解密用sa加密的特征碼
解密出錯===>身份驗證失敗
正常解密===>繼續下面步驟
B重新生成特征碼并和解密後的特征碼對比
對比一緻===>消息可靠(機密性、完整性、身份驗證都保證了)
不一緻=====>消息發生了變化
雖然同時滿足了機密性、完整性和身份驗證三個安全因素。
但這個過程有點複雜了,還要借助于IKE協定,非對稱加密的代價也是很大。
7.2 方式二
此處還是以A向B發送資訊為例:
) A和B拿到對方的公鑰
A的公鑰、私鑰分别記為:pa,sa
B的公鑰、私鑰分别記為:pb,sb
) A生成一個随機串兒(m)作為對稱密鑰來機密明文資料
消息體包括:
用m加密的明文消息
用sa加密的特征碼
用pb加密的m
) B解密消息
用sb解密得到對稱密鑰m
用m解密密文得到明文
重新計算特征碼并與用pa解密得到的特征碼對比
這個過程并不依賴于IKE協定生成對稱密鑰。
真正的對稱密鑰是加密後附加在消息體中的。