Anti-Piracy aware IP Chipset Design forCEDevicesctsoc.ieee.org/images/files/pdf/DL2.pdf ·...

Anti-Piracy aware IP Chipset Designfor CE Devicesfor CE Devices

Dr. Anirban Sengupta, Prof.IEEE Di ti i h d L t IEEE C El t i S i tIEEE Distinguished Lecturer, IEEE Consumer Electronics SocietySenior Editor, IEEE Consumer Electronics (CEM)Editor-in-Chief, IEEE VCAL (IEEE Computer Society TC-VLSI)Executive Committee, IEEE CS Technical Committee VLSITechnical Program Chair, ICCE ‘18, Las VegasComputer Science and EngineeringIndian Institute of Technology Indore-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --E-mail: [email protected]: www.iiti.ac.in/~asengupt

Some of my key Journal Contributions in CE Device - Hardware Security/IP Protection1. A. Sengupta et. al “Triple-Phase Watermarking for Reusable IP Core Protection during Architecture Synthesis", IEEE Transactions on Computer Aided Design of Integrated

Circuits & Systems (TCAD), 20172. A. Sengupta et. al "Securing IoT Hardware: Threat models and Reliable, Low-power Design Solutions", IEEE Transactions on Very Large Scale Integration (VLSI) Systems,

20173. A. Sengupta et. al "TL-HLS: Methodology for Low Cost Hardware Trojan Security Aware Scheduling with Optimal Loop Unrolling Factor during High Level Synthesis", IEEE

Transactions on Computer Aided Design of Integrated Circuits & Systems (TCAD), 20164. A. Sengupta et. al "Exploring Low Cost Optimal Watermark for Reusable IP Cores during High Level Synthesis" , IEEE Access Journal, 20165. A. Sengupta et. al "Protecting an Intellectual Property Core during Architectural Synthesis using High-Level Transformation Based Obfuscation", IET Electronics Letters, 20176. A. Sengupta et. al "IP core Protection of CDFGs using Robust Watermarking during Behavioral Synthesis Based on User Resource Constraint and Loop Unrolling Factor", IET

lElectronics Letters, 20167. A. Sengupta et. al "Low Cost Security Aware High Level Synthesis Methodology", IET Journal on Computers & Digital Techniques (CDT), 20168. Deepak Kachave, Anirban Sengupta "Functionally Locked IP Core in CE Hardware for Shielding against Reverse Engineering Attacks", IEEE Consumer Electronics, 20189. A. Sengupta "Protection of IP-Core Designs for CE Products", IEEE Consumer Electronics Magazine, 201510. A. Sengupta "Hardware Vulnerabilities and its Effect on CE Devices: Design-for-Security against Trojan", IEEE Consumer Electronics Magazine, 201711. A. Sengupta et. al "Anti-Piracy aware IP Chipset Design for CE Devices: Robust Watermarking Approach", IEEE Consumer Electronics Magazine, 2017.

" d f h d l d f d " l12. A. Sengupta "Hardware Security of CE Devices: Threat Models and Defence against IP Trojans and IP Piracy", IEEE Consumer Electronics Magazine, 201713. A. Sengupta et. al "Forensic Engineering for Resolving Ownership Problem of Reusable IP Core generated during High Level Synthesis", Elsevier Journal on Future

Generation Computer Systems, 201814. A. Sengupta et. al "Low Overhead Symmetrical Protection of Reusable IP Core using Robust Fingerprinting and Watermarking during High Level Synthesis", Elsevier Journal

on Future Generation Computer Systems, 201715. A. Sengupta et. al "Automated Low Cost Scheduling Driven Watermarking Methodology for Modern CAD High-Level Synthesis Tools" Elsevier Journal of Advances in

fEngineering Software, 201716. A. Sengupta et. al Low cost optimized Trojan secured schedule at behavioral level for single & Nested loop control data flow graphs, Elsevier VLSI Integration, 201617. A. Sengupta et. al "Security and Reliability Aware System Design for Mobile Computing Systems", IEEE Access Journal, 2016

CE Device Vulnerabilities

A. Sengupta et. al "Hardware Vulnerabilities and its Effect on CE Devices: Design-for-Security against Trojan", IEEE Consumer Electronics Magazine, 2017

Threats to an IP

