How to Protect Intellectual Property in FPGAs Devices--Part 1

Antifuse devices are also secure against invasive attacks involving decapping and probing or visually inspecting the part. In an antifuse FPGA, a fuse link is created (rather than blowing a fuse, hence the name antifuse) during programming, but even so it is difficult to invasively attack and clone antifuse FPGAs. This is because fuses are located below layers of metal, making it impossible to view them. The only option is to slice the part along the metal tracks and use an electron microscope (each fuse is only a few angstroms wide) to determine the state of each fuse. In addition, there are several million fuses in even the smallest antifuse FPGA, so an invasive attack is not only futile it is essentially impossible. If the fuse map can be determined through an invasive method, the hacker would still need to reverse engineer the FPGA architecture to know which fuses are used for interconnect, which for logic, and which for clock distribution, etc.

It is clear that even a determined hacker faces several insurmountable hurdles when attempting to invasively attack an antifuse FPGA. From a practical perspective, antifuse devices are impossible to clone. It is no surprise that designs developed by industry and government that require the highest degree of IP protection are developed with antifuse devices.

Flash FPGAs offer all of the IP protection provided by antifuse devices in terms of non-volatility and having all memory on-chip, and are secure when locked. With a flash device, the application designer writes the configuration bitstream into the part during manufacture of the application and then locks it into the part, increasing the IP security of flash devices, because the configuration bitstream is never exposed or available outside of the device where it can be obtained and cloned.

Unlike antifuse devices, a flash FPGA contains the configuration bitstream, so if the bitstream can be extracted from the part, the proprietary IP can be cloned. As a result, flash FPGA manufactures provide several levels of security locking circuits to protect the proprietary contents in the device. These locking circuits vary in the degree to which the part is accessible after locking. When a flash FPGA is locked, functions such as device read, write, verify and erase are disabled.

An advantage that flash-based and SRAM-based FPGAs have over antifuse devices is that they are reprogrammable. Newer families are reprogrammable in the field. In some applications, this capability is highly desirable, but it is in conflict with the ability to configure the device and then lock it to protect the IP. To accommodate reprogrammability and still enable the application designer to lock a flash device, the first level of locking works via a user-defined key that the designer uses to lock or unlock the device. These keys are typically 75 to 263 bits in length making them virtually impossible to crack. With keys of this length, even the use of parallel setups to exhaustively test for the key would take a prohibitive amount of time. If there is no need to reprogram the device in the application, then the part has a permanent lock that provides the highest level of security in a flash FPGA, creating a permanent barrier preventing further access to the contents of the device. The FPGA can no longer be r ead, written, modified or erased, even with a key.

Flash FPGAs are also secure from hackers mounting an invasive attack. Flash cells are buried beneath as many as seven layers of metal. Device layers cannot be removed without disturbing the charge on the programmed flash gates, so a flash FPGA cannot be easily deconstructed to decode IP contents. When permanently locked, they offer an extremely high level of security that is similar to that offered by antifuse devices. Flash FPGAs are unique in being reprogrammable and highly resistant to both invasive and noninvasive attacks.

SRAM-based FPGAs are volatile and require an external configuration memory so they are the least secure of available FPGA devices. Recognizing this, FPGA manufacturers have implemented support for an encrypted bitstream in newer SRAM FPGA families. For these devices, the bitstream can be encrypted using a 3DES or comparable algorithm and stored in external memory. On power up, the encrypted configuration bitstream is read from the memory into the FPGA where it is decrypted and loaded into the fabric. While this makes it impossible for all but the most sophisticated hackers to steal IP, it is still possible to capture the bitstream or introduce a different bitstream.

Older SRAM FPGAs do not support bitstream encryption so there are a number of schemes possible to make these devices more secure. A common method is to implement the design using “handshake tokens,” whereby the functionality of the design is disabled within the FPGA if the expected token is not passed to it. This means that the configuration bitstream can be copied and cloned into an FPGA, but it won’t work without the token. Handshake tokens are generated using a small nonvolatile programmable device (NVPD), so the tokens cannot be copied. Typically, the SRAM FPGA generates a random number at power-up or reset and sends it to the NVPD. The FPGA then requests a token from the NVPD, which generates the token and sends it to the FPGA. The FPGA also calculates the token based on the random number and monitors the token sent from the NVPD to see if they are the same. The functionality of the FPGA (other than the handshake token circuitry) is disabled until the correct token is received. The FP GA controls the token passing by requesting another token from the NVPD at regular intervals. As long as the token received is the correct token, the functionality of the FPGA is enabled.

While this increases the security of the IP, this protection scheme can be defeated since the NVPD is protected but the FPGA isn’t. It is still possible to copy the bitstream out of the external configuration memory and then reverse engineer it to obtain the algorithm that is running in the NVPD. A new NVPD can be created and used to generate the tokens in a cloned circuit. While this protection method significantly increases the amount of effort needed to clone the design, it doesn’t fully secure the proprietary IP within the FPGA.

Other schemes can be used to protect SRAM FPGAs, but these schemes only raise the level of difficulty in obtaining or using the bitstream; they don’t fully protect IP. Ironically, in many of these schemes the contents of the NVPD are protected because the device is nonvolatile, while the contents of the FPGA are exposed because the configuration bitstream has to be written to it every time the device is powered-up.

In Part 2, learn how to protect against cloning, reverse engineering and run-on counterfeiting; and who's responsibility is it to secure IP?

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