1

IIPS: Infrastructure IP for Secure SoC DesignXinmu Wang, Member, IEEE, Yu Zheng, Student Member, IEEE, Abhishek Basak, Student Member, IEEE,

and Swarup Bhunia, Senior Member, IEEE

Abstract—Security is becoming an increasingly important parameter in current system-on-chip (SoC) design due to diverse hardwaresecurity attacks that can affect manufacturers, system designers or end users. To effectively address the security issues, design-timeconsiderations, i.e. incorporation of Design-for-Security (DfS) features, are becoming essential. However, DfS measures for diversesecurity threats require specific design modifications to achieve target security level, which significantly increases design effort thustime-to-market, and usually incurs considerable design overhead. In addition, the general heterogeneous architecture of current SoCsmakes many core level DfS mechanisms unusable at SoC level. In this paper, we propose a centralized on-chip infrastructure IP for SoCsecurity (IIPS), which alleviates the SoC designers from separately addressing different security issues through design modifications inmultiple cores. It also provides ease of integration and functional scalability. We consider a specific implementation of IIPS that providesprotection against (1) scan-based attack for information leakage through low-overhead authentication; (2) counterfeiting attacks throughintegration of a Physical Unclonable Function (PUF); and (3) hardware Trojan attacks through a test infrastructure for trust validation.To make the IP amenable for plug-and-play during SoC design, working protocols of the security functions are designed to comply withIEEE 1500 Standard for Embedded Core Test (SECT). Since IIPS resides outside the functional modules, it does not incur functionalperformance or power overhead. Simulations and experiments on example SoC designs validate the effectiveness of IIPS in providingprotections against diverse attacks at a low hardware overhead.

Keywords—System-on-chip Security, Infrastructure IP, Hardware Trojan, PUF, Scan-based Attack

F

1 INTRODUCTION

S ECURITY is becoming an increasingly important pa-rameter in modern System-on-Chip (SoC) design.

This is primarily due to the fact that for various formsof existing and emerging security attacks at hardwarelevel, post-manufacturing detection alone cannot provideadequate protection. Fig. 1(a) displays diverse hardwaresecurity issues at different stages of SoC developmentand deployment cycle. To effectively protect SoC hard-ware against these threats, design-time considerationsare becoming mandatory as a mechanism to preventan attack or facilitate detection (or recovery) in theevent of an attack. Major threats that are currently beingconsidered in academia and industries include hardwareTrojan attacks in the form of malicious modifications of adesign; hardware intellectual property theft, such as ille-gal sale or use of soft IP cores/ICs; and physical attackson cryptographic systems during deployment, e.g. side-channel attack, fault-based attack, and scan-based attack.Different design solutions have already been reported toprotect against these attacks. For hardware Trojan threats,rare-event removal [15] and ring-oscillator (RO) network[13] have been proposed as design-for-security (DfS) ap-proaches to facilitate Trojan detection or partially preventTrojans from functioning. For hardware IP protection,

• X. Wang, Y. Zheng, A. Basak and S. Bhunia are with the Departmentof Electrical Engineering and Computer Science, Case Western ReserveUniversity, Cleveland, USA, 44122.E-mail: {xxw58, yxz402, axb594, skb21}@case.edu

techniques like Physical Unclonable Function (PUF) [4],IC metering [8] and hardware obfuscation [12] havebeen proposed to achieve passive or active protection.For power analysis attacks on crypto modules, variouscountermeasures have been reported which require de-sign modification at architecture [1] or circuit level [2].Similarly, several secure scan architectures have beenpresented earlier [5] [11] [6] [7] to prevent scan-basedattack. These solutions collectively show that DfS ap-proaches can provide effective countermeasures againstdifferent threats.

However, with the emerging trend of IP-based SoCdesign, incorporating DfS features in a SoC faces thefollowing major challenges: 1) It requires design of eachIP to be modified at design time, thus considerably in-creasing design effort, hardware overhead, and time-to-market; 2) Separate DfS features need to be incorporatedto protect against multiple attacks, which can imposeconflicting design as well as test requirements; and 3)The heterogeneous architecture of many modern SoCs,makes core-level DfS measures difficult to apply at SoClevel. The situation is aggravated by the prevalent use ofthird-party IP cores during SoC design, which prohibitsarbitrary modifications in a IP. Moreover, many of thesetechniques incur large silicon area and power overhead,and may cause considerable performance degradation.For example [2] increases the area and power consump-tion of a crypto core by more than 200%, and theone in [3] incurs 38% performance overhead. The DfSscheme presented in [11] causes significant performancedegradation and suffer from scalability issue. Therefore,

2

(a)

(b)

Fig. 1. (a) Security threats at different stages of ICdevelopment and deployment cycle; (b) Proposed infras-tructure IP for security (IIPS) interfaces with constituentcores of a SoC and provides a flexible, convenient meansof addressing various security concerns.

it is desirable to have an easy-to-integrate scalable IPthat serves as a centralized resource in a SoC to achievecomprehensive protection against diverse attacks at lowdesign and hardware overhead. Such an IP resembles aninfrastructure IP for SoC verification or test [16] [19], butis dedicated to provide security against various attacks.

In this paper, we propose an infrastructure IP for SoCsecurity, referred to as IIPS. IIPS can efficiently interfacewith constituent cores in a SoC through the use of IEEE1500 Standard Embedded Core Test (SECT), as illustratedin Fig. 1(b). It can provide protection against diverseattacks by either preventing an attack or facilitatingdetection/recovery during manufacturing test. This cen-tralized module acts as a plug-and-play reusable core fora SoC designer. We have presented general design of IIPSand its interface with other cores. Furthermore, we haveconsidered a specific case study using three major attackmodels. First, it provides protection against scan-basedattack that aims at information leakage through illegalaccess of a scan chain. The protection is realized throughan authentication process, which conditionally activatesthe scan chains within IPs based on checking a key.Next, it integrates a low-overhead Physical UnclonableFunction (PUF) primitive for device authentication orcryptographic key generation. It uses a prevalent Design-for-Testability (DfT) structure, namely, the scan chain toimplement the PUF. Finally, it implements an infrastruc-ture (based on path delay analysis) for trust validationin presence of hardware Trojan attacks. We show that allthe countermeasures exploit the existing test wrappersin IPs to greatly minimize the overhead.

We show that IIPS requires minimal modifications tofunctional cores for interfacing, thus facilitating system-level integration. Since it resides outside the functionalcores and only activates when performing test or securitytasks, it does not incur functional performance/poweroverhead. Our analysis shows that the die-area overheadis very low for realistic SoCs, and is further minimized bysharing the same infrastructure among multiple securityprimitives. In particular, major contributions of the paperare as follows:

(1) The paper proposes, for the first time to our knowl-edge, an on-chip infrastructure IP, which can provideprotection against multiple security threats for a SoC.

(2) It describes an efficient, general interface of IIPSwith functional IP cores through standard SoC bound-ary scan architecture [25]. It presents appropriate low-overhead design modifications in the IP cores for inter-facing with IIPS.

(3) For three dominant threat models, it studies thedesign of IIPS and its interface. In particular, it considers:(i) scan based attack, (ii) counterfeiting attack, and (iii)hardware Trojan attack. It presents the design require-ments for protection against these attacks and optimizesIIPS implementation for hardware overhead.

(4) It presents simulation as well as measurementresults to validate the IIPS module functionally, evalu-ate the hardware overhead and verify its capability inachieving SoC security against the attacks considered.

The remainder of the paper is organized as follows.Section 2 provides background of infrastructure IP andembedded core test standard. Section 3 presents anoverview of IIPS, followed by the design details inSection 4. Section 5 describes the SoC level test protocol.Simulation and experimental results are presented in Sec-tion 6. Section 7 discusses functional flexibility, scalabilityand integrity of IIPS. We conclude in Section 8.

