Appears in Proceedings: IEEE International Conference on Field-Programmable Technology – ICFPT 2007,
IEEE, pp. 169–176, ISBN 978-1-4244-1472-7, 2008.

Dynamic Intellectual Property Protection for Reconfigurable Devices
Tim Güneysu, Bodo Möller, Christof Paar
Horst Görtz Institute for IT Security, Ruhr-Universitt Bochum, Germany{gueneysu,bmoeller,cpaar}@crypto.rub.de

Abstract

market has evolved where companies have specializedon the development of abstract hardware functions thatcan be distributed and licensed to system integrators byusing only a logical description file. However, the flexibility of SRAM-based FPGAs also brings up the issue
of protecting the Intellectual Property (IP) of such circuit layouts from unauthorized duplication or reverse engineering. Unfortunately, a configuration bit file of an
FPGA can easily be retrieved from a product and used
to clone a device with only little effort. Furthermore, IP
vendors that deliver configuration bit files to licensees
do not have any control over how many times the IP is
actually used.

The distinct advantage of SRAM-based Field Programmable Gate Arrays (FPGA) is their flexibility for
configuration changes. However, this opens up thethreat of theft of Intellectual Property (IP) since thesystem configuration is stored in easy-to-access Flashmemory. To prevent this, high-end FPGAs have alreadybeen extended with symmetric-key decryption engines
used to load an encrypted version of the configurationthat cannot simply be copied and used without knowledge of the secret key. However, such protection systems
based on straightforward use of symmetric cryptography are not well-suited with respect to business and licensing processes, since they are lacking a convenientscheme for key transport and installation.
We propose a new protection scheme for the IP ofcircuits in configuration bit files that provides a significant improvement to the current unsatisfying situation. It uses both public-key and symmetric cryptography, but does not burden FPGAs with the usual overheadof public-key cryptography: While it needs hard-wired
symmetric cryptography, the public-key functionality is
moved into a temporary configuration bit stream for a
one-time setup procedure. This approach requires only
very few modifications to current FPGA technology. Using five basic stages, the new protection scheme allows
new accounting models for volume licensing of IP, with
automated key installation on FPGAs taking place at thecustomer’s site.

Previous Work. To cope with these problems, various
approaches have been proposed. A simple “security by
obscurity” approach is to split the IP among multiple
FPGAs and create a unique timing relationship between
the components [4]. This type of mechanism, however,will not protect proprietary IP from more intensive attacks. Moreover, such techniques force IP vendors selling only bit files to deal with the customer’s board layout
as well.
In a smarter approach, IP vendors can insist on installing their configuration bit file only on encryptionenabled FPGA devices using a previously inserted secretkey. Common high-end FPGA types like Virtex 2, Virtex 4 and Virtex 5 from Xilinx [25] as well as Altera’s
Stratix II GX and Stratix III [2] devices provide decryption cores based on symmetric 3DES and AES blockciphers. With an encrypted configuration file, the IP can
only be used on a device that has knowledge of the appropriate secret key. But here the issue of key transfer
arises. One approach is to ship FPGAs to the IP ownerfor key installation: The IP owner installs secret keys inthe devices such that these keys are available to decrypt
configuration bit streams but remain otherwise unaccessible; after key installation, the devices are returned tothe customer. The high logistical effort makes this a very
unsatisfying solution to the problem.
Further solutions are based on separate security chipsthat dongle the IP to a specific FPGA by exchanging
cryptographic handshaking tokens between the components [1]. Similarly, this approach requires modification

Keywords: IP protection, secure configuration, FPGA,
embedded security

1

Introduction

When Field Programmable Gate Arrays (FPGA) werefirst introduced in the 1980s, this was a revolutionary
step from static ASIC and VLSI solutions to flexible
and maintainable hardware applications. It has become
possible to avoid the static designs of standard VLSI
technology, and instead to compile electrical circuits forarbitrary hardware functions into configuration bit files
used to program a fabric of reconfigurable logic. A new12.1

