Counterfeiting & Theft Protection Measures for FPGA Designs

How do FPGA manufacturers protect their devices against counterfeiting and theft of IP? By Tony Storey, Applications Engineer, Digi-Key

The shift from vertical integration to a structure based on an extended third-party supply chain has improved cost-effectiveness but introduced risks for the electronics OEM. A particular risk due to this shift is the task of securing the Intellectual Property (IP) within a design.

Individuals, criminal networks and even governments are involved in attempts to unlock the secrets of electronics systems either for financial gain or to compromise systems for future tactical advantage. Pirates may offer near-identical counterfeits and sap profits; competitors may use your IP to kick-start their own efforts, and adversaries may use the information obtained from a system to cripple it when they see a chance.

The field-programmable gate array (FPGA) has become a key target in these attacks. FPGAs have now become widely used in systems that, previously, would have required hardwired ASICs or microcontrollers. Process technology improvements have increased gate counts into the millions; this makes it possible to build a complete system with an FPGA at the heart of it. Increasing logic density allows FPGAs to provide the processor and the custom logic for the bulk of the system. This transition to programmable solutions has changed how engineers need to look at design security while protecting their organisation’s IP and reputation.

There are several ways in which design security can be compromised

One is reverse engineering. Determining the logical functions of a chip lets a pirate duplicate a system or mix and match other functions to implement new systems being sold as more advanced products than the original. Both ASICs and FPGAs are vulnerable to this practice, but it is possible to use the FPGA’s features to make reverse engineering much more difficult for competitors.

The layout of an ASIC can be obtained by decapping the device and gradually stripping the device of its layers of metal interconnect. Although this is a time-consuming process, reverse engineering teams can use available tools to extract workable netlists from layout information obtained by destructive analysis. With an FPGA, reverse engineering is not carried out using destructive analysis but by extracting the configuration bitstream.

Today’s most common FPGA technology is SRAM-based, which is fast and reconfigurable but must be re-configured every time the FPGA is powered up. Typically, an external Programmable Read-Only Memory (PROM) is used to hold the configuration data for the FPGA. The configuration data can be intercepted and read out during boot time. Although the configuration data is not human readable, automated analysis can be used to reconstruct the netlist in support of reverse-engineering the IP.

The ability to read out the configuration bitstream makes possible two other forms of commercial piracy: cloning and overbuilding. If a pirate only seeks to mimic the design to produce counterfeits for sale, cloning is the most likely method. FPGAs in a given product are most likely available on the open market. This allows the pirate to simply obtain the configuration bitstream and program the FPGA’s PROM to produce a functional counterfeit product.

Overbuilding is closely related to cloning and is one of the easiest forms of piracy to pursue. Overbuilding occurs when a contract manufacturer builds more than the requested quantity of a system. As the components for the entire system are likely to be available from multiple sources, it is often easy for the manufacturer to order a complete bill of materials that replicates the original design. The contract manufacturer will most likely not need to extract the configuration data from on-board ROMs since they more than likely have been sent the necessary information by the OEM customer.

A related issue to design security is that of features designed to prevent theft of services. Many electronic devices are designed to use secure transactions to provide paid-for services. In many cases, the service’s revenue provides the bulk of the vendor’s profits, and the hardware itself may be sold at or below cost. To maintain a revenue stream, the vendor needs to ensure that the user can only receive service after payment. If a user circumvents the payment mechanisms, it will lead to a severe loss of revenue and profitability.

Suppose a hacker can obtain detailed information about the encryption implementation. In that case, they stand a much higher chance of being able to crack encryption keys handled by the system and, with that, defeat the protection mechanisms. The techniques for cracking encryption are not limited to conventional reverse engineering (figure 1). Analysis of side-channel information – power consumption or EMI conducted by a heat sink – can provide important clues about the processing steps that a crypto processing unit performs. The technique is common enough that it stemmed a competition among security researchers. This competition has been held three times so far to find the fastest researcher to find a protected key on a standard system.

Figure 1. Analysis of side-channel information can provide important clues that can help hackers break an FPGA’s cryptography.

Device-specific security measures to protect against various forms of counterfeiting

FPGA manufacturers have introduced some device-specific security measures to protect against various forms of counterfeiting and to help prevent the unauthorised unlock of IP and services.

The first line of defence for FPGAs rests heavily in bitstream encryption. This provides an additional layer of protection beyond the obscurity of the configuration bitstream format itself. FPGAs from Altera, Lattice and Xilinx currently provide on-chip decryption hardware for configuration data. Typically, the bitstream is encrypted by the manufacturer using the AES algorithm. The AES algorithm is based on the Rijndael algorithm. It is a symmetrical 128-bit data block cipher using 128, 192, and 256-bit cipher keys. Symmetrical means the same key is used in both encryption and decryption. Each 128-bit input block (a four by four 2-D array of bytes also referred to as a State) goes through a sequence of four byte-oriented block transformations; how many rounds of each depends on the key length used; 10 rounds for AES-128, 12 rounds for AES-192 and 14 rounds for AES-256.

