浅谈IPsec、IKE和IKEv2的基本原理

比眉伴天荒 2024-03-22 22:51 112阅读 0赞

### IPsec简介 ###

IPsec（IP Security，IP安全）是IETF制定的三层隧道加密协议，它为互联网上传输的数据提供了高质量的、基于密码学的安全保证，是一种传统的实现三层VPN（Virtual Private Network，虚拟专用网络）的安全技术。IPsec通过在特定通信方之间（例如两个安全网关之间）建立“通道”，来保护通信方之间传输的用户数据，该通道通常称为IPsec隧道。

#### IPsec协议框架 ####

IPsec协议不是一个单独的协议，它为IP层上的网络数据安全提供了一整套安全体系结构，包括安全协议AH（Authentication Header，认证头）和ESP（Encapsulating Security Payload，封装安全载荷）以及用于网络认证及加密的一些算法等。其中，AH协议和ESP协议用于提供安全服务。

#### IPsec提供的安全服务 ####

IPsec提供了两大安全机制：认证和加密。认证机制使IP通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。加密机制通过对数据进行加密运算来保证数据的机密性，以防数据在传输过程中被窃听。

IPsec为IP层的数据报文提供的安全服务具体包括以下几种：

*  数据机密性（Confidentiality）：发送方通过网络传输用户报文前，IPsec对报文进行加密。
 *  数据完整性（Data Integrity）：接收方对发送方发送来的IPsec报文进行认证，以确保数据在传输过程中没有被篡改。
 *  数据来源认证（Data Origin Authentication）：接收方认证发送IPsec报文的发送端是否合法。
 *  抗重放（Anti-Replay）：接收方可检测并拒绝接收过时或重复的IPsec报文。

#### IPsec的优点 ####

IPsec可为IP层上的数据提供安全保护，其优点包括如下几个方面：

*  所有使用IP协议进行数据传输的应用系统和服务都可以使用IPsec，而不必对这些应用系统和服务本身做任何修改。
 *  对数据的加密是以数据包为单位的，而不是以整个数据流为单位，这不仅灵活而且有助于进一步提高IP数据包的安全性，可以有效防范网络攻击。

#### 安全协议 ####

IPsec包括AH和ESP两种安全协议，它们定义了对IP报文的封装格式以及可提供的安全服务。

*  AH协议（IP协议号为51）定义了AH头在IP报文中的封装格式，如图1-5所示。AH可提供数据来源认证、数据完整性校验和抗重放功能，它能保护报文免受篡改，但不能防止报文被窃听，适合用于传输非机密数据。

![图1-1 AH头格式][1-1 AH] 图1-1 AH头格式

*  ESP协议（IP协议号为50）定义了ESP头和ESP尾在IP报文中的封装格式，如图1-5所示。ESP可提供数据加密、数据来源认证、数据完整性校验和抗重放功能。与AH不同的是，ESP将需要保护的用户数据进行加密后再封装到IP包中，以保证数据的机密性。ESP使用的加密算法有DES、3DES、AES等。同时，作为可选项，ESP还可以提供认证服务。虽然AH和ESP都可以提供认证服务，但是AH提供的认证服务要强于ESP。

![图1-2 ESP头和尾格式][1-2 ESP] 图1-2 ESP头和尾格式

在实际使用过程中，可以根据具体的安全需求同时使用这两种协议或仅使用其中的一种。设备支持的AH和ESP联合使用的方式为：先对报文进行ESP封装，再对报文进行AH封装。

#### 封装模式 ####

IPsec支持两种封装模式：传输模式和隧道模式。

1.  传输模式（Transport Mode）

该模式下的安全协议主要用于保护上层协议报文，仅传输层数据被用来计算安全协议头，生成的安全协议头以及加密的用户数据（仅针对ESP封装）被放置在原IP头后面。若要求端到端的安全保障，即数据包进行安全传输的起点和终点为数据包的实际起点和终点时，才能使用传输模式。如图1-3所示，通常传输模式用于保护两台主机之间的数据。

![图1-3 传输模式下的IPsec保护][1-3 _IPsec] 图1-3 传输模式下的IPsec保护

1.  隧道模式（Tunnel Mode）

该模式下的安全协议用于保护整个IP数据包，用户的整个IP数据包都被用来计算安全协议头，生成的安全协议头以及加密的用户数据（仅针对ESP封装）被封装在一个新的IP数据包中。这种模式下，封装后的IP数据包有内外两个IP头，其中的内部IP头为原有的IP头，外部IP头由提供安全服务的设备添加。在安全保护由设备提供的情况下，数据包进行安全传输的起点或终点不为数据包的实际起点和终点时（例如安全网关后的主机），则必须使用隧道模式。如图1-4所示，通常隧道模式用于保护两个安全网关之间的数据。