2 BACKGROUND

2.1 Infrastructure IPInfrastructure IPs (IIPs) refer to a range of IPs that arededicated to facilitate SoC functional verification, testingor yield improvement. Synopsys Inc. provides a set ofverification IPs that can be instantiated in a SoC toverify certain bus protocols [16]. These IPs are targetedto benefit front-end SoC designers, and do not existon the manufactured SoCs. There are also IIPs that areon-chip modules to be fabricated in order to facilitatepost-manufacturing test or debug or to improve yield.Examples include the structures proposed in [19] to helpin-field SoC test, for embedded timing characterization[20], transient-error tolerance [21], and for mixed-signalyield improvement [22]. Several vendors provide test-IP products for test capability enhancement for board-level designs [17]. The demand for on-chip dedicatedinfrastructure logic to facilitate test and debug is risingdue to increasing SoC defect rate and test time/cost [18].

3

Fig. 2. IEEE 1500 Standard: (a) core wrapper interfaceterminals; (b) mandatory components of the wrapper [23].

The proposed infrastructure IP for security shares thesame motivation and design principles as IIP for test.

2.2 IEEE 1500 Standard

The general heterogeneous architecture of SoCs limitsthe controllability and observability of internal functionalIP cores affecting test coverage. It requires incorporatingcertain infrastructure logic at design time to allow effec-tive testing of IP cores. Besides, test reuse is becomingan indispensable part in SoC development [23]. It createsa need for a standard test protocol associated with thetest infrastructure hardware so that different IP corescan be tested with a unified test framework, and corelevel test sets created by the core developer can be easilyexpanded to SoC level. IEEE Std. 1500 is the test standarddeveloped to serve these purposes.

IEEE Std. 1500 [25] contains two parts: (1) a coretest wrapper architecture for test access to embeddedcores; and (2) a core test language (CTL) [24] for coretest knowledge transfer. To comply with the standard,each IP core in the SoC should have a test wrapper.The wrapper provides one boundary register cell foreach functional I/O port of the core, where all bound-ary register cells are referred to as Wrapper BoundaryRegister (WBR). It also contains a Wrapper InstructionRegister (WIR) and a Wrapper Bypass Register (WBR). Fig.2 displays a high-level core wrapper interface and themandatory components of a core wrapper.

Test access to the embedded cores is enabled by thecore wrapper and an on-chip Test Access Mechanism(TAM). Fig. 2(a) shows two ways of accessing the cores:the mandatory Wrapper Serial Ports (WSP) and the op-tional Wrapper Parallel Ports (WPP). WSP provides asingle bit test data port (WSI/WSO) along with testclock (WRCK) and control signals (WSC), while WPPoffers a larger bit-width for more efficient test execution.However, IEEE Std. 1500 does not anticipate a WPPport, for which the design responsibility resides with thecore provider. In this work, IIPS design exploits WSP.However, it can be extended to also use WPP, if available.

Fig. 3. Block diagram of the IIPS module showing in-terconnection with other IP cores in a SoC using SoCboundary scan architecture.

Fig. 4. State transition diagrams of the IIPS master FSMand Scan enable control FSM embedded inside it.

3 OVERVIEW OF IIPSThe block diagram of IIPS is provided in Fig. 3. It consistsof a Master Finite State Machine (M-FSM) that controlsthe working mode of IIPS, a Scan Chain Enabling FSM(SE-FSM) to provide individual control over activationof scan chains in the SoC, and a clock control moduleto generate necessary clock and control signals for per-forming ScanPUF authentication and path delay basedhardware Trojan detection. The state transition diagramsof the M-FSM and SE-FSM are illustrated in Fig. 4.When enabled, IIPS takes the standard SoC test inputsfrom Wrapper Serial Port (WSP) (WSO output pin is notshown). As outputs, IIPS sends one scan chain enablesignal to each functional-IP core, and replaces the orig-inal test clock WRCK with CLK, which is generated in-side IIPS, to support ScanPUF authentication and Trojandetection. Besides, test control ShiftWR and CaptureWRapplied to the cores are replaced with ShiftWR TD andCaptureWR TD during Trojan detection for automaticcapture of test responses. In short, IIPS serves as a testcontrol line translator. SoC test inputs arrive at IIPS, andIIPS generates the actual test clock and control signals

4

that are applied to the cores. During normal testingthe test signals are automatically preserved by IIPS. Asingle functional clock is assumed in this work andmultiple clock domains can be adapted with slightlyaltered design of the clock control module.

After IIPS is turned on, M-FSM starts from IDLE state.A specific vector sequence applied at WSP can bring M-FSM to SC EN state to allow scan chain activation. Afterscan chain activation is done, M-FSM can be set to Scan-PUF or TrojDet state to perform ScanPUF authenticationor hardware Trojan detection, respectively. SC EN stateis designed to precede ScanPUF and TrojDet states, be-cause both ScanPUF and Trojan detection require at leastone active scan chain. Specific sequences of vectors arerequired for M-FSM to switch among different securityfunctions, acting both as an authentication mechanismand to prevent unintentional trigger of a function. Whenperforming each IIPS function, M-FSM stays in the corre-sponding state; when the task is completed, M-FSM canbe reset to IDLE state with IIPS reset signal IIPS RSTN.The SC LOCK and TD LOCK states are two lockingstates designed to support scan chain based SoC testingand delay fault testing, respectively, as described belowin detail. When IIPS is deactivated or in the lockingstates, intact test signals are propagated to the functionalcores; during IIPS security functions, modified (in Scan-PUF and TrojDet) or deasserted (in SC EN) signals willbe applied to the functional cores.

IEEE 1500 compliant SoCs have a standard activelow test reset signal WRSTN. Since the test inputs WSPusually reuse chip functional inputs, WRSTN is requiredto separate the test mode from functional mode byinterpreting the inputs as test signals, and consequentlyconfiguring the test infrastructure as well as propagatingtest data. Similarly, one extra input pin IIPS RSTN isneeded in the SoC to provide an active low reset signalfor IIPS. Active IIPS RSTN disables IIPS by setting M-FSM to IDLE. IIPS RSTN and WRSTN together definefour operating modes of the SoC:

(i) {IIPS RSTN, WRSTN} = “00”, functional mode;(ii) {IIPS RSTN, WRSTN} = “01”, basic SoC test mode;(iii) {IIPS RSTN, WRSTN} = “11”, advanced SoC test

mode requiring faster-than at-speed delay test;(iv) {IIPS RSTN, WRSTN} = “10”, IIPS security mode.In mode (i) and (ii), IIPS is not turned on. Hence mode

(ii) can only perform basic SoC testing where core scanchains are disabled, and delay fault testing is not sup-ported. Mode (iii) enables IIPS to allow scan-chain basedSoC testing and delay fault testing. One requirement inthis procedure is that IIPS should not have unnecessarystate transitions in order to avoid interfering with thenormal testing procedure. For example, in scan-basedtesting, IIPS should enable the scan chains as requestedand then stay idle during the rest of the test. If M-FSM happens to enter ScanPUF or TrojDet state, the testclock WRCK and scan shift signal ShiftWR will be tam-pered, causing wrong test responses. Similarly, duringdelay testing, IIPS should transition to the TrojDet state

to provide appropriate clock signals. To achieve such“functional locking”, states SC LOCK and TD LOCKare added to M-FSM for scan-based and delay testing,respectively. In the locking states, proper output signalsare retained, but any state transition is disallowed exceptfor resetting the entire IIPS to IDLE with IIPS RSTN. Inthe SC LOCK state, IIPS maintains the scan chain enablesignals as determined in SC EN state. Similarly, the clockand test control signals in TrojDet state are available inTD LOCK state for delay testing.

