Is Your FPGA Design Secure? Use Xilinx to Make Sure

I hope your Christmas break is starting off well! You know this, but evil takes no break for Christmas. We are seeing more and more the hacking of systems and it seems to have become the norm. Do you get nervous anymore when you hear that your credit card company lost their data? Or I mean your data?

It’s as if we have given up on the ideas of privacy and security or that they are something that cannot be obtained. North Korea is not as stupid as we thought, eh? Will we actually see market crashes? Power grid failures? Will the ‘news’ be hacked? To say the least these are interesting times and probably will not get better anytime soon.

More important than ever, depending on your application for your Xilinx FPGA, security and Anti-Tamper (AT) may be more important as ever! Think of applications like High Frequency Trading (HFT), RADAR, Medical, Power Control, and Data Centers which Xilinx will start gobbling up due to their innovative OpenCL solution called SDAccel.

To start, security and the likes are not seasonings that get sprinkled on at the end of your design. Security is a methodology that must be in lock step with the Xilinx FPGA design and the systems in and around the FPGA. To mess up here is to have a very unsecure, but often a very expensive design. Now is the time to get familiar with what Xilinx has to offer as the leader in FPGA security. To begin, May I recommend reading the Xilinx web page on ‘Design Security Solutions’. Here is just the beginning into the world of Secure Xilinx designs. I will call your attention to three key documents:

· XAPP1084 – Developing Tamper Resistant Designs with Xilinx Virtex-6 and 7 Series FPGAs
· WP365 – Solving Today’s Design Security Concerns Using Spartan-3 Generation FPGAs
· WP412 – The Xilinx Isolation Design Flow for Fault-Tolerant Systems

There is a lot of meat here, read carefully and slowly. The three areas to keep in mind are prevention, detection and response. For example, we can encrypt the bit stream to prevent a first order attack from being successful. Detection can be very elaborate or very simple by monitoring voltages and temperature. When a attack is detected what do you want to happen? Erase the bit stream? Load a new image to start recording the attack? Some of you may be asking is all this really necessary? Until my eyes were opened, I would of asked the same question years ago. Given the Internet of Things, the ‘Cloud’ and everything flowing over wireless data pipes I would say yes, 100% you need a secure FPGA design. XAPP1084 sums it up best:

The decision as to how much AT to include primarily depends on three factors:
• Value: The perceived value of the intellectual property and the damage it might cause either financially and/or to national security if it were to become compromised. Certain AT features can be expensive to implement and that cost must be weighed against the value of the technology being protected.

• Adversary: Access to the system and the sophistication level/resources available to carry out the attack. For example, will access to the system be prevented by “guns, gates, and guards” or will it be easily obtained in the open market? Is the adversary a garage-based hacker or a nation-state? The adversary’s capabilities could be at these extremes or anywhere in-between.

• Design Stage: At what point in the system development cycle is the decision made to enable AT for the FPGA design? Xilinx highly recommends that the decision to utilize FPGA AT features is made very early on (i.e., after CT is defined in a system) to help address both schedule and cost concerns. It is always more costly and time consuming to insert AT features later on.

You can Trust and Count on Xilinx not only for the World’s Finest FPGAs and Tools, but also for your next Secure FPGA design.