In most design camps, system engineers view SSL and IPSec security as based on different architectures, the first usually deployed in software and the second better implemented in hardware. However, a single architecture can reconcile both sets of security protocol requirements with a design that can either be IPSec or SSL by simply choosing the appropriate acceleration vehicle, without altering the basic design.

Symmetric cryptography is a scheme in which the same key is used for encryption and decryption. Data-encryption algorithms supporting symmetric cryptography include Data Encryption Standard, triple DES, Advanced Encryption Standard and ARC4. Public-key cryptography (PKC), on the other hand, uses two keys, one public, one private. One key does the encryption, the other the decryption. Known PKC algorithms are orders of magnitude slower than the best-known symmetric cryptographic algorithms. Popular PKC algorithms include Diffie-Hellman and Rivest-Shamir-Adleman.

In the IPSec application, public-key cryptography sets up a transaction session via the Internet, followed by symmetric-key cryptography for data encryption and decryption. All encrypted and decrypted data flows through a virtual private network. In these IPSec instances, transactions typically run for long periods of time, two to three hours or more. Public-key cryptography is thus used sparingly, but symmetric-key encryption and decryption are used considerably in the back-and-forth transfer of data.

In an SSL application for e-commerce, the opposite is true. Symmetric-key cryptography is used sparingly, for instance to fleetingly encrypt credit card information or other personal data. However, public-key cryptography is the cornerstone for e-commerce transactions because it is used primarily to open millions and millions of sessions per second to conduct business. Consequently, SSL requires a growing amount of public-key processing power.

The typical IPSec security design in a server might consist of one or two functional blocks to perform session setups and accelerate encryption algorithms. Meanwhile, the SSL portion of a multichip design like this would rely on the modulo-arithmetic acceleration and, possibly, random-number generator. If done in hardware, a total of three to four chips is required for this design.

The ideal architecture for handling both IPSec and SSL protocols should have several essential functionalities: packet-manipulation engines, a dedicated control bus, a point-to-point data interface, on-chip symmetric- and public-key engines, scalability and local memory to reduce bus congestion.

The first architectural requirement, intelligent packet processing, means offloading the CPU of the task of processing and handling packets, and incorporating that job totally in a new security-processor chip that operates in tandem with the host CPU. This significantly reduces the amount of data interactions over external buses and between such critical system resources as the CPU and memory. Hence, the system engineer achieves higher performance for next-generation server and router systems that power the new Web.

One possible hardware configuration is based on the Hifn intelligent packet-processing architecture, or HIPP, which consists of specialized security processors that handle hardware algorithms for high-speed security processing and soft or programmable packet-manipulation engines, also known as dynamic protocol units (DPUs). A device based on this kind of an architecture would be able to support all major security and compression protocols, including IPSec, SSL, Point-to-Point Protocol, Point-to-Point Tunneling Protocol and Layer 2 Tunneling Protocol.

Each core within the architecture consists of a security/compression engine and the DPU. The security/compression engine contains pipelined compression, encryption and authentication units, along with hardware for computing checksums, cyclical redundancy checks and longitudinal check bytes.

The DPU, running RAM-based microcode, controls the security/compression engine, performs packet-header processing and allows new protocols to be supported as needed. It analyzes the headers of incoming packets such as IPSec or SSL and constructs the headers of outgoing packets. Also, the DPU supports the automatic handling of mutable fields, stateful sequence numbers, anti-replay, tunneling headers, IP checksums and automatic packet fragmentation.

For example, a DPU recognizes whether a packet header is IPSec or SSL, and decrypts the encrypted payload accordingly. Hence, the architecture not only classifies the packet, but also constructs new headers for outgoing packets. Other design approaches, lacking this intelligent packet processing, incur considerable engineering overhead. Largely, these designs rely solely on the system CPU, which keeps the header, sends the encrypted payload to a coprocessor for decryption and modifies the header. As a result, the CPU is unnecessarily overloaded with the task of processing packets.

Two host interfaces support this new architecture: PCI and the streaming bus. The PCI interface, which primarily serves to control transaction sessions, operates at 64-bit, 66-MHz, 3.3-volt PCI bus master. It can also operate at 32 bits with a streaming bus. The streaming-bus interface is an alternative I/O interface supporting 32-bit data channels. The streaming bus has exceptionally high-throughput bandwidth, up to 3 Gbits/second, to help turbocharge packet processing.

The integrated public-key processing subsystem implements modular arithmetic and random-number functions, and leaves the other public-key encryption tasks-primarily control protocols-to the local host's general-purpose processor. The arithmetic unit operates on integers of up to 1,024 bits in width. It reads operands from the data register file, operates on them and writes the results back to the data register file. The arithmetic unit has such modular arithmetic functions as exponentiation, multiplication, reduction, addition and subtraction. Also, it performs nonmodular two's complement addition, subtraction and multiplication, logical left and right shifts, increment and decrement functions.

Two other major functions in the public-key subsystem are the microcontroller and random-number generator. The microcontroller is the public-key processor's instruction sequencer. It controls the operation of the arithmetic unit, and its instruction set consists solely of arithmetic operations. This controller has two sections: the microsequencer and the instruction memory. The microsequencer contains the control logic, while the instruction memory consists of thirty-two 32-bit instruction words.

Other types of security or public-key processors can be added to the system as security requirements dictate. Adding a public-key processor accelerates the key-exchange process secure sessions. With its own PCI interface, it can be added to the system as an independent PCI device or it can be added to the subsystem as a slave device controlled by the private CPU. In the latter case, the public-key processor can be inside a Federal Information Processing Standard (FIPS) 140-1 security boundary. The system engineer can add multiple public-key processors for any desired level of public-key performance.

Private memory support also plays a major role in this architecture. This synchronous DRAM holds the session context locally, which results in system bus traffic dominated by packet data rather than overhead. In this scheme, private memory can be 32 or 64 bits wide with optional 8-bit error correction. Here, memory sizes ranging from 8 to 256 Mbytes are supported.

Lastly, this architecture includes a 32-bit interface for a MIPS processor. This private CPU unloads tasks such as session setup and exception handling from the host CPU. Sensitive data items are handled by either the private CPU or, in our architecture, the Hifn 8154, isolating this information from the PCI bus and host CPU. This makes it possible to implement a highly secure, FIPS 140-1, Level 3-compliant security subsystem.

See related chart