![图1-4 隧道模式下的IPsec保护][1-4 _IPsec] 图1-4 隧道模式下的IPsec保护

不同的安全协议及组合在隧道和传输模式下的数据封装形式如图1-5所示。

![图1-5 安全协议数据封装格式][1-5] 图1-5 安全协议数据封装格式

#### 安全联盟 ####

IPsec在两个端点之间提供安全通信，这类端点被称为IPsec对等体。SA（Security Association，安全联盟）是IPsec对等体间对某些要素的约定，例如，使用的安全协议（AH、ESP或两者结合使用）、协议报文的封装模式（传输模式或隧道模式）、认证算法、加密算法（DES、3DES或AES）、特定流中保护数据的共享密钥以及密钥的生存时间等。

SA是单向的，在两个对等体之间的双向通信，最少需要两个SA来分别对两个方向的数据流进行安全保护。同时，如果两个对等体希望同时使用AH和ESP来进行安全通信，则每个对等体都会针对每一种协议来构建一个独立的SA。

SA由一个三元组来唯一标识，这个三元组包括SPI（Security Parameter Index，安全参数索引）、目的IP地址和安全协议号。其中，SPI是用于标识SA的一个32比特的数值，它在AH和ESP头中传输。

SA采用手工配置的方式，通过命令行配置SA的所有信息，手工方式建立的SA永不老化。

1.  认证算法

IPsec使用的认证算法主要是通过杂凑函数实现的。杂凑函数是一种能够接受任意长度的消息输入，并产生固定长度输出的算法，该算法的输出称为消息摘要。IPsec对等体双方都会计算一个摘要，接收方将发送方的摘要与本地的摘要进行比较，如果二者相同，则表示收到的IPsec报文是完整未经篡改的，以及发送方身份合法。

1.  加密算法

IPsec使用的加密算法属于对称密钥系统，这类算法使用相同的密钥对数据进行加密和解密。目前设备的IPsec使用三种加密算法：

*  DES：使用56比特的密钥对一个64比特的明文块进行加密。
 *  3DES：使用三个56比特（共168比特）的密钥对明文块进行加密。
 *  AES：使用128比特、192比特或256比特的密钥对明文块进行加密。

这三个加密算法的安全性由高到低依次是：AES、3DES、DES，安全性高的加密算法实现机制复杂，运算速度慢。

#### IPsec隧道保护的对象 ####

IPsec隧道可以保护IPv6路由协议报文。要实现建立IPsec隧道为两个IPsec对等体之间的数据提供安全保护，首先要配置和应用相应的安全策略，这里的安全策略包括IPsec安全策略和IPsec安全框架。有关IPsec安全策略和IPsec安全框架的详细介绍请参见“IPsec安全策略和IPsec安全框架”。

当IPsec对等体根据IPsec安全策略和IPsec安全框架识别出要保护的报文时，就建立一个相应的IPsec隧道并将其通过该隧道发送给对端。这些IPsec隧道实际上就是两个IPsec对等体之间建立的IPsec SA。由于IPsec SA是单向的，因此出方向的报文由出方向的SA保护，入方向的报文由入方向的SA来保护。对端接收到报文后，首先对报文进行分析、识别，然后根据预先设定的安全策略对报文进行不同的处理（丢弃，解封装，或直接转发）。

![图1-6 IPsec入站包处理流程][1-6 IPsec] 图1-6 IPsec入站包处理流程

#### IPsec隧道保护IPv6路由协议报文 ####

将IPsec安全框架应用到某一IPv6路由协议（目前支持保护OSPFv3、IPv6 BGP、RIPng路由协议）后，设备产生的需要IPsec保护的某一IPv6路由协议的所有报文都要进行封装处理，而设备接收到的不受IPsec保护的以及解封装失败的业务协议报文都要被丢弃。

由于IPsec的密钥交换机制仅适用于两点之间的通信保护，在广播网络一对多的情形下，IPsec无法实现自动交换密钥，同样，由于广播网络一对多的特性，要求各设备对于接收、发送的报文均使用相同的SA参数（相同的SPI及密钥），因此该方式下必须手工配置用来保护IPv6路由协议报文的IPsec SA。

#### IPsec安全策略和IPsec安全框架 ####

IPsec安全策略和IPsec安全框架用于在两个对等体之间建立IPsec隧道，保护两个对等体之间需要被安全防护的报文。

