The 2020 IEEE Asia Pacific Conference on Circuits and Systems (APCCAS) A Lightweight AEAD encryption core to secure IoT applications Ngo-Doanh Nguyen, Duy-Hieu Bui, Xuan-Tu Tran SISLAB, VNU University of Engineering and Technology, 144 Xuan Thuy road, Cau Giay, Hanoi, Vietnam Corresponding author’s email: hieubd@vnu.edu.vn the most popular mechanisms of AEAD in IoT is the CCM mode with AES encryption because it requires only one AES encryption core Consequently, for highly constrained devices, CCM mode is a right candidate because of its low hardware cost For high-speed data transfer, GCM mode [6] with parallel implementation are the preferred option, but it requires a GHASH function, which increase the complexity of designs AEAD can be also implemented with other AES encryption modes such as OCB, OFB, CBC and yet required an additional decryption circuits which lead to the increase in hardware area Nonetheless, the AES and its relatives are often used in the AEAD setup or data encryption mode For example, the basic data encryption mode such as ECB [7] has been reported in [8]–[12] However, ECB mode is the simplest mode of AES and often not used in real applications In practice, CCM mode [5] is the most widely used in various applications CCM mode is the combination of CBC mode and CTR mode In detail, the CBC mode is used to calculate the Message Authentication Code (MAC) while the CTR mode is for data encryption Both CBC mode and CTR mode are implemented in [13] and [14], but only the key size of 128-bit is coverred Another concern is how the data encryption hardware is connected to the processor because data encryption modules are often used in a System-on-Chip (SoC) The data encryption module with the controller for data encryption mode must be connected through the bus interfaces or connected directly to the processor as the works in [13] and [8] This method can provide very high throughput; however, a special connection to the processor is needed A design with a customized bus interface named Advanced ASBUS protocol is presented in [11] However, this bus protocol is not popular at this time In this paper, we design a lightweight AEAD encryption core using AES algorithm with AXI interfaces to secure IoT applications AXI Interface is widely used in the ARM MCU for IoT and also employed to interface with many opensource RISC-V cores Our AEAD encryption core can provide CCM mode in hardware and GCM mode in the hardware/software co-design setup Besides, it is also capable of operating common data encryption modes such as ECB, CBC, CTR and OFB Our design has been implemented with Pulpino RISC-V core in FPGA and in ASIC with TSMC 65nm technology The design includes a lightweight AES core along with lightweight AXI DMA interface to load the plaintext data and store the encrypted results The proposed design Abstract—The Internet of Things (IoT) with the advancements of many technologies opens a wide range of new applications such as smart appliances, smart cities and smart grids Despite its popularity and usability, it also creates a new attack surface for the hackers especially on highly constrained devices which have limited memory footprints and processing power These constrained devices often use Authenticated Encryption with Associated Data (AEAD) to secure data stored in the devices and transmitted over the network In this work, we design a lightweight data encryption core in hardware with the support for AEAD to secure IoT applications on highly constrained devices The design achieves a low area cost with only 23kGEs in TSMC 65nm technology and an encryption throughput of 123Mbps at 60MHz Index Terms—Software/Hardware Co-design, Advanced Encryption Standard, Advanced eXtensible Interface, Hardware Implementation, Authenticated Encryption with Associated Data I I NTRODUCTION Internet-of-Things (IoT) applications have become more and more popular in recent years The IoT networks using ultra-low-power and ultra-long-range communications such as LoraWan [1] or Sigfox [2] have been deployed in many countries around the world Consequently, it expands IoT applications greatly on the ultra-low-power, low-cost and highlyconstrained devices To cope with the security and privacy issues, many IoT proposals for ultra-low-power constrained devices, such as LoraWan, Sigfox and Z-Wave, use the Authenticated Encryption with Associated Data (AEAD) [3] with Advanced Encryption Standard (AES) [4] as the main algorithm For example, AES with CCM mode [5] is used to secure the data of simple devices transmitted over the network On the other hand, high-speed applications such as the Wifi-enabled ones need the parallelism of GCM However, these encryption mechanisms implemented in software requires large memory footprints and occupied the processing times of MCU which correspondingly reduces the system throughput Therefore, implementing AEAD data encryption scheme in hardware or hardware/software co-design can sharply improve the overall throughput and reduce the power/energy consumption, which are crucial problems for new IoT applications In practice, AEAD is a data encryption mode which ensures the secrecy of the data and its integrity This data is commonly encrypted using standardized algorithms such as AES In fact, 978-1-7281-9396-0/20/$31.00 ©2020 IEEE 35 Authorized licensed use limited to: Univ of Calif Santa Barbara Downloaded on May 15,2021 at 07:02:51 UTC from IEEE Xplore Restrictions apply with the AXI interface occupied only 8.3kGEs for AES core and 23kGEs in total, achieves the encryption throughput of 123Mbps in CCM mode with a power consumption of 0.7mW at the operating frequency of 60MHz The rests of this paper are organized as follows Section II shows the related works which uses various interfaces for AES encryption Our proposal design to secure IoT applications is then described in Section III Section IV presents our hardware implementation results Finally, there are some conclusions and perspectives in Section V CCM and GCM but also other blockcipher modes such as ECB, CBC, CTR and OFB It also has been optimized with a lightweight AXI and DMA interface for loading configuration and encryption data The whole design only costs 23kGEs in TSMC 65nm technology with the encryption throughput of 123Mbps at the frequency of 60MHz III P ROPOSED H ARDWARE A RCHITECTURE We propose the architecture of an AEAD encryption module using 32-bit AXI-bus interface for communication with the processor and the memory in Figure This module can be split into three main components including an AXI Slave Interface to load the key and the configuration for the encryption, a DMA module with an AXI Master Interface to load/store data without the need of the processor, and an encryption controller to manipulate the AES encryption core In this work, we use the 32-bit-datapath AES encryption core in [16], which has a small hardware area footprint of 8.6kGEs with supporting for all the key sizes To perform an AEAD encryption, the processor first sends configurations through AXI Slave Interface to the configured registers in the AES controller The configurations consist of the encryption key, the base address of the formatted plaintext and the associated data, the AES key length and the AEAD mode After that, AES encryption module activates the DMA to request the formatted plaintext data for the AES encryption core At this stage, the AES controller controls the sending of the secret key and the plaintext data to AES encryption module at the same time whenever 128-bit of data is copied successfully through the DMA interface To reduce hardware area, the DMA interface buffers only a block of 128 bits The AES core is activated when all the data for that encryption has been sufficiently transferred to it On the other hand, the DMA can preload the next block for the next encryption while AES core is encrypting At the end of each encryption, the DMA writes the encrypted data directly into the memory based on the configured address The AES encryption core needs 44 clock cycles to encrypt a block of 128 bits with the key size of 128 bits The DMA needs five cycles to transfer the data from memory and to memory in the best case Because the data is preloaded during the AES encryption, therefore, only 49 cycles in total are needed for the AES encryption core, the DMA and the encryption controller to load the input data, encrypt and store the result back into the memory II R ELATED W ORKS Implementing AEAD encryption using the AES algorithm for IoT might require low-cost encryption hardware with ultra-low power consumption Therefore, many works have been focusing on optimizing AES algorithms in hardware For example, Mathew et al [15] focus on 8-bit architecture for low power and low hardware cost, but their design has low throughputs Bui et al [16] optimize the 32-bit datapath architecture, which has low power consumption with high throughputs In this work, we choose the model in [16] to develop our hardware architecture Although optimizing AES encryption core might not be sufficient because it must be properly controlled to perform difference encryption modes Therefore, AEAD core is in charge of utilizing the AES core to support different encryption modes Additionally, AEAD core also has to interface with the software This leads to the need of an interface to communicate the AEAD core with processors For highspeed systems, the encryption core can interface directly with processors using a dedicated connection as the works in [8] and [13] The disadvantage of this method is the requirement to support a special co-processor interface Nonetheless, different architectures might need additional supports for co-processor interfaces A better approach for embedded systems is to design AEAD core with standardized bus interfaces The core can be employed with various processors with different system configurations AMBA bus architecture from ARM is widely used in this area Hodjat et al [13] design the encryption core with AHB Bus with a memory-mapped interface to support high speed system However, this memory-mapped interface requires the processor to write data to the encryption core and read the data back This reduces the system throughput while increases power consumption Cowart et al [14] design many separate encryption cores for different encryption modes using the AXI interface However, this work requires high hardware cost and does not support Direct Memory Access (DMA) The authors in [11] and [10] define their own bus protocols to increase the throughput of the encryption core, but their designs also require high area cost and are not suitable for highly constrained IoT applications In this work, we propose an AEAD encryption core which is able to support a medium throughput with a low area cost using widely-used AXI4 interfaces The proposed design covers not only the common standardized AEAD mode including A AES controller The AES controller is the most important part of AEAD module which controls the AEAD mode The microarchitecture of the AES controller is described in Figure First, the controller receives the configurations from the processor through AXI slave interface In detail, the 32bit configuration, the 256-bit secret key and the 32-bit base memory addresses of data are transferred to AES controller in turn The proposed design supports the key length of 128 bits, 192 bits and 256 bits so that the size of key register needs to 36 Authorized licensed use limited to: Univ of Calif Santa Barbara Downloaded on May 15,2021 at 07:02:51 UTC from IEEE Xplore Restrictions apply / 32 AXI Slave Interface Read Data Address Config Key Size / 32 / 32 / 32 / 32 / 32 AEAD Mode Status Key IV DMA + AES FSM / 32 / 32 / 32 M_AXI Write Data / 32 Operation Modification AES Module Ciphertext IV AES FSM Read Data / 32 AES Status Plaintext CPU Write Data AXI Master Interface RAM ROM S_AXI AXI Slave System Config Regs S_AXI M_AXI AXI BUS AES Encryption Module AXI Master DMA FSM System Configurations AES Controller Encrypted Data Fig The proposed architecture of AEAD encryption module AES Encryptor be maximum On the other hand, the configurations are performed in software running in the processor Our architecture supports the following encryption modes: ECB, CBC-MAC, CTR, OFB, CCM and GCM Moreover, the AES encryption controller is also capable of arranging input data of the AES encryption core and modifying the encrypted data output by XORing with the supported data such as the Initialization Vector (IV) or Nonce according to the selected encryption operation The process of this arrangement is executed in one clock cycle This procedure is explained briefly in the next subsection Fig The architecture of AES controller Software Region Switching to CTR Mode Formatting Data Manipulating Encryption Data Configured System Hardware Region Software Region CBC Mode Storing Auth Tag CTR Mode a) Hardware/software co-design of CCM mode Formatting Data HASH function Manipulating Encryption Data HASH function Configured System CTR Mode B AES operation modes Hardware Region As illustrated in Figure 2, the single-encryption operation modes such as ECB, CBC-MAC, CTR, OFB can be easily handled In fact, the encryption controller operates the XOR at the input of the AES encryption core or the output of the AES encryption core The IV register for CBC, OFB also acts as the counter for the CTR mode to save the hardware area For CCM and GCM operations, which require not only encryption but also authentication, our design splits the process into numerous stages described in Figure In details, the Nonce, associated data, and plaintext are firstly formatted in software These formatted data is accessed by AES controller through the DMA to encrypt data in CCM mode As metioned in Section I, CCM mode is a combination of CBC-MAC method and CTR method Therefore, our architecture for low-cost hardware is designed to use one encryption module processing two encryption rounds The first encryption round uses the CBC-MAC mode on formatted data to generate the authenticated tag Hence, the second one performs the CTR mode to encrypt the data The encrypted data is copied back to the memory using the DMA module While waiting for the AEAD encryption core to finish its tasks, the processor can execute other tasks to improve the overall system performance For GCM mode, the mechanism of encryption is a variation of the CTR mode and it is split into two encryption rounds as the CCM mode The GCM mode is based on a GHASH function, which is the multiplication in binary Galois field As shown in Figure 3, our design initially performs formatting data and calculating the GHASH function in software The first encryption round is then started using the obtained results CTR Mode b) Hardware/software co-design of GCM mode Fig The data flow of processing AEAD mode of GHASH function and produces the ciphertext of the GCM mdoe The processor then performs the next GHASH function on this ciphertext combined with the additional authenticated data to generate new 128-bit formatted data Finally, the authenticated tag is created by encrypting these new data in the CTR mode IV H ARDWARE I MPLEMENTATION R ESULTS The proposed architecture has been modelled in VHDL and implemented in both FPGA and ASIC The encryption results of this architecture are fully verified based on the NIST test vectors (3 types of key sizes and multiple operation modes including ECB, CBC, CTR, OFB, CCM and GCM) For FPGA version, our design connected as an IP with Pulpino platform is simulated and synthesized using Vivado 2017.4 from Xilinx with Arty-a7-100T development kit The same platform is implemented into ASIC using TSMC 65nm process and the memory compiler from ARM Figure shows the area and the power consumption of individual modules in our design The AES encryption core occupies 35% of the area but consumes only 27% of the power consumption The encryption controller ranks the second highest in terms of area and power consumption with 28% in area and 25% in power The DMA with AXI master interface and the AXI Slave Interface take 16%, 17% in area, respectively 37 Authorized licensed use limited to: Univ of Calif Santa Barbara Downloaded on May 15,2021 at 07:02:51 UTC from IEEE Xplore Restrictions apply TABLE I C OMPARISON OF THE PROPOSED DESIGN WITH THE PREVIOUS WORKS Technology Total Area Data Path Frequence (MHz) Throughput (Mbps) Power Consumption (mW) Area Efficiency (Mbits/cycles/ kGEs(kSlices) Power Efficiency (Mbits/cycles/ mW) Bus Interface Modes of Operation [10] FPGA Virtex6 13.2 kSlices 32-bit [12] FPGA ASIC VirtexSCL 0.18um 2.5 53 kSlices kGEs - Encryption controller 28% This work FPGA ASIC TSMC Artix-7 65nm 1.1 23 KSlices kGEs 32-bit 32-bit 216 164.25 200 25 60 730 309.17 376.46 49 123 1277 1369.1 11.9 0.7 0.256 0.752 0.035 1.781 0.089 0.0023 0.0013 0.158 0.142 2.857 Others 2% AES DMA 16% Others, 11% AES Slave IF 17% Encryptio n controller , 25% AES core 37% a) AEAD encryption core’s area by module AES DMA, 23% AES Slave IF, 14% AES core, 27% b) AEAD encryption core’s power by module Fig Area and power distribution by modules of the proposed design ACKNOWLEDGEMENT DBUS APB ECB ECB This research is supported by Ministry of Science and Technology of Vietnam under grant number KC.01.21/16-20 R EFERENCES [1] Lora Alliance, “LoraWan Specification,” 2015 [2] S Technology, “Sigfox technology.” [Online] Available: http://sigfox.com [3] P Rogaway, “Authenticated-encryption with associated-data,” in Proceedings of the 9th ACM Conf on Computer and Communications Security, ser CCS ’02 New York, NY, USA: Association for Computing Machinery, 2002, p 98107 [Online] Available: https://doi.org/10.1145/586110.586125 [4] U.S National Institute of Standards and Technology, “Advanced Encryption Standard,” 2001 [Online] Available: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf [5] M Dworkin, “Recommendation for block cipher modes of operation: the ccm mode for authentication and confidentiality.” [Online] Available: https://csrc.nist.gov/publications/detail/sp/800-38c/final [6] M Dworkin, “Recommendation for block cipher modes of operation: Galois/counter mode (gcm) and gmac.” [Online] Available: https://csrc.nist.gov/publications/detail/sp/800-38d/final [7] M Dworkin, “Recommendation for block cipher modes of operation: Methods and techniques,” 2001 [Online] Available: https://csrc.nist.gov/publications/detail/sp/800-38a/final [8] A Irwansyah, V P Nambiar, and M Khalil-Hani, “An aes tightly coupled hardware accelerator in an fpga-based embedded processor core,” in 2009 ICCET, vol 2, 2009, pp 521–525 [9] A Hodjat and I Verbauwhede, “Interfacing a high speed crypto accelerator to an embedded cpu,” in CRTEAC on Signals, Systems and Computers, 2004., vol 1, 2004, pp 488–492 Vol.1 [10] X Yang and W Wen, “Design of a pre-scheduled data bus for advanced encryption standard encrypted system-on-chips,” in 2017 22nd ASPDAC, 2017, pp 506–511 [11] X Yang, W Wen, and M Fan, “Improving aes core performance via an advanced asbus protocol,” J Emerg Technol Comput Syst., vol 6, no 23, Dec 2017 [12] J G Pandey, S Gupta, and A Karmakar, “A unified architecture for aes/present ciphers and its usage in an soc environment,” pp 1–4, 2020 [13] A Hodjat and I Verbauwhede, “High-throughput programmable cryptocoprocessor,” IEEE Micro, vol 24, no 3, pp 34–45, 2004 [14] R Cowart, D Coe, J Kulick, and A Milenkovie, “An implementation and experimental evaluation of hardware accelerated ciphers in allprogrammable soc,” in Proceedings of ACM Southeast Conf., Apr 2017 [15] S Mathew, S Satpathy, V Suresh, M Anders, H Kaul, A Agarwal, S Hsu, G Chen, and R Krishnamurthy, “340 mV – 1.1 v, 289 gbps/w, 2090-gate NanoAES hardware accelerator with area-optimized encrypt/decrypt GF(24 )2 polynomials in 22 nm tri-gate CMOS,” IEEE Journal of Solid-State Circuits, vol 50, no 4, pp 1048–1058, 2015 [16] D.-H Bui, D Puschini, S Bacles-Min, E Beign, and X.-T Tran, “Aes datapath optimization strategies for low-power low-energy multisecuritylevel internet-of-things applications,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol 25, no 12, pp 3281–3290, 2017 AXI4 ECB, CBC, CTR, OFB, CCM, GCM However, the DMA consumes 25% of the power consumption while the AXI Slaxe interface only takes 17% Table I shows the comparison of our work with the previous works On FPGA, our design with AXI interfaces and the AES encryption core only occupied 1.1kSlices while the area of the ASIC implementation is 23kGEs Obviously, our design achieves the smallest hardware area in both FPGA and ASIC implementation For power consumption, our ASIC design consumes the least with only 0.7mW with the encryption throughput of 123Mbps@60MHz in TSMC 65nm technology On the other hand, the FPGA system is configured to run at 25MHz with the encryption throughput of 49Mbps and the power consumption of 7mW The comparison points out that our design has huge improvements in both area efficiency and power efficiency In practice, our FPGA version has 6.9×, 2.3× more area efficiency and 61×, 109× more power efficiency compared to works in [10] and [12], respectively For ASIC version, our work also has 2.5× more area efficiency and 18× more power efficiency compared to work in [12] V C ONCLUSIONS AEAD has been one of the main mechanisms to secure ultra-low-power highly-constrained IoT applications In this work, we designed an AEAD encryption core based on the AES algorithm The proposed design focuses on optimizing the hardware cost and the power consumption by using a lightweight 32-bit datapath AES encryption core along with the lightweight AXI-4 interfaces supporting DMA The proposed design has a small hardware area of 23kGEs in TSMC 65nm technology with the power consumption of only 0.7mW with the maximum encryption throughput of 123Mbps at 60MHz Obviously, the proposed design can be used for ultralow-power IoT applications 38 Authorized licensed use limited to: Univ of Calif Santa Barbara Downloaded on May 15,2021 at 07:02:51 UTC from IEEE Xplore Restrictions apply ... 2% AES DMA 16% Others, 11% AES Slave IF 17% Encryptio n controller , 25% AES core 37% a) AEAD encryption core? ??s area by module AES DMA, 23% AES Slave IF, 14% AES core, 27% b) AEAD encryption core? ??s... Ciphertext IV AES FSM Read Data / 32 AES Status Plaintext CPU Write Data AXI Master Interface RAM ROM S_AXI AXI Slave System Config Regs S_AXI M_AXI AXI BUS AES Encryption Module AXI Master DMA FSM System... consist of the encryption key, the base address of the formatted plaintext and the associated data, the AES key length and the AEAD mode After that, AES encryption module activates the DMA to request