Fundamentals of Cryptography and VPN Technologies - Secure Connectivity - Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Part IV: Secure Connectivity

Chapter 12. Fundamentals of Cryptography and VPN Technologies

This chapter introduces the concepts of cryptography and VPN technologies. It covers the following topics:

• Need for VPN and VPN deployment models

• Encryption, hashing, and digital signatures and how they provide confidentiality, integrity, and nonrepudiation

• Methods, algorithms, and purposes of symmetric encryption

• Use and purpose of hashes and digital signatures in providing integrity and nonrepudiation

• Use and purpose of asymmetric encryption and Public Key Infrastructure (PKI)

An IP Security (IPsec) virtual private network (VPN) is an integral part of the security architecture of most organizations. It is used to connect branch offices, remote employees, and business partners to the resources of the organization. Providing confidentiality, integrity, and endpoint authentication, VPNs are ubiquitous and provide data loss prevention mechanisms for data in transit at multiple levels. From Secure Sockets Layer (SSL) VPNs to IPsec VPNs, site-to-site VPNs or remote access options, this security control is now embedded in networks and applications and should be made available in a transparent and manageable fashion. This chapter introduces the cryptographic elements used by VPNs, including symmetric and asymmetric algorithms, and describes the components, deployment options, and operational framework of VPN technologies.

VPN Overview

Historically, a VPN was an IP tunnel. Therefore, a generic routing encapsulation (GRE) tunnel is technically a VPN, even though GRE does not encrypt. Today, the use of a VPN implies the use of encryption. With a VPN, the information from a private network is transported over a public network, such as the Internet, to form a virtual network instead of using a dedicated Layer 2 connection, as shown in Figure 12-1. To remain private, the traffic is encrypted to keep the data confidential. VPNs are virtual because they are not deployed over a physical private network end to end. At some point, they will traverse a public network of some sort.

Figure 12-1. Where VPNs Are Found

VPNs are private because they use different methods of traffic segregation to keep the transferred traffic private. For instance, legacy Frame Relay networks could be considered VPNs in that they use a public network (the Frame Relay provider network), and they segregate traffic that shares the public network by encapsulating traffic within Frame Relay frames and tagging traffic that belongs to different customers with different virtual circuit identifiers. More recently, Multiprotocol Label Switching (MPLS) networks can also implement VPN-type connectivity because the customers share the provider’s network (hence considered public) and their traffic is segregated using MPLS labels. It is worth mentioning that MPLS VPN does not provide confidentiality because the payload is not encrypted.

The term private can optionally refer to confidentiality. Even if traffic is segregated along the path of the VPN, malicious and nonmalicious attackers could technically intercept it at some point on the path and see its contents. To mitigate this risk, and to ensure traffic remains private, traffic is often encrypted to keep the data confidential. Encryption also provides other benefits, such as data integrity and authentication of the entities involved in the VPN. Encryption mechanisms are key in IPsec and SSL VPNs, the main subjects in this chapter, and will be explained in more detail throughout the rest of this book.

VPNs have many benefits:

Cost savings: VPNs enable organizations to use cost-effective third-party Internet transport to connect remote offices and remote users to the main corporate site, thus eliminating expensive dedicated WAN links and modem banks. Furthermore, with the advent of cost-effective high-bandwidth technologies, such as digital subscriber line (DSL), organizations can use VPNs to reduce their connectivity costs while simultaneously increasing remote connection bandwidth.

Scalability: VPNs enable corporations to use the Internet infrastructure within ISPs and devices, which makes it easy to add new users. Therefore, corporations are able to add large amounts of capacity without adding significant infrastructure.

Compatibility with broadband technology: VPNs allow mobile workers, telecommuters, and people who want to extend their workday to take advantage of high-speed, broadband connectivity, such as DSL and cable, to gain access to their corporate networks, providing workers significant flexibility and efficiency. Furthermore, high-speed broadband connections provide a cost-effective solution for connecting remote offices.

Security: Optionally, VPNs provide the highest level of security by using advanced encryption and authentication protocols that protect data from unauthorized access.

VPN Types

There are different types of commercially deployed VPNs. VPN are classified according to the following criteria:

Based on deployment mode: Site-to-site VPN and remote-access VPN

Based on Open Systems Interconnection (OSI) layer: Layer 2 VPN (legacy protocols such as Frame Relay or ATM, and Layer 2 MPLS VPN), Layer 3 VPN (IPsec and MPLS Layer 3 VPN), and Layer 7 VPN (SSL VPN)

Based on underlying technology: IPsec VPN, SSL VPN, MPLS VPN, other Layer 2 technologies such as Frame Relay or ATM, and hybrid VPNs combining multiple technologies

The two basic VPN deployment models typically use either IPsec or SSL technologies to keep the communications secured. The Cisco VPN solutions, illustrated in Figure 12-2, and their associated technologies will be discussed throughout the rest of this book. Other VPN technologies, such as MPLS, are beyond the scope of this book.

Figure 12-2. Cisco VPN Solutions

Site-to-Site VPNs

A site-to-site VPN, shown in Figure 12-3, is an extension of a classic WAN network. Site-to-site VPNs connect entire networks to each other; for example, they can connect a branch office network to a company headquarters network. In the past, a leased line or Frame Relay connection was required to connect sites, but because most corporations now have Internet access, these connections can be replaced with site-to-site VPNs.

Figure 12-3. Site-to-Site VPNs

In a site-to-site VPN, hosts do not have Cisco VPN Client software; they send and receive normal TCP/IP traffic through a VPN “gateway,” which could be a router, firewall, Cisco VPN Concentrator, or Cisco ASA 5500 Series Adaptive Security Appliance. The VPN gateway is responsible for encapsulating and encrypting outbound traffic for all the traffic from a particular site and sending it through a VPN tunnel over the Internet to a peer VPN gateway at the target site. Upon receipt, the peer VPN gateway strips the headers, decrypts the content, and relays the packet toward the target host inside its private network.

Remote-Access VPNs

In the past, corporations supported remote users by using dial-in networks and ISDN. With the advent of VPNs, a mobile user simply needs access to the Internet to communicate with the central office. In the case of telecommuters, their Internet connectivity is typically a broadband connection such as DSL or cable. Remote-access VPNs, shown in Figure 12-4, can support the needs of telecommuters, mobile users, and extranet consumer-to-business traffic. Remote-access VPNs connect individual hosts who must access their company network securely over the Internet.

Figure 12-4. Remote-Access VPN

Hosts in a remote-access VPN commonly have a VPN client installed. As shown in Figure 12-2, this is called “Full Client.” Cisco produces two clients: Cisco AnyConnect and Cisco VPN Client. These clients use a virtual network adapter (virtual network interface card) in the host computer to send traffic back to the head office. The VPN client software encapsulates and encrypts the traffic received on the virtual NIC before sending it over the Internet to the VPN gateway at the edge of the target network. Upon receipt, the VPN gateway behaves as it does for site-to-site VPNs.

Examining Cryptographic Services

Cryptographic services are the foundation for many security implementations. The key services provided by cryptography are as follows:

Confidentiality: The assurance that no one can read a particular piece of data except the receivers explicitly intended.

Integrity or data authentication: The assurance that data has not been altered in transit, intentionally or unintentionally.

Peer authentication: The assurance that the other entity is who he, she, or it claims to be.

Nonrepudiation: A proof of the integrity and origin of data. The sender can’t repudiate that he or she is the person who sent the data.

Key management: The generation, exchange, storage, safeguarding, use, vetting, and replacement of keys.

VPN services use a combination of cryptographic technologies and algorithms to accomplish their goals. In the router-to-router VPN, also known as site-to-site VPN, IP packets use symmetric encryption algorithms to encrypt the payload, with keys negotiated by key management protocols. They also use asymmetric encryption algorithms to create digital signatures and authenticate the VPN peers, and use hashing functions to provide checksum-type integrity checks.

This combination of algorithms and cryptographic methods, when used as a unit to negotiate the security settings to accomplish confidentiality, integrity, and authentication, is known as a cipher suite.


Data Authentication Versus User Authentication

Data authentication, also known as message authentication, is not the same as user authentication. With user authentication, as an example, an administrator is requested to provide his username and password to gain administrative access to a network device. Simply put, data authentication is a means for senders and receivers to validate the origin of each segment of a message that is exchanged. Data authentication also ensures data integrity, a way to prove that the payload wasn’t tampered with during transmission. Data authentication is covered in greater detail in this chapter when we discuss cryptographic hashes.


Cryptology Overview

Cryptology is the science of making and breaking secret codes. Cryptology is broken into two separate disciplines: Cryptography is the development and use of codes, and cryptanalysis is the breaking of those codes. A symbiotic relationship exists between the two disciplines because each makes the other one better. National security organizations employ members of both disciplines and put them to work against each other.

In the past, there have been times when each discipline has been ahead of the other. For example, during the Hundred Years’ War between France and England, the cryptanalysts were ahead of the cryptographers. France believed that its cipher was unbreakable; however, the Englishmen were able to break it. Some historians believe that World War II largely turned on the fact that the winning side on both fronts was much more successful than the losing side at cracking the encryption of its adversary.

It is an ironic fact of cryptography that it is impossible to prove that an algorithm is secure. You can prove only that it is not vulnerable to known cryptanalytic attacks. If there are methods that have been developed but are unknown to the cryptographer, an algorithm might be able to be cracked. You can prove only invulnerability to known attacks, except for a brute-force attack.

All algorithms are vulnerable to brute force. If every possible key is tried, one of the keys has to work. Therefore, no algorithm is unbreakable. The best you can hope for are algorithms that are vulnerable only to brute-force attacks.


Note

Two separate techniques can be used to try to achieve secure communication.

The first one is discussed in this chapter: cryptography, which is the science of encrypting a message.

The second technique is called steganography, which pertains to the method used to hide a message. The message is hidden either within another message or by other means. For example, the German Embassy in Washington, D.C., used steganography by hiding a message within a message. The first letter of each word of a telegram would make up a secret message. This method is referred to as using a null cipher. Another example of steganography was by Histiaeus, a Greek tyrant, who had the head of his most trusted slave shaved, tattooed a message on the scalp, waited for the hair to grow back, and then dispatched the slave to deliver the secret message. Obviously, the element of urgency wasn’t there! Another example of steganography is encoding a message in a JPG or BMP image. The “noise” that is induced in the picture by encoding the message is not noticeable to the naked eye.

By comparison, when using cryptography, others are aware that a secret message is being transmitted, but hopefully they can’t decipher the message. With steganography, third parties don’t know that a message is being transmitted.

If the topic of cryptography and steganography interests you, you must read this fascinating book: The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography, by Simon Singh (First Anchor Books Edition, 2000).


The History of Cryptography

The history of cryptography starts in diplomatic circles thousands of years ago. Messengers from a king’s court would take encrypted messages to other courts. Occasionally, other courts not involved in the communication would attempt to steal any message sent to a kingdom they considered an adversary. Encryption was first used to prevent this information theft.

Not long after, military commanders started using encryption to secure messages. The messengers had far greater challenges than those of the diplomatic messengers because killing the messenger to get the message was common. With the stakes so high, military commanders resorted to encryption to secure their military communications.

The cipher attributed to Julius Caesar was a simple substitution cipher that he used on the battlefield to quickly encrypt a message that could easily be decrypted by his commanders. Thomas Jefferson, the third president of the United States, was also an inventor, and one of his inventions was an encryption system that he was believed to have used when serving as Secretary of State from 1790 to 1793.

Arthur Scherbius invented a machine in 1918 that served as a template for the machines that all the major participants in World War II used. He called the machine Enigma and sold it to Germany, estimating that if 1000 cryptanalysts tested four keys per minute, all day, every day, it would take 1.8 billion years to try them all.

During World War II, both the Germans and Allies had machines modeled after the Scherbius machine. These were the most sophisticated encryption devices ever developed, and in response, the British invented arguably the world’s first computer, the Colossus, to break the encryption that was used by the Germans’ Enigma machine.

Ciphers

A cipher is an algorithm for performing encryption and decryption. It is a series of well-defined steps that you can follow as a procedure. Substitution ciphers simply substitute one letter for another. In their simplest form, substitution ciphers retain the letter frequency of the original message. Table 12-1 provides a summary of popular cipher categories.

Table 12-1. Cipher Categories

Substitution Cipher

The cipher attributed to Julius Caesar is a simple substitution cipher. Every day has a different key, and that key is used to adjust the alphabet accordingly. For example, if today’s key is five, an A is moved five spaces, resulting in an encoded message using F instead; a B is a G, a C is an H, and so forth. The next day the key might be eight, and the process begins again, so A is now I, B is J, and so on.

For example, if a message has 25 occurrences of the letter S, and S is replaced by the letter Q, there will 25 occurrences of the letter Q. If the message is long enough, it will be vulnerable to frequency analysis because it retains the frequency patterns found in the language. Because of this weakness, polyalphabetic ciphers were invented.

Polyalphabetic Cipher

The Vigenère cipher, shown in Figure 12-5, is a polyalphabetic cipher that encrypts text by using a series of different Caesar ciphers based on the letters of a keyword. It is a simple form of polyalphabetic substitution and therefore invulnerable to frequency analysis.

Figure 12-5. The Vigenère Cipher

The method was originally described in 1553 in a book by Giovan Batista Belaso. Mistakenly, Blaise de Vigenère, a French cryptographer, has been attributed with its invention, hence its name.

To illustrate how it works, suppose that a key of SECRETKEY is used to encode ATTACK AT DAWN. The A (the first letter of ATTACK) is encoded by looking at the row starting with S (the first letter of the key SECRETKEY) for the letter in the A column. In this case, the A is replaced with S. Then you look for the row that begins with E for the letter T. This results in X as your second character. If you continue this encoding method, the message ATTACK AT DAWN is encrypted as SXVRGDKXBSAP.