1.  IPsec安全策略

一个IPsec安全策略是若干具有相同名字、不同顺序号的IPsec安全策略表项的集合，IPsec安全策略被应用在接口上，用于控制对等体之间建立IPsec隧道，由ACL定义要保护的数据范围。IPsec安全策略主要定义了以下内容：

*  要保护的数据流的范围：由ACL定义。
 *  对数据流实施何种保护：由IPsec安全提议定义。
 *  IPsec SA的生成方式为手工方式。
 *  保护路径的起点或终点：即对等体的IP地址。

在同一个IPsec安全策略中，顺序号越小的IPsec安全策略表项优先级越高。当从一个接口发送数据时，接口将按照顺序号从小到大的顺序逐一匹配引用的IPsec安全策略中的每一条安全策略表项。如果数据匹配上了某一条安全策略表项引用的ACL，则停止匹配，并对其使用当前这条安全策略表项进行处理，即根据已经建立的IPsec SA对报文进行封装处理；如果数据与所有安全策略表项引用的ACL都不匹配，则直接被正常转发，IPsec不对数据加以保护。

应用了IPsec安全策略的接口收到数据报文时，对于目的地址是本机的IPsec报文，根据报文头里携带的SPI查找本地的IPsec SA，并根据匹配的IPsec SA对报文进行解封装处理；解封装后的IP报文若能与ACL的permit规则匹配上则采取后续处理，否则被丢弃。

IPsec安全策略除了可以应用到串口、以太网接口等实际物理接口上之外，还能够应用到Tunnel、Virtual Template等虚接口上，对流量进行保护。

1.  IPsec安全框架

IPsec安全框架（IPsec Profile）与IPsec安全策略类似，但不需要使用ACL指定要保护的数据流的范围。一个IPsec安全框架由名字唯一确定。手工方式的IPsec安全框架定义了对数据流进行IPsec保护所使用的安全提议，以及SA参数，应用于IPv6路由协议中。

#### 协议规范 ####

与IPsec相关的协议规范有：

*  RFC 2401：Security Architecture for the Internet Protocol
 *  RFC 2402：IP Authentication Header
 *  RFC 2406：IP Encapsulating Security Payload
 *  RFC 4552：Authentication/Confidentiality for OSPFv3

### IKE简介 ###

IKE（Internet Key Exchange，互联网密钥交换）协议利用ISAKMP（Internet Security Association and Key Management Protocol，互联网安全联盟和密钥管理协议）语言定义密钥交换的过程，是一种对安全服务进行协商的手段。

用IPsec保护一个IP数据包之前，必选先建立一个安全联盟（IPsec SA），IPsec SA可以手工创建或动态建立。IKE为IPsec提供了自动建立IPsec SA的服务，具体有以下优点。

*  IKE首先会在通信双方之间协商建立一个安全通道（IKE SA），并在此安全通道的保护下协商建立IPsec SA，这降低了手工配置的复杂度，简化IPsec的配置和维护工作。
 *  IKE的精髓在于DH（Diffie-Hellman）交换技术，它通过一系列的交换，使得通信双方最终计算出共享密钥。在IKE的DH交换过程中，每次计算和产生的结果都是不相关的。由于每次IKE SA的建立都运行了DH交换过程，因此就保证了每个通过IKE协商建立的IPsec SA所使用的密钥互不相关。
 *  IPsec使用AH或ESP报文头中的顺序号实现防重放。此顺序号是一个32比特的值，此数溢出之前，为实现防重放，IPsec SA需要重新建立，IKE可以自动重协商IPsec SA。

如图2-1所示，IKE为IPsec协商建立SA，并把建立的参数交给IPsec，IPsec使用IKE建立的SA对IP报文加密或认证处理。

![图2-1 IPsec与IKE的关系图][2-1 IPsec_IKE] 图2-1 IPsec与IKE的关系图

#### IKE的协商过程 ####

IKE使用了两个阶段为IPsec进行密钥协商以及建立SA：

(1) 第一阶段，通信双方彼此间建立了一个已通过双方身份认证和对通信数据安全保护的通道，即建立一个IKE SA（本文中提到的IKE SA都是指第一阶段SA）。第一阶段有主模式（Main Mode）和野蛮模式（Aggressive Mode）两种IKE协商模式。

(2) 第二阶段，用在第一阶段建立的IKE SA为IPsec协商安全服务，即为IPsec协商IPsec SA，建立用于最终的IP数据安全传输的IPsec SA。

![图2-2 主模式交换过程][2-2] 图2-2 主模式交换过程

