一种稳定高效的加密报文回收设计*

2015-06-23秦培斌肖志辉杨大川

通信技术 2015年4期

关键词：加解密序列号报文

秦培斌，李青，肖志辉，杨大川

(1.西南交通大学信息科学与技术学院，四川成都 610031；2.迈普通信技术股份有限公司路由产品研发部，四川成都 610041)

一种稳定高效的加密报文回收设计*

秦培斌1，李青1，肖志辉2，杨大川2

(1.西南交通大学信息科学与技术学院，四川成都 610031；2.迈普通信技术股份有限公司路由产品研发部，四川成都 610041)

目前,加密报文回收设计多采用连续序列号回收或基于时间戳的报文回收方法，但这两种方法都存在明显缺陷，不能很好满足软件设计的需求。连续序列号回收方法要求硬件安全可靠，严格按照报文顺序处理、回送报文，否则易导致IPSec逻辑错误。基于时间戳的报文回收方法消耗系统资源较多，同时报文超时时间不易设定，因此，有必要设计一种稳定高效的加密报文回收方法。通过对加密报文回收设计的研究，在加密报文中加入特定的报文序列号，有效解决了上述两种方法的缺陷，并可通过设定解锁次数合理设定报文超时时间，满足了软件稳定、高效的运行需求。

报文回收；加密；IPSec

0 引言

当今社会信息安全问题日显突出，如何确保网络通信安全已成为全社会关注的问题。IETF(因特网工程任务组)于1998年发布了安全协议标准IPsec，该协议随后成为互联网安全的基石之一[1]。IPSec作为开放标准的网络安全协议已经广泛应用于全球互联网[2]，为了提高我国互联网的数据业务安全性，国家密码管理局也研制了一系列具有自主知识产权的加密算法，SM1作为最基础的商用密码分组标准对称算法，已成为我国各行业应用最广泛的加密算法策略。

1 加密驱动报文回收流程

现在我国大部分通信设备制造商的路由器产品均支持SM1加密算法，且大多采用：IPSec协议层↔SM1加密算法驱动层↔SM1硬件加密芯片，这种软硬件架构[3]。驱动程序作为一个桥梁，使得应用程序和加密卡的通信得以实现[4]。为了提高加密芯片的利用率，SM1加密算法驱动层会采用异步流水线设计方式，即IPSec协议层可以将数据报文批量发给驱动层，然后进行缓存和排序并送交硬件加密芯片进行加密处理，等待报文加密完成并从硬件回送至驱动层过后，软件通过排序的序列号查找对应的回调函数将报文送回IPSec协议层。基于这种设计思路，目前加密报文回收采用的技术方案要点如下：

1)采用一个虚拟BD(Buffer Descriptor)环进行报文的缓存和排序。

2)设计加密报文封装头，将BD序列号信息保存到封装头中，并跟随报文发送至硬件加密芯片(整个加密报文封装头在处理过程中不会发生变化)。

3)根据回送的加密报文封装头获取对应的BD序列号，并查找到对应BD上保存的回调参数，最后将加密报文回送IPSec协议层。数据处理流程如图1所示。

图1 报文处理流程框

处理流程1：将待处理资源进行缓存和封装，并锁定BD资源。

处理流程2：将封装完成的报文发送至硬件加密芯片进行加解密处理。

处理流程3：接收加解密完成的报文并解析对应的BD序列号，查找对应的BD缓存的回调参数，通过回调函数将报文回送IPSec协议层，并将对应的BD资源进行解锁，供后续待处理报文使用。

2 现有解决方案

在上述整个处理流程中，需要考虑由于硬件加密芯片或硬件通道不稳定引起的丢包情况，所以如何识别和判断报文丢包，并将相应的BD资源释放，同时将加解密失败的结果通告IPSec层成为软件设计的关键问题。针对以上问题目前有两种解决方案：连续序列号报文回收和基于时间戳的报文回收方案。

2.1 连续序列号报文回收

报文传输的一个重要特征就是正常传输的报文序号应该是连续非递减的，当到达报文的序号没有按照连续非递减方式出现时，则网络中出现丢包或乱序[5]。该方案的算法实现即是基于此理论，通过判断回收报文的BD序列号是否连续，判断是否存在丢包的情况。例如发送到硬件加密芯片的报文序列号为1、2、3、4，但是驱动接收到硬件加密完成的报文序列号为1、2、4，此时报文序号不连续，因此判定3号报文已经丢弃，驱动则可查找到对应的BD资源，将3号报文加解密失败的结果通过回调函数通告IPSec协议层。

