IPSec協議

概述

​ IPsec是網際層實現IP分組端到端安全傳輸的機制，由一組安全協議組成。鑒別首部協議AH(Authentication Header)和封裝安全凈荷協議ESP(Encapsulating Security Payload)是其中的兩個協議，AH和ESP協議均實現IP分組源端鑒別和防重放攻擊，兩者的差別是，AH只實現數據完整性檢測，而ESP不但要實現數據完整性檢測還可以對數據進行加密。而為了實現安全關聯的動態建立過程，還設計了Internet密鑰交換協議IKE(Internet Key Exchange Protocol)，用於完成安全關聯兩端之間的額雙向身份鑒別過程和安全關聯相關安全參數的協商過程。

​ 所謂安全關聯，就是為了以實現源端鑒別、數據加密和完整性檢測為目的的關聯就稱為安全關聯。安全關聯是單向的，用於確定發送者至接收者傳輸方向的數據所使用的加密算法和加密密鑰、消息鑒別碼MAC算法和消息鑒別MAC密鑰。

​ 其次IPsec對數據進行加密的方式有兩種，一種是是傳輸模式，另一種是隧道模式。在傳輸模式下，IPsec所保護的數據就是作為IP分組凈荷上層協議數據。而在隧道模式下，將整個IP分組作為另一個IP分組的凈荷的封裝方式就是隧道模式。

傳輸模式:

隧道模式:

​ 那么前面所提到的防重放攻擊是怎么做到的呢。ESP報文或AH報文就會采用序號來防止重放攻擊。在建立安全關聯時，序號初始值會設置為0。源端發送AH報文會ESP報文，會先將序號增1。在安全關聯的壽命內，不允許出現相同的序號。由於報文的到達也會有先后順序，所以會設置一個防重放窗口，在規定窗口內到達的序號是合規的，但是如果小於窗口中允許的最小的那個序號值，那就可能是重放攻擊了。

鑒別頭AH(Authentication Header)協議

AH報文格式

傳輸模式下的AH報文封裝

隧道模式下的AH報文封裝

​ 首先兩種模式，在IP協議的首部字段會與普通IP報文區分開。

• 在傳輸模式下，IP首部中的協議字段值為51，表示AH報文

• 在隧道模式下，就有兩個IP首部了，在新IP包頭首部的協議字段值仍未51，表示AH報文

鑒別首部AH格式:

• 下一個首部:

  • 在傳輸模式下，該字段值為IP報文中原本的數據凈荷的協議類型，比如原來包的TCP報文，那么這個字段值就為6

  • 在隧道模式下，該字段值為表示凈荷是隧道格式的協議字段值。

• 鑒別首部長度:以32位為單位給出AH的總長度

• 安全參數索引SPI:接收端將其和AH報文的目的IP地址和IP首部(隧道模式下的外層IP首部)中IPsec協議類型一起用於確定AH報文所屬的安全關聯

• 序號:用於防重放攻擊

• 鑒別數據:消息鑒別碼MAC，用於鑒別源端身份和實現數據完整性檢測。其鑒別算法可采用MD5或SHA-1，鑒別算法和鑒別密鑰都是在之前約定的，是在建立安全關聯時所協商的。

鑒別過程

​ 那么AH報文是如何實現源端鑒別和完整性檢測過程的呢，其源端鑒別由消息鑒別碼的共享密鑰來實現，完整性檢測則是由消息鑒別碼本身所實現。

​ 但要注意，在傳輸模式下和隧道模式下要用報文摘要算法加密的數據是有所區別的。

​ 在傳輸模式下，包括IP首部，IP凈荷和AH中除鑒別數據以外的其他字段。

​ 在隧道模式下，包括外層IP首部，包括內層IP首部在內的整個IP分組和AH中除鑒別數據以外的其他字段。

封裝安全凈荷ESP(Encapsulating Security Payload)協議

ESP報文格式

傳輸模式下的ESP報文:

隧道模式下的ESP報文:

​ 同樣，在IP首部中的協議字段值為50，表示凈荷協議ESP報文。

封裝安全凈荷ESP格式:

​ 其字段構成跟AH是差不多的，都由安全參數索引、序號、下一個首部和鑒別數據組成。

​ 但是有不同的地方，比如，ESP會將字段分為兩個部分，分別插到凈荷的前面和后面；再比如，在ESP尾部中會有一個填充和填充長度的統計，那為什么會有這個填充呢，是因為對ESP的加密是通過某些對稱算法實現的，比如DES加密算法，其每次加密數據都是要求64位一組，所以加密的數據必須為64位的倍數，不夠倍數，就會用填充數據。

​ 其余字段的作用跟AH的差不多，就不再一一介紹。

​ ESP加密運算覆蓋的字段是凈荷+ESP尾部，可以選擇眾多加密算法，比如三重DES、AES、RC5、IDEA等

​ 鑒別數據字段包括ESP首部+凈荷+ESP尾部，隧道模式下的凈荷包括內層IP首部在內的整個IP分組。

Internet密鑰交換協議IKE(Internet Key Exchange)

靜態安全關聯和動態安全關聯

​ 靜態安全關聯就是由人工完成的配置過程;動態關聯則是根據需要，通過協商建立的安全關聯。而我們的IKE剛好就是這樣一種動態建立安全關聯並完成參數協商的協議。

​ 啟動IKE的過程如圖所示:

IKE建立安全關聯過程

其過程如圖所示,涉及Diffie-Hellman密鑰分發協議

​ 其實在如圖所示的IKE建立安全關聯的過程可以細分為兩個過程，第一個建立安全通道的過程也被稱為建立IKE安全關聯的過程，也就是上圖的第一二條報文互換的階段；第二段過程則是所謂的建立IPsec安全關聯的階段，也就是上圖的第三四條報文互換的階段。

• 在第一條報文中，終端A會向Web服務器發送的信息包括IKE安全傳輸通道所使用的加密算法DES、報文摘要算法MD5、用於生成密鑰種子KS的YA和NA。YA是通過計算得出，YA=αˣᴬ mod p，再其中，XA為隨機數，α和p則為組號為2的Diffie-Hellman參數組指定的值。NA也是隨機數

• 在第二條報文中，web服務器對上面的消息作出響應，同意使用DES加密算法和報文摘要算法MD5。此外，還會發送給終端A用於生成密鑰種子的YB和NB。YB也是通過計算得出，YA=αˣᴮ mod p，再其中，XB也為隨機數，α和p跟上面是一樣的。此外，服務器還會向終端A發送證書請求。

• 在終端A收到服務器B發送的YB和NB，就會根據這兩個數字生成密鑰種子KS=YBˣᴬ mod p；服務器B在生成YB后就會跟之前收到的YA來生成密鑰種子KS=YAˣᴮ mod p，這兩個KS值是相等的。根據密鑰種子KS和隨機數NA、NB生成所有需要的密鑰，包括IKE安全傳輸信道所使用的加密密鑰K和IPsec安全關聯所使用的鑒別MAC密鑰。

• 在第三條報文中，就是終端A向web服務器發送IPsec安全關聯所指定的安全協議AH和消息鑒別算法MD5、並且給出終端A和web服務器B的標識符名IDA和IDB、以及用於證明自己的公鑰是PKA的證書、用A私鑰加密的用於證實自己身份的數字簽名Dska，而且以上這些數據也會經過上訴步驟已經協商好的密鑰K來加密傳輸。

• 在第四條報文中，web服務器B會同意使用安全協議AH和消息鑒別算法MD5、並設置安全參數索引SPI、給出終端A和web服務器B的標識符名IDA和IDB、以及用於證明自己的公鑰是PKB的證書和用B私鑰加密的用於證實自己身份的數字簽名Dskb，而且以上這些數據也會經過上訴步驟已經協商好的密鑰K來加密傳輸。

• 根據密鑰種子KS生成MAC密鑰XXX。