摘 要：為了保證物聯(lián)網(wǎng)設(shè)備數(shù)據(jù)安全，面向資源受限的物聯(lián)網(wǎng)設(shè)備，提出了一種基于SM4-CCM算法的軟硬件協(xié)同實現(xiàn)架構(gòu)。首先，提出了內(nèi)部流水線型SM4架構(gòu)，相比現(xiàn)有輕量級SM4架構(gòu)，大幅降低了邏輯資源的消耗；在此基礎(chǔ)上，設(shè)計了CCM模式軟硬件協(xié)同架構(gòu)，軟件部分完成了密鑰擴展和數(shù)據(jù)預(yù)處理，硬件部分完成了加密的實際運算；最后，基于ZYNQ平臺實現(xiàn)了軟硬件協(xié)同架構(gòu)。實驗結(jié)果表明，與硬件架構(gòu)相比，所提出的架構(gòu)硬件部分的邏輯資源消耗減少了約43%，具備接收可變長度的數(shù)據(jù)輸入的數(shù)據(jù)預(yù)處理功能，并可單獨應(yīng)用于ECB和CTR模式，具有更高的靈活性和可擴展性。與ARM處理器上以軟件方式實現(xiàn)的SM4-CCM算法相比，在100 MHz的工作頻率下該架構(gòu)的吞吐率達到了17.64 Mb/s，性能提高了約93.8%，滿足了主流物聯(lián)網(wǎng)通信協(xié)議的速率要求。

關(guān)鍵詞：物聯(lián)網(wǎng)；數(shù)據(jù)安全；SM4-CCM；軟硬件協(xié)同；ARM；ZYNQ

中圖分類號：TP309.7 文獻標(biāo)識碼：A 文章編號：2095-1302（2025）01-00-06

0 引 言

物聯(lián)網(wǎng)（IoT）技術(shù)的應(yīng)用十分廣泛，涵蓋了眾多領(lǐng)域，每個領(lǐng)域中部署的物聯(lián)網(wǎng)設(shè)備數(shù)量都非?？捎^。物聯(lián)網(wǎng)設(shè)備通常使用標(biāo)準(zhǔn)或自定義協(xié)議進行通信，以數(shù)據(jù)包的形式發(fā)送數(shù)據(jù)[1]。這些數(shù)據(jù)包一般包含機密信息和非機密信息。機密信息大多為包含隱私的敏感數(shù)據(jù)[2]，應(yīng)當(dāng)防止未經(jīng)授權(quán)的讀取、修改和偽造。非機密信息包含地址、端口號、協(xié)議版本以及處理數(shù)據(jù)包的其他信息，不需要加密，但需確保不被篡改或者替換。

認(rèn)證加密算法（AEAD）中，一部分?jǐn)?shù)據(jù)被加密，另一部分?jǐn)?shù)據(jù)雖然未被加密，但用于整個數(shù)據(jù)包的真實性和完整性的驗證，契合物聯(lián)網(wǎng)數(shù)據(jù)包的格式要求。在物聯(lián)網(wǎng)設(shè)備上部署AEAD可確保數(shù)據(jù)的安全性[3]，而物聯(lián)網(wǎng)設(shè)備大多是資源受限性設(shè)備，因此面向物聯(lián)網(wǎng)設(shè)備的AEAD需盡可能占用較少的資源。SM4-GCM和SM4-CCM算法是基于SM4分組密碼的AEAD算法，目前已被RFC 8998標(biāo)準(zhǔn)化并廣泛使用[4]。相較于SM4-GCM算法，SM4-CCM算法不涉及乘法運算，在資源受限的場景下具有更大優(yōu)勢[5]。SM4-CCM算法在軟件實現(xiàn)中資源消耗高且性能低下[6]，在硬件實現(xiàn)中的數(shù)據(jù)預(yù)處理階段存在實現(xiàn)困難以及靈活性差的問題。因此需要一種低資源消耗、高效率的方法將SM4-CCM算法部署到資源受限的物聯(lián)網(wǎng)設(shè)備中。

文獻[7]將SM4-CCM算法劃分成不同的層次結(jié)構(gòu)，并組合各層次優(yōu)化方法，設(shè)計了一種能耗低、面積小的SM4-CCM硬件實現(xiàn)架構(gòu)。文獻[8]提出了雙SM4加密模塊并行實現(xiàn)的SM4-CCM硬件架構(gòu)，在90.909 MHz的最高工作頻率下吞吐率能夠達到0.705 Gb/s。在對SM4算法實現(xiàn)架構(gòu)的研究中，文獻[9]提出了4種SM4算法架構(gòu)，分別應(yīng)用于不同的場景，其中循環(huán)型SM4算法架構(gòu)消耗193個Slice，吞吐率為1.27 Gb/s。在其他相似研究中，文獻[10]面向物聯(lián)網(wǎng)領(lǐng)域，設(shè)計了一個低成本、多功能的SM4-GCM算法硬件架構(gòu)，消耗604個Slice，在100 MHz的工作頻率下能達到39.78 Mb/s的吞吐率。

對以上工作進行分析發(fā)現(xiàn)如下問題：

（1）現(xiàn)有的SM4-CCM算法架構(gòu)大多采用硬件架構(gòu)，但未充分說明CCM模式中的數(shù)據(jù)預(yù)處理過程。SM4-CCM算法工作前需要對數(shù)據(jù)進行長度檢測、填充數(shù)據(jù)計算以及分組等操作，這些操作在硬件中實現(xiàn)困難、靈活性差且邏輯資源消耗巨大。

（2）物聯(lián)網(wǎng)設(shè)備大多集成微型CPU[11]，但現(xiàn)有加密算法硬件架構(gòu)并未與這些CPU進行聯(lián)合設(shè)計開發(fā)，這將導(dǎo)致算法架構(gòu)應(yīng)用于系統(tǒng)時性能受限，同時會增加系統(tǒng)的開發(fā)成本[12]。

為了解決上述問題，本文采用軟硬件協(xié)同的方法設(shè)計了一種面向物聯(lián)網(wǎng)設(shè)備的SM4-CCM算法架構(gòu)。首先設(shè)計了內(nèi)部流水線型SM4算法架構(gòu)，并基于此設(shè)計了SM4-CCM算法軟硬件協(xié)同架構(gòu)，該架構(gòu)的數(shù)據(jù)預(yù)處理功能更靈活高效、資源占用低且支持多模式，適用于不同安全需求的加密場景，也適用于不同標(biāo)準(zhǔn)規(guī)范的CCM模式。

1 SM4-CCM算法原理

1.1 SM4算法原理

SM4算法是中國國家密碼管理局發(fā)布的商用密碼算法之一，已得到多個標(biāo)準(zhǔn)化組織的認(rèn)可和支持，如ISO、IEC、ITU和GM/T等。SM4算法結(jié)構(gòu)為非平衡Feistel網(wǎng)絡(luò)結(jié)構(gòu)，采用128位密鑰和128位分組長度，加密運算和密鑰擴展運算均采用32輪非線性循環(huán)迭代結(jié)構(gòu)。

SM4算法結(jié)構(gòu)如圖1所示。SM4算法的加密運算與解密運算整體流程相同，加密和解密運算時使用的輪密鑰順序相反。

1.2 CCM模式

CCM（Counter with Cipher Block Chaining-Message Authentication Code）模式是一種組合了CTR（Counter）和CBC-MAC（Cipher Block Chaining Message Authentication Code）的分組密碼工作模式，其結(jié)構(gòu)如圖2所示。

CCM模式采用128位的輸入長度。分組輸入數(shù)據(jù)分為三部分，第一部分B0為初始分組，包含填充完畢的Nonce值；第二部分（B1...Ba）為附加數(shù)據(jù)分組，關(guān)聯(lián)數(shù)據(jù)分組長度可為0；第三部分（Ba+1...Bn）為明文數(shù)據(jù)分組。所有分組按照CBC-MAC模式生成MAC（Message Authentication Code）值，明文數(shù)據(jù)分組按照CTR模式進行加密得到密文數(shù)據(jù)。

