Data Privacy and Secure Communications

With the exponential growth in popularity of the Internet, and millions of people using it as a communications highway, data privacy and secure communications have become extremely important. From the Physical Layer to the Application Layer, cryptography is the first of many steps that are necessary to provide a secure communications solution. The IINS exam objectives covered in this chapter are as follows:

• Explain the different methods used in cryptography
• Explain IKE protocol functionality and phases
• Describe the building blocks of IPsec and the security functions it provides
• Configure and verify IPsec site-to-site VPN with pre-shared key authentication using SDM

We teach cryptography and many other security topics in our CompTIA Security+ course.

This chapter is broken up into the following sections:

• Cryptography Overview
• Symmetric Key Cryptography
• Asymmetric Key Cryptography
• Hash Algorithms
• VPN Technologies
• IP Security
• IPsec VPN Configuration in SDM

Back to book index.

Cryptography Overview

Cryptography is the art of protecting information by encrypting, or translating it into an unreadable format, which is then referred to as ciphertext. In order to view ciphertext, users must possess a secret key that can decipher, or decrypt, the message back into plaintext. Cryptographic technologies and solutions help address issues related to information confidentiality, integrity, and access control, which are the three core reasons for security solutions. Cryptography solutions also provide techniques that allow network security administrators to identify unauthorized data modifications and alterations.

A cryptosystem, or cryptographic system, is a framework that involves the application of cryptography to provide secure communications. In essence, a cryptosystem is a collection of protocols, procedures, and algorithms that are required to implement an encoding and decoding system using cryptography. By implementing a cryptosystem, the confidentiality and integrity of information can be achieved by using various methods that employ cryptography, such as encryption and decryption techniques, hash functions, digital signatures, and key management techniques, which will all be described in detail in this chapter.

Cryptographic Terminology

Before delving into the specifics of cryptosystems and related technologies, it is imperative to have a sound understanding of the jargon or terminology used in cryptography. This section describes the following cryptographic terminologies that will be used throughout this chapter and that you should be familiar with:

• Encryption
• Decryption
• Plaintext
• Ciphertext
• Hash
• Virtual Private Network

Encryption is the process of obscuring information to make it unreadable to unauthorized recipients. Encryption employs the use of algorithmic processes that use secret keys to transform plain data into a secret code. Encryption is used to provide data confidentiality.

Decryption is the reverse of encryption. This process is used to make the encrypted information readable by converting the data back into its original form.

Plaintext is information a sender wishes to transmit to a receiver. In other words, it is the original, unencrypted data. Plaintext is used as input to an encryption algorithm.

Ciphertext is the product of the encryption process. This is simply the plaintext data that has been encrypted. It is therefore considered the output of an encryption algorithm.

A hash, also referred to as a message digest, is a unique number from a sequence of text that is generated by applying a mathematical formula. The basic function of a hash is to take a random-length block of data and return a fixed-size bit string, which is then referred to as the hash value or message digest. Any accidental or intentional changes to the data will also result in a change of the hash value. Hashing is used to provide data integrity. For example, the following table lists four different phrases and their corresponding hash values:

Table 9.1. Hash Values

Phase (Random-length Block of Data)	Hash (Fixed-size Bit String)
Cryptography is fun!	690f76027b02363393535937e1e12a44
IINS Security	589ab55fc5929b8fdb5c10bea26a1a18
CCNA	3d645983387566a4af67b11ff5f6bc1d
Howtonetwork is great!	cbb34c101e51142e808dbfd6c6c71a2b

As illustrated in the table above, even though the four phrases contain different numbers of letters (i.e. are different lengths) the hash value for all four values contains exactly the same number of alphanumeric digits (i.e. is a fixed-size bit string).

A Virtual Private Network (VPN) is used to carry private traffic over a public transport, such as the Internet. In all cases, a VPN consists of two endpoints, which may be routers, firewalls, servers, or even individual client workstations. While a VPN can use both cryptographic and non-cryptographic approaches to create a secure communication channel, this chapter focuses exclusively on cryptographic VPN technologies – specifically IP Security, also called IPsec.

The following diagram provides a basic illustration of these components within a cryptosystem:

Figure 9.1. Hash Values Through a VPN

In the diagram illustrated above, Host 1 sends a plaintext message to Host 2. This plaintext is encrypted by R1, which scrambles the data using a hash algorithm. The ciphertext is then forwarded to R4 across the VPN tunnel between R1 and R4. R4 receives the encrypted data and then decrypts it. The plaintext is forwarded to Host 2 and appears as was originally sent by Host 1. Keep in mind that this diagram serves only as a basic representation of the entire process. We will go into detail on these and other terms as we progress through this chapter.

Cryptographic Algorithms

Cryptographic techniques can be classified as either traditional or modern. Traditional techniques use transposition and substitution mechanisms and are sometimes referred to as classical cryptographic techniques.

A transposition mechanism is an encryption method that simply reorders plaintext such that the derived ciphertext represents a variation of the original plaintext. In layman’s terms, transposition simply reorders plaintext, making it illegible.

A substitution cipher is a method of encryption by which units of plaintext are replaced with ciphertext according to a regular system.  The receiver deciphers the text by performing an inverse substitution. A substitution cipher that operates on single letters is referred to as a simple substitution cipher, while a substitution cipher that operates on larger groups of letters is referred to as a polygraphic cipher. Additionally, a monoalphabetic cipher uses fixed substitution over the entire message, whereas a polyalphabetic cipher uses a number of substitutions at different times in the message.

The current IINS certification exam focuses primarily on modern ciphers. Therefore, traditional or classical cryptographic techniques will not be described in any further detail in this chapter. You are only expected to demonstrate detailed knowledge of modern cryptographic techniques.

Modern cryptographic techniques, which will be described in detail in this chapter, rely on sophisticated protocols and algorithms to ensure the security of information. There are three types of cryptographic algorithms:

• Symmetric Key Cryptography
• Asymmetric Key Cryptography
• Hash Algorithms

Symmetric key cryptography uses a single key for the encryption and decryption process. It is also commonly referred to as secret key or pre-shared key cryptography. Symmetric key cryptography will be described in detail later in this chapter.

Asymmetric key cryptography uses two keys for the encryption and decryption process; that is, one key for encryption and another key for decryption. Asymmetric key cryptography is also commonly referred to as public-key cryptography. Asymmetric key cryptography will be described in detail later in this chapter.

Hash algorithms, or hash functions, use a one-way mathematical function to produce an algorithmically randomized unique hash value to identify data. Because of the one-way process, the original message cannot be reconstituted, even with knowledge of the hash algorithm. Hash algorithms will also be described in detail later in this chapter.

Symmetric Key Cryptography

Symmetric key cryptography is used to encrypt the contents of a message to provide data confidentiality. Symmetric key cryptography uses a single shared secret key for the encryption and decryption process. This key is referred to as a symmetric key. Due to the fact that the symmetric key is shared, it must be known to the entity that encrypts the message as well as the entity that is going to eventually decrypt the message. There are two categories of symmetric key cryptography:

• Block ciphers
• Stream ciphers

Block Ciphers

Block ciphers encrypt plaintext in chunks. These ciphers are used to encrypt plaintext on a fixed-length group of bits, with an unvarying transformation during the encryption cycle. A block cipher encrypts blocks of data by using the same key on each block. The block size is typically 64 or 128 bits in length, with the latter being the most commonly used in modern cryptography. However, some ciphers, which will be described later in this chapter, have the ability to use a variable block size.

A block cipher consists of two paired algorithms, one for encryption and another for decryption. Both algorithms accept two inputs. The first is an input block of a particular size, and the second input is the shared secret key, also of a particular size. This allows the block cipher to produce a corresponding 128-bit block of ciphertext. For example, a block cipher encryption algorithm might take a 128-bit block of plaintext as input and produce a corresponding 128-bit block of ciphertext. However, the exact transformation is controlled using a second input, which is the shared secret key. Additionally, it is important to understand that with block ciphers, if the input changes even in the slightest manner (e.g. if a plaintext bit or the secret key is changed), the resultant ciphertext is completely changed. This characteristic is referred to as the avalanche effect.

Most block ciphers are constructed by repeatedly applying a simpler function. These ciphers are known as iterated block ciphers. Iterated block ciphers increase the effectiveness of the encryption algorithm by repeatedly applying the same algorithm. This means that with each repetition, the message is further encrypted. Each single repetition, or iteration, is referred to as a round, and the repeated function is referred to as the round function. The number of rounds selected is usually determined by the computational power available and the security level desired. In general terms, anywhere between four and thirty-two rounds are typical.

Feistel ciphers are a special class of iterated block ciphers, where the ciphertext is calculated from the plaintext by repeated application of the encryption process. The Feistel structure uses similar encryption and decryption operations, which can also be identical.

Block ciphers have several modes of operation. Currently, the National Institute of Standards and Technology (NIST) has approved eight block cipher modes. There are five confidentiality modes, which are ECB, CBC, CFB, OFB, and CTR; one authentication mode, which is CMAC; and two combined modes for confidentiality and authentication, which are CCM and GCM. These modes are defined as follows:

• ECB, which stands for Electronic Code Book, is only as secure as the underlying block cipher. However, plaintext patterns are not concealed. Each identical block of plaintext gives an identical block of ciphertext. The plaintext can be easily manipulated by removing, repeating, or interchanging blocks. The speed of each encryption operation is identical to that of the block cipher. ECB allows easy parallelization to yield higher performance.

• CBC stands for Cipher Block Chaining. In this mode, the initial block is encrypted using an initialization vector that is randomly generated, and then, for additional blocks, the cipher text of an encoded block is simply XORed (i.e. an either-or operation is performed) with the next plaintext block that is to be encoded. This means that the resulting ciphertext not only is a function of the key and the encryption algorithm but also depends on the blocks that were previously encoded.

• CFB, which stands for Cipher Feedback Mode, is only as secure as the underlying cipher and plaintext patterns that are concealed in the ciphertext by the use of the XOR operation. In CFB, the previous ciphertext block is encrypted and the output produced is combined with the plaintext block using XOR to produce the current ciphertext block. An initialization vector is used as a seed for the process. With CFB and full feedback, when two ciphertext blocks are identical, the outputs from the block cipher operation at the next step are also identical. However, it is possible to define CFB so it uses feedback that is less than one full data block. It is important to keep in mind that a block cipher in CFB is essentially a self-synchronizing stream cipher. Stream ciphers are described in the following section.

