## Runtime Mitigation of Packet Drop Attacks in Fault-tolerant Networks-on-Chip

N. PRASAD, NAVONIL CHATTERJEE, SANTANU CHATTOPADHYAY, and INDRAJIT CHAKRABARTI, Indian Institute of Technology Kharagpur

Fault-tolerant routing (FTR) in Networks-on-Chip (NoCs) has become a common practice to sustain the performance of multi-core systems with an increasing number of faults on a chip. On the other hand, usage of third-party intellectual property blocks has made security a primary concern in modern day designs. This article presents a mechanism to mitigate a denial-of-service attack, namely packet drop attack, which may arise due to the hardware Trojans (HTs) in NoCs that adopt FTR algorithms. HTs, associated with external kill switches, are conditionally triggered to enable the attack scenario. Security modules, such as authentication unit, buffer shuffler, and control unit, have been proposed to thwart the attack in runtime and restore secure packet flow in the NoC. These units work together as a shield to safeguard the packets from proceeding towards the output ports with faulty links. Synthesis results show that the proposed secure FT router, when compared with a baseline FT router, has area and power overheads of at most 4.04% and 0.90%, respectively. Performance evaluation shows that SeFaR has acceptable overheads in the execution time, energy consumption, average packet latency, and power-latency product metrics when compared with a baseline FT router while running real benchmarks, as well as synthetic traffic. Further, a possible design of a comprehensive secure router has been presented with a view to addressing and mitigating multiple attacks that can arise in the NoC routers.

Additional Key Words and Phrases: Packet drop attack, hardware Trojans, link faults, Network-on-Chip, security

## ACMReference format:

N. Prasad, Navonil Chatterjee, Santanu Chattopadhyay, and Indrajit Chakrabarti. 2016. Runtime Mitigation of Packet Drop Attacks in Fault-tolerant Networks-on-Chip. 1, 1, Article 1 (January 2016), 23 pages. DOI: 10.1145/nnnnnnn.nnnnnnn

## 1 INTRODUCTION

Network-on-Chip (NoC) has emerged as a promising and scalable medium for interconnecting various cores in a multi-core system [21]. However, with aggressive technology scaling, as well as an increase in the transistor density, multi-core systems are subjected to faults that may occur either during the manufacturing time or runtime. NoCs, being part of such multi-core systems, are also susceptible to these faults. Several fault-tolerant techniques have been developed over the years to overcome the consequences that may arise due to the occurrence of faults in NoCs [26, 31]. As mentioned in [26], the adopted fault-tolerant techniques differ with different layers of the NoC-based multi-core system, such as transport, network, and data-link. Further, in the network layer, which consists of components such as routers and links, fault-tolerant mechanisms are realized through spatial and temporal redundancy techniques. These techniques include redundant modules inside the routers, as well as fault-tolerant routing algorithms in the NoC.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

© 2016 ACM.

XXXX-XXXX/2016/1-ART1 $15.00

On the other hand, with the ever-increasing complexity of multi-core systems to process diverse tasks, the role of third-party intellectual property (3PIP) cores is increasingly becoming prominent in such systems. With so many 3PIP cores at hand during the system integration, there exists a barrier of security and trust among the 3PIP vendors that tempts the adversaries to adopt unfair means to disrupt the functionality of the other 3PIP cores. One way of achieving such an unsought disruption is through the insertion of hardware Trojans (HTs) into the chip, by an untrusted foundry or design house that include untrusted people, design tools, or components. Consequences of such an uninvited insertion of the HTs include the undesired functional behavior of an integrated circuit (IC) and provision of covert channels or backdoor that can leak sensitive information [5]. Though several detection techniques, to detect HTs, have been proposed in the literature [4], they may not be advantageous for all kinds of HTs present on a chip. Thus, the proactive security measures at the hardware level are increasingly being considered, which can improve the detection capability, as well as mitigate the consequences that arise due to the HTs.

Packet drop attack is similar to a well-known denial-of-service (DoS) attack in a network router, namely blackhole attack, where the router, instead of relaying the packets to proper output ports, discards them [2, 30]. Similar attack scenario can be achieved in NoCs with faulty links, where a router with faulty links, instead of sending packets to ports with healthy links, forwards the packets to ports with faulty links. This scenario is same as dropping the packets by a router, as it is unable to relay them to the next router. Since this case would arise in NoCs in the presence of faulty links, existing mitigation mechanisms for packet drop attacks in the case of wireless or mobile networks may not be advantageous for NoCs. Existing methods to mitigate the packet drop attack in wireless ad hoc and mobile networks, such as routing recovery, time-based threshold, and Bayesian detection, cost a lot concerning area and energy consumption when considered for NoC routers [12, 30]. Thus, to mitigate the packet drop attacks in FTNoCs, we endow the routers with security modules, such as authentication unit (AU), buffer shuffler (BS), and control unit (CU). The proposed logic-based mitigation mechanism is advantageous when compared to the above-mentioned mechanisms while considering the hardware and timing overheads into account.

As the NoC forms the backbone of the interconnection architecture of a multi-core system, there is an immense need in securing its hardware resources, as well as to secure the packet flow in it. Hardware security in NoCs has been a vibrant research area for over a decade [13, 16]. Traditionally, research in secure NoCs has focused on the areas like secure memory access, memory protection, and secure packet flow, in NoC-based multi-core systems [14, 19, 27]. Of late, research in several attacks on NoC hardware, such as attacks due to HTs on routers [3, 7, 15, 17, 25] and links [8, 9], as well as timing side-channel attacks [29], are being investigated. All the works mentioned in the literature assume that the NoC is a fault-free one. Security aware design of FTNoCs has not been explored to date. With the introduction of faults, many possibilities arise for the adversaries to take advantage of such scenarios to raise new attacks in the NoC. This article proposes one such attack called packet drop attack in the context of FTNoCs and presents a mitigation mechanism to thwart such attacks effectively.

The main contributions of the present article are as follows. A mechanism to raise packet drop attacks in the context of fault-tolerant NoCs has been presented. In the current study, we assume that fault-tolerant routing is the fault-tolerant method adopted in the NoC. A possible threat model, as well as design of hardware Trojan that has the potential to raise the packet drop attacks, has been proposed. A secure fault-tolerant NoC router, referred to as SeFaR, has been presented to thwart the packet drop attacks at runtime. Experimental analysis for establishing the impact of the proposed attack, as well as for analyzing the performance of the system in the presence of the

proposed secure router, has been presented. A possible design of a comprehensive secure router has been presented, which can mitigate multiple attacks that can arise in the NoC routers.

The rest of the article is organized as follows. Section 2 discusses the related work. Section 4 presents motivation behind the packet drop attack, proposes the threat model, and discusses its relevance. Section 3 briefly describes the architecture of the baseline fault-tolerant router. Section 5 describes the security modules including the authentication unit, buffer shuffler, and the control unit. Section 6 presents the performance analysis of the mitigation mechanisms. Section 7 presents the architecture of a comprehensive secure router, which can mitigate multiple attack scenarios that arise within the NoC routers. Section 8 concludes the article.

## 2 RELATED WORK

This Section articles out the related work that has been carried out in the areas of fault-tolerant routing, as well as hardware attacks on the NoC architecture, particularly within routers and links.

## 2.1 Fault-tolerant Routing in NoCs

Several fault-tolerant techniques have been extensively reviewed in [31], which also include faulttolerant routing algorithms for the NoCs. Majority of the fault-tolerant routing strategies consider distributed routing, whereas very few strategies consider source routing. Next, we review few other fault-tolerant routing algorithms for the NoCs that have been proposed recently.

