在Ip sec 中，由ESP模块去使用加解密算法和秘钥进行加密和解密。
ESP是一个功能
安全策略
ip-sec vpn想要正常工作，想要保护业务流量，最少得有两个策略，一个策略让墙与墙之间去建立隧道，一个策略让你的用户能够从墙走出去。
抓包
改成AH认证
现在数据就没有加密了
IKE主模式生成的三把钥匙------a、e、d ，分别是认证密钥（Authentication Key） 、加密密钥（Encryption Key） 、派生密钥（Derivation Key，或叫衍生材料）。它们共同保障IKE协商过程的安全，但又各自分工，互不干扰。
一、这三把钥匙到底干什么用的？
首先搞清它们的来源：IKE主模式经过Diffie-Hellman交换后，双方协商出一个共享的SKEYID（伪随机数）。然后用SKEYID派生出三个独立的密钥材料，分别交给三个不同的任务：
| 钥匙代号 | 全称 | 作用 | 谁使用 | 备注 |
|---|---|---|---|---|
| a | SKEYID_a (Authentication Key) | 对IKE消息进行完整性校验和认证 | 双方 | 防止IKE消息被篡改 |
| e | SKEYID_e (Encryption Key) | 加密IKE消息（保护机密性） | 双方 | 防止IKE消息被窃听 |
| d | SKEYID_d (Derivation Key) | 派生后续IPsec SA的密钥材料（用于生成子SA的加密/认证密钥） | 双方 | 用于后续建立IPsec隧道 |
具体作用：
-
a（认证） ：给IKE消息加上HMAC（哈希消息认证码），确保消息未被篡改、来源真实。攻击者修改了协商参数，接收方会校验失败，抛弃消息。
-
e（加密）：给IKE消息加密（如使用AES-CBC），保证协商内容（身份ID、证书、预共享密钥哈希等）不被中间人偷看。
-
d（衍生） ：本身不直接用于加密或认证，而是作为"种子"，结合后续quick mode中的随机数，派生出IPsec SA使用的加密密钥、认证密钥。
所以这三把钥匙分别负责：完整性、机密性、继承衍生。
IPsec VPN 是一套"加密快递系统"：
-
IPsec SA 是"快递员与收发室之间签订的一份临时工作合同"，规定了用什么锁、用什么签名、钥匙是什么。
-
IKE 是"专门负责签订这份合同的谈判官"，它先谈出一份安全通道（IKE SA），再用这条安全通道去签第二份合同（IPsec SA）。
一句话：IKE 是"合同的合同"，IPsec SA 是真正的"数据加密合同"，IPsec VPN 就是利用这套合同来加密传输普通IP数据包。
ESP 工作时需要一个 SA（Security Association，安全联盟）------就是双方商量好的一堆参数：
-
使用什么加密算法（AES-256？3DES？）
-
使用什么认证算法（SHA-256？MD5？）
-
加密密钥是什么（一串随机数）
-
认证密钥是什么（另一串随机数）
-
SPI（Security Parameters Index，一个编号，用来唯一标识这条SA）
问题来了 ：这些参数怎么让双方都知道？总不能明文写在网络上吧？------于是发明了 IKE（Internet Key Exchange）。
IKE 的使命：自动协商并建立 IPsec SA
IKE 分为两个阶段：
-
IKE 第一阶段 ：建立一个 IKE SA （也叫 ISAKMP SA）。这个 SA 是一条双向的安全通道，用来保护第二阶段的协商过程。
-
IKE 第二阶段 ：在 IKE SA 的保护下，协商出真正用于数据加密的 IPsec SA（通常是两个单向的：一个进，一个出）。
类比：
-
你公司有严格的保密制度，两个部门要签合同。你不能直接把合同草案扔到公共网络上，因为会被偷看。
-
第一步：两个部门的代表先私下见面，互相验证身份，约定一个临时暗号（IKE SA）。
-
第二步：用这个临时暗号加密传输真正的合同内容，签下正式合作合同（IPsec SA）。
主模式是 IKE 第一阶段最严格、最安全的协商方式，共6个消息交互，分成三步：
| 步骤 | 交换内容 | 作用 | 产生的钥匙 |
|---|---|---|---|
| 消息1-2 | 协商 IKE 安全提议（加密/认证/哈希/DH组等） | 双方确认"用什么锁、什么签名" | 尚无 |
| 消息3-4 | Diffie-Hellman 交换 + 随机数（nonce） | 双方各自计算出相同的 DH共享密钥，这是所有后续钥匙的母材 | 母材 (SKEYID) |
| 消息5-6 | 身份认证（ID + 签名/预共享密钥哈希），此时已加密 | 确认对方身份，防止中间人 | 派生三把子钥匙 |
注意：消息5-6是加密的，加密密钥来自前面 DH 和随机数派生出的临时密钥。这就是"主模式"安全的原因：身份信息不在明文中传输。
三把钥匙的详细推导与分工
从 DH 共享密钥、随机数、预共享密钥等材料，通过 PRF（伪随机函数，通常就是HMAC-SHA1） 反复迭代，生成一个叫 SKEYID 的种子。然后再用 SKEYID 派生出三个密钥材料：
bash
SKEYID = PRF(预共享密钥, DH共享密钥 | 随机数A | 随机数B)然后：
bash
SKEYID_d = PRF(SKEYID, DH共享密钥 | 随机数A | 随机数B | 0)
SKEYID_a = PRF(SKEYID, SKEYID_d | DH共享密钥 | 随机数A | 随机数B | 1)
SKEYID_e = PRF(SKEYID, SKEYID_a | DH共享密钥 | 随机数A | 随机数B | 2)| 钥匙 | 名称 | 用途 | 长度取决 |
|---|---|---|---|
| SKEYID_d | 派生密钥 | 用于第二阶段派生 IPsec SA 的加密/认证密钥 | 哈希算法输出（如SHA1=160位） |
| SKEYID_a | 认证密钥 | 对 IKE 消息计算 HMAC，保证完整性 | 同上 |
| SKEYID_e | 加密密钥 | 加密 IKE 消息 | 协商的加密算法需要多少位就取多少 |
| 钥匙代号 | 名称 | 加密/保护的对象 | 谁使用 | 何时使用 |
|---|---|---|---|---|
| SKEYID_e | 加密密钥 | IKE消息的载荷（身份ID、证书、HASH等） | 双方 | IKE主模式第5、6条消息，及所有后续IKE消息（如快速模式） |
| SKEYID_a | 认证密钥 | 对整个IKE消息做HMAC（完整性校验） | 双方 | 同上，与加密同时使用 |
| SKEYID_d | 派生密钥 | 不直接加密，而是用于派生IPsec SA的加密/认证密钥 | 双方 | IKE第二阶段（快速模式） |
一句话 ：
SKEYID_e 负责"不让别人偷看"，SKEYID_a 负责"不让别人篡改"，SKEYID_d 负责"生出后续孩子（IPsec密钥）"。
