安基网 首页 安全 安全学院 查看内容

详解IPSec介绍

2021-1-12 09:40| 投稿: xiaotiger |来自: 互联网


免责声明:本站系公益性非盈利IT技术普及网,本文由投稿者转载自互联网的公开文章,文末均已注明出处,其内容和图片版权归原网站或作者所有,文中所述不代表本站观点,若有无意侵权或转载不当之处请从网站右下角联系我们处理,谢谢合作!

摘要: 定义IPSec是Internet工程任务组(IETF)制定的一个开放的网络层安全框架协议。它并不是一个单独的协议,而是一系列为IP网络提供安全性的协议和服务的集合。IPSec主要包括安全协议AH(Authentication Header)和ESP( ...

定义

IPSec是Internet工程任务组(IETF)制定的一个开放的网络层安全框架协议。它并不是一个单独的协议,而是一系列为IP网络提供安全性的协议和服务的集合。IPSec主要包括安全协议AH(Authentication Header)和ESP(Encapsulating Security Payload),密钥管理交换协议IKE(Internet Key Exchange)以及用于网络认证及加密的一些算法等。

目的

在IPv4协议诞生之时,Internet网络的规模还非常小,Internet网络的安全完全可以通过物理隔离的方式来保证。另一方面,所有人都未预料到以后Internet网络会爆炸式的增长,所以在设计和开发IPv4协议时,没有考虑IPv4协议的安全保护手段。

由于IP报文本身并不集成任何安全特性,恶意用户很容易便可伪造IP报文的地址、修改报文内容、重播以前的IP数据包以及在传输途中拦截并查看数据包的内容。因此,传统IP层协议不能担保收到的IP数据包的安全。在应用层保证网络安全的方法只对特定的应用有效,不够通用。人们迫切需要能够在IP层提供安全服务的协议,这样可以使TCP/IP高层的所有协议受益。IPSec(Internet Protocol Security)正是用来解决IP层安全性问题的技术。

IPSec主要通过加密与验证等方式,为IP数据包提供安全服务。IPSec可以提供的安全服务包括:

  • 数据加密通过数据加密提供数据私密性。
  • 数据源验证通过对发送数据的源进行身份验证,保证数据来自真实的发送者。
  • 防止数据重放通过在接收方拒绝重复的数据包防止恶意用户通过重复发送捕获到的数据包进行攻击。

受益

IPSec具有以下优点:

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

运营商场景


点到点VPN(Site-to-Site VPN)

IPSec可以为任何基于IP的通信提供安全保护,既可以保护传统的固定网络,也可以保护LTE等移动网络。

点到点VPN也称网关到网关VPN(Gateway to Gateway VPN),可以保证两个网关之间IP流量的安全性。典型组网如图1所示。图1 点到点VPN组网

点到点VPN部署非常灵活,而且当两个IPSec网关之间存在NAT设备时,支持IPSec NAT穿越。

企业场景


企业场景里IPSec主要用于公司之间通过IPSec VPN网络互连,典型应用是点到点VPN。企业场景里IPSec的组网更加灵活多样。

点到点VPN(Site-to-Site VPN)

点到点VPN主要用于公司总部与分支机构之间建立IPSec隧道,从而实现局域网之间互通。典型组网如图1所示。图1 点到点VPN组网

点到多点VPN(Hub-Spoke VPN)

实际组网中最常见的是公司总部与多个分支机构通过点到多点IPSec VPN互通,典型组网如图2所示。图2 Hub-Spoke VPN组网

在这种组网中,用户可以根据实际需求配置IPSec。

此时网络内数据流量可能存在如下两种情况:

  • 各分支机构之间不需要通信只有总部和分支之间部署IPSec VPN,也只有总部和分支之间存在业务流量。如图3所示。图3 Hub-Spoke VPN组网应用一
  • 各分支机构之间需要通信分支机构之间通过总部进行通信,如图4所示。图4 Hub-Spoke VPN组网应用二

分支机构用户上网控制

在点到点或点到多点VPN中,分支机构用户上网可以通过两种方式来实现。

  • 分支机构用户通过总部接入Internet为进行统一管理和监控,分支机构用户不允许通过自身的网关接入Internet,只能通过VPN接入到总部,然后通过总部访问Internet。分支访问Internet的流量一般需要在总部做NAT才能到公网。如图5所示。图5 分支机构用户通过总部接入Internet
  • 分支机构用户自行接入Internet对分支机构的上网流量不做控制,如图6所示。图6 分支机构用户自行接入Internet

安全协议


IPSec通过AH(Authentication Header,验证头)和ESP(Encapsulating Security Payload,封装安全载荷)两个安全协议实现IP报文的封装/解封装。

  • AH是报文头验证协议,主要提供数据源验证、数据完整性验证和防报文重放功能,不提供加密功能。
  • ESP是封装安全载荷协议,主要提供加密、数据源验证、数据完整性验证和防报文重放功能。

虽然AH协议和ESP协议都可以提供数据源验证和数据完整性校验服务,但是两者不能互相取代。两者之间的差别在于验证报文的范围不同,验证范围请参见封装模式。

AH和ESP协议的简单比较如表1所示。

从上表中可以看出两个协议各有优缺点,AH协议不提供数据加密功能,ESP的验证范围不包括IP头,其安全性不如AH,故在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。AH协议和ESP协议联合使用时,需要先使用ESP,这是因为AH对整个IP数据报文进行认证,如果先使用AH再使用ESP,ESP的头和尾会改变数据报文的长度,而且ESP的填充字段也会改变数据报文的长度,造成AH认证失败。

封装模式


目前NE支持隧道模式。

隧道模式

隧道模式的报文格式如图1所示。在隧道模式下,原始IP数据报文被封装成一个新的IP数据报文,并在旧IP报文头(图1中的IP Header)和新IP报文头(图1中的New IP Header)之间插入一个IPSec报文头(AH或ESP),原IP地址被当作有效载荷的一部分受到IPSec的安全保护。图1 隧道模式的报文格式

隧道模式隐藏了原始IP报文头信息,因此主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。

隧道模式下,AH协议的完整性验证范围为包括新增IP头在内的整个IP报文。ESP协议验证报文的完整性检查部分包括ESP头、原IP头、传输层协议头、数据和ESP尾,但不包括新IP头,因此ESP协议无法保证新IP头的安全。ESP的加密部分包括传输层协议头、数据和ESP尾。

当安全协议同时采用AH和ESP时,AH和ESP协议必须采用相同的封装模式。

加密算法


加密是一种将数据从明文转换成无法读懂的密文的过程,接收方只有在拥有正确的密钥的情况下才能对密文进行解密,从而保证了数据的私密性。

IPSec VPN工作过程中涉及数据加密(IP报文加密)和协议消息加密(ISAKMP消息加密)两种情况。

数据加密

ESP能够对IP报文内容进行加密保护,以防止IP报文内容在传输过程中被窥探。IPSec采用对称加密算法对数据进行加密和解密。对称加密算法是指数据发送方和接收方使用相同的密钥进行加密、解密。

采用对称加密算法进行数据加密和解密的过程如图1所示。图1 加密和解密的过程

用于加密的对称密钥可以手工配置,也可以通过DH算法生成并在两端设备共享。有关DH算法具体能够生成哪些密钥及密钥的作用请参见IKEv1 Phase-1 Negotiation。

一般来说IPSec使用以下加密算法:

  • DES(Data Encryption Standard):使用64bit的密钥对一个64bit的明文块进行加密。
  • 3DES(Triple Data Encryption Standard):使用三个64bit的DES密钥(共192bit密钥)对明文形式的IP报文进行加密。
  • AES-CBC-128(Advanced Encryption Standard Cipher Block Chaining 128):使用128bit加密算法对IP报文进行加密。
  • AES-CBC-192(Advanced Encryption Standard Cipher Block Chaining 192):使用192bit加密算法对IP报文进行加密。
  • AES-CBC-256(Advanced Encryption Standard Cipher Block Chaining 256):使用256bit加密算法对IP报文进行加密。

3DES比DES安全得多,但是其加密速度慢于DES。AES比3DES更安全。

协议消息加密

协议消息加密用于IKE协商阶段。协议消息加密所用的算法也是DES、3DES和AES。用于加密的对称密钥通过DH算法生成。有关DH算法具体能够生成哪些密钥及密钥的作用请参见IKEv1 Phase-1 Negotiation。

认证算法


IPSec采用HMAC(Keyed-Hash Message Authentication Code)功能进行认证。HMAC是HASH函数(单向散列函数)和消息认证码MAC(Message Authentication Code)的结合,HMAC利用Hash函数,以一个对称密钥和一个数据包作为输入,生成一个固定长度的输出,这个输出被称为完整性校验值ICV(Integrity Check Value)。接收方通过比较自身生成的ICV和对端发送的ICV来判断数据的完整性和真实性。

数据源验证和数据完整性验证统一被称为验证。因为这两种安全服务总是绑定在一起提供的。数据完整性验证是基于每个IP数据包进行计算;将完整性验证密钥同IPSec对端身份绑定的结果间接提供了数据源验证。

虽然加密后的数据只能通过原始的加密密钥进行解密,但是无法验证解密后的信息是否是原始发送的信息。另外加密和解密的过程非常的消耗CPU资源,恶意用户可能会通过发送欺骗数据包,占用CPU资源。HMAC功能通过比较数字签名进行数据包完整性和真实性验证,这个过程消耗的CPU资源非常少,效率非常高。

所以在IPSec VPN发送设备中,加密和验证通常配合使用。加密后的报文经HMAC生成数字签名,IP报文和数字签名同时发给对端(数字签名填写在AH和ESP报文头的完整性校验值ICV字段,请参见安全协议);在接收设备中,通过比较数字签名进行数据完整性和真实性验证,验证不通过的报文直接丢弃,验证通过的报文再进行解密。

加密和HMAC验证配合使用的过程如图1所示。图1 HMAC验证过程

用于验证的对称密钥可以手工配置,也可以通过DH算法生成并在两端设备共享。有关DH算法具体能够生成哪些密钥及密钥的作用请参见IKEv1协商安全联盟的过程。

一般来说IPSec使用以下几种认证算法:

  • MD5(Message Digest 5):输入任意长度的消息,产生一个128比特的消息摘要。
  • SHA-1(Secure Hash Algorithm):输入长度小于264比特的消息,然后生成一个160比特的消息摘要。
  • SHA2-256:通过输入长度小于264比特的消息,产生256比特的消息摘要。
  • SHA2-384:通过输入长度小于2128比特的消息,产生384比特的消息摘要。
  • SHA2-512:通过输入长度小于2128比特的消息,产生512比特的消息摘要。

SHA-2的消息摘要长于MD5和SHA-1,因此,SHA-2比MD5和SHA-1更安全。

密钥交换


IKEv1和IKEv2的协商过程中,隧道两端需要进行密钥材料的交换,以便使用相同密钥进行正确的加密和解密。

密钥交换方法

使用对称密钥进行加密、验证时,如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题:

  • 带外共享密钥在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式(例如通过电话或邮件方式)保证密钥一致性。这种方式的缺点是可扩展性差,在点到多点组网中配置密钥的工作量成倍增加。另外,为提升网络安全性需要周期性修改密钥,这种方式下也很难实施。
  • 使用一个安全的连接分发密钥IPSec使用IKE协议在发送、接收设备之间安全地协商密钥。IKE采用DH算法在不安全的网络上安全地交换密钥信息,并生成加密、验证密钥。这种方式配置简单,可扩展性好,特别是在大型动态的网络环境下此优点更加突出。

IKE提供密钥交换,自动协商建立安全联盟等服务。采用IKE协议可以使IPSec配置和管理更简单、更灵活。

  • Internet安全联盟和密钥管理协议ISAKMP(Internet Security Association and Key Management Protocol)是IKE的基础,IKE使用ISAKMP协议定义密钥交换的过程。ISAKMP提供了对安全服务进行协商的方法,密钥交换时交换信息的方法,以及对对等体身份进行验证的方法。
  • IKE的精髓在于它永远不在不安全的网络上传送密钥,而是通过一些数据的交换,通信双方最终计算出共享的密钥,并且即使第三方截获了双方用于计算密钥的所有交换数据,也无法计算出真正的密钥。其中的核心技术就是DH(Diffie Hellman)交换技术。

DH密钥交换

DH用于产生密钥材料,并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后,两端设备各自计算出完全相同的对称密钥。该对称密钥用于加密和验证密钥的计算。在任何时候,双方都不交换真正的密钥。

DH密钥交换过程如图1所示。图1 DH密钥交换过程

  1. 进行DH交换的双方各自产生一个随机数,如a和b。
  2. 使用双方确认的共享的公开的两个参数:底数g和模数p各自用随机数a和b进行幂和模运算,得到结果c和d,计算公式如下:c=gamod(p)d=gbmod(p)
  3. 交换计算所得的结果c和d
  4. 各自进一步计算,得到一个共同的DH公有值:damod(p)=cbmod(p)=gabmod(p),此公式可以从数学上证明。DH公有值就是双方的密钥。

若网络上的第三方截获了双方的模c和d,那么要计算出DH公有值gabmod(p)还需要获得a或b,a和b始终没有直接在网络上传输过。如果想由模c和d计算a或b就需要进行离散对数运算,而p为素数,当p足够大时(一般为768位以上的二进制数),数学上已经证明,其计算复杂度非常高,从而认为是不可实现的。所以,DH交换技术可以保证双方能够安全地获得密钥信息。

DH使用密钥组来定义自己产生的密钥长度。密钥长度越长,产生的密钥就越安全,但所需的计算时间也依次递增。

IPSec安全联盟


IPSec在两个端点之间提供安全通信,这两个端点被称为IPSec对等体。

安全联盟(Security Association)是通信对等体间对某些要素的约定。它定义了保护IP报文安全的协议(AH或者ESP)、IP报文的封装模式、认证算法、保护IP报文的共享密钥等。通过安全联盟实现了IPSec对IP报文的保护。安全联盟是IPSec的基础,也是IPSec的本质。

SA是单向的,输入的IP报文和输出的IP报文由入方向安全联盟和出方向安全联盟分别处理。因此,如果有两个设备(DeviceA和DeviceB)使用ESP进行通信,则必须在DeviceA上设置两个SA,一个用于处理外发IP报文,另一用于处理接收IP报文。同样地,DeviceB也需要两个SA。如图1所示。图1 SA的单向逻辑连接

安全联盟还与协议相关。如果主机A和主机B同时使用AH和ESP进行安全通信,对于主机A就需要四个SA,AH协议的两个SA(入方向和出方向上各一个SA)和ESP协议的两个SA(入方向和出方向上各一个SA)。同样地,主机B也需要四个SA。

安全联盟由一个三元组来唯一标识。这个三元组包括:安全参数索引SPI(Security Parameter Index)、目的IP地址、安全协议号(AH或ESP)。SPI是为唯一标识SA而生成的一个32比特的数值,它在AH和ESP头中传输。

安全联盟建立方式

安全联盟可通过手工配置和自动协商两种方式建立。

  • 手工建立安全联盟的方式是指用户通过在两端手工设置一些参数,在两端参数匹配和协商通过后建立IPSec安全联盟。手工方式配置比较复杂,创建IPSec安全联盟所需的全部信息都必须手工配置,而且不支持IPSec的一些高级特性(例如定时更新密钥),但优点是可以不依赖IKE而单独实现IPSec功能。手工方式目前主要用于协议报文的认证,例如RIPng、OSPFv3、IGMP、MLD、PIM和DHCPv6 Relay等。
  • 自动协商方式由IKE生成和维护,通信双方基于各自的安全策略库经过匹配和协商,最终建立安全联盟而不需要用户的干预。IKE属于一种混合型协议,它建立在由Internet安全联盟和密钥管理协议ISAKMP(Internet Security Association and Key Management Protocol)定义的一个框架上。它能够为IPSec提供自动协商交换密钥、建立安全联盟的服务,以简化IPSec的使用和管理。IKE分为IKEv1和IKEv2两个版本,二者建立安全联盟的方式大体相同,具体请参考IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。

IKE的安全机制

  • DH密钥交换。
  • 完善的前向安全性PFS(Perfect Forward Secrecy):指一个密钥被破解,并不影响其他密钥的安全性,因为这些密钥间没有派生关系。PFS是由DH算法保障的。此特性是通过在IKE阶段2的协商中增加密钥交换来实现的。
  • 身份验证:身份验证用于确认通信双方的身份。对于pre-shared key验证方法,验证字用来作为一个输入产生密钥,验证字不同是不可能在双方产生相同的密钥的。验证字是验证双方身份的关键。
  • 身份保护:身份数据在密钥产生之后加密传送,实现了对身份数据的保护。

IKEv1协商安全联盟的过程


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

  1. IKEv1阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证,这条安全通道可以保证IKEv1阶段2的协商能够安全进行。
  2. IKEv1阶段2的目的就是建立用来传输数据的IPSec SA。

IKEv1协商阶段1

IKEv1阶段1主要协商下面三个任务:

  1. 协商建立IKE SA所使用的参数。加密算法、完整性验证算法、身份认证方法和认证字、DH组、IKE SA生存周期等等。这些参数在IKE安全提议中定义。
  2. 使用DH算法交换与密钥相关的信息(生成各种密钥的材料)。对等体双方设备能够使用这些密钥信息各自生成用于ISAKMP消息加密、验证的对称密钥。
  3. 对等体之间验证彼此身份。使用预共享密钥或数字证书来验证设备身份。

这三个任务都协商成功后,IKE SA就建立成功了。

IKEv1阶段1支持两种协商模式:主模式(Main Mode)和野蛮模式(Aggressive Mode)

主模式

主模式采用三个步骤来完成上述三个任务。每个步骤需要2个ISAKMP报文,共6个ISAKMP报文。交换密钥相关信息的操作在身份认证之前完成,故设备的身份信息受到已生成的共享密钥的保护。

采用主模式时IKEv1阶段1的协商过程如图1所示。图1 主模式下IKEv1阶段1的协商过程

下面对这三个步骤进行详细说明:

  1. 协商对等体之间使用的IKE安全提议。DeviceA发送ISAKMP消息,携带建立IKE SA所使用的参数(由IKE安全提议定义)。DeviceB对DeviceA的IKE安全提议进行协商。在协商时将从优先级最高的提议开始匹配,协商双方必须至少有一条匹配的IKE安全提议才能协商成功。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。DeviceB响应ISAKMP消息,携带经协商匹配的安全提议及参数。 如果没有匹配的安全提议,DeviceB将拒绝发起方的安全提议。
  2. 使用DH算法交换与密钥相关的信息,并生成密钥。两个对等体通过两条ISAKMP消息(3、4)交换与密钥相关的信息。由获得的密钥信息推导出4个密钥。其中SKEYID为基础密钥,通过它可以推导出SKEYID_a,为ISAKMP消息完整性验证密钥;可以推导出SKEYID_e,为ISAKMP消息加密密钥;可以推导出SKEYID_d,用于衍生出IPSec报文加密、验证密钥。预共享密钥方式和数字证书方式下SKEYID的计算公式不同。图2 DH密钥生成
  3. 对等体之间验证彼此身份。两个对等体通过两条ISAKMP消息(5、6)交换身份信息(预共享密钥方式下为IP地址或名称,数字证书方式下还需要传输证书的内容),身份信息通过SKEYID_e加密,故可以保证身份信息的安全性。两个对等体使用IKE安全提议中定义的加密算法、验证算法、身份验证方法和SKEYID_a、SKEYID_e对IKE消息进行加解密和验证。IKEv1支持如下身份验证方法:预共享密钥这种方法要求对等体双方必须要有相同的预共享密钥(该密钥直接参与SKEYID的生成计算)。对于设备数量较少的VPN网络来说易于配置,在大型VPN网络中,不建议采用预共享密钥来做身份验证。RSA签名(通常称为数字证书)数字证书需要由CA服务器来颁发。这种方法适用于大型动态的VPN网络。证书验证和预共享密钥验证的主要区别在于SKEYID的计算和交换的身份信息,其他的交换和计算过程和预共享密钥验证方式相同。数字信封认证在数字信封认证中,发起方采用对称密钥加密信息内容,并通过非对称密钥的公钥加密对称密钥,从而保证只有特定的对端才能阅读通信的内容,从而确定对端的身份。此认证方法只能在IKEv1的主模式协商过程中使用,不能在IKEv1野蛮模式协商过程中使用。

野蛮模式

野蛮模式仅交换3个消息就可以完成IKE SA的建立。

采用野蛮模式时IKEv1阶段1的协商过程如图3所示。图3 野蛮模式下IKEv1阶段1的协商过程

野蛮模式时IKEv1阶段1的协商过程:

  1. DeviceA发送ISAKMP消息,携带建立IKE SA所使用的参数、与密钥生成相关的信息和身份验证信息。
  2. DeviceB对收到的第一个数据包进行确认,查找并返回匹配的参数、密钥生成信息和身份验证信息。
  3. DeviceA回应验证结果,并建立IKE SA。

与主模式相比,野蛮模式的优点是建立IKE SA的速度较快。但是由于密钥交换与身份认证一起进行,野蛮模式无法提供身份保护。

主模式与野蛮模式的区别

野蛮模式安全性比主模式差。但是野蛮模式可以满足某些特定场合的网络环境的需求。例如:

  • 远程访问时,如果响应者(服务器端)无法预先知道发起者(终端用户)的地址、或者发起者的地址总在变化时,而双方都希望采用预共享密钥验证方法来创建IKE SA,此时可以采用野蛮模式。NE采用预共享认证方式,若是可以获取出口网关的代理IP,也可以在此种情形下采用主模式下配置代理IP的方式。
  • 如果发起者已知响应者的策略,或者对响应者的策略有全面的了解,采用野蛮模式能够更快地创建IKE SA。

IKEv1协商阶段2

IKEv1阶段2的目的就是建立用来传输数据的IPSec SA。IPSec SA与IKE SA的关系如图4所示。图4 IPSec SA与IKE SA的关系

IKEv1阶段2通过快速交换模式完成。由于快速交换模式使用IKEv1阶段1中生成的密钥SKEYID_a对ISAKMP消息的完整性和身份进行验证,使用密钥SKEYID_e对ISAKMP消息进行加密,故保证了交换的安全性。

在快速交换模式中,对等体两端协商IPSec SA的各项参数,并为数据传输衍生出密钥。

快速模式的协商过程如图5所示。图5 IKEv1阶段2协商过程

快速模式共有3条消息完成双方IPSec SA的建立。

  1. 消息1发送本端的安全参数和身份认证信息。安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等,可以再次认证对等体。
  2. 消息2响应消息1,发送响应方的安全参数和身份认证信息并生成新的密钥。对等体双方通过交换密钥材料生成新的共享密钥,并最终衍生出IPSec的加密密钥。此时响应者和发送者各有两个SA。IPSec SA数据传输需要的加密、验证密钥由SKEYID_d、SPI、协议等参数衍生得出,以保证每个IPSec SA都有自己独一无二的密钥。当启用PFS时,要再次应用DH算法计算出一个共享密钥,然后参与上述计算,因此在参数协商时要为PFS协商DH密钥组。
  3. 消息3响应消息2,确认与响应方可以通信,协商结束。

IKEv2协商安全联盟的过程


要建立一对IPSec SA,IKEv1需要经历两个阶段:“主模式+快速模式”或者“野蛮模式+快速模式”。前者至少需要交换9条消息,后者也至少需要6条消息。而IKEv2,正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA,如果要求建立的IPSec SA大于一对时,每一对SA只需额外增加1次交换,也就是2条消息就可以完成。这比IKEv1要简化很多。

IKEv2协商安全联盟的过程

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

  1. 初始交换IKE通信总是从IKE安全联盟初始交换(IKE_SA_INIT交换)和IKE认证交换(IKE_AUTH交换)开始。这2个交换通常由4条消息组成,在某些场景下消息数目可能会增加。所有使用IKE的通信都由请求/响应对组成。IKE安全联盟初始交换和IKE认证交换完成后可以建立一个IKE SA和第一对CHILD_SA(即IPSec SA)。具体如图1所示。图1 IKEv2初始阶段的协商过程
    详细说明如下:第一个消息对(IKE_SA_INIT)这个消息对负责进行IKE安全联盟参数的协商,包括协商加密和验证算法,交换临时随机数(nonces)和DH交换。IKE_SA_INIT交换后可以生成一个共享密钥材料。通过这个共享密钥材料可以生成其他相关密钥。第二个消息对(IKE_AUTH)从IKE_AUTH交换开始,所有报文都必须加密再交换。IKE_AUTH交换至少需要两个消息。在这两个报文的交互中完成了身份认证以及一个CHILD_SA的创建过程。IKEv2支持RSA签名认证、预共享密钥认证。RSA签名认证和预共享密钥认证方式下,认证载荷(AUTH载荷)的计算方式不同。在IKE_SA_INIT交换阶段,生成IPSec SA的密钥材料,并通过这个密钥材料衍生出IPSec SA的所有密钥。IKEv2除支持RSA签名和预共享密钥认证外,还支持扩展认证方法EAP(Extensible Authentication Protocol)。EAP认证是作为附加的IKE_AUTH交换在IKE中实现的。发起者通过在消息3中省去AUTH载荷来表明需要使用EAP认证。
  2. 创建子SA交换当一个IKE SA需要创建多对IPSec SA时,需要使用创建子SA交换来协商多于一对的SA。另外创建子SA交换还可以用于进行IKE SA的重协商。创建子SA交换包含一个交换两个消息。在IKEv1中这个交换称为阶段2交换(快速模式交换)。这个交换必须在IKE初始交换完成之后才能进行,交换的发起者可以是IKE初始交换的发起者,也可以是IKE初始交换的响应者。在交换中的两个消息需要由IKE初始交换协商的密钥进行保护。类似于IKEv1的PFS,创建子SA交换阶段可以重新进行一次DH交换,生成新的密钥材料。生成密钥材料后,子SA的所有密钥都从这个密钥材料衍生出来。
  3. 通知交换运行IKE协商的两端有时会传递一些控制信息,例如错误信息或者通告信息,这些信息在IKEv2中是通过通知交换完成的。通知交换必须在IKE SA保护下进行,也就是说通知交换只能发生在初始交换之后。

IPSec报文处理流程


IPSec安全联盟建立以后,可以对IP报文做加解密处理。与IPSec报文转发相关的概念如下:

  • 安全策略数据库SPDB(Security Policy Database):定义IP数据报文应使用何种安全服务,以及如何获得这些服务。SPDB是SA创建的前提,决定了SA的作用范围和相关属性。
  • 安全联盟数据库SADB(Security Association Database):存放与SA关联的所有状态数据的存储结构。因为一个网络实体可以创建多对SA,所以需要有个DB来做存储管理。
  • SPI(安全参数索引):一个携带在AH或ESP头部的一个32位数值,接收端通过SPI来判断接收到的数据流应该用SADB中的哪个SA来做安全保护。

IPSec对于发送报文的处理流程如图1所示。图1 IPSec发送报文处理流程

IPSec对于接收报文的处理流程如图2所示。图2 IPSec接收报文处理流程

IPSec DPD


DPD

当两个对等体之间采用IKE和IPSec进行通信时,对等体之间可能会由于路由问题、对等体重启或其他原因等导致连接断开。IKE协议本身没有提供对等体状态检测机制,一旦发生对等体不可达的情况,只能等待安全联盟的生存周期到期。生存周期到期之前,对等体之间的安全联盟将一直存在。安全联盟连接的对等体不可达将引发“黑洞”,导致数据流被丢弃。通常情况下,迫切需要识别和检测到这些“黑洞”,以便尽快的恢复IPSec通信。

Keepalive机制可以解决这个问题。Keepalive机制是指IKE对等体间通过周期性的交换Hello/Ack消息来告知对方自己处于活动状态。但是在设备上的IKE SA数量很大时,发送的Hello/Ack消息将会大量消耗设备的CPU资源,限制了这种机制的应用。

失效对等体检测DPD(Dead Peer Detect)是Keepalive机制的一种替代机制,它利用IPSec流量使对等体状态检测所需消息的数量达到最小化。DPD规定每个IKE peer的状态和对端状态是完全独立的,当IKE peer想知道对端是否在线时,随时请求,不需要等待间隔时间的到来。当peer之间有正常的IPSec流量时,证明对端肯定在线,此时没有必要去发送额外的消息探测对端是否在线。只有一段时间内没有流量发生,peer的活动状态才值得怀疑,那么本端在发送流量前应该发送一次DPD消息来检测对端的状态。

DPD有两种模式可以选择:interval和on-demand。

interval:表示DPD工作在轮询模式,在check-interval时间内,如果没有收到对端发过来的流量就会以check-interval为周期循环发送DPD检测报文。如果期间收到对端的响应报文,那么本次DPD流程结束,进入新的DPD检测周期。如果期间没有收到对端的响应报文,则会进行报文重传。重传结束后,如果依然没有收到响应则会删除本端SA表项,重新执行隧道新建流程。

on-demand:表示DPD工作在流量触发模式,如果本端没有加密流量发送,那么是不会发送DPD报文的,这是和轮询模式的最大区别。如果本端有加密流量需要发送,并且发送后在check-interval时间内没有收到对端发过来的流量,那么就会以check-interval为周期循环发送DPD检测报文。如果期间收到对端的响应报文,那么本次DPD流程结束,进入新的DPD检测周期。如果期间没有收到对端的响应报文,则会进行报文重传。重传结束后,如果依然没有收到响应则会删除本端SA表项,重新执行隧道新建流程。

IPSec安全性


IKEv2的安全性分析

此处着重分析IKEv2的安全性。

IKEv2对传统IKE存在的安全漏洞进行了修订,提高了密钥协商的安全性,并明确规定了所有的消息必须以请求/响应对的形式存在,有效的解决了使用UDP作为传输层协议的不可靠性问题。

以下从三方面来讨论IKEv2的安全性问题。

  • 抵御中间人攻击中间人攻击(Man-in-the-middle Attack)是一种主动攻击,指攻击者对通信双方进行窃听,截获通信双方的消息并进行任意插入、删除或篡改消息,之后返回消息给发送者,或者重放旧消息以及重定向消息,是最危险的攻击。IKEv2中抵御中间人攻击的机制和方法:密钥材料生成方式与传统IKE相比,IKEv2的密钥材料发生了变化,双方用于后继交互使用的加密密钥与认证密钥都是不同的。这些密钥是从prf+输出流中依次提取,从而增加了攻击者猜测密钥的难度,减少了密钥泄漏的可能性,增强了传输的安全性,一定程度上可以抵御中间人攻击。身份认证IKEv2使用预共享密钥和数字签名方式进行身份认证。身份认证方式具有交互性,参与协商的实体彼此都对对方的身份进行认证;具有对称性,参与协商的双方都使用相同的机制或方法对对方的身份进行认证。双向的身份认证可以有效地抵御中间人攻击。同时IKEv2定义了扩展认证交互,即使用扩展认证协议(EAP)描述的方法对IKEv2协商进行身份认证,支持非对称双向认证,进一步加强了认证的灵活性和协商的可扩展性。消息交换IKEv2将传统IKE主模式交换的六条消息修订为四条消息,将SA载荷和KE载荷、nonce载荷一同发送,这样,消息中包含随机的nonce值,如果攻击者伪装成响应方进行应答,将收到的发起方的消息基本上不做改变,再发回给发起方,发起方可以根据消息内容判断消息的真假,在一定程度上可以抵御重放攻击。每个IKEv2消息的头都包含了一个消息ID,用于匹配对应的请求和响应消息以及识别消息重传。当发送和接收到请求时,必须对消息ID值顺序增加,且除了IKE_SA_INIT交互外其值受加密和完整性保护,使得它能够防重放攻击。同时IKEv2加入了滑动窗口机制,使交互能够更加有效地抵御重放攻击的威胁。
  • 抵御DDoS(Distributed Denial of Service)攻击IKEv2中抵御DDoS攻击的机制和方法:SPI值IKEv2消息头部有发起方SPIi和响应方SPIr,它们是内核产生的8字节的随机数,用来标识SA,同时也可以标识进行消息交换的一对节点。具有相同SPI值的请求处理一次(重传消息除外),而把其他请求作为重复数据包丢弃,可以在一定程度上防止DDoS攻击。带Cookie交互IKEv2中使用N载荷携带Cookie的辅助交换来抵御拒绝服务攻击。在通信过程中,响应方认为自己正受到DDoS攻击时,可以向发起方请求回复一个无状态cookie。响应方收到对方发来的第一条消息后并不急于进行IKE_SA_INIT交互,而是再产生一个新的cookie,封装在通知载荷中发送给对方。如果发起方不是攻击者,就可以收到这条消息,然后重新开始协商,并将响应方的cookie封装在该消息中,其它载荷内容保持不变。重传约定IKEv2中所有消息都是成对出现,在每对消息中,发起方负责重传事件,响应方不必对其响应消息进行重传,除非收到对方的一个重传请求。避免了双方同时发起重传,造成资源的浪费,同时也可以防止攻击者截获消息后,伪装成协商者不断地发送重传消息,耗费协商双方的资源。丢弃半开(half-open)连接IKEv2只能通过两种情况判断对方是否失效:一种是重复尝试联系对方,直到应答时间过期;另一种是收到对方的不同IKE SA加密保护下的INITIAL CONTACT通知消息。IKEv2发起方允许多个响应方响应第一条消息,并把所有的响应方视为合法并作回应。发起方发送一些消息后,一旦收到一个有效的加密的响应消息,将其他的响应消息忽略,并将其他所有的无效的半连接丢弃。这样在协商开始时就可以避免受到DDoS攻击。
  • 完善的前向安全性PFS(Perfect Forward Secrecy)IPSec SA数据传输需要的加密、验证密钥由SKEYID_d、SPI、协议等参数衍生得出,可以保证每个IPSec SA都有自己独一无二的密钥。但是由于所有IPSec SA密钥都是相同的来源产生的,所以这些IPSec SA密钥相互间都有关联,假如有攻击者能够根据IKE SA判断出SKEYID_d的值,那么就能非常容易的掌握从该SKEYID_d衍生出来的所有IPSec SA的密钥。IPSec专门提供PFS特性来解决这个问题,实现思路是:IKEv2初始交互的密钥衍生材料不被用于衍生供IPSec SA使用的相关密钥,而是通过在CREATE_IPSec_SA交互中引入可选的IKE载荷重新进行一次额外的DH交换来生成密钥材料。通过这种方式,IPSec密钥之间相互没有关联,即使攻击者攻克了一个密钥,也只能破解这个密钥保护的数据,而不能破解受其它密钥保护的数据。

防重放

IPSec中的重放攻击(Replay Attack)主要是指攻击者大量发送目的主机已接收过的数据包,大量消耗系统资源,可能导致系统CPU资源耗尽。

IPSec利用序列号和滑动窗口来实现防重放(Anti-Replay)。IPSec中AH和ESP协议报文头中有个序列号字段(Sequence Number)专门用于防重放攻击。

通信双方协商好IPSec SA之后,序列号字段被置为0,此后发送方每发出一个报文,该数值加1。接收方存在一个防重放滑动窗口和已接收报文的序列号数据库。

  • 如果该序列号的报文从未被接收过,且在防重放窗口内,接收方就接收该报文。如果该序列号的报文已经被接收过,则认为是重放攻击,丢弃该报文。
  • 如果该序列号在防重放窗口的左侧(小于防重放窗口的最小值),则认为是已经接收的报文,因而被丢弃。
  • 如果该序列号在防重放窗口的右侧(大于防重放窗口的最大值),则认为未被接收的报文,会正常接收,同时触发防重放窗口向右滑动。

下面结合图1详细描述防重放的原理。图1 防重放示意图

  • 如图1(a)所示,初始防重放窗口是[0–63],序列号在此范围内的报文会被正常接收,接下来如果接收到序列号大于63的报文,也会正常接收,并且防重放窗口向右滑动。但是如果再次收到序列号在[0–63]范围内的报文,则认为是重放攻击,拒绝接收报文。
  • 如果此时收到序列号为66的报文,则防重放窗口滑动到[3–66],接下来如果接收到序列号大于66的报文,也会正常接收,具体如图1(b)所示。此时[0–2]这三个序列号已经不在防重放窗口范围内,如果再次收到此范围内的报文,则会认为是已经接收过的报文,所以会丢弃这些报文。
  • 如图1(c)所示,假如报文发生乱序,接收端先接收到序列号为67的报文,则防重放窗口滑动到[4–67]。然后再接收到序列号为3的报文,虽然该报文之前从未接收过,但是因为其序列号已经在防重放窗口之外,因此也被丢弃。从这一点可以看出,在报文乱序情况下,防重放窗口设置越大,报文被错误丢弃的几率就越低,反之就越高。

安全联盟生存周期

为了防止密钥长期使用而带来的安全隐患,安全联盟存在生存周期。衡量生存周期有两种方式:基于时间的生存周期和基于流量的生存周期。

  • 基于时间的生存周期是从安全联盟建立开始的时刻起,此安全联盟存活的时间。
  • 基于流量的生存周期是此安全联盟允许处理的最大流量。

其中IPSec安全联盟两种方式都支持,IKE安全联盟并不传输IPSec流量,因此仅支持基于时间的生存周期。IPSec安全联盟和IKE安全联盟的生存周期可以分别配置,互不干扰。

对于IKE安全联盟的生存周期:


小编推荐:欲学习电脑技术、系统维护、网络管理、编程开发和安全攻防等高端IT技术,请 点击这里 注册账号,公开课频道价值万元IT培训教程免费学,让您少走弯路、事半功倍,好工作升职加薪!

本文出自:https://www.toutiao.com/a6916424303504327181/

免责声明:本站系公益性非盈利IT技术普及网,本文由投稿者转载自互联网的公开文章,文末均已注明出处,其内容和图片版权归原网站或作者所有,文中所述不代表本站观点,若有无意侵权或转载不当之处请从网站右下角联系我们处理,谢谢合作!


鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

 最新
返回顶部