to the customer’s board layout, additional hardware, anda secure domain for installing the secret parameters; so
it provides only a partial solution at a high cost.
In the literature, there are only very few suggestions
to enhance this situation. In [11, 12], a strategy was proposed based on a static secret key already inserted during the manufacturing process. The issue of key transfer
is solved by including cores both for encryption and fordecryption in the FPGA: an FPGA specimen containing
the appropriate key can be used to encrypt a configuration file, yielding a configuration that will work for
itself and for other FPGAs sharing the same fixed key.
In [13, 22], more complex protocols have been proposed
for a more complete solution. Both approaches require
the implementation of additional security features in the
FPGA. They also require the participation of the FPGA
manufacturer (as a trusted party) whenever a bit stream
is to be encrypted for a particular FPGA, meaning thatsuch transactions cannot be kept just between the IP vendor and the customer.

Our idea assumes a use case with three participating
business parties. The first contributor is the Hardware
Manufacturer (HM), who designs and produces FPGA
devices. A second participant is the Intellectual Property Owner (IPO), who has created some novel logic design for a specific problem. This IP is synthesized as aconfiguration bit file for a specific class of FGPAs manufactured and provided by the HM. The IPO wants todistribute the configuration bit file using a special costor licensing model, usually on a per-volume basis. The
final participant is a System Integrator (SI), who intends
to use the IPO’s design in products employing the HM’s
FPGA devices. To support a volume licensing model,
we want to allow the IPO to limit the number of FPGAs
that can use the design.

2.2

Cryptographic Primitives

For a protection scheme that is not just based on obscurity, we need to use cryptography to achieve security.
Symmetric Cryptography: For design protection
and configuration confidentiality, some FPGAs already
implement symmetric encryption based on well-known
blockciphers like AES and 3DES [2, 25]. Such cryptographic functionality can actually be used for more thanjust confidentiality: In the CMAC construction [19], acomputational process mostly identical to that of CBC
encryption with a blockcipher is used to generate a
one-block message authentication code (MAC). Thus,
to keep the footprint of the crypto component small,an implementation of a single blockcipher can be usedboth for decryption and for MAC verification, using a
CBC scheme in both cases. Using separate blockcipher
keys, a combination of such a MAC with encryption canachieve authenticated encryption [5]: we simply have toprovide a MAC of the CBC-encrypted ciphertext. (Thiswill provide security in the sense of the IND-CCA and
INT-CTXT notions as explained in [5]; thus a party that
does not know the keys cannot hope to derive a new
ciphertext that would be accepted as valid.) We canconsider the pair of such keys a single (longer) key k.
Throughout this paper, we will write enck (x) for authenticated encryption of a value x (the plaintext) yielding aciphertext including a MAC value, and deck (y) for thereverse step of decryption of a ciphertext y while also
checking for an authentication error based on the MAC
value provided as part of the ciphertext.
The use of CBC for confidentiality with CMAC
for authentication is just an example of a convenientscheme. Alternatively, we could use any suitable symmetric cryptographic scheme that provides authenticatedencryption in an appropriate sense. As an implemen-

Our Contribution. In this paper, we propose a new protection scheme for configuration bit files that provides
IP vendors with means for exact tracking and control of
their licensed designs without any need for additional
hardware components or major modifications of recent
FPGA technology. Instead of demanding a crypto component for key establishment in the static logic as neededby [13, 22], we use the reconfigurable logic for a setup
process based on public key cryptography. Besides exact tracking of the number of licensed IP, our solution
provides the invaluable advantage of off-site IP installation: The installation of the designs can be performedby the licensees without any shipping of hardware; ourapproach does not require the continuing participationof a third party (such as the FPGA manufacturer) either.
To enable FPGAs for these new features, only marginalmodification are required on recently available FPGA
models.
Outline. Our new protection scheme is described in thefollowing section. This includes assumptions and requirements as well as the description of the protocol andits components. In Section 3, we describe security aspects of our proposal with respect to practical attacker
models and objectives. Section 4 discusses implementation aspects and the impact of necessary changes oncurrent FPGA types. Finally, we conclude with an outlook for further research options.

2

Participating Parties

Protection Scheme

In this section, we introduce a new protection scheme
for the IP in configuration files for FPGAs.
2