CCM模式的解密過程與加密過程相似，將待處理數(shù)據(jù)進行分離，得到密文分組、初始向量分組、關(guān)聯(lián)數(shù)據(jù)分組以及MAC校驗值。根據(jù)加密過程中使用的密鑰、Nonce值和計數(shù)器值，采用CTR模式還原明文數(shù)據(jù)。最后根據(jù)還原的明文數(shù)據(jù)以及關(guān)聯(lián)數(shù)據(jù)通過CBC-MAC模式生成MAC校驗值，與輸入MAC校驗值進行比較，以驗證消息的真實性和完整性。如果匹配，則還原的明文數(shù)據(jù)有效，否則無效。

CCM模式目前已廣泛應(yīng)用于802.11、802.15、ZigBee、Bluetooth等通信協(xié)議[13]。不同標(biāo)準(zhǔn)定義的CCM模式具有長度不同的Nonce值、關(guān)聯(lián)數(shù)據(jù)和MAC值。例如RFC 8998中采用12 Byte的Nonce值，而物聯(lián)網(wǎng)常用的ZigBee協(xié)議則采用13 Byte的Nonce值。

2 SM4-CCM硬件架構(gòu)設(shè)計

2.1 SM4輕量級硬件架構(gòu)

SM4算法是SM4-CCM算法的底層算法，在資源消耗方面，SM4算法消耗資源的占比較大，因此對于SM4算法的輕量級實現(xiàn)有利于降低整個架構(gòu)的資源消耗。SM4-CCM算法加解密均只需SM4加密，SM4加密需32輪迭代計算，每輪輪函數(shù)相同，輸入的輪密鑰不同。輪函數(shù)包含異或、非線性變換以及循環(huán)移位等操作。大部分SM4算法的流水線架構(gòu)是基于輪函數(shù)的全流水線型架構(gòu)[14-15]，此架構(gòu)將算法按輪函數(shù)分解為多個子操作并以此劃分流水線級，每個流水線級之間插入寄存器。此架構(gòu)能大幅提高加解密性能，但硬件資源消耗巨大。本文提出了一種基于SM4算法輪函數(shù)的內(nèi)部流水型架構(gòu)，能夠大幅降低資源消耗，且擁有優(yōu)異的性能，具體硬件架構(gòu)如圖3所示。

SM4計算部分將輪函數(shù)劃分成3個子模塊，分別進行異或、非線性變換以及線性變換操作。每個模塊之間插入寄存器，并添加輸入寄存器，共構(gòu)成5級流水線。實際加密場景中，密鑰大多定時更新或基于其他更新策略更新，本架構(gòu)采用離線儲存的方式將輪密鑰存儲于BRAM中，加密前由PS端計算輪密鑰并寫入BRAM，避免重復(fù)的輪密鑰計算。S盒采用雙口BRAM實現(xiàn)，并啟用BRAM內(nèi)置的輸出寄存器實現(xiàn)加密數(shù)據(jù)的非線性變換。BRAM本身和內(nèi)置的輸出寄存器提供2級流水線。啟用BRAM內(nèi)置的輸出寄存器解決了BRAM延遲輸出的時序問題，并且內(nèi)置寄存器位于BRAM內(nèi)部，不使用額外的邏輯資源，節(jié)省了實現(xiàn)寄存器所需的邏輯資源。流水線型輪函數(shù)架構(gòu)在一個時鐘周期內(nèi)最多可并行處理5個128位數(shù)據(jù)分組。

該架構(gòu)的控制部分由控制狀態(tài)機和移位寄存器組成。其中5個160位移位寄存器，用于跟蹤并行的5個數(shù)據(jù)分組在數(shù)據(jù)路徑中的位置。當(dāng)數(shù)據(jù)分組完成32輪循環(huán)迭代時，對應(yīng)移位寄存器的輸出拉高，表示數(shù)據(jù)分組已完成加密。移位寄存器采用M型Slice片中的LUT實現(xiàn)，此類型LUT具有時鐘輸入，可用作32位移位寄存器[16]。每個移位寄存器消耗5個LUT資源，而不需要任何觸發(fā)器。計數(shù)器用于跟蹤每個數(shù)據(jù)塊所處的迭代輪數(shù)，以此控制輸入對應(yīng)輪密鑰參與運算。

