面向物联网设备的SM4-CCM算法软硬件协同架构设计

摘 要：为了保证物联网设备数据安全，面向资源受限的物联网设备，提出了一种基于SM4-CCM算法的软硬件协同实现架构。首先，提出了内部流水线型SM4架构，相比现有轻量级SM4架构，大幅降低了逻辑资源的消耗；在此基础上，设计了CCM模式软硬件协同架构，软件部分完成了密钥扩展和数据预处理，硬件部分完成了加密的实际运算；最后，基于ZYNQ平台实现了软硬件协同架构。实验结果表明，与硬件架构相比，所提出的架构硬件部分的逻辑资源消耗减少了约43%，具备接收可变长度的数据输入的数据预处理功能，并可单独应用于ECB和CTR模式，具有更高的灵活性和可扩展性。与ARM处理器上以软件方式实现的SM4-CCM算法相比，在100 MHz的工作频率下该架构的吞吐率达到了17.64 Mb/s，性能提高了约93.8%，满足了主流物联网通信协议的速率要求。

关键词：物联网；数据安全；SM4-CCM；软硬件协同；ARM；ZYNQ

中图分类号：TP309.7 文献标识码：A 文章编号：2095-1302（2025）01-00-06

0 引 言

物联网（IoT）技术的应用十分广泛，涵盖了众多领域，每个领域中部署的物联网设备数量都非常可观。物联网设备通常使用标准或自定义协议进行通信，以数据包的形式发送数据[1]。这些数据包一般包含机密信息和非机密信息。机密信息大多为包含隐私的敏感数据[2]，应当防止未经授权的读取、修改和伪造。非机密信息包含地址、端口号、协议版本以及处理数据包的其他信息，不需要加密，但需确保不被篡改或者替换。

认证加密算法（AEAD）中，一部分数据被加密，另一部分数据虽然未被加密，但用于整个数据包的真实性和完整性的验证，契合物联网数据包的格式要求。在物联网设备上部署AEAD可确保数据的安全性[3]，而物联网设备大多是资源受限性设备，因此面向物联网设备的AEAD需尽可能占用较少的资源。SM4-GCM和SM4-CCM算法是基于SM4分组密码的AEAD算法，目前已被RFC 8998标准化并广泛使用[4]。相较于SM4-GCM算法，SM4-CCM算法不涉及乘法运算，在资源受限的场景下具有更大优势[5]。SM4-CCM算法在软件实现中资源消耗高且性能低下[6]，在硬件实现中的数据预处理阶段存在实现困难以及灵活性差的问题。因此需要一种低资源消耗、高效率的方法将SM4-CCM算法部署到资源受限的物联网设备中。

文献[7]将SM4-CCM算法划分成不同的层次结构，并组合各层次优化方法，设计了一种能耗低、面积小的SM4-CCM硬件实现架构。文献[8]提出了双SM4加密模块并行实现的SM4-CCM硬件架构，在90.909 MHz的最高工作频率下吞吐率能够达到0.705 Gb/s。在对SM4算法实现架构的研究中，文献[9]提出了4种SM4算法架构，分别应用于不同的场景，其中循环型SM4算法架构消耗193个Slice，吞吐率为1.27 Gb/s。在其他相似研究中，文献[10]面向物联网领域，设计了一个低成本、多功能的SM4-GCM算法硬件架构，消耗604个Slice，在100 MHz的工作频率下能达到39.78 Mb/s的吞吐率。

对以上工作进行分析发现如下问题：

（1）现有的SM4-CCM算法架构大多采用硬件架构，但未充分说明CCM模式中的数据预处理过程。SM4-CCM算法工作前需要对数据进行长度检测、填充数据计算以及分组等操作，这些操作在硬件中实现困难、灵活性差且逻辑资源消耗巨大。

（2）物联网设备大多集成微型CPU[11]，但现有加密算法硬件架构并未与这些CPU进行联合设计开发，这将导致算法架构应用于系统时性能受限，同时会增加系统的开发成本[12]。

为了解决上述问题，本文采用软硬件协同的方法设计了一种面向物联网设备的SM4-CCM算法架构。首先设计了内部流水线型SM4算法架构，并基于此设计了SM4-CCM算法软硬件协同架构，该架构的数据预处理功能更灵活高效、资源占用低且支持多模式，适用于不同安全需求的加密场景，也适用于不同标准规范的CCM模式。

1 SM4-CCM算法原理

1.1 SM4算法原理

SM4算法是中国国家密码管理局发布的商用密码算法之一，已得到多个标准化组织的认可和支持，如ISO、IEC、ITU和GM/T等。SM4算法结构为非平衡Feistel网络结构，采用128位密钥和128位分组长度，加密运算和密钥扩展运算均采用32轮非线性循环迭代结构。

