IPv6环境下的IPSEC通信安全审计机制研究

杜学凯 吴承荣 严 明

(复旦大学网络与信息工程中心，计算机科学技术学院 上海 200433)

IPv6环境下的IPSEC通信安全审计机制研究

杜学凯 吴承荣 严 明

(复旦大学网络与信息工程中心，计算机科学技术学院 上海 200433)

当前IPv6网络正在逐步推广，由于IPv6地址可以满足全球的网络节点唯一地址的需求，所以IPv6用户越来越多地使用点对点的安全通信技术IPSEC。然而，对于很多机构来说，网络内部的IPSEC通信的合法监管逐渐变得困难，这是一个需要解决的问题。针对于这样的场景，提出一种在IPv6网络中运用基于中间人机制与密钥托管机制的IPSEC通信安全审计方法，设计并实现一种在IPv6网络内部以及IPv6网络之间进行IPSEC通信安全审计的原型系统，并进行IPv6网络环境下的功能验证与性能分析。实验表明，该方法能够很好得达到进行IPv6网络环境下IPSEC审计的效果。

IPv6网络 安全审计 中间人机制 密钥托管 Internet Protocol Security

0 引 言

IPv6是互联网工程任务组IETF(Internet Engineering Task Force)设计的用于替代现行版本IP协议的下一代IP协议。IPv6服务的大规模使用对于传统的网络安全审计还是会带来一定的影响的。比如，网络通信加密、身份认证、网络访问控制、安全审计监控、安全审计监控、操作系统及平台软件的安全增强、应用层安全保护机制、安全管理等场景会受到IPv6服务部署的影响。

IPSEC机制提供了端到端的网络层加密通信机制。IPv6的使用一方面使得端到端加密措施成为内生的端到端安全机制，另一方面， NAT[1]等机制在IPv6网络环境中已经不太需要，所以限制基于IPSEC的端到端加密的技术障碍已经基本排除。

IPSEC端到端加密机制在IPv4环境中由于条件限制并未被广泛使用，而在IPv6环境中只要PKI机制被普遍使用，通过客户端或服务端的设定采用自动协商机制即可实施。所以IPSEC机制将会成为IPv6网络中较为普遍的通信保障方式，而这将会对网络通信内容的审计带来挑战，这正是IPv6环境中的安全审计不得不正视的问题。因此在IPv6环境中，有必要对采用IPSEC的端到端加密机制的使用进行管理，包括哪些通信可以使用，哪些通信不能使用，可采用的加密算法，需要采用的密钥管理机制等等。并且在IPv6环境下的IPSEC机制的监管中，无论采用预共享密钥方式、公钥方式还是证书方式，可能都需要面临大范围(甚至开放环境)下的密钥管理和使用，对原有的密钥管理机制提出了挑战，需要专门设计和部署。

本文根据IPv6网络场景下IPsec数据流进行审计机制的研究。对于基于IKE[2]网络密钥协商机制的IPsec保密通信协议，主要有几种监管方法，比如中间人破坏协商连接方法、旁路监听存储密文信息方法、旁路监听实时上报方法、终端密钥修改方法、终端DH随机数修改方法、中间人降低协商双方加密等级方法，和针对DH算法的中间人方法。我们根据上述几种方法的优点和缺点，采用了基于中间人机制与密钥托管相结合的方法对需要进行安全审计的IPv6网络内部IPSEC通信进行解密，并基于这种方法实现了一个审计系统的原型。

1 基本原理

IPsec协议实现端到端认证的方式主要有：PSK预共享密钥认证、数字签名认证、公钥认证与Kerberos认证等。公钥认证由于公钥的公开性，容易受到篡改，而Kerberos认证一般在基于Windows系统的主机上使用。所以我们主要针对预共享密钥认证方式、数字签名认证方式与公钥认证方式等认证机制进行破解，获取密钥，达到最终安全审计的目的。

1.1 数据分类处理

IPSEC通信过程中如果主机之间采用的是IPSEC的AH协议进行通信，由于AH协议数据内容没有被加密，所以可以达到安全审计的目的，不必进行特殊处理。而且由于IPsec的IKE协议协商过程中不同阶段的处理方式不同，不能统一对待，所以我们首先需要对数据进行分类处理。

如图1所示，分类器的处理工作处理如下：

