0% found this document useful (0 votes)
23 views4 pages

A Protection Mechanism For Intellectual

Uploaded by

Shreya Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views4 pages

A Protection Mechanism For Intellectual

Uploaded by

Shreya Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

A Protection Mechanism for Intellectual Property Rights (IPR) in

FPGA Design Environment


Wael Adi, Bassel Soudan,Nizar Kassab
[email protected], [email protected], [email protected]
Etisalat College of Engineering, University of Sharjah, Ajman University of Science and Technology
UAE

ABSTRACT systems that can be manufactured from their design? This


scenario is very similar to software copy-protection
One of the major difficulties in offering new VLSI requirements. Here, the issue may not be protecting the
designs is protecting the designer’s Intellectual Property actual design data. Rather the issue here is controlling the
Rights IRP. It often requires limited field deployment and number of copies that can be made of a particular design.
testing before a novel implementation may be accepted Therefore, limiting IPR violations in the manufacturing
for general use. The difficulty arises in the need to deploy process as well as limiting IPR violations by possible
the design for testing while disabling the tester from production of illegal copies after the design has been
deciphering the design details. A similar requirement introduced into the market.
applies when the designer is interested in limiting the
number of deployments as part of a business agreement. Of particular interest in this area are FPGA-based
This work leverages the similarities between the issues of designs. Field Programmable Gate Areas (FPGAs) have
IPR protection in the hardware and software arenas and gained a lot of importance in the recent past as they
presents a novel solution to protect the use of designs in present a useful vehicle for introducing new design
FPGA hardware environment. The mechanisms used are concepts to the evaluators (and the market) quickly and
based on hardware-supported design encryption and economically. FPGAs have become the tool of choice for
secured authentication protocols. a large number of fab-less design houses. Especially
those who deal with designs that don’t require cutting
Keywords: secured IPR, FPGA device uniqueness, edge speed or complicated implementations requiring
provable identification, global authentication, VLSI customized layout. FPGAs have an advantage in the IPR
identity. protection area, as they appear to have some particular
structures, which would allow implementing the
necessary IPR security.
1. INTRODUCTION
There is a very important difference between IPR
The major problem in disclosing VLSI designs for protection for FPGA-based designs and software
evaluation is the difficulty to protect the Intellectual copyright protection methods; the FPGA device
Property Rights IRP of the design originator. New design programmer has access to the internal structure of the
ideas can only be accepted after they have been tested in FPGA device. The device programmer is an intermediate
a realistic environment. This leads hardware partner, and the real producer, between the end-user and
manufacturers to depend on their customers (who may the device manufacturer. This fact allows different IPR
eventually become their competitors) for evaluating these protection scenarios.
designs. A problem arises in protecting the designer’s
Intellectual Property Rights – IPR – in the process. How Our proposed solution allows the designer to sell a
can a designer deliver a new system to an limited number of copies, say m, of his design to run only
evaluator/competitor for testing and ensure that they in m different FPGA devices. This assumes that the
won’t be able to extract the design information from the FPGA device manufacturer would offer a provable
system and violate the designer’s IPR? unique identity for every delivered FPGA device.

There are other situations that might be quite different The proposed system offers mutual, provable and
from the above but pose similar difficulties and dangers. traceable IPR transfer with limited number of uses. All
One of these would be the designer’s interest in limiting parties are securely traceable in the entire commercial
the number of system deployments as part of a business and technical transaction. The system is breakable only if
agreement. This is an issue especially for small design the manufacturer cheats; this can be easily traced by
houses who have to depend on out-of-plant chip using a globally authenticated mechanism to prove the
manufacturers/programmers for the production of the device uniqueness. The mechanisms and algorithms
final system. How can the designer limit the number of required for implementing the scenario are presented in
this paper. The mechanisms employed are based on design stream runs only on the device uniquely
trustable secret-key low-complexity functions similar to identified in the order. The stream gives no
those described in [1], [2] and [3]. information about the design structure itself.