Xie et al. [32] have presented a Preferable Mad-y (PMad-y) turn model and Low-cost Adaptive and Fault-tolerant Routing (LAFR) method that use one and two virtual channels along the X and Y dimensions for 2D mesh NoC. Applying PMad-y rules and using the link status of neighbor routers within 2-hops, LAFR can tolerate multiple faulty links and routers in more complicated faulty situations and impose the reliability of network without losing the performance of the network. Zhao et al. [33] have proposed a path-counter method, which labels every node that is helpless to make up for a fault-tolerant minimal path with low time complexity. This strategy can support arbitrary fault distribution, check the existence of fault-tolerant minimal paths, and not sacrifice any available fault-tolerant minimal paths.

Liu et al. [20] have proposed two novel adaptive routing algorithms, namely coarse and finegrained look-ahead routing algorithms, to enhance the fault-tolerant capabilities of 2D mesh/torus NoC system. These strategies use fault flag codes from the neighboring nodes to obtain the status or conditions of real-time traffic in a NoC region, then calculate the path weights and choose the route to forward the packets. Chen et al. [11] have proposed a Path-Diversity-Aware Fault-Tolerant Routing (PDA-FTR) algorithm, which simultaneously considers path diversity information and buffer information. This strategy achieves fault-resilient packet delivery and traffic balancing in the NoC.

Though the FT routing algorithms mentioned above adopt different techniques in successfully transmitting the packets to their destinations if there exists a path, a common metric used in many of these routing algorithms is the knowledge of the status of the links at different capacities in the NoC. Another feature of these routing algorithms is that despite with an increase in the number of faulty links in the NoC, the throughput degradation, as well as the increase in the average packet latency, is kept limited to a considerable value.

## 2.2 HT Attacks on NoCs

Fig. 1 shows the locations considered in inserting HTs as well as employing security units (encircled numbers) in NoC-based systems. The following survey primarily considers the attacks on NoC hardware due to HTs.

Fig. 1. Locations considered in inserting HTs as well as employing security units in NoC based systems.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-5151165d-9c59-4126-bab1-9d04e97d6671.jpg)

Ancajas et al. [3] have demonstrated a range of security attacks, which include information leaking attacks, that could arise in a compromised NoC (C-NoC) that has an accomplice software component. A series of techniques have been proposed to counter the demonstrated attacks by hardening security on systems with a C-NoC, which consists of data scrambling, packet certification, and node obfuscation. The attack scenario and security measures addressed mainly concentrate on data duplication. No control over the packet flow has been enforced. Biswas et al. [7] have investigated a new attack scenario, namely router attack, targeted towards routing tables in routers. These attacks include unauthorized access attack and misrouting attack. The authors have proposed several monitoring-based countermeasures to thwart these attacks. However, this article does not consider attacks on logic-based route computation units.

Frey and Yu [15] have proposed a collaborative dynamic permutation and flit integrity check method to mitigate the consequences caused by the HTs located in the NoC routers. Though the mentioned security hardening mechanism efficiently thwarts the specific role of the HTs, it has no impact on attacks arising in the locations of a router, other than buffers. Prasad et al. [25] have proposed a DoS attack, namely illegal packet request attack (IPRA), and have addressed the measures to mitigate the same. The IPRAs are raised by the HTs located within routers, which are triggered when a core attached to the router goes idle. A security unit has been proposed to detect these attacks and mitigate the consequent loss by guiding the control units of the corresponding buffers to either isolate or mask the attacked buffers at runtime. Though the work considers the

Boraten and Kodi [9] have proposed a packet validation technique, namely packet-security (PSec), merged with two robust error detection schemes, to protect C-NoCs from fault injection side-channel attacks and covert HT communication. P-Sec is a security measure incorporated at NI, which primarily deals with packet encryption and decryption. However, the technique has no control over attacks that arise within a router. They [8] have also proposed a target-activated sequential payload (TASP) HT model that injects faults into the packets, by inspecting them. The faults injected by the HT trigger the error correction code schemes employed for re-transmitting the packets unnecessarily, which could create network congestion and even deadlocks. To circumvent these threats, the authors have proposed a heuristic threat detection model to classify faults and to discover the HTs within compromised links. In addition to this model, several switch-to-switch link obfuscation methods have been proposed to utilize the compromised links instead of rerouting the packets. Though the work covers transient and permanent fault scenarios associated with links in detecting HTs within links, no measure has been considered for threats that arise within a router.

location of the HTs inside routers, the NoC is assumed as a fault-free one. JayashankaraShridevi et al. [17] have proposed a runtime latency auditor to counter the threat posed by a rogue NoC (rNoC) that can selectively disrupt the perceived availability of on-chip resources. The proposed mechanism to thwart the bandwidth denial attack enables an MPSoC integrator to monitor the trustworthiness of the deployed NoC throughout the chip lifetime. However, the presented mechanism does not consider the HT attacks arising in the control module of a router, such as a routing unit. A summary of the HT mitigation mechanisms in NoC considered so far has been mentioned in Table 1.

Table 1. Comparison of HT Mitigation Mechanisms in NoCs

| Work                             | Trojan Location in NoC   | Attack(s) Considered                                   | Fault-tolerant Router   | Protection Mechanism Location   |
|----------------------------------|--------------------------|--------------------------------------------------------|-------------------------|---------------------------------|
| Ancajas et al. [3]               | Router                   | Information leaking                                    | No                      | Network Interface               |
| Biswas et al. [7]                | Router                   | Unauthorized access, mis-routing                       | No                      | NoC                             |
| Boraten and Kodi [9]             | Link                     | Fault injection side-channels, covert HT communication | No                      | Network Interface               |
| Frey and Yu [15]                 | Router                   | Packet corruption                                      | No                      | NoC/Router                      |
| Prasad et al. [25]               | Router                   | Illegal packet requests                                | No                      | NoC/Router                      |
| JayashankaraShridevi et al. [17] | Router                   | Bandwidth denial                                       | No                      | SoC Firmware                    |
| Boraten and Kodi [8]             | Link                     | fault injection side channels                          | Yes                     | NoC/Router                      |
| Present Work                     | Router                   | Packet drop                                            | Yes                     | NoC/Router                      |

Many of the works mentioned above take into account attacks on NoC within routers and links, assuming that the NoC is fault free. However, in the presence of faults, mainly permanent link faults, there is vast scope for attackers to attack routers, while taking advantage of the knowledge of faulty links. Several strategies exist in the literature that subsume the operation of NoC in the presence of faulty links [26, 31]. Although identification of faulty links has been considered in [8], no security mechanism has been proposed thus far for attacks arising within the routers that are adjacent to the faulty links. One of such attacks may well be created with the motivation of forwarding packets towards the output ports associated with the faulty links. This work has addressed one such attack situation and has proposed a secure router to circumvent those attacks.

## 3 BASELINE SYSTEM MODEL

This section describes the baseline system model by detailing the architectural and functional properties of the NoC-based MPSoC, which has been considered for the present study.

Fig. 2a shows a baseline FT router microarchitecture, which consists of a link status analyzer (LSA) with each routing unit (RU), for forwarding packets to fault-free output ports, in the presence

An MPSoC in the present study is a tile-based system, where each tile consists of a processing element (PE) or core, a set of level-one private instruction and data caches, a memory controller, and a router along with the network interface. A shared level-two cache has also been considered to be present in the system. The communication infrastructure that interconnects all the tiles in the system has been realized using a two-dimensional mesh NoC. Traditional input-queue based buffered routers have been considered, which adopt round-robin arbitration mechanism for switch allocation and logic-based fault-tolerant distributing routing units. An application in the MPSoC has been assumed to be mapped onto multiple cores using the mapping algorithm mentioned in [28]. The nature of the applications considered is generic. Also, the kind of the MPSoC can be either homogeneous or heterogeneous. The communication between the cores is deemed to happen via the NoC, through network interface units and routers in the network.

of faulty links. The remaining inputs and outputs of the router are as follows. I1, : : : , I5 and O1, : : : , O5 are the data input and output (IO) ports. Credits (C), which record the occupancy of buffers of adjacent routers, deal with buffer and virtual channel management, and status signals (SS) record the health of the links associated with the ports of the router. All routers in the NoC are assumed to have five-stage pipeline: input buffer and route computation, virtual channel allocation, switch allocation, switch traversal, and link traversal. Regarding the fault-tolerant routing algorithm, we assume that the routing algorithm maintains the status of all the links that are associated with the current router. A current router, concerning a packet, is defined as the router in which the packet currently resides.

Fig. 2. (a) Microarchitecture of a fault-tolerant NoC router with a hardware Trojan. (b) A 4 GLYPH&lt;2&gt; 4 NoC with faulty links.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-bb9d92ca-d61a-4748-bc7d-c3eff3452d30.jpg)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-ca339478-1aee-4349-8675-e27a3cc45bd8.jpg)

The routing algorithm considered in the baseline fault-tolerant router is similar to the one mentioned in [20], where each router maintains a register, named as LSR, in which the status of the links connected to the router is stored. In the current analysis, the state of those links, which are up to two hops away from the current router, has been considered.

## 4 MOTIVATION AND THREAT RELEVANCE

This section presents the motivation for considering the packet drop attack and describes the threat relevance in the context of NoCs with faulty links.

## 4.1 Motivation and Attack Scenario

Analysis of works surveyed in [26, 31], as well as the ones mentioned in Section 2.1, shows that the measures taken to forward packets in a NoC with faulty links are mostly enforced either at the RU or input buffers. However, the intended inclusion of HTs makes even these units vulnerable from the security perspective. Thus, any attack within the FT router created after the RC pipeline stage goes undiscovered. This drawback motivates the attacker to choose an appropriate attack point to disrupt the functionality of the NoC endowed with FT routers.

Consider a 4 GLYPH&lt;2&gt; 4 mesh based two-dimensional NoC as shown in Fig. 2b. The links in black are healthy links, and those in red are faulty. Faults associated with the links are considered to be permanent faults. The mechanism given in [8] for identifying permanent faults can be applied here as well to detect the faults. Further, the current study considers that the NoC has not been divided into secure and non-secure zones. Consider routers nine and ten in Fig. 2b. The link connecting from router nine to router ten is a faulty one. Once this link becomes faulty, router nine informs its neighbors regarding the faulty link and sends the updated link status information to them. Consider a case where a packet needs to travel from router 8 to router 11, via routers 9 and 10. Had the link

that connects from router 9 to router 10 been healthy, the packet would have traveled through router 9. Since the link is faulty in this case, router 8 will now have the updated link status and the packet from router 8 to router 11 will find another path for its traversal, for instance through the routers 8, 4, 5, 6, 10, and 11. This path avoids router 9 in the network. Consider another scenario where another packet needs to travel from router 8 to router 5, with the path through the routers 8, 9, and 5, being the primary path and the path through the routers 8, 4, and 5, being a secondary path. Though router 8 knows the information of the faulty link at the east output port of router 9, it would still send the packet to router 5 through router 9, as the path connecting routers 8, 9, and 5, does not have any faulty link. Thus, this path does not avoid router 9. Assume now that there is an HT present in router nine at the routing unit associated with its left input port, with a motivation to drop the packets that arrive at this port, by forwarding them to the east output port, which has the faulty link. Though the packets from router 8 to router 10 or router 11 avoid router 9, those other packets, which have to take a turn at router 8, such as the ones from router 8 to router 5, are dropped at router 9, because of the presence of the HT in router 9.

Attack situations as mentioned above, though not common, can be easily created in NoCs, since most of the FTR also consider network congestion information to route the packets in the network [24] adaptively. Further, though there exist techniques, such as packet retransmission, to reduce the loss of packets in traditional FT NoCs, they will not be successful in a scenario as mentioned above. The reason for such techniques for not being successful is because even if the packets are retransmitted, they would still follow the same path, which makes them inevitable from getting lost again. This kind of packet dropping can be done by manipulating the port select signals of the XB, which come from the RU. Had there not been any attack in the scenario mentioned above, and with the link associated with the east port of router nine is faulty, the RU associated with the left input port of router 9 would have adapted its routing algorithm such that no packet would go towards its east output port. Owing to the FT operation of a router, if an attack is created after the RU, it is always possible to forward the packets to the east output port, which has the faulty link. This kind of misrouting and its subsequent packet dropping process ends up in data loss and can be disruptive if deployed in critical systems.

## 4.2 Threat Model

An attacker in the current study can be either a rogue employee who knows a part of the design, a computer-aided design (CAD) tool, an untrusted foundry, or any combination of the above [5, 15]. The attacker can infect HTs into the design only during the design time. Once the chip is fabricated, the attacker cannot further modify the functionality of the design. Fig. 2a shows an attack point of the proposed attack in a router, which is marked as H.

Similar to all HTs, the proposed HT is assumed to go undetected either during the design verification phase or the chip testing phase. An HT in the proposed design remains dormant in a router until one of the links associated with the output ports of the router becomes faulty. Once a link associated with an infected router becomes faulty, the HT wakes up and waits until the trigger condition is met to raise the packet drop attack. Once the HT is triggered, it starts to divert the

An attacker can infect the system in one of the following ways. A rogue employee of the design house can leak the design information to the foundry, which can replace the correct masks with the ones infected with the HTs [15]. Otherwise, a CAD tool can hide particular details of the design from the designer while generating the layout of the design. Similarly, an untrusted foundry may reverse engineer the obtained masks to infect the HTs. However, for the present study, we assume that the addition of the security modules to the design is done at the last phase of the design, similar to [8].

packets in the router to the output ports with faulty links, which is the threat in the case of a packet drop attack. However, unlike in packet drop attacks of other networks, where multiple malicious nodes cooperate, we assume that the attack scope of the proposed HTs is limited to those routers in which they are injected.

Since an attacker does not have provision to modify the design once fabricated, placement of HTs in the NoC is essential to increase the chance of triggering the HTs, as well as making the attack a significant one. In the present design, selection of routers in the NoC to place the HTs has been made considering the traffic observed while running real benchmark circuits on a NoC-based MPSoC platform. Further details on the same have been mentioned in Section 4.3.

An infected router in the proposed design is a baseline fault-tolerant router with an HT. However, a difference between an infected and a non-infected router is that a non-infected router always tries to divert the packets towards the output ports that do not have faulty links. Whereas, an infected router is a router that always tries to divert the packets at an input port towards the output ports that have faulty links.

## 4.3 Attack Significance

The attack scenario to raise the packet-drop attacks, as mentioned in Section 4.1, requires a NoC to have at lease one faulty link. The reason to have one or more faulty links is that of the specific behavior of the proposed HT, which remains dormant till a link in the NoC becomes faulty. This specific behavior of the proposed HT limits its significance to create a potential attack scenario. However, with the knowledge of the design footprint of the proposed HT, which will be mentioned in Section 4.4, one may use a combination of the proposed HT with any other HT to increase the scope of the attack scenario in the NoC, and still hide the HTs during the design verification or chip testing phase, to carry out the desired attack.

Since there exist many RUs in a router, each associated with an input port, any RU can be chosen for inserting the HT. However, selecting a particular port for inserting the HTs is essential, as different ports in different routers have different probabilities of packet transmission. For instance, inserting the HTs at the RU associated with the local input port of a router is more efficient than placing them at other RUs, if the data transmission at the local port is higher than that of other ports. Further, due to the look-ahead routing mechanism adopted in some FT NoCs [22], where the packets may not reach the routers that are associated with the faulty links, the selection of routers, and corresponding ports, becomes more critical to increase the severity of the attack.

On the other hand, a NoC architecture can be considered as a truly fault-tolerant one, only if the fault tolerance mechanism addresses all its hardware resources, such as links and routers. Several such architectures, as reviewed in [26, 31], either focus on links alone or focus on both routers and links, to endow the fault tolerance property to the NoC. Thus the scope of the proposed HT, which requires a NoC to be embedded with a fault-tolerant routing mechanism, can be extended to many fault-tolerant NoC architectures mentioned in [26, 31].

To establish the significance of the packet drop attack in the present context, traffic distributions of PARSEC [6] benchmark applications have been obtained in the forms of traces, link utilization ratios, router utilization ratios, as well as inter-core communication volumes. SniperSim [10] full-system simulator has been used to obtain all of the information mentioned above, with the parameters mentioned in Table 2. Fig. 3 shows the link utilization ratios of the directional links of routers while running the blackscholes application in an 8 GLYPH&lt;2&gt; 8 mesh NoC. These ratios are obtained for a fault-free scenario by employing the fault-tolerant routing technique mentioned in [20]. Even the other benchmark applications exhibit similar trends in the link utilization ratios. These statistics aid the adversary in locating the links to place the HTs in the NoC. For instance, the attacker may

Table 2. Parameters to Carry out Full System Simulation

| Parameter           | Value                 |
|---------------------|-----------------------|
| System architecture | Xeon X5550 Gainestown |
| Core frequency      | 2.66 GHz              |
| Number of cores     | 64                    |
| Shared cache        |                       |
| Data access time    | 30 cycles             |
| Tags access time    | 10 cycles             |
| Cache size          | 8 MB                  |
| Cache block size    | 64 KB                 |
| DRAM                |                       |
| Latency             | 45 cycles             |
| Network             |                       |
| Link bandwidth      | 128 bits              |
| Hop latency         | 1                     |
| dimensions          | 2                     |
| Concentration       | 1                     |

insert the HTs inside router 35 or router 36, as the number of packets utilizing the links associated with these routers exceeds 9% of the total number of packets in the NoC. Thus, if an HT present in any of the router mentioned above triggers, it can drop 9% of the total packets in the NoC, which can be disruptive in critical systems.

Fig. 3. Link utilization of directional links in an 8 GLYPH&lt;2&gt; 8 mesh NoC when running blackscholes benchmark.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-7ec77288-b5b7-418e-9a79-403abfb8901c.jpg)

The link utilization ratios shown in Fig. 3 are for a fault-free case of the NoC. When a link in the NoC becomes faulty, these values deviate from the ones shown in the figure. Further, the routing algorithm considered in the current analysis adopts a look-ahead mechanism in deciding the paths for the packets. This look-ahead mechanism may avoid the routes that contain the routers associated with the faulty links, through which the packets had traveled when there were no link faults. Thus, to still attack with a high disruption rate, the adversary may consider the router utilization ratios to locate the points of insertions of the HTs. Fig. 4 shows the amount of injected/ejected traffic of each router in an 8 GLYPH&lt;2&gt; 8 NoC when running the blackscholes application. As these traffic values remain constant for a mapped application on the NoC, an attack raised in a

router would drop these packets, if not all packets that pass through the router. For instance, if a packet drop attack is successfully raised for the shown benchmark in router 35, the minimum and maximum packet loss will be 1.35% and 9.24% of the total number of packets, respectively.

Fig. 4. Traffic injection/ejection ratio of routers in an 8 GLYPH&lt;2&gt; 8 NoC when running blackscholes benchmark.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-386c12af-d63e-4748-b18c-aa08e44684de.jpg)

Further, Fig. 5 shows the packet drop ratio trends of various PARSEC benchmark applications for an 8 GLYPH&lt;2&gt; 8 mesh NoC when one of the routers is infected with the HTs. From the figure, one may note that the maximum packet drop ratio of an application can go as high as 34.47%, with only one infected router in the NoC. These values, which show the severity of the attack, would further increase if multiple routers become victims of the packet drop attacks.

Fig. 5. Packet drop ratio (%) of PARSEC benchmark applications when run on an 8 GLYPH&lt;2&gt; 8 NoC with SeFaR. Full-system simulation has been run for the NoC with a maximum of four HTs in the NoC that affects four out of five input ports of a router.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-fb5c8d6a-485a-49e9-8b70-f621f88690f8.jpg)

## 4.4 Design Features of the HT

For an HT to be effective, its area and power parameters ought to be insignificant, when compared to those corresponding to the conventional design in which they are placed. Fig. 6a shows a design of an HT of the proposed attack. The HT consists of a link-to-port decoder (DEC) that decodes the port index corresponding to the faulty link, and three multiplexers to select the desired port index once the attack is created. For this HT, the DEC block serves as the trigger, and the three multiplexers serve as the payload. Inputs to the DEC are status signals of four directional links of a

router associated with north (LN), east (LE), south (LS), and west (LW) ports, respectively, and an enable (EN) signal, which activates the DEC. The EN signal is a backdoor kill switch, similar to the one mentioned in [8]. The EN signal can also be realized using FSM based designs, to make the activation mechanism more complex to be detected. Other inputs to the HT constitute the input port index (P2P1P0) that serves as outputs to the RU. The outputs of the HT are the actual port index (A2A1A0) that serves as inputs to the crossbar and the select signal (S) to the multiplexers. The port indices of 001, 010, 011, and 100 correspond to the north (N), east (E), west (W), and south (S) ports, respectively. The purpose of the DEC block is to change the input port index to the compromised port index (D2D1D0) to trigger the attack, when EN = '1' and any of the link status is '1'. Figs. 6b and 6c show the hardware of the DEC block in a proposed HT and its corresponding truth table.

Fig. 6. (a) Logic of considered hardware Trojan (HT). (b) Logic of DEC. (c) Truth table of DEC.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-96b25cc1-5670-4d13-8d70-2557a57c0257.jpg)

Fig. 7a and 7b show the design foot-print of proposed HT regarding both percentage area overhead and percentage power overhead when compared to the baseline FT router. The values have been obtained by synthesizing the modules using Synopsys DC and Faraday 90 nm library, for an operating voltage of 1 V and an operating frequency of 1 GHz. Area and power overheads are calculated by considering five HTs in a router. Each router has five IO ports, wherein each virtual channel (VC) is capable of storing four flits. Size of the NoC considered is 8 GLYPH&lt;2&gt; 8, and its topology is mesh. From the figures, it is evident that both area and power overheads of HTs are less than 1.35% and 1.79%, respectively, for a router with 2 VCs per IO port and flit width of 32 bits. As routers constitute only a small fraction of the area in a NoC based MPSoC, 1.35% area overhead and 1.79% power overhead are insignificantly low values when compared with those of the entire NoC based MPSoC. Further, the area and power overheads reduce with an increase in the flit width of the NoC. This comparison with different flit widths is to show that the design footprint of the HTs does not depend on the flit width of the network. Another observation one can make from the plots is as the share of the design footprint of the HTs reduces the complexity of their detection in such designs increases.

## 5 PROPOSED MITIGATION MECHANISM

To counter the consequences caused because of the proposed HTs, a secure FT router, called SeFaR, has been proposed. To establish security within SeFaR, security components, namely the authentication unit (AU), the control unit (CU), and the buffer shuffler (BS) have been introduced. Fig. 8 shows the microarchitecture of SeFaR along with the blocks mentioned above. The AU block connects with the XB and acts as a shield by blocking the port indices, which attempt to force the packets injected into the router to proceed to the output ports containing faulty links. CU controls

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-74ae6fdb-9516-47ed-9cef-0c16cbd724e6.jpg)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-8095cf42-c0bf-4ebb-955d-825a0226d54e.jpg)

2

Power Overhead (%)

Fig. 7. (a) Area overhead and (b) Power overhead of the proposed HT with respect to baseline fault-tolerant NoC router.

the BS block in securing the router, by considering the output signals of the AU. BS shuffles the buffer locations where the input data needs to occupy.

Fig. 8. Microarchitecture of the proposed secure fault-tolerant router (SeFaR).

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-4df85177-3cce-4b78-911f-fdfa13fedc95.jpg)

## 5.1 Buffer Shuffler (BS)

The purpose of the BS block, in SeFaR, is to shuffle the port indices such that the incoming data is sent into a buffer, whose routing unit is not compromised. Design of the BS block is straightforward, as it conforms to the logic of a crossbar. However, to keep its logic simple, pass transistor based crossbar can be considered instead of a multiplexer based one. A router with N ports requires an N GLYPH&lt;2&gt; N BS. The select inputs to the BS come from the CUs of respective ports in the router.

## 5.2 Authentication Unit (AU)

Workflow of the logic corresponding to the AU has been summarized next. AU continuously gathers the link status information from the LSA and keeps on checking for any anomaly in the

port indices obtained from the routing units. If any anomaly is detected, it raises a warning flag (F) associated with a particular port to '1'. This flag indicates the presence of an HT in the router at the routing unit (RU) associated with that port and alerts the CU to take further action. Figs. 9a and 9b show the truth table and logic diagram of the proposed AU.

Fig. 9. (a) Truth table of the proposed authentication unit (AU). (b) Logic of the proposed authentication unit (AU). (c) Logic of the proposed Control Unit (CU).

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-7bfd3bb1-adae-4575-b32f-dbd6bb8820dd.jpg)

## 5.3 Control Unit (CU)

Fig. 9c shows the logic of CU and its association with the BS block. If there are N ports in a router, there would be N CU blocks, each corresponding to a port of the router. Since CU generates the state bits to be given to the BS block, an FSM-based modulo-N counter has been employed, with the initial states being the port indices. Here, B1 to B5 represent the busy status flags of the buffers of all ports. A logic '1' of any of these means that the buffer has either been occupied by other CU. This condition indicates that no two CUs should have same states in their FSMs, else the RU associated with the corresponding port has been compromised. F is the warning signal coming from AU, and Z is the output of the FSM, which serves as the input to the BS block.

An example to illustrate the functionality of the CU is shown in Fig. 10. Here, port I1 is considered, which is associated with the signals B 1 and F 1. The initial seed, as well as the output of the constituent FSM, is 001. From the diagram, as soon as F 1 goes high, B1 follows it, cautioning the CU to change its state. CU changes its state from 001 to 010, which corresponds to P2. Now, the FSM checks for the availability of associated buffer, by checking the B2 flag. Z 1 remains in state 010, till B 2 remains zero. This condition means that the shuffler now allows the packets coming from I1 to occupy the input buffer IB2. As soon as the flag B 2 goes high, Z 1 changes to its next free state. This process continues until BS finds a suitable port for the packets to occupy.

The functionality of the CU can be explained as follows. Initially, the seed value corresponding to the port is set, and the FSM outputs the same, which directs the shuffler to forward the incoming packets to their default buffers. The same output works as the select signal for the multiplexer present in CU, which selects the buffer status signal corresponding to its port. It then waits for F of respective port, to enable the FSM to change its output, thus asserting the shuffler to redirect the incoming packets to some other buffer locations. The signal F acts as the enable signal to CU. Once F of a port becomes high, the buffer status flag also becomes high, which makes the FSM change its state, transiting to its next state. Then, depending on the availability of the buffers of the port corresponding to its new state, the FSM decides whether to change its state further or to remain in that state.

The proposed CU can also be designed using look-up tables (LUTs), instead of FSMs, if the application traffic is known beforehand. Also, with the emergence of dynamic VC management

Fig. 10. Timing diagram showing functionality of the CU.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-0e327eb2-270f-427e-ad7c-7b752781331c.jpg)

techniques, as in [23], the proposed CU can be integrated with the VC management unit of such techniques, to enhance the serviceability of the NoC. However, the difference between the dynamic VC management and the functionality of the CU is that the dynamic VC management manages the allocation of the VCs present inside a buffer at an input port, whereas the CU manages the allocation of the buffers itself.

## 5.4 An Example Scenario

A better understanding of how the proposed runtime mitigation technique using SeFaR functions can be obtained using an example. Fig. 11 shows the snapshots of a scenario, wherein the execution steps of SeFaR are shown. The following steps elaborate the execution of SeFaR in the event of a packet drop attack. The scenario is that a packet has to travel from the router R1 to the router R5 via the router R3. The input and output ports through which the packet passes through R3 are I1 and O3, respectively. The outbound link associated with the port connecting R3 and R4, namely O2, has become faulty and there exists an HT that can raise a packet drop attack in R3, near the routing unit of the input port I1. The default data path of the packet through the central router is the input port I1, the buffer shuffler (BS), the input buffer IB1, the crossbar, and the output port O3. It is assumed that there is no contention in R3 for the packets arriving at I1 due to the other ports.

Fig. 11. Snapshots of a scenario showing the execution steps of SeFaR in the event of a packet drop attack.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-459a7392-5050-4de0-97c4-66571870ea67.jpg)

- GLYPH&lt;15&gt; Snapshot 01 At this instance, the HT present at the routing unit of the input port I1 is not triggered. Thus the packet follows the default path and occupies the input buffer B1. With the knowledge of the faulty link associated with the output port O2, the routing unit of input port I1 does not forward any packet through this output port.

- GLYPH&lt;15&gt; Snapshot 02 At this instance, the HT present at the routing unit of the input port I1 triggers, and manipulates the output port indices obtained from the routing unit, so that the packet is forced to go through the output port O2, instead of O3. This situation makes the router R3 a packet drop router, with respect to the input port I1. AU, present at the crossbar, finds that the packet from the input port I1 is being forced to the output port O2, and raises a warning flag and communicates with the CU, located at the input buffer IB1.
- GLYPH&lt;15&gt; Snapshot 03 At this instance, the CU associated with the input buffers applies the permutation and shuffles the buffer index such that the packets arriving at the input port I1, which had to occupy B1, now occupy B2. Simultaneously, the CU instructs the switch allocator not to consider further packet requests from the input buffer IB1. Since the RU associated with the input buffer IB2 is not affected by the existing Trojan, it forwards the packets to their legitimate output ports, which is O3 in this case.

SeFaR thus restores the communication flow by preventing the network from losing the packets at the router R3. The new path for the packets from the router R1 to the router R5 through the router R3 will be the input port I1, the input buffer IB2, the crossbar, and the output port O3.

## 6 PERFORMANCE EVALUATION

Performance metrics such as area, power, and performance overheads of SeFaR have been compared with the baseline FT router. Architectures of both baseline and secure FT routers have been coded in VHDL. Synopsys Design Compiler [1] and Faraday 90 nm technology library have been used in implementing the designs. An operating frequency of 1 GHz has been set for the routers. The size of the network considered is 8 GLYPH&lt;2&gt; 8, and the topology is mesh. Each router has five input/output (IO) ports, and each VC in a buffer can store four flits.

## 6.1 Area and Power Overhead Evaluation

Fig. 12a shows the area overhead (in %) of SeFaR when compared with the baseline FT router. To evaluate the metric over a wide range, we considered routers with two, four, and eight virtual channels (VCs) per IO port. For each of these configurations, the flit width has been varied from 32 bits to 128 bits. We have synthesized the SeFaR with five AUs in each router. From the figure, it is evident that for a 32-bit flit in a router with 2 VCs per IO port, the area overhead of SeFaR is found to be 2.02%. This overhead is further reduced when higher configurations of routers are considered.

Fig. 12b shows the power overhead (in %) of SeFaR when compared with the baseline FT router. Since the additional logic associated with SeFaR is very little, the power overhead achieved by it is also very less. From the figure, for SeFaR with 32-bit wide flits and 2 VCs per IO port, the power overhead is 0.90 %. This overhead is further reduced when higher configurations of routers are considered. When this power overhead is measured with respect to the power consumption of NoC based MPSoC, it becomes insignificantly low, which makes SeFaR a promising alternative to baseline FT routers, with an additional security layer.

## 6.2 Performance Overhead Evaluation

To evaluate the performance overhead of SeFaR and compare it with that of the baseline FT router, we have obtained the traffic distributions of applications from the PARSEC benchmark suite using the SniperSim [10] full-system simulator. Further, to analyze the performance of SeFaR for synthetic traffic, patterns such as shuffle, transpose, and uniform-random (uniform) have been considered. The network evaluation for all real, as well as synthetic, traffic distributions, has been done using the BookSim [18] network simulator. Performance overhead evaluation has been done for the metrics such as execution time and energy consumption overheads for real benchmark applications.

Fig. 12. (a) Area overhead and (b) Power overhead of secure fault-tolerant router (SeFaR) compared to baseline fault-tolerant router.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-da033828-8e8a-46db-aa4b-74dcfae888fb.jpg)

For synthetic traffic, parameters such as average packet latency (APL) and power-latency product (PLP) have been analyzed for SeFaR and compared with that of the baseline FT router. An advantage of analyzing the performance of SeFaR for synthetic traffic is that one can estimate the overheads of the mitigation mechanism for a range of packet injection rates (PIRs).

6.2.1 Real Benchmarks. For the current evaluation with real benchmark traffic patterns, we considered one packet drop router in the network at a time. Further, to observe the system performance for different routers acting as packet drop routers, results have been obtained for all the cases one after the other. A packet drop router in the current scenario is analyzed for two cases-one with a single HT that affects one input port, the other with four HTs that affect four input ports.

Figs. 14a and 14b show a comparison of SeFaR with the baseline FT router regarding the overheads observed in the execution time while running the real benchmarks. Fig. 14a refers to the routers that are infected with a single HT, whereas Fig. 14b refers to the routers that are affected with four HTs. The links, which are faulty, have been considered to be faulty for the entire application execution. For the case of a single HT in a packet drop router, the maximum overhead in the

Figs. 13a and 13b show a comparison of SeFaR with the baseline FT router regarding the overheads observed in the communication time while running the real benchmarks. Fig. 13a refers to the NoC with one router that is infected with a single HT that drops the packets arriving at an input port, whereas Fig. 13b refers to the NoC with one router that is infected with a maximum of four HTs, which drop the packets arriving at all but one input ports of the router. From the plots, one can find that for the case of a router infected with a single HT, the overhead observed in the communication time can go as high as 10 GLYPH&lt;2&gt; the baseline value. Similarly, for the case of a router infected with a maximum of four HTs, the overheads observed in the communication time can go as high as 90 GLYPH&lt;2&gt; the baseline value. Despite the huge overheads accounted in SeFaR to mitigate the packet drop attacks while running the PARSEC benchmarks, the application execution time has not been observed to increase similarly. This increasing trend in the application execution time is because of the core idle time and the dependence of the spatial and temporal traffic distributions of the application under execution. Details on the same are presented next.

Norm. Comm. Time

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-f6ae5bd5-c7d8-4734-b5e3-72f1d969c13d.jpg)

(a)

Norm. Comm. Time

Fig. 13. Communication time overhead of PARSEC benchmark applications when run on an 8 GLYPH&lt;2&gt; 8 NoC with SeFaR. Full-system simulation has been run for the NoC with (a) one infected router in the NoC with one HT and (b) one infected router in the NoC with a maximum of four HTs in the NoC that affects four out of its five input ports.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-cca04551-23bf-481c-ab39-e33d8369bf60.jpg)

execution time has been observed for dedup , which is 4.46%, when compared with the baseline FT router. However, the average overhead in the execution time for each application does not exceed 0.8% with respect to the baseline FT router, when a packet drop router is infected with a single HT. Similarly, for the case with four HTs in a packet drop router, the maximum overhead observed for SeFaR regarding the execution time has been 70.87% for dedup , when compared with the baseline FT router. Whereas, the average overhead in the execution time for this case does not exceed 12.89%, for the considered real benchmarks. The reason for the difference seen in the execution time overheads of these applications is because of the difference in their traffic distributions as well as traffic volumes.

Similarly, Figs. 15a and 15b show a comparison of SeFaR with the baseline FT router regarding the overheads observed in the energy consumption while running the real benchmarks. The energy consumption overheads include the consumption overheads of the security blocks endowed in SeFaR. Fig. 15a refers to the routers that are infected with a single HT, whereas Fig. 15b refers

Norm. Exec. Time

(a)

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-9d6854c9-4367-4c16-9608-2383b53d4106.jpg)

Norm. Exec. Time

Fig. 14. Normalized execution time of PARSEC benchmark applications when run on an 8 GLYPH&lt;2&gt; 8 NoC with SeFaR. Full-system simulation has been run for the NoC with (a) one infected router in the NoC with one HT and (b) one infected router in the NoC with a maximum of four HTs in the NoC that affects four out of its five input ports.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-e7ec2322-c47a-4611-b1b4-99a523d7e1f0.jpg)

to the routers that are infected with four HTs. For the case of a single HT in a packet drop router, the maximum overhead in the energy consumption has been observed for canneal , which is 44.46%, when compared with the baseline FT router. However, the average overhead in the energy consumption for each application does not exceed 28.36% with respect to the baseline FT router, when a packet drop router is infected with a single HT. Similarly, for the case with four HTs in a packet drop router, the maximum overhead observed regarding the energy consumption for SeFaR has been 82.10% for canneal , when compared with the baseline FT router. Whereas, the average overhead in the execution time for this case does not exceed 28.58%, for the considered real benchmarks. For the above set of evaluations, each benchmark application has been executed entirely, considering a link in the NoC to be faulty for the entire run of the application. However, if the link becomes defective while the application is being executed, the overheads observed would decrease depending on the temporal traffic distribution of the application under execution.

6.2.2 Synthetic Traffic Patterns. Fig. 16 shows the plots of different configurations of an 8 GLYPH&lt;2&gt; 8 NoC endowed with SeFaR regarding the average packet latency (APL) and power-latency product

Normalized Energy

Normalized Energy

Fig. 15. Energy overhead of PARSEC benchmark applications when run on an 8 GLYPH&lt;2&gt; 8 NoC with SeFaR. Fullsystem simulation has been run for the NoC with (a) one infected router in the NoC with one HT and (b) one infected router in the NoC with a maximum of four HTs in the NoC that affects four out of its five input ports.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-681d0e25-f0ea-42b9-b038-defb1ec653dd.jpg)

(PLP) with varying packet injection rates (PIRs) while running the synthetic traffic patterns. Here, 'Fault-free' case refers to the NoC without any link fault. 'Faulty5%-No HT' case refers to the NoC with 5% link faults, but the HTs, which are infected in the routers that have these links at their output ports, are not triggered. 'Faulty5%-HT' case refers to the NoC with 5% link faults and all routers with those links serving as output links are infected with an HT. Similar is the convention for the NoC with 10% link faults. From the plots, one may note that the APL and PLP of the NoC have similar trends for the shuffle and uniform traffic patterns, for all the five cases. This similarity is due to the nature of the spatial distribution of the traffic in the network. However, for the transpose traffic pattern, the NoC with active HTs suffers a slight degradation in APL and PLP when compared to the NoC with link faults, but with dormant HTs. Though the plots in Fig. 16 are shown for random locations of the faulty links, similar trends have been observed for all the five configurations of SeFaR when the locations of the defective links in the network change. From the plots, one may find that the overhead introduced in the NoC with faulty links and active HTs,

because of the mitigation mechanism in the form of SeFaR, in the APL and PLP metrics are not so high when compared with the values observed when the NoC has faulty links, but dormant HTs.

Fig. 16. Average packet latency (APL) (a, b, and c) and power-latency product (PLP) (d, e, and f) versus packet injection rate (PIR) of different synthetic traffic patterns in an 8 GLYPH&lt;2&gt; 8 mesh NoC.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-4c30b7ac-54cb-4ba5-8852-156b9017dfd1.jpg)

## 7 DESIGN OF A COMPREHENSIVE SECURE ROUTER

Several mitigation mechanisms proposed hitherto, which aim in restoring security in NoCs, primarily address one particular attack. This kind of attack-specific mitigation mechanism for NoCs may not be viable to be considered in practice, as each such architecture can nullify only a specific attack raised by the HTs. Thus, more generic mitigation mechanisms, which can mitigate multiple attacks, are necessary to extend the scope of Quality-of-Security Service (QoSS) in the future NoC architectures. One way of realizing a secure architecture of a router in the NoC is by leveraging the common properties of several mitigation mechanisms and integrating them into the router. This kind of hardening mechanism improves the immunity of the routers in the NoCs to resist and thwart several attacks.

Fig. 17 shows one such CSR, which can mitigate the attacks considered in [15, 25], along with the proposed packet drop attack. The blocks buffer shuffler (P), control unit (CU), and authentication unit (AU) help in mitigating the packet drop attack, whereas, the blocks security unit (SU) and

This section presents the architecture of one such router, namely comprehensive secure router (CSR), which can mitigate multiple attack scenarios that arise within the NoC routers. The architecture of CSR is a derived architecture, which has been derived from other secure architectures presented in the literature.

Fig. 17. Microarchitecture of a secure router capable of mitigating several HT attacks.

