Securing Network-on-Chip Using Incremental Cryptography

Subodha Charles and Prabhat Mishra

Department of Computer and Information Science and Engineering
University of Florida, Gainesville, Florida, USA

Abstract—Network-on-chip (NoC) has become the standard Threat Model: Figure 1 shows a typical NoC-based
communication fabric for on-chip components in modern many-core architecture which encrypts packets transferred
System-on-chip (SoC) designs. Since NoC has visibility to all between IP cores. When packets are sent through the NoC,
communications in the SoC, it has been one of the primary
targets for security attacks. While packet encryption can a router infected by a hardware Trojan can copy or re-route
provide secure communication, it can introduce unaccept- packets and send to a malicious IP sitting on the same
able energy and performance overhead due to the resource- NoC to leak sensitive information. Therefore, our model
constrained nature of SoC designs. In this paper, we propose assumes that some of the IPs, as well as the routers, can
a lightweight encryption scheme that is implemented on the be malicious. The IPs that we can trust to be non-malicious
network interface. Our approach improves the performance of
encryption without compromising security using incremental are referred to as secure IPs. The goal is to ensure secure
cryptography, which exploits the unique NoC traffic charac- communication between these secure IPs. We assume that
teristics. Experimental results demonstrate that our proposed network interfaces (NI) that connect IPs with routers are
approach significantly (up to 57%, 30% on average) reduces secure. This assumption is valid since the NIs are used to
the encryption time compared to traditional approaches with integrate components of an SoC and are typically built in
negligible (less than 2%) impact on area overhead.
house. A similar threat model and assumptions have been
Keywords-system-on-chip; network-on-chip; security used in previous work on NoC security, proving the validity
of the model [10; 11].
I. I NTRODUCTION

With the growing demand for high-performance and low-