2.2 基于內(nèi)部流水線型SM4算法架構(gòu)的CCM架構(gòu)

大多CCM模式采用調(diào)用兩個底層密碼模塊并行運行實現(xiàn)加解密[17]，為了降低CCM模式的資源消耗，本文基于內(nèi)部流水線型SM4算法架構(gòu)，設(shè)計了單個SM4加密模塊串行調(diào)用的CCM架構(gòu)。SM4-CCM硬件架構(gòu)如圖4所示。

該架構(gòu)包含AXI4數(shù)據(jù)接口、多個寄存器、計數(shù)器、SM4模塊、多路選擇器和控制狀態(tài)機。在此架構(gòu)中，控制狀態(tài)機由Mealy型狀態(tài)機構(gòu)成，負(fù)責(zé)數(shù)據(jù)的輸入輸出、SM4模塊使能和整體工作流程的控制。控制狀態(tài)機的狀態(tài)跳轉(zhuǎn)如圖5所示。其工作過程如下：

（1）當(dāng)接收到mode_sel信號為3’b001時，狀態(tài)機由IDLE狀態(tài)跳轉(zhuǎn)到ENCODE_IV_CCM狀態(tài)。此狀態(tài)下，系統(tǒng)會對分組進行處理，并將分組的加密結(jié)果寫入至MAC中間值寄存器。處理完成后flag值拉高為1表示處理完成。

（2）" 當(dāng)接收到mode_sel信號為3’b010且flag值為1時，狀態(tài)機跳轉(zhuǎn)至ENCODE_ADD_CCM狀態(tài)。此狀態(tài)下，系統(tǒng)會對關(guān)聯(lián)數(shù)據(jù)分組進行處理。每完成一個關(guān)聯(lián)數(shù)據(jù)分組的SM4加密，其加密結(jié)果會被即時更新至MAC中間值校驗值寄存器中。flag值在進入新狀態(tài)時清零，每個狀態(tài)處理完成后拉高。

（3）當(dāng)接收到mode_sel信號為3’b011且flag值為1時，狀態(tài)機跳轉(zhuǎn)至ENCODE_P_CCM狀態(tài)。此狀態(tài)下，系統(tǒng)開始對明文數(shù)據(jù)分組進行處理，SM4模塊對計數(shù)器值進行加密，一次最大支持生成640 bit的密鑰流，密鑰流與明文進行異或運算生成密文并寫入密文寄存器。同時每組明文數(shù)據(jù)與MAC中間值進行異或運算作為SM4模塊的輸入，加密結(jié)果刷新MAC中間值校驗值寄存器。處理完成后flag值拉高。

（4）" 當(dāng)接收到mode_sel信號為3’b100且flag值為1時，狀態(tài)機跳轉(zhuǎn)至GET_MAC狀態(tài)。此狀態(tài)下，SM4模塊對計數(shù)器初始值進行加密，加密結(jié)果與MAC中間值進行異或運算得到最終MAC校驗值并寫入MAC值寄存器。

2.3 基于內(nèi)部流水線型SM4算法架構(gòu)的多模式架構(gòu)

為應(yīng)對不同場景的加密需求，提高本架構(gòu)的適用性，本文提出的SM4-CCM架構(gòu)另支持ECB和CTR模式。ECB和CTR模式的狀態(tài)跳轉(zhuǎn)在圖5中表示。狀態(tài)機在IDLE狀態(tài)下接收到mode_sel信號為3’b101時，跳轉(zhuǎn)至ENCODE_CTR狀態(tài)，架構(gòu)工作于SM4-CTR模式。此時SM4模塊的輸入為計數(shù)器值，產(chǎn)生的密鑰流與明文分組直接進行異或運算后生成密文并寫入密文寄存器；狀態(tài)機在IDLE狀態(tài)下接收到mode_sel信號為3’b110時，跳轉(zhuǎn)至ENCODE_ECB狀態(tài)，架構(gòu)工作于SM4-ECB模式。此時明文分組直接輸入至SM4模塊進行加密，加密結(jié)果直接寫入密文寄存器。無論在哪種狀態(tài)下，只要所有數(shù)據(jù)分組加密完成，flag值即拉高，狀態(tài)機跳轉(zhuǎn)回IDLE狀態(tài)，等待下一次的加密。

