You bring a new product to market, and, within weeks, a rival appears, one that is clearly a rip-off of your design: not just looking like yours or performing much the same functions, but actually a clone of your design. There are shed-loads of statistics that show that the problem is increasing within the electronics industry and a mass of anecdotal evidence that indicates that designs using FPGAs are being increasingly targeted.
As FPGAs have moved from simply mopping up glue-logic to becoming full-blown Systems on Chip (SoCs), so they now embody the key Intellectual Property (IP) of the end product. The amount of design work to create them is considerable, and this has made them very attractive as a target for IP theft. After all, if you steal a design from someone foolish enough to leave it lying around for you to pick up, then it is possible to bring a copy to the market for a lot less than the designer invested. Many markets, particularly consumer markets, are very price sensitive, and some elements of the supply chain around the world are not overly scrupulous as to where the design originated.
So what are the issues for an FPGA user, and what tools have the FPGA manufacturers supplied to help you safeguard your design efforts?
If you have a “volatile” or SRAM-based FPGA, where the configuration data is stored in external memory and downloaded to the FPGA every time the system boots up, then there is a dataflow between the memory and the FPGA. Potentially this dataflow can be intercepted and used to configure multiple, illegal copies. Actel, whose devices do not need to be configured from external memory, have regularly pointed out that this can be seen as a significant point of weakness in their competitors’ products.
To circumvent this weakness, both Altera and Xilinx have introduced encoding to their larger devices. The external memory, earlier PROM and now usually flash, holds the configuration data in encrypted form, and the target device carries out decryption. Both companies use Advanced Encryption Standard (AES) 256-bit encryption for this. The US Government, and others, uses AES for encrypting material with a security rating all the way up to Top Secret. Encrypting with AES requires a complex series of encoding steps, and decrypting requires another equally complex series of steps using a 256-bit key.
On Xilinx Virtex II families onwards, the key is loaded through a JTAG port, and an external battery or other power supply is required to maintain the key. If the device loses power, then a replacement key has to be loaded. In the Virtex 6, external power can be used or, in an interesting move, you can use eFUSEs to store the key permanently. Altera has introduced a similar AES-based approach with the Cyclone III.
Both manufacturers provide techniques to stop the key being read through the JTAG port used for programming.
Encryption introduces complications to the manufacturing process. Obviously, it makes no sense to hand both the encrypted configuration data and the key to the same programming house. That is inviting them to either run on a few extra copies or hand both data and key over to a friend. Normally, developers will have the key programmed in the FPGA by one sub-contractor and the configuration data programmed into memory by another.
Some FPGAs have a factory-programmed serial number; for example, Xilinx provides a 57-bit “Device DNA” for some Spartan and Virtex devices. This number can be used for inventory control and as a part of a key for encryption: if a bad guy gets hold of the configuration data, he still needs devices with the right serial numbers to use the key.
Xilinx did try another route with the Spartan-3AN when it combined the external memory and the FPGA in a single package. This made it more difficult, although theoretically not impossible, to tap into the configuration stream. (See Short Stack with Syrup.)
Actel, with non-volatile solutions, doesn’t have the problem of the configuration data stream. (And isn’t that exploited in marketing material!) There are two Actel technologies: the original antifuse approach and the low-power flash technology.
In an antifuse-based FPGA, only a small percentage of the antifuses are programmed – Actel says only 2-5% of the 53,000,000 antifuses in the flagship AX2000 are programmed. Determining by physical examination if an antifuse has been programmed is difficult – physically, a programmed antifuse looks very much like an un-programmed one. Determining which of 53,000,000 have been programmed is so difficult that realistically it is impossible.
The security risk comes when programming the device, particularly in volume. Again the programming file can be encrypted and decrypted on-chip using a key. In this case the developer provides the programming house with the encrypted stream and puts the key on the devices themselves or at another programming house.
Actel’s other non-volatile approach uses flash technology, with flash switches replacing SRAM or antifuses. There is no visible difference between a programmed and non-programmed switch, and electrical probing of a flash-based switch may destroy the charge on the floating gate, making it very difficult to impossible to determine the state of a single switch. Again, the sheer scale of the numbers makes flash-based FPGAs basically impervious to reverse engineering.
Many of the flash devices from Actel have an area of user-programmable FlashROM. This can house a cipher key, which can be unlocked to allow re-programming or permanently locked to prevent re-programming. The ProASIC3 can also use a 128-bit AES key for protection against overbuilding, as with Xilinx and Altera. This same key can be used for secure remote reprogramming; for example, upgrading a product in the field using internet access. The FlashROM can also be used to provide serialisation for inventory control and device tracking.
Programming Actel devices is also normally through a JTAG interface, and debugging during development may also use JTAG. If there is to be no in-service programming, then JTAG can be de-commissioned, by blowing security fuses, after the FPGA has been configured.
Altera addresses a different kind of security with Cyclone III AS. Systems often employ redundancy to provide increased security in the field: for example, two copies of the same hardware running the same software in case one fails. Equally there may be a need for different applications to run in their own, physically isolated area, so that information cannot flow from one to the other. With the Cyclone III LS, Altera claims to achieve physical separation, but within a single device, reducing board size and component count.
All the FPGA companies also offer IP, their own or third-party, that provides security for data during use. For example they all provide AES encryption/decryption so that data streams in use in applications can be protected. But the different approaches to this would be the subject for another article.
Security in normal life is always a trade-off: a determined intruder can always get into a house, but he will balance the time and effort that is needed to circumvent the security in place against the likely rewards that will be achieved. The householder, by making life as difficult as possible for the intruder, will hope to deter them sufficiently that they will go to a neighbour’s house. At the same time, a householder doesn’t want to spend five minutes with locks, bolts, and alarm systems every time they enter or leave.
With FPGAs, you pays your money and you takes your choice. It seems that if you want in-service programmability, then you are going to have to accept that you can only slow down the intruder. If you want to nail down every window and door, then you will lose the freedom to re-program in the field. But who said life is easy?