面向多密码业务流快速处理的硬件实现方案

李 莉，史国振，李雪梅

(1.北京电子科技学院 电子与通信工程系，北京 100070； 2.北京电子科技学院 信息安全研究所，北京 100070)

0 引 言

高速发展的数字经济和网络业务面临着越来越多安全问题，密码服务作为保证数据传输安全的最基本的服务，也成了保障网络安全的不可或缺的环节，密码服务设备也成了安全网络的基本配置。面向越来越多的业务安全需求，密码设备必须提供不同的密码运算服务，且要求具有快速的数据处理能力。密码运算作为计算密集型应用，为了提高其处理速率，通常采用多密码算法核并行处理、单密码算法流水线处理的硬件实现架构，通过多核并行处理提高多业务处理的能力，以及单核流水线实现高的数据吞吐率。

考虑到经过网络传输的多密码业务流存在业务间的相互交叉，如何最大性能地发挥并行流水处理的有效性是必须考虑的问题。本文以多业务交叉的密码业务流为研究对象，考虑不同密码工作模式特点，提出了一种关联业务数据迁移的硬件架构，从而更好地发挥密码设备多密码算法核并行流水处理性能。

1 相关研究

如图1所示，在高并发、多对多通信的场合下，请求密码服务的数据可能来自不同的应用服务器，即不同的数据链接，也可能来自同一数据链接下的不同业务，为实现密码服务的快速正确响应，密码服务器必须有快速的异步并发数据处理能力。

文献[1]研究了密码算法在GPU上的并行化处理技术，评估了在CUDA上对AES算法采用不同并行设计实现后的性能。文献[2-5]研究了ECC算法的特点，通过对点乘、模乘运算的并行处理，提高了椭圆曲线的运算性能。戴紫彬等、L. Bossuet等研究了密码算法的流水线、串行化实现技术，以达到多核并行和高吞吐率目的[6,7]。

多密码算法IP核的并行处理涉及两方面的问题：并行处理架构以及算法IP的调度。文献[8]通过并行层叠执行结构，实现ECC算法在数据级、线程级和任务级上的并行计算。文献[9]针对密码处理器运算过程中，数据访存时间开销大的问题，提出了一种层次化-分布-分体式流存储结构，改善了数据访存开销。文献[10]提出了一种减少核间通信开销的设计方法。文献[11]提出了一种面向分组密码的可重构异构多核并行处理架构RAMCA，具有独立的指令传输通路、数据输入通路和数据输出通路，但未涉及交叉业务数据处理的问题。

考虑密码运算的特点，密码运算通常是以固定大小的分组数据为单位进行的，且根据采用的密码工作模式的不同，同一业务的不同分组间的关系也不同。以ECB、CTR工作模式为例，不同分组间的运算相互独立，可以进行并行运算；但是CBC、CFB等工作模式，后一分组数据的运算要用到前一分组数据的运算结果，即不同分组间存在关联性，不能进行并行运算。且数据流作业包间存在如图2所示的分布情况。

在此，对分组间存在关联性的业务称为关联业务，关联业务的存在，势必影响多核密码运算的并行流水处理，从而降低业务的处理速率。

文献[12，13]提出了一种支持多种密码算法运算随机交叉运算的多核流数据处理模型，通过基于业务标识的分层硬件调度实现业务流的并行处理。文献[14]提出了一种本地存储异构多核并行架构，将数据的处理分为分转、预处理、运算及同步重组4个阶段，通过基于数据标识的分级处理机制实现作业包与算法IP核间的映射与数据处理，增设密钥及状态存储器(KSM)和KSM存取控制逻辑用于交叉访问下关联作业包中间状态的存取，保证并行及串行工作模式下数据处理的正确性。考虑到数据存取速率的限制，以及架构并没有对算法核输入端的关联数据做额外的管理，仍会造成交叉数据在一定程度上的等待，从而影响数据吞吐率。本文在文献[14]的基础上，提出一种关联业务数据迁移的硬件架构，删除KSM，在算法核前端增设关联CAM，算法核后端增设关联FIFO的方式，进行关联作业包的管理，实现交叉数据流的不间断高速处理。通常查找功能在硬件上的实现是在时钟驱动下，对搜索空间的依次对照实现的，最坏情况下存储容量为n的查找操作需要消耗n个时钟周期，即查找时间复杂度为O(n)， 本文采用关联CAM，实现查找时间复杂度由O(n) 减少为O(1)， 使得后序关联作业包的查找可以实现快速定位，加速数据流的处理。后端采用关联FIFO的设计，使得先运算完的关联作业包的后序作业包可以及时得到处理，减少对前段关联CAM的占用，从而减少系统对存储空间的需求。

