闫 露，邓浩江，陈 晓，叶晓舟

1(中国科学院 声学研究所 国家网络新媒体工程技术研究中心，北京 100190)2(中国科学院大学，北京 100190)

1 引 言

近年来，出现了越来越多来源于网络内部的攻击，如内部人员对网络的滥用、信息泄露等.为监督内部用户行为，规范网络操作，保护内网安全，网络安全审计系统快速发展.作为系统中后续工作的数据来源，数据采集起着至关重要的作用.网络上的数据大部分是以明文形式传输的，这便于采集分析.随着人们对数据安全需求的增强，安全协议得到了广泛应用[1].通过安全协议保护的数据是以密文形式传输的，这为数据采集带来了新的挑战，需要首先将其转换为相应的明文数据[2].

传输层安全协议[3-5](Transport Layer Security，TLS)及其前任安全套接层协议[6](Secure Sockets Layer，SSL)是网络上应用广泛的安全协议，目前已成为传输层安全的事实标准.TLS协议是一个可选的安全层，位于TCP层和应用层之间，各种应用层协议可以透明的运行于TLS协议层之上，例如HTTP协议、FTP协议等.

TLS协议提供身份认证、数据加密和完整性校验等安全特性.通常，由客户端发起TLS连接，并通过服务器提供的基于PKI(Public Key Infrastructure)体系的数字证书[7]来验证其身份.同样的，在一些安全性需求较高的场景下，服务器可选择认证客户端的身份.此外，双方需要通过握手协议协商安全参数[8]，进行密钥交换，以此建立起安全的通道来保障通信的机密和可靠性.

由于TLS协议数据是密文传输的，需要首先在握手阶段解析数据包，通过一定技术手段获取到密钥信息后，才可以在数据传输阶段对数据进行解密.为完成握手协商过程，客户端和服务器需要维护正确的状态机，状态机主要描述了TLS消息数据包的发送顺序，然而协议文档并未规定一个严格的状态机.许多学者研究了TLS协议客户端和服务器的状态机实现问题.文献[9]关注安全协议的状态机，并讨论了从协议实现中学习出状态机的可能性.文献[10]则通过黑盒测试的方法学习了主流TLS协议库的状态机实现，并且指出对于TLS协议而言，正确的状态机并不是唯一的.文献[11]分析了TLS的状态机实现，找出一些状态机实现错误并分析了可能导致的攻击.基于对协议规范和特性的不同理解，在实现过程中会存在多种正确的状态机.对于数据采集器而言，理解客户端与服务器实现的所有状态机是较为困难的.

TLS协议在提供安全特性的同时，频繁的密码操作为客户端和服务器带来了较大的开销.在握手阶段，双方需要通过公开密钥算法进行身份认证和密钥交换，其中服务器私钥操作是非常费时的.此外，当双方传输大量数据时，对数据进行加解密和完整性校验的开销也较大.同时，网络上传输的数据量不断增大，速度不断增快，这都对数据采集的性能提出了更高的要求.

本文针对网络安全审计系统中TLS协议采集的需求，基于多核网络处理器平台实现高效的数据采集，提出一种状态机无关的数据采集方法，并针对私钥查找操作进行优化，提高系统性能.

2 数据采集系统架构

网络安全审计系统可基于网络进行数据的采集分析，数据采集器主要完成数据采集分析的工作，对网络协议进行处理，识别用户行为，提取关键信息，并封装生成日志发送至数据中心.数据采集器可以旁路方式部署于网络环境中，通过交换机镜像流等[12]方式实时获取到数据流并采集分析.在这种模式下，采集器不能够对数据包进行修改，检测到不规范的操作或者危险的命令时，只可以及时进行告警.旁路部署的优势在于对原有系统的影响小，数据采集器的故障并不会影响客户端和服务器的连接.

由于TLS协议带来的额外负载，以及高速增长的网络带宽，单个核心的处理速度已经不能满足采集分析TLS协议数据的需求.多核网络处理器具有多核并行、功耗低、加速网络数据包处理等特点，基于多核网络处理器平台来实现数据采集器具有明显的性能优势.