key(PK z0 , SK z , OtherInfo) where key is a function combining the basic DH primitive (possibly in the ECDH
variant) with a key derivation function (KDF). Eachparty uses the other party’s public key and its own secret key as input to the Diffie-Hellman primitive, whichthen will yield identical intermediate results for bothparties. To get the final output, the KDF is applied to thegiven inputs: by varying the OtherInfo value (which directly becomes part of the KDF input), static-key DiffieHellman can be used to generate many seemingly independent symmetric keys. (The recommendations in [20]for static-key Diffie-Hellman settings additionally require the use of a nonce in the KDF input for each invocation of the key establishment scheme. This use of nonrepeated random values ensures that different results canbe obtained based on otherwise identical inputs. However, we do not need this nonce here: for our application,
the reproducibility of key establishment results is a feature, not a deficiency.)

tation note regarding the particular combined scheme
using CBC with CMAC, note that an implementationof either blockcipher encryption or blockcipher decryption is sufficient in the FPGA: we can arrange to use
the blockcipher “in reverse” for one of the two cryptographic steps, e.g. use a CMAC based on blockcipher
decryption rather than on blockcipher encryption.
Asymmetric Cryptography: If we want to use symmetric data encryption, this means we have the issue ofestablishing a shared key k between the parties (usually
over an untrusted communication channel). With asymmetric (or public-key) cryptography, a pair of keys consisting of a public (PK) and a private (SK) component isused to overcome the key transport deficiencies of symmetric methods, at the cost of higher system and computation complexity. The first publicly known example ofpublic-key cryptography was the Diffie-Hellman (DH)scheme [9], which can be used to establish keys for symmetric cryptography. Appropriately used in conjunction
with a key derivation function (KDF) based on a cryptographic hash function, the DH scheme remains state of
the art. An important variant of this is the DH scheme
using elliptic curve cryptography [8], ECDH. See [20]for elaborate recommendations on the proper use of DH
and ECDH.
Public-key cryptography can also be used for authentication through digital signatures. These authentication
features are beneficial for our purposes, although their
exact use in authenticated communication is outside of
the scope of the present paper.

2.3

2.4

Prerequisites and Assumptions

For realizing our protection scheme, we assume the following prerequisites (P).
P1. Trusted Party. We assume the FPGA hardware
manufacturer (HM) as a commonly trusted party.
All other participating and non-involved parties in
the protocol can assume the HM to be trustworthy
and unbiased, i.e., the HM will neither share any
secrets with other parties nor unfairly act in favorof someone else. All other parties, however, areregarded per se as untrusted, and may try to cheat.

Key Establishment

For the protocol interactions, we define the set of partiesasZ = {HM, IPO, SI, FPGA},

P2. Secure Cryptography. Furthermore, we assume
that all cryptographic primitives to be computationally secure, i.e., no attacker with a practicalamount of computational power will likely be able
to compute any secret keys or otherwise break thecryptography in any reasonable amount of time.
This includes the symmetric and asymmetric cryptographic primitives as well as the auxiliary cryptographic hash function. Moreover, implementations used for the protocol are assumed to be faulttolerant, tamper-resistant (cf. [21]) and to remain
secure against side-channel attacks over multiple
executions, i.e., it must not be possible to learn any
further information concerning a secret key by analyzing observations from multiple independent protocol runs.

which corresponds to the participants introduced in Subsection 2.1 plus any specific FPGA device, here considered a party in its own right. A key for symmetric cryptography chosen by party z ∈ Z is denoted Kz . Keys forasymmetric cryptography are given in pairs (PK z , SK z )where PK z is the public key component (which may beknown by anyone), and SK z is the private, or secret,component (which generally should only be known by z,
but may sometimes be shared with specific other parties).
A key establishment scheme based on Diffie-Hellman(including the ECDH variant for elliptic curve cryptography) is described in detail in [20]. Given any two parties’ public and private keys PK z , SK z , PK z0 , SK z0 and an
additional bit string OtherInfo, where the keys are understood to have been generated based on common domain
parameters, these parties can determine symmetric key
material by evaluating key(PK z , SK z0 , OtherInfo) andP3. FPGA Security Environment. For the scheme,
we assume an FPGA with an integrated symmetric
decryption engine that is able to handle encrypted3configuration files. This reference device is extended with the following features:that all parties behave as desired without any fraud attempts or protocol abuse. We have five main stages inour scheme (described in detail further below):(i) A unique device identifier ID (an l-bit value)is assigned by the hardware manufacturer(HM), accessible from the fabric.

