This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics

Embedding Digital Signature using Encrypted-

Hashing for Protection of DSP cores in CE
Anirban Sengupta, Senior Member, IEEE, E. Ranjith Kumar, and N. Prajwal Chandra

device is a processor in the form of system-on-chip (SoC).

1
Abstract—Reusable Intellectual Property (IP) cores from signal
processing and multimedia form an integral part of Consumer
Electronics (CE) systems. However, owing to the value it
represents, it needs protection against important threats such as
piracy and illegal claim of ownership. This paper presents a novel
multi-level encoding and encrypted-hash based digital signature
for protection of complex reusable IP core used in CE Systems.
For the first time in the literature, a digital signature based IP
core protection is proposed for digital signal processing (DSP)
kernels. The proposed methodology is capable of encoding a DSP
kernel application, followed by creating a digest of the encoded
application to finally form a digital signature using RSA, which is
subsequently implanted into the same design during architectural
synthesis. The proposed approach on DSP benchmarks is capable
of achieving higher robustness in terms of lower probability of
coincidence - indicating stronger proof of authorship. The
proposed approach achieves stronger robustness (on average by
~24.8%) as well as requires lesser storage hardware (on average
reduction of ~14%) compared to similar prior work.
Index Terms—DSP core, Digital Signature,
Protection, Encryption, Hashing
I. INTRODUCTION
C ONSUMER electronics have now become ubiquitous in
human life. CE devices play crucial roles in everyday
tasks including entertainment, communications, and home-
office activities. Owing to the heavy dependency on CE
devices, domain of protection of its intellectual property (IP)
cores (especially the ones from digital signal processing (DSP)
and multimedia) has emerged as an important subject of
research. In the domain of consumer electronics, reusable IP
cores have become a practical solution to the design
challenges of higher complexity and surging time to market
pressure. Consequently, current design era of CE devices is
hugely reliant on global IP supply chains. At the heart of a CE
1
This work has been submitted on Jan 15, 2019. This Publication is an
outcome of the R&D work undertaken in the project under the Visvesvaraya
PhD Scheme of Ministry of Electronics & Information Technology,
Government of India, being implemented by Digital India Corporation
(formerly Media Lab Asia) and CSIR grant no. 22/730/17/EMR-II.
A. Sengupta is with the Discipline of Computer Science and Engineering,
Indian Institute of Technology Indore, 453552, India (e-mail:
asengupt@iiti.ac.in).
E. R. Kumar is with the Discipline of Computer Science and Engineering,
Indian Institute of Technology Indore, 453552, India (e-mail:
cse150001011@iiti.ac.in).
N. P. Chandra is with the Discipline of Computer Science and Engineering,
Indian Institute of Technology Indore, 453552, India (e-mail:
cse150001019@iiti.ac.in).
Global supply chain for CE SoC design is vulnerable to
security threats such as IP piracy, counterfeit and forgery [1].
A thematic representation of a IP core protection for CE
devices is shown in Fig. 1.
Impending security threats posed to the IP core of CE
devices include piracy or counterfeiting, false claim of
ownership, reverse engineering, and hardware Trojan insertion
[2]. Different solutions have been proposed [3]-[14] as
countermeasures to the aforementioned threat scenarios. To
protect against infringements such as IP piracy/counterfeiting
and false claims of ownership, vendor watermark is embedded
in the design of IP core [3]-[8]. More explicitly, false claim of
ownership is invalidated by embedding robust watermarks
during the design process of IP core in Koushanfar et al. [3]
and Sengupta and Bhadauria [4]. Further, Alkabani et al. [5]
presented a remote activation scheme for IP protection. A
symmetric IP core protection method is proposed in Roy and
Synthesis, Sengupta [6] where a buyer fingerprint and seller watermark
are simultaneously embedded in the design of an IP core.
Alkabani and Koushanfar [7] introduced an approach that
enables active control of multiple IP cores remotely by the
owner. Marvel [8] employed an information hiding technique
through watermarking and steganography. To protect the IP
cores against Trojan insertions, Zhang et al. [2] and Xue et al.
[9] used Physical Unclonable Functions (PUF).
II. CONTRIBUTIONS OF THIS PAPER TO STATE OF THE ART
A. Novel Contributions of the Paper
The novel contributions of this paper are as follows:
1) Proposes a multi-level encoding encrypted-hash-based
Vendor design houses
Threats
IP 1 IP 2 IP 3
IP cores with owner signature implanted
to protect against threats
Consumer Electronic System on chip integrated
devices with third party IPs
Fig. 1. Signature based IP core protection mechanism for CE devices

0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics

digital signature for protecting the reusable IP cores of literature on IP core protection of complex DSP kernels used
digital signal processing and multimedia kernels. in CE systems. In some of the works such as Koushanfar et al.
2) Proposes a novel methodology for encoding DSP kernel [3], Sengupta and Bhadauria [4] watermark is embedded in the
application, followed by creating a digest of the encoded design during high level synthesis. Koushanfar et al. [3] used
application to finally form a digital signature using RSA. binary encoding of bits to implant constraints in the colored
interval graph, while Sengupta and Bhadauria [4] used multi
B. Importance for CE systems and consumers
variable encoding to implant constraints in the colored interval
Importance to CE systems: The proposed approach is capable graph. However, both approaches incur significant design
to protect IP cores for dedicated DSP blocks such as digital overhead due to nature of encoding as well as do not provide a
filters (FIR, IIR etc.), Discrete Cosine Transformation (DCT), strong proof of ownership. Further, both these approaches are
Haar Wavelet Transformation (HWT), Fast Fourier hugely dependent on the chosen signature combination for
Transformation (FFT), JPEG against IP piracy and achieving robustness and lower design hardware
counterfeiting. These DSP cores are used extensively in CE cost/overhead. Further, the security of these approaches is
systems, for example, FIR filters used in audio devices, high intact as long as the signature and encoding is unknown. Once
definition TV, headsets etc., IIR filters used in audio both are compromised, the vendor cannot prove his
processors for equalization of speakers, HWT used in lossless ownership. Moreover, in case of normal signature schemes
image compression of camera systems, DCT used in lossy used in Koushanfar et al. [3] and Sengupta and Bhadauria [4],
compression of audio, image and video files, FFT used in the vendor has to remember the signature for future reference.
digital video broadcasting (DVM) etc., low pass filter, FFT In case the vendor forgets his/her signature, authenticity
used as anti-aliasing filter in spectrum analyser and JPEG cannot be proved. Additionally, Nie et al. [10] implanted
compression/decompression (CODEC) process used in image watermark at lower abstraction level (gate/netlist or register
and video compression of camera systems. Similarly, there are transfer), which is complex for DSP based IP cores. Moreover,
extensive applications of DSP cores in CE systems. The the design overhead may be higher. Obfuscation is another
proposed approach can significantly bolster the protection of class in the domain of IP protection which protects the IP
such IP cores against piracy through robust detection. designs from reverse engineering attacks [11]-[13], [19]-[24].
Detection of counterfeited and pirated CE products is These structural obfuscation techniques are responsible for
important from the point of view of consumer safety, structurally camouflaging the design architecture of DSP cores
protecting IP/brand value, returning revenue and resolving [14]. By preventing the attacker to identify the structure and
traffic bleed. Consumers who are likely to buy a fake CE functionality of the DSP core, obfuscation thwarts reverse
product are unaware that these fakes are not put through the engineering of DSP designs. However, obfuscation is not
same rigorous health, safety, and quality checks as their capable of authenticating a genuine IP core owner or provides
legitimate counterparts. detective control of fake IP cores, unlike proposed approach.
Benefits to Consumers: The proposed approach is a forensic
detective control against counterfeit IP cores i.e. it can detect a III. PROPOSED APPROACH
fake (or cloned) IP core designed by an adversary, thus A. Problem Formulation
curbing the flow of cloned IP cores in the consumer market. Input/Output: Inputs: (a) data flow graph (DFG) of a DSP
The proposed approach embeds a robust digital signature core and (b) user specified hardware resources set (X) =
generated through a combination of encoding algorithms, N(R1), N(R2), N(RD), where N(RD) is the number of hardware
secure hashing and RSA encryption to authenticate a genuine resources type RD; Output: Watermarked IP core design.
IP maker. Fraud IP makers with cloned IP cores would fail to
authenticate themselves, thus detecting pirated IPs and INPUTS
blocking further flow of cloned IP cores into the market.
Several studies [17], [18] in the past have revealed that a Resource configuration Scheduled
Pre-processing Encoding
cloned (counterfeited) IP core is dangerous to the end Block 1 DSP block 1
DFG of the DSP core
consumer as it may not undergo the rigorous testing needed to Bitstream
ensure their integrity, thus threatening the safety and reliability representation
of device in which they are integrated. Additionally, Decimal value Post-processing Bitstream
RSA SHA-512
of n-bit blocks Block 1 digest of
adversaries or counterfeiters usually tamper with a pirated IP
Encrypted decimal DSP core
core which superficially may look fine, but can behave
value of each block
erratically and unreliably under certain conditions. Other Digital signature
tampered IP cores may be able to send information back to the Post-processing Encrypted Encoding constraints
Block 2 bitstream block 2
adversary, thus risking the secrecy and safety of a consumer.
The proposed approach combats against such problems using Signature
OUTPUT Watermarked DSP
detective control based on robust digital signature IP cores. embedding block

C. Prior Similar Approaches Fig. 2. Overview of proposed digital signature embedding approach
There is few hardware watermarking approaches in the

0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics

B. Overview of Proposed Security Modules for Watermarking
The diagrammatic representation of the overview of the
proposed approach is shown in Fig.2. In this sub-section, the
inputs/outputs and the functionality of individual blocks of
Fig.2 are described. Each of SHA-512 block, RSA encryption
block and two encoding blocks serve as security modules in
the presented watermarking approach. To begin with, the
inputs to the pre-processing block 1also the primary inputs
to the proposed algorithmare: DFG of the DSP core in which
the digital signature is to be embedded and user-specified
resource configuration. In this pre-processing block, the DFG
is scheduled according to the given resource configuration
using a scheduling algorithm. Now, the scheduled DFG serves
as input to the next block, i.e., encoding block 1. The
scheduling information is extracted and converted into
bitstream using an encoding rule in this block. Further, the
bitstream is passed as an input to the SHA-512 module in
order to generate a bitstream digest of the DSP core. Before
encrypting the output bitstream in the RSA module, it is
processed in the post-processing block 1 to make it compatible
with the input type required for RSA algorithm. Subsequently
the decimal output values from the preceding step are
encrypted using vendor selected RSA private (secret) key. In
post-processing block 2, the bitstream of the equivalent
encrypted decimal outputs of RSA block is constructed. This
encrypted-hashed bitstream generated through proposed
approach is termed as ‘digital signature’. Note: In case of
digital signature generation process for standard digital
certification applications private key is used in RSA
encryption instead of public key. To embed this digital
signature in the form of design constraints, each bit of the
INPUTS
Resource
configuration
Scheduled
Construct SDFG and
assign storage variables
DFG of the DSP
application
Pre-processing block 1
bitstream is encoded, based on the devised encoding scheme
of encoding block 2. Finally, the digital signature constraints
are implanted into the register allocation step (using creation
of coloured interval graph (CIG)) of high level synthesis in
signature embedding block to obtain the watermarked DSP
core as the primary output.
C. Advantages of the Proposed Digital Signature as
Watermark for IP Core Protection
1) Proposed digital signature eliminates dependency on
different signature combinations, as digital signature always
produces unique hashed encrypted bitstream (representing
watermarking constraints). Typically, even a same size
signature can have innumerable combinations possible,
which has different implications on security and design
overhead. It is very hard to estimate which signature
combination would result into lower overhead as well as
higher security.
2) In case the signature and encoding becomes leaked
(compromised), the vendor can still prove his/her ownership
mathematically as the design carries digital signature that is
created through his/her private key RSA encryption. Thus
during ownership resolution, signature implanted using
proposed ‘RSA private key encryption’ provides an added
mathematical basis for the vendor to establish ownership in
a more meaningful way, than arbitrarily chosen signatures.
D. Proposed Security Modules for Digital Signature
The diagrammatic illustration of the details of the proposed
approach is shown in Fig. 3.
Rule: If OPN and CS are of same
parity, then bit = ‘0’, else ‘1’
Bitstream representation
of DSP core
Generate a rule based
DSP bitstream
Encoding block 1