Note

When using the Vigenère cipher and the message is longer than the key, just repeat the key.


Transposition Ciphers

In transposition ciphers, letters are simply rearranged rather than replaced. An example of this type of cipher is taking the message THE PACKAGE IS DELIVERED and transposing it to read DEREVILEDSIEGAKCAPEHT. In this example, the key is to reverse the letters.

Another example of a transposition cipher is the rail fence cipher, shown in Figure 12-6. In this transposition, the words are spelled out as if they were a rail fence. The example in Figure 12-6 uses a key of three to illustrate how this could be done.

Figure 12-6. Transposition Cipher: Rail Fence Cipher

The message THE COVER IS BLOWN FLEE AT ONCE would be encoded as TOIOLTEHCVRSLWFEAOCEEBNEN using this method of transposition. Once again, no letters were changed; they were just rearranged.

One-Time Pad Cipher

The one-time pad was invented and patented by Gilbert Vernam in 1917 while working at AT&T. The primary design of the one-time pad was meant to overcome the weaknesses of using the Vigenère cipher. Vernam’s idea was a stream cipher that would apply the exclusive OR (XOR) operation to plaintext with a key, but still using the Vigenère cipher. Joseph Maubourgne, a captain in the U.S. Army Signal Corps, contributed the idea of using random data as a key. This combined idea is so significant that the U.S. National Security Agency (NSA) has called this patent “perhaps the most important in the history of cryptography.”

Figure 12-7 shows three one-time pads used in conjunction with the Vigenère cipher.

Figure 12-7. One-Time Pads

There are several difficulties inherent in using one-time pads in the real world. The first of these is the challenge of creating random data. Computers, because they have a mathematical foundation, are incapable of creating random data. In addition, if the key is used more than once, it is trivial to break. Key distribution is also challenging (for example, how do you distribute the pads?).


Note

Rivest Cipher 4 (RC4) is an example of a Vernam cipher that is widely used on the Internet. It is not a one-time-pad because the key used is not random. If you have used Wired Equivalent Privacy (WEP) with a wireless network, you have used RC4.


In Figure 12-8, the plaintext “at dawn attack the high plains” is encrypted with Sheet 2 of the one-time pads, using the Vigenère cipher.

Figure 12-8. Encryption Using One-Time Pad

In Figure 12-9, the ciphertext is decrypted using Sheet 2 of the one-time pads.

Figure 12-9. Decryption Using One-Time Pad

Classical ciphers are either transposition ciphers or substitution ciphers.

Recall that a transposition cipher exchanges the position of letters, whereas a substitution cipher replaces one letter with another letter based on a secret key.

Figure 12-10 illustrates an example of a simple computer version of a substitution cipher, where the word WOLFE is translated in ASCII. The key MAJOR is also translated in ASCII. The key is applied to the cleartext using in this example the logical operation XOR. The result is ciphertext. The result of applying the key, using again the XOR operation, is the deciphering of the ciphertext to its original cleartext.

Figure 12-10. Computer Version of a Substitution Cipher

XOR is a type of logical disjunction on two operands that results in a value of true if only one of the operands has a value of true. In other words, for the result to be true (result of 1), the two operands must be different (one operand must be 0 and the other operand must be 1). In mathematics, operands are the input values used on the operation. With the formula 4 * 5, 4 and 5 are operands, and * (multiplication) is the operation.

Figure 12-10 is an example of both a substitution cipher and symmetric encryption. Symmetric encryption is discussed later in this chapter.

Block and Stream Ciphers

Algorithms can operate in two modes:

Block mode: The algorithm can work on only fixed chunks of data.

Stream mode: The algorithm can process data bit by bit.

Block Ciphers

Block ciphers transform a fixed-length block of plaintext into a block of ciphertext. Applying the reverse transformation to the ciphertext block and using the same secret key results in decryption. Currently, the fixed length (also known as the block size) for many block ciphers is typically 128 bits. DES has a block size of 64 bits.


Note

Block size refers to how much data is encrypted at any one time, whereas key length refers to the size of the encryption key. For example, DES encrypts blocks in 64-bit chunks, including an 8-bit parity check, thus yielding a 56-bit effective key strength.


Block ciphers usually result in output data that is larger than the input data because the ciphertext must be a multiple of the block size. To accomplish this, block algorithms take data one chunk at a time (for example, 8 bytes) and use padding to add artificial data (blanks) if there is less input data than one full block.

The following are common block ciphers:

• DES and 3DES, running in either Electronic Code Book (ECB) mode or Cipher Block Chaining (CBC) mode

• Advanced Encryption Standard (AES)

• International Data Encryption Algorithm (IDEA)

• Secure and Fast Encryption Routine (SAFER)

• Skipjack

• Blowfish

• Rivest-Shamir-Alderman (RSA)

Figure 12-11 illustrates the differences between ECB mode and CBC mode.

Figure 12-11. DES ECB Mode Versus DES CBC Mode

ECB mode serially encrypts each 64-bit plaintext block using the same 56-bit key. If two identical plaintext blocks are encrypted using the same key, their ciphertext blocks are the same. Therefore, an attacker could identify similar or identical traffic flowing through a communications channel and use that information to build a catalog of messages, which have a certain meaning, and replay them later without knowing their real meaning. For example, an attacker might capture a login sequence of someone with administrative privilege whose traffic is protected by ECB mode and then replay that sequence. That risk is undesirable, so CBC mode was invented to mitigate this risk.

In CBC mode, each 64-bit plaintext block is exclusive ORed (XORed) bitwise with the previous ciphertext block and then is encrypted using the DES key. Because of this process, the encryption of each block depends on previous blocks.

Encryption of the same 64-bit plaintext block can result in different ciphertext blocks. CBC mode can help guard against certain attacks, but it cannot help against sophisticated cryptanalysis or an extended brute-force attack.

Stream Ciphers

Unlike block ciphers, stream ciphers operate on smaller units of plaintext, typically bits. With a stream cipher, the transformation of these smaller plaintext units varies, depending on when they are encountered during the encryption process. Stream ciphers can be much faster than block ciphers, and generally do not increase the message size, because they can encrypt an arbitrary number of bits.

In stream cipher mode, the cipher uses previous ciphertext and the secret key to generate a pseudorandom stream of bits, which only the secret key can generate. To encrypt data, the data is XORed with the pseudorandom stream bit by bit, or sometimes byte by byte, to obtain the ciphertext. The decryption procedure is the same: The receiver generates the same random stream using the secret key, and XORs the ciphertext with the pseudorandom stream to obtain the plaintext.

Common stream ciphers include the following:

• DES and 3DES, running in output feedback (OFB) or cipher feedback (CFB) mode

• Rivest Cipher 4 (RC4)

• Software-optimized Encryption Algorithm (SEAL)

The Process of Encryption

Encryption is the process of disguising a message in such a way as to hide its original contents, as shown in Figure 12-12. With encryption, the plaintext readable message is converted to ciphertext, which is the unreadable, “disguised” message. Decryption reverses the process. The purpose of encryption is to guarantee confidentiality so that only authorized entities can read the original message.

Figure 12-12. Transforming Plaintext into Ciphertext

Old encryption algorithms, such as the Caesar cipher or the Enigma machine, were based on the secrecy of the algorithm to achieve confidentiality. With modern technology, where reverse engineering is often simple, public-domain algorithms are often used. With most modern algorithms, successful decryption requires knowledge of the appropriate cryptographic keys; that is, the security of encryption lies in the secrecy of the keys, not the algorithm.

Encryption can provide confidentiality at an OSI layer, such as the following:

• Encrypt application layer data, such as secure email, secure database sessions (Oracle SQL*Net), and secure messaging (Lotus Notes sessions)

• Encrypt session layer data, using a protocol such as SSL or Transport Layer Security (TLS)

• Encrypt network layer data, using protocols such as those provided in the IPsec protocol suite

• Encrypt link layer data, using proprietary link-encrypting devices

Nowadays, encryption algorithms such as Triple Data Encryption Standard (3DES) and Advanced Encryption Standard (AES) are readily distributed. So, because we all share the same algorithms, they have no need for protection (except for the fact that Western countries define cryptography as munitions, and therefore encryption algorithms are subject to the same export regulations as weapons).

Because we all share algorithms, what we protect are the cryptographic keys used with the algorithms. Cryptographic keys are sequences of bits that are input into an encryption algorithm together with the data to be encrypted.

Encryption Application Examples

The IPsec protocols can provide the encryption functionality for all the packets routed over an untrusted network. The encrypting IPsec peer takes a packet with the plaintext payload, encrypts the payload into ciphertext, and forwards the packet to the untrusted network (for example, the Internet). Its IPsec partner receives the ciphertext payload packet and decrypts the payload into the original plaintext. The two IPsec peers share the same encryption and decryption algorithm and proper keys.

The SSL protocol provides an encrypted channel on top of an existing TCP session. For example, HTTPS, which is HTTP encapsulated inside SSL, also known as HTTP over SSL or HTTP Secure, provides, among other services, confidentiality of the session between a web browser and a web server, using symmetric cryptography.

Both IPsec and SSL are used to set up a VPN. An IPsec VPN is application independent and requires a specialized IP stack on the end system or in the packet path that includes IPsec. Originally, SSL-based VPN supported only web-based applications with the SSL software included with all Internet browsers. Nowadays, SSL-based VPN also provides full tunnel support. Both SSL and IPsec are explained in more detail later in this book.

In contrast to IPsec and SSL, Layer 2 encryption, also known as data link layer encryption and depicted in Figure 12-13, encrypts the whole frame, including the physical address fields located in the header of the frame, and therefore can be used only on point-to-point links where no network switching or routing equipment is required for path decision.

Figure 12-13. Cisco ASA Configured as a Layer 2 Firewall


Note

IPsec implementation is a mandatory part of IPv6.


Cryptanalysis

Cryptanalysis is the practice of breaking codes to obtain the meaning of encrypted data. An attacker who tries to break an algorithm or encrypted ciphertext might use one of the following attacks:

• Brute-force attack

• Ciphertext-only attack

• Known-plaintext (the usual brute-force) attack

• Chosen-plaintext attack

• Chosen-ciphertext attack

• Birthday attack

• Meet-in-the-middle attack

The sections that follow describe these attacks in greater detail.

Brute-Force Attack

In a brute-force attack, an attacker tries every possible key with the decryption algorithm, knowing that eventually one of them will work. All encryption algorithms are vulnerable to this attack. On average, a brute-force attack will succeed about 50 percent of the way through the keyspace (see “Keyspaces,” later in this chapter, for more information). The objective of modern cryptographers is to have a sufficiently large keyspace so that it takes too much money and too much time to accomplish a brute-force attack.


Note

As reported by Distributed.net in 1999, a DES cracking machine was used to recover a 56-bit DES key in 22 hours using brute force. It is estimated that it would take 149 trillion years to crack AES using the same method.


Ciphertext-Only Attack

In a ciphertext-only attack, the attacker has the ciphertext of several messages, all of which have been encrypted using the same encryption algorithm, but the attacker has no knowledge of the underlying plaintext. The job of the attacker is to recover the ciphertext of as many messages as possible or, better yet, to deduce the key or keys used to encrypt the messages so as to decrypt other messages encrypted with the same keys. The attacker could use statistical analysis to achieve the result. Those attacks are no longer practical today because modern algorithms produce pseudorandom output that is resistant to statistical analysis.

Known-Plaintext Attack

In a known-plaintext attack, the attacker has access to the ciphertext of several messages, but also knows something about the plaintext underlying that ciphertext. With knowledge of the underlying protocol (HTTP, FTP, SMTP), file type (web page, file transferred, email message), and some characteristic strings that might appear in the plaintext, the attacker uses a brute-force attack to try keys until decryption with the correct key produces a meaningful result. This attack may be the most practical attack, because attackers can usually assume the type and some features of the underlying plaintext, if they can only capture ciphertext. However, modern algorithms with enormous keyspaces make it unlikely for this attack to succeed, because on average an attacker would have to search through at least half of the keyspace to be successful.


Note

A known-plaintext attack was used in the cracking of the Enigma machine. During World War II, Alan Turing, a famous British crypto-mathematician, discovered that at around 6 a.m. each day the Germans were sending an encrypted weather report. Turing was sure that within the ciphertext captured around that time of day the word WETTER (weather in German) could be found. With the ciphertext equivalent to the plaintext WEATHER, Turing had a good start to continue reverse engineering the rest of the message.

In cryptanalysis, a sample of ciphertext suspected to be a resulting plaintext is called a crib.


Chosen-Plaintext Attack

In a chosen-plaintext attack, the attacker chooses what data the encryption device encrypts and observes the ciphertext output. A chosen-plaintext attack is more powerful than a known-plaintext attack because the attacker gets to choose the plaintext blocks to encrypt, allowing the attacker to choose plaintext that might yield more information about the key. This attack might not be very practical, because it is often difficult or impossible to capture both the ciphertext and plaintext, unless the trusted network has been broken into and the attacker already has access to confidential information.

Chosen-Ciphertext Attack

In a chosen-ciphertext attack, the attacker can choose different ciphertexts to be decrypted and has access to the decrypted plaintext. With the pair, the attacker can search through the keyspace and determine which key decrypts the chosen ciphertext in the captured plaintext. For example, the attacker has access to a tamperproof encryption device with an embedded key. His job is to deduce the embedded key by sending data through the box. This attack is analogous to the chosen-plaintext attack. This attack might not be very practical, because it is often difficult or impossible to capture both the ciphertext and plaintext, unless the trusted network has been broken into and the attacker already has access to confidential information.