TLS数据采集架构如图1所示，逻辑是可以分为两部分：控制平面和数据平面.控制平面完成采集策略和证书配置等管理功能.采集策略指明需要分析采集的数据流，证书配置使得采集器在旁路模式下可以使用服务器的证书私钥.数据平面用于采集和分析数据，当数据采集器接收到网络数据后，首先完成TCP/IP重组等功能，确认数据的完整和有效性之后提交给高层协议进行分析.

图1 数据采集器系统架构Fig.1 System architecture

数据采集器基于异构系统实现.由于Linux操作系统具有通用及灵活性的特点，数据采集器中控制平面的功能在Linux系统下实现，这可以降低开发和移植难度并且为管理功能的多样性提供了基础.SE(Simple Executive)系统下可以直接操作底层资源，并且避免了系统调用、中断处理等开销，可进行高效的网络数据包处理，实现数据采集器中数据平面的功能.在数据处理时，同一个数据流的处理放在同一个处理核心上，这样可以避免过多的核间通信开销.Linux系统和SE系统可通过共享内存或者消息等机制进行通信.

3 状态机无关的TLS协议数据采集方法

3.1 状态机实现问题

TLS协议是一个分层协议，包括底层的TLS记录层协议和高层的TLS改变密码规范协议、TLS告警协议、TLS握手协议.TLS记录层协议为底层协议，为其他协议提供最基本的安全特性和封装传输.TLS改变密码规范协议用以通知数据接收方随后的记录都会用协商好的安全参数来进行保护.TLS告警协议用以通知对方连接信息，包括告警的严重性和告警描述.通信双方通过TLS握手协议进行安全参数协商、身份认证、生成密钥等.

如图2所示，这是一个常见的TLS协议状态机，然而在实际过程的实现时，情况远没有这么简单.TLS协议提供多种密码套件和扩展特性，很多特征都是通过单独的文档来定义的.TLS协议在实现过程中会存在多种正确的状态机.此外，协议文档是不断更新的，当前一个不合法的数据包发送顺序将来可能是正确的，也就会导致一个新的状态机，这都使情况变得更加复杂.TLS false start[13，14]便是一个很好的例子，TLS协议文档规定通信双方在发送和验证对方的Finished消息后才可以发送接下来的加密应用层消息.后来在实践中有人员提出，当通信中的一方发送Finished消息后，可以不用等对方发送并验证对方的Finished消息，便可以直接发送应用层消息，这样可以减少TCP传输的时延.因此在TLS数据采集过程中，若采集器维持自身的TLS状态机，首先兼容客户端与服务器所实现的所有状态机是比较困难的，其次若根据状态机来实现，未来的可扩展性也不强.对于该问题，我们提出了一种状态机无关的TLS协议数据采集方法，具体而言，采集器不维持自身的状态机，在处理数据时仅将关注的重点放在接收到的数据包上，而不是数据包的发送顺序上.

图2 TLS协议状态机Fig.2 TLS state machine

3.2 状态机无关的数据采集方法

该方法的总体思想在于数据采集器不维持TLS协议状态机，在客户端和服务器握手阶段，对接收到的握手消息进行处理获取会话信息，会话信息主要包括随机数、加密套件、压缩算法、预主秘密等，最终计算生成主秘密并扩展生成MAC密钥、对称加密算法密钥、IV，随后在数据传输阶段，利用获取的密钥信息等将密文数据解密，并将解密后的数据提交至高层协议解析进行处理生成审计数据.

TLS协议中，记录是传输的最小单元，在进一步解析处理数据之前，首先需要提取完整的记录.协议规定，TLS记录内容长度不超过 2^14+2048 字节，而这一数字远超出一般TCP的最大报文段长度(Maximum Segment Size，MSS)，因此较大的记录会被分作多次TCP传输.此外，由于TCP传输的特性以及网络环境较差等原因，不超过TCP最大报文长度的记录也会被分作多次进行传输.另一方面，为了提高传输性能，将多个长度较小的记录合并在一个TCP报文段的情况也会发生.因此TCP传输的报文并不作为TLS记录的边界，在经过TCP重组后的数据虽然是完整有序的，仍需要从中提取生成完整的TLS记录后再进行处理.TLS记录的格式满足以下格式：