SM4算法结构如图1所示。SM4算法的加密运算与解密运算整体流程相同，加密和解密运算时使用的轮密钥顺序相反。

1.2 CCM模式

CCM（Counter with Cipher Block Chaining-Message Authentication Code）模式是一种组合了CTR（Counter）和CBC-MAC（Cipher Block Chaining Message Authentication Code）的分组密码工作模式，其结构如图2所示。

CCM模式采用128位的输入长度。分组输入数据分为三部分，第一部分B0为初始分组，包含填充完毕的Nonce值；第二部分（B1...Ba）为附加数据分组，关联数据分组长度可为0；第三部分（Ba+1...Bn）为明文数据分组。所有分组按照CBC-MAC模式生成MAC（Message Authentication Code）值，明文数据分组按照CTR模式进行加密得到密文数据。

CCM模式的解密过程与加密过程相似，将待处理数据进行分离，得到密文分组、初始向量分组、关联数据分组以及MAC校验值。根据加密过程中使用的密钥、Nonce值和计数器值，采用CTR模式还原明文数据。最后根据还原的明文数据以及关联数据通过CBC-MAC模式生成MAC校验值，与输入MAC校验值进行比较，以验证消息的真实性和完整性。如果匹配，则还原的明文数据有效，否则无效。

CCM模式目前已广泛应用于802.11、802.15、ZigBee、Bluetooth等通信协议[13]。不同标准定义的CCM模式具有长度不同的Nonce值、关联数据和MAC值。例如RFC 8998中采用12 Byte的Nonce值，而物联网常用的ZigBee协议则采用13 Byte的Nonce值。

2 SM4-CCM硬件架构设计

2.1 SM4轻量级硬件架构

SM4算法是SM4-CCM算法的底层算法，在资源消耗方面，SM4算法消耗资源的占比较大，因此对于SM4算法的轻量级实现有利于降低整个架构的资源消耗。SM4-CCM算法加解密均只需SM4加密，SM4加密需32轮迭代计算，每轮轮函数相同，输入的轮密钥不同。轮函数包含异或、非线性变换以及循环移位等操作。大部分SM4算法的流水线架构是基于轮函数的全流水线型架构[14-15]，此架构将算法按轮函数分解为多个子操作并以此划分流水线级，每个流水线级之间插入寄存器。此架构能大幅提高加解密性能，但硬件资源消耗巨大。本文提出了一种基于SM4算法轮函数的内部流水型架构，能够大幅降低资源消耗，且拥有优异的性能，具体硬件架构如图3所示。

SM4计算部分将轮函数划分成3个子模块，分别进行异或、非线性变换以及线性变换操作。每个模块之间插入寄存器，并添加输入寄存器，共构成5级流水线。实际加密场景中，密钥大多定时更新或基于其他更新策略更新，本架构采用离线储存的方式将轮密钥存储于BRAM中，加密前由PS端计算轮密钥并写入BRAM，避免重复的轮密钥计算。S盒采用双口BRAM实现，并启用BRAM内置的输出寄存器实现加密数据的非线性变换。BRAM本身和内置的输出寄存器提供2级流水线。启用BRAM内置的输出寄存器解决了BRAM延迟输出的时序问题，并且内置寄存器位于BRAM内部，不使用额外的逻辑资源，节省了实现寄存器所需的逻辑资源。流水线型轮函数架构在一个时钟周期内最多可并行处理5个128位数据分组。

该架构的控制部分由控制状态机和移位寄存器组成。其中5个160位移位寄存器，用于跟踪并行的5个数据分组在数据路径中的位置。当数据分组完成32轮循环迭代时，对应移位寄存器的输出拉高，表示数据分组已完成加密。移位寄存器采用M型Slice片中的LUT实现，此类型LUT具有时钟输入，可用作32位移位寄存器[16]。每个移位寄存器消耗5个LUT资源，而不需要任何触发器。计数器用于跟踪每个数据块所处的迭代轮数，以此控制输入对应轮密钥参与运算。

2.2 基于内部流水线型SM4算法架构的CCM架构

大多CCM模式采用调用两个底层密码模块并行运行实现加解密[17]，为了降低CCM模式的资源消耗，本文基于内部流水线型SM4算法架构，设计了单个SM4加密模块串行调用的CCM架构。SM4-CCM硬件架构如图4所示。

该架构包含AXI4数据接口、多个寄存器、计数器、SM4模块、多路选择器和控制状态机。在此架构中，控制状态机由Mealy型状态机构成，负责数据的输入输出、SM4模块使能和整体工作流程的控制。控制状态机的状态跳转如图5所示。其工作过程如下：

