數據傳輸安全-IKE工作過程

在前面的課程中，你已經掌握了：
IPSec的目標：提供機密性、完整性、身份認證、防重放。
IPSec的執行者：AH和ESP協議。
IPSec的規則手冊：SA（安全關聯），包含了所有保護參數（算法、密鑰、模式等）。
SA的創建方式：手工配置（麻煩、不安全）或自動協商（IKE）。
本課程就是深入講解“自動協商”這個環節，即?IKE協議是如何工作的。它解決了最根本的問題：如何在不安全的網絡上，安全地協商出那些需要用來保護網絡安全的秘密參數（尤其是密鑰）？

一、IKE的工作過程

1.IKE協議概述與基礎

1.1? IKE定義

IKE是一種混合型協議，用于在IPSec通信雙方之間，動態地、自動地建立、協商、管理和刪除安全關聯（SA）。

1.2 IKE的組成

?IKE的組成：一個混合協議

IKE不是一個從零設計的協議，而是一個“集大成者”，它建立在由ISAKMP定義的框架上，并實現了Oakley和SKEME兩種協議的一部分功能。

協議組件	角色與貢獻	簡單理解
ISAKMP (Internet Security Association and Key Management Protocol)	定義了協商、建立、修改和刪除SA的過程和報文格式（即“怎么談”）。注意：ISAKMP只提供了一個通用框架，它本身不定義具體的密鑰交換方式或認證方式。	定義了語言的語法和結構。比如，問句怎么開頭，答句怎么結尾。但它不管具體問什么內容。
Oakley	描述了一系列被稱為“模式”的密鑰交換方法（即“用什么方法談”），其核心是Diffie-Hellman密鑰交換的多種變體。	提供了多種具體的對話技巧。比如，如何通過三步對話達成一個共識，或者如何通過五步對話來達成。
SKEME	提供了一種快速的密鑰交換機制，并支持公鑰加密認證等概念。	提供了快速達成共識和驗證對方身份的方法。

結論：IKE =?ISAKMP的框架?+?Oakley的交換模式?+?SKEME的共享和密鑰更新技術。

3.IKE的版本

IKE主要有兩個版本：

IKEv1 ：

特點：功能強大且成熟，但協議較復雜，報文交換數量多，有多個模式（主模式、野蠻模式、快速模式）。
IKEv1協議直接使用ISAKMP定義的報文結構和交換模式。

IKEv2 (RFC 7296)：

是IKEv1的演進版本，目前已成為新部署項目的首選。
特點：
- 更簡潔：交換次數更少（通常4次報文交換即可完成雙向認證和IPSec SA建立）。
- 更安全：修復了IKEv1的一些已知漏洞。
- 更可靠：內置了 NAT-T（NAT穿越）支持和更強大的存活檢測機制。
- 效率更高：報文結構更優化。

2. IKE的報文結構

IKE報文是通過UDP協議傳輸的，其整體結構可以分解為以下三層：
| IP頭部 | UDP頭部 (源端口500, 目的端口500) | ISAKMP報文 |
其中最核心、最復雜的就是?ISAKMP報文。
一個ISAKMP報文由?一個通用頭部?和?一串鏈接起來的載荷?組成。

ISAKMP報文是IKEv1協議的載體，所有IKEv1的協商（主模式、野蠻模式、快速模式）都通過交換ISAKMP報文完成。其結構分為兩大塊：固定長度的通用頭部?和?可變長度的載荷鏈。

2.1通用頭部

發起方：

應答方：

下一個載荷：

版本號：

交換類型：

標志：

報文ID：

報文長度：

2.2 載荷

載荷是掛在ISAKMP頭部后面、真正攜帶協商信息的數據塊。多種不同類型的載荷通過“下一個載荷”字段像鏈條一樣連接起來。

載荷通用頭部：每個載荷都以一個簡單的頭部開始：

下一個載荷 (1字節)：指向鏈中下一個載荷的類型。如果這是最后一個載荷，則該字段為0。
保留 (1字節)?|
載荷長度 (2字節)：當前載荷的總長度（包括本頭部）。

3.IKE協商的兩個階段

階段一：建立IKE SA

2.1 目的

驗證對端身份真實性。
協商出一個雙向的IKE SA（管理SA），用于保護第二階段的通信。

2.2 兩種模式

主模式?-?6個報文
- 特點：身份保護（Identity Protection），第5/6報文才交換身份信息且已加密。
- 過程：三組報文交換（策略協商、DH交換、身份認證）。
野蠻模式-?3個報文
- 特點：速度快，但身份信息在明文階段交換。
- 適用場景：適合對端IP地址不固定（如動態IP）、且對身份暴露不敏感的情況。

2.3 IKE協商第一階段過程分析

第1、2個報文：協商安全策略（明文交換）

過程：
1. （報文1）?發起方(RA)將自己支持的所有IKE策略（一個或多個策略套件）放在SA載荷中發送給響應方(RB)。
  - 每個策略套件包含：加密算法（如AES）、散列算法（如SHA）、認證方法（如pre-share）、DH組（如group 14）、生存時間。
