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:

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 1. 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
2. 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. 1. 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. 2. 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 3. 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. 3. 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 4 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
5
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

7

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. 4. 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:

[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:
/>[4] U.S
National
Institute
of

Standards
and
Technology,
“Advanced Encryption Standard,” 2001. [Online]. Available:
/>[5] M. Dworkin, “Recommendation for block cipher modes of operation:
the ccm mode for authentication and confidentiality.” [Online].
Available: />[6] M. Dworkin, “Recommendation for block cipher modes of
operation: Galois/counter mode (gcm) and gmac.” [Online]. Available:
/>[7] M. Dworkin, “Recommendation for block cipher modes of
operation: Methods and techniques,” 2001. [Online]. Available:
/>[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.