Overview of Cryptographic Components

As we had discussed briefly while introducing the criteria for defining an effective VPN, data confidentiality, data authentication, data integrity, and data nonrepudiation must be maintained. These criteria also apply to the effectiveness of any encrypted communicationthe more of these criteria are met, the more secure and private the communication channel is deemed to be.

Cryptographic processes use three basic components to deliver upon these criteria for successa key, a cryptographic mathematical function (also called a cipher), and a message to be encrypted or decrypted. A one-thousand-foot view of the process is as follows: the message is fed into the cipher algorithm, which uses the key to transform the original message into a format that is undecipherable to anybody who does not possess the appropriate decryption key.

As depicted in Figure 2-1, the exchange between James and Charlie relies heavily on encryption and decryption keys. In any cryptographic operation, these appropriate keys must be obtained in order to encrypt and decrypt messages. In some cases, the encryption key and decryption key may be one and the same. In other cases, they may be intentionally different from one another (one used for encryption, the other used for decryption). We will now explore how these two different types of encryption (symmetric and asymmetric) provide for data confidentiality in VPN deployments.

Figure 2-1. EncryptionA One-Thousand-Foot View

Asymmetric Encryption

In an asymmetric encryption scheme, each party derives a private and public key pair, as shown in the following text. As noted by the name, public keys can be exchanged securely with communications partners, while private keys must be kept secret.

In asymmetric cryptographic operations, private keys are generally used to decrypt data, while public keys are used to encrypt data. In the scenario depicted in Figure 2-2, James and Charlie will exchange public keys to encrypt traffic to one another. James will then use Charlie's public key to encrypt his message to Charlie, and Charlie must use his private key to decrypt the message. The same operation will transpire in the future when Charlie replies to JamesCharlie's reply will be encrypted with his James' public key, and James will have to use his private key to decrypt Charlie's reply. Thus the requirement for James and Charlie to exchange public keys before any encrypted communication can take place. Of critical importance is that these public keys be exchanged securely and only between the appropriate parties. As we will see in later sections, effective methods exist to guarantee the authenticity of key exchange across untrusted media.

Figure 2-2. Asymmetric, Public Cryptographic Setup and Key Exchange

After having exchanged public keys, James and Charlie should be able to send messages to one another confidentially, using that key to encrypt the message. Note that private keys are never exchanged across the shared media, which lessens the influence of compromised keys. As we will discuss later in this section, a compromised symmetric key (use decryption and encryption) increases the vulnerability of impersonation and hijacking attacks on the Virtual Private Network (VPN), as the compromised key is used for encryption and decryption of data. Asymmetric key encryption lessens this effect, as a compromised public key cannot be used to decrypt dataonly to encrypt it. Figure 2-3 depicts the series of exchanges that compose James' and Charlie's confidential conversation using asymmetric cryptography.

Figure 2-3. Exchanging Messages with Asymmetric Cryptography

The following sequence of events describes the exchange between James and Charlie illustrated in Figure 2-3:

1.	James encrypts a message to Charlie with Charlie's public RSA key.
2.	Charlie receives the message from Step 1 and decrypts it with his private RSA key.
3.	Charlie crafts a response to James and encrypts it with James' public RSA key.
4.	James receives the message from Step 3, and decrypts it with his private RSA key.

The original message never crosses the shared media in cleartext. Confidentiality is maintained, in that intermediary parties that exist between Charlie and James are unable to view the original, unencrypted message contents as they do not possess the required private key for decryptiononly cipher text, or encrypted text is transmitted between James and Charlie.

When Charlie receives James' message, he will be able to decrypt the message with his private key and interpret the original message contents. Charlie is now able to read the original contents of James' message to him and crafts a reply. As James had done earlier to his message to Charlie, Charlie now encrypts his reply with James' public key and forwards the cipher text over to James. Again, only cipher text traverses the shared media. Due to the fact that Charlie has encrypted his response with James' public key, James can use his private key to decrypt and interpret Charlie's reply. Let's now have a look at the effect of a compromised public key in the exchange between James and Charlie in Figure 2-4.

Figure 2-4. An Attempt to Compromise an Asymmetric Key Cryptosystem

The following sequence of events describes Figure 2-4:

1.	James attempts to exchange his public key with Charlie.
2.	Olivia intercepts James' public key.
3.	Charlie exchanges his public key with James.
4.	Olivia attempts to interpret data sent from James to Charlie, but is unable to. Olivia can encrypt messages to James only with his public keyshe cannot decrypt messages from him.

If a third party, Olivia in this case, were to intercept Charlie's public key, she would be able only to encrypt data toward James, but would be unable to decrypt messages from him. To successfully facilitate this attack, she would have to fool James into thinking that she was indeed Charlie, so that she could obtain James' public key, thereby adding another layer of complexity to the attack over an attack situation on a symmetric key cryptosystem. In this regard, Olivia is attempting to act as a man in the middle. This attack is described in detail later in this chapter in Figure 2-9.

