Content uploaded by Stefano di Matteo
Author content
All content in this area was uploaded by Stefano di Matteo on Dec 01, 2023
Content may be subject to copyright.
IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 30, NO. 2, FEBRUARY 2022 177
VLSI Design of Advanced-Features AES
Cryptoprocessor in the Framework
of the European Processor Initiative
Pietro Nannipieri ,Member, IEEE, Stefano Di Matteo, Luca Baldanzi, Luca Crocetti ,
Luca Zulberti ,Member, IEEE, Sergio Saponara ,Senior Member, IEEE,
and Luca Fanucci ,Fellow, IEEE
Abstract— This article presents a cryptographic hardware
(HW) accelerator supporting multiple advanced encryption stan-
dard (AES)-based block cipher modes, including the more
advanced cipher-based MAC (CMAC), counter with CBC-MAC
(CCM), Galois counter mode (GCM), and XOR-encrypt-XOR-
based tweaked-codebook mode with ciphertext stealing (XTS)
modes. The proposed design implements advanced and innovative
features in HW, such as AES key secure management, on-chip
clock randomization, and access privilege mechanisms. The
system has been tested in a RISC-V-based system-on-chip (SoC),
specifically designed for this purpose, on an Ultrascale + Xilinx
FPGA, analyzing resource and power consumption, together
with system performances. The cryptoprocessor has been then
synthesized on a 7-nm CMOS standard-cells technology; per-
formances, complexity, and power consumption information are
analyzed and compared with the state of the art. The proposed
cryptoprocessor is ready to be embedded within the innovative
European Processor Initiative (EPI) chip.
Index Terms—Advanced encryption standard (AES), crypto-
processor, European Processor Initiative (EPI), RISC-V.
I. INTRODUCTION
NOWADAYS, the demand for secure data exchange is ever
growing. For this reason, cryptography has become an
essential component of modern electronic systems.
Generally, an embedded system is equipped with a micro-
processor in charge of executing the software (SW); this can be
a valid approach to perform security algorithms. Nevertheless,
in specific application cases, the performance of the embed-
ded microprocessor could be insufficient to comply with the
latency and/or throughput requirements, for example, in real-
time IoT applications [1]. In these cases, a valid solution
could be to privilege hardware (HW) accelerated rather than
pure SW implementations, for security algorithms. It is from
these considerations, together with the need for a European
Manuscript received June 10, 2021; revised September 6, 2021 and
October 26, 2021; accepted November 14, 2021. Date of publication
December 1, 2021; date of current version February 7, 2022. This work was
supported by the European Union’s Horizon 2020 Research and Innovation
Programme under Grant 826647 (European Processor Initiative). (Correspond-
ing author: Pietro Nannipieri.)
The authors are with the Department of Information Engineering,
University of Pisa, 56122 Pisa, Italy (e-mail: pietro.nannipieri@ing.unipi.it).
Color versions of one or more figures in this article are available at
https://doi.org/10.1109/TVLSI.2021.3129107.
Digital Object Identifier 10.1109/TVLSI.2021.3129107
Fig. 1. High-level EPI security subsystem architecture.
platform for computing, that the European Processor Initiative
(EPI) [2] has been launched. EPI is an H2020 project under
development, started in 2018, whose aim is to design and
implement a new family of low-power European processors
for exascale computing, high-performance Big-Data, and a
range of emerging applications, including automotive [3].
Robustness and safety issues play a significant role in the
framework of the targeted markets, especially automotive. The
EPI processor is expected to answer the currently unaddressed
need of proper architecture, at both HW and SW levels,
to support the requirements of current and future cybersecurity
standards and certifications.
The proposed EPI HW security architecture relies on iso-
lated blocks of the circuit, with specific HW and dedicated
private resources for security responsibility. Fig. 1 illus-
trates the proposed EPI HW security subsystem architecture,
which foresees the cryptoprocessor-tile (CT) with multiple
HW cryptographic accelerators including advanced encryption
standard (AES), secure hash algorithm (SHA) [4], elliptic-
curve cryptography (ECC) [5], and random number generation
(RNG) [6], [7]. All is controlled by a secure micro-controller
unit (MCU), which is a RISC-V processor.
The security cryptoprocessor can be used both exploiting
the secure MCU interface and also a dedicated secure direct
memory access (DMA) connection.
Among the available cryptographic functions, the AES [8]
is probably the most popular symmetric-key algorithm.
1063-8210 © 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
178 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 30, NO. 2, FEBRUARY 2022
HW implementations of the AES are usually preferred to SW
ones [3] in performance and power-critical environments: with
dedicated HW, it is possible to achieve better performance
with lower power consumption. They are also often coupled
with other more advanced cryptographic algorithms, such
as SHA3 [9] or as authenticated encryption with associated
data (AEAD) services [10]. The proposed work belongs to
the wider EPI CT design project: we aim to illustrate and
comment on the architecture for the AES cryptoprocessor,
embedded in the CT of the breaking-trough EPI processor,
focusing on the main innovation introduced. Being the AES
standard well established, several solutions already address the
problem of the AES HW acceleration [11]–[13]. There are
also Systems-on-Chip available in the literature, but either they
are performance-limited or they lack the in HW support for
advanced features. Reference [14] is a RISC-V-based system-
on-chip (SoC) with AES HW accelerator, but its features are
not declared; it is not clear which modes are supported, with
which performances, making it impossible to carry out a fair
and solid comparison. Reference [15] is a very interesting
implementation, like our proposed system. However, the AES
processor is barely described and does not support all the
features we intended to support [it seems to support only
Galois counter mode (GCM)]. It is interesting to observe that
also here the approach of the loosely coupled accelerator has
been followed, also for much larger accelerators such as the
ECC which requires a lot of HW resources. Reference [16]
is a very structured solution but also here, probably since
it is a commercial product, no information is given on the
internal architecture and the features supported in HW. Similar
consideration applies to [17]. The main innovation of this
work is to present an implementation of a complete AES
cryptoprocessor, fully HW-accelerated with advanced features,
integrated with a RISC-V processor, to be employed within the
upcoming EPI processor; our contributions include, but are not
limited, to the following.
1) Architectural design of the AES cryptoprocessor inside
the CT, a HW accelerator compliant to AES stan-
dard supporting nine different block cipher modes,
ensuring not only confidentiality, but also integrity
and AEAD.
2) HW implementation of innovative and advanced fea-
tures that are not usually HW-accelerated: policies for
secure keys storage, employment of clock randomization
technique on the cryptoprocessor, the control mecha-
nism for configuring the cryptoprocessor, preemption of
cryptographic operations, and panic mechanism.
3) Design of an SoC with a RISC-V processor coupled with
the AES cryptoprocessor as a HW accelerator. There
are other examples in literature where a form of AES
HW acceleration is coupled with a RISC-V processor
[18]–[21]. Most of the available solutions are tightly
coupled HW acceleration, which exploits the extendible
ISA of the RISC-V processor to accelerate in HW small
primitives. The tightly coupled approach requires greater
efforts and better exploits the flexibility of the RISC-V
processor. It requires a very small HW overhead that
needs to be inserted in the processor pipeline. However,
the achievable improvements in terms of performances
are more limited, since it is not possible to add too
much logic to the processor pipeline without affecting its
timing performances. Our approach explores a different
region of the design space: the innovation of our pro-
posed system is the support for advanced HW features,
such as the key management, that would not be possible
to be realized in HW within the processor pipeline.
In addition, we aim for HW acceleration of different
operating modes to maximize achievable throughput.
The result is a more complex design that needs to be
interfaced as a separate HW accelerator, requiring more
HW resources but achieving greater performance and
more advanced features.
4) SoC FPGA verification on a Xilinx Ultrascale +board
with preliminary analysis on complexity, throughput,
and performances.
5) Implementation on the cutting-edge 7-nm TSMC silicon
technology (target technology for the EPI processor, first
contribution available on this technology to the best of
our knowledge), with a complete analysis of complexity,
throughput, and power dissipation.
After this introduction, the rest of this article is organized
as follows. In Section II, we present and define the cryp-
toprocessor architecture, focusing on the innovative mech-
anisms (key management mechanism, clock randomization,
etc.). In Section III, we illustrate the architecture of the AES
core embedded in the cryptoprocessor and we illustrate the
architecture of the AES engine, focusing on the key and more
innovative architectural portions. In Section IV, we present the
innovative SoC platform used to validate the system, based
on a RISC-V processor to emulate as much as possible the
target EPI security sub-system architecture. In Section V, the
results on various silicon technologies, especially the 7 nm, are
shown and compared with the results available in the literature.
Finally, in Section VI, we will conclude this work, highlighting
the achieved results.
II. AES CRYPTOPROCESSOR ADVANCED HW FEATURES
The CT offers security services and algorithms based on
symmetric-key and public-key cryptography, hash functions,
and random numbers generation, aiming to guarantee data con-
fidentiality, integrity, authenticity, authentication, and signature
services. The AES cryptoprocessor inside the crypto-tile is
responsible for the symmetric-key algorithms, supporting the
AES cipher and the modes of operations reported in Table I,
both in the case of AES-128 and AES-256. The architecture
of the AES cryptoprocessor (see Fig. 2) is composed of
the interface registers to handle the cryptographic operations
(i.e., configuration, control, error, and status registers), a state
machine (i.e., FSM), data, and key registers, and the AES
engine that effectively computes the AES cipher and the
supported modes of operations.
A. AES Cryptoprocessor Functionalities
The AES cryptoprocessor integrates and offers several
enhanced functionalities that increase the robustness of
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
NANNIPIERI et al.: VLSI DESIGN OF ADVANCED-FEATURES AES CRYPTOPROCESSOR IN FRAMEWORK OF EPI 179
TAB L E I
SUPPORTED BLOCK CIPHER MODES AND RELATED PROPERTIE S.
ECB; CBC; CFB; OFB; CTR; CMAC; CCM; GCM; XTS
Fig. 2. AES cryptoprocessor inside the crypto-tile.
security boundaries and strength the resistance against misuse,
unauthorized accesses, and physical attacks.
Other than six key slots that can be employed, for instance,
to install three couples of keys for different scopes (e.g.,
chip keys, SW context keys, and application keys), the AES
cryptoprocessor also provides the possibility to redirect the
output of the underlying AES engine onto internal key slots,
thus allowing the user to derive and generate secure keys
which are not outsourced from the AES cryptoprocessor.
This feature enables the employment of the AES crypto-
processor as a building block of pure HW or HW and SW
root-of-trust (RoT).
To allow restriction mechanisms on the cryptoprocessor
usage, two different privilege levels (i.e., supervisor and user)
can be used to access a specific set of registers. The supervisor
level is responsible for configuring the cryptoprocessor at
startup, enabling or disabling features and functionalities (e.g.,
supported modes of operation, reserved key slots) as well as
using it normally for cryptographic operations. The User Level
cannot configure processor functionalities and can only be
used for cryptographic operations with the key slots reserved
for it. Such a privilege mechanism allows differentiating
between two different execution contexts that are strictly
independent. Only the Privilege Level of the current execution
context can retrieve the whole information about it such as
configuration and state of the ongoing cryptographic operation,
as well as the input and output data. Once a cryptographic
operation configuration is initiated in a Privilege Level, only
this level can manage it and terminate it. To prevent denial
of access, only the supervisor level can abort a cryptographic
operation initiated with the User Level, reporting a specific
error. In addition, any error occurring on a cryptographic
operation or a key slot is reported separately for each Privilege
Level. The Privilege Level differentiation is implemented at
the interface level, exploiting the AXI4 functionalities.
Also, the cryptoprocessor embeds control and handling
mechanisms that ensure a proper configuration and usage of
the module to perform cryptographic operation: a specific
state-based flow has to be respected to successfully run an
operation, and the evolution from one state to another one is
managed by a set of actions that relies on strict control of
authorization and privileges. Such mechanisms also regulate
the access to sensitive data, both input and output ones,
allowing or forbidding such databasing not only on a Privilege
Level base, but also on the state of the AES cryptoprocessor,
and limiting the number of access to such data: in case
multiple access to the same sensible data is performed, the
cryptoprocessor prevent write or read of data and raises an
error flag, moving to the error state.
To improve the flexibility and fit real-time application con-
texts, the AES cryptoprocessor also supports the preemption
of cryptographic operations, allowing to halt the execution of
a cryptographic operation and to perform the execution of
another one with higher priority. The implementation of this
feature requires the AES cryptoprocessor to allow access to
some internal states of the cryptographic operation that is
going to be suspended, to resume it later, once the execution
of operation with higher priority has been completed. Halting
an operation in progress occurs once the 128-b block of data
has been correctly processed by the cryptoprocessor, and the
internal states and data are stored in proper auxiliary registers
that can only be accessed according to restriction mechanisms
for access to sensitive data. Also, in this case, the AES
cryptoprocessor strictly regulates the access to internal states
of cryptographic operations to improve security and counteract
unauthorized or illegal usage of assets.
For the same purpose, the cryptoprocessor embeds also
panic mechanisms that allow to partially or completely flush
the sensible data installed into the cryptoprocessor itself (e.g.,
the secret keys), offering a specific interface to trigger the
panic state (allowed only for the supervisor level) and to con-
figure the actions to be performed. This panic mechanism is
implemented to react immediately and with minimal assistance
of SW to manage events that may lead to a critical security
breach. Two levels of panic mechanisms are implemented in
the AES cryptoprocessor: partial-panic (level 1) and full-panic
(level 2). The partial-panic mechanism stops immediately any
cryptographic operation and resets all the input and output
registers. Each of the key slots can be configured (before being
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
180 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 30, NO. 2, FEBRUARY 2022
populated with sensitive data) to be sensible to the partial-
panic mechanism; in this case, if a partial-panic is triggered
all the registers of that key slot are reset immediately. The
full-panic mechanism stops and resets any ongoing crypto-
graphic operation and resets all the data and key registers.
Finally, the AES cryptoprocessor embeds also dedicated
resources for the local derivation and randomization of clock
signal feeding the AES engine, starting from the external
clock source. This feature highly increases the robustness
of cryptoprocessor to physical attacks such as side-channel
attacks (SCAs), which are based on the analysis of power
consumption [power analysis (PA)] and electromagnetic emis-
sion [electromagnetic analysis (EMA)]. Randomization and
manipulation of clock cycles alter the acquisition pattern an
attacker has to gather and observe to retrieve secret data
(usually the secret key), significantly increasing the acquisition
time and the pre-processing resources an attacker must employ
for a successful attack.
We opted for this countermeasure even if there are
more secure ones, such as threshold implementation, as it
almost does not affect system complexity and through-
put, as shown in [22]. A higher level of security can be
obtained with various techniques, including threshold imple-
mentation, such as described in [23], and can theoretically
completely protect the system from SCAs. Unfortunately,
the price that needs to be paid for this protection is
very high and grows with the desired degree of protec-
tion, affecting the system throughput and the dimension
of the circuit. The clock randomization technique proposed
does not ensure complete protection against SCA; how-
ever, it improves its resistance as demonstrated in [24]–[26],
with negligible costs in terms of HW resources, better resis-
tance compared to fixed clock solution. It is possible of course,
but out of the scope of this article, to exploit more complex
techniques available in the literature to enrich the resistance
level to SCAs.
Fig. 3 shows a functional block scheme of the clock
randomization circuitry: for simplicity, control logic, reset, and
exceptions signals are not reported. Such sub-module of the
AES cryptoprocessor is mainly composed of a multiplexer to
select the clock source (i.e., from PLL or an on-board internal
oscillator), a clock division stage, and finally the pure clock
randomization stage. As depicted by the detail box at the
bottom of Fig. 3, this last stage counts a pseudorandom number
generator (PRNG, based on linear feedback shift register,
LFSR, approach) that generates a random number (rnd_num)
and a clock cycles counter that reports the actual number of
elapsed clock cycles (cc_cnt) and raise the update flag when
it reaches the total number of clock cycles (this parameter
is configured employing AES cryptoprocessor configuration
registers). When the random number and the number of
elapsed clock cycles match, the skip_cc flag is asserted and
the clock gating logic mask the clock cycle of clock signal
clk_div_x_gmux; when the update flag is asserted, the clock
cycles counter is cleared, while the PRNG block generates a
new random number. In a complete cryptoprocessor system,
the PRNG resistance to SCA is fundamental. In this work,
we focused on the AES core of a much wider cryptoprocessor,
Fig. 3. Clock division and randomization circuit architecture.
as mentioned in Section I. However, in our vision, we are
aware of the importance of the topic: indeed, we designed
also a TRNG to be exploited in our final cryptoprocessor
system [6], [7]. The PRNG used for clock randomization is
re-seeded periodically with TRNG values, to improve both
entropy and SCA resistance.
For what concerns the compliance with standards defining
security requirements for cryptographic modules, the definition
of architecture and security features of both the AES cryp-
toprocessor and the whole CT has been designed following
the guideline of FIPS 140-2 [27]. The specifications of [27]
cover different areas such as module ports and interfaces,
finite state model, cryptographic key management, self-tests,
and other aspect related also to physical security. The CT
employs only NIST-approved algorithms and modes of oper-
ations and is strictly physically isolated to the rest of the
EPI chip. Authentication mechanisms are included to permit
the usage of the entire CT and of defined key slots of the
AES cryptoprocessor adopting a seal/unseal procedure that
requires secret tag values. All the possible operations and
states of the AES cryptoprocessor are specified with a finite
state model. Cryptographic key storage and management are
included in the AES cryptoprocessor, which is in line with
the indication provided by NIST. The connectivity with a
RISC-V processor allows implementing self-test and power-up
test through HW-SW cooperation. The security considerations
related to physical and environmental aspects are out of the
scope of this work.
B. Secure Keys Storage and Management
The AES cryptoprocessor embeds a dedicated set of reg-
isters to contain and manage the cipher keys through strict
usage rules, detection, and management of error conditions
and access restrictions, as shown in Fig. 4. The population
and usage of a key in a cryptoprocessor is a very sensitive
operation. Key slot access and usage shall be protected to
prevent any misusage due to HW failures, SW bugs, or attacks.
The key management registers are composed of the follow-
ing set of registers implementing different security features.
1) Seal/unseal registers: Store an access tag required to
lock/unlock the key slot.
2) Configuration registers: Allow to configure the key slot.
3) Errors registers: Flag errors due to misusages of the key
slots.
4) Usage counter: Allows to keep track of the number of
cryptographic operations executed with the key.
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
NANNIPIERI et al.: VLSI DESIGN OF ADVANCED-FEATURES AES CRYPTOPROCESSOR IN FRAMEWORK OF EPI 181
Fig. 4. AES key storage and management registers.
5) Key-value register: Contains the value of the key or the
value of the encrypted key.
Six independent key slots are supported to allow key man-
agement fully done inside the CT and allow population by dif-
ferent isolated parts of SW upon specific chip lifecycles (e.g.,
some key slots are populated during chip boot, other during
applicative context switch). The proposed key-management
registers aim to handle errors and threats, offering different
levels of protection.
1) Key Slot Protection: The access of each key slot can be
reserved to a given Privilege Level. If a key is loaded by a
given Privilege Level, it is aimed and shall be used only by
that Privilege Level, until it is released by being cleared. Also,
key slots access is protected by an access tag to prevent access
or usage from an unexpected part of the SW not knowing the
tag value (it lowers the attack surface at the SW level by
requiring more than a given Privilege Level). Such an access
tag is intended to allow access (set of configuration, usage
rules, and value) to the key slot only to a specific, identified
part of the SW that knows the tag. The key slot supports the
possibility to lock his configuration (including his value) until
the next reset. This allow, for instance, to protect master keys
of the chip that can be set at an early stage of boot. Every
misusage of each key slot flags an error on the corresponding
error register that must be cleared before using again the slot.
2) Key-Value Protection: A lot of attacks conducted through
malicious SW aim at trying to steal secret keys or to use
such keys without authorization. The restrictions based on
the privilege levels are clearly not sufficient to enforce proper
protection. A solution proposed inside the AES cryptoproces-
sor is to have the application only manipulating half secret,
that is, encrypted keys, which are then deciphered only inside
the cryptoprocessor and associated with needed usage rules.
Each AES secret key slot can be directly populated with a
specific configuration from the output of an AES cryptographic
operation performed by the cryptoprocessor. This internal
mechanism enforces that the application is never manipulating
the plaintext key value. For this reason, different key slots are
included to have some key slots reserved for this usage: as
an example, an AES key slot may be dedicated to storing a
dedicated chip unique key, and another slot can contain a key
specific to the application process context (that is changed
upon each context switch of the OS, thus enforcing strong
isolation and data confidentiality between each application).
3) Key-Value Usage: To mitigate improper usage of a
loaded key, each key slot integrates configuration elements that
allow restricting its usage to specific algorithms and modes.
There is a counter that reports the usage count accessed
by the SW, which allows it to effectively detect misuse or
illegal access to the key, since at the end of the cryptographic
operation it can check that the counter matches the expected
value it calculated.
III. AES ENGINE
A. AES Core
Only one AES core is instantiated and shared among all
the implemented block cipher modes, thus only one mode
at a time can be driven from the processor. The AES core
is implemented with the most convenient tradeoff between
performance and complexity: only the functions belonging to
one round are implemented and used iteratively for several
rounds ranging from 10 to 14 depending on the key size.
To save logic resources, only the 128 and 256-b key lengths are
supported. It is a remarkable fact that the AES-256 is already
considered secure against post-quantum attacks [28]. The AES
core includes the key schedule that provides the round-keys
from the input key.
The implemented architecture of the AES core is based on
the one presented in [11]: this architecture uses a merged S-
box approach [29], to perform both encryption and decryption
by executing one round of AES per clock cycle.
B. Electronic Code Book (ECB), Cipher Block Chaining
(CBC), Output FeedBack (OFB), Cipher FeedBack (CFB),
Counter (CTR) Modes of Operations
The AES engine supports the basic AES modes of oper-
ations (i.e., ECB, CBC, OFB, CFB, and CTR algorithms)
described in National Institute of Standards and Technology
NIST special publication 800-38A [30]. To reduce the logic
resources consumption, the proposed architecture shares the
AES core and performs reshaping of data flow according to
the mode of operation, employing multiplexers, XOR gates,
and registers. Fig. 5 shows data flow in the case of encryption
process, while Fig. 6 shows data flow in the case of decryption
process. Referring to Figs. 5 and 6, IV corresponds to the
initialization vector foreseen by the various AES modes, and
D_in and D_out are, respectively, the input data and the output
data; thus, in the case of encryption (see Fig. 5) D_in port is
fed with a data block of plaintext, and D_out corresponds to
a ciphertext block, vice versa in the case of decryption.
C. Cipher-Based MAC (CMAC) Core
The Cipher-based MAC (CMAC) mode described in
the NIST special publication 800-38B [31] is supported by the
AES engine. Fig. 7 shows the high-level block scheme of the
logic resources employed by the AES engine when supporting
the CMAC mode: other than the AES core in CBC (encryp-
tion) mode, an additional module for derivation of sub-keys
K1 and K2 is instantiated. In this case, after the processing
of the sequence of all the Miblocks composing the message
M, a unique output data block is produced, which is the tag
of the message, T.
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
182 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 30, NO. 2, FEBRUARY 2022
Fig. 5. ECB, CBC, OFB, CFB, and CTR modes with a single AES core
architecture: Encryption data flow.
Fig. 6. ECB, CBC, OFB, CFB, and CTR modes with a single AES core
architecture: Decryption data flow.
Fig. 7. Logic resources of AES engine when supporting CMAC mode.
On the receiver side, the recipient can easily verify the
integrity and authenticity of the message by locally recom-
puting the message tag and comparing it with the received
one.
D. Counter With CBC-MAC (CCM) and GCM Cores
The AES engine supports CCM and GCM modes,
described, respectively, in the NIST special publications
800-38C [32] and 800-38D [33]. They are AES modes of
operations providing confidentiality, integrity, and authenticity
services. For this reason, the processes they perform are named
encryption-generation and decryption-verification (being the
terms encryption/decryption referring to plaintext/ciphertext
and generation/verification to the tag produced for integrity
check). The two modes are equivalent in terms of secu-
rity services offered, and the only difference consists in
Fig. 8. GCM core.
the methodology for the generation of the tag. CCM mode
employs the MAC-then-Encrypt (MtE) paradigm, that is, the
tag is computed before converting the plaintext into ciphertext,
and this implies that on the recipient side, the verification of
tag can be performed only once the whole ciphertext has been
completely decrypted; the GCM employs the Encrypt-then-
MAC (EtM) paradigm, which calculates the integrity tag using
the ciphertext: in this case, the recipient can verify the tag
without decrypting the ciphertext, allowing to save resources
dedicated to the decryption in case the tag verification fails.
Both cores embed the module described in Section III-B
and a module dedicated to the encoding and the formatting
of input data, that is, associated data, that are not encrypted
and usually termed as additional authenticated data (AAD),
and the plaintext (or ciphertext, in the case of decryption-
verification). For encryption/decryption, both the cores exploit
the CTR mode of AES, while for tag generation, the CCM core
employs the CBC mode (like the CMAC algorithm); instead,
the GCM core requires a multiply-and-accumulate operation
using a multiplication over the Galois field GF(2128 )and using
as modulo the polynomial M(x)=x128 +x7+x2+x+1: such
operation is typically termed GHASH (Galois-HASH) and for
this reason, the GCM core integrates also a module dedicated
to it.
Fig. 8 illustrates the GCM core, for which AAD jis the jth
data block of AAD, Pi(or Ci)istheith block of plaintext
(or ciphertext), and Tis the integrity tag.
E. XOR-Encrypt-XOR-Based Tweaked-Codebook Mode With
Ciphertext Stealing (XTS) Core
AES XTS described in NIST special publication
800-38E [34] is a mode of operation aimed at encryption of
sector-based storage, guaranteeing random access to encrypted
data. To perform this operation, two different keys are required
and an initialization vector that must be updated for each new
sector to be encrypted: the initialization vector is computed
using arithmetic operation over the Galois field defined by the
polynomial M(x)=x128 +x7+x2+x+1. Thus, the XTS
core embeds the ECB mode logic described in Section III-B,
a module dedicated to the computation of sector-based
initialization vector and a block dedicated to formatting of
input and output data.
Fig. 9 shows the XTS core, for which Sjis the jth sector
number, Pi(or Ci)istheith data block to be encrypted
(or ciphertext), and K1and K2are the keys.
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
NANNIPIERI et al.: VLSI DESIGN OF ADVANCED-FEATURES AES CRYPTOPROCESSOR IN FRAMEWORK OF EPI 183
Fig. 9. XTS core.
Fig. 10. Architecture of the demonstrative SoC.
IV. CRYPTOPROCESSOR TECHNOLOGY VALIDATION
ON FPGA-BASED SOCPROTOTYPE
To validate the AES cryptoprocessor system emulating the
EPI cryptoprocessor behavior, we designed an FPGA pro-
totype system. The designed demo application employs the
CVA6 RISC-V core [35] and exploits an AXI4 Interconnect
structure for securely performing AES cryptographic opera-
tions. Using the UART module, the application provides to
the user a command-line interface, with which he can perform
encryption and decryption operations of strings.
A. Unipi Cryptoprocessor Demoboard
The chosen board, ZCU106 from Xilinx, features a Zynq
UltraScale+MPSoC EV device and supports all major periph-
erals and interfaces, enabling development for a wide range
of applications.
In Fig. 10, a simplified block diagram of the prototyped
system is shown. The interconnection of the demo board is
composed of several AXI peripheral masters and slaves due
to the presence of the DMA. For this reason, there are three
different AXI crossbars that connect the main components of
the block design, reported in the following together with the
other building blocks.
1) RISC-V CVA6 CPU: It has a master AXI4 interface
that is connected to the main memory crossbar and
the peripheral crossbar. It can access all the available
resources in the design. To save resources and power,
we did not include the floating point unit (FPU).
2) UART: Provided by Xilinx, it has a slave AXI4-Lite
interface which is connected to the peripheral Crossbar,
from which it can be configured and used.
3) AES cryptoprocessor: It has a slave AXI4-Lite interface
connected to the peripheral Crossbar from which it can
be configured and a couple of AXI stream interfaces
connected to the AES DMA with which the data can be
sent and the results can be taken.
4) AXI4 128-b AES DMA: Provided by Xilinx, in addition
to the AXI stream interfaces connected to the AES
peripheral, it has a slave AXI4-Lite interface connected
to the peripheral Crossbar for configuration and a master
AXI4 interface connected to the main memory Crossbar
for accessing data.
5) Block RAMs (BRAM): Provided by Xilinx; are on-chip
memories implemented with Block RAMs and are used
to store the program binary and data. Its size is 128 KB.
6) AXI4 64-b Xbar SmartConnect: Provided by Xilinx;
connect the masters with the peripherals and the memory
using speed optimization strategy for CPU and memory
interconnects and area optimization strategy for the
peripherals interconnect.
7) AXI4-Lite 32-b Xbar Peripheral: Provided by Xilinx;
bridges the AXI4-Lite peripherals to the main AXI
interconnect.
8) JTAG AXI: Provided by Xilinx; it is used to load the
program binary into the main memory at run time.
9) Virtual I/O: Provided by Xilinx; it is used to assert the
reset signal to the SoC from the HW Manager in Vivado.
We opted for a loosely coupled accelerator approach to
maximize system performance, at the price of a more complex
HW accelerator. Indeed, a tightly coupled accelerator requires
a negligible amount of resources but has several disadvantages:
even if it does not have any AXI communication delay,
it has a memory communication overhead, especially heavy
in the case of large encryptions. Our solution to the problem,
optimized for larger blocks encryption, is to mitigate the delay
by exploiting an independent DMA to deliver plain data to the
engine and collect the encrypted messages. A second problem
is that it would be problematic to enable HW acceleration of
all the supported AES operational modes inside the processor
pipeline, and the overall clock frequency would be heavily
affected by the resulted complexity. This is observable in
work such as [21], where the system is less complex than our
proposed system (about 6.5 kGE against 131.45 kGE), but the
performances are much lower (about 6 Mbps against 30 Gbps),
resulting in the worst throughput on complexity ratio.
Please note that the blocks performing the conversion of the
AXI protocol and the data width are omitted in Fig. 10.
The demo application takes the input from the user using
the UART interface. Then it configures the AES DMA to
gather the data, that must be encrypted or decrypted, from the
memory and send it to the AES peripheral which performs the
cryptographic operation. The data is processed and the result is
scattered back in the main memory. After that, the application
prints the result on the terminal using the UART.
B. Implementation Results
The presented SoC has been synthesized and implemented
on the ZCU106 board. The timing requirements are met with
the margins listed in Table II; note that within the AES
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
184 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 30, NO. 2, FEBRUARY 2022
TAB L E I I
TIMING REPORT FOR THE TWO CLOCK DOMAINS
TABLE III
ABSOLUTE AND RELATIVE RESOURCE UTILIZATION
ON THE ZCU106 BOARD , XCZU7EV FPGA
Fig. 11. Visual resource placement on the FPGA of CVA6 no FPU (yellow),
AES cryptoprocessor (red), AXI SmartConnect (green), and DMAs (purple).
cryptoprocessor, the interface registers (i.e., configuration,
control, error, and status registers), the state machine, and the
data and key registers are clocked with the main clock. While
the resource utilization is presented in Table III, both with the
absolute values and the percentage of resources occupied on
the FPGA. The resulting placement is illustrated in Fig. 11.
V. V L S I T ECHNOLOGY MAPPING
This section presents the synthesis and implementation
results obtained in different platforms and technologies.
A. Synthesis on 7-nm Standard-Cell Technology
The proposed AES cryptoprocessor has been synthesized
with design compiler by synopsys on the Artisan 7-nm TSMC
standard-cell technology in the typical case (0.75 versus
85 ◦C). Table IV reports the synthesis results for the AES
cryptoprocessor, the AES engine, and the AES core. Note
that the AES engine includes the AES core plus the cores
dedicated to the supported modes of operations (i.e., ECB,
CBC, OFB, CFB, CTR, CMAC, CCM, GCM, and XTS),
while the AES cryptoprocessor includes the AES engine plus
TAB L E I V
RESOURCE UTILIZATION AND POWE R CONSUMPTION WITH 7-nm
STANDARD-CELL TECHNOLOGY SYNTHESIS AT 2.55 GHz
TAB L E V
THROUGHPUT WITH 7-nm STANDARD-CELL TECHNOLOGY
SYNTHESIS AT 2.55 GHz
the interface registers (i.e., configuration, control, error, and
status registers), the state machine, the data, and key registers,
all synthesized at 2.55 GHz as reported in Table IV. Also,
the AES cryptoprocessor includes a dedicated synchroniza-
tion logic to manage clock domain crossing. In Table V,
we present the system throughputs for each operating mode.
The measurements have been carried out exploiting the system
presented in [40], where an emulation environment capable of
performing a low-level post-synthesis simulation of code exe-
cution on a RISC-V-based system is carefully described. The
test has been performed simulating the entire system, loading
the memory with bare-metal code, aiming at measuring the
maximum capabilities of the HW system.
B. Comparison to the State of the Art
To the best of our knowledge, no contribution related to HW
accelerators for AES implemented in 7-nm technology can be
found in the literature. In addition, few implementations can
be directly compared to the proposed AES cryptoprocessor
due to the major differences that can be found in the overall
architecture of the cryptoprocessor (e.g., interface registers,
communication interfaces, supported modes of operations, key
storage, key length, etc.). Highly optimized implementations
are available but unfair to be compared since they focus
just on one of the figures of merit (e.g., area [41], [42]).
Also, new emerging research topics tend to involve AES-like
processing, such as the use of memristors to empower SCA
resistance [43]. Table VI reports the results in terms of area,
throughput, and supported functions of different AES crypto-
processors which have been extracted in both research articles
and commercial products. Since the most relevant work in
the literature provided significant results only in CBC mode,
we decide to carry out the comparison based on that opera-
tional mode. The works in [36] and [37] are both commercial
AES cryptographic IPs, while the works in [38] and [39] are
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
NANNIPIERI et al.: VLSI DESIGN OF ADVANCED-FEATURES AES CRYPTOPROCESSOR IN FRAMEWORK OF EPI 185
TAB L E V I
COMPARISON AMONG DIFFERENT AES CRYPTOPROCESSOR IMPLEMENTATIONS
research articles. The throughput refers to the 128-b CBC
encryption mode as it was the one with more reports in the
referenced works. The CRYPT-IP-120b [36] is produced by
Rambus and supports different AES modes of operations (i.e.,
ECB, CBC, CTR, CMAC, CCM, and GCM). It includes key
storage and management service and a DMA controller. The
area consumption is reported around 49–53 kGE while the
throughput cannot be extracted. The IP in [37] is designed
by EnSilica and is all-in-one encryption, decryption, key
expansion, and chaining modes ECB, CBC, CTR, and GCM.
It can support three different key sizes (i.e., 128, 192, and
256) but does not have any support for secure storage and
DMA. No performance in terms of throughput and area is
reported by the company. In [39], a flexible cryptographic
processor named Cryptoraptor is described. It supports a wide
range of symmetric key algorithms in addition to the AES
and showed good performance in terms of throughput for the
AES algorithm. Concerning our work, it offers more flexibility
but no dedicated features for security. The work in [38] is an
AES HW accelerator fabricated in 45-nm CMOS, for content
protection in a high-performance microprocessor. It supports
three key lengths and only ECB and CBC modes of operations.
Although it is hard to perform a full comparison among
these implementations due to the architectural differences they
have, we can claim that our proposed solution is the more
complete on the HW side, supporting all the available modes
of operation at the same time, with complexity and throughputs
overcoming less-featured cryptoprocessors.
VI. CONCLUSION
This work presented an AES-based cryptoprocessor imple-
mentation, suitable to be employed both in embedded SoC
applications and already adopted by the upcoming EPI proces-
sor. The accelerator was implemented on both a Xilinx
Ultrascale+FPGA device and 7-nm standard-cell technolo-
gies. In particular, the cryptoprocessor has been embedded
with a RISC-V CVA6 processor and the proposed SoC has
been prototyped on a ZCU106 board. Complexity and per-
formance have been thoroughly characterized for all the AES
modes of operations in all the above-mentioned technologies.
The achieved results show that our implementation offers inno-
vative HW support to advanced cryptoprocessor features such
as access control, IP configuration, key management, and clock
randomization mechanisms. On top of that, we extensively
support up to nine modes of operations, contemporaneously
on the same HW accelerator, obtaining results that are aligned
with the state-of-the-art solution, where only a few modes
of operations were included and no advanced features were
supported. To the best of the authors’ knowledge, this work
is the first contribution available in the literature on AES
implementation results on 7-nm technology.
REFERENCES
[1] F. Rahman, M. Farmani, M. Tehranipoor, and Y. Jin, “Hardware-
assisted cybersecurity for IoT devices,” in Proc. 18th Int. Workshop
Microprocessor SOC Test Verification (MTV), Dec. 2017, pp. 51–56.
[2] European Consortium. EPI Website. Accessed: Sep. 6, 2021. [Online].
Available: https://www.european-processor-initiative.eu/
[3] L. Baldanzi, L. Crocetti, S. Di Matteo, L. Fanucci, S. Saponara, and
P. Hameau, “Crypto accelerators for power-efficient and real-time on-
chip implementation of secure algorithms,” in Proc. 26th IEEE Int. Conf.
Electron., Circuits Syst. (ICECS), Nov. 2019, pp. 775–778.
[4] P. Nannipieri et al., “SHA2 and SHA-3 accelerator design in a
7 nm technology within the European processor initiative,” Micro-
processors Microsyst., Nov. 2020, Art. no. 103444. [Online]. Available:
https://www.sciencedirect.com/science/article/pii/S0141933120305986
[5] S. Di Matteo, L. Baldanzi, L. Crocetti, P. Nannipieri, L. Fanucci, and
S. Saponara, “Secure elliptic curve crypto-processor for real-time IoT
applications,” Energies, vol. 14, no. 15, p. 4676, Aug. 2021.
[6] P. Nannipieri et al., “True random number generator based on
Fibonacci–Galois ring oscillators for FPGA,” Appl. Sci., vol. 11, no. 8,
p. 3330, Apr. 2021.
[7] L. Baldanzi et al., “Cryptographically secure pseudo-random number
generator IP-core based on SHA2 algorithm,” Sensors, vol. 20, no. 7,
p. 1869, Mar. 2020. [Online]. Available: https://www.mdpi.com/1424-
8220/20/7/1869
[8] Advanced Encryption Standard (AES), Federal Information Processing
Standards Publication 197, NIST, 2001, no. 441, p. 0311.
[9] D.-E.-S. Kundi, A. Khalid, A. Aziz, C. Wang, M. O’Neill, and W. Liu,
“Resource-shared crypto-coprocessor of AES enc/dec with SHA-3,”
IEEE Trans. Circuits Syst. I, Reg. Papers, vol. 67, no. 12, pp. 4869–4882,
Dec. 2020.
[10] S. Sawataishi, R. Ueno, and N. Homma, “Unified hardware for high-
throughput AES-based authenticated encryptions,” IEEE Trans. Circuits
Syst. II, Exp. Briefs, vol. 67, no. 9, pp. 1604–1608, Sep. 2020.
[11] R. Ueno, S. Morioka, N. Homma, and T. Aoki, “A high throughput/gate
AES hardware architecture by compressing encryption and decryption
datapaths—Toward efficient CBC-mode implementation,” in Proc. 18th
Int. Conf. Cryptograph. Hardw. Embedded Syst. (CHES), Santa Barbara,
CA, USA, Aug. 2016.
[12] J. C. Resende and R. Chaves, “Compact dual block AES core on FPGA
for CCM protocol,” in Proc. 25th Int. Conf. Field Program. Log. Appl.
(FPL), Sep. 2015, pp. 1–8.
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
186 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 30, NO. 2, FEBRUARY 2022
[13] X. C. Tao, D. L. Zhang, and Y. K. Song, “An implementation of
configurable and small-area AES IP core oriented Avalon bus,” in Proc.
Int. Conf. Artif. Intell. Ind. Eng., 2015, pp. 173–176.
[14] Get Started With K210: Hardware and Programming Environment.
Accessed: Oct. 26, 2021. [Online]. Available: https://www.seeedstudio.
com/blog/2019/09/12/get-started-with-k210-hardware-and-
programming-environment/
[15] V. B. Y. Kumar, A. Chattopadhyay, J. Haj-Yahya, and A. Mendelson,
“ITUS: A secure RISC-V system-on-chip,” in Proc. 32nd IEEE Int.
Syst.-on-Chip Conf. (SOCC), Sep. 2019, pp. 418–423.
[16] SiFive Shield: An Open, Scalable Platform Architecture for Secu-
rity. Accessed: Oct. 26, 2021. [Online]. Available: https://www.
sifive.com/blog/sifive-shield-an-open-scalable-platform-architecture
[17] Using RISC-V as a Security Processor for Darpa Chips and Commercial
IoT. Accessed: Oct. 26, 2021. [Online]. Available: https://riscv.org/wp-
content/uploads/2017/12/Wed-1430-RISCV-MarkBealV2.pdf
[18] W. Wang, J. Han, X. Cheng, and X. Zeng, “An energy-
efficient crypto-extension design for RISC-V,” Microelectron. J.,
vol. 115, Sep. 2021, Art. no. 105165. [Online]. Available: https://www.
sciencedirect.com/science/article/pii/S0026269221001749
[19] B. Marshall, G. R. Newell, D. Page, M.-J.-O. Saarinen, and C. Wolf,
“The design of scalar AES instruction set extensions for RISC-
V,” IACR Trans. Cryptograph. Hardw. Embedded Syst., vol. 2021,
no. 1, pp. 109–136, Dec. 2020. [Online]. Available: https://tches.
iacr.org/index.php/TCHES/article/view/8729
[20] K. Stoffelen, “Efficient cryptography on the RISC-V architecture,”
in Progress in Cryptology—LATINCRYPT 2019, P. Schwabe and
N. Thériault, Eds. Cham, Switzerland: Springer, 2019, pp. 323–340.
[21] C. Duran, H. Gomez, and E. Roa, “AES sbox acceleration schemes
for low-cost SoCs,” in Proc. IEEE Int. Symp. Circuits Syst. (ISCAS),
May 2021, pp. 1–5.
[22] B. Hettwer, K. Das, S. Leger, S. Gehrer, and T. Guneysu, “Light-
weight side-channel protection using dynamic clock randomization,” in
Proc. 30th Int. Conf. Field-Programm. Log. Appl. (FPL), Aug. 2020,
pp. 200–207.
[23] A. Moradi, A. Poschmann, S. Ling, C. Paar, and H. Wang, “Pushing
the limits: A very compact and a threshold implementation of AES,”
in Advances in Cryptology—EUROCRYPT 2011, K. G. Paterson, Ed.
Berlin, Germany: Springer, 2011, pp. 69–88.
[24] A. G. Bayrak, N. Velickovic, F. Regazzoni, D. Novo, P. Brisk, and
P. Ienne, “An EDA-friendly protection scheme against side-channel
attacks,” in Proc. Design, Autom. Test Eur. Conf. Exhib. (DATE), 2013,
pp. 410–415.
[25] A. A. El-Moursy, A. M. Darya, A. S. Elwakil, A. Jha, and S. Majzoub,
“Chaotic clock driven cryptographic chip: Towards a DPA resistant
AES processor,” IEEE Trans. Emerg. Topics Comput., early access,
Dec. 21, 2020, doi: 10.1109/TETC.2020.3045802.
[26] R. Menicocci, A. Trifiletti, and F. Trotta, “Experiments on two clock
countermeasures against power analysis attacks,” in Proc. 21st Int. Conf.
Mixed Design Integr. Circuits Syst. (MIXDES), Jun. 2014, pp. 215–219.
[27] Security Requirements for Cryptographic Modules,
Standard FIPS 140-2, NIST, 2001.
[28] V. Mavroeidis, K. Vishi, M. D. Zych, and A. Jøsang, “The impact of
quantum computing on present cryptography,” Int. J. Adv. Comput. Sci.
Appl., vol. 9, no. 3, pp. 405–414, 2018.
[29] R. Ueno, N. Homma, Y. Sugawara, Y. Nogami, and T. Aoki, “Highly
efficient GF(28)inversion circuit based on redundant GF arithmetic
and its application to AES design,” in Cryptographic Hardware and
Embedded Systems—CHES 2015 (Lecture Notes in Computer Science),
vol. 9293, T. Güneysu and H. Handschuh, Eds. Berlin, Germany:
Springer, 2015, doi: 10.1007/978-3-662-48324-4_4.
[30] M. Dworkin, NIST Special Pubblication 800-38A, National Institute of
Standards and Technology, 2001.
[31] M. Dworkin, NIST Special Pubblication 800-38B, National Institute of
Standards and Technology, 2005.
[32] M. Dworkin, NIST Special Pubblication 800-38C, National Institute of
Standards and Technology, 2004.
[33] M. Dworkin, NIST Special Pubblication 800-38D, National Institute of
Standards and Technology, 2007.
[34] M. Dworkin, NIST Special Pubblication 800-38E, National Institute of
Standards and Technology, 2008.
[35] F. Zaruba and L. Benini, “The cost of application-class process-
ing: Energy and performance analysis of a Linux-ready 1.7-GHz
64-bit RISC-V core in 22-nm FDSOI technology,” IEEE Trans. Very
Large Scale Integr. (VLSI) Syst., vol. 27, no. 11, pp. 2629–2640,
Nov. 2019.
[36] CRYPT-IP-120 AES Crypto, Rambus. Accessed: Jun. 4, 2021. [Online].
Available: https://www.rambus.com/security/crypto-accelerator-
hardware-cores/basic-crypto-blocks/crypt-ip-120/
[37] AES Cryptographic IP, EnSilica. Accessed: Jun. 4, 2021. [Online].
Available: https://www.ensilica.com/ip/esi-crypto/aes/
[38] S. K. Mathew et al., “53 Gbps native GF(24)2composite-field AES-
encrypt/decrypt accelerator for content-protection in 45 nm high-
performance microprocessors,” IEEE J. Solid-State Circuits, vol. 46,
no. 4, pp. 767–776, Apr. 2011.
[39] G. Sayilar and D. Chiou, “Cryptoraptor: High throughput reconfigurable
cryptographic processor,” in Proc. IEEE/ACM Int. Conf. Comput.-Aided
Design (ICCAD), Nov. 2014, pp. 155–161.
[40] L. Zulberti, P. Nannipieri, and L. Fanucci, “A script-based cycle-true
verification framework to speed-up hardware and software co-design
of system-on-chip exploiting RISC-V architecture,” in Proc. 16th Int.
Conf. Design Technol. Integr. Syst. Nanosc. Era (DTIS), Jun. 2021,
pp. 1–6.
[41] K. Shahbazi and S.-B. Ko, “Area-efficient nano-AES implementation
for Internet-of-Things devices,” IEEE Trans. Very Large Scale Integr.
(VLSI) Syst., vol. 29, no. 1, pp. 136–148, Jan. 2021.
[42] S. N. Dhanuskodi, S. Allen, and D. E. Holcomb, “Efficient register
renaming architectures for 8-bit AES datapath at 0.55 pJ/bit in 16-nm
FinFET,” IEEE Trans. Very Large Scale Integr. (VLSI) Syst., vol. 28,
no. 8, pp. 1807–1820, Aug. 2020.
[43] M. Masoumi, “Novel hybrid CMOS/memristor implementation of the
AES algorithm robust against differential power analysis attack,” IEEE
Trans. Circuits Syst. II, Exp. Briefs, vol. 67, no. 7, pp. 1314–1318,
Jul. 2020.
Authorized licensed use limited to: University of Pisa. Downloaded on December 01,2023 at 15:09:42 UTC from IEEE Xplore. Restrictions apply.
