Gearing Up For The Next Round Of Security Processors

Gearing Up For The Next Round Of Security Processors
By Loring Wirbel, Communication Systems Design
January 18, 2002 (11:25 a.m. EST)
URL: http://www.eetimes.com/story/OEG20011112S0066

When a second generation of general-purpose network processors fell in behind the Xaqtis, C-Ports, and SiTeras of the world, founders of the new companies had two basic options. Some chose to offer an all-encompassing packet-forwarding chip set that emphasized high performance, handling multi-dimensional header analysis at rates of 10 Gbps and above. Others wanted to drill down to a specific header-analysis or traffic-management function, with the hope of winning a socket for deep-classifying or fine-grained QoS that functioned alongside the primary packet processor.

In the network security realm, the newcomers falling in behind pioneers like Hifn, Inc., Chrysalis-ITS, and Broadcom Corp.'s Blue-Steel group, can take many different paths to perform security functions at several levels. Some still focus on improving bulk file encryption, expanding support for public-key algorithms, and adding hard-wired processing for the new advanced encryption stand ard (AES). Many micro-programmable engine specialists are concentrating on the Internet protocol security (IPSec) standard, looking at secure tunnel creation, VPN establishment, and embedded encryption support, in order to put the bulk of security on the data-link and router layers of the OSI security stack.

And an increasing number of players are opting for an immediate leap to TCP session management and hard-wired support for secure sockets layer (SSL) processing. This model assumes that the biggest market to exploit in designing access devices is that of the business or residential client desiring secureweb transactions in a public or extranet environment.

To SSL processor supporters, a focus on IPSec, public key infrastructure (PKI), and user authentication is a certain aim toward a narrow niche. Since all clients and servers must be outfitted with specialized security equipment, the layer 2 and 3 approach is necessarily limited to an enterprise intranet, at least for now. But since all major web browsers support SSL, chip developers can sell into a market with a volume base from day one.

No Shortage Of Approaches

There's certainly no shortage of approaches. In the first quarter of 2002, new security processors will be arriving from Cavium Networks, Inc. (San Jose, CA), NetOctave, Inc. (Morrisville, NC), Corrent, Inc. (Tempe, AZ), and Layer N Networks, Inc. (Austin, TX). Existing players like Broadcom and Hifn will be expanding their security offerings in the same time frame.

The landscape looks far different than early 2001, when Chrysalis-ITS announced it would abandon the network-security chip market, eliminating its Luna processor before it sampled. Meanwhile, SafeNet, Inc. announced it would move to an intellectual property licensing model, for the work on security processors it performed with Analog Devices, Inc.

Two successive events in the latter half of 2001 changed the outlook for network security. During the course of the summer, worms and viruses like Code Red and SirCam penetrated not just corporate America, but even the government servers formerly thought to be secure. Suddenly, IT managers at large corporations took internal and extranet security far more seriously than they had in the past.

And of course, the terrorist attacks of September 11 changed the consciousness of the nation, perhaps permanently. Just as intense searches and scans have become a regular part of the airport experience, corporate IT managers are now expected to protect resources with a full arsenal of firewalls, user authentication methodologies, regular encryption of data files, distribution of keys for digital signature and authentication, and secure transactions over the web. If one layer of defense doesn't cut it any more, then perhaps one approach to embedding security functions in silicon is inadequate, as well.

Some highly-optimized programmable and hard-wired architectures will be demonstrated this winter, with a few claiming specific benchmarks for numbers of SSL or Rivest-Sha mir-Adelman (RSA, a public-key algorithm) operations per second. While the silicon designers pushing the edge of parallel processing may be proud of certain numbers, many developers are already warning against an approach that is too reliant on specmanship.

John Davis, chief system architect at Corrent, and Glen Anderson, founder and chief scientist of system security OEM Andes Networks Inc., both warn that focusing too heavily on specific numbers may blind access-system designers to what is required from a network security processor overall.

Syed Ali, president and chief executive of Cavium, said that even though SSL acceleration may win the most attention over the next few months, a security-processor vendor cannot afford to ignore the important IPSec market for expanding the use of VPNs. The two applications are complementary and of equal importance, Ali said, which is why his company chose a flexible, high-performance crypto engine called GigaCipher at the heart of its new Nitrox processor (see Figure 1).

Security From The Bottom Up

Both the layer 3 IPSec approach and the layer 4/5 SSL acceleration approach represent a grand departure from the 30-year-old history of encrypting bulk data files, a method that might be considered a physical layer (PHY) approach to enciphering bits during transmission.

Encryption in the commercial world was a hit-and-miss affair until the federal government proposed the data encryption standard (DES) in the mid-1970s. While critics charged that IBM had worked with the National Security Agency (NSA) to deliberately hobble DES, the algorithm proved efficient enough to implement in silicon that several companies made a good 20-year business of DES. VLSI Technology, Inc.'s secure products division, now a part of Philips Semiconductor, was a DES pioneer, and Hifn, Inc. started the company based on a focus on both symmetric and asymmetric key encryption.