power designs, multi-core architectures are widely used in
general purpose chip multiprocessors as well as special
purpose system-on-chip (SoC) designs [1; 2]. The desired
performance improvement of multi-core architectures cannot
be fully achieved by parallelizing the applications unless an
efficient interconnect is used to connect all the heteroge-
neous components on the chip. Network-on-chip (NoC) has
become the standard interconnect solution [3; 4]. Due to Figure 1: NoC based many-core architecture connecting IPs
increasing SoC complexity, it is crucial to develop efficient on a single SoC using a 4 × 4 Mesh topology. Each node
NoC fabrics [5]. The importance of the information passing contains an IP that connects to a router via a network
through the NoC has made it one of the focal points of interface. Communication between two IPs (in this case, a
security attacks. Diguet et al. have classified the major NoC processor IP and a memory controller) is encrypted so that
security vulnerabilities as denial of service attack, extraction an eavesdropper cannot extract the packet content.
of secret information, and hijacking [6]. Typically, SoCs con-
tain several assets (e.g., encryption and authentication keys, Prior research on security architectures have explored
random numbers, configuration keys, and sensitive data) that trust-zones [12; 13], lightweight encryption [14], DoS attack
reside in different Intellectual Property (IP) cores [7; 8]. detection [15; 16], side channel analysis [17; 18], etc.
Protecting communications between IPs, which involve asset However, none of the existing approaches have leveraged
propagation, is a major challenge and requires additional the unique traffic characteristics of an NoC to design a
hardware implementing security such as on-chip encryp- lightweight security architecture. In this paper, we utilize
tion and authentication units. However, implementation of incremental encryption to encrypt packets in NoC. Our pro-
security features introduce area, power and performance posed solution takes advantage of the unique characteristics
overhead. Security engineers have to take into account these of NoC traffic, and as a result, it has the ability to construct
non-functional and real-time constraints while designing a “lighter-weight” encryption scheme without compromising
secure architectures to address various threats [9]. The threat the security. Incremental cryptography has been explored
model we use in this paper is as follows: in areas such as software virus protection [19] and code
obfuscation [20]. To the best of our knowledge, our approach function (E) that takes a β-bit key (K) and an n-bit plaintext
is the first attempt to utilize incremental encryption to imple- (m) and outputs an n-bit long ciphertext (c). The values
ment a lightweight and secure NoC architecture. The goal of of β and n depend on the design and are fixed for a
n
using incremental encryption is to design cryptographic al- given block cipher. For every c ∈ {0, 1} , there is exactly
n
gorithms that can reduce the effort of encryption/decryption one m ∈ {0, 1} such that EK (m) = c. Accordingly,
−1
by reusing the previously encrypted/decrypted memory fetch EK has an inverse block cipher denoted by EK such
−1 −1
requests/responses rather than re-computing them from the that EK (EK (m)) = m and EK (EK (c)) = c for all
n
scratch. In our framework, data is encrypted at the NI of m, c ∈ {0, 1} .
each secure IP core. The NI is chosen to accommodate the
encryption framework so that each packet can be secured
before injecting into the NoC. Prior research on NoC secu-
rity have proposed similar architectures where the security
framework was implemented at the NI [11; 21]. Our major
contributions are as follows:
• We show that consecutive NoC packets that contain
memory fetch requests/responses differ only by a few
bits while communicating between IP cores and mem-
ory controllers in an SoC. Figure 2: A block cipher-based encryption scheme using
• We propose a lightweight encryption scheme based on counter mode. Each block cipher (EK ) encrypts an n-bit
incremental cryptography that exploits the unique NoC block (mq ) and b block ciphers together encrypt the entire
traffic characteristics observed above. message M and outputs ciphertext C. This constructs E of
• We show that our solution is resilient against existing the encryption scheme S.
NoC attacks, and it significantly improves the per-
formance compared to state-of-the-art NoC encryption When using block ciphers to encrypt long messages, the
methods. plaintext (M ) of a given length l is divided into b substrings
The rest of the paper is organized as follows. Section (mq ) where each substring is n(= bl ) bits long and n is
II presents prior research efforts. Section III motivates the called the block size. Block ciphers are used in operation
need for our work. Section IV describe our approach for modes where one or more block ciphers work together to
lightweight encryption. Section V presents the experimental encrypt n-bit blocks and concatenate the outputs at the end
results. Finally, Section VI concludes the paper. to create the ciphertext of l bits. Figure 2 shows the counter
mode (CM) which is a popular operation mode. CM also
II. BACKGROUND AND R ELATED W ORK uses an initialization vector (IV) which is concatenated with
In this section, we first provide a brief overview of a d-bit value counter (e.g., if d = 4, {1}d = 0001) before
concepts used in this paper and present the related research inputting to the block cipher. This is done to create domain
efforts to highlight the novelty of our proposed work. separation by giving per message and per block variability.
The decryption process is shown in Algorithm 1. In fact, the
A. Symmetric Encryption Scheme
decryption process would be the inverse of the encryption
A symmetric encryption scheme S = (K, E, D) consists scheme shown in Figure 2.
of three algorithms defined as follows:
• The key generation algorithm is written as K ← K. Algorithm 1 - Decryption process of Counter Mode
This denotes the execution of the randomized key Inputs: ciphertext to decrypt C
generation algorithm K and storing the return string Output: plaintext corresponding to the ciphertext M
as K where β is the length of the key. Procedure: DK
• The encryption algorithm E produces the ciphertext 1: for all q = 1, ..., b do
l
C ∈ {0, 1} by taking the key K and a plaintext 2: rq ← EK (IV ||{q}d )
l
M ∈ {0, 1} as inputs, where l is the length of the 3: mq ← rq ⊕ cq
plaintext. This is denoted by C ← EK (M ). 4: M ← m1 k m2 k ... k mb
• Similarly, the decryption algorithm D denoted by M ←
l 5: return M
DK (C), takes a key K and a ciphertext C ∈ {0, 1}
l
and returns the corresponding M ∈ {0, 1} .
C. Incremental Cryptography Overview
B. Block Ciphers Consider a scenario that involves encrypting sensitive
A block cipher typically acts as the fundamental building files/documents. Once a file is encrypted initially, there may
block of the encryption algorithm (E). Formally, it is a be minor changes in the original file. In such a scenario, if
typical encryption is used, the previous encrypted file will best of our knowledge, incremental cryptography has not
be discarded and a new encryption will be performed on been used to encrypt/decrypt NoC packets. We propose a
the modified file. However, since these changes are very technique that is able to use incremental encryption in the
small in comparison to the size of the file, encrypting the domain of NoC and can increase the efficiency of secure
entire file again is clearly inefficient. Incremental encryp- NoCs.
tion can give significant advantages in such a setup [22].
Updating an obfuscated code to accommodate patches and III. M OTIVATION
video transmission of images when there are minor changes The IPs use the capabilities given by the NoC to com-
between frames, are two similar scenarios [20]. Incremental municate with each other and to request/store data from/in
encryption allows to find the cryptographic transformation memory. The packets injected into the network can be
of a modified input not from scratch, but as a function of the classified into two main categories - (1) control packets
encrypted version of the input from which the modified input and (2) data packets. For example, a cache miss at an IP
was derived. When the changes are small, the incremental will cause a control packet to be injected into the network
method gives considerable improvements in efficiency. requesting for that data from the memory. The memory
controller, upon receiving the request will reply back with
D. Related Work a data packet containing the cache block corresponding to
Adhering to the tight power budgets and cost con- the requested address. The formats of these packets are
straints, industrial and academic researchers are coming up shown in Figure 3. The NI divides the packet into flits
with lightweight security primitives specific for domains (fliticization) before injecting into the network. Flits are
such as NoC-based SoCs, RFID communication and IoT. the basic building blocks of information transfer between
Lightweight security architectures for NoC-based SoCs were routers. Sensitive data of each flit is encrypted by the NI and
proposed in [23; 11]. These methods try to eliminate com- injected into the network through the local router. Encryption
plex encryption schemes such as AES and replace them with process of a packet consumes time as each block has to be
lightweight encryption schemes. However, these methods encrypted and concatenated to create the encrypted packet.
encrypt each block in a packet which leads to significant Depending on the parameters used for the block cipher
performance penalty. Intel introduced TinyCrypt - a crypto- (block size, key size, number of encryption rounds, etc.),
graphic library with a small footprint which is built for con- the time complexity of the process differs. If each packet
strained embedded and IoT devices [14]. Several researchers is encrypted independently, it takes z × T time to encrypt
have proposed other lightweight encryption solutions in the all of them, where z is the number of packets and T is the
IoT domain [24]. Exploiting the unique characteristics of average time needed to encrypt one packet.
RFID communication, Engels et al. have proposed a low-
cost encryption algorithm and a protocol [25]. None of these
security architectures exploit the unique communication
characteristics in NoC-based SoCs. Our approach utilizes
incremental encryption to create a lightweight NoC security
framework that minimizes performance overhead with minor
impact on area and power.
Bellare et al. [19] used incremental encryption to encrypt
files/documents undergoing minor changes. Rather than en- Figure 3: Packet formats for control and data packets. Blue
crypting every file from scratch after each change, they shows header (H) which is sent as plaintext. Red shows the
proposed to encrypt only the change(s) and send it together payload (P) with sensitive data encrypted.
with the previous encryption such that the encryption of the
modified version can be constructed. There are fundamental As discussed in Section II, the idea of incremental en-
challenges when using incremental encryption to encrypt cryption is to develop a scheme where the time taken to
packets in the NoC. In the file setup, when a file undergoes encrypt an incoming packet should not be dependent on the
some number of modifications, every previous modification packet size, but rather on the amount of modifications done
becomes redundant. In other words, intermediate steps lose compared to the previous packet. To explore how to use
their values as long as the latest version is available. How- this idea in the context of NoC, we profiled the number
ever, when encrypting packets in the NoC, we cannot drop of bit changes between consecutive packets generated by a
certain packets and encrypt after some modifications because particular IP. Figure 4 shows the number of bit differences
each packet is important for the correct functionality of as a percentage of memory fetch requests (control packets)
the SoC. Ideas from incremental cryptography have been when running five benchmarks (FFT, FMM, LU, RADIX,
adopted in other areas such as hashing and signing [22], OCEAN) from the SPLASH-2 benchmark suite on the
program obfuscation [20] and cloud computing [26]. To the gem5 full-system simulator [27]. More details about the
experimental setup is given in Section V-A. Out of the the changed blocks. The decryption process uses previously
64 bits of data to be encrypted, according to the default received packets and header information to reconstruct the
gem5 packet size, the maximum number of bit difference new packets. Only the first packet has to be fully encrypted
between consecutive packets was 13 bits in all benchmarks. since there is no prior packet for comparison. This example
On average, 30% of the packets differed by only one bit. shows a speedup of 1.43 times. However, when many
This is expected since an application running on a core most packets are encrypted, the time spent to encrypt the first
likely accesses memory locations within the same memory packet becomes negligible and as a result, we observe a
page which differs by only a few bits. significant performance improvement as shown in Section
V-B. A detailed description of the methodology is given in
the next three subsections.

