1 186 186 186 IEEEIEEE TRANSACTIONS TRANSACTIONS ON MULTI-SCALE ON MULTI-SCALEIEEE COMPUTING TRANSACTIONS COMPUTING SYSTEMS, SYSTEMS, ON MULTI-SCALE VOL. VOL. 2, NO. 2, COMPUTING 3,NO. JULY-SEPTEMBER 3, JULY-SEPTEMBER SYSTEMS, 2016 VOL. 2016 2, NO. 3, JULY-SEPTEMBER 2016 DesignDesign andDesign and ValidationDesign Validation and and Validation for for Validation FPGA FPGA for Trust Trust for FPGA FPGA Trust Trust under underunder Hardware HardwareunderHardware Trojan Trojan Hardware Attacks Attacks Trojan Trojan Attacks Attacks Sanchita Mal-Sarkar, Member, IEEE, Robert Karam, Student Member, IEEE, SanchitaSanchita Mal-Sarkar, Mal-Sarkar,Member,Member,SeetharamSanchita IEEE IEEE Mal-Sarkar,, Robert Narasimhan,, Robert Karam, Karam,Member,Member,StudentStudent IEEE IEEEMember,, RobertMember,, Anandaroop IEEE Karam, IEEE, ,Student Ghosh, Member, Aswin Krishna, IEEE, SeetharamSeetharam Narasimhan, Narasimhan,Member,SeetharamMember, IEEEand IEEE Narasimhan,, Swarup Anandaroop, Anandaroop Bhunia,Member, Ghosh, Ghosh,Senior IEEE Member,, Anandaroop IEEE Ghosh, AswinAswin Krishna, Krishna,StudentStudent Member,Aswin Member, Krishna, IEEE IEEE, and,Student and Swarup Swarup Member, Bhunia, Bhunia, IEEESeniorSenior, and Member, Member,Swarup IEEE Bhunia, IEEE Senior Member, IEEE Abstract—Field programmable gate arrays (FPGAs) are being increasingly used in a wide range of critical applications, including industrial, automotive, medical, and military systems. Since FPGA vendors are typically fabless, it is more economical to outsource Abstract—Abstract—FieldField programmable programmable gate gateAbstract— arrays arrays (FPGAs) (FPGAs)Field areprogrammable beingare being increasingly increasingly gate arrays used used (FPGAs) in a inwide a wide are range being range of critical increasingly of critical applications, applications, used in including a wide including range of critical applications, including device production to off-shore facilities. This introduces many opportunities for the insertion of malicious alterations of FPGA Devices in industrial,industrial, automotive, automotive, medical, medical, and and militaryindustrial, military systems. automotive, systems. Since Since medical, FPGA FPGA vendors and vendors military are typically are systems. typically fabless, Since fabless, it FPGA is moreit is vendors more economical economical are typically to outsource to outsource fabless, it is more economical to outsource the foundry, referred to as hardware Trojan attacks, that can cause logical and physical malfunctions during field operation. The devicedevice production production to off-shore to off-shore facilities. facilities.device This Thisproduction introduces introduces to many off-shore many opportunities opportunities facilities. for This the for introduces insertionthe insertion of many malicious of malicious opportunities alterations alterations for ofthe FPGA insertionof FPGA devices ofdevices malicious alterations of FPGA devices vulnerability of these devices to hardware attacks raises serious security concerns regarding hardware and design assurance. In this in thein foundry, the foundry, referred referred to as to hardware as hardwarein Trojan the Trojan foundry, attacks, attacks, referred that that can to can ascause hardware cause logical logical Trojan and and physical attacks, physical malfunctions that malfunctions can cause during logical during field and field operation. physical operation. The malfunctions The during field operation. The paper, we present a taxonomy of FPGA-specific hardware Trojan attacks based on activation and payload characteristics along with vulnerabilityvulnerability of these of these devices devices to hardware to hardwarevulnerability attacks attacks of raises these raises serious devices serious security to security hardware concerns concerns attacks regarding regardingraises hardware serious hardware security and and design concerns design assurance. assurance. regarding In this hardware In this and design assurance. In this paper,paper, we present we present a taxonomy a taxonomy of FPGA-specific ofTrojanpaper, FPGA-specific models we present hardware that hardware acan taxonomy Trojan be Trojan inserted attacks of attacks FPGA-specific by based an based attacker. on activation on hardware activation We also and Trojan present and payload payload attacks an characteristics efficient basedcharacteristics Trojanon activation along detection along with and with method payload for characteristics FPGA based along on a with TrojanTrojan models models that that can canbe inserted be inserted bycombinedTrojan an by attacker. an models attacker. approach We that alsoWe can of also present logic-testing be present inserted an efficient an by and efficient an side-channel attacker. Trojan Trojan detection We detection analysis.also method present method Finally, for an FPGA efficient for we FPGA propose based Trojan based on a detection novel a on combined a design combined method approach, for FPGA referred based to on as a Adapted combined approachapproach of logic-testing of logic-testing and and side-channel side-channelTripleapproach Modular analysis. ofanalysis. logic-testing Redundancy Finally, Finally, we and propose we (ATMR), side-channel propose a to novel areliably novel analysis.design designprotect approach, Finally, approach, against we referred Trojan propose referred to circuits asa to novel Adapted as of Adapted design varying Triple approach, Triple forms in FPGA referred devices. to as Adapted We compare Triple ATMR ModularModular Redundancy Redundancy (ATMR), (ATMR), to reliably towithModular reliably the protect conventional protectRedundancy against against Trojan TMR (ATMR), Trojan approach.circuits circuits to reliably of varying The of varying protect results forms againstforms demonstrate in FPGA in Trojan FPGA devices. the circuits devices. advantages We of compareWe varying compare of formsATMR ATMR ATMR in over with FPGA with TMRthe devices. the with respect We compare to power ATMR overhead, with the conventionalconventional TMR TMR approach. approach. The The resultswhileconventional results demonstrate maintaining demonstrate TMR the the approach.same advantages the advantages or The higher ofresults ATMR level of ATMR demonstrate of over security over TMR TMR withand the with respectperformancesadvantages respect to power to of poweras ATMR overhead, TMR. overhead, over Further TMR while while withimprovement respect to in power overhead overhead, associated while with maintainingmaintaining the samethe same or higher or higher level levelATMR ofmaintaining security of is security achieved and the and performances same by performances exploiting or higher as reconfigurationlevel TMR. as TMR.of Further security Further improvement and and improvement time-sharingperformances in overhead in of as overhead resources. TMR. associated Further associated improvement with with ATMR ATMR is in overheadis associated with ATMR is achievedachieved by exploiting by exploiting reconfiguration reconfigurationachieved and and time-sharing bytime-sharing exploiting of resources. reconfiguration of resources. and time-sharing of resources.! Ç Ç Ç