Birthday Attack

The birthday attack gets its name from the amazing statistical probability involved in two individuals having the same birthday. According to statisticians, the probability that 2 people in a group of 23 people share the same birthday is greater than 50 percent.

This particular attack is a form of brute-force attack against hash functions. If some function, when supplied with a random input, returns one of k equally likely values, then by repeating the function with different inputs, the same output is expected after 1.2k1/2 number of times.


Tip

To test the birthday theory, input 365 in the place of k.


Meet-in-the-Middle

The meet-in-the-middle attack is a known-plaintext attack. Do not confuse this with the man-in-the-middle attack, which is discussed later. In a meet-in-the-middle attack, the attacker knows a portion of the plaintext and the corresponding ciphertext. The plaintext is encrypted with every possible key, and the results are stored. The ciphertext is then decrypted using every key until one of the results matches one of the stored values.

Desirable Encryption Algorithm Features

The following are features that a good encryption algorithm provides:

• Resists cryptographic attacks

• Supports variable and long key lengths and scalability

• Creates an avalanche effect


Note

When deciding on a algorithm for your organization, keep in mind the export regulations of cryptographic equipment, which might limit your choice.


A good cryptographic algorithm is designed in such a way that it resists common cryptographic attacks. The best way to break data protected by the algorithm is to try to decrypt the data using all the possible keys. The length of time that such an attack requires to succeed depends on the number of possible keys, but is generally very, very long. With appropriately long keys, such attacks are usually considered infeasible.

Variable key lengths and scalability are also desirable attributes of a good encryption algorithm. The longer the encryption key, the longer it takes an attacker to break it. For example, a 16-bit key would mean that there are 65,536 possible keys, but a 56-bit key would mean there are 7.2 * 1016 possible keys. Scalability provides flexible key lengths and allows you to select the strength and speed of encryption that you need.

When changing only a few bits of the plaintext message causes its ciphertext to change completely, this is known as an avalanche effect. The avalanche effect is a desired feature of an encryption algorithm because it allows very similar messages to be sent over an untrusted medium, with the encrypted (ciphertext) messages being completely different.

You must carefully consider export and import restrictions when you use encryption internationally. Some countries do not allow the export of encryption algorithms, or allow only the export of these algorithms with shorter keys, and some countries impose import restrictions on cryptographic algorithms.

In January 2000, and again in 2010, the restrictions that the U.S. Department of Commerce placed on export regulations were dramatically relaxed. As an example of the loosening of the rules, cryptographic products were made exportable under a license exception unless the end users were governments outside the United States or under embargo. For more information on the current U.S. Department of Commerce export regulations, see http://www.commerce.gov.

Key Management

Key management is often considered the most difficult part of designing a cryptosystem. Many cryptosystems have failed because of mistakes in their key management, and all modern cryptographic algorithms require the services of key management procedures. In practice, most attacks on cryptographic systems will be aimed at the key management level rather than at the cryptographic algorithm itself.

Key Management Components

Key management consists of the following components:

Key generation: In a modern cryptographic system, key generation is usually automated and not left to the end user. The use of good random number generators is needed to ensure that all keys are likely to be equally generated so that the attacker cannot predict which keys are more likely to be used.

Key verification: Almost all cryptographic algorithms have some weak keys that should not be used, and with the help of key verification procedures, you can regenerate these keys if they occur.

Key storage: On a modern multiuser operating system that uses cryptography, a key can be stored in memory. This presents a possible problem when that memory is swapped to the disk, because a Trojan horse program, installed on the PC of a user, could then have access to the private keys of that user. A possible solution is to store the key on a USB stick and require a password to unlock that key.

Key exchange: The key management procedures should also provide a secure key exchange mechanism, which allows secure agreement on the keying material with the other party, probably over an untrusted medium.

Key revocation and destruction: Key revocation notifies all the interested parties that a certain key has been compromised and should no longer be used. Key destruction erases old keys in such a manner that malicious attackers cannot recover them.

Key management deals with the secure generation, verification, exchange, storage, revocation, and destruction of keys.

Keyspaces

The keyspace of an algorithm is the set of all possible key values. A key that has n bits produces a keyspace that has 2n possible key values. By adding 1 bit to the key, you effectively double the keyspace. For example, DES with its 56-bit keys has a keyspace of more than 72,000,000,000,000,000 (256) possible keys, but by adding 1 bit to the key length, the keyspace doubles, and an attacker needs twice the amount of time to search the keyspace.

As previously mentioned, almost every algorithm has some weak keys in its keyspace that enable an attacker to break the encryption via a shortcut. Weak keys show regularities in encryption or poor encryption. For instance, DES has four keys for which encryption is the same as decryption. This means that if one of these weak keys is encrypted twice, the original plaintext is recovered.

The weak keys of DES are those that produce 16 identical subkeys. This occurs when the key bits are

• Alternating 1s + 0s (0101010101010101)

• Alternating F + E (FEFEFEFEFEFEFEFE)

• E0E0E0E0F1F1F1F1

• 1F1F1F1F0E0E0E0E

It is unlikely that such keys would be chosen, but implementations should still verify all keys and prevent weak keys from being used. With manual key generation, you must take special care to avoid defining weak keys.

Key Length Issues

If the cryptographic system is trustworthy, the only way to break it is with a brute-force attack. A brute-force attack is a search through the entire keyspace, trying all the possible keys, to find a key that decrypts the data. If the keyspace is large enough, the search should require an enormous amount of time, making such an exhaustive effort infeasible. On average, an attacker has to search through half of the keyspace before the correct key is found. The time that is needed to accomplish this search depends on the computer power available to the attacker. However, current key lengths can easily make any attempt insignificant, because it would take many millions or billions of years to complete the search when a sufficiently long key is used.

With modern algorithms that are trusted, the strength of protection depends solely on the length of the key. Choose the key length so that it protects data confidentiality or integrity for an adequate period of time. Data that is more sensitive and needs to be kept secret longer must use longer keys.

The funding of the attacker should also affect your choice of key length. When you assess the risk of someone breaking the encryption algorithm, you must estimate the resources of the attacker and how long you must protect the data. For example, if the attacker has $1 million of funding, and the data must be protected for one year, classic DES is not a good choice because it can be broken by a $1 million machine in a couple of minutes. However, it would take an attacker some million years or more to crack 168-bit 3DES or 128-bit RC4, which makes either of these key length choices more than adequate.

Performance is another issue that can influence the choice of key length. You must find a good balance between the speed and protection strength of an algorithm, because some algorithms, such as RSA, run slower with larger key sizes. Strive for adequate protection while also enabling unhindered communication over untrusted networks.

Because of the rapid advances in technology and cryptanalytic methods, the key size needed for a particular application is constantly increasing. Go to the BlueKrypt website at http://www.keylength.com/en/4/ to see updated NIST key length recommendations.

Example of the Impact of Key Length

Part of the strength of the RSA algorithm is the difficulty of factoring large numbers. If a 1024-bit number is hard to factor, then a 2048-bit number is going to be even harder to factor. Even with the fastest computers available today, it would take many lifetimes to factor a 1024-bit number that is a factor of two 512-bit prime numbers. Of course, this advantage is lost if an easy way to factor large numbers is found. However, cryptographers consider this possibility unlikely, and the rule “the longer the key, the better” is valid, except for possible performance reasons.

As of 2005, the best known attack on 3DES required around 232 known plaintexts, 2113 steps, 290 single DES encryptions, and 288 memory operations. This is not currently practical. If the attacker seeks to discover any one of many cryptographic keys, there is a memory-efficient attack that will discover one of 228 keys, given a handful of chosen plaintexts per key and around 284 encryption operations. This attack is highly parallelizable and verges on the practical, given billion-dollar budgets and years to mount the attack, although the circumstances in which it would be useful are limited.

Symmetric and Asymmetric Encryption Overview

An encryption algorithm, which is also called a cipher, is a mathematical function that is used to encrypt and decrypt data. Generally, there are two functions, one to encrypt and one to decrypt. If the security of an encryption system is based on the secrecy of the algorithm itself, the algorithm code must be heavily guarded. If the algorithm is revealed, every party that is involved must change the algorithm.

Modern cryptography takes a different approach: all algorithms are public, and cryptographic keys are used to ensure the secrecy of data. There are two classes of encryption algorithms, which differ in their use of keys:

Symmetric encryption algorithms: Use the same key to encrypt and decrypt data

Asymmetric encryption algorithms: Use different keys to encrypt and decrypt data

A key is a required parameter for encryption algorithms. There are two concepts regarding keys:

Symmetric encryption: The same key encrypts and decrypts.

Asymmetric encryption: One key encrypts, and a different key decrypts.

Symmetric Encryption Algorithms

Symmetric encryption algorithms are algorithms in which the encryption and decryption keys are the same, as shown in Figure 12-14. Therefore, the sender and the receiver must share the same secret key before communicating securely. The security of a symmetric algorithm rests in the secrecy of the symmetric key; by obtaining the key, anyone can encrypt and decrypt messages. Symmetric encryption is often called secret-key encryption. Symmetric, or secret-key, encryption is the more traditional form of cryptography. The typical key length range of symmetric encryption algorithms is 40 to 256 bits. Best practice considers that anything less than 128-bit key material is not considered strong enough for business use.

Figure 12-14. Symmetric Encryption at Work

The following are well-known encryption algorithms that use symmetric keys:

DES: 56-bit keys

Triple DES (3DES): 112- and 168-bit keys

AES: 128-, 192-, and 256-bit keys

IDEA: 128-bit keys

The RC series (RC2, RC4, RC5, and RC6):

RC2: 40- and 64-bit keys

RC4: 1- to 256-bit keys

RC5: 0- to 2040-bit keys

RC6: 128-, 192-, and 256-bit keys

Blowfish: 32- to 448-bit keys

The most commonly used techniques in symmetric encryption cryptography are block ciphers, stream ciphers, and message authentication codes (MAC).

Because symmetric algorithms are usually quite fast, they are often used for wire-speed encryption in data networks. Symmetric algorithms are based on simple mathematical operations and can easily be accelerated by hardware. Because of their speed, you can use symmetric algorithms for bulk encryption when data privacy is required (for example, to protect a VPN).

On the other hand, key management can be a challenge. The communicating parties must exchange the symmetric, secret key using a secure channel before any encryption can occur. Therefore, the security of any cryptographic system depends greatly on the security of the key exchange method.

Because of their speed, symmetric algorithms are frequently used for encryption services, with additional key management algorithms providing secure key exchange.

Some of the characteristics of symmetric algorithms are as follows:

• Faster than asymmetric algorithms.

• Much stronger than asymmetric algorithms.

• Much shorter key lengths than asymmetric algorithms.

• Simpler mathematics than asymmetric algorithms.

• One key is used for both encryption and decryption.

• Sometimes referred to as private-key encryption.

Modern symmetric algorithms use key lengths that range from 40 to 256 bits. This range gives symmetric algorithms keyspaces that range from 240 (1,099,511,627,776 possible keys) to 2256 (1.5 * 1077) possible keys. (Keyspaces are described in depth later in this chapter.) This large range is the difference between whether or not the algorithm is vulnerable to a brute-force attack. If you use a key length of 40 bits, your encryption is likely to be broken easily using a brute-force attack. In contrast, if your key length is 256 bits, it is unlikely that a brute-force attack will be successful, because the keyspace is too large.

On average, a brute-force attack will succeed halfway through the keyspace. Key lengths that are too short can have the entire possible keyspace stored in RAM on a server cluster of a cracker, which makes it possible for the algorithm to be cracked in real time.

Table 12-2 illustrates ongoing expectations for valid key lengths, assuming that the algorithms are mathematically and cryptographically sound. What is also assumed in such calculations is that computing power will continue to grow at its present rate and the ability to perform brute-force attacks will grow at the same rate.

Table 12-2. Acceptable Key Lengths in Bits


Caution

If a method other than brute-force is discovered against a particular algorithm, the key lengths in Table 12-2 become obsolete.



Note

Note the comparatively short symmetric key lengths, illustrating that symmetric algorithms are the strongest type of algorithm.


Comparing Symmetric Encryption Algorithms

Symmetric encryption algorithms operate under the same framework, but they present considerable differences. Table 12-3 provides a summary analysis of their respective characteristics.

Table 12-3. Characteristics of Symmetric Encryption Algorithms

DES

Data Encryption Standard (DES) is a symmetric encryption algorithm, as shown in Figure 12-14. It usually operates in block mode, in which it encrypts data in 64-bit blocks.

The DES algorithm is essentially a sequence of permutations and substitutions of data bits, combined with the encryption key. The same algorithm and key are used for both encryption and decryption. Cryptography researchers have scrutinized DES for nearly 35 years and have found no significant flaws.

Because DES is based on simple mathematical functions, it can easily be implemented and accelerated in hardware.

DES has a fixed key length. The key is actually 64 bits long, but only 56 bits are used for encryption, with the remaining 8 bits used for parity; the least significant bit of each key byte is used to indicate odd parity.

A DES key is always 56 bits long. When you use DES with a weaker encryption of a 40-bit key, it actually means that the encryption key is 40 secret bits and 16 known bits, which makes the key length 56 bits. In this case, DES actually has a key strength of 40 bits.

DES Modes of Operation

To encrypt or decrypt more than 64 bits of data, DES uses two different types of ciphers:

Block ciphers: Operate on fixed-length groups of bits, termed blocks, with an unvarying transformation

Stream ciphers: Operate on individual digits one at a time with the transformation varying during the encryption

DES Security Guidelines

You should consider doing several things to protect the security of DES-encrypted data:

• Change keys frequently to help prevent brute-force attacks.

• Use a secure channel to communicate the DES key from the sender to the receiver.

