🍬 博主介紹

• 👨?🎓 博主介紹：大家好，我是 _PowerShell ，很高興認識大家~
• ?主攻領域：【滲透領域】【資料通信】 【通訊安全】 【web安全】【面試分析】
• 🎉點贊?評論?收藏 == 養成習慣（一鍵三連）😋
• 🎉歡迎關注💗一起學習👍一起討論??一起進步📝文末有彩蛋
• 🙏作者水平有限，歡迎各位大佬指點，相互學習進步！

目錄

🍬 博主介紹

一、什么是安全聯盟

二、協商引數兩種方式：（手動、IKE）

1. 手動

2. IKE方式

三、IKE的三個組件：

四、IKEv1三種模式（主模式/野蠻模式+快速模式）

1. 資料包分析

2. 詳細程序

2. 快速模式（三個包）

3. 野蠻模式

協商程序

4. 主模式與野蠻模式的區別：

5. 野蠻模式適用場景

五、專欄分享

一、什么是安全聯盟

IPSec中通信雙方建立的連接叫做安全聯盟SA (Security Association) ,顧名思義，通信雙方結成盟友，使用相同的封裝模式、加密演算法、加密密鑰、驗證演算法、驗證密鑰，相互信任親密無間，安全聯盟是單向的邏輯連接，為了使每個方向都得到保護，總舵和分舵的每個方向上都要建立安全聯盟，總舵入方向上的安全聯盟對應分舵出方向上的安全聯盟,總舵出方向上的安全聯盟對應分舵入方向卜的安全聯明，

SA在傳輸模式下也存在 只是不存在隧道報頭IP SA表示一種安全環境

安全聯盟定義了IPSec對等體間將使用的資料封裝模式、認證和加密演算法、密鑰等引數，

安全聯盟是單向的，兩個對等體之間的雙向通信，至少需要兩個SA，

同時使用了AH和ESP需要4個聯盟

需要考慮引數：本地IP 遠端IP 入方向索引編號 出方向索引（編號） （A入=B出）

加密的密鑰 建立聯盟的提議（標識）

二、協商引數兩種方式：（手動、IKE）

1. 手動

手動方式：適用于小型網路 （有匹配流量才會觸發ipsce）

現在手工配置不存在：不安全/不方便（密鑰不會變化）

2. IKE方式

IKE-互聯網隧道交換協議：IPsce的加解密(對稱加密、非對稱加密都需要密鑰解密)、哈希(密鑰參與哈希)、身份認證(數字證書本身就是非對稱加密演算法做的密鑰)都需要密鑰

解決手工配置問題

IKE用來管理、 生成、洗掉、變更各種密鑰

IKE負責自動建立和維護IKE SAs（密鑰素材安全環境（要是生成環境安全？？？））和IPSec SAs（IPSec安全環境 生成密鑰，確定引數）功能主要體現在

如下幾個方面:

對雙方進行認證

交換公共密鑰，產生密鑰資源，管理密鑰，

協商協議引數(封裝，加密，驗證”.) .

IKE協議分IKEv1和IKEv2兩個版本，IKEv1使用兩個階段為IPSec進行密鑰協商并建立IPSec SA，

第一階段，通信雙方協商和建立IKE本身使用的安全通道，建立一個IKESA，

第二階段，利用這個已通過了認證和安全保護的安全通道，建立一對IPSec SA

IKEv2則簡化了協商程序，在一次協商中可直接產生IPSec的密鑰，生成IPSec SAo

華為默認v2

三、IKE的三個組件：

SKEME：實作公鑰加密認證的機制

Oakley：基于到達兩個對等體間的加密密鑰的機制

ISAKMP：在兩個物體間進行分組格式及狀態轉換的訊息交換的體系結構，

四、IKEv1三種模式（主模式/野蠻模式+快速模式）

IKEv1建立IKE SA的程序定義了主模式(Main Mode)和野蠻模式(Aggressive Mode)兩種交換模式，

主模式包含三次雙向交換，用到了六條資訊，

野蠻模式只用到三條資訊，

1. 主模式：

1. 資料包分析

IKEv1的主模式協商：包含了三次雙向交換，用到了六條ISAKMP資訊，協商程序如下圖所示： IKEv1的協商程序總用用到了9個包，（加上快速模式3個包）

