IPSec之IKEv1详解

IKEv1协商安全联盟的过程

IKE协议

因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）端口为500的应用层协议。

ISAKMP报文格式：

Initiator Cookie ― Initiator Cookie：启动 SA 建立、SA 通知或 SA 删除的实体 Cookie。
Responder Cookie ― Responder Cookie：响应 SA 建立、SA 通知或 SA 删除的实体 Cookie。
Next Payload ― 信息中的 Next Payload 字段类型。
Major Version ― 使用的 ISAKMP 协议的主要版本。
Minor Version ― 使用的 ISAKMP 协议的次要版本。
Exchange Type ―
表示所用的交换类型。这表示消息和载荷遵循所用的交换顺序。
交换类型 值
NONE 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Informational 5
ISAKMP Future Use 6 - 31
DOI Specific Use 32 - 239
Private Use 240 - 255

抓包对照：

采用IKEv1协商安全联盟主要分为两个阶段：

第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；

第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟（IPSec SA）

IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。

IKEv1协商第一阶段支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。

**图1 **IKEv1协商阶段1的协商过程图

​

主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图1所示。这三次交换分别是：

1. 消息①和②用于提议交换发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
2. 消息③和④用于密钥信息交换双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
3. 消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。

​

• IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
• nonce是个随机数，用于保证IKE SA存活和抗重放攻击。

第一阶段：

IKEv1主模式的详细过程：

第一阶段的第①②个包

1-2包，用于安全参数协商（明文）

           HDR, SA             -->
           
                               <--    HDR, SA

1（Ci）2包（Ci、Cr）

HDR拆解为Ci，Cr，分别代表Initiator cookie和Responder Cookie。第一个包Cr为0。

Cookie值：随机参数=ip时间hash生成=Ci、对方已接收Cr确认回复

安全联盟：

认证算法：sha1(160)sha2(256\384\512)MD5

认证方式：RSA、预共享密钥

加密算法：DES(128)、3DES(168)、AES(128\192\256)

DH组：1、2经典、5

抓包验证：

第一个包：

安全提议展开

第二个包：

第一阶段的第③④个包