A. SETUP. On the launch of a new class of FPGA
devices, the HM creates a specific bit stream forthem, a Personalization Module (PM) that later will
be used in the personalization stage. An encryptedversion of this PM is made available to all participants, together with a public key associated to it.

(ii) A symmetric key KHM (an m-bit value) thatis statically integrated by the HM during the
manufacturing process, and which can only
be read by the internal decryption engine, notfrom the FPGA fabric.

B. LICENSING. When an IPO offers licenses to an
SI, it provides a public key of its own. The device
identifier ID of each FPGA on which the SI intends
to use the licensed IP is transferred to the IPO.

(iii) A symmetric key store KFPGA (also an mbit value) that is implemented as non-volatilememory and allows for storing a variable key.
The key stored in KFPGA can either be updated
using an external interface (e.g., JTAG, SelectMap) or via an internal port from the reconfigurable logic of the FPGA; however, it
can only be read from the internal decryptionengine (not from the fabric).

C. PERSONALIZATION. A personalization stage isperformed for each FPGA device in the domain of
the SI. The PM is used to install a device-specific
key in each FPGA on which it is executed.
D. CONFIGURATION. Using the device information, the IPO sends copies of the configuration filecontaining its IP to the SI, specifically encrypted
for each FPGA.

(iv) A data exchange register that can be accessed via a standardized configuration interface like JTAG as well as from the reconfigurable fabric using a dual-ported logic. Thisfeature is already available on many common
FPGAs based on user-defined instructions in
the JTAG protocol.

E. INSTALLATION. The SI installs the IP in each
FPGA (using the appropriate encrypted copy).
The information exchange between the parties is simple. Figure 1 shows the data flow between the participants. Steps 1 through 3 can be considered one-time operations (these are part of the setup and licensing stage);steps 4 and 5 (part of the licensing and configuration
stage) are required to be performed repetitively for each
FPGA that should make use of the protected IP.
'$(v) Tamper-resistant control and security components that can withstand invasive and noninvasive attacks on the device. Particular
protection mechanisms should cover the integrated keys KHM and KFPGA , the decryption engine and the FPGA controller distributing the unencrypted configuration bits in the
fabric of the FPGA after decryption. Hence,a readback of the plain configuration bits orpartial reconfiguration must not be possible
on a device with an encrypted configuration
loaded. Possible physical threats to securityenabled devices as well as side-channel attacks have been discussed more thoroughly in[16, 7, 24].

1. Public key PK HM

?
'$
IPO



3. Public key PK IPO
4. Device identifier ID
5. Response IPenc,ID

&%

?
'$
SI
&%

Figure 1. Data flow between parties

We assume that the decryption engine can be invoked such that, at the user’s choice, either KHM or
KFPGA is employed to decrypt a configuration filefor subsequent use.

2.5

2. Encrypted
personalization&%module Penc

HM

2.5.1 SETUP Stage (A)The setup stage, described in the following, is performed
once by the HM for each FPGA class to be enabled forthe proposed security features. Note that it is reasonable
to artificially keep each FPGA class relatively small by
splitting a large series of otherwise identical FPGAs into

Steps for IP-Protection

This section covers the steps performed by each party
according to an ideal protection protocol, i.e., assuming4multiple separate classes. This limits the potential damage done if an FPGA’s permanent secret KHM or the secret SK HM is compromised (cf. Section 2.4). Any suchclass should be treated as independent from any otherclass; i.e., the results of the setup stage as described below cannot be shared between classes. For practical reasons, a specific part of the device ID should be used todenote the class that a given FPGA belongs to.

