VPN：IKE密鑰交換原理

在采用IKE動態協商方式建立IPSec隧道時，SA有兩種：一種IKE SA，另一種是IPSec SA。建立IKE SA目的是為了協商用于保護IPSec隧道的一組安全參數，建立IPSec SA的目的是為了協商用于保護用戶數據的安全參數，但在IKE動態協商方式中，IKE SA是IPSec SA的基礎，因為IPSec SA的建立需要用到IKE SA建立后的一系列密鑰。本文介紹在IKE動態協商方式建立IPSec隧道時的基本工作原理。

1. IKE動態協商

手工方式建立SA存在配置復雜、不支持發起方地址動態變化、建立的SA永不老化、不利于安全性等缺點。下面介紹動態協商方式的好處，以及IKE與IPSec的關系。

1.1 IKE動態協商方式的好處

采用IKE協議為IPSec自動協商建立SA，可以得到以下好處。

（1）降低了配置的復雜度

在IKE動態協商方式下，SPI、認證密鑰和加密密鑰等參數將自動生成，而手工方式中需根據SA出方向和入方向分別指定。

（2）提供抗重放功能

IPSec使用AH或ESP報頭中的序列號實現抗重放（不接受序列號相同的數據包）。當AH或ESP報頭中的序列號溢出（也是達到了最大值，不能再繼續往下編號，要開始新一輪的重新編號了）后，為實現抗重放，SA需要重新建立，這個過程需要IKE協議的配合，所以手工方式下不支持抗重放功能。

重放攻擊是指再次發送已發送過（數據包序列號與原來一樣）的數據包，攻擊者可采用這種方式對目的主機進行攻擊，使目的主機不斷接收本已接收、解析重復的數據包而大量消耗資源，甚至崩潰。抗重放就是抵抗這種重放攻擊。

（3）支持協商發起方地址動態變化情況下（如采用PPPo E撥號方式接入Internet）的身份認證，手工方式不支持，只能適用于在兩端都采用專線連接方式接入Internet情形。

（4）支持認證中心CA（Certificate Authority）在線對對等體身份的認證和集中管理，有利于IPSec的大規模部署，手工方式不支持在線認證方式。

（5）通過IKE協商建立的SA具有生存周期，可以實時更新，降低了SA被破解的風險，提高了安全性。

生存周期到達指定的時間或指定的流量，SA就會失效。在SA快要失效前，IKE將為對等體協商新的SA。在新的SA協商好之后，對等體立即采用新的SA保護通信。生存周期有兩種定義方式：

• 基于時間的生存周期，定義了一個SA從建立到失效的時間。
• 基流量的生存周期，定義了一個SA允許處理的最大流量

1. 2 IKE與IPSec的關系

IKE 協議建立在 ISAKMP（Internet Security Association and Key Management Protocol，Internet安全聯盟和密鑰管理協議）定義的框架上，是基于UDP的應用層協議（對應UDP 500端口）。它為IPSec提供了自動協商交換密鑰、建立SA的服務，能夠簡化IPSec的使用和管理。

其實IKE也不是一個單獨的協議，它包括三大協議：ISAKMP（Internet Security Association and Key Management Protocol，因特網安全聯盟和密鑰管理協議）、Oakley （Oakley Key Determination Protocol，奧利克密鑰確定協議）和SKEME（Secure Key Exchange Mechanism for Internet，因特網安全密鑰交換機制）。ISAKMP主要定義了IKE對等體（IKE Peer）之間合作關系，建立IKE SA。Oakley協議是一個產生和交換IPSec密鑰材料并協調IPSec參數的框架（包括支持哪些安全協議）；SKEME協議決定了IKE密鑰交換的方式，主要采用DH（Diffie-Hellman）算法。

IKE與IPSec（包括AH和ESP協議）的關系如圖1所示，IKE是UDP之上的一個應用層協議（AH和ESP是網絡層協議），是IPSec的信令協議；IKE為IPSec協商建立SA，并把建立的參數及生成的密鑰交給IPSec；IPSec使用IKE建立的SA對IP報文加密或認證處理。

圖1 IKE與IPSec的關系示意