3 軟硬件協(xié)同架構(gòu)設(shè)計

SM4-CCM算法的完整加密過程包括數(shù)據(jù)預(yù)處理、密鑰擴展、數(shù)據(jù)傳輸、加密運算。PS端主要負(fù)責(zé)數(shù)據(jù)預(yù)處理、密鑰擴展、數(shù)據(jù)傳輸和加解密流程控制。加解密前，PS端根據(jù)128 bit主密鑰提前計算完成32組輪密鑰，輪密鑰通過AXI-lite總線寫入PL端的BRAM中，PL端工作時直接讀取BRAM中的輪密鑰進行計算。實際加密場景中密鑰更新相對于加密操作并不頻繁，在PS端實現(xiàn)密鑰擴展，避免了在每次加解密中進行輪密鑰的重復(fù)計算，有效提高了架構(gòu)的整體性能。

數(shù)據(jù)預(yù)處理是確保加密和認(rèn)證正確性的關(guān)鍵步驟，主要包括長度檢測、填充數(shù)據(jù)計算、數(shù)據(jù)分組等過程。首先對輸入數(shù)據(jù)的各部分進行長度檢測，得到Nonce長度、關(guān)聯(lián)數(shù)據(jù)長度、明文數(shù)據(jù)長度。隨后進行填充數(shù)據(jù)計算，以標(biāo)準(zhǔn)802.11定義的CCM模式的規(guī)范舉例說明，Nonce數(shù)據(jù)長度為13 Byte，須在Nonce頭部填充1 Byte的控制信息，該字節(jié)的內(nèi)容為MAC校驗值的長度和Nonce數(shù)據(jù)長度信息。Nonce后3 Byte也需要填充，填充數(shù)據(jù)為明文數(shù)據(jù)長度的十六進制表現(xiàn)。Nonce值填充后長度為16 Byte，作為第一個數(shù)據(jù)分組。

對于關(guān)聯(lián)數(shù)據(jù)，關(guān)聯(lián)數(shù)據(jù)頭部需填充2 Byte的十六進制數(shù)用于表示關(guān)聯(lián)數(shù)據(jù)的長度，標(biāo)準(zhǔn)802.11定義的CCM模式采用的關(guān)聯(lián)數(shù)據(jù)長度在22 Byte和30 Byte之間，則填充數(shù)據(jù)為十六進制數(shù)0016至001E。對填充完畢后的關(guān)聯(lián)數(shù)據(jù)進行長度檢測，若長度不是16 Byte的整數(shù)倍，則在關(guān)聯(lián)數(shù)據(jù)后補0，使其長度為16 Byte的整數(shù)倍，隨后按16 Byte長度將關(guān)聯(lián)數(shù)據(jù)分為（B1...Ba）組。類似地，若明文數(shù)據(jù)長度不是16 Byte的整數(shù)倍，則在尾部補0，使其長度為16 Byte的整數(shù)倍，隨后按16 Byte長度將明文數(shù)據(jù)分為（Ba+1...Bn）組。

各個標(biāo)準(zhǔn)使用的CCM模式針對不同長度的Nonce和關(guān)聯(lián)數(shù)據(jù)，采用硬件實現(xiàn)數(shù)據(jù)預(yù)處理步驟，在處理位寬上更為直接，但硬件描述中需要明確定義數(shù)據(jù)的位寬，面對不同長度的數(shù)據(jù)時缺乏靈活性且后期維護困難。因此為了使得本架構(gòu)適用性更高，本文采用PS端以軟件實現(xiàn)CCM模式的數(shù)據(jù)預(yù)處理，提供了更多的靈活性，使得本架構(gòu)在面對不同的加密場景時能夠靈活配置相關(guān)數(shù)據(jù)的長度，提高本架構(gòu)應(yīng)用于不同協(xié)議的CCM模式的擴展性。