Again, authentication of the communication between
IPO and SI is not explicitly covered by this paper sincewell-known solutions do exist (e.g., digital signatures).
It should be remarked that authentication is required to
avoid any abuse of the license model; again, a PKI, canbe very useful.
2.5.3 PERSONALIZATION Stage (C)In contrast to current solutions, our scheme allows for a
key installation that is done in the untrusted domain of
the SI, thanks to the secret key KHM available in the specific FPGAs from the setup stage. The following steps
need to be performed for every FPGA intended to be operated with the IP from the IPO. They can be automatedvery efficiently. The personalization and the key establishment within an FPGA makes use of the encrypted
configuration Penc performing the (one-time) key setup
in logic residing in the fabric. Compared with the optionof demanding static security components for this step inthe static part of an FPGA, this provides huge efficiency
advantages since it limits the resources that have to bepermanently allocated in the FPGA device.

A1. The HM generates a symmetric key KHM and an
asymmetric key pair (SK HM , PK HM ) for key establishment.
A2. The HM creates a specific bit stream P for the
FPGA class such that P implements a key establishment scheme, as described below in 2.5.3.
P includes the private key SK HM . All components employed should be fault-tolerant and include countermeasures against external tampering[16]. The bit stream P acts as a personalization
module and implements the FPGA behavior that
we will present in Subsection 2.5.3.
A3. After the configuration bit file P has been built, it
is encrypted using the secret key KHM , yielding theencrypted configuration file Penc = encKHM (P).

C1. Using a programming interface, the FPGA is configured with the encrypted personalization module
Penc made available by the HM, which is decryptedusing the statically integrated key KHM .

A4. The secret key KHM is statically integrated in each
FPGA (cf. Subsection 2.4) during the manufacturing process.

C2. Then, the data exchange register of the FPGA isloaded with the public key PK IPO via a common
interface (e.g., JTAG), thus initiating the computation process.

After these setup steps have been completed, the HM
distributes the encrypted personalization bit stream Penc
and the public key component PK HM to all participating
parties.
The other parties (notably IPO) must convince themselves that PK HM actually originates from HM. How
this authentication is performed in detail is outside of
the scope of the present paper; however, we remark that
if HM supports many different FPGA classes, then apublic-key infrastructure (PKI) can be very useful.
2.5.2

C3. The personalization module that has now
been loaded determines a symmetric key
key(PK IPO , SK HM , ID) using the integrated
key agreement scheme, and stores the resulting
symmetric key in KFPGA . From now on, the FPGA
can decrypt designs that are encrypted using thiskey.
The security properties of the key establishment scheme
imply that knowledge of either SK HM or SK IPO is required to compute the key now stored in KFPGA ; thus,
SI cannot determine KFPGA . Including ID in the KDF
input ensures that KFPGA will differ for different FPGA
instances. For further implementation aspects, see Section 4.

LICENSING Stage (B)The licensing stage can be regarded as a first interaction between IPO and SI. To use external IP, the SI signs
a contract with the IPO (usually for a volume license).
Then, the following steps are required.

2.5.4 CONFIGURATION Stage (D)For each FPGA ID for which SI has bought a license,
the IPO returns a corresponding configuration file to the
SI usable only on the specific FPGA. This mechanism
allows the IPO to easily track the number of FPGAs that

B1. The IPO creates a key pair (SK IPO , PK IPO ) andsends the public component PK IPO to the SI.
B2. SI provides IPO with a list of the ID values of those
FPGAs for which the SI intends to obtain a license.
5well-known cryptographic mechanisms: symmetric encryption in the sense of authenticated encryption, and a
key establishment scheme.
Only for authenticated encryption, we require a hardwired implementation within the FPGA device. As
sketched in Section 2.2, this can be done based on a single blockcipher such as AES or 3DES. Authenticatedencryption ensures integrity of configuration bit strings,
i.e., a user cannot modify the encrypted configuration to
obtain another (related) configuration that would be accepted by FPGA device and modify part of the intended
behavior, which would be the case for unauthenticatedencryption (such as mere CBC-mode encryption using
AES or 3DES).
Finally, we want to emphasize that special careshould be taken for the realization of the personalization module because of its exposed application in an
untrusted domain. Luckily, such a fault-tolerant andtamper-resilient design has to be developed only onceand should be easily portable between different FPGA
classes.