DES and similar government -sponsored encryption algorithms are based on symmetric systems, where both encryption and decryption keys must be kept secret.

In the late 1970s, several researchers, including the Rivest-Shamir-Adelman team and the Diffie-Hellman team behind D-H key exchange, proposed new public-key asymmetric systems. These public-key systems allowed the encryption key of a user to be published in the open, since decryption keys could only be determined from encryption keys through various difficult factoring operations.

Hardware support for public-key encryption was challenging in the early days, due to the memory and CPU-cycle requirements of asymmetric keys. But often, arithmetic blocks developed for the keys could also be put to use implementing secure hashing algorithms (which protect data integrity). Thus, many early crypto chips had built-in hashing support.

In the early 1990s the NSA briefly tried to promote a managed-key silicon approach with its Clipper/Capstone program. Though the effort foundered d ue to user suspicions of the intelligence agency, the effort to develop Clipper/Capstone ASICs bore indirect fruit. The founders of Mykotronx, a small company that developed the initial chips for the NSA, sold their operation to Rainbow Technologies, Inc., and later went on to positions in VLSI and Intel. Richard Takahashi, founder of Mykotronx, now serves as president of Tempe, AZ security startup Corrent.

In recent years, the federal government has put its weight behind an update to DES, which is arriving in the form called AES. Several players, including Hifn, Broadcom, Corrent, and Cavium, have pledged support for AES, indicating the market for bulk encryption devices will stay strong, even as more advanced and special-purpose silicon engines emerge.

Tunnels and VPNs

Long before interest in secure web transactions emerged, the notion of allowing secure access to corporate computers for telecommuters drove the creation of VPNs. These systems would use combinations of encryption and head er analysis to create temporary tunnels in which secure IP flows could take place between end user and central system. The first startups in this area, including VPN Systems, Inc. and Red Creek Systems, Inc., used software or dedicated ASICs to perform these functions. A variety of proprietary protocols operating at layer 2, most notably layer 2 tunneling protocol, took on the task of early VPN establishment.

In the late 1990s, however, VPN tunnel creation was brought directly to the heart of the routing environment through the standardization of a suite of protocols within IETF, called IPSec. This suite specified standard ways that extensions of IPv4, and standard protocol portions of IPv6, could carry out packet-level authentication, embedded encryption, and key management. The relationship between the sender and receiver of tunneled data is called a security association (SA) and the number of SAs supported in silicon has become a standard benchmark.

Because a layer 3 solution standardizes security at a higher layer, and builds on the popularity of IP, IPSec is being adopted more rapidly than earlier layer 2 tunneling protocols. And because the standard does not specify encryption algorithms, the flexibility of IPSec is a natural for programmable silicon.

Existing encryption specialists were some of the first in the market - Hifn with its 78xx series of processors, and Analog Devices, Inc. with SafeNet, Inc. (at the time, known as IRE, Inc.) with the SafeNet products.

While the popularity of VPNs has been skyrocketing in recent quarters, the popularity of IPSec still depends on solutions being implemented at both client and server. The potential has been enough to warrant new startups such as Corrent, Cavium, and NetOctave being founded with an initial focus on IPSec. But the drive to move to common client platforms has caused a new stir in a higher layer of security - a direct approach sitting between layers 4 and 5, that has generated its own new cloister of security processor startups.

SSL And Web Transactions

When Netscape, Inc. still existed as an independent company, it worked with RSA and several hardware security specialists to develop a special sockets software function that rode across a TCP session layer. The function, known as SSL, was rapidly adopted by Netscape and Microsoft, and has become a de facto standard for secure web transactions. Since many of the functions used in setting up SSL utilize key management from the asymmetric public-key encryption world, there are commonalities with crypto accelerators that can readily be adopted for SSL acceleration.

Several companies were founded in 2000 with a primary focus on SSL acceleration: Layer N Networks, Inc. on the chip level, and Andes Networks, Inc. on the system level, among them. Others rapidly adopted SSL-specific projects, including Hifn, Corrent, and NetOctave. And a debate rapidly emerged on whether it makes more sense to keep security engines as flexible as possible, to handle a range of IPSec and SSL dut ies; or to dedicate a hard-wired engine specifically for SSL tasks.

This could be the most critical silicon debate for security in 2002. Since SSL requires much more detailed analysis and processing of session states, the role for hard-wired engines and embedded state machines can be rationalized far more than with IPSec.

There are nuances to the approaches, of course. Cavium has staked out what may be the most extreme position on programmability. Although it offers several versions of its core Nitrox architecture, the family of chips uses a common GigaCipher core, in which the core processor can be dynamically re-allocated for encryption, hashing, tunnel creation, and SSL session tasks.