如果不是有关于IPsec机制的数据包，则将数据包不作处理，透明传输。

图1 分类处理原理

如果是AH协议包，则将数据包不作处理，透明传输。

如果是已经协商的ESP[3]协议包，则将ESP包的IPv6地址对信息和Cookie字段值发送到一个特定的存储密钥的密钥存储中心进行密钥的查询。

如果此IPv6地址的主机未进行过密钥托管，密钥托管中心向运行的IKE处理模块发送一个未托管信息，将此通信断开，并将此ESP数据包信息存储到一个保存警告信息的数据中心，通知管理员运用其他监管手段获取其认证和密钥信息进行处理。

如果此IPv6地址对的数据包进行过密钥托管，则向运行的IKE处理模块发送一个已托管信息，并将已托管的对应于相应地址对的密钥发送给IKE处理模块(通过密钥托管中心与IKE处理模块的保密线路)。此处还要根据具体处理后的情形进行分类：由于密钥托管中心是否托管的是两个通信主机实际在使用的密钥对，解密ESP数据包后有两种情况，一种是解密出正确的明文，另外一种是解密出不正确的明文。可以通过解密后数据包的传输层协议报头部分的下一字段来判断是否解密成功。(TCP报头的头部长度字段、校验和字段或UDP报头的长度字段、校验和是否正确或在正确的范围内)。

如果接收到的是IKE认证协商数据包，则需要根据不同的情形进行处理。

1.2 IKE协商处理

本节主要对图1中IKE协商过程[4-5]的原理进行描述。经过分类器的分类，已经将需要处理的IKE协商数据包分离出来，然后再进行IKE协商中间人方法的处理。

如果接收到的是IKE的数据包，则根据其中相关字段的值判断接收到的IKE数据包是否处于IKE协商的开始阶段。IKE协商的第一阶段分为主模式和积极模式(野蛮模式)这两种协商模式。我们这里只是研究了主模式的工作方式，因为积极模式或野蛮模式的安全性较主模式低。

在IKE第一阶段的实现中，贯穿于整个交换的关键选择是认证，认证方法决定了通信双方如何交换载荷以及在何时交换。认证的最主要目的是为了避免与未经过认证的用户建立传输隧道连接。IKE可以接收的认证方式包括预共享密钥认证(PSK)、数字签名认证(SIG)、公钥加密认证等等。我们主要研究的是预共享密钥认证和数字签名认证两种方式，因为这两种认证方式的使用在IPsec的IKE协商过程中比较普遍，而且公钥加密认证的安全性比数字签名认证方式要低。虽然不同的认证算法提供的安全强度不同，使得交换消息的内容也各不相同，但达到的目的是完全一致的，最终都是生成安全通道SA。

如果接收到的包是处于IKE协商的第一阶段的第一条信息，则可以迅速用IKE处理模块进行中间人方法。

如果接收到的包是处于IKE协商的第一阶段的第一条信息，则分类器向状态及会话密钥查询是否该IPv6通信主机对正在进行IKE协商的处理。如果是，则继续进行相应IKE处理；如果不是，则向发送方和接收方分别发送一条协商出错信息，来迫使发送方重新开始IKE协商过程。

如果接收到IKE协商第一阶段的第一条信息后，转发给接收方，接收方直接应答了第三条信息，则代表主机双方运用的是AH协议进行的最终通信，则对此处IKE协商过程不做处理。

如果接收到IKE协商第一阶段的第一条信息后，转发给接收方，接收方应答了第二条信息，则代表主机双方最终运用的是ESP协议，这样就能够用针对于Diffie-Hellman算法[6]的IKE中间人方法进行密钥信息的获得。首先判断此次IKE协商使用的认证方法。通过对于不同的认证方式，可以进行不同的处理：

对于数字签名认证的IKE主模式认证方式,IKE协商的第一和第二条消息是透明传输的，不做任何的修改。而在第三条消息中，要进行KE值的修改，进行Diffie-Hellman算法的中间人方法，利用消息中的参数和中间人对主机协商的KE值，可以生成两对密钥素材。为IKE协商的第二阶段的破解和最终ESP加密密钥的生成创造条件。

