TCP/IP數據加密傳輸及CA簡述

TCP/IP跨主機之間的通訊數據封裝發送的都是明文數據，現代通信中會有安全問題。

三個安全問題

如：A發送消息給B的三個安全問題
機密性：明文傳輸如：ftp,http,smtp,telnet等
完整性：數據可能被篡改（舉例:電商下單生產數量或者傳輸過程信號錯亂）
身份驗證：A和B從未見過（舉例:釣魚網站冒名頂替，保證對方便是其所聲稱的身份）

解決上述三個問題能夠經過加密算法的混合使用，常見加密算法有以下

對稱加密
DES：數據加密標準，早期使用的56bit密鑰
3DES：Triple DES 對每一個數據塊應用三次DES加密
AES：高級加密標準128bit默認，還有AES19二、AES25六、AES512

單向加密
MD5
SHA1 輸出長度爲160
SHA192/SHA256/SHA384 輸出長度

公鑰加密：核心功能是數據加密和簽名
RSA：實現加密和簽名，部分公開使用
DSA：只實現簽名，公開使用
數字簽名是什麼？

三個問題的解決

機密性假如傳輸數據abc，爲了避免讓互聯網上的其餘人獲取，就要加密，那麼如何加密呢？加密就是轉換規則，把明文轉換成密文，plaintext-->轉換規則-->ciphertext。

若是其餘人得到了轉換規則（算法）怎麼辦？一般更換的是祕鑰而不是算法，設計思想是靠祕鑰保證機密性而非算法，換祕鑰更簡單

加密算法--對稱加密：用於加密任意大小的數據塊數據內容，加密方和解密方使用的是同一個密碼，加密速度快。如：A要與BCDEF…通訊，各方不一樣密鑰，密鑰管理複雜。缺點：通訊對象多的時候，沒法有效對密鑰管理。

                      ↓↓

完整性如何保證數據不被篡改？加密算法—單向加密：抽取數據的特徵碼。把特徵碼附加在原文以後一併發送。

單向加密特性：
輸入同樣，輸出必然同樣；
雪崩效應，輸入的微小改變，將會引發結果的巨大改變；
不管原始數據是多少，結果大小都是相同的；
不可逆，沒法根據特徵碼還原原來的數據

中間人攻擊：修改數據和特徵碼從新發送。因此數據完整性的手段沒法保證完整性自己，要藉助其餘機制——加密特徵碼。特徵碼可以使用對稱加密，但是在兩我的第一次通訊時，因爲互相都不知道對方的密鑰，在網絡上傳輸密鑰時是明文傳輸的，密鑰安全性不能獲得保證。

如何實現雙方協商密鑰，可是卻不讓第三方獲得密鑰？——密鑰交換
最先的Diffie-Hellman IKE（Internet Key Exchange）互聯網密鑰交換
①A、B各自選擇兩個數字p,g(大素數，生成數)
②A、B各自生成本身的隨機數x,y
③A:g^x%p—>B    B:g^y%—>A   把計算結果發給對方
④A:(g^y%p)^x=g^yx%p(結果就是密鑰) B:(g^x%p)^y=g^xy%p
經過這種方式，雙方只知道本身的x,y，可是通過計算能夠在未知對方x或y的狀況下獲得相同的一個數值（g^xy%p）

                      ↓↓

密鑰交換後能夠加密特徵碼，但是仍是沒有解決問題，仍然沒法驗證對方身份

如何驗證對方身份？催生第三種加密算法產生--公鑰加密算法

公鑰加密（非對稱加密）加密和解密使用的是不一樣的密碼，有公鑰和私鑰，密鑰是成對出現的，公鑰是從私鑰中提早出來的，私鑰是很長的，私鑰加密速度比較慢。公鑰是公開的，公鑰加密須要用私鑰解密，用私鑰加密得用公鑰解密。

用對方公鑰加密數據，能夠保證機密性。發送方用本身私鑰加密，能夠實現身份驗證

公鑰加密算法速度太慢，不適用於加密數據，慢於對稱加密三個數量級，用於身份驗證

結合兩種加密（保證完整性+身份驗證）

使用私鑰加密特徵碼，中間人能解密能夠修改數據，可是接收方能夠發覺。這一切的保證就是公鑰，那麼從哪裏得到公鑰？

                      ↓↓

