計算機網絡——如何保證網絡傳輸的安全性

1、前言

  前幾天在面試時，被問到了如何保證網絡數據傳輸的安全性的問題，當時對這一塊沒怎麼研究過，因此當時並無回答出來。因此，今天花了點時間，研究了一下這方面的內容。這篇博客就來簡單說一說保證網絡傳輸安全性的一些方式。

2、正文

2.1 安全傳輸須要解決的問題

  先有問題，纔有解決方案，因此咱們先來討論一下，網絡傳輸中，須要解決哪些問題，才能保證安全。須要解決的問題大體有以下三個：

1. 發送方鑑別：確保接收到的數據，確實是由咱們認爲的那我的（或主機）發送來的，而不是其餘人以虛假身份發送的；
2. 報文完整性：確保咱們接收到的報文就是發送方發送的初始報文，而沒有被第三方進行篡改；
3. 數據機密性：確保報文即便被其餘人截獲，也沒法讀出其中的信息，也就是要對數據加密；

  若是上面三個問題都獲得瞭解決，那咱們基本上就能夠保證數據傳輸是安全的。下面咱們就針對上面三個問題，來談一談解決方案。

2.2 非對稱加密與對稱加密

  在網絡安全中，有兩個很是重要的概念，就是對稱加密和非對稱加密，後面要談的全部方案，都離不開這兩種機制。因此，在瞭解具體解決問題的方案前，咱們先來了解這兩個概念。

（一）對稱加密

  對稱加密的原理很簡單，就是數據的發送方和接收方共享一個加密數據的密鑰，使用這個密鑰加密的數據，可使用這個密鑰進行解密。而這個密鑰是隱私的，只有數據的發送方和接收方知道，這也就意味着，其餘人若是截獲了數據，因爲這個數據使用了密鑰加密，而它沒有這個密鑰，全部沒法解析出原始數據。

（二）非對稱加密

  非對稱加密系統中，參與加密解密的共有兩個——公鑰和私鑰，使用私鑰加密的數據，只能用公鑰解密，而使用公鑰加密的數據，只能用私鑰解出。在非對稱加密系統中，每一臺主機都有本身的私鑰和公鑰，私鑰只有本身知道，而公鑰是公開的，可讓全部主機知道。發送方在發送數據時，使用接收方的公鑰進行加密，而接收方使用本身的私鑰進行解密，便可完成隱私的數據傳輸。若是數據被其它人截獲，可是由於它沒有接收方的私鑰，因此沒法解析出數據。

  非對稱加密可以工做的一個前提是，必須確保發送方拿到的公鑰，就是接收方的公鑰，而不是其餘人發送來的假公鑰，若是公鑰是假的，那麼這個機制也就失去了意義。在實際應用中，解決這個問題的方式就是，每一臺主機的公鑰和私鑰，都是由官方機構所分配的，這些機構被稱爲認證中心（CA）。CA在分配公鑰私鑰時，會嚴格地驗證身份，而後對身份進行綁定，而咱們在獲取公鑰時，經過CA獲取，便可保證獲取到的公鑰就是接收方的。

  須要注意的一點是，非對稱加密的效率通常比較低，而對稱加密的效率相對較高。下面，開始正式討論解決上面三個問題的方案。

2.3 解決數據機密性

（一）非對稱加密

1. 發送方獲取接受方的公鑰，使用公鑰對須要發送的數據進行加密，而後發送；

2. 接受方接收到後，使用本身的私鑰進行解密，解析出數據；

總結：由於只有接受方知道本身的私鑰，因此只有接受方能讀出數據。可是，非對稱加密的執行效率比較低，因此每一次數據傳輸都使用非對稱加密，響應速度將會比較慢；

（二）非對稱加密 + 對稱加密（屢次傳輸）

  爲了解決非對稱加密效率較低的問題，咱們可使用對稱加密，可是同步對稱加密的密鑰，卻須要依賴於非對稱加密：

1. 發送方隨機生成一個密鑰，而後獲取接受方的公鑰，使用公鑰加密這個密鑰，發送給接受方；