对于数字签名认证的方式，如果在认证过程中需要证书的交换，需要去密钥托管中心进行证书的获取，如果证书未经托管备案，则分别向正在协商的两台主机发送IKE协商出错信息，阻断两台主机的IKE协商过程；如果托管了证书，且如果B主机的证书有多个，则对每个证书进行验证运算，如果验证成功说明找到主机的证书，如果匹配未成功说明主机的证书没有经过备案，则向两台主机分别发送IKE协商出错信息阻断协商过程。

对于预共享密钥认证方式的IKE主模式认证方式，同上面的SIG认证的方式，IKE协商的第一和第二条消息是透明传输的，不做任何的修改。而在第三条消息中，要进行KE值的修改，进行Diffie Hellman算法的中间人方法，利用消息中的参数和中间人对协商主机的KE值，为IKE协商的第二阶段的破解和最终ESP加密密钥的生成创造条件。

对于IKE协商过程的第二阶段(快速模式)[7]的处理为：根据主模式协商建立好的认证通道，要对协商双方的协商数据进行相关篡改，同时进行再一次的针对Diffie-Hellman算法的中间人方法，获取最终进行ESP数据加密与认证运算的密钥数据。

至此，生成ESP包加解密的IPSEC SA密钥所需的参数能够全部得到，IKE协商处理主模块与协商的两主机分别生成一对IPSEC SA密钥(入口密钥和出口密钥)，此密钥保存到IPsec密钥托管中心，将IPv6地址对、SPI值对、IPSEC SA密钥对和协商方向关联起来存储。

2 总体设计

基于密钥托管和中间人机制的IPv6网络通信监控系统的总体框架如图2所示。

图2 总体框图

这个总体框架图绘制了对于需要安全审计的网络内部或被审计网络与外网之间通信数据的机制和方法。当一个数据包通过被审计通道时，所进行的处理是首先由分类器进行分类策略，选择与数据包相匹配的策略进行处理。比如对IKE协商的ISAKMP数据包要交由IKE处理模块处理，对于ESP数据包或AH数据包要交由IPsec处理模块处理。对于IPsec机制之外的数据包要根据预先制定的策略进行处理。在策略中没有要求的数据包要进行透明传输，以达到使中间人安全审计主机作为被审计通道上的透明网桥的效果。IKE处理模块和IPsec处理模块是中间人监管主机上的两个进程，这两个是对于IPsec机制的主要处理模块。IKE处理模块主要是对IKE第一阶段和第二阶段中的DH协商使用中间人方法，使得使用IKE协商的两台主机能够和中间人主机分别建立IPsec通信密钥。IPsec处理是将通道中的ESP数据包或AH数据包根据SPI值向密钥托管中心获取相关的IPsec数据的相关加解密的密钥值和HMAC散列的相关密钥值，并将收到ESP数据包和AH数据包做相关加解密处理或散列处理后从另一端发送出去。IPsec处理模块在处理过程中解密出明文后，将ESP数据包或AH数据包转换为明文状态的IPv6数据包保存起来。

框架图中的报警/审计中心模块的功能是接收IKE处理模块和IPSEC处理模块中出现的各种报错或其他提供给受审计网络管理员的信息，如SPI相关的加解密密钥未查找到、IKE处理过程中认证未成功等。密钥托管中心保存了IKE处理模块和IPSEC处理模块中所用到的认证数据或密钥数据，比如预共享密钥字符串、受监管主机的证书(根据IPv6地址匹配)、伪造的证书、受监管主机的证书的公钥值、ESP数据包的加解密密钥值和散列密钥值(根据SPI值匹配)等。安全策略中心制定了一系列与IPv6网络通道中相关的协议的处理和监管要求，当分类器对相关数据包处理时，要从策略中心进行相关策略的处理。

3 详细实现

3.1 密钥素材

用于IKE协商处理模块与ESP数据解密的密钥素材如下：

密钥集合：需要生成的密钥有SKEYID、SKEYID_d、SKEYID_a、SKEYID_e和通信数据加解密密钥KEYMAT。

签名和散列数据：HASH_I、HASH_R、SIG_i、SIG_r、HASH(1)、HASH(2)、HASH(3)。

SKEYID需要的密钥素材有：PSK、通信双方的NONCE载荷的数据、通信双方和中间人产生的两个DH协商的密钥。

SKEYID_d需要的密钥素材有：SKEYID、通信双方和中间人产生的两个DH密钥、通信双方的Cookie值。