• Consider using DES in CBC mode. With CBC, the encryption of each 64-bit block depends on previous blocks. CBC is the most widely used mode of DES.

• Verify that a key is not part of the weak or semi-weak key list before using it. DES has 4 weak keys and 12 semi-weak keys. Because there are 256 possible DES keys, the chance of picking one of these keys is small. However, because testing the key has no significant impact on the encryption time, it is recommended that you test the key. The keys that should be avoided are listed in Section 3.6 of Publication 74 of the Federal Information Processing Standards, found at http://www.itl.nist.gov/fipspubs/fip74.htm.


Note

If possible, use 3DES rather than DES. You should use DES only for very short-term confidentiality.


3DES

With advances in computer processing power, the original 56-bit DES key became too short to withstand even medium-budget attackers. One way to increase the DES effective key length, without changing the well-analyzed algorithm itself, is to use the same algorithm with different keys several times in a row.

The technique of applying DES three times in a row to a plaintext block is called 3DES. Brute-force attacks on 3DES are considered infeasible today, and because the basic algorithm has been well tested in the field for more than 35 years, it is considered very trustworthy.

3DES uses a method called 3DES-Encrypt-Decrypt-Encrypt (3DES-EDE) to encrypt plaintext, as shown in Figure 12-15. 3DES-EDE includes the following steps:

Step 1. The message is encrypted using the first 56-bit key, known as K1.

Step 2. The data is decrypted using the second 56-bit key, known as K2.

Step 3. The data is encrypted again, now using the third 56-bit key, known as K3.

Figure 12-15. 3DES Encryption Process

The 3DES-EDE procedure provides encryption with an effective key length of 168 bits. If keys K1 and K3 are equal, as in some implementations, a less-secure encryption of 112 bits is achieved.

The following procedure is used to decrypt a 3DES-EDE block:

Step 1. Decrypt the ciphertext using key K3.

Step 2. Encrypt the data using key K2.

Step 3. Decrypt the data using key K1.


Note

Encrypting the data three times with three different keys does not significantly increase security. The 3DES-EDE method must be used. For example, it can be shown that encrypting data three times in a row using different 56-bit keys equals an effective 58-bit key strength and not the full 168-bit key strength, as you would expect.

Also, here’s why 3DES can be either 56-, 112-, or 168-bit strong: 3DES keying option 1, which provides 168-bit strength, uses three independent 56-bit values for K1, K2, and K3 (3 × 56 bits). With keying option 2, K1 and K3 use the same value and K2 is a different value, so two different 56-bit keys produce a 112-bit strength (2 × 56). Keying option 1 uses only one 56-bit value for K1, K2, and K3, offering only 56-bit strength.


AES

For a number of years, it was recognized that DES would eventually reach the end of its usefulness. In 1997, the AES initiative was announced, and the public was invited to propose candidate encryption schemes, one of which could be chosen as the encryption standard to replace DES. There were rigorous reviews of 15 original candidates. Rijndael, Twofish, and RC6 were among the finalists. Rijndael was ultimately selected.

The Rijndael Cipher

On October 2, 2000, the U.S. National Institute of Standards and Technology (NIST) announced the selection of the Rijndael cipher as the AES algorithm. The Rijndael cipher, developed by Joan Daemen and Vincent Rijmen, has a variable block length and key length. The algorithm currently specifies how to use keys with a length of 128, 192, or 256 bits to encrypt blocks with a length of 128, 192, or 256 bits, which provides nine different combinations of key length and block length. Both block length and key length can be extended very easily in multiples of 32 bits.

The U.S. Secretary of Commerce approved the adoption of AES as an official U.S. government standard, effective May 26, 2002. AES is listed in Annex A of FIPS Publication 140-2 as an approved security function.


Note

Go to http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf for more information about AES.


Rijndael is an iterated block cipher, which means that the initial input block and cipher key undergo multiple transformation cycles before producing output. The algorithm can operate over a variable-length block using variable-length keys; a 128-, 192-, or 256-bit key can be used to encrypt data blocks that are 128, 192, or 256 bits long, and all nine combinations of key and block length are possible. The accepted AES implementation of Rijndael contains only some of the capabilities of the Rijndael algorithm. The algorithm is written so that the block length or the key length or both can easily be extended in multiples of 32 bits, and the system is specifically designed for efficient implementation in hardware or software on a range of processors.

AES Versus 3DES

AES was chosen to replace DES and 3DES because the key length of AES makes it stronger than DES and AES runs faster than 3DES on comparable hardware. AES is more efficient than DES and 3DES on comparable hardware, usually by a factor of five when it is compared with DES. Also, AES is more suitable for high-throughput, low-latency environments, especially if pure software encryption is used. However, AES is a relatively young algorithm, and, as the golden rule of cryptography states, a more mature algorithm is always more trusted. 3DES is therefore a more conservative and more trusted choice in terms of strength, because it has been analyzed for around 35 years.

Rivest Ciphers

The RC family of algorithms is widely deployed in many networking applications because of their favorable speed and variable key length capabilities.

The RC algorithms were designed all or in part by Ronald Rivest. Some of the most widely used RC algorithms are as follows:

RC2: A variable-key-size block cipher that was designed as a “drop-in” replacement for DES.

RC4: A variable-key-size Vernam stream cipher often used in file encryption products and for secure communications, such as within SSL. It is not considered a one-time pad because its key is not random. The cipher can be expected to run very quickly in software and is considered secure, although it can be implemented insecurely, as in WEP.

RC5: A fast block cipher that has variable block size and variable key size. With a 64-bit block size, RC5 can be used as a drop-in replacement for DES.

RC6: A block cipher that was designed by Rivest, Sidney, and Yin and is based on RC5. Its main design goal was to meet the requirement of AES.


SEAL

Although it is beyond the scope of this book, it is good to know that Cisco also provides support for SEAL encryption. The Software-optimized Encryption Algorithm is an alternative algorithm to software-based DES, 3DES, and AES. SEAL encryption uses a 160-bit encryption key and has a lower impact on the CPU compared to other software-based algorithms. The SEAL encryption feature provides support for the SEAL algorithm in Cisco IOS IPsec implementations. SEAL support was added to Cisco IOS Software Release 12.3(7)T.


Asymmetric Encryption Algorithms

Asymmetric algorithms, also sometimes called public-key algorithms, are designed in such a way that the key used for encryption differs from the key used for decryption, as shown in Figure 12-16.

Figure 12-16. Asymmetric Encryption at Work

The decryption key cannot, in any reasonable amount of time, be calculated from the encryption key, and vice versa. The typical key length range for asymmetric algorithms is 512 to 4096 bits. You cannot directly compare the key length of asymmetric and symmetric algorithms because the underlying design of the two algorithm families differs greatly.


Note

For further reference, consult the book Applied Cryptography, by Bruce Schneier. Mr. Schneier also maintains an informative and entertaining blog/newsletter, which you can subscribe to at http://www.schneier.com/crypto-gram.html.


The best-known asymmetric cryptographic algorithms are RSA, ElGamal, Digital Signature Algorithm (DSA), and elliptic curve algorithms.


Note

Rivest, Shamir, and Aldeman, who met while at the Massachusetts Institute of Technology (MIT), released the RSA algorithm in 1977.


Asymmetric algorithms are substantially slower than symmetric algorithms. Their design is based on computational problems, such as factoring extremely large numbers or computing discrete logarithms of extremely large numbers. Because they lack speed, asymmetric algorithms are typically used in low-volume cryptographic mechanisms, such as digital signatures and key exchange. However, the key management of asymmetric algorithms tends to be simpler than that of symmetric algorithms, because usually one of the two encryption or decryption keys can be made public.

Because symmetric ciphers are faster than asymmetric algorithms, they are used for bulk data encryption.

Asymmetric algorithms are explained in greater detail later in this book.

Public Key Confidentiality

The confidentiality objective of asymmetric algorithms is achieved when the encryption process is started with the public key. When the public key is used to encrypt the data, the private key must be used to decrypt the data. Because only one host has the private key, confidentiality is achieved.

Public key (encrypt) + Private key (decrypt) = Confidentiality

In Figure 12-17, Alice and Bob exchange data with the goal of confidentiality. They follow these steps:

Step 1. Alice acquires Bob’s public key (how the public key is acquired will be discussed later in this chapter when we discuss certificate authorities).

Step 2. Alice uses Bob’s public key to encrypt a message, which is often a symmetric key, using an agreed upon algorithm.

Step 3. Alice transmits the encrypted message.

Step 4. Bob uses his private key to decrypt, and reveal, the message.

Figure 12-17. Asymmetric Confidentiality Process

We just saw how asymmetric encryption can be used to provide confidentiality. In an upcoming section, we will see how asymmetrical encryption is used to provide proof of authenticity and integrity by using digital signatures.

Encryption Algorithm Selection

Choosing an encryption algorithm is one of the most important steps of building a cryptography-based solution. You should consider two main criteria when selecting an encryption algorithm for your organization:

Trust in the algorithm by the cryptographic community: Most new algorithms are broken quickly, so algorithms that have been resisting attacks for a number of years are preferred. Inventors and promoters often oversell the benefits of new algorithms. The truth is that there are few or no revolutions in cryptography.

Protection against brute-force attacks: If the algorithm is considered trusted, there is no shortcut to break it, and the attacker must search through the keyspace to guess the correct key. The algorithm must allow key lengths that satisfy the confidentiality requirements of an organization. For example, DES no longer provides enough protection for most modern needs because of its short key length.

The following symmetric encryption algorithms are considered trustworthy:

• 3DES

• IDEA

• AES

The following asymmetric encryption algorithms, all covered in more detail later in this book, are considered trustworthy:

• RSA

• Elliptic Curve Digital Signature Algorithm (ECDSA)

• Diffie-Hellman (DH)

For symmetric algorithms, each bit in a key doubles the difficulty of finding the key. But with asymmetric algorithms, such as RSA, each additional bit only nominally increases the difficulty of factoring the composite number that is used by the algorithm. Therefore, comparatively shorter key lengths for symmetric algorithms are similar to larger key lengths using asymmetric algorithms, when both types of algorithm are used for similar objectives (for instance, when comparing the two types of algorithm in terms of confidentiality and payload encryption). Symmetric and asymmetric keys compare as follow:

• An 80-bit symmetric key is considered equal to a 1024-bit key using the RSA algorithm.

• A 112-bit symmetric key is considered equal to a 2048-bit key using the RSA algorithm.

• A 128-bit symmetric key is considered equal to a 3072-bit key using the RSA algorithm.

For more information about the comparison of the key strengths of symmetric algorithms to RSA, refer to http://www.rsasecurity.com/rsalabs/node.asp?id=2004.

Cryptographic Hashes and Digital Signatures

Cryptographic hashes and digital signatures play an important part in modern cryptosystems. They provide verification and authentication and play an important role in non-repudiation. It is important to understand the basic mechanisms of these algorithms and some of the issues involved in choosing a particular hashing algorithm or digital signature method.

Hashing is a mechanism used for data integrity assurance. The hashing process uses a hash function, which is a one-way function of input data that produces a fixed-length digest of output data, also known as a fingerprint. The digest is cryptographically very strong. Hashes are functions that are relatively easy to compute, but significantly harder to reverse. Grinding coffee is a good example of a one-way function: it is easy to grind coffee beans, but it is impractical (not to say impossible) to put all the tiny pieces back together to rebuild the original beans.

If the input data changes just a little bit, the digest changes substantially. This is known as the avalanche effect. Essentially, the fingerprint that results from hashing data uniquely identifies that data. If you are given only a fingerprint, it is computationally infeasible to generate data that would result in that fingerprint.

Figure 12-18 illustrates how hashing is performed. Data of arbitrary length is input into the hash function. Hashing is similar to the calculation of cyclic redundancy check (CRC) checksums, but it is much stronger cryptographically. That is, given a CRC value, it is easy to generate data with the same CRC. However, with hash functions, it is computationally infeasible for an attacker to have two different sets of data that would come up with the same fingerprint.

Figure 12-18. Cryptographic Hashes


Note

Extrapolating from the explanation above, it is easy to understand the possibility that two different pieces of data could produce the same hash result. This is called a collision. As an example, a few years ago I transferred my Microsoft Outlook PST file to a new computer. Upon launching MS Outlook from my new computer, I was asked for the password of the PST file. I couldn’t remember it because it had been cached in the settings of my previous laptop for years and, therefore, I never had to type it in. Knowing that MS Outlook PST passwords are kept as a CRC32 hash in the PST file itself, I used freeware designed for this purpose and was able to get the hash result of my password. I then proceeded to find a CRC32 hash-guessing freeware tool and get the hash result found in the PST file. The hash-guessing tool provided me with a long alphanumeric code which, when hashed, produced the same result as the hashed password for my PST file. This code was obviously not my real password, but at least it provided the same hash result, so I proceeded to use that code as the password to open my PST file. This is how I cracked my own MS Outlook file. And, by the way, I immediately proceeded to change the Outlook password to a string I could remember.

This is an example of having two separate seed values producing the same hash results is an example of collision.


The hashing process is not reversible; it is a one-way function with a fixed-length output. If you hash the word “Hello” with MD5 (covered later), the output, called the message digest, will be 128 bits long. If you process the Oxford English Dictionary through MD5, the message digest will be 128 bits long. It is impossible to take a message digest of 128 bits long and try to reverse-engineer it into a 1200-page dictionary; thus the expression that hashing is a one-way function.

Hashing is often applied in the following situations:

• To generate one-time and one-way responses to challenges in authentication protocols such as PPP Challenge Handshake Authentication Protocol (PPP CHAP), Microsoft NT Domain, and Extensible Authentication Protocol-Message Digest 5 (EAP-MD5)