2 交叉并行数据处理方案

2.1 并行数据处理模型

本文提出的关联业务数据迁移的处理模型如图3所示，通过将业务流中的关联作业包迁移至关联CAM，在其前序作业包运算完成时，将其送至算法核的处理方式，提高业务流的整体处理速率。

其中接口模块用于接收网络发送过来的数据流，为保证数据流的处理速率，采用PCIE接口的DMA方式进行数据的接收；算法分转模块用于将数据流中的不同业务数据包发送至对应的算法核进行处理；Pre_FIFO模块用于接收独立作业包和关联作业的首包数据，进行排队暂存；关联CAM用于存储前序作业包尚未运算完成，因而不能进行处理的后序关联作业包；选择模块用于将关联CAM或Pre_FIFO中的数据送至算法核输入队列进行排队等待运算。在关联FIFO有运算完成的关联作业包数据时，优先处理关联CAM中的数据。算法核模块为不同的密码算法IP核；输出FIFO用于接收运算完成的作业包；关联FIFO用于存储运算完成的关联作业包，其中尾包由于没有后序作业包，所以不进入关联FIFO，关联FIFO中的数据用于生成后序作业包运算的输入数据；输出反馈模块用于接收各算法核运算完成的数据，并发送回数据应用程序。

2.2 通信作业包

为便于业务流的处理，构造如下的数据包格式： {Header,load}， Header={IDPROCESS,IDIV,head,tail,SEQ,CMD,l}。

IDPROCESS：进程号，API接口的算法数据发送处理进程为每个链接分配独立的进程号，与应用进程对应，用于区分不同的数据链接。

IDIV：业务号，每个业务有一个全局唯一的IDIV。

SEQ：同一业务流中的作业包序号，用于作业包重组。

Head：业务的首个作业包(首包)标识。

tail：业务的最后一个作业包(尾包)标识。

CMD：命令字，用于标识业务处理类型， CMD={CYPID,OPTMODE}。

(1)CYPID字段标识算法类型和算法IP的ID号。算法类型如SM2、SM3、SM4，每一类算法可以采用多个模块实现，此字段的位数在FPGA内部逻辑资源充足的条件下决定了可以线性扩展的算法模块的个数。若此字段位数为n，则最多可扩展2n个密码算法模块。为加强数据处理的并行性，算法类型和算法ID号采用统一编码的方式，由加密终端CPU按照随机调度的方式一次完成填写，与算法模块一一对应的同时，保证算法IP核间的均衡性。

(2)OPTMODE字段表示算法的具体操作，例如加密、解密、签名、验签以及不同的加/解密模式(ECB、CBC、OFB)等。

l：数据长度，用于指出本作业包内运算数据的长度，一般为一次算法运算所需最小分组长度的整数倍。

load={IV,KEY,Data(l)} 为可变长度的数据区。其中IV表示初始向量或中间变量字段，KEY为密钥字段，当SEQ=1时，IV和KEY字段存在。Data(l) 为长度l的运算数据。在进行业务数据的分割打包时，若最后一组数据不够一次业务处理数据最小分组长度时，进行补足。

3 方案实现

上述并行数据处理架构的FPGA实现如图4所示，数据的处理分为3个阶段，分别由分转pd_se_ctrl、预处理IPx_CTRL及运算IPx这3个模块完成，模块间采用FIFO进行数据流的缓冲。虚线框内的部分可以根据各算法模块进行线性扩展，算法模块的具体实现个数可以不同。

FPGA与应用程序之间采用PCIE接口，以DMA的方式进行业务数据的传递。应用程序将业务数据拆分并封装为通信作业包，以阻塞的方式写入算法应用进程对应的下行数据存储区DOWN_FIFO中。算法数据的下行和上行读写操作分别由pd_tlp_ctrl和pu_tlp_ctrl完成。算法分转模块pd_se_ctrl完成对作业包头命令CMD的解析，把数据分转到相应的IPx_DOWN FIFO或Related CAM中。

下行预处理模块IPx_CTRL负责对命令的解析，并由此构造算法模块需要的处理子命令，以及获取处理本作业包所需要的中间状态数据，并将作业包头Header作为一个数据项放入本算法模块对应的作业包同步队列IPx_SYN FIFO，将分组后的数据、处理子命令、算法状态，及获取的基础数据作为一个数据项放入本算法模块对应的算法运算队列OPRTxFIFO。