完成密鑰擴展和數(shù)據(jù)預(yù)處理后，PS端控制與PL端的數(shù)據(jù)傳輸和PL端的工作流程。PS端通過AXI-lite總線依次向PL端傳輸數(shù)據(jù)分組以及控制PL端IP核的工作模式的控制字，通過AXI-lite總線接收數(shù)據(jù)并組合生成最終的密文和MAC校驗值。

4 架構(gòu)測試和分析

4.1 資源消耗分析

在硬件部分實現(xiàn)過程中，首先實現(xiàn)內(nèi)部流水線型SM4算法輕量級架構(gòu)，再封裝CCM模式頂層模塊，采用Verilog HDL對架構(gòu)進行描述，使用軟件Vivado2018.2進行仿真驗證和性能評估，開發(fā)平臺選用ZYNQ-7020，芯片型號為xc7z020clg484-1。本文架構(gòu)硬件部分的資源消耗和性能情況見表1。

本文提出的內(nèi)部流水線型SM4架構(gòu)僅需消耗132個Slice。SM4算法下硬件部分單獨工作時，最大工作頻率能達到289 MHz，吞吐率能達到1.12 Gb/s。SM4-CCM算法架構(gòu)的硬件部分消耗651個Slice；硬件部分單獨工作時，最大工作頻率能達到145 MHz，吞吐率能達到0.74 Gb/s。

軟件部分對CCM模式的密鑰擴展以及數(shù)據(jù)預(yù)處理部分采用C語言實現(xiàn)，通過對程序編譯后的text、data、bss字段的記錄，得到軟件部分內(nèi)存占用情況見表2。

針對物聯(lián)網(wǎng)設(shè)備大多資源受限，而對于性能要求相對較低的特點[18]，本文在SM4-CCM軟硬件協(xié)同架構(gòu)的設(shè)計過程中主要關(guān)注其資源消耗情況。本文提出的架構(gòu)邏輯資源消耗較低，適用于資源受限的物聯(lián)網(wǎng)設(shè)備。

4.2 軟硬件協(xié)同功能驗證及性能分析

為了對本文提出的軟硬件協(xié)同架構(gòu)進行功能驗證，首先將SM4-CCM算法架構(gòu)硬件部分封裝為硬件IP核，由PS端直接調(diào)用。PL端部分工作頻率設(shè)置為100 MHz，PS端CPU工作頻率設(shè)置為100 MHz。本文軟硬件協(xié)同架構(gòu)采用ZYNQ SoC系統(tǒng)實現(xiàn)，系統(tǒng)架構(gòu)如圖6所示。利用RFC 8998提供的CCM模式測試數(shù)據(jù)進行一次功能測試，程序運行結(jié)果通過UART串口在SDK terminal進行打印，打印結(jié)果如圖7所示，結(jié)果表明功能驗證正確。

為了對本文提出的軟硬件協(xié)同架構(gòu)的性能進行分析，本文使用C語言對SM4-CCM算法進行軟件實現(xiàn)，分別調(diào)用ZYNQ的ARM處理器和PC端的CPU對測試數(shù)據(jù)循環(huán)加密10 000次并記錄運行時間。另采用本文架構(gòu)對相同測試數(shù)據(jù)進行10 000次循環(huán)加密，運行時間由XTime_GetTime系統(tǒng)函數(shù)記錄。架構(gòu)軟件部分性能情況見表3。

分析表3可得，在100 MHz工作頻率下，本文提出的SM4-CCM軟硬件協(xié)同架構(gòu)對測試數(shù)據(jù)進行一次加密需要約5.805 μs，因此估算吞吐率為17.64 Mb/s。與在ARM處理器上以軟件方式實現(xiàn)的SM4-CCM算法相比，本文架構(gòu)的性能提高了約93.8%。與在PC端以軟件方式實現(xiàn)的SM4-CCM算法相比，本文的架構(gòu)僅以PC端4%的工作頻率，達到了其性能的約21%。物聯(lián)網(wǎng)設(shè)備常用的通信協(xié)議如NB-IoT、ZigBee和LoRa等，傳輸速率最高為每秒數(shù)百千比特[19]，本文架構(gòu)提供的吞吐率已滿足主流物聯(lián)網(wǎng)通信協(xié)議的速率要求。