False claim of Ownership

Ownership Ab Piracy

Threats to IPAbuse y

an IP core

Trojan Insertion

Approaches for IP Protection

False claim of Ownership

Digital Watermarking

Computational Forensic Engineering

(CFE)

Ownership Ab Piracy

Threats to IP

IP meteringAbuse yan IP core

g

Trojan Insertion

Logic/Structural Obfuscation

IC design flowg

InputDFG/CDFG

RTL design

Gate level netlistHigh Level

Synthesis Logic Synthesis Physical Design Physical Verificationy

FabricationPackagingTesting

Application Library Constraints Resource Configuration

Anti-Piracy aware IP Chipset Design for CE Devices: Detecting IP Piracy/Cloning/False IP Core ownership through Watermark

Application, Library, Constraints

The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.

Scheduling


Hardware Allocation & Binding in Scheduled graph

Resource Configuration

Select desired signatureHardware Allocation & Binding in Scheduled graph


Perform Register allocation using colored interval graph


M difi d R i t ll ti i f ti i S h d li

Decode signature to convert to watermarking constraints

Insert constraints into IP design

The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.Multiplexing scheme based on modified register allocation in scheduling


DatapathThe image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.

Controller

Modified Register allocation information in SchedulingWatermarking

Datapath Controller


Watermarked IP core at RTLArchitectural Synthesis

RTL SynthesisRTL Synthesis

Gate level Synthesis

Layout Synthesis Watermarked IP chipset

Design before embedding WatermarkDesign before embedding Watermark

Reg Y2

A2

Reg Y2

Reg Y1Reg Y1

Design before embedding Watermark andDesign before embedding Watermark and Signature

Design after embedding WatermarkDesign after embedding Watermark

Reg Y2

A2

Reg Y1

Multiplexing schemes for RegistersMultiplexing schemes for Registers

i

Reg I1Reg I2 Reg I3 Reg I4

Final watermarked (anti-piracy aware) IP chipset

Sig 1

Sig 2

Sig 3

Sig 4

Sig 5

Sig 6

Sig 7

ControlUnit

Sig 7

Sig 8

Sig 9

Sig 10

Sig 11

Sig 12

Clock

Reset

Reg Y1

Reg Y2

………………….

Sig 44

Clock

Reset

Reg I1 RegY1

VDD GND

Reg I1

Reg I2

Reg I3

Reg I4

RegY1

RegY2

Computational Forensic Engineering (CFE): Detecting IP Piracy/Cloning/False IP CoreComputational Forensic Engineering (CFE): Detecting IP Piracy/Cloning/False IP Coreownership

F t d St ti ti l d t ll ti Study HLS tool of each competing IPFeatures and Statistical data collection

Feature Extraction

IP core Features AnalysisStudy HLS tool of each competing IP

vendor

Decide common design/parametric features

Entity Clustering

Perform IP core Feature Extractiondesign/parametric features

Create feature set

Validation

Perform IP Validation/Matching Devise feature

extraction rules

CFE can be understood as follows: given a solution S to a problem P having a finite set of algorithms/tools A n (n = 1 i) applicableCFE can be understood as follows: given a solution S to a problem P having a finite set of algorithms/tools A_n (n = 1....i) applicableto problem P that can generate solution S, the aim of CFE is automated identification with a high degree of confidence that thealgorithm/tool A_i has been applied to generate solution S

A. Sengupta et. al "Forensic Engineering for Resolving Ownership Problem of Reusable IP Core generated during High Level Synthesis", Elsevier Journal on Future Generation Computer Systems, 2018

Problem Statement: Computational Forensic Engineering for IP protectiong g

HLS Tool of Vendor 1



Inputs

HLS Tool of Vendor n……

Given IPID3

IPV1(HDL) IPV2(HDL) IPV3(HDL) IPvn (HDL)……

Given IPID(HDL)

• Note: The IP core whose owner (rightful claimant) is to be identified is termed as IPID and IPs generated (in RTLcode) as output through ‘nth’ competing HLS tool is termed as IPvn.

• Assuming that there are ‘n’ numbers of claimant (competing HLS tool providers) parties who are claiming theownership rights of IPID i.e. the IP core providers are claiming that the IPID has been generated by their respectiveHLS tool.