Perform SHA-512
1. Bitstream Pre-processing.
Convert each binary data Divide the bitstream digest Bitstream digest of 2. W values computation.
block into decimal value into blocks of desired size DSP application 3. Initialize 512-bit hash buffer.
4. Perform Round function.
5. Compute bitstream digest.
Post-processing block 1

Encoding block 2
Rule: If bit is ‘0’, extra edge added between <prime, prime>
node pair, else between <even, even> node pair.

Encrypt each decimal Encrypted Construct bitstream from Encrypted Encode bit value of encrypted bitstream based on the
value using RSA decimal values encrypted decimal values bitstream rule

Post-processing block 2 Digital signature constraints

RSA private OUTPUT
key
Embed the digital signature in the
Watermarked DSP
register allocation phase

Fig. 3. Details of the proposed digital signature embedding approach

0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics
D.1 Generating Bitstream Representation of the DSP Core
First, the given DFG is scheduled according to the input
resource configuration using LIST scheduling algorithm.
Through this each operation in the DFG is assigned a time
stamp value, i.e., the control step in which each operation is to
be performed. Subsequently, a binary stream (of ‘0’ and
‘1’bits) is generated in the first encoding block. Bitstream is
generated from the operation scheduling, based on the
following encoding rule:
 Bit = ‘0’, if operation number (OPN) and the control step
number (CS) assigned to that operation are of same parity.
 Bit = ‘1’, if operation number and the control step number
assigned to that operation are of different parity.
Further, storage variables are assigned to the scheduled DFG
at the intermediate inputs and outputs, that will be used later to
create coloured interval graph (explained later in the paper).
D.2 Performing SHA-512 and Processing the Output
The bitstream representation of the DSP core generated in
the preceding step is passed as an input to the SHA-512
module. Well known properties of SHA-512 that contribute to
security are high collision resistance and uniformity. Collision
resistance enables proposed approach in preventing two
bitstream inputs having same bitstream digest rendering it
challenging for adversary to gain knowledge of bitstream from
the digest. Further, the main hash computation in SHA-512
involves executing a function called ‘Round function’ for 80
iterations. Complex repetition of the aforesaid round function
produces results that are well distributed; that is, it is highly
unlikely that two different bitstreams will have the same digest
value even if they exhibit similar regularities.
First, the bitstream is appended with padding bits and
bitstream length, such that the bitstream size becomes a
multiple of 1024. Next, ‘word computation function (W)’
values are evaluated from the updated bitstream. Further, a
512-bit bufferused to store hash valuesrepresented as
eight working variables is initialized with predefined values
(the exact values are reported in motivational example –
section IV). In the penultimate step, main hash computation is
performed in which round function is executed for 80
iterations. Thereafter, the output of the 80 th iteration of round
function is added to the input of the first iteration to eventually
produce the hashed bitstream digest. The post-processing
block 1 consists of two sub-blocks. In the first sub-block, the
bitstream digest is divided into blocks of size chosen by the
vendor (for example 128 bits or higher). Sub-block 2 converts
these data blocks into equivalent decimal values.
D.3 RSA Encryption and Digital Signature Creation
First step of the RSA module is generating a private key,
according to IP vendor’s choice. Thereafter, each decimal
value input to the RSA block is encrypted with the
aforementioned vendor private key using: ‘C = Md mod n’,
where ‘C’ = cipher-data, M = input data, d= vendor private
key, n = p * q, and p and q both prime, p ≠ q. Only the vendor
has the knowledge of private key used for encryption. The
encrypted decimal values are provided as input to the post-
0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
processing block 2. Subsequently, an encrypted bitstream is
constructed by converting each input decimal value into
binary, followed by concatenation. This encrypted-hashed
bitstream known as ‘digital signature’ generated through
proposed approach, is used for implanting as watermark. The
vendor selects the respective digital signature size from this
bitstream based on the robustness required and the design cost
trade-off. This information on the strength (number of bits
used) of the digital signature is only known to a genuine IP
vendor. Even if an attacker somehow knows the entire digital
signature, however he has no knowledge on the strength of the
digital signature that will be used for watermark subsequently.
Further, once the strength has been decided by the vendor, it is
passed through proposed encoding block 2 (explained in next
sub-section) that converts selected digital signature strength
into respective artificial constraints representing watermark.
Additionally, only the genuine IP vendor has knowledge about
this encoding algorithm. This indicates that an attacker would
also need to know the encoding algorithm (besides knowing
the entire digital signature, which is challenging as it requires
knowledge of complete hash/digest of the design representing
encryption inputs, and also encrypted output bytes) to implant
watermark into the design. The above process thus secures
against reputation/trust attack on a genuine vendor (where an
attacker observes encryption of genuine vendor ‘A’, signs
design of competitor ‘B’ using A’s encryption and then
announces ‘A’ has illegally implanted his signature on ‘B’).
This is because attacker and ‘B’ are required to know the exact
digital signature strength representing watermark and the
subsequent encoding algorithm that converts it into artificial
constraints for design embedding. Thus ‘A’ is capable of
thwarting any potential reputation and trust attack.
D.4 Encoding the Digital Signature in Proposed Approach
Having created the digital signature, the next important step
of watermarking approach is to embed the digital signature
into the design (using encoding block 2 of Fig. 3). The
proposed encoding scheme is applied:
 If bit = ‘0’, then additional edge is added between node
pair (prime, prime) in a colored interval graph.
 If bit = ‘1’, then additional edge is added between node