ε=t|v|l|p

(1)

其中，ε为一条记录，t为一个字节的内容类型，v为两个字节的协议版本，l为两个字节的内容长度，p为具体的内容.

算法1.TLS Record Reconstruct

1：procedure Reconstructing(fi，bufc)

2：bufc←Empty，lbc←0，j←1

5： whileltemp>0 do

6：lbc←calc_len(bufc)

7： iflbc+ltemp>5 then

9： iflbc+ltemp>5+rcdlentthen

◁ TLS record reconstruct OK

11.bufc←Empty

13.ltemp←ltemp-(rcdlent+5-lbc)

14. else

16.ltemp← 0

17. end if

18： else

20：ltemp← 0

21： end if

22： end while

23：j←j+1

24： end for

25：end procedure

算法1描述了具体流程，在记录提取过程中，充分考虑多种传输情况，实用性好.另一方面，为提高处理效率，需要减少内存拷贝的次数.如果底层提交的数据仅仅是记录的一部分，则对该部分数据进行拷贝缓存，待后续拼接生成完整的记录后再处理，而如果底层提交的数据中已经包含完整的记录，则不需要对数据进行拷贝缓存，可直接进行处理以减少内存拷贝带来的开销.

在TLS握手阶段，客户端和服务器会传输多个握手消息以进行协商，数据采集器需针对消息进行处理.消息是封装在记录中的，一个记录中可能包含单个或者多个握手消息，首先需要提取出完整的单个消息后再进行接下来的处理，这一过程与提出完整记录类型，在此不再赘述.

消息处理 的目的在于获取会话信息，生成密钥.在握手消息中，Hello Request消息用以通知客户端在何时的时候开始进行握手协商，Certificate Request消息和客户端Certificate消息用以认证客户端，这些消息与会话信息并没有太多关系.当服务器证书无法供客户端进行密钥交换时，服务器发送Server Key Exchange消息用以提供密钥交换的参数，在这种密钥交换方式下，仅仅为数据采集器配置服务器证书和私钥是不足以计算出预主秘密的，因此数据采集器需要其他方式来获取预主秘密，本文暂不讨论这种情况.对于其他握手消息，数据采集器进行差异化的处理以获取会话信息，如算法2所示.

算法2.TLS Handshake Message

1：procedure processing(hdmsg)

2：type←hdmsg[1]

3： switch (type)

4： case 1： ◁Client Hello

5：vsc，rdc，IDc← calc(hdmsg)

6：dealwithExtensions

7： case 2 ： ◁ Server Hello

8： ifSessionResume

9：rds，IDs← calc(hdmsg)

10：getcipher_suite，comm，master_secretfromcache

11：key_block← calc(master_secret，rdc，rds)

12： else

13：vss，rds，IDs，cipher_suite，comm← calc(hdmsg)

14： end if

15：dealwithExtensions

16： case 4 ： ◁ New Session Ticket

17：updatesessiontickets

18： case 11： ◁ Certificate

19： ifmessagefromserver

20：pubkey.der← calc(hdmsg)

21：keypri← find(pubkey.der)

22： end if

23： case 16： ◁ Client Key Exchange

24：p_master_secret← calc(keypri，hdmsg)

25：master_secret← calc(p_master_secret，rdc，rds)

26：key_block← calc(master_secret，rdc，rds)

27：savesessioninfo

28： case 20 ： ◁ Finished

29：verifydata← calc(allhandshakemessage)

30：compareverifydataandhdmsg

31： default ： ◁ Other Handshake Message

32：donothingnow

33： end switch

34：end procedure

在此需要注意的是，TLS协议中定义了许多的扩展项，有些扩展项是与会话信息紧密相关的，在处理握手消息时需要对这些扩展项进行相应的处理.例如，Extended Master Secret扩展项[15]，该扩展项定义了另外一种相对更加安全的主秘密的计算方式，若忽略该扩展项则会计算出错误的主秘密，以至于后续无法正确解密数据.