• Proposed CFE provides a novel solution to the problem that arises during such legal battles for claiming IP rightsof vendor i.e. “it solves among the various claimants of IP core, who is the rightful claimant (actual owner) ?”


Devised Methodology: Computational Forensic Engineering for IP protection g g g




HLS Tool of Vendor n

Inputs

……Given IPID

3

IPV1 (HDL) IPV2 (HDL) IPV3(HDL) IPvn (HDL)……

Given IPID(HDL)

Devised CFE methodology

IP core feature and data collectionAutomated

IP core feature extraction

Automated portion of

proposed CFE

IP core Validation


Devised Methodology (cont.) g

IP core feature and data collectionIdentify generic features (properties) of HLS &

RTL IP d iRTL IP core design

Identify unique features of HLS & RTL IP core design

Feature set = {Unique features, generic features}

IP core feature extraction

Devising methodology to extract generic and unique features of IP core

f f

(a) Unique features = {pipelining, chaining, multi cycling reliability, loop support, design objective, Trojan security}

IP core Validation

Perform feature extraction and store the ‘feature set’

IP ownership is decided on basis of matching

(b) Generic features = {scheduling algorithm, resource type, bus width support}

IP ownership is decided on basis of matching between vendor’s IP and IPO


Important things to know: Computational Forensic Engineering for IP protection

• Typically HLS tool employ stochastic algorithms (control parameters such as seed population, terminatingditi ) d t t lti l t h l i


condition) and target multiple technologies.

• Each separate run of these HLS tool produces slightly different IP core design for same application. Selectingtechnology/control parameter dependent feature set would require the environment of the tool to bereproduced *exactly* while verifying ownership through CFE (during feature extraction and validation)reproduced *exactly* while verifying ownership through CFE (during feature extraction and validation).

• On the contrary, selecting technology/control parameter independent feature set does not require the toolto be executed (for IP core generation) in the *exactly same* reproduced environment.

• As technology/control parameter independent design feature set is based on internal algorithmic propertiesof the HLS tool, it allows verifying ownership accurately despite slightly different IP core solutions beinggenerated on each separate run.


•The CFE approach for IP core protection for validation requires the following as inputs: Executable version of HLS tools


corresponding to ‘n’ claiming IP vendors and the given IP core (in RTL hardware description language) whose owner is to beidentified.• This is analogous to signature detection step in watermarking where the signatures from claiming vendors are taken as input todetermine which matches the signature present in the given IP core. Similarly for proposed CFE, the feature set (extracted from RTLdescription) of IP core corresponding to ith HLS tool which fully matches the feature set of the given IP core is the rightful owner.description) of IP core corresponding to ith HLS tool which fully matches the feature set of the given IP core is the rightful owner.

• Procuring the RTL HDL of given IP core is practical because the given IP core can be obtained from any of the claimants(competing IP vendors), as they all claim ownership of the same IP core (and have copies of the same IP core. Except the originalvendor, all others have stolen/counterfeit copies, but we don’t know who produced the original version). The ith HLS tool vendorwhose IP feature set fully matches with the given IP core is the rightful owner of the given IP corewhose IP feature set fully matches with the given IP core, is the rightful owner of the given IP core.

•The proposed approach does not require access to source codes, package information etc. of the HLS tools of the ‘n’ claiming IPvendors. This indicates that only the executable version of the HLS tools is required from the competing vendors. The CFE approachdoes not require any secret in-house information, internal algorithm etc.

•The executable version of each HLS tool would be run to generate RTL description files of an IP core as output, which in turn will beused to extract the relevant feature information for analysis without accessing the tool source code at all.

• In case any claimant IP vendor is un-willing to share its HLS tool (or its respectively generated RTL description) during CFE analysisy g ( p y g p ) g y(which is typically performed in labs as a legal exercise) then that specific claimant IP vendor is considered disqualified.

• This is because any genuine IP vendor will provide at-least its executable HLS tool for running and generating a sample IP RTLdesign through it such that necessary features can be extracted for ownership validation.

CFE V W t k f IP C t ti f CE h dCFE Vs. Watermark for IP Core protection of CE hardware

IP protection Technique of Overhead Quality of Nature of Complexity Security Possibility of Time mechanism protection the design protection threat complexity

IP Watermarking