上行控制模块UP_IPx_CTRL将作业包同步队列中提取的作业包头与处理后数据队列中提取的数据合并为一个带有链路数据标识的完整数据项，送入上行IPx_UP FIFO中，供pu_tlp_ctrl根据链路数据标识将运算结果返回给相应的上行数据存储区。

随机交叉的数据流以及异构IP核，不能保证关联作业包进入处理系统时，其前序作业包已处理完，因此，该系统在架构中增加关联CAM和关联FIFO。其中关联CAM用来存储尚不能进入算法核进行处理，处于等待前序关联作业包运算结果的关联作业包；关联FIFO用于保存关联业务中间状态，即关联作业包(非尾包)的运算结果，以供对应业务的后序作业包使用。

由于每个算法IP核都有自己独立的上行队列和下行队列，所以增加算法IP核不会对其它的操作造成影响。

3.1 数据处理流程

数据的处理采用两级命令解析的方式进行，系统按照通信数据包中包含的属性信息对数据进行解析和分流，主要取决于CMD={CYPID,OPTMODE}。 第一级解析在分转模块pd_se_ctrl中完成，根据算法类型CYPID字段，进行数据的分流，将不同密码算法需求的作业包分转至对应的下行数据IPx_DOWN FIFO或Related CAM中，排队等待；第二级解析在下行预处理模块IPx_CTRL中完成，根据运算模式OPTMODE，生成对应的子命令，并将命令和相应的数据传送给IP核接口OPRTxFIFO中。完整的数据处理过程包含6个状态，见表1。

数据处理状态转换如图5所示。

3.2 关联CAM

内容可寻址存储器(CAM)具有高速、并行、易扩展的特点，常用于路由器中，实现地址的快速查找。这里用于实现根据任务ID和作业包序号快速查找同一任务后序作业包。关联CAM模块如图6所示，内部包含任务ID和作业包序号存储列表id_seq_list、列表状态寄存器status_reg、作业包数据存储双端口DPRAM、数据拆分写控制模块write_ctrl，以及一个查询条件比较模块compare。

表1 数据处理状态

关联CAM模块的读和写相互独立，可并行执行，通过列表状态寄存器status_reg保证并行执行时读写操作的不冲突。

关联CAM的写操作由分转模块pd_se_ctrl启动，当分转模块判断作业包为关联作业包，且非首包，则将此数据通过din_wr送CAM保存，算法如下：

if OPTMODE=={CBC|OFB|CFB}

if head！=1

begin

wr_en<=1;

din_wr<=作业包；

end

write_ctrl模块将数据拆分为两部分：任务ID和作业包序号{IDIV,SEQ}、 作业包数据data，其中{IDIV,SEQ} 存储在列表中，Data存储在DPRAM中，且保持地址联动。

关联CAM的读操作由Related FIFO的非空状态启动，给出rd_en信号，由Related FIFO给出的前序作业包的运算结果din_rd作为查询输入信号，查询条件为同一任务ID和后序作业包序号，即IDIV&& (SEQ+1)。 根据查询条件对id_seq_list单元进行并行搜索，给出满足条件的作业包数据所在的地址rd_addr，以此为地址从双口DPRAM中将数据取出，送对应IP核的输入FIFO。

其中ram_full和infifo_almostfull为流控信号，保证作业包的不丢失。

在这种设计方式下，若前序作业包存在，则从查询数据(din_rd，ren)给出到找到结果(dout)，只需要4个时钟周期，其中匹配成功(find)只需两个时钟周期，如图7所示。

3.3 关联FIFO

考虑到及时处理运算完成的关联作业包，以便移除其对关联CAM的占用，降低对CAM存储容量的需求，增加利用率，输出关联作业包的存储采用FIFO的形式，下行预处理模块IPx_CTRL按作业包完成顺序接收其后序作业包。

作业包在算法IP核中运算完成后，上行控制模块UP_IPx_CTRL判断运算结果是否为关联业务作业包输出，若为非关联作业包或关联作业包的尾包数据，则将其送至输出FIFO；若为关联作业包(尾包除外)输出，则在将其送至输出FIFO的同时，将其送至关联FIFO。

if (OPTMODE=={CBC|OFB|CFB} && tail==0)

begin

UP_FIFO_data<=作业包;

UP_FIFO_wr<=1;