Symmetric Encryption

Symmetric key encryption is a slightly simpler operation than asymmetric encryption, and, as such, is more suited to bulk cryptographic transmission. In a symmetric cryptographic operation, James and Charlie will share the same secret key. In Figure 2-5, James and Charlie have both been given the same symmetric (encryption and decryption) key and use it to exchange confidential messages.

Figure 2-5. Symmetric Key Encryption

The following sequence of events describes the symmetric encryption operation illustrated in Figure 2-5:

1.	James crafts a message to be sent to Charlie. Note that, in this step, James and Charlie are preconfigured with a shared, symmetric, key used for both encryption and decryption.
2.	James encrypts the message crafted in Step 1 with his shared symmetric key and forwards the ciphered message to Charlie.
3.	Charlie decrypts the message received in Step 2 with his shared symmetric key, making the original cleartext message available for interpretation.

Unlike asymmetric encryption, the shared secret key used in symmetric encryption is used not only to encrypt data, but also to decrypt the data. James begins the exchange by using his shared, secret key to encrypt his message to Charlie.

Because the operation is considered to be symmetric, James and Charlie have identical keys for encryption and decryption. Now that Charlie has James' message, Charlie uses the secret key shared between James and Charlie to decrypt the message.

When Charlie decides to answer James' query, the operation would follow the same procedure. Specifically, Charlie would craft his reply to James and encrypt it with the shared secret key. Upon receipt of the message, James would decrypt the message with the same key that Charlie used to encrypt it.

Note

Transforms used in IPsec Security Associations, such as Data Encryption Standard (DES), 3DES, and AES, are symmetric encryption algorithms. As such, IPsec relies heavily on symmetric key encryption to deliver confidential exchange of data.

Let's return to Olivia's attempt to compromise the confidential communication between James and Charlie. This time, Olivia intercepts the symmetric key that James and Charlie share for both encrypting and decrypting data communications between them. In this case, Olivia does not need an additional key to talk with James and Charliethe symmetric key is sufficient to both encrypt and decrypt data to and from both James and Charlie. When comparing Figure 2-6 with Figure 2-4, the simplicity of Olivia's man-in-the-middle attack on James and Charlie's symmetrically encrypted conversation relative to their asymmetrically encrypted conversation can be observed.

Figure 2-6. An Attempt to Compromise a Symmetric Key Cryptosystem

Unlike asymmetric cryptographic operations, symmetric key transforms are more susceptible to attack if a symmetric key becomes compromised. For this reason, symmetric keys are typically not exchanged over an untrusted medium. Instead, they are typically derived over a secured medium.

Note

As we will discuss later in this text, IPsec uses the Diffie-Hellman algorithm to derive shared secret keys for bulk data encryption with a symmetric key transform. Diffie-Hellman is facilitated over a trusted channel secured with IKE.

The following order of operation describes the effect of a compromised symmetric key illustrated in Figure 2-6.

1.	James and Charlie create and share symmetric transform keys over an untrusted medium.
2.	Olivia intercepts the symmetric key shared between James and Charlie in Step 1 above.
3.	Olivia can now encrypt and decrypt messages to and from James and Charlie. This enables her to eavesdrop on conversations between James and Charlie. She is also able to falsely impersonate James and Charlie and craft messages to and from both of them.

Message Authentication, Message Integrity, and Sender Nonrepudiation Mechanisms

IPsec incorporates several cryptographic operations to ensure message authenticity, data integrity, and sender nonrepudiation. In this section, we will describe the mechanics of these cryptographic operations, including message hashing, message digests, and Digital Signatures.

Hashing and Message Digests

Data integrity ensures that transmitted data has not been tampered with en route to its destination. Hashes can be deployed to ensure data integrity. A hash takes an input message of variable length and outputs fixed-length code. The fixed length code is then appended to the original message before transmission. A basic hashing function consists of an algorithm and a key that is known to both sender and receiver, as described in the scenario between James and Charlie illustrated in Figure 2-7.

Figure 2-7. Creating and Verifying a Message Digest

Before sending his message to Charlie in Step 1 of Figure 2-7, James performs a mathematical operation, or hashing function, on the original message. The output of that mathematical operation is called a hash value, or message digest, which is then appended to the original message and sent to Charlie.

In Step 2 of Figure 2-7, Charlie then removes the hash value from the original message and runs the same hash operation on the original message received. Charlie then compares his hash value with the one that James had sent appended to the original message. If the two hash values match, then Charlie can be assured that the message's integrity has not been compromised. That is to say that James' message to Charlie has not been modified and has not been spoofed by a source other than James himself.

Although message digests provide data integrity, they do not provide message authenticity unless the original message is hashed with a secret key shared between the two endpoints. This operation is commonly used in routing protocol authentication and also in the creation of hashed message authentication codes (HMACs) used for bulk data encryption by a symmetric key transform defined an IPsec SA.