• To provide proof of the integrity of data, such as that provided with file integrity checkers, digitally signed contracts, and PKI certificates

• To provide proof of authenticity when it is used with a symmetric secret authentication key, such as IPsec or routing protocol authentication

Hashing algorithms are one-way processes.

A hash function, H, is a transformation that takes an input, (x), and returns a fixed-size string, which is called the hash value, h. The formula for the calculation is h = H(x).

A cryptographic hash function should have the following general properties:

• The input can be any length.

• The output has a fixed length.

• H(x) is relatively easy to compute for any given x.

• H(x) is one way and not reversible.

• H(x) is collision free.

If a hash function is hard to invert, it is considered a one-way hash. “Hard to invert” means that given a hash value h, it is computationally infeasible to find some input, (x), such that H(x) = h. H is said to be a weakly collision-free hash function if, given a message x, it is computationally infeasible to find a message y not equal to x such that H(x) = H(y). A strongly collision-free hash function, H, is one for which it is computationally infeasible to find any two messages x and y such that H(x) = H(y).

Figure 12-18 illustrates the hashing process. Data of arbitrary length is input into the hash function, and the result of the hash function is the fixed-length digest, or fingerprint. Hashing is similar to the calculation of CRC checksums, but is cryptographically stronger. That is, given a CRC value, it is easy to generate data with the same CRC. However, as mentioned before, with hash functions, it is computationally infeasible for an attacker, given a hash value h, to find some input, (x), such that H(x) = h.

Figure 12-19 illustrates hashing in action. The sender wants to ensure that the message is not altered on its way to the receiver. The sending device inputs the message into a hashing algorithm and computes its fixed-length digest. This fingerprint is then attached to the message, where the message and the hash are in plaintext. The message, and its fingerprint attached, is sent to the receiver. The receiving device removes the fingerprint from the message and inputs the message into the same hashing algorithm. If the hash that is computed by the receiving device is equal to the one that is attached to the message, the message has not been altered during transit.

Figure 12-19. Data Integrity: Hashing in Action

Hashing does not add security to the message. When the message traverses the network, a potential attacker could intercept the message, change it, recalculate the hash, and append it to the message. Hashing only prevents the message from being changed accidentally, such as by a communication error. There is nothing unique to the sender in the hashing procedure; therefore, anyone can compute a hash for any data, as long as they have the correct hash function.

Thus, hash functions are helpful to ensure that data did not change accidentally, but it cannot ensure that data was not deliberately changed.

These are two well-known hash functions:

• Message Digest 5 (MD5) with 128-bit digests

• Secure Hash Algorithm 1 (SHA-1) with 160-bit digests

Hashing Algorithms

The two most commonly used cryptographic hash functions are MD5 and SHA-1. SHA-2 is an additional and newer option. Table 12-4 compares the three algorithms in terms of strength, key size, and vulnerability to cryptanalytic attacks.

Table 12-4. Comparing Hashing Algorithms


Note

Although originally thought to be collision resistant, both MD5 and SHA were later found to be vulnerable to such forms of attack.


MD5

The MD5 algorithm is a ubiquitous hashing algorithm that was developed by Ron Rivest and is used in a variety of Internet applications today.

MD5 is a one-way function, which makes it easy to compute a hash from the given input data but makes it infeasible to compute input data given only a hash. MD5 is also collision resistant, which means that two messages with the same hash are very unlikely to occur. MD5 is essentially a complex sequence of simple binary operations, such as XORs and rotations, that are performed on input data and produce a 128-bit digest.

The main algorithm itself is based on a compression function, which operates on blocks. The input is a data block plus a feedback of previous blocks. Each 512-bit block is divided into sixteen 32-bit subblocks. These blocks are then rearranged with simple operations in a main loop, which consists of four rounds. The output of the algorithm is a set of four 32-bit blocks, which concatenate to form a single 128-bit hash value. The message length is also encoded into the digest.