have been configured to use the licensed IP. In detail, theIPO performs the following steps to generate the FPGAspecific configuration file.
D1. The IPO recovers the specific key KFPGA using its
own secret key and the HM’s public key:
KFPGA = key(PK HM , SK IPO , ID)
D2. The IPO encrypts the plain IP configuration bit fileusing the secret key, thus binding the IP to a specific
FPGA device:
IPenc,ID = encKFPGA (IP).
IPO then transmits this encrypted file to SI.
By the properties of the key establishment scheme, wehave key(PK IPO , SK HM , ID) = key(PK HM , SK IPO , ID),so they key KFPGA as determined by the IPO is identical to the key KFPGA as determined by the FPGA in the
personalization stage.
2.5.5 INSTALLATION Stage (E)After having received IPenc,ID , the SI configures the
FPGA with the personalized IP.

4

We will give some brief suggestions and implementation
details how to realize the participating components, anddiscuss their expected system costs.

E1. SI configures the flash memory of the specific
FPGA denoted by identifier ID with IPenc,ID to operate the device.

4.1

Since KFPGA is available in the FPGA from the personalization stage, this step enables the FPGA to
use the IPO’s configuration bit file IP by computing
decKFPGA (IPenc,ID ).

3

Implementation Aspects

Implementing the Personalization Module

In the following we will demonstrate the feasibility ofthe personalization module that incorporates the implementation of a key establishment scheme as specified by
the protection scheme in Section 2.
Several public-key algorithms have successfully been
implemented in FPGAs. Low footprint RSA/DiffieHellman implementations have been proposed in [10,14, 18] and are already available in ready-to-use IP coresby FPGA vendors like Altera.
Taking the smallest Virtex-4 XC4VFX12 FPGA withan integrated AES-256 bit stream decryption core as areference device, we have implemented the key establishment scheme for the personalization module. For
this proof-of-concept implementation, we realized an
ECC core over prime fields, which forms the basis for
an Elliptic Curve Diffie-Hellman (ECDH). Parameters
for this implementation have been chosen by a trade-offof long-term security and efficiency: We designed an
ECDH component over GF(p) and log2 p = 160 bits,
which is sufficient for mid-term security nowadays. For
details, Table 1 presents requirements of logical elements and data throughput of our implementations.
For the implementation of the KDF according to [20],
we integrated an implementation of the SHA-1 as cryp-

Security Aspects

We assumed the implementations of cryptographic elements integrated in the personalization module to befault-tolerant and tamper-resistant. This is mandatory
since an attacker might take physical influence on thedevice while security-relevant processes are performed.
Hence, countermeasures against device tampering are
required to check if the module is executed under unconventional conditions, e.g, over-voltage, increased temperature or clock frequency. A fairly easy approach todetect operational faults caused by such conditions is touse multiple, identical cryptographic components in the
personalization module operated at different clocks orclock shifts. When all computations are finished, all results are compared which will detect any injected faults
and operational irregularities. With the option to integrate a multitude of countermeasures [3, 16], we arewilling to rely on the FPGA behaving as specified. Then,the protocol is a rather straightforward application of
6

FPGA Fabric

RO M ci

needs to be externally connected with the FPGA’s SelectMAP interface since a direct configuration from thefabric is not yet available. It should be remarked that
all implementations have been developed for an optimal area-time product so that reductions in logical elements can still be achieved if data throughput is nota primary issue. Concluding, the implementations at
hand are small enough to fit even the smallest Virtex4 XC4VFX12 device (providing a total of 5472 slices ofwhich less than 4000 are required) with some remaining
logical resources to add functionality providing tamper
resistance and fault tolerance.

H ash O utput
ShiftRegister

0x00000000
0x00000001

ECD H Core

160

320

32

G F(p),160 Bit
160

320

H A SHS

SH A -1
160

320

128
256

JTA G
ShiftRegister

RO M
SKH M
FPGA ID