這三次交換分別是：

訊息①和②用于策略交換

發起方發送一個或多個IKE安全提議，回應方查找最先匹配的IKE安全提議，并將這個IKE安全提議回應給發起方，匹配的原則為協商雙方具有相同的加密演算法、認證演算法、認證方法和Diffie-Hellman組標識，

訊息③和④用于密鑰資訊交換

雙方交換Diffie-Hellman公共值和nonce值，用于IKE SA的認證和加密密鑰在這個階段產生，

訊息⑤和⑥用于身份和認證資訊交換（雙方使用生成的密鑰發送資訊），雙方進行身份認證和對整個主模式交換內容的認證，

IKE安全提議指IKE協商程序中用到的加密演算法、認證演算法、Diffie-Hellman組及認證方法等，nonce是個亂數，用于保證IKE SA存活和抗重放攻擊，

2. 詳細程序

協商程序
使用預共享密鑰進行身份認證主模式的詳細程序
階段一: IKE SA	
主模式（6個包）
Initiator                        Responder
             ----------                       -----------
-----------------------------------------------------------
    1-2包，用于安全引數協商（明文）
              HDR, SA             -->
              Ci  SAi
                                  <--    HDR, SA
                                           Ci Cr  SAr
SA安全聯盟(協商各種引數  加密演算法   驗證演算法  驗證方式【預共享密鑰  數字證書】 DH組  密鑰有效期） 
HDR拆解為Ci，Cr，分別代表Initiator cookie和Responder Cookie，第一個包Cr為0，
------------------------------------------------------------
3-4個包   交換密鑰素材，以及產生密鑰(明文）
              HDR, KE, Ni         -->
              Ci  Cr  K   Ni
                                  <--    HDR, KE, Nr
                                           Ci Cr  k  Nr
Ni Nr----代表亂數
通過KE交換素材得到公共的K值
K值為推導SKEYID使用  K = g^xy
SKEYID ------基準密鑰
使用預共享密鑰
SKEYID = prf(pre-shared-key, Ni|Nr)
使用數字證書
SKEYID = prf(Ni | Nr, K) -----基準密鑰
 通過SKEYID推導三個密鑰
   SKEYID_d = prf(SKEYID, K | Ci | Cr | 0) -----------推導密鑰，衍生密鑰
   SKEYID_a = prf(SKEYID, SKEYID_d | K | Ci | Cr | 1)---------驗證密鑰
   SKEYID_e = prf(SKEYID, SKEYID_a | K | Ci | Cr | 2)---------加密密鑰
-----------------------------------------------------------
5-6 兩個包    做身份驗證 （加密）
采用預共享密鑰5 6兩個包
   HDR*, IDii, HASH_I  --> 
   Ci Cr  
                                  <--    HDR*, IDir, HASH_R
IDii和IDir------標識，通常要IP地址
 HASH_I =   prf(SKEYID,K| Ci | Cr| SAi | IDi )
 HASH_R =  prf(SKEYID, K| Ci | Cr | SAr | IDr )
采用數字證書的5 6兩個包
 HDR*, IDii, [ CERT, ] SIG_I -->
                                    <--    HDR*, IDir, [ CERT, ] SIG_R
-----------------------------------------------------------------

2. 快速模式（三個包）

IKEv1協商階段2通過三條ISAKMP訊息完成雙方IPSec SA的建立：

1.發起方發送IPSec安全提議、被保護的資料流(ACL)和密鑰材料給回應方，

2.回應方回應匹配的IPSec安全提議、被保護的資料流，同時雙方生成用于IPSec SA的密鑰，IKEv1不協商ACL規則，建議兩端設備配置的ACL規則互為鏡像,避免IPSec SA協商失敗，IPSec對等體兩端交換密鑰材料(SKEYID_ _d、SPI和協議1、nonce等引數) ,然后各自進行密鑰計算生成用于IPSec SA加密驗證的密鑰,這樣可以保證每個IPSec SA都有自己獨一無二的密鑰，由于IPSec SA的密鑰都是由SKEYID_d衍生的,一旦SKEYID_d泄露將可能導致IPSec VPN受到侵犯，為提升密鑰管理的安全性，IKE提供了PPS (完美向前保密)功能，啟用PFS后，在進行IPSec SA協商時會進行一次附加的DH交換, 重新生成新的IPSec SA密鑰,提高了IPSec SA的安全性，

說明: 協議指AH和或ESP協議，

3. 發送方發送確認資訊，確認與回應方可以通信，協商結束，

協商完成后發送方開始發送IPSec (ESP) 報文，

3. 野蠻模式

主模式 需要知道對方IP進行指定

野蠻模式 解決一端為動態IP的問題（用的少不太安全）

配置命令exchange- mode aggressive即可將IKEv1的協商模式改為野蠻模式，

野蠻模式只用到三條資訊：前兩條訊息①和②用于協商IKE安全提議，交換Diffie-Hellman公共值、必需的輔助資訊以及身份資訊，并且訊息②中還包括回應方發送身份資訊供發起方認證，訊息③用于回應方認證發起方，

協商程序

當做一個預共享秘鑰認證時，野蠻模式的協商如下：

      Initiator                        Responder
第1包-------安全提議（各種協商）  密鑰交換素材   亂數  身份ID
            HDR, SA, KE, Ni, IDii -->
                                  <--    HDR, SA, KE, Nr, IDir, HASH_R
第2包---------安全提議，密鑰交換素材  亂數  身份ID  HASH_R
第3包---------加密的環境
            HDR*, HASH_I           -->

主要攜帶了安全提議（各種協商） 密鑰交換素材 亂數 身份ID等，發送給回應方，

第二個包：主要攜帶確認雙方都支持的安全提議，密鑰交換素材 亂數 身份ID HASH_R等，發送給協商發起方，

第三個包：的傳輸程序是加密的，主要用于回應方認證發起方，

4. 主模式與野蠻模式的區別：

交換的訊息：主模式為6個包，野蠻模式為3個包，野蠻模式能夠更快創建IKE SA

NAT支持：對預共享密鑰認證：主模式不支持NAT轉換，而野蠻模式支持，而對于證書方式認證：兩種模式都能支持

對等體標識：主模式只能采用IP地址方式標識對等體；而野蠻模式可以采用IP地址方式或者Name方式標識對等體，這是由于主模式在交換完3、4訊息以后，需要使用預共享密鑰來計算SKEYID，當一個設備有多個對等體時，必須查找到該對等體對應的預共享密鑰，但是由于其對等體的ID資訊在訊息5、6中才會發送，此時主模式的設備只能使用訊息3、4中的IP報文源地址來找到與其對應的預共享密鑰；如果主模式采用Name方式，Name資訊卻包含在訊息5、6中，而設備必須在訊息5、6之前找到其對等體的預共享密鑰，所以就造成了矛盾，無法完成Name方式的標識，

而在野蠻模式中，ID訊息在訊息1、2中就已經發送了，設備可以根據ID資訊查找到對應的預共享密鑰，從而計算SKEYID，但是由于野蠻模式交換的2個訊息沒有經過加密，所以ID資訊也是明文的，也相應造成了安全隱患，

提議轉換對數量：在野蠻模式中，由于第一個訊息就需要交換DH訊息，而DH訊息本身就決定了采用哪個DH組，這樣在提議轉換對中就確定了使用哪個DH組，如果第一個訊息中包含多個提議轉換對，那么這多個轉換對的DH組必須相同(和DH訊息確定的DH組一致)，否則訊息1中只能攜帶和確定DH組相同的提議轉換對，

協商能力：由于野蠻模式交換次數的限制，因此野蠻模式協商能力低于主模式，

主模式常用，野蠻已經不推薦使用,推薦使用模板方式

兩者之間的協商程序不同

場景不同：

5. 野蠻模式適用場景

與主模式相比，野蠻模式減少了交換資訊的數目，提高了協商的速度，但是沒有對身份資訊進行加密保護，雖然野蠻模式不提供身份保護，但它可以滿足某些特定的網路環境需求，

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

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

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

五、專欄分享

每個專欄都在持續更新中~~~

滲透測驗自學篇 web基礎知識點

網路基礎 面試總結

網路工程師 python

作業系統篇 通訊安全

閑聊 漏洞復現篇

代碼審計 SSM

docker 環境搭建篇

python爬蟲 靶場

??????心理學