網路層的護身符（下）：IPSec協定與應用

  • 發行項

Updated :2005 年 9 月 21 日

作者： 賴榮樞
http://www.goodman-lai.idv.tw

在IP加入安全協定的最大好處在於確保所有網路通訊的安全。因為即使位於IP層上層的應用程式或傳輸層沒有提供任何安全機制，但由於IP層加入了安全機制，因此也可保護整個網路通訊的內容。

在上一篇文章已經簡介過IPSec的應用、優點、架構，以及IPSec的運作方式、封包結構、使用模式、通訊協定，並且詳述IPSec三大協定的金鑰交換協定，我們將在這篇文章繼續討論IPSec的另兩種協定：認證表頭，以及資料封裝加密。

本頁內容

認證表頭
資料封裝加密
設定IPSec的選項
結語

認證表頭

認證表頭(Authentication Header，AH)可提供封包認證的功能。封包認證有兩層涵意：

  • 確保IP封包的完整性(確認IP封包在傳送途中未曾遭篡改)。

  • 確認IP封包發送者的身份。

請注意，封包認證並無法防止網路上的第三者窺伺封包內容。若不想讓其他人讀取封包內容，必須使用ESP封包加密的機制。

演算法

AH支援HMAC-MD5-96與HMAC-SHA-1-9這兩種HMAC演算法。

HMAC可視為雜湊函數與對稱式加密法的結合。雜湊函數與對稱式加密法都可用來認證資料。雜湊函數運算速度較快，但較不安全；對稱式加密法運算較速度較慢(相對於雜湊函數)，但較為安全。HMAC則兼具了雜湊函數與對稱式加密法的優點，不僅運算速度較快，且安全性也很高。此外，HMAC不受美國輸出法令的限制，因此可以廣泛地在全球使用。

HMAC實際上的運作原理如下：

圖1：HMAC的架構
圖1：HMAC的架構

HMAC所產生的值叫做MAC(Message Authentication Code)或ICV(Integrity Check Value)，其實與雜湊函數所產生的雜湊值意義相近，只是HMAC的演算法更加安全。

認證步驟

使用AH認證功能的步驟大致如下：

  1. 傳送端與接收端首先經由金鑰交換協定，讓雙方各自有一把相同的工作金鑰(Ks)。

  2. 傳送端利用Ks計算封包資料的ICV，然後將ICV附在封包內的AH表頭中，一起送給接收端。

  3. 接收端利用Ks計算封包資料的ICV，然後與傳送端附在封包內的ICV相互比對。若兩者不同，代表這個封包有問題。若兩者相同，即完成封包確認的動作。

傳輸模式與通道模式

AH協定支援傳輸模式和通道模式。傳輸模式又稱為點對點(End-to-end)模式。使用此模式時，傳送端與接收端都必須移植IPSec功能。若要建立區域網路內兩台電腦的IPSec連線，即可使用傳輸模式。

使用傳輸模式時，原來的IP封包的格式大致不變，僅在原有的IP表頭與TCP表頭之間加上AH表頭。然後針對整個封包計算ICV，再將ICV記錄到AH表頭中。

圖2：AH傳輸模式的封包
圖2：AH傳輸模式的封包

請注意，上圖只是一個簡單的示意圖，HMAC在計算時並非包含封包中的每個欄位。實際上，IP封包內有些欄位在封包傳送過程中會不斷改變，例如，IP封包每經過一台路由器，TTL欄位值即會減少1。因此，HMAC在計算時，會排除這些變動欄位。同理，使用ESP協定加密封包時，也會排除這些變動欄位。

通道模式又稱為中介(End-to-intermediate)模式。使用此模式時，傳送端與接收端有一方未移植IPSec功能，而必須透過其他裝置來處理。例如，傳送端具有IPSec功能，接收端本身沒有IPSec功能，但接收端所在的區域網路路由器有IPSec功能，如此即適合使用通道模式。

使用通道模式時，會在原來的IP表頭前加上新的IP表頭與AH表頭。然後針對整個封包計算ICV，再將ICV記錄到AH表頭中。

圖3：AH通道模式的封包
圖3：AH通道模式的封包

防止重送攻擊

不論AH或ESP都提供防止重送攻擊的功能，運作的方式與原理皆同。

所謂重送攻擊(Replayed Attack)是指第三者從網路中截取認證訊息，並再稍後原封不動地將訊息送出，以假扮該訊息的原始送出者。重送攻擊並非屬於密碼學/密碼破解的範疇，因此認證協定必須使用額外的資訊來加以防範。

