WEB安全——IPsec傳輸模式下ESP報文的裝包與拆包過程

標籤：style   blog   http   io   color   ar   os   使用   sp   

WEB安全概論

                                                         ——IPsec傳輸模式下ESP報文的裝包與拆包過程

一、IPsec

      （一）簡介

      互連網安全協定（英語：Internet Protocol Security，縮寫為 IPsec），是透過對IP協議（互連網協議）的分組進行加密和認證來保護IP協議的網路傳輸協議族（一些相互關聯的協議的集合）。

 

      IPsec由兩大部分組成：（1）建立安全分組流的金鑰交換協議；（2）保護分組流的協議。前者為互連網金鑰交換（IKE）協議。後者包括加密分組流的封裝安全載荷協議（ESP協議）或認證頭協議（AH協議）協議，用於保證資料的機密性、來源可靠性（認證）、不需連線的完整性並提供抗重播服務。

 

      （二）設計意圖

      IPsec被設計用來提供（1）入口對入口通訊安全，在此機制下，分組通訊的安全性由單個節點提供給多台機器（甚至可以是整個區域網路）；（2）端到端分組通訊安全，由作為端點的電腦完成安全操作。上述的任意一種模式都可以用來構建虛擬私人網路 (VPN)，而這也是IPsec最主要的用途之一。應該注意的是，上述兩種操作模式在安全的實現方面有著很大差別。

       網際網路範圍內端到端通訊安全的發展比預料的要緩慢，其中部分原因，是因為其不夠普遍或者說不被普遍信任。公開金鑰基礎設施能夠得以形成（DNSSEC最初就是為此產生的），一部分是因為許多使用者不能充分地認清他們的需求及可用的選項，導致其作為內含物強加到賣主的產品中（這也必將得到廣泛採用）；另一部分可能歸因於網路響應的退化（或說預期退化），就像兜售資訊的充斥而帶來的頻寬損失一樣。

       (三)與其他互連網協議的對比

       IPsec協議工作在OSI 模型的第三層，使其在單獨使用時適於保護基於TCP或UDP的協議（如 安全套接子層（SSL）就不能保護UDP層的通訊流）。這就意味著，與傳輸層或更高層的協議相比，IPsec協議必須處理可靠性和分區的問題，這同時也增加了它的複雜性和處理開銷。相對而言，SSL/TLS依靠更高層的TCP（OSI的第四層）來管理可靠性和分區。

 