1I1INTRODUCTIONNTRODUCTION 1INTRODUCTION and secure processing due to the efficient implementation IELDIELDprogrammableprogrammable gate gate arraysField arraysIELD programmable(FPGA)programmable (FPGA) are are integrated integratedgate gate arrays arraysPrevious (FPGA) (FPGA)Previous research are are research integrated on on programmable programmableofPrevious cryptographic logic research logic devices algorithms. devices on programmablehas has The growing logic use devicesof FPGAs has in FFcircuitscircuits (IC), (IC), consisting consisting ofFcircuits, an of ancircuitsarray array consisting of (IC), logic of logic consisting blocks of blocks an and array of and anprimarily arrayofprimarily logic of focused logic blocks focused blocks on and tappingon and dis- tapping theirprimarilydiverse their potential potential and focused critical for forimplement- on implement- applicationstapping their has potential motivated for implement- designers distributeddistributed interconnect interconnect structure, structure,distributedtributed which interconnect which interconnect can can be structure, be pro- structure, pro-ing whiching signal which can signal processingbe can programmedprocessing be algorithms,pro- algorithms,ingto consider signal building building processing the reconfigurable security reconfigurable algorithms, of these devices. building In reconfigurable this context, grammedgrammed and andreprogrammedreprogrammedgrammedand re severalprogrammed several and timesre timesprogrammed several post- post- timessystems,systems, severalpost-manufacturing and and times for for applications applications post- to systems,security in ain wide a refers and wide range forto range protecting applications of usageof usage against in a Intellectual wide range Property of usage (IP) manufacturingmanufacturing to implement to implement logicmanufacturingimplement logic functions. functions. logic to Early functions. implement Early FPGAs FPGAs Early logicdomains, FPGAsdomains, functions. including were including Early used satellite,FPGAs only satellite, automotive,domains,Piracy, automotive, due including andto the and military substantial military satellite, sys- sys- automotive, financial investment and military involved sys- werewere used used only only as as prototypes prototypeswereas prototypes for used for implementing implementing only for implementing as prototypes ASIC ASICtems. ASIC fortems. More designs implementing More recently, on recently, hardware FPGAs ASIC FPGAs havetems.in have developing been More been used recently, used for the for encryption IP. FPGAs encryption Little have attention been used has for been encryption directed designsdesigns on onhardware hardware for for functional functionaldesignsfor functional verification. on verification. hardware verification. In the Infor the past functional In past theand pastand verification. secure decade, secure processing processing advances In the pastdue in due toandtowards the to the efficientsecure efficient security processing implementation implementation and assurance due to the of theefficient physical implementation system itself. decade,decade, advances advances in fabrication in fabricationdecade,fabrication processes processes advances haveprocesses have reduced in reducedfabrication have the reduced the processesof cryptographicof thecryptographic haveperformance reduced algorithms. algorithms. gap the TheofMalicious Thecryptographic growing growing alterations use use of algorithms. FPGAs of to FPGAs the in Thedesign in growing are possible use of FPGAs at several in performanceperformance gap gap between between FPGAsperformancebetween FPGAs and and FPGAs ASICs, gap ASICs, and between leading leading ASICs, to FPGAs leadingtodiversediverse and to and ASICs, FPGAs and critical critical leading being applications applications the to diversestages has has motivated of and designmotivated critical flow designers applications designers in FPGAs, to to hasas shown motivated in Fig. designers 1. Security to FPGAsFPGAs being being the the main main solution solutionFPGAsmain in solution beingina variety a variety inthe a of main variety ofperfor- perfor-solution of performance-criticalconsider inconsider a varietythe the security security of applica- perfor- of these of these devices.considerin devices. every In the stage this In security this context, of context, the of designsecu-these secu- devices. flow is In of this growing context, impor- secu- mance-criticalmance-critical applications. applications. Additionally,mance-criticaltions. Additionally, Additionally, designs applications. designs designs imple- imple- implemented Additionally,rityrity refers refers on to designs FPGAs protecting to protecting imple-do not against againstritytance; Intellectual refers inIntellectual response, to protecting Property Property the Defense against(IP) (IP) Advanced Intellectual Research Property Projects (IP) mentedmented on on FPGAs FPGAs do do not notmentedsuffer suffer suffer the the on increasing the increasing FPGAs increasing non-recurring do non- not non- sufferPiracy,Piracy, engineering the due due increasing to the to (NRE) the substantial substantial costsnon- financialPiracy,Agency financial due (DARPA)investment toinvestment the substantial [1] involved has involved initiated financial the investmentTRUST in Integrated involved recurringrecurring engineering engineering (NRE) (NRE)recurringof costs ASIC costs of production. engineering of ASIC ASIC production.FPGAs production. (NRE) are costsin typically developingin of developing ASIC designed the production. theas IP. an IP. Little in- LittleinCircuits attention developing attention program has has been the forbeen IP. directed hardware Little directed attention validation, has including been directed FPGA FPGAsFPGAs are are typically typically designed designedFPGAsterleaved as anas are an interleaved array interleaved typically of configurable array designed array of of logictowardsastowards an blocks, interleaved security security programmable and array and assurance assurance of towardsdevice of the of thesecurity physical security physical and system and system protection assurance itself. itself. of of third-party the physical IP. system itself. configurableconfigurable logic logic blocks, blocks, programmable programmableconfigurableinterconnects, interconnects, logic interconnects, and blocks, distributed and programmable and embeddedMaliciousMalicious interconnects, alterations memory alterations blocks. to and the to the designMalicious designTo are the are possible alterationsbest possible of our at toseveral atknowledge, the several design FPGA are possible system atprotection several distributeddistributed embedded embedded memory memorydistributedHigh resourceblocks blocks embedded (EMBs). availability (EMBs). High memory and High thestages flexibilitystages blocks of design of (EMBs).ofdesign the flow intercon- flow in High FPGAs, in FPGAs,stageshas as been shown as of shown design investigated in Fig. in flow Fig. 1. Security in 1. by FPGAs, Security relatively as shown few researchers in Fig. 1. Security [2], [3], resourceresource availability availability and and the the flexibilityresourcenect flexibility network availability of the of enables the interconnect interconnect and designs the flexibility toin perform everyin every of stage multiple the stage of interconnect the of parallel the design design flowin[4]. flow every is Hadzic of is growing stageof growinget. of al. theimportance;describe importance; design the flow various is of growing logical and importance; electrical networknetwork enables enables designs designs to perform tonetworkoperations perform multiple enables multiple each parallel designscycle parallel for oper- to increasedoper- performinin response, multiple computational response, parallel the the Defense power oper- Defense Advancedinattacks Advanced response, possible Research Research the tocause Defense Projects Projects malfunction Advanced and Research physical Projectsdestruc- ationsations each each cycle cycle for for increased increasedationscompared computational computational each to cycle sequential power for power increased processors. com- com-Agency computationalAgency (DARPA) (DARPA) power [1] [1]has com- has initiated initiatedAgencytion theof an the (DARPA)TRUST FPGA TRUST in device. [1] Integrated in has Integrated These initiated attacks the are TRUST caused in byIntegrated creating paredpared to sequential to sequential processors. processors.paredPrevious to sequential research processors. on programmableCircuitsCircuits program logic program devices for for hardware has hardwareCircuitsinternal validation, validation, program conflicts including including forin the hardware FPGA device FPGA validation,by inserting including malicious FPGA code primarily focused on tapping theirdevice potentialdevice security security for and implement- and protection protectiondevice ofin third-party theof third-party security configuration IP. and IP. protection files of designsof third-party [3]. Drimer IP. presents ing signal processing algorithms,To buildingTo the the best reconfigurablebest of our of our knowledge, knowledge,attackTo FPGA the models FPGA best system systemsuch of our protection as knowledge,replayprotection attacks, FPGA cloning, system authentication protection S. Mal-SarkarS. Mal-Sarkar is with is with the theDepartment DepartmentS. ofMal-Sarkar Electrical of Electrical is Engineering with Engineering the Department and and of Electrical Engineering and attacks, power analysis attacks, invasive and semi-invasive   systems, and for applicationshas inhas a been wide been investigated range investigated of usage by byrelatively relativelyhas been few few investigated researchers researchers by[2],[4], [2],[4],relatively few researchers [2],[4], ComputerComputer Science, Science, Cleveland Cleveland State State University, University,Computer Cleveland, Science, Cleveland, OH Cleveland OH44114. 44114. State University,[3].[3]. Hadzic Cleveland, Hadzic et OH al. et 44114. al. describe describe various[3].attacks, various Hadzic logical and logical et radiation and al. and describe electricalattacks electrical various as related logical to the and security electrical of E-mail:E-mail: [email protected]. [email protected],E-mail: [email protected]. including satellite, automotive, and military sys- R. KaramR. Karam and and S. Bhunia S. Bhunia are arewithtems. with theR. theKaramDepartment More Department and recently, S.of BhuniaElectrical of FPGAs Electrical are and with have andattacks the beenattacks Department used possible possible for of Electrical encryption to causeto cause and malfunctionattacksFPGA malfunction design possible and and [4]. physical to None physical cause of des- malfunctionthese des- works, andhowever, physical discusses des-  Computer Computer Engineering, Engineering, University University of Florida,Computer of Florida, Gainesville, Engineering, Gainesville, FL 32611. FL University 32611. of Florida,tructiontruction Gainesville, of an of an FPGAFL 32611. FPGA device. device.truction Thesehardware These attacks of attacks attacks an are FPGA are in caused the caused device. foundry by by These as aattacks means are to causedcause mal- by E-mail:E-mail: robkaram@ufl.edu, robkaram@ufl.edu, [email protected]fl.edu. [email protected]fl.edu.SanchitaE-mail: Mal-Sarkar robkaram@ufl.edu, is with [email protected]fl.edu. the Departmentcreatingcreating of Electrical internal internal Eng conflicts and conflicts Com- in the increatingfunction the device device internal and by leak byinserting insertingconflicts IP. mali- in mali- the device by inserting mali- puter Sc., Cleveland State University, Cleveland, OH-44114, USA. E-mail: S. Narasimhan,S. Narasimhan, A. Ghosh, A. Ghosh, and and A. Krishna A.S. Krishna Narasimhan, are withare with the A. Departmentthe Ghosh, Department and of A. Krishna of are with the Department of Trimberger discusses the issue of foundry trust as related  Electrical Electrical Engineering Engineering and andComputer Computer[email protected]. Science,Electrical Science, Case Engineering Case Western Western Reserve Seetharamand Reserve Computer Uni- Uni- Narasimhan Science,ciouscious code Case is codewith Western in Intel the in Reservethe Corporation,configuration configuration Uni- cious files files code of designs of in designs the [3].configuration [3]. Drimer Drimer files of designs [3]. Drimer versity,versity, Cleveland, Cleveland, OH OH44106. 44106. E-mail: E-mail:Hillsboro, {sxn124,versity, {sxn124,OR, Cleveland, axg468, axg468, USA. ark70}@case.edu. OH E-mail: ark70}@case.edu. 44106. [email protected]. E-mail:presents {sxn124,presents axg468, Anandaroop attack attack ark70}@case.edu. models Ghosh models and such suchpresentsto as the asreplay production replay attack attacks, attacks, models of FPGAs cloning, cloning, such [2].as However, replay Trimberger attacks, cloning, claims Aswin Krishna are with the department of Electrical Eng and Computer ManuscriptManuscript received received 23 Oct. 23 Oct. 2015; 2015; revisedManuscript revised 12 Apr. 12 received Apr. 2016; 2016; 23accepted Oct. accepted 2015; 2 June 2 revised Juneauthentication 12authentication Apr. 2016; attacks,accepted attacks, 2 power June power analysisauthenticationthat analysis attacks attacks, attacks, on attacks, FPGA invasive invasive hardware power and and analysis in the foundry attacks, invasiveas a means and to Sc., Case Western Reserve University, Cleveland, OH-44106, USA. E-mail: 2016.2016. Date Date of publication of publication 22 June 22 June 2016; 2016;2016. date date of Date current of of current publication version version 19 22 Oct. 19 June Oct. 2016. 2016; 2016. datesemi-invasive ofsemi-invasive current version attacks, 19 attacks, Oct. 2016. and and radiation radiationsemi-invasivetamper attacks with attacks the as attacks, related functionalityas related and to the radiation to the of the finalattacks design as related are unlikely to the (axg468, ark70)@case.edu. Robert Karam and Swarup Bhunia are with the De- RecommendedRecommended for acceptance for acceptance by S.Hu, by S.Hu, Y.Recommended Jin, Y. M.M. Jin, M.M. Tehranipoor, for Tehranipoor, acceptance and K.and by Heffner. S.Hu, K. Heffner. Y. Jin, M.M. Tehranipoor, and K. Heffner. partment of Electrical and Computer Eng,security Universitysecurity of of FPGAFlorida, of FPGA Gainesville, design design [4]. [4].securityfor None Noneseveral of of these ofFPGA reasons: these prior design prior (1) works, the works, [4]. foundry None of does these not prior know works, about ForFor information information on obtaining on obtaining reprints reprintsFor of this information of this article, article, please on please obtaining send send e-mail reprints e-mail to: to:of this article, please send e-mail to: FL-32611, USA. E-mail: robkaram@ufl.edu, [email protected]fl.edu. the design being mapped or end application of the devices; [email protected],[email protected], and andreference reference the Digital [email protected], Digital Object Object Identifier Identifier and below. reference below. the Digitalhowever, Objecthowever, Identifier discusses discusses below. hardware hardwarehowever, attacks attacks in discusses the in the foundry foundry hardware as aas attacksa in the foundry as a DigitalDigital Object Object Identifier Identifier no. 10.1109/TMSCS.2016.2584052 no. 10.1109/TMSCS.2016.2584052Digital Object Identifier no. 10.1109/TMSCS.2016.2584052meansmeans to cause to cause malfunction malfunction andmeans and leak leak IP.to cause IP. malfunction and leak IP.

