網路層的護身符(下):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

顯示: