There are only two ways to make data secure: You can lock it up or you can make it unusable by people you don’t want to ever see it. Some of the military and intelligence networks are locked down behind guarded fences in closed-loop networks. There’s no way to connect that data to the outside world short of smuggling it out on a disk or Universal Serial Bus (USB) drive. In other scenarios, the security is embedded inside a ruggedized chip. In almost all cases, however, it’s nearly impossible to crack into the data because it’s physically isolated.

For the rest of the digitized world, security is a much bigger challenge. In the business arena, e-commerce relies on open and often global connectivity. Doing business across international borders isn’t uncommon. Patterns can be established to determine the IP address where a person usually does his or her banking, identify the operating system normally used, and even pinpoint the resolution of the monitor. Yet that information almost always needs to be accompanied by some form of encryption.

Encryption of some sort isn’t a new idea, of course. Early cryptography dates back at least 4500 years ago and probably well beyond that. Some information has always had a value, which is why most of the sensitive data in the business world uses at least some form of encryption. The security features are embedded within applications and the hardware itself to safeguard such things as computer authentication at login, money transfers, corporate e-mail exchanges, and personal information involving credit cards, identity, or medical records.

In most cases, that encryption is invisible to the user. In the corporate world, company employees simply log into a corporate network, where data already is encrypted. The employees are given their own key for decrypting that data—whether it’s done virtually or with a physical device that has the security key embedded into it. In many cases, those keys can be programmed to include the employee’s level of security clearance. A CFO would have access to almost all records, for example, while a salesperson would have a completely different set of permissions.

Several years ago, the encryption/decryption process was handled by separate processors because it could have a significant impact on the performance of a computer’s central processing unit (CPU). Some of the security is still handled in hardware, such as login information that automatically kicks in when a computer is booted up. Yet much of it is now being handled in software.

Multicore chips are at least partly to blame for that shift. Having multiple cores on a chip is particularly useful for the encryption and decryption of data. While most applications don’t scale particularly well, embedded security does because it’s largely based upon algorithms that can be parsed onto different cores. Perhaps even better, embedded security operations can run in the background on unused cores. This aspect actually speeds up the entire compute session because the encryption/ decryption is being run simultaneously on the same chip as the application that interacts with it, such as e-mail.

“The nice thing about multicore is we can parallelize encryption on multiple cores,” explains John Callas, chief technology officer at PGP. “We used to have to do this in specialized hardware. Now it can be done with general software.” According to Callas, Intel is building instructions for the Advanced Encryption Standard (AES) into its new multicore CPUs. The result will be blazing-fast encryption of a disk along with the ability to manage it remotely.

AMP Vs. SMP

How encryption software takes advantage of those cores is a matter of preference. Some use a symmetric multiprocessing approach. But Team F1 co-founder Mukesh Lulla says the real speed advantage uses asymmetric multiprocessing. “With asymmetric multiprocessing, you get the effect of dedicated cores. It’s not hard-wired, of course, so you could use the cores for other things. But you can leverage them to their maximum benefit.” Lulla comments that IP security (IPsec), a standard suite of security protocols, has been tested using as many as 32 cores. The problem is that most implementations of the software utilize the lowest common denominator of complex hardware configurations. As a result, performance isn’t always as fast as it could be.

Nevertheless, Bill Lattin, Certicom’s chief technology officer, comments that multicore chips have proved to be particularly popular in the security world because they provide the raw horsepower necessary to run security applications in software instead of hardware. Software is by far the less expensive solution to develop and distribute. “Hardware is much more difficult to attack, which is why you see it for military applications and very sensitive data,” Lattin explains. “You also see it with the Trusted Platform Module, which is a hardware device used to verify a PC in a known state when it boots up.”

Yet software is much easier to develop and customize, which is why software-based cryptography is being embedded in radio-frequency-identification (RFID) tags. Texas Instruments, for one, has developed tags that are used in pharmaceuticals to make sure that they’re being sold through a legitimate channel. It’s also being used in personal-identification chips on passports, devices like the Blackberry, and Blu-ray disk players to make sure that intellectual property is being protected.

Typically, cryptography is broken down into two parts. One is the algorithm used to encrypt data. The second is the key, which is used to lock and unlock that data. The key can be embedded into a USB-based device. Or it can live on the client or server with access restricted through various schemes. Once the key is shared between both sides of a transaction, encryption can occur at speeds of gigabits per second.

Compatibility Issues

The problem in systems that employ security is that not all of the parts are 100% compatible. According to Lulla at Team F1, standards like IPsec, secure socket layer (SSL), and other low-level cryptography are relatively worked out—unlike several years ago, when the combination of all of those standards created compatibility issues. “The scrambling and de-scrambling is okay,” he says. “It’s how you piece it together. If a message is sent by one side, the other side of the device may not be compatible.”

Even when the pieces do work together, they don’t always work at the same security level. “The real issue is the strength of the encryption,” points out Certicom’s Lattin. He says that the 128-bit Advanced Encryption Standard (AES) kit, for example, needs to be used with 3072-bit RSA technology. But most companies use only 1024-bit RSA. (RSA is an algorithm for public-key cryptography). “That’s like adding a steel door and leaving the key in a plastic box on the front porch.”

Ed Sperling is Consulting Editor for Chip Design magazine. He is the Editor-in-Chief of the “System Level Design” portal. Ed has received numerous awards for journalistic excellence.