對等體之間建立一個IKE SA后，在IKE SA保護了IPSec隧道的情況下，再根據配置的AH、ESP安全協議等參數協商出一對IPSec SA，用于對等體間的數據在IPSec隧道中的安全數據傳輸。

IKE協議目前有IKEv1和IKEv2兩個版本。IKEv1版本使用兩個階段為IPSec進行密鑰協商并最終建立IPSec SA。第一階段，通信雙方協商建立IKE本身使用的安全通道（即隧道），即建立一對IKE SA。第二階段，利用這個已通過了認證和安全保護的安全通道建立一對用于保護隧道中數據安全傳輸的IPSec SA。而IKEv2版本則簡化了協商過程，在一次協商中可直接產生IPSec的密鑰，生成IPSec SA。

2. IKE的安全機制

IPSec應用方案之所以能在公網（如Internet）上安全地進行網絡通信，其重要原因是可在對等體間的整個隧道建立和數據傳輸過程中均有各種安全機制來做保障，這方面如果采用的是IKE來進行自動的密鑰交換和協商同樣可以做到，因為IKE本身就具有一整套自我保護機制，可以在不安全的網絡上安全地認證身份、分發密鑰。具體體現在以下幾種安全保護方面。

2.1 身份認證機制

當使用IKE在對等體間進行信息交換時，首先要識別對方的合法性，也就是身份認證問題。在IKE中可用于確定對等體身份（對等體的IP地址或名稱）的機制比較全面，包括預共享密鑰PSK（pre-shared key）認證、RSA數字證書（rsa-signature，或稱RSA數字簽名）認證和RSA數字信封認證。

（1）預共享密鑰認證

在預共享密鑰認證中，共享密鑰是作為密鑰生成材料的，通信雙方采用共享的密鑰用相同的哈希算法（也稱雜湊算法，或單向散列算法）對報文進行哈希運算，根據運算的結果是否與發送方發來的哈希一致來判斷所接收的數據是否被篡改，消息來源是否可靠。如果相同，則認證通過；否則認證失敗。

在大多數IPSec應用中都是采用配置比較簡單的預共享密鑰認證方法。

（2）數字證書認證

在數字證書認證中，通信雙方使用CA證書進行數字證書合法性驗證。在CA證書中，雙方有各自的公鑰（網絡上傳輸）和私鑰（自己持有）。發送方對原始報文進行哈希運算，并用自己的私鑰對報文計算結果進行加密，生成數字簽名。接收方使用發送方的公鑰對數字簽名進行解密，然后采用相同的哈希算法對解密后的報文進行哈希算，看運算的結果與解密發送方發來的哈希值是否相同。如果相同，則認證通過；否則認證失敗。

（3）數字信封認證

數字信封認證的基本原理是將對稱密鑰通過非對稱加密（即有公鑰和私鑰兩個）的結果向對方分發對稱密鑰的方法，類似于現實生活中的信件。我們知道，現實生活中的信件在法律的約束下可保證只有收信人才能閱讀信的內容。數字信封則采用密碼技術保證了只有規定的接收人才能閱讀被保密的內容。

在數字信封中，發送方采用對稱密鑰（需要發送方事先隨機產生一個對稱密鑰）來對要發送的報文進行數字簽名，然后將此對稱密鑰用接收方的公鑰來加密（這部分稱數字信封）之后，再將加密后的對稱密鑰連同經過數字簽名的報文一起發送給接收方。接收方在收到后，首先用自己的私鑰打開數字信封，即可得到發送方的對稱密鑰，然后再用該對稱密鑰解密原來被數字簽名的報文，驗證發送方的數字簽名是否正確。如果正確，則認證通過；否則認證失敗。

對于預共享密鑰認證方法，當有一個對等體對應多個對等體時，需要為每個對等體配置預共享的密鑰，工作量大，所以該方法在小型網絡中容易建立，但安全性較低。使用數字證書安全性高，但需要CA來頒發數字證書，適合在大型網絡中使用。而數字信封認證用于設備需要符合國家密碼管理局要求時使用（需要使用國家密碼管理局要求的哈希算法SM3），且此認證方法只能在IKEv1的主模式協商過程中支持。