如图2-2所示，第一阶段主模式的IKE协商过程中包含三对消息，具体内容如下：

*  第一对消息完成了SA交换，它是一个协商确认双方IKE安全策略的过程；
 *  第二对消息完成了密钥交换，通过交换Diffie-Hellman公共值和辅助数据（如：随机数），最终双方计算生成一系列共享密钥（例如，认证密钥、加密密钥以及用于生成IPsec密钥参数的密钥材料），并使其中的加密密钥和认证密钥对后续的IKE消息提供安全保障；
 *  第三对消息完成了ID信息和验证数据的交换，并进行双方身份的认证。

野蛮模式交换与主模式交换的主要差别在于，野蛮模式不提供身份保护，只交换3条消息。在对身份保护要求不高的场合，使用交换报文较少的野蛮模式可以提高协商的速度；在对身份保护要求较高的场合，则应该使用主模式。

![图2-3 野蛮模式交换过程][2-3] 图2-3 野蛮模式交换过程

#### IKE的安全机制 ####

IKE可以在不安全的网络上安全地认证通信双方的身份、分发密钥以及建立IPsec SA，具有以下几种安全机制。

1.  身份认证

IKE的身份认证机制用于确认通信双方的身份。设备支持三种认证方法：预共享密钥认证、RSA数字签名认证和DSA数字签名认证。

*  预共享密钥认证：通信双方通过共享的密钥认证对端身份。
 *  数字签名认证：通信双方使用由CA颁发的数字证书向对端证明自己的身份。

1.  DH算法

DH算法是一种公共密钥算法，它允许通信双方在不传输密钥的情况下通过交换一些数据，计算出共享的密钥。即使第三方（如黑客）截获了双方用于计算密钥的所有交换数据，由于其复杂度很高，也不足以计算出双方的密钥。

1.  PFS特性

PFS（Perfect Forward Secrecy，完善的前向安全性）是一种安全特性，它解决了密钥之间相互无关性的需求。由于IKE第二阶段协商需要从第一阶段协商出的密钥材料中衍生出用于IPsec SA的密钥，若攻击者能够破解IKE SA的一个密钥，则会非常容易得掌握其衍生出的任何IPsec SA的密钥。使用PFS特性后，IKE第二阶段协商过程中会增加一次DH交换，使得IKE SA的密钥和IPsec SA的密钥之间没有派生关系，即使IKE SA的其中一个密钥被破解，也不会影响它协商出的其它密钥的安全性。

2.3 协议规范

与IKE相关的协议规范有：

*  RFC2408：Internet Security Association and Key Management Protocol (ISAKMP)
 *  RFC2409：The Internet Key Exchange (IKE)
 *  RFC2412：The OAKLEY Key Determination Protocol

### IKEv2简介 ###

IPsec隧道两端通过共享密钥对IP报文提供机密性、完整性、以及数据来源认证服务。共享密钥可以手工建立，也可以通过协商方式自动建立。IKE协议定义了自动协商共享密钥的机制，并用于建立和维护IPsec安全联盟。IKEv2（Internet Key Exchange Version 2，互联网密钥交换协议第2版）是第1版本的IKE协议（本文简称IKEv1）的增强版本，它在保留了IKEv1中的大部分特性的基础上引入了一些新特性。

IKEv2与IKEv1相同，具有一套自保护机制，可以在不安全的网络上安全地进行身份认证、密钥分发、建立IPsec SA。相对于IKEv1，IKEv2具有抗攻击能力和密钥交换能力更强以及报文交互数量较少等特点。

#### IKEv2的协商过程 ####

要建立一对IPsec SA，IKEv1需要经历两个阶段，至少需要交换6条消息。在正常情况下，IKEv2只需要进行两次交互，使用4条消息就可以完成一个IKEv2 SA和一对IPsec SA的协商建立，如果要求建立的IPsec SA的数目大于一对，则每增加一对IPsec SA只需要额外增加一次交互，也就是两条消息就可以完成，这相比于IKEv1简化了设备的处理过程，提高了协商效率。

IKEv2定义了三种交互：初始交换、创建子SA交换以及通知交换。

下面简单介绍一下IKEv2协商过程中的初始交换过程。

![图3-1 IKEv2的初始交换过程][3-1 IKEv2] 图3-1 IKEv2的初始交换过程

如图3-1所示，IKEv2的初始交换过程中包含两个交换：IKE\_SA\_INIT交换（两条消息）和IKE\_AUTH交换（两条消息）。

*  IKE\_SA\_INIT交换：完成IKEv2 SA参数的协商以及密钥交换；
 *  IKE\_AUTH交换：完成通信对等体的身份认证以及IPsec SA的创建。