4 DESIGN OF IIPS SECURITY FUNCTIONS4.1 Attack Models and Mitigation Strategies4.1.1 Scan-based Attack in Cryptographic SystemsScan chain is the most prevalent DfT infrastructure inmodern ICs. It helps to greatly improve the controlla-bility and observability of internal nodes, thereby en-hancing structural test coverage. However, scan chainturns out to be a two-edged sword when it comesto security hardware like cryptographic processors orASICs. The enhanced controllability and observabilitythat scan chains offer can help reveal internal secret infor-mation (e.g. a cryptographic key) from a chip. Previousstudies [6] have demonstrated that by operating AESin functional and scan modes alternately, intermediatecomputation of each clock cycle can be observed throughthe scan chain. With a chosen plain-text attack, the secretkey can then be discovered easily.

Several secure scan architectures have been proposedto prevent access to scan chain by illegal users. Thecommon philosophy behind them is to implement anauthentication mechanism to allow only legitimate scanaccess. In particular, the scan structure in [5] masks thescan output with pseudo random numbers when usersfail to embed the correct test key into their test vectors. In[6], authors proposed a method to isolate important dataregisters (e.g. those holding the keys) when the chip runsin insecure mode. A low-overhead authentication basedscan protection was proposed in [7] that gates the scanoutput unless the authentication is successful.

In IIPS, we adopt VIm-Scan proposed in [7] primarilydue to the fact that it does not require structural changeson the scan chains except for the minor interface adap-tion. Hence, it minimizes the design modification in SoCfunctional cores and facilitates the integration process. Italso provides the advantages of ultra-low overhead andgood scalability to larger SoCs.

4.1.2 Counterfeiting AttacksCurrent trend in outsourcing design and fabrication ofSoCs provides opportunities for counterfeiting attacksthrough cloning and overproduction of chips. Increasingincidences of counterfeit chips in a supply chain pose aserious concern to the SoC designers as well as systemintegrators. Device authentication has been consideredas an effective method to prevent counterfeiting attacks.

5

By assigning each legitimately fabricated IC a unique IDand registering it in a vendor-built database, consumerscan authenticate each IC and thus get only the authenticones activated and deployed [9]. However, a digitallystored device ID is not secure or tamper-proof. Invasiveor non-invasive methods can be applied to reveal thestored ID [10], and a cloned device can be programmedwith the same ID subsequently. On the other hand, un-clonable IC fingerprints based on PUF have been widelyinvestigated as a reliable vehicle for authentication. PUFforms an important security primitive by exploiting in-trinsic process-induced variations in circuit parameterssuch as path delay to generate unique device signatures.Well-designed PUFs are also expected to exhibit highuniqueness and robustness, thus are capable of reliablyidentifying authenticity of ICs.

To integrate a PUF primitive into IIPS, it is necessarythat it incurs low silicon overhead considering both thePUF circuitry and the control logic for signature genera-tion. Moreover, it is desirable that the signature genera-tion and extraction process complies with standard SoCtesting flow. With these requirements, we employ theScanPUF architecture described in [30], which is realizedwith scan chain in the IPs. It incurs negligible hardwareoverhead and provides high uniqueness and robustness.

4.1.3 Hardware Trojan AttackMalicious modification of a design, also known as, hard-ware Trojan attack, in untrusted fabrication facilities ordesign house has emerged as a major security concern[34]. Due to their stealthy nature and practically infiniteTrojan space (in terms of trigger conditions, forms andsizes), a cleverly inserted Trojan in large SoC is highlylikely to evade conventional post-silicon testing. Further-more, malicious hardware can easily bypass traditionalsoftware-implemented defense techniques as it is a layerbelow the entire software stack.

To address the threat of Trojan attack, several promis-ing Trojan detection approaches have been proposed,including logic testing and side-channel analysis basedmethods. In the context of IIPS, we focus on the lattermethods due to the following reasons. First, it is gen-erally believed that larger Trojans specifically sequentialTrojans requiring a sequence of rare events to trigger, areextremely difficult to detect in logic testing, due to diffi-culty in activating such Trojans [37]. Second, on-chip gen-eration of targeted test vectors is very expensive in termsof hardware resources. Among the various side-channelanalysis based detection approaches, combinational pathdelay based detection [14] has several advantages. First,it does not require triggering the Trojan payload todetect the Trojan. In fact, it does not necessarily requireswitching activities in the Trojan circuitry, unlike currentbased Trojan detection approaches. Instead, extra delaydue to capacitive loading due to Trojan circuitry canmake a Trojan detected. Second, high-resolution pathdelay measurement can be accomplished through on-chip infrastructure at modest cost, which, can also be

Fig. 5. Functional core scan chain protection with SC EN.

used to perform delay fault testing. In this work, wechoose the clock sweeping technique proposed in [31]for Trojan detection through path delay measurementusing an efficient clock sweeping approach. IIPS providesa centralized infrastructure for characterization of pathdelays in individual IPs.

4.2 Design of Security Primitives4.2.1 Authentication-based Scan Chain ActivationThe state diagram of SE-FSM is illustrated in the circlein Fig. 4. IIPS generates an external scan chain enablesignal SC ENi (i ∈ [1, N ], where N is the number offunctional cores) for each functional core. The scan chainlocking is achieved by gating both the scan input andoutput when SC ENi is inactive. Fig. 5 demonstrates thescan-in and scan-out gating of a IEEE 1500 compliantcore. Gating both the input and output of a scan chaincan prevent illegal users from gaining controllability andobservability via the scan chain. [7] chose to gate only thescan output, which still leaves illegal users the opportu-nity of scanning in an arbitrary state to operate the chipfrom, and observe the functional primary outputs. Analternative way of controlling access to the scan chain isto gate the core internal scan enable SE. However, thismay compromise the timing of SE, which is usually oneof the critical paths of a SoC.

By default, SC ENi is set to logic 0, hence all scanchains are disabled and the cores can only work infunctional mode. Even if the scan chain is concatenatedwith the wrapper boundary register (WBR) during testing,only logic 0’s will be scanned in and shifted out from thescan chain. In order to perform scan-based testing or IIPSsecurity tasks, a test initiation phase is required to enablenecessary core scan chains prior to the testing procedure.This can only be done when M-FSM is in SC EN state.To enable scan chain access of each functional core, asequence of input vectors specific to the core has tobe provided at test interface WSP to bring SE-FSM tothe particular scan activation state, e.g. Core1 SC EN

6

(a)

(b)

Fig. 6. (a) Signature generation in ScanPUF realizedin the scan chains of IPs by the IIPS module; (b) clockgenerator and timing of relevant signals.

for enabling scan chain of Core1. During scan chainactivation, the predefined authentication input sequencesare distinct for different scan chains, hence can be con-sidered as the scan activation key to each core. After eachactivation, M-FSM will return to SC INIT waiting for thenext scan chain activation request. SC ENi of the enabledscan chain is latched and can only be disabled by activeIIPS RSTN.

4.2.2 ScanPUF PrimitiveFig. 6(a) illustrates the ScanPUF concept. The basic ideais to exploit random delay variations in scan paths, i.e.the paths between adjacent scan flip-flops (SFFs). Scanchain is essentially a shift register. When a vector is beingshifted in, to guarantee that each SFF can successfullylatch the value from the previous SFF, the new valuehas to be ready by a setup window (tsetup) ahead ofthe rising edge of the clock. This means the shift clockperiod should be no less than tclk2q + tpd + tsetup, wheretclk2q is the clock-to-Q delay of the SFF and tpd isthe combinational propagation delay from the previousSFF, which can include interconnect and buffer delay.Smaller clock period will lead to setup violation, causinguncertain value being latched to the SFF. Generally, scanpaths within a functional core can be partitioned intogroups, where paths in each group have closely matchingdelays. In each group, the path delays can be modeledas a single nominal delay (tpd0) plus a random intra-die variation (δi, i is the index of the scan path) withGaussian distribution. By using a shift clock with periodtclk2q + tpd0 + tsetup (denoted as nominal capture clockperiod t0), half the SFFs are expected to have a setupfailure; and the positions of the failing SFFs in the scanchain depends on the random intra-die delay variations.This creates the PUF signature, i.e. response to a specific