相對於連接導向傳輸（connection-oriented）的TCP協定，IP屬於非連接導向傳輸（connectionless）的協定，在封包傳送過程中，不會確認每一個封包是否完整送達目的地，即使接收一方沒收到某個IP封包，也不會要求傳送一方重送封包。因此，傳統的IP封包特別容易遭受重送攻擊。有鑑於此，IPSec利用序號(Sequence Number)欄位，將每個封包加以編號，以防止重送攻擊。

假設現在A要使用IPSec認證表頭來傳送資料給B。當A、B之間的安全聯結決定後，以該安全聯結所送出的封包會從0開始逐一按順序編號，這些編號會記錄在序號欄位中。序號欄位的長度為32個位元，因此，當編號超過232-1時，A、B之間必須重新協調新的安全聯結，使序號欄位再從0開始編起。

至於在B端則必須設有封包接受範圍(window size)的機制。封包接受範圍是一個固定的常數，預設值為64。這個機制的主要原理就是接收一方必須記錄所收到IPSec封包的編號，並據以檢查封包是否有問題。封包接受範圍會隨著新收到的封包而往前移。例如，B目前所收到封包的最大編號為N，則B會記錄編號N至編號N-63封包的接收狀態：

圖4：接收方所收到封包最大編號為N時的情形
圖4：接收方所收到封包最大編號為N時的情形

如果收到的封包位於接受範圍內(例如，編號為N-2的封包)，經過認證無誤後則加以記錄。

圖5：
圖5：收到N-2封包後的情形

如果收到的封包位於接受範圍的左側，或是在接受範圍內但與先前已收到的封包編號重覆，則丟棄該封包，並記錄此事件。

圖6：重覆收到編號為N-1的封包，則丟棄該封包並記錄此事件
圖6：重覆收到編號為N-1的封包，則丟棄該封包並記錄此事件

如果收到的封包位於接受範圍的右側，經過認證無誤後，將接受範圍的右端往右移至新收到封包的位置，並記錄該封包。

圖7：收到編號為N+3的封包，則封包接受範圍往右移三個單位
圖7：收到編號為N+3的封包，則封包接受範圍往右移三個單位

藉由上述機制，接收端可控管所有收到的IPSec封包，有效防止重送攻擊。

AH表頭欄位

AH表頭實際上包含了以下幾個欄位：

  • Next Header(8個位元)：記載後續表頭的類型。

  • Payload Length(8個位元)：記載Authentication Data欄位的長度，單位為32位元Word)，再減去2。

  • Reserved(16個位元)：保留將來之用。

  • Security Parameters Index(32個位元)：用來識別安全聯結。

  • Sequence Number(32個位元)：IP封包序號，可用來防止重送攻擊。

  • Authentication Data(長度不定)：儲存IP封包的ICV或MAC。

圖8：AH表頭的欄位
圖8：AH表頭的欄位

資料封裝加密

資料封裝加密(Encapsulating Security Payload，ESP)可提供封包加密的功能，也可選擇性地再加上認證的功能。

演算法

ESP支援CBC(Cipher Block Chaining)模式的DES加密演算法。

DES(Data Encryption Standard)是由IBM研發的加密方法，在1977年經美國官方採用而成為加密標準。標準版的DES使用64位元的區塊加密(Block Cipher)與56位元的秘鑰，在當時可說是相當安全的加密法。不過，近年來隨著電腦硬體運算能力的快速進步，加上破解密碼的技術也日新月異，DES已經稱不上是很安全的演算法了。

DES日後衍生出許多版本，後來的版本加密能力都遠勝過DES。以下列舉幾種ESP所支援的加密法：

  • Three-key triple DES

  • RC5

  • IDEA

  • Three-key triple IDEA

  • CAST

  • Blowfish

ESP使用的加密步驟倒是沒有什麼特別之處，就是在傳送端進行加密，在接收端進行解密。

傳輸模式與通道模式

ESP與AH相同，支援傳輸與通道兩種使用模式，使用的時機也類似。

  • 傳輸模式

    圖9：ESP傳輸模式的封包
    圖9：ESP傳輸模式的封包

  • 通道模式

    圖10：ESP通道模式的封包
    圖10：ESP通道模式的封包

除此之外，ESP防止重送攻擊的功能與AH完全相同，不再贅述。

ESP的認證功能

ESP可選擇性地加上認證功能。使用時，ESP會先加密封包，再計算封包的ICV，然後在封包最後面加上一個認證欄位，用來儲存ICV。也就是說，ICV不在加密範圍內。接收端收到封包後，先進行比對ICV值，確認無誤後再將封包解密。

ESP表頭欄位