（1）当接收到mode_sel信号为3’b001时，状态机由IDLE状态跳转到ENCODE_IV_CCM状态。此状态下，系统会对分组进行处理，并将分组的加密结果写入至MAC中间值寄存器。处理完成后flag值拉高为1表示处理完成。

（2）" 当接收到mode_sel信号为3’b010且flag值为1时，状态机跳转至ENCODE_ADD_CCM状态。此状态下，系统会对关联数据分组进行处理。每完成一个关联数据分组的SM4加密，其加密结果会被即时更新至MAC中间值校验值寄存器中。flag值在进入新状态时清零，每个状态处理完成后拉高。

（3）当接收到mode_sel信号为3’b011且flag值为1时，状态机跳转至ENCODE_P_CCM状态。此状态下，系统开始对明文数据分组进行处理，SM4模块对计数器值进行加密，一次最大支持生成640 bit的密钥流，密钥流与明文进行异或运算生成密文并写入密文寄存器。同时每组明文数据与MAC中间值进行异或运算作为SM4模块的输入，加密结果刷新MAC中间值校验值寄存器。处理完成后flag值拉高。

（4）" 当接收到mode_sel信号为3’b100且flag值为1时，状态机跳转至GET_MAC状态。此状态下，SM4模块对计数器初始值进行加密，加密结果与MAC中间值进行异或运算得到最终MAC校验值并写入MAC值寄存器。

2.3 基于内部流水线型SM4算法架构的多模式架构

为应对不同场景的加密需求，提高本架构的适用性，本文提出的SM4-CCM架构另支持ECB和CTR模式。ECB和CTR模式的状态跳转在图5中表示。状态机在IDLE状态下接收到mode_sel信号为3’b101时，跳转至ENCODE_CTR状态，架构工作于SM4-CTR模式。此时SM4模块的输入为计数器值，产生的密钥流与明文分组直接进行异或运算后生成密文并写入密文寄存器；状态机在IDLE状态下接收到mode_sel信号为3’b110时，跳转至ENCODE_ECB状态，架构工作于SM4-ECB模式。此时明文分组直接输入至SM4模块进行加密，加密结果直接写入密文寄存器。无论在哪种状态下，只要所有数据分组加密完成，flag值即拉高，状态机跳转回IDLE状态，等待下一次的加密。

3 软硬件协同架构设计

SM4-CCM算法的完整加密过程包括数据预处理、密钥扩展、数据传输、加密运算。PS端主要负责数据预处理、密钥扩展、数据传输和加解密流程控制。加解密前，PS端根据128 bit主密钥提前计算完成32组轮密钥，轮密钥通过AXI-lite总线写入PL端的BRAM中，PL端工作时直接读取BRAM中的轮密钥进行计算。实际加密场景中密钥更新相对于加密操作并不频繁，在PS端实现密钥扩展，避免了在每次加解密中进行轮密钥的重复计算，有效提高了架构的整体性能。

数据预处理是确保加密和认证正确性的关键步骤，主要包括长度检测、填充数据计算、数据分组等过程。首先对输入数据的各部分进行长度检测，得到Nonce长度、关联数据长度、明文数据长度。随后进行填充数据计算，以标准802.11定义的CCM模式的规范举例说明，Nonce数据长度为13 Byte，须在Nonce头部填充1 Byte的控制信息，该字节的内容为MAC校验值的长度和Nonce数据长度信息。Nonce后3 Byte也需要填充，填充数据为明文数据长度的十六进制表现。Nonce值填充后长度为16 Byte，作为第一个数据分组。

对于关联数据，关联数据头部需填充2 Byte的十六进制数用于表示关联数据的长度，标准802.11定义的CCM模式采用的关联数据长度在22 Byte和30 Byte之间，则填充数据为十六进制数0016至001E。对填充完毕后的关联数据进行长度检测，若长度不是16 Byte的整数倍，则在关联数据后补0，使其长度为16 Byte的整数倍，随后按16 Byte长度将关联数据分为（B1...Ba）组。类似地，若明文数据长度不是16 Byte的整数倍，则在尾部补0，使其长度为16 Byte的整数倍，随后按16 Byte长度将明文数据分为（Ba+1...Bn）组。

各个标准使用的CCM模式针对不同长度的Nonce和关联数据，采用硬件实现数据预处理步骤，在处理位宽上更为直接，但硬件描述中需要明确定义数据的位宽，面对不同长度的数据时缺乏灵活性且后期维护困难。因此为了使得本架构适用性更高，本文采用PS端以软件实现CCM模式的数据预处理，提供了更多的灵活性，使得本架构在面对不同的加密场景时能够灵活配置相关数据的长度，提高本架构应用于不同协议的CCM模式的扩展性。