• OFB, which stands for Output Feedback Mode, is similar to CFB, except that the quantity XORed with each plaintext block is generated independently of both the plaintext and the ciphertext. An initialization vector is used as a seed for a sequence of data blocks, and each data block is derived from the encryption of the previous data block. The encryption of a plaintext block is derived by taking the XOR of the plaintext block with the relevant data block. OFB makes a block cipher into a synchronous stream cipher because it generates keystream blocks. Stream ciphers are described in detail in the following section.

• CTR stands for Counter. This mode is similar to OFB in that it turns a block cipher into a stream cipher. It generates the next keystream block by encrypting successive values of a counter. The counter can be any function that produces a sequence that is guaranteed not to repeat for a long time, although an actual counter is the simplest and most popular.

• CMAC stands for Cipher Block Chaining Message Authentication Code and can also be abbreviated as CBC-MAC. The message is encrypted with some block cipher algorithm in CBC mode to create a chain of blocks such that each block depends on the proper encryption of the previous block. This interdependence ensures that a change to any of the plaintext bits will cause the final encrypted block to change in a way that cannot be predicted or counteracted without knowing the key to the block cipher.

• CCM, which stands for Counter with CBC-MAC, is a modern construction, building on traditional mechanisms developed by RSA. CCM was designed initially for use with packet-oriented security protocols. As such, it includes provisions to authenticate the packet header and the payload while encrypting only the payload. However, CCM can also be used for encrypting files, messages, and other data. CCM uses a single cryptographic key to provide authentication and encryption. The primary advantages offered by CCM are its smaller implementation size, packet header authentication, use of a single key for all cryptographic operations, and solid cryptographic confidence backed by mathematical proof.

• GCM, which stands for Galois/Counter Mode, is an authenticated encryption algorithm designed to provide both authentication and privacy. GCM is defined for block ciphers with a block size of 128 bits. GMAC is an authentication-only variant of the GCM.

An XOR or EOR algorithm, which was described in Chapter 3, is an algorithm that basically means either one or the other, but not both. This concept is illustrated in the following table:

Table 9.2. XOR/EOR Algorithms

First Color Selected	Second Color Selected	Does this make the color green?
Yellow	Blue	Yes
Yellow	Yellow	No
Blue	Yellow	Yes
Blue	Blue	No

In the table above, one of the second colors selected to make the color green must be either yellow or blue, depending on the first color selected. If the first and second color selected is blue, the end result will never be the color green. Likewise, if the first and second color selected is yellow, the end result will never be the color green. The XOR operator would only create the color green if the colors selected were either [yellow + blue] or [blue + yellow], not if they were either [blue + blue] or [yellow + yellow]. 

Stream Ciphers

Unlike block ciphers, stream or state ciphers encrypt plaintext digits (bits or bytes) one by one. This means that the transformation of encrypted output varies during the encryption cycle. In stream ciphers, plaintext bits are combined with a pseudo-random cipher bit stream, referred to as a keystream. The keystream is combined with the plaintext digits one at a time to form the ciphertext, typically via an XOR operation.

There are two categories of stream ciphers: synchronous and self-synchronizing.  In a synchronous stream cipher, a stream of pseudo-random digits is generated independently of the plaintext and ciphertext messages and then combined with the plaintext (to encrypt the data) or the ciphertext (to decrypt the data). In the most common form, binary digits (bits) are used, and the keystream is combined with the plaintext using the XOR operation. This is referred to as a binary additive stream cipher.

In addition to this, when using a synchronous stream cipher, it is important to remember that the sender and the receiver must be exactly in sync for decryption to be successful. If digits are added or removed from the message during transmission, synchronization is lost. To restore synchronization, various offsets can be tried systematically to obtain the correct decryption. Alternatively, another approach that is commonly used is to tag the ciphertext with markers at regular points in the output.

If, however, a digit is corrupted in transmission, rather than added or lost, only a single digit in the plaintext is affected and the error does not propagate to other parts of the message. This property is useful when the transmission error rate is high; however, it makes it less likely the error would be detected without further mechanisms. Moreover, because of this property, synchronous stream ciphers are very susceptible to active attacks whereby an attacker changes a digit in the ciphertext, allowing him or her to make predictable changes to the corresponding plaintext bit; for example, flipping or changing a single bit or byte in the ciphertext causes the same bit or byte to be flipped or changed in the plaintext.

Self-synchronizing stream ciphers use several of the previous ciphertext digits to compute the keystream. These stream ciphers are also commonly referred to as self-synchronizing stream ciphers, asynchronous stream ciphers, or ciphertext autokey (CTAK). Self-synchronizing stream ciphers allow the receiver automatically to synchronize with the keystream generator after receiving ciphertext digits, making it easier to recover if digits are dropped or added to the message stream. This limits the effects of single-digit errors. An example of a self-synchronizing stream cipher is a block cipher in cipher-feedback mode.

Because these terms are relatively confusing, keep in mind that the generation of the keystream in stream ciphers can be independent of the plaintext and ciphertext, resulting in a synchronous stream cipher. Alternatively, the generation of the keystream can also depend on the data and its encryption, in which case the stream cipher is self-synchronizing. Additionally, also remember that the majority of stream cipher designs are for synchronous stream ciphers.

Binary stream ciphers are often constructed using linear feedback shift registers (LFSRs) because they can easily be implemented in hardware and can readily be analyzed mathematically. LFSR is a mechanism for generating a sequence of binary bits. Delving into further details on LSFRs is beyond the scope of the IINS course requirements.

Stream ciphers attempt to operate in the same manner as the one-time pad, or OTP, which is also referred to as the Vernam cipher. OTP uses a string of bits that is generated completely at random. Because of this, OTP is said to offer perfect secrecy, and the analysis of the OTP is seen as one of the cornerstones of modern cryptography. OTP has proven, in theory, to be an unbreakable cipher; however, it must be noted that while perfectly secure, the OTP is, in general, impractical.

Because the information covered in this section may be quite overwhelming at first glance, keep in mind that a block cipher mode yields the same ciphertext from a block of plaintext when using the same key; however, a stream cipher mode yields different ciphertext from the same plaintext. Use this as a baseline to remember the different modes of operation and algorithms that are used for block ciphers and stream ciphers. We will conclude this section by describing some of the most common symmetric cryptographic algorithms, which are as follows:

• Digital Encryption Standard
• Triple-Digital Encryption Standard
• Advanced Encryption Standard
• RC4
• International Data Encryption Algorithm
• Blowfish

Data Encryption Standard

The Data Encryption Standard (DES) is a block cipher algorithm and is the name of the Federal Information Processing Standards (FIPS), which describes the data encryption algorithm (DEA). DEA is also defined in the ANSI standard X3.92. DES was adopted by the NIST in 1977 for commercial and unclassified government documents. DEA, often called DES, has been extensively studied since its initial publication and is perhaps the best-known and most commonly used symmetric algorithm in the world.

DEA has a 64-bit block size and uses a 56-bit key during execution because parity bits are stripped off from the full 64-bit key. DEA is a symmetric cryptosystem, specifically a 16-round Feistel cipher, which was originally designed for implementation in hardware. When used for communication, both sender and receiver must know the same secret key, which can be used to encrypt and decrypt the message or to generate and verify a message authentication code (MAC). DEA can also be used for single-user encryption, such as to store files on a hard disk in encrypted form. In a multi-user environment, secure key distribution may be difficult; however, public-key cryptography provides an ideal solution to this problem. Public-key cryptography will be described in detail later in this chapter.

DES uses both block and stream cipher modes to encrypt or decrypt more than 64 bits of data. For block cipher mode, DES uses Electronic Code Book (ECB) or Cipher Block Chaining (CBC) to provide data confidentiality. However, for stream cipher mode, DES uses Cipher Feedback Mode (CFB) or Output Feedback Mode (OFB) to provide data confidentiality. The following diagram illustrates the basic DES encryption process:

Figure 9.2. Basic DES Encryption

In the diagram illustrated above, Host 1 wants to send a plaintext message to Host 2. This data is sent to R1, where it is encrypted with a shared key and sent over the IP network in an unreadable format until it is received by R4. R4, in turn, decrypts the ciphertext using the shared key and the resulting plaintext is forwarded on to Host 2.

In modern-day networks, DES is no longer considered very secure, primarily because the inherent 56-bit key size is too small. DES has been known to be compromised in less than 24 hours. However, in the case of Triple DES, the documented key-breaking times are approximately 10 billion years when one million PC 3 computers are used. As a result, Triple DES, which is described next, is recommended instead of DES.

Triple-Digital Encryption Standard

Triple-DES is a block cipher and is a variant of DES that encrypts the plaintext with the DES algorithm three times. Three keys are used to encrypt data, resulting in a 168-bit key, which is calculated by multiplying the original DES key size of 56 by 3. The following six steps serve to illustrate the manner in which Triple-DES, or 3DES, operates:

1. The sending device encrypts the data with the first 56-bit key.
2. The sending device decrypts the data with the second key, also 56-bits long.
3. The sending device encrypts the data for a final time with another 56-bit key.
4. The receiving device decrypts the data with the first 56-bit key.
5. The receiving device then encrypts the data with the second key, also 56-bits long.
6. Finally, the receiving device decrypts the data with the third and final 56-bit key.

The end goal of DES and 3DES is to provide data confidentiality by hiding secret data. The data must have integrity to ensure that it has not been modified in any manner or form, and it must be authenticated by ensuring that the source or destination endpoint is indeed what it professes to be. Data integrity and authentication mechanisms will be described later in this chapter.

Advanced Encryption Standard

AES is a block cipher algorithm that stands for Advanced Encryption Standard. AES was issued as FIPS PUB 197 by the NIST as the proposed successor to DES. In January 1997, the AES initiative was announced, and in September 1997, the public was invited to propose suitable block ciphers as candidates for AES. The AES algorithm was selected in October 2001 and the standard was published in November 2002. NIST’s intent was to have a cipher that would remain secure well into the next century. AES is one of the most commonly used algorithms amongst the symmetric key cryptography implementations.