In order for a hash to effectively provide data integrity, the hash operation must have the following characteristics:

• Identical input messages must consistently yield the same output.

• The input message length can vary, but the length of the output of the hash operation must be of fixed length.

• The output must be random, or give the appearance of randomness.

• It must be irreversible, or one wayone should never be able to determine the original message by reversing the hash operation.

• Each unique input message should yield a unique output value.

The most widely used hash algorithms are the Secure Hash Algorithm (SHA) and the Message Digest 5 algorithm (MD5). Both MD5 and SHA process input in 512-bit blocks, but the length of their output variesMD5 outputs a 128-bit message digest, while the message digest output of SHA is 160 bits. As such, SHA is considered a stronger hash, but requires more processing power than the MD5 hash algorithm.

Note

Although SHA-1 and MD5 are 160- and 128-bit computations, respectively, the length of the resulting hash is sometimes truncated to 96 bits in length in transmission.

Secure Cisco networks use hashing operations for a variety of things, including routing protocol authentication and in various applications of IPsec and IKE. Within the IPsec framework, hashing algorithms are used when appending message digests to the messages exchanged to generate shared secret keys during IKE, when collaborating with a certificate authority, when building Digital Signatures, and when computing a keyed message authentication check for shared secret-key encryption.

Digital Signatures

Data authentication refers to information originating from the original valid source. Authentication in simple hashes can be compromised by data replay attacks and man-in-the-middle attacks. Digital Signatures use a combination of hashes and asymmetric encryption in order to secure the integrity of the hash exchanged between two peers. Preserving data integrity ensures that a message has not been altered or compromised en route to its destination. A Digital Signature is an encrypted form of a hashed message. As such, a Digital Signature can be verified only by those parties containing the necessary public key that corresponds to the private key used to encrypt the hash. Therefore, if the Digital Signature is verified, its source is deemed to be authentic, as the public key would not decrypt a message digest value encrypted by a different private key. Consider again the exchange of a message between two routers, James and Charlie. A Digital Signature can be used to provide an additional level of authenticity over a standard hash. The first step that James takes to create the Digital Signature of his original message is derivation of a public and private key pair associated with the original message. Figure 2-8 illustrates the process of creating and validating a Digital Signature.

Figure 2-8. Generating and Verifying a Digital Signature

The following order of events describes the exchange in Figure 2-8:

1.	James crafts a cleartext message, performing a hash with his public key that results in a message digest. James forwards his public key to Charlie to be used for decrypting Digital Signatures from James (as in Step 2 following).
2.	James then encrypts the message digest created in Step 1 with his private key. This results in a Digital Signature that is appended to the original cleartext message. The original message is sent in cleartext to Charlie with the appended Digital Signature.
3.	Charlie uses James' public key sent in Step 1 to decrypt the Digital Signature sent in Step 2.
4.	Charlie hashes the cleartext message sent in Step 2 with the public key sent in Step 1. If the resulting message digest matches the message digest resulting from the decryption process of Step 3, the Digital Signature is deemed to be valid.

Up until this point in the exchange, the process of creating a hash value and creating a Digital Signature has been identical, save one itemJames' creation of a public and private key pair. These keys encrypt (private key is used for encryption) and decrypt (public key is used for decryption) the hash value created by the hash operation performed on the original message.

Note

In our previous discussion of public key encryption, or asymmetric encryption, two parties have exchanged keys to encrypt data to one another (public keys), and retained the corresponding private keys to decrypt data from their peers. In certain circumstances, the reverse operation may existprivate keys are used for encryption, and public keys are used for decryption. Digital Signatures typically follow this behaviorprivate keys are used to encrypt, and public keys are used to decrypt, contrary to typical asymmetric key usage.

This form of public key encryption is known as asymmetric encryption, as one key, the private key, is used to encrypt the data, while the other key, the public key, is used to decrypt the data.

Once James has created a hash value of the original message, that message is encrypted with James' private key, resulting in the creation of a Digital Signature. This chain of events shows how a Digital Signature serves as an effective fingerprint of the original messageit is derived from the original message through a hash function and encrypted for data integrity and authenticity as James' public key is the only key that can be used to decrypt the hash value. James must therefore securely forward his public key to Charlie so that Charlie can decrypt the hash for verification.

When Charlie receives the original message, a Digital Signature, and public key from James, he must attempt to verify the authenticity and integrity of the message. Charlie's first task is the decryption of the Digital Signature that James had sent with James' public key. The output of this decryption process should be the message digest of the hash of James' original message.

After decrypting the Digital Signature, Charlie now has the original message digest of James' original message. Charlie can now hash James' original message and compare the resulting message digest to the newly decrypted message digest that was sent by James. If the two message digests match, the message is believed to be authentic, with preserved integrity.