Soft IP Protection: Watermarking HDL Codes.

Full text

Page 1

224
Soft IP Protection: Watermarking HDL Codes
Lin Yuan, Pushkin R. Pari, and Gang Qu
Department of Electrical and Computer Engineering
and Institute for Advanced Computer Studies
University of Maryland, College Park, MD 20742
{yuanl,pushkin,gangqu@eng.umd.edu}
Abstract. Intellectual property (IP) reuse based design is one of the
most promising techniques to close the so-called design productivity gap.
To facilitate better IP reuse, it is desirable to have IPs exchanged in the
soft form such as hardware description language (HDL) source codes.
However, soft IPs have higher protection requirements than hard IPs
and most existing IP protection techniques are not applicable to soft
IPs. In this paper, we describe the basic requirements, make the neces-
sary assumptions, and propose several practical schemes for HDL code
protection.
We protect the HDL codes by hiding author’s signature also called as
watermarking, similar to the idea for hard IP and multimedia data pro-
tection. But the new challenge is how to embed watermark into HDL
source codes, which must be properly documented and synthesizable for
reuse. We leverage the unique feature of Verilog HDL design to develop
several watermarking techniques. These techniques can protect both new
and existing Verilog designs. We watermark SCU-RTL & ISCAS bench-
mark Verilog circuits, as well as a MP3 decoder. Both original and water-
marked designs are implemented on ASICs & FPGAs. The results show
that the proposed techniques survive the commercial synthesis tools and
cause little design overhead in terms of area/resources, delay and power.
1 Introduction
Design reuse and reuse-based design have become increasingly important and
are widely considered as the most efficient way to close the design productivity
gap between silicon capacity and designer’s ability to integrate circuits onto
silicon [27]. For reuse to be successful, the reusable building blocks, also known
as macros, cores, intellectual properties (IPs), or virtual components, must be
easily accessible and integrable. Several industry organizations such as the San
Jose-based ”Virtual Socket Interface Alliance”, the ”design and reuse” in Europe,
and ”IP highway” in Japan have already started building libraries and tools
that can be shared by designers all over the world. More importantly, they are
working on the specification of various IP design standards for IP integration.
But how to guarantee IP provider’s IP rights and royalties remains one of the
major obstacles for design reuse.
J. Fridrich (Ed.): IH 2004, LNCS 3200, pp. 224–238, 2004.
c ? Springer-Verlag Berlin Heidelberg 2004

Page 2

Soft IP Protection: Watermarking HDL Codes 225
IP exchange and reuse normally takes the forms of hard, firm, or soft. Hard
IPs, delivered as GDSII files, are optimized for power, size, or performance. Soft
IPs are delivered in the form of synthesizable HDL codes. Firm IPs, such as place-
ment of RTL blocks or fully placed netlist, are a compromise between hard and
soft IPs [24]. From security point of view, hard IPs are the safest because they are
hard to be reverse engineered or modified. But this one-fits-all solution does not
give IP users any flexibility other than the built-in configuration options. Soft
IPs, on the other hand, are preferred by IP users due to their flexibility of being
integrated with other IPs without much physical constraints. On some occasions,
IP provider may also prefer releasing soft IPs to leave customer-dependent opti-
mization process to the users. Not surprisingly, it has been recognized that the
IP market will be dominated by soft IPs [10]. However, the flexibility makes soft
IPs hard to trace and therefore difficult to prevent IP infringements from hap-
pening. IP providers are taking a high risk in releasing their IPs in the soft form
without protecting their HDL codes with techniques that are effective, robust,
low-complexity, and low-cost. Unfortunately, such techniques or tools are not
available and their development is challenging.
Most existing VLSI design IP protection mechanisms, such as physical tag-
ging, digital watermarking and fingerprinting, target the protection of hard/firm
IPs. Traditional software obfuscating and watermarking methods are not appli-
cable to HDL code either. In this paper, we 1) analyze the challenges in HDL code
protection; 2) describe the basic requirements and necessary assumptions; 3) de-
velop the first set of Verilog source code protection methods. Our approaches can
be easily integrated with the design process to protect a new design. They can
also be applied to protect existing designs, which give IP providers the option
of releasing the (protected) source code for their hard/firm IPs that are already
in the IP market to make them more competitive.
We propose three watermarking techniques to protect Verilog source code.
The first method takes advantage of the don’t-care conditions inherently exist-
ing in the modules by enforcing them to have specific values corresponding to
designer’s signature. A separate test module can be easily constructed to re-
trieve such information. The second one utilizes the fact that many logic units
can be implemented in different ways. Instead of using one fixed structure, we
build multiple functionally identical modules with different implementations in
the same Verilog code. We then selectively instantiate these duplicated modules
for information hiding. The third technique splits the implementation of one
module into two phases in such a way that designer’s signature will be mixed
with the module’s input and output information. We implement and test the
proposed protection schemes on SCU-RTL and ISCAS benchmark circuits using
Synopsys’ design analyzer and Xilinx FPGA CAD tool. The results show that
our watermark survives the synthesis and optimization tools. We measure the
area/resources, delay, and power of the designs before and after watermarking,
and find that our methods introduce little overhead in these three key aspects.