The AES algorithm can use a variable block and key length. AES supports key sizes of 128 bits, 192 bits, and 256 bits, in contrast to the 56-bit keys offered by DES. The AES algorithm resulted from a multi-year evaluation process led by the NIST with submissions and review by an international community of cryptography experts. The Rijndael algorithm, invented by Joan Daemen and Vincent Rijmen, was selected as the standard. Over time, many implementations are expected to upgrade to AES, both because it offers a 128-bit key size, and because it is a federal standard.

Unlike its predecessor, DES, AES does not use a Feistel network. Instead, AES encryption is an algorithm based on permutations. For the mathematically inclined, AES is based on a design principle known as a Substitution-Permutation Network (SPN). This makes AES very fast in both software and hardware. Additionally, this means that AES is relatively easy to implement and requires little memory. Going into the details pertaining to the algorithm used is beyond the scope of the IINS course requirements; however, at a very high level, AES operates as follows:

• AES encryption receives the message or information (plaintext) that needs to be sent as an input.

• This information is then scrambled using the shared key during the encryption process. The bigger the key used, the larger the scrambled output. For example, a 512-bit shared key will produce larger ciphertext output than a 128-bit shared key.

• Finally, the generated ciphertext is then sent to the recipient, as illustrated in the following diagram:

Figure 9.3. Overview of AES Encryption

The recipient then uses the shared secret key to decrypt the ciphertext and read the message. This process makes AES very secure. You are not required to demonstrate knowledge of the AES encryption algorithm(s). However, ensure that you have a basic understanding of the overall process used in AES encryption.

AES is so secure that up until May 2009, the only successful published attacks against the full AES were side-channel attacks on specific implementations. A side-channel attack is any attack that is based on information gained from the physical implementation of a cryptosystem, rather than brute force or theoretical weaknesses in the algorithms used by the method of encryption. For example, in April 2005, D.J. Bernstein announced a cache-timing attack that he used to break a custom server that used OpenSSL’s AES encryption. The custom server was designed to give out as much timing information as possible, and the attack required over 200 million chosen plaintexts in order to be successful. 

RC4

RC4 is the most widely-used software stream cipher. This cipher was designed by Rivest for RSA Data Security, now RSA Security. RC4 is also known as ARC4 or ARCFOUR. RC4 is used in popular protocols such as Secure Sockets Layer (SSL) and Wired Equivalent Privacy (WEP), which is used to secure wireless networks.

RC4 is a variable-key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation. Although independent analysts have scrutinized the algorithm and it is considered secure, RC4 has weaknesses that argue against its use in new systems. For example, it is especially vulnerable when the beginning of the output keystream is not discarded, when nonrandom or related keys are used, or when a single keystream is used twice. As a result, some ways of using RC4 can lead to very insecure cryptosystems, such as WEP.

RC4 generates a pseudo-random keystream that, for encryption, is combined with the plaintext using bit-wise XOR. Because RC4 is a symmetric cryptographic algorithm, decryption is also performed the same way. To generate the keystream, the cipher makes use of a secret internal state that consists of two parts:

• A permutation of all 256 possible bytes
• Two 8-bit index-pointers

The permutation is initialized with a variable-length key, typically between 40 and 256 bits, using the key-scheduling algorithm, or KSA, which is used to initialize the permutation. Upon completion, the stream of bits is generated using the pseudo-random generation algorithm, which is abbreviated as PRGA. For as many iterations as are needed, the PRGA modifies the state and outputs a byte of the keystream. The design of RC4 avoids the use of LFSRs and is ideal for software implementation, as it requires only byte manipulations. The algorithm used in RC4 is extremely complex and is beyond the scope of the IINS course requirements.

International Data Encryption Algorithm

IDEA, which stands for International Data Encryption Algorithm, is a block cipher designed and presented by Lai and Massey. IDEA is a 64-bit iterative block cipher with a 128-bit key. The encryption process requires eight complex rounds. In other words, the data is encrypted eight times over. While the cipher does not have a Feistel structure, because it is a symmetric cryptographic algorithm, the decryption process is carried out in the same manner as encryption once the decryption subkeys have been calculated from the encryption subkeys.

The cipher structure was designed to be easily implemented in both software and hardware, and the security of IDEA relies on the use of three incompatible types of arithmetic operations on 16-bit words. However some of the arithmetic operations used in IDEA are not particularly fast in software. As a result the speed of IDEA in software is similar to that of DES. IDEA is generally considered to be a very secure cipher, and both the cipher development and its theoretical basis have been openly and widely discussed. Going into specific detail on the IDEA algorithm is beyond the scope of the IINS course requirements. 

Blowfish

Blowfish is a 64-bit block cipher developed by Bruce Schneier. While Blowfish provides a good encryption rate in software and has yet to be cracked, it is not as popular as AES. Blowfish is a Feistel cipher and each round consists of a key-dependent permutation and a key-and-data-dependent substitution. All operations are based on XORs and additions on 32-bit words. The key that is used has a variable length, with a maximum length of 448 bits, and is used to generate several subkey arrays. This cipher was designed specifically for 32-bit machines and is significantly faster than DES.

While going into specific details on Blowfish is beyond the scope of the IINS course requirements, it is important to remember that it was designed as a general-purpose algorithm, intended as a replacement for the aging DES. In other words, Blowfish is unpatented and can be used by anyone, anywhere in the world.

Asymmetric Key Cryptography

Now that we have a solid understanding of symmetric key cryptography, we are going to be learning about asymmetric key cryptography, which is also referred to as public-key cryptography. In this section, we are going to learn about asymmetric key cryptography and conclude with the most common public-key algorithms. It is important to remember that in this section, and throughout this guide, asymmetric key cryptography and public-key cryptography mean the same thing and are used interchangeably.

Public-Key Cryptography Overview

Asymmetric key cryptography design uses a two-key pair. One key is used to encrypt the plaintext and the other key is used to decrypt the ciphertext. Unlike symmetric key cryptography, two parties using public-key cryptography can communicate securely over an insecure channel without having to share a secret key.

Public-key cryptography is typically used in digital certification and key management, both of which will be described later in this chapter. However, in theory, asymmetric key cryptography could also be used to actually encrypt data, although this is rarely done because symmetric key cryptography is much more efficient and much less computationally intensive than asymmetric key cryptography. The following diagram provides a basic illustration of the operation of asymmetric key cryptography:

Figure 9.4. Asymmetric Key Cryptography

In the diagram above, Host 1 wants to send a message to Host 2. Using public-key cryptography, the plaintext is encrypted using the public key of Host 2. The cipher text is then sent over an insecure communications channel, such as the Internet, which is used in this example. In order for Host 2 to view the message, it must decrypt the ciphertext using its private key. Once decrypted, the plaintext message is legible. The same process would be applicable if Host 2 sent data to Host 1.

In asymmetric key cryptography, it is important to know that the public key is widely distributed to all users; however, the private key is never exchanged or revealed to any other party. Another variation of the asymmetric key approach is used to validate the identity of the sender by having the sender encrypt the message using their private key and the receiver decrypt the message using the public key of the sender. If the key pairs match, then the process will work; if not, the message will not be decrypted. This method is typically used to provide non-repudiation, which simply means that the sender cannot deny, or repudiate, that he or she sent the message. This concept is analogous to being captured on camera in broad daylight. Once you view the tape, you cannot deny that it was in fact you.

The two types of asymmetric key cryptography are public key encryption and digital signatures. When public key encryption is employed, a message encrypted with a recipient’s public key cannot be decrypted by anyone except a possessor of the matching private key. Referencing the diagram used in the previous example, because the plaintext is encrypted using Host 2s public key, only Host 2 can decrypt the message using the corresponding private key. This method is used for data confidentiality.

When digital signatures are employed, a message signed with a sender’s private key can be verified by anyone who has access to the sender’s public key, thereby proving that the sender had access to the private key and that the message has not been tampered with. This is used to ensure the authentication of messages, i.e. authenticity.

Public Key Infrastructure (PKI) schemes may employ a trusted third party that issues digital certificates for use by other parties. This trusted third party is referred to as a Certificate Authority or Certification Authority (CA). The CA issues digital certificates that contain a public key and the identity of the owner; however, the private key is never disclosed.  The CA signs the public keys of entities in PKI-based systems. If the entity trusts the CA and can verify the CA’s signature, then it can also verify that a certain public key does indeed belong to the person identified in the certificate.

The asymmetric key cryptography algorithms that will be described in this section are:

• Rivest, Shamir, and Adleman
• Diffie-Hellman
• Digital Signature Algorithm and Digital Signature Standard
• Public-Key Cryptography Standards

Rivest, Shamir, and Adleman

The RSA algorithm was invented by Ronald L. Rivest, Adi Shamir, and Leonard Adleman in 1977. RSA is an asymmetric cipher and is the first greatest advancement that used the asymmetric cryptography mechanism, suitable for both digital signing and encryption. RSA is one of the most popular and widely implemented asymmetric algorithms that can be used for key exchange, digital signatures, and message encryption. The RSA algorithm involves key generation, encryption, and decryption.

The RSA key generation process is used to generate the public and the private keys. The public key is typically known to everyone (i.e. is non-secret) and is used for encrypting messages. Messages encrypted with the public key can only be decrypted using the private key, which is secret. The details pertaining to the computation of the RSA algorithm are beyond the scope of the IINS course requirements. They will not be described in this chapter.

RSA encryption and decryption processes use both public and private keys. Public keys are used to encrypt messages and create ciphertext from plaintext, while private keys are used to decrypt messages and create plaintext from ciphertext. When used in practice, RSA is generally combined with some padding scheme, which further secures RSA. Padding is the process of preparing a message for encryption or signing with a low-level cryptographic algorithm, such as a one-way hash function. Standards such as PKCS #1 have been carefully designed to securely pad messages prior to RSA encryption. PKCS is described in detail later in this section.

RSA has proven to have several disadvantages and flaws from a security perspective. One of the main weaknesses of RSA is that it is significantly slower to compute when compared to other secret-key algorithms, such as DES and Triple-DES. Additionally, RSA has some security implications that should be considered. For example, Cisco’s IKE implementation uses a Diffie-Hellman exchange to get the secret keys. With the Diffie-Hellman exchange, if DES is used, the key never crosses the network, which is not the case with RSA encryption and signing. IKE and Diffie-Hellman will be described later in this chapter.