以上所提到的用于身份認證的各種密鑰都屬于IKE認證密鑰，支持的算法有：MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3。MD5算法使用128位的密鑰，SHA-1算法使用160位的密鑰，SHA2-256、SHA2-384、SHA2-512分別采用256位、384位和512位密鑰，SM3使用128位密鑰。它們之間的安全性由高到低順序是：SM3>SHA2-512>SHA2-384>SHA2-256>SHA1>MD5。對于普通的安全要求，認證算法推薦使用SHA2-256、SHA2-384和SHA2-512，不推薦使用MD5和SHA1，對于安全性要求特別高的地方，可采用SM3算法。

2.2 數據加密機制

IPSec 的數據加密機制主要用在兩個方面：一是在IKE協商階段，保護所傳輸的用于身份認證的數據信息（如共享密鑰、證書、認證密鑰等），二是在IPSec隧道建立后保護在隧道中傳輸的用戶數據。但這里所說的數據加密機制所采用的對稱密鑰機制，即加密和解密采用相同的密鑰，而不是像數字證書身份認證和數字簽名應用中所采用的非對稱密鑰體系。

IKE支持的加密算法包括：DES、3DES、AES-128、AES-192、AES-256、SM1和SM4等。DES算法使用56位密鑰，3DES使用168位密鑰，AES-128、AES-192、AES-256分別使用128、192和256位密鑰，SM1和SM4均使用128位密鑰。這些加密算法的安全級別由高到低的順序是：SM4 > SM1 > AES-256 > AES-192 > AES-128 > 3DES > DES，推薦使用AES-256、AES-192和AES-128，不推薦使用3DES和DES算法，SM1和SM4僅建議在保密及安全性要求非常高的地方采用，因為它們的運算速度比較慢。非對稱密鑰體系中通常使用的是RSA或DSA（Digital Signature Algorithm，數字簽名算法）加密算法。

2.3 DH（Diffie-Hellman）密鑰交換算法

Diffie-Hellman算法是一種公開密鑰算法。通信雙方可在不傳送密鑰的情況下，僅通過交換一些數據，即可計算出雙方共享的密鑰。而且可以做到，即使第三方截獲了雙方用于計算密鑰的所有交換數據，也不足以計算出真正的密鑰。

DH主要用于IKE動態協商時重新生成新的IPSec SA所用的密鑰，因為它可以通過一系列數據的交換，最終計算出雙方共享的密鑰，而不依賴于在前期生成的密鑰生成材料。但DH沒有提供雙方身份的任何信息，不能確定交換的數據是否發送給合法方，第三方可以通過截獲的數據與通信雙方都協商密鑰、共享通信，從而獲取和傳遞信息，所以IKE還需要身份認證來對對等體身份進行認證。

2.4 PFS機制

PFS（Perfect Forward Secrecy，完善的前向安全性）是一種安全特性，指一個密鑰被破解后并不影響其他密鑰的安全性，因為這些密鑰間沒有派生關系。

IPSec SA的密鑰是從IKE SA的密鑰導出的。由于一個IKE SA協商可生成一對或多對有一定派生關系的IPSec SA，所以當IKE的密鑰被竊取后，攻擊者很可能通過收集到足夠的信息來非法導出IPSec SA的密鑰，這樣就不安全了。如果在生成IPSec階段啟用了PFS，即可通過執行一次額外的DH交換，生成新的、獨立的IPSec SA，這樣就可以保證IPSec SA密鑰的安全了。

3. IKEv1密鑰交換和協商：第一階段

IKEv1版本產生最終的IPSec SA是需要經過兩個階段，分別用來建立IKE SA和IPSec SA。下面先介紹第一階段。

IKEv1的第一階段的最終目的是在對等體之間創建了一條安全通道，建立對等體的IKE SA。在這個階段中，IKE對等體間彼此驗證對方，并確定共同的會話密鑰。這個階段需要用到Diffie-Hellman（簡稱DH）算法進行密鑰交換，完成IKE SA建立，使后面的第二階段過程的協商過程受到安全保護。

在IKEv1版本中，建立IKE SA的過程有主模式（Main Mode）和野蠻模式（Aggressive Mode，也稱“積極模式”）兩種交換模式。下面分別予以介紹。