一旦收到改变密码规范协议消息，数据采集器便可以知道在该方向上接下来的消息将会用协商好的密钥和安全参数进行保护.

告警协议对于会话信息的获取并没有太大作用.告警协议对双方通信状态进行报告，在网络安全审计系统中，对于一类有意义的错误信息，可将其作为重要的错误日志进行存储.

通过以上的处理，数据采集器已经可以获取到相应的加密算法等安全参数，计算出用于数据传输阶段的MAC密钥、对称加密算法密钥、IV.在数据传输阶段，便可以对相应的加密数据进行解密、验证完整性、解压缩等.解密后的数据可提供给高层协议模块进行进一步的解析，生成审计日志发送至数据中心.

在消息处理过程中，一种常见的证书配置方式是为每个IP配置一个服务器私钥，例如Wireshark便采用这种方式.这种证书配置方法适用于每个服务器IP只有一个证书私钥对或者抽取一些特定的数据流后进行配置.但是服务器的IP和证书私钥并不总是一一对应的，同一个服务器IP下很可能会有多个证书私钥对.数据采集器需要实时对数据流进行采集分析，当后端服务器每个IP下拥有多个证书私钥对时，便没有办法通过IP来查找私钥.而证书和私钥却肯定是一一对应的关系，因此在数据采集时，选择通过证书来查找相应的私钥，而不是IP.

通常的私钥查找算法我们称之为PCS(Private Key Certificate Search).控制层面完成服务器的证书和私钥配置，生成一个哈希表，以供后续查找.证书和私钥都有其特定的文件格式，通常配置的证书为PEM格式，而在TLS通信过程中服务器Certificate消息中的证书为DER格式.若在配置时，服务器证书依然选择以PEM格式进行计算关键词并存储至哈希表，那么在数据平面进行证书查找时，每个数据流的Certificate消息提取证书后都需要进行相应的格式转换才能进行查找，这显然是不高效的.因此，控制层面在进行配置时，首先将证书转化为DER格式再进行接下来的处理.

算法3.PCS algorithm

1：procedure processing(hdmsg)

2： control plane：

3： ifCertificateConfigurationthen

4：keyt←Empty，i← 1

5： forpubkey.pemido

6：pubkey.deri←p2d(pubkey.pemi)

7：hashk←Hash(pubkey.deri)

8：keyt←add(hashk，prikey.pemi)

9：i←i+1

10： end for

11： end if

12： data plane：find(pubkey.der)

13：hashk←Hash(pubkey.deri)

14：prikey.pem←lookup(hashk，keyt)

15：keypri←P2X(prikey.pem)

16：end procedure

尽管PCS算法已经针对证书格式进行了优化，然而在实践中发现，这种算法的效率并不是十分理想.在数据平面使用服务器私钥时，首先需要将私钥文件转换为特定的封装结构，这一操作影响了系统的性能，因此我们提出了一种更高效的结构化私钥信息缓存算法，简称PKES (Private Key Encapsulation Structure caching algorithm).算法的优点在于减少了私钥的转换次数.该算法在每个数据处理核上建立一个哈希表，用于存储证书和对应的私钥封装结构.每个数据处理核都需要存储一份的原因在于，私钥的封装结构若希望能够被多个核共同使用，则必须进行加锁，否则会造成数据的同步错误.而加解锁操作会影响多核的处理效率，因此在每个数据核上都存储一份，以空间来换取更高的效率.私钥的转换与哈希表的加入并不是在证书私钥对配置时便在每个数据核生成一份，而是流驱动的.控制层面更新证书私钥对配置时，仅更新相应的标志位.当在数据处理时，遇到证书消息后，首先查看标志位，若发现控制层面进行了更新操作，则将旧哈希表中的数据删除，再进行相应的私钥查找、转换与哈希表的加入.后续，当在同个数据核上遇到相同的证书时，便可以直接查找使用相应的私钥封装结构.这样的优势在于配置的证书私钥对可能在下一次配置更新前并不会被用到，也就不用进行相应的转换.此外，同一个证书对应的连接很可能会被调度到某些特定的数据核上，而不是在所有的数据核都会出现，在数据核上遇到证书后再进行操作，可以避免一些无用的转换，节省时间和空间.

