一、前言
前幾天在面試時，被問到了如何保證網絡數據傳輸的安全性的問題，當時對這一塊沒怎么研究過，所以當時並沒有回答出來。所以，今天花了點時間，研究了一下這方面的內容。這篇博客就來簡單說一說保證網絡傳輸安全性的一些方式。
二、正文
2.1 安全傳輸需要解決的問題
先有問題，才有解決方案，所以我們先來討論一下，網絡傳輸中，需要解決哪些問題，才能保證安全。需要解決的問題大致有如下三個：
- 發送方鑒別：確保接收到的數據，確實是由我們認為的那個人（或主機）發送來的，而不是其他人以虛假身份發送的；
- 報文完整性：確保我們接收到的報文就是發送方發送的初始報文，而沒有被第三方進行篡改；
- 數據機密性：確保報文即使被其他人截獲，也無法讀出其中的信息，也就是要對數據加密；
如果上面三個問題都得到了解決，那我們基本上就可以保證數據傳輸是安全的。下面我們就針對上面三個問題，來談一談解決方案。
2.2 非對稱加密與對稱加密
在網絡安全中，有兩個非常重要的概念，就是對稱加密和非對稱加密，后面要談的所有方案，都離不開這兩種機制。所以，在了解具體解決問題的方案前，我們先來了解這兩個概念。
（一）對稱加密
對稱加密的原理很簡單，就是數據的發送方和接收方共享一個加密數據的密鑰，使用這個密鑰加密的數據，可以使用這個密鑰進行解密。而這個密鑰是隱私的，只有數據的發送方和接收方知道，這也就意味着，其他人如果截獲了數據，由於這個數據使用了密鑰加密，而它沒有這個密鑰，所有無法解析出原始數據。
（二）非對稱加密
非對稱加密系統中，參與加密解密的共有兩個——公鑰和私鑰，使用私鑰加密的數據，只能用公鑰解密，而使用公鑰加密的數據，只能用私鑰解出。在非對稱加密系統中，每一台主機都有自己的私鑰和公鑰，私鑰只有自己知道，而公鑰是公開的，可以讓所有主機知道。發送方在發送數據時，使用接收方的公鑰進行加密，而接收方使用自己的私鑰進行解密，即可完成隱私的數據傳輸。如果數據被其它人截獲，但是因為它沒有接收方的私鑰，所以無法解析出數據。
非對稱加密能夠工作的一個前提是，必須確保發送方拿到的公鑰，就是接收方的公鑰，而不是其他人發送來的假公鑰，如果公鑰是假的，那么這個機制也就失去了意義。在實際應用中，解決這個問題的方式就是，每一台主機的公鑰和私鑰，都是由官方機構所分配的，這些機構被稱為認證中心（CA）。CA在分配公鑰私鑰時，會嚴格地驗證身份，然后對身份進行綁定，而我們在獲取公鑰時，通過CA獲取，即可保證獲取到的公鑰就是接收方的。
需要注意的一點是，非對稱加密的效率一般比較低，而對稱加密的效率相對較高。下面，開始正式討論解決上面三個問題的方案。
2.3 解決數據機密性
（一）非對稱加密
-
發送方獲取接受方的公鑰，使用公鑰對需要發送的數據進行加密，然后發送；
-
接受方接收到后，使用自己的私鑰進行解密，解析出數據；
總結：因為只有接受方知道自己的私鑰，所以只有接受方能讀出數據。但是，非對稱加密的執行效率比較低，所以每一次數據傳輸都使用非對稱加密，響應速度將會比較慢；
（二）非對稱加密 + 對稱加密（多次傳輸）
為了解決非對稱加密效率較低的問題，我們可以使用對稱加密，但是同步對稱加密的密鑰，卻需要依賴於非對稱加密：
-
發送方隨機生成一個密鑰，然后獲取接受方的公鑰，使用公鑰加密這個密鑰，發送給接受方；
-
接收方接收到加密的密鑰后，使用自己的私鑰解析出密鑰，此時雙方就完成了密鑰同步；
-
之后雙方發送的所有數據，都可以使用這個密鑰進行加密解密；
總結：由於私鑰只有接收方自己知道，所以這個密鑰不會被其他人截獲；同時使用對稱加密的速度，要高於非對稱加密，所以解決了上一個方案效率不高的問題；需要注意，一般密鑰都比較短，所以使用非對稱加密對密鑰進行加密，一般比直接加密數據更快，而且只需要進行一次，所以速度能夠顯著提高。
HTTPS依賴於SSL保證數據傳輸的安全性，而SSL就是使用類似機制。
（三）非對稱加密 + 對稱加密（單次傳輸）
如果發送方只是需要向接收方發送一次數據，那先進行一次密鑰同步可能有些浪費時間，可以使用如下方案解決：
-
發送方隨機生成一個密鑰，然后使用這個密鑰對數據進行加密；
-
發送方使用接收方的公鑰對數據密鑰進行加密，然后將加密的數據和加密的密鑰發送；
-
接收方首先使用自己的私鑰解析出密鑰，然后使用解析出的密鑰將數據解析出來；
總結：此方案適合於進行單次數據發送，因為不需要進行密鑰的同步，而是將密鑰與數據一同發送；同時，這個密鑰使用了接收方的公鑰加密，所以這個密鑰只有接收方自己能解析出來，而其他人解析不出密鑰，自然無法解析數據；
2.4 同時解決發送方鑒別和報文完整性
下面我們來說說解決發送方鑒別和報文完整性的方案。有一個經典的方案能夠同時解決這兩個問題，其過程如下：
-
發送方使用一個
hash算法（如MD5、SHA-1），計算需要發送的數據的hash值； -
使用自己的私鑰，對計算出的
hash值進行加密； -
將原始數據和加密后的
hash值發送到接收方； -
接收方使用發送方的公鑰解析出加密后的
hash值； -
使用與發送方相同的
hash算法，計算接收到的數據的hash值，與解析出的hash值進行比較； -
若這兩個
hash值一致，表示這個數據並沒有被篡改；
總結：
1、首先，hash值是用發送方的私鑰加密，私鑰只有發送方自己知道，如果接收方能夠使用發送方的公鑰解密，那就說明這個數據就是預期中的發送方發的，不可能是其他人發的，於是完成了發送方鑒別；
2、接收方使用同樣的hash算法，計算原始數據的hash值，如果這個hash值與解密后的hash值一致，則就能保證這個數據沒有被篡改；
上面兩步中，但凡有一步出現了錯誤，就認為這是一個臟數據；
這個方案被稱為數字簽名。為什么是計算出hash值，對hash值加密，而不是直接使用私鑰對數據加密？這是因為hash值比較小，加密解密比較快。
2.5 同時解決三個問題的方案
上面提到的三個問題中，但凡有一個沒有解決，數據傳輸都是不可靠的，這里我們就通過上面提到的幾個辦法，來同時解決三個問題。辦法很簡單，直接將上面解決方案進行整合即可：
-
首先，我們使用
2.4中所提出的辦法，對數據進行處理，也就是計算hash，然后使用自己的私鑰加密hash； -
然后，將第一步計算出的
hash與原始數據組合，使用2.3中提出的非對稱加密 + 對稱加密的方式，進行加密，加密之后再進行發送，保證數據的隱秘性； -
接收方接收到數據后，使用
2.3中的過程對數據解密，得到原始數據和加密后的hash； -
使用
2.4中的方式完成發送方鑒別以及數據完整性校驗；
總結：上面的方式非常簡單，就是將我們之前提過的加密，以及2.4中的方案組合，以此來同時解決三個問題。這是一個非常常用的方案，比如安全的郵件傳輸協議的實現就使用了類似方案。
2.6 解決發送方鑒別的其他方案
假設接收方和發送方有一個共享的密鑰，則可以使用以下方式進行身份鑒別：
-
發送方向接收方發送自己的身份，比如發送一個“我是xxx”；
-
接收方為了驗證不是其他人發送的虛假數據，向發送方發送一個隨機數，這個隨機數短時間內不會重復；
-
發送方使用它們共享的密鑰，對這個隨機數加密后發回接收方；
-
接收方接收后，使用密鑰解密，如果確實是自己之前發送出去的隨機數，即可確認對方身份；
這里存在的問題是如何讓接收方和發送方有一個共享密鑰，其實就可以通過2.3節中第二個方案提到的，使用非對稱加密的方式同步密鑰。
總結：
1、由於密鑰只有發送方和接收方知曉，所以如果發送方能夠將加密后的隨機數發回，即可確認它的身份；
2、為什么不直接使用加密后的身份信息發送，而是使用隨機數？因為如果這個加密后的身份數據被截獲，其他人不需要進行解密，只需要向接收方發送這個加密后的身份，即可偽造自己的身份；
2.7 解決數據完整性的其他方案
假設發送方和接收方有一個共享的密鑰，則可以使用如下步驟保證數據完整性：
-
發送方將原始數據與密鑰拼接，然后計算拼接后的
hash值，將這個hash值與原始數據一同發送； -
接收方接收到后，同樣將原始數據和密鑰拼接，並計算
hash值，然后與發來的hash值比較； -
若
hash值一致，可以保證這個數據沒有修改，否則就是被篡改的數據；
總結：由於拼接進原始數據的密鑰只有傳輸雙方知道，這個hash值只有它們雙方能計算出來，所以如果hash值不一致，即可認為數據是有問題的。
這個方案叫報文鑒別碼，和前面提過的數字簽名有些類似，但是不同的是，這個方案中，並不需要對發送的數據進行加密，只是計算hash作為鑒別碼，只要保證密鑰不被竊取，即可保證數據的完整性。
2.8 如何防止發送方自己發送虛假數據
需要注意的一點是，我們上面所提出的方案，都是針對第三方侵入的解決方法，也就是防止除發送方和接收方外，有其他人對數據傳輸做手腳。但是，如果發送方自己篡改數據，或偽造數據，然后發送，這應該怎么解決呢？接收方如何能夠識別出接收到的數據就是原始數據，而不是發送方自己篡改或發送的虛假數據呢？這是我最近一直在想的問題。
在這種情況下，我們需要考慮的是，發送數據的用戶可以做到什么程度？由於發送數據的設備就在發送者手上，是不是意味着數據發送過程中的密鑰等信息，用戶是可以通過一些手段看到的？如果是可以，那上面所說的機制應該就沒法保證安全性了。但是，本人水平有限，並不清楚有戶對於發送到自己設備上的數據，可以竊取到什么程度。希望了解這個問題的人能夠為我解答。
當然，上面的機制可能沒辦法保證完全可靠，但是也有很大的效果。比如說報文鑒別碼就能解決用戶自己篡改自己的數據這個問題。如果用戶沒有獲取到密鑰，則它自然無法發送虛假數據，因為沒有密鑰就沒有辦法計算出虛假數據的hash。雖然用戶可能可以通過一些手段，獲取到這個密鑰，但是過程是應該是非常復雜的，這就對竊取的技術要求非常高，所以在大部分情況下可以保證數據不被篡改。
說實話，對於用戶自己發送虛假數據這個問題，由於我知識水平不足，一直無法想清楚，網上也沒有找到相關的資料，所以上面的描述都是基於我目前的理解。如果有了解這個問題相關知識，以及解決方案的，麻煩告知。
三、總結
以上就對數據的安全傳輸方案做了一個大致的介紹，歸根到底，就是基於數據隱秘性，報文完整性以及發送方鑒別這三個問題，這三者缺一不可，只有全部解決，才能保證傳輸的可靠。
希望上面的內容對需要了解這一方面的人有所幫助，若存在錯誤或不足，也歡迎指正。
四、參考
- 《計算機網絡——自頂向下方法（原書第七版）》