3.1 主模式

在IKEv1的主模式的IKE SA建立過程中，包含三次雙向消息交換，用到了六條信息，交換過程如圖2所示。

圖2 主模式的密鑰交換和協商過程示意

這6條消息其實總體上是三個步驟，各包含兩條相鄰編號的消息。

第一個步驟對應的是消息①和②，是隧道兩端對等體間通過交換彼此配置的IKE策略協商好要共同采用的IKE安全策略，因為只有雙方都采用相同的安全策略才能相互識別對方加密的數據，并對對方身份進行正確認證。

第二個步驟對應的是消息③和④，是對等體間通過DH算法交換彼此的密鑰生成所需的參數信息（DH公開值和隨機數nonce等），建立兩端相同的一系列共享密鑰，主要包括用于在第二階段協商的身份認證密鑰和協商數據的加密密鑰。

第三步對應的是消息⑤和⑥，用已創建好的加密密鑰彼此相互發送各自的身份（如對等體的IP地址或名稱）和驗證數據（所采用的身份認證方式中的密鑰，或證書數據等），采用相應認證方法在對等體間進行身份認證。最終完成IKE SA的建立。

在正式進行消息交換前，發起方和接收方必須先計算出各自的cookie（在ISKMP報頭中，可以防重放和DoS攻擊），這些cookie用于標識每個單獨的協商交換消息。RFC建議將源/目IP地址、源/目端口號、本地生成的隨機數、日期和時間進行散列操作生成cookie。cookie成為在IKE協商中交換信息的唯一標識, 在IKEv1版本中為Cookie，在IKEv2版本中的Cookie即為IKE的SPI（安全參數索引）。

下面再具體介紹以上所提到的這6條消息。

（1）消息①和②用于IKE策略交換，是一個協商確認雙方IKE安全策略的過程，但這個交換過程的框架是由ISAKMP定義的，為SA的屬性和協商、修改、刪除SA的方法提供了一個通用的框架，并沒有定義具體的SA格式。

在這個過程中，發起方發送一個或多個IKE安全提議［包括5元組：認證方法（數字證書認證、預共享密鑰認證或數字信封認證）、加密算法（AES、DES或3DES等）、哈希算法（MD5或SHA等）、DH組、IKE SA的生存期］，響應方在本地查找最先與收到的安全提議匹配的IKE安全提議，并將這個確定的IKE安全提議回應給發起方，使發起方獲知雙方共同確定的IKE策略。這是為后面能在一個安全的環境之下協商IPSec SA打下基礎，因為這些IKE策略會直接提供對第二階段的IPSec SA協商的加密保護。

（2）消息③和④用于密鑰信息交換，是一個產生各種所需密鑰的過程。

首先雙方交換通過Diffie-Hellman算法計算出的公鑰和nonce值（一個隨機數），然后利用自己的公/私鑰、對方的公鑰、nonce值、配置的預共享密鑰（采用預共享密鑰認證方法時）等最終生成一系列用于第二階段的共享密鑰（兩端產生的密鑰是相同的）。例如，認證密鑰（稱之為skey ID_a）、加密密鑰（稱之為skey ID_e）以及可用于生成IPSec SA密鑰的密鑰材料（稱之為skey ID_d）。認證密鑰用于在IKE第二階段協商中為信道中傳輸的協商數據（非用戶數據）進行認證；加密密鑰用于在IKE第二階段協商中為信道中傳輸的協商數據進行加密。

如果采用預共享密鑰認證方法，為了正確生成以上各密鑰，每一個對等體必須找到與對方相對應的預共享密鑰，當有多個對等體連接時，每一對對等體的兩端都需要配置一個相同的共享密鑰。

（3）消息⑤和⑥用于對等體間的身份信息（如對等體的IP地址或名稱）和驗證數據（所采用的身份認證方式中的密鑰，或證書數據等），雙方進行身份認證。

這個過程的信息交換是受前面生成的加密密鑰（skey ID_e）進行加密保護的。當相互認證通過后，對等間的IKE SA建立就完成了，第二個階段協商IPSec SA所需的安全通道就會立即建立，兩端的VPN設備就可用第一個階段協商的安全策略對第二階段協商IPSec SA進行安全加密和認證。