SKEYID_a需要的密钥素材有：SKEYID、SKEYID_d、通信双方和中间人产生的两个DH密钥、通信双方的Cookie值。

SKEYID_e需要的密钥素材有：SKEYID、SKEYID_a、通信双方和中间人产生的两个DH密钥、通信双方的COOKIE值。

签名和HASH计算需要的素材：SKEYID、通信双方和中间人产生的两对DH公开值、两个阶段的SA载荷的数据、通信双方的身份认证识别载荷ID、同一个CA的根证书签发的两个或多个证书文件。

上述密钥素材将会运用到IKE协商发起方(A主机)、IKE协商接收方(B主机)与IKE协商中间人处理主机(C主机)的数据处理之中。

3.2 模块划分

整个网络的IPSEC通信的安全审计系统主要分为五个模块，各个模块的功能如下：

密钥托管中心模块 用于存储针对于通信主机IP地址对和SPI值的IPSEC SA出入口密钥、证书、预共享密钥等管理、查找和其他密钥素材计算处理的模块。主要实现的功能是：密钥与密钥素材的计算、针对特定主机IP的伪证书的存储管理、数据的签名计算和密钥与证书的验证计算。

分类器模块 用于对受安全审计环境通道上各种数据包的分流处理。对于不同特征的数据包进行不同的处理流程。

ESP包处理模块 用于对受安全审计环境通道上ESP包的处理的验证、加解密计算处理。

IKE协商处理模块 用于对受安全审计通道上的IKE协商过程进行中间人方法，生成密钥发送给密钥管理中心，生成明文信息发送给明文信息数据库，向密钥托管中心交互进行相关参数的申请和验证。

策略中心模块 接收策略申请和发送策略。

3.3 分类器模块实现

当一个数据包被中间人程序所运行的主机接收到时，验证程序中的数据包分类器首先根据此数据包的以太网帧头部的以太网类型字段判断接收到的数据包是否为IPv6数据包。如果接收到的不是IPv6的数据包，则把此数据包透明传输到协商接收方B主机。如果接收到的是IPv6数据包，则去掉接收到的数据包的以太网头部，再判断其IPv6头部的发送方A地址和接收方B地址是否和所要进行监管的两台主机的地址是否一致。如果和两台受监管主机的IPv6地址不一致，则将数据包透明传输到协商接收方B主机。如果接收到的数据包和两台受监管主机的IPv6数据包一致，则再次判断此数据包的IPv6头部字段的Next Header字段是否为所需要协议(ESP协议或者ISAKMP协议)，如果不是，则将此数据包透明传输到协商接收方B主机。如果判断出数据包的下一层协议是ESP协议，则将此数据包所存储的内存地址作为参数传给ESP数据包处理单元。如果判断出数据包的下一层协议是UDP协议，则再次判断UDP的目的端口号是否为ISAKMP协议的端口号。如果不是ISAKMP协议的端口号，则将此数据包透明传输到协议接收方B。如果接收到的是ISAKMP协议的数据包，则将此数据包所存储的内存地址作为参数传递给IKE协商处理单元。

3.4 IKE协商处理模块

当数据包进入IKE中间人协商模块进行数据处理，首先判断数据包中的ISAKMP的头部字段的发送者和接受者的COOKIE是否都为0，如果是，则表示接收到的ISAKMP包为畸形包，直接透明传输给接收方主机。然后再次判断ISAKMP头部的版本号是否为支持的版本号，支持的版本号为1。然后判断ISAKMP头部的FLAG值是否规范，如果FLAG为提交类型则将此数据包透明传输到协商接收方B。如果FLAG字段的类型为标准类型，则根据协商的双方的COOKIE值头部字段从存储双方协商细节数据的双链表PH1TREE中获取第一阶段协商数据结构体PH1。如果获得的PH1结构体为非空，且如果本地为协商发起方并且接收方的COOKIE为0，则抛弃此数据包，否则，再次判断变量PH1变量中的源地址和目的地址和数据包中是否一致，如果是，则转入判断ISAKMP头部的交换类型，否则抛弃此数据包。如果没有查找到相应的PH1结构体，则转入判断ISAKMP头部的交换类型。

根据ISAKMP头部的交换类型值，判断所发送的IKE协商数据包处于协商的哪一个阶段。如果处于第一阶段主模式，则将数据包交由第一阶段处理单元处理。如果处于第二阶段的快速模式，则将数据包交由第二阶段处理单元处理。

