INTEGRATING SECURITY IP In many cases, the end application will dictate the type of algorithm or algorithms required—or at least narrow the field of choices. When designing a "Top Secret" military communications system, choices may be limited to AES192 or AES-256 ciphers. If you have more liberty for your system's security, consider using a decision tree and table to determine which ciphers will best suit your requirements (see the figure and Table 1).
Then, there will be a very important decision to make— should the cipher be implemented in software or hardware? When it comes to security, the choice isn't as simple as analyzing speed, area, and power tradeoffs.
Suppose you use an ASIC to implement security on your new widget and deploy millions of your widgets around the world. Just when you're counting all of your money, your favorite news site reports that a serious flaw has been posted all over the Internet. It's time for a total recall.
Implementing a cipher in software, however, is generally more insecure. Memory often is shared between programs. The application code may be changed. And, the operating system or underlying application software itself likely will have security holes.
Since most advanced ciphers are considered unbreakable in a "reasonable" amount of time (except perhaps from sophisticated side-channel attacks), you should focus on overall system security. After all, the best cipher in the world can be "broken" if the cryptographic key is readily available in off-chip memory or can be shifted out using the JTAG port. In securing your overall system, maximum paranoia and devil advocation are in order.
SECURITY IP SHOPPING LIST If you've gone through the tradeoff checklist and decided a hardware implementation is the way to go, there are some options to consider. IP ranges from free open-source cores to very expensive integrated IP blocks with significant up-front licensing and royalty fees (Table 2). And with IP, you get what you pay for.
Next, you need to decide if you want the RTL code so you can make tweaks or just the netlist implementation. Yet tweaking the base cipher risks creating a security hole that may be exploited. If such tweaks are desired, work closely with the IP vendor to make them.
As with other IP, find out if and how many times a given block has been successfully deployed in silicon for the platform you're targeting. Often, IP vendors validate security ciphers using test vectors recommended by the standards body. For instance, FIPS-197 includes recommended test vectors.
You may even want to ask for a few references to call and find out how easy the IP was to integrate, if any bugs were found, and so on. Also, find out how much support can be expected and for how long. Before you buy, ask if the support is proactive and if the company works with you from concept through manufacturing, or if it is more reactive and you're expected to do most of the integration and tweaks yourself. With a royalty-based approach, better support is the norm, whereas with open-source IP, you're mostly on your own.
If you're considering implementing the IP block in an FPGA, you may want to use one designed specifically for the FPGA family you're targeting and not one that was simply re-synthesized from a generic design. This approach takes advantages of specific family resources and will allow for a more flexible design at a similar performance level compared to an ASIC-based implementation.
"In a changing world, where new threats to security can occur at any time, FPGAs [offer] a very persuasive platform on which to enable the security aspects of a new product," says Graeme Durant, CEO of Helion Technology. "As an example, we've seen several security standards in recent years switch algorithms at the last minute, reinforcing this approach as being the way to go."
Reprints