pair (even, even) in a colored interval graph.
D.5 Embedding the Digital Signature
Here the digital signature is encoded in the form of hidden
constraints (cover attributes) that are imposed in the design
during the register allocation step of high-level synthesis.
Register allocation step in HLS can be performed through
creation of CIG. The nodes of the CIG represent storage
variables and an edge between two nodes indicates
overlapping lifetime of those two storage variables in a
particular control step. A common register cannot be allocated
to store the storage variables if there is an edge between those
two storage variables in the coloured interval graph. To
impose the obtained digital signature in the register allocation
step, additional constraints are added in the form of extra
edges between nodes in a coloured interval graph. Based on
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
RSA Decimal Input
328629211327023525868991755443368749196
338967726051337686699507528186630279801
74508071724950413296959519603599240546
14047629289186758734138225185020455483
this encoding mechanism, each bit of the digital signature is
mapped to a hidden constraint representing watermark. These
additional edges added as digital signature constraints
(representing watermark), ensures that the corresponding
storage variables of a coloured interval graph are forced to
execute through distinct registers, affecting design datapath
interconnectivity and architecture.
To insert the digital signature, following algorithm is used:
Pre-embedding steps (1 – 4):
(1) Based on user provided hardware resources, schedule the
DFG of DSP core.
(2) Assign storage variables to the scheduled DFG at the
intermediate inputs and outputs.
(3) Sort the storage variables in the scheduled DFG in
ascending order.
(4) Use the obtained digital signature in the form of
encrypted binary bitstream (after post-processing block 2
in Fig.3), to obtain watermark using steps below.
Embedding watermark (step 5 - 10):
(5) Create a coloured interval graph to find the minimum
number of registers required for register allocation.
(6) Create a “register allocation” table for the schedule.
(7) Feed the digital signature (obtained in step 4).
(8) Create a list of additional edge pairs corresponding to its
encoded rule (using encoding block 2 shown in Fig.3 and
as explained in III.D.4) by traversing the sorted nodes.
(9) Insert the digital signature constraints in the CIG.
(10) Modify the “register allocation” table representing IP
design based on coloured interval graph in previous step.
E. Signature Detection
In our proposed approach, signature detection is a two-step
process described as follows:
1) Inspection: This first step is performed in two sub-steps.
The first sub-step performs inspection of the IP design
hardware description language (HDL) files by feeding the
‘Data path HDL code file’. Further, the second sub-step is
to read the “register allocation” table.
2) Signature Verification: The objective of this step is to
verify the presence of digital signature (watermark) in the
collected information from the preceding step. This is
done by verifying the register multiplexer inputs of the
Data path HDL code to check the presence of “register
allocation” table information.
Signature can be validated using the public key to resolve
fraudulent ownership or detect cloned or pirated IP as follows:
for a genuine owner, first, decryption of the digital signature is
performed. Decryption using public key, results in hashed
bitstream blocks (blocks of SHA-512). This regenerated SHA
0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Transactions on Consumer Electronics
TABLE I
Inputs (128 bits) and outputs of RSA module
Encrypted Decimal Output Encrypted Binary Equivalent
172965408816778267187249504979673070306 100000100001111…………011101011100010
85672039843033815680911718133925146652 100000001110011…………111000000011100
118723369081268069007546544190418005189 101100101010001…………010110011000101
28893010973959342128966236208388489987 101011011110010…………100001100000011
hash (obtained from decryption step) can be verified with the
second (or initially) computed SHA-512 output blocks. If this
matches, then the genuine owner is able to provide a definite
proof of authenticity or ownership. In proposed approach, for
decrypting a digital signature, the information on points of
concatenation of bitstreams are required which is only known
by a genuine owner. Hence, even if the digital signature is
compromised and key for performing the decryption is
available (public key), attacker cannot perform the decryption
and hence validate the signature as he/she has no knowledge
of points of concatenation of digital signature. The presence of
proposed digital signature based watermark in an IP of a CE
system ensures the authenticity of the design. This watermark
is capable to differentiate an authentic design from a cloned or
pirated IP design in a CE system. The verification of the
authenticity of the system is typically performed by the SoC
integrator or system manufacturer before it reaches the end
consumer. Since the proposed signature validation step is
capable to provide IP security by avoiding pirated and fake
designs at the SoC integrator and device manufacturer level,
thus it relieves the end consumers of the need to verify real or
fake designs.
IV. APPLICATION OF THE PROPOSED APPROACH ON 8-POINT
DCT BLOCK USED IN AUDIO AND IMAGE COMPRESSION
This section provides an example of proposed digital signature
based IP core protection mechanism for 8-point DCT core.
A. Case Study on 8-Point DCT
This sub-section presents a motivational example to
demonstrate our process of creating and embedding the digital
signature. Steps (1, 2, 3) explained below correspond to the
TABLE II
Mapping of each digital signature bit to its corresponding edge constraint
Bits in digital Corresponding additional
signature (S=15) edges
1 <V2,V4>
0 <V2,V3>
0 <V2,V5>
0 <V2,V7>
0 <V2,V11>
0 <V2,V13>
1 <V2,V6>
0 <V2,V17>
0 <V2,V19>
0 <V3,V5>
0 <V3,V7>
1 <V2,V8>
1 <V2,V10>
1 <V2,V12>
1 <V2,V14>
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics

V0 V2 V4
V2 V3
4 V1 V7
1 2 B R R B O
1 * *
V1 V3
*V V7 V9 V11 V0
5
2 3 6 V5
+ * V 8 * 10
* V9
V6 V8 10 V12 V14 V16 V4 G G Y C
V11
3 + 5 12
* 14
V13 V15 * V17 V14
B C R V16
4 + 7 V6
V18

5 9 V22 B V8 V10
+ Bl O Y V12
V19

6 + 11 V18
V20 B
GV B V13
V19 B 15
7 + 13
V21
V20 B
C
8 + 15
V22 V21 B V17

Default signature
Fig. 4. Scheduled DFG of 8-point DCT with storage variables
Effective signature
process of creating digital signature and step ‘4’ describes the
procedure for embedding the created digital signature. Existing CIG Edges