2. （報文2）?響應方(RB)收到后，在自己的策略庫中尋找優先級最高且完全匹配的策略，并將該策略通過SA載荷發回給發起方。
狀態：明文傳輸。此時尚未建立安全通道。
結果：雙方就保護IKE SA的安全參數達成一致。如果找不到匹配項，協商就此失敗。

第3、4個報文：交換DH公共值和隨機數（明文交換）

目的：生成共享密鑰的“種子”，為后續所有加密和認證提供基礎。
過程：
1. （報文3）?發起方(RA)生成一個DH私鑰，計算出對應的DH公鑰，放入KE載荷（Key Exchange）。同時，生成一個隨機數Ni，放入Nonce載荷。一并發送給對方。
2. （報文4）?響應方(RB)執行相同的操作：生成自己的DH私鑰，計算DH公鑰放入KE載荷，生成隨機數Nr放入Nonce載荷，發回給發起方。
狀態：明文傳輸。KE和Nonce載荷本身不需要加密，因為DH算法的安全性基于數學難題（離散對數）。
結果：
- 雙方各自使用對方的DH公鑰和自己的DH私鑰，通過DH算法獨立計算出相同的共享秘密?g^ab。這個值從未在網絡上傳輸過。
- 雙方都擁有了兩個隨機數?Ni?和?Nr。

DH算法

DH的安全性基于一個數學難題：計算離散對數在有限域中是非常困難的。我們用一個經典的“顏色混合”比喻來理解它：
公開約定公共參數：
通信雙方（Alice和Bob）公開約定一種公共顏色（黃色）。這對應DH算法中的公共參數（一個大質數?p?和一個底數?g）。在IKE中，這由選擇的?DH組（Group）?決定。
各自選擇私有數字：
Alice秘密地選擇一個私密數字（Private Key）?a。
Bob也秘密地選擇自己的私密數字（Private Key）?b。
a?和?b?是核心秘密，永遠不告訴任何人，也不在網絡上傳送。
計算并交換公共值：
Alice用自己的私密數字?a?和公共顏色（黃色）進行混合，得到一種新的混合色（橘色）。她將橘色發送給Bob。
Bob用自己的私密數字?b?和公共顏色（黃色）進行混合，得到一種新的混合色（綠色）。他將綠色發送給Alice。
這個過程對應數學運算：A = g^a mod p?(Alice計算) 和?B = g^b mod p?(Bob計算)。
這里的?A?和?B?就是各自的?DH公鑰，對應IKE報文中的?KE載荷，是在網絡上明文傳輸的。
雙方計算最終共享秘密：
Alice收到Bob的綠色后，再加入自己的私密數字?a?進行混合，得到最終的顏色（棕色）。
Bob收到Alice的橘色后，再加入自己的私密數字?b?進行混合，得到最終的顏色（同樣是棕色）。
這個過程對應數學運算：
Alice計算：B^a mod p = (g^b)^a mod p = g^{ba} mod p
Bob計算：A^b mod p = (g^a)^b mod p = g^{ab} mod p
由于?g^{ab} = g^{ba}，雙方獨立計算出了完全相同的數字，這個數字就是?DH共享秘密?g^{ab}。
關鍵點：竊聽者（Eve）可以看到公共顏色（黃色）、Alice的混合色（橘色）和Bob的混合色（綠色）。但從這些顏色中，她幾乎無法分離出最終的棕色。數學上，從公鑰?A?或?B?反推私鑰?a?或?b（離散對數問題）在計算上是不可行的。
DH組定義了密鑰交換的強度。組號越大，使用的質數?p?越大，計算出的共享秘密?g^{ab}?就越長，安全性越高，但計算開銷也越大。（回顧）

第5、6個報文：身份認證（加密交換）

目的：驗證對端身份的真實性。確認你正在和“正確的人”通信，而不是中間人。
過程：
1. （密鑰衍生）?在交換3、4報文后，雙方已經可以計算出共享秘密?g^ab?并擁有隨機數?Ni, Nr?和Cookie?CKYi, CKYr。它們會使用一個偽隨機函數(PRF)，結合預共享密鑰，衍生出三把關鍵的密鑰：
  - SKEYID_e：用于加密后續IKE報文的密鑰。
  - SKEYID_a：用于認證（完整性驗證）后續IKE報文的密鑰。
  - SKEYID_d：作為種子，用于衍生IPSec SA的密鑰。
    例如：SKEYID = prf(pre-shared-key, Ni | Nr)
2. （報文5 - 已加密）?發起方(RA)使用剛生成的?SKEYID_e?和?SKEYID_a?對ID載荷（身份信息，如IP地址）和Hash載荷進行計算和加密，然后發送給響應方。
  - Hash_I = prf(SKEYID, RA's_IP | RB's_IP | CKYi | CKYr | SA_offer | IDi)
3. （報文6 - 已加密）?響應方(RB)收到后，先用?SKEYID_e?解密，再用相同的算法和本地信息計算一個Hash值。如果與自己收到的?Hash_I?完全一致，則證明：
  - 消息未被篡改（完整性）。
  - 發起方擁有正確的預共享密鑰（身份認證）。
    驗證通過后，響應方以同樣方式發送自己的ID和Hash載荷給發起方進行驗證。