该方案的优点是算法逻辑简单，但缺点是适应性窄，健壮度低。因为该驱动的设计方案对硬件的要求很高，要求硬件加密通道及加密芯片对报文做到顺序处理，否则一旦回送的报文乱序则会引起函数逻辑错误。然而，大量研究表明，报文乱序是互联网中普遍存在的现象[6]，随着网络传输速率的提高，报文乱序出现的比例同时也呈增长趋势[7]。如果加密卡回送报文的序列号为1、2、4、3，当驱动发现4号报文已经回送时，则认为3号报文已经丢弃，于是将3号报文加密失败的结果通告IPSec协议层并释放3号BD资源，后续待处理的报文马上占据了3号BD资源进行使用，此时原来已经上报错误的3号报文的加密结果回送到驱动，驱动这时就无法区别回收到的3号报文是否为本轮次发起的加密请求返回的结果，默认将上一轮的报文处理结果当作本轮次的加密结果回送IPSec协议层，导致报文顺序错误，引起IPSec层处理异常。

2.2 基于时间戳的报文回收

我们通常将在网络上传输的带时间的信息叫做时间戳[8]。基于时间戳的报文回收方法引入了时间戳的概念，每一个BD资源在LOCK的时候就打上了一个时间戳，并且需要不断的轮询检测每一个BD是否在合理的时间内进行了解锁，如果超出限定时间未解锁，则判定该BD对应的报文已经丢弃，然后进行错误通告以及BD资源解锁等一系列动作，该方案作为现在应用比较广泛的技术方案，虽然能够避免由于乱序引起的对丢包事件的错误判断，但也存在明显的缺陷：

1)引入时间戳及轮询BD超时的任务带来了较大的资源开销，每一次轮询都要对每一个BD的当前时间戳进行获取，并且和BD LOCK的时间戳进行比较判断是否超时，整个流程的处理繁琐，且驱动程序的实现也比较复杂。

2)超时阈值不易设置。报文超时阈值的设定非常重要，阈值设置过长时会导致服务质量降低[9]，即丢包情况下BD资源不能迅速解锁，资源回收效率低下；如果阈值设置过短，一旦出现超时过后对应的报文才回收到驱动，会出现和连续序列号报文回收方案中一样无法处理的情况，即驱动无法识别当前报文是否是上一次加解密请求的结果，回送IPSec协议层同样会导致报文顺序错误，引起IPSec协议层处理异常。

3)另外，在某些多核的情况下，核间的时间戳存在差异，并不能保持完全同步[10]，所以不同处理核对时间戳的判断标准不一致，导致超时判断标准出现波动，引起不可避免的错误判断。

由此可见，上述两种方案均存在比较明显的缺陷，无法做到一个比较理想的状态，即整个加密报文的回收检测算法简单，不受报文乱序等因素的限制，且出现超时判断过后，即使原来的报文收回也不会受到干扰甚至引起异常。

3 优化方案

针对以上存在的问题，本文设计了一种非常简单且易于软件编码实现的算法，增加了整个加密驱动软件的健壮度，既没有软件乱序的限制，也可以在一个合理的超时时间过后，识别报文的正确性，将已超时的报文过滤掉，不影响正确报文的回收。具体如下：

1)加密驱动软件构建用于缓存报文的虚拟BD环，虚拟BD环的长度由调用模块请求速率和被调用模块执行速率之间的速度差来决定[11]，对应的加密速率越高，建议设定的BD环长度越大。如图2所示，创建完成BD环过后，需要对每一个BD结构进行初始化，保证每一个BD结构处于解锁状态供待加解密报文进行缓存，BD结构用于存储对应缓存报文回送IPSec层时的回调函数和参数。

2)当IPSec协议层将待加解密报文送入驱动层时，驱动程序需要依次查找BD环并获取空闲的BD结构(解锁状态)缓存该报文，然后将BD序列封装至报文头，并将回调参数保存至对应的BD结构中，最后对BD资源进行锁定，确保该报文在加密完成之前该BD不会被其他报文占用。

图2 优化方案BD操作

3)本设计在加密报文封装头中加入了除BD序列号之外的另一个专属于本次发送报文的序列号，该序列号在每一个报文完成封装过后进行累加，每次累加1即可，目的是保证每一个加密报文都有独占的特定标识符。同时也将该标识符保存到报文对应的BD结构中去，作为回收报文时对比报文正确性的依据。具体的报文头封装如图3所示，从理论上来说，该序列号的取值范围空间尽可能大，例如64bit,即8字节位宽，此时可以基本忽略序列号翻转的可能性，保证所有报文标识符的独立。

图3 报文处理流程框

4)完成报文的缓存信息存储及报文的封装后，将报文发送至加密芯片进行加解密处理。加密芯片会保持封装头不变，并将处理完成的密文内容代替原有的待加密数据区域的明文，最后将加解密完成的报文回送至加密驱动[12]。