Another disadvantage that is important to know is that RSA is not public domain. In other words, you must be licensed by RSA Data Security to use RSA. From a security perspective, Branch Prediction Analysis (BPA) attacks, which use a spy process running alongside the RSA process, allow attackers to collect almost all the secret bits used in an RSA signing operation by monitoring the states of a CPU. This information allows attackers successfully to extract almost all secret key bits used by RSA – effectively cracking it. Additionally, RSA has also effectively been cracked by using an Adaptive Chosen Ciphertext Attack (CCA2), which is an attack where an attacker sends a number of ciphertexts to be decrypted and then proceeds to use the results of these decryptions to select subsequent ciphertexts.

RSA algorithms are available in varying standards, such as RC1, RC2, RC3, RC4, RC5, and RC6. All RC ciphers were named after Ronald Rivest (the abbreviation RC stands for Ron’s Code). RC4 has already been described earlier in this chapter; RC3 was broken at RSA Security during development and was never published; and RC1 was also never published. The following section provides a brief description of RC2, RC5, and RC6:

• RC2 is a block cipher designed by Ron Rivest. RC2 has a block size of 64 bits and is about two to three times faster than DES in software. An additional string, between 40 to 88 bits long, referred to as salt, can be used to thwart attackers who try to pre-compute a large look-up table of possible encryptions.

• RC5 is a fast block cipher also designed by Ronald Rivest. The RC5 algorithm uses a variable block size, a variable key size, and a variable number of rounds. Block sizes can be 32 bits, 64 bits, or 128 bits in length. The number of rounds can range from 0 to 255, while the key can range from 0 bits to 2040 bits in size. There are three routines in RC5: key expansion, encryption, and decryption. Going into detail on these is beyond the scope of the IINS course requirements.

• RC6 is a block cipher based on RC5 and was designed by Rivest, Sidney, and Yin. Like RC5, RC6 uses a variable block size, key size, and number of rounds; again, the upper limit on the key size is 2040 bits.

Diffie-Hellman

The Diffie-Hellman algorithm, abbreviated as DH, was introduced shortly after the RSA algorithm was published. DH allows two parties to establish a shared secret over insecure communications channels, such as the Internet. Diffie-Hellman is a public-key distributing system, also known as a key-exchange protocol, which uses asymmetric key cryptography. Contrary to the RSA algorithm, DH is not used for authentication or digital signatures. Instead, it is used only for secret key exchange.

DH ensures that by exchanging just the public keys, both devices can generate a session and ensure that data is encrypted and decrypted by valid sources only. It is imperative to keep in mind that only public keys are exchanged (in clear text) over the public network. Private keys will never be exchanged over the network. By using each device’s public key, and running the key through the DH algorithm, a common session key is generated, which can then be used to encrypt subsequent messages using a symmetric key algorithm.

The DH protocol has two system parameters: p and g. They are both public and may be used by all the users in a system. Parameter p is a prime number and parameter g, which is usually called a generator, is an integer less than p. These two non-secret (public) numbers must be agreed upon by both parties before the DH exchange process can begin. If the two parties do not agree on these two non-secret numbers, the DH exchange will not proceed.

The following diagram illustrates a basic Diffie-Hellman exchange between two hosts that want to agree on a shared secret key:

Figure 9.5. Diff e-Hellman Exchange

In the diagram above, Host 1 and Host 2 want to agree on a shared secret key using the Diffie-Hellman key agreement protocol. The first thing that happens is that both Host 1 and Host 2 generate a random private value drawn from the set of integers, as illustrated in step 1. Next, Host 1 and Host 2 derive their public values using parameters p and g and their private keys, as illustrated in step 2.

In the third step of the process, Host 1 and Host 2 exchange their public values. Finally, as illustrated in step 4, Host 1 and Host 2 compute the shared secret key. This symmetric shared key is then used to facilitate the secure exchange of data between Host 1 and Host 2.

While the DH protocol depends on the discrete logarithm problem, which assumes that it is computationally infeasible to calculate the shared secret key, its security is still susceptible to other attacks, with the most common being MITM attacks. For example, referencing the diagram used in the explanation of the protocol operation, an attacker intercepts Host 1’s public key and sends his or her own public key to Host 2, and when Host 2 transmits its public value, the attacker substitutes it with his or her own public value and sends it to Host 1. Thus, the attacker and Host 1 agree on one shared key and the attacker and Host 2 agree on another shared key.

After this exchange, the attacker simply decrypts any messages sent out by Host 1 or Host 2, and then reads and possibly modifies them before re-encrypting with the appropriate key and transmitting them to the other party. This vulnerability is present because Diffie-Hellman key exchange does not authenticate the participants. However, this can be mitigated by including the use of digital signatures and the authenticated Diffie-Hellman key agreement protocol.

The authenticated Diffie-Hellman key agreement protocol, or Station-to-Station (STS) protocol, was developed in 1992 to defeat the MITM attack on the Diffie-Hellman key agreement protocol. The immunity is achieved by allowing the two parties to authenticate themselves to each other by the use of digital signatures and public-key certificates, both of which will be described in the following sections in this chapter.

The basic idea behind STS is that prior to execution of the protocol, the two parties (e.g. Host 1 and Host 2) each obtain a public and private key pair, as well as a certificate for the public key. During the protocol, Host 1, for example, computes a signature on certain messages, covering the public value. Host 2 proceeds in a similar way. Even though an attacker is still able to intercept messages between Host 1 and Host 2, the attacker cannot forge signatures without Host 1’s private key and Host 2’s private key. Hence, the enhanced protocol defeats the MITM attack.

Digital Signature Algorithm and Digital Signature Standard

Digital Signature Algorithm (DSA) is an asymmetric key algorithm proposed by the NIST in 1991 for their use in Digital Signature Standard. DSA is also a Federal Information Processing Standards (FIPS) standard for digital signatures.

DSA is based on the discrete logarithm problem, which is also used by the DH protocol. Unlike RSA, which can be used for both encryption and digital signatures, the DSA can only be used to provide digital signatures, which ensures the authentication of messages. Additionally, in DSA, signature generation is faster than signature verification, whereas with the RSA algorithm, signature verification is very much faster than signature generation.

The use of digital signatures protects data from undetected changes while traversing the network. This is typically accomplished by using a hashing algorithm in conjunction with DSS. Hashing algorithms, such as MD5, will be described in the following section in this chapter. The following diagram provides an illustration of the DSS signature generation used in conjunction with a keyed-hash algorithm that ensures that data is protected over an insecure channel:

Figure 9.6. DES Signature Generation with Keyed-Hash

Given that the diagram illustrated above is self-explanatory, and to avoid being redundant, we will not describe the step-by-step process illustrated above. However, it is worth pointing out the fact that it is imperative that the computed and decrypted hash values are the same. If they are not, this indicates that the data has been modified along the way.

Public-Key Cryptography Standards

Public-Key Cryptography Standards (or PKCS) is a set of interoperable public-key cryptography standards and guidelines designed and published by RSA Data Security. There are numerous PKCS standards; and while going into detail on them is beyond the IINS course requirements, the following table lists and describes these standards:

Table 9.3. PKCS Standards

Standard	Description
PKCS # 1	RSA Cryptography Standard. Defines the mathematical properties and format of RSA public and private keys and the basic algorithms and encoding/padding schemes for performing RSA encryption, decryption, and producing and verifying signatures. Standardized in RFC 3447.
PKCS # 2	This standard was withdrawn and merged into PKCS # 1. It covered RSA encryption of message digests. This standard is no longer active.
PKCS # 3	This specifies the Diffie-Hellman Key Agreement Standard.
PKCS # 4	This standard was withdrawn and merged into PKCS # 1. It covered RSA key syntax. This standard is no longer active.
PKCS # 5	This specifies the Password-based Encryption Standard. It was standardized in RFC 2898.
PKCS # 6	This specifies the Extended-Certificate Syntax Standard. It defines extensions to the old X.509v1 certificate specification, which was made obsolete by X.509v3.
PKCS # 7	This specifies the Cryptographic Message Syntax Standard. It is used to sign or encrypt messages under a Public Key Infrastructure, or PKI. It is standardized in RFC 2315. This standard describes general syntax for encrypted messages and messages with digital signatures.
PKCS # 8	This specifies the Private-Key Information Syntax Standard. Used to carry private certificate keypairs, which may be encrypted or unencrypted.
PKCS # 9	This specifies the Selected Attribute Types and defines these types for use in PKCS #6 extended certificates, PKCS #7 digitally signed messages, PKCS #8 private-key information, and PKCS #10 certificate-signing requests. It is standardized in RFC 2985.
PKCS # 10	This specifies the Certification Request Syntax Standard, as specified in RFC 2986. It defines the format of messages sent to a Certification Authority to request certification of a public key.
PKCS # 11	This specifies the Cryptographic Token Interface, or cryptoki. It is an API that defines a generic interface to cryptographic tokens. It is often used for single sign-on and smart card authentication.
PKCS # 12	This specifies the Personal Information Exchange Syntax Standard. It defines a file forma commonly used to store private keys with accompanying public-key certificates protected with a password-based symmetric system. This standard can be used as a format for the Java key store.
PKCS # 13	This specifies the Elliptic Curve Cryptography (ECC) Standard. This is still under development.
PKCS # 14	This specifies the Pseudo-Random Number Generation (PRNG) Standard. PRNG is an algorithm that is used to generate a sequence of numbers that is not truly random.
PKCS # 15	This specifies the Cryptographic Token Information Format Standard. It defines a standard allowing users or cryptographic tokens to identify themselves to applications, independent of the application’s cryptoki (PKCS # 11) implementation or other Application Programming Interface (API).

 Hash Algorithms

Hash algorithms are referred to by many various names. They may be referred to as a hash function, a message digest, or one-way encryption. Hash algorithms use a mathematical formula to compute a fixed-length hash value based on the original plaintext. One significant advantage to hashing plaintext is that the original message cannot be reconstituted, even with knowledge of the hash algorithm.