The rest of this paper is organized as follows: Section 2 The proposed system offers mutual, provable and
describes the details of the IPR protection scenario, traceable security transaction, which can be performed
Section 3 describes the IPR protection mechanisms for using open Internet media without loss of security. All
architectures, Section 4 details the security threats and parties are securely traceable in the entire commercial
possible attacks and Section 5 presents a summary and and technical transaction. The mechanisms employed are
conclusion. based on trustable secret-key low complexity functions
such as those used in mobile systems [1], [2] and [3]. A
public key mechanism is in preparation.
2. “IPR” PROTECTION SCENARIO

The scenario for implementing our proposed solution to 3. IPR PROTECTION MECHANISM FOR FPGA
the IPR protection issue can be summarized in the ARCHITECTURES
following required steps:
The proposed system implementation includes hardware
1. The FPGA manufacturer produces devices with and software components. The hardware component is
secured unique identity and takes the responsibility of the device identity module DIM that should reside in the
delivering only such devices. A violation of this FPGA in a secured area. This module will guarantee the
responsibility is easily traceable as the device essential physical uniqueness of each device. The
uniqueness must be global. location of the module is to be selected such that no
attack would be possible on the module in any operation
2. The IPR carrier offers his VLSI design – such as a mode. Figure 1 represents a simplified functional block
core function performing a particular task in a certain diagram for the proposed device identification module.
FPGA technology. The binary stream representing
this design is to be securely downloaded into the pre-
defined devices to run this function. Design
Area
DIM
3. The end-customer orders from the IPR carrier a
DIM Device Identity Module
certain number of copies of the offered design – say Secret Device Identity
m copies. In the order the end-customer assigns the Write Once Input
SDI
Secret Type Key

a
unique FPGA device identities DI’s in which the STK

re
DSN

fa
o
design should run. For more security, the device
ro
DSN`
rp
RAND F-1 pe
owner (end-customer) can prove that he owns the
m

s1
Ta

devices by delivering a challenge response proof Cipherd Binary K


Design Stream
using his own random challenges together with C-BDS F-1 BDS
Binary
eventually random challenges from the IPR carrier. s2 Design Stream
RCH
Random
4. After receiving the order, the IPR carrier forwards the Challenge Res

device identities to the manufacturer (eventually with


the proof responses if it was requested during the Figure 1. Architecture of a Possible Device Identity Module
ordering process by the IPR carrier) asking for
authentication keys for these particular devices. The The module includes mainly a non-volatile write once
manufacturer delivers the requested IPR protection memory register, which accommodates the secret device
keys PK’s and certifies that the devices are owned by identity SDI. The manufacturer selects a unique open
the customer by checking his responses (if available). device identity DI, which can be branded on the device
In addition to that the manufacturer can verify the itself and/or stored in a readable area in the device. The
identity of the IPR carrier and certify that he received secret device identity SDI is mapped from DI by some
the IPR protection keys. keyed hash function in a secret way selected by the
manufacturer such that no repetition is possible. A strong
5. Using the IPR protection keys PK, the IPR carrier
cipher with a size of 128 bit – such as AES – can be used
then generates for every device its own ciphered
as a hash function. A mapping cipher function F-1 –
binary design stream C-BDS together with a set of
again such as AES – in deciphering mode should be
random challenges and delivers m ciphered binary
implemented as a hardware block in the module with SDI
design streams to the end-customer.
as a secret key input and the ciphered binary design
6. The end-customer downloads the m ciphered binary stream C-BDS as a cipher text input. The output is the
design streams to the particular m FPGA devices clear text representing the clear binary design stream
designated in the original purchase order. Every BDS that represents the design layout in the FPGA. The
whole structure should be floor planned such that no way secretly as no one can make use of the communicated
is possible to reach BDS and SDI in any direct or indirect information.
method. IPR-Carrier Customer
To check the response of the device to a challenged
IK K
random value RCH the output is switched to an output F-1 C-BDS
“Res”. The cipher text input is XORed automatically with RAND
the secret value SDI by closing the switches s1 and s2 in
that case. RAND
Rand

IPR-Carrier Manufacturer BDS

DSN DSN
Secret Type Key
DI DI
STK

DSN` License Token LT= DI| C-BDS | RAND | DSN