Fig. 7. Design of the programmable delay line [27].

capture clock period. In particular, ScanPUF signaturegeneration is performed as follows:

(1) Scan chain initialization: In test mode (scan-shiftingmode), scan-in a sequence of alternating 0’s and 1’sunder normal test clock.

(2) Signature generation: Launch a clock rising edge tsiglater than the last rising edge in scan chain initialization.Since every SFF is supposed to have a transition, thoseend up holding the old values indicate setup violationsdue to longer scan path delay.

(3) Signature propagation: Shift out the response bitsthrough scan-out port with normal test clock.

ScanPUF test procedure simply requires scan shift op-eration with a dedicated clock signal. Therefore, ShiftWRshould be asserted and applied to the functional coresthroughout the signature generation process to enablescan shift. To generate CLK with a proper signaturecapture cycle, test inputs need to acknowledge IIPSon the completion of scan initialization. Since SoC testinput CaptureWR (one of Wrapper Serial Control lines)is not used during SoC configuration or scan shift,it can be used as the acknowledge signal. The actualCaptureWR sent to the embedded cores are deassertedbecause capture operation is not needed during ScanPUF.Relevant signal timing in the signature capturing processis demonstrated in Fig. 6(b). The clock generation logicshown in Fig. 6(b) works in the following manner: Inthe beginning of ScanPUF process, RSTN is asserted toset SEL to 0. Normal test clock WRCK is used for scanshifting (CLK=WRCK), while ShiftWR is active during theentire ScanPUF process and applied to all the functionalcores. CaptureWR is asserted before the last shift in scaninitialization and holds for one cycle, indicating thecompletion of scan initialization. In this way, with theclock rising edge of the last shift, CaptureWR is latchedby a SFF, turning SEL to 1 so that CLK is switched toWRCK d, which is a phase-shifted version of WRCK. Theamount of the phase shift is tuned to be the capture

7

period tsig . Buffers are added before the clock port ofthe SFF to introduce a slight positive skew, to ensurethe capture clock pulse of reasonable width. An overlynarrow pulse may cause unsuccessful latching or sufferfrom distortion when passing through the clock tree.WRCK d is used thereafter until the PUF response iscompletely shifted out through WSO.

As described above, the capture clock is generated byswitching between two clocks with a phase difference.The phase shift is realized by adopting a programmabledelay line (PDL) proposed in [27], as shown in Fig. 7. Ithas a coarse delay control and a fine delay control block,differentiated by the delay of a unit buffer. The totaldelay can be configured by serially loading the controlflip-flops to set one bit in each block. The coarse and finecontrol together allow a fine-grained delay tuning withwide range at low hardware cost. The implementationdetails are provided in Section 6.1.

For the purpose of authentication, the signature gen-eration is done by the chip manufacturer during pro-duction test and by a system integrator before a chip isintegrated into a system. The latter generates signatureto verify the authenticity and integrity of a chip - i.e. tomake sure it is not a counterfeit one. The authenticationprocess is based on off-line testing. The signature doesnot need to be stored inside a chip for the purpose ofauthentication. The system designer needs to generateit, extract out through the scan out process and match itwith manufacture provided golden signature database.ScanPUF is not designed to target in-field authentica-tion. Therefore, similar to post-manufacturing testing, theScanPUF authentication by a system designer needs tobe done under specified range of test conditions.

4.2.3 Path Delay Based Hardware Trojan Detection

Fig. 8(a) illustrates the basic concept of clock sweepingtechnique. For a combinational path, it sensitizes it fromits source (i.e. a primary input or flip-flop) and capturesthe output at the destination (i.e. a primary output orflip-flop) with a clock of certain frequency. By sweepingthe clock frequency, path propagation delays in a circuitcan be categorized into different bins, where each binstand for a small range of period, determined by theclock sweeping resolution. Efficient test pattern gener-ation to sensitize maximum number of paths can beachieved leveraging the existing CAD algorithms andtools for transient and path delay fault generation [31].

We have implemented a clock generation logic that cangenerate appropriate clock and test control signals insidethe IIPS to support both Launch-On-Capture (LOC) andLaunch-On-Shift (LOS) test schemes. In clock sweepingbased Trojan detection, Trojan impacts are modeled aspath delay variations. The testing responses over the en-tire circuit are collected for statistical analysis to identifypossible Trojans. We make the capture clock frequencytunable to support a fine-grained frequency sweepingover a wide range, thus covering non-critical paths even

(a)

(b)

Fig. 8. (a) Concept of clock sweeping technique forhardware Trojan detection; (b) Trojan detection throughmonitoring of delay shift by observing the latched valueunder clock sweep in two possible schemes.

with short delays. Path delay characterization is a two-pattern test, which involves one vector to initialize theinputs and a second one to excite the transition on thetarget path. LOC and LOS refer to two ways of generat-ing the second test vector. LOC takes the functional resultof the first vector (V0) as the second one (V1), namely

V0 = {PI0, PPI0} (1)V1 = {PI0, fPPI(V0)} (2)

where PI represents the primary input, PPI standsfor the pseudo primary inputs, i.e. internal state ele-ments, and fPPI is the boolean dependency of PPIon {PI, PPI}. In this case, the circuit should operatein functional mode during both the V1 generating cycleand the capture cycle, hence the scan enable (Shift) canbe deasserted before the V1 generating cycle and re-asserted after the capture cycle, as shown in Fig. 8(b). Inthis way the scan enable timing just needs to meet thetest clock frequency, and does not depend on capturecycle. On the contrary, LOS scheme shifts the first testvector by one bit to create the second one, which posesa stringent requirement on the scan enable timing, asshown in Fig. 8(b). The turnaround time of the scanenable is limited by the capture clock period.

Fig. 9 demonstrates the clock generator circuitry aswell as the timing of relevant signals. The basic clockgeneration scheme is similar to that of ScanPUF. How-ever, in this case both ShiftWR and CaptureWR are used tocontrol IIPS, and the actual test control lines ShiftWR TDand CaptureWR TD that go to the cores are generated byIIPS. Particularly, ShiftWR is used to acknowledge thecompletion of test initialization by holding low for onecycle after the last shift for V0. CaptureWR is used to dif-ferentiate LOC (CaptureWR=1) from LOS (CaptureWR=0).

8

Fig. 9. Clock sweeping based hardware Trojan detection:(a) clock generator; (b) clock generation signal timing.

During the clock generation, rising of SEL indicatesoccurrence of the launching clock edge, and rising ofREC SE indicates the capture clock edge. While for bothLOC and LOS, the scan enable ShiftWR TD returns to1 with REC SE after the capture, ShiftWR TD in LOCis deasserted together with ShiftWR to allow the core toenter functional mode in order to generate the launchingvector, and ShiftWR TD in LOS maintains high until SELrises with the launching clock edge.

Trojan detection covering every region of a SoC is time-consuming and prone to false positive results. Hence,the side-channel analysis should ideally target security-critical regions of a SoC to make it more effective. For agiven SoC, designers can figure out critical IPs in a SoCor critical regions of an IP (e.g. memory managementunit, crypto cores, buses). Such an approach will notincrease the hardware overhead of IIPS. However, it cansignificantly reduce the Trojan detection time and cost.