Hash functions are generally faster than encryption algorithms and are typically used to provide a digital fingerprint of any type of data to ensure that information has not been modified or altered during transmission, which provides information integrity. Additionally, hash algorithms are commonly used for both data integrity and digital certificates. In a manner similar to block ciphers, hash algorithms are also susceptible to the avalanche effect, which results in completely different ciphertext, if even a single bit in the plaintext is changed. For example, the MD5 hash for the word Test is 0cbc6611f5540bd0809a388dc95a615b; but if the entire word was written in lower-caps (i.e. test) the resulting MD5 hash would be 098f6bcd4621d373cade4e832627b4f6.

The following two hash algorithms will be described in detail in the next two sections:

• Message Digest
• Secure Hash Algorithm

Message Digest

Message Digest (MD) algorithms are a series of byte-oriented cryptographic hash functions that take variable-length data and produce a mathematically computed 128-bit fixed-length hash value. This hash is commonly referred to as the fingerprint, message digest, or simply just as the digest. There are three message digest algorithms, all developed by Rivest, which are:

• MD2
• MD4
• MD5

MD2 is standardized in RFC 1319.  This algorithm was developed by Rivest in 1989, and was designed and optimized for 8-bit machines, or machines with limited memory, such as smart cards.

MD4 was developed by Rivest in 1989 and standardized in RFC 1320. MD4 was designed and optimized for 32-bit machines. MD4 is similar to MD2 but was designed specifically for faster processing in software.

Because MD2 and MD4 are considered broken – i.e. have been cracked – Rivest designed MD5 in 1991. MD5 is standardized in RFC 1321 and is similar to MD4, although additional enhancements have been added to provide better security. For example, salt – an additional string of bits (which was described earlier in this chapter) – can be used with MD5 to enhance security. MD5 remains popular and is widely used in various products and applications.

For example, the enable secret command used in Cisco IOS software uses an MD5 hashing algorithm. However, it should be noted that MD5 is no longer considered very secure because it has been documented that it can be broken. The following diagram provides a basic illustration of the MD5 hashing algorithm:

Figure 9.7. MD5 Hashing

Secure Hash Algorithm

Secure Hash Algorithm (SHA) is another series of popular cryptographic hash algorithms. SHA is the newer, more secure version of MD5, and Hash-based Message Authentication (HMAC) provides further security with the inclusion of a key exchange.  HMAC, which can be used in conjunction with SHA, is a type of message authentication code (MAC) that may be used to verify data integrity and the authenticity of a message. The cryptographic strength of the HMAC depends on the cryptographic strength of the underlying hash function, on the size and quality of the key, and on the size of the hash output length in bits. Going into detail on the algorithms used in HMAC is beyond the scope of the IINS course requirements.

SHA produces a 160-bit output and was developed by the National Security Agency (NSA) and published as a US government standard. The SHA algorithm is also used in NIST’s Secure Hash Standard (SHS). While SHA is computationally slower than MD5, it is much more secure. As is the case with MD, there are several versions of the SHA hash algorithm, which are:

• SHA-0
• SHA-1
• SHA-2
• SHA-3

SHA-0 was the original specification of the algorithm published in 1993. At that time, it was published as the Secure Hash Standard. SHA-0 did not have a long lifespan and was withdrawn by the NSA shortly after publication to be superseded by SHA-1. Due to the sensitive nature of the algorithm, the only information provided by the NSA on the migration to SHA-1 was that there was a need to correct a flaw in the SHA-0 algorithm that reduced its cryptographic security.

SHA-1 was introduced in 1995 and standardized in RFC 3147. SHA-1 is used in a variety of applications and protocols, including, but not limited to, Transport Layer Security (TLS), Pretty Good Privacy (PGP), Secure Sockets Layer (SSL), Secure Shell (SSH), and IP Security (IPsec).  SSL and SSH have already been described in this guide. IPsec will be described later in this chapter.

TLS is the successor of SSL. Like SSL, TLS is a cryptographic protocol that provides security for communications over networks such as the Internet. Both TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end. TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography. TLS provides RSA security with 1024 and 2048 bit strengths. TLS involves three basic phases, which are peer negotiation for algorithm support, key exchange and authentication, and symmetric cipher encryption and message authentication.

PGP is a software package developed by Philip Zimmermann that provides cryptographic routines for email and file storage applications. PGP is most commonly used for signing, encrypting, and decrypting emails to increase the security of email communications. SHA-1 is based on principles similar to those used by Rivest in the design of the MD4 and MD5 message digest algorithms.

Four additional variants of SHA have also been introduced. These variants, which are collectively referred to as SHA-2, are SHA-224, SHA-256, SHA-384, and SHA-512. These variants are described in RFC 4634. SHA-256 and SHA-512 are novel hash functions computed with 32- and 64-bit words, respectively. They use different shift amounts and additive constants, but their structures are otherwise virtually identical, differing only in the number of rounds. SHA-224 and SHA-384 are simply truncated versions of SHA-256 and SHA-512, computed with different initial values. However, it should be noted that these hash functions are not as widely used as SHA-1, even though they provide much better security, because protocols like SSL do not make it easy to introduce new hash functions without breaking backwards compatibility.

SHA-3 is still in the development phase and has yet to be standardized. As of the time of this writing, the publication of the new standard is scheduled to take place in the year 2012. 

VPN Technologies

As defined in RFC 2828, a Virtual Private Network (VPN) is:

A restricted-use, logical (i.e., artificial or simulated) computer network that is constructed from the system resources of a relatively public, physical (i.e., real) network (such as the Internet), often by using encryption (located at hosts or gateways), and often by tunneling links of the virtual network across the real network.

There are three distinct types of VPN technologies that are available today, as follows:

• Secure Virtual Private Networks
• Trusted Virtual Private Networks
• Hybrid Virtual Private Networks

Secure Virtual Private Networks

Secure VPNs are also referred to as Cryptographic VPNs. These VPN types use cryptographic technologies and protocols to ensure the confidentiality, integrity, and authenticity of data. Secure VPNs are often deployed over insecure communication channels, such as the Internet. These VPN types are commonly used to replace or augment existing point-to-point networks that utilize dedicated leased lines (e.g. T1/E1 and T3/E3 circuits) or even WAN networks over common technologies such as Frame Relay. Secure VPN technologies include:

IP Security (IPsec)

• Layer 2 Tunneling Protocol (L2TP) over IPsec
• Point-to-Point Tunneling Protocol (PPTP)
• SSL Encryption (SSL VPN)

The only secure VPN technology that you are required to demonstrate detailed knowledge of, as well as configure and troubleshoot, as a requirement of the IINS certification is IPsec VPNs.

However, it is important that you demonstrate some basic knowledge on the other secure VPN technologies listed above. IPsec will be described in the next section in this chapter.

The Layer 2 Tunnel Protocol (L2TP) is an emerging Internet Engineering Task Force (IETF) standard that combines the best features of two existing tunneling protocols: Cisco’s Layer 2 Forwarding (L2F) and Microsoft’s Point-to-Point Tunneling Protocol (PPTP). L2F is beyond the scope of the IINS course requirements. L2TP is one of the key building blocks for virtual private networks in the dial access space. It does not provide any encryption on its own but can be deployed in conjunction with IPsec to provide encryption services and data confidentiality.

The Point-to-Point Tunneling Protocol (PPTP) is a method for implementing virtual private networks. In a manner similar to L2TP, PPTP does not provide confidentiality or encryption by itself and, as such, is typically deployed in conjunction with IPsec to provide encryption services and data confidentiality. PPTP has been made obsolete by L2TP and IPSec.

The SSL VPN solution offers a flexible and highly secure way to extend network resources to virtually any remote user with access to the Internet and a web browser. Unlike traditional VPNs that require software programs to allow client machines to connect to the VPN, the SSL VPN is accessible via HTTP over almost all web browsers. This flexibility allows SSL VPN technology to be customized for special applications, for example.

SSL VPNs support asymmetric algorithms, such as RSA and the Diffie-Hellman protocol, for authentication and key exchange. Additionally, SSL VPNs use symmetric algorithms, such as DES, Triple-DES, and AES, for encryption. SSL VPNs are becoming very popular and are perceived by many as a solid alternative and possible replacement for all IPsec VPNs. However, it should be noted that SSL VPNs can be deployed on routers in conjunction with IPsec VPNs (although this does have some performance impact), allowing greater secure VPN flexibility.

The three most common secure VPN deployment scenarios are:

• Intranet-based VPNs
• Internet-based VPNs
• Extranet-based VPNs

An Intranet-based VPN is used to provide protection for private communications within an enterprise or organization that may or may not involve traffic traversing a WAN. An Intranet-based VPN connection takes advantage of IP connectivity in an organization intranet. The following diagram illustrates an Intranet-based VPN. This VPN type is used to allow secure communication between users and hosts in the Sales and Finance departments of Company Z:

Figure 9.8. Intranet VPN

Internet-based VPNs are the most common types of VPNs. These VPNs protect private communications over the public network, or Internet. Internet-based VPNs can take several forms. Although there are numerous types of secure Internet-based VPNs, the only type that falls within the confinements of the IINS course requirements is a site-to-site VPN using IPsec. The following diagram serves to illustrate a typical site-to-site Internet-based VPN between two different office locations of the same company:

Figure 9.9. Internet VPN

Another common Internet-based VPN is a remote access VPN. A remote access VPN is used to establish a secure connection to a trusted network over unsecure communications channels, such as the Internet. A remote access VPN is illustrated in the following diagram:

Figure 9.10. Remote Access VPN

In the diagram illustrated above, the home-based employee uses a remote VPN to establish a secure connection to the corporate network. The home-based employee uses software installed onto his or her PC to establish a connection to the VPN termination device, also referred to as the headend VPN device. Once a secure connection has been established, the home-based employee is able to access internal network resources in the same manner as employees physically located at the corporate office.

Extranet-based VPNs provide private communications between two or more separate entities. For example, a company can deploy an extranet VPN between its headquarters to certain business partner networks. The business partner is given access only to the headquarters’ public server to perform various IP-based network tasks, such as placing and managing product orders, as illustrated in the following diagram:

Figure 9.11. Extranet VPN

Trusted Virtual Private Networks

Trusted VPNs are also referred to as non-cryptographic VPNs. These VPN technologies are usually provided by a dedicated service provider. Trusted VPNs allow service providers to offer a dedicated or leased circuit or channel to a customer, which allows pseudo point-to-point communication for different customer locations.