Figure 4: Number of bit differences between consecutive

memory fetch requests in SPLASH-2 benchmarks.

Since encryption is done in blocks, we profiled this data

assuming a block size of 16 bits [25]. In this case, up to
16 consecutive bit differences can be considered for each
block, and the maximum number of blocks for 64 bits of
secure data is 4. The results showed that on average, 80% Figure 5: Illustrative example of using incremental encryp-
of the packets differ by only one block and the other 20% tion. Assumptions: encryption takes 20 cycles for each block
differ by two blocks for the benchmarks we used. Similar cipher, comparing two bit strings to identify different blocks
to memory fetch requests, we profiled the response memory take 1 cycle each.
data packets as well. Since the response contains a whole
cache block consisting of data modified by calculations, we
A. Overview
don’t observe the same optimization opportunity shown by
memory fetch requests. However, it still shows that 15% of Figure 6 shows an overview of our proposed NoC se-
consecutive packets are identical. These observations show curity framework. It consists of two main components: (i)
that the encryption process can be significantly optimized incremental crypto engine, and (ii) encryption scheme which
using incremental encryption. includes the block ciphers. Each packet sent from an IP
core has two main parts: (i) packet header (H) which is sent
IV. I NCREMENTAL E NCRYPTION as plaintext across the network, and (ii) payload (P) which
This section describes our incremental encryption scheme should be encrypted before sending to the network. Both
in detail. First, we give an illustrative example to demon- header and payload are sent to the incremental crypto engine
strate the merit of exploiting unique traffic characteristics to start the incremental encryption process. We consider
using incremental encryption. Then we elaborate the major the payload to be divided into b blocks. For example, the
components in our framework. 64-bit payload of a control packet will contain four 16-bit
Illustrative example: Figure 5 shows an example on how blocks (b = 4) numbered 1 through 4 starting from the least
incremental encryption can improve the performance of an significant byte. Our encryption scheme uses block ciphers
NoC. It shows the encryption process of three consecutive arranged in counter mode [28]. A detailed explanation of
NoC packets (each with 16 bits) using two methods (i) parameters used in our experiments is given in Section V-A.
traditional encryption, (ii) incremental encryption. In tradi- Algorithm 1 describes our incremental encryption process.
tional encryption, both packets are encrypted sequentially When a packet is sent from the IP core, the incremental
using the two 8-bit block ciphers. In incremental encryption, crypto engine first identifies which blocks are different
each packet is compared with the previous packet and compared to the previous packet (line 3). This is done by
only the different blocks are encrypted. Identical blocks comparing with the previous packet payload (Pi−1 ) which
are filled with zeros and header bits are added to indicate is stored in a register inside the NI. In our model, only two
Figure 6: Overview of our proposed security framework. The packet sent from source (IPs ) goes through the encryption
process implemented in the network interface (N Is ). It traverses the NoC, and N It of the target IP (IPt ) decrypts before
forwarding the packet to IPt .