2332-77662332-7766ß 2016ß 2016 IEEE. IEEE. Personal Personal use is use permitted, is permitted,2332-7766 but republication/redistribution butß republication/redistribution2016 IEEE. Personal requires use isrequires permitted, IEEE IEEE permission. but permission. republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.htmlSee http://www.ieee.org/publications_standards/publications/rights/index.htmlSee http://www.ieee.org/publications_standards/publications/rights/index.html for more for more information. information. for more information. 2 IEEE TRANSACTIONS ON MULTI-SCALE COMPUTING SYSTEMS, VOL. 2, NO. 3, JULY-SEPTEMBER 20162 to the functionality and reliability of the device. Third, the TMR technique suggested in [2] suffers from high area, power, and performance overhead. Given the relatively high power consumption and poor performance of FPGAs relative to application specific ICs (ASICs), this technique can be used only for a few logic functions, leaving other functions vulnerable to attack. Moreover, the tech- nique assumes that an attack will affect only one of the identical functions - it will not be useful if the payload of the Trojan is the output of the voting circuit. Therefore, in this paper, we make the following key contributions: 1) We provide a detailed analysis of hardware Trojan attacks in FPGA devices, as well as a taxonomy of hardware Trojans in FPGA. 2) We present a trust validation approach for FPGA de- vices, based on both functional and side-channel vali- dation, to counter diverse FPGA Trojan attacks. These approaches enable detection of arbitrary Trojan circuits in FPGA hardware. 3) We introduce a modified version of TMR, which we call Adapted Triple Modular Redundancy (ATMR), to enable robust protection against Trojan attacks with Fig. 1. Simplified diagram of FPGA design flow from device design to deployment showing possible stages for malicious alterations. considerably less power overhead than TMR. The remainder of the paper is organized as follows. Section 2 provides a brief overview of hardware Trojan and (2) a large number of reconfigurable resources enables the how it differs from faults. Section 3 provides an analysis of usage of Triple Modular Redundancy (TMR), so that critical hardware Trojans that can be inserted into FPGA devices functions are replicated three times, and a majority vote during production. In section 4 we discuss the methods that circuit can be used to select the most common output; (3) ex- can be used for detecting the Trojan attacks. We describe haustively testing the bitstream security features can ensure an approach for run-time Trojan tolerance in Section 5. that any attacks on them are detected during testing; (4) a We discuss the simulation results for the Trojan tolerance sample of chips can be destructively tested after fabrication scheme and important design/test considerations in Section to identify extraneous logic. 7. Finally, we conclude in Section 8. However, even with the above-mentioned security fea- tures ensuring the integrity of FPGA devices, we can 2BACKGROUND demonstrate that a variety of Trojan attacks are possible in the foundry. First, we show that not all attacks have 2.1 Hardware Trojan Attacks to depend on the final design and it is possible to insert Malicious modifications of integrated circuits (IC), referred malicious logic which is independent of the design. Besides to as Hardware Trojans, have emerged as a major security causing malfunction, a Trojan in the FPGA can be used to threat due the widespread outsourcing of IC manufactur- either partially or even completely leak the IP implemented ing to untrusted foundries. An adversary can potentially in the device. Moreover, an attacker in the foundry can tamper with a design in these fabrication facilities by insert- distribute Trojans dependent on the internal logic values ing malicious circuitry, leading to potentially catastrophic over the chip. Even though such Trojans which depend on malfunctions in security-critical application domains, such the IP have a low probability of being triggered, this is still as the military, government, communications, space, and unacceptable for mission-critical applications. medicine. Conventional post-manufacturing testing, test Second, although bitstream security functions can be generation algorithms, and test coverage metrics often fail to fully tested to ensure that no attacks are made on the FPGA’s detect Hardware Trojans due to their diversity, complexity, security, an attack can be made to steal a key and not cause a and rare triggering conditions. malfunction. Thus, thoroughly testing the security functions An intelligent adversary can design a Trojan to only may not help in protecting the IP from being copied by trigger under very rare conditions on an internal node, an attacker. Furthermore, sampling the fabricated devices which is unlikely to arise during post-manufacturing test, may not provide complete confidence that the device has but can be triggered during long hours of in-field operation not been altered during production; in other words, though [24]. The detection of Trojans by employing side-channel invasive testing may not reveal any Trojans, their absence parameters, such as power trace or delay overhead, is in the tested devices does not necessarily imply absence limited due to the large process variations in nanoscale IC on other untested devices. Since most FPGA vendors are technologies, detection sensitivities of small Trojans, and fabless and rely on off-shore foundries for production, hard- measurement noise [25]. Often these issues mask the effect ware Trojans inserted in the foundry pose a practical threat of Trojan circuits, especially for ultra small Trojans. From an MAL-SARKAR ET AL.: DESIGN AND VALIDATION FOR FPGA TRUST UNDER HARDWARE TROJAN ATTACKS 3

Fig. 2. General model of a hardware Trojan circuit realized through malicious modification of a hardware; (b) an example of combinational Trojan; (c) an example of sequential Trojan. adversary’s perspective, the desired features for a successful 2.2 Fault versus Trojan Trojan are as follows: rarely activated to evade logic based Conventional fault models can properly represent hard- testing, low overhead to evade side-channel based detection ware Trojans; however, standard functional/structural test- approach, and low side-channel signature to evade Design ing methods, as well as fault tolerance schemes cannot for Security (DfS) hardening mechanisms. adequately protect against diverse Trojan attacks. The major The condition of Trojan activation is referred to as the differences are that unanticipated behavior is not included trigger, and the node affected by the Trojan is referred as its in the fault list [24], and hardware Trojans usually have a payload. Trojans can be classified based on their triggering covert trigger condition, which is expected to rarely occur conditions or payload mechanisms. The trigger mechanism during normal field operation. On the contrary, traditional can be either digital or analog. Digitally triggered Trojans faults, run-time failures, and soft-errors typically occur at can be classified into combinational and sequential Trojans. random locations and are sensitized through arbitrary, typ- Trojan can also be classified into digital and analog based ically non-rare – and hence easily detectable – condition. on the payload mechanisms. Digital Trojans invert the logic Due to the random occurrence of faults, in many cases they values at internal nodes or modify the contents of memory may turn out to be ineffective or benign [26]. The payload locations, while the analog payload Trojans may change of a Trojan, however, is likely to be carefully selected by circuit parameters, such as performance, power, and noise an adversary to cause critical system failure or information margin. leakage. With respect to post-silicon validation or run-time toler- A combinational Trojan is activated on the simultane- ance, the difference between faults and Trojans are two-fold. ous occurrences of a particular condition at certain inter- First, faults induced by manufacturing defects are static, and nal nodes, while a sequential Trojan acts as a time-bomb, run-time failures are one-cycle transient failures. However, exhibiting its malicious effect due to a sequence of rare hardware Trojans are dynamic, causing malfunction for one events after a long period of operation. Fig. 2(a) illustrates or more cycles after triggering, and can also go back to a the general scenario of a Trojan attack in a design, where benign state after causing the malicious effect. In a spatial a Trojan is realized through the malicious modification of sense, manufacturing faults and soft errors can occur ran- the circuit with a trigger condition and payload. Fig. 2(b) domly in any part of a design. However, hardware Trojans shows an example of combinational Trojan which does not are inserted by intelligent adversaries and hence are likely contain any sequential elements, and depends only on the placed at strategic locations (e.g. in the key-dependent logic simultaneous occurrence of a set of rare node conditions. of a crypto-chip, enabling key leakage) while being hard-to- Conversely, the sequential Trojans shown in Fig. 2(c) un- detect. dergo a sequence of state transitions before triggering a malfunction. The 3-bit counter causes a malfunction at the node S on reaching a particular count, and the count is 3HARDWARE TROJAN ATTACKS IN FPGA increased only when the condition a = 1, b = 0 is satisfied at Before we describe the taxonomy of hardware Trojans in the positive clock-edge. reconfigurable hardware, it is necessary to understand why Protection against hardware Trojan has been widely such Trojans can be inserted in the foundry. Reconfigurable explored [25, 30-40] by researchers. These approaches are hardware consists of a regular array of identical repro- based on the following three approaches: (1) specialized grammable cells and other modules connected through functional testing [14] that rely on triggering an unknown a distributed programmable interconnect structure. Since Trojan and observing its effect in output ports of a design; most of the chip is occupied by the regular structure of (2) side-channel analysis that rely on observing a Trojan logic blocks and interconnect, it is relatively easy (compared effect in physical parameters, such as supply current or path to ASICs) for an attacker to reverse engineer the device delay [25, 40]; and (3) design/integration approaches [31-35] and identify the regular structures as well as additional that either prevent a Trojan insertion or facilitate detection modules. For example, a DSP core or clock manager can be during production test. easily identified from the layout of the FPGA and can be a 4 IEEE TRANSACTIONS ON MULTI-SCALE COMPUTING SYSTEMS, VOL. 2, NO. 3, JULY-SEPTEMBER 20164