算法4.PKES algorithm

1：procedure processing(hdmsg)

2： control plane ：

3： ifCertificateConfigurationthen

4：keyt←Empty，i← 1

5： forpubkey.pemido

6：pubkey.deri← p2d(pubkey.pemi)

7：hashk← Hash(pubkey.deri)

8：keyt← add(hashk，prikey.pemi)

9：i←i+ 1

10： end for

11.flag← 1

12： end if

13： data plane：find(pubkey.der)

14： ifflag= 1 then

15： forj←1：totalworknumdo

16：flagd[j] ←1

17： end for

18： end if

19：n←tempworknum

20： ifflagd[n] = 1 then

21：keyd[n] ←empty

22：flagd[n] ← 0

23： end if

24：hashk← Hash(pubkey.deri)

25：keypri←lookup(hashk，keyd[n])

26： ifkeypri=NULLthen

27：prikey.pem← lookup(hashk，keyt)

28：keypri← P 2X(prikey.pem)

29：keyd[n] ←add(hashk，keypri)

30： end if

31：end procedure

1Cavium.OCTEON II CN66XX Multi-Core MIP S64 Processors.http://www.cavium.com/OCTEON-II_CN66XX.html.

为评估算法性能，首先定义如下属性：

M：数据采集器配置的证书和私钥对的数目.

N：数据采集器用作数据处理的处理核心的数目.

Fc：一段时间内总的新建连接数量.

Fcd：该段时间内的新建连接种类.其中，在通信过程中所使用的证书相同的连接定义为同一类连接.

Ot：私钥转换为特定封装结构的次数.

那么，在PCS算法中，需要在处理每一个连接时都将私钥转换为封装结构，即：

Ot=Fc

(2)

而在PKES算法中：

(3)

在PCS算法中，数据采集器所需要进行的私钥的转换次数是与新建连接的数量成正比的.新建连接数量不断增多，私钥转换操作的累积时间开销不断增长.而在PKES算法中，数据采集器所需要进行的私钥的转换次数与连接类型的数量直接相关，而不是新建连接的总数量.转换是流驱动的，所进行的私钥的转换次数一定不会超过新建连接的数量.并且其最大次数是可以预估的，它受限于所配置的证书私钥对数目和数据处理核心数目.所配置的证书私钥对数目与后端服务器的数目和配置相关，这并不会太大，而处理核心的数目受物理平台的限制.因此，服务器的数量，服务器配置的证书数量终归有限，在新建连接数量较多时，新建连接类型的数量却并不会一直增长，而是有一个上限.PKES算法仅需要牺牲较小的内存空间，便可以减少转换次数，取得更高的效率.

3.3 方法分析

状态机无关的TLS数据采集方法具有很强的可扩展性和可维护性.我们可以很清楚的知道有多少握手消息，有多少扩展项，而且均有详细的文档对这些消息和扩展项进行描述.但是协议却没有规定一个严格的状态机，在实现这些规范时，会有许多不同的状态机存在.如果数据采集器在分析TLS数据流时维护一个TLS状态机，那么当客户端和服务器发送消息数据包的顺序不符合数据采集器的状态机时，那么工作便没有办法继续，后续的维护工作也会十分繁琐，而数据采集器维持的状态机也必将越来越复杂.而状态机无关的TLS数据采集方法将关注的重点放在消息本身，而不是消息的发送顺序.对于数据采集器而言，需要关注消息的类型，如果消息当前不能识别，虽然不能被处理，只要这些消息对会话信息没有影响，则数据采集器可以继续正确解密数据.后续的维护工作也只需要加入对相应消息的处理，而不需要修改复杂的逻辑.

4 实验与分析

在本节中，进行一系列实验，用以验证所提出多核数据采集框架以及状态机无关的TLS数据采集方法.数据采集器以Cavium OCTEON CN6645多核网络处理器1为平台实现，该平台有10个处理核心，主频为1200MHz，配备8G内存以及2MB的L2级缓存.实验中，TLS客户端和服务器分别运行在两台Dell服务器上，系统通过交换机镜像流获取到双方通信数据.实验测试了系统的性能，并比较了PKES和PCS两种算法.