4.3 現(xiàn)有架構(gòu)對比

不同架構(gòu)的資源消耗與性能對比見表4。由表4可知，對比文獻[8]的架構(gòu)，本文架構(gòu)硬件部分減少了約43%的資源消耗，但文獻[8]未充分說明數(shù)據(jù)預(yù)處理過程，在不考慮數(shù)據(jù)輸入的情況下，本文架構(gòu)硬件部分性能更加優(yōu)異。本文架構(gòu)在數(shù)據(jù)預(yù)處理方面更加靈活，支持不同長度Nonce和關(guān)聯(lián)數(shù)據(jù)的CCM模式，為后續(xù)SM4-CCM算法應(yīng)用于其他協(xié)議提供可能。對比文獻[10]，本文架構(gòu)雖然資源消耗和性能不具優(yōu)勢，但本文架構(gòu)支持CCM、CTR和ECB模式，適用性更高，安全性更高。文獻[20]在資源消耗和性能上稍具優(yōu)勢，但是文獻[20]同樣未充分說明數(shù)據(jù)預(yù)處理過程，且只支持固定長度的關(guān)聯(lián)數(shù)據(jù)和Nonce值，相比之下本文架構(gòu)具備更高的靈活性。

5 結(jié) 語

基于軟硬件協(xié)同的方法，設(shè)計適用于資源受限的物聯(lián)網(wǎng)設(shè)備的SM4-CCM算法架構(gòu)。本文首先設(shè)計了內(nèi)部流水線型SM4架構(gòu)，較現(xiàn)有的SM4輕量級架構(gòu)，資源消耗更低，硬件性能優(yōu)異。其次基于SM4架構(gòu)設(shè)計了CCM模式架構(gòu)，硬件部分較現(xiàn)有工作在資源消耗以及性能方面有明顯優(yōu)勢。最后劃分了軟硬件功能，并基于ZYNQ-7020實現(xiàn)了SM4-CCM軟硬件協(xié)同架構(gòu)。實驗結(jié)果表明，與硬件實現(xiàn)架構(gòu)相比，SM4-CCM算法的軟硬件協(xié)同架構(gòu)的硬件部分資源消耗更小，且在數(shù)據(jù)預(yù)處理方面靈活性更高，并支持ECB、CTR模式單獨使用，增加了SM4算法應(yīng)用于多種場景的靈活性和可擴展性；與軟件實現(xiàn)相比，SM4-CCM算法的軟硬件協(xié)同架構(gòu)具有更優(yōu)異的性能表現(xiàn)，能夠滿足主流物聯(lián)網(wǎng)通信協(xié)議的數(shù)據(jù)傳輸速率要求。本文所提出的架構(gòu)可直接用于物聯(lián)網(wǎng)安全專用芯片或片上系統(tǒng)的設(shè)計與實現(xiàn)。

注：本文通訊作者為何樂生。

參考文獻

[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] 王凱，劉凱，李拓，等.可重構(gòu)高速數(shù)據(jù)加密系統(tǒng)設(shè)計和實現(xiàn)[J].電子測量技術(shù)，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優(yōu)化實現(xiàn)方法[J].西安電子科技大學(xué)學(xué)報，2021，48（3）：155-162.

[10] 陳銳，李春強.認(rèn)證加密算法SM4-GCM的低成本硬件架構(gòu)設(shè)計與實現(xiàn)[J].物聯(lián)網(wǎng)學(xué)報，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算法優(yōu)化及其密鑰擴展算法的設(shè)計與實現(xiàn)[D].哈爾濱：哈爾濱工業(yè)大學(xué)，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通用協(xié)處理器的優(yōu)化設(shè)計實現(xiàn)[J].密碼學(xué)報，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模式的低開銷實現(xiàn)[J].信息技術(shù)與信息化，2023（5）：144-148.