Unlike secure VPNs, the security and integrity of trusted VPN traffic relies on the fact that the circuit is not shared because each circuit is dedicated to a single site. Trusted VPN technologies are beyond the scope of the IINS course requirements and will not be described further.

Hybrid Virtual Private Networks

A hybrid VPN is a combination of both a trusted VPN and a secure VPN. Hybrid VPNs are an emerging technology that is slowly gaining momentum. While going into detail on the hybrid VPN technologies is beyond the scope of the IINS course requirements, it is important to note that a hybrid VPN is only secure in the parts that are based on secure VPNs. That is, adding a secure VPN to a trusted VPN does not increase the security for the entire trusted VPN, only to the part that was directly secured. The secure VPN only acquires the advantages of the trusted VPN. 

IP Security

As stated in RFC 2401:

IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more “paths” between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term “security gateway” is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.)

The IPsec framework is a set of open standards developed by the Internet Engineering Task Force (IETF). IPsec is implemented by a set of cryptographic protocols for securing IP datagrams. The IPsec framework secures IP traffic operating at the Network Layer of the OSI Model, thus securing all network applications and communications that use the IP network.

While IPsec is defined in a number of RFCs, it is not a mandatory requirement for IPv4. However, IPsec is a mandatory requirement for IPv6. IPv6 is beyond the scope of the requirements of the IINS course and will not be described in this guide. Using a combination of hashing, symmetric key, and asymmetric key cryptographic algorithms, the IPsec framework offers the following security services:

• Peer Authentication
• Data Confidentiality
• Data Integrity
• Data Origin Authentication
• Replay Detection
• Access Control
• Traffic Flow Confidentiality

IPsec Modes

IPsec can use two different modes to propagate data across networks. These modes, which are commonly referred to as Security Association, or SA, are used to provide security to a given IP connection. The two modes used by IPsec are transport mode and tunnel mode.

Transport mode protects the payload (data) of the original IP datagram. This mode is typically used for host-to-host and end-to-end sessions, for example, protecting data between Host 1 in Site 1 and Host 2 in Site 2, as illustrated in the following diagram:

Figure 9.12. Transport Mode for Host-to-Host Comms

In transport mode, the original IP header is retained, while the IPsec header is inserted between the original IP header and the payload. The diagram that is shown below illustrates the insertion of the IPsec header between the original IP header and the data, or payload, when using transport mode:

Figure 9.13. IPSec Header Inside IP Packet

Transport mode can be used only when two different IPsec endpoints are the source and destination (respectively) of the original IP datagram, or packet. Transport mode is commonly used by end systems (i.e. hosts) to protect individual sockets or by intermediate systems (i.e. routers) to protect traffic that is already tunneled.

Tunnel mode is used to protect data in network-to-network (i.e. between networks or subnets) or site-to-site scenarios; for example, tunnel mode would be used to protect data between the 10.1.1.0/24 subnet in Site 1 and the 192.168.1.0/24 subnet in Site 2. When operating in tunnel mode, IPsec encrypts traffic through IPsec peers, as illustrated in the following diagram:

Figure 9.14. Tunnel Mode for Network-to-Network Comms

Tunnel mode allows IPsec to encapsulate the entire IP packet (i.e. the IP header as well as the payload or data) in a new IP packet, as illustrated in the following diagram:

Figure 9.15. New IP Packet Generated

It is important to understand that IPsec is unidirectional. In other words, SA is required for both inbound and outbound connections. Internet Key Exchange (IKE), which will be described in detail later in this chapter, allows for bidirectional SAs. In both transport and tunnel mode, IPsec adds a new header to all IP packets to provide information for securing the data within the original IP datagram. This header may be either an Encapsulating Security Payload or an Authentication Header. These two types of headers are described in the next two sections.

Encapsulating Security Payload

Encapsulating Security Payload (ESP) is an IP-based protocol that uses IP port 50 for communication between IPsec peers. ESP is documented in RFC 4303 and is used to provide the confidentiality, integrity, and authenticity of the data. Additionally, ESP also provides anti-replay protection services. The IPsec anti-replay service is described later in this chapter.

ESP does not provide any kind of protection for the outer IP header. In other words, ESP does not encrypt the original IP header. When used for data integrity, ESP does not include the invariant field in the IP header, which means that ESP is unable to detect any alternations during packet delivery. The following diagram illustrates the structure of the ESP header:

Table 9.4. ESP Header

0                                  7                                  15                                23                                31

Security Parameters Index
Sequence Number
Payload Data
Padding	Pad Length	Next Header
Authentication Data

The information contained in each field is as follows:

• Security Parameters Index

The Security Parameters Index (SPI) is an arbitrary 32-bit value that, in conjunction with the destination IP address and the security protocol (ESP), uniquely identifies the Security Association for this datagram.  A reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI is typically selected by the destination system upon establishment of an SA. This field is mandatory. The value of zero is reserved for local, implementation-specific use and must never be sent across the wire.

• Sequence Number

The Sequence Number field is an unsigned 32-bit field that contains a consistently increasing counter. As is the case with the SPI, the sequence number is mandatory and must always be sent by the sender, even if the receiver does not elect to enable the anti-replay service for a specific SA. The sender’s counter and the receiver’s counter are initialized to 0 when an SA is established. The first packet sent using a given SA will have a sequence number of 1. If anti-replay is enabled, which is the default, the transmitted sequence number must never be allowed to cycle. Thus, the sender’s counter and the receiver’s counter must be reset by establishing a new SA and thus a new key prior to the transmission of the second packet on an SA.

• Payload Data

This 32-bit field contains the data described by the Next Header field. This field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g. an Initialization Vector, then this data may be carried explicitly in the Payload Data field. Any encryption algorithm that requires such explicit, per-packet synchronization data must indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC.

• Padding

The Padding field is a variable-length field. Padding is used when the frame needs to meet minimum frame size formats. Padding is used, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right-aligned within a 4-byte word to ensure that the Authentication Data field, if present, is aligned on a 4-byte boundary.

• Pad Length

This 8-bit field is used to define the length of padding used. In other words, this field specifies the size of the Padding field, in bytes.

• Next Header

The Next Header field is an 8-bit field that identifies the type of data contained in the Payload Data field. It is simply an IPv4 protocol number describing the format of the Payload Data field.

• Authentication Data

The Authentication Data field is a variable-length field that contains the Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The ICV is a checksum capable of detecting modification of an information system and is the result of the integrity process. In other words, the ICV is used to ensure data integrity. The length of the Authentication Data field is specified by the authentication function selected. This field is optional and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification must specify the length of the ICV, as well as the comparison rules and the processing steps for validation.

The following diagram illustrates the ESP header when using IPsec in transport mode:

Figure 9.16. ESP Header Using Transport Mode

As illustrated in the diagram above, both ESP and the payload are authenticated; however, only the payload is actually encrypted. The following diagram illustrates the ESP header when using IPsec in tunnel mode:

Figure 9.17. ESP Header Using Tunnel Mode

In tunnel mode, the ESP header, original IP header, and payload are authenticated; however, only the original IP header and payload are actually encrypted, as illustrated above.

Authentication Header

Authentication Header (AH) is an IP-based protocol that uses IP port 51 for communication between IPsec peers. AH is used to protect the integrity and authenticity of data, and also offers anti-replay protection; however, AH does not provide confidentiality protection. Unlike ESP, AH provides protection to the IP header; however, not all fields in the IP header are encrypted. For example, the TTL field is not encrypted. AH is described in RFC 2402.

When using AH, authentication is performed by applying a one-way hash to create a message digest of the packet. Replay detection can be implemented using the sequence number in the IP packet header. The following diagram illustrates the AH header structure:

Table 9.5. Authentication Header Structure

0                                  7                                  15                                23                                31

Next Header	Length	0
Security Parameters Index
Sequence Number
Authentication Data

The Next Header, SPI, Sequence Number, and Authentication Data fields contained in the AH header are the same as those contained in the ESP header. To avoid being redundant, they will not be described again. The Length field is an 8-bit field specifying the length of the AH header in 32-bit words, minus 2.

AH can operate in transport or tunnel mode. Unlike ESP, AH also protects the fields in the outer IP header (i.e. the original IP header in transport mode) or the newly added IP header in tunnel mode, which are normally considered invariable. AH ensures that if the original IP header has been altered, the packet is rejected.

IPsec Anti-Replay Service

Both ESP and AH provide an anti-replay mechanism, which is used to defeat replay attacks and is mainly based on sequence numbers combined with authentication. The sender increments the sequence number after each transmission, and the receiver can check the sequence number and reject the packet if it is out of sequence. However, as stated previously, checking and using the sequence numbers is optional for the receiver. Without the anti-replay mechanism, an attacker could replay intercepted encrypted packets. 

Before delving into the configuration of IPsec on Cisco IOS routers, it is important to understand how keys are exchanged between secure devices to ensure that data is not compromised. IPsec ensures that once an IPsec tunnel is created, the keys are not modified, which prevents attackers from replicating the keys and creating IPsec tunnels to insecure locations. Internet Security Association and Key Management Protocol (ISAKMP) and IKE provide the framework that allows for secure key determination and distribution mechanisms in IPsec.

Internet Security Association and Key Management Protocol

ISAKMP describes the framework for key management and defines the procedure and packet format necessary to establish, negotiate, modify, and delete Security Association. ISAKMP offers the identification of the peers only; it does not offer a key exchange mechanism. ISAKAMP is documented in RFC 2408 but was made obsolete by RFC 4306, which standardized Internet Key Exchange version 2.

Internet Key Exchange

IKE is a hybrid protocol. It is basically a combination of ISAKMP, Oakley key exchange, and the SKEME protocol. Oakley describes a series of key exchanges, called modes, and details the services provided by each. These services include perfect forward secrecy for keys, identity protection, and authentication. SKEME describes a versatile key exchange technique that   provides anonymity, non-repudiation, and quick key refreshment. Both Oakley and SKEME are beyond the scope of requirements for the IINS course.

IKE defines the mechanism for exchanging keys. IKE derives authenticated keying material and negotiates SAs that are used for the ESP and AH protocols. IKE uses UDP port 500 and is documented in RFC 2409, and updated in RFC 4306, which is IKEv2 (the current IKE standard).