Inserts authors signature by

imposing constraints

Hardware overhead may exist resulting

from

Degradation in quality or performance may occur, if

not taken

Nullifying/ resolving

false claim of

ownership

More complex as it involves two layered data security viz. signature

di d

More secured when two

layered data security is

provided with l

Higher due to existence of

reverse engineering

step in i

Faster than other IP

protection mechanism

storage registers

care encoding and encryption

complex signature

signature detection

CFE Identifies the source of the

IP creator

No overhead

No degradation

in quality can occur as no i t /ID

For identifying IP creator

Equally complex as

watermarking as it involves 3

t

Equally fail-proof as

watermarking in identifying

IP t

Threat due to reverse

engineering does not exist

Time consuming as it

involves feature/statistics

ll tisignature/ID is inserted

stage process. IP creator collection, feature

extraction, clustering and

validation

Anirban Sengupta "Protection of IP-Core Designs for CE Products", IEEE Consumer Electronics, Vol 5, pp. 83- 89, Dec 2015

Feature 1 : Scheduling Algorithmg g

ASAP: both rule a & b conditions should satisfy

Check for scheduling algorithm

ALAP: both rule a & b conditions should satisfysimultaneously

a) All Functional Units (FUs) of independent operations are activated in first control Step (first

clock cycle)b) All dependent operations and its successors should be placed in consecutive control steps

ALAP: both rule a & b conditions should satisfy simultaneously

a) All Functional Units having Primary Outputs should be activated in last control step

b) All parent operations and its predecessors should be placed in consecutive control steps based on their

dependencies.

LIST: Rule a or b must satisfy simultaneouslywith either c or d for scheduling to be identifiedas list algorithm:a) All functional units of independent operationsshould not be activated in the first control step.b) All dependent operations and its successors

based on their dependencies.dependencies. ) p p

should not be placed in consecutive control stepbased on their dependencies.c) All functional units having primary outputsshould not be activated in last control step.d) All parent operations and its predecessorsshould be placed in consecutive control steps.

ASAP scheduling ALAP scheduling

p p

ASAP/ALAP/LIST

LIST scheduling

Flow graph representing the feature extraction methodology for scheduling algorithm featureFlow graph representing the feature extraction methodology for scheduling algorithm feature


Feature 2 : Resource Feature 3 : Bus Width Configuration type Support

t S bt tcomponent Subtractorport ( enable_R1 : in std_logic;

Data_out7 : in std_logic_vector (3 downto 0); Data_out8 : in std_logic_vector (3 downto 0); Data_in9 : out std_logic_vector (3 downto 0));

end component;

component registerTpport ( tp : in std_logic_vector (7 downto 0);

regtp: out std_logic_vector (7 downto 0); strobe: in std_logic);

end component;end component;


Feature 4 : Multi-cyclingg

M1

Control Steps

1

2

3

4

*

38

:

:

40

39

CS-E(FUi) > CSS(FUi)


Feature 5 : Chainingg

A1

A1

M1+

+

Control Steps

1

2

Algorithm (Input: controller VHDL of IP: Output: detection of chaining)

for ( i=1 to n){

for ( j=1 to n && j != i )

*

3

4

:

{if (CSS(FUi) <= CSS(FUj) && CSE(FUi) => CSE(FUj))

{ if ( CSE(FUi) – CSS(FUi) => (CSE(FUj) – CSS(FUj))1 + ( CSE(FUj) –

CSS(FUj))2 + …. + (CSE(FUj) – CSS(FUj))m

39

38

:

S( j))2 ( E( j) S( j))m

){

Chaining feature detected in IP core!}

}40

}}

}