在第一阶段处理单元中，首先判断接收到的ISAKMP包的MSG_ID是否为0，因为主模式阶段的MSG_ID字段值必须为0。然后判断从PH1TREE双链表中获得的主模式阶段结构体是否为空，如果是，则该报的接受者的COOKIE值必定为0，根据协商连接标识(A或B)和I_COOKIE从PH1TREE中查找PH1变量，如果查找到的主模式数据结构PH1依旧是空并且数据包中的接收方的COOKIE值为0，则进入到主模式开始处理流程单元。如果在此单元处理的第一次从PH1TREE中获得主模式信息结构体PH1时不为空，然后判断PH1中的ETYPE变量和数据包中的字段是否匹配，如果匹配，则将数据包交由主模式后期处理流程单元处理，如果不匹配，则向用户打印警告信息。

在第二阶段处理单元中，首先判断之前第一阶段的结构体PH1是否为空，如果为空，则打印出错信息，如果不为空，则判断PH1结构体的连接状态是否为已建立状态，如果已经建立连接状态，然后通过第一阶段的结构体PH1查询相关的第二阶段结构体PH2，如果查询到的第二阶段结构体PH2为空，则将数据包传递给快速模式开始处理流程单元进行处理；否则，判断其ISAKMP包头部的FLAG字段是否为提交类型，如果是，则将数据包传递给快速模式后期处理流程单元处理，否则向用户打印警告信息。

在主模式或者快速模式下的处理过程中，首先要根据存储的连接状态和接收到的ISAKMP包中的信息判断接收到的数据包是否合理，然后根据协商数据包所处的状态判断接收到的ISAKMP数据包应该交由什么状态的消息处理函数处理。处理过程中包括相应的接收函数和发送函数。在接收和发送工作完成后，将协商过程中改变的状态和协商好的参数等信息保存到连接信息存储变量中。

中间人程序在主模式状态处理过程中包括6个接收处理过程和6个发送处理过程。每一个处理步骤包括一个接收处理过程和一个发送处理过程。

第一次接收到发送方A发送的协商包1后，对数据包中的参数不作修改，并且将协商发起方A发送的SA载荷保存起来，在这个过程中，要建立协商发起方A和中间人主机之间的连接状态变量，并且根据预设的值将连接状态变量进行相应初始化。

第一次向协商接收方B发送数据时，首先要建立协商接收方B主机和中间人主机之间的连接状态变量，并且根据预设的值将连接状态变量进行相应的初始化处理，并且将协商发起方A主机之前发送的数据包1直接传送给协商接收方B主机。

第二次接收到协商接收方B主机发送的协商包2后，修改协商接收方B主机和中间人主机之间的连接状态，不对其中的参数修改。

第二次向协商发起方A发送数据，首先要修改协商发起方A主机和中间人主机之间的连接状态变量，然后将之前接受到的协商接收方发送的协商包2之间传送给协商发起方A主机。

第三次接收到协商发起方A主机发送的协商包3后，修改协商发起方A主机和中间人主机之间的连接状态信息，然后将数据包中保存的Diffie-Hellman公开值和随机值NONCE载荷数据保存到协商发起方与中间人主机之间的连接状态变量中，并且修改协商发起方A主机和中间人主机之间的连接状态变量，产生两个Diffie-Hellman公开值，一个是用于中间人回送给协商发起方A的DH1，另外一个是用于中间人主机发送给协商接收方B主机的DH2，这两个值的产生实现了对于Diffie-Hellman算法的中间人方法。然后将DH1保存到中间人主机与协商发起方A主机的连接共享变量中，DH2值保存到中间人主机与协商接收方B主机之间的连接共享变量中。

第三次向协商接收方B主机发送协商包3，并且将其中的Diffie-Hellman算法值修改为DH2，然后发送给协商接收方B主机。

第四次接收到协商接收方B主机发送的协商包4，修改协商接收方B主机和中间人主机之间的连接状态信息，然后将协商包4中的随机值Nonce载荷数据保存到协商接收方B主机和中间人主机之间的连接状态信息中。