NOTE: The terms ISAKMP and IKE are often used interchangeably in many texts. While we will only be using the term IKE in this chapter, you should be aware of this fact if you encounter a question on ISAKMP or IKE during the IINS certification exam.

IKE is a two-phase, multimode protocol that offers the following three methods of authenticating a remote peer:

• The pre-shared key method uses statically defined keys and is the most common method because of its ease of deployment; however, this method is not scalable or secure.

• The public key signature method, also referred to as the RSA-Signature method, is the most secure method and requires Public Key Infrastructure (PKI).

• The public key encryption, commonly referred to as the RSA-Nonce, is similar to the public key signature method but requires prior knowledge of the peer’s public key. However, it is important to know that this method has limited support.

IKE phase 1 verifies the identity of a remote peer and the two peers establish a secure authentication communications channel. This phase is primarily concerned with the protection suite for IKE messages. IKE phase 1 also protects the negotiation of phase 2 communication. Phase 1 operations are required infrequently and can use either main or aggressive mode.

Main mode is the default method used in most implementations. Main mode defines six message exchanges to establish SA. Messages 1 and 2 are used to negotiate IKE policy, messages 3 and 4 are used to perform an authenticated Diffie-Hellman exchange, and messages 5 and 6 are used to protect the identities of the IKE peers. This exchange is illustrated in the following diagram:

Figure 9.18. Main Mode in Operation

The diagram illustrated above shows the messages exchanged between Host 1, the initiator, and Host 2, the responder, during IKE phase 1.

Messages 1 and 2 are used to negotiate the IKE policy. Message 1, sent by the initiator, offers acceptable encryption, authentication algorithms, and proposals, such as 3DES, MD5, RSA, and the DH group number. The DH group number, also referred to as the prime modulus group, is used to specify the size, in bits, of the DH key. Currently, Cisco IOS supports three groups, which are listed and described in the following table:

Table 9.6. DH Groups

DH Group Number	Description
1	This specifies the 768-bit Diffie-Hellman group.
2	This specifies the 1024-bit Diffie-Hellman group.
3	This specifies the 1536-bit Diffie-Hellman group.

Message 2, sent by the responder, states whether the proposals are accepted, and if not, then what proposals Host 2 is prepared to accept.  All messages are carried in UDP packets with a destination port of 500. The UDP data comprises a header, the SA payload, and one or more proposals. Message 1 offers many proposals, while message 2 contains only a single proposal.

Messages 3 and 4 carry out the DH exchange. Message 3 contains the DH key and nonce, or bit string. The key value is usually 1024 bits in length. Message 4, from the responder, also contains the DH key and bit string. Message types 3 and 4 also contain the remote peer’s IP public key and hashing algorithm. A common session key is created on both ends and the remaining IKE messages exchanged from this point are encrypted. If perfect forward secrecy (PFS) is enabled, then another DH exchange will be completed. PFS is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised if one of the (long-term) private keys is compromised in the future.

Messages 5 and 6 are used to protect the identities of the IKE peers. Message 5 contains the initiator signature, cert (if used for authentication data, for example), and ID. Message 6, received from the responder, provides the same information. Messages 5 and 6 are the last stage before traffic is sent over the IPsec tunnel. In essence, message 5 allows the initiator to authenticate the responder and message 6 allows the responder to authenticate the initiator. These messages are not sent in clear text; rather, they are encrypted using the agreed upon encryption methods in messages 1 and 2.

Aggressive mode is faster than main mode because it uses three message exchanges to establish phase 1. However, this means that aggressive mode is not as secure as main mode. Aggressive mode uses a three-way packet exchange, while main mode uses a six-way packet exchange. The following diagram illustrates message exchange when using aggressive mode:

Figure 9.19. Aggressive Mode Exchange

In aggressive mode, the first message from the initiator is used to perform the key exchange, ID, and nonce, as well as for parameter proposals, e.g. hashing algorithms.

The responder uses message 2 for its key exchange and ID, as well as to specify whether the parameters presented are acceptable.

Finally, in message 3, the initiator provides its signature, hash, and ID. IKE phase 1 is considered complete after this exchange.

IKE phase 2 is used to protect the data and establish SA for IPsec. IKE phase 2 is used to negotiate the protection suite (i.e. ESP and AH), the algorithms that will be used within the protection suite (e.g. DES, 3DES, AES, or SHA-1), the networks or traffic that is being encrypted, which is sometimes referred to as proxy identities or phase 2 identities, and any optional keying material for negotiated protocols.

Unlike IKE phase 1, IKE phase 2 has one mode, which is quick mode. Quick mode uses message exchanges to establish the phase 2 IPsec SA. Phase 2 SA is negotiated for a given proxy or phase 2 identities and a given IPsec protocol (ESP). Multiple phase 2 SAs can be established under the same phase 1 SA.  Phase 2 contains three messages, as illustrated in the following diagram:

Figure 9.20. Phase 2 Messages

IKE phase 2 datagrams are also exchanged using UDP, with a destination port of 500. Phase 2 negotiations occur in Oakley quick mode, which can be without key exchange (no PFS enabled) or with key exchange (with PFS enabled); this requires the DH algorithm to be run twice to generate the shared secret key.

In IKE phase 2, message 1 allows the initiator to authenticate itself and select a random nonce, as well as propose an SA to the remote peer. Additionally, a public key can be provided. This public key can be different from that exchanged in IKE phase 1.

Message 2 is sent by the responder and it allows the responding peer to generate the hash. This message is used by the responding peer to authenticate itself, as well as to select a random number and accept the SA offered by the initiating peer. Message 3 acknowledges information sent from quick mode message 2 so that the phase 2 tunnel can be established.

At the end of phase 2 negotiations, two unidirectional IPsec SAs are established for user data. One SA is for sending data and the other SA is for receiving encrypted data. The concept of an SA is that two devices have agreed on certain policy parameters to be used during their communication session. In other words, an SA is an agreement between two entities on a method to communicate securely. Each IKE phase has its own SA. Phase 1 has ISAKMP/IKE SA and phase 2 has IPsec SA. This concept is illustrated in the following diagram:

Figure 9.21. IKE Phases

IPsec VPN Configuration in SDM

While IPsec VPN configuration can be performed using CLI or SDM, the requirement of the IINS course is that you have a solid understanding of IPsec VPN configuration using SDM. This section walks through the configuration tasks required in order to enable IPsec VPN using Cisco SDM. The example used in this section will be based on the following network diagram:

Figure 9.22. Ipsec VPN Example

NOTE: As illustrated in the diagram above, a network-to-network IPsec tunnel will be created to encrypt data between the 172.16.1.0/24 and 192.168.1.0/24 subnets. Because the configuration tasks on R1 and R2 will be similar, only the configuration of R1 will be illustrated. In addition, it is also assumed that R2 has already been configured for an IPsec tunnel to its peer (R1), and routing for R1, R2, and R3 has already been configured to allow for end-to-end IP connectivity.

The first configuration step required to enable the IPsec VPN is to select VPN under the Tasks menu on the main configuration page, as illustrated in the following screenshot:

Figure 9.23. Select ‘VPN’ Under ‘Tasks’

On the VPN page, ensure that Site-to-Site VPN is highlighted and click on the Launch the selected task button, as illustrated in the following screenshot:

Figure 9.24. Launch the Slected Task

NOTE: The Create a secure GRE tunnel (GRE over IPSec) option allows network security administrators to configure a Generic Routing Encapsulation tunnel between the two peer routers to enable IPsec over this tunnel. This configuration is beyond the scope of the IINS course requirements.

The next page is the Site-to-Site VPN Wizard page. From this page, network security administrators can configure IPsec using Quick setup (default option) or customize their configuration by using the Step by step wizard. Because we are only concerned with basic IPsec implementation, click on Next to accept the default option and continue, as illustrated in the following screenshot:

Figure 9.25. Site-to-Site VPN Wizard

This action brings up the Site-to-Site VPN Wizard. This page asks for several inputs. The VPN Connection Information option asks for the interface on which the IPsec configuration will be applied. In this example, this will be the Serial0/0 interface.

The Peer Identity section asks for the type of IPsec peer, as well as the IP address of that peer. Based on the network topology used in this example, a Peer with a static IPsec is being configured (R2) and the IP address is 10.1.1.2.

The Authentication section is used to specify whether pre-shared keys or digital certificates are to be used. Adhering to the requirements of the IINS course requirements, Pre-shared keys should be selected. Manually specify the pre-shared key, which should be the same as that configured on R2.

The Traffic to encrypt section asks for the Source and Destination subnets. In this example, the source will be the 172.16.1.0/24 subnet (the FastEthernet0/0 interface on R1) and the destination will be the 192.168.1.0/24 subnet (the FastEthernet0/0 interface on R2).

Once these parameters have been entered, click on Next to proceed. This configuration is illustrated in the following screenshot:

Figure 9.26. Select the Correct Inputs

This action brings up the Summary of the Configuration page. From this page, it is highly recommended that network security administrators check the Test VPN connectivity after configuring checkbox so that SDM can ensure that the IPsec VPN is up. This is illustrated in the following screenshot:

Figure 9.27. Test the VPN Connectivity

Once SDM has configured the router, it will perform VPN troubleshooting to ensure that the VPN is up, as illustrated in the following screenshot:

Figure 9.28. VPN Testing

Enter the destination IP address of a host on the remote subnet and click on Continue to proceed, as illustrated in the following screenshot:

Figure 9.29. Enter Remote Host IP and Subne

If there are any issues, SDM will advise the administrator of the problem. However, assuming there are no configuration issues, the VPN tunnel will come up and SDM will advise of this status, as illustrated in the following screenshot:

Figure 9.30. VPN Status Report

To monitor VPN statistics, select Monitor and click on VPN. This brings up the VPN Status page, as illustrated in the following screenshot:

Figure 9.31. Monitor VPN Page

For example to view real-time traffic statistics, a continuous ping from Host 1 to R3 is initiated via the ping 192.168.1.3  –t command, as illustrated in the following diagram:

Figure 9.32. Test With Continuous Ping

Based on the continuous ping, the VPN Status page shows the spike on the charts depicting Encapsulation Packets and Decapsulation Packets, as illustrated in the following screenshot:

Figure 9.33. VPN Status Page