3-4个包 交换密钥素材，以及产生密钥(明文）

          HDR, KE, Ni         -->
      
                               <--    HDR, KE, Nr

Ni Nr----代表随机数
HDR拆解为Ci，Cr
KE为DH算法需要的密钥交换素材x，y
根据DH算法可以推导出一个共享的密钥K
K值为推导SKEYID使用 K = g^xy

SKEYID ------基准密钥
使用预共享密钥

**prf(key, msg) **是键控伪随机函数（pseudo-random function），通常是键控散列函数。用于生成出现伪随机的确定性输出。prf 用于密钥派生和身份验证（即作为密钥 MAC）：说人话就是一个函数，放入参数，进行计算得到一个输出

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 -->

                               <--    HDR*, IDir, HASH_R

采用数字证书的5 6两个包

HDR*, IDii, [ CERT, ] SIG_I -->

                                         <-- HDR*, IDir, [ CERT, ] SIG_R

IDii和IDir------标识，通常要IP地址

首先解释一下这里的密文，是根据第三四个包的SKEYID_e进行的加密
HASH_I = prf(SKEYID,K| Ci | Cr| SAi | IDi )
HASH_R = prf(SKEYID, K| Ci | Cr | SAr | IDr )

预共享密钥：将HASH_i和本地ID进行加密发送给对方，对端收到后先解密，得到HASH_i和ID。接受者收到后，将SKEYID+一系列参数+对端ID进行HASH，得到一个HSAH值，进行对比，相同则认证成功。

证书：CERTi=数字证书,SiGi=HASH_I用私钥加密=签名，证书只是验证是否对方身份

抓包验证：

数据加了密看不到东西

IKEv1野蛮模式的详细过程

野蛮模式（3个包）

        HDR, SA, KE, Ni, IDii -->
                                            <--    HDR, SA, KE, Nr, IDir, HASH_R
           HDR, HASH_I           -->

第1包-------安全提议（各种协商） 密钥交换素材 随机数 身份ID
HDR, SA, KE, Ni, IDii -->

第2包---------安全提议，密钥交换素材 随机数 身份ID HASH_R
<-- HDR, SA, KE, Nr, IDir, HASH_R

第3包---------加密的环境
HDR*, HASH_I -->
野蛮模式包里承载的内容跟主模式包里承载的内容目的是相同的，不再做赘述。

第二阶段

IKEv1协商阶段2

IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。IKEv1协商阶段2的协商过程如图2所示。

**图2 **IKEv1协商阶段2的协商过程图

IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：

1. 协商发起方发送本端的安全参数和身份认证信息。安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。 > 说明：IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。
2. 协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。如果启用PFS，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
3. 发送方发送确认信息，确认与响应方可以通信，协商结束。

第二阶段报文详解

HDR contains CKY-I | CKY-R

KE (for PFS) = g^I (Initiator) or g^r (Responder)

HASH(1)＝PRF (SKEYID_a | Message_ID | SA|Ni[|KE][| IDi2 | IDr2])

HASH(2)= PRF (SKEYID_a | Message_ID | Ni | SA|Nr[|KE][| IDi2 | IDr2])

HASH(3) =PRF (SKEYID_a | 0 | Message_ID | Ni | Nr)

IDi2：ACL，源IP和源掩码的哈希

IDr2：ACL，目的IP和目的掩码的哈希

解释：

使用IKEv1阶段1中生成的密钥SKEYID_a对ISAKMP消息的完整性和身份进行验证，使用密钥SKEYID_e对ISAKMP消息进行加密，故保证了交换的安全性。KE和第一阶段中的KE的目的是一样的，使用DH算法，计算出一个对公共的密钥作为隧道所用的加密密钥。

完美向前保密PFS

消息1发送本端的安全参数和身份认证信息（默认不协商感兴趣流）

安全参数包括保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。

2、消息2响应消息1，发送响应方安全参数和身份认证信息并生成新的密钥

对等体双方通过交换密钥材料生成新的共享密钥，并最终衍生出IPSec的加密密钥。此时响应者发送者各有两个SA

IPSec SA数据传输需要的加密、验证密钥由SKEYID_d、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥

当启用PFS时，要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组

抓包验证（加了密没啥好看的 -.-）：

主模式与野蛮模式的区别

1. 交换的消息：主模式为6个包，野蛮模式为3个包，野蛮模式能够更快创建IKE SA
2. NAT支持：对预共享密钥认证：主模式不支持NAT转换，而野蛮模式支持。而对于证书方式认证：两种模式都能支持
3. 对等体标识：主模式只能采用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信息也是明文的，也相应造成了安全隐患。
4. 提议转换对数量：在野蛮模式中，由于第一个消息就需要交换DH消息，而DH消息本身就决定了采用哪个DH组，这样在提议转换对中就确定了使用哪个DH组，如果第一个消息中包含多个提议转换对，那么这多个转换对的DH组必须相同(和DH消息确定的DH组一致)，否则消息1中只能携带和确定DH组相同的提议转换对。
5. 协商能力：由于野蛮模式交换次数的限制，因此野蛮模式协商能力低于主模式。
6. 主模式常用，野蛮已经不推荐使用,推荐使用模板方式
7. 两者之间的协商过程不同
8. 场景不同：

野蛮模式的场景：

与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。虽然野蛮模式不提供身份保护，但它可以满足某些特定的网络环境需求：

• 当IPSec隧道中存在NAT设备时，需要启动NAT穿越功能，而NAT转化会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得采用预共享密钥验证方式时，NAT穿越只能在野蛮模式中实现。
• 如果发起方的IP地址不固定或者无法预知，而双方都希望采用预共享密钥验证方法来创建IKE SA，则只能采用野蛮模式。
• 如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。

主模式场景：

要求两端都是固定IP地址

该文章仅供学习参考，若有侵权，联系删除
参考文档：华为hdx文档，防火墙技术漫谈，CSDN曹世宏博客