DSN F-1
IK
Figure 3. IPR-Carrier with Customer Transaction for One
DI F SDI Design Copy

MK 4. SECURITY THREATS AND POSSIBLE


Secret Master Key
ATTACKS
IK The system is breakable only if the manufacturer cheats.
However, this can be easily proven, as the device
uniqueness should be a globally authenticated
Figure 2. IPR Carrier-Manufacturer Transactions
mechanism. The system includes a hardware
identification module, which should reside in every
Figure 2 shows the required transactions and operations
FPGA device to achieve physical uniqueness. The device
between the IPR-carrier and device manufacturer. The
manufacturer is the only one who can attack the
IPR-carrier generates his own unique design serial
presented mechanisms. In that case the manufacturer
number DSN for each design copy he wants to sell. For
needs to cooperate with the customer. He can either
every device to be licensed, the IPR-carrier then sends its
generate devices with the same device identity DI or take
DI number and the particular DSN. As shown in Figure
the individual random number of the device to generate
2, the device manufacturer generates the intermediate key
the clear binary design stream BDS. The fist case can be
IK where:
traced, as duplicated-identity can be detected by
IK = F −1 (STK , DSN ) ⊕ SDI = DSN ' ⊕ SDI (1) challenging existing devices and checking for
uniqueness. The second case can also be traced as the
IK is generated individually for every device and sent manufacturer would not be able to find BDS if the
back to the IPR-Carrier. The IPR-Carrier then generates customer did not violate the license agreement and
the following license token LT for every device from the release the secret random number to the manufacturer. In
customer as shown in Figure 3. such a case the cooperation can be also traced. These two
attacks can be prohibited if the IPR-carrier would
LT = C-BDS | RAND (2)
personalize the devices himself and insert secretly the
Where C-BDS is the ciphered binary design stream BDS secret type key STK. This requires however that the
enciphered by using the key K where devices should be shipped to the IPR-carrier for that
purpose. In that case the manufacturer can no longer
K= IK + RAND (3)
attack the system other than by building hardware
RAND is a random number generated by the IPR-Carrier backdoors in the manufactured FPGA architecture.
uniquely for each license.
5. SUMMARY AND CONCLUSION
The customer uses the received license token LT to feed
the corresponding device with the device identity DI. The proposed system offers new mutual, provable and
traceable security transactions to protect IPR in FPGA
The binary vectors C-BDS, DSN and RAND are
design environment. The secured design distribution can
sufficient to generate the clear binary design stream BDS
be established by using simple Internet media without
internally in the corresponding device. Notice that a
security loss. All parties are securely traceable in the
correct BDS would result only if the device has the right
whole commercial and technical transaction. The system
unique identity. The customer would not be able to see
is breakable only if the device manufacturer cheats which
the design stream nor replicate it. The whole
can be easily proven as the device uniqueness
communication transactions need not be communicated
incorporates global authentication. The technical and
procedural requirements as well as all security
mechanisms are described for the proposed system.
6. REFERENCES
[1] Adi, W., "Secured Mobile Device Identification with
Multi-Verifier", Proceedings of the International
Conference on Telecommunications (ICT2001), pp. 289 –
292, 2001

[2] Technical Specification 3G Security, Security Architecture


3G TS 33.102 V. 3.2.0 from 10.1999

[3] Specification of the MILENAGE Algorithm Set. 3GPP TS


35.206 V5.0.0 ETSI, http://www.3gpp.org, 2002.

You might also like