A.1 Obtaining the Bitstream of DCT Core
Fig. 4 shows the scheduled DFG of 8-point DCT based on
user specified resource configuration (3 multipliers, 1 adder)
using LIST scheduling algorithm with storage variables (V 0–
V22) assigned at the intermediate inputs and outputs.
Subsequently, the bitstream representation of the DCT core is
generated according to the encoding rule (stated in section
III.D.1). The bitstream generated is 011100100011011.
A.2 Computing SHA-512 Hash and Processing Digest of DCT
Next, hash of the bitstream constructed in previous step is
generated. First, the bitstream is processed before performing
the main hash computation. The output of this preliminary
step is 01110010 00110111 ……… 00000000 00000000
00001111 (1024 bits). The 512-bit hash buffer is initialised to
0110101000001001……….0010000101111001(512 bits). The
round function is executed for 80 iterations and the output of
the 80th iteration is added to the input of the first iteration to
produce the hashed bitstream digest. This bitstream digest is
divided into four blocks of size 128 bits each. Each block is
converted to equivalent decimal value and the same can be
seen in the first column of Table I.
A.3 RSA Encryption and Digital Signature of DCT Core
Now each decimal value is processed through RSA block
using an assumed vendor private key value (d=
49986153633228319567872468342563701819 as example).
Table I comprises details of decimal value outputs from the
previous step, respective encrypted decimal values and their
equivalent encrypted binary representation. Note: For sake of
brevity only first and last 15 bits of the binary representation
are shown. These encrypted bitstreams are concatenated to
form a continuous bitstream of binary data. The respective
digital signature size can be selected based on vendor’s choice
from this continuous bitstream data depending upon the
Fig. 5. Colored interval graph of 8-point DCT after embedding digital
signature constraints (S = 15)
robustness required and the design cost trade-off. For
example, in this particular application we assume a vendor
selected digital signature size or strength (S) of 15 digits for
demonstration. Here first fifteen binary bits (S=15) represent
the watermark strength. The first fifteen bits of the digital
signature are 100000100001111.
A.4 Converting Digital Signature into corresponding
Watermarking Constraints and Embedding into DCT Core
A CIG is created to find the minimum number of registers
required for allocation of storage variables (as available in the
scheduled 8-point DCT). Corresponding register allocation
information is evident in Table III. Subsequently, the bits of
the obtained digital signature are mapped to additional edges
of a CIG representing watermarking constraints. Table II
shows the digital signature bits and their corresponding
decoded mapping to the node pairs of additional edges. The
CIG after including the additional edges as signature
constraints is shown in Fig. 5. It can be seen in Fig. 5 that only
12 additional edges (from total of 15 additional edges in the
signature) have been added as watermarking constraints,
because three edges (viz. edges between node pairs (V2, V4),
(V3, V5) and (V3, V7)) were already present in CIG by default.
Since these three edges are already added, the constraints
imposed by them are satisfied by default. Therefore, register
allocation table needs to be modified to satisfy the remaining
12 constraints based on the new edges added in the CIG
between node pairs viz., (V2, V3), (V2, V5), (V2, V7), (V2, V11),
(V2, V13), (V2, V6), (V2, V17), (V2, V19), (V2, V8), (V2, V10),
(V2, V12), (V2, V14). For example, due to existing conflict
between variables (V2, V3) owing to storage variables V2 and
V3 being assigned to the same register (Red), modification to
register allocation table was performed. To satisfy this

0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics

TABLE III TABLE IV

Register allocation table of 8-point DCT Register allocation table of 8-point DCT after embedding digital signature
(S = 15)
Control
B R G O Y C Bl Control
Step B R G O Y C Bl
Step
0 V0 V2 V4 - - - -
1 V1 V3 V5 V7 V9 V11 - 0 V0 V2 V4 - - - -
2 V6 V8 V5 V10 V12 V14 V16 1 V3 V1 V5 V7 V9 V11 -
3 V13 V8 V15 V10 V12 V17 - 2 V6 V16 V5 V10 V12 V14 V8
4 V18 - V15 V10 V12 V17 - 3 V13 - V15 V10 V12 V17 V8
5 V19 - V15 - V12 V17 - 4 V18 - V15 V10 V12 V17 -
6 V20 - V15 - - V17 - 5 V19 - V15 - V12 V17 -
7 V21 - - - - V17 - 6 V20 - V15 - - V17 -
8 V22 - - - - - - 7 V21 - - - - V17 -
8 V22 - - - - - -
watermark constraint, V2 and V3 required to be allocated to
distinct registers. Hence, V3 has to be swapped with other watermarked designs. For this type of conflict, the entity
variable in the same control step. Inspecting control step 1 of with a more meaningful and stronger signature will be
Table III, it can be observed that V3 can be swapped with rewarded as actual owner.
V1 which was previously assigned to ‘Blue’ register.  Implanting unauthorized signature: ‘B’ may embed a new
Similarly, there exists conflict between variables (V 2, V8). signature into the purchased watermarked design ‘D A’ and
Therefore, V8 needs to be swapped with other variable in the claim that it is his design [3]. In this case, entity ‘B’
same control step. However, V8 cannot be swapped with V6, imposes the watermarking constraints represented by his
V5, V10, V12 and V14 due to violation of other watermarking signature in addition to ‘A’’s signature in original
constraints. Hence, V8 is swapped with V16. The final watermarked design. In such a conflict the real owner ‘A’
modified register allocation table is shown in Table IV. can easily prove his ownership because ‘A’’s design
Finally, the watermarked DCT core with implanted digital contains only his signature, whereas ‘B’’s design contains
signature is obtained. both entities signature.
 Tampering the original signature: In this case, ‘B’ may
V. THREAT SCENARIOS OF FALSE CLAIM OF IP OWNERSHIP try to create his own unauthorized design by introducing
Entity ‘A’ has a watermarked design (D A). ‘DA’ represents local changes to the original watermarked design ‘D A’
design is watermarked by the proposed approach with [3]. In the proposed approach, the signature is encoded
signature ‘SA’. Entity ‘B’ has purchased ‘D A’ from ‘A’. The into constraints that are imposed in the register allocation
following threats [3] can be imposed by ‘B’. step of the design, as hidden attributes. Therefore, it
renders the tampering of all watermarking constraints
 Extraction of unintended signature: After obtaining the