SelectM AP
FPGAKeystore

4.2

PKIPO key (JTA G )To use our proposed key scheme on common FPGA devices, an additional key storage with a fixed key needs
to be added to the static design. This is no technical andbig financial issue since it can be integrated by the HM
either directly in the circuit layout, or using antifuses, orby using similar techniques in a post-production step.
Such a strategy based on laser inscriptions or antifuses can also be used to provide each FPGA with aunique identification number. Alternatively, so called
Physically Unclonable Functions (PUF) implemented
using a coating or delay technique might be an option
to create a unique identification of each chip [17].
A further additional requirement for our scheme isaccess from the fabric to the key store via an internal(write-only) interface. This is obviously no problem
since it only requires some internal component repositioning and some dedicated internal I/O pins.
Moreover, for advanced bit stream protection in the
FPGA, we require the decryption direction of authenticated encryption as explained in Section 2.2. A single
blockcipher engine can be used both for authenticationand for decryption, and such reuse means that only little
modification are needed for current FPGA architectures
already containing a symmetric blockcipher engine.
To achieve tamper resistance against invasive attackers, most HMs have already taken efforts to hide away
critical parts from observation and manipulation, i.e., by
distracting those components over multiple layers andlocations. Moreover, strategies known from smart cards[16] could be applied to strengthen FPGAs against physical and invasive attacks.

Figure 2. Simplified schematic of a personalization module for Xilinx Virtex-4 FPGAs
with a 256-bit decryption key

tographic hash function h(x) with an output bit lengthof 160 bits. During key generation, the SHA-1 hashfunction is executed twice using three different inputs:
Given two 32-bit counter values (effectively, two constants) c0 , c1 , a 128-bit FPGA ID and the ECDH result
E, a 256-bit AES key KFPGA can be derived as follows:
Hi
KFPGA

= h(ci || E || ID) for i ∈ {0, 1}= S(H0 || H1 ),where S(x) is a selection function choosing the first 256
out of 320 input bits and where || denotes concatenation.
The data exchange between the personalization moduleand an external party (SI) was realized using a shift register which is writable from the JTAG interface. Besidea ROM for storing the secret key of the HM and constants c0 , c1 , a SelectMAP controller is required to program the key storage of the FPGA, which was provided
by Berkeley’s Bee2 project [6]. The schematic of theimplemented personalization module is sketched in Figure 2.
For this proof-of-concept work, the SelectMAP core
Component
ECDH Core
SHA-1 CoreROM
JTAG Register
SelectMAP Core

Logical Elements
2706 slices
716 slices
112 slices
160 slices
159 slices

Additional FPGA Features

Data Throughput
186Kbit/s
730Mbit/s———

5

Conclusions and Outlook

We proposed a new protection scheme for IP of circuits for FPGAs that provides a significant improvement
to the recent unsatisfying situation, with only very few
modifications to current FPGA devices and corresponding infrastructures. Due to a resource-preserving per-Table 1. Data throughput and logic requirement of personalization components on a
Xilinx Virtex-4 FPGA

7

sonalization module temporarily located in the reconfigurable logic, for a one-time key-establishment, the newprotection scheme is suitable for nearly every modern
FPGA type with just minor modifications to the function set and architecture.
An open issue is the protection of partial designs,
e.g., functional cores that are used as a subcomponent
in a configuration of an FPGA. One could make use of a∗protection scheme with multiple keys KFPGA
per FPGA,
where protected subdesigns are loaded into well-defined
fabric areas of the FPGA using a feature of partial reconfiguration.
Instead of integrating a static ID into each FPGA, theHM might use a Random Number Generator (RNG) thatis additionally included in the personalization module.
This RNG can generate a random value taken as input
to the KDF and used to bind an encrypted configuration
IPenc,RN to a specific FPGA. Implementations for cryptographically secure RNGs in FPGAs are already available [23, 15]. The RNG implemented in the reconfigurable logic might be an additional option to reduce thenumber of modifications with respect to current FPGA
architectures to implement our protection scheme.