完成密钥扩展和数据预处理后，PS端控制与PL端的数据传输和PL端的工作流程。PS端通过AXI-lite总线依次向PL端传输数据分组以及控制PL端IP核的工作模式的控制字，通过AXI-lite总线接收数据并组合生成最终的密文和MAC校验值。

4 架构测试和分析

4.1 资源消耗分析

在硬件部分实现过程中，首先实现内部流水线型SM4算法轻量级架构，再封装CCM模式顶层模块，采用Verilog HDL对架构进行描述，使用软件Vivado2018.2进行仿真验证和性能评估，开发平台选用ZYNQ-7020，芯片型号为xc7z020clg484-1。本文架构硬件部分的资源消耗和性能情况见表1。

本文提出的内部流水线型SM4架构仅需消耗132个Slice。SM4算法下硬件部分单独工作时，最大工作频率能达到289 MHz，吞吐率能达到1.12 Gb/s。SM4-CCM算法架构的硬件部分消耗651个Slice；硬件部分单独工作时，最大工作频率能达到145 MHz，吞吐率能达到0.74 Gb/s。

软件部分对CCM模式的密钥扩展以及数据预处理部分采用C语言实现，通过对程序编译后的text、data、bss字段的记录，得到软件部分内存占用情况见表2。

针对物联网设备大多资源受限，而对于性能要求相对较低的特点[18]，本文在SM4-CCM软硬件协同架构的设计过程中主要关注其资源消耗情况。本文提出的架构逻辑资源消耗较低，适用于资源受限的物联网设备。

4.2 软硬件协同功能验证及性能分析

为了对本文提出的软硬件协同架构进行功能验证，首先将SM4-CCM算法架构硬件部分封装为硬件IP核，由PS端直接调用。PL端部分工作频率设置为100 MHz，PS端CPU工作频率设置为100 MHz。本文软硬件协同架构采用ZYNQ SoC系统实现，系统架构如图6所示。利用RFC 8998提供的CCM模式测试数据进行一次功能测试，程序运行结果通过UART串口在SDK terminal进行打印，打印结果如图7所示，结果表明功能验证正确。

为了对本文提出的软硬件协同架构的性能进行分析，本文使用C语言对SM4-CCM算法进行软件实现，分别调用ZYNQ的ARM处理器和PC端的CPU对测试数据循环加密10 000次并记录运行时间。另采用本文架构对相同测试数据进行10 000次循环加密，运行时间由XTime_GetTime系统函数记录。架构软件部分性能情况见表3。

分析表3可得，在100 MHz工作频率下，本文提出的SM4-CCM软硬件协同架构对测试数据进行一次加密需要约5.805 μs，因此估算吞吐率为17.64 Mb/s。与在ARM处理器上以软件方式实现的SM4-CCM算法相比，本文架构的性能提高了约93.8%。与在PC端以软件方式实现的SM4-CCM算法相比，本文的架构仅以PC端4%的工作频率，达到了其性能的约21%。物联网设备常用的通信协议如NB-IoT、ZigBee和LoRa等，传输速率最高为每秒数百千比特[19]，本文架构提供的吞吐率已满足主流物联网通信协议的速率要求。

4.3 现有架构对比

不同架构的资源消耗与性能对比见表4。由表4可知，对比文献[8]的架构，本文架构硬件部分减少了约43%的资源消耗，但文献[8]未充分说明数据预处理过程，在不考虑数据输入的情况下，本文架构硬件部分性能更加优异。本文架构在数据预处理方面更加灵活，支持不同长度Nonce和关联数据的CCM模式，为后续SM4-CCM算法应用于其他协议提供可能。对比文献[10]，本文架构虽然资源消耗和性能不具优势，但本文架构支持CCM、CTR和ECB模式，适用性更高，安全性更高。文献[20]在资源消耗和性能上稍具优势，但是文献[20]同样未充分说明数据预处理过程，且只支持固定长度的关联数据和Nonce值，相比之下本文架构具备更高的灵活性。

5 结 语

