IPSec协议分析
简介
IPSec主要包括安全协议AH（Authentication Header）和ESP（Encapsulating Security Payload），密钥管理交换协议IKE（Internet Key Exchange）以及用于网络认证及 加密 的一些算法等。
IPSec主要通过加密与验证等方式，为IP数据包提供安全服务。
IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输：
- 数据来源验证：接收方验证发送方身份是否合法；
- 数据加密：发送方对数据进行加密，以密文的形式在Internet上传送，接收方对接收的加密数据进行解密后处理或直接转发；
- 数据完整性：接收方对接收的数据进行验证，以判定报文是否被篡改；
- 抗重放：接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击；
IPSec首选使用IKE协议建立IPSec SA（安全联盟），安全联盟是要建立IPSec 隧道的通信双方对隧道参数的约定，包括隧道两端的IP地址、隧道采用的验证方式、验证算法、验证密钥、加密算法、共享密钥以及生命周期等一系列参数。
SA由三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或 ESP ）。其中，SPI是为唯一标识SA而生成的一个32位比特的数值，它在AH和ESP头中传输。在手工配置SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。
SA是单向的逻辑连接，因此两个IPSec对等体之间的双向通信，最少需要建立两个SA来分别对两个方向的数据流进行安全保护。
SA是IPSec的一个基本组成部分，SA是SADB的一个条目，它包含双方关于IKE和IPSec已经协商完毕的安全信息。
- IKE or ISAKMP SA：双向的，决定了IKE协议处理相关细节
- IPSec SA：单向的，与封装协议相关，决定了具体加密流量的处理方式。
IKE协议
因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）500 端口号，的应用层协议。
IKE协商两种SA：
- IKE(ISAKMP) SA (阶段一）；
- IPSEC SA（阶段二）；
IKE的三个组件：
- SKEME：实现公钥加密认证的机制
- Oakley：基于到达两个对等体间的加密密钥的机制
- ISAKMP：在两个实体间进行分组格式及状态转换的消息交换的体系结构。
IKE与IPSec的关系：
IKE为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的使用和管理，大大简化IPSec的配置和维护工作。
IKE与IPSec的关系如上图所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。
IKE的安全机制：
IKE具有一套自保护机制，可以在不安全的网络上安全地认证身份、分发密钥、建立IPsec SA：
身份认证
身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared key）认证、数字证书RSA（rsa-signature）认证和数字信封认证。
- 在预共享密钥认证中，认证字作为一个输入来产生密钥，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
- 在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。
- 在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。
ISAKMP报文格式：
8 12 16 24 32
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 发起者 !
! Initiator Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 应答 !
! Responder Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 下一个载荷 ! MjVer ! MnVer ! 交换类型 ! 标志 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 消息 ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 长度 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 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- Flags ― 为 ISAKMP 交换设置的各种选项。
- Message ID ― 唯一的信息标识符，用来识别第2阶段的协议状态。
- Length ― 全部信息（头＋有效载荷）长（八位）。
IKE的两个阶段：
采用IKEv1协商安全联盟主要分为两个阶段：第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟
经典版本的IKEv1有两个阶段：
-
阶段一 ： IKE SA
主模式（6个包）
野蛮模式（3个包）
-
阶段二：IPSec SA
快速模式（3个包）
第一阶段
IKEv1的主模式协商：包含了三次双向交换，用到了六条ISAKMP信息。协商过程如下图所示：
这三次交换分别是：
-
消息①和②用于策略交换
发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
-
消息③和④用于密钥信息交换
-
双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
-
消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。
IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
nonce是个随机数，用于保证IKE SA存活和抗重放攻击。
阶段一: 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
-----------------------------------------------------------------
阶段一的第1个包（明文）：
第一包的作用是，协商发起发，发送IKE安全提议，给响应方。下图为抓包示例内容：
电力监控系统的纵向加密认证装置，使用数字证书的方式进行身份认证
阶段一的第2个包（明文）：
第2个包的作用主要是：通过查找第一个包的安全提议。给发送者回复一个确认的安全提议。下图是第二个包的抓包内容。
阶段一的第3个包（明文）：
第三个包的作用：如果发起方接受了安全提议，就给对方发送密钥生成信息，对方用来生成IKE的秘钥。
阶段一第四个包（明文）：
主要作用：协商相应方给协商发起方发送密钥生成信息，使得协议发起方能生成密钥。
然后双方各自计算出共享的密钥，一共有三个密钥，SKEYID_a，d，e，其中d是根据z=pfs（pre-shared key，cookie_i，cookie_ni，nl|0），其中d用来给第二阶段提供密钥的素材。a用来对IKE的数据进行认证，e用来加密整个IKE协商的数据。
K值为推导SKEYID使用
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)---------加密密钥当使用预共享密钥认证与主模式时，密钥可以只能通过对等点的IP地址来标识，因为必须使用HASH_I，在启动程序处理IDir之前计算。野蛮模式允许更大范围的预共享密钥标识符被使用。此外，野蛮模式允许双方进行维护多个不同的预共享密钥，并确定正确的密钥一个特定的交换。
阶段一的第5个包（密文）：
主要作用：发起方发送身份和验证数据。
初始方开始继续协商，发送第五个信息，注意，此刻所有的负载信息是被ekey加密过的。信息主要包含两个内容，其中之一是标识负载，另一个是散列负载，标识负载的主要内容是包含自己的IP地址，就是我们所谓的ID_I，或者是主机名称。散列负载主要的内容是使用session_a进行的散列计算，计算的参数有上述的Z，和两端的cookie，pre-share key ，提议，转换集，SA的内容。
阶段一的第6个包（密文）：
主要作用: 协商响应方给发起方发送身份和验证数据。
Authentication: No authentication：这里的描述极具误导性，但符合标准。 在IKEv1报文头中，
Authentication标志位特指“载荷是否包含数字签名”。对于PSK认证，其认证载荷 (AUTH) 是一个哈希值，而非数字签名，所以此标志位为0。这并不代表“没有进行身份认证”，而是代表“没有使用基于数字签名的认证”。PSK认证正在进行中。
然后当接收方收到的时候进行确认，先解密，然后根据ID找到pre-key，然后进行相同的计算，得出散列的值，然后对比接收呼叫。
总结：在这个过程中，所有的数据都是被封装在UDP 500的端口内进行协商的。
| 特性 | 预共享密钥 | 数字证书 |
|---|---|---|
| 身份凭据 | 一个双方预先配置的、相同的密码字符串。 | 基于PKI体系，双方持有由可信第三方（CA）签发的X.509数字证书和对应的私钥。 |
| 认证本质 | 验证对方是否知道同一个“秘密”。你知道秘密，所以我假设你就是你声称的身份。 | 验证对方持有的证书是否由可信CA签发，并且用证书中的公钥验证其数字签名。可信第三方证明你是谁，并且你能用对应的私钥签名来证明你是你。 |
| 身份绑定 | 弱。通常与IP地址绑定（如配置时指定对端IP和PSK）。IP欺骗可能导致身份冒用。 | 强。证书中的“主题”字段（如CN=gatewayA.company.com）明确绑定了身份，与IP无关。 |
| 扩展性 | 差。每对设备之间都需要单独配置一个密钥。N台设备需要管理约N²/2个密钥，难以维护。 | 优。只需将所有设备信任同一个根CA，任何两台设备都可以自动验证对方身份。易于增加新设备。 |
| 安全性 | 依赖于密钥的复杂性和保密性。密钥泄露、弱密钥、静态密钥长期不更换是主要风险。 | 依赖于私钥的保密性和PKI体系的安全性。支持密钥轮换和吊销（CRL/OCSP）。 |
第二阶段：
IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。
阶段二的快速模式的协商如下：
Initiator Responder
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) --> HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：
-
协商发起方发送本端的安全参数和身份认证信息。
-
安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。
-
协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。
-
IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。
-
如果启用PSF，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
-
发送方发送确认信息，确认与响应方可以通信，协商结束。
AH协议与ESP协议
| 区别与联系 | AH协议 | ESP协议 |
|---|---|---|
| 名字 | 验证头部协议 | 封装安全载荷协议 |
| IP协议封装的协议 | 是 | 是 |
| IP协议字段 | 51 | 50 |
| 下一头部 | 在最开始的8位，指明载荷类型（TCP\UDP\IP\IPSec） | ESP尾部，8位，语义与AH一致 |
| 载荷长度 | 8比特，表示以32比特为单位的AH头部长度减2 | 无此字段 |
| 保留字段 | 16bits，默认0，为保留用 | 无此字段 |
| SPI | 32比特，用于标识有相同IP地址和相同安全协议的不同SA。由SA的创建者定义，只有逻辑意义 | ESP头部，32位，语义与AH一致 |
| 序列号 | 32比特，一个单项递增的计数器，用于防止重放攻击，SA建立之初初始化为0，序列号不允许重复 | ESP头部，32位，语义与AH一致 |
| 认证数据 | 摘要或者指纹，用于认证，由SA初始化时指定的算法来计算，长度=整数倍32位比特，变长（通信双方必须采用相同的HMAC算法和密钥，认证数据是HMAC算法结果，被称为数据报的完整性校验值ICV，） | ESP验证数据，可选，选择ESP验证服务时使用，语义和AH一致（但具体验证区域不同） |
| 载荷数据 | 紧跟AH头部的载荷，变长，明文 | 可变长字段，包含实际的载荷数据，根据是否需要加密，该字段可以是密文或者明文 |
| 填充和填充长度 | 无 | 填充字段，0-255字节，大多数加密算法要求输入数据包含整数个分组，因此需要填充。填充长度，8bits，填充字段的长度。 |
| 报文格式 | AH头部+AH载荷 | ESP头部+ESP净荷+ESP尾部（填充、填充长度和下一个头字段）+ESP验证数据（可选） |
| 传输模式 | 保护IP载荷 | 保护IP载荷 |
| 传输模式验证区域 | IP头部+AH头部+TCP/UDP头部+数据（可变字段除外） | ESP头部+ TCP/UDP头部+数据+ESP尾部 |
| 传输模式加密区域 | 无 | ESP净荷+ESP尾部 |
| 隧道模式 | 保护整个IP包 | 保护整个IP包 |
| 隧道模式验证区域 | 新IP头部+AH头部+ IP头部+ TCP/UDP头部+数据（可变字段除外） | ESP头部+IP头部+TCP/UDP头部+数据+ESP尾部 |
| 隧道模式加密区域 | 无 | ESP净荷+ESP尾部 |
| 外出处理 | 查询SAD，产生或增加序列号，计算完整性校验值（ICV） | 如果验证，则和AH相同；如果进行加密，则还会加密分组；如果加密+验证，则计算ICV和加密都有 |
| 进入处理 | 重组分片，查询SAD并操作，查询SPD并检查，检查序列号（抗重放功能），认证检查数据完整性 | 如果验证，则和AH相同；如果加密，则还需解密操作；如果验证+加密，则计算ICV比较和解密都有 |
| 算法 | 验证 | 验证、加密（至少有一种） |
| 服务 | 无连接的数据完整性：通过哈希函数产生的校验来保证 数据源身份认证：通过计算校验码时加入一个共享密钥实现 防止重放攻击：AH报头的序列号可以防止重放攻击 | 除了AH已有的三种服务之外（可选），还提供数据包加密和数据流加密 |
| 与NAT的联系 | NAT会对IP头进行修改导致AH协议下的IPsec不能穿越NAT | 如果是NAT对IP头进行修改，ESP能适用于NAT。但如果NAT为IP地址映射+端口映射（端口改变），则ESP协议下的IPSec都不能适用NAT（考虑NAT-T） |
AH协议
ESP协议
| 特性 | 加密范围 | 认证范围 |
|---|---|---|
| 目的 | 机密性 | 完整性、真实性、抗重放 |
| 是否可选 | 是 | 是 |
| 包含的内容 | 原始载荷 + ESP尾部（Pad, Pad Len, Next Hdr） | ESP头 + 加密范围的全部内容 + ESP尾部 |
| 在报文中的位置 | ESP头之后，Next Header字段之前（均为密文） | 整个数据包的最后（ICV，明文） |
| 保护关系 | 认证范围包含了加密范围。即先对数据进行加密，然后对整个结果（包括加密后的数据和外层的ESP头）进行认证。 |
Comments NOTHING