4.1 每秒新建连接数

每秒新建连接数(Connection Per Second，CPS)直接反映系统新建连接的时间，对于TLS协议而言，在TCP连接建立之上，双方需要经历一个握手协商阶段才可以建立TLS连接.握手消息的处理速度直接影响系统的CPS性能，在握手阶段，最耗时的操作在于服务器对于预主秘密的解密，这涉及公开密钥算法的私钥操作.在本实验中，服务器分别配置密钥长度为1024位的RSA证书和2048位RSA证书，同时为数据采集器配置相应的证书和私钥对.首先，我们测试了在不同数据处理核心数目下，系统的CPS性能，结果如图3所示.

由图3可以看出，随着数据处理核心数目的增加，系统CPS性能线性增长.在新建连接时，使用2048位RSA证书比1024位的RSA证书时解密预主秘密速度要慢许多，CPS性能也就差很多.但在相同密钥算法下，密钥长度增加对于TLS连接而言更加安全.总的来说，TLS协议服务器需要在性能和安全性之间做出一个平衡，研究更高效的新的加密算法也是提供TLS协议执行性能的有效途径之一.

PCS算法和PKES算法区别在于对私钥的操作，主要影响握手消息的处理、系统新建连接的时间.我们分别测试了使用PCS算法和PKES算法下系统的CPS性能，测试结果如图4所示.相比PCS算法，PKES算法取得了很大的系统性能提升，当证书密钥长度为1024位时，系统CPS增长了130%，当证书密钥长度为2048位时，系统CPS增长了50%.对于不同长度的密钥，将私钥转换为封装结构的时间不同，因此PKES算法对系统性能提升程度也不相同.

图3 系统CPS性能Fig.3 CPS measured from experiment图4 PCS算法和PKES算法性能对比Fig.4 CPS performance comparison

在这个实验中，我们分别为数据采集器配置了一对证书和私钥，使用6个核心来进行数据处理.使用PCS算法时，每当新建一个连接，都需要为这个连接对私钥进行相应的封装结构转换，累积时间开销较大.而在使用PKES算法时，私钥的转换次数为6.私钥封装结构的存储减少了所需要的转换次数，节约了握手消息的处理时间，增加了系统的CPS性能.

4.2 吞 吐

当TLS双方握手协商完成后连接建立，便可以进行数据的传输.在进行吞吐性能测试时，双方传输的数据量较大，此时握手阶段的开销则相对较小，此时主要考虑对称密钥算法和哈希算法.在本次实验中，我们使用AES256_SHA算法组合.数据采集器使用6个处理核心进行数据的采集，吞吐可稳定达到2500Mbps，而我们作为对比测试的一款成熟产品只能达到240Mbs.图5显示了在不同处理核心数目下系统的性能，随着处理核心数目的增加，吞吐性能的增长并不是完全线性，出现这一现象的原因在于大量的数据处理造成了不同处理核对缓存的竞争.

图5 吞吐率测试结果Fig.5 Throughput of the collector system

5 总 结

本文首先讨论了数据采集器的部署模式，提出了多核网络处理器平台下的数据采集架构.数据采集系统主要由控制平面和数据平面两部分构成，控制平面运行于通用Linux系统，数据平面运行于SE系统，充分利用平台的优势，兼具性能与灵活性.

在TLS协议实现过程中，客户端与服务器实现的状态机多种多样，我们提出了一种状态机无关的数据采集方法，达到更好的兼容性，并支持协议的灵活变化和扩展.此外，为减少私钥转换为对应封装结构的时间开销，提出了一种结构化私钥信息缓存算法(PKES)算法，算法牺牲了少量的内存空间换取到更高的性能.实验表明，与常规私钥查找算法PCS相比，PKES大大提高了系统CPS性能，当证书为1024位RSA密钥时，系统CPS增长了130%，当证书为2048位RSA密钥时，系统CPS增长了50%.系统性能较高，吞吐率可达2500Mbps.