5 TEST PROTOCOL UNDER IEEE STD. 15005.1 Wrapper Operation ModesIEEE Std. 1500 allows testing of a SoC in various config-urations via collaborative control of Wrapper InstructionRegister (WIR) and Wrapper Serial Control (WSC) lines.It can concatenate the core boundary registers and scanchains of embedded cores into a test path, thus enablingtest access to each core. Fig. 10(a) demonstrates theconcatenated WBRs of SoC cores. By loading the WIRwith different instructions, the test path can include orexclude the scan chain, and the decision can be corespecific. As shown in Fig. 10(a), Core 2 is incorporatedinto the test path with its internal scan chain, allowingtesting of the core in scan mode. IEEE Std. 1500 supportscore based testing, namely when a core is under test,irrelevant cores can be set into BYPASS mode with onlythe 1-bit WBY register included in the test path so as tosave test time. This can be done by configuration of WIRsof irrelevant cores with BYPASS instruction.

Different core operation modes include functionalmode, inward facing mode, outward facing mode, andbypass mode. Functional mode corresponds to the sce-nario where the SoC is performing its normal function,while the other three modes are for testing. In particular,

TABLE 1Control values for wrapper boundary cell

Input Cell Output Cell

Instruction Scan Enable Hold Enable Scan Enable Hold Enable

WS INTEST ShiftWR 1 ShiftWR ∼ CaptureWR

WS EXTEST ShiftWR ∼ CaptureWR ShiftWR 1

inward facing mode allows testing the internal logic ofa core; outward facing mode supports validating thefunctionality of interconnects among different cores; andbypass mode indicates use of WBY register to facilitatetesting of other cores. These operation modes are realizedby configurations of the Wrapper Boundary Cell (WBC), i.e.element in WBR.

Fig. 10(b) displays the structure of a minimal WBCand its configurations to realize different operations. Theoperation mode a WBC performs, controlled by values ofScan Enable and Hold Enable, depends both on the coreconfiguration (i.e. instruction in WIR) and the test controllines WSC. IEEE 1500 serial test interface contains a testdata input terminal WSI and output terminal WSO, atest clock WRCK, a test reset WRSTN, and test controllines WSC. Mandatory WSC signals include SelectWIRwhich, when active, connects WSI with WIR for testmode configuration; ShiftWR controls the shift operationof WBR and CaptureWR indicates capture operation ofthe wrapper cells. The actual dependency of Scan Enableand Hold Enable on WSC is mode dependent. Exampleimplementation of WBC control is shown in Table 1 forinward facing and outward facing modes [36].

5.2 SoC-Level IIPS Test Protocol5.2.1 Scan Chain AuthenticationThe control of IIPS M-FSM and SE-FSM is at SoC level.Therefore, for overall IIPS control and scan chain acti-vation, creation of test protocols/patterns is the systemintegrator’s responsibility. Test can be directly providedin terms of SoC primary inputs and delivered in the formof standard Core Test language (CTL) [24]. In particular,the enabling process of each security mode (i.e. SC EN,ScanPUF or TrojDet) can be modeled as a test macro.

5.2.2 ScanPUFOn the other hand, it is desirable to generate test setsfor ScanPUF and Trojan detection at core level by coredesigners, because ScanPUF test data lengths and Trojandetection test patterns are core dependent. The test setscan then be expanded to SoC level by the system integra-tor. For test sets in conventional testing, expansion fromcore to SoC level involves translating the core terminalsto the corresponding SoC pins, as well as searching forpaths to and from the CUT for test stimuli and responsepropagation when using the parallel test interface [28].Expansion of ScanPUF and Trojan detection test sets canreuse the same methodology, with the main distinction

9

(a) (b)

Fig. 10. (a) Wrapper boundary registers concatenated for SoC test or IIPS functions; (b) wrapper boundary cell and itsvarious configurations.

Fig. 11. Configuration of scan chains of different IPsduring signature generation for chip authentication usingscanPUF structures.

that an acknowledge signal should be raised for oneclock cycle at the completion of test initialization.

For both ScanPUF and Trojan detection, the entire testprocedure can be divided into four parts: (1) core testmode configuration; (2) test initialization; (3) signaturegeneration; and (4) signature propagation. In case ofScanPUF, although scan chains in SoC functional corescan be concatenated into a single scan chain to generateScanPUF signature, scan paths in different cores mayhave different mean delays and require different tsig .Hence, an efficient way for saving test time is to performScanPUF test on different cores individually by settingthe Core Under Test (CUT) to INTEST SCAN mode (i.e.connect both WBR and core internal scan chain intothe test path) while configuring other cores to BYPASSmode, as shown in Fig. 11. This procedure is referredto as core test mode configuration, which conformsto the procedure followed in normal SoC testing. Wenote that core-based signature generation can effectivelyobtain information from all scan chains but in a per-corefashion. Even for a short scan chain (e.g. 256 bit), wecan generate a signature of adequate length (e.g. 128 bit)for authentication. However, a longer scan chain givesus the opportunity to choose the scan paths in manypossible ways, thus providing more challenge-responsepairs, which can increase security for authentication or

can be used to generate keys for crypto operations.Within an IP, a long scan chain is usually broken into

a hierarchy of multiple shorter scan chains to improvethe test time. Such a scan architecture, however, wouldnot affect the uniqueness of the proposed scanPUF im-plementation. Actually, multiple scan chain would helpin accelerating the pre-load of scan FFs and scan out ofthe signature.

ScanPUF test initialization refers to initializing theentire scan chain with alternate 0’s and 1’s. Beside testdata input and output translation, the initialization datalength is expanded to account for the BYPASS registersof irrelevant cores on the test path. On completion oftest initialization, SoC input CaptureWR is asserted forone clock cycle to launch the signature generation andpropagation process. Thereafter, one maintains the testlines and pausing the clock until the signature is shiftedout. We note that the actual clock and WSC signalsapplied to the cores for test control will be automaticallygenerated by IIPS, the only responsibility at the SoCboundary is to raise the acknowledge signal when testinitialization ends.

5.2.3 Hardware Trojan DetectionFor Trojan detection, test set creation can be consideredin two scenarios. To detect Trojans mounted inside thefunctional cores, test sets should be developed by thecore designers and then expanded to SoC level. Trojanscould also be inserted to tamper the interconnectionamong cores, e.g. on system buses. To test against suchattacks, test sets should be created at SoC level.

Fig. 12 illustrates the core configurations in the twoscenarios. In the first case, to detect Trojans inside a core,the CUT is set to INTEST SCAN mode to allow inwardfacing test, while other cores are set to BYPASS mode.Here test initialization means scanning in test vectorsfor CUT primary and pseudo primary inputs (scan flip-flops) before launching the capture clock. Associatedwith this step is the translation of the test terminals

10

Fig. 12. Example SoC configuration when performingTrojan detection for: (a) Trojans inside a core; (b) Trojansin SoC system bus.

from core to SoC boundary, and expansion of the testdata to account for the BYPASS registers in other cores,which is trivial because test is executed through theserial interface. In the second case where integrity ofsystem interconnections is concerned, test patterns canbe directly created at SoC level and no test data ex-pansion is needed. Multiple test sets can be generated,with each focusing on Trojan detection of a particularregion of interconnects. When one region of interconnectis being tested, the corresponding driver and receivercores should be configured to EXTEST mode while othercores in the BYPASS mode. In this way, output wrapperregisters of the driver cores can provide test stimuli, andtest responses can be captured at receiver core inputwrapper registers.

The test scheme choices are also different for the twocases. When considering Trojans inside a core, both LOCand LOS can be used to capture test response. However,for Trojans on system buses, only LOS scheme can beapplied for minimally configured IEEE 1500 architecture.This is because minimally configured output wrappersdo not support capture operation in EXTEST mode, thuscannot generate the excitation pattern in functional modewith LOC. However, with higher 1500 configurationwhere output wrappers are implemented with enhancedscan cells, or extended 1500 infrastructure to supportoutput wrapper capture in EXTEST mode [26], LOCscheme can also be used for detecting Trojans on systeminterconnects. A simplified example of SoC level testprotocol for Trojan detection using LOC is representedin Algorithm 1. It is worth noting that WSC may havepatterns that are invalid for normal testing, as the actualtest control lines are generated by IIPS.

6 RESULTSTo verify the functionality and security effectiveness ofIIPS, we performed HSPICE simulation on a IIPS moduleusing 45 nm CMOS process model. We also implementedIIPS in a representative SoC on Altera DE0 FPGA plat-form. Functional simulations validated the IIPS statetransitions in response to SoC test inputs and the timingof the clock generator module. We also analyzed thehardware overhead in both ASIC and FPGA contexts.

Algorithm 1 SoC-level test protocol for Trojan detectionMacroDefs Core TrojDet macros{

//core test mode configurationcore config{// If core is CUT, configure to WS INTEST SCAN// Otherwise WS BYPASS (Omitted here)

Purpose Instruction;W core config timing;C {WRSTN=0; WSI=0; WSO=x; WSC=0000;}V {WRSTN=1; SelectWIR=1;} //to load WIRShift {V {WSI=010;} //instruction WS INTEST SCAN}V {WSC=0001;} //update WIR

}//Trojan DetectionTrojDet{//Test initialization

W TrojDet timing;C {WRSTN=1; WSC=0110; } //enable scan, LOCShift {

V {WSI=‘wsi’; WSO=#; } //apply test pattern}

//Signature generation acknowledgeV {ShiftWR=0; }

//Signature propagationF {ShiftWR=1; }Shift {

V {WSI=0; WSO=‘wso’;} //check response}

}}

Fig. 13. Inter-die HD distribution for scan-based PUF in500 chips under tsig = 0.19ns.

6.1 SoC Authentication and Trojan DetectionThe clock generator including the PDL block is imple-mented using 45 nm CMOS Predictive Technology Model(PTM) [29]. The PDL contains a 6-level coarse delaycontrol and a 11-level fine delay control block, with reso-

11

lution of 136ps and 12ps, respectively. The tunable clockhas period range of ∼ 300ps − 1.15ns, i.e. ∼ 870MHz −3.33GHz frequency. Monte Carlo HSPICE simulationswere performed to verify the effectiveness of IIPS in sup-porting ScanPUF and delay based Trojan detection. Toevaluate uniqueness of signatures generated by the PUF,we employed the inter-die Hamming distance (HD) as ameasure of the difference between two signatures. Fig. 13shows the inter-die HD histogram of signatures (128 bitseach) in 500 chips when the signature-generation periodis 0.19 ns. We can observe that most of HDs are around50%, which means that nearly 64 bits in a signatureare different from others. Hence, the ScanPUF in IIPScan provide excellent performance in SoC authenticationwith a highly unique signature in each SoC. [30] alsoshows that under temporal variations (temperature orsupply voltage fluctuation), signature of ScanPUF hasgood robustness with only a few flipped bits.

For Trojan detection, Monte Carlo HSPICE simulationswere performed on combinational paths starting fromand ending at flip-flops. A test path example is providedin Fig. 14. Since the biggest challenge in side-channelanalysis based Trojan detection is process variations thatcan significantly mask the Trojan effect, it is necessaryto validate IIPS Trojan detection capability under inter-die and intra-die process variations. The smallest Trojanthat can be reliably detected in terms of its impact onpath delay is used to indicate IIPS Trojan sensitivity.In particular, two combinational paths of delay 393psand 1013ps were chosen, representing short and longpaths in real circuits, respectively. Inter-die variations oftransistor threshold voltage Vth with standard deviationσth,inter = 5%, 10%, and 15% were considered, with intra-die variation of standard deviation σth,intra = 5%. Ateach process corner, a test is first performed on oneTrojan-free path to find out the capture frequency, whichis then used to differentiate Trojan-infected paths fromTrojan-free ones. We inserted multiple Trojans incurringdifferent delays at each process corner to determine theTrojan sensitivity. We consider reliable detection of Trojanas a miss rate of less than 5%, including false positiveand false negative. For each process corner and eachpath, 100 Trojan-free and 100 Trojan-infected copies ofthe path with Vth following Gaussian distribution weresimulated. Fig. 15 demonstrates IIPS Trojan sensitivity ateach process corner. It can be observed that the Trojandetection resolution decreases slightly with increasinginter-die process variations, and is lower for the longerpath. This is because the over all impact of variationon the long path is greater than that on the short path,mainly due to higher logic levels. With σ = 5% intra-dieand σ ≤ 15% inter-die process variations, Trojans causingdelay above 44ps can be reliably detected, equivalent tothe delay caused by an extra level of XOR gate.

It is worth noting that Trojan detection approachesgenerally rely on statistical methods, e.g. principal com-ponent analysis [14] or multidimensional scaling [31], toisolate the Trojan-infected ICs from process noise with

Fig. 14. Example combinational path used as a model ofTrojan attack.

Fig. 15. Minimum delay of Trojan detectable withclock sweeping technique implemented in IIPS for σ =5, 10, 15% intra-die process variation.

high confidence. In this paper, our focus is to show thatIIPS module can facilitate Trojan detection at IP and SoClevel using on-chip infrastructure. The proposed pathdelay analysis based Trojan detection can, however, becombined with statistical analysis to significantly im-prove Trojan detection sensitivity and reliability.

6.2 Hardware OverheadWe use two representative SoC benchmarks as the base-line design to characterize the silicon overhead intro-duced by IIPS. SoC benchmark 1 contains three IS-CAS89 sequential circuits, while SoC benchmark 2 triesto imitate realistic designs by incorporating a 32-bitDLX processor, an AES with 128-bit key, and a 128-bit pipelined FFT module. Both designs have full-scaninfrastructure. The numbers of scan chains are estimatedby assuming an average scan chain length of 250, whichis obtained from the first ten benchmark circuits in ITC02SoC benchmark [33]. We note that although the SE-FSMscales up with increasing number of scan chains, thenumber of state elements in SE-FSM increases with onlythe rate of log2(C · p), i.e. log2(p) + log2(C), where pis the rate of increasing number of scan chains and Cis the authentication key length. Table 2 demonstratesthat percentage area overhead induced by IIPS decreasesremarkably with the size of the benchmark circuits. Forreal designs, the overhead is less than 1%. In addition,since IIPS resides outside the functional modules and isused only when performing off-line testing or securitytasks, it does not incur functional performance degrada-tion or power overhead. The clock tree routing can alsobe preserved by keeping multiplexers between IIPS clockand functional clock inside IIPS.

12

TABLE 2Hardware overhead of IIPS w.r.t. two example SoCs

Benchmark SoC 1 Benchmark SoC 2Cores/SoC IP Cores SoC IIPS IP Cores SoC IIPS

s1423 s5378 s9234 DLX AES FFTArea (µm2) 1151 2659 3344 7154 546 (+7.6%) 30845 83049 500386 614280 4978 (+0.8%)

# of SFFs 74 179 211 464 - 521 2469 33203 36193 -# of scan chains 1 1 1 3 - 3 10 133 146 -

TABLE 4Hardware Trojan detection results on FPGA

Path index 1 2 3 4 5 6 7 8 AveragePath delay (ns) 3.7 4.5 5.8 6.1 7.2 8.1 10.3 13.1 -

Trojan induced delay overhead (ns) 0.37 0.26 0.46 0.30 0.26 0.33 0.59 0.19 0.35Miss rate 0 9.4% 3.1% 9.4% 3.1% 12.5% 0 12.5% 6.3%

6.3 Experimental Validation