如何保證不是中間人的公鑰，只能藉助於第三方機構。

這裏最重要的一步就是公鑰的獲取，如何獲得對方的公鑰，又如何得知必定是對方的公鑰？

此時就須要依賴於CA，每一個人所發的公鑰對方沒法驗證其真假，就像你說本身是xx，那怎麼證實你就是xx呢？生活中咱們都是經過身份證來驗證的，可是身份證不能你本身作一張印上一個名字，就說本身叫xx，須要提供一張由公安部門所頒發的權威的身份證才能獲得承認，由於你們是信任公安部門的權威性的。這裏把公安部門稱爲第三方機構也便是這裏的CA。AA和BB通訊以前要向CA去註冊認證本身的身份。

AA向CA申請給本身發一個證（裏面包含公鑰、名字、有效期等CA會使用單向加密計算這些數據特徵碼，CA再用本身的私鑰加密這段特徵碼並附加在證書的後面，即數字簽名，保證了證書的信息沒有被更改），AA就把本身的證給BB，那此時BB如何去驗證AA發來的證書不是僞證書？則BB須要信任CA，才能信任CA所頒發的證書，BB使用CA的公鑰解密這段特徵碼，再用相同的單向加密計算這些數據特徵碼，比較兩個特徵碼是否一致。

獲取到CA的證書就包含了CA的公鑰，此時CA的證書（公鑰）從何而來呢？CA是本身給本身給發證書的。用自身的私鑰給包含公鑰的證書籤名。如何判斷得到的CA的證書就是發證機關的？沒法保證。你能夠到頒發機構本地複製證書，還有一些電子商務網站，你信任這些網站，你訪問時就安裝它的證書。且須要提供有公信力CA是須要向根CA註冊申請，都是須要收費的。

雖然私鑰把特徵碼加密附到源數據一塊兒發送能夠解決完整性和身份驗證問題，可是數據仍然未加密，此時經過祕鑰交換造成的對稱祕鑰把有附加信息的源數據總體再次加密就能解決機密性問題。

祕鑰交換除了上述的DH算法，也能夠經過對稱祕鑰來實現
以隨機生成一個數當加密密鑰，用接收方的公鑰加密後加在數據後面發送出去，接收方用私鑰解密得到對稱密鑰，用對稱密鑰解密數據，最後用私鑰解密特徵碼。

證書

證書頒發機構和彼此間的信任關係述組成了PKI（public key infrastructure公鑰基礎設施），基本組成以下：

簽證機構：CA
註冊機構：RA
證書吊銷列表：CRL
證書存取庫：

證書頒發機構（根證書頒發機構）派發出子機構 ，稱爲RA，用於接受證書申請，最後發給CA簽名。

還有一種特殊狀況，若是說證書（私鑰）丟失了，該如何處理呢？私鑰丟了，必須讓得到公鑰的主機知道公鑰被廢了，所以CA機構須要維持一張列表（證書吊銷列表），一旦私鑰丟棄，則向CA申請本身的證書做廢。CA機構就把丟失私鑰的主機放到證書吊銷列表中。

crl：證書吊銷列表，Certificate Revocation List；保存此前發出的仍未過時但被撤銷的證書。則通訊時，還須要增長一步就是通訊的對方收到數據後，須要到CA機構查看發送方是否在證書吊銷列表中。（注意互聯網上絕大部分通訊者都沒有這樣作，所以互聯網上通訊仍是存在安全隱患的）

一個證書中應該包含什麼？
不一樣標準下的證書格式是不一樣的，主流的標準格式如x509（國際電信聯盟ITU-T 制定），包含

主體名稱：證書的合法擁有者
附加在最後是經過CA私鑰簽名的證書特徵碼

獲取證書就是爲了得到對方公鑰，如何驗證證書
一、利用本地預存的公鑰信息，解密頒發機構的簽名
二、解密得到證書的特徵碼，驗證此證書內容沒有被篡改
三、聯繫證書頒發機構確認證書有效可用

有兩種PKI：TLS/SSL使用的是x509的證書；OpenGPG是另外一種證書管理機制（或者叫PKI的實現架構）

另外爲了驗證證書不是由假裝的CA頒發的，必須經過可靠的途徑來獲取可信任CA的公鑰（如廠商之間互相信任內置公鑰）