Fig. 3. Taxonomy of hardware Trojans in FPGA.

potential target for hardware attacks as described in the next section [27] While the proposed Trojan models and detection methods may be applicable to many programmable logic devices, we focus on hardware Trojans in the widely-used SRAM-based FPGAs Programmability in FPGAs can be used to change the logic and electrical properties of a system [3]. Although this programmability provides flexibility to designers to quickly implement their designs according to their requirements, it can be exploited by an adversary to mount attacks to cause malfunction, leak sensitive information, and even cause physical damage [3], [5]. This also differentiates FPGA hardware Trojans from ASIC Trojans where the former alter the state of the system through malicious reprogramming after configuration. Wang, Tehranipoor, and Plusquellic proposed a taxon- omy of hardware Trojans in ICs [6]. In this paper, we present a taxonomy of FPGA-specific hardware Trojans that alter the programmed state of logic and I/O blocks. We classify Fig. 4. Simplified architecture of an FPGA showing the trigger points that the variety of FPGA hardware Trojans into two main cate- a Trojan may use. gories as shown in Fig. 3 according to their activation and payload characteristics. While it may be possible to classify FPGA Trojans based on other characteristics such as size IP-dependent Trojans: IP-dependent Trojans represent a or distribution, we believe that the proposed classification subclass of Trojans whose trigger signals depend on the covers most FPGA Trojans and is adequate to evaluate the design implemented in the device. Fig. 4 shows a simplified capabilities and limitations of detection methods. architecture of FPGAs consisting of a regular array of pro- grammable logic blocks and interconnects. As shown in Fig. 4, an adversary can insert a malicious circuit which monitors 3.1 Activation Characteristics the logic values of several nodes such as configuration logic, Based on the activation characteristics, Trojans can fall into outputs of logic modules, or look-up table (LUT) values. two subcategories marked as condition-based and always- When triggered, such a Trojan can cause malfunction in on in Fig. 3. Always-on Trojans are always active and per- many different ways, e.g. by altering the values stored in form their defined purpose of malfunction or leaking sensi- LUTs or configuration cells in the interconnect network to tive information. An example in this subcategory would be a cause incorrect routing between logic blocks, or writing Trojan that inverts all the bits of the configuration bitstream random values into the embedded memory. as the device is being programmed. This class of Trojans Since the final IP design is not available to the foundry may not be inserted by an intelligent adversary since they during device fabrication, an attacker who plans to insert can be easily detected during conventional testing. design-dependent hardware Trojans must do so without as- Condition-based FPGA Trojans, on the other hand, wait suming anything about the IP. Even though the probability until a particular condition is met before they become of such a Trojan becoming active is very low, an attacker active and cause malfunction. At this level, Trojans can may distribute many such Trojans over the entire chip to be further classified as logic-based and sensor-based (e.g. increase the likelihood of causing malfunction. Given the temperature, delay). At the lowest level, logic-based FPGA growing scope of the FPGA domain, IP-dependent Trojans Trojans can be further divided into IP dependent and IP are a practical threat that must be considered for hardware independent subcategories which we will discuss in detail assurance. with examples. IP-independent Trojans: An intelligent attacker can also MAL-SARKAR ET AL.: DESIGN AND VALIDATION FOR FPGA TRUST UNDER HARDWARE TROJAN ATTACKS 5

Fig. 5. Simplified schematic of digital clock manager (DCM) in Xilinx’s Virtex-5. Fig. 6. Programmable I/O block containing hardware Trojans to cause logical and electrical malfunction. insert Trojans whose activation conditions do not depend on the final design. Such Trojans can be inserted to alter the functionality of critical modules of the device. For example, Xilinx Spartan-3, Virtex-II, Virtex-II Pro FPGAs contain a separate module for clock management known as the digital clock manager (DCM) as shown in Fig. 5. This module contains a delay locked loop (DLL) for reconditioning clock signals. Additionally, it contains a frequency synthesizer for producing multiples or divisions of the input clock. Configuration parameters for the DCM are stored in its local SRAM. A simple Trojan design could simply increment an n-bit counter each clock edge until a particular number is reached, and then modify the configuration to produce a faster clock. This in turn can cause the critical path logic to fail in a sequential circuit. As another example of IP-independent Trojans, consider a simplified programmable I/O block shown in Fig. 6 which contains buffers, enable logic, slew rate control, and level Fig. 7. Diagram showing examples of payloads that can be altered by shifters for logic level compatibility. Similar to the DCM, the Trojans. configuraiton of the I/O block is stored in local SRAM. A counter-based Trojan could be inserted in the device; when Trojans intended to cause physical damage can create activated, this could modify the output-slew control, disable electrical conflicts at the I/O ports or at the programmable the output logic, or cause physical damage with logic-level interconnects. Consider the programmable I/O block in incompatibility at the I/O port. Again, these Trojans could Fig. 6. When a I/O port is configured to be an input by be distributed in many I/O blocks to improve the chances a design, the configuration cells in the I/O block should of causing malfunction. disable the output block to prevent internal conflicts. A counter-based Trojan can be inserted in the foundry which 3.2 Payload Characteristics detects the state of the I/O port and begins counting. Hardware Trojans can also be classified based on their When the counter counts to the final value, the Trojan may intended behavior. Trojans can be inserted for causing mal- enable the output logic when the port is configured as an function or for leaking sensitive information. In the former input. This would cause a high short-circuit current to flow case, Trojans alter the functionality of the design in some between the FPGA and the external device, possibly dam- way, while Trojans designed for leaking sensitive informa- aging the system. These Trojans are similar to the MELT tion may do so without modifying the logic functionality of viruses described in [3] except that Trojans causing physical the design. destruction may also be inserted in the foundry. Trojans for malfunction: Trojans in this category can be IP-leak Trojans: Since IP designs involve a high develop- further classified into two subcategories based on whether ment cost and contain sensitive information, security is of they cause logical malfunction or physical malfunction. utmost importance Many high-end FPGAs such as Xilinx’s Trojans presented in the previous sections cause logic mal- Virtex4 and Virtex5, and Altera’s StratixII and StratixIII offer function by modifying the values in the LUTs, causing bitstream encryption to prevent unauthorized cloning of the undesired routing between two logic modules, etc. Fig. 7 bitstream. Fig. 8 shows the security features in a generic shows additional examples of payloads affected by Trojans. FPGA device which contains the programmable logic ar- 6 IEEE TRANSACTIONS ON MULTI-SCALE COMPUTING SYSTEMS, VOL. 2, NO. 3, JULY-SEPTEMBER 20166

Fig. 8. FPGA device with security features for bitstream decryption.

