|
|
|
10-6 IKE 協定
10-6-1 IKE 協定簡介 (A) IKE 協定功能 『網際網路金鑰交換』（Internet Key Exchange, IKE）是一種混合協定，係將 Oakely 與 SKEME 兩個鑰匙交換協定結合於 ISAKMP 協定上，標準規範由 RFC 2409文件敘述。ISAKMP 協定為了提高鑰匙交換的變異性，僅制定鑰匙交換的基礎架構，並沒有規範鑰匙交換的實作規範，一方面為了配合鑰匙技術的快速發展，另一方面也可阻斷推陳出新的駭客攻擊手段。倘若 ISAKMP 同時制定了鑰匙交換的實作協定，一旦有更新的隱密技術或攻擊手法被發展出來時，勢必需修改其運作程序，才能滿足新的環境需求。值得注意的是，一個已被 Internet 網路廣泛使用的通訊協定，無論是修改或增加功能，都是耗時費力的重大工程。譬如，已在網路上應用一段不短時日的 IPv4，很多人都知道若想把它改成 IPv6，實在是困難重重。ISAKMP 協定有鑑於此，於是將鑰匙交換協定分離出來，並以選項的方式，由各組織單位依其所需選擇不同的交換協定，不但可以滿足不同環境的需求，也可隨時增加它的功能。雖然目前 IKE 只制定 Oakely（RFC 2412）與 SKME [91] 兩種交換協定，但相信陸續會有更新的協定被加入。 到底 IKE 協定是如何將 Oakely 與 SKEME 協定嵌入 ISAKMP 協定中？記得我們在介紹 ISAKMP 協定時，曾經提到許多與鑰匙或認證有關的承載，譬如，金鑰交換承載、雜湊承載、簽章承載等等，其承載資料中並沒有指定何種資料型態，大多只說明依照 ODI 編碼方式。又許多交換型態，譬如，部份保護交換、僅供認證交換等等，也沒有說明如何產生加密或認證金鑰。既然 ISAKMP 協定僅提供一個運作架構，IKE 協定就是在這運作架構中來實作鑰匙交換的工作，簡單的說，IKE 就是利用 ISAKMP SA 中，與鑰匙交換有關的承載或交換型態，作為實作鑰匙交換的工作；然而協議雙方之間鑰匙交換的運作程序就依照 Oakely 與 SKEME 協定所規範的方式。礙於篇幅，本書主要以 Oakely 協定為介紹重點（RFC 2409 也是如此）。(請參閱『資訊與網路安全技術』) (A) IKE 協定特性 IKE 協定主要是提供 IPSec 通訊中所需的一切『鑰匙』（Key，或稱金鑰），其中除了包含加密與認證金鑰的產生，還可選擇不同的鑰匙產生技術、以及協議各種加密或認證系統。我們首先將 IKE 協定的一些特性歸類起來，希望對讀者有所幫助： ² 兩階段協商：為了配合 ISAKMP 協定運作，IKE 亦採用兩階段的協商方式，第一階段協商是建立安全通訊連線；第二階段才真正進入鑰匙交換程序。 ² 協商項目：IKE 協定至少必須協商下列相關演算法： l 加密演算法（Encryption Algorithm），如 DES。 l 雜湊演算法（Hash Algorithm），如 MD5 或 SHA。 l 認證方法（Authentication Method），如 HMAC。 l Diffie-Hellman 演算法所需的訊息群組，如 MOPD（容後介紹）。 ² 認證或加密金鑰產生：在 IKE 協定上，針對認證或加密金鑰產生有下列三種方式： l 預先共享金鑰（Pre-Shared Key）：雙方通訊之前利用其他管道，將秘密金鑰分配給雙方；一般大多採用 KDC 系統（如 Kerberos）系統來分配金鑰。 l 會議金鑰（Session Key）：雙方利用 Diffie-Hellman 演算法，以互相交換鑰匙材料，所計算產生的金鑰。 l 公開金鑰（Public key）：係利用憑證授權（CA）中心所發給的公鑰，互相認證彼此身份，並利用它傳遞『主密鑰』(Master Secret)。 ² 『完全順向密鑰』（Perfect Forward Secret, PFS）：如果僅能用一把秘密金鑰加密或解密，而沒有另外其他鑰匙可以取代的話，稱之為『完全順向加密』（PFS）。IKE 協定所建立的會議金鑰，就是必須達到 PFS 的特性。 ² 『虛擬亂數函數』（Pseudo-Random Function, PRF）：係嵌入鑰匙的雜湊演算法，如 HMAC-MD5 等。IKE 為了增加鑰匙的複雜度，通常利用 PRF 函數計算鑰匙材料，以得到相關鑰匙參數。但許多金鑰交換協定之中，並未包含協議 PRF 函數的產生方式，因此，實作時必須規範採用何種 PFR 函數。 其實計算鑰匙時，如何使所產生的鑰匙具有完全順向密鑰（PFS）功能，需賴 PRF 函數的重複計算，唯經由 PRF 函數重複計算所產生的鑰匙，比較能接近 PFS 所要求的功能。 10-6-2 IKE 交換模式 ISAKMP 主要定義金鑰交換與各種承載（ISAKMP Payload）的基礎架構，而 IKE 協定則將實現的金鑰交換程序嵌入 ISAKMP 所定義的架構，即IKE 協定（Oakely 與 SKME）係利用 ISAKMP 承載作為攜帶交換鑰匙的訊息，並且依照 ISAKMP 交換類別（16-8 節介紹）達成金鑰交換的運作程序。換句話說，Oakely 主要定義運作『模式』（Mode），而 ISAKMP 則定義協商『階段』（Phase），至於如何將『模式』的運作程序嵌入協商『階段』裡，則與交換功能的型態有關。 (A) 兩階段協商模式 簡單的說，就 ISAKMP 的基礎架構而言，第一階段協商既然是建立安全性的 ISAKMP SA，所以 Oakely 必須將某些運作『模式』嵌入此階段之中；同樣的道理，第二階段既然ISAKMP利用所建立的安全連線協商相關 SA 的參數值，所以 Oakely 亦需將某些『模式』嵌入其中。至於兩個階段中應該嵌入那些『模式』，則必須視通訊所需的交換型態而定，因此我們必須先了解 Oakley 到底定義了那些『運作模式』才行，以下有四種定義： ² 主要模式（Main Mode）：主要功能是協商雙方安全機制，協議出認證與加密所需的會議金鑰（也許使用 Diffie-Hellman 演算法），並認證雙方身份。其實它的功能非常類似於 ISAKMP 的『識別保護交換』；此模式主要應用於 ISAKMP 的第一階段協商。 ² 積極模式（Aggressive Mode）：此模式非常類似於 ISAKMP 的『積極交換』，其實就是它的實作。積極模式是為了簡化主要模式而來，主要目的是要認證雙方身份，因此可以應用於 ISAKMP 協定的第一階段協商。 ² 快速模式（Quick Mode）：此模式主要應用於有保護的連線下，從事鑰匙交換的工作，所以在此模式下交換的承載，都經過加密編碼處理過；此模式主要應用於 ISAKMP 的第二階段協商（與任何 ISAKMP 交換不類似）。 ² 新群組模式（New Group Mode）：主要應用於 Diffie-Hellman 演算法協議出新的演算群組。在 IKE 協定上，Diffie-Hellman 有三個亂數群組供建立會議金鑰所需，且這些群組是公開的，此運作模式就是用來協商使用哪一個群組；此模式可應用於ISAKMP 的兩個協議階段（與任何 ISAKMP 交換不類似）。 由以上敘述可以了解，ISAKMP 的第一階段協商中可能用到主要模式、積極模式或新群組模式，至於第二階段協商則可能用到快速模式或新群組模式。無論何種模式都必須被嵌入於 ISAKMP 交換種類之中，其中主要模式與積極模式可能被嵌入的交換類別如表 10-2 所示。但快速模式與新群組模式並不屬於 ISAKMP 交換種類，因此，IANA 另外定義兩個交換種類以滿足 Oakely 協定的需求，表示值如下： ² 快速模式：32 ² 新群組模式：33 (B) 承載訊息表示法 無論是主要模式、積極模式、快速模式或新群組模式，都是由 ISAKMP 的各種承載來封裝。譬如，主要模式或積極模式是利用提案承載來封裝，而每個提案承載中可再包含若干個轉換承載，其中每一轉換承載表示一個安全機制的訊息。在進入運作程序前，我們先介紹會使用到的承載與訊息之表示方法： ² HDR：代表 ISAKMP 標頭（Header）；而 HDR* 表示標頭以後的承載都是經過加密編碼的。 ² SA：代表一個 SA 承載，其中可能攜帶一個或一個以上的提案承載，以及其相關的轉換承載。 ² KE：代表金鑰交換承載。 ² IDx：代表身分證明承載，若 x = ii 或 ir，係表示 ISAKMP 發起者（Initiator）與回應者（Responder）的身份證明，若x=ui 或 ur，則表示使用端（非 ISAKMP SA）之發起者與回應者的身分證明。 ² <P>_b：ISAKMP 封包內的承載實體（Payload Body），其中不包含承載標頭（Payload Header）。 ² HASH：雜湊承載。 ² CERT：憑證承載。 ² SIG：簽章承載。 ² Nx：隨機承載（Nonce Payload），若 x = i表示此隨機值是由發起者（Initiator）傳送若 x = r，則表示由回應者（Responder）發出。 ² Ck-I 與 Ck-R：ISAKMP 封包標頭上的發起者與回應者的 Cookie 值。 ² gxi 與 gxr：發起者與回應者的公開 Diffie-Hellman 值。 ² prf(key, msg)：表示利用鑰匙 key 對訊息 msg，經過某一種雜湊演算法計算後，所得到『虛擬亂數函數』（PRF）的值。 ² SKEYID：『共享金鑰標示』；係由雙方交換『秘密材料』（Secret Material）所推演出來的一個字串，並作為產生各種鑰匙的依據。 ² SKEYID_e：係 ISAKMP SA 為了達成資料隱密性功能，所需產生加密金鑰的『鑰匙材料』（Keying Material）；由 SKEYID 計算而來。 ² SKEYID_a：係 ISAKMP SA為了達成認證功能，所需產生認證金鑰的『鑰匙材料』；由 SKEYID 計算而來。 ² SKEYID_d：是非 ISAKMP SA 所需產生『衍生鑰匙』（Derive Key）的『鑰匙材料』；由 SKEYID 計算而來。 ² <x>y：代表資料（x）經過鑰匙（y）所編碼。 ² x | y：代表 x 和 y 串接（Concatenation）在一起。 ² [x]：代表 x 是選項，可有可無。 10-6-3 IKE 鑰匙計算 『共享金鑰標示』（Shared Key Identifier, SKEYID）係計算各種鑰匙材料的基本要素，也是IKE 協定制定 SKEYID 的基本產生方法。在第一階段協商中包含：數位簽章認證、公鑰認證、修正型公鑰認證、以及預先共享金鑰認證等四種方法，每一種認證系統所產生 SKEYID 的方法如下： 數位簽章：SKEYID = prf(Ni_b | Nr_b, gxy) 公鑰加密：SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R) 共享金鑰：SKEYID = prf(pre-shared-key, Ni_b | Nr_b) 其中 prf 表示採用某一種 PRF 函數。基本上，IKE 並沒有規定應該採用何種演算法，但至少必須提供 HMAC-MD5 與 HMAC-SHA 兩種方法。 經過主要模式或積極模式交換訊息之後，可計算出下列三種鑰匙材料： SKEYID_d = prf(SKEYID, gxy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | gxy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | gxy | CKY-I | CKY-R | 2) 其中 “prf” 是雙方協議的某一種雜湊演算法計算出來的虛擬亂數；gxy 是雙方互相傳送鑰匙材料之後，並經由 Diffie-Hellman 演算法計算得來的共享密鑰（Shared Secret）。CKY-I 與 CKY-R 是由 ISAKMP 封包標頭上取得的發起者與回應者 Cookie。為了提供未來通訊安全機制的延伸，數值 0、1、2 表示一個位元組的空間，以作為未來擴充使用（請參考 RFC 2409）。 依照 IKE 協定，在認證過程的交換訊息當中，發起者需產生 HASH_I，回應者產生 HASH_R 並作為雙方認證使用，產生的方法如下： HASH_I = prf(SKYID, gxi | gxr | CKY-I | CKY-R | SAi_b | IDii_b) HASH_R = prf(SKYID, gxr | gxi | CKY-R | CKY-I | SAi_b | IDir_b) 其中 gxi 與 gxr 表示雙方所交換的鑰匙材料、SAi_b 表示發起者 SA 承載實體（Payload Body）、IDii_b 與 IDir_b 表示發起者與回應者的身份識別承載實體。HSAH_I 與 HASH_R 主要運用在數位簽章認證方面，作為簽章與身份證明時使用；在公開金鑰或共享金鑰認證方面，則作為交換認證使用。 10-6-4 IKE 第一階段協議 第一階段協商，雙方除了協議安全機制外，還必須互相確認對方身份。基本上，協議安全機制的方法大多與認證方法有關，在 IKE 協定上，第一階段有下列四種身份認證方法：簽章認證、公開金鑰認證、修正型公鑰認證、預定共享金鑰認證，以下分別介紹這四種認證方法。 (A) 使用簽章認證 使用簽章認證表示雙方利用一個『共享密鑰』（Shared Secret）向某一筆資料簽署，再互相傳送給對方作為認證身份時使用。由此可見，雙方必須利用 KE 承載交換鑰匙材料，以建立雙方共享密鑰（SKEYID_a），並交換亂數承載（Nonce, Nr, Ni）來建立雜湊亂數（HASH_I 與 HSAH_R）。簽章認證有主要模式與積極模式，如圖 10-20 所示，主要模式的運作程序說明如下： ² 編號 (1) 與 (2)：發起者與回應者之間協調安全機制（ISAKMP SA），譬如，協議雙方進行鑰匙交換時，所採用的是 AH-MD5 安全套件（其他套件如表 16-4 所示）。 ² 編號 (3) 與 (4)：雙方進行鑰匙交換程序，其中 KE 承載為雙方進行 Diffie-Hellman 演算法所傳送的鑰匙材料。譬如，發送端傳送 gx 給回應端，且回應端亦傳送 gy 給發起者，雙方利用此鑰匙材料建立會議金鑰為 gxy。亂數承載（Ni 與 Nr）是作為反重複攻擊與計算 HASH_I 和 HSAH_R 時使用。
圖 10-20 IKE 第一階段 – 使用簽章認證 ² 編號 (5) 與 (6)：雙方除了利用會議金鑰將身分證明（或身份憑證）加密外，同時與協議出的數位簽章演算法（如HMAC-MD5）計算出虛擬亂數函數（PRF），並以 SIG_I（或 SIG_R）承載傳送給對方。 簡單的說，訊號 (1) 與 (2) 是雙方協議的安全套件，訊號 (3) 與 (4) 是交換所協議安全套件的相關鑰匙材料，再由這些材料計算出共享密鑰（SKEYID）與雜湊值，計算方式如下：（與前面介紹的相同） SKEYID = prf(Ni_b | Nr_b, gxy) SKEYID_d = prf(SKEYID, gxy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | gxy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | gxy | CKY-I | CKY-R | 2) HASH_I = prf(SKYID, gxi | gxr | CKY-I | CKY-R | SAi_b | IDii_b) HASH_R = prf(SKYID, gxr | gxi | CKY-R | CKY-I | SAi_b | IDir_b) 接下來，訊號 (5) 與 (6) 係利用上述所建立的共享密鑰來交換訊息，譬如利用 SKEYID_a 簽署 HASH_I 與 HASH_R 以得到 SIG_I 與 SIG_R；或利用 SKEYID_e 向所承載的資料加密。另外，憑證承載（CERT）為選項項目，如沒有的話，則需藉身份識別承載來互相確認身份。 圖 10-20 (b) 為積極模式的運作程序，可以看出他是由主要模式（圖 10-20 (a)）簡化而來，簡化的方式非常類似 ISAKMP 的積極交換。雖然積極模式對於雙方身分識別承載（IDi 與 IDr）並沒有經過加密保護，但在產生 HASH_I 與 HASH_R時已將這兩個承載加入，同時已得到相當的保護作用；所以攻擊者竄改 ID 承載時，雙方亦可由 SIG_I 與 SIG_R 檢測出來。另外，沒有利用憑證驗證身份，很容易遭受中間人攻擊，此點於應用時必須特別注意。因為積極模式的運作程序與主要模式大同小異，這裡就不再贅言了。 (B) 使用公鑰認證 利用公鑰（Public Key）認證，雙方雖無需協議出會議金鑰，但還是需要一個憑證授權（CA）中心來發行雙方公鑰（如 PKI 系統）。它的運作程序是雙方交換訊息（身份識別或亂數）時，傳送者先利用對方的公鑰加密，對方收到後再利用自己的私鑰（Private Key）解密，如此便能達到認證性與隱密性的功能。採用公鑰認證，必須使用非對稱加密演算法（如RSA 演算法），IKE 協定建議至少必須提供 PKCS #1 密碼系統。圖 10-21 為使用公鑰認證的運作程序，同樣可利用主要模式與積極模式來實現，我們就主要模式來介紹，有關積極模式的運作既然由主要模式簡化而來，在此不再另述（圖 10-21 (b)）。圖 10-21 (a)是以公鑰認證建立第一階段的協商，說明如下：
圖 10-21 使用公鑰認證之運作程序 ² 編號 (1) 與 (2)：雙方以 ISAKMP SA 協議採用何種安全機制。此範例是協議以公鑰認證機制，並保護雙方傳送的訊息。 ² 編號 (3) 與 (4)：雙方互相以對方的公鑰，向自己的身分識別承載加密（<IDi_b>PubKey_r 或 <IDr_b>PubKey_i），對方再以自己的私鑰（Private Key）解密。如果回應者擁有許多不同身份（或擁有許多 CA 中心），而有多把公鑰時，發起者必須加入亂數並將其加密（<Ni_b>PubKey_r），而身分證明與亂數的加密鑰必須相同。HASH(1) 是亂數與身分證明的雜湊值（雙方已協議出雜湊演算法），回應者利用私鑰向身分證明與亂數解密後，再依照協議的亂數演算法，計算出亂數值，如果與 HASH(1) 相同的話，表示使用相同配對的公/私鑰。除了雙方使用公鑰認證外，也可以傳送鑰匙材料（KE）來協議雙方的會議金鑰（Diffie-Hellman 演算法），作為爾後通訊時使用。 ² 編號 (5) 與 (6)：雙方利用公鑰（或會議金鑰）來保護協議中的訊息（隱密性功能），也可以利用雜湊演算法來認證雙方訊息的正確性（HASH_I 與 HASH_R）。 其中 HASH(1) 是一個雜湊值（雙方協議之雜湊函數），它是由發起者的亂數與身份承載所計算得來的，雖然可以避免中間人攻擊，但仍逃不過阻斷攻擊。 (B) 使用修正型公鑰認證 使用公鑰認證最大的缺點是，加密與解密的負荷過大（通常需較長的計算時間），這也是非對稱加密演算法的優點(增加安全性)。更何況公鑰認證需要四次加密/解密的過程（兩次公鑰加密、兩次私鑰解密），如此更顯得公鑰認證的低效益。如果我們可以稍加修改，在公鑰基礎架構上協議出對應的加密金鑰，然後利用對稱加密演算法來保護雙方所傳送的訊息，如此便可以提高效益了，這就是『修正型公鑰認證』的基本構想。 它的做法是，利用雙方所交換的 SA 與 Nonce 承載，各自製造出一個加密金鑰，然後雙方再利用此鑰匙向所交換的身份識別與鑰匙材料承載加密，如此一來，除了可以減少加密與解密的負荷，還可以增加安全性。只要將製造共享密鑰的亂數（Ni 與 Nr）利用對方的公鑰加密，接收端再利用自己的私鑰解密，攻擊者就很困難得到製造共享密鑰的材料。圖 10-22 為修正型公鑰認證之主要模式和積極模式的運作模式，我們還是用主要模式來介紹它的運作程序，說明如下：
圖 10-22 修正型公鑰認證之運作程序 ² 編號 (1) 與 (2)：雙方利用 SA 承載協調安全機制。 ² 編號 (3) 與 (4)：發起者利用對方公鑰向亂數（計算共享密鑰使用）加密，並與身份證明一同計算雜湊值（HASH(1)），傳給對方確認封包未經竄改。雙方利用協議的會議金鑰（Ke_i 與 Ke_r），向鑰匙材料（KE_b）與身分證明（IDi 與 IDr）加密，並相互傳輸。任何一方除了可以認證對方身份外，並可以協議出通訊所需的共享密鑰，亦即利用雙方的鑰匙材料（KE_b）所計算出來（容後介紹）。 ² 編號 (5) 與 (6)：雙方利用會議金鑰來執行加密與數位簽章的功能（HASH_I 與 HSAH_R，如 10-5-3 節介紹）。 到底如何利用 SA 交換來建立雙方的認證金鑰（Ke_i 與 Ke_r，兩者不相同）？簡單的做法是，自己先製造出自己的認證金鑰（Ke_i 或 Ke_r），並對某些訊息加密（ID 與 KE），再將製造出來的材料（SA 與 Nonce）傳送給對方；對方收到這些材料後，一樣製造出它的認證金鑰，並對他所傳送的訊息解密；其中我們只要針對某些材料（Nonce），使用對方的公鑰加密，就不怕他人窺視。 在編號 (3) 與 (4) 協議中，雙方互送一個經由對方公鑰加密過的亂數承載，其中只針對承載的內容加密（<Ni_b>Pubkey_r 與 <Ni_b>PubKey_i），而就利用這個亂數與雙方的 Cookie 號碼（CKY_I 與 CKY_R）製作會議金鑰的材料（Ne_i 與 Ne_r），如下： Ne_i = prf(Ni_b, CKY-I) Ne_r = prf(Ni_b, CKY-R) 其中“prf”為雙方協議的雜湊演算法的『虛擬亂數函數』（PNF）。接下來，我們以發起者（Initiator）為範例，說明製造認證與加密金鑰（訊號 (5) 與 (6) 使用）的步驟，如下： K1 = prf(Ne_i, 0) K2 = prf(Ne_i, K1) K3 = prf(Ne_i, K2) 則：Ke_i = K1 | K2 | K3 （”|”為串接記號） 在製造過程中，如果 K1（或 K2、K3）超過鑰匙所規範的長度時，只取較高位元部份，並捨棄較低位元。至於然而回應者的認證金鑰如同發起者一樣，不再另述。另外，如果採用 CBC 模式的對稱加密法時需要起始向量（IV），它將會被第一個 Nonce 承載所攜帶，並利用鑰匙 Ne_i 或 Ne_r 加密著，隨著此承載後面才是傳輸資料（HASH_I 或 HSAK_R），並利用鑰匙 K 加密著。 (C) 使用預定共享鑰匙認證 『預定共享鑰匙』（Pre-Shared Key）表示雙方為通訊之前，就各自擁有一支共享金鑰。至於此鑰匙是如何分配得來(經由人工轉送或其他等等)，不在 IKE 的處理範圍內。預定共享鑰匙確認的做法是，雙方交換鑰匙材料之後，再配合共享鑰匙製造出一把『共享密鑰』，如下：（如 10-5-3 介紹） SKEYID = prf(pre-shared-key, Ni_b | Nr_b) 接著再利用此共享密鑰（SKEYID）製造出其他加密金鑰。 圖 10-23 所示為使用預定共享鑰匙認證的運作程序，其中包含主要模式（圖 10-23 (a)）與積極模式（圖 10-23 (b)），我們依然只針對主要模式的運作程序加以介紹，如下： ² 編號 (1) 與 (2)：發起者與回應者之間協調 ISAKMP SA 的安全機制。 ² 編號 (3) 與 (4)：雙方交換亂數（Ni 與 Nr），並配合共享金鑰製造出共享密鑰（SKEYID）。另外，鑰匙材料承載（KE）在 RFC 2409 內並沒有明確規範使用方法（作者也不清楚），可能是攜帶起始向量時使用。 ² 編號 (5) 與 (6)：雙方利用該共享密鑰向身分證明（IDi 與 IDr）加密，並計算數位簽章（或雜湊演算）（HASH_I 與 HASH_R），以便互相通訊。
圖 10-23 預定共享金鑰認證之運作程序 一般積極模式主要應用於身分證明不需保護的情況下，所以通常僅做數位簽章（HASH_I 與 HASH_R），不適用於加密的動作。 10-6-5 IKE 第二階段協商 經過第一階段協商之後，通訊雙方已協議出安全套件（ISAKMP SA），並可確認對方身份無誤（交換 ID 或 CERT 承載），也已協議出共享密鑰（SKEYID），以及加密或認證密鑰（SKEYID_e、SKEYID_a 與 SKEYID_d）。如此一來，便可利用這些安全機制進行第二階段的協商。換句話說，第二階段是利用第一階段所建立的安全通道，來協商 IPSec SA 的安全機制，而且第二階段協商是希望在安全連線之下，建立相關 IPSec SA 的安全套件。我們可以發現，經過許多的運作程序，至今才真正進入協商『安全閘門』所需要的安全機制 SA，唉！可真辛苦。如此嚴密的措施就是為了防止在協商 SA 時，遭受攻擊者的竄改、偽裝或竊聽。到目前為止，總算可以清楚的分辨： ² ISAKMP SA：在第一階段的安全機制，並依此安全機制來保護第二階段協商。 ² IPSec SA：在第二階段中協商 VPN 的安全機制，又依照 SA 內所指定的安全協定，可區分為 AH SA 或 ESP SA 兩種。 然而，第二階段協商又可區分為下列三種運作模式： ² 快速模式 ² 新群組模式 ² ISAKMP 訊息交換 以下分別介紹之。 (A) 快速模式 『快速模式』（Quick Mode）並不是一個完整的訊息交換程序，僅是延續第一階段訊息的交換。也就是說，它必須配合第一階段，其中可能是簽章認證、公鑰認證、修正型公鑰認證或預定共享金鑰認證的交換訊息。並且快速模式的交換過程當中，所有 ISAKMP 封包的承載都是經過加密，並且在 ISAKMP 標頭（HDR）後面必須緊接著一個 HASH 承載，此 HASH 承載是用來認證該訊息，以及作為存活的證明。接下來 SA 承載必須緊接在 HASH 承載之後，而在 SA 承載之後必須緊接著 Nonce 承載，Nonce 承載上的亂數是作為反重複攻擊使用。如果需要利用提供 Diffie-Hellman 演算法來協商會議金鑰時，會緊接著一個攜帶鑰匙材料的 KE 承載，如需要身份識別，則必須加入 ID 承載。在這些承載之中，必須強調下列重點： ² HDR 標頭：如同圖 10-24中的連線類別 (3) 與 (4)，也就是說，該 HDR 標頭的 Message-ID 與 SPI 欄位已有固定數值。 ² SA 承載：表示欲協商安全套件，因此，它的後面會緊隨著一些提案承載，與相對應的轉換承載。 ² ID 承載：表示欲協商安全機制的身份識別，可能是某一網路位址（IP 位址），或網路位址附加傳輸埠口（TCP/UDP 埠口）（表示伺服器設備）。 第二階段協商是採用連線類別 (3) 與 (4)，表示之前雙方已協議出訊息標示（Message-ID）與 SPI 值。然而 ISAKMP 封包也是利用這兩個欄位來識別是 ISAKMP SA 或 IPSec SA。 在快速模式下，有一個重要的安全機制，稱之為『完全性順向機密』（Perfect Forward Secrecy, PFS）。在 PFS 機制上，雙方協議出一把保護資料的鑰匙，就不能允許另一把鑰匙的產生；換句話說，如果某鑰匙是被用來保護傳輸資料，則製造此鑰匙的材料，就不能拿來再製作其他鑰匙。如果依照這個機制，就不會有第二把重複鑰匙的產生；更進一步，即使此鑰匙被破解，仍不會影響到其他鑰匙所保護的資料，因為，鑰匙之間並沒有重複的資料可尋。 圖 10-24 為快速模式的運作程序，說明如下： ² 編號 (1) 與編號 (2)：發起者與回應者之間互相協議安全機制，如果協議中要求使用『完全性順向機密』（PFS）的機制時，雙方訊息必須包含鑰匙交換的訊息（KE）。另外，整個封包除了標頭以外，都經過第一階段所協議的安全機制加密過。 ² 編號 (3)：此封包是確認前面的交換訊息。
圖 10-24 快速模式的運作程序 在圖 10-24 中有三的重要的雜湊值，如下： HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE] [ | IDci | IDcr] ) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr | [ | KE] [ | IDci | IDcr] ) HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) 其中prf 表示經由協議出來的雜湊演算法，所計算出來的『虛擬雜湊函數』（PRF），M-ID 表示 ISAKMP 標頭上訊息欄位的『訊息標示』（Message ID）（如圖 16-4 所示）。在第二階段協商中，M-ID 是由發起者所產生的一個亂數，作為雙方連線的標記。IDci 與 IDcr 表示發起者與回應者欲協商設備的識別碼（c 表 Client 的意思），其中可能包含通訊協定、傳輸埠口、使用者名稱等等。另外，SKEYID 的產生方法請參考 16-4-3 節介紹。 依照不同的安全機制，對於 HASH 產生方式有許多選項，譬如協議時，需要檢視較詳細的雙方身份資料（如通訊協定、傳輸埠口、使用者名稱等等），則必須將 IDcr 與 IDci 兩個承載加入雜湊演算法之中。更重要的，如果雙方選擇採用『完全性順向機密』（PFS）機制時，表示雙方必須協議出一個獨一無二的會議金鑰，因此便需交換鑰匙材料（KE），也會將他加入 HASH 計算之中。 接下來，探討如何產生『鑰匙格式』（KEYMAT），KEYMAT 是產生各種鑰匙的基本元件；至於如何由 KEYMAT 產生加密或認證金鑰，這可必須依照各種密碼系統而定。無論如何，雙方依照所交換鑰匙材料製造出 KEYMAT 之後，就可自行製造出其他鑰匙，並且可以填入 SA 記錄之中（SAD 資料庫）。依照不同的安全強度需求，製造 KEYMAT 有下列三種方法： ² 不採用『完全性順向機密』的安全機制：表示會議金鑰是由一般性資料產生，而沒有任何交換鑰匙材料（KE），則新的鑰匙格式如下： KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b) 其中，SKEYID_d 是由第一階段協商出來的；protocol 與 SPI（Security Parameter Index）兩者都是由 ISAKMP 封包上的『提案承載』（Proposal Payload）取得，其中protocol 表示雙方的通訊協定（IPSec AH 或 IPSec ESP）；SPI 的產生就較為複雜，如果僅是 ISAKMP 封包，則 SPI 是由 Initiator Cookie 與 Responder Cookie 兩個欄位所組成；如果是 IPSec 封包，則 SPI 是由 IPSec 標頭上的 SPI 欄位取得。 ² 採用『完全性順向機密』的安全機制：表示是經由雙方交換會議材料，再計算出來新的會議金鑰。當交換鑰匙材料之後，會依照 Diffie-Hellman 演算法計算出鑰匙基本元素：g(gm)xy，新鑰匙格式如下： KEYMAT = prf(SKEYID_d, g(gm)xy | protocol | SPI | Ni_b | Nr_b) ² 重複連結技巧：在某些安全性要求較高的情況，可使用重複連結技巧來製作鑰匙格式，其製作技巧如下：（比使用單一個 prf 計算來得安全） KEYMAT = K1 | K2 | K3 | … 其中： K1 = prf(SKEYID_d, [g(gm)xy] | protocol | SPI |Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | [g(gm)xy] | protocol | SPI |Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | [g(gm)xy] | protocol | SPI |Ni_b | Nr_b) … 等等 如果採用短暫使用的 Diffie-Hellman（Ephemeral Diffie-Hellman）機制，來交換鑰匙材料（g(gm)xy），也就是說，所交換出來的鑰匙格式僅使用一次（或較短暫的時間）；下一次通訊時，必須再重新協議新的鑰匙格式。在這種情況下，第一階段協商所產生的 SKEYID_e 與 SKEYID_a 將不會被使用於快速模式的協商之中，兩者僅提供於第一階段的認證（SKEYID_a）與加密（SKEYID_e）使用。 在快速模式的運作程序中，也允許同時建立多個 SA 之間的鑰匙交換。如圖 10-25 所示，發起者傳送兩個 SA（SA0 與 SA1），而回應者也發送兩個 SA（SA0 與 SA 1）給發起者，就每一個 SA 都是獨立且單方性的特性而言，其實它們之間已經建立了四個安全關聯。
圖 10-25 快速模式的多重 SA 協商 (B) 新群組模式 『新群組模式』（New Group Mode）的運作時機是，當建立完成第一階段協商之後，雙方才可以協商建立新的群組，但這個時機是在還未進入第二階段協商之前，因此，它可以屬於第一階段或第二階段協商。但每一次執行新群組模式運作時，必須再重複執行第二階段交換鑰匙的程序，這是因為製作鑰匙材料已經改變，而必須經過交換程序再產生新的鑰匙。 就我們所知道，IKE 協定是利用 Diffie-Hellman 演算法來計算雙方所需的共享金鑰，而該演算法需要一個公開的亂數來作為計算鑰匙的基本元素（Prime）；為了符合協議此亂數的需求，Oakley 協定便定義了四個群組的基本元素，所以新群組模式主要是用來協議應該採用哪一群組，其運作程序如圖 10-26 所示。
圖 10-26 新群組模式的運作程序 雙方協議群組模式的訊息是存放於 SA 的『提案承載』內，其中 HASH(1) 與 HASH(2) 的計算方法相同，如下： HASH(1) = prf(SKEYID_a, M-ID | SA) HASH(2) = prf(SKEYID_a, M-ID | SA) 上述中， HASH(1) 與 HASH(2) 是 prf 計算的輸出值，使用 ISAKMP 封包標頭上的訊息欄位（M-ID）與 SA 提案承載（包含標頭與承載）的連結值，及 SKEYID_a 經過某一雜湊演算法所計算得來的。 (C) ISAKMP 訊息交換 當 IPSec SA（快速模式）建立完成之後，便可以利用『ISAKMP 訊息交換』（ISAKMP Information Exchange）協定來交換訊息；此交換模式與 ISAKMP SA 建立之後再交換訊息沒有兩樣，都是利用連線類別 5，只不過兩者交換訊息有所不同而已。其運作程序如圖 10-27 所示。
圖 10-27 ISAKMP 訊息交換的運作程序 圖 10-27 中，N/D 表示傳送 ISAKMP 通知承載（Notify Payload）或 ISAKMP 刪除承載（Delete Payload）；HASH(1) 是 prf 計算的輸出值，其計算方法如下： HASH(1) = prf(SKEYID_a, M-ID | N/D) 這裡必須強調一下，經過第二階段協商後，不同 ISAKMP SA 之間的訊息標示（M-ID）是不會重複的，而整個封包的承載是經由 SKEYID_e 所加密。
|
翻轉工作室：粘添壽
網路規劃與管理技術：
翻轉電子書系列：
|
