Secure Model Checkers for Network-on-Chip (NoC)Architectures

Travis Boraten, Dominic DiTomaso and Avinash Karanth KodiDepartment of Electrical Engineering and Computer Science

Ohio UniversityAthens, Ohio

tb286706@ohio.edu, dd292006@ohio.edu, kodi@ohio.edu

ABSTRACTAs chip multiprocessors (CMPs) are becoming more sus-ceptible to process variation, crosstalk, and hard and softerrors, emerging threats from rogue employees in a compro-mised foundry are creating new vulnerabilities that couldundermine the integrity of our chips with malicious alter-ations. As the Network-on-Chip (NoC) is a focal point ofsensitive data transfer and critical device coordination, thereis an urgent demand for secure and reliable communication.In this paper we propose Secure Model Checkers (SMCs),a real-time solution for control logic verification and func-tional correctness in the micro-architecture to detect Hard-ware Trojan (HT) induced denial-of-service attacks and im-prove reliability. In our evaluation, we show that SMCsprovides significant security enhancements in real-time withonly 1.5% power and 1.1% area overhead penalty in themicro-architecture.

CCS Concepts•Security and privacy → Hardware security imple-mentation; •Networks→ Network on chip; Denial-of-service attacks;

KeywordsHardware security; Network-on-Chip; Hardware trojan

1. INTRODUCTIONNetwork-on-Chip (NoC) architectures have emerged as

the prevailing communication fabric for on-chip communi-cation today that efficiently interconnect heterogeneous pro-cessing cores, last level of cache(s), memory controllers andI/O devices [2, 5]. As NoC coordinates and controls all datatransfer on the chip, communication on the NoC must beboth reliable and secure. However, the complex, globalizedcircuit design and fabrication process makes the NoC vul-nerable to both device faults and security threats [3, 13, 14].Reliability and security in the NoC control paths can be

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

GLSVLSI ’16, May 18-20, 2016, Boston, MA, USAc© 2016 ACM. ISBN 978-1-4503-4274-2/16/05. . . $15.00

DOI: http://dx.doi.org/10.1145/2902961.2903032

compromised by inadvertent errors, malicious hardware ora combination of both.

Inadvertent errors are unintentional bit corruptions causedby the failure or unexpected behavior of devices. Unreli-ability in devices can be caused by many factors includ-ing voltage, temperature, process variations, crosstalk, de-vice wear-out, and electromigration. The combined effect ofthese factors results in transient and permanent faults on thelinks and the router microarchitecture of the NoC which ad-versely affects the energy-efficiency and performance of theNoC due to packet loss, misrouting, packet duplication, net-work disruptions, etc. NoCs are designed with fault-toleranttechniques that include both fault-recovery and fault detec-tion techniques. To recover from errors, error correctioncodes (ECC), re-routing, modular redundancy and othertechniques could be used. To detect the errors, Built-in-Self-Test (BIST), error-detection codes (EDC) or dynamicverification with model checkers could be employed. Invari-ant model checkers are light-weight error detection mecha-nisms that target both functional as well as runtime errorswith minimal impact to power/performance of NoCs.

Malicious hardware, on the other hand, is purposefully in-jected into the system with the intent to deny service, stealinformation, slow traffic, bypass encryption/authentication,or corrupt data. A Hardware Trojan (HT) is a result ofan untrusted third-party maliciously modifying hardware atsome point during the integrated circuit (IC) design process.HTs can be inserted by an intellectual property (IP) vendor,untrusted CAD tool/designer, or at the foundry throughreverse engineering [3, 13, 14]. While ICs are extensivelytested and validated, HTs can still go undetected as bil-lions of transistors from different IP vendors are integratedon chip which make physical inspection and reverse engi-neering difficult and costly process [14]. Furthermore, withthe increase of inadvertent errors, HT can mask themselvesas transient errors which can only be activated under veryspecific conditions to avoid detection.

As HTs manifest as transient errors that either corruptdata or steal data, HTs can exploit vulnerabilities created bythe fault-tolerant techniques. For example, data corruptionon the channel connecting adjacent routers can be recov-ered by ECC that may trigger a retransmission (multi-bit er-rors using single-error correction with double error detection(SECDED)). HTs may intentionally corrupt data to causeretransmissions which may lead to a Denial-of-Service (DoS)attack by creating false congestion between the routers byconsuming network resources. While the error may appearas benign for the system, this is intentionally created by

HTs to create DoS attack and disrupt the system. There-fore we believe that both security and fault tolerance areintertwined issues and an integrated framework that simul-taneously targets both is essential and focus of this paper.

In this paper, we propose Secure Model Checkers (SMCs)- in which we provide real-time security enhancements toreduce HT micro-architecture vulnerabilities through im-proved fault coverage for control logic with minimal powerand area overhead. To achieve our objective, first we providea design methodology that identifies vulnerabilities withinthe NoC which we define as security points-of-interests (SPOI)and discuss possible mitigation techniques. To improve thesecurity of control logic, we propose secure model checkers(SMCs) to enhance dynamic verification employed by faultdetection techniques by incorporating security features thatwere identified by SPOIs. Using our design methodology,SMCs provide erroneous execution coverage for invalid, andillegal output, but also for newly defined inefficient outputto detect HT induced faults. SMCs differ from prior faultdetection model checkers as they compare previous routerpipeline stage computation with the next stage to validateand assert that the computation is legal and not malicious.Our major contributions are as follows:

1. Security Points-of-Interest: We define SPOI andtheir vulnerabilities in existing NoC micro-architecturesand fault tolerant techniques. With SPOI identified,threats are examined and adequate mitigation tech-niques proposed to improve security and reliability.

2. Secure Model Checkers: We propose SMCs, whichinclude enhancements over existing independent in-variant model checkers to improve prevention of HT-enabled DoS attacks and malicious gaming of resourcesin a compromised NoC.

2. RELATED WORK

2.1 Fault DetectionThe micro-architecture should identify, isolate, and re-

cover from faults to ensure functional correctness in criticalcontrol logic and provide recovery mechanisms when faultsare detected. One approach is to diagnose faults with BIST[7, 9, 11] that periodically evaluate the operational correct-ness of critical control logic. To minimize the performanceimpact of fault diagnosis, the authors in [12], proposed No-CAlert, a real-time fault detection mechanism implementedwith light-weight invariant checkers. Unlike BIST, whichrequires putting devices under test, invariance rule check-ing can be executed concurrently and in real-time with sim-ple hardware assertions. While invariance checkers detectfaults that create rule violations through illegal outputs,faults that create legal but invalid outputs create outcomeswhere faults may go undetected and cause devices to oper-ate in-efficiently. Careful consideration must be taken whendefining rules such that when invalid outcomes occur, faultsare benign or they are subsequently detected in downstreamrouters.

2.2 SecurityIn NoCs, several security papers have begun to address

architectural concerns in quality of service [16], DoS attacks[8, 6], HTs [1, 8, 17], and obfuscation [1]. The focal point of

recent work however, has been on prevention and mitigation,and little has been done in regards to HT detection. Thereare many reasons for this, as HTs are often dormant until ac-tivated, and when active, the diversity of HT triggers makesthis task non-trivial because triggers may be combinationalcircuits and require rare excitation, sequential, ticking timebombs, or could be externally driven. If a HT can be trig-gered, logic testing [4, 13] can be used to detect the presenceand location of the threat. Since uphill challenges exist intrying to detect HTs, authors in [1] proposed obfuscation ofrouting tables and data scrambling in an approach to reducethe chance of activating HTs triggered by snooping data ina compromised router.

More recently, a DoS attack was proposed in [8] that sup-presses allocation requests and de-prioritizes arbiters withinthe micro-architecture to increase contention and flit la-tency. While the authors proposed a runtime latency au-ditor to systematically monitor the trustworthiness of theNoC, using delay to detect an attack is difficult as severalfactors influence packet latency during normal operation.While this technique to attack is new, other existing faulttolerant run-time invariant checkers proposed in [12] couldeasily detect and prevent the attack if invariant rules areviolated, however many invariant rules fail to shield con-trol units like arbitration from de-prioritization, starvation,flooding, or modulated attacks.

Since security can be compromised by injecting faults, oneway to improve security is to identify the ways in whichfaults could be used to maliciously exploit architecture fea-tures, protocols, control logic, reconfiguring hardware, andmitigation responses. With SMCs, we enhance security byblanketing control logic with secure model checkers to de-tect HTs that would violate functional correctness in waystraditional random faults would not.

3. DESIGN METHODOLOGYIn this section we will present a design methodology that

designers could use to evaluate their architectures and aiddevelopment of future NoCs with improved security. Next,we will use our methodology and describe in detail our pro-posed secure model checkers to enhance security for pipelinecontrol logic. In the following section, we will discuss ourperformance evaluation and compare other state-of-the-artarchitectures to SMCs in terms of the reliability, networkperformance, and power and area overhead.

As hardware security emerges as a threat to undermine thereliability of future technologies, researchers need tools toevaluate the integrity of their designs, and develop hardwarewith fail-over mechanisms in a similar way we approach faulttolerance. A significant portion of that challenge starts byshifting the focus from porous post chip validation and off-line side channel analysis [15, 10], to the architectural designphase. We now outline steps that should be exercised witheach development phase.Design phase: During the design phase, architects shouldcritically analyze their implementations and thereby pin-point single points of failure, or devices that could be mali-ciously gamed. Gaming of architectural features could starve,flood, or deny service of network resources, for example, ex-ploitation of retransmission and cache coherency protocols,fairness of arbitration units, illegal VC allocations and inad-vertent triggering of power-gating or dynamic voltage andfrequency scaling (DVFS) technology. In a compromised

Table 1: SPOI for NoCsSecurity Points-of-Interest

Router1 Buffers

2Pipeline stages(BW,RC,VA,SA,ST,LT)

3 Status registers

Techniques

4 Asynchronous logic5 Cache6 DVFS7 Power-gating8 Reconfiguration9 Speculation10 Wear-out & aging11 Wireless

LinksMemory Controllers

Table 2: Security Threats for NoCsThreat Types

1 Hardware trojans (HT)2 Denial-of-Service (DoS)3 Covert Side-channels4 Side-channel analysis5 Fault tolerance

NoC, strategically placed HTs in any of those critical com-ponents within the delicate router micro-architecture couldsilently degrade performance unbeknownst to the user.Security Points-of-Interest: In our methodology, wedefine vulnerable locations and exploitable architecture fea-tures as security points-of-interest (SPOI). Accurately iden-tifying SPOI is not trivial, HTs may inject faults locallythat would traditionally be disregarded as benign, but cas-cade in a manner that violate global functional correctness.For control logic model checkers, this includes expandingthe blanket of coverage to include the validation of inputsin previous steps to validate the result of the current step.For example, a HT could suppress or impair the result inearly RC, VA, or SA stages, such that a flit that should takeST in the next stage, would be disallowed to move, but notcreate an invariance violation because the model checker forthe ST stage is independent and unaware of the results inprevious stages. In the micro-architecture, multiple viola-tions that exhibit the same dependencies exist. Outside thepipeline, many SPOI exist as extensive research in NoCshas led to adaptive, reconfigurable and increasingly com-plex designs. In table 1, we include a number of locationswe classify as SPOI for existing architectures. Techniqueslike power-gating, DVFS, and reconfiguration are SPOI be-cause they could be maliciously modulated to covertly passmessages across security domains with covert side-channelsor inadvertently switched to cause inefficient execution.Identifying Threats: After SPOI have been identified,threats can be evaluated for the design in question. In table2, we list a series of threats poised to challenge the reliabilityof future NoCs. It is important to determine the applicablethreats because each type of threat could require a uniquecounter-measure. For example, a crypto-circuit that han-dles encrypt/decrypt transactions is more likely to face side-channel attacks to steal encryption key information, while aHT attack for router control logic would be more detrimen-

Fault tolerance

Security

Reliability in NoCs

56 57

49 48

58 59

51 50

60 61

53 52

62 63

55 54

40 41

33 32

42 43

35 34

44 45

37 36

46 47

39 38

24 25

17 16

26 27

19 18

28 29

21 20

30 31

23 22

8 9

1 0

10 11

3 2

12 13

5 4

14 15

7 6

12 16

8 11

4 7

0 3

13 15

9 10

5 6

1 2

VC Allocator

Routing computation

… …

Switch Allocator

…

Crossbar Switch

Retransmit Buffers

Output 1

Output n

ECC ECC ECC ECC

ECC

ECC

Retransmission Control TMR

HT

HT

Router 1 Rogue Router

Figure 1: A secure fault tolerant stack to evalu-ate architectures during design time to identify HTpoints of interest, evaluate threats, and select ade-quate mitigation.

tal than a side-channel because the HT could not only stealinformation, but alter execution. Many of these threats havebeen recently explored for NoCs. In contrast, devices mayface a combination of threats that are not guaranteed to bemutually exclusive. A HT on links, memory controllers, orcontrol logic, could be engineered to create a control-drivenDoS attack, unlike flood-based bandwidth depleting DoS.In NoCs, detection of a particular control-driven DoS at-tack was proposed in [8], but in this paper we will show howour proposed SMCs can prevent the attack, after identifyingthe porus holes with existing fault tolerant designs.Mitigation Selection: While challenges continue to existin off-line detection for integrated circuits, architects shoulddevelop designs with detection and mitigation techniques.Ignoring threats could facade performance and overall reli-ability. After carefully identifying SPOI and evaluating de-signs for vulnerabilities, selecting the proper detection andmitigation techniques to reinforce weak points in the de-sign is the last step in the process. In Figure 1, we show acompromised NoC with multiple HTs embedded within thepipeline logic and buffers. The infected routers were cho-sen randomly but could be selected appropriately to targetresources in different geographical locations of the chip. Inthis scenario, HTs have access to influence resource alloca-tions and corrupt data. Currently, fault tolerance for faultsin both locations is inadequate to prevent such an attack.For example, when flits are transmitted, switch-to-switch(s2s) ECC decodes for errors, after which the data is storedin buffers unprotected. Typically the data is not encodeduntil the flit progresses to the next router. A HT injectingfaults in the buffer will bypass s2s detection. For a controllogic HT, suppression of requests in VA logic for a flit couldside-line a packet and create a DoS attack. Suppressing therequest effectively masks the fault as a loss in arbitrationand the fault would be undetected.

To improve reliability, we propose a two-fold approachinvolving fault tolerance and security. In Figure 1, we il-lustrate the reliability stack which consists of Obfuscation,Authentication, Quality of Service, ECC, Redundancy, andModel Checkers. Each of the SPOIs and threats presentedabove can be addressed with at least one element of thestack. In the next sections, we will describe how we use ele-ments of the stack to improve coverage for control flow anddata paths.

4. SECURE MODEL CHECKERSTo protect the critical micro-architecture pipeline and its

control logic, light-weight invariant model checkers proposedin [12], provide near instantaneous concurrent fault detec-

Step:N Logic Step:N+1

Validate Step: N+1

Existing invariance model checkers

Step:N Logic Step:N+1

Validate Step: N+1

Validate Step: N

Assert

Assert

Assert New model checkers

BW RC VA SA ST

MC MC MC MC

NoC Alert Fault coverage

BW RC VA SA ST

SMC

SMC Fault coverage SMC SMC SMC

MC

SMC

Normal output

Inefficient output

Benign (masked)

Invalid output Illegal output

Validate Previous Step New

Coverage

Existing Coverage

Fault tolerance

Security Key:

Model Checkers

IN OUT

Assert Logic input

Logic output

Ineff-Eval

Secure Model Checker (SMC)

Figure 2: High level overview and the fault coverageenhancements for the proposed SMCs.

tion. Model checkers consist of hardware assertions withsimple combinational logic, implemented to follow a set ofinvariant rules. The invariant rules are enforced by com-paring the inputs of control logic to the output. Outputfor model checkers can be classified in the following ways:Normal, and Invalid. Invalid output can be benign, or ille-gal. Illegal output is output that violates an invariant rule.For example, if an arbiter receives one or more requests, atleast one grant should be on the output. An assertion flagis raised when a violation occurs.Inefficient Output: For SMCs we expand this model toinclude an additional classification of invalid output, namely,inefficient output. In Figure 2, we show a generic modelchecker, a proposed SMC, and the expansion of coverage.In Figure 3, we further expand the classification of ineffi-cient output and provide example violations. For inefficientoutput, this includes the modulated, flooded, starved andde-prioritization of network resources. In this paper, wepropose security through enhanced fault tolerance to detectmalicious gaming of resources. In traditional fault toler-ance, the threat of inefficient output exist through perma-nent faults but is minimal. When transient faults occurin this category, the faults will be detected downstream orresult in benign violations. We will now discuss how ourproposed SMCs include coverage for the new violations.Starvation & Previous Step Validation: For existingmodel checkers shown in Figure 2, we define the output theyvalidate as the next step (Step N+1). The input providedto the control logic, which came from the previous stage,is defined as the previous step (Step N). For example, StepN could be the execution of the RC stage and Step N+1 isthe following VA stage. Between the time RC and VA wascomputed in adjacent cycles, the output of RC is stored forthe flit and the state machine tracking pipeline progress isupdated, allowing the flit to request VA in the next cycle.

Invalid output

Inefficient

output

De-prioritization

Starved Flooded Modulated Benign

(masked)

Illegal output

Policy

violation

Out of

range

Dual

allocation

Output Classification

New Coverage

Existing Coverage

Figure 3: Threat identification and enhancementsfrom traditional model checkers to the proposedSMCs.

While invariant rules cover the detection of faults on theinputs of control logic, generic model checkers are designedindependently and Step N+1 is oblivious to output gener-ated in the Step N. If a HT is maliciously suppressing a VArequest, the generic model checker methodology would notraise an invariance violation and diagnose the fault as be-nign. Disallowing the flit to move and disguising the faultas a arbitration loss because the generic model checker isunaware of the results in the previous stage. We integrateour proposed SMCs and define new violations to detect HTsand prevent them from stalling flits by suppressing resourcerequests. The integration of SMCs is shown in Figure 2.Each SMC has access to adjacent SMCs and direct accessto buffers and status registers. For a SMC blanketing a VAblock, a HT suppressing a request would no longer go un-detected. Other scenarios exist that include SA and creditcounts and SA, ST integration. A complete list of violationswill be provided later in the paper.De-prioritization: In addition to suppressing requestsand grants, arbiters are vulnerable to de-prioritization HTattacks. In a de-prioritization attack, a HT embedded withinarbitration logic directly influences the allocation of resources.Flits could be permanently or periodically stalled to createa DoS attack. Depending on the implementation (roundrobin, weighted, FIFO) different approaches are required.For FIFO and round robin, no requester should win consec-utive grants in the presence of multiple requesters. To cap-ture the violation, previous inputs and outputs are storedto validate the next grant. For weighted, detection is longerbecause counters are needed to measure the arbitration fair-ness. In the performance evaluation section, we will evaluatethe cost of each approach.

5. PERFORMANCE EVALUATIONIn this section, we provide the results of the proposed

SMCs and discuss our HT detection technique to addressthe SPOI presented earlier in this paper in terms of area,power, detection latency, and network performance. In ourevaluation, we compare against NoCAlert [12], an existingfault tolerant detection framework that originally proposedlight-weight invariant checkers for real-time fault detectionin the router micro-architecture.

As a first order analysis, we assume only a single point ofattack in the compromised NoC which is sufficient to pro-vide significant network disruption but the number of com-promised routers is orthogonal. Power and area were syn-thesized and optimized using the Synopsys Design Compiler

In

pu

t D

em

ux

…

…

…

…

…

Routing Computation

(RC)

VC Allocator (VA)

Switch Allocator (SA)

Crossbar …

Model Checkers

IN OUT

Assert

Model Checkers

IN OUT

Assert

Model Checkers

IN OUT

Assert Bu

ilt-I

n S

elf-

Test

(B

IST)

Model Checkers

IN OUT

Assert O

utp

ut

Mu

x

s2

s

EC

C

In

pu

t D

em

ux

…

…

…

…

…

Ou

tpu

t M

ux

Flow

Control

Ineff-Eval

Ineff-Eval

Ineff-Eval

Ineff-Eval

S2

s

EC

C

Model Checkers

IN OUT

Assert Logic input Logic output

Ineff-Eval

…

…

…

…

Output 1

Output N

Secure Model Checker

…

Figure 4: The SMC micro-architecture with the pro-posed enhancements in blue.

tool using the TSMC 40 nm technology libraries with a 1.0V supply voltage and 2 GHz operating frequency. Networkevaluation was conducted using an in-house cycle accuratenetwork simulator and used real traffic distributions fromthe PARSEC and SPLASH-2 benchmark suites on a 64-core,16 router mesh-based NoC with each router connected to 4cores. Each router has two unidirectional links connectingadjacent routers with 4 VCs per port and a 5-stage routerpipeline.

5.1 Micro-architecture RulesIn this section, we describe the proposed micro-architecture

and a set of additional functional correctness rules obtainedusing our SPOI methodology. In Figure 4, we illustrate themodifications needed to implement SMCs (shown in blue) ina typical fault tolerant micro-architecture (shown in grey),and arrows between each model checker to relay previousstate information between consecutive stages. In additionto previous state information, SMCs concurrently observeinputs and output values to verify the functional correct-ness of each pipeline stage without causing an interruptionin performance during fault free operation. In Figure 5, welist a portion of invariance rules proposed in [12] (left), andthe security enhancements provided by SMCs proposed inthis paper (right) for a detail comparison. It is importantto note NoCAlert was originally designed with naturally oc-curring faults in mind and not those injected to maliciouslygame network resources and produce in-efficient output ordenial of service. With the expansion of coverage shown inFigure 5, we improve the reliability of NoCs by increasingour ability to verify functional correctness and detect HTs.When SMCs detect HTs our proposed design could comple-ment mitigation techniques by enabling them or begin theshutdown of compromised components in a controlled man-ner.

5.2 Area overhead and power consumptionOur proposed design includes additions to the BW, RC,

VA ,SA and ST stages of the router micro-architecture. Thearea overhead and power consumption for each stage is pre-sented in Figure 6 and 7 respectively. While the overheadcost for area and power consumption is larger than that ofNoCAlert, that is expected as the proposed SMCs includeadditional hardware assertions and are integrated together

# Existing Model Checkers (NoCAlert) SMC enhancments #

RC

1 Illegal turn Inefficient route selection 1

2 Invalid RC output direction Deprioritization (if required) 2

3 Non-minimal routing (if required)

VA a

nd S

A

4 Grant w/o request No VA requests w/ existing flits 3

5 Grant to nobdy No VA requests w/ mismatched credit count 4

6 1-hot grant vector Deprioritization of VA grants 5

7 Grant to occupied or full VC VA requets inconsistent with flits in previouc RC cycle 6

8 One-to-One VC assignment No SA requests w/ existing flits 7

9 One-to-One port assignment No SA requests w/ mismatched credit count 8

10 VA agress with RC Deprioritization of SA grants 9

11 SA agrees with RC

12 Intra-VA stage order

13 Intra-SA stage order

ST

14 1-hot column control vector ST inconsistent with grants in previous VASA cycle 10

15 1-hot row control vector

16 # of Incoming flits equals # of Outgoing flits

Figure 5: List of invariant rules proposed in [12](left), and security rule enhancements proposed inthis paper with SMCs (right).

NoC Alert SMCs

Area (um2)

RC 37.926 37.044

VASA 51.3324 107.604

ST 9.3492 15.1704

Buffer 38.2788 38.2788

Port 15.6996 15.6996

End-to-End 13.0536 13.0536

0

50

100

150

200

250

Mo

de

l C

he

ck

er

Are

a O

ve

rhe

ad

(u

m2

)

End-to-End Port Buffer ST VASA RC

Figure 6: Comparison of area overhead for SMCs totraditional model checkers.

to expand coverage to malicious HTs. Results indicate a35% increase in total area overhead, and 124% increase inpower consumption to that of NoCAlert with round robinarbitration. This cost however, is only 1.1% area overheadand 1.5% power consumption of a single router. The major-ity of the SMC cost is due to the verification of arbitrationunits and the counters needed to detect de-prioritization.Since it is not uncommon for NoCs to implement other ar-bitration methods such as round robin and different weightsfor VA and SA, we provide a comprehensive look at the costof arbitration shown in Figure 8. What we found was thatverifying round robin is significantly cheaper than weightedunits because of expensive multi-bit counters.

5.3 Detection latencyWhen protecting against HTs, time is of the essence since

a single HT could cause denial of service, create routingdead-locks, or covertly leak sensitive information. To avoiddetection, HTs can be implemented in a variety of waysand lay dormant until selectively enabled through combina-tion logic, sequential clocks, or external signals. Fortunately,with our proposed SMCs, near instantaneous HT detectionis possible within pipeline control logic. For rules involvingprevious state information, SMCs can detect each violationin the subsequent cycle. For de-prioritization, the detectionlatency depends on the size of counters needed to measureweighted values which could reach tens to hundreds of cy-cles. For round robin arbitration, detection time is nearinstantaneous.

NoC Alert SMCs NoC Alert SMCs

Dynamic Power (uw) Static Power (nw)

RC 6.9646 6.9739 13.7104 14.5054

VASA 6.9649 47.505 18.1341 46.7618

ST 4.1702 4.6024 4.6856 7.9891

Buffer 5.9119 5.9119 15.7099 15.7099

Port 3.4348 3.4348 2.8368 2.8368

End-to-End 4.9633 4.9633 7.2056 7.2056

0

10

20

30

40

50

60

70

80

90

100M

od

el

Ch

eck

er

Po

we

r C

on

su

mp

tio

n

End-to-End Port Buffer ST VASA RC

Figure 7: Comparison of power consumption forSMCs to traditional model checkers.

6.9649

40.83

27.6987

47.5609

72.1133

85.2545

51.3324 56.0952 55.2132

107.7804

179.5752

221.0292

0

50

100

150

200

250

0

10

20

30

40

50

60

70

80

90

VASA Round RobinWeighted 2 Weighted 3 Weighted 4 Weighted 5

Are

a (

um

2)

Dyn

am

ic P

ow

er

(uW

)

Dynamic Power (uw) Area (um2)

Figure 8: Comparison of area overhead and powerconsumption for arbitration model checker units.

6. CONCLUSIONIn this paper, we proposed a design methodology that de-

fined SPOI and their vulnerabilities in existing NoC micro-architectures and fault tolerant techniques. With SPOI iden-tified, we then proposed SMCs to provide near instantaneousHT detection and prevent in-efficient gaming of network re-sources with only 1.1% and 1.5% total router area overheadand power consumption respectively. With identification ofSPOI, SMCs could be tailored to future designs and im-prove on mitigation techniques complemented by our threatdetectors.

AcknowledgementThis research was partially supported by NSF grants CCF-1054339 (CAREER), CCF-1420718, CCF-1318981, ECCS-1342657, and CCF-1513606.

7. REFERENCES[1] D. M. Ancajas, K. Chakraborty, and S. Roy.

Fort-nocs: Mitigating the threat of a compromisednoc. In Proceedings of the The 51st Annual DesignAutomation Conference on Design AutomationConference, DAC ’14, 2014.

