Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

Most people may strive for moral and ethical righteousness. But it's still a scary world, especially when it comes to technology. Laptops and hard-disk drives with valuable and confidential commercial information seem to be stolen every day. Mainframes containing similarly sensitive data are routinely hacked. Certain semiconductor companies are overproducing chips to later sell on the black market. And it's only getting worse.

Viruses, financial fraud, computer theft, and network intrusion cost U.S. businesses $67 billion a year, according to a January 2006 report from the FBI. Likewise, a 2006 survey from the Ponemon Institute, Vontu Inc., and PGP Corp. says the average business loss from unauthorized data access grew 31% to $182 per compromised record. The total cost to each business ranges from less than $1 million to over $22 million, with an average of over $4 million.

Yet Gartner VP Avivah Litan says a company with 10,000 accounts can spend an up-front cost of $6 per account to encrypt its data and up to $16 per account for more sophisticated security.

Compared to Ponemon's $182 figure, recovering from data loss costs 11 to 30 times as much as prevention. So what does it take to make your next product more secure? Commodity IP may be a good place to start.

THE IP IS OUT THERE
Plenty of algorithms are available in IP form for designers to use in their ASICs and FPGAs (see "Security IP Definitions"). But cryptography algorithms are a lot like sports records, only lasting a few years before they're broken. A few standards have achieved some longevity, though.

• Advanced Encryption Standard (AES): Based on the Rijndael (pronounced "Rhine Doll") algorithm, AES is the official U.S. federal government standard for information technology encryption as adopted by the Computer Security Resource Center (CSRC) of the National Institute of Standards and Technology (NIST). This symmetric key 128-block cipher and successor to the Data Encryption Standard (DES) also is used in the private sector worldwide.

Listed as Federal Information Processing Standard 197 (FIPS 197), AES was selected by the government because of its resistance to linear and differential cryptanalysis. Key sizes include 128, 192, and 256 bits. While 128-bit keys can be used for information classified by the government as "Secret," "Top Secret" classification requires 192- or 256-bit keys. To date, only side-channel attacks have been able to break AES.

• Data Encryption Standard: Adopted in the 1970s as a FIPS standard, DES is now considered too insecure for most applications, as its 56-bit key can be broken in less than 24 hours. Yet it's still used today, and Triple DES (known by several names and available in several varieties) was designed to overcome some of its flaws. While AES is supplanting its use, DES sees prolific use in e-commerce and smart cards.

• RSA: Named after inventors Rivest, Shamir, and Adleman, RSA is an asymmetric key-based algorithm suitable for both authentication and encryption. Its usage normally is governed by one of the Public Key Cryptographic Standards (PKCS), which are non-industry standards. Since the RSA algorithm depends on the product of two large prime numbers, it can be broken in less time than other algorithms using smaller key sizes. For example, when compared to AES using a key size of 256 bits, the RSA key size would need to be roughly 13,500 bits¹.

• Secure Hash Algorithm (SHA): This standard is a collection of several algorithms that employ secure hashing. Five of these algorithms are FIPS-approved under publication 180. Hashing is the process of taking a string of arbitrary length and producing a fixed-length string as output. Designed to supercede the MD5 cipher due to its relative insecurity based on lack of collision resistance, hashing is suitable for authentication and message integrity.

The full version of SHA-1 can be compromised in 2⁶³ operations, as compared to SHA-1 brute force attacks that withstand on the order of 2⁸⁰ operations. At 1 million operations per second, 2⁶³ operations would take roughly 292,000 years to break. But experts fear a more sophisticated attack can be found based on the current one using a large network of computers. That's why NIST recommends using a SHA-2-based cipher.

• Elliptic Curve Cryptography (ECC): This asymmetric key cipher comprises algebraic constructs known as elliptic curves based on the equation y² = x³ + ax + b or some similar variation. Bit for bit, ECC is considered both more efficient and secure than RSA.

ECC hasn't been vulnerable to sub-exponential attacks to date, so it's being adopted in both authentication-based (normally as ECDSA) and encryption-based algorithms. The Standards for Efficient Cryptography Group (SECG) is the governing body for some ECC-based algorithms.

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."

For more, see "Integrating System-Wide Security Into SoC Designs"; "The Key To Security"; "Five Things To Know About Security In Silicon"; and "Connecting Security IP Decisions To Chip Cost".

REFERENCE
1. Cryptography for Developers, Tom St. Denis of Elliptic Semiconductor Inc. and Simon Johnson, Syngress Publishing Inc., 2007