very difficult.
watermarked design, Entity ‘B’ can try to find a new
signature through inverse watermark calculation in the
VI. EXPERIMENTAL RESULTS
original watermarked design ‘DA’. ‘B’ may try to claim
any random existing information in the design as his The proposed approach and related work [4] are all
signature. For example, an attacker may claim "storage implemented in java and executed on a CPU workstation. To
variables V7 and V10 must be assigned to ‘Orange’ evaluate cost of a watermarked IP design, 15nm technology
register" (Table IV) as his signature encoding. scale based on NanGate [15] is used. Comparison with related
Consequently, ‘B’ can claim ‘DA’ as his design because it work [4] has been performed as this work is one of the most
contains both his and ‘A’’s signature (S A). Claiming any recent works that targets DSP core protection against fraud IP
unintended signature may work for the particular design core using watermark.
in consideration (DA), but will have no meaning for other
TABLE V
Probability of Coincidence (Pc) for proposed approach
Size of Digital signature (S)
Benchmarks [16] c S = 15 S = 30 S = 60 S = 120 S = 240
Pc Pc Pc Pc Pc
BPF 6 0.0649 4.2127x10-3 1.7747x10-5 3.1496x10-10 9.9198x10-20
-3 -6
JPEG SAMPLE 10 0.2059 0.0424 1.7970x10 3.2292x10 1.0428x10-11
JPEG IDCT 29 0.5907 0.3490 0.1218 0.0148 2.1999x10-4
-4
MESA FEEDBACK POINTS 17 0.4028 0.1622 0.0263 6.9267x10 4.7979x10-7
DWT 5 0.0352 1.2379x10-3 1.5325x10-6 2.3485x10-12 5.5157 x10-24
ARF 8 0.1349 0.0182 3.3150x10-4 1.0989x10-7 1.2076x10-14
IIR BUTTERWORTH 5 0.0352 1.2379x10-3 1.5325x10-6 2.3485x10-12 5.5157 x10-24
MESA MATRIX
23 0.5134 0.2635 0.0695 4.8237x10-3 2.3268x10-5
MULTIPLICATION

0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics

TABLE VI
Impact on storage overhead on doubling size of digital signature for proposed approach
# of # of registers before
# of edges added resulting into ‘k’ more registers
Benchmarks storage applying proposed
variables digital signature k=0 k=1 k=2 k=3
JPEG IDCT 136 29 15,30,60,120,240 - - -
MESA FEEDBACK
62 17 15,30 60,120 240 -
POINTS
DWT 22 5 - 15,30 - 60
ARF 36 8 15,30,60 120 NA NA
IIR BUTTERWORTH 14 5 15 NA NA NA
JPEG SAMPLE 45 10 15 30,60,120 NA NA
BPF 36 6 15 30,60 NA NA
MESA MATRIX
108 23 15,30,60,120,240 - - -
MULTIPLICATION

TABLE VII
Percentage reduction in Pc value achieved for proposed approach compared to prior work [4] for different DSP cores
Percentage reduction in Pc
Benchmarks
S = 15 S = 30 S = 60 S = 120 S = 240

BPF 34.44 57.05 81.55 96.60 99.88

JPEG SAMPLE 24.05 42.31 66.74 88.94 98.78
JPEG IDCT 1.78 3.51 6.88 13.45 24.84
MESA FEEDBACK POINTS 9.36 17.87 32.56 54.47 79.27
DWT 0 0 0 0 0
ARF 0 0 0 0 0
IIR BUTTERWORTH 0 0 0 0 0
MESA MATRIX
2.78 5.53 10.9 20.31 36.5
MULTIPLICATION

TABLE VIII
different digital signature sizes viz. S = 15, 30, 60, 120, 240.
Comparison of Pa (indicating attackers’ effort) in proposed approach with As evident from Table V, the Pc value decreases as digital
prior work [4] signature size increases. This is because with increase in
# of times digital signature size, the number of watermarking constraints
higher
Pain attacker implanted in the design increases; resulting into lower P c
proposed Pain [4] effort in value. This trend is observed for all benchmarks irrespective
Benchmarks
approach (using (4)) proving of size. Lower the value of Pc, stronger the proof of
(using (3)) ownership
through
authorship, more robust is the implanted watermark. Strength
proposed of digital signature generated contributes to robustness of
BPF 2.57x10-167 7.52x10-37 2.93x10130 proposed watermarking approach. SHA-512 algorithm used in
JPEG SAMPLE 1.61x10 -168
5.66x10 -73
3.52x1095 the digital signature generation process of the proposed
JPEG IDCT 2.66x10 -192
32.03x10 -146
12.04x1046 approach includes collision resistance and uniformity as
MESA FEEDBACK
explained earlier (III.D.2) which contributes to the robustness
6.28x10-171 32.03x10-146 5.1x1025 of the digital signature generation process. Additionally, it has
POINTS
DWT 1.05x10-163 8.67x10-19 8.26x10144 the property that every bit of bitstream digest is a function of
ARF 5.15x10-167 5.66x10-73 1.100x1094 every bit of the bitstream input.
IIR
0.27x10-160 9.31x10-10 34.48x10150
BUTTERWORTH B. Evaluation of the Embedding Cost of Proposed Approach
MESA MATRIX
7.14x10-184 32.03x10-146 4.49x1038 The proposed approach is evaluated in terms of embedding
MULTIPLICATION
cost of digital signature with respect to hardware area and
A. Evaluation of Robustness of Proposed Approach delay as follows ( [4], [12], [13]):
𝐿𝑇 𝐴𝑇
Robustness of proposed approach is evaluated using P c 𝐶𝑓 (𝑋𝑖 ) = 1 + 2 (2)
𝐿𝑚𝑎𝑥 𝐴𝑚𝑎𝑥
metric [3], which is an indication of proof of authorship. The
Pc function is defined below: where, Cf (Xi) is the cost of the watermarked design
1 𝑆
solution for user-provided resource configuration Xi; 1 and 2
𝑃𝑐 = (1 − ) (1) are user defined weights both kept at 0.5 for equal priority, LT
𝑐
and AT indicate design latency and design area of a
where, Pc= the probability of coincidence, c = number of
watermarked design respectively, and Lmax and Amax are
colors used in the original design, S = number of digits used
maximum possible delay and area of a design solution.
for digital signature. Table V, reports the P c for the proposed
digital signature based watermarking approach for five

0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics

C. Impact on Storage Overhead on Doubling Size of Digital proposed approach compared to related work [4] for S = 15 to
Signature for Proposed Approach S = 240 ranges from 9.05 % to 42.4 %. Next in case the
Table VI highlights the respective storage variables in the proposed digital signature gets compromised, then probability
CIG of the original DSP designs for respective benchmarks. of an attacker being able to prove ownership of an IP (leading
to the digital signature) through brute force (Pa) is given in (3).
The number of registers required for these storage variables
Lower is the probability, it becomes more difficult for an
for proposed digital signature approach is shown in the second
attacker to authenticate ownership of an IP.
column of the same table. The number of edges added in the
CIG in accordance to the digital signature size chosen (by the 𝑃𝑎 (𝑝𝑟𝑜𝑝𝑜𝑠𝑒𝑑) = 1/ (2𝑛 ∗ 2512 ∗ 9 ∗ 25 ∗ 24) (3)
designer) is shown in the last column, where ‘k’ denotes the Here, ‘n’ represents the number of operations in a DSP data
number of extra registers required due to embedding proposed flow graph; 2n indicates first encoding rule possibilities; 2 512
digital signature. On doubling the size of digital signature indicates possibilities after SHA-512 step (considering that the
from S=15 onwards, most of the tested benchmarks report attacker has knowledge about the length of output after
nominal increase in ‘k’ value. hashing step is 512 bits); considering that the attacker knows
that the 512-bit output is divided into blocks of length only in
D. Comparison of proposed approach with related work [4] power of 2, then there are 9 possibilities for block length
in terms of robustness and storage hardware (length>1); for generation of private key in RSA, considering
The percentage reduction in Pc value obtained through the an attacker knows that ‘p’ and ‘q’ values selected (prime
proposed approach compared to related work [4] is numbers),were within 100, then there are 25 possibilities of
highlighted in Table VII. This proves that proposed approach ‘p’ and 24 possibilities of ‘q’ ( as p ≠ q). On the contrary for
achieves strong proof of ownership than related work [4] for prior work [4], since the signature is a random combination of
same signature sizes. This is because in evaluation of P c using four variables, the probability of an attacker being able to
(1), number of colours (registers) used in the pre-watermarked prove ownership (leading to the signature) [4] is:
design is higher in case of prior watermarking approach [4] 𝑃𝑎 [4] = 1/ 4𝑊 (4)
than proposed approach. This is possible due to ASAP
scheduling [4] compared to LIST scheduling in proposed where, ‘W’ is the maximum signature size for that DSP core.
approach. For example, an average reduction of Pc value by Comparison of effort needed by an attacker or probability of
~24.8% is achieved in proposed approach compared to related an attacker in proving ownership in proposed and prior work
work [4], for S = 60. Further, the average Pc value for [4] is shown in Table VIII. The last column in Table VIII
proposed approach is 1.9 times lower than related work [4] for indicates lower chances of authenticating ownership (i.e. more
S = 60. The average reduction in Pc value achieved through effort needed through brute force) by an attacker when an IP
TABLE IX
Design cost analysis of proposed approach and [4] (after embedding signature)
Design cost of proposed Design cost
Benchmarks approach of [4]
S = 15 S = 30 S = 60 S = 120 S = 240 S = 15 S = 30 S = 60 S = 120 S = 240
BPF 0.4129 0.4134 0.4134 NA NA 0.4140 0.4145 0.4143 NA NA
JPEG SAMPLE 0.4285 0.4294 0.4294 0.4294 NA 0.4506 0.4506 0.4512 0.4512 NA
MESA MATRIX
0.2687 0.2687 0.2687 0.2687 0.2687 0.2790 0.2790 0.2792 0.2795 0.2795
MULTIPLICATION
JPEG IDCT 0.2160 0.2160 0.2160 0.2160 0.2160 0.2333 0.2333 0.2333 0.2335 0.2335
MESA FEEDBACK
0.3141 0.3141 0.3144 0.3144 0.3144 0.3189 0.3189 0.3191 0.3194 0.3196
POINTS
DWT 0.6409 0.6409 NA NA NA 0.6630 0.6630 NA NA NA
ARF 0.3765 0.3765 0.3765 0.3766 NA 0.3771 0.3768 0.3773 0.3774 NA
IIR BUTTERWORTH 0.5465 NA NA NA NA 0.5469 NA NA NA NA

TABLE X
Number of registers required in proposed approach compared to prior work [4] (after embedding signature)
# of registers # of registers
required in required in
Benchmarks proposed approach [4]
S = 15 S = 30 S = 60 S = 120 S = 240 S = 15 S = 30 S = 60 S = 120 S = 240
BPF 6 7 7 NA NA 8 9 9 NA NA
JPEG SAMPLE 10 11 11 11 NA 13 13 14 14 NA
MESA MATRIX
23 23 23 23 23 24 24 25 26 26
MULTIPLICATION
JPEG IDCT 29 29 29 29 29 30 30 30 31 31
MESA FEEDBACK
17 17 18 18 19 19 19 20 21 22
POINTS
DWT 6 6 8 NA NA 7 7 9 NA NA
ARF 8 8 8 9 NA 9 9 10 11 NA
IIR BUTTERWORTH 5 NA NA NA NA 6 NA NA NA NA

