Developing FPGAs for secure environments

18 May 2009

128 Bit AES Encryption in LatticeECP3 devices.
128 Bit AES Encryption in LatticeECP3 devices.

Ted Merena examines the options available for securing and protecting FPGA design code and an entire design.

As many of us have seen, duplicate or “authentic” products, whether they are shoes or electronic circuit boards, are illegally produced and sold on the black market every day. Whether companies rely on third parties or have in-house manufacturing to build their electronic boards, their product is exposed to the possibility of theft due to copying and overbuilding, among other threats.

Most systems today have elevated the use of FPGAs and the functions they perform. In some organisations, FPGAs contain the most significant IP and value-added functionality of a product. Given that many of the components in a design are commercial off-the-shelf devices, it is increasingly important not to overlook the security of the FPGA design code. There are four common security concerns that electronic organisations must combat:

*Reverse Engineering, which is the analysis of an existing system to identify its components and their interrelationships. This information is typically used by competitors trying to improve their own designs or products.

*Cloning, the making of an exact copy of a system without having to determine the complete implementation details. Part or all of the design’s IP will be stolen. This will save significant engineering resources to build and develop a system.

*Overbuilding, which occurs when a contract manufacturer builds more than the requested number of systems from their customer and sells the extra systems in the open market for a much cheaper price. These identical products built from inventory of standard products are sold for profit without any support, development or engineering cost.

*Theft of Service, when an unauthorised party re-programs electronic components (such as FPGAs) running in a critical part of a system in order to change the operation of the system for their own financial gain.

Organisations must ensure they protect their intellectual property, as it is vital to fuel their growth and future existence. Unfortunately, the same tools that have enabled organisations to quickly develop products have also enabled criminals to reproduce them. Even though many of today’s electronic systems have complex software functions, these can be bypassed, especially if FPGAs are a central point of interconnect in the system. An FPGA could be reprogrammed to circumvent the software control allowing unlimited access. One must first look for a secure FPGA to ensure an entire design is protected. To address these concerns for the FPGA portion of the design, Lattice has implemented enhanced security features into their newer FPGA families.

Component technology security levels
It is first necessary to consider the various popular technologies for programmable logic available to a designer today. Table 1 summarises the options and their corresponding security levels. Because SRAM-based FPGAs without encryption have an external bit stream, they are the easiest devices to reverse engineer. During programming time, the device bit stream can be monitored, and potentially copied. Utilising FPGAs with encryption enables secure logic designs. Currently Lattice offers four FPGA families that incorporate encryption. Three of the families are SRAM-based with encryption and one is Flash based with encryption. All of these families utilise a 128-bit key which is either stored in a one-time programmable element or a flash block. No special voltage or battery source is necessary to utilise the encryption capability.

Secure, low power, high value SERDES-based SRAM FPGA
The LatticeECP3 family ranges from 17 K LUTs up to 150 K LUTs, and offers from 4 to 16 SERDES channels which start at 250 Mbps (Megabits per second) and support up to 3.125 Gbps. This family is ideal for Ethernet, PCIe, DVI/HDMI and other serial protocols. The LatticeECP3 also incorporates sysDSP Blocks including a 54-bit ALU for efficient implementation of arithmetic logic (e.g. FIR filters, multipliers). In addition, the LatticeECP3 family has embedded memory blocks that range from 552 Kbits to 6.8 Mbits. Because the LatticeECP3 devices are SRAM-based FPGAs, they must receive their programming information from an external source. This device could be an external memory (such as SPI Flash), or a microprocessor that boots the device via the processor interface in a parallel or serial protocol. To protect the design, all LatticeECP3 FPGAs support an encrypted bit stream. Lattice uses industry standard encryption, AES 128-bit to protect the FPGA IP. The 128-bit key can be generated by the user and kept private from any external source, including Lattice. In the LatticeECP3, the 128-bit key is stored in a one-time programmable element. Once programmed, this key does not require any external voltage or battery to maintain its contents. The encrypted bit stream can still be observed and copied, but only a LatticeECP3 FPGA containing the identical 128-bit encryption key can be programmed with this bit stream. This makes the re-engineering significantly more difficult, because the internal FPGA information is no longer available in an easily copied format.

All device data can be encrypted with the AES 128-bit algorithm, independent of which boot method is used. When using a serial SPI Flash, no additional bit size overhead is added for the encryption. For the parallel configuration method, Lattice usually adds 25-50% overhead to the encrypted file size. When the encrypted bit stream goes into the FPGA, it will be decrypted internally. If an unauthorised user tries to read out the bit stream from the FPGA, only a logical ‘0’ will be visible. Figure 1 shows the overview of the encryption implementation for the LatticeECP3.

