Cryptographic Rights Management of FPGA Intellectual
Property Cores
Tom Kean
Algotronix Ltd.
PO Box 23116
Edinburgh EH8 8YB United Kingdom
tom@algotronix.com

ABSTRACTAs the capacity of FPGA’s increases to millions of equivalent
gates the use of Intellectual Property (IP) cores becomesincreasingly important to control design complexity. FPGA’s are
becoming platforms for integrating a system solution fromcomponents supplied by independent vendors in the same way as
printed circuit boards provided a platform for earlier generationsof designers. However, the current commercial model for IP
cores involves large up-front license fees reminiscent of ASIC
NRE charges. In order to match the IP core business model to the
low to medium volume applications addressed by FPGA
customers it is important to develop cryptographic techniques
which allow IP core vendors to sell their product on a pay-peruse basis rather than through up-front license fees.

General Terms
Algorithms, Design, Economics, Security, Legal Aspects.

Keywords
FPGA, Intellectual Property, Cryptography, Rights Management.

1. INTRODUCTION
Improvements in process technology and device architecture
have allowed very large circuits to be implemented on FPGA’s.
FPGA’s can now implement designs with the equivalent ofseveral million gates of logic and medium sized memory blocks.
FPGA’s with on board micro-controllers, implemented either
directly in silicon or on the FPGA resources are available.
FPGA’s and Configurable System on Chip (CSoC) parts fromcompanies such as Xilinx, Altera and Triscend are becoming‘platforms’for implementing entire systems.
The trend to implement entire systems on an FPGA iscreating a market for intellectual property ‘cores’. These are
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.
FPGA 2002, February 24-26, 2002, Monterey, CA, USA.
Copyright 2002 ACM 1-58113-452-5/02/0002… $5.00.

designs created by third parties which are sold to FPGA users toincorporate in larger systems. Examples of cores include bus
inter-faces such as PCI bus, signal processing functions such as
Reed Solomon Decoders and communications interface functions
such as Serialiser / Deserialiser (SERDES). Leading FPGA
manufacturers offer access to a catalogue of cores and customers
expect to be able to create a large part of the functionality of
their system using cores – thus reducing their time to market andengineering effort.
An important difficulty for the FPGA core industry is that
there is no way for a core vendor to monitor how many times
their core has been configured into FPGA’s by a particularcustomer. For this reason it normal for third-party core vendors
to have a one time ‘license’ charge to access the design files
rather than a ‘per use’ charge. This is an undesirable businessmodel since it means that a customer with a low-volume
application must pay the same license fee as a customer who willsell millions of units. Further, customers have to pay the entire
license fee ‘up front’ long before obtaining revenue from productsales. Customers might be willing to pay much more forintellectual property if the charges were proportionate to theirown sales rather than a fixed up-front charge.
In order to make a return on the engineering time invested
the core vendors are forced to charge high fees to access the core
– which has the effect of pricing the core beyond the reach ofusers with low volume applications. Unfortunately, FPGA’s
have the greatest market advantage over mask-programmed
Application Specific Integrated Circuits (ASIC’s) in low andmedium volume applications. By selecting an FPGA instead ofa mask programmed ASIC customers have decided to pay higher
per-chip costs in exchange for avoiding up-front NRE charges.
As process technology improves mask programmed chips
implementing medium complexity functions become pad limited
and no longer offer a cost advantage over programmablesolutions. This should allow FPGA’s to take over the market for
many categories of medium complexity Application SpecificStandard Product (ASSP) chips – such as PCI interfaces.
However ASSP vendors are reliant on ASIC implementations to
support their pay-per-use business model. Cryptographic rights
management technology for FPGA’s would allow ASSP vendors
to address medium complexity functions more economically bysupplying bitstreams for FPGA’s (creating Virtual ASSP’s).
Customers who purchased a complete FPGA bitstream would notrequire any FPGA design tools or experience allowing the FPGA
vendors to sell to the large community of engineers who work at
the board level with catalogue parts.
The poor match between the up-front license fee model andthe FPGA customer base has deterred many companies withsignificant IP from making it available to FPGA users. At
present, many of the available cores are supplied by the FPGA
vendors – either free of charge or for nominal fees – in order tostimulate chip sales. As FPGA chip sizes continue to increase it
will become impossible for FPGA vendors to provide all thenecessary cores. It is in everyone’s interest: FPGA customers,
FPGA vendors and third party IP suppliers to find a businessmodel by which core vendors can receive ‘per-use’ payments fortheir intellectual property in order to create a viable market for IP
cores.
Previous work has considered cryptographic schemes forpreventing piracy and reverse engineering of FPGA bitstreams[1-7] but this is believed to be the first proposal for a scheme tosecure pay-per-use licensing of FPGA IP cores.