[9] W. Diffie and M. E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory,22(6):644–654, 1976.
[10] J. Fry and M. Langhammer. RSA & Public Key Cryptography in FPGAs. Technical report, Altera Corp., 2005.
[11] T. Kean. Secure configuration of field programmablegate arrays. In In proceeding of 11th International Conference on Field-Programmable Logic and Applications,
FPL2001, Belfast, United Kingdom, 2001.
[12] T. Kean. Secure configuration of field programmablegate arrays. In IEEE Symposium on Field Programmable
Custom Computing Machines (FCCM), Rohnert ParkCA, 2001.
[13] T. Kean. Cryptographic Rights Management of FPGAIntellectual Property Cores. In Proceedings ACM Conference on FPGAs, Monterey, CA, 2002.
[14] Ç. K. Koç. RSA hardware implementation. Technicalreport TR801, RSA Data Security, Inc., Aug. 1995.
[15] P. Kohlbrenner and K. Gaj. An embedded true random number generator for FPGAs. In R. Tessier and
H. Schmit, ed., FPGA, pp. 71–78. ACM, 2004.
[16] O. Kömmerling and M. G. Kuhn. Design principles fortamper-resistant smartcard processors. In Proceedings of
the USENIX Workshop on Smartcard Technology, 1999.

References[17] D. Lim. Extracting secret keys from integrated circuits.
Master’s thesis, 2004.

[1] Altera Corp. FPGA design security using MAX II
reference design. http://www.altera.com/end-markets/
refdesigns/sys-sol/indust˙mil/ref-des-secur.html[18] A. Mazzeo, L. Romano, G. PaoloSaggese, and N. Mazzocca. FPGA-based implementation of a serial RSA processor. Design, Automation and Test in Europe Conference and Exposition, pp. 10582–10589, 2003.
[19] National Institute of Standards and Technology (NIST).
Recommendation for block cipher modes of operation –the CMAC mode for authentication. NIST Special Publication SP 800-38B, 2005.

[2] Altera Corp. Stratix II GX and Stratix III FPGAs, 2006.
www.altera.com/products/devices/[3] R. Anderson, M. Bond, J. Clulow, and S. Skorobogatov.
Cryptographic processors – a survey. Proceedings of theIEEE, 94(2):357– 369, Feb 2006.

[20] National Institute of Standards and Technology (NIST).
Recommendation for pair-wise key establishment
schemes using discrete logarithm cryptography. NIST
Special Publication SP 800-56A, 2006.

[4] T. Barraza. How to Protect Intellectual Property in
FPGA Devices Part II. Design and Reuse Online: Industry Articles, 2005. http://www.us.design-reuse.com/
articles/article11240.html[21] S. B. Örs, E. Oswald, and B. Preneel. Power-analysis attacks on an FPGA — first experimental results. In CHES
2003, LNCS vol. 2779, pp. 35–50, 2003.

[5] M. Bellare and C. Namprempre. Authenticated encryption: Relations among notions and analysis of thegeneric composition paradigm.
[6] Berkeley University.
berkeley.edu

Bee2 project.

[22] E. Simpson and P. Schaumont.
Offline hardware/software authentication for reconfigurable platforms. In CHES 2006, LNCS vol. 4249, pp. 311–323,
2006.

http://bee2.eecs.

[23] B. Sunar, W. J. Martin, and D. R. Stinson. A provably
secure true random number generator with built-in tolerance to active attacks. IEEE Tr. Computers, 56.1:109–
119, January 2007.

[7] L. Bossuet, G. Gogniat, and W. Burleson. Dynamicallyconfigurable security for SRAM FPGA bitstreams. International Journal of Embedded Systems, 2(1-2):73–85,
2006.

[24] T. Wollinger and C. Paar. How secure are FPGAs in
cryptographic applications, 2003.

[8] H. Cohen, G. Frey, R. Avanzi, C. Doche, T. Lange,
K. Nguyen, and F. Vercauteren. Handbook of Elliptic and Hyperelliptic Curve Cryptography. CRC Press,
2006.

[25] Xilinx Corp. Virtex2, Virtex 4 and Virtex 5 FPGAs,
2006. www.xilinx.com/products/silicon˙solutions/8