第四次向协商发起方A主机发送协商包4，修改协商包4中的Diffie-Hellman算法公开值为DH1，并且计算协商发起方A主机与中间人主机和协商接收方B主机和中间人主机之间的DH最终值，并且将两方的DH最终值保存到相应的连接状态信息共享变量中。然后将所得到密钥素材根据认证方式的不同如预共享密钥认证和数字签名认证方式计算出SKEYID_d、SKEYID_a、SKEYID_e 和第二阶段数据加解密密钥，并且分别保存到协商发起方A主机与中间人主机和协商接收方B主机和中间人主机之间的连接信息共享变量中，最后将协商包4回送给协商发起方A主机。

第五次接收到协商发起方A主机发送的协商包5后，如果协商主机A和B之间是预共享密钥的认证方式，则首先运用之前得到的协商发起方A主机和中间人主机之间的解密密钥解密协商包5，获取其中的身份认证信息载荷数据，并且根据之前得到的密钥素材重新计算协商包5后的HASH_I载荷数据值。如果协商主机A和B之间是数字签名认证的方式，首先要从密钥托管中心获取两个受安全审计主机A和B的证书的私钥，如果能够拿到两个主机的证书的私钥，然后将重新计算协商发起方A主机发送的HASH_I值，并且用协商发起方A主机的证书的私钥对HASH_I值进行签名产生SIG_I；如果没有拿到其中一个主机的证书的私钥，比如协商发起方A主机的私钥，就要将协商发起方A主机发送的证书载荷替换成托管密钥中心提供的一个已知私钥的证书，然后运用此私钥签名HASH_I值生成SIG_I值。最后修改协商发起方A主机和中间人主机之间的连接状态变量。

第五次向协商接收方B主机回送协商包5，将之前过程中重新生成的数据构造成协商包5，然后发送给协商接收方B主机，并且修改协商接收方B主机和中间人主机之间的连接状态共享变量。

第六次接收到协商接收方B主机回送的协商包6，其处理过程与第五次接收到协商包5过程相似，但是在本环境中默认协商接收方B主机的证书信息受到密钥托管中心的托管。

第六次向协商发送方A主机回送协商包6，将之前过程中重新生成的数据构造成协商包6，然后发送给协商发送方A主机，并且修改协商发送方A主机和中间人主机之间的连接状态共享变量。

中间人程序在快速模式状态处理过程中包括4个接收处理过程和4个发送处理过程。同主模式的处理过程相同，每一个处理步骤包括一个接收处理过程和一个发送处理过程。

由于验证环境中采用的是PFS前向认证的模式，所以和主模式中的中间人处理过程类似，快速模式中的中间人处理也要替换前两个协商包中的DH公开值，重新计算DH公开值；与主模式中不同的是，IPsec SA的每个提案载荷中的头部之后会有一个32位的随机值(256-0xffffffff)SPI作为最终ESP加解密密钥计算的素材，所以要将发送方A主机的多个SPI存储起来，等到接收方B主机选择的提案回送给A主机时，首先将接收方B主机产生的SPI储存，然后将B主机选择的IPsec SA中的提案与A主机发送的多个提案进行匹配处理，找到相应的A主机的SPI值进行存储。

经过主模式和快速模式的处理，中间人主机分别和协商的A、B两个主机产生一对ESP包的数据加解密密钥与认证密钥，需要分别保存到相应的连接信息共享变量中。

4 实验验证

4.1 验证环境

我们将进行实验验证的进行IPSEC通信的两台主机分别定义为A主机与B主机。把进行中间人方法验证的主机定义为C主机。

A、B两个主机的配置是大致相同的，主机配置如下所示：

机器型号：戴尔OptiPlex 990

操作系统：CentOS Linux6.5(开发者版本)

IKE协商开源应用：Racoon2-20100526a.tgz

A主机验证中间人程序有效的socket工具：SocketApp_Client(自己开发的Socket服务器端)。

B主机验证中间人程序有效的socket工具：SocketApp_Server(自己开发的Socket客户端)。

IPv4配置：禁用。

A主机IPv6配置：2001::ba97:5aff:fe04:dff0。

B主机IPv6配置：2001::ba97:5aff:fe04:dfe4。

C主机的配置如下：

机器型号：戴尔OptiPlex 990

操作系统：CentOS Linux6.5(开发者版本)

针对IKE协商和ESP数据传输中间人程序：Racoon2-20100526a_1005.tgz

网络数据包捕获函数包：libpcap-1.5.3.tar.gz

