APP下载

面向802.11ac的安全加速引擎Gbps VLSI 架构设计与实现

2015-06-05潘志鹏吴斌尉志伟叶甜春

哈尔滨工程大学学报 2015年7期
关键词:加解密引擎密钥

潘志鹏,吴斌,尉志伟,叶甜春

(中国科学院微电子研究所专用集成电路与系统研究室,北京100029)

安全协议作为无线通信网络必不可少的组成部分,一直是行业的研究重点。针对WLAN网络采用WEP(有线等效私密性)协议存在的不安全性,Wi-Fi联盟制定了 IEEE 802.11i[1]安全协议,增加 TKIP(暂时性密钥完整协议)和CCMP(计数器模式和密码分组链接模式协议)2种算法协议,提高了WLAN网络的安全性。数据帧的加解密涉及大量实时、复杂的算法运算,实现的性能将会严重影响系统的吞吐率和处理延迟,尤其是基于 IEEE 802.11ac[2]协议的下一代WLAN网络,单芯片系统的吞吐率达到Gbit/s量级,使得安全加速引擎的VLSI实现面临巨大挑战。为了实现高吞吐率、低延迟的WLAN系统加解密数据传输性能,改善安全加速引擎的算法架构并提出优化的VLSI架构将显得至关重要。

文献[3-7]针对RC4和AES加解密算法进行优化设计,虽然可以实现较高吞吐率,但并未涉及具体的安全协议,且未考虑VLSI实现对整个系统性能的影响。文献[8]实现了WEP/TKIP/CCMP 3种加解密协议,但其性能不足以满足下一代WLAN系统802.11ac对Gbit/s吞吐率的需求。本文基于不降低系统运算吞吐率为前提,提出了一种多模式、高性能的安全加速引擎架构,可以支持WEP/TKIP/CCMP等安全协议,重点优化了密钥查找的处理延迟以及提升AES-CCM的运算性能。

1 多模安全加速引擎VLSI系统架构

安全加速引擎运行于WLAN系统的MAC层,负责对MPDU数据帧进行加/解密运算,以保证通信双方数据交互的私密性。而安全协议设计实现的关键点在于,针对不同的安全协议设计相应算法引擎的VLSI架构以及加解密算法的高性能实现。安全加速引擎的VLSI架构将直接影响到系统的运算效率,甚至有可能会制约下一代WLAN系统性能的提升。综合考虑IEEE 802.11i安全协议对可扩展性的需求和IEEE 802.11ac下一代WLAN协议对数据传输性能的要求,本文提出一种可重构的安全加速引擎VLSI架构,如图1所示,主要包括5个部分:输入FIFO,输出FIFO,控制器,密钥信息查找模块和加解密运算核。

图1 安全加速引擎的系统架构Fig.1 System architecture of cipher engine

其中,输入缓存及输入封装状态机、安全加速引擎控制状态机、输出解封装状态机及输出缓存,这三者在运算数据流上构成一个流水线处理结构。在一个数据块运算周期内,可以同时实现下一个数据块的封装、当前数据块的加解密运算和上一个数据块的解封装。流水线的处理方式减小了数据块运算之间的等待延迟,也间接提高了数据帧加解密运算的吞吐量。该架构将不同加解密协议算法的实现,如WEP/TKIP/CCMP等安全协议,构成一个独立的加解密运算核,并提供一个统一的交互接口,使得整体架构具备较强的可扩展性。

安全加速引擎对每一个数据帧的处理,均需要与外部模块进行控制信息和状态信息的交互。若采用分立的信号线传输方式,无形中会增加系统处理的复杂性,且不易于系统的集成和扩展。对此,本文在标准的MAC帧格式上增加了2个信息域,如图2所示,一个是MAC帧头之前的控制信息,另一个则是帧末尾的处理状态信息。总线式的交互简化了模块之间协同工作的复杂性,使得所设计的安全加速引擎适用于IEEE 802.11a/b/g/n/ac等不同的协议标准,保证了系统的可维护性和可扩展性。

图2 安全加速引擎的输入输出帧格式Fig.2 Input/ouput frame format of cipher engine

2 低延迟密钥查找算法

一般情况下,经认证过程相互协商的各站点加解密信息会被配置到安全加速引擎,组成一个密钥信息查找表。而安全加速引擎进行数据帧的加解密运算之前,须根据对方站点的MAC地址查找到所对应的密钥信息。当一个BSS网络存在多个站点同时通信,接入点获取不同站点加解密运算所需的密钥信息会造成较大的查找延迟。为了降低密钥查找所带来的延迟,本文提出一种面向VLSI实现的快速密钥查找算法,可以实现平均查找延迟不随站点数的增加而线性增加,大大提升了引擎的查找效率。