2. 接收方接收到加密的密鑰後，使用本身的私鑰解析出密鑰，此時雙方就完成了密鑰同步；

3. 以後雙方發送的全部數據，均可以使用這個密鑰進行加密解密；

總結：因爲私鑰只有接收方本身知道，因此這個密鑰不會被其餘人截獲；同時使用對稱加密的速度，要高於非對稱加密，因此解決了上一個方案效率不高的問題；須要注意，通常密鑰都比較短，因此使用非對稱加密對密鑰進行加密，通常比直接加密數據更快，並且只須要進行一次，因此速度可以顯著提升。

  HTTPS依賴於SSL保證數據傳輸的安全性，而SSL就是使用相似機制。

（三）非對稱加密 + 對稱加密（單次傳輸）

  若是發送方只是須要向接收方發送一次數據，那先進行一次密鑰同步可能有些浪費時間，可使用以下方案解決：

1. 發送方隨機生成一個密鑰，而後使用這個密鑰對數據進行加密；

2. 發送方使用接收方的公鑰對數據密鑰進行加密，而後將加密的數據和加密的密鑰發送；

3. 接收方首先使用本身的私鑰解析出密鑰，而後使用解析出的密鑰將數據解析出來；

總結：此方案適合於進行單次數據發送，由於不須要進行密鑰的同步，而是將密鑰與數據一同發送；同時，這個密鑰使用了接收方的公鑰加密，因此這個密鑰只有接收方本身能解析出來，而其餘人解析不出密鑰，天然沒法解析數據；

2.4 同時解決發送方鑑別和報文完整性

  下面咱們來講說解決發送方鑑別和報文完整性的方案。有一個經典的方案可以同時解決這兩個問題，其過程以下：

1. 發送方使用一個hash算法（如MD5、SHA-1），計算須要發送的數據的hash值；

2. 使用本身的私鑰，對計算出的hash值進行加密；

3. 將原始數據和加密後的hash值發送到接收方；

4. 接收方使用發送方的公鑰解析出加密後的hash值；

5. 使用與發送方相同的hash算法，計算接收到的數據的hash值，與解析出的hash值進行比較；

6. 若這兩個hash值一致，表示這個數據並無被篡改；

總結：

一、首先，hash值是用發送方的私鑰加密，私鑰只有發送方本身知道，若是接收方可以使用發送方的公鑰解密，那就說明這個數據就是預期中的發送方發的，不多是其餘人發的，因而完成了發送方鑑別；

二、接收方使用一樣的hash算法，計算原始數據的hash值，若是這個hash值與解密後的hash值一致，則就能保證這個數據沒有被篡改；

上面兩步中，但凡是有一步出現了錯誤，就認爲這是一個髒數據；

  這個方案被稱爲數字簽名。爲何是計算出hash值，對hash值加密，而不是直接使用私鑰對數據加密？這是由於hash值比較小，加密解密比較快。

2.5 同時解決三個問題的方案

  上面提到的三個問題中，但凡是有一個沒有解決，數據傳輸都是不可靠的，這裏咱們就經過上面提到的幾個辦法，來同時解決三個問題。辦法很簡單，直接將上面解決方案進行整合便可：

1. 首先，咱們使用2.4中所提出的辦法，對數據進行處理，也就是計算hash，而後使用本身的私鑰加密hash；

2. 而後，將第一步計算出的hash與原始數據組合，使用2.3中提出的非對稱加密 + 對稱加密的方式，進行加密，加密以後再進行發送，保證數據的隱祕性；

3. 接收方接收到數據後，使用2.3中的過程對數據解密，獲得原始數據和加密後的hash；

4. 使用2.4中的方式完成發送方鑑別以及數據完整性校驗；

總結：上面的方式很是簡單，就是將咱們以前提過的加密，以及2.4中的方案組合，以此來同時解決三個問題。這是一個很是經常使用的方案，好比安全的郵件傳輸協議的實現就使用了相似方案。

2.6 解決發送方鑑別的其餘方案

  假設接收方和發送方有一個共享的密鑰，則可使用如下方式進行身份鑑別：