The transformations used are:

1. Bytesubstitution
2. Row byte shifting by increasing amounts 0 through 3
3. Mixing of the columns within the State array
4. Adding the respective round key to the State
   

The 256-bit key needs to be written into the target FPGA during board assembly and programming. During boot, an AES block takes the bitstream, decrypts it and passes the configuration data to the configuration logic. As the plaintext configuration data is not visible on any of the I/O ports, a pirate cannot read out the stream. Instead, they must expend considerable resources on bitstream decryption using powerful computers.

FPGAs differ in how the key is stored. Lower-cost SRAM-based FPGAs will generally store the data in SRAM, which calls for battery backup to protect the key when the system is powered down. More advanced SRAM-based FPGAs use One-Time-Programmable (OTP) memory to hold the keys, removing the need for battery backup.

An alternative to encryption is to store the configuration on the FPGA itself; consequently, the only time the bitstream can be read is in the factory where it is programmed. Some devices, such as the Lattice ECP2 FPGAs, include a block of on-chip flash memory that can be assigned to configuration data. The configuration data is copied using only internal buses into the SRAM cells that control the FPGA’s internal state at boot time. The technology used in Lattice’s non-volatile FPGAs provides high configuration pattern security while delivering the benefits of rapidly reconfigurable SRAM memory.

Figure 2. Some FPGAs, such as the Lattice MachXO2 shown here, store the configuration data on the FPGA itself.

Microsemi’s devices take non-volatile configuration technology one step further. By way of anti-fuse and flash-based gates, there is no bulk configuration bitstream to protect. This provides the benefit of being live at power-up and ensures that there is no means to read out the bitstream after programming.

The flash memory-based devices in Microsemi’s portfolio promote added security by offering several key storage and management options. These options help prevent tampering that might compromise data, service security or any attempts to analyse the FPGA’s internal state.

With flash-based devices, user encryption keys can be held permanently without the need for battery backup. Several Microsemi Flash-based device architectures use securable blocks of non-volatile memory. This memory is writable only from the device programming interface, not from the FPGA or, in the case of the SmartFusion family, the on-chip microprocessor. This helps make the device more resistant to attacks that are launched over the system bus – a common technique.

Figure 3. A number of Microsemi Flash-based device architectures use securable blocks of non-volatile memory, and this memory is writable only from the device programming interface.

Security lock-bit setting can, for example, require subsequent upgrades to be encrypted with the correct key. Alternatively, this can prohibit upgrades without first unlocking via a valid passcode. Upgrades can also be permanently prohibited, making the device effectively OTP.

The segmented nature of key and passcode storage in Microsemi’s flash-based family of devices enables different participants in the supply chain to program the device at different times. This provides ways to manage security effectively if only parts of the supply chain can be trusted (figure 4).

Figure 4. An example of a secure configuration flow for an FPGA.

For example, Microsemi may configure one flash memory segment before leaving the factory. This may be used to store a key that allows a licensed third-party IP core to be loaded. The design owner may configure another segment, such as the bitstream decryption key and security options; the contract manufacturer may apply the configuration to the main FPGA fabric. Finally, the end-user may configure the Flash ROM segment, for example, loading application-level cryptographic keys that control access to user services.

To protect against attacks on a running system, FPGA manufacturers have implemented countermeasures. For example, Altera has anti-tamper protection on a number of its FPGAs. If a control fuse is set, the device will only accept configuration bitstreams that are encrypted with the correct key. This prevents an attacker from trying to determine the functionality of other parts within the system by altering the FPGA configuration. Stratix, Cyclone and Arria devices can also be set to regularly monitor the internal configuration to see if it matches a checksum. This prevents an attacker from overwriting sections of the logic to see how the change affects system behaviour. The Stratix devices can also be configured such that, if the system logic has functions to detect tampering, it can issue a command to zero the FPGA’s entire memory, including its configuration.

To protect against side-channel attacks, Microsemi has licensed technology from several design-security specialists, including Cryptographic Research. The AES implementation on its latest flash-based devices has been made highly resistant to this class of attack. Customers can use licensed countermeasures for use in their own secure-logic functions.

Although FPGAs may seem more vulnerable to cloning, counterfeiting and tamper-based attacks, silicon vendors have made it possible for customers to implement highly effective countermeasures. The different types of available FPGAs now make it possible to choose the level of design security that one needs for nearly any application.