[2] L. Benini and G. De Micheli. Networks on chips: anew soc paradigm. Computer, 35(1):70–78, 2002.

[3] S. Bhunia, M. Hsiao, M. Banga, and S. Narasimhan.Hardware trojan attacks: Threat analysis andcountermeasures. Proceedings of the IEEE,102(8):1229–1247, Aug 2014.

[4] R. S. Chakraborty, F. Wolff, S. Paul, C. Papachristou,and S. Bhunia. Mero: A statistical approach forhardware trojan detection. In Proceedings of the 11th

International Workshop on Cryptographic Hardwareand Embedded Systems, CHES ’09, 2009.

[5] W. J. Dally and B. Towles. Route packets, not wires.In Proceedings of the Design Automation Conference(DAC), Las Vegas, NV, USA, June 18-22 2001.

[6] D. Fang, H. Li, J. Han, and X. Zeng. Robustnessanalysis of mesh-based network-on-chip architectureunder flooding-based denial of service attacks. InNetworking, Architecture and Storage (NAS), 2013IEEE Eighth International Conference on, pages178–186, 2013.

[7] D. Fick, A. DeOrio, J. Hu, V. Bertacco, D. Blaauw,and D. Sylvester. Vicis: A reliable network forunreliable silicon. In Design Automation Conference,2009. DAC ’09. 46th ACM/IEEE, pages 812–817,2009.

[8] R. JS, D. M. Ancajas, K. Chakraborty, and S. Roy.Runtime detection of a bandwidth denial attack froma rogue network-on-chip. In Proceedings of the 9thInternational Symposium on Networks-on-Chip, NOCS’15, pages 8:1–8:8, 2015.

[9] M. Kakoee, V. Bertacco, and L. Benini. A distributedand topology-agnostic approach for on-line noc testing.In Networks on Chip (NoCS), 2011 Fifth IEEE/ACMInternational Symposium on, pages 113–120, 2011.

[10] J. Li and J. Lach. At-speed delay characterization foric authentication and trojan horse detection. InHardware-Oriented Security and Trust, 2008. HOST2008. IEEE International Workshop on, June 2008.

[11] R. Parikh and V. Bertacco. Forever: A complementaryformal and runtime verification approach to correctnoc functionality. ACM Trans. Embed. Comput. Syst.,13(3s):104:1–104:30, Mar. 2014.

[12] A. Prodromou, A. Panteli, C. Nicopoulos, andY. Sazeides. Nocalert: An on-line and real-time faultdetection mechanism for network-on-chiparchitectures. In Microarchitecture (MICRO), 201245th Annual IEEE/ACM International Symposium on,pages 60–71, 2012.

[13] S. Sethumadhavan, A. Waksman, M. Suozzo,Y. Huang, and J. Eum. Trustworthy hardware fromuntrusted components. Commun. ACM, 58(9):60–71,Aug. 2015.

[14] M. Tehranipoor and F. Koushanfar. A survey ofhardware trojan taxonomy and detection. Design Testof Computers, IEEE, 27(1):10–25, Jan 2010.

[15] X. Wang, H. Salmani, M. Tehranipoor, andJ. Plusquellic. Hardware trojan detection and isolationusing current integration and localized currentanalysis. In Defect and Fault Tolerance of VLSISystems, 2008. DFTVS ’08. IEEE InternationalSymposium on, Oct 2008.

[16] H. M. G. Wassel, Y. Gao, J. K. Oberg, T. Huffmire,R. Kastner, F. T. Chong, and T. Sherwood. Surfnoc:A low latency and provably non-interfering approachto secure networks-on-chip. SIGARCH Comput.Archit. News, 41(3):583–594, June 2013.

[17] Q. Yu and J. Frey. Exploiting error control approachesfor hardware trojans on network-on-chip links. InDefect and Fault Tolerance in VLSI andNanotechnology Systems (DFT), 2013 IEEEInternational Symposium on, Oct 2013.