Hardware validation of IIPS was performed on a FPGAplatform where Altera DE0 FPGA development boardswere used to emulate the ASIC scenario. IIPS was im-plemented on 65 nm Cyclone III FPGA devices usedin the DE0 boards. Due to lack of precise control overthe placement and routing of the mapped design, thePDL cannot be implemented as in ASIC to produceprecisely tunable delays. We employ the on-chip PhaseLocked Loop (PLL) module in the FPGA to generate thephase shifted clock. The on-chip PLL can provide phaseshift at resolution of 97ps in our experiments, which isequivalent to the clock frequency sweeping resolution.We have implemented a minimally configured IEEE 1500infrastructure in SoC benchmark 1, and validated thefunctionality of IIPS by interfacing it with the bench-mark circuit. The hardware overhead incurred by IIPSis provided in Table 3. Part of the additional resourceutilization is contributed by the control logic for PLL,which should not be required in ASIC scenarios. Totest the effectiveness of the clock generation logic, weperformed Trojan detection with IIPS implemented inSoC benchmark 1. In particular, Trojans were insertedon 8 different paths of s9234 core. A Trojan was realizedas a single inverter inserted at different locations of thepaths to model minimal delay impact of an extra logiclevel. The underlying assumption is that the payload ofa typical digital Trojan will introduce at least one extralogic gate on certain path of the circuit. We preservedthe post-fitting netlist of the Trojan-free design by usingincremental compilation to insert the Trojan to assurethe extra delay is caused by Trojan logic rather thanchanges in global layout topology. Target circuit paths

TABLE 3IIPS overhead in FPGA platform

SoC 1 SoC 1 w/ IIPS Overhead# of LUTs 1194 1238 +3.7%

# of Registers 533 577 +8.3%

were chosen to have nominal delay ranging from 3.7ns to 12.5 ns. 16 FPGA boards were used, with Trojan-free and Trojan-infected design mapped once on eachboard for 32 copies of the design. The percentage ofincorrect detection (miss rate) for each path is providedin Table 4. It can be observed that the minimal single-inverter Trojan with average delay of 0.35ns can bereliably detected with miss rate of 6.3%. The miss rate isexpected to increase monotonically with increasing pathlength. Note that, the measured miss rate varies due tominor differences in Trojan placement and routing thatare out of our control. The actual Trojan coverage canbe much higher using statistical analysis, as explainedin Section 6.1.

7 DISCUSSION

7.1 FlexibilityThe IIPS test protocol described in this paper is based ona minimal implementation of IEEE 1500 test infrastruc-ture. However, IIPS functions are flexible in interfacingwith enhanced configurations of IEEE 1500 architecture.In fact, IIPS test efficiency can be improved with ad-vanced features of IEEE 1500. Both ScanPUF and Trojandetection test protocols can be adapted to use the parallelinterface for test vector propagation to save test time,when a parallel TAM architecture is available. For theminimally configured IEEE 1500 infrastructure, Trojandetection on system buses can only be performed withLOS scheme, because core output wrapper cells do notsupport a capture operation in EXTEST mode. However,if the wrapper is implemented using WBCs with en-hanced scan functions, or the infrastructure is extendedto support delay-fault test [26], a broadside capture canbe realized at the system bus inputs for LOC test scheme.It would improve both hardware Trojan as well as delay-fault coverage.

Furthermore, in the case where a SoC is equippedwith a different test wrapper interface than IEEE 1500,the integration and/or design of IIPS can be adjustedaccordingly. Since most test wrappers would provide

13

access to the scan and internal test infrastructure of an IP,as required by IIPS, it can be easily extended to anothertest wrapper interface.

7.2 ScalabilityIIPS exhibits good scalability when applied to largecomplex SoCs. Since the ScanPUF based authenticationand Trojan detection procedures are core-based, the testtime either does not increase (for authentication), orincrease linearly with the SoC size (for Trojan detection).Protection against scan based attack is based on system-level authentication and scan chain activation logic isindependent of the SoC size. The hardware overhead isminimal since IIPS utilizes the existing IEEE 1500 DFTinfrastructure. This justifies our observation in Table 2that the percentage overhead is very small for largerSoCs.

IIPS also exhibits good functional scalability in termsof integrating more security functions or test infrastruc-tures at minimal extra overhead. It can be adapted toprovide protection against other attack models, e.g. side-channel attack on crypto cores. For example, IIPS can beequipped with a noise injector [32] to mask key-relatedinformation leak through transient current. Moreover,IIPS can incorporate multiple countermeasures for cer-tain attacks to enhance the overall security of a SoC.For instance, a current monitor can be integrated todetect behavior of hardware Trojans at run-time [34]. IIPScan also include an assertion-based security checker todetect malicious inclusions in on-chip processors [35].Moreover, it can potentially be integrated with otherinfrastructure IPs - e.g. test infrastructure IPs whichprovide built-in self-test (BIST) capability to SoCs [19].Integrating security functions and test support logic inIIPS can significantly minimize the design and hardwareoverhead due to resource sharing and a centralizedcontrol logic. IIPS can support a library of securityfunctions that provides a system integrator design-timeconfigurability to selectively enable/disable a functionbased on design requirements.

7.3 Integrity of IIPSSecurity of the IIPS itself against tampering or unau-thorized access is important to ensure its effectiveness.While the IPs that go into a SoC design can be acquiredfrom 3rd party untrusted vendors, the IIPS module itselfcan be designed by the SoC manufacturer in a trustedenvironment. However, malicious modification of IIPScan possibly be made in an untrusted foundry. TheIIPS design would primarily include FSMs, which wouldbe extremely difficult to reverse engineer from theirlayout. Extraction of state machine of reasonable sizefrom a synthesized FSM is known to be an intractableproblem. Hence, incorporating hard-to-detect maliciousmodification in these FSMs can be practically infeasible.

Furthermore, possible Trojan attacks in the sequentiallogic in IIPS (both in foundry and design house) can be

reliably detected through efficient side-channel analysis,such as temporal self-referencing, which aim at detectingany modification to a well-defined state transition func-tion [37]. Finally, to enhance the security of IIPS againstdeliberate malicious modification, one can employ low-cost hardware obfuscation approaches [12], that makesreverse engineering and Trojan attacks significantly moredifficult to mount.

8 CONCLUSIONWe have presented a novel paradigm of secure SoCdesign using an infrastructure IP, referred to as IIPS.IIPS is a centralized low-overhead on-chip module thatinterfaces with other IPs in SoC and provides counter-measures against various security threats. It features easeof integration, compliance to standard SoC test protocol,functional flexibility and scalability. We have shown theeffectiveness of an IIPS module that incorporates a low-overhead authentication mechanism for preventing scan-based attacks; a PUF to protect against piracy and coun-terfeit chips; and a test infrastructure for trust validationagainst hardware Trojan attacks. We have validated thefunctionality and security of IIPS through circuit-levelsimulations as well as experimental measurements on anFPGA platform. Both ASIC and FPGA implementationsof IIPS show that it incurs ultra-low hardware overhead.IIPS can flexibly interface with SoCs equipped withvarious configurations of IEEE 1500 infrastructure, andcan benefit from higher configurations in test efficiency.IIPS can be effectively integrated with test infrastructuresto minimize the design cost and overhead. It can beextended to implement protection against other attackse.g. side-channel attacks at the SoC level. Future workwill include effective integration of IIPS with other in-frastructure IPs for test and debug as well as expansionof its capability to protect against other attacks.

REFERENCES[1] S. Mangard, E. Oswald and T. Popp, “Power Analysis Attacks-

Revealing the Secrets of Smart Cards,” Springer 2007.[2] K. Tiri and I. Verbauwhede, “A Logic Level Design Methodology

for a Secure DPA Resistant ASIC or FPGA Implementation,”Design, Automation and Test in Europe, 2004.

[3] Y. Lu, M.P. O’Neill and J.V. McCanny, “FPGA Implementationand Analysis of Random Delay Insertion Countermeasure againstDPA,” Intl. Conference on ICECE Tech., 2008.

[4] G.E. Suh and S. Devadas, “Physical Unclonable Functionsfor Device Authentication and Secret Key Generation,” DesignAutomation Conference, 2007.