if (Related_FIFO_almostfull==0)

begin

Related_FIFO_full_flag<=0;//流控信号

Related_FIFO_wr<=1;

Related_FIFO_data<=作业包

end

end

考虑到交叉数据流的复杂性，极端情况下，可能在其前序作业包处理完成时，其后序作业包尚未进入关联CAM，为避免对其它任务作业包的阻塞，在经过一定的时钟周期，仍没有匹配作业包的情况下(find==0)，将关联FIFO的此输出数据重新转存至关联FIFO，从而越过此作业包，进行下一个作业包的处理，如图8所示。

3.4 数据间的同步

数据间的同步通过同步IPx_SYN FIFO和下行预处理模块IPx_CTRL、数据重组模块UP_IPx_CTRL完成。下行预处理模块IPx_CTRL将作业包的包头取出，送入同步IPx_SYN FIFO，数据重组模块UP_IPx_CTRL在作业包运算完成后，再将运算完成的数据与同步IPx_SYN FIFO中存储的包头数据组合为一个完整的作业包输出。由于作业包包头同步信息的存储单元和算法处理IP核的接口单元均为FIFO，保证了UP_IPx_CTRL进行封装时包头和处理数据运算结果间的一致性。

4 性能分析

将此硬件实现方案在FPGA上进行实现，并在modelsim下仿真，观察不同作业包和不同关联业务作业包数量下的数据流执行时间。

以最多需要3种IP进行处理的5个业务共20个作业包随机交叉的数据流为例，仿真结果如图9所示，为便于观察，只取数据流上下行中存储模块的读信号，其中find1、find2、find3为3个IP核对应的关联CAM匹配输出，可以看出关联CAM2没有信号，表示数据流中没有需要IP2处理的关联业务，因此IP2的关联FIFO也无数据，ip2_out_dependfifo_rd始终为0，IP2输入FIFO上infifo2_rd信号的存在是由于数据流中存在需要IP2处理的非关联业务。

关联CAM的存储深度为48，若任务id和作业包序号分别为32 bit和16 bit，分组运算数据的大小为256 bit，则需要的存储空间为： 48×(32+16)+48×256≤16K。

当数据流总量为100个作业包，随机属于10个不同的业务，其中4个业务为关联业务，且关联作业包的总数为40个，即关联业务量占总业务量的40%。Modelsim的仿真结果如图10所示，其中横轴表示数据流中作业包的分布，白色块表示独立作业包，其它色块表示关联作业包，且相同颜色的色块属于同一关联业务。纵轴表示数据流的执行时间。

当数据流总量为100个作业包，且分别属于10个不同的业务，其中6个业务为关联业务，关联作业包的总数为60个，即关联业务量占总业务量的60%。Modelsim的仿真结果如图11所示。

可见，相同大小的数据流，且数据流中的关联业务和关联作业包的数量相同时，数据流的执行时间与不同关联业务作业包的数量及其在数据流中的位置有关。

若数据流中有n个关联业务，每个关联业务的作业包数分别为a1,a2,…,an个，有m个非关联业务，每个非关联业务的作业包数分别为b1,b2,…,bn个。若能将非关联作业包穿插在关联作业包之间，在∑aiTi≥∑bi的情况下，则在IP核流水线处理业务的情况下，可以使得非关联作业包得到尽快的处理，而数据流的整体处理时间取决于关联作业包的串行执行时间。

随机选取6组数据流，每组数据流的作业包数均为100，且分别属于10个不同的业务，其中6个业务为关联业务，关联作业包的总数为60个。将关联CAM改为关联FIFO，对这6组数据流的执行时间进行测试，仿真结果如图12所示。

可见，采用关联CAM对关联作业包进行迁移的设计方式有利于提升交叉业务数据流的处理速度。由于IP核采用流水线的数据处理方式，所以在系统设计中，对于同一功能的IP进行数量的扩展，其对数据流处理速度的提升贡献不大，省出的逻辑空间可以用于扩展关联CAM和关联FIFO。

5 结束语

本文提出并在FPGA上实现了一种关联业务数据迁移的流数据并行处理系统。仿真结果验证，在多种不同的应用同时请求密码运算服务的场景下，该系统可以实现对交叉业务数据的正确处理，避免输入数据流阻塞现象的发生，实现业务数据的不间断处理。该系统的不足在于随着交叉程度的增加，所需关联FIFO和关联CAM的空间也要适当增加，否则不能保证非关联数据的及时处理。