For a while I have been looking very closely at how FPGA cores are distributed (the common term is “IP cores”, or just “IP”, but I try to minimize the use of this over-used catch-all catch phrase). In what I hope to be a series of posts, I will mostly discuss The problem (rather than solutions), as I think that that needs to be addressed and adequately defined first. I’ll start with my attempt at a concise definitions of the following:

FPGA: Field Programmable Gate Arrays are generic semiconductor devices comprising of interconnected functional blocks that can be programmed, and reprogrammed, to perform user-described logic functions.

Cores: ready-made functional descriptions that allow system developers to save on design cost and time by purchasing them from third parties and integrating them into their own design.

The “cores distribution problem” is easy to define, but challenging to solve: how can a digital design be distributed by its designer such that he can a) enable his customer to evaluate, simulate, and integrate it into its own, b) limit the amount of instances that can be made of it, and c) make it run only on specific devices. If this sounds like “Digital Rights Management” to you, that’s exactly what it is: DRM for FPGAs. Despite the abuse of some industries that made a bad name for DRM, in our application there may be benefits for both the design owner and the end user. We also know that enabling the three conditions above for a whole industry is challenging, and we are not even close to a solution.

The problem isn’t new, ASIC cores designers have been having trouble with this issue for years: run-on-fraud, copying, etc. The solution they arrived at is mostly based on trust and good reputation—valuable assets that are slowly gained yet easily lost—rather than cryptography. Big companies shaking hands with other big “trusted” companies relying on the potential reputation loss as an acceptable guarantee for honesty (plus a legal document). Apparently, this still works well for big companies, and while cryptographic solutions would be nice in order to alleviate the need for trust and provide for smaller companies world-wide, there is no real rush. “Panel unscrambles intellectual property encryption issues” has a very revealing discussion from the industry’s perspective and is well worth the read.

Back to FPGAs, with their unique use model, the trust-based system holds here as well; established companies can afford to purchase a blanket license for cores, are trusted, and that lets them use those as they like. You might have a problem, though, if you are a small and obscure company. As a poor start-up designer, you want to save time and money by taking advantage of “design-reuse”, but you can’t afford blanket licensing, and you may not be big enough, or in the right country, to be trusted even if you sign the NDA/licensing agreement. So, you either spend the time developing the design in-house, perhaps missing that three month opportunity window, or you give up. FPGA DRM could help you here because it will enable a pay-per-use model. You will be able to pay only for the instances of the core you use regardless of your company’s “trust status”, starting with small quantities until you hit it big. In turn, pay-per-use also benefits cores designers by giving them business that they wouldn’t have gotten otherwise. Both sides win. Sort of. More in Part 2.

A project called NSA@home has been making the rounds. It’s a gem. Stanislaw Skowronek got some old HDTV hardware off of eBay, and managed to create himself a pre-image brute force attack machine against SHA-1. The claim is that it can find a pre-image for an 8 character password hash from a 64 character set in about 24 hours.

The key here is that this hardware board uses 15 field programmable gate arrays (FPGAs), which are generic integrated circuits that can perform any logic function within their size limit. So, Stanislaw reverse engineered the connections between the FPGAs, wrote his own designs and now has a very powerful processing unit. FPGAs are better at specific tasks compared to general purpose CPUs, especially for functions that can be divided into many independently-running smaller chunks operating in parallel. Some cryptographic functions are a perfect match; our own Richard Clayton and Mike Bond attacked the DES implementation in the IBM 4758 hardware security module using an FPGA prototyping board; DES was attacked on the FPGA-based custom hardware platform, the Transmogrifier 2a; more recently, the purpose-built COPACOBANA machine which uses 120 low-end FPGAs operating in parallel to break DES in about 7 days; a proprietary stream cipher on RFID tokens was attacked using 16 commercial FPGA boards operating in parallel; and finally, people are now in the midst of cracking the A5 stream cipher in real time using commercial FPGA modules. The unique development we see with NSA@home is that it uses a defunct piece of hardware.

Let me explain why this is important. The Virtex-II PRO FPGA—the one used by NSA@home—was introduced in 2002, only about five years ago. It is spec’d at about 400 MHz while today’s latest FPGAs, two generations later, are spec’d at around 550 MHz. So we have not gained that much in speed, but rather in size, specialization, and integration of embedded interface functions such as fast serial transceivers, Ethernet MACs, more embedded memory, etc. But if you want only plain logic and memory for parallelism, the old dinosaurs of a few years ago are still very much relevant, especially if you can get them for next to nothing and someone already took the effort to design the PCB for you. Hobbyists are (extremely) displeased that the dense ball grid packages put them out of business, so to speak (and that the FPGA vendors do not care so much about it, which is another discussion). So, with FPGAs being used in ever more applications, I see this type of recycling becoming more popular. When will we see an enterprising student create a Logic-101 lab from recycled consumer electronics?

The other interesting aspect of NSA@home is the trade-offs. Much like Clayton and Bond, Stanislaw is checking subsets of the hash, places them within ranges, and leaves the final checking for the host PC; he could barely fit an unrolled, pipe-lined SHA-1 into each FPGA, so that trade-off was necessary. Another important aspect is the realization that FPGA resources are still there even if you do not use them. Usually, you would try to minimize the resources you use in order to make room for other functions; or, try to fit your design into a smaller FPGA and save money. But when you have a single application, and a given device size, you should try to use all at your disposal. This designer decided to use the embedded block RAMs, which would otherwise be unused, as look-up tables. Good job.