3.2 野蠻模式

如圖3所示，野蠻模式只用到三條信息，消息①和②用于在對等體間協商IKE安全策略，交換DH公鑰、必需的輔助信息和身份信息（通常不以IP地址進行標識，而是以主機名進行標識的）。

圖3 野蠻模式的密鑰交換和協商過程示意

1）消息①中包括了發起方提供給響應方的IKE安全策略、本端密鑰生成信息（本端的DH公鑰）和身份信息（主要是對等體名稱），響應方在收到這些信息后，首先也是要在本地查找與發起方發來的IKE安全策略匹配的策略，如果找到即確定作為共同的IKE策略。然后利用確定的IKE安全策略、發起方發來的密鑰生成信息，以及本端的DH公/私鑰，一個nonce隨機數生成認證密鑰和加密密鑰，并根據發起方發來的身份信息對發起方的身份進行初步的驗證。

2）消息②中僅包括響應方的密鑰生成信息、身份信息，以及響應方用于身份驗證的驗證數據（包括所采用的身份認證機制中的密鑰、證書等）發給發起方，發起方在收到后獲知最終采用的IKE策略，并利用響應方的公鑰、本端的公/私鑰，以及一個nonce隨機數生成一系列密鑰（正確情況下，與響應方生成的密鑰是相同的），并根據響應方發來的身份信息和驗證數據對響應方進行最終的身份驗證。

3）消息③是發起方根據已確定的IKE策略，把自己的驗證數據（包括所采用的身份認證機制中的密鑰、證書等）發給響應方，讓響應方最終完成對發起方的身份驗證。至此整個信息交換過程就完成了，進入第二階段IPSec SA建立了。

由圖2和圖3的對比可以發現，與主模式相比，野蠻模式減少了交換信息的數目，提高了協商的速度，但是沒有對身份信息和驗證數據進行加密保護，因為雙方在發送身份信息時（對應第①和第②條消息）是不加密的（但主模式中發送的身份信息和驗證數據是加密的，對應第⑤和第⑥條消息）。但雖然野蠻模式不提供身份保護，它仍可以滿足某些特定的網絡環境需求。

當IPSec隧道中存在NAT設備時，需要啟用NAT穿越功能，而NAT轉換會改變對等體的IP地址，由于野蠻模式不依賴于IP地址標識身份，使得如果采用預共享密鑰驗證方法時，NAT穿越只能在野蠻模式中實現。

如果發起方的IP地址不固定或者無法預知，而雙方都希望采用預共享密鑰驗證方法來創建IKE SA，則只能采用野蠻模式。

如果發起方已知響應方的策略，或者對響應者的策略有全面的了解，采用野蠻模式能夠更快地創建IKE SA。

主模式和野蠻模式在確定預共享密鑰的方式不同。主模式只能基于IP地址來確定預共享密鑰。而野蠻模式是基于ID信息（主機名或IP地址）來確定預共享密鑰。當對等體兩端都是以主機名方式標識的時候，就一定要用野蠻模式來協商，如果用主模式的話，就會出現根據源IP地址找不到預共享密鑰的情況，以至于不能生成密鑰，因為主模式在交換完第③、④條消息以后，需要使用預共享密鑰來計算密鑰，但是由于雙方的身份信息要在第⑤、⑥條消息中才會被發送。而在野蠻模式中，主機ID信息（IP地址或者主機名）在消息①、②中就已經發送了，對方可以根據ID信息查找到對應的預共享密鑰，從而計算出密鑰。

4. IKEv1密鑰交換和協商：第二階段

IKEv1版本的第二階段就是要在第一階段基礎上最終建立一對IPSec SA，它只有一種模式，即快速模式（Quick Mode）。快速模式的協商是受IKE SA保護的，整個協商過程如圖4所示。

圖4 快速模式協商過程示意

在快速模式的協商過程中主要是完成以下IPSec SA安全策略的確定：

• 使用哪種IPSec安全協議：AH或ESP。
• 使用哪種HASH算法（認證算法）：MD5或SHA。
• 使用哪種IPSec工作模式：隧道模式或傳輸模式。
• 是否要求加密，若是，選擇加密算法：3DES或DES。
• 可選支持PFS（Perfect Forward Secrecy，完善的前向安全性）。