ray (bottom right in the figure), configuration logic which controls the programming of the SRAM cells in the logic array, interconnect network, and additional modules in the device [7], [8]. The device also contains a decryptor module for decrypting the bitstream using a key stored in a non- volatile memory. Security measures in the device (1) prevent the key from being read and sent to a port by clearing the configuration data and keys when a read attempt is made, (2) prevent readback of the configuration data, and (3) restrict decryptor access after configuration [2]. However, all of these measures only prevent malicious code in an IP Fig. 9. Hardware Trojan inside: (a) a Configurable Logic Block (CLB) and from accessing the key or configuration data. (b) an Embedded Memory Block (EMB) of FPGA. Hardware Trojans can leak the IP in two ways: by leaking the decryption key, or leaking the design itself. An attacker in the foundry can insert an extraneous circuit (Fig. 8) to tap This severely harms the memory or logic integration density the wires connecting the non-volatile memory and decryp- in FPGA which makes it more amenable for Trojan insertion. tor module. Even if the decryptor module is implemented in Figure 9 shows a FPGA CLB, which can act as a 2-input the logic array by using a decryptor bitstream as mentioned look up table, a 4-bit RAM, or a 4-bit shift register [29]. in [7], such an instantiated module must have access to In Fig. 9(a), the inserted Trojan has been shown in red: the non-volatile key for decryption. A copy of the key can the trigger condition is derived from the memory content be stored in the Trojan which may then leak it through of two consecutive RAM locations, and can harm the shift side-channels or covert-channels. Using side-channels, a register functionality or the write enable functionality of the Trojan can hide the key in the power traces or by emitting memory block at run-time. The trigger condition can also electromagnetic radiation containing the information and be generated from the output of other CLBs, or alternatively an attacker can observe these signals to steal the key. For can be derived from the output of other functional units. example, the MOLES Trojan presented in [9] uses a spread- Figure 9(b) shows a Trojan instance inserted inside an spectrum technique to leak the key in the power traces over embedded memory block in a commercial FPGA device [30]. several clock cycles. Alternatively, a Trojan may also mul- Similar to a CLB, an EMB is also capable of executing func- tiplex the JTAG port, USB port, or any other programming tionalities like shift register, FIFO etc. in addition to acting port to leak the key through covert channels when the ports as Random Access Memory (RAM). The control circuitry are not being used. shown in Fig. 9(b) decides between normal read operation Since SRAM-based FPGAs are volatile, an external de- and shift register operation inside the EMBs. The inserted vice must be used to store the encrypted design. If an ad- logic or Trojan conditionally affects the shift operation inside versary is in possession of the FPGA device loaded with the a EMB by using adjacent memory contents and so can be design, the encrypted bitstream can be stolen by eavesdrop- triggered at run-time. It can be noted that the similar trigger ping the connection between an FPGA’s programming ports conditions can also be effectively used to leak the contents and the external device storing the encrypted bitstream. In of the memory to the output port. Such malfunctions can be other cases, a Trojan may fake a request to the external achieved by changing the address bits of the memory blocks device to send the programming data to the FPGA. This in different clock cycles and reading out the immediate next time, however, the Trojan muxes the bitstream and rather location of the memory in each and every cycle so as to than sending it to the the decryptor, it may store blocks of obtain the complete memory contents stored in a particular the bitstream at any given time and leak them through side- EMB or a set of EMBs. channels or covert-channels.

3.3 Trojans in CLB/EMB 4TROJAN DETECTION METHODS FOR FPGA FPGA configurable logic blocks (CLBs) and embedded In this section, we discuss some detection methods for memory blocks (EMBs) are highly flexible, but require sig- detecting FPGA hardware Trojans. These methods must be nificant configuration to implement the desired functions. used by the FPGA vendors when they receive the chips from MAL-SARKAR ET AL.: DESIGN AND VALIDATION FOR FPGA TRUST UNDER HARDWARE TROJAN ATTACKS 7

Fig. 10. Iterative logic-based self-checking test.

the off-shore foundry. We assume that the testing facility example, for a 2-input LUT having 4 cells, a 2-input Trojan used by a FPGA vendor is secure, eliminating the possibility can be chosen from the 4 cells in 4C2=6 ways. If the chosen that an adversary in the testing facility could intentionally two cells are designated a and b, then the trigger values for not detect malicious alterations. Detection methods can be the Trojan can be (ab, ab, ab, ab), requiring 24 functions to be classified into 3 categories: Visual detection techniques, logic mapped. However, since entire functions are mapped onto testing, and side-channel analysis. the LUTs, mapping one function with values a, b, c, d can Visual Detection methods: This class of detection meth- detect several Trojans such as ab, bc, cd, etc., thus requiring ods uses imaging to identify any malicious insertions fewer functions to be mapped. in the chip. These techniques include using X-ray imag- Still, if the trigger nodes are distributed among logic ing [10], scanning optical microscopy (SOM), scanning elec- blocks, the sheer number of logic blocks, LUTs, and configu- tron microscopy (SEM) [11], and picosecond imaging circuit ration cells makes it impossible for exhaustive testing to be analysis (PICA), among others. These methods, however, used for Trojan detection. Due to this restriction, we propose can be expensive in cost and analysis time. Moreover, a statistical approach of iterative self-checking based on the these techniques suffer from lack of resolution to decipher MERO test approach [14] as shown in Fig. 10 Since the logic/transistor/interconnect level information, primarily probability of activating a Trojan using the logic testing due to the obstruction by the stack of metal layers in approach decreases with the number of trigger inputs, we modern FPGAs [12]. With increasing device density due to assume that the number of trigger nodes n is small (2 to 4) technology scaling, effectiveness of the imaging techniques and only distributed within nearby CLBs. is expected to reduce significantly. Partial de-layering of Algorithm 1 shows the major steps in the proposed sta- ICs appears more effective [13]; however, it may in turn tistical test approach. We begin with a cluster of logic blocks render an FPGA non-functional. Due to the above limita- of size S, the number of nodes B, random configuration set tions, imaging analysis may not be a viable Trojan detection C, and input pattern set I. For each configuration mapped technique. to the logic blocks, we activate the nodes to logic-0 and logic- Logic-based testing: Standard logic testing of FPGAs by 1 several times using different input patterns. This proce- automatic test pattern generation (ATPG) tools is used for dure is done concurrently with the other remaining clusters detecting faults. Using input vectors, all the programmable of logic blocks, such that for each configuration all clusters logic blocks can be tested to function correctly without are tested simultaneously. The outputs of the clusters can be faults. For example, a stuck-at-0 fault in the programmable tested by a few logic blocks configured as output response logic blocks can be detected by mapping an AND function analyzers (ORA). These ORAs can be exhaustively tested at in the blocks and applying all-1 inputs. However, since the beginning of the test procedure. Any activated Trojan Trojan models are very different from fault models, a better that is activated will be observed at the primary outputs. approach is required to detect Trojans. For example, an Then, the cluster size is iteratively increased (e.g. to include attacker can insert a Trojan which uses many values of the two neighboring logic blocks) and the process is repeated. LUT SRAM cells or configuration cells as trigger nodes, and Such a statistical approach of testing can be effective since an such a Trojan will not be detected using testing based on attacker does not know the exact test procedure to cleverly fault models. insert malicious circuits. Moreover, for larger combinational Due to the availability of a large number of pro- and sequential Trojans, this approach can be useful to cause grammable blocks containing countless nodes, exhaustive partial activation of Trojans for detection using side-channel testing of all combinations of nodes is infeasible. For a k- techniques. k input LUT, having L=2k cells in the logic block, F =22 Redundancy and reconfigurability are two key features distinct functions are possible. For a n-input Trojan, the that are helpful for Trojan detection. Just as these features L inputs can be chosen in C2 ways from the L cells. Since are used are used to counter run-time failures in FPGAs, each combination can in turn be one out of 2n values, so can they be used to counter against FPGA hardware the total number of functions that need to be mapped to and design Trojans. In the case of FPGA hardware, recon- k exhaustively test a logic block becomes F =22 2n. For figurability allows the activation of several nodes in the ∗ 8 IEEE TRANSACTIONS ON MULTI-SCALE COMPUTING SYSTEMS, VOL. 2, NO. 3, JULY-SEPTEMBER 20168 Algorithm 1 The Statistical FPGA Testing Approach veal information about a few gates which are switching Inputs: Cluster of logic blocks of size S, the number of at any given time. The advantage of this type of analysis nodes B, random configuration set C and input pattern set is that, unlike logic-based testing, a Trojan does not have I to become active for detection; it merely needs to cause Outputs: Trojan-free ICs switching in the Trojan to consume dynamic power. For the IP-independent Trojans presented in section 3, transient 1: for all S =2Y such that 0 Y K do ≤ ≤ power analysis can be an effective detection method. For ex- 2: for all nodes in S do ample, a counter-based Trojan inserted in the clock manager 3: for all configurations in C do module can be detected by applying a clock signal to the 4: for all vector vi in I do FPGA and applying constant inputs to prevent logic blocks 5: propagate values to ORAs (simultaneously test from switching. An extraneous counter or any sequential other clusters of same size) circuit will consume transient power as it transitions from 6: observe outputs of ORAs one state to another. This contribution to dynamic power can 7: end for be identified and associated with malicious insertions after 8: end for accounting for process noise and clock coupling power. 9: end for 10: end for 5HARDWARE TROJAN TOLERANCE IN FPGA In this section, we propose a novel approach to protect logic blocks through different logic values. Redundancy can against Trojan circuits of varying forms in FPGA devices be used during testing, for example, by using N-modular (as discussed in Section 3). The protection approach is redundancy to ensure that the trigger nodes present in the based on tolerating Trojan effects during operation by either ORAs can also be detected by comparing the outputs of containing the Trojan effect (through activation detection) many ORAs. This is under the assumption that Trojans in or bypassing the effect of Trojan activation using redundant FPGA hardware (localized or distributed) do not affect all logic. The proposed Trojan tolerance approach takes its in- the resources in the same way. This can be coupled with spiration from existing run-time fault tolerance approaches dynamic run-time reconfigurability to improve the level of [15], [16]. The focus of the Trojan tolerance approach is to security. achieve maximum confidence with respect to trusted oper- Side-channel Analysis: Logic-based testing may not be ef- ation in the presence of Trojans in FPGA hardware, while fective for activating large combinational or sequential Tro- minimizing the area, power, and performance overhead. jans due to the extremely large number of possible trigger It is a challenge to maintain a satisfactory level of sur- nodes. Side-channel analysis involves the measurement and vivability with minimum cost. Each user requires differ- analysis of information obtained from an IC’s side-channels. ent survivability level, optimizing some attributes at the The information could be based on timing, power consump- expense of others. A single Trojan mitigation scheme may tion, or electromagnetic radiation. Side-channel analysis has not be satisfactory to all FPGA users; therefore various been proposed previously as a powerful technique to detect schemes can be combined in a coherent way to satisfy malicious insertions in an IC [14]. In this section, we specifi- different users’ requirements. We propose a hybrid scheme cally concentrate on side-channel information obtained from of hardware Trojan tolerance that combines adapted Triple power consumption in the device. Modular redundancy (TMR) and dynamic reconfiguration. Static power contains comprehensive information re- Dynamic reconfiguration in FPGA works around failures garding all the gates in the chip (including malicious while allowing time sharing of hardware components, and gates/transistors). Trojans causing physical damage by cre- therefore reduces area overhead while achieving high relia- ating electrical conflicts can also be detected using side- bility. However, increasing device failures can significantly channel analysis since these Trojans result in a large current affect the yield, run-time reliability, and the number of map- flow through the power supply. A simple design file can be pable functions. In addition, hardware Trojans are diverse, loaded which configures I/O ports as inputs and then mea- requiring different levels of resource usage, power con- sures the supply current. If these Trojans simultaneously try sumption, and response time [17], [18]. Although dynamic to configure the port as an output, then a very large current reconfiguration allows us to reduce resource requirements, can be detected by current sensors in the device, indicating it must be combined with a technique that is capable of a malicious modification. Since on-chip current sensors may detecting Trojans and restoring the original functionality. also be tampered in the foundry during production, they must be tested thoroughly to identify any tampering. An alternative and secure strategy would be to use an on-board 5.1 Trojan Tolerance through Adapted TMR (ATMR) current sensor to detect short-circuit conditions. Triple modular redundancy (TMR) is a well-known fault Trojans which do not cause physical damage and only mitigation technique that masks circuit faults by using cause logical malfunction may be extremely difficult to redundant hardware [15], [16], [19]. A TMR circuit has detect by analyzing static power. This is due to the difficulty three copies of the original circuit and a majority voter. A in isolating the contribution of the malicious insertions from single fault in one of the redundant hardware modules will the measured power traces in ICs containing many millions not produce an error at the output as the majority voter of transistors. On the other hand, transient or dynamic selects the result from the two working modules. Several power can be controlled by applying input vectors to re- experiments have demonstrated significant improvements MAL-SARKAR ET AL.: DESIGN AND VALIDATION FOR FPGA TRUST UNDER HARDWARE TROJAN ATTACKS 9