While you are not required to perform CLI configuration for IPsec VPNs, the following output shows the configuration commands implemented by SDM based on the previous configuration example. The IPsec VPN configuration is illustrated in bold font:

R1#show running-config Building configuration…   Current configuration : 3219 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R1 ! boot-start-marker boot-end-marker ! no logging buffered no logging console ! no aaa new-model no network-clock-participate slot 1 no network-clock-participate wic 0 ip cef ! ! ! ! ip domain name howtonetwork.net ! multilink bundle-name authenticated ! ! crypto pki trustpoint TP-self-signed-533650306 enrollment selfsigned subject-name cn=IOS-Self-Signed-Certificate-533650306 revocation-check none rsakeypair TP-self-signed-533650306 ! ! crypto pki certificate chain TP-self-signed-533650306 certificate self-signed 01 30820249 308201B2 A0030201 02020101 300D0609 2A864886 F70D0101 04050030 30312E30 2C060355 04031325 494F532D 53656C66 2D536967 6E65642D 43657274 69666963 6174652D 35333336 35303330 36301E17 0D303230 33303130 31303335 315A170D 32303031 30313030 30303030 5A303031 2E302C06 03550403 1325494F 532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3533 33363530 33303630 819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100 A10043E2 FB10C1D1 BA18F3AD 554F081C ACA14F4C EA48E0C1 4739653D B7759EE7 8EB29881 7F391723 E2BB7EC6 54EB6F25 B4E94520 DF8DA15C 3B9E6F7C 3AA57549 80AB643F A9427071 965DD56A 2D3E60CE 775F2ED5 C9014FCD F313F3EB B5189F62 09F461BC 32E3E78F F93C8B07 0740DDA8 7B880D1B A3185787 CE621B35 3511A9D5 02030100 01A37330 71300F06 03551D13 0101FF04 05300301 01FF301E 0603551D 11041730 15821352 312E686F 77746F6E 6574776F 726B2E6E 6574301F 0603551D 23041830 168014CD 63D2C471 B7ABA4AC F9C2B602 0D4A8954 71C7F930 1D060355 1D0E0416 0414CD63 D2C471B7 ABA4ACF9 C2B6020D 4A895471 C7F9300D 06092A86 4886F70D 01010405 00038181 002A76D9 7EB68101 CC23FE4F DD2F0D1F C952DC42 A7AC65A8 74D21FB0 577DF998 79B86023 239F8E5E AFD09B29 E87B777D 079642DB 3B629E27 803E28F9 1987544F 40F2DC8F 700EBAA2 C8833DD1 7BE366F0 D8ADD696 BD57262E F0C4A5AC 516D6A46 AC593CC6 AA0E71C3 D45557B3 C88BFC09 046D3D8D EA605BF6 E0AF1DDD 27D64C91 A8 quit ! ! username secadmin privilege 15 secret 5 $1$LE94$AOOi72zla5fPxRcubcQU1. archive log config hidekeys ! ! crypto isakmp policy 1  encr 3des  authentication pre-share  group 2 crypto isakmp key security address 10.1.1.2 ! ! crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac ! crypto map SDM_CMAP_1 1 ipsec-isakmp  description Tunnel to10.1.1.2  set peer 10.1.1.2  set transform-set ESP-3DES-SHA  match address 100 ! ! ! ip ssh time-out 30 ip ssh authentication-retries 2 ! ! ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet0/0 ip address 172.16.1.1 255.255.255.0 duplex auto speed auto ! interface Serial0/0 ip address 10.1.1.1 255.255.255.252 crypto map SDM_CMAP_1 ! router eigrp 1 network 0.0.0.0 no auto-summary ! ip forward-protocol nd ! ! ip http server ip http authentication local ip http secure-server ! access-list 100 remark SDM_ACL Category=4 access-list 100 remark IPSec Rule access-list 100 permit ip 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.255 ! ! ! ! control-plane ! ! ! line con 0 line aux 0 line vty 0 4 privilege level 15 password cisco login ! ! end   R1#

Chapter Summary

The following section is a summary of the major points you should be aware of in this chapter:

Cryptography Overview

• Cryptography is the art of protecting information by encrypting it
• Users must possess a secret key can decrypt ciphertext into plaintext
• A cryptosystem is a framework that involves the application of cryptography
• Encryption is the process of obscuring information to make it unreadable
• Decryption is the reverse of encryption
• Plaintext is information a sender wishes to transmit to a receiver
• Ciphertext is the product of the encryption process
• A hash is a unique generated by applying a mathematical formula
• A VPN, is used to carry private traffic over a public transport, such as the Internet
• Cryptographic techniques can be classified as either traditional or modern
• Traditional techniques use transposition and substitution mechanisms
• Modern cryptographic techniques rely on sophisticated protocols and algorithms
• There are three types of cryptographic algorithms, which are:

• Symmetric Key Cryptography
• Asymmetric Key Cryptography
• Hash Algorithms

• Symmetric key cryptography uses a single key for encryption and decryption
• Asymmetric key cryptography uses two keys for encryption and decryption
• Hash algorithms use a one-way function to produce a randomized unique hash value

Symmetric Key Cryptography

• Symmetric key cryptography uses a single shared secret key for encryption and decryption
• The two categories of symmetric key cryptography are stream ciphers and block ciphers
• Block ciphers encrypt plaintext in chunks, or blocks
• Block ciphers have several modes of operation, which are:

1. ECB – Electronic Code Book
2. CBC – Cipher Block Chaining
3. CFB – Cipher Feedback Mode
4. OFB – Output Feedback Mode
5. CTR – Counter
6. CMAC – Cipher Block Chaining Message Authentication Code
7. CCM – Counter with CBC MAC
8. GCM – Galois/Counter Mode

• Stream or state ciphers encrypt plaintext digits (bits or bytes) one by one
• There are two categories of stream ciphers: synchronous and self-synchronizing
• Stream ciphers attempt to operate in the same manner as OTP
• Some of the most common symmetric cryptographic algorithms, which are:

• Digital Encryption Standard
• Triple-Digital Encryption Standard
• Advanced Encryption Standard
• RC4
• International Data Encryption Algorithm
• Blowfish

Asymmetric Key Cryptography

• Asymmetric key cryptography is commonly referred to as public key cryptography
• Asymmetric key cryptography design uses a two-key pair
• Public key cryptography is typically used in digital certification and key management
• The two types of public key cryptography are public key encryption and digital signatures
• Some of the most common asymmetric key cryptography algorithms are:

1. Rivest, Shamir, and Adleman
2. Diffie-Hellman
3. Digital Signature Algorithm and Digital Signature Standard
4. Public-Key Cryptography Standards

Hash Algorithms

• Hash algorithms use a mathematical formula to compute a fixed-length hash value
• With hashing, the original message cannot be reconstituted
• Hash functions are generally faster than encryption algorithms
• Hash algorithms are commonly used for both data integrity and digital certificates
• The most common hash algorithms are:

1. Message Digest
2. Secure Hash Algorithm

VPN Technologies

• VPN technology is described in RFC 2828
• The three types of VPN technologies that are available today are:

1. Secure Virtual Private Networks
2. Trusted Virtual Private Networks
3. Hybrid Virtual Private Networks

• Secure VPNs are also referred to as Cryptographic VPNs

Secure VPN technologies include:

IP Security (IPsec)2.

Layer 2 Tunneling Protocol (L2TP) over IPsec3

Point-to-Point Tunneling Protocol (PPTP)4.      SSL Encryption (SSL VPN)

The three most common secure VPN deployment scenarios are:

1. Intranet-based VPNs
2. Internet-based VPNs
3. Extranet-based VPNs

• Trusted VPNs are also referred to as non-cryptographic VPNs
• Trusted VPN technologies are usually provided by a dedicated service provider
• A hybrid VPN is a combination of both a trusted VPN and a secure VPN

IP Security

• IP Security is standardized in RFC 2401
• The IPsec framework is a set of open standards developed by the IETF
• IPsec is implemented by a set of cryptographic protocols
• The IPsec framework secures IP traffic operating at the Network Layer of the OSI Model
• The IPsec framework offers the following security services:

 

1. Peer Authentication
2. Data Confidentiality
3. Data Integrity
4. Data Origin Authentication
5. Replay Detection
6. Access Control
7. Traffic Flow Confidentiality

• IPsec can use transport mode and tunnel mode propagate data across networks.
• IPsec modes are commonly referred to as Security Association, or SA
• Transport mode protects the payload (data) of the original IP datagram
• Transport mode is used host-to-host and end-to-end sessions
• Tunnel mode allows IPsec to encapsulate the entire IP packet
• Tunnel mode is used to protect data in network-to-network or site-to-site scenarios
• IPsec is unidirectional and SA is required for both inbound and outbound connections
• IKE allows for bidirectional SAs within the IPsec framework
• The IPsec header may either be Encapsulating Security Payload or Authentication Header
• ESP is an IP-based protocol that uses IP port 50
• ESP is documented in RFC 4303
• ESP is used to provide confidentiality, integrity, and authenticity of the data
• ESP does not provide any kind of protection for the outer IP header
• AH is an IP-based protocol that uses IP port 51
• AH is used to protect the integrity and authenticity of data
• AH provides protection to the IP header
• AH is described in RFC 2402
• Both ESP and AH provide an anti-replay mechanism
• Anti-replay services are possible by using the sequence numbers in the ESP and AH headers
• ISAKMP is used to establish, negotiate, modify, and delete Security Association
• ISAKAMP is documented in RFC 2408, but was made obsolete by RFC 4306 (IKEv2)
• IKE is a combination of ISAKMP, Oakley key exchange, and the SKEME protocol
• IKE defines the mechanism for exchanging keys
• IKE uses UDP port 500 and is documented in RFC 2409, and updated in RFC 4306
• The terms ISAKMP and IKE are often used interchangeably in many texts
• IKE is a two-phase, multimode protocol
• IKE uses pre-shared keys, public key signature, and public key encryption
• IKE phase 1 operations can use either main or aggressive mode
• IKE phase 1 main mode uses a six message exchange process
• IKE phase 1 aggressive mode uses a three message exchange process
• IKE phase 2 operates in quick mode
• IKE phase 2 uses a three message exchange process
• A single SA is created in IKE phase 1
• Two SAs are created in IKE phase 2: one for sending and the other for receiving data

Advanced cryptography.