网络数据包构造函数包：libnet-1.1.2.1.tar.gz

IPv4配置：禁用

IPv6配置：禁用

4.2 网络连接

在C主机上增加了一个USB网络接口转换器，作为连接B主机的网络接口。而C主机主板上的网络接口连接到A主机。其网络连接拓扑如图3所示。其中，接口eth0是中间人C主机主板上的网络接口，接口eth1是C主机上增加的USB网络连接转化器。

图3 网络连接拓扑

4.3 验证方法

分别对受监管主机A和主机B上的IKE协商工具Racoon2进行配置，使两台主机选择建立IKE协商通道的方法，比如预共享密钥身份验证方式和数字签名身份验证的方式。当两台主机之间的配置包括IKE SA、密钥生存时间、预共享密钥、证书文件位置、打开PFS开关等。

当确定好两台主机之间IKE协商参数后，在主机A上使用Ping6 2001::ba97:5aff:fe04:dfe4命令去访问B主机，当两者通信开始后，A主机和B主机就开始IKE协商并且建立好受监管主机A和B之间的IPsec连接通道，当受监管主机A和B之间的连接通道建立好之后，然后用A主机上的SocketApp Client 端去访问B主机上的SocketApp Server端，并且循环发送字符串信息，Server端在收到字符串信息后也回复相同的字符串信息。如果访问过程中A、B主机通信的内容都准确无误到达对方并且在中间人主机上能够解密出A、B主机通信的明文信息的话，就表明针对IPsec协议的透明中间人方法模型有效并且传输信息不受干扰。

4.4 验证结果

在实验开始时，我们在A主机运用Ping命令去测试A、B主机之间是否能通过中间人主机C去建立一个IPsec通道。通过我们实验显示，在A能够通过C主机与B主机进行Ping通信后，表明一个IPsec通道已经建立。在IPSEC通道建立的过程中，C主机上接收并处理其两个网络接口上的协商数据包，一共产生了两组IKE协商过程。

我们试验了预共享密钥认证方式的IKE协商过程与数字签名认证的IKE协商过程，这两种认证方式协商生成的数据大致相同，只是数字签名认证方式的IKE协商第一阶段的最后两个数据包需要证书的交换。

如图4所示的是C主机进行中间人处理的过程，标记的部分为中间人C主机对从两个网络上接收的ESP数据包进行转换的相应操作。

图4 中间人C主机ESP数据包转换操作

中间人C主机与A、B两台主机之间产生的一组出口与入口的加密密钥、认证密钥。在我们实验的过程中，使用enckey表示为ESP数据包加密密钥输出到日志中，authkey表示为ESP数据包的认证密钥输出到日志中。产生的总密钥数量为2对。

图5 SockApp Client端发送消息内容

图5显示了我们自己编写了一对Socket数据包传输程序在A、B主机之间进行验证通信，A、B主机相互之间发送UDP数据包，发送的数据信息为随机输入的一串字符串“dsfsdfdsfdsf”，并且此字符串数据在两个Socket程序之间是循环相互发送的。如图6所示，A、B两台主机之间发送与接收数据成功。

图6 SockApp Server端接受消息内容

中间人C主机在分别接收到A主机与B主机发送的信息后进行ESP数据包的转换操作，同时，C主机会将解密的明文数据包转换成PCAP格式的文件。我们通过Wireshark软件打开明文数据包的PCAP文件后，在明文数据包的Data字段找到了一组十六进制的数据，如图7所示，转换为十进制后为我们的Socket程序发送的字符串信息“dsfsdfdsfdsf”，以上实验证明了我们的原型系统具有对IPsec加密通信的数据进行审计的功能。

图7 中间人C截获和转换出的明文数据包

4.5 对通信效率带来的影响测试

图8所示的是当我们在有C主机运行时与没有C中间人主机时运用A主机对B主机进行ping通信时产生的数据通信的时延进行分析的数据图。斜线填充柱状数据代表当C主机运行安全审计时A主机对B主机在进行Ping通信的时延，时延数据用左边Y轴的坐标数据进行表示，单位为毫秒；与之作对比的灰色填充柱状数据代表没有C主机的情况下A主机对B主机进行正常Ping通信的时延。

图8 性能验证结果