packets are required to be stored for the two different packet B. Incremental Crypto Engine
types (control and data) at the sender’s end. Similarly, the The operation of the incremental crypto engine is outlined
receiver’s side also stores the most recent packet for each in Algorithm 2. The payload (Pi ) sent from the IP core
packet type. In addition to that, the key (K) and initialization is compared with the previous payload of that type (Pi−1 )
vector (IV ) for the encryption scheme are also stored to identify the blocks that are different (Mi ). This can be
by both sender and receiver IPs. Once block differences implemented with a simple XOR operation in hardware (line
are computed, it is then sent to the encryption scheme 1). Once the bitwise differences are obtained, we split the
which encrypts only the different blocks (line 4). The final payload into blocks (line 2) to see which blocks are different
ciphertext is derived from the encrypted blocks and block (lines 3-6). Only different blocks are sent for encryption.
comparison results (line 5). Additional header bits are also The incremental crypto engine also sends the different block
computed in this step to be used by the decryption process. numbers (δi ) to build the complete ciphertext as well as to
Finally, the header and encrypted payload are concatenated set the header bits indicating the different blocks to be used
to create the final packet and injected into the network by the decryption algorithm.
(line 6). At the destination node, the inverse process takes
place. It also stores the previous packet for each packet Algorithm 2 - Finding Block-wise Packet Differences
type, and therefore, can construct the next packet using the Inputs: current payload Pi , previous payload Pi−1
stored packet and the incoming packet data. Since we store Output: different blocks Mi , different block indices δi
the previous packets in special registers, we don’t have to Procedure: compareBlocks
encrypt/decrypt the full packet. We send only the changed 1: bitDif f ← Pi ⊕ Pi−1
blocks and the receiver replaces the changed blocks with its 2: B[1], ..., B[k] ← split(bitDif f, blockSize)
modifications to construct the new packet. 3: for all x = 1, ..., size(B) do
4: if B[x] > 0 then
Algorithm 1 - Encryption Process
5: Mi .append(B[x])
Inputs: current packet packeti , previous payload Pi−1 , key 6: δi [x] = 1
K, initialization vector IV 7: return Mi , δi
Output: encrypted packet consisting of header Hi and en-
crypted payload Ci
Procedure: encryptP ackets C. Encryption Scheme
1: Pi ← packeti .payload We use the counter mode for encryption which uses
2: Hi ← packeti .header an initialization vector (IV), a key and the message to
3: Mi , δi ← compareBlocks(Pi , Pi−1 ) be encrypted as inputs and produces the ciphertext. The
4: C 0 ← E(IV, K, Mi ) IV k {q}d string, which is the standard format of the input
5: Ci ← constructCipherT ext(C 0 , δi ) nonce to counter mode, is used to give per message and
6: return Hi k Ci per block variability. In our framework, it is calculated
using the sequence number of the packet (let seqj be the
The remainder of this section elaborates the major compo- sequence number of packet Pj ), a counter, and the IV as
nents of our NoC security framework. Section IV-B explains IV k seqj k q to identify different blocks. The block cipher
the compareBlocks function which is implemented in the ID (q ∈ {1, 2, 3, 4}) changes with each block cipher and
incremental crypto engine. Section IV-C presents our en- the sequence number seqj varies from packet to packet. As
cryption scheme E and constructCipherT ext function in discussed before, the performance improvement is gained
Algorithm 3 and Algorithm 4, respectively. by encrypting multiple blocks in parallel. For example, if
two consecutive control packets have differences in two were generated by the cycle-accurate full-system simulator
blocks each, we can achieve twice the speedup by encrypting - gem5 [27]. The 4x4 Mesh NoC was built on top of
both at the same time compared to the traditional (non- “GARNET2.0” model that is integrated with gem5 [31].
incremental) approach where all four block ciphers will be We modified the network interface (NI) to simulate the
used to encrypt each packet. Algorithm 3 shows the major proposed security framework. We selected the following
steps of the encryption scheme. options to simulate architectural choices in a resource-
constrained NoC.
Algorithm 3 - Encrypt Selected Blocks
Packet format: For control and data packet formats,
Inputs: initialization vector IV , key K, we used the default GARNET2.0 implementations which
different blocks Mi allocates 128 bits for a flit. This value results in control
Output: encrypted blocks C 0 messages fitting in 1 flit, and data packets, in 5 flits. Out of
Procedure: E the 128 bits, 64 bits are allocated for the payload (address)
1: for all q = 1, ..., 4 do in a control packet and data packets have a payload of 576
2: seqj ← getSequenceN umber(Pj ) bits (64-bit address and 512-bit data). This motivated the use
3: rq ← EK (IV k seqj k q) of 16-bit blocks to evaluate the performance of our proposed
4: C 0 .append(rq ⊕ Mi [q]) incremental encryption scheme.
5: return C 0 Block cipher: We use an ultra-lightweight block cipher
- Hummingbird-2 as the block cipher of our encryption
C 0 is stored in a buffer. The final ciphertext is constructed scheme [25]. Hummingbird-2 was chosen in our experiments
using δi and C 0 as shown in Algorithm 4. Algorithm 4 takes mainly because it is lightweight and also, with the block
the encrypted value from the buffer for the changed blocks size being 16, other encryption schemes can be broken using
(lines 2-3) and appends n (block size) zeros to identical brute-force attacks in such small block sizes. However, it has
blocks compared to the previous packet (lines 4-5). It ensures been shown in [25] that Hummingbird-2 is resilient against
the construction of the same packet size, and as a result, attacks that try to recover the plaintext from ciphertext. It
every other functionality from fliticization to NoC traversal uses a 128-bit key and a 128-bit internal state which provides
remains the same. adequate security for on-chip communication. Considering
Algorithm 4 - Construct the Encrypted Payload the payload and block sizes, we used four block ciphers
in counter mode for our encryption scheme. Each block
Inputs: encrypted blocks C 0 , different block indices δi
cipher is assumed to take 20 cycles to encrypt a 16-bit
Output: Encrypted payload Ci
block and each comparison of two-bit strings incurs a 1-
Procedure: constructCipherT ext
cycle delay [25]. Our framework is flexible to accommodate
1: for all x = 1, ..., size(δ) do
different packet formats, packet sizes and block ciphers
2: if δi [x] > 0 then depending on the design requirements. For example, if a
3: Ci .append(C 0 [x]) certain architecture requires 128-bit blocks, AES can be used
4: else while keeping our incremental encryption approach intact.
5: Ci .append({0}n )
6: return Ci B. Performance Evaluation
We present the performance improvement achieved by
To ensure the secure implementation of our approach, the
our approach in two steps: (i) time taken for encryption
generation and management of keys and nonces needs to be
(Figure 7) and (ii) execution time (Figure 8). We measured
addressed. However, this is beyond the scope of this paper
the cycles spent for encryption alone (encryption time) and
and many previous studies have addressed this problem in
total cycles executed to run the benchmark (execution time)
several ways [29; 30].
including encryption time, using our approach as well as
V. E XPERIMENTS traditional encryption. Figure 7 shows the encryption time
In this section, we first describe the experimental setup comparison. Our approach improves the performance of
used to evaluate our approach. Then, results are presented encryption by 57% (30% on average) compared to the
to show the performance gain achieved through incremental traditional encryption schemes. The locality in data and the
encryption by comparing it with traditional encryption. Next, differences in operand values affect the number of changed
we discuss the security of the proposed framework and blocks between consecutive packets. This is reflected in the
associated overhead. encryption time. For example, if an application is doing an
image processing operation on an image stored in memory,
A. Experimental Setup accessing pixel data stored in consecutive memory locations
We validated our framework using five benchmarks cho- provides an opportunity for performance gain using our
sen from the SPLASH-2 benchmark suite. Traffic traces approach.
 the design, nor access to known plaintext/ciphertext pairs. In