‘n’ indicates the number of functional units present in IP core thus the algorithm repeats the process for each functional unit present in the IP. (CSE(FU) –( ) f f f ( ) ( ) f ‘ ’


CSS(FU) denotes the delay of a functional unit. The values of CSS(FU) and CSE(FU) for ‘IPID and IPv n’ can be obtained by reading the starting CS and ending CSof respective functional units in controller HDL code of each IP core.

Feature 5 : Chaining

CS <= CS +1;end if;

---------------------------------CONTROL STEP 1---------------------------if CS=1 then

if count=first_countADD_EN_1<='1';MUL_EN_1<='1'; //start of multiplication

operation//count <= count+1;

end if;g

entity control_unit is port( clock, reset: in std_logic; : : : ADD_EN_1, ADD_EN_2, MUL_EN_1 : out std_logic;

REG Y t td l i

end if;::If count = last_countADD_EN_1 <= '0';count <= '0';end if;CS <= CS+1;

end if;---------------------------------CONTROL STEP 2---------------------------if CS=2 then

if count= first_countADD EN 1<='1';

Algorithm (Input: controller VHDL of IP: Output: detection of chaining)

for ( i=1 to n){

REG_Y : out std_logic; : : : ); end control_unit;

architecture Behavioral of control_unit is signal CS: INTEGER RANGE 0 TO 19;

ADD_EN_1<= 1 ;count <= count+1;

end if;:::If count = last_countADD_EN_1 <= '0';count <= '0';end if;CS <= CS+1;

end if;

for ( j=1 to n && j != i ){if (CSS(FUi) <= CSS(FUj) && CSE(FUi) => CSE(FUj))

{ if ( CSE(FUi) – CSS(FUi) => (CSE(FUj) – CSS(FUj))1 + ( CSE(FUj) – g

signal count: INTEGER RANGE 0 TO 10; signal busy : std_logic; begin process(clock,reset) begin

if (clock'event and clock='1') then if(reset='0')then if CS =0 then

clk<='1';

:::---------------------------------CONTROL STEP 40--------------------------if CS=40 then

if count= first_countcount <= count+1; REG_IP_A_EN <='0';REG_IP_B_EN <='0';REG_IP_C_EN <='0';REG IP D EN <='0';

E i S i E j S j 1 E jCSS(FUj))2 + …. + (CSE(FUj) – CSS(FUj))m

){

Chaining feature detected in IP core!} ;

REG_IP_A_EN <='1'; REG_IP_B_EN <='1'; REG_IP_C_EN <='1'; REG_IP_D_EN <='1';

REG_IP_E_EN <='1';

Fig. a Portion of a HDL code

REG_IP_D_EN <= 0 ;REG_IP_E_EN <='0';

end if;:::If count = last_countMUL_EN_1 <= '0'; //end of multiplication

operation//REG_IP_A_EN <='1';REG_IP_B_EN <='1';REG_IP_C_EN <='1';

‘ ’ i di t th b f f ti l it t i IP th th lg ith t th f

}}

}}

REG_IP_D_EN <='1';REG_IP_E_EN <='1';count <= '0';end if;CS <= CS+1;

end if;..…..

‘n’ indicates the number of functional units present in IP core thus the algorithm repeats the process foreach functional unit present in the IP. (CSE(FU) – CSS(FU)) denotes the delay of a functional unit. Thevalues of CSS(FU) and CSE(FU) for ‘IPID and IPCT n’ can be obtained by reading the starting CS and endingCS of respective functional units in controller HDL code of each IP core

Feature 6 : Data pipelining E g IP core Design solution: 2 Adders and 1 Multiplierg

A1 M1+

Control Steps

1

E.g. IP core Design solution: 2 Adders and 1 Multiplier1st data set

A1 +

*2

:

:2nd data setDelay = 41 CS

+

42

41

40

A2

A1

M1+

+

A1

1st o/p

:

:*

80

Delay = 40 CS

81+A1

2nd o/p

(CSE(N)1 - CSS(N)1) > (CSE(N)2 – CSE(N)1)

Feature 6 : Data-Pipelining• assume CSS(N)1 indicate the starting control step

of data set 1, CSE(N)1 and CSE(N)2 indicates theend control step of data set 1 and 2 respectively.The starting and ending control step number canbe determined using the controller HDL code of

-----------------------------CONTROL STEP 42---------------------------if CS=42 then

if count= first_count

REG_Y <='1';//output of data set 1 available//

count <= count+1;

end if;CS <= CS+1;end if;

---------------------------------CONTROL STEP 82---------------------------if CS=82 then


REG_Y <='1';//output of dataset 2 available// gIP core.

• the data set 1 has output available in register Y atcontrol step 42 and data set 2 has outputavailable at control step 82. Thus, CSE(N)1 = 42 andCS (N) 8 M th d t t b i it

ADD_EN_1 <= '1';end if;

:::If count = last_count

ADD_EN_1 <= '0';

count <= '0';end if;

count <= count+1;

ADD_EN_1 <= '1';end if;

:::

If count = last count CSE(N)2 = 82. Moreover, the data set 1 begins itsoperation at CSS(N)1 = 1. Thus the condition belowsatisfies indicating presence of data pipelining

CS<=CS+1;end if;

-----------------------------CONTROL STEP 80---------------------------if CS=80 then


count <= count+1;

REG_IP_A_EN <='0';

_

ADD_EN_1 <= '0';

count <= '0';end if;

CS<=CS+1;end if;

(CSE(N) - CSS(N) ) > (CSE(N)2 – CSE(N) )REG_IP_B_EN <='0';

REG_IP_C_EN <='0';

REG_IP_D_EN <='0';

REG_IP_E_EN <='0';end if;

:::If count = last count

::-----------------------CONTROL STEP 4001(for 100 data set) ---------if (clock'event and clock='1') then

elsif (reset='1')then

count<=0;end if;

end if;end if;

(CSE(N)1 CSS(N)1) > (CSE(N)2 CSE(N)1)

If count last_count

MUL_EN_1 <= '0';

CS<=CS+1;end if;

-----------------------------CONTROL STEP 81---------------------------

Fig. Portion of a HDL code

--end if;end process; --count1 <=count;end Behavioral;

Fig. Portion of a HDL code

Feature 7 : Reliability

Control Steps

Original Unit

Duplicate unit

A1

A1

M1+

+

*

1

2

:

A2

A2

M2+

+

*

This is done by checking the top levelentity HDL code of IP core for DMRconcept. In case DMR is implemented,then the top level entity datapath HDLcode comprises of a comparator

+A1

:

41

40

+A2

component that uses output registersignal 1 (from original unit) and outputregister signal 2 (from duplicate unit) asinputs and comparator output signal asfinal output during port mapping.

42<C1

The following port mapping is visible in the HDL code:The following port mapping is visible in the HDL code: port map (output register signal 1, output register signal 2, comparator output signal);If such a scenario is extracted, then reliability feature is detected.


Feature 8 : Trojan security

Control Steps

Vendor 1 Vendor 2

A1

A1

M1+

+

*

Control Steps

1

2

:

A1

A1

M1+

+

*

This is done by checking the top levelentity HDL code of IP core for DMRconcept. In case DMR is implemented,then the top level entity datapath HDL

+A1

:

:

41

40

+A1

code comprises of a comparatorcomponent that uses output registersignal 1 (from original unit of V1) andoutput register signal 2 (from duplicateunit of V2) as inputs and comparatoroutput signal as final output during port+ 41

42

+C1 <

• The following port mapping is visible in the HDL code:

output signal as final output during portmapping.

The following port mapping is visible in the HDL code: port map (output register signal 1, output register signal 2, comparator output signal);

• Additionally, the input module library is checked to see if there are design parameters (area, delay, power etc.) defined corresponding to modules from two distinct vendors.

IP V lid tiIP core Validation


Experimental ResultsBenchmark: JPEG_IDCT (112 nodes)

IP features Schedule algorithm

Resource type chaining Bus width

supportData

pipeline

Multi-cycling Design objective Reliability Loop

supportTrojan

SecurityMatch

percent

Area - Execution IPID LIST A, M Yes 8 bit Yes Yes time / Power-

Execution timeNo DFG No NA

IPCT 1(Hybrid PSO-GA HLS

(Ram, 2011))LIST A, M Yes 16 bit No Yes Area-Power-

Latency No DFG No 70

IPCT 2[Fault secure HLS LIST A, M, C No 16 bit No Yes

Area - Execution time / Power- Yes DFG No 50[

[(Sengupta, 2015)), , /

Execution time5

IPCT 3(Watermark-HLS

(Koushanfar, 2005))LIST A, M, C, S No 32 bit No No

Area - Execution time / Power-

Execution timeNo DFG No 50

IPCT 4(Trojan Secure-HLS(Rajendran 2013))

LIST A, M, C, S No 16 bit No NoArea - Execution

time / Power-Execution time

No DFG Yes 40(Rajendran, 2013)) Execution time

IPCT 5(BFOA-HLS (Bhadauria,

2015))LIST A, M Yes 32 bit No Yes



IPCT 6(Fault Tolerant-HLS

(Inoue, 2011))LIST A, M, C, S No 16 bit No No Area - Latency Yes DFG No 30

IPCT 7(PSO-HLS

(Mishra, 2014)LIST A, M Yes 8 bit Yes Yes




Experimental Results

Benchmark: DCT (42 nodes)

IP features Schedulealgorithm

Resource type chaining Bus width

supportData

pipelineMulti-

cycling Design objective Fault Reliability

Loop support

Trojan Security

Match percent

Area - Execution IPID LIST A, M Yes 32 bit No Yes time / Power-

Execution timeNo DFG No NA

IPCT 1(Hybrid PSO-GA HLS

(Ram, 2011))LIST A, M Yes 16 bit No Yes Area-Power-Latency No DFG No 80

IPCT 2[Fault secure HLS LIST A M C No 16 bit No Yes

Area - Execution time / Power- Yes DFG No 60[Fault secure HLS

[(Sengupta, 2015))LIST A, M, C No 16 bit No Yes time / Power

Execution timeYes DFG No 60

IPCT 3(Watermark-HLS

(Koushanfar, 2005))LIST A, M, C, S No 32 bit No No



IPCT 4(Trojan Secure-HLS LIST A M C S No 16 bit No No

Area - Execution time / Power- No DFG Yes 50(Trojan Secure-HLS

(Rajendran, 2013))LIST A, M, C, S No 16 bit No No time / Power

Execution timeNo DFG Yes 50

IPCT 5(BFOA-HLS (Bhadauria,

2015))LIST A, M Yes 32 bit No Yes



IPCT 6(Fault Tolerant-HLS

(Inoue 2011))LIST A, M, C, S No 16 bit No No Area - Latency Yes DFG No 40

(Inoue, 2011))IPCT 7

(PSO-HLS(Mishra, 2014)

LIST A, M Yes 8 bit Yes YesArea - Execution

time / Power-Execution time

No DFG No 80



ki i d b dBenchmark

Watermarking IP protection HLS approach

Proposed CFE based IP protection HLS approach

Storage registers Storage registers

ARF 11 0ARF 11 0

BPF 11 0

DCT 11 0

FFT 10 0

FIR 11 0

JPEG_IDCT 25 0

A. Sengupta et. al "Forensic Engineering for Resolving Ownership Problem of Reusable IP Core generated during High Level Synthesis", Elsevier Journal on Future Generation Computer Systems, Aug 2018

References1. D. S. Harish Ram, M. C. Bhuvaneswari, and S. M. Logesh, (2011) “A novel evolutionary technique for multi-objective power, area

and delay optimization in high level synthesis of datapaths,” in Proceedings of the IEEE Computer Society Annual Symposiumon VLSI (ISVLSI ’11), pp. 290–295.

2. Sengupta, Anirban, and Reza Sedaghat (2015) "Swarm intelligence driven design space exploration of optimal k-cycle transientg p , , g ( ) g g p p p yfault secured datapath during high level synthesis based on user power–delay budget." Elsevier Journal on MicroelectronicsReliability, Vol 55, Issue 6, pp. 990-1004.

3. Koushanfar F, I. Hong, and M. Potkonjak (2005) ‘‘Behavioral synthesis techniques for intellectual property protection,’’ ACMTransactions on Design Automation of Electronic Systems, vol. 10, no. 3, pp. 523–545

4. J. Rajendran, H. Zhang, O. Sinanoglu and R. Karri (2013) "High-level synthesis for security and trust," IEEE 19th InternationalOn-Line Testing Symposium (IOLTS), pp. 232-233.

5. Anirban Sengupta, Saumya Bhadauria (2015) “Adaptive Bacterial Foraging Driven Datapath Optimization: Exploring Power-Performance Tradeoff in High Level Synthesis”, Elsevier Journal on Applied Mathematics & Computation, Vol. 269, pp. 265 –278278.

6. T. Inoue, H. Henmi, Y. Yoshikawa and H. Ichihara (2011) "High-level synthesis for multi-cycle transient fault tolerantdatapaths." 2011, IEEE 17th International On-Line Testing Symposium, pp. 13 – 18

7. Vipul Kumar Mishra, Anirban Sengupta (2014) “MO-PSE: Adaptive multi-objective particle swarm optimization based designspace exploration in architectural synthesis for application specific processor design”, Elsevier Journal on Advances inspace exploration in architectural synthesis for application specific processor design , Elsevier Journal on Advances inEngineering Software, Volume 67, pp. 111-124.

8. https://hub.91mobiles.com/phone-launches-india-20169. https://www.themobileindian.com/news/year-end-roundup-271-mobiles-tablets-launched-in-india-in-2012-6878

Some of my key Journal Contributions in CE Device - Hardware Security/IP Protection1. A. Sengupta et. al “Triple-Phase Watermarking for Reusable IP Core Protection during Architecture Synthesis", IEEE Transactions on Computer Aided Design of1. A. Sengupta et. al Triple Phase Watermarking for Reusable IP Core Protection during Architecture Synthesis , IEEE Transactions on Computer Aided Design of

Integrated Circuits & Systems (TCAD), 20172. A. Sengupta et. al "Securing IoT Hardware: Threat models and Reliable, Low-power Design Solutions", IEEE Transactions on Very Large Scale Integration (VLSI)

Systems, 20173. A. Sengupta et. al "TL-HLS: Methodology for Low Cost Hardware Trojan Security Aware Scheduling with Optimal Loop Unrolling Factor during High Level Synthesis",

IEEE Transactions on Computer Aided Design of Integrated Circuits & Systems (TCAD), 20164 A Sengupta et al "Exploring Low Cost Optimal Watermark for Reusable IP Cores during High Level Synthesis" IEEE Access Journal 20164. A. Sengupta et. al Exploring Low Cost Optimal Watermark for Reusable IP Cores during High Level Synthesis , IEEE Access Journal, 20165. A. Sengupta et. al "Protecting an Intellectual Property Core during Architectural Synthesis using High-Level Transformation Based Obfuscation", IET Electronics

Letters, 20176. A. Sengupta et. al "IP core Protection of CDFGs using Robust Watermarking during Behavioral Synthesis Based on User Resource Constraint and Loop Unrolling

Factor", IET Electronics Letters, 20167. A. Sengupta et. al "Low Cost Security Aware High Level Synthesis Methodology", IET Journal on Computers & Digital Techniques (CDT), 20168 A S l "P i f IP C D i f CE P d " IEEE C El i M i 20158. A. Sengupta et. al "Protection of IP-Core Designs for CE Products", IEEE Consumer Electronics Magazine, 20159. A. Sengupta et. al "Hardware Vulnerabilities and its Effect on CE Devices: Design-for-Security against Trojan", IEEE Consumer Electronics Magazine, 201710. A. Sengupta et. al "Anti-Piracy aware IP Chipset Design for CE Devices: Robust Watermarking Approach", IEEE Consumer Electronics Magazine, 2017.11. A. Sengupta et. al "Hardware Security of CE Devices: Threat Models and Defence against IP Trojans and IP Piracy", IEEE Consumer Electronics Magazine, 201712. A. Sengupta et. al "Forensic Engineering for Resolving Ownership Problem of Reusable IP Core generated during High Level Synthesis", Elsevier Journal on Future

Generation Computer Systems, 201813. A. Sengupta et. al "Low Overhead Symmetrical Protection of Reusable IP Core using Robust Fingerprinting and Watermarking during High Level Synthesis", Elsevier

Journal on Future Generation Computer Systems, 201714. A. Sengupta et. al "Automated Low Cost Scheduling Driven Watermarking Methodology for Modern CAD High-Level Synthesis Tools" Elsevier Journal of Advances in

Engineering Software, 201715. A. Sengupta et. al Low cost optimized Trojan secured schedule at behavioral level for single & Nested loop control data flow graphs, Elsevier VLSI Integration, 201616. A. Sengupta et. al "Security and Reliability Aware System Design for Mobile Computing Systems", IEEE Access Journal, 2016g p y y y g p g y , ,

THANK YOU!

Anti-Piracy aware IP Chipset Design forCEDevicesctsoc.ieee.org/images/files/pdf/DL2.pdf ·...

Documents

Transcript of Anti-Piracy aware IP Chipset Design forCEDevicesctsoc.ieee.org/images/files/pdf/DL2.pdf ·...