The advent of DSL and cable modems for home and small office/home office (Soho) are spurring dramatic growth in home PC Internet access. Accompanying this growth, however, are major security problems, produced by the increased and widespread involvement of the home in e-commerce, remote access to corporate enterprises, banking and other data-sensitive online transactions. And, because DSL and cable modem Internet hookups are "always-on" connections, users of these services are particularly vulnerable to hacker attacks.
Designers of networking systems for home and Soho applications must therefore understand the Data Encryption Standard (DES) and Triple DES, Internet Protocol Security (IPSec), various security algorithms and design considerations involved in designing and developing price-sensitive security for these growing home and Soho markets. In particular, it is important for system engineers to have a good grasp of symmetric and public key cryptography.
Traditional cryptography is based on the sender and receiver of a message knowing and using the same secret key. A key is defined as a piece of data that, when fed to an algorithm along with cipher text or encrypted data, will yield plain text or information in regular language. Also, when a key or piece of data is fed to an algorithm along with plain text, cipher text is produced.
Secret keys
The sender uses the secret key to encrypt the message, and the receiver uses the same secret key to decrypt the message. This method is called secret key or symmetric cryptography. The main problem is getting the sender and receiver to agree on the secret key without anyone else finding out. If they are in separate physical locations, they must trust a courier, a phone system or some other transmission medium to prevent the disclosure of the secret key.
Anyone who overhears or intercepts the key in transit can later read, modify and forge all messages encrypted or authenticated using that key. The generation, transmission and storage of keys is called key management. All crypto systems must deal with key-management issues. Since all keys in a secret key crypto system must remain secret, it is often difficult for symmetric cryptography to provide secure key management, especially in open systems with a large number of users.
Public keys
The key-management issue can be resolved through public key cryptography, a concept introduced in 1976 by Whitfield Diffie and Martin Hellman. In this scheme, each person gets a pair of keys-one public key and one private key. Each person's public key is published while the private key is kept secret. The need for the sender and receiver to share secret information is eliminated. All communications involve only public keys, and no private key is ever transmitted or shared.
Public keys are associated with their users in a trusted or authenticated manner, for example, in a trusted directory held by a certificate authority. The authority performs a function similar to a notary public. Since it does not have access to a sender's private key, the certificate authority cannot vouch for the content of the message, only that the sender is the legitimate owner of the public key. The certificate authority could be a large third-party repository of public keys or one's own corporation, as long as the appropriate standards are met. Most certificate authorities conform to the X.509 standard proposed by the International Telecommunication Union (ITU). Anyone listed in such a directory can send a confidential message just by using public information. But the message can only be decrypted with a private key, which only the intended recipient possesses.
In public key cryptography, when Alice wants to send a secret message to Bob, she looks up Bob's public key in a directory, uses it to encrypt the message, and sends it off. Bob then uses his private key to decrypt the message and read it. No one listening in can decrypt the message. Anyone can send an encrypted message to Bob, but only he can read it. One requirement is that no one can figure out the private key from the corresponding public key. The basic notion underlying public key cryptography is that factorization is difficult. Accordingly, if two large prime numbers are chosen at random and multiplied together, the product can be used publicly without risk that anyone would figure out the prime numbers originally chosen.
Digital signatures
Also, the source of the message is often at least as important as the message's content. Digital signatures or authentication are used to identify the message's source. Like public key crypto systems, digital signature systems use public and private keys. The sender of a message uses a private key to sign it, and the public key verifies the sender's signature.
Digital signature systems do not necessarily imply secrecy: A number of them do not provide it. But the RSA crypto system-named after its inventors Ronald Rivest, Adi Shamir and Leonard Adleman, for example, can be used for both purposes. To sign a message with RSA, the sender decrypts it, using a private key. Anyone can verify and recover this message by encrypting with the corresponding public key. Mathematical operations used in RSA allow decrypting plain text and encrypting to recover the original message.
DES uses a 56-bit key and maps a 64-bit input block into a 64-bit output block. The key looks like a 64-bit quantity, but one bit in each of the 8 bytes is used for odd parity on each byte. Therefore, only seven of the bits in each byte are actually meaningful as a key.
DES is efficient to implement in hardware, but relatively slow if implemented in software, although software-based DES is occasionally used. The 64-bit input is subjected to an initial permutation to obtain a 64-bit result, which is just the input with the bits shuffled. The 56-bit key is used to generate 16 48-bits-per-round keys, by taking a different 48-bit subset of the 56 bits for each of the keys. Each round takes as input the 64-bit output of the previous round and the 48-bitper-round key, and produces a 64-bit output. After the 16th round, the 64-bit output is subjected to another permutation, which is the inverse of the initial permutation.
Designing security measures into Soho router systems involves several major considerations, the goal of which is the highest possible performance at the right cost point.
In systems like these, keeping the bill of materials as low as possible is of paramount importance for OEMs to hit the right price point. Hence, security measures must be based on highly integrated chips.
Currently, most Soho router designs are based on a highly integrated processor and DSL chip set, but these host CPUs aren't powerful enough for the necessary security function. For example, to perform the DES or Triple DES encryption algorithms used in IPSec applications at 1 megabit/second, a standard processor needs 50 to 100 Mips, or more, of performance.
Therefore, the system designer must deploy a dedicated security coprocessor to implement IPSec algorithms. Such a coprocessor should have a PCI bus interface for design flexibility. This interface is key for efficiently sending data packets to the security coprocessor; performing compression, encryption and authentication; and then sending those packets into packet memory.
An example is Hi/fn's 7951 security coprocessor, which implements symmetric key encryption, public key encryption, authentication and data compression in hardware. The chip's pipeline architecture permits many of these functions to be performed in a single pass, thus making high throughput possible. Integrated algorithms support standard network security protocols, including IPSec, Point-to-Point Tunneling Protocol, Layer 2 Transport Protocol, Point-to-Point Protocol and others. Algorithms implemented by this coprocessor include DES, Triple DES, and RC4 encryption; SHA-1 and MD5 hash algorithms and HMAC functions; and Lempel-Ziv-Stac and Microsoft Point-to-Point data compression.
The four IPSec processing requirements in a Soho router design are public key cryptography, data compression, symmetric key encryption and data authentication. Public key cryptography exchanges the symmetric keys when a secure communication link is established. Symmetric keys are the keys that perform data scrambling on each IP packet. Symmetric key cryptography, instead of public key cryptography, is used to encrypt each packet because it is considerably less computationally intensive. However, even symmetric keys demand dedicated hardware acceleration for data rates greater than a few hundred kilobits per second, because encrypted data requires on average 30 to 40 times more computing power to process than clear text.
Data authentication is used to ensure that data isn't tampered with in any way. Lastly, data compression reduces the size of the packet, which mitigates some of IPSec's performance impact.
In a Soho router design, the Internet key exchange (IKE) is performed in software. IKE, also known as the Internet Security Association Key Management Protocol, is used to make an agreement on the various security methods to be employed for a particular communications session.
Public key security in a Soho router design depends on a relatively high-speed source of random numbers. A security coprocessor like the 7951 contains a hardware random number generator based on internal free-running oscillators whose frequencies drift relative to each other and to the security coprocessor's internal clock.
Works at Layer 3
IPSec is the dominant protocol used in network security subsystems in a Soho router, remote access concentrator, or virtual private network gateway. Operating at Layer 3 of the Open Systems Interconnect model, IPSec is a collection of protocols that address security at the network layer. These protocols cover such issues as key management and packet processing. There are three components to IPSec's packet-processing portion: IP Payload Compression Protocol (IPPCP), encapsulating security payload (ESP) and authentication header.
IPPCP defines the methods by which a packet can be compressed to improve overall system bandwidth and performance.
ESP defines packet encryption and authentication. The authentication header also defines a method of authenticating packets. Compressing packet data before it is encrypted increases performance. Using ESP with IPPCP contributes to that increased performance, because this combination is the most efficient way to implement compression, encryption and authentication of IP packets.
ESP provides data integrity and confidentiality, as well as authentication. It can be used to encrypt either an upper-layer packet in transport mode or an entire IP packet in tunnel mode. Transport and tunnel modes are the two options for ESP implementations.
In transport mode, the original IP header is transmitted in the clear, meaning it is not compressed or encrypted. The ESP header, the upper-layer protocol header, and the payload follow the IP header. Then comes the ESP trailer, and if authentication is used, the ESP message-authentication code. In ESP transport mode, compression and encryption are performed on the TCP header and the payload. Authentication is performed over the ESP header, the TCP header, the payload and the ESP trailer.
If the security-based Soho router system design calls for authentication or encryption over the original IP header, there are two choices. The ESP transport mode is not one of them, since it is not defined to support this arrangement. Instead, the authentication header can be used in transport mode, although the IPSec subsystem would require two passes to perform the operation. The reason is that the compression operation must be performed before the total-length field in the IP header can be inserted and the total-length field must be used in the authentication. This would tax the subsystem more.
That alternative is tunnel-mode ESP, which processes the original IP header in a single pass in a security coprocessor, such as Hi/fn's 7951. In ESP tunnel mode, the original header, TCP header and payload are compressed, encrypted, authenticated and encapsulated. A new IP header, which usually contains the source and destination addresses of gateways or firewalls, is inserted.
Authentication is performed over the ESP header, the original IP header (as with authentication header), the TCP header and the payload. Compression and encryption are performed on the original IP header, the TCP header and the payload. Tunnel-mode ESP provides authentication and encryption of the original IP header.