二、ESP

      （一）ESP和傳輸模式簡介

        ESP（Encapsulating Security Payloads），封裝安全載荷協議，IPsec 所支援的兩類協議中的一種。該協議能夠在資料的傳輸過程中對資料進行完整性度量，來源認證以及加密，也可防止回放攻擊。

            傳輸模式，與隧道模式同為IPsec工作的兩種方式。與隧道模式不同，當IPsec工作在傳輸模式時，新的IP頭並不會被產生，而是採用原來的IP頭，保護的也僅僅是真正傳輸的資料，而不是整個IP報文。在處理方法上，原來的IP報文會先被解開，再在資料前面加上新的ESP或AH協議頭，最後再裝回原來的IP頭，即原來的IP包被修改過再傳輸。

    （二）傳輸模式下的ESP包

              傳輸模式下，ESP包大致結構和詳細結構如下所示：

      

      （三）傳輸模式下的ESP裝包和拆包過程

        1、裝包過程：

        裝包過程，即處理外出資料包。

        對在IPv4上啟動並執行傳送模式應用來說， ESP頭緊跟在IP頭（包括IP頭可能有的任何選項）之後，插入一個外出的IP包中。IP頭的協議欄位被複製到ESP頭的“下一個頭”欄位中， ESP頭的其餘欄位則被填滿— SPI欄位分配到的是來自SADB的、用來對這個包進行處理的特定 SA 的 SPI；以數列填滿號欄位的是序列中的下一個值；填充資料會被插入，其值被分配；同時分配的還有填充長度值。隨後， IP頭的協議欄位得到的是ESP的值，或者50。除了頭插入位置不同之外， IPv6處理規則基本上類似於IPv4。 ESP頭可插在任意一個擴充頭（在路由過程中，有可能被修改）之後。

        從恰當的 SA中選擇加密器（密碼編譯演算法），對包進行加密（從載荷資料的開頭，一直到“下一個頭”欄位）。隨後，使用恰當的 SA中的驗證器，對包進行驗證（自 ESP頭開始，中間經過加密的密文，一直到 ESP尾）。隨後，將驗證器的結果插入 ESP尾的“驗證資料”欄位中。對外出資料包進行處理的最後一步是：重新計算位於 ESP前面的IP頭的校正和。

         在傳輸模式下，當要發出一個資料包時：

         1、在原IP報文末尾添加尾部（ESP trailer）資訊。如所示，尾部包含三部分。由所選密碼編譯演算法可能是塊加密，那麼當最後一塊長度不夠時就需要進行填充（padding），附上填充長度（Pad length）方便解包時順利找出用來填充的那一段資料。而Next header則用來標明被加密的資料報文的類型，例如TCP。

 

           2、將原IP報文以及第1步得到的ESP尾部作為一個整體進行加密。具體的密碼編譯演算法與密鑰由SA給出。

           3、為第2步得到的加密資料添加ESP頭部。

           ESP頭由兩部分組成，SPI和序號（Sequence number）。加密資料與ESP頭合稱為“enchilada”。

           4、附加完整性度量結果（ICV，Integrity check value）。

           對第三步得到的“enchilada”做摘要，得到一個完整性度量值，並附在ESP報文的尾部。

                 5、拿到原本的IP頭。這樣就可以發送了。

                2、拆包過程。

                拆包過程，即處理接受到的資料包。

                接收端在收到一個 ESP包之後，若不對這個包進行處理，就無法得知它究竟處於通道模式，還是傳送模式。根據對這個包進行處理的SA，便可知道它到底處在什麼模式下。

                如果收到的IPSec包是一個分段，必須把它保留下來，直到這個包的其他部分收完為止。

                我們不能對一個不完整的IPSec包進行處理，因為可能會導致對它施行的初次校檢失敗。

               收到 ESP包後，進行的第一件事情是：檢查處理這個包的SA是否存在，這是基本的 IPSec要求，而不是ESP專有的。如果沒有SA，這個包就會被丟棄。只有在SA存在的情況下，才可開始進行輸入處理。一旦驗證通過了一個有效SA，就可用它開始包的處理。

               首先檢查序號。如果這個包的序號是有效—也就是說，它不是一個重複（重播）的包，也不是出現在包含在S A中的序號視窗的右邊—就開始進行處理。由於E S P身分識別驗證密文而不是明文，接下來進行的便是對這個包進行身分識別驗證。利用恰當的密鑰，把這個完整的ESP包（當然除開驗證資料）傳遞到驗證器那裡（它取自SA）。如果其結果能與“驗證資料”欄位中包含的資料相符（將身分識別驗證演算法可能需要的任何分段考慮在內），就可對這個包進行身分識別驗證。接下來是解密。通過取自SA的密鑰和密碼演算法，就可對 ESP包進行解密，這個ESP包在載荷資料開始之處到下一個頭之間。判斷解密成功的一個最簡單的測試是檢驗其填充。由於填充內容具有決定意義—要麼是一個從1開始的單向遞增的數，要麼通過密碼編譯演算法來決定—對填充內容進行驗證將決定這個包是否已成功解密。

                傳送身分識別驗證和解密檢查成功之後，就可對結果資料包進行初步的有效性檢驗。如果用來處理這個資料包的SA表明在某一特定模式下—要麼是通道模式，要麼是傳送模式—只能處理ESP包，那麼還必須檢驗這個包的適用性。如果這個包與要求的模式不符，就必須把它丟棄。

                對傳送模式而言，上層協議頭與IP頭是同步的，ESP頭的下一個頭欄位被複製到IP頭的協議欄位中，並計算出一個新的IP校正和；而對通道模式而言，就拋開外部IP頭和ESP頭—我們需要的是這個解開封裝的包。這時，必須進行另一個有效性檢驗。

                如果它是一個傳送模式包，就會轉讓到一個高一級的協議層—比如TCP或 UDP—由它們對這個包進行處理。

