一、數據存儲完整性校驗
數據存儲完整性校驗需通過加密密鑰實現。數據存儲前還需通過身份認證,該過程同樣依賴密鑰完成。
二、對稱key的產生、傳遞、管理
VPN中需使用多組對稱密鑰:
- 數據加解密需獨立密鑰
- 數據完整性校驗需獨立密鑰
- 身份認證需獨立密鑰
- 不同功能的密鑰必須獨立,以增強VPN安全性。同種功能的密鑰可復用,但跨功能密鑰需嚴格區分。
1.對稱key的傳遞:
對稱密鑰傳遞依賴非對稱加密算法。算法原理雖簡單,但實現復雜度高。
1) DH算法
DH算法通過私鑰與對方公鑰計算生成相同對稱密鑰,該密鑰用于保護數據傳輸。
- VPN僅使用DH算法的前半部分(密鑰協商階段)
- 對稱密鑰始終不在網絡中傳輸,僅通過本地計算驗證
- DH密鑰組
DH組類型 | 密鑰特性 | 安全性對比 |
直線型算法(如DH組2/3) | 密鑰長度較長(如1024位) | 計算簡單,需更長密鑰保障安全 |
橢圓曲線算法(如163位) | 密鑰長度較短 | 計算復雜,同等安全性下密鑰更短 |
密鑰長度與安全性非絕對正比,需結合算法復雜度評估。當前推薦使用橢圓曲線算法(如DH組20+)。 |
2.思考
同一設備可建立多條VPN隧道,各隧道參數(加密算法、校驗方式等)可獨立配置。
- 隧道間數據嚴格隔離,網段不可重疊
- 每條隧道需綁定唯一保護策略(如傳輸模式/隧道模式ESP)
- 安全關聯(SA)用于統一管理隧道參數,確保數據按預設規則處理。
三、SA概述
安全關聯(SA)是IPSec的核心規則集,每個VPN連接對應多組SA:
- 單向通信需獨立SA(如A→B與B→A需分別配置)
- 單條VPN連接通常包含4個SA(出/入方向各一對)
1.安全關聯
SA包含以下協商參數:
- 協議類型(AH/ESP)
- 傳輸模式(傳輸/隧道)
- 加密算法與密鑰
- 驗證算法與密鑰
- SA生成方式:
- 手工配置:參數永不過期,維護成本高
- IKE自動協商:動態管理,支持定期更新
2.SA如何產生
SA通過協議自動協商生成。SA與IP不同,其作用是在IPSec VPN中雙方協定并保護數據。
1) 手工配置
- 手工配置的SA無過期時間,密鑰使用時間越長,安全性越低。
- 手工配置需在兩端設備上完全一致,且物理距離較遠時配置難度大。
- 配置錯誤風險高,需通過電話或消息同步策略,效率低。
- 適用場景:實驗室測試或開發環境,項目中基本不使用。
2) IKE自動管理
- IKE(互聯網密鑰交換協議)為協議簇,用于動態建立、維護和刪除SA。
- 自動協商的SA具有生命周期,與路由、ARP等網絡協議類似。
- 本地無符合條件SA時,設備自動啟動IKE協議協商。
- IKE適用于生產環境,手工配置僅用于特殊場景。
四、IKE工作過程
1.IKE概述
- IKE全稱為互聯網密鑰交換,用于動態建立、維護和刪除SA。
- IKE為協議簇,包含多種子協議,主要功能包括密鑰協商和認證。
- ISAKMP協議定義了消息交換體系和狀態轉換流程,為IKE核心協議。
2.ISAKMP協議
- ISAKMP為標準協議,文檔公開,廠商設備均支持。
- 協議定義了SA協商的完整流程,包括建立、修改和刪除。
- 僅提供參數框架,具體實現由設備廠商決定。
1) ISAKMP報文格式
- ISAKMP報文格式固定,使用UDP傳輸,默認端口為500(廠商可能不同)。
- 協議獨立于密鑰交換,可被不同密鑰交換協議使用。
- NAT穿越技術通過添加UDP頭部解決IPSec與NAT兼容性問題,支持單公網地址多隧道。
- ESP加密后傳輸層不可見,需依賴NAT穿越實現端口區分。
- 密鑰管理IKE任務
IPSec VPN使用IKE自動協商SA的過程分為兩個階段:
- 階段一任務:
- 雙向ISAKMP SA協商,包含三部分:
- 協商安全參數:包括加密算法、驗證算法、DH組、身份認證方式及密鑰生存周期
- 建立初始SA
- 交換計算密鑰材料:通過DH算法交換公鑰及隨機數,生成身份認證密鑰、數據加解密密鑰、完整性校驗密鑰
- 身份認證:通過后進入階段二
- 雙向ISAKMP SA協商,包含三部分:
- 階段二任務:
- 生成兩個單項IPSec SA用于保護數據
- 協商內容:
- 數據傳輸協議(AH/ESP)
- 傳輸模式(傳輸模式/隧道模式)
- 數據保護算法(加密算法、校驗算法)
- 密鑰生存周期
- 步驟:
- 交換密鑰計算材料
- 生成密鑰
- 身份認證
- IKE協商的兩個階段
對比項 | 階段一 | 階段二 |
SA類型 | ISAKMP SA(IKE SA) | IPSec SA |
模式 | 主模式(6報文)/野蠻模式(3報文) | 快速模式(3報文) |
保護對象 | 階段二協商報文 | 用戶數據 |
復用性 | 可保護多個階段二協商 | 獨立生成 |
報文總數 | 主模式+快速模式=9報文 | 野蠻模式+快速模式=6報文 |
2) ISAKMP報文攜帶的載荷
- ISAKMP消息報頭
ISAKMP報文采用火車式結構:
- 報頭固定字段:
- 發起方Cookie:通過哈希算法(源IP+源端口+隨機數+時間戳)生成前64位,用于身份標識且不可逆推
- 應答方Cookie:首報文置零,后續報文由接收方生成
- 特性:
- 單次協商中Cookie不可變
- 不同協商會話Cookie必然不同
- 下一載荷字段:指示報頭后首個載荷類型
- 防篡改機制:Cookie變更將導致報文丟棄
- 載荷類型
ISAKMP可攜帶的載荷類型包括:
- SA載荷(安全聯盟參數)
- 密鑰交換載荷
- 身份認證載荷
- 證書載荷(僅證書認證時存在)
- 哈希/簽名載荷
- 隨機數載荷
- 通知/刪除載荷
- 版本號
版本號字段包含主版本和次版本標識,無實際協商功能。
- 交換類型
交換類型字段用于標識階段一的協商模式:
- 主模式(值1)
野蠻模式(值2)
- 該字段不參與階段二(快速模式)標識。
- 標志
標志的最后三位具有特定功能:從最后一位開始依次為加密位、提交位和純驗證位
- 加密位功能:值為1表示頭部后面的所有載荷被加密,值為0表示明文傳輸
- 提交位作用:確保被保護數據發送前完成協商,未完成協商則禁止發送數據
- 純驗證位含義:允許特定機構(如政府公安)實施密鑰恢復機制,可解密截獲的報文
- 報文ID
第一階段報文ID:全為零值
- 第二階段報文ID:由發起方生成隨機值,用于唯一標識第二階段狀態
- 報文長度定義:頭部與所有載荷的總長度之和
- 載荷頭部
載荷頭部結構包含三個要素:
- 下一載荷類型標識:指示后續載荷的數據類型
- 當前載荷長度:本段數據的字節長度
- 實際數據內容:具體傳輸的有效信息
- 終止標識規則:當下一載荷類型值為零時,表示報文結束
3) 一個完整的ISAKMP報文結構
ISAKMP報文采用模塊化結構:由頭部和多個可擴展的載荷組成
- 載荷數量特性:根據實際需求靈活配置,支持攜帶2-4個或更多載荷
- 與IPV6報文結構的相似性:兩者均采用頭部+擴展頭的設計,使IPV6原生支持IPSec加密功能
3.IKE協商第一階段過程分析
1) IKE協商第一階段目的及任務
階段一核心目標:協商建立ISAKMP SA(或IKE SA)
- 需完成的三個關鍵任務:
- 加密套件協商
- 密鑰材料交換與生成
- 通信雙方身份認證
2) 加密套件:
- 加密套件包含五個要素:
- 加密算法
- 哈希算法
- DH組參數
- 身份認證方式
- SA生命周期
3) 交換密鑰計算材料,生成密鑰
- 密鑰生成分兩步:
- 交換計算材料:包含DH公鑰和隨機數
- 生成最終密鑰:基于共享材料進行密碼運算
4) 身份認證
- 認證階段作用:驗證通信雙方身份的合法性
- 典型認證方式:預共享密鑰機制
5) 主模式六個報文
報文序號 | 功能分類 | 傳輸內容 | 方向 |
1-2 | 加密套件協商 | 發起方支持的加密套件列表 | 發起方→應答方 |
3-4 | 密鑰材料交換 | DH公鑰與隨機數 | 雙向交互 |
5-6 | 身份認證 | 基于預共享密鑰的認證信息 | 雙向確認 |
6) 加密套件的選擇
- 加密套件選擇原則:
- 優先級判定標準:選擇雙方支持的最小策略編號
- 安全配置建議:將高安全等級的套件配置為較小編號
7) 第1、2個ISAKMP報文
- 首報文關鍵字段:
- 發起方Cookie:用于標識會話
- 加密套件列表:包含全部支持的策略組合
- 應答方處理邏輯:從匹配的套件中選擇策略編號最小的配置項
8) 身份認證密鑰
- 身份認證密鑰(s key.ID)通過隨機數算法計算生成
- 計算要素包括預共享密鑰和雙方隨機數,通過prf算法生成
- s key ID杠d密鑰作為中間材料使用,計算方式為:身份認證密鑰+DH對稱密鑰+發起方cookie+應答方cookie
- s key ID杠d密鑰用于后續加密密鑰和完整性校驗密鑰的計算
9) 完整性認證密鑰和數據加解密密鑰
密鑰類型 | 計算要素 | 功能 | 算法特性 |
完整性認證密鑰 | s key ID + s key ID杠d + DH對稱密鑰 | 數據完整性校驗 | 算法固定,不同算法添加常數不同 |
數據加解密密鑰 | s key ID + s key ID杠d + DH對稱密鑰 | 數據加密解密 | AES/DES/3DES等加密算法實現 |
10) 身份認證過程
- 身份認證步驟:將SA信息、cookie值及身份信息通過身份認證密鑰進行散列計算
- 發起方操作:生成散列值后附加身份ID,使用e密鑰加密并通過a密鑰校驗完整性
- 應答方驗證:解密后通過cookie和SA信息驗證身份,需雙向認證(發起方→應答方→發起方)
- 主模式六個報文中有兩個加密報文,階段一生成的密鑰用于后續通信保護
11) 階段一與階段二的關系
階段一生成的加密密鑰和完整性校驗密鑰直接應用于階段二的快速模式,實現安全參數協商。
12) 階段二:快速模式
- 核心目標:協商IPsec SA(安全關聯)
- 協商內容包括:
- 協議類型(AH/ESP)
- 工作模式(傳輸/隧道)
- 加密算法與校驗算法
- 生命周期參數
13) 階段二:快速模式任務
快速模式通過三個報文完成:
- 發起方發送安全參數(含加密套件)及密鑰計算材料
- 應答方確認參數并返回驗證信息
- 雙方確認SA建立
14) 階段二:安全參數
- 安全參數組成:協議類型、工作模式、加密算法、校驗算法、生命周期
- 報文保護機制:使用階段一生成的e密鑰加密和a密鑰校驗
- 密鑰材料更新:需重新生成DH公鑰和隨機數,確保前向安全性
4.IKE協商第二階段過程分析
- 第二階段協商內容包括:proposal載荷、ESP加密算法、校驗算法、傳輸/隧道模式選擇、生命周期參數
- 關鍵載荷構成:
- KE載荷:包含DH公鑰隨機值
- 身份ID載荷:用于通信雙方身份標識
- 哈希載荷:使用階段一生成的完整性校驗密鑰對加密數據做認證
- 哈希值功能:應答方通過該值完成報文完整性校驗
五、IPSec協議概述
1.IPSec協議保護IP數據的方式
完整性校驗哈希值用于應答方驗證報文完整性,該值可見于報文特定字段。
2.eNSP新建拓撲
加密數據通過哈希值實現校驗功能,該機制未在報文顯式標注。第一階段協商生成的密鑰材料為校驗基礎。
3.密鑰計算材料與身份認證
- 答方處理流程:
- 確認安全參數(SA)
- 發送包含應答方公鑰和隨機數的密鑰計算材料
- 附加身份ID載荷
- 密鑰生成時機:收到第二個報文后,應答方可計算全部五個會話密鑰
4.密鑰計算與安全參數確認
- 身份認證機制:通過R哈希載荷實現應答方身份驗證
- 發起方驗證條件:
- 安全參數已確認
- 密鑰材料完整接收
- 具備身份ID及認證函數
5.身份認證與密鑰保護
處理階段 | 完成動作 | 剩余任務 |
第三個報文 | 安全參數確認 | 應答方認證發起方身份 |
密鑰生成完成 | 附加發起方身份載荷 | |
保護機制:所有報文參數受第一階段密鑰保護,實際內容不可見 |
6.實驗平臺與隧道模式
GRE over IPSec實驗中隧道模式通過GRE實現,而純IPSec實驗需顯式配置階段二工作模式。后者需明確指定ESP封裝協議、加密算法及完整性驗證方式。
六、實驗
實驗配置差異:
- 混合模式:GRE隧道隱式確定IPSec模式參數
- 獨立模式:需手動配置ESP協議參數及傳輸/隧道模式選項