Fig. 11. Proposed Trojan-tolerant application mapping scheme using redundant computing blocks. Fig. 12. Flowchart showing a variant generation approach from a gate- level design along with an example. in reliability when using TMR through fault injection and 5.2 Improving Trojan Coverage with Design of Variants radiation testing [19]. Use of TMR has been explored ear- The Trojan tolerance scheme proposed in Section 5.1 can lier in FPGA in the context of tolerating run-time failures, provide protection against single Trojan attack in either such as functional failures induced by soft errors [20], [21]. the original or replica module. However, it cannot protect However, the use of TMR in FPGA results in very high (¿3x) against simultaneous activation of identical Trojan instances area overhead, as well as a performance overhead incurred in O and R . An adversary can incorporate the same Trojans from additional routing delay. Reducing these effects by i i in two or more clusters or CLBs in an FPGA, so that both selectively applying TMR makes all non-covered functions O and R can be similarly affected. For example, this vulnerable to attack. Moreover, the output of the voting i i can happen if O and R are identically mapped in two circuit itself may be the target of a Trojan. TMR also cannot i i different clusters, both of which have a combinational Trojan protect the system against attacks made to steal a key triggered by a specific combination of LUT content. In such without causing malfunction. a scenario, two Trojans in Oi and Ri would trigger at the Minor changes to TMR can not only reduce the overhead same cycle with identical malicious effect and the proposed associated with redundant hardware, but also enable it to tolerance approach would fail to detect it. To address this detect when an error has occurred, and which replica is scenario, we present an addition to the proposed Trojan responsible for the error. This is accomplished by using only tolerance approach. McIntyre et al [22] have proposed the two instances at a time instead of three. Using a comparator use of variants previously on multiple processing elements circuit, the outputs of the two instances are compared; if (PEs) or cores of a chip to discover Trojans but they did not a mismatch occurs, only then will the third replica, along explore it for other environments (e.g. FPGAs or ASICs). with an arbiter circuit, be enabled. This enables the system to In FPGA, the proposed ATMR scheme can further be detect which of the two original replicas was in error, output improved by implementing variants of adders for Oi and the correct result, and discard the erroneous replica. During Ri to ensure that Oi and Ri functionally compute the same operation, the circuit may halt for a short time interval result, but the adders are implemented in a structurally during the involvement of the third replica and arbiter. different manner. This can be achieved by applying differ- ent synthesis constraints like area and latency to different Fig. 11 shows three adders (O , R , and S ) that are 1 1 1 instances of the same module.It is highly unlikely that both mapped to the Trojan infected region of an FPGA, and adders (O and R ) will simultaneously trigger the same their corresponding outputs (p, q, and r). The comparator i i Trojan because different implementations involve different will compare the outputs (p, q) of the first two adders (O , 1 logic blocks, storage elements, interconnects, and memory R ). The third adder (S ) will not be used unless there is 1 1 locations. An intelligent attacker is likely to design sophisti- a mismatch between the two outputs p and q. In case of cated Trojans so that they are triggered by a sequence of rare a mismatch, the comparator, with the help of the arbiter, events or conditions [17]. Thus the probability of triggering continues comparing the output r with the outputs (p, q) the same Trojan by its variants is extremely rare, and we can until it finds a match and it determines which adder is in assume that both O and R cannot simultaneously trigger error. Then the comparator outputs the correct result and i i the same Trojan. prevents the propagation of erroneous data. A judicious design of structural variants can tolerate Although the third replica is required to determine simultaneous activation of Trojans in both original and which replica is in error, only two replicas are enough to flag replica modules. The dissimilarity between the variants can that at least one of them is infected with a Trojan, prevent the be exploited to defeat/avoid Trojans and design Trojan propagation of the Trojan’s payload in the system, and stop tolerant FPGAs. The variants would differ in both LUT leakage of potentially sensitive data. Therefore the scheme and programmable interconnect structures while maintain- we have proposed, even without the third replica, will be of ing the functional behavior and parametric specifications particular interest to military and government applications, (e.g. critical path delay). One possible approach to making as well as to commercial entities concerned with guarding variants is finding non-delay critical gates and regrouping their highly sensitive data. them. It ensures that the content of the LUT and the layout 10 IEEE TRANSACTIONS ON MULTI-SCALE COMPUTING SYSTEMS, VOL. 2, NO. 3, JULY-SEPTEMBER 201610 different implementations involve different logic blocks, storage elements, logic structures, and memory locations. Thus a judicious design of structural variants can avoid si- multaneous activation. Case 2b cannot be handled by using only one spare adder with the highest level of security. Two spare adders S1 and S2 may be required in order to achieve the highest level of trust in the case of two simultaneous failures as in Case 2b (in general, to tolerate n number of simultaneous failures with n max#ofmodules, we need n spares). Each spare resource≤ is used to determine and replace a faulty adder in each module. Worst-case Scenario: If multiple adders from multiple modules trigger Trojans simultaneously, the set of adders that trigger Trojans = X ,X ,X ,X , where X = OorR. { 1 2 3 4} Fig. 13. Sharing a spare resource by a set of homogeneous resources In the worst-case scenario, the highest level of security to reduce the hardware overhead. can be achieved at the expense of four spare adders because different implementations for Oi and Ri ensure that both adders will not trigger the same Trojans at the same time. of the design will be changed while the delay remains Thus the number of spare resources (S ) varies from zero the same. We regroup the logic gates to change both LUT i to four to achieve the highest level of security, depending content and their interconnection possibly changing the on the number and the location of Trojan affected adders required number of LUT resources. Next, we convert the (Fig. 13). However, many real time applications do not regrouped LUTs as “hard macros” (so that they are not require the highest level of security and (S ) can be time- optimized again by the synthesis tool). The last step is to re- i shared among the faulty modules. The proposed hybrid synthesize the circuit including the macros with the original scheme that combines adapted TMR with reconfiguration time constraints. Thus even when both replicas are infected has the potential to reduce the overhead/power consump- with a Trojan, the Trojan is very unlikely to be activated in tion associated with TMR by decreasing the usage of re- both the original and replica modules simultaneously. Thus, dundancies while allowing reconfiguration. The proposed the proposed scheme can overcome the limitation of TMR scheme can also overcome the limitation of TMR in that in that it can protect the circuit from multiple Trojan effects it can protect the circuit from multiple single event upsets by employing variants of a processing unit. Fig. 12 shows (SEUs) by employing variants of adders. the flow chart for implementing the variants.

5.3 Exploiting Reconfigurability to Reduce Overhead 6SIMULATION RESULTS Many real time applications do not require the highest level In this section we present case studies with a commercial of security and spare resources can be time-shared among FPGA device and a benchmark circuit to illustrate the effec- the faulty modules. For example, instead of using a dedi- tiveness of the proposed Trojan tolerance approach. cated third redundant component, n number of redundant We consider the Altera Cyclone IV GX FPGA family of components can be shared among m (n

TABLE 1 Comparison of design overhead between TMR and ATMR without variants, with variants, and with time-shared resources

Without Variants With Variants Time-shared Res. TMR ATMR x Impr. TMR ATMR x Impr. TMR ATMR x Impr. Power (mW) 4.70 3.15 1.5X 4.95 3.26 1.5X 16.0 12.42 1.3X Area (LE∗) 850 856 1X 860 872 1X 3166 2184 1.4X Latency (ns) 6.7 6.7 1X 6.4 6.4 1X 7.9 7.9 1X

∗Logic Elements, as reported by the Altera Quartus II FPGA mapping tool

TABLE 2 with Trojan verification and/or tolerance approaches [20] Comparison of Design Overhead for TMR and ATMR at the Component for the IP. Additional, redundant hardware, such as that (C) and ALU (A) Levels of Granularity used in hot-swapping [31] or hot-spares [31] can provide additional fault tolerance against some Trojan attacks and Area Lat. Pow. x Impr. x Impr. x Impr. increase reliability for mission-critical systems. to provide (LEs) (ns) (mW) (Area) (Lat.) (Pow.) comprehensive protection against Trojan attacks. ALU 225 6.4 1.4 - - - TMR-C 1928 10 7.05 8.6X 1.6X 7.9X ATMR-C 1940 10 5.1 8.6X 1.6X 5.7X 7.3 Granularity for ATMR TMR-A 860 6.4 4.95 3.8X 1.0X 3.5X ATMR-A 872 6.4 3.26 3.9X 1.0X 2.3X While selecting the granularity for designing ATMR, there is a trade-off among the controller/comparator overhead, the number of Trojans, reconfiguration complexity, and the de- 7DISCUSSION lay in Trojan detection. The advantages to finer-granularity In this section, we discuss several relevant issues related to modules include fewer Trojans, simplicity in reconfigu- FPGA security and the proposed Trojan tolerance approach. ration, and accuracy in Trojan detection. However, fine- grained detection will result in high controller/comparator overhead, increased simulation time, and increased latency 7.1 Trojans in the Control/Arbiter or Comparator Logic of the entire system, which makes it hard to track the Most research on TMRs assumes that the voter circuits system-level propagation of Trojans. On the other hand, are hardened structures, and therefore not vulnerable to coarse-grained modules could result in multiple Trojans hardware Trojans. This assumption is not always true, affecting the same circuit and increased complexity in leaving the TMR system itself unprotected. Kshirsagar and reconfiguration, but less controller/comparator overhead Patrikar [23] proposed a novel fault-tolerant voter circuit for and delay. Table 2 shows the area/delay/power overheads TMR that improved the reliability of the digital systems. Ban for component level and ALU level TMR and ATMR ap- and Lirida [28] further enhanced the reliability of a system proaches. While component level TMR / ATMR provides by providing an alternative architecture for a majority voter more security, it increases reconfiguration latency and over- in TMR. However, their architectures are robust to single all system latency (1.6x), while incurring greater area (8.6x) fault but cannot handle multiple failures. and power (5.7x) overhead. Conversely, ALU-level TMR The proposed scheme can overcome the limitation of and ATMR provide less security, but incur smaller area TMR, since it can protect the circuits from multiple faults (3.9x) and power (3.5x) overhead, while delay remains un- by employing variants. We suggest two techniques to de- changed; again, the power consumption for ATMR is further termine if the arbiter or the comparator in the proposed reduced (2.3x) because of the conditionally-enabled third architecture is compromised: (1) majority voting, or (2) instance. These tradeoffs enable designers to fine-tune the exhaustively testing the comparator and arbiter circuits system security while considering relevant overheads in the for the presence of Trojans. The first approach would im- resultant hardware. prove the reliability of the system majority voting on the voters/arbiters will result in high overhead. The second 8CONCLUSION approach – exhaustive testing for trojans – is feasible in this case because the voter/arbiter circuits are relatively small, Malicious alterations to a design are possible at various making this the preferred method. stages of the design flow. In this paper, we focused on malicious changes that can be inserted into FPGA devices during production. We presented a taxonomy of hardware 7.2 Trojan in the Design (FPGA IP) Trojan models specific to FPGAs, including those that cause Hardware Trojans also can be inserted into the RTL or logical malfunctions and/or physical damage, and can be netlist of the design IP. With the increasing complexity inserted by an attacker in the foundry without knowledge of of hardware designs, it is becoming increasingly common the final design. We explained multiple detection strategies for companies to purchase IP blocks, saving on the de- that could be used to non-invasively test FPGAs to identify sign and verification effort. The prevalence of IP vendors the presence of Trojans. As FPGAs are being increasingly makes IP Trojan insertion a very real concern for real- used in a wide field of applications, the hardware Trojan world applications. The proposed approach, which aims to models must be fully understood before reliable detection tolerate Trojans in the physical hardware, can be combined strategies can be developed to provide hardware assurance. 12 IEEE TRANSACTIONS ON MULTI-SCALE COMPUTING SYSTEMS, VOL. 2, NO. 3, JULY-SEPTEMBER 201612

TABLE 3 Comparison of Design Overhead for TMR and ATMR Correction Techniques on a DLX Processor

Area (LEs) Flipflops RegFile (bits) Delay (ns) Power (mW) x Impr. (Area) x Impr. (Lat.) x Impr. (Pow.) IF 199 128 0 5.6 6.89 - - - TMR IF 813 384 0 5.7 20.1 4.1X 1X 2.9X ATMR IF 835 384 0 5.7 11.4 4.2X 1X 1.7X ID 222 128 2048 4.9 11.96 - - - TMR ID 988 384 6144 4.9 33.96 4.5X 1X 2.8X ATMR ID 1011 384 6144 4.9 21.4 4.6X 1X 1.8X EX 1512 133 0 18 23.0 - - - TMR EX 4747 399 0 19.7 71.98 3.1X 1.1X 3.1X ATMR EX 4770 399 0 19.7 38.03 3.2X 1.1X 1.7X MEM 105 101 0 5 2.03 - - - TMR MEM 487 303 0 5 11.05 4.6X 1X 5.4X ATMR MEM 510 303 0 5 5.5 4.9X 1X 2.7X WB 44 0 0 4 1.24 - - - TMR WB 186 0 0 4 3.09 4.2X 1X 2.5X ATMR WB 209 0 0 4 2.05 4.8X 1X 1.7X DLX 2082 490 2048 18 29.04 - - - TMR DLX 7221 1470 6144 19.7 89.7 3.5X 1.1X 3.1X ATMR DLX 7244 1470 6144 19.7 48.5 3.5X 1.1X 1.7X

In addition, we proposed a novel Trojan tolerance scheme, [11] J. Soden, R. Anderson and C. Henderson, “IC Failure Analysis namely ATMR, that protects FPGA devices against Trojans Tools and Techniques – Magic, Mystery, and Science,” International Test Conference, Lecture Series II - Practical Aspects of IC Diagnosis and of varying sizes and functionalities. We compared the pro- Failure Analysis: A Walk through the Process, pp. 1-11, 1996. posed scheme with the conventional TMR approach and [12] V. Nagabudi, “Extraction Based Verification Method for off the demonstrated that ATMR requires less power overhead, Shelf Integrated Circuits,” M.S. Thesis, CWRU, 2010. while maintaining the same or higher level of security and [13] K.K. Yu and C.N. Berglan, “Automated system for extracting performances as TMR. Further improvements in overhead design and layout information from an integrated circuit,” United States Patent 5,086,477, 1992 have been achieved by exploiting reconfiguration and reuse [14] R.S. Chakraborty, F. Wolff, S. Paul, C. Papachristou, and S. Bhunia, of the resources in ATMR without compromising security. “MERO: A Statistical Approach for Hardware Trojan Detection,” CHES, 2009. [15] H. Kubatova and P. Kubalik, “Fault-Tolerant and Fail-Safe Design ACKNOWLEDGMENT Based on Reconfiguration,” Design and Test Technology for Dependable Systems-on-Chip, pp. 175-194, 2011. The work is funded in part by National Science Foundation [16] N. Gaitanis, “The Design of Totally Self-Checking TMR Fault- (NSF) grants 1603475, 1603483 and 1603480 Tolerant Systems,” IEEE Transaction on Computers, vol. 37, no. 11, 1988. [17] R. S. Chakraborty, S. Narasimhan, and S. Bhunia, “Hardware Trojan: Treats and Emerging Solutions,” IEEE International High REFERENCES Level Design Validation and Test Workshop, pp. 166-171, 2009. [18] M. Tehranipoor and F. Koushanfar, “A Survey of Hardware Trojan [1] DARPA, TRUST in Integrated Circuits (TRUST), 2008. Avail- Taxonomy and Detection,” IEEE Design and Test of Computers, vol. able [Online] http://www.darpa.mil/mto/programs/trust/index. 27, no. 1, pp. 10-25, 2010. html. [2] S. Trimberger, “Trusted design in FPGAs,” 44th Design Automation [19] F. Lima, C. Carmichael, J. Fabula, R. Padovani, R. Reis, “A Fault Conference, 2007. Injection Analysis of Vertex FPGA TMR Design Methodology,” [3] I. Hadzic, S. Udani, J. Smith, “FPGA viruses,” Ninth International European Conference on Radiation and Its Effects on Components and Workshop on Field-Programmable Logic and Applications, 1999. Systems, pp. 275 - 282, 2001. [4] S. Drimer, “Volatile FPGA design security: a survey,” Cambridge [20] M. Abramovici and P. Bradley, “Integrated Circuit Security - New University, 2008. Threats and Solutions,” Annual Workshop on Cyber Security and [5] T. Huffmire, “Handbook of FPGA design security,” 44th Design Information Intelligence Research, pp. 1-3, 2009. Automation Conference, 2007. [21] S. Srinivasan, A. Gayasen, N. Vijaykrishnan, M. Kandemir, Y. Xie, [6] X. Wang, M. Tehranipoor, J. Plusquellic, “Detecting Malicious In- M.J. Irwin, “Improving Soft-error Tolerance of FPGA Configuration clusions in Secure Hardware: Challenges and Solutions,” IEEE Bits,” IEEE/ACM International conference on Computer-aided design, International Workshop Hardware- Oriented Security and Trust, pp. 15- 2004. 19, 2008. [22] D. McIntyre, F. Wolff, C. Papachristou and S. Bhunia, “Trustworthy [7] S. Trimberger, “Method and apparatus for protecting proprietary Computing in a Multi-core System using Distributed Scheduling,” decryption keys for programmable logic devices,” US Patent IEEE International On-Line Testing Symposium), 2010. 6654889, 2003. [23] R.V. Kshirsagar and R.M. Patrikar, “Design of a novel fault- [8] Aletar: Military Anti-Tampering Solutions Using Programmable tolerant voter circuit for TMR implementation to improve reliability Logic. [Online]. Available: http://www.altera.com/literature/cp/ in digital circuits,” Microelectronics Reliability, vol. 49, pp. 1573-1577, CP-01007.pdf. Dec. 2009. [9] L. Lin, W. Burleson, C. Paar, “MOLES: malicious off-chip leakage [24] F. Wolff, C. Papachristou, S. Bhunia, R.S. Chakraborty, “Towards enabled by side-channels,” Intl. Conf. on Computer-Aided Design, Trojan-Free Trusted ICs: Problem Analysis and Detection Scheme,” 2009. Design, Automation and Test in Europe, 2008. [10] A. Schropp et al, “Non-destructive and quantitative imaging of a [25] D. Agrawal, S. Baktir, D. Karakoyunlu, P. Rohatgi, B. Sunar, “Tro- nano-structured microchip by ptychographic hard X-ray scanning jan detection using IC fingerprinting,” IEEE Symposium on Security microscopy,” Journal of Microscopy, 2010. and Privacy, 2007. MAL-SARKAR ET AL.: DESIGN AND VALIDATION FOR FPGA TRUST UNDER HARDWARE TROJAN ATTACKS 13

[26] M. Rebaudengo et al., “Analysis of SEU effects in a pipelined Seetharam Narasimhan (Member, processor,” IEEE International On-Line Testing Workshop, 2002. IEEE)received the B.E. (honors) degree in [27] R. Torrance and D. James, “The State-of-the-Art in IC Reverse En- electronics and telecommunication engineering gineering,” Cryptographic Hardware and Embedded Systems (CHES), from Jadavpur University, Kolkata, India, in 2006 pp. 363-381, 2009. and the Ph.D. degree in computer engineering [28] T. Ban and L.A.B. Naviner, “A simple fault-tolerant digital voter from Case Western Reserve University, circuit in TMR nanoarchitectures,” 8th IEEE International NEWCAS Cleveland, Ohio, USA, in 2012. Currently, he Conference, pp. 269 - 272, 2010. is a Component Design Engineer with Intel [29] T.J. Bauer and S.P. Young, “FPGA Architecture with Deep Look-up Corporation, Hillsboro, OR, USA, in the System Table RAMs,” US Patent 6288568 B1, 2001. Validation and Engineering (SVE) Security [30] Y. Lin, C. Zhang, D. Jefferson and S. Reddy,“Memory Array Center of Excellence. His areas of interest Operating as Shift Registers,” US Patent 6288568 B1, 2006. include hardware security evaluation of system-on-chip products. He [31] J.M. Bearfield, “Introduction to Hot Swap,” [Online] has worked extensively on hardware Trojan design and detection as http://eetimes.com/design/analog-design/4018093/Introduction-to-Hot- part of his graduate research under the guidance of Prof. S. Bhunia. He Swap, Nov 2011. has two book chapters and more than 30 publications in peer-reviewed [32] K. Xiao and M. Tehranipoor, “BISA: Built-In-Self-Authentication journals and premier conferences in the areas of hardware security and for Preventing Hardware Trojan Insertion”, IEEE Int. Workshop on biomedical very large scale integration (VLSI) design. Hardware Oriented Trust and Security, pp. 45-50, 2013. Dr. Narasimhan has served as a peer reviewer for various IEEE [33] F. Imeson, A. Emtenan, S. Garg, and M.V. Tripunitara, “Securing conferences and journals and in the Technical Program Committee computer hardware using 3D integrated circuit (IC) technology and for several IEEE/ACM conferences such as the Design Automation split manufacturing for obfuscation, USENIX conference on Security, Conference (DAC), the International Symposium on Quality Electronic 2013. Design (ISQED), VLSI Design-India, the Workshop on NanoArchitecture [34] S. Narasimhan, W. Yueh, X. Wang, S. Mukhopadhyay, and S. (NANOARCH), and the International Conference on Computer Design Bhunia, “Improving IC Security against Trojan Attacks through (ICCD). He has been a student competition finalist at the IEEE EMBS Integration of Security Monitors, IEEE Design & Test of Computers, conference in 2009, finalist at the CSAW Embedded Systems Challenge 2012. in 20092011, and received the best paper nomination at the 2010 IEEE [35] J. Rajendran, V. Jyothi, O. Sinanoglu, and R. Karri, “Design and Symposium on Hardware-Oriented Security and Trust (HOST). analysis of ring oscillator based Design-for-Trust technique, VLSI Test Symposium, 2011. [36] H. Salmani, M. Tehranipoor, and J. Plusquellic, “A Novel Tech- Anandaroop Ghosh graduated with a M.S. de- nique for Improving Hardware Trojan Detection and Reducing gree from the department of Electrical Engineer- Trojan Activation Time, IEEE Transactions on VLSI, 2011. ing and Computer Science, Case Western Re- [37] M. Banga and M. Hsiao, “ODETTE: A non-scan design-for-test serve University. He received his B.E. (Hons) in methodology for Trojan detection in ICs, IEEE Int. Workshop on Electrical Engineering from Jadavpur University, Hardware Oriented Trust and Security, pp. 18-23, 2011. Kolkata, India in 2008. Prior to admission at [38] G. T. Becker, F. Regazzoni, C. Paar, and W. P. Burleson, “Stealthy Case, he worked as a Research Consultant at dopant-level hardware Trojans: extended version, Journal of Crypto- the Indian Institute of Technology (IIT), Kharag- graphic Engineering, pp. 1-13, 2014. pur, India. [39] S. Wei and M. Potkonjak, “Scalable hardware trojan diagnosis, IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 20, pp. 1049-1057, 2012. [40] A. Waksman, M. Suozzo, and S. Sethumadhavan, “FANCI: Iden- Aswin Krishna (Student Member, IEEE) re- tification of stealthy malicious logic using Boolean functional anal- ceived the B.E. (honors.) degree in electronics ysis, ACM SIGSAC Conference on Computer & Communications Secu- and instrumentation from the Birla Institute of rity, pp. 697-708, 2013. Technology and Science, Pilani, India, in 2006. [41] N. Yoshimizu, “Hardware Trojan detection by symmetry breaking in path delays, IEEE International Symposium on Hardware-Oriented Security and Trust, 2014.

Sanchita mal-Sarkar received her Doctor of En- gineering (D. Eng) in Electrical and Computer Engineering from Cleveland State University in 2009. She received her MS in Computer Science Swarup Bhunia (Senior Member, IEEE) re- from the University of Windsor, Winsor, Canada ceived the B.E. degree (honors) from Jadavpur and her MSc in Physics (with specialization in University, Kolkata, India, the M.Tech. degree Electronics) from the Benaras Hindu University, from the Indian Institute of Technology (IIT), Benaras, India. Currently she is an associate Kharagpur, India, and the Ph.D. degree in com- lecturer in Electrical Engineering and Computer puter engineering from Purdue University, West Science at Cleveland State University. Her re- Lafayette, IN, USA in 2005. Currently, he is a search interests include Hardware and Software Professor in the Department of Electrical and Security and Trust, Fault-tolerant Networks, Soft/Granular Computing Computer Engineering, University of Florida, and Risk Analysis, and Wireless Sensor Networks. She has authored Gainesville, FL, USA. Earlier, he has served as numerous journal articles and presented papers at several national and the T. and A. Schroeder Associate Professor of international conferences. Her research is supported by the National Electrical Engineering and Computer Science at Case Western Reserve Science Foundation (NSF) and Cleveland State University. Dr. Mal- University, Cleveland, OH, USA. He has over ten years of research and Sarkar has been a member of IEEE since 2011. development experience with over 200 publications in peer-reviewed journals and premier conferences. His research interests include hardware security and trust, adaptive Robert Karam (Student Member, IEEE) re- ceived the B.S.E. and M.S. degrees in com- nanocomputing, and novel test methodologies. Dr. Bhunia received the puter engineering from Case Western Reserve 2013 IBM Faculty Award, the 2011 National Science Foundation Career University, Cleveland, OH, USA, in 2012 and Development Award, the 2009 Semiconductor Research Corporation 2015, respectively. He is currently working to- Inventor Recognition Award, the 2005 SRC Technical Excellence Award, ward the Ph.D. degree in computer engineer- and several best paper awards/nominations. He has been serving as an ing at the University of Florida, Gainesville, FL, Associate Editor of the IEEE TRANSACTIONS ON COMPUTER-AIDED USA. His research interests include reconfig- DESIGN, the IEEE TRANSACTIONS ON MULTI-SCALE COMPUTING urable and domain-specific accelerator architec- SYSTEMS, ACM Journal of Emerging Technologies, and Journal of Low tures, biomedical signal processing, neuromor- Power Electronics. phic computing, and hardware security.