ESP表頭中主要包含下列欄位：

  • Security Parameters Index：用來識別安全聯結。

  • Sequence Number(32個位元)：IP封包序號，可用來防止重送攻擊。

  • Payload Data(長度不定)：指封包所負載的資料，內容包括上層協定的表頭，以及實際要傳送的資料。

  • Padding(0至255個位元組)：這個欄位必須特殊，目的是為了將Payload Data補足一定的長度，以符合加密法對區塊的要求。

  • Pad Length(8個位元)：用來記載padding的長度。

  • Next Header(8個位元)：記載後續表頭的類型。

  • Authentication Data(長度不定)：用來記載ICV。

圖11：ESP表頭的欄位
圖11：ESP表頭的欄位

設定IPSec的選項

IPSec相關設定在Windows是由群組原則(Group Policy)來負責，以方便管理員集中管理。換言之，管理員可從Windows網域控制站(Domain Controller)上，控制所有電腦的IPSec設定。

群組原則可套用在整個網路區段(Site)、網域、組織單位，也可直接套用在個別的電腦。因此，管理員可依實際須要，根據群組原則的套用規則來決定如何套用IPSec。

如何規劃IPSec

管理員在規劃網域內的IPSec設定時，可遵循以下步驟：

  1. 評估區域網路內資料傳輸的安全類型，例如，完全不需要安全保護、需要中等程度的安全保護等等。

  2. 根據這些安全類型來建立安全性原則。

  3. 將安全性原則套用至現有的群組原則上，或是直接套用在指定的電腦上。

建立IP安全性原則

IP安全性原則（IP Security Policy）有點類似範本。管理員歸納出所需的安全類型後，即可建立對應的IP安全性原則，然後再將這些原則套用至合適的對象。IP安全性原則最好不要太多，以免造成管理工作過度複雜。

在每項IP安全性原則中，可包含多項的安全性規則(Security Rule)。安全性規則定義了IPSec的相關參數。以下為安全性規則的設定項目：

  1. IP篩選器清單(IP Filter Lists)：篩選器清單中列出了IP安全性原則中所有的篩選器。篩選器主要是用來定義IPSec的來源與目的位址，以及IPSec所要涵蓋的上層通訊協定。

  2. 篩選器動作(Filter Actions)：篩選器動作定義封包處理的方式。

  3. 安全性方法(IPSec Security Methods)：安全性方法定義了IPSec的安全設定，例如，指定使用AH或ESP協定、指定演算法等等。使用時，通常會定義多種安全性方法，比較容易與對方達成協議並建立IPSec連線。管理員可自訂安全性方法，也可使用內建的兩種安全性方法：

    • 高(High)：使用ESP協定。

    • 中(Medium)：使用AH協定。

    • 自訂(Custom)：若要同時使用AH或ESP，可在此自訂安全性方法。此外，也可選擇認證與加密所使用的演算法，以及工作金鑰的建立原則。

  4. 驗證方法(IPSec Authentication)：有三種在建立IPSec連線時確認對方身份的驗證方式，使用IPSec的雙方必須協議使用一致的驗證方式，才能建立IPSec連線。

    • Kerberos V5 protocol。

    • 使用下列憑證授權單位(CA)的憑證：支援X.509規格的憑證。

    • 使用這個字串來保護金鑰間的交換(預先共用金鑰)：若建立IPSec連線的雙方在事前已共享秘鑰(密碼或字串等等)，則可在此填入秘鑰。

  5. 連線類型(IPSec Connection Types)：指定安全規則要套用至哪些連線類型。

    • 所有網路連線(All Network Connections)：套用至電腦的全部網路連線。

    • 區域網路(Local Area Network)：僅套用至區域網路連線。

    • 遠端存取(Remote Access)：僅套用至遠端存取或撥號連線。

  6. 通道設定(IPSec Tunneling)：這就是先前提到的通道模式功能。

    • 這個規則並沒有指定IPsec通道(This rule does not specify an IPSec tunnel)：不使用通道模式。

    • 由這個IP位址來指定通道的結束點(The tunnel endpoint is specified by this IP Address)：使用通道模式，並指定對方的IP位址。

結語

與現有的一些安全性解決方案相比，IPSec的確提供了較大的使用彈性，以及較為廣泛的保護。不過，在使用IPSec來建立安全連線的同時，也要了解由於IPSec需傳輸要額外的資料，因此會降低整體網路傳輸效能。此外，加密與解密的動作也會耗費不少系統的資源。管理員必須在安全性與效能之間取得平衡點，才能有效地提升網路安全。

本文參考資料：

  • Security Architecture for the Internet Protocol / RFC 2401 Nov. 1998 / Kent & Atkinson

  • IP Authentication Header / RFC 2402 Nov. 1998 / Kent & Atkinson

  • IP Encapsulating Security Payload / RFC 2406 Nov. 1998 / Kent & Atkinson

  • Internet Cryptography / Addison Wesley 1997 / Richard Smith

  • Cryptography and Network Security / Prentice Hall 1999 / William Stallings