本文采用一个128条目的密钥信息表,如图3所示,每一个条目的信息包括MAC地址、加解密协议和密钥等信息,将其分成3个查找区域:KeyId查找区、顺序查找区和Hash查找区。查找算法如下:

1)根据固定的Hash算法对MAC地址进行哈希运算,然后以哈希值直接索引Hash查找区,判断该信息条目是否匹配;

2)若该条目为空或发生Hash碰撞,表示Hash查找不命中,则跳转到顺序查找区进行顺序查找,直到某一条目命中;

3)如果Hash查找区和顺序查找区均未找到匹配的信息条目,则根据KeyId标识在KeyId查找区中进行查找。

图3 基于Hash算法的密钥查找表Fig.3 Key table based on Hash scheme

本文提出的密钥查找算法的关键在于,增加了Hash查找区(条目64~127),极大提高了密钥信息。查找的效率。然而,不同的Hash算法存在较大的哈希性能差异,如哈希碰撞概率的大小,并且也将直接影响到最终实现的复杂性。文献[9]分析了几种Hash算法的性能,包括 CRC校验、Fletcher校验、mod校验和异或运算,经过统计发现简单的异或运算能够达到较高的查找效率,且非常易于硬件逻辑实现。该文献同时指出,对于给定的MAC地址B1-B2-B3-B4-B5-B6,其中字节 B5(32~39 bit)存在较高的信息量。因此,本文采用异或运算作为固定的Hash算法,并截取6个字节异或值的中间6位(Index[6∶1])作为Hash查找区的索引值,如下

由于存在Hash碰撞现象,增加了一个顺序查找区(条目4~63),以此来保证能够存放足够多站点的信息。根据上述分析,假定经过MAC地址运算后的Hash值满足随机均匀分布,不同站点数下具备64个信息条目的Hash查找区平均存放的地址个数如下

式中:n为站点数;S(n,k)为第二类Stirling数,表示n个元素的集定义k个等价类的方法数目:

图4 不同站点数下Hash查找区的平均地址个数Fig.4 Average address number in Hash searching field

图5 查找效率对比Fig.5 Comparison of searching efficiency

如图4所示,在一定的站点数下,通过统计平均分析可知,Hash查找能够直接获取到绝大多数站点的密钥信息。若采用完全顺序查找方法,平均查找延迟会随着站点数的递增而线性增加,在32个站点数的情况下,其平均查找延迟需要16.5个时钟周期。而采用Hash查找算法,基本能够保持在平均1~2个时钟周期的查找延迟,大大缩短了密钥查找的平均延迟。2种查找算法的查找效率对比如图5所示。尤其是针对企业级 WLAN以及运营级WLAN,需要支持单节点密集用户的应用情况下,采用Hsah查找算法的WLAN接入点将能大大降低密钥查找的处理延迟,从而提升网络系统的吞吐率。

3 高吞吐率AES-CCM实现

针对下一代WLAN协议(IEEE 802.11ac)Gbit/s高吞吐率的需求,安全加速引擎实现的另一个关键问题是,在尽可能减小硬件逻辑开销的同时,寻求如何提高加解密算法协议实现性能的方法。本文在保证兼容性,实现WEP/TKIP/CCMP3种加解密协议的前提下,通过提出一种优化的AES-CCM算法协议实现架构,从而可以有效地满足Gbit/s高吞吐率的需求。

3.1 AES 算法实现

AES算法是一种对称分组加密算法,其加密流程如图6所示,每一轮的运算包括:字节替换、行移位、列混合和轮密钥异或。AES算法的硬件实现性能将直接影响整个安全加速引擎的运算吞吐量。大量的文献主要集中在对AES算法实现结构和字节替换上进行研究。通过采用循环展开或流水线方式的实现结构,提高AES运算核的工作频率,进而提升算法实现的吞吐量。但由于CCMP协议采用了AES-CBC的反馈模式,无法发挥流水线的结构优势。基于以上分析,本文采用基本迭代结构实现AES运算核,并对字节替换的实现性能进行精细地设计。

图6 AES加密流程Fig.6 Encryption structure of AES algorithm