Page 3

226Lin Yuan, Pushkin R. Pari, and Gang Qu
2Previous Work
HDL codes describe VLSI design IPs in the style and structure similar to general
C/C++ programs. Hence, it is natural to investigate whether the existing design
IP protection techniques and software watermarking and obfuscating methods
can be extended for HDL code protection.
2.1VLSI Design IP Protections
According to the IP protection white paper released by VSIA, there are three
approaches to secure an IP: deterrent approach like patents, copyrights, and
trade secrets; protection via licensing agreements or encryption; detection
mechanism such as physical tagging, digital watermarking and fingerprinting
[23]. Legal enforcement (copyright, licensing agreement, etc.) can be used to pro-
tect HDL codes. But it is always hard to enforce such protection, particularly
for the flexible soft IPs. Encryption can be used for soft IP protection [21,22].
But it makes IP reuse inconvenient and there are security holes from which
the un-encrypted IP information may leak. Recently, Kahng et al. [8] estab-
lished principles for constraint-based watermarking techniques in the protection
of VLSI design IPs [16,17].
The protection is achieved by tracing unauthorized reuse and making un-
traceable unauthorized reuse as difficult as re-designing the IP from scratch.
The essence of their approach is to introduce watermark-related additional con-
straints into the input of a black-box design tool such that the design will be
rather unique and the embedded watermark can be revealed as proof of author-
ship. This approach is generic and has been applied to various stages of the VLSI
design process, from behavioral and logic synthesis to standard cell place and
route algorithms, to FPGA designs [7,8,9,10,11,14].
It is possible, but never easy, to extend the idea of constraint-based water-
marking directly into the context of HDL code protection. RT-level HDL source
codes normally describe a design in a program-like manner. The constraints
are the abstract description of the system’s functionality. One can introduce
new constraints as watermark. However, any additional constraint at the top
abstract level description usually can be easily identified and thus removed or
modified. Another concern is the design overhead incurred by adding constraints
at this level. If we add constraints at such early stage, it may have large impact
to the design quality.
2.2Software Watermarking and Obfuscating
Watermarking, tamper proofing, and obfuscating are the typical source code
protection methods to prevent software piracy [3,2,6,15,19,20]. Watermarking
is a technique that embeds a secret message into the program to discourage
IP theft by enabling the establishment of IP ownership [5,12]. Tamper-proofing
technique protects software from being tampered by making the software with

Page 4

