Public Key Encryption Methods

In almost every form of commercially available cryptographic scheme, which would include all of the components used in IPsec, the cipher used is generally known. It is the key that is used within the cipher that makes the encryption harder to crack. Consider the asymmetric key encryption scheme used by James and Charlie. Charlie and James must have each other's public key to encrypt communications that are decipherable by the other party. Let's say that another party, Olivia in this case, decided to play a trick on James and Charlie by convincing them that she was Charlie and James, respectively. Figure 2-9 illustrates how a public key can be compromised by a user inserting themselves between two cryptographic endpoints.

Figure 2-9. Compromised Keys in an Asymmetric Exchange

Charlie's keypair has been compromised. Olivia can now send messages to Charlie and decrypt messages from Charlie originally intended for James and vice versa. The type of attack that Olivia executes on James' and Charlie's conversation is typically referred to as a man-in-the-middle attack. The steps in Figure 2-9 are as follows:

1.	Olivia authenticates herself to Charlie as James and to James as Charlie. Charlie and James intend to exchange their public keys with one another. But, because Olivia has authenticated as James to Charlie and as Charlie to James, James and Charlie actually exchange public keys with Olivia.
2.	James encrypts a message to Charlie with Olivia's public key, thinking that he is using Charlie's public key, and transmits it to Olivia unknowingly.
3.	Olivia receives the message, decrypts it with her private key, and is now able to read the original content of James' transmission to Charlie.
4.	Olivia encrypts a message and manipulates the original content to suit her needs. She encrypts the message with Charlie's public key and forwards it on.
5.	Charles receives the message from Olivia, thinking it was from James. Charlie then uses his private key to decrypt the message and reads the altered message sent by Olivia in Step 3.

Apply this type of attack to an exchange of financial account information between large global financial organizations, the exchange of patient health care records between regional hospitals and their insurance providers, or a customer and retailer exchanging credit card information over the Internet, and it becomes apparent why it is absolutely critical that the keys used in the exchange of encrypted data be exchanged securely and privately.

ISAKMP employs several operations to protect the authenticity and integrity of cryptographic keys. There are generally three different methods for doing so, all of which will be discussed later in this chapterPreshared Authentication Keys, RSA Encrypted Nonces, and RSA Signatures. As we'll discuss at several points throughout this text, many of these methods are secured by the computational difficulty of factoring two large prime numbers. Let us begin our exploration of these techniques by discussing the RSA encryption algorithm.

RSA Public-Key Technologies

Ron Rivest, Adi Shamir, and Leonard Adleman developed the RSA encryption algorithm in 1977. To this day, RSA encryption has served as a critical authentication component in many large-scale commercial ISAKMP deployments. Two key cryptographic operations that leverage the RSA encryption algorithm are RSA encryption and RSA signatures. In this section, we will explore the operation of both RSA technologies within the context of the IPsec protocol suite.

RSA Encryption

RSA encryption uses an asymmetric cryptographic exchange to secure data. However, the strength of RSA encryption lies within the generation of the public and private key pair. Although the generation of RSA keypairs is somewhat expensive computationally relative to IKE preshare keys, RSA encryption is asymmetric, and therefore yields an added level of security in authentication over manually defined IKE preshared keys (see Figures 2-4 and 2-6 for the added value of asymmetric cryptography). Consider the exchange of information between James and Charlie in Figure 2-9. Figure 2-10 shows how the encryption and decryption processes work when using RSA encryption.

Figure 2-10. Encrypting Data with the RSA Encryption Algorithm

The following sequence of events describes the generation of RSA keys and the methods used to encrypt data between two cryptographic endpoints using RSA encryption:

1.	James and Charlie generate parameters needed to establish cryptographic keys: Prime Number #1 (P) = a large, randomly generated prime number. Prime Number #2 (Q) = another large, randomly generated prime number. Modulus (M) = the factor of two large, randomly generated prime numbers. Computed by the equation M = (P 1) x (Q 1). Exponent (E) = E must be selected coprime to modulus M. It is a small number that shares a greatest common denominator with M of 1. Decryption (Private) RSA Key (D) = (Y x [(P 1) x (Q 1)] + 1) / E; where Y is any number divisible by 1 that yields an integer value for D.
2.	James exchanges his public exponents with Charlie. In this situation, public exponents must be exchanged so that James' peers can encrypt data, and the private exponent must be kept secret so that only James can decrypt data that is being sent using his public exponent. Note Public exponents must be exchanged with parties deemed to be authentic. Otherwise, a vulnerability to man-in-the-middle attacks is exposed, as described in Figure 2-9. The use of a Public Key Infrastructure (PKI) provides a scalable solution to managing the risks of public key distribution.
3.	James uses Charlie's public exponent to encrypt his data, using the encryption function depicted below. Charlie then uses his private exponent to decrypt the communication as they receive it.

The encryption function in RSA encryption is [(PT)^E]mod(M) where:

• PT is the numerical representation of the plain text message.

• E and M are components of the RSA public key generated above.

• Mod is the modulus of two numbers.

• The decryption function in RSA encryption is [(CT)^D]mod(M), where:

• CT is the numerical representation of the cipher text message.

• D and M are the RSA private key that corresponds to the RSA private key mentioned previously.

• Mod is the modulus of two numbers.

In the above example, small prime numbers were used for generating RSA keys. In reality, these numbers must be much larger, for the larger they are, the harder RSA encrypted messages are to crack. RSA derives its strength from the computational difficulty of factoring large numbers. As such, encryption mechanisms that effectively use the RSA algorithm use values for P and Q of at least 100 decimal values in length.

Note

Cisco manufactures crypto engines that can support key length (modulus) sizes of up to 2048 bits in length. As we've discussed, generation of RSA key pairs can be computationally expensive. The longer the key modulus selected when generating RSA keypairs, the longer it takes the processor to generate the keys.

RSA encryption is useful in certain site-to-site VPN topologies. However, as the number of crypto peers scales upwards, the maintenance of RSA keypairs can become cumbersome, both in terms of processor load on network devices and in terms of key maintenance and administration required. In order to solve these issues, RSA signatures can be deployed to increase the scalability of an RSA encryption environment and ease the administrative overhead required to maintain the RSA-encrypted environment without sacrificing the cryptographic strength delivered by deploying the RSA encryption algorithm.

RSA Signatures

IPsec crypto endpoints running Cisco IOS support authentication using RSA Signatures using X.509-based Certificates and Certificate authorities. This method of authentication, though more complicated to configure, offers a more scalable configuration alternative to RSA encryption and preshared keys.

Crypto endpoints using RSA signatures use X.509 certificates to authenticate and enroll with the CA. Using a central resource for authentication services, the Certificate Authority, simplifies maintenance on both crypto endpoints. This is particularly useful in large networks, as administrators now configure each crypto endpoint to use the CA for authentication, instead of manually configuring preshared keys for each peer. Cisco IOS supports RSA signatures when negotiating ISAKMP SAs. The operation and configuration of crypto endpoints using RSA signatures is covered in greater detail in Chapter 11, "Public Key Infrastructure and IPsec VPNs."

Diffie-Hellman Key Exchange

Network infrastructures are increasingly relied on for transferring bulk amounts of data, which lends itself more to a symmetric crypto solution. Given this trend, many network architects turn to the Diffie-Hellman algorithm to securely derive shared keys across an untrusted network infrastructure.

Note

Diffie-Hellman is a core component of the IKE protocol. Aspects of the Diffie-Hellman algorithm will be covered in additional detail in the IKE and perfect forward secrecy (PFS) section of this chapter.

Diffie-Hellman key exchange was designed for crypto endpoints to derive shared secret session keys across unsecured media. The shared secret keys are negotiated between crypto endpoints dynamically. As such, administrators need to specify only the prime modulus (MODP) size for use in the Diffie-Hellman exchange. IKE uses Diffie-Hellman keys to encrypt the ISAKMP SA over which IPsec SAs are established. Likewise, Diffie-Hellman is used to generate keys to be used in the ciphers specified in IPsec transforms. These transforms, when used in conjunction with Diffie-Hellman keys, will be used by IPsec to encrypt and decrypt data as it passes through the VPN tunnel.