0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCE.2019.2924049, IEEE
Transactions on Consumer Electronics
core is implanted with proposed digital signature compared to [9]
signature implanted in prior work [4].
Table IX reports the post-watermark design cost
comparison of proposed approach and related work [4]. As [10]
highlighted in the aforesaid table, for all different digital
signature sizes (S=15 to 240) the proposed approach has been [11]
capable to implant watermark at lower hardware design cost.
This trend is observed for all reported DSP cores. The lower
embedding cost is a result of lesser register hardware used [12]
compared to prior work [4]. Lesser register hardware is used
because the proposed approach eliminates dependency on
different signature combinations, as digital signature always [13]
produces unique hashed encrypted bitstream (representing
watermarking constraints) as opposed to prior work [4] in
[14]
which digital signature is a random combination of variables,
selected by the vendor (without knowing its implication on
design cost overhead). Typically, even a same size signature [15]
can have innumerable combinations possible which has
[16]
different implications on security as well as design overhead.
It is very hard to estimate which combination would result into
lower overhead and higher security. Further, the proposed [17]
approach uses LIST scheduling algorithm in HLS framework [18]
compared to ASAP [4]. This also has potential to affect the
latency of the design which in turn reduces the design cost. [19]
The corresponding register comparison is reported in Table X.
[20]
VII. CONCLUSION
[21]
In this paper a novel multi-level encoding and encrypted-
hash based digital signature for protection of reusable IP cores
[22]
is presented. The proposed approach yields stronger protection
through highly robust digital signature and it is reflected in
reduction of Pc value on an average by ~24.8% compared to
prior work [4], while significantly lowering the average design [23]
overhead incurred in terms of storage hardware by ~13.73%. [24]
REFERENCES
[1] P. J. Lobo, E. Juarez, F. Pescador, G. Maturana, and M. C. Rodrguez,
“A DVB-H receiver and gateway implementation on a FPGA- and DSP-
based platform,” IEEE Trans. Consum. Electron., vol. 57, no. 2, pp.
372–378, May 2011.
[2] J. Zhang et al., “FPGA IP protection by binding Finite State Machine to
Physical Unclonable Function,” in Proc. FPL, Portugal, Sept. 2013, pp.
1–4.
[3] F. Koushanfar, I. Hong, and M. Potkonjak, “Behavioral synthesis
techniques for intellectual property protection,” ACM Trans. Des.
Autom. Electron. Syst., vol. 10, no. 3, pp. 523–545, July 2005.
[4] A. Sengupta and S. Bhadauria, “Exploring low cost optimal watermark
for reusable IP cores during high level synthesis,” IEEE Access, vol. 4,
no. 99, pp. 2198–2215, May 2016.
[5] Y. Alkabani, F. Koushanfar, and M. Potkonjak, “Remote activation of
ICs for piracy prevention and digital right management,” in Proc.
ICCAD, CA, USA, Nov. 2007, pp. 674–677.
[6] D. Roy and A. Sengupta, “Low overhead symmetrical protection of
reusable IP core using robust fingerprinting and watermarking during
high level synthesis,” Future Gener. Comput. Syst., vol. 71, no. C, pp.
89–101, Jun. 2017.
[7] Y. Alkabani and F. Koushanfar, “Active control and digital rights
management of integrated circuit IP cores,” in Proc. CASES, GA, USA,
Oct. 2008, pp. 227–234.
[8] L. M. Marvel, “Information hiding: steganography and watermarking,”
in Optical and Digital Techniques for Information Security, vol. 1, B.
Javidi, Ed., New York, NY, USA: Springer, 2005, pp. 113–133.
0098-3063 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
M. Xue, J. Wang, Y. Wang and A. Hu, “Security against hardware trojan
attacks through a novel chaos FSM and delay chains array PUF based
design obfuscation scheme,” in Proc. CCS, Nanjing, China, Aug. 2015,
pp. 14–24.
T. Nie, L. Zhou and Y. Li, “Hierarchical watermarking method for
FPGA IP protection,” IETE Tech. Rev., vol. 30, no. 5, pp. 367–374,
Sept. 2013.
A. Sengupta, S. P. Mohanty, F. Pescador and P. Corcoran, “Multi-phase
obfuscation of fault secured DSP designs with enhanced security
feature,” IEEE Trans. Consum. Electron., vol. 64, no. 3, pp. 356–364,
Aug. 2018.
A. Sengupta, D. Roy, S. P. Mohanty and P. Corcoran, “DSP design
protection in CE through algorithmic transformation based structural
obfuscation,” IEEE Trans. Consum. Electron., vol. 63, no. 4, pp. 467–
476, Nov. 2017.
A. Sengupta, D. Roy, S. P Mohanty and P. Corcoran, “Low-cost
obfuscated JPEG codec IP core for secure CE hardware,” IEEE Trans.
Consum. Electron., vol. 64, no. 3, pp. 365–374, Aug. 2018.
R. Schneiderman, “DSPs evolving in consumer electronics
applications,” IEEE Signal Process. Mag., vol. 27, no. 3, pp. 6–10, May
2010.
NanGate, [Online]. Available: http://www.nangate.com/?pageid=2328,
last accessed on July 2018.
University of California Benchmark, Express Benchmarks, [Online].
Available: https://www.ece.ucsb.edu/EXPRESS/benchmark/,last
accessed on July 2018.
Maxim, [Online]. Available: https://www.maximintegrated.com/en/app-
notes/index.mvp/id/545, last accessed on May 2019.
SMT Corp., [Online]. Available: https://www.smtcorp.com/counterfeit-
detection, last accessed on May 2019.
J. Zhang, “A practical logic obfuscation technique for hardware
security,” IEEE Trans. Very Large Scale Integr. Syst., vol. 24, no. 3, pp.
1193–1197, 2015.
P. Subramanyan, S. Ray, S. Malik “Evaluating the security of logic
encryption algorithms” in Proc. HOST, Washington, pp. 137–143, 2015.
Y. Lao and K. K. Parhi, “Obfuscating DSP circuits via high-level
transformations,” IEEE Trans. Very Large Scale Integr. Syst., vol. 23, no.
5, pp. 819–830, May 2015.
A. Vijayakumar, V. C. Patil, D. E. Holcomb, C. Paar, and S. Kundu,
“Physical design obfuscation of hardware: a comprehensive
investigation of device and logic-level techniques,” IEEE Trans. Inf.
Forensics Security, vol. 12, no. 1, pp. 64–77, Jan 2017.
R. Torrance and D. James. “The state-of-the-art in IC reverse
engineering,” in Proc. CHES, vol. 5747, 2009, pp. 363–381.
J. Rajendran, Y. Pino, O. Sinanoglu, and R. Karri, “Security analysis of
logic obfuscation,” in Proc. DAC, San Francisco, June 2012, pp. 83–89.
Anirban Sengupta (M’09, SM’17) received the
Ph.D. in Electrical and Computer Engineering
from Ryerson University, Canada, in 2012.
He is an Associate Professor in Computer
Science and Engineering at Indian Institute of
Technology Indore. He has over 200 Publications
and is an elected Fellow of IET and BCS.
Ranjith Kumar received the B.Tech degree in
Computer Science Engineering from Indian
Institute of Technology (I.I.T) Indore.
He is a research assistant in Discipline of
Computer Science Engineering at Indian Institute
of Technology (I.I.T) Indore.
Prajwal Chandra received the B.Tech degree
in Computer Science Engineering from Indian
Institute of Technology (I.I.T) Indore.
He is a research assistant in Discipline of
Computer Science Engineering at Indian
Institute of Technology (I.I.T) Indore.