拆包過程如下：

1. 收到資料報文後，發現協議類型是50，故知道這是一個IPsec包。首先查看ESP 頭， 通過裡面的SPI決定資料報文所對應的SA。

2. 計算“enchilada”部分的摘要，與附在末尾的ICV做對比，如果一樣的話說明資料 是完整的。否則可以斷定所收到的報文已經不是原來的報文了。

3. 檢查Seq裡的順序號，保證資料是“新鮮”的。

4. 根據SA所提供的密碼編譯演算法和密鑰，解密被加密過的資料，即“enchilada”。得到原 IP報文與ESP尾部（trailer）。

5. 根據ESP尾部裡的填充長度資訊，我們可以找出填充欄位的長度，刪去後就得到原來 的IP報文。

6. 最後轉讓到一個高一級的協議層—比如TCP或 UDP—由它們對這個包進行處理。

             (四)拓展：傳輸模式下的ESP裝包和拆包過程

 

裝包過程: 

1. 在原IP報文末尾添加尾部(ESP trailer)資訊。如所示,尾部包含三部分。由所選密碼編譯演算法可能是塊加密,那麼當最後一塊長度不夠時就需要進行填充(padding),附上填充長度(Pad length)方便解包時順利找出用來填充的那一段資料。而Next header則用來標明被加密的資料報文的類型,例如TCP。 

2. 將原IP報文以及第1步得到的ESP尾部作為一個整體進行加密。具體的密碼編譯演算法與密鑰由SA給出。

3. 為第2步得到的加密資料添加ESP頭部。如所示,ESP頭由兩部分組成,SPI和序號(Sequence number)。加密資料與ESP頭合稱為“enchilada”。 

4. 附加完整性度量結果(ICV,Integrity check value)。對第三步得到的“enchilada”做摘要,得到一個完整性度量值,並附在ESP報文

的尾部。
5. 加上新的IP頭。新構造的IP頭附在ESP報文的前面組成一個新的IP報文。注意這個新的IP頭的目的地址跟源地址可以不一樣。協議類型為50,說明它裡面裝的是一個IPsec報文。 

 

 

拆包過程:

1. 接收方收到資料報文後,發現協議類型是50,故知道這是一個IPsec包。首先查看ESP頭,通過裡面的SPI決定資料報文所對應的SA。

2. 計算“enchilada”部分的摘要,與附在末尾的ICV做對比,如果一樣的話說明資料是完整的。否則可以斷定所收到的報文已經不是原來的報文了。

3.檢查Seq裡的順序號,保證資料是“新鮮”的。

4.根據SA所提供的密碼編譯演算法和密鑰,解密被加密過的資料,即“enchilada”。得到原IP報文與ESP尾部(trailer)。

5. 根據ESP尾部裡的填充長度資訊,我們可以找出填充欄位的長度,刪去後就得到原來的IP報文。

6. 最後根據得到的原IP包的目的地址來進行轉寄。

 

參考資料：

#傳輸模式下ESP的裝包和拆包過程#

http://blog.sina.com.cn/s/blog_64ffd1280101egtj.html

#IPSec傳輸模式/隧道模式下ESP報文的裝包與拆包過程#

http://blog.csdn.net/johnson_puning/article/details/14163751

#IPsec#

http://zh.wikipedia.org/wiki/IPsec

 

WEB安全——IPsec傳輸模式下ESP報文的裝包與拆包過程