How to Protect Intellectual Property in FPGA Devices--Part2

Protecting Against IP Theft
Once you determine which FPGA best suits the application, the next area of concern in securing IP is designing in protections against cloning, reverse engineering and run-on counterfeiting.

Cloning of an application is often accomplished without the hacker even knowing how the design works; they don’t need to. They simply copy the FPGA's contents without concern for the technical details of the functionality of the IP, or for any outstanding patents. Cloning requires that something be easily copied, which is true of SRAM-based FPGAs. A competitor can either make a copy of the configuration memory, or intercept the bitstream from the on-board processor and copy the code. They can then manufacture clones of the design. As these cloned products, which often have lower quality, hit the market, the original manufacturer suffers not only lost revenue, but also brand degradation and in some cases increased service costs.

Reverse engineering is considered an acceptable practice in many parts of the world; allowing competitors to steal the design of an IC using testing and analysis. Once the competitor obtains the design details, they can improve upon the original product with minimal R&D costs and sell it at a lower price. Reverse engineering a design is more difficult than cloning and requires that the design be extensively analyzed to determine the exact operation of the application so that it can be duplicated. While reverse engineering requires a great deal more knowledge and time than cloning, it should not be discounted and at least as much effort should be made when designing an FPGA-based product to protect it from reverse engineering as is taken to protect it from cloning.

The most common form of reverse engineering is a simple I/O scan attack. Such attacks attempt to reverse engineer a design by cycling through a large number of possible inputs, then monitoring outputs to determine the internal logic function. While this method of reverse engineering does not actually copy the IP within an FPGA, it does duplicate the response of the part to an input. In this way the functionality can be exactly duplicated even when IP is locked into the FPGA. Even complex functions can be scanned, modeled, and duplicated. Simple combinatorial logic functions are the easiest to duplicate because a given input will always produce a predictable output.

Circuits that have an internal processor are more difficult to scan and duplicate because of the complex relationship that exists between an input and any potential output. A processing element can take many forms, but they all take the input to the circuit and use it to make decisions about how to respond and what output to generate. When memory within the FPGA is used as storage for the processing element, it increases the protection against scan attacks since, in most cases, there is not a direct relationship between an input and the output that results. It is often the case with a processing element that an output is significantly displaced in time, or that an output is the result of many successive inputs. Without knowing what processing is taking place within the part, it is difficult to determine the relationship between inputs and outputs. This protects FPGAs with internal processing elements from scan attacks, although the designer should never assume this is true, and should always evaluate the ci rcuit to make sure that there isn’t an exploitable relationship between inputs and outputs. If a relationship between inputs and outputs can be established, or the circuit doesn’t contain a processing element, other means of protection must be employed.

One method of protecting the IP is to split the circuit among multiple FPGAs and create a timing relationship between the parts. While each individual part can be scanned and the outputs for a given set of inputs determined, the timing relationship to the other parts is much harder to deduce. While this will increase the level of difficulty in duplicating the functionality, it will not fully protect proprietary IP from scan attacks. A better method is to put a small processing block into a second FPGA that generates tokens (as discussed previously in this paper) that are passed to the main FPGA, which contains the proprietary IP. In the event that the tokens don’t match, the main FPGA can reset or do something else that puts the application into a controlled state. The tokens can be generated in one of several rolling key formats, which are random and realistically impossible to crack if you use enough bits. Keep in mind that protecting the IP in the application from scan attacks is very important, but it will not protect IP if the FPGA used isn’t secure and can be cloned.

Run-on Counterfeiting is a form of IP theft that occurs during the manufacture of a design. Run-on counterfeiting takes place when a third-party manufacturer produces additional products beyond those contracted by the designer. Also known as overbuilding, this is the single largest source of counterfeit goods and in some markets around the world, the only source. Run-on counterfeiting has nothing to do with the design of a product and even the best chip or board-level security schemes will fail to protect the design. While it may seem that there is little that a company can do to prevent this, short of manufacturing the product themselves, there are actually several ways to prevent this from happening. The best protection is to control the supply of a critical component to the manufacturer. In the case of designs that use FPGAs, it is easy to deliver one or more of the FPGAs to the manufacturer that is already programmed and secured. If the design company doesn’t wish to get involved in programming, t he function can be contracted to a programming house that is not connected to the manufacturer.

Click here for Figure 2

Another approach is to use an FPGA that has built-in encryption capabilities. The design company can program the encryption key into the FPGA and then deliver the FPGA to the manufacturer along with an encrypted bit-stream that the manufacturer programs into the parts. Only parts that have the encryption key programmed into them will be usable with the encrypted bit stream and the supply of these devices can be controlled, limiting the number of end products that can be manufactured. This cuts down significantly on the programming required prior to shipping FPGA parts to the manufacturer and gives the design company full control over the number of products produced. It is often desirable, since manufacturers normally bundle the cost of the programming into the manufacture of the project. In either case, the design company controls a critical component in the application, preventing run-on counterfeiting. Whether it is at the design site or another location in the development and manufacturing process, the se curity of the design must be considered and processes put in place to protect application IP.

Click here for Figure 3

Who's Responsible for Securing IP?

Proactive companies recognize that a comprehensive security policy is a critical element of corporate governance, and that all employees must understand the need for security. Whether it is ensuring that designs don’t leave with designers, or having remote workers use a secure central server, dealing with systemic security issues within a company is the responsibility of management.

The programmable nature of an FPGA means that the proprietary portion of a design can be carried off in a shirt pocket, or easily emailed out of the company. No matter how good the security is within a design, if there are breaches within an organization, chip-level security, while giving the illusion of protection, will not protect the company’s proprietary technology. In addition when it is found that a company’s IP has been infringed upon, it is vitally important that management take an aggressive posture and use all legal means to vigorously pursue the offenders. It is important to file patent applications in as many countries as possible as early as possible, and to monitor and prosecute any products that infringe on those patents. Pursuing the patent process at least provides a legal foundation for a defense against counterfeiters. This is not to imply that management’s role is somehow more important in the securing of a company’s IP, but the best laid plans of designers and eng ineers to build in protections at the board and chip-level can quickly come to naught if security is not an important part of a company’s overall quality goals. When a design takes months to develop and can be stolen in seconds, it pays to take the time to make sure that it is secure. The protection of IP implemented in an FPGA should be proactively planned and implemented. Designers and engineers must determine the best FPGA to use and best methods of securing IP to protect the success of their products.

Antifuse FPGAs are the most secure and are recommended for applications that require the highest level of protection. If reprogrammability is needed, a flash FPGA is a secure choice, with SRAM FPGAs acceptable for some applications. Protecting against reverse engineering and preventing cloning can be as simple as choosing the most secure FPGA and then using the built-in locks and encryption. Management needs to do its part by promoting a culture of security within the company, and preventing against run-on counterfeiting and other schemes used to steal designs.

With the growth of SOF applications and the increasing use of FPGAs in production designs, security of the IP cannot be taken for granted and must be vigorously protected to preserve competitive advantages and protect investment. Product success and ultimately the future of your company may depend on it.

About the Author
Thomas Barraza is a senior Staff IP Design Engineer at Actel Corporation, responsible for the development of new IP cores for use in Actel FPGAs. With more than 15 years of IP and hardware design experience, Tom holds patents for data encryption control and LAN transmission of digital audio and video, and has developed several network and telecommunications systems. He is currently developing innovative IP for implementation in Actel’s next generation FPGA solutions. Tom has a Bachelors degree in Electrical Engineering from MIT. He can be reached at Thomas.Barraza@actel.com.