这两个交换过程顺序完成后，可以建立一个IKEv2 SA和一对IPsec SA。

创建子SA交换：当一个IKE SA需要创建多个IPsec SA时，使用创建子SA交换来协商多于一个的SA，另外还可用于进行IKE SA的重协商功能。

通知交换：用于传递控制信息，例如错误信息或通告信息。

#### IKEv2引入的新特性 ####

1.  IKEv2支持DH猜想

在IKE\_SA\_INIT交换阶段，发起方采用“猜”的办法，猜一个响应方最可能使用的DH组携带在第一条消息中发送。响应方根据发起方“猜”的DH组来响应发起方。如果发起方猜测成功，则这样通过两条消息就可以完成IKE\_SA\_INIT交换。如果发起方猜测错误，则响应方会回应一个INVALID\_KE\_PAYLOAD消息，并在该消息中指明将要使用的DH组。之后，发起方采用响应方指定的DH组重新发起协商。这种DH猜想机制，使得发起方的DH组配置更为灵活，可适应不同的响应方。

1.  IKEv2支持cookie-challenge机制

在IKE\_SA\_INIT交换中消息是明文传输的，响应方接收到第一个消息后无法确认该消息是否来自一个仿冒的地址。如果此时一个网络攻击者伪造大量地址向响应方发送IKE\_SA\_INIT请求，根据IKEv1协议，响应方需要维护这些半开的IKE会话信息，从而耗费大量响应方的系统资源，造成对响应方的DoS攻击。

IKEv2使用cookie-challenge机制来解决这类DoS攻击问题。当响应方发现存在的半开IKE SA超过指定的数目时，就启用cookie-challenge机制。响应方收到IKE\_SA\_INIT请求后，构造一个Cookie通知载荷并响应发起方，若发起方能够正确携带收到的Cookie通知载荷向响应方重新发起IKE\_SA\_INIT请求，则可以继续后续的协商过程。

半开状态的IKEv2 SA是指那些正在协商过程中的IKEv2 SA。若半开状态的IKEv2 SA数目减少到阈值以下，则cookie-challenge功能将会停止工作。

1.  IKEv2 SA重协商

为了保证安全，IKE SA和IPsec SA都有一个生命周期，超过生命周期的SA需要重新协商，即SA 的重协商。与IKEv1不同的是，IKEv2 SA的生命周期不需要协商，由各自的配置决定，重协商总是由生命周期较小的一方发起，可尽量避免两端同时发起重协商造成冗余SA的生成，导致两端SA状态不一致。

1.  IKEv2报文确认重传机制

与IKEv1不同，IKEv2中所有消息都是以“请求–响应”对的形式出现，IKEv2通过消息头中的一个Message ID字段来标识一个“请求–响应”对。发起方发送的每一条消息都需要响应方给予确认，例如建立一个IKE SA一般需要两个“请求-响应”对。如果发起方在规定时间内没有接收到确认报文，则需要对该请求消息进行重传。IKEv2消息的重传只能由发起方发起，且重传消息的Message ID必须与原始消息的Message ID一致。

#### 协议规范 ####

与IKEv2相关的协议规范有：

*  RFC 2408：Internet Security Association and Key Management Protocol (ISAKMP)
 *  RFC 4306：Internet Key Exchange (IKEv2) Protocol
 *  RFC 4718：IKEv2 Clarifications and Implementation Guidelines
 *  RFC 2412：The OAKLEY Key Determination Protocol
 *  RFC 5996：Internet Key Exchange Protocol Version 2 (IKEv2)

[1-1 AH]: https://img.wljslmz.cn/wljslmzcn/202209280924559.png
[1-2 ESP]: https://img.wljslmz.cn/wljslmzcn/202209280925298.png
[1-3 _IPsec]: https://img.wljslmz.cn/wljslmzcn/202209280927673.png
[1-4 _IPsec]: https://img.wljslmz.cn/wljslmzcn/202209280928702.png
[1-5]: https://img.wljslmz.cn/wljslmzcn/202209280925537.png
[1-6 IPsec]: https://img.wljslmz.cn/wljslmzcn/202209280928052.png
[2-1 IPsec_IKE]: https://img.wljslmz.cn/wljslmzcn/202209280926632.png
[2-2]: https://img.wljslmz.cn/wljslmzcn/202209280926939.png
[2-3]: https://img.wljslmz.cn/wljslmzcn/202209280926668.png
[3-1 IKEv2]: https://img.wljslmz.cn/wljslmzcn/202209280927128.png