2. PARTIES TO THE FPGA IP
TRANSACTION
Before discussing a cryptographic scheme to manage IP
rights it is helpful to clearly define the various parties involved.
The goal of a cryptographic rights management scheme is tocreate a framework in which the actions of various parties can becontrolled in order to create business models better matched tomarket needs.
The ‘End User’– purchases equipment containing FPGA’s.
The end user may become a participant in the licensing process if
the equipment allows downloading new designs into the FPGA
after the equipment is delivered to the user. Other parties in theprocess may wish to limit the end users ability to ‘clone’equipment by copying the FPGA bitstream file or to replace the
FPGA design with one which changes the equipment’s
functionality. For example, in the case of a cellular telephone
containing an FPGA the user might wish to reconfigure the
FPGA to avoid service charges.
The ‘FPGA Customer’ – manufactures equipment whichcontains FPGA’s. To do this the customer requires bitstream
files for ‘user designs’ which when loaded onto the FPGA cause
it to perform the desired functions in the equipment. These ‘user
designs’ may include intellectual property blocks or ‘cores’
which implement a portion of the required function.
The ‘Designer’ – creates a complete design for an FPGA
chip. The design may make use of one or more ‘IP cores’
purchased from Core vendors or obtained from the FPGA vendor.
The design can be converted into a bitstream file for the FPGA
chip using the FPGA vendor’s implementation software. Oftenthe ‘Designer’ and ‘Customer’ are the same organization but
there is no reason why this should always be the case and so forthe purpose of describing the protocols it is helpful to separate
the two roles.
The ‘Core Vendor’ – designs intellectual property cores forresale. These cores may be provided as Hardware Description

Language (HDL) files, or in another suitable format such as a
netlist for a particular FPGA manufacturer’s Computer Aided
Design (CAD) tools. Core vendors normally also supply
substantial documentation and test sets for their design. Core
vendors may sell direct to the ‘Designer’ or may have amarketing agreement for the FPGA vendor to distribute theirproduct.
FPGA vendors also generally provide Intellectual
Property (IP) cores which can be incorporated in customer
designs for their chips. These include simple functions (such asadders and multipliers) which are generally provided free ofcharge and more complex functions (such as PCI bus interfaces)
which are provided for a fee. In some cases FPGA vendors
license and resell cores from third party core vendors.
The ‘FPGA Vendor’ – designs and manufactures FPGA
chips.
The ‘CAD Software Vendor’ – designs and sells CAD
software tools. These include ‘Implementation Tools’ which
map netlists describing user designs into bitstreams which canprogram FPGA’s. Implementation tools include place and routeand bitstream generation tools. The complete design flow also
requires higher level synthesis and simulation tools. Today,
implementation tools for a given FPGA are generally only
available from the FPGA vendor. There is a general trend for
FPGA companies to provide more and more of the complete toolflow.
For the purposes of our model we have separated thefunctions of software vendor and FPGA vendor because
marketplace dynamics may well force a separation of thefunctions in the future.
The ‘Trusted External Party (TEP)’ – or ‘trusted third
party’ is an organization which all parties to the transaction are
willing to trust to behave fairly. The TEP has the role offacilitating the IP transaction by maintaining various securedatabases and managing billing for accessing the IP. Trusted
third parties are common in cryptographic protocols – forexample certification authorities sign public keys issued by
websites to indicate that the organization issuing the key isactually entitled to use it. As an example when one visits
Amazon’s website and sets up a secure connection to transfer acredit card number it is a Certification Authority such as
Verisign corporation that guarantees that the public key obtained
from the website which purports to be that of amazon.com
actually is from amazon.com.
In the context of FPGA’s the FPGA vendor is likely to act as thetrusted external party since they have existing business
relationships with all the parties to the transaction. However,since the trusted external party role is a distinct one and need not
be fulfilled by the FPGA vendor it makes sense to describe theprotocols as if the trusted third party is a separate organization.

3. THE RIGHTS MANAGEMENTPROTOCOL
The proposed rights management protocol has three phases: theseoccur when the FPGA is manufactured, when the designer
incorporates cores into his design and during the manufacture ofequipment containing FPGA chips. The protocol is dependent
on additional cryptographic circuitry installed in each FPGA
chip. This circuitry is a simple extension of that proposed by
Algotronix to protect FPGA designs from piracy and reverse
engineering [5], [6], [7]. The protocol described here also
depends on a server computer on the internet operated by aTrusted External Party which maintains various databases andadministrates charging for IP cores.