[5] J. Lee, M. Tehranipoor, C. Patel and J. Plusquellic, “Securing ScanDesign Using Lock & Key Technique,” IEEE Intl. Symp. on Defectand Fault Tolerance in VLSI Systems, 2005.

[6] B. Yang, K. Wu and R. Karri, “Secure Scan: A Design-for-TestArchitecture for Crypto Chips,” Design Automation Conference,2005.

[7] S. Paul, R.S. Chakraborty and S. Bhunia, “VIm-Scan: A LowOverhead Scan Design Approach for Protection of Secret Key inScan-Based Secure Chips,” IEEE VLSI Test Symp., 2007.

14

[8] F. Koushanfar, “Integrated Circuits Metering for Piracy Protectionand Digital Rights Management: an Overview,” ACM GLS-VLSI,2011.

[9] V.V.D. Leest and P. Tuyls, “Anti-counterfeiting with hardwareintrinsic security,” Design, Automation and Test in Europe, 2013.

[10] B. Gassend, D. Clarke, M.V. Dijk and S. Devadas, “Delay-BasedCircuit Authentication and Applications,” ACM Symposium onApplied Computing, 2003.

[11] D. Hely, M. Flottes, F. Bancel, B. Rouzeyre, N. Berard and M.Renovell, “Scan Design and Secure Chip,” IEEE Intl. On-LineTesting Symp., 2004.

[12] R.S. Chakraborty and S. Bhunia, “Security Against HardwareTrojan Attacks Using Key-based Design Obfuscation,” Journal ofElectronic Testing: Theory and Applications, vol. 27. no. 6, pp. 767-785,Dec 2011.

[13] X. Zhang and M. Tehranipoor, “RON: An on-chip ring oscillatornetwork for hardware Trojan detection,” Design, Automation andTest in Europe, 2011.

[14] Y. Jin and Y. Makris, “Hardware Trojan detection using pathdelay fingerprint,” IEEE Symp. on Hardware Oriented Trust andSecurity, 2008.

[15] H. Salmani, M. Tehranipoor and J. Plusquellic, “A Novel Tech-nique for Improving Hardware Trojan Detection and ReducingTrojan Activation Time,” IEEE Transactions on Very Large ScaleIntegration Systems, Vol. 20, No. 1, Jan 2012.

[16] Synopsys Verification IP: http://www.synopsys.com/Tools/Veri-fication/FunctionalVerification/VerificationIP/Pages/default.aspx

[17] Intellitech Test-IP Product Family:http://www.intellitech.com/products/boundary scan test.asp

[18] Y. Zorian, “Guest Editor’s Introduction: What is InfrastructureIP?” IEEE Design & Test of Computers, 2002.

[19] P. Bernardi, M. Rebaudengo and M.S. Reorda, “Exploiting an I-IPfor in-field SoC test,” IEEE Intl. Symp. on Defect and Fault Tolerancein VLSI Systems, 2004.

[20] S. Tabatabaei and A. Ivanov, “Embedded Timing Analysis: ASoC Infrastructure,” IEEE Design & Test of Computers, 2002.

[21] E. Dupont, M. Nicolaidis and P. Rohr, “Embedded RobustnessIPs for Transient-Error-Free ICs,” IEEE Design & Test of Computers,2002.

[22] J. Bordelon, B. Tranchina, V. Madangarli and M. Craig, “AStrategy for Mixed-Signal Yield Improvement,” IEEE Design &Test of Computers, 2002.

[23] F. DaSilva et al., “Overview of the IEEE P1500 Standard,” Intl.Test Conference, 2003.

[24] IEEE 1450.6 Core Test Language (CTL):http://grouper.ieee.org/groups/ctl/

[25] IEEE 1500 Embedded Core Test:http://grouper.ieee.org/groups/1500/

[26] Q. Xu and N. Nicolici, “Delay Fault Testing of Core-BasedSystems-on-a-Chip” Design, Automation and Test in Europe, 2003.

[27] R. Tayade and J.A. Abraham, “On-chip Programmable Capturefor Accurate Path Delay Test and Characterization,” Intl. TestConference, 2008.

[28] E.J. Marinissen, “The Role of Test Protocols in Automated TestGeneration for Embedded-Core-Based System ICs,” Journal ofElectronic Testing: Theory and Applications, Vol. 18 Issue 4-5, Aug.-Oct., 2002.

[29] Available Online: http://ptm.asu.edu/.[30] Y. Zheng, A.R. Krishna and S. Bhunia, “ScanPUF: Robust

Ultralow Overhead PUF Using Scan Chain,” Asia and South PacificDesign Automation Conference, 2013.

[31] K. Xiao, X. Zhang and M. Tehranipoor, “A Clock SweepingTechnique for Detecting Hardware Trojans Impacting CircuitsDelay,” IEEE Design & Test of Computers, Issue 99, 2013.

[32] X. Wang, W. Yueh, D.B. Roy, S. Narasimhan, Y. Zheng, S.Mukhopadhyay, D. Mukhopadhyay and S. Bhunia, “Role ofPower Grid in Side Channel Attack and Power-Grid-Aware SecureDesign,” Design Automation Conference, 2013.

[33] ITC’02 SoC Test Benchmarks:http://itc02socbenchm.pratt.duke.edu/

[34] S. Narasimhan, W. Yueh, X. Wang, S. Mukhopadhyay and S.Bhunia, “Improving IC Security against Trojan Attacks throughIntegration of Security Monitors,” IEEE Design & Test of ComputersSpecial Issue on Smart Silicon, 2012.

[35] M. Bilzor, T. Huffmire, C. Irvine and T. Levin, “Security Checkers:Detecting processor malicious inclusions at runtime,” IEEE Symp.on Hardware Oriented Trust and Security, 2011.

[36] S. Francisco et al., “The Core Test Wrapper Handbook,” Springer2006.

[37] S. Narasimhan, X. Wang, D. Du, R.S. Chakraborty and S.Bhunia, “TeSR: A Robust Temporal Self-Referencing Approachfor Hardware Trojan Detection,” IEEE Symp. on Hardware OrientedTrust and Security, 2011.

9 AUTHOR’S BIOXinmu Wang received her PhD degree in computer engi-neering at Case Western Reserve University, Cleveland,OH in 2014. Currently she is a product security engineerat Qualcomm Inc., San Diego, CA. She has researchinterests in hardware security, including hardware Trojandesign and detection, design for cryptographic systemside-channel attack resistance, and secure SoC design.

Yu Zheng received the B.S. degree in communicationengineering and M.S. degree in communication and in-formation system from University of Electronic Scienceand Technology of China (UESTC) in 2007 and 2010,respectively. He is currently pursuing the Ph.D. degreein computer engineering at Case Western Reserve Uni-versity, Cleveland, OH. He held an internship in LSICorporation during the summer of 2013. His currentresearch interests include hardware security and VLSIarchitecture for communications and signal processing.

Abhishek Basak received his B.E. (Hons.) from Ja-davpur University, Kolkata, India in 2010 and is currentlypursuing his Ph.D. degree in Computer Engineering atCase Western Reserve University, Cleveland, OH. He hasmany publications in premier conferences in the areasof biomedical system design for point-of-care healthmonitoring and hardware security, trust and validation.He is a student member of IEEE and EMBS.

Swarup Bhunia received his Ph.D. from Purdue Uni-versity, USA in 2005. Currently, he is an T. and A.Schroeder associate professor of Electrical Engineeringand Computer Science at Case Western Reserve Univer-sity, USA. He has published over 150 articles in peer-reviewed journals and premier conferences. His researchinterests include low power and robust design, hardwaresecurity, and implantable electronics. Dr. Bhunia receivedNational Science Foundation (NSF) career developmentaward (2011), Semiconductor Research Corporation tech-nical excellence award (2005), several best paper awardsand SRC Inventor Recognition Award (2009). He is asenior member of IEEE.