And then, to calculate decryption for ciphertext, C, such that is generated into plaintext, P, you can use the following formula:

P=Cd modulus x

It is extremely difficult to obtain the private key d from the public key (x,e). However, if someone or something could factor x into p and q, then they could obtain the private key d. The security of the RSA system is based on the assumption that factoring is difficult.

Using the network displayed in Figure 5.3, Host A would like to send a message to Host B using RSA encryption. The message will be denoted by m. Host A creates the ciphertext, c, by using the exponentiation of c=me modulus x; both e and x are Host B's public key. Host A then sends ciphertext, c, to Host B. Host B then attempts decryption by using the exponentiation of m=cd modulus x. There is a one−to−one relationship between e and d that ensures that Host B can recover the message, m.

RSA encryption can also provide authentication services, something that symmetric key encryption cannot do. To provide authentication services between Host A and Host B, such that the message, m, can be verified to be authentic and not tampered with, Host A creates a digital signature, s, by using the exponentiation of s=md modulus x. Both d and x in this example are Host A's private key. Host A then sends both the message, m, and the signature, s, to Host B. Host B then must verify the signature, s, by using the exponentiation of the message, m=se modulus x. Both values of e and x at Host B are Host A's public key.

Using RSA encryption means that encryption and decryption take place between two hosts without the exchange of each host's private keys. Each host only uses the other host's public key, or it uses its own private key. This means that any host can send an encrypted message or verify the signature of an authenticated message, but only a host that has possession of the correct private key can decrypt or sign a message.

Diffie−Hellman Key Exchange

Diffie−Hellman was developed by Diffie and Hellman in 1976 and published in the paper "New Directions in Cryptography" (citeseer. nj.nec.com/diffie76new.html). The protocol allows two users to exchange a secret key over an insecure medium without any prior secrets.

Diffie−Hellman is primarily used to provide a secure mechanism for exchanging public keys so that shared secret keys can be securely generated for DES keys. It provides a means for two parties to agree upon a shared secret in such a way that the secret will be unavailable to eavesdroppers. Diffie−Hellman key agreement requires that both the sender and recipient of a message have key pairs. By combining one's private key and the other party's public key, both parties can compute the same shared secret number. This number can then be converted into cryptographic keying material.

Note The functional operation of the Diffie−Hellman key exchange is explained in detail in Chapter 6.

Digital Signature Standard

Digital Signature Standard (DSS) is defined by the Federal Information Processing Standards Publication 186. Cisco implements DSS, which is used for peer router authentication and to protect data from undetected change. This standard specifies a Digital Signature Algorithm (DSA) for applications that require a digital signature as opposed to a written signature. The DSA signature is a pair of large numbers represented in a computer as strings of binary digits. The digital signature is

166

computed using a set of rules and a set of parameters such that the identity of the signature and integrity of the data can be verified. The DSA provides the capability to generate and verify signatures. Signature generation makes use of a private key. Signature verification makes use of a public key that corresponds to, but is not the same as, the private key. Each user possesses a private and public key pair. Public keys can be known by anyone and shared with anyone, but private keys are never shared. Anyone can verify the signature of a user by employing that user's public key. Signature generation can be performed only by the possessor of the user's private key.

The algorithm relies on the MD5 hash function to verify the authenticity of the data sent. The hash function is equivalent to taking a "fingerprint" of the message. If two fingerprints match, the message has not been altered in transit, and if the two fingerprints do not match, the message has been altered in transit. The hash is run through a function that uses the private key to sign the message and is reversible only if you have the public key. The peer runs the same hash and verifies the signature to determine the identity and content of the message.

Cisco Encryption Technology Overview

Cisco Encryption Technology (CET) is a proprietary Network layer encryption process that encrypts the data payload of an IP packet. Special portions of the IP header, for instance the UDP and TCP portions, are not encrypted. This allows the packet to be successfully routed through the internetwork. Only IP packets can be encrypted. The actual encryption and decryption of IP packets occur only at routers that you configure for CET. Such routers are considered to be peer routers. Intermediate routers do not participate in the encryption or decryption process. CET features include the following:

∙CET allows for granularity in the specification of which packets are encrypted. Packets needing to be encrypted can be defined with the configuration of an extended access list.

∙DSS is used to provide authentication.

∙Diffie−Hellman is used to manage each session's key.

∙DES is used to provide confidentiality (encryption).

Peer router authentication occurs during the setup of each encrypted session. Prior to peer router authentication, DSS public and private keys must be generated for each peer and the DSS public keys must be exchanged with each peer. This allows peer routers to authenticate each other at the start of encrypted communication sessions. The generation and exchange of DSS keys occurs only once on a per−peer basis, and afterward, these DSS keys will be used each time an encrypted session occurs. To be successfully exchanged, DSS public keys must be verified via a trusted source at the location of each encryption peer. This usually occurs via a phone call and is called "voice authentication." During the exchange process, one peer is configured to be the "passive" and the other peer is configured to be the "active" peer.

Each peer router's DSS keys are unique: a unique DSS public key and a unique DSS private key. DSS private keys are stored in a private portion of the router's NVRAM, which cannot be viewed. If you have a router with an Encryption Service Adapter (ESA), DSS keys are stored in the tamper−resistant memory of the ESA. The DSS private key is not shared with any other device. However, the DSS public key is distributed to all other peer routers. You must cooperate with the peer router's administrator to exchange public keys between the two peer routers, and you and the other administrator must verbally verify to each other the public key of the other router. When an encrypted session is being established, each router uses the peer's DSS public key to authenticate the peer.

Prior to a router passing encrypted data to a remote peer, an encrypted session needs to be

167