5)加密驱动对接收报文的报文头进行解析，获得BD序列号以及报文自身的序列号，然后通过BD序列号查找到对应的BD缓存结构，将BD序列号和BD结构中保存的报文序列号进行比较，如果相等就说明该报文就是需要回收的报文，然后从BD结构中读取对应的回调参数，将报文回送IPSec协议层；如果比较结果不相等，说明该报文已经被判定为被丢弃的报文，此时已经不具备有效性，直接进行丢弃操作。整个过程如图4所示。

图4 判断加密报文丢弃过程

1)待处理报文1占用BD1资源过后对BD1进行锁定，将自己的报文序列号1封装至报文头发送至加密芯片，同时将序列号1这个信息保存至BD结构中。

2)当整个2048个BD环全部锁定过后，驱动判断BD1的报文已经超时，对BD1资源进行解锁，然后使待处理报文2049占用BD1。

3)待处理报文2049对BD1完成锁定后，将自己的报文序列号2049封装至报文头发送至加密芯片，同时将序列号2049这个信息保存至BD结构中。

4)此时处理完成报文1回送至驱动层，驱动通过其封装头中的BD序列号查找到对应的BD1资源，然后将处理完成报文1的序列号和BD1资源中保存的待处理报文2049的序列号相比较，发现该报文并不是需要接收的报文，说明该报文已经被判定为被丢弃，不再进行处理，直接丢弃该报文，完成对已经过期报文的准确过滤。

5)当处理完成报文2049回收到驱动层时，通过其封装头中的BD序列号查找到对应的BD1资源，并通过报文的序列号对比，发现2049号报文确实是本轮次BD1中正在处理的报文，即可进行后续正常流程的处理。

6)本设计中不再引入时间戳作为判断超时的标准，也不再借助BD序列号判断报文顺序是否连续，这里通过判断BD是否已经全部LOCK作为判断标准，当所有的BD均处于LOCK状态时，从IPSec传入的报文已经没有缓存资源可用，此时将第一个被LOCK的BD资源进行解锁，提供给新传入的报文使用，默认前一个占用该BD资源的报文已经丢弃。同时这里是需要进行灵活调整的，如果BD环的长度较长，则可以将判断BD Lock的次数设置为1次，即如果出现了无Unlock BD的情况时，则把第一个Lock的BD进行解锁，默认第一个报文已经丢弃。如果BD环较短，则可以通过对第一个被Lock BD进行多次判断再进行解锁，即当出现无Unlock BD情况时，并不立即对第一个Lock的BD进行解锁，而且等待多次判断尝试过后，如果依然处于Lock状态，再进行解锁，同时默认第一个报文已经丢弃。这里推荐在内存足够充足的情况下，尽可能将BD环加大，这样也可以提升驱动模块的缓存能力。具体的解锁过程见图5。

图5 BD环解锁过程

综上所述，本设计中的算法，具备两个可以保证加密流程高效运行的必要条件：

1)简单高效的超时判断机制，只要硬件平台的处理出现任何的阻塞或者波动，被影响的报文可以通过对应BD的Lock次数立即被判定为丢弃。

2)有效可靠的序列号识别机制，即使被硬件波动而影响的报文被回收至驱动层，也可以进行识别和丢弃，不会影响后续报文的正常处理流程。

4 结语

本所述的优化方案从简化算法，提高程序运行处理效率为出发点，同时通过修订加密报文的封装头信息实现了对报文正确性的识别。通过对比可知，连续序列号报文回收方法逻辑简单，但是其对硬件要求高，不允许报文出现乱序；基于时间戳的报文回收方法可以避免由于报文乱序引起的对丢包事件的错误判断，但其存在额外的任务开销、超时时间不易设定等问题；而本文所设计的优化方案，既没有报文乱序的限制，也可以在合理的超时时间过后识别报文的正确性，同时也不存在额外的任务开销。无论从处理效率还是从软件健壮度上这种方案都带来了明显的提升，同时将软件设计的复杂度大大降低。此外，本技术方案并不局限于具体的加密算法，也不仅仅局限于对加密数据的处理，只要是类似使用一个BD虚拟环进行数据流发送和回收的设计均可以使用本方案，可见本方案具有良好地可扩展性。

综上所述，只要合理的运用BD环的锁定状态作为报文超时判断标准，并通过加入报文的独有序列号进行报文的正确性识别，本方案从理论上完全解决了现有的加密驱动软件在丢包处理上可能遇到难点。