由图中数据我们可以分析出，C主机处理的时延对于正常Ping通信的每次响应时间平均增加了约5.8 ms时间。据我们的估计分析，这5.8 ms时延时间是因为C主机的硬件因素、C主机加解密处理时间、C主机网卡数据包处理时间造成的。所以，还需要对我们的原型系统进行算法与硬件上的改进，以减少审计处理的时延。

5 结 语

当前的工作是在一种类似透明网桥模式下进行安全审计的方式，所以我们现在的安全审计的性能还是有一些不理想的。由于现在很多的研究热点都集中在SDN，我们今后的网络安全审计的工作会在SDN环境下进行。

在SDN的模式下由于控制层面[8-9]与数据层面[10-11]的分离的出现，会对我们当前的工作产生很大的跨越，也会给其他端到端的安全协议的数据安全审计带来革命性的进步。我们设想在SDN网络环境下很多会造成延时的工作或者需要计算资源比较大的工作可以转移到一个计算集群中进行，集群之间的计算资源可以做安全审计的并行处理。那么在这种情况下，对于整个网络的数据的安全审计的速度也会大大增加，安全审计的性能也会大大提高。

[1] NAT traversal[EB/OL]. http://en.wikipedia.org/wiki/NAT_traversal.

[2] Wei J, Tang L, Chen Z. Two Modifications for Identity Protection of Internet Key Exchange Protocols[J].Computer Engineering and Applications, 2004,40(26):33-36.

[3] Singh E G，Dhanda E S K. Quality of Service Enhancement of Wireless Sensor Network Using Symmetric Key Cryptographic Schemes[J].International Journal of Information Technology and Computer Science, 2014,6(8):32-42.

[4] Liu Z, Li Z, Lin S. Design and Implementation of 10-Gigabit IPsec ESP Protocol based on FPGA[J].Communications Technology, 2015.

[5] Zseby T，Fabini J. Security Challenges for Wide Area Monitoring in Smart Grids[J]. e & i Elektrotechnik und Informationstechnik, 2014,131(3):105-111.

[6] Xu H, Cheng G, Yang F. Prevention of Man-In-The-Middle Attack in Diffie-Hellman Key Exchange under Specific Environment[J]. Information Security and Communications Privacy,2009(2):90-92.

[7] Zhang J. The Key Exchange System base on IKEv2 protocol[D].Shandong: Shandong University, 2014.

[8] Matsumoto S, Hitz S, Perrig A. Fleet: Defending SDNs from Malicious Administrators[C]//Proceedings of the Third Workshop on Hot Topics in Software Defined Networking,2014:103-108.

[9] Berde P, Gerola M, Hart J, et al. ONOS: Towards an Open, Distributed SDN OS[C]//Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, 2014:1-6.

[10]JeyakumarV,AlizadehM,GengY,etal.MillionsofLittleMinions:UsingPacketsforLowLatencyNetworkProgrammingandVisibility[C]//Proceedingsofthe2014ACMConferenceonSIGCOMM,2014:3-14.

[11]YangT,XieG,LiY,etal.GuaranteeIPLookupPerformancewithFIBExplosion[C]//Proceedingsofthe2014ACMConferenceonSIGCOMM, 2014: 39-50.

THE RESEARCH OF IPSEC SECURITY AUDIT MECHANISM IN IPV6 ENVIRONMENT

Du Xuekai Wu Chengrong Yan Ming

(NetworkandInformationCenter,SchoolofComputerScience,FudanUniversity,Shanghai200433，China)

IPv6 network is now popularized gradually because IPv6 can satisfy the demand of possessing exclusive address of global network nodes, and more and more people use the IPSEC technology to communicate with each other. However, the lawful interception in IPSEC communication is becoming difficult for many institutions; it is a problem that needs to be solved. To address this problem, an IPSEC security audit method of combining man-in-the-middle attack and key escrow system in IPv6 network is proposed and a prototype system is also built to realize the IPSEC security audit in and between the IPv6 networks. After functional verification and performance analysis in IPv6 environment, the experiment demonstrates the efficiency of the proposed method as expected.

IPv6 network Network security audit Man-in-the-middle Key escrow scheme Internet protocol security

2015-10-23。杜学凯，硕士生，主研领域：网络安全与SDN。吴承荣，副教授。严明，工程师。

TP393.08

A

10.3969/j.issn.1000-386x.2017.01.054