3.1 Creation of Security Information by
FPGA Manufacturer
Algotronix has previously described details of a scheme toprevent ‘cloning’ and reverse engineering of FPGA bitstream
information. This scheme is based on a secret key stored
permanently on each FPGA chip. Many techniques are available
for embedding the key on the chip for example, laser
programming of fuses, embedding the key information in thedevice maskwork and use of antifuses or FLASH memory. A
feature of the Algotronix anti-piracy scheme is that the secret key
stored on the chip need not be known to anyone - including the
FPGA manufacturer. In the present proposal, as well as
containing a secret cryptographic key, known only to itself, eachchip contains a unique ID or serial number. This ID is not secret
and is made available on request through the programming
interface.
In order to extend the scheme to support secure download andprotection of IP cores it is desired to maintain a shared secretknown only to the chip and an external party. This shared secretcan be used to create a secure communications channel to thechip. Normally the shared secret is a cryptographic key which isused to encrypt messages using a symmetric cipher such as triple
DES or AES.

freely distributed and need not be kept secret but which, whenpresented to the FPGA at a later time allows the FPGA todetermine the secret key and communicate securely with theorganization who created the token.
5.
The entity stores the token and the corresponding user
key in a database indexed by the chip identifier. Using thisdatabase the organization can find the appropriate token and user
key for a given chip at a later time.
Using this scheme anyone who has access to the FPGA cancreate a ‘token’ allowing secure communication with the FPGA
once it leaves their possession. Since tokens are not stored on
the chip itself there is no limit to the number of tokens that may
be associated with a given chip. Tokens can be distributed
freely over unencrypted links and stored in non-volatile memory
along with FPGA bitstreams. When the FPGA that created thetoken loads it in it can recover the secret user key informationand communicate securely with the entity that asked it to create
the token.
As well as their use for IP rights management tokens may be
used to support secure download of programming information to
the FPGA in the field. In this case the tokens are created by the
manufacturer of the equipment containing the FPGA prior toshipping the equipment to end-customers. The token is stored in
non-volatile memory in the equipment containing the FPGA
along with the original bitstream. When a field-download is to
be initiated the FPGA provides its ID to the server computer
operated by the equipment manufacturer. The manufacturer
then encrypts the bit-stream to be downloaded with the user key
corresponding to the ID and supplies the bitstream to the FPGA.
The FPGA decrypts the token using its on-chip secret key toextract the user key necessary to decrypt the bitstream
information. The transfer of the FPGA ID to the manufacturer
server and the download of the bitstream information can takeplace over insecure communication channels.
For the purposes of enforcing IP licensing schemes it is attractive
to create security tokens for all FPGA’s at the time of
manufacture. This can be done during final testing of the
FPGA’s at minimal cost.

An entity (for example a person or organization) who has
physical possession of the chip or equipment containing the chip
can then create a shared secret ‘token’as follows:IV

1.
The entity chooses a secret ‘user’ key and presents it to
the chip through the programming interface (e.g. via JTAG) withheader information indicating that this is a secret key.

User FPGA Key

2.
The chip creates a random initial value (IV) using an
on chip random number generator.

Checksum3.
The chip encrypts the supplied secret key using its own
on-chip secret key in cipher block chaining (CBC) mode using
the initial value created in step two. In CBC mode the IV isexored with the first item of secret information prior to
encryption. CBC mode encryption protects against chosen
plaintext attacks and pat-tern analysis of the ciphertext [8].
4.
The chip reports its identifier and the CBC encrypted
data including the final checksum through the programming
interface. This constitutes a ‘token’ (figure 1) which may be

Encrypted withFPGA Key

Figure 1. Cryptographic Token.

3.2 Use of IP by FPGA Designer
Where a user design incorporates one or more IP cores problems
arise in protecting intellectual property. The user will run CAD
tools provided by the FPGA vendor to create a bitstream fromhigh level design files. However, core vendors may not wish toprovide complete design files to the user – since this would allow
the user to modify the vendor’s core and circumvent any copy