1. 發送方向接收方發送本身的身份，好比發送一個「我是xxx」；

2. 接收方爲了驗證不是其餘人發送的虛假數據，向發送方發送一個隨機數，這個隨機數短期內不會重複；

3. 發送方使用它們共享的密鑰，對這個隨機數加密後發回接收方；

4. 接收方接收後，使用密鑰解密，若是確實是本身以前發送出去的隨機數，便可確認對方身份；

  這裏存在的問題是如何讓接收方和發送方有一個共享密鑰，其實就能夠經過2.3節中第二個方案提到的，使用非對稱加密的方式同步密鑰。

總結：

一、因爲密鑰只有發送方和接收方知曉，因此若是發送方可以將加密後的隨機數發回，便可確認它的身份；

二、爲何不直接使用加密後的身份信息發送，而是使用隨機數？由於若是這個加密後的身份數據被截獲，其餘人不須要進行解密，只須要向接收方發送這個加密後的身份，便可僞造本身的身份；

2.7 解決數據完整性的其餘方案

  假設發送方和接收方有一個共享的密鑰，則可使用以下步驟保證數據完整性：

1. 發送方將原始數據與密鑰拼接，而後計算拼接後的hash值，將這個hash值與原始數據一同發送；

2. 接收方接收到後，一樣將原始數據和密鑰拼接，並計算hash值，而後與發來的hash值比較；

3. 若hash值一致，能夠保證這個數據沒有修改，不然就是被篡改的數據；

總結：因爲拼接進原始數據的密鑰只有傳輸雙方知道，這個hash值只有它們雙方能計算出來，因此若是hash值不一致，便可認爲數據是有問題的。

  這個方案叫報文鑑別碼，和前面提過的數字簽名有些相似，可是不一樣的是，這個方案中，並不須要對發送的數據進行加密，只是計算hash做爲鑑別碼，只要保證密鑰不被竊取，便可保證數據的完整性。

2.8 如何防止發送方本身發送虛假數據

  須要注意的一點是，咱們上面所提出的方案，都是針對第三方侵入的解決方法，也就是防止除發送方和接收方外，有其餘人對數據傳輸作手腳。可是，若是發送方本身篡改數據，或僞造數據，而後發送，這應該怎麼解決呢？接收方如何可以識別出接收到的數據就是原始數據，而不是發送方本身篡改或發送的虛假數據呢？這是我最近一直在想的問題。

  在這種狀況下，咱們須要考慮的是，發送數據的用戶能夠作到什麼程度？因爲發送數據的設備就在發送者手上，是否是意味着數據發送過程當中的密鑰等信息，用戶是能夠經過一些手段看到的？若是是能夠，那上面所說的機制應該就無法保證安全性了。可是，本人水平有限，並不清楚有戶對於發送到本身設備上的數據，能夠竊取到什麼程度。但願瞭解這個問題的人可以爲我解答。

  固然，上面的機制可能沒辦法保證徹底可靠，可是也有很大的效果。好比說報文鑑別碼就能解決用戶本身篡改本身的數據這個問題。若是用戶沒有獲取到密鑰，則它天然沒法發送虛假數據，由於沒有密鑰就沒有辦法計算出虛假數據的hash。雖然用戶可能能夠經過一些手段，獲取到這個密鑰，可是過程是應該是很是複雜的，這就對竊取的技術要求很是高，因此在大部分狀況下能夠保證數據不被篡改。

  說實話，對於用戶本身發送虛假數據這個問題，因爲我知識水平不足，一直沒法想清楚，網上也沒有找到相關的資料，因此上面的描述都是基於我目前的理解。若是有了解這個問題相關知識，以及解決方案的，麻煩告知。

3、總結

  以上就對數據的安全傳輸方案作了一個大體的介紹，歸根到底，就是基於數據隱祕性，報文完整性以及發送方鑑別這三個問題，這三者缺一不可，只有所有解決，才能保證傳輸的可靠。

  但願上面的內容對須要瞭解這一方面的人有所幫助，若存在錯誤或不足，也歡迎指正。

4、參考

• 《計算機網絡——自頂向下方法（原書第七版）》