[TOC]
聲明
** 本篇文章只是記錄一些加密類型和常見算法，所用的并不是嚴謹的術語,而是使用日常用語以方便理解,當然都是參考各種資料后自己的理解,所以難免有理解偏差之處，歡迎指正。大神請繞路。不喜勿噴。 **
本篇文章將記錄總結常見的加密類型及其算法，并最終得出常用的安全通信的方式
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之后計算如下:
1) A生成一個隨機數x
B生成一個隨機數y
2) A計算g^x%p 記為M,將M傳輸給B
B計算g^y%p 記為N,將N傳輸給A
3) A計算N^x==(g^y%p)^x==g^xy%p 記為C1
B計算M^y==(g^x%p)^y==g^xy%p 記為C2
4) C1和C2就是秘鑰，并且C1==C2
4.2 特征
- 在整個過程中,只有p、g、M、N四個數字在互聯網上傳輸。
- 真正的秘鑰是雙方計算出來的，并不需要在互聯網上直接傳輸。
- 只憑借這四個數字來推算出真正的秘鑰幾乎是不可能的。
- 可以方便的更換秘鑰
5 非對稱加密算法
5.1 特征
- 非對稱加密,機密解密使用不同的秘鑰
- 秘鑰對兒
- 私鑰(s):很長的一段密碼,比如1024位、2048位或者更長
- 公鑰(p):利用一定的機制從公鑰中提取
- 用自己的私鑰加密的密文只能用與之配對的公鑰解密(簽名、身份驗證)
- 用對方的公鑰加密的密文只能用與之配對的私鑰解密(機密性)
5.2 身份認證
- 公鑰加密解密代價太高,所有很少直接用來解密傳輸數據的機密性
- 主要用途就是身份認證
此處以A向B發送數據為例:
此處暫且認為公鑰私鑰已經拿到并且可靠
1) A用自己的私鑰加密明文數據的特征碼,并傳輸消息體(明文數據+私鑰加密后的特征碼)
2) 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的公鑰解密該證書，并對比特征碼即可。
以下是來自百度百科對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 方式一
1) A和B拿到對方的公鑰
A的公鑰、私鑰分別記為:pa,sa
B的公鑰、私鑰分別記為:pb,sb
2) A和B通過IKE協議生成一個對稱秘鑰，記為m
3) A===>B發送信息
A將消息體用2中生成的對稱秘鑰m加密
消息體包括:
明文數據(plantext)
sa加密的plantext的特征碼
4) B解密數據
B用m解密整個消息體(m是通過IKE生成的,可以認為只有AB雙方知曉)
解密出錯===>消息不可信
正常解密===>繼續下面步驟
B用pa解密用sa加密的特征碼
解密出錯===>身份驗證失敗
正常解密===>繼續下面步驟
B重新生成特征碼并和解密后的特征碼對比
對比一致===>消息可靠(機密性、完整性、身份驗證都保證了)
不一致=====>消息發生了變化
雖然同時滿足了機密性、完整性和身份驗證三個安全因素。
但這個過程有點復雜了，還要借助于IKE協議，非對稱加密的代價也是很大。
7.2 方式二
此處還是以A向B發送信息為例:
1) A和B拿到對方的公鑰
A的公鑰、私鑰分別記為:pa,sa
B的公鑰、私鑰分別記為:pb,sb
2) A生成一個隨機串兒(m)作為對稱密鑰來機密明文數據
消息體包括:
用m加密的明文消息
用sa加密的特征碼
用pb加密的m
3) B解密消息
用sb解密得到對稱密鑰m
用m解密密文得到明文
重新計算特征碼并與用pa解密得到的特征碼對比
這個過程并不依賴于IKE協議生成對稱密鑰。
真正的對稱密鑰是加密后附加在消息體中的。