other words, as long as the block cipher and operation mode
is secure, incremental encryption doesn’t allow recovering
of plaintext from the ciphertext. The same argument has
been proven to hold true in previous work on incremental
encryption [19; 32].
Figure 7: Encryption time comparison using traditional Counter mode encryption: Using our approach, each
encryption and incremental encryption (our approach). block is treated independently while encrypting, and blocks
belonging to multiple packets can be encrypted in parallel.
In such a setup, using the same IV k {q}d string with the
We also compare the total execution time using traditional same key K can cause the “two time pad” situation. This
encryption as well as incremental encryption. Figure 8 is solved by setting the string to IV k seqj k q as shown in
presents these results. When the overall system including Algorithm 3. It gives per message and per block variability
CPU cycles, memory load/store delays and delays traversing and ensures that the value is a nonce. Our proposed usage
the NoC is considered, the total execution time improves of counter mode adheres to the security recommendations
upto 10% (5% on average). Benchmarks that have significant outlined in [28].
NoC traversals such as RADIX and OCEAN show higher Block cipher: As discussed above, the security of the
performance improvement (10%). proposed framework depends on the security of the block ci-
pher. The security of the block cipher used in our framework,
Hummingbird-2, has been discussed extensively in [25]. The
first version of the Hummingbird scheme was shown to be
insecure [33] and Hummingbird-2 was developed to address
the security flaws. After thousands of hours of cryptanal-
ysis, no significant flaws or sub-exhaustive attacks against
Hummingbird-2 have been found [25]. Hummingbird-2 ap-
Figure 8: Execution time comparison using traditional en- proach has been shown to be resilient against birthday
cryption and incremental encryption (our approach). attacks on the initialization, differential cryptanalisys, linear
cryptanalisys and algebraic attacks. Zhang et al. presented
a related-key chosen-IV attack against Hummingbird-2 that
C. Security Analysis recovered the 128-bit secret key [34]. However, the attack
When discussing the security of our approach, three requires 228 pairs of plaintext to recover the first 4 bits of
main components have to be considered: (i) incremental the key adding up to a data complexity of O(232.6 ) [34]. As
encryption, (ii) encryption scheme that uses counter mode, discussed before, launching such chosen plaintext attacks is
and (iii) block cipher. not possible in the NoC setting. A brute force key recovery
Incremental encryption: Due to the inherent character- takes 2128 attempts which is not computationally feasible
istics of incremental encryption, our approach reveals the according to modern computing standards as well as for
amount of differences between consecutive packets. Studies computing power in the foreseeable future.
on incremental encryption have shown that even though Our proposed approach allows easy plug-and-play of
hiding the amount of differences is not possible, it is possible security primitives. Any block size/key size/block cipher
to hide “everything else” by using secure block ciphers can be combined with our proposed incremental encryption
and secure operation modes [19]. Attacks on incremental approach. Note that stronger security comes at the expense
encryption using this vulnerability relies on the adversary of performance. Therefore, security parameters can be de-
having many capabilities in addition to the ones defined cided depending on the desired security and performance
in the threat model. When using incremental encryption to requirements.
encrypt documents undergoing frequent, small modifications
as explained in Section II, it is reasonable to assume that D. Overhead Analysis
the adversary not only has availability to the previously We implemented our proposed incremental encryption
encrypted versions of documents but is also able to modify approach using Verilog to show the area overhead in com-
documents and obtain encrypted versions of the modified parison with the original Hummingbird-2 implementation.
ones. This attack model allows the adversary to launch Our implementation is capable of assigning blocks to idle
chosen plaintext attacks [19]. Discussing security of our block ciphers and encrypting up to four payloads in parallel.
approach for known plaintext, chosen plaintext and chosen Merger and scheduler units were implemented to ensure
ciphertext attacks are irrelevant in our design since the the correctness of final encrypted/decrypted payloads. We
adversary doesn’t have access to an oracle that implements conducted our experiments using the Synopsys Design Com-
piler with 90nm Synopsis library (saed90nm). Based on [8] P. Mishra, S. Bhunia, and M. Tehranipoor, Hardware IP
our results, our proposed approach introduces less than 2% security and trust. Springer, 2017.
overall area overhead with respect to the entire NoC. When [9] S. Charles et al., “Lightweight anonymous routing in noc
based socs,” in DATE, 2020.
only the encryption unit is considered, the overhead is 15%.
[10] D. M. Ancajas et al., “Fort-NOCs: Mitigating the threat of a
This overhead is caused due to components responsible compromised NoC,” in DAC, 2014.
for buffering and scheduling of modified blocks to idle [11] J. Sepúlveda et al., “Towards Protected MPSoC Communi-
block cipher units as well as computations related to the cation for Information Protection against a Malicious NoC,”
construction of the final result. Therefore, our proposed Procedia computer science, 2017.
encryption approach has a negligible area overhead and it [12] J. Winter, “Trusted computing building blocks for embedded
can be efficiently implemented as a lightweight security linux-based arm trustzone platforms,” in STC, 2008.
[13] S. Charles and P. Mishra, “Lightweight and trust-aware rout-
mechanism for NoCs. While there is a minor increase in ing in noc based socs,” ISVLSI, 2020.
power overhead due to the additional components, there is no [14] “Using TinyCrypt Library, Intel Developer Zone, Intel, 2016.”
penalty on overall energy consumption due to the reduction https://software.intel.com/en-us/node/734330, [Online].
in execution time. [15] S. Charles et al., “Real-time detection and localization of dos
attacks in noc based socs,” in DATE, 2019.
VI. C ONCLUSIONS [16] S. Charles et al., “Real-time detection and localization of
In this paper, we proposed a lightweight security mecha- distributed dos attacks in noc based socs,” TCAD, 2020.
nism that improves the performance of traditional encryption [17] Y. Huang et al., “Scalable test generation for trojan detection
using side channel analysis,” TIFS, vol. 13, no. 11, pp. 2746–
schemes used in NoC while incurring negligible area and
2760, 2018.
power overhead. The security framework consists of an [18] Y. Lyu and P. Mishra, “A survey of side-channel attacks
encryption/decryption scheme that provides secure commu- on caches and countermeasures,” Journal of Hardware and
nication on the NoC. We used incremental encryption to Systems Security, vol. 2, no. 1, pp. 33–50, 2018.
improve performance by utilizing the unique traffic charac- [19] M. Bellare et al., “Incremental cryptography and application
teristics of packets observed in an NoC. We validated our to virus protection,” in STOC, 1995.
framework in terms of security to prove that the performance [20] S. Garg and O. Pandey, “Incremental program obfuscation,”
in CRYPTO, 2017.
gain is not achieved at the expense of security. Experimental
[21] L. Fiorin et al., “A security monitoring service for NoCs,” in
results show a performance improvement of up to 57% CODES+ISSS, 2008.
(30% on average) in encryption time and up to 10% (5% [22] M. Bellare et al., “Incremental cryptography: The case of
on average) in total execution time compared to traditional hashing and signing,” in CRYPTO, 1994.
encryption while introducing less than 2% overall area over- [23] K. Sajeesh and H. Kapoor, “An authenticated encryption
head. In the future, we plan to explore the development of based security framework for NoC architectures,” in ISED,
2011.
an incremental authentication scheme that can be seamlessly
[24] E. R. Naru et al., “A recent review on lightweight cryptogra-
integrated with the incremental encryption scheme to ensure phy in iot,” in I-SMAC, 2017.
data integrity. [25] D. Engels et al., “The Hummingbird-2 lightweight authenti-
cated encryption algorithm,” in RFIDSec. Springer, 2011.
ACKNOWLEDGMENT
[26] W. Itani et al., “Energy-efficient incremental integrity for
This work was partially supported by the National Science securing storage in mobile cloud computing,” in ICEAC,
Foundation (NSF) grant SaTC-1936040. 2010.
[27] N. Binkert et al., “The gem5 simulator,” SIGARCH Computer
R EFERENCES Architecture News, 2011.
[1] S. Charles et al., “Proactive thermal management using [28] D. A. McGrew, “Counter mode security: Analysis and rec-
memory-based computing in multicore architectures,” in ommendations,” Cisco Systems, November, 2002.
IGSC, 2018. [29] B. Lebiednik et al., “Architecting a secure wireless network-
[2] U. Gupta et al., “Dypo: Dynamic pareto-optimal configuration on-chip,” NOCS, 2018.
selection for heterogeneous mpsocs,” TECS, vol. 16, no. 5s, [30] J. Sepulveda et al., “Efficient security zones implementation
pp. 1–20, 2017. through hierarchical group key management at noc-based
[3] S. Charles et al., “Exploration of memory and cluster modes mpsocs,” Microprocessors and Microsystems, 2017.
in directory-based many-core cmps,” in NOCS, 2018. [31] N. Agarwal et al., “Garnet: A detailed on-chip network model
[4] A. Sodani et al., “Knights landing: Second-generation intel inside a full-system simulator,” in ISPASS, 2009.
xeon phi product,” IEEE MICRO, 2016. [32] I. Mironov et al., “Incremental deterministic public-key en-
[5] S. Charles et al., “Efficient cache reconfiguration using cryption,” in EUROCRYPT. Springer-Verlag, 2012.
machine learning in noc-based many-core cmps,” TODAES, [33] M. J. O. Saarinen, “Cryptanalysis of hummingbird-1,” in FSE.
vol. 24, no. 6, pp. 1–23, 2019. Springer, 2011.
[6] J.-P. Diguet et al., “NOC-centric security of reconfigurable [34] K. Zhang, L. Ding, and J. Guan, “Cryptanalysis of
SoC,” in NOCS, 2007. hummingbird-2,” Cryptology ePrint Archive, Tech. Rep.,
[7] F. Farahmandi, Y. Huang, and P. Mishra, System-on-Chip 2012.
Security: Validation and Verification. Springer Nature, 2019.