|
|
|
10-4 IPSec ESP 安全協定
10-4-1 IPSec ESP 協定簡介 IPSec 另一個安全協定為『封裝安全承載』（Encapsulation Security Payload, ESP），同樣包含 IPv4 與 IPv6 兩種規範。ESP 協定是將原來封包所承載的資料經過加密處理之後，再重新封裝一個新的封包（ESP 封包）才傳送給接收端；接收端拆解 ESP 封包後，先將資料解密，再組合回原封包格式，故稱之為『封裝安全承載』，其特性歸納如下： (1) ESP 提供資料的隱密性、資料來源認證、非連接方式完整性、反重播攻擊能力、以及有限度的流量機密性等功能。 (2) 具有傳輸模式（Transport Mode）和通道模式（Tunnel Mode）等兩種封包格式。 (3) 利用封包序號作為防禦重播攻擊（如同 IPSec AH）。 (4) 對所承載的資料可進行加密，以達到隱密性功能。一般都採用對稱加密法，針對加/解密所需的秘密金鑰，以及加密演算法皆是由 SA 參數而定。基本規範有 DES 的 CBC 模式與 NULL 編碼演算法。 (5) 可利用 ICV 驗證整個封包資料，以達到資料來源驗證。認證的範圍（亦是所選用的欄位）可由雙方協議的 SA 參數而定，認證演算法有 HMAC-MD5、HMAC-SHA-1以及 NULL。 (6) 必須採用通道模式才具『有限度的流量機密性』的功能。 (7) 可配合 AH 協定使用，以達到較完整的封包標頭驗證，與資料隱密性的功能。 相較於 AH，ESP 好像增加了資料隱密性和有限的流量機密性功能，但對於資料來源的認證，就沒有 AH 協定那麼完整。簡單的說，AH 協定主要是提供封包標頭的認證，任何有修改或偽裝封包將被偵測出來，但對於資料是否認證功能，完全取決於所選用的認證欄位而定；當然ESP 協定除了提供簡單的封包標頭認證之外，並將所承載的資料加密，以達到資料隱密性的功能。 (A) ESP 封包格式 ESP 封包格式與 AH 有很大的不同點，AH 是將認證標頭插入原封包標頭的後面或前面，基本上還是保留原來的封包格式；然而 ESP 為了達到資料的隱密性，會將原封包所承載的資料重新包裝成另一個『ESP 封包格式』，並依照操作模式（傳輸或通道模式）處理原封包標頭。譬如，傳輸模式就是將 ESP 封包放置於原封包標頭的後面；而通道模式是新建立一個的封包標頭，放置於最前面（容後詳細介紹）。
圖 10-13 IPSec ESP 封包格式 圖 10-13 為 ESP 封包格式（未包含原封包標頭），它是將原封包所承載資料經過加密（或未加密）後，再重新包裝的格式。一般將 SPI 與 Sequence Number 稱之為『ESP 標頭』（ESP Header），而 Payload Length 與 Next Header 兩個欄位稱之為『ESP 標尾』（ESP Trailer），各欄位功能如下： ² 安全參數索引（Security Parameter Index, SPI）：32 位元長度。SPI 的功能和 AH 協定中的 SPI 相同，都是雙方事先協議完成安全關聯（SA）的索引值，但它必須配合目的位址和安全協定（AH 或 ESP）來查詢相關安全參數。 ² 序號（Sequence Number）：32 位元長度。如 AH 協定中的序號一樣，都是作為反重播攻擊使用。 ² 承載資料（Payload Data）：為不定長度的欄位。當有啟動隱密性資料功能時（SA 參數決定），ESP 協定先將原來 IP 封包所承載的資料（TCP、UDP 或其他協定），經過某一加密演算法編碼後，再存入此欄位上傳送；如果沒有啟動隱密性功能，則填入原來 IP 所承載的資料。另一方面，如所選用的加密演算法需要『初始向量』（Initial Vector, IV）的話，則必須將 IV 值填入此欄位。基本上，無論是只有密文或密文附帶 IV 值，資料都必須是一個可以被 8 整除的長度。 ² 填補（Padding）：此欄位是選項的不定長度。主要作用於對齊資料長度是否是 32 位元長的整數倍，但它的長度可以由 0 到 255 位元組。 ² 填補長度（Pad Length）：8 位元長度。此欄位是表示所加入的填補資料的長度，有效值是 0 ~ 255 之間。 ² 下一個標頭（Next Header）：8 位元長度。此欄位是用來辨識封包裡所承載資料的協定，譬如，Next Header = 6，表承載資料為 TCP 協定的資料封包。 ² 認證資料（Authentication Data）：不定長度欄位。此欄位所存放的是『完整性檢查值』（ICV），認證範圍可以由 SPI 到 Next Header 欄位，這可由雙方協議的 SA 參數而定。 由上述的介紹，可以分辨出 AH 和 ESP 兩協定之間最大的不同點，AH 協定較著重於封包標頭認證，因此對於封包來源認證功能較強；然而 ESP 協定則偏重於承載資料的隱密性及認證，對於資料的保護較為嚴密。使用者可依照環境需求選擇 AH 或 ESP 協定，甚至也可以整合 AH 與 ESP 協定使用。 (B) ESP 加密及認證演算法 基本上，ESP 都使用對稱加密演算法。這是因為公開金鑰演算法必須耗費較長的加密/解密時間，這對於一般通訊而言效率太低。另一方面，IPSec 只建議 VPN 系統至少需具備有 DES 與 NULL 兩種編碼演算法，其中 NULL 表示所承載的資料是沒有經過編碼的，亦即選用 NULL 編碼演算法，則表示沒有加密的功能。除了上述兩種編碼系統外，通訊雙方也可以經由 SA 連線來協議雙方的編碼系統（如 AES 演算法）。 同樣的，IPSec 並沒有強制規定一定要用何種認證演算法，但規定至少要有：HMAC-MD5、HMAC-SHA-1 與 NULL 等演算法，其中 NULL 表示沒有認證功能的意思。無論所採用的加密系統、驗認演算法或演算法中所需的秘密金鑰，都必須雙方經由 ISAKMP 協定協議出來，如果在協議之中需要交換雙方鑰匙，就會使用到 IKE 協定。 10-4-2 IPSec ESP 操作模式 IPSec ESP 協定有：傳輸模式與通道模式等兩種操作，說明如下： （A）IPv4 ESP 傳輸模式 如同AH 協定一樣，ESP 協定也分為『傳輸模式』與『通道模式』兩種操作模式，其最大的不同點在於 ESP 標頭（SPI 與 Sequence Number 欄位）所存放的位置，以及是否重新建立新的封包。以下分別就 IPv4 與 IPv6 來介紹這兩種運作模式。 圖 10-14 為 IPv4 ESP 傳輸模式的封包格式，它是將 ESP 標頭（SPI 與 Sequence Number 欄位）插在原 IP 封包標頭之後，並對原封包所承載的資料編碼加密，再存放於 ESP 承載欄位上；緊接著是 ESP 標尾（Padding、Pad Length 與 Next Header 等欄位），最後才是 ESP 認證資料的欄位（ICV 資料）。其中經加密編碼欄位是否包含 ESP Trailer、或所提供的認證範圍（ESP 標頭到 ESP 標尾之間），皆由雙方協議之 SA 而定。
圖 10-14 IPv4 ESP 傳輸模式之封包格式 （B）IPv4 ESP 通道模式 之前我們利用圖 10-14 說明傳輸模式與通道模式之間的不同點，其中表示通道模式可使用於 NAT 網路環境裡，方法是將內部網路位址包裝在『內部標頭』（或稱原 IP 標頭）之內隱藏起來，再將『外部標頭』（或稱新的 IP 標頭）設定為合法網路位址。也就是說，IPSec ESP 封包封裝時，是將原來 IP 標頭包含進去（傳輸模式沒有），並且另外建立一個新的 IP 標頭（外部標頭）。圖 10-15 為 IPv4 封包經由 IPSec ESP 通道模式封裝的格式，加密編碼與認證範圍如同傳輸模式一樣（ESP 封包範圍如同圖 10-16、17 一樣）。
圖 10-15 IPv4 IPSec ESP 通道模式封包
|
翻轉工作室：粘添壽
網路規劃與管理技術：
翻轉電子書系列：
|