MD5 is based on MD4, an earlier algorithm. MD4 has been broken, and currently MD5 is considered less secure than SHA-1 by many authorities on cryptography, such as ICSA Labs (http://www.icsalabs.com). These authorities consider MD5 less secure than SHA-1 because some noncritical weaknesses have been found in one of the MD5 building blocks, causing uneasy feelings inside the cryptographic community. The availability of the SHA-1 and RACE Integrity Primitives Evaluation Message Digest (RIPEMD)-160 HMAC functions, which do not show such weaknesses and use a stronger (160-bit) digest, makes MD5 a second choice as far as hash methods are concerned.

SHA-1

The U.S. National Institute of Standards and Technology (NIST) developed the Secure Hash Algorithm (SHA), the algorithm that is specified in the Secure Hash Standard (SHS). SHA-1 is a revision to the SHA that was published in 1994; the revision corrected an unpublished flaw in SHA. Its design is similar to the MD4 family of hash functions that Ron Rivest developed.

The SHA-1 algorithm takes a message of less than 264 bits in length and produces a 160-bit message digest. The algorithm is slightly slower than MD5, but the larger message digest makes it more secure against brute-force collision and inversion attacks. More details on SHA-1 collision attacks can be found at http://www.rsa.com/rsalabs/node.asp?id=2927.

You can find the official text for the standard at http://www.itl.nist.gov/fipspubs/fip180-1.htm.


Note

SHA also has 224-, 256-, 384-, and 512-bit versions.


SHA-2

Secure Hash Algorithm 2 (SHA-2) specifies five SHAs—SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512—for computing a condensed representation of electronic data. When a message of any length less than 264 bits (for SHA-224 and SHA-256) or less than 2128 bits (for SHA-384 and SHA-512) is input to a hash algorithm, the result is a message digest that ranges in length from 224 to 512 bits, depending on the algorithm.

The SHA-2 family of hash functions was approved by NIST for use by federal agencies in 2006, for all applications using SHAs. The publication encouraged all federal agencies to stop using SHA-1 for digital signatures, digital time stamping, and other applications that require collision resistance as soon as practical, and it mandated the use of the SHA-2 family of hash functions for these applications after 2010. After 2010, federal agencies used SHA-1 only for the following applications: HMACs, key derivation functions (KDF), and random number generators (RNG). This change was triggered in 2005 when security flaws were identified for SHA-1 in theoretical exploits that exposed weaknesses to collision attacks.

Hashed Message Authentication Codes

Hash functions are the basis of the protection mechanism of Hashed Message Authentication Codes (HMAC). HMACs use existing hash functions, but with a significant difference; HMACs add a secret key as input to the hash function. Only the sender and the receiver know the secret key, and the output of the hash function now depends on the input data and the secret key. Therefore, only parties who have access to that secret key can compute the digest of an HMAC function. This behavior defeats man-in-the-middle attacks and provides authentication of the data origin. If two parties share a secret key and use HMAC functions for authentication, a properly constructed HMAC digest of a message that a party has received indicates that the other party was the originator of the message, because it is the only other entity possessing the secret key.

Cisco technologies use two well-known HMAC functions:

• Keyed MD5, based on the MD5 hashing algorithm

• Keyed SHA-1, based on the SHA-1 hashing algorithm

Figure 12-20 illustrates how an HMAC digest is created. Data of an arbitrary length is input into the hash function, together with a secret key. The result is the fixed-length hash that depends on the data and the secret key.

Figure 12-20. HMAC Digest Creation

Figure 12-21 illustrates an HMAC in action. The sender wants to ensure that the message is not altered in transit and wants to provide a way for the receiver to authenticate the origin of the message.

Figure 12-21. HMAC in Action

The sending device inputs data and the secret key into the hashing algorithm and calculates the fixed-length HMAC digest. This authenticated fingerprint is then attached to the message and sent to the receiver. The receiving device removes the fingerprint from the message and uses the plaintext message with the secret key as input to the same hashing function. If the fingerprint calculated by the receiving device is equal to the fingerprint that was sent, the message has not been altered. In addition, the origin of the message is authenticated, because only the sender possesses a copy of the shared secret key. The HMAC function has ensured the authenticity of the message.


Note

IPsec VPNs rely on HMAC functions to authenticate the origin and provide data integrity checking of every packet.


Cisco products use hashing for entity-authentication, data-integrity, and data-authenticity purposes:

• IPsec gateways and clients use hashing algorithms, such as MD5 and SHA-1 in HMAC mode, to provide packet integrity and authenticity.

• Cisco IOS routers use hashing with secret keys in an HMAC-like manner, to add authentication information to routing protocol updates.

• Cisco software images that you can download from Cisco.com have an MD5-based checksum available so that customers can check the integrity of downloaded images.

• Hashing can also be used in a feedback-like mode to encrypt data; for example, TACACS+ uses MD5 to encrypt its session.

Overview of Digital Signatures

When data is exchanged over untrusted networks, several major security issues must be determined:

Whether data has changed in transit: Hashing and HMAC functions rely on a cumbersome exchange of secret keys between parties to provide the guarantee of integrity.

Whether a document is authentic: Hashing and HMAC can provide some guarantee of authenticity, but only by using secret keys between two parties. Hashing and HMAC cannot guarantee authenticity of a transaction or a document to a third party.

Digital signatures are often used in the following situations:

• To provide a unique proof of data source, which can be generated only by a single party, such as with contract signing in e-commerce environments

• To authenticate a user by using the private key of that user and the signature it generates

• To prove the authenticity and integrity of PKI certificates

• To provide a secure time stamp, such as with a central trusted time source

Suppose a customer sends transaction instructions via an email to a stockbroker, and the transaction turns out badly for the customer. It is conceivable that the customer could claim never to have sent the transaction order, or that someone forged the email. The brokerage could protect itself by requiring the use of digital signatures before accepting instructions via email.

Handwritten signatures have long been used as a proof of authorship of, or at least agreement with, the contents of a document. Digital signatures can provide the same functionality as handwritten signatures, and much more.

Digital signatures provide three basic security services in secure communications:

Authenticity of digitally signed data: Digital signatures authenticate a source, proving that a certain party has seen and has signed the data in question.

Integrity of digitally signed data: Digital signatures guarantee that the data has not changed from the time it was signed.

Nonrepudiation of the transaction: The recipient can take the data to a third party, which accepts the digital signature as a proof that this data exchange did take place. The signing party cannot repudiate that it has signed the data.


Note

To better understand nonrepudiation, consider the use of HMAC functions, which also provide authenticity and integrity guarantees. With HMAC functions, two or more parties share the same authentication key and can compute the HMAC fingerprint. Therefore, taking received data and its HMAC fingerprint to a third party does not prove that the other party sent this data; you could have generated the same HMAC fingerprint yourself, because you have a copy of the HMAC authentication key. With digital signatures, each party has a unique, secret signature key, which is not shared with any other party, making nonrepudiation possible.


To achieve the preceding goals, digital signatures have the following properties:

The signature is authentic: The signature convinces the recipient of the document that the signer signed the document.

The signature is not forgeable: The signature is proof that the signer, and no one else, signed the document.

The signature is not reusable: The signature is a part of the document and cannot be moved to a different document.

The signature is unalterable: After a document is signed, the document cannot be altered without detection.

The signature cannot be repudiated: The signature and the document are physical things. The signer cannot claim later that they did not sign it.

Well-known asymmetric algorithms, such as RSA or DSA, are typically used to perform digital signing.

In some countries, including the United States, digital signatures are considered equivalent to handwritten signatures, if they meet certain provisions. Some of these provisions include the proper protection of the certificate authority, the trusted signer of all other public keys, and the proper protection of the private keys of the users. In such a scenario, users are responsible for keeping their private keys private, because a stolen private key can be used to “steal” their identity.

Later in this chapter you will have the opportunity to delve deeper into the mechanics of digital signatures, but for now Figure 12-22 illustrates the basic functioning of digital signatures:

Step 1. When someone wants to sign some data, they use a signature algorithm with their signature key. Only the signer knows this signature key. Therefore, the signer must keep the signature key secret.

Step 2. Based on the input data and a signature key, the signature algorithm generates its output, which is called a digital signature.

Step 3. The sending device attaches the digital signature to the message and sends the message to the receiver.

Step 4. The receiving device verifies the signature with the verification key, which is usually public.

Step 5. The receiving device inputs the message, the digital signature, and the verification key into the verification algorithm, which checks the validity of the digital signature.

Step 6. If the check is successful, the document has not been changed after signing and the document was originated by the signer of the document.

Figure 12-22. Digital Signatures in Action

Digital Signatures = Encrypted Message Digest

A digital signature is the result of encrypting, with the user’s private key, the digest and appending that encrypted digest to the plaintext or encrypted message to verify the identity of the sender. The digest will be decrypted with the corresponding public key.

A digital signature provides authentication and integrity. If the recipient is successful at decrypting the digest using the public key of the sender, the recipient has proof of the origin of the message. Also, if both hashes have the same value—the hash calculated by the recipient upon receiving the message and the decrypted hash that was appended to the message in the first place—the recipient has proof that the message wasn’t tampered with during transmission, and thus proof of its integrity.

Digital signatures are commonly used to provide assurance of the code authenticity and integrity of both mobile and classic software. As an example, you might have noticed that some executable files (or possibly the whole installation package of a program) are wrapped with a digitally signed envelope, which allows the end user to verify the signature before installing the software.

Digitally signing code provides several assurances about the code:

• The code has not been modified since it left the software publisher.

• The code is authentic and is actually sourced by the publisher.

• The publisher undeniably publishes the code. This provides nonrepudiation of the act of publishing.

The digital signature could be forged only if someone obtained the private key of the publisher. The assurance level of digital signatures is extremely high if the private key is protected properly.

The user of the software must also obtain the public key, which is used to verify the signature. The user can obtain the key in a secure fashion; for example, the key could be included with the installation of the operating system, or transferred securely over the network (for example, using the PKI and certificate authorities).

Diffie-Hellman

Earlier, we discussed how symmetric encryption is faster than asymmetric encryption. However, a significant drawback of symmetric encryption is key generation and distribution. The Diffie-Hellman algorithm is one answer to this problem. The topic of key management, such as key generation and distribution, is covered in more detail in the next section. For now, let’s only focus on the mathematical function that could be used to solve these problems.

The goal of DH is that each peer deduces the same secret number following the exchange of some values, in cleartext. That secret number that both peers deduce could then be used as the symmetric encryption key.

The DH algorithm is the basis of most modern automatic key exchange methods. The Internet Key Exchange (IKE) protocol in IPsec VPNs uses DH algorithms extensively to provide a reliable and trusted method for key exchange over untrusted channels.

Whitfield Diffie and Martin Hellman invented the DH algorithm in 1976. Its security stems from the difficulty of calculating the discrete logarithms of very large numbers. The DH algorithm, depicted in Figure 12-23, provides secure key exchange over unsecure channels and is frequently used in modern key management to provide keying material for other symmetric algorithms, such as DES, 3DES, and AES. Don’t be too intimidated by Figure 12-23 and the explanation that follows. Later we will demonstrate an example of DH and you’ll see it’s not too complicated.

Figure 12-23. Diffie-Hellman Key Exchange Algorithm

To start a DH exchange, the two parties must agree on two nonsecret numbers. The first number is g, the generator, and the second number is p, the modulus. These numbers can be made public and are usually chosen from a table of known values. g is usually a very small number, such as 2, 3, or 4, and p is a very large prime number.

Next, every party generates its own secret value. Then, based on g, p, and the secret value of each party, each party calculates its public value. The public value is computed according to the following formula:

Y = gx mod p

In this formula, x is the secret value of the entity, and Y is the public value of the entity.

After computing the public values, the two parties exchange their public values. Each party then exponentiates the received public value with its secret value to compute a common shared-secret value, represented by K and K’ in Figure 12-23. When the algorithm completes, both parties have the same shared secret, which they have computed from their secret value and the public value of the other party.

No one listening on the channel can compute the secret value, because only g, p, YA, and YB are known; at least one secret value is needed to calculate the shared secret. Unless attackers can compute the discrete algorithm of the preceding equation to recover XA or XB, they cannot obtain the shared secret.

The following steps describe a DH exchange:

Step 1. Alice and Bob agree on generator g and modulus p.

Step 2. Alice chooses a random large integer, XA, and sends Bob its public value, YA, where YA = gxA mod p.

Step 3. Bob chooses a random large integer, XB, and sends Alice his public value, YB, where YB = gxB mod p.

Step 4. Alice computes K = YBxA mod p.

Step 5. Bob computes K’ = YAxB mod p.

Step 6. Both K and K’ are the equal to gxAxB mod p.

Alice and Bob now have a shared secret (K = K’), and even if someone has listened on the untrusted channel, there is no way the listener could compute the secret from the captured information, assuming that computing a discrete logarithm of YA or YB is practically infeasible.


Note

RFC 2409 (http://www.ietf.org/rfc/rfc2409) and RFC 3526 (http://www.ietf.org/rfc/rfc3526) provide more details about the values of g and p.


Diffie-Hellman Example

As you just read, a modulus operation is at the heart of DH. In simple terms, a modulus gives you the remainder of a division when the result of that division is an integer; you don’t want a fraction here. Figure 12-24 shows a simple modulus operation.

Figure 12-24. Simple Modulus Calculation

So, let’s try a Diffie-Hellman together. Follow along with Figure 12-25.

Figure 12-25. Diffie-Hellman Example

Step 1. In cleartext, Alice and Bob agree on a generator and on a modulus. The generator is usually a small number. In our example, shown in Figure 12-25, the peers, Alice and Bob, agree that the generator will be 7. Typically, the modulus is a very large prime number. To keep our calculations simple, we are using a very small modulus number, 13.

Step 2. Alice and Bob independently come up with a random private value that they will keep secret. Alice randomly generates as Alice’s private value 3. Bob randomly generates as Bob’s private value 2.

Step 3. Alice and Bob proceed to derive their public value, using the generator and primer they agreed on in Step 1 and their own private value they generated in Step 2. Review Figure 12-24 to confirm the procedures of modulus calculations of Step 3. Through the modulus operation, Alice derives that her public value is 5 and Bob derives that his public value is 10.

Step 4. They proceed at sharing their public value with each other, in the clear. Thus, Alice hears that Bob’s public value is 10 and Bob hears that Alice’s public value is 5.

Step 5. They use their peer’s public value, their own private value, and the generator and the prime number of Step 1 to finally calculate a key of 12. The result in Step 5, though independently calculated, will be the same. This will be the shared key that will be used for symmetric encryption. In our example, the key is decimal 12, which is very small. It’s only 4 bits long. In real life, with AES as an example, the symmetric keys are 128, 192, or 256 bits long.

If you had sniffed the communication, what would you have learned? The generator (7), the prime number (13), Alice’s public value (3), and Bob’s public value (2). But you would not know the private values used by Alice and Bob, so it would be impossible for you to proceed with Step 5. DH hasn’t been broken yet.

The result of a DH calculation, which will be the same result on both peers, could be used as the encryption key for symmetric algorithms, such as when encrypting with DES, 3DES, or AES.

Additional information can be found at http://www.rsa.com/rsalabs/node.asp?id=2248. There is also a great and colorful explanation of Diffie-Hellman at http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange.

Cryptographic Processes in VPNs

In the previous pages, you learned about encryption algorithms such as AES, hashing algorithms such as SHA, and key management algorithms such as DH. The combination of symmetric algorithms, hashing functions, and key management algorithms is what comprises IPsec. In Chapter 14, you will see how all these pieces fit together.

Similarly, the SSL and TLS protocols support the use of a variety of different cryptographic algorithms, or ciphers, for use in operations. In Chapter 15, you will see in more detail how SSL and TLS work.

Different protocols support different cryptographic algorithms to accomplish these goals. The selection of the protocol is part of the design phase of VPN implementations, and is directly tied to the strength of the protocol itself, as well as the strength of the keys. The strength of the keys, as you know, is directly related to the key size.

The prevalent algorithms today are 160-bit hashes, provided by SHA-1, and 1024-bit DH keys, among others.

Federal Information Processing Standard (FIPS) 140-2 is the current version of the FIPS 140 publication that specifies requirements for cryptography modules in the United States. NIST issued the FIPS 140 series to uphold the standards that describe the U.S. federal government requirements that IT products should meet. The 2011 specification calls for the following cryptographic algorithms: encryption with AES-128, key generation with Diffie-Hellman 2048 bit, digital signature with RSA 2048 bit, and hashing with SHA 256-bit. These stricter requirements are an indication of the ever-evolving and dynamic nature of threats and acceptable levels of risk in information security. Note that FIPS 140-3 is currently available in its draft format.

Asymmetric Encryption: Digital Signatures

Asymmetric encryption algorithms accomplish two primary objectives: confidentiality and authentication. Asymmetric algorithms are slower than symmetric algorithms because they use more complex mathematics. Because asymmetric algorithms are slower, they are usually used as key exchange protocols and are rarely used for bulk encryption. The sections that follow cover the principles behind asymmetric encryption for digital signatures. Later in the chapter, we will also see how asymmetric encryption is used for PKI environments.

Asymmetric Encryption Overview

To provide the two main objectives of confidentiality and authentication, asymmetric algorithms are based on mathematical formulas that are considerably more complex than the formulas symmetric algorithms are based on. As a result, computation takes more time for asymmetric algorithms. Despite this slower computation trait, asymmetric algorithms are often used as key exchange protocols for symmetric algorithms, which have no inherent key exchange technology.

Also known as public-key encryption, asymmetric algorithms have two keys: a public key and a private key. Both keys are capable of the encryption process. However, the complementary matched key is required for decryption. For example, if a public key encrypts the data, the matching private key decrypts the data. The opposite is also true. If a private key encrypts the data, the corresponding public key decrypts the data.

Examples of public-key encryption algorithms are RSA, DSA, DH, ElGamal, and elliptic curve cryptography (ECC). The mathematical operations differ with each algorithm, but the algorithms all share one trait: the mathematics are complicated.

Asymmetric algorithms are designed in such a way that the key that is used for encryption is different from the key that is used for decryption (Figure 12-16, shown earlier, illustrates the mechanics of asymmetric encryption). The decryption key cannot, in any reasonable amount of time, be calculated from the encryption key, and vice versa. The usual key length for asymmetric algorithms ranges from 512 to 4096 bits. Asymmetric algorithm key lengths cannot be directly compared to symmetric algorithm key lengths because the two algorithm families differ greatly in their underlying design.

To illustrate this point, it is generally thought that an encryption key of RSA that is 2048 bits is roughly equivalent to a 128-bit key of RC4 in terms of resistance against brute-force attacks.

Public Key Authentication

The authentication objective of asymmetric algorithms is achieved when the encryption process is started with the private key. When the private key is used to encrypt the data, the public key must be used to decrypt the data. Because only one host has the private key, only that host could have encrypted the message, therefore providing authentication of the sender.

Private key (encrypt) + Public key (decrypt) = Authentication.

Typically, no attempt is made to preserve the secrecy of the public key, so any number of hosts can decrypt the message. When a host successfully decrypts a message using a public key, it is trusted that the private key encrypted the message, which verifies who the sender is; this is a form of authentication.

In Figure 12-26, Alice and Bob exchange data with the goal of authentication. They follow these steps:

Step 1. Alice, using her private key, creates a digital signature and appends it to the message.

Step 2. Alice transmits the signed message to Bob.

Step 3. Bob acquires Alice’s public key.

Step 4. Bob uses Alice’s public key to verify the signature.

Figure 12-26. Asymmetric Authentication Process = Digital Signature

If Bob wishes to also sign a document, he will need to go through Steps 1 and 2 using his private key, and Alice will need to acquire Bob’s public key to check his signature. Therefore, the authentication is unidirectional. Each party is responsible for creating his or her own signature.


Safekeeping the Private Key

As you can imagine, the private key must be kept secret. As an example, in some organizations, the private key is kept on a USB thumb drive. When the owner of the private key wishes to use it, he inserts it into the USB port and is typically asked for the PIN to unlock the private key. Using a private key provides strong authentication. Strong authentication requires using two separate authentication methods. To unlock the private key, we are therefore using strong authentication: something you have (the USB thumb drive) and something you know (the PIN).



Caution

If the private key is compromised, another key pair must be generated to replace the compromised key.


RSA and Digital Signatures

RSA is one of the most common asymmetric algorithms. Ron Rivest (discussed earlier in this chapter), Adi Shamir, and Len Adleman invented the patented public-key RSA algorithm in 1977. The patent expired in September 2000, and the algorithm is now in the public domain. Of all the public-key algorithms that were proposed over the years, RSA is by far the easiest to understand and implement.

The RSA algorithm is very flexible because it has a variable key length that allows speed to be traded for the security of the algorithm if necessary.

The RSA keys are usually 512 to 2048 bits long. RSA has withstood years of extensive cryptanalysis, and although the security of RSA has been neither proved nor disproved, it does suggest a confidence level in the algorithm. The security of RSA is based on the difficulty of factoringvery large numbers, which means breaking large numbers into multiplicative factors. If an easy method of factoring these large numbers were discovered, the effectiveness of RSA would be destroyed.

The RSA algorithm is based on the fact that each entity has two keys: a public key and a private key. The public key can be published and given away, but the private key must be kept very secret. It is not possible to determine, using any computationally feasible algorithm, the private key from the public key, and vice versa. What one of the keys encrypts, the other key decrypts, and vice versa.

RSA keys are long term and are usually changed or renewed after some months or even years.

The current procedures for signing digital signatures are not simply implemented by public-key operations. In fact, a modern digital signature is based on a hash function and a public-key algorithm. Figure 12-27 illustrates this procedure.

Figure 12-27. RSA Digital Signatures

The signature process shown in Figure 12-27 is as follows:

Step 1. The signer (Alice) makes a hash, or fingerprint, of the document, which uniquely identifies the document and all of its contents.

Step 2. Alice encrypts the hash only with her private key.

Step 3. The encrypted hash, known as the signature, is appended to the document.

The verification process works as follows:

Step 1. The verifier (Bob) obtains Alice’s public key.

Step 2. Bob decrypts the signature using Alice’s public key. This step unveils the assumed hash value of the signer.

Step 3. Bob makes a hash of the received document, without its signature, and compares this hash to the decrypted signature hash. If the hashes match, the document is authentic; that is, it has been signed by Alice, and has not changed since it was signed.

This example illustrates how the authenticity and integrity of the message are ensured even though the actual text is public. Both encryption and digital signatures are required to ensure that the message is private and has not changed.


Note

The RSA algorithm is currently the most common method for signature generation and is used widely in e-commerce systems and Internet protocols in that role.


RSA is substantially slower than DES in both hardware and software implementations. This performance problem is the main reason that RSA is typically used only to protect small amounts of data. RSA is mainly used for two services:

• To ensure confidentiality of data by performing encryption

• To perform authentication of data, nonrepudiation of data, or both by generating digital signatures


Note

RSA encryption is faster than decryption, and verification is faster than signing.


Public Key Infrastructure

The example in the previous section of authentication using asymmetric encryption and digital signatures suffers from one critical drawback: scalability. If applied to two parties, such as the Bob and Alice example, you need two sets of private/public keys to authenticate the two parties. As the number of parties increases, and if you want to maintain authentication separate for each pair of entities, the number of private/public keys increases exponentially, and the number of validations to verify the signatures does as well.

For instance, if 10 individuals need to validate each other, 95 validations would need to be performed before everyone would have validated everyone else. Adding a single individual to the group would require an additional 20 validations because each of the original 10 individuals would need to authenticate the new individual, and the new individual would need to authenticate the original 10. This method does not scale well.

The impact is more tangible in real-life environments involving large organizations. In those scenarios, it is impractical for all parties to continually exchange identification documents. For example, Cisco goes to reasonable measures to identify employees and contractors, and then issues ID badges. The badge is relatively difficult to forge. Measures are in place to protect the integrity of the badge and the badge issuance. Because of these measures, all Cisco personnel accept this badge as authoritative as to the identity of any individual.

The badge scenario is an example of a trusted third-party protocol. This concept involves the use of a trusted introducer to all the parties trying to communicate. All individuals agree to accept the word of this neutral third party. In this way, parties that need to validate each other rely on the in-depth authentication of an agreed-upon third party instead of performing their own authentication. Presumably, the third party does an in-depth investigation before the issuance of credentials. After this in-depth investigation, the third-party issues credentials that are difficult to forge. From that point forward, all individuals who trust the third party simply accept the credentials that the third party issues.

Passports and driver’s licenses are real-life examples of a trusted third-party environment that uses the concept of a trusted introducer. Certificate authority (CA) servers are an example of this concept in PKI environments.


Note

Certificate servers are an example of a trusted third party.


In Figure 12-28, Alice applies to the license bureau for a driver’s license. In this process, she submits evidence of her identity and her qualifications to drive. Her application is approved and a license is issued.

Figure 12-28. Trusted Third Party Example

Later, Alice needs to cash a check at the bank. Upon presenting the check to the bank teller, the bank teller asks her for ID. Alice presents her driver’s license. The bank, because it trusts the government agency that issued the driver’s license, verifies her identity, and cashes her check.


Note

Certificate servers function like the license bureau in this example. The driver’s license is analogous to a certificate in a PKI or a technology that supports certificates.


A PKI provides a framework upon which you can base security services, such as encryption, authentication, and nonrepudiation. A PKI allows for very scalable solutions, and is becoming an extremely important authentication solution for VPNs. A PKI uses specific terminology to name its components.

PKI Terminology and Components

When these concepts are applied in practice, it is important to understand the supporting framework. A PKI is the service framework that is needed to support large-scale, public-key-based technologies. PKI is a set of technical, organizational, and legal components that are needed to establish a system that enables large-scale use of public-key cryptography to provide authenticity, confidentiality, integrity, and nonrepudiation services.

Three very important terms must be defined when talking about a PKI:

PKI: A service framework needed to support large-scale PK-based technologies

Certificate authority (CA): The trusted third party that signs the public keys of entities in a PKI-based system

Certificate: A document that in essence binds together the name of the entity and its public key and that has been signed by the CA


Note

The certificate of a user is always signed by a CA. Moreover, every CA has its own certificate, containing its public key, signed by itself. This is called a CA certificate, or more properly, a self-signed CA certificate, or more commonly, a root certificate.


A PKI is more than just a CA and its users. And implementing the enabling technology and building a large PKI involves a huge amount of organizational and legal work. There are five main areas of a PKI:

• CAs for key management

• PKI users, such as people, devices, servers, and so on

• Storage and protocols

• Supporting organizational framework, known as practices and user authentication using local registration authorities (LRA)

• Supporting legal framework

Many vendors offer CA servers as a managed service or as an end-user product:

• VeriSign

• Entrust Technologies

• RSA

• Cybertrust

• Microsoft

• Novell

Certificate Classes

CAs, especially outsourced ones, can issue certificates of a number of classes, which determine how trusted a certificate is. A single outsourcing vendor (for example, VeriSign) might run a single CA, issuing certificates of different classes, and its customers will use the CA they need depending on the desired level of trust.

A certificate class is usually a number; the higher the number, the more trusted the certificate is considered. The trust in the certificate is usually determined by how rigorous the procedure was that verified the identity of the holder when the certificate was issued. For example, a class 0 certificate might be issued without any checks, such as for testing purposes. A class 1 certificate might require an email reply from the future certificate holder to confirm his wish to enroll. This confirmation is a weak authentication of the holder. For a class 3 or 4 certificate, the future holder must prove his identity and authenticate his public key by showing up in person with at least two official ID documents.

Certificate Authorities

PKIs form different topologies of trust. In the simple model shown in Figure 12-29, a single CA, which is also known as the root CA, issues all the certificates to the end users. The benefit in such a setup is simplicity, but there are several pitfalls:

• It is difficult to scale this topology to a large environment.

• This topology needs a strictly centralized administration.

• There is a critical vulnerability in using a single-signing private key; if this key is stolen, the whole PKI falls apart because the CA can no longer be trusted as a unique signer.

Figure 12-29. PKI Topology Using a Single-Root CA

Because of its simplicity, VPNs that are managed by a single organization often use this topology.

Going beyond the single-root CA, topologies that are more complex can be devised that involve multiple CAs within the same organization. One such topology is the hierarchical CA system, shown in Figure 12-30. With the hierarchical topology, CAs can issue certificates to end users and to subordinate CAs, which in turn issue their certificates to end users, other CAs, or both. Therefore, a tree of CAs and end users is built in which every CA can issue certificates to lower-level CAs and end users.

Figure 12-30. PKI Topology Using Hierarchical CAs

The main benefits of a hierarchical PKI topology are increased scalability and manageability; trust decisions can now be hierarchically distributed to smaller branches. This distribution works well in most large organizations. For example, a large company may have a root CA that issues certificates to level-2 CAs. These level-2 CAs issue the certificates to the end users. Because the root-signing key is seldom used after the subordinate CA certificates are issued, it is less exposed and therefore much more trusted. Also, if a subordinate CA has its private key stolen, only a branch of the PKI is rendered untrusted. All other users can consider this by no longer trusting that particular CA.

One issue with hierarchical PKI topologies lies in finding the certification path for a certificate (in other words, determining the chain of the signing process). The more CAs involved in establishing the trust between the root CA and the end user, the more difficult the task.

Another approach to hierarchical PKIs is called cross-certifying, as shown in Figure 12-31. In this scenario, multiple flat single-root CAs establish trust relationships horizontally, by cross-certifying their own CA certificates.

Figure 12-31. PKI Topology Using Cross-Certifying CAs

Some PKIs might offer the possibility or even require the use of two key pairs per entity:

• One public and private key pair is intended only for encryption operations. The public key encrypts, and the private key decrypts.

• The other public and private key pair is intended only for signing operations. The private key signs, and the public key verifies the signature.

These keys are sometimes called “usage” or “special” keys. They may differ in key length and even in the choice of the public-key algorithm. If the PKI requires two key pairs per entity, a user has two certificates:

• An encryption certificate containing the public key of the user who encrypts the data

• A signature certificate containing the public key of the user who verifies the digital signature of the user

The following scenarios typically use usage keys:

• When encryption is used much more frequently than signing, a certain public and private key pair is more exposed due to its frequent usage. In this case, it might be a good idea to shorten its lifetime and change it more often, while having a separate signing private and public key pair with a longer lifetime.

• When different levels of encryption and digital signing are required, because of legal, export, or performance issues, usage keys allow you to assign different key lengths to the two pairs.

• When key recovery is desired (for example, a copy of a user’s private key is kept in a central repository for various backup reasons), usage keys allow you to back up only the private key of the encrypting pair; the signing private key remains with the user, enabling true nonrepudiation.

The CA, with its private key, is the security-critical component in a PKI system. To make the operation of a CA simpler, and therefore more secure, many key management tasks are often offloaded to registration authorities (RA). RAs are PKI servers that perform management tasks on behalf of the CA, so that the CA can focus on the signing process.

Usually, the following tasks are offloaded to the RA:

• Authentication of users when they enroll with the PKI

• Key generation for users who cannot generate their own keys

• Distribution of certificates after enrollment

PKI Standards

Standardization and interoperability of different PKI vendors are still issues when interconnecting PKIs. The X.509 standards and the Internet Engineering Task Force (IETF) Public-Key Infrastructure X.509 (PKIX) workgroup have made progress toward publishing a common set of standards for PKI protocols and data formats.

A PKI also uses a number of supporting services, such as Lightweight Directory Access Protocol (LDAP)-accessible X.500 directories.

Interoperability between a PKI and its supporting services is a concern because many vendors have proposed and implemented proprietary solutions instead of waiting for standards to develop. The state of interoperability can still be described as basic, even after 10 years of PKI software development.


Note

The IETF has formed a working group that is dedicated to promoting and standardizing PKI in the Internet. The working group has published a draft set of standards detailing common data formats and PKI-related protocols in a network. The goals and milestones of the PKI working group can be tracked at http://www.ietf.org/html.charters/pkix-charter.html.


The X.509 standard describes an identity and how to store an authentication key, more precisely defining basic PKI formats, such as certificate and certificate revocation list (CRL) formats, to enable basic interoperability. Abstract Syntax Notation One (ASN.1) provides information about the format of the X.509 certificate and the syntax of the fields in the certificate. The X.509 standard has been widely used for years with many Internet applications, such as SSL and IPsec.

The X.509 Version 3 (X.509v3) standard defines the format of a digital certificate. This format is already extensively used in the infrastructure of the Internet, in the following ways:

• Secure web servers use X.509v3 for website authentication in the SSL and TLS protocols.

• Web browsers use X.509v3 for services that implement client certificates in the SSL protocol.

• User mail agents that support mail protection using the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol use X.509.

• IPsec VPNs where certificates can be used as a public-key distribution mechanism for IKE RSA-based authentication use X.509.

Certificates are public information. They contain the binding between an entity’s names and public keys and are usually published in a centralized directory so that other PKI users can easily access them.

In the CA authentication procedure, the first step of the user, when contacting the PKI, is to securely obtain a copy of the public key of the CA. The public key of the CA verifies all the certificates issued by the CA and is vital for the proper operation of the PKI.

The public key of the CA is also distributed in the form of a certificate issued by the CA itself. This certificate is also called a self-signed certificate, because the signer and the holder are the same entity. Only a root CA issues self-signed certificates to itself.

Public-Key Cryptography Standards (PKCS) provide basic interoperability of applications, which use public-key cryptography. The PKCS define the low-level standardized formats for the secure exchange of arbitrary data, such as a standard format for an encrypted piece of data, a signed piece of data, and so on. The origin and purpose of PKCS are described on the RSA Laboratories website: “The Public-Key Cryptography Standards are specifications produced by RSA Laboratories in cooperation with secure systems developers worldwide for the purpose of accelerating the deployment of public-key cryptography.”

There are many defined PKCS standards:

PKCS #1: RSA Cryptography Standard

PKCS #3: Diffie-Hellman Key Agreement Standard

PKCS #5: Password-Based Cryptography Standard

PKCS #6: Extended-Certificate Syntax Standard

PKCS #7: Cryptographic Message Syntax Standard

PKCS #8: Private-Key Information Syntax Standard

PKCS #9: Selected Attribute Types

PKCS #10: Certification Request Syntax Standard

PKCS #11: Cryptographic Token Interface Standard

PKCS #12: Personal Information Exchange Syntax Standard

PKCS #13: Elliptic Curve Cryptography Standard

PKCS #15: Cryptographic Token Information Format Standard


Note

For more information about these standards, visit http://www.rsa.com/rsalabs/node.asp?id=2124.


Public-key technology is becoming more widely deployed and is becoming the basis for standards-based security, such as the IPsec and IKE protocols. With the use of public-key certificates in network security protocols comes the need for a certificate management protocol that PKI clients and CA servers can use to support certificate lifecycle operations, such as certificate enrollment and revocation, and certificate and CRL access. The goal of the Simple Certificate Enrollment Protocol (SCEP) is to support the secure issuance of certificates to network devices in a scalable manner, using existing technology wherever possible.

As shown in Figure 12-32, an end entity starts an enrollment transaction by creating a certificate signing request using PKCS#10. The PKCS#10 signing request is encapsulated in a PKCS#7 and sent to the CA or RA. PKCS#7 is a syntax standard for cryptographic messages. After the CA or RA receives the request, it either automatically approves the request and sends the certificate back, or it compels the end entity to wait until the operator can manually authenticate the identity of the requesting end entity.

Figure 12-32. Certificate Signing Request

Distinguished names (DN) provide a way to identify an entity by using multiple fields to provide hierarchical identification. DNs are used on a certificate in the Subject field.


Note

An example of a distinguished name used as the Subject Name field in an X.509 user certificate would appear as

CN=Harry Wales,OU=Sales,O=My Computer,L=My Company,L=Chicago,S=Ohio,C=US

where

• CN= commonName

• OU= organizationalUnitName

• O= Organization

• L= Locality (City)

• S= State

• C= US


The merging of the X.509 standard with public-key encryption allows the introduction of a trusted third party: the CA. The CA has a pair of asymmetric keys, a private key, and a public key. An X.509 certificate is created to identify the CA. The certificate of the CA contains the following information:

• The identity of the CA (for example, a subject containing the identity in the DN format)

• Other parameters (such as serial number, algorithms used, and validity period)

• The public key of the CA (for example, an RSA public key)

• The signature using the private key of the CA (for example, self-signing using the private key of the CA with RSA encryption and the SHA-1 hash algorithm)


Caution

The certificate is freely distributed. The receiver of the certificate should verify the authenticity of the certificate of the CA out-of-band.

Also, browsers such as Microsoft Internet Explorer come with certificates of large CAs, such as VeriSign, GoDaddy, and so on, already provisioned in the installation. That’s how our personal computers are able to established HTTPS sessions with banks and Internet retailers without having to install additional software.


In Figure 12-33, the following steps occur to retrieve the CA certificate:

Step 1. Alice and Bob request the CA certificate that contains the CA public key.

Step 2. Upon receipt of the CA certificate, Alice’s and Bob’s systems verify the validity of the certificate using public-key cryptography.

Step 3. Alice and Bob follow up the technical verification done by their systems by telephoning the CA administrator and verifying the public key and serial number of the certificate.

Figure 12-33. Retrieving a CA Certificate

After retrieving the CA certificate, Alice and Bob perform the following steps to submit certificate requests to the CA, as shown in Figure 12-34:

Step 1. Alice’s and Bob’s systems forward a certificate request that includes their public keys along with some identifying information. All of this information is encrypted using the public key of the CA.

Step 2. Upon receipt of the certificate requests, the CA administrator telephones Alice and Bob to confirm their submittals and the public keys.

Step 3. The CA administrator issues the certificate by adding some additional data to the certificate request, and digitally signing it all.

Step 4. Either the end user manually retrieves the certificate or SCEP automatically retrieves the certificate, and the certificate is installed onto the system.

Figure 12-34. Certificate Enrollment

Having installed certificates signed by the same CA, Bob and Alice are now ready to authenticate each other, as shown in Figure 12-35:

Step 1. Bob and Alice exchange certificates. The CA is no longer involved.

Step 2. Each party verifies the digital signature on the certificate by hashing the plaintext portion of the certificate, decrypting the digital signature using the CA public key, and comparing the results. If the results match, the certificate is verified as being signed by a trusted third party, and the verification by the CA that Bob is Bob and Alice is Alice is accepted.

Figure 12-35. Authentication Using Certificates

Certificate Revocation

Digital certificates can be revoked if keys are thought to be compromised, or if the business use of the certificate calls for revocation (for example, VPN access, network logon, and so on). If keys are thought to be compromised, generating new keys will force the creation of a new digital certificate, rendering the old certificate invalid and a candidate for revocation. On the other hand, a consultant could obtain a digital certificate for VPN access into the corporate network only for the duration of the contract.

Certificate revocation is also a centralized function, providing “push” and “pull” methods to obtain a list of revoked certificates frequently or on demand from a centralized entity. In some instances, the CA server often acts as the issuer of certificate revocation information, as shown inFigure 12-36.

Figure 12-36. Certificate Revocation Process

Several methods can be used for certificate revocation. The most prevalent today is the use of CRLs, but other methods such as Online Certificate Status Protocol (OCSP) overcome some of the limitations of CRLs and are often used. An alternative method is Cisco-proprietary and involves querying the AAA server to see if the user exists. If the user exists, the entity checking the validity of the certificate presumes that the certificate is good because the user is valid in the AAA server. Table 12-5 lists benefits and limitations of each method.

Table 12-5. Certificate Revocation Methods

Certificates were traditionally used at the application layer to provide strong authentication for applications. Each application may have a different implementation of the actual authentication process, but they all use a similar type of certificate in the X.509 format.

Certificate Use

SSL is probably the most widely used certificate-based authentication. SSL includes the negotiation of keys that are used to encrypt the SSL session. Many applications use SSL to provide authentication and encryption. The most widely used application is HTTPS. Other well-known applications that were using poor authentication and no encryption were modified to use SSL, such as Simple Mail Transfer Protocol (SMTP), LDAP, and Post Office Protocol version 3 (POP3).

Email has experienced many extensions. One of the important extensions was the introduction of Multipurpose Internet Mail Extensions (MIME), which allowed arbitrary data to be included in an email. Another extension was to provide security to entire mail messages or parts of mail messages. S/MIME authenticates and encrypts email messages.

Pretty Good Privacy (PGP) is an application that was originally developed by Phil Zimmerman, a privacy advocate, so that end users could engage in confidential communications using encryption. The most frequent use of PGP has been to secure email.

Certificates are also used at the network layer, or at the application layer, by network devices. Cisco routers, Cisco VPN concentrators, and Cisco ASA firewalls can use certificates to authenticate IPsec peers.

Cisco switches can use certificates to authenticate end devices connecting to LAN ports. Authentication uses IEEE 802.1X between the adjacent devices. The authentication can be proxied to a central access control server (ACS) via EAP-TLS.

Cisco routers can also provide Telnet 3270 support that does not include encryption or strong authentication. Cisco routers can now use SSL to establish Secure Telnet 3270 sessions.

Figure 12-37 illustrates a network where certificates are used for various purposes. A single CA server can facilitate many applications that require digital certificates for authentication purposes. Using CA servers is therefore a solution that simplifies the management of authentication and provides strong security due to the strength of cryptographic mechanisms that are used in combination with digital certificates.

Figure 12-37. Where We Find Certificates Being Used

Digital Certificates and CAs

Compared to other authentication mechanisms, a PKI has the following characteristics:

• To authenticate each other, users have to obtain the certificate of the CA and their own certificate. These steps require the out-of-band verification of the processes. After this verification is complete, the presence of the CA is no longer required until one of the certificates that is involved expires.

• Public-key systems use asymmetric keys where one is public and the other one is private. One of the features of these algorithms is that whatever is encrypted using one key can only be decrypted using the other key. This provides nonrepudiation.

• Key management is simplified because two users can freely exchange the certificates. The validity of the received certificates is verified using the public key of the CA, which the users have in their possession.

• Because of the strength of the algorithms involved, you can set a very long lifetime for the certificates, typically a lifetime measured in years.

The disadvantages of using trusted third parties relate to key management:

A user certificate is compromised (stolen private key): Other users should not accept compromised certificates. The only way to prevent the compromised certificates from being used is to keep a list of all revoked certificates. A server, not necessarily the CA server, must be accessible to users so that they can periodically download the latest CRL and use the list when authenticating other users. If the CRL lists the received certificate of the user, the authentication fails.

The certificate of the CA is compromised (stolen private key): This invalidates all certificates signed by the CA. A single CA environment requires the creation of a new CA certificate and the creation of new user certificates. A hierarchical CA environment requires the use of an authority revocation list (ARL), where all child certificates of the compromised CA become invalid if the ARL lists the CA.

The CA administrator: The human factor is an additional limitation of the CA-based solution. To lessen the impact, the CA administrator should follow strict rules when issuing certificates to users. A security policy should define the steps required to create certificates (for example, mandatory out-of-band verification of all initial enrollment procedures or verification steps for CA administrators before approving certificate requests).

When you use certificates in IP networks, you might need to combine public-key authentication with another authentication mechanism to increase the level of security and provide more authorization options. For example, IPsec using certificates for authentication and Extended Authentication (XAUTH) with one-time password hardware tokens would be a superior authentication scheme when compared to certificates alone. XAUTH is used for user authentication during IPsec remote access VPN, while the digital certificate is used typically for asset authentication (machine authentication).

Summary

The key points covered in this chapter are as follows:

• A cryptosystem is made up of a combination of hashing, symmetric, and asymmetric algorithms.

• Symmetric algorithms use a single key for encrypting and decrypting. Generally speaking, symmetric algorithms are the strongest and fastest algorithms and therefore are used for most encryption.

• Hashing algorithms use a one-way process designed to provide integrity. Usually, successful decryption of a digest provides proof of integrity and authenticity.

• Asymmetric algorithms use a key pair for the encrypting/decrypting process. One key encrypts, and the other key decrypts.

• RSA is a widely used algorithm for public-key cryptography.

• A PKI uses asymmetric encryption to provide confidentiality, integrity, and authentication services.

• PKI solutions are based on digital certificates and a trusted third party trust model.

• X.509v3, PKCS, and others provide standards for certificate formats and interoperability.

• CRL, OCSP, and AAA server certificate authorization are means to validate a certificate.

• The hierarchical trust model of PKI solutions includes CAs and RAs.

References

For additional information, refer to these resources.

Books and Articles

Giry, D. “Cryptographic Key Length Recommendation,” http://www.keylength.com/en/3/

Kahn, D. The Codebreakers: The Comprehensive History of Secret Communication from Ancient Times to the Internet (Scribner, 1996).

Kaliski, B. “TWIRL and RSA Key Size,” http://www.rsasecurity.com/rsalabs/node.asp?id=2004.

Singh, S. The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography (Knopf Publishing Group, 1999).

Standards

IETF. Public-Key Infrastructure (X.509) (pkix), http://tools.ietf.org/html/rfc5280

NIST. “Advanced Encryption Standard (AES)” (FIPS PUB 197), http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.

NIST. “Secure Hash Standard” (FIPS PUB 180-1), http://www.itl.nist.gov/fipspubs/fip180-1.htm.

RSA Laboratories. Public-Key Cryptography Standards (PKCS), http://www.rsa.com/rsalabs/node.asp?id=2124.

Wikipedia. “Diffie-Hellman,” http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange.

Encryption Regulations

U.S. Department of Commerce, http://www.commerce.gov.

“EAR Controls for Items That Use Encryption,” http://www.bis.doc.gov/encryption/default.htm.

Review Questions

Use the questions here to review what you learned in this chapter. The correct answers are found in the Appendix, “Answers to Chapter Review Questions.”

1. Which three business benefits are directly associated with VPNs?

a. Cost savings

b. Traffic segregation

c. Telemetry

d. Scalability

e. Productivity

2. Asymmetric encryption utilizes which of the following?

a. A complex solution to leverage certificates

b. Key pairs to accomplish encryption

c. All types of authentication as long as they support PKI procedures

d. A certificate authority that signs public keys in a network

3. Select all the desirable features of an encryption algorithm.

a. Resistance to known cryptanalytic attack

b. Short lengths and scalability of the key for easy storage

c. No export or import restrictions

d. Susceptible to the avalanche effect; a small change in plaintext causes substantial changes in ciphertext

4. A cipher suite is ______________.

a. The place of storage of cipher keys

b. A combination of cryptographic methods that work together

c. A chain of crypto keys

d. The prevalent set of algorithms at a given point in time

5. The selection of asymmetric encryption algorithms is based on a tradeoff between security and ______________.

a. Operational efficiency

b. Reliability

c. Performance

d. Key length

6. RC4 is a(n) ______________ encryption algorithm.

a. Asymmetric

b. Polyalphabetic

c. Elliptic curve

d. Symmetric

7. Which two options determine the strength of protection of modern cryptography algorithms?

a. Length of key

b. Mathematical complexity

c. Number of permutations

d. Level of trust toward the algorithm itself

e. Resistance to brute force attacks

8. Which combination does asymmetric encryption use in confidentiality scenarios?

a. The private key is used to encrypt and the public key is used to decrypt.

b. The public key is used to encrypt and the private key is used to decrypt.

c. A digital certificate is used to encrypt and the private key is used to decrypt.

d. The public key is used to encrypt and the corresponding digital certificate is used to decrypt.

9. Which of the following is not involved in RSA user authentication?

a. A hashing function

b. A public key

c. Digital signatures

d. A shared secret

10. Which of the following cipher categories transforms plaintext into ciphertext by operating bit by bit?

a. Transposition

b. Stream

c. Polyalphabetic

d. Block

11. DES operates in which two block cipher modes?

a. ECB

b. CFB

c. CBC

d. OFB

12. Which algorithm is used in AES?

a. Twofish

b. RC6

c. RC4

d. Rijndael

13. Which statement best describes MD5?

a. MD5 is a one-way function that makes it difficult to compute a hash from the given input data, but makes it feasible to compute input data given only a hash.

b. MD5 is a one-way function that makes it easy to compute a hash from the given output data, but makes it infeasible to compute input data given only a hash.

c. MD5 is a one-way function that makes it difficult to compute a hash from the given output data, but makes it feasible to compute input data given only a hash.

d. MD5 is a one-way function that makes it easy to compute a hash from the given input data, but makes it infeasible to compute the exact input data given only a hash.

14. Which of the following statements regarding public-key authentication is true?

a. When the private key is used to encrypt, the corresponding public key is used to decrypt.

b. Because the public key is present on only one system, authentication is assured when its private key decrypts the message.

c. Great effort is made to maintain the secrecy of the public keys.

d. Public-key scenario is used for producing fingerprint.

15. Which set of algorithms provides the most secure communication?

a. AES, SHA-1

b. 3DES, SHA-1

c. 3DES, MD5

d. AES, MD5

16. Which of the following statements best describes a digital signature?

a. A digital signature is a message digest encrypted with the sender’s public key.

b. A digital signature is a message digest encrypted with the receiver’s public key.

c. A digital signature is a message digest encrypted with the sender’s private key.

d. A digital signature is a message digest encrypted with the receiver’s public key.

17. Complete the sentence with the best statement: The Vigenère cipher is a(n) _______.

a. Polyalphabetic cipher

b. Polymorphic cipher

c. Polybius square cipher

d. Alphabetum cipher

18. Which of the following is not a term that is related to hierarchical CA topologies?

a. Certificate chain

b. Subordinate CAs

c. PKI

d. Single point of failure

19. Which protocol encrypts at the session layer of the OSI model?

a. IPsec

b. Enigma

c. SSL

d. MD5

20. Which statement is most accurate when describing aspects of a birthday attack?

a. An attacker tries every possible key with the decryption algorithm.

b. The attacker has the ciphertext of several messages, all of which have been encrypted using the same encryption algorithm.

c. If some function, when supplied with a random input, returns one of k equally likely values, then by repeating the function with different inputs, the same output would be expected after 1.2k½ number of times.

d. The attacker knows a portion of the plaintext and the corresponding ciphertext.

21. Which of the following terms identifies a standard that describes the structure of digital certificates?

a. PKCS#10

b. SCEP

c. X.509v3

d. RSA

22. Out-of-band authentication, in the context of certificate authorities, typically involves which of the following? (Choose two.)

a. Certificate request

b. Separate network

c. Digital signature

d. Public key

e. Serial number