By Carol Marsh Algotronix / iSLI, Tom Kean Algotronix Edinburgh, United Kingdom Abstract :
This paper introduces a novel idea for labelling and protecting electronic designs and in particular Intellectual Property (IP) Cores, implemented in Application Specific Integrated Circuits (ASICs) and Field Programmable Gate Arrays (FPGAs). INTRODUCTION
As the size and complexity of FPGAs and ASICs increase and design cycle times shrink, more and more designers are implementing multiple IP Cores in their designs. While this increase in IP Core business is good news for IP Core vendors, two major problems are emerging:
- How can IP Cores be protected?
- How can misuse of IP Cores be detected?
The IP rights of a designer can be abused by either their customers or by pirates. When an IP Core owner sells its IP Core to a customer, they have to trust that the customer will use the IP Core correctly. Sometimes however, this trust is misplaced and a customer can for example:
- Use the IP Core on multiple products when they have purchased a licence for only one
- Provide the IP to other sites in their company or to subsidiary or partner companies when they have purchased a ‘single site’ licence.
- ‘Overbuild’ a licensed product – i.e. they produce more units than the license allows or they have paid royalty for.
This misuse of the IP can happen deliberately, but it is more likely to happen accidentally or through negligence. An engineer in a large organization may reuse an IP block without taking the time to check the exact details of the licence agreement associated with the core. Engineering may ‘forget’ to inform production that there is a royalty associated with a particular IP block or the customer may not have systems in place to track each product variant which incorporates a particular IP block and calculate appropriate royalties. The problem could happen years after the IP core was licenced, after the people responsible for negotiating the licence have moved on. Should the royalty stream coming from a particular customer suddenly drop off, an IP core vendor might like to check whether their IP was still present in the customer’s product.
Another threat is from pirates who can steal an IP Core or, more likely, an entire design by either:
- Copying the ASIC/FPGA bitstream and using it to configure the same kind of FPGA in their own products
- Obtaining design information (such as ASIC maskwork or netlist) through fraudulent methods or through reverse engineering and making use of the design without paying any required fees
For the owners of the IP Core or a complete chip design, it is difficult and expensive to prove that their IP is being used illegally in a product. In the case of silicon chips, the only practical method of detecting an IP Core, is to obtain a sample of the product under suspicion and send it to a specialist laboratory for analysis and reverse engineering. However, detecting the presence of an IP Core in designs implemented on an anti-fuse FPGA or designs for a SRAM FPGA in which the bitstream is protected by cryptography is virtually impossible.
The technology described here and at greater length in a corresponding patent application  quickly identifies the IP Cores used in a chip and thus provides the IP Core owners with a cost-effective method of proving illegal use of their designs. This is implemented in two parts:
DESIGN IP PROTECTION BACKGROUND
- Firstly for labelling the IP Core, we supply a ‘security tag’ which is placed in the IP Core or electronic design to be protected. This tag is an active circuit which generates a signal which can be detected off chip. The functionality of the tag is independent of the bitstream file format or the memory technology used to store the FGPA configuration data and is equally applicable to conventional non-programmable chips.
- Secondly for proving illegal use, we will supply a ‘wand’ which detects and reads the information from the ‘security tag’.
The theft of IP can seriously affect companies in terms of lost revenue and reputation. This is a serious concern not only for IP core vendors but also for the much larger number of designers who create complete FPGA or ASIC designs. This section considers the current methods available for protecting designs. Non Volatile FPGA Technology
FPGAs based on non-volatile memories such as antifuse or Flash memory can provide physical design security. A programming option is provided to disable read-out of the on chip programming memory . Since the bitstream does not leave the FPGA chip, any attempt to access it requires opening the package and using analysis tools to attempt to determine the state of the program memory.
Strong claims about the security of these devices have been made based on the difficulty of determining the state of an individual antifuse using laboratory equipment such as scanning electron microscopes. It is not clear that Flash memories are as difficult to read back as anti-fuses. Reading back every memory location using laboratory equipment is the most obvious but is unlikely to be the most effective method of attacking the security of these chips.
The main problem with antifuse and Flash based FPGAs is that they are significantly slower and less dense than SRAM based devices. SRAM FPGA Bitstream Protection
SRAM FPGAs are volatile devices, so the bitstream has to be stored in a non-volatile device, usually an EPROM or Flash memory and downloaded into the FPGA on power up. This means that pirates can intercept the programming data as it passes between the memory and the FPGA and steal the design .
To prevent reverse engineering and to reduce cloning of SRAM FPGA bitstreams, the bitstream can be protected using cryptography as follows:-
- A security key is permanently stored in the SRAM FPGA
- The bitstream is downloaded into the FPGA in the factory via JTAG
- The FPGA encrypts the bitstream using the security key and outputs the encrypted bitstream to an external non-volatile memory
- In the field, the encrypted bitstream from the non-volatile memory is loaded into the FPGA and decrypted by the FPGA using the security key.
The problem is storing the security key in a volatile device.  and  suggest several methods of storing the key including laser etching the key into the FPGA during manufacturing, by providing a battery backup for an internal register, by embedding the key in FPGA artwork and using non volatile memory such as Flash or antifuse.
SRAM FPGA vendors are now addressing the configuration problem, by either providing;
ASIC Design Protection
- Battery backed SRAM key memory 
- A small amount of internal FLASH memory on their devices to store the security key .
- An internal FLASH memory, large enough to store the entire bitstream . These devices are relatively small compared to state of the art SRAM FPGAs.
Unscrupulous manufacturers with access to ASIC mask sets may ‘overbuild’ chips and sell the excess to the black market. Certicom  have tried to address this problem by adding a manufacturing security system at every level of the production cycle, thus only chips which have been through the correct production cycle will work. IP Core Protection
All of the methods described so far, provide solutions for protecting the overall chip, but they do not prevent designers from misusing IP Cores within their chips.
Traditionally, IP Core owners, worried about the misuse of their IP have supplied only the netlist to their customers. This netlist is then integrated with the rest of the FPGA design netlist during the build process to provide a complete bitstream. This makes reverse engineering more difficult but does not absolutely prevent it.
SystemVerilog and the latest proposal for VHDL  have included IP protection and encryption techniques in the source code to encrypt complete designs or sections of a design. The output is an encrypted RTL file with a security key. The security key is used by the FPGA synthesis and build tools to produce an encrypted bitstream.
The problem is that the security key needs to be passed around and if it is leaked then the design can be stolen. Synplicity  have set a new standard to address this problem, using asymmetric cryptography methods to encrypt the security key.
It is unlikely that these mechanisms can be made completely secure since they are implemented in application software running on an insecure computing platform under the control of the potential pirate – the problem is essentially the same as that faced by Digital Rights Management systems for multimedia. It would be prudent to regard them as deterring rather than preventing design piracy.
These source code encryption techniques are built in to CAD tools and have no contact with bitstream files or ASIC artwork. Therefore they cannot prevent overbuilding or use of IP in multiple projects by an authorised customer. Encryption techniques which address this area are discussed in . Chip Cloning
Chip cloning or ‘ghosting’ is emerging as a major problem, especially in the mobile phone industry. Modern consumer electronics are manufactured by Original Device Manufacturers (ODM) in low cost areas such as China rather than by the ‘brand name’ which sells the product. Price pressure is intense and ODMs are highly motivated to reduce the cost of the component ‘bill of materials’. Unscrupulous distributors and chip suppliers may offer ODMs ‘ghost’ chips. Similar to ‘fake’ Rolex watches these are chips which are marked as if they came from a reputable semiconductor company but are actually cheap copies, pre-used chips which were recovered from scrapped equipment or even chips which failed test and were ‘rescued’ from the scrap bins. These re-animated ‘ghost’ chips may reduce the reliability of the final product and damage the reputation of the ‘brand name’ chip manufacturer resulting in lost revenue.
The only method currently available to detect these ‘cloned’ chips is to debug the product, find the chip which is causing the fault and send that chip to a specialist laboratory for analysis. By then, however, the damage has already been done. Safety critical applications such as medical and aerospace require absolute confidence in the authenticity of parts. Detecting IP Cores and Designs
The problem that no one as yet has addressed is what happens when the protection techniques fail or are not used for business reasons: how do you prove that your IP Core is in a design or determine which version of your IP Core is in a product which has failed in the field?
The industry needs a method of detecting IP in shipped products as well as protecting IP. SECURITY TAG
The first part of the proposal is to provide an active ‘security tag’ which can be placed in an IP Core or chip.
Figure 1 shows a generic ‘security tag’ which contains:
- IP Tag
- Input data
Figure 1 - Generic Security Tag Input data
This input is provided to allow chip designers to insert additional information into the IP Tag within the ‘security tag’. The additional data could contain status or error information from other circuitry on the chip or within the system. Many chips in an electronic system have no way of communicating error information to service engineers through their normal interface signals. The number of pins on a chip package is usually severely limited and there is no reasonable standardized way to collect error signals. The ability to transmit error information securely via the ‘security tag’ would greatly simplify failure analysis of complex electronic systems. By using a secure channel system designers could also be confident that error information from its product will only be available to its own engineers. IP Tag
The IP Tag is the section of the ‘security tag’ which will provide labelling information and will uniquely identify an IP Core. Virtually all commercial merchandise is labelled using either a barcode  or a Radio Frequency Identification (RFID) chip . There are many different barcode and RFID standards, but they all contain Manufacturing and Product information. The IP Tag will contain information similar to that held on bar codes and RFID tags. The VSIA  provide a suggests which information should be held in a maskwork IP Tag. At an implementation level the tag data format is not important - it is just a relatively small block of data (perhaps 128 bits) that needs to be transmitted. Coding/Modulation
This section of the ‘security tag’ is responsible for converting the information stored in the IP Tag into a format more suitable for transmission. Transmitter
This section of the ‘security tag’ must cause some effect which can be detected off chip.
Many possible physical effects could be used, for example, voltage, power, temperature or timing variations. In general any physical effect caused by on chip circuitry which can be detected off chip could potentially be used to signal information.
The transmitter must be very simple and in the case of an FPGA use only standard digital logic. It will transmit only a small amount of data (less than 1k byte) at a slow rate over a short range.
Using the Security Tag
The ‘security tag’ will be used as follows, refer to Figure 2:
- The ‘security tag’ will be added to an IP Core
- The IP Core will be sold to a customer, who will put the IP Core in their FPGA / ASIC design
- The FPGA / ASIC will subsequently be placed in a piece of electronic equipment.
When the detection equipment is connected to or in some cases positioned near the electronic equipment, the ‘security tag’ will create a covert communications channel between itself and the detection equipment to allow its presence to be detected and its information to be extracted. Figure 2 - Covert Channel
The ‘security tag’ should have the following properties:-
SIDE CHANNEL ATTACKS
- It must be easy and cost effective to insert in an IP Core.
- It should not require special silicon processing, excessive silicon area or excessive power consumption.
- It must be difficult for a malevolent party to remove or disable the ‘security tag’. One way of achieving this is to make the ‘security tag’ difficult to find.
- It must be able to uniquely identify the IP Core it is protecting. If adding a ‘security tag’ to an IP Cores becomes the standard, there could be multiple IP Cores within an FPGA, so the ‘security tag’ must be able to identify itself, rather than just announcing it’s presence.
In traditional cryptographic products like smart cards, the key used for encryption can be detected using ‘side channel attacks’. A ‘side channel’ is information which is leaked from a device during operation and can be measured externally. Figure 3 shows the most popular side channel attacks:
- Timing 
- Power consumption 
- Electro-Magnetic (EM) Emissions 
Figure 3 - Side Channels
These ‘side channels’ are undesirable and a considerable amount of research has gone into trying to hide them. Our method, however, will deliberately use these ‘side channels’ and in particular Power Analysis and EM Analysis. Power Analysis
Small changes in the voltage caused by variations in the current drawn by circuits on a chip can be measured by connecting test equipment to the power pins of a chip. This is called Power Analysis.
It is proposed that the transmitter in the ‘security tag’ will deliberately modulate the power supply requirement of the FPGA, in such a way as to secretly produce a distinctive signal to equipment connected to the power pins of the FPGA. If the external equipment detects such a signal, then the user can be sure that a ‘security tag’ is present within the FPGA and therefore that the IP Core to which the ‘security tag’ was added is also present. If the FPGA designer does not have a license to use the IP Core then this is evidence that the IP Core is being used illegally.
The problem with monitoring the ‘security tag’ on the power supply pins is twofold. Firstly the ‘security tag’ will be a very small part of an overall design. Therefore, almost all signal transitions within a chip will be unrelated to the ‘security tag’.
Secondly it is standard practice to place capacitors close to the pins of a chip to filter transients on the power supply. The challenge is therefore to detect the signal from the ‘security tag’ in the presence of the interfering signals and despite the attenuation from smoothing capacitors.
It is not feasible or desirable to simply increase the transmit power of the IP tag so that it dominates the noise signals on the power supply lines. Therefore, the receiver must be able to distinguish a small signal from within much larger noise. This is exactly the same problem faced by radio receivers and approaches developed for digital radio receivers in equipment like cellular phones can be applied to this problem
The design of the transmit and receive circuitry will be a compromise between complexity and cost based on how difficult it is to detect the ‘security tag’, the robustness of the covert channel and the likelihood of an attacker deliberately jamming the ‘security tag’ signals.
Chips operating at high clock frequencies radiate radio signals. Normally, these radio signals are considered undesirable and designers attempt to minimise them since they can potentially interfere with radio communications or other circuits within a system. For example, the metal cases of personal computers are designed to act as a shield to stop these radio signals escaping. The undesired radio signals are referred to as Electromagnetic Interference (EMI).
These unintended emissions have been used for practical purposes before. For example, in the United Kingdom television licensing regulations were enforced by ‘detector vans’ which patrolled the streets and could detect the EMI emitted by television sets in nearby buildings. If a television was detected in a building for which there is no television license then officers had reason to believe that it was being operated illegally.
The voltages required to create images on Cathode Ray Tube (CRT) based television sets and computer monitors, reach several thousand volts and therefore the level of EMI is massively greater than that in the tiny low power circuits of an individual integrated circuit. Moreover the characteristics of the signal corresponding to an image on a monitor are repetitive (once per frame) and information changes relatively slowly (since it is intended to be read by a human) – both these characteristics simplify the task of processing the received signal.
The power of radio signals falls off quickly with distance from the source of the signals (the rate of fall off depends on the frequency of the signals and the surrounding environment, but it is at least quadratic with distance). Thus the distance at which low power signals, such as EMI from an integrated circuit, can be detected is much shorter. Preferably, the detection equipment antenna which receives the EMI signals from the ‘security tag’ will be held within the equipment box and close to the chip of interest.
The equipment required for detecting the radio signals from the ‘security tag’ will be very similar to that used in power analysis. Instead of connecting a probe from the receiver to the power supply within the design, the receiver will be connected to an antenna which is held close to the design.
IP CORE DETECTION ‘WAND’
This description of the ‘Security Tag’ detection ‘wand’ assumes the use of the EM Analysis side channel. Figure 4 shows a ‘wand’, which contains:
- Extracted IP Tag
- Output data
Figure 4 - Wand
The antenna in the ‘wand’ will initially be used to determine if an IP Core is present in a design by detecting the signal being transmitted by the transmitter within the ‘security tag’. If the antenna detects the presence of an IP Core it will extract the data being transmitted by the transmitter.
The receiver will decode the data received by the antenna and covert it into 128 bit binary data stream. Although, the transmitter in the ‘security tag’ must be very simple, the receiver will be relatively complex and expensive.
Extracted IP Tag
This will contain the IP Tag extracted from a chip. It will be used to determine which IP Core is in a chip. If the IP Tag matches the expected IP Tag, then the owner of the IP Core will have enough evidence to start legal proceedings.
This output will be provided to allow the chip designers to use the information stored in the Extracted IP Tag. This is especially useful if the chip designer has used the ‘input data’ signal to provide additional information.
The ‘wand’ must:-
- Reliably detect the ‘security tag’. Since the ‘security tag’ will be used to provide legal evidence of the presence of an IP Core, it is important that the detection equipment does not falsely detect an IP Tag.
- Be capable of detecting multiple ‘security tags’ in a system
- Detect the ‘security tag’ even if the FPGA bitstream is encrypted.
DESIGN VERSION LABELLING
This application of the ‘Security Tag’ will make use of the Power Analysis side channel attacks. For this application to work, the use of IP tags and the information contained in the IP tag would have to be adopted as an industry standard.
Information contained in the IP tag can be extracted via the power supply lines by plugging an analyser into a connector on the main power supply bus. Alternatively, the analyser function could be built in to the system itself, where the system is connected to the internet this can provide a remote diagnostic facility.
The IP Tag could be used for the following purposes:-
- To allow service engineers to obtain a complete inventory of chips used in a product
- To determine the exact version of each chip in a product. This is especially useful for FPGAs which can be modified after a product has been shipped.
- To communicate error information from areas of a design which would normally, be inaccessible to test equipment. This information could greatly simplify the diagnosis of complex electronic systems which fail in the field, especially if the information could be accessed by authorised engineers remotely over the internet
- To allow consumer electronics company to check that the components in a product it was receiving from its ODM are the components specified in its ‘bill of materials’. The IP tag would also make it easy to determine which batches of components were causing problems should a previously reliable product start to experience quality problems.
This paper describes a novel patented technology based on a small ‘security tag’ circuit which is added to IP cores (or complete designs) and a ‘wand’ which can detect and receive information from the ‘security tag’.
This technique provides a method of proving illegal use of an IP core, which is non-invasive, quick and does not affect the functionality of a system. The technique can detect the IP Tag even if it is implemented on an FPGA where the bitstream is encrypted.
As well as protecting against design piracy the security tag can be used to combat the increasing problem of chips which have been marked by pirates as coming from a reputable manufacturer when in fact they are low-cost ‘equivalents’.
 Algotronix Ltd, “Method of Actively Tagging Electronic Designs and Intellectual Property Cores”, UK Patent Application GB 0617697.8
 Actel, “The Importance of Design Security”, 2005, http://www.actel.com/documents/Security_PIB.pdf
 Algotronix Ltd, “Method and Apparatus for Secure Configuration of a FPGA”, US Patent Application US21015919A1
 Algotronix Ltd, “Method of Using a Mask Programmed Key to Securely Configure of a FPGA”, US Patent Application US21037458A1
 Anil Telikepalli, Xilinx, “Is your FPGA Design Secure”, Fall 2003
 Altera Corporation, “Stratix II Device Handbook, Volume 2”, December 2005
 Lattice, “LatticeXP Family Handbook”, Version 02.5, May 2006
 Certicom, “Certicom Security for Fabless Semiconductor Design Companies”, 2006, www.certicom.com/download/aid-603/AppNotes-fabless.pdf
 Ashenden, Peter, “LCS-2006-140 VHDL IP Protection / Encryption Proposal”, 31 May 2006
 Dauman Andrew, Synplicity, “How to Implement an Open IP Encryption Flow”, June 23, 2006
 Algotronix Ltd, “Method of Protecting Intellectual Property Cores on FPGA”, US Patent US22199110A1
 GS1 General Specifications, “EAN/UPC Symbology Specifications”, v7, January 2006, http://www.gs1uk.org/EANUCC/
 EPC Global, “Draft protocol specification for a 900 MHz Class 0 Radio Frequency Identification Tag”, 23 February 2003 http://www.epcglobalinc.org/standards/specs/
 VSIA, “VSI Alliance Releases Soft-IP Tagging Standard (IPP 4 1.0)”, Nov 2004
 Kocher Paul, “Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems”, Proceedings of Crypto’96, Springer-Verlag, August 1996, pages 104–113.
 Kocher, Jaffe and Jun, “Differential Power Analysis”, Proceedings of Crypto’99, Springer-Verlag, 1999, pages 388-397
 Gandolfi, Mourtel and Olivier, “Electromagnetic Analysis: Concrete Results”, Proceedings of CHES’01 Springer-Verlag, 2001, pages 251-261