![image](https://ac.marcodsn.me/arxiv-markdown-images/1908.00289v1-figure-a7ab4d08-7441-4389-8a57-f89bf4b4c3b4.jpg)

buffer shuffler (P) help in mitigating the illegal packet request attack [25]. Similarly, the blocks F, G, and B conform to the blocks HTC1, HTC2, and HTC3, mentioned in [15], which help in mitigating the flit sabotage attacks that arise within the router.

The design overhead of the router in Fig. 17 compared to the baseline router mentioned in [15], which consists of 5 IO ports and 8 VCs/port with a flit-width of 32 bits, is found to be about 41% in terms of area and 18% in terms of power consumption.

## 8 CONCLUSIONS AND FUTURE WORK

Packet drop attack, a type of denial-of-service attack, has been proposed in the context of NoCs, in which packets are forced by the HTs to proceed to those output ports of a router that have faulty links. The HTs that can raise the proposed attack have been inserted inside the routers, which become active when an output link associated with such routers becomes faulty. Security modules, namely authentication unit, control unit, and buffer shuffler have been proposed to mitigate the anomaly raised because of the attacker HTs. Regarding overheads in performance, SeFaR suffers an average overhead of at most 0.8% and 12.89% in terms of execution time, when one and four active HTs are considered in the NoC while running real benchmarks. Similarly, regarding the overhead in energy consumption, SeFaR additionally consumes an average energy of at most 28.36% and 28.58%, when one and four active HTs are considered in the NoC while running real benchmarks. For synthetic traffic patterns, SeFaR with an active HT suffers from slight degradation in the average packet latency and power-latency product metrics, when compared with SeFaR without any HT. Area and power overheads of SeFaR, when put next to the baseline FT router, have been found to be 2.02% and 0.90%, respectively. Further, a comprehensive secure router, with area and power overheads of 41% and 18% compared to the baseline router, has been designed, which can mitigate multiple attack scenarios that arise within the routers of a NoC. Future work aims at improving the mitigation mechanism for the proposed attack.

## REFERENCES

- [1] 2017. Design Compiler. https://www.synopsys.com/support/t-raining/rtl-synthesis/design-compiler.html. (2017). Accessed: 01 July 2017.
- [3] D. M. Ancajas, K. Chakraborty, and S. Roy. 2014. Fort-NoCs: Mitigating the threat of a compromised NoC. In 2014 51st ACM/EDAC/IEEE Design Automation Conference (DAC) . 1-6.
- [2] Mohammad Al-Shurman, Seong-Moo Yoo, and Seungjin Park. 2004. Black Hole Attack in Mobile Ad Hoc Networks. In Proceedings of the 42Nd Annual Southeast Regional Conference (ACM-SE 42) . ACM, New York, NY, USA, 96-97.
- [4] S. Bhasin and F. Regazzoni. 2015. A survey on hardware trojan detection techniques. In 2015 IEEE International Symposium on Circuits and Systems (ISCAS) . 2021-2024.

## N. Prasad, Navonil Chatterjee, Santanu Chattopadhyay, and Indrajit Chakrabarti

- [5] S. Bhunia, M. S. Hsiao, M. Banga, and S. Narasimhan. 2014. Hardware Trojan Attacks: Threat Analysis and Countermeasures. Proc. IEEE 102, 8 (Aug 2014), 1229-1247.
- [7] Arnab Kumar Biswas, S. K. Nandy, and Ranjani Narayan. 2015. Router Attack toward NoC-enabled MPSoC and Monitoring Countermeasures against such Threat. Circuits, Systems, and Signal Processing 34, 10 (Oct 2015), 3241-3290.
- [6] Christian Bienia. 2011. Benchmarking Modern Multiprocessors . Ph.D. Dissertation. Princeton University.
- [8] Travis Boraten and Avinash Kodi. 2018. Mitigation of Hardware Trojan based Denial-of-Service attack for secure NoCs. J. Parallel and Distrib. Comput. 111, Supplement C (2018), 24 - 38.
- [10] T. E. Carlson, W. Heirman, S. Eyerman, I. Hur, and L. Eeckhout. 2014. An Evaluation of High-Level Mechanistic Core Models. ACM Transactions on Architecture and Code Optimization 11, 3 (Oct. 2014), 23.
- [9] T. Boraten and A. K. Kodi. 2016. Packet security with path sensitization for NoCs. In 2016 Design, Automation Test in Europe Conference Exhibition (DATE) . 1136-1139.
- [11] Y. Y. Chen, E. J. Chang, H. K. Hsin, K. C. (. Chen, and A. Y. (. Wu. 2017. Path-Diversity-Aware Fault-Tolerant Routing Algorithm for Network-on-Chip Systems. IEEE Transactions on Parallel and Distributed Systems 28, 3 (March 2017), 838-849.
- [13] S. Evain and J. P. Diguet. 2005. From NoC security analysis to design solutions. In IEEE Workshop on Signal Processing Systems Design and Implementation, 2005. 166-171.
- [12] S. Djahel, F. Nait-abdesselam, and Z. Zhang. 2011. Mitigating Packet Dropping Problem in Mobile Ad Hoc Networks: Proposals and Challenges. IEEE Communications Surveys Tutorials 13, 4 (Fourth 2011), 658-672. https://doi.org/10. 1109/SURV.2011.072210.00026
- [14] L. Fiorin, G. Palermo, S. Lukovic, V. Catalano, and C. Silvano. 2008. Secure Memory Accesses on Networks-on-Chip. IEEE Trans. Comput. 57, 9 (Sept 2008), 1216-1229.
- [16] C. H. Gebotys and R. J. Gebotys. 2003. A framework for security on NoC technologies. In VLSI, 2003. Proceedings. IEEE Computer Society Annual Symposium on . 113-117.
- [15] Jonathan Frey and Qiaoyan Yu. 2017. A hardened network-on-chip design using runtime hardware Trojan mitigation methods. Integration 56 (2017), 15-31.
- [17] Rajesh JayashankaraShridevi, Dean Michael Ancajas, Koushik Chakraborty, and Sanghamitra Roy. 2017. Security Measures Against a Rogue Network-on-Chip. Journal of Hardware and Systems Security (30 May 2017).
- [19] Hemangee K. Kapoor, G. Bhoopal Rao, Sharique Arshi, and Gaurav Trivedi. 2013. A Security Framework for NoC Using Authenticated Encryption and Session Keys. Circuits, Systems, and Signal Processing 32, 6 (Dec 2013), 2605-2622.
- [18] N. Jiang, J. Balfour, D. U. Becker, B. Towles, W. J. Dally, G. Michelogiannakis, and J. Kim. 2013. A detailed and flexible cycle-accurate Network-on-Chip simulator. In 2013 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS) . 86-96. https://doi.org/10.1109/ISPASS.2013.6557149
- [20] J. Liu, J. Harkin, Y. Li, and L. P. Maguire. 2016. Fault-Tolerant Networks-on-Chip Routing With Coarse and Fine-Grained Look-Ahead. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 35, 2 (Feb 2016), 260-273.
- [22] C. Nicopoulos, V. Narayanan, and C.R. Das. 2009. Network-on-Chip Architectures: A Holistic Design Exploration . Springer Netherlands.
- [21] G. De Micheli and L. Benini. 2017. Networks on Chips: 15 Years Later. Computer 50, 5 (May 2017), 10-11.
- [23] M. Oveis-Gharan and G. N. Khan. 2016. Efficient Dynamic Virtual Channel Organization and Architecture for NoC Systems. IEEE Transactions on Very Large Scale Integration (VLSI) Systems 24, 2 (Feb 2016), 465-478.
- [25] N. Prasad, R. Karmakar, S. Chattopadhyay, and I. Chakrabarti. 2017. Runtime Mitigation of Illegal Packet Request Attacks in Networks-on-Chip. In IEEE International Symposium on Circuits and Systems (ISCAS) . 1472-1475.
- [24] Maurizio Palesi and Masoud Daneshtalab (Eds.). 2014. Routing Algorithms in Networks-on-Chip . Springer New York, New York, NY.
- [26] Martin Radetzki, Chaochao Feng, Xueqian Zhao, and Axel Jantsch. 2013. Methods for Fault Tolerance in Networks-onChip. Comput. Surveys 46, 1 (Oct 2013), 8:1-8:38.
- [28] P. K. Sahu, T. Shah, K. Manna, and S. Chattopadhyay. 2014. Application Mapping Onto Mesh-Based Network-on-Chip Using Discrete Particle Swarm Optimization. IEEE Transactions on Very Large Scale Integration (VLSI) Systems 22, 2 (Feb 2014), 300-312. https://doi.org/10.1109/TVLSI.2013.2240708
- [27] Ahmed Saeed, Ali Ahmadinia, and Mike Just. 2016. Secure On-Chip Communication Architecture for Reconfigurable Multi-Core Systems. Journal of Circuits, Systems and Computers 25, 08 (2016), 1650089.
- [29] M. J. Sep´lveda, J. P. Diguet, M. Strum, and G. Gogniat. 2015. NoC-Based Protection for SoC Time-Driven Attacks. u IEEE Embedded Systems Letters 7, 1 (March 2015), 7-10.
- [31] Sebastian Werner, Javier Navaridas, and Mikel Luj´ an. 2016. A Survey on Design Approaches to Circumvent Permanent Faults in Networks-on-Chip. Comput. Surveys 48, 4 (May 2016), 59:1-59:36.
- [30] Fan-Hsun Tseng, Li-Der Chou, and Han-Chieh Chao. 2011. A survey of black hole attacks in wireless mobile ad hoc networks. Human-centric Computing and Information Sciences 1, 1 (22 Nov 2011), 4.

- [32] Ruilian XIE, Jueping CAI, Xin XIN, and Bo YANG. 2017. Low-Cost Adaptive and Fault-Tolerant Routing Method for 2D Network-on-Chip. IEICE Transactions on Information and Systems E100.D, 4 (2017), 910-913.
- [33] H. Zhao, N. Bagherzadeh, and J. Wu. 2017. A General Fault-Tolerant Minimal Routing for Mesh Architectures. IEEE Trans. Comput. 66, 7 (July 2017), 1240-1246.
N Prasad Navonil Chatterjee Santanu Chattopadhyay Indrajit Chakrabarti
Runtime Mitigation of Packet Drop Attacks in Fault-tolerant Networks-on-Chip
Fault-tolerant routing (FTR) in Networks-on-Chip (NoCs) has become a common
practice to sustain the performance of multi-core systems with an increasing
number of faults on a chip. On the other hand, usage of third-party
intellectual property blocks has made security a primary concern in modern day
designs. This article presents a mechanism to mitigate a denial-of-service
attack, namely packet drop attack, which may arise due to the hardware Trojans
(HTs) in NoCs that adopt FTR algorithms. HTs, associated with external kill
switches, are conditionally triggered to enable the attack scenario. Security
modules, such as authentication unit, buffer shuffler, and control unit, have
been proposed to thwart the attack in runtime and restore secure packet flow in
the NoC. These units work together as a shield to safeguard the packets from
proceeding towards the output ports with faulty links. Synthesis results show
that the proposed secure FT router, when compared with a baseline FT router,
has area and power overheads of at most 4.04% and 0.90%, respectively.
Performance evaluation shows that SeFaR has acceptable overheads in the
execution time, energy consumption, average packet latency, and power-latency
product metrics when compared with a baseline FT router while running real
benchmarks, as well as synthetic traffic. Further, a possible design of a
comprehensive secure router has been presented with a view to addressing and
mitigating multiple attacks that can arise in the NoC routers.