面向物聯網設備的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模塊使能和整體工作流程的控制?？刂茽顟B機的狀態跳轉如圖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.