protection mechanisms. Instead core vendors may choose tosupply encrypted cores which can be processed by CAD tools but
cannot be easily viewed or modified by the user.
For example, Altera provides encrypted cores for evaluation
purposes, these cores can be simulated to make sure they havethe desired functionality but they cannot be used to generate
bitstreams and the source code cannot be viewed. Once thedesigner buys a license to use the core the unencrypted data isprovided [9]. Several large CAD companies and FPGA vendors
have developed similar technologies to support evaluation of IP
cores.
In the proposed IP rights management scheme (figure 2), insteadof refusing to generate bitstreams for designs that contain‘encrypted’ IP cores the FPGA vendor CAD software creates
special encrypted bitstreams (figure 3) containing copyrightinformation for any IP cores that were used. If a user designcontains no encrypted licensed IP the FPGA tools will generate aconventional unencrypted bitstream.
The trusted software needs to be able to decrypt the various
encrypted cores to allow processing – this is an identical problem
to that solved by Altera and others for evaluation of IP cores.
Various solutions are available which depend on embedding
secret information (e.g. a private key for use in a public key
algorithm like RSA) in the trusted software. The trusted
software also determines a new ‘design’ key to encrypt theresulting bitstream using a method which allows a program withaccess to TEP secret information to decrypt the bitstream at alater date. These cryptographic functions be implemented in
hardware using a ‘dongle’ or expansion card in the user PC or insoftware - the hardware implementation allows better protectionof secret key information but is less convenient.
A feature of this scheme is that no design information need betransferred to either the FPGA vendor or the TEP. The computerrunning the design tools need not be connected to the internet.
This is advantageous since many designers would refuse to contemplate a security scheme which required that their design
information was transferred to the TEP.

3.3 Programming of FPGA’s by FPGA
Customer
When it is desired to program an FPGA using an encrypted
bitstream the bitstream is supplied to ‘trusted’ programming
software which has embedded secret information provided by the
TEP. This software runs on a computer connected to the internet
and to the programming interface on the FPGA. The computer
may be part of the test system for the equipment containing the
FPGA.
The trusted programming software decrypts the bitstream file toextract the copyright information on any licensed IP cores
included in the bitstream. It then interrogates the FPGA throughits programming interface to determine its ID number (figure 4).
The trusted programming software makes contact with a server
operated by the TEP over internet and provides that server withthe copyright identifiers of the various cores, the ID number of
the FPGA to be programmed and the billing information for thecustomer. The TEP computer bills the FPGA customer accountfor the various cores and looks up the FPGA chip identifier in its
database to find the token and user key information created when
the FPGA chip was manufactured. It then supplies this token to
the programming software along with the corresponding user
key. The communication between the trusted programming
software and the TEP server is protected using a standard
internet security protocol such as SSL.
The trusted programming software then re-encrypts the bitstream
information using the key supplied by the TEP and appends thebitstream information to the token to create a complete set ofprogramming information specific to this particular FPGA
(figure 5). This information can be programmed into a local
serial EPROM or stored elsewhere on the equipment containing
the FPGA in exactly the same way as a conventional unencrypted
FPGA bitstream.
The bitstream created by the programming software can only be
used by one particular FPGA: as well as enforcing pay-per-use
licensing the bitstream is protected against cloning and reverse
engineering by this technique. There is no need for the FPGA tobe physically adjacent to the programming software or for thelink between the FPGA and the programming software to be
secure – thus this scheme can be used to update FPGA
configurations in the field via an internet connection.
When the FPGA loads the bitstream information it decrypts thetoken using its on-chip secret key to determine the TEP user key
then uses the TEP user key to decrypt the programming
information prior to configuration.

3.4 Potential Attacks on the Scheme
The scheme outlined above uses standardized ciphers (such as
triple DES or AES) in a standardized mode – Cipher Block
Chaining (CBC). These ciphers and modes are well understoodand have a large enough key-size to resist key-search attacks(such as presenting very large numbers of potential tokens to thechip in the hope of finding the correct one). Triple DES in CBC
mode is used in common protocols such as SSL and IPSEC andin the banking industry. It is believed that the algorithms used
are not a significant weakness of the scheme.
The scheme also requires secret information to be stored on
integrated circuit chips. Fundamentally, all cryptography isbased on secret information and is only as strong as the physicalsecurity preventing the secret being accessed. There are many
ways of storing secrets on integrated circuits and this is a subjectof considerable study by the smartcard industry. More details ofsuitable techniques for FPGA’s are given in [5] and [6].
The embodiment of the scheme described here requires secret
information to be embedded in computer software running on
general purpose computers. This choice is a tradeoff between
ease-of-use and security. Information embedded in a computer
program is much less well protected than information embedded
in an integrated circuit. Reference [10] describes variants of thescheme in which design software runs on the TEP’s secure server
computers. These alternative schemes do not require secret
information to be stored in software accessible to the FPGA
designer or customer.