基于软硬件协同的方法，设计适用于资源受限的物联网设备的SM4-CCM算法架构。本文首先设计了内部流水线型SM4架构，较现有的SM4轻量级架构，资源消耗更低，硬件性能优异。其次基于SM4架构设计了CCM模式架构，硬件部分较现有工作在资源消耗以及性能方面有明显优势。最后划分了软硬件功能，并基于ZYNQ-7020实现了SM4-CCM软硬件协同架构。实验结果表明，与硬件实现架构相比，SM4-CCM算法的软硬件协同架构的硬件部分资源消耗更小，且在数据预处理方面灵活性更高，并支持ECB、CTR模式单独使用，增加了SM4算法应用于多种场景的灵活性和可扩展性；与软件实现相比，SM4-CCM算法的软硬件协同架构具有更优异的性能表现，能够满足主流物联网通信协议的数据传输速率要求。本文所提出的架构可直接用于物联网安全专用芯片或片上系统的设计与实现。

注：本文通讯作者为何乐生。

参考文献

[1] MADUREIRA A L R， ARAUJO F R C， SAMPAIO L N. On supporting IoT data aggregation through programmable data planes [J]. Computer networks， 2020， 177： 107330.

[2] SADEGHI A R， WACHSMANN C， WAIDNER M. Security and privacy challenges in industrial Internet of Things [C]//Proceedings of the 52nd Annual Design Automation Conference. San Francisco， CA， USA： ACM， 2015.

[3] RANDHAWA R H， HAMEED A， MIAN A N. Energy efficient cross-layer approach for object security of CoAP for IoT devices [J]. Ad hoc networks， 2019， 92： 101761.

[4] YANG P. RFC 8998 ShangMi （SM） Cipher Suites for TLS 1.3 [EB/OL]. （2021-03-10）. https：//datatracker.ietf.org/doc/rfc8998/.

[5] SZALACHOWSKI P， KSIEZOPOLSKI B， KOTULSKI Z. CMAC， CCM and GCM/GMAC： Advanced modes of operation of symmetric block ciphers in wireless sensor networks [J]. Information processing letters， 2010， 110（7）： 247-251.

[6] 王凯，刘凯，李拓，等.可重构高速数据加密系统设计和实现[J].电子测量技术，2021，44（19）：8-15.

[7] CHEN R， LI B. Exploration of the high-efficiency hardware architecture of SM4-CCM for IoT applications [J]. Electronics， 2022， 11（6）： 935.

[8] TSANTUKIDOU K， SKLAVOS N. Flexible security and privacy， system architecture for IoT， in healthcare [C]//2022 IFIP/IEEE 30th International Conference on Very Large Scale Integration （VLSI-SoC）.Patras， Greece： IEEE， 2022.

[9] 何诗洋，李晖，李凤华. SM4算法的FPGA优化实现方法[J].西安电子科技大学学报，2021，48（3）：155-162.

[10] 陈锐，李春强.认证加密算法SM4-GCM的低成本硬件架构设计与实现[J].物联网学报，2023，7（4）：168-179.

[11] SOVYN Y， KHOMA V， PODPORA M. Comparison of three CPU-core families for IoT applications in terms of security and performance of AES-GCM [J]. IEEE internet of things journal， 2019， 7（1）： 339-348.

[12] CHEN D， CONG J， GURUMANI S， et al. Platform choices and design demands for IoT platforms： cost， power， and performance tradeoffs [J]. IET cyber-physical systems： theory amp; applications， 2016， 1（1）： 70-77.

[13] DRAGOMIR D， GHEORGHE L， COSTEA S， et al. A survey on secure communication protocols for IoT systems [C]//2016 International Workshop on Secure Internet of Things （SIoT）. Heraklion， Greece： IEEE， 2016.

[14] GRYCEL J T， WALLS R J. DRAB-LOCUS： An area-efficient AES architecture for hardware accelerator co-location on FPGAs [C]//2020 IEEE International Symposium on Circuits and Systems （ISCAS）. Seville， Spain： IEEE， 2020： 1-5.

[15] 窦玉超. SM4算法优化及其密钥扩展算法的设计与实现[D].哈尔滨：哈尔滨工业大学，2021.

[16] XILINX. 7 series FPGAs configurable logic block user guide [DB/OL]. https：//docs.xilinx.com/v/u/en-US/ug474_7Series_CLB， 2016.

[17] 崔超，赵云，肖勇，等. AES-CCM通用协处理器的优化设计实现[J].密码学报，2021，8（5）：834-843.

[18] REZVANI B， COLEMAN F， SACHIN S， et al. Hardware implementations of NIST lightweight cryptographic candidates： A first look [J]. Cryptology ePrint archive， 2019： 824.

[19] SINHA R S， WEI Y Q， HWANG S H. A survey on LPWA technology： LoRa and NB-IoT[J]. ICT express， 2017， 3（1）： 14-21.

[20] 缪光耀，王磊，于哲，等. SM4算法CTR模式的低开销实现[J].信息技术与信息化，2023（5）：144-148.