通常,字节替换有2种实现方式:查表法和纯组合逻辑实现[5-7]。前者采用多个查找表,结构简单,易于实现,但占用硬件资源较大。后者利用有限域上的数学运算规则,采用硬件逻辑的方式直接求解替换值,可节省大量的存储器开销,但实现较为复杂。为了降低硬件逻辑开销,本文采用改进的有限域运算方式实现AES算法的字节替换,其实现结构如图7所示。将字节替换分成2步运算实现:1)有限域GF(28)的乘法逆运算;2)仿射变换过程。为了降低实现的复杂性,将第一步转化到复合域GF((24)2)上求解乘法逆运算:

其中:

式(5)计算的关键在于有限域GF(24)的乘法逆运算,同理,也可以变换到复合域GF((22)2)上进行运算,进一步降低实现的复杂性。

另一方面,为了尽可能减小关键路径的延时,提高整体运算的吞吐率,本文对2个步骤进行了合并预计算,分别为复合域GF((24)2)映射到有限域GF(28)的操作与仿射变换,将原本的两次矩阵运算变为一次运算。通过矩阵合并方式,从而降低关键路径上的逻辑开销,提升AES运算核的工作频率。

图7 字节替换结构框图Fig.7 Block diagram of implementation of SubByte

3.2 CCMP 协议实现

CCMP协议采用AES算法的计数器(CTR)模式用于数据加密,密文分组链接(CBC)模式用于完整性校验。相比于单个AES运算核顺序执行或交替执行数据加解密和MIC校验,双AES运算核并行实现架构将加倍提升安全加速引擎的吞吐量。但另一方面,也将面临如何降低双AES核所带来的硬件逻辑开销问题。本文在保证双AES核的数据块运算之间严格同步的前提下,将AES算法中的密钥扩展单元进行了逻辑复用,如图8所示,一定程度上节省了硬件逻辑的开销。

图8CCMP结构框图Fig.8 Block diagram of implementation of CCMP

图9CCMP加解密时序Fig.9 CCMP encryption/decryption flow

文献[10]指出,高速率WLAN系统采用的帧聚合和块确认机制,要求MPDU的加解密处理具备较小的响应延迟。而无论是双AES运算核的并行执行,还是加/解密运算的逻辑复用,均涉及到对输入数据块与输出数据块的精确调度。因此,本文充分利用CTR和CBC两种工作模式的运算特点,并且兼顾加密和解密过程的数据流执行顺序,设计了如图9所示的详细调度时序。双AES运算核的并行处理,使得平均每个数据块的加/解密运算延迟仅为11个时钟周期(11-cycleper-block),也就是AES算法的数据载入和10轮迭代的执行周期数。另外,因CBC模式处理{NONCE,AAD1,AAD2}而导致安全加速引擎的响应延迟也仅为33个时钟周期,相比于 Bae[8,10]的设计进一步减小了响应延迟。

4 系统验证与性能比较

本文采用硬件描述语言完成了硬件实现,通过RTL仿真验证,功能满足IEEE 802.11i的协议要求。同时,在项目组的WLAN协议原型系统开发平台上,集成本文设计的安全加速引擎,配合协议驱动的开发,实现了数据帧的正常加解密通信,进一步验证了所设计的安全加速引擎的正确性。

经过 QuartusⅡ10.0综合,选用器件型号为StratixⅡ EP2S180F1020I4,其综合的结果如表1所示。由于采用了有限域运算方式实现AES算法,使得单个AES运算核无需任何的存储器开销,且仅使用了较少的硬件逻辑资源。而相比于单个AES运算核较小的硬件逻辑开销,由于安全加速引擎完整实现了WEP/TKIP/CCMP3种加解密协议,同时需要处理不同MAC帧格式的数据帧,包括各字段信息的提取、数据块的封装与解封装以及配合外部模块实现流水线操作,一定程度上均增加了安全加速引擎的硬件逻辑开销。另外,较大的块存储开销则是因为存储了多达128个站点信息的密钥表所导致的。

表1 FPGA综合结果Table 1 Synthesis results by FPGA

AES运算核的运算吞吐率可采用下式进行计算:

式中:lblock为AES算法的分组块大小,单位为比特;φ为AES运算核的平均数据块运算周期数。本文所设计的AES运算核可实现平均11个时钟周期处理一个 128 bit的数据块,此时,lblock为128 bit,φ 为 11。