在上述幾方面達成一致后，將建立起兩個IPSec SA，分別用于入站和出站通信。

在消息①和②中的IPSec安全提議包括了安全協議、SPI、IPSec封裝模式、PFS（可選）、IPSec SA生存周期等。這兩條消息中還包括雙方的身份信息（如IP地址、傳輸層端口），驗證數據（包括所采用的身份認證機制中的密鑰、證書等），以及nonce（一個隨機數，用于抗重放，還被用作密碼生成的材料，僅當啟用PFS時用到）。接收方會利用所收到的對方數據生成加密密鑰，消息③為確認消息，通過確認發送方收到該階段的消息②，使響應方獲知可以正式通信了。

5. IKEv2密鑰協商和交換

IKEv1需要經歷兩個階段，至少交換6條消息才能最終建立一對IPSec SA，而IKEv2在保證安全性的前提下，減少了傳遞的信息和交換的次數，實現起來更簡單。

5.1 IKEv2概述

IKEv2保留了IKEv1的大部分特性，而且IKEv1的一部分擴展特性（如NAT穿越）作為IKEv2協議的組成部分被引入到IKEv2框架中。與IKEv1不同，IKEv2中所有消息都以“請求-響應”的形式成對出現，響應方都要對發起方發送的消息進行確認，如果在規定的時間內沒有收到確認報文，發起方需要對報文進行重傳處理，提高了安全性。

IKEv2還可以防御DoS攻擊。在IKEv1中，當網絡中的攻擊方一直重放消息，響應方需要通過計算后，對其進行響應而消耗設備資源，造成對響應方的DoS攻擊。而在IKEv2中，響應方收到請求后，并不急于計算，而是先向發起方發送一個cookie類型的Notify載荷（即一個特定的數值），兩者之后的通信必須保持cookie與發起方之間的對應關系，有效防御了DoS攻擊。

IKEv2定義了三種交換類型：初始交換（Initial Exchanges）、創建子SA交換（Create_Child_SA Exchange）以及通知交換（Informational Exchange）。IKEv2通過初始交換就可以完成一個IKE SA和第一對IPSec SA的協商建立。如果要求建立的IPSec SA大于一對時，每一對IPSec SA值只需要額外增加一次創建子SA交換（而如果采用IKEv1，則子IPSec SA的創建仍然需要經歷兩個階段）。

5.2 IKEv2初始交換

IKEv2初始交換對應IKEv1的第一階段，初始交換包含兩次交換四條消息，如圖5所示。消息①和②屬于第一次交換，以明文方式完成IKE SA的參數協商，主要是協商加密算法、交換nonce值、完成一次DH交換，從而生成用于加密，并驗證后續交換的密鑰材料。消息③和④屬于第二次交換，以加密方式完成身份認證（通過交換身份信息和驗證數據）、對前兩條信息的認證和IPSec SA的參數協商。

圖5 IKEv2初始交換過程

5.3 創建子SA交換

在初始交換完成后，可以由任何一方發起創建子SA交換，該次交換中的發起者和初始交換中的發起者可能是不同的。該交換必須在初始交換完成后進行，交換消息由初始交換協商的密鑰進行保護。

創建子SA交換包含兩條消息，用于一個IKE SA創建多個IPSec SA或IKE的重協商，對應IKEv1的第二階段。如果需要支持PFS，創建子SA交換可額外進行一次DH交換，建立用于IPSec SA的新密鑰。

5.4 通知交換

通信雙方在密鑰協商期間，某一方可能希望向對方發送控制信息，通知某些錯誤或者某事件的發生，這就需要由“通知交換”過程來完成。

通知交換如圖6所示，用于對等體間傳遞一些控制信息，如錯誤信息、刪除消息，或通知信息。收到信息消息的一方必須進行響應，響應消息中可能不包含任何載荷。通知交換只能發生在初始交換之后，其控制信息可以是IKE SA的（由IKE SA保護該交換），也可以是子SA的（由子SA保護該交換）。

圖6 通知交換過程