Soft IP Protection: Watermarking HDL Codes227
any unauthorized modification into a nonfunctional code. Obfuscating method
makes the program ”unintelligible” while preserving its correct functionality.
Obfuscating and tamper-proofing techniques are not suitable for HDL code
protection. First, they make programs less readable and harder (if not impossi-
ble) to modify, which are all against the incentive to release soft IPs for better
design reuse. Secondly, the continuous push for HDL design standards reduces
the power of such protections.
Software watermarking methods embed a structure or a function into the
program such that it can be reliably located and extracted even after the program
has been translated, optimized, and obfuscated. Existing software watermarking
schemes are either static or dynamic [4]. Static schemes embed watermark only
in the executable and are vulnerable to many attacks. HDL program does not
have any executables, so this approach cannot be applied. Dynamic watermark
is constructed at run time and stored in dynamic state of the program. The
quality of a watermarking scheme depends on how well it stands up to different
types of attacks and how successfully the watermark can be retrieved.
To sum up, HDL source codes are soft IPs in the form of program. They have
more reuse value than hard/firm IPs because of their flexibility and easy acces-
sibility. However, existing hard/firm IP protection techniques cannot be directly
used to prevent designers from losing control of their IPs once HDL source codes
are released. On the other hand, HDL code is different from other program-
ming languages like C/C++ and Java [1,13,18]. Current software protection is
not applicable for HDL code protection due to the following two reasons: 1)
design reuse methodology requires HDL code to be developed and documented
following industrial standards; 2) there are no executables associated with HDL
programs.
3HDL Code Watermarking Techniques
3.1Goals and Assumptions
The sole objective of HDL code watermarking is to hide designer’s digital in-
formation into the HDL source code for ownership protection. However, a good
HDL watermarking technique (at RT-level) must also meet the following goals:
(1) Strong proof of authorship. (2) Low design overhead. (3) Survivability from
re-synthesis. (4) Resilience. (5) Preserve IP’s I/O interface.
To achieve the above goals, we make two necessary assumptions:
Documentation Assumption: designer must document the HDL modules
properly and give sufficiently detailed information on each reusable module’s
input, output, and functionality. However, other details on how each module is
implemented are not required.
This assumption has been widely accepted in the HDL design community. It is
critical for HDL code watermarking. Without this assumption, designers will be
forced to document everything including their watermark implementation. This
makes watermark visible and further increases the difficulty of watermarking.

Page 5

228Lin Yuan, Pushkin R. Pari, and Gang Qu
Verification Assumption: all HDL design should follow the hierarchical
modular fashion and complicated gate-level HDL code should not be mixed with
RT-level description.
We focus on the protection of soft IP at HDL source code level and conse-
quently we restrict the watermark verification problem to be within the context
of HDL code as well. The verification assumption prohibits the following attack:
obtain the gate-level HDL codes for certain modules from the netlist and use
them to replace their equivalent modules. We mention that our proposed tech-
niques are robust against the attack of replacing a single RT-level module by
its equivalent gate-level code. However, if the attacker constructs a new module
by flattening and combining several modules in gate-level code, then the prob-
lem of identifying a watermark is equivalent to sub-circuit isomorphism which is
NP-hard. The verification assumption requires hierarchical modular design and
discourages designs with only a single module. This is not vital to our approach,
but rather a common practice in large real life designs. Attackers can verify the
functionality of each module, but they cannot afford to extract all the modules
from the HDL source code and re-synthesize them and their combinations. In
fact, such attempt is more expensive than redesign from the top-level description
given in the documentation.
Next, we will use Verilog as the framework to illustrate three HDL code
watermarking approaches. We mention that since Verilog share many common
features as hierarchical modular design fashion, code documentation and reused-
based design with other HDL languages, VHDL for example, we can easily extend
the proposed watermarking techniques for the protection of general HDL code.
3.2Verilog Watermarking Approaches
Module Watermarking: In this method, we extend the concept of constraint-
based watermarking to the Verilog design of a module. A module takes certain
input signals and produces output based on the logical functionality to be im-
plemented. The input-output relationship, known as truth table, constrains the
module’s implementation. To embed additional constraints, we take advantage
of the don’t care conditions inherently existing in the module. Consider the de-
sign of an encoder that converts radix-4 numbers into binary. The useful inputs
for this module are 0001, 0010, 0100 and 1000, which produce outputs 00, 01, 10
and 11 respectively. The other twelve combinations of the 4-bit input are don’t
care conditions as they will not occur in the circuit. Now we show how to embed
into the design of this encoder a 15-bit stream b14b13...b1b0=100010010000010
(’DA’ in binary with the last bit as the parity bit). First we order the 12 don’t
cares in ascending order and make a cyclic list: 0000,0011,0101,,1111. Then we
repetitively pick don’t cares one- by-one and assign them specific output values
to embed the above bit-stream following the algorithm in Figure 1.
More specifically, we take 3, the value of ?log212? , bits b2b1b0= 010 from
the given bit-stream (line 4 and 5). This gives us the binary 2 and we thus
select the third (0-offset) don’t care 0101 from the list of don’t cares. Next we
assign a specific value, 00=b4b3, to this input (line 7) and delete it from the list