狀態：加密傳輸。從第5個報文開始，所有載荷均被?SKEYID_e?加密，并用?SKEYID_a?進行認證。
結果：完成雙向身份認證。至此，一個安全的、經過認證的IKE SA正式建立。

總結：

?“DH交換是在哪個階段完成的？為什么它不怕被竊聽？”
"DH交換是在IKE階段一的第3和第4個報文中完成的。
它不怕被竊聽是因為其安全性基于計算離散對數的數學難題。雖然雙方在網絡上明文傳輸了各自的DH公鑰（g^a mod p?和?g^b mod p），但竊聽者無法從這些公鑰中反算出雙方的私鑰?a?和?b，因此也就無法計算出雙方最終協商出的共享秘密?g^{ab} mod p。這個共享秘密本身從未在鏈路上出現過。"

?“IKE階段一是如何實現身份認證的？”
"IKE階段一主要通過驗證對方是否擁有相同的預共享密鑰或數字證書來實現身份認證。
以預共享密鑰為例：
雙方在完成DH交換后，會使用預共享密鑰、交換的隨機數（Nonce）等參數，衍生出一個認證密鑰（SKEYID_a）。
隨后，雙方會計算一個哈希值（例如?Hash_I），這個哈希值的內容包含了身份信息和之前的協商參數，并用?SKEYID_a?作為密鑰。
這個哈希值在加密通道中交換。接收方用相同的本地參數和預共享密鑰重新計算一遍。
如果計算出的哈希值與對方發來的完全一致，就證明對方擁有正確的預共享密鑰，身份認證通過。如果不一致，協商立即終止。"

?“主模式和野蠻模式的主要區別是什么？”（野蠻模式更快但身份明文傳輸，且只有3個報文）
"主模式和野蠻模式的主要區別有三點：
報文數量與速度：主模式是6次報文交換，速度較慢；野蠻模式只有3次交換，速度更快。
身份保護：這是最核心的區別。主模式的身份交換（ID載荷）在加密后的第5、6報文中進行，隱藏了身份信息。而野蠻模式的身份信息在明文的第1、2報文中就交換了，無法提供身份保護。
適用場景：主模式更安全通用。野蠻模式通常用于對端IP地址不固定（如動態IP）且對身份信息暴露不敏感的特殊場景。"

階段二：建立IPSec SA

2.3 目標

在IKE SA的保護下，協商用于保護用戶數據的IPSec SA。

2.4 快速模式?-?3個報文

所有報文均被IKE SA的加密和認證功能所保護。
協商IPSec SA的具體參數：協議（AH/ESP）、模式（傳輸/隧道）、算法、生存期、受保護的數據流等。

2.5?IKE階段二（快速模式）過程

第1個報文：發起提議

目的：發起方(RA)提出保護用戶數據的IPSec SA策略。
載荷內容：
- SA載荷：包含一個或多個提議載荷和變換載荷，詳細定義了IPSec SA的參數：
  - 安全協議：是使用?ESP?還是?AH？
  - 封裝模式：是傳輸模式還是隧道模式？
  - 加密算法：用于數據的算法（如AES-256）和密鑰長度。
  - 認證算法：用于數據完整性的算法（如SHA256）。
  - 生存時間：IPSec SA的有效期（時間或流量）。
- Nonce載荷：發送一個新的隨機數?Ni2，用于保證交換的新鮮性，防止重放攻擊，并參與新密鑰的生成。
- (可選) KE載荷：如果啟用了完美前向保密（PFS），則會包含一個新的DH公鑰，用于一次全新的DH交換。
- ID載荷：標識要保護的數據流（通常由ACL定義），例如?源IP：192.168.1.0/24 -> 目標IP: 192.168.2.0/24。
- Hash載荷：用于對消息進行認證。

第2個報文：響應應答

目的：響應方(RB)接受發起方的提案，并參與生成新密鑰。
過程：
1. RB?收到報文后，用IKE SA的密鑰（SKEYID_e和SKEYID_a）進行解密和驗證。
2. 在自己的配置中查找與收到的提案匹配的IPSec策略。
3. 如果找到，RB?會生成自己的隨機數?Nr2。
4. RB?構建一個回應報文，其載荷結構與報文1類似：
  - SA載荷：指明所接受的提議。
  - Nonce載荷：攜帶?Nr2。
  - (可選) KE載荷：如果對方請求了PFS，則也返回自己的新DH公鑰。
  - ID載荷：標識數據流。
  - Hash載荷：計算一個新的Hash值進行回應和認證。

第3個報文：確認

目的：發起方(RA)對響應方的應答進行最終確認，完成協商。
過程：
1. RA?收到報文后，同樣進行解密和驗證。
2. 驗證通過后，RA?發送第三個也是最后一個報文。
3. 這個報文通常只包含一個Hash載荷，作為對整個快速模式交換的確認。
結果：收到此報文后，雙方都認為IPSec SA已成功建立，可以開始用來保護用戶數據了。