The scheme also requires a database on a server computer ownedby the TEP to be kept secret. The threat here is of ‘hacking’ ormalicious access by an ‘insider’ and is similar to that faced bybanks and other organizations who maintain sensitive
information on server computers. While the need to maintain asecure on-line database may be considered a weakness of thissecurity scheme it is a well understood problem addressed
successfully by many organizations.

4. SUMMARY
An important problem facing the emerging FPGA IP coreindustry is the mismatch between the up-front license fee
business model and FPGA customer expectations.
FPGA
customers are used to paying a relatively high per-chip cost while
avoiding up front non-recurring engineering charges. The IP
industry, faced with the inability to enforce pay-per-use billing
has adopted an ASIC like business model in which a large upfront charge is made to access IP, independent of the customers
expected or actual unit volume. This prevents designers withlow and medium volume applications from accessing IP cores.
Further, it has been unattractive for design houses to offer
complete FPGA designs to end users as off the shelf solutions forniche markets. This ‘Virtual’ Application Specific Standard
Product (VASSP) model is potentially a significant market since
it opens FPGA technology to board level designers with no inhouse FPGA design skills. In the VASSP model the design
house does not release any design information beyond a datasheet and the user does not require FPGA CAD tools except for
the trusted device programming software.
A combination of simple cryptographic circuitry added to each
FPGA and an internet service operated by a Trusted External
Party allows convenient pay-per-use revenue collection oncomplete FPGA designs and IP cores incorporated in user FPGA
designs.
This paper has described a conceptually simple implementationof a scheme for securing FPGA IP cores. Based on thisinfrastructure a wide variety of business models can beengineered to match the timing and manner of revenue extraction
to the requirements of particular groups of customers. As an
additional benefit, the cryptographic infrastructure on each chipcan be used to secure bitstreams against reverse engineering andpiracy and secure and control field upgrading of bitstream
information. Reference [10] covers many possible variations,extensions and refinements to this approach.

5. REFERENCES[1] Dipert, B., "Cunning Circuits Confound Crooks", EDN
Magazine, October 12, 2000.
[2] Actel Corporation, "Protecting your Intellectual
Property from the Pirates", presentation at DesignCon'98. Available from www.actel.com.
[3] Xilinx Inc., "Using Bitstream Encryption", in Chapter 2of the Virtex II Platform FPGA Handbook available
from www.xilinx.com.

[4] Austin, K., US Patent 5,388,157 "Data Security
Arrangements for Semiconductor Programmable
Devices"[5] Algotronix Ltd., "Method and Apparatus for Secure
Configuration of a Field Programmable Gate Array",
PCT Patent Application PCT/GB00/04988.
[6] Algotronix Ltd., "Method of using a Mask Programmed
Key to Securely Configure a Field Programmable Gate
Array", European Patent Application EP01124330A2.
[7] Kean, T. “Secure Configuration of Field Programmable
Gate Arrays”, Proceedings of FPL 2001, Belfast, UK.
Published as Springer LNCS 2147.
[8] Schneier, B., “Applied Cryptography”, 2nd edition,
Wiley, 1996.
[9] Altera Inc., “Evaluating AMPP and MegaCore
Functions”, AN-125, April 2000, available fromwww.altera.com .
[10] Algotronix Ltd., “Method of Protecting Intellectual
Property Cores on Field Programmable Gate Array”,
unpublished pending patent application.

EncryptedCore

Trusted CAD
SoftwareEncrypted
Core

TEP SecretInformation

User Design
Files

Figure 2. CAD Software Flow.

IV

Copyright Information

Bitstream Information
Bitstream Checksum

Encrypted
with Design
Key

Figure 3. Encrypted Bitstream Format.

Encrypted
Bitstream+
Copyright
Information

Encrypted
Bitstream+
Copyright
Information

Trusted
Programming
Software

FPGA

ID

TEP
SecretInformation
Customer
Identification

FPGA
SecretKey

Chip
Specific
Bitstream
File

Figure 4. Programming the FPGA.

IVTEP User Key

Encrypted withFPGA Key

ChecksumIV

Copyright Information

Bitstream Information
Bitstream Checksum
Encrypted withTEP User Key
Figure 5. Chip Specific FPGA Bitstream Format.