[1] 杨洋，花欣，李希源等.对IKE协议中弱密钥的研究[J].通信技术，2014，47(10):1198-1202. YANG Yang,HUA Xin,LI Xi-yuan,et al.Weak Keys in IKE Protocol[J].Communication Technology, 2014，47(10):1198-1202.

[2] 马小婷.深入浅出密码学—常用加密技术原理与应用[M].北京：清华大学出版社，2012.118-122. MA Xiao-ting.Understanding Cryptograph-A Text Book for Students and Practitioners[M].Beijing:Tsinghua University Press,2012.

[3] 秦培斌，肖志辉，杨大川等.基于多核处理器的加密卡异步并行驱动设计[J].通信技术，2014,47(07):832-835. QIN Pei-bin,XIAO Zhi-hui,YANG Da-chuan,et al.Asynchronous Parallel Driver Design of Encryption Card based on Multi-core Processing Unit[J].Communications Technology,2014,47(07):832-835.

[4] 陈静，章喜才，张金果等.基于DM642的PCI加密卡驱动程序设计[J].制造业自动化，2011,(04):129-131. CHEN Jing,ZHANG Xi-cai,ZHANG Jin-guo,et al. The design of the PCI Encryption Card Driver based on DM642[J]. Manufacturing Automation, 2011,(04):129-131.

[5] 高中耀，程光.TCP报文丢包定位方法研究[J].计算机工程与应用，2013，49(15)：70-74. GAO Zhong-yao,CHEN Guang.Locating TCP Packet Loss[J].Computer Engineering and Applications,2013，49(15)：70-74.

[6] Allman M，Eddy W M，Ostermann S.Estimating Loss Rates with TCP[J].ACM Performance Evaluation Review,2003:31.

[7] Gharai L,Perkins C,Lehman T. Packet Reordering,High Speed Networks and Transport Protocol Performance[C]//IEEE 13thIntl Conf on Computer Comm,and Networks,ICCCN 2004,2004:73-78.

[8] 赵英，张莹莹.基于连续时间戳通信模型的时钟同步[J].微计算机信息，2006，22(8-1)：238-240. ZHAO Ying,ZHANG Ying-ying.Clock Synchronization Based on Continuous Timed- Stamp Communication Model[J].Microcomputer Information,2006，22(8-1)：238-240.

[9] 曹哲，尤政.超时策略动态阈值的阈值选择影响因素[J].哈尔滨工业大学学报，2013，45(06)：119-123. CAO Zhe,YOU Zheng. The Influencing Factor of Threshold Selection in Dynamic Threshold of Timeout Policies[J].Journal of Harbin Institute of Technology, 2013，45(06)：119-123.

[10] 许斌.基于DM3730异构多核处理器的嵌入式操作系统设计与实现[D].成都：电子科技大学，2013. XU Bin.Design and Implementation of DM3730 heterogeneous Multi-core Processor based Operating System[D].Chengdu:University of Electronic Science and Technology,2013.

[11] 康杰.基于异步回调机制的嵌入式linux浏览器底层设计与实现[D].重庆：重庆大学软件学院,2005. KANG Jie.Design and Implementation on Asynchronous Callback Mechanism based Lower-layer of Embed Linux Browser[D].School of Software Engineering Chongqing University,2005.

[12] 陈亚东，林为民，张涛等.基于X86的高速加密卡异步并行驱动设计[J].电力系统自动化，2010,34(10)：93-96. CHEN Ya-dong,LIN Wei-min,ZHANG Tao,et al.High Speed Asynchronous Parallel Driver Design Based on x86[J]. Automation of Electric Power Systems:2010,34(10):93-96.

Design of Stable and Efficient Encrypted Packet Callback

QIN Pei-bin1,LI Qing1,XIAO Zhi-hui2,YANG Da-chuan2

(1.School of Information Science and Technology, Southwest Jiaotong University, Chengdu Sichuan 610031,China;2.Maipu Communication Technology Co., Ltd, Chengdu Sichuan 610041,China)

Nowadays consecutive serial number callback or message callback based on time stamp is usually adopted in the design of encrypted message callback.However these two callbacks feature obvious defects and could not well meet the demand of software design. The continuous sequence number callback method requires fairly high hardware safety and reliability,process and send back the message in strict accordance with the message sequence,otherwise would easily lead to IPSec logic error.The callback method based on time stamp may consume more system resources and at the same time,it is not easy to set up the message timeout. Therefore, it is necessary to design a stable and efficient encryption packet callback method.The research on the design of encrypted packet callback indicates that by adding a specific message sequence number to the encrypted packet head,the defects of the above two methods could be effectively solved,thus satisfying the demand for stable, efficient operation of software.

packet callback; encryption; IPSec

date:2014-10-16；Revised date：2015-02-20

TP311.52

1002-0802(2015)04-0473-05