在中芯国际集成电路(SMIC)55 nm CMOS工艺条件下,采用Design Compiler工具对所设计的安全加速引擎进行了 ASIC综合,最高工作频率为322 MHz,利用式(6)可得运算吞吐率达3.747 Gbit/s。然后,将该安全加速引擎集成于项目组自主研发的一款802.11a/b/g/n/ac协议系统芯片中。最终的芯片测试结果表明,本文所设计的安全加速引擎完全满足802.11i协议要求。

表2给出了本文设计与3个已发表设计的实现性能对比,由于各个设计的功能不尽一致,无法从面积或功耗上做统一的衡量,但从可重构性、密钥查找延迟、块响应延迟和运算吞吐率上进行分析,本文的设计均具备一定的性能优势。

表2 安全加速引擎的实现性能对比Table 2 Implementation performance comparisons of cipher engine

5 结论

本文基于下一代WLAN系统802.11ac对于高吞吐率的需求,设计了一个多模式、高性能的安全加速引擎,同时支持WEP/TKIP/CCMP 3种加解密协议,主要针对密钥信息查找和AES-CCM算法实现进行优化。

1)提出基于Hash算法的改进密钥信息查找算法,大大降低密钥查找的时钟延迟。

2)双AES运算核的并行实现方式,不仅提高了运算的吞吐量,而且减小了处理所需的响应延迟。

3)在可扩展结构、低处理延迟和高运算吞吐率等关键指标上有优异的性能,本文的设计完全满足下一代WLAN系统802.11ac对于安全加速引擎的性能要求。

[1]IEEE Std 802.11i-2004.Part 11:Wireless lAN medium access control(MAC)and physical layer(PHY)specifications amendment 6:Medium access control(MAC)security enhancements[S].New York,USA,2004.

[2]IEEE Std 802.11ac-2013.Part 11:Wireless LAN medium access control(MAC)and physical layer(PHY)specifications amendment 4:enhancements for very high throughput for operation in bands below 6 GHz[S].New York,USA,2013.

[3]TRAN T H,LANANTE L,NAGAO Y,et al.Hardware implementation of high throughput RC4 algorithm[C]//IEEE International Symposium on Circuits and Systems(ISCAS).Seoul,Korea,2012:77-80.

[4]GUPTA S S,CHATTOPADHYAY A,SINHA K,et al.High-performance hardware implementation for RC4 stream cipher[J].IEEE Transactions on Computers,2013,62(4):730-743.

[5]SATOH A,MORIOKA S,TAKANO K,et al.A compact Rijndaelhardware architecture with S-box optimization[C]//Proc ASIACRYPT.Berlin,2000:239-245.

[6]HSIAO S F,CHEN M C,TU C S.Memory-free low-cost designs of advanced encryption standard using common subexpression elimination for subfunctions in transformations[J].IEEE Transactions on Circuits and Systems,2006,53(3):615-626.

[7]WONG M M,WONG M L D,NANDI A K,et al.Construction of optimum composite field architecture for compact high-throughput AES S-boxes[J].IEEE Transactions on Very Large Scale Integration(VLSI)Systems,2012,20(6):1151-1155.

[8]BAE D,KIM G,KIM J,et al.Design and Implementation of efficient cipher engine for IEEE 802.11i compatible with IEEE 802.11n and IEEE 802.11e[J].Lecture Notes in Computer Science,2005,3802:439-444.

[9]JAIN R.A comparison of hashing schemes for address lookup in computer networks[J].IEEE Transactions on Communications,1992,40(10):1570-1573.

[10]BAE D,KIM G,KIM J,et al.An efficient design of CCMP for robust security network[C]//Information Security and Cryptology(ICISC).Busan,Korea,2006:352-361.

[11]GNACIO A B,CLAUDIA F U,RENE C,et al.Efficient hardware architecture for the AES-CCM protocol of the IEEE 802.11i standard[J].Computers and Electrical Engineering,2010,36:565-577.

[12]SMYTH N,MCLOONE M,MCCANNY J.WLAN security processor[J].IEEE Transactions on Circuits and Systems,2006,53(7):1506-1520.

猜你喜欢

加解密引擎密钥
幻中邂逅之金色密钥
新海珠,新引擎,新活力!
密码系统中密钥的状态与保护*
TPM 2.0密钥迁移协议研究
三生 三大引擎齐发力
一种对称密钥的密钥管理方法及系统
蓝谷: “涉蓝”新引擎
电子取证中常见数据加解密理论与方法研究
网络数据传输的加解密系统研究
One Engine Left只剩下一个引擎