Corrent and NetOctave are two examples of companies that have created dedicated programmable architectures optimized for IPSec and SSL tasks. Corrent's former family is called PacketArmor, while the upcoming SSL-specific family to sample at year's end is called SocketArmor.

Corrent's Davis said that with cryp to algorithm specialists on board at Corrent from companies such as VLSI and Intel, there was no need to stake out the extreme case of requiring a state-machine processor for SSL acceleration.

A SAN approach

NetOctave similarly has spun its NSP2000 for SSL, and NSP3000 for IPSec, respectively. NetOctave further optimized chips for target markets at the October Microprocessor Forum, by introducing a chip developed specifically for IP-based storage area networks (SAN). Joe Ardini, NetOctave's vice president of strategy and business development, said that storage networks display special characteristics for security: a high percentage of large packets, a relatively small number of TCP session creations and tear-downs, and a corresponding smaller number of SAs than in normal networks.

Unlike normal networks in which network processors are used for deep header analysis, SANs do not require a network processor to be used with the NSP. Consequently, NetOctave developed a dedicated storage securit y processor, the NSP4200, for this market.

"It is a much more cost-effective solution for 10-Gb security in the storage market than the attempt we've seen to reposition general-purpose security chips for storage," Ardini said.

Since the proliferation of specialized security chips can allow the use of cost-effective memory options or off-chip interfaces, most vendors are predicting a growing proliferation of application-specific security processors.

Current Players Join In

Existing players seem to be moving to this approach, as well. When Broadcom acquired BlueSteel, Inc. two years ago, the company's main interest was in a general-purpose IPSec and an encryption processing engine. But at the Fall NetWorld+Interop in Atlanta, Broadcom introduced a board-level SSL accelerator product, CryptoNetX, developed by the same team that designed BlueSteel. Similarly, Hi/fn has introduced the 8165 SSL accelerator chip as a dedicated member of its HIPP II processor line.

But is an optimized vers ion of a micro-programmable engine the best solution for a session-layer security device? Greg North, vice president of engineering at Layer N, said that his company has explicitly rejected a spin from a programmable architecture for SSL. The goal for moving SSL acceleration into mass numbers of clients using secure browsers was to keep the security technology as transparent as possible. This meant not requiring system developers to learn programming tools.

In its UltraLock architecture, Layer N uses state machines for all SSL session termination functions, including a dedicated hard-wired TCP stack (see Figure 2). While there are some small embedded RISC cores in the Layer N design, they are used solely for low-level management tasks and are not exposed to the customer.

"We are fundamentally against programmable elements as a goal of our overall business," said Mike Salas, president of Layer N. "You cannot drive ubiquitous secu rity without a complete offload of tasks from the client, which was the business reason we bypassed an IPSec solution."

Ali of Cavium said that such an approach may limit potential applications in the SSL field, and also could limit scaling of a security engine. Cavium provides plenty of programming tools and application programming interfaces (APIs) at multiple levels, he said, but the company believes that corporations implementing firewalls, VPN tunnels, and SSL sessions will want flexible hardware that can support many functions.

This also leads to differences in connectivity. Cavium expects Nitrox to be used in systems with host CPUs, for example, so it offers PCI-X and Hyper-Transport interfaces. NetOctave is using SPI-4 as its primary external interface at the high end, reserving PCI-X for use only as a management interface for controlling lower-level operations. Layer N anticipates standalone web-access functionality for its processor, and so makes its Ethernet MAC the primary interface to th e external world.

Memory Options

Different approaches need different memory options. Cavium, for example, expects some users to push the limits of simultaneous SAs, and consequently offers a special local memory interface to DDR synchronous DRAMs (SDRAMs), used for storing SAs and context information. Layer N offers three separate DDR SDRAM interfaces, to store up to 1 million SSL session states. NetOctave can offer storage security options with no external memory, while relying on DDR SDRAMs with no external CAMs in applications where some external SA storage is required.

Expect a mad dash of specmanship to emerge in early 2002, particularly in SSL operations. Layer N is pledging a 100,000 1,024-b RSA SSL sessions per second for UltraLock. This is a profound leap over the previous promise by Andes to show 2,500 to 5,000 SSL sessions per second on the system level, a pledge more in tune with the claims of Hifn to offer 4,500 sessions per second on the 8165. Cavium splits the difference bet ween the two sides, claiming its programmable engine will be able to handle 10,000 to 40,000 SSL handshakes per second.

"The lesson for developers is to be cautious about generic claims, until you can analyze the implementation in a particular application," Corrent's Davis said.

An Open Question

The appropriate deliverables for the market are an open question, particularly in the web transaction environment. Broadcom launched a PCI board product line as the preferred implementation vehicle for servers offering secure web support. NetOctave began with board-level offerings of its 2000 and 3000 families at the fall NetWorld+Interop, but launched the newer 3200 and 4200 families as chip set products first. Corrent and Cavium stress that they will remain chip set developers first and foremost, but will work with a variety of partners to offer reference designs.