The 128-bit key is stored in a non-volatile area of the FPGA, meaning that no external battery is needed to store the encryption key. Lattice uses polysilicon fuses to store this key. These fuses are buried under ten layers of metal and are extremely difficult to access and isolate. More than one fuse is available per key bit. The combination makes it nearly impossible to find this key in the silicon with conventional techniques such as decapsulation of the device and trying to remove the silicon layer by layer. This key can also be programmed via the JTAG port of the device. An authorised user can program the device key themselves, or they can order the devices from the factory or distributor with their key already programmed (and custom marked) in the LatticeECP3 device. Once a key is programmed into the device, a customer can control how many boards are produced for their system, because the subcontractor can build only as many boards as encrypted devices are available. This prevents a manufacturer from overbuilding the system. Because of the encrypted bit stream, the system also can also not be cloned or easily reverse engineered.

Secured software system code using LatticeECP3 FPGA
Often designs require more than just the code in the FPGA to be secured. Some applications dictate that the operating and executing software of a design must also be protected. In these instances, an encryption enabled FPGA is an ideal foundation to allow such a design to be built. By utilising the LatticeECP3 and an embedded soft 32-bit processor with encryption, a cost effective, secure design can be built. When the operating software and data of a microprocessor must be secured, one must ensure the memory interfaces for such information are also secure. When a microprocessor executes its operating code, it does so by accessing flash or a volatile memory. If the signals between the microprocessor and memory can be monitored, then execution code and data can be readily copied. If the data to and from the microprocessor is not encrypted, then it can easily be copied and the entire system could be compromised.

To secure the software code, one needs to incorporate the microprocessor in the LatticeECP3 FPGA. Figure 2 shows an example block diagram. Lattice has a soft 32-bit microprocessor that could be used or any other FPGA targetable microprocessor or microcontroller would work in this design. For example, there exists 8051, HC11, 80186 and many more processors that can be fit in an FPGA. With the incorporation of the microprocessor the data to and from the external flash and system memory must still be secured. This is done by converting the execution code and data to an encrypted format. So in addition to the microprocessor, the LatticeECP3 would also incorporate an AES encryption and decryption core. By utilising this core, all software code and data that is written to or read from either flash or main memory will be secured.

Lattice has worked with a 3rd party encryption IP provider called Escrypt who has a family of AES encryption and decryption cores. These cores vary in size and performance. The throughput of the design will dictate the IP core size and its performance. For example, if a design does not have significantly fast throughput needs, then a smaller core could be utilised. In general, the smaller the encryption and decryption core is, the slower it will execute and convert the data. If very low latency performance is needed in the design, then a larger IP core will be required such that only 1 clock cycle of delay will be experienced. Table 2 shows a sample variety of Escrypt encryption and decryption cores. Their size and throughput is noted for the slowest speed grade LatticeECP3-70 device.

Once a design has the microprocessor incorporated and the desired throughput is determined, then the appropriate encryption and decryption core can be selected. These two blocks will dictate the minimum FPGA size needed to be utilised. For example, if a design incorporates an 80186 microprocessor and its full performance is required, then the largest Escrypt AES Pipelined core will be required. This core operates in only 1 cycle of operation yielding the maximum possible performance for the system. For this design, the AES Pipelined core consumes 28,000 LUTs and an 80186 about 4,000 LUTs for a total of 32 K LUTs. The LatticeECP3 family spans from 17 K, 35 K, 70 K, 95 K up to 150 K LUTs. If the ECP3-70 were used in the design, the designer would have more than 30,000 LUTs to implement the rest of their design. The additional FPGA size cost for incorporating the processor and encryption core can easily be recouped by being able to maintain higher end product margins.

One last security measure that is also available from Lattice is a custom marked device. As stated previously, the 128-bit encryption key of LatticeECP3 can be programmed by the user. However,a pre-programmed device with a special marking from Lattice or the distributor could be ordered. Using a custom marked device and encryption offers even more protection for IP and overall design. All of the previously mentioned security features provide the best protection against reverse engineering, cloning, overbuilding and theft of service attacks.

Ted Merena is the Director of Field Applications, Europe & North America for Lattice Semiconductor.

Contact Details and Archive...

Print this page | E-mail this page

This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.