Chapter 5. Fundamentals of Cryptography and Public Key Infrastructure (PKI)

This chapter covers the following topics:

• Cryptography

• Block and Stream Ciphers

• Symmetric and Asymmetric Algorithms

• Hashes

• Digital Signatures

• Next-Generation Encryption Protocols

• IPsec and SSL/TLS

• Fundamentals of PKI

• Root and Identity Certificates

• Revoking Digital Certificates

• Using Digital Certificates

This chapter discusses the fundamental components of cryptography, including algorithms for hashing, encryption, and key management, which may be used by virtual private networks, secure web connections, and many other applications.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 5-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

Table 5-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. Which of the following are examples of common methods used by ciphers? (Select all that apply.)

a. Transposition

b. Substitution

c. Polyalphabetic

d. Polynomial

2. Which of the following are examples of symmetric block cipher algorithms? (Select all that apply).

a. Advanced Encryption Standard (AES)

b. Triple Digital Encryption Standard (3DES)

c. DSA

d. Blowfish

e. ElGamal

3. Which of the following is a type of encryption algorithm that uses the same key to encrypt and decrypt data?

a. Symmetric

b. Asymmetric

c. PKI

d. Digital signatures

4. Which of the following are examples of hashing algorithms? (Select all that apply.)

a. DES

b. SHA-1

c. SHA-2

d. MD5

5. Which of the following are benefits of digital signatures? (Select all that apply.)

a. Authentication

b. Nonrepudiation

c. Masking

d. Encoding

6. Which of the following cryptographic protocols are considered next-generation protocols? (Select all that apply.)

a. AES-GCM mode

b. AES-CBC mode

c. SHA-512

d. SHA-2

7. Which of the following is a key management algorithm used in IPsec site-to-site and remote access VPN implementations?

a. Diffie-Hellman (DH)

b. AES

c. SHA

d. ESP

8. Which of the following statements about public and private key pairs are true? (Select all that apply.)

a. A key pair is a set of two keys that work in combination with each other as a team.

b. A key pair is a set of two keys that work in isolation.

c. If you use the public key to encrypt data using an asymmetric encryption algorithm, the corresponding private key is used to decrypt the data.

d. If you use the public key to encrypt data using an asymmetric encryption algorithm, the peer decrypts the data with that public key.

9. Which of the following entities can be found inside a digital certificate? (Select all that apply.)

a. Serial number

b. DNS server IP address

c. Default gateway

d. Public key

10. Which of the following is true about root certificates?

a. A root certificate contains information about the user.

b. A root certificate contains information about the network security device (such as a firewall or intrusion prevention system).

c. A root certificate contains the public key of the root certificate authority.

d. Root certificates never expire.

11. Which of the following are public key standards that specify the format and implementation of digital certificates? (Select all that apply.)

a. IPsec

b. PKCS #10

c. PKCS #12

d. ISO33012

e. AES

12. You are you using your web browser to connect to a web application that is using transport layer security (TLS) and digital certificates. It is very important that your web browser check the validity of the certificate and to make sure that it has not been revoked. Your browser (the client) simply sends a request to find the status of a certificate and gets a response without having to know the complete list of revoked certificates. What protocol is used by your browser to check whether the certificate has been revoked or is still valid?

a. AES

b. OCSP

c. PKCS#12

d. PKCS#10

13. Which of the following statements about subordinate certificate authorities is true?

a. For a client to verify the chain of authority, a client needs only the root certificate.

b. For a client to verify the chain of authority, a client needs only the subordinate CA’s certificate.

c. For a client to verify the chain of authority, a client needs both the subordinate CA’s certificate and the root certificate.

d. For a client to verify the chain of authority, a client needs the subordinate CA’s certificate, the CRL, the private key, and the root certificate.

14. What is a PKI topology or implementation where a CA has a horizontal trust relationship over to a second CA so that clients of either CA can trust the signatures of the other CA?

a. Cross-certifying CAs

b. CRL

c. OCSP

d. None of these answers are correct

Foundation Topics

Cryptography

The words cryptography and cryptology come from the Greek word kryptós, which means a secret. Cryptography is the study of the techniques used for encryption and secure communications. Cryptographers are the people who study and analyze cryptography. Cryptographers are always constructing and analyzing protocols for preventing unauthorized users from reading private messages as well as the following areas of information security:

• Data confidentiality

• Data integrity

• Authentication

• Nonrepudiation

Cryptography is a combination of disciplines, including mathematics and computer science. Examples of the use of cryptography include virtual private networks (VPNs), e-commerce, secure email transfer, and credit card chips. You may also often hear the term cryptanalysis, which is the study of how to crack encryption algorithms or their implementations.

Ciphers and Keys

Understanding the terminology is a large part of understanding any technology, so let’s begin with some fundamentals.

Ciphers

A cipher is a set of rules, which can also be called an algorithm, about how to perform encryption or decryption. Literally hundreds of encryption algorithms are available, and there are likely many more that are proprietary and used for special purposes, such as for governmental use and national security.

Common methods that ciphers use include the following:

• Substitution: This type of cipher substitutes one character for another.

• Polyalphabetic: This is similar to substitution, but instead of using a single alphabet, it can use multiple alphabets and switch between them by some trigger character in the encoded message.

• Transposition: This method uses many different options, including the rearrangement of letters. For example, if you have the message “This is secret,” you could write it out (top to bottom, left to right) as shown in Example 5-1.

Example 5-1 Transposition Example

T S S R
H I E E
I S C T

You then encrypt it as RETCSIHTSSEI, which involves starting at the top right and going around like a clock, spiraling inward. For someone to know how to encrypt or decrypt this correctly, the correct key is needed.

Keys

The key in Example 5-1 refers to the instructions for how to reassemble the characters. In this case, it begins at the top-right corner and moves clockwise and spirals inward.

A one-time pad (OTP) is a good example of a key that is used only once. Using this method, if you want to encrypt a 32-bit message, you use a 32-bit key, also called the pad, which is used one time only. Each bit from the pad is mathematically computed with a corresponding bit from the message, and the results are the cipher text, or encrypted content. The key in this case is the one-time use pad. The pad must also be known by the receiver if he or she wants to decrypt the message.

Key Management

Key management deals with the relationship between users and keys; it’s important to manage the generation, exchange, storage, and usage of those keys. It is crucial technically and organizationally because issues can present themselves due to poorly designed key systems and poor management. Keys must be chosen and stored securely. The generation of strong keys is probably the most important concept. Some algorithms have weak keys that make cryptanalysis easy. For example, Digital Encryption Standard (DES) uses a considerably weaker key than Advanced Encryption Standard (AES); the stronger the key, the stronger the key management.

You learn several methods for the exchange of keys later in this chapter, including encapsulating one key within another, using key indicators, and exchanging symmetric session keys with an asymmetric key algorithm—in effect, ciphering the cipher. Secure storage of keys often depends on users and passwords, or other authentication schemes. Proper storage of keys allows for availability, part of the CIA triad. Finally, keys should be replaced frequently. If a particular user uses a key for too long, it increases the chances of the key being cracked. Keys, like passwords, should be changed and/or recycled often (for example, every six months or every year).

Key management is huge in the world of cryptography. Symmetric keys can be used with symmetric algorithms for hashing and encryption. Asymmetric keys, such as public-private key pairs, can be used with asymmetric algorithms such as digital signatures, among other things. You could say that the key to security with all these algorithms described so far is the keys themselves.

Key management deals with generating keys, verifying keys, exchanging keys, storing keys, and, at the end of their lifetime, destroying keys. This is critical when two devices that want to establish a VPN session send their encryption keys over at the beginning of their session in plaintext. If that happens, an eavesdropper who sees the keys could use them to change ciphertext into understandable data, which would result in a lack of confidentiality within the VPN.

Keyspace refers to all the possible values for a key. The bigger the key, the more secure the algorithm will be. The only negative of having an extremely long key is that the longer the key, the more the CPU is used for the decryption and encryption of data.

Block and Stream Ciphers

Encryption algorithms can operate on blocks of data at a time, or bits and bytes of data, based on the type of cipher. Let’s compare the two methods.

Block Ciphers

A block cipher is a symmetric key cipher (meaning the same key is used to encrypt and decrypt) that operates on a group of bits called a block. A block cipher encryption algorithm may take a 64-bit block of plaintext and generate a 64-bit block of ciphertext. With this type of encryption, the key to encrypt is also used to decrypt. Examples of symmetric block cipher algorithms include the following:

• Advanced Encryption Standard (AES)

• Triple Digital Encryption Standard (3DES)

• Blowfish

• Digital Encryption Standard (DES)

• International Data Encryption Algorithm (IDEA)

Block ciphers may add padding in cases where there is not enough data to encrypt to make a full block size. This might result in a very small amount of wasted overhead because the small padding would be processed by the cipher along with the real data.

Stream Ciphers

A stream cipher is a symmetric key cipher (meaning the same key is used to encrypt and decrypt), where the plaintext data to be encrypted is done a bit at a time against the bits of the key stream, also called a cipher digit stream. The resulting output is a ciphertext stream. Because a cipher stream does not have to fit in a given block size, there may be slightly less overhead than with a block cipher that requires padding to complete a block size.

Symmetric and Asymmetric Algorithms

As you build your vocabulary, the words symmetric and asymmetric are important ones to differentiate. Let’s look at the options of each and identify which of these requires the most CPU overhead and which one is used for bulk data encryption.

Symmetric Algorithms

As mentioned previously, a symmetric encryption algorithm, also known as a symmetric cipher, uses the same key to encrypt the data and decrypt the data. Two devices connected via a virtual private network (VPN) both need the key (or keys) to successfully encrypt and decrypt the data protected using a symmetric encryption algorithm. Common examples of symmetric encryption algorithms include the following:

• DES

• 3DES

• AES

• IDEA

• RC2, RC4, RC5, RC6

• Blowfish

Symmetric encryption algorithms are used for most of the data protected in VPNs today because they are much faster to use and take less CPU than asymmetric algorithms. As with all encryption, the more difficult the key, the more difficult it is for someone who does not have the key to intercept and understand the data. Usually, you refer to keys with VPNs by their length. A longer key means better security. A typical key length is 112 bits to 256 bits. The minimum key length should be at least 128 bits for symmetric encryption algorithms to be considered fairly safe. Again, bigger is better.

Asymmetric Algorithms

An example of an asymmetric algorithm is a public key algorithm. There is something magical about asymmetric algorithms because instead of using the same key for encrypting and decrypting, they use two different keys that mathematically work together as a pair. Let’s call these keys the public key and the private key. Together they make a key pair. Let’s put these keys to use with an analogy.

Imagine a huge shipping container that has a special lock with two keyholes (one large keyhole and one smaller keyhole). With this magical shipping container, if you use the small keyhole with its respective key to lock the container, the only way to unlock it is to use the big keyhole with its larger key. Another option is to initially lock the container using the big key in the big keyhole, and then the only way to unlock it is to use the small key in the small keyhole. (I told you it was magic.) This analogy explains the interrelationship between the public key and its corresponding private key. (You can decide which one you want to call the big key and which one you want to call the little key.) There is a very high CPU cost when using key pairs to lock and unlock data. For that reason, you use asymmetric algorithms sparingly. Instead of using them to encrypt bulk data, you use asymmetric algorithms for things such as authenticating a VPN peer or generating keying material that you can use for symmetric algorithms. Both of these tasks are infrequent compared to encrypting all the user packets (which happens consistently).

With public key cryptography, one of the keys in the key pair is published and available to anyone who wants to use it (the public key). The other key in the key pair is the private key, which is known only to the device that owns the public-private key pair. A public-private key pair is used, for example, when visiting a secure website. In the background, the public-private key pair of the server is used for the security of the session. Your PC has access to the public key, and the server is the only one that knows its private key.

Here are some examples of asymmetric algorithms:

• RSA: This algorithm is named after Rivest, Shamir, and Adleman, who created it. The primary use of this asymmetric algorithm today is for authentication. It is also known as Public-Key Cryptography Standard (PKCS) #1. The key length may be from 512 to 2048, and a minimum size for good security is at least 1024. As long as the proper size keys are used, it is considered to be a secure protocol and is used in many e-commerce scenarios. It is slower than symmetric key algorithms but has advantages of being suitable for signing and for encryption. It works well with credit card security and TLS/SSL. Key lengths for RSA are much longer than in symmetric cryptosystems. Regarding security, the larger the key size, the better. For example, 512-bit RSA keys were proven to be breakable over a decade ago; however, 1024-bit keys are currently considered unbreakable by most known technologies, but RSA still recommends using the longer 2048-bit key, which should deter even the most powerful super hackers. It is important to note that asymmetric algorithm keys need to be much larger than their symmetric key counterparts to be as effective. For example, a 128-bit symmetric key is essentially equal to a 2304-bit asymmetric key in strength. The RSA algorithm uses what is known as integer factorization cryptography. It works by first multiplying two distinct prime numbers that cannot be factored. Then it moves on to some more advanced math to derive a set of two numbers. Finally, from these two numbers, it creates a private and public key pair.

• DH: The Diffie-Hellman key exchange protocol is an asymmetric algorithm that allows two devices to negotiate and establish shared secret keying material (keys) over an untrusted network. The interesting thing about DH is that although the algorithm itself is asymmetric, the keys generated by the exchange are symmetric keys that can then be used with symmetric algorithms such as 3DES and AES.

• ElGamal: This asymmetric encryption system is based on the DH exchange.

• DSA: The Digital Signature Algorithm was developed by the U.S. National Security Agency.

• ECC: Elliptic curve cryptography is a public-key cryptography based on the algebraic structure of elliptic curves over finite fields.

Asymmetric algorithms require more CPU processing power than symmetric algorithms. Asymmetric algorithms, however, are more secure. A typical key length used in asymmetric algorithms can be anywhere between 2048 and 4096. A key length that is shorter than 2048 is considered unreliable or not as secure as a longer key.

A commonly asymmetric algorithm used for authentication is RSA (as in RSA digital signatures).

Elliptic Curve

Elliptic curve cryptography (ECC) is a type of public key cryptography based on the structure of an elliptic curve. It uses logarithms calculated against a finite field and is based on the difficulty of certain mathematical problems. It uses smaller keys than most other encryption methods. Keys are created by graphing specific points on the curve, which were generated mathematically. All parties involved must agree on the elements that define the curve. This asymmetric algorithm has a compact design, leading to reduced computational power compared to other asymmetric algorithms, yet it creates keys that are difficult to crack.

Other algorithms have been adapted to work with elliptic curves, including Diffie-Hellman and the DSA. The Diffie-Hellman version (known as Elliptic Curve Diffie-Hellman, or ECDH) uses elliptic curve public-private key pairs to establish the secret key. Another variant, Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), runs in ephemeral mode, which makes sure that a compromised message won’t start a chain reaction and that other messages maintain their integrity. By its very design, the elliptic curve solves the problem of the extra computational power required by DHE. DSA is a U.S. federal government standard public key encryption algorithm used in digital signatures. The elliptic version is known as ECDSA. In general, the size of the public key in an elliptic curve–based algorithm can be 1/6 the size of the nonelliptic curve version. For example, ECDSA has a public key that is 160 bits, but regular DSA uses a public key that is 1024 bits. This is part of the reasoning behind the reduced amount of CPU power needed.

ECC is used with smart cards, wireless security, and other communications such as VoIP and IPsec (with DSA). It can be susceptible to side-channel attacks (SCAs), which are attacks based on leaked information gained from the physical implementation (number and type of curves) of the cryptosystem, and fault attacks (a type of SCA); plus there are concerns about backdoors into the algorithm’s random generator. Elliptic curve cryptography (as well as RSA and other algorithms) is also theoretically vulnerable to quantum cryptanalysis–based computing attacks.

Quantum Cryptography

The quantum computer (as of the writing of this book) is highly theoretical, but quantum encryption is more of a reality. More accurately known as quantum cryptography, it builds on quantum mechanics, and in particular, quantum communications.

In the standard digital encryption scenario, the key is established between two parties: one person encodes bits of information, and the other decodes them. Standard bits of information are used (1s and 0s). But in a quantum encryption scenario, the bits of the key can be encoded as quantum data (in which bits can exist in multiple states). This allows information to be encoded in such a way that would otherwise be impossible in classical digital encryption schemes.

Currently, quantum cryptography is a reality only in the form of quantum key distribution (QKD), which does have various protocols based on it. It commonly uses a fiber channel (fiber-optic matrix) to transmit quantum information, which can be very costly. In fact, the entire procedure is quite expensive and difficult to undertake, making it uncommon. But it is known to have flaws. Let’s remember one general rule about security: there is no perfect, utopian, secure solution. Given time, every encryption technique is exploited and its vulnerabilities are exposed. It would follow that quantum encryption is no exception.

More Encryption Types

There are a couple more encryption types to address. They don’t quite fit into the other sections. The first is the one-time pad, and the second is the Pretty Good Privacy (PGP) application and encryption method.

One-Time Pad

A one-time pad (also known as the Vernam cipher, named after the engineer Gilbert Vernam) is a stream cipher that encrypts plaintext with a secret random key that is the same length as the plaintext. It uses a string of bits that is generated at random (known as a keystream). Encryption is accomplished by combining the keystream with the plaintext message using the bitwise XOR operator to produce the ciphertext. Because the keystream is randomized, even an attacker with a plethora of computational resources on hand can only guess the plaintext if the attacker sees the ciphertext.

Unlike other encryption types, the one-time pad can be computed by hand with a pencil and paper (thus the word pad in the name), although today computers are used to create a one-time pad algorithm for use with technology. It has been proven as impossible to crack if used correctly and is known as being “information-theoretically secure”; it is the only cryptosystem with theoretically perfect secrecy. This means that it provides no information about the original message to a person trying to decrypt it illegitimately. However, issues with this type of encryption have stopped it from being widely used.

One of the issues with a one-time pad is that it requires perfect randomness. The problem with computer-based random number generators is that they usually aren’t truly random because high-quality random numbers are difficult to generate; instead, they are pseudorandom number generators (PRNGs), discussed later. Another issue is that the exchange of the one-time pad data must be equal to the length of the message. It also requires proper disposal, which is difficult due to data remanence.

Regardless of these issues, the one-time pad can be useful in scenarios in which two users in a secure environment are required to also communicate with each other from two other separate secure environments. The one-time pad is also used in superencryption (or multiple encryption), which is encrypting an already-encrypted message. In addition, it is commonly used in quantum cryptography, which uses quantum mechanics to guarantee secure communications. These last two concepts are far beyond the CyberOps Associate certification, but they show the actual purpose for this encryption type.

PGP

Pretty Good Privacy (PGP) is an encryption program used primarily for signing, encrypting, and decrypting emails in an attempt to increase the security of email communications. PGP uses (actually wrote) the encryption specifications as shown in the OpenPGP standard; other similar programs use this as well. Today, PGP has an entire suite of tools that can encrypt email, enable whole disk encryption, and encrypt zip files and instant messages. PGP uses a symmetric session key (also referred to as a preshared key, or PSK), and as such, you might hear PGP referred to as a program that uses symmetric encryption, but it also uses asymmetric RSA for digital signatures and for sending the session key. Because of this, it is known as a hybrid cryptosystem, combining the best of conventional systems and public key cryptography.

When encrypting data, PGP uses key sizes of at least 128 bits. Newer versions allow for RSA or DSA key sizes ranging from 512 bits to 2048 bits. The larger the key, the more secure the encryption is, but the longer it takes to generate the keys; however, keep in mind, this is done only once when establishing a connection with another user. The program uses a combination of hashing, data compression, symmetric key cryptography, and public key cryptography. New versions of the program are not fully compatible with older versions because the older versions cannot decrypt the data that was generated by a newer version. This is one of the issues when using PGP; users must be sure to work with the same version. Newer versions of PGP support OpenPGP and S/MIME, which allows for secure communications with just about everyone.

Because it works with RSA, the security of PGP is based on the key size. It is considered secure and uncrackable as long as a sufficient key size is used. As an example, 2048-bit keys are mostly used nowadays and should be safe against the strongest of well-funded adversaries with knowledgeable people; however, 3072-bit keys are recommended (as the strongest key alternative). You should avoid 1024-bit or lower key lengths, as they are considered weak implementations.

Around the turn of the millennium, the creator of PGP, and many other security-minded people that used PGP, sensed that an open-source alternative would be beneficial to the cryptographic community. This was presented to, and accepted by, the Internet Engineering Task Force (IETF), and a new standard called OpenPGP was developed. With this open-source code, others could write software that could easily integrate with PGP (or replace it). One example of this is the GNU Privacy Guard (GPG, or GNuPG), which is compliant with the OpenPGP standard. Over time this has been developed for several platforms including various Linux GUIs, macOS/Mac OS X, and Windows. GPG is a combination of symmetric key encryption and public key encryption.

Many businesses and individuals worldwide use PGP and its derivatives so that files can be easily encrypted before transit. The original PGP (developed by Philip Zimmerman) has changed hands several times and, as of this writing, is owned by Symantec, which offers it as part of its products (for a fee). Several versions of PGP, as well as GNuPG, are available for download for free. A good starting point is the following link: http://openpgp.org. There are several public PGP/GPG repositories such as MIT’s Public Key Server (https://pgp.mit.edu), Ubuntu’s Key Server (https://keyserver.ubuntu.com), Keybase (https://keybase.io), and many others. For example, you can obtain my public PGP/GPG key in Keybase at https://keybase.io/santosomar.

Pseudorandom Number Generators

Pseudorandom number generators (PRNGs) are used by cryptographic applications that require unpredictable output. They are primarily coded in C or Java and are developed within a cryptography application such as a key generator program. Within that program there is a specific utility—for example, SHA2PRNG—that is used to create the PRNG. (Remember to use SHA-256 or higher.) For additional “randomness,” a programmer will increase entropy, often by collecting system noise. One of the threats to PRNGs is the random number generator attack, which exploits weaknesses in the code. This can be prevented by implementing randomness, using AES, using newer versions of SHA, and maintaining physical control of the system where the PRNG is developed and stored.

Hashes

Hashing is a method used to verify data integrity. For example, you can verify the integrity of a downloaded software image file from Cisco and then verify its integrity using a tool such as the verify md5 command in a Cisco IOS or Cisco IOS-XE device or a checksum verification in an operating system such as Microsoft Windows, Linux, or macOS.

SHA-512 checksum (512 bits) output is represented by 128 characters in hex format, whereas Message Digest 5 (MD5) produces a 128-bit (16-byte) hash value, typically expressed in text format as a 32-digit hexadecimal number. Example 5-2 provides a comparison of the output of an SHA-512 checksum with an MD5 checksum for a Cisco ASA software image (asa941-smp-k8.bin).

Example 5-2 Hash Verification of a Cisco ASA Software Image

SHA512 checksum
1b6d41e893868aab9e06e78a9902b925227c82d8e31978ff2c412c18ac99f49f7035471544
1385e0b96e4bd3e861d18fb30433d52e12b15b501fa790f36d0ea0
MD5 checksum
6ddc5129d43a22490a3c42d93f058ffe

A cryptographic hash function is a process that takes a block of data and creates a small fixed-sized hash value. It is a one-way function, meaning that if two different computers take the same data and run the same hash function, they should get the same fixed-sized hash value (for example, a 12-bit long hash). MD5 algorithm is an example of a cryptographic hash function. It is not possible (at least not realistically) to generate the same hash from a different block of data. This is referred to as collision resistance. The result of the hash is a fixed-length small string of data, and is sometimes referred to as the digest, message digest, or simply the hash.

An example of using a hash to verify integrity is the sender running a hash algorithm on a packet and attaching that hash to it. The receiver runs the same hash against the packet and compares results against the results the sender had (which are attached to the packet as well). If the hash generated matches the hash that was sent, they know that the entire packet is intact. If a single bit of the hashed portion of the packet is modified, the hash calculated by the receiver will not match, and the receiver will know that the packet had a problem—specifically with the integrity of the packet.

Example 5-3 verifies the integrity of three files and compares the contents of each one. In Example 5-3, three files are shown (file_1.txt, file_2.txt, and file_3.txt). The shasum Linux command is used to display the hashes of all three files. Files file_1.txt and file_3.txt have exactly the same contents; that’s why you see the same SHA-512 hash.

Example 5-3 File Hash Verification

bash-3.2$ ls -l
-rw-r--r--  1 omar  staff   32 Dec  7 12:30 file_1.txt
-rw-r--r--  1 omar  staff  288 Dec  7 12:31 file_2.txt
-rw-r--r--  1 omar  staff   32 Dec  7 12:30 file_3.txt

bash-3.2$ shasum -a 512 *

815e1cbe6556ba31d448c3e30df3f1942d2f05a85ce2dd9512604bfbc9336fcb8ad0ea688597003b1806
cf98ce7699bd58c48576ccd1010451154afa37814114  file_1.txt
72ff6c32b9d2b0ff288382f8f07a8556fa16ccb3ef4672c612a1ec4a9a397b195b4ac993dca710dbebbd72b7f72da3364da444d7d64580f035db405109b6f6e1  file_2.txt
815e1cbe6556ba31d448c3e30df3f1942d2f05a85ce2dd9512604bfbc9336fcb8ad0ea688597003b1806
cf98ce7699bd58c48576ccd1010451154afa37814114  file_3.txt

Hashes are also used when security experts are analyzing, searching, and comparing malware. A hash of the piece of malware is typically exchanged instead of the actual file, to avoid infection and collateral damage. For example, Cisco Advanced Malware Protection (AMP) uses malware hashes in many of its different functions and capabilities.

The three most popular types of hashes are as follows:

• Message Digest 5 (MD5): This hash creates a 128-bit digest.

• Secure Hash Algorithm 1 (SHA-1): This hash creates a 160-bit digest.

• Secure Hash Algorithm 2 (SHA-2): Options include a digest between 224 bits and 512 bits.

With encryption and cryptography, and now hashing, bigger is better, and more bits equals better security. There are several vulnerabilities in the MD5 hashing protocol, including collision and pre-image vulnerabilities. Attackers use collision attacks to find two input strings of a hash function that produce the same hash result. The reason is that hash functions have infinite input length and a predefined output length. Subsequently, there is the possibility of two different inputs producing the same output hash.

There are also several vulnerabilities and attacks against SHA-1. Subsequently, it is recommended that SHA-2 with 512 bits be used when possible.

Cisco provides a great resource that explains the next-generation encryption protocols and hashing protocols at www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html.

Hashed Message Authentication Code

Hashed Message Authentication Code (HMAC) uses the mechanism of hashing but kicks it up a notch. Instead of using a hash that anyone can calculate, HMAC includes in its calculation a secret key of some type. Thus, only the other party who also knows the secret key and can calculate the resulting hash can correctly verify the hash. When this mechanism is used, an attacker who is eavesdropping and intercepting packets cannot inject or remove data from those packets without being noticed because that attacker cannot recalculate the correct hash for the modified packet because he or she does not have the key or keys used for the calculation.

Once again, MD5 is a hash function that is insecure and should be avoided. SHA-1 is a legacy algorithm and therefore is adequately secure. SHA-256 provides adequate protection for sensitive information. On the other hand, SHA-384 is required to protect classified information of higher importance.

Digital Signatures

Signing something often represents a commitment to follow through, or at least proves that you are who you say you are. In the world of cryptography, a digital signature provides three core benefits:

• Authentication

• Data integrity

• Nonrepudiation

Digital Signatures in Action

One of the best ways to understand how a digital signature operates is to remember what you learned in previous sections about public and private key pairs, hashing, and encryption. Digital signatures involve each of these elements.

In most security books, three fictional characters are used to explain encryption and PKI: Bob, Alice, and Eve. Bob and Alice typically are the two entities that exchange a secured message over a public or untrusted network, and Eve is the person who tries to “eavesdrop” and steal the information being exchanged. In this book, let’s make it more entertaining and use Batman, Robin, and the Joker. In Figure 5-1, all three entities are illustrated. Batman wants to send an encrypted message to Robin without the Joker being able to read it.

Figure 5-1 Fundamentals of Encrypted Communications

Batman and Robin are two people who want to establish a VPN connection to each other, and to do so they want to use digital signatures to verify each other to make sure they are talking to the right entity. This concept is illustrated in Figure 5-2.

Figure 5-2 Digital Signature Verification

Both Batman and Robin want to verify each other, but for simplicity let’s focus on one entity: Batman wanting to prove its identity to the other device, Robin. (This could also be phrased as Robin asking Batman to prove Batman’s identity.)

As a little setup beforehand, you should know that both Batman and Robin have generated public-private key pairs, and they both have been given digital certificates from a common certificate authority (CA). A CA is a trusted entity that hands out digital certificates. This concept is illustrated in Figure 5-3.

Figure 5-3 Digital Certificate Enrollment with a CA

In Figure 5-3, Batman requests a digital certification from (enrolls with) a CA, and the CA assigns one to Batman. If you were to open the digital certificate, you would find the name of the entity (in this case, Batman). You would also find Batman’s public key (which Batman gave to the CA when applying for the digital certificate). Figure 5-4 shows an example of a digital certificate. In this case, Cisco’s website (www.cisco.com) digital certificate is shown. Also, the digital signature of the CA is shown.

Figure 5-4 Digital Certificate Enrollment with a CA

Both Batman and Robin trust the CA and have received their certificates.

Batman takes a packet and generates a hash. Batman then takes this small hash and encrypts it using Batman’s private key. (Think of this as a shipping container, and Batman is using the small key in the small keyhole to lock the data.) Batman attaches this encrypted hash to the packet and sends it to Robin. The fancy name for this encrypted hash is digital signature.

When Robin receives this packet, it looks at the encrypted hash that was sent and decrypts it using Batman’s public key. (Think of this as a big keyhole and the big key being used to unlock the data.) Robin then sets the decrypted hash off to the side for one moment and runs the same hash algorithm on the packet it just received. If the hash Robin just calculated matches the hash just received (after Robin decrypted it using the sender’s public key), then Robin knows two things: that the only person who could have encrypted it was Batman with Batman’s private key, and that the data integrity on the packet is solid, because if one bit had been changed, the hashes would not have matched. This process is called authentication, using digital signatures, and it normally happens in both directions with an IPsec VPN tunnel if the peers are using digital signatures for authentication (referred to as rsa-signatures in the configuration).

At this point you might be wondering how Robin got Batman’s key (Batman’s public key) to begin with. The answer is that Batman and Robin also exchanged digital certificates that contained each other’s public keys. Batman and Robin do not trust just any certificates, but they do trust certificates that are digitally signed by a CA they trust. This also implies that to verify digital signatures from the CA, both Batman and Robin also need the CA’s public key. Most browsers and operating systems today have the built-in certificates and public keys for the mainstream CAs on the Internet. Figure 5-5 shows the System Roots keychain on Mac OS X.

Figure 5-5 Mac OS X System Roots

Next-Generation Encryption Protocols

The industry is always looking for new algorithms for encryption, authentication, digital signatures, and key exchange to meet escalating security and performance requirements. The U.S. government selected and recommended a set of cryptographic standards called Suite B because it provides a complete suite of algorithms designed to meet future security needs. Suite B has been approved for protecting classified information at both the secret and top-secret levels. Cisco participated in the development of some of these standards. The Suite B next-generation encryption (NGE) includes algorithms for authenticated encryption, digital signatures, key establishment, and cryptographic hashing, as listed here:

• Elliptic curve cryptography replaces RSA signatures with the ECDSA algorithm and replaces the DH key exchange with ECDH. ECDSA is an elliptic curve variant of the DSA algorithm, which has been a standard since 1994. The new key exchange uses DH with P-256 and P-384 curves.

• AES in the GaRobin/Counter Mode (GCM) of operation.

• ECC digital signature algorithm.

• SHA-256, SHA-384, and SHA-512.

IPsec and SSL/TLS

IPsec is a suite of protocols used to protect IP packets and has been around for decades. It is in use today for both remote-access VPNs and site-to-site VPNs. SSL/TLS is typically used for remote-access VPNs and for secure communications with web services. Let’s take a closer look at both of these widely implemented suites of protocols.

IPsec

IPsec is a collection of protocols and algorithms used to protect IP packets at Layer 3, hence the name IP Security (IPsec). IPsec provides the core benefits of confidentiality through encryption, data integrity through hashing and HMAC, and authentication using digital signatures or using a preshared key (PSK) that is just for the authentication, similar to a password. IPsec also provides anti-replay support. The following is a high-level explanation of IPsec components (protocols, algorithms, and so on):

• ESP and AH: These are the two primary methods for implementing IPsec. ESP stands for Encapsulating Security Payload, which can perform all the features of IPsec, and AH stands for Authentication Header, which can do many parts of the IPsec objectives, except for the important one (the encryption of the data). For that reason, AH is not used frequently.

• Encryption algorithms for confidentiality: DES, 3DES, and AES.

• Hashing algorithms for integrity: MD5 and SHA.

• Authentication algorithms: Preshared keys and RSA digital signatures.

• Key management: Examples of key management include Diffie-Hellman (DH), which can be used to dynamically generate symmetric keys to be used by symmetric algorithms; PKI, which supports the function of digital certificates issued by trusted CAs; and Internet Key Exchange (IKE), which does a lot of the negotiating and management needed for IPsec to operate.

Secure Sockets Layer and Transport Layer Security

Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are cryptographic protocols that provide secure Internet communications such as web browsing, instant messaging, email, and VoIP. These protocols rely on a PKI for obtaining and validating certificates.

Many people refer to the secure connections they make to websites as SSL, but actually some of these are TLS. The last version of SSL, version 3, was released in 1996. TLS is a more secure solution; version 1 of TLS supersedes SSLv3. As of the writing of this book, the latest version of TLS is 1.3. TLS and SSL work in much the same manner. Two types of keys are required when any two computers attempt to communicate with the SSL or TLS protocols: a public key and a session key. Asymmetric encryption is used to encrypt and share session keys, and symmetric encryption is used to encrypt the session data. Session keys used by protocols such as TLS are used only once; that is, a separate session key is utilized for every connection. A recovery key will be necessary if any data is lost in an SSL/TLS session. SSL and TLS encrypt segments of network connections that start at the transport layer of the OSI model. The actual encryption occurs at the session layer. In general, SSL and TLS are known as application layer protocols.

If a server running SSL/TLS requires additional processing, consider an SSL/TLS accelerator. This can be another computer, or more commonly, an add-on card that solely works on the CPU-intensive public-key encryption, namely the SSL/TLS handshake process. Your organization might have a policy stating that SSL/TLS-encrypted data needs to be decrypted when it reaches the internal network and then analyzed for malware and potential attacks. It is often then re-encrypted and sent to its final destination. This process is also very CPU intensive, and an SSL/TLS accelerator can provide the additional power required. SSL/TLS decryption and re-encryption can be a security risk and a privacy issue (especially for users bringing their own devices to the corporate network [BYOD users]). Careful consideration is required regarding where the decryption/re-encryption will take place, how it is implemented, and how people are notified about this policy.

HTTPS, which stands for Hypertext Transfer Protocol Secure, is a combination of HTTP and TLS. Web servers that enable HTTPS inbound connections must have inbound port 443 open (although web services using TLS can be configured in any TCP port). Numerous websites nowadays use HTTPS using TLS. If you connect to an online shopping portal such as Amazon, your credit card transactions should be protected by HTTPS, and you should see the protocol within the address bar of your browser when you enter a secure area of the website. If you connect to social network sites such as Facebook and Twitter, you should also see HTTPS/TLS used.

Email protocols can use SSL/TLS as well. For example, there is SSL/TLS-encrypted POP (which uses port 995), SSL/TLS SMTP (uses port 465), and SSL/TLS IMAP (uses port 993).

To use SSL, the user connects to an SSL server (that is, a web server that supports SSL) by using HTTPS rather than HTTP. To the end user, it represents a secure connection to the server, and to the correct server.

Even if the user does not type in HTTPS, the website can redirect him or her behind the scenes to the correct URL. Once there, the browser requests that the web server identify itself. (Be aware that everything that is about to happen is occurring in the background and does not require user intervention.) The server sends the browser a copy of its digital certificate, which may also be called an SSL certificate. When the browser receives the certificate, it checks whether it trusts the certificate. Using the method for verifying a digital signature discussed earlier, the browser determines whether the certificate is valid based on the signature of the CA. Assuming the certificate is trusted, the browser now has access to the server’s public key contained in the certificate.

Most of the time, the server does not require the browser to prove who it is. Instead, the web server uses some type of user authentication, such as a username and password, as required, to verify who the user is.

After the authentication has been done, several additional exchanges occur between the browser and the server as they establish the encryption algorithm they will use as well as the keys they will use to encrypt and decrypt the data. You learn more about that exact process later in this chapter in the section titled “Fundamentals of PKI.”

SSH

Secure Shell (SSH) is a protocol that can create a secure channel between two computers or network devices, enabling one computer or device to remotely control the other. Designed as a replacement for Telnet, it is commonly used on Linux and UNIX systems, and nowadays also has widespread use on Windows clients. It depends on public key cryptography to authenticate remote computers. One computer (the one to be controlled) runs the SSH daemon, while the other computer runs the SSH client and makes secure connections to the first computer (which is known as a server), as long as a certificate can be obtained and validated.

Computers that run the SSH daemon have inbound port 22 open. If a proper SSH connection is made, files can also be transferred securely using Secure File Transfer Protocol (SFTP) or Secure Copy Protocol (SCP). Tunneling is also supported.

As mentioned previously, understanding the terminology is important for you in mastering encryption and secure communication technologies. Figure 5-6 explains the key components and their functions as well as provides examples of their implementation.

Figure 5-6 Fundamental Encryption Components

Fundamentals of PKI

Public key infrastructure (PKI) is a set of identities, roles, policies, and actions for the creation, use, management, distribution, and revocation of digital certificates. The reason that PKI exists is to enable the secure electronic transfer of information for many different purposes. You probably know that using simple passwords is an inadequate authentication method. PKI provides a more rigorous method to confirm the identity of the parties involved in the communication and to validate the information being transferred.

PKI binds public keys with the identities of people, applications, and organizations. This “binding” is maintained by the issuance and management of digital certificates by a certificate authority.

Public and Private Key Pairs

A key pair is a set of two keys that work in combination with each other as a team. In a typical key pair, you have one public key and one private key. The public key may be shared with everyone, and the private key is not shared with anyone. For example, the private key for a web server is known only to that specific web server. If you use the public key to encrypt data using an asymmetric encryption algorithm, the corresponding private key is used to decrypt the data. The inverse is also true. If you encrypt with the private key, you then decrypt with the corresponding public key. Another name for this asymmetric encryption is public key cryptography or asymmetric key cryptography. The uses for asymmetric algorithms are not just limited to authentication, as in the case of digital signatures discussed in the previous sections, but that is one example of an asymmetric algorithm.

RSA Algorithm, the Keys, and Digital Certificates

Keys are the secrets that allow cryptography to provide confidentiality. Let’s take a closer look at the keys involved with RSA and how they are used.

With RSA digital signatures, each party has a public-private key pair because both parties intend on authenticating the other side. Going back to the analogy in the previous sections, let’s use two users named Batman and Robin. As you saw in Figures 5-2 and 5-3, they both generated their own public-private key pair, and they both enrolled with a certificate authority . That CA took each of their public keys as well as their names and IP addresses and created individual digital certificates, and the CA issued these certificates back to Batman and Robin, respectively. The CA also digitally signed each certificate.

When Batman and Robin want to authenticate each other, they send each other their digital certificates (or at least a copy of them). Upon receiving the other party’s digital certificate, they both verify the authenticity of the certificate by checking the signature of a CA they currently trust. (When you trust a certificate authority, it means that you know who the CA is and can verify that CA’s digital signature by knowing the public key of that CA.)

Now that Batman and Robin have each other’s public keys, they can authenticate each other. This normally happens inside of a VPN tunnel in both directions (when RSA signatures are used for authentication). For the purpose of clarity, we focus on just one of these parties (for example, the computer Batman) and proving its identity to the other computer (in this case, Robin).

Batman takes some data, generates a hash, and then encrypts the hash with Batman’s private key. (Note that the private key is not shared with anyone else—not even Batman’s closest friends have it.) This encrypted hash is inserted into the packet and sent to Robin. This encrypted hash is Batman’s digital signature.

Robin, having received the packet with the digital signature attached, first decodes or decrypts the encrypted hash using Batman’s public key. It then sets the decrypted hash to the side for a moment and runs a hash against the same data that Batman did previously. If the hash that Robin generates matches the decrypted hash, which was sent as a digital signature from Batman, then Robin has just authenticated Batman—because only Batman has the private key used for the creation of Batman’s digital signature.

Certificate Authorities

A certificate authority is a computer or entity that creates and issues digital certificates. Inside of a digital certificate is information about the identity of a device, such as its IP address, fully qualified domain name (FQDN), and the public key of that device. The CA takes requests from devices that supply all of that information (including the public key generated by the computer making the request) and generates a digital certificate, which the CA assigns a serial number to. The CA then signs the certificate with its own digital signature. Also included in the final certificate is a URL that other devices can check to see whether this certificate has been revoked and the certificate’s validity dates (the time window during which the certificate is considered valid). Also in the certificate is the information about the CA that issued the certificate and several other parameters used by PKI. This is illustrated in Figure 5-7, which shows the certificate for the website h4cker.org.

Figure 5-7 h4cker.org Certificate

In Figure 5-7, you can see the Certificate Practice Statement (CPS) URL and the Online Certificate Status Protocol (OCSP) URLs.

Now let’s go back to our scenario. Batman and Robin’s computers can receive and verify identity certificates from each other (and thousands of others) by using a third-party trusted certificate authority, as long as the certificates are signed by a CA that is trusted by Batman and Robin. Commercial CAs charge a fee to issue and maintain digital certificates. One benefit of using a commercial CA server to obtain digital certificates for your devices is that most web browsers maintain a list of the more common trusted public CA servers, and as a result anyone using a browser can verify the identity of your web server by default without having to modify their web browser at all. If a company wants to set up its own internal CA and then configure each of the end devices to trust the certificates issued by this internal CA, no commercial certificate authority is required, but the scope of that CA is limited to the company and its managed devices, because any devices outside of the company would not trust the company’s internal CA by default.

Root and Identity Certificates

A digital certificate can be thought of as an electronic document that identifies a device or person. It includes information such as the name of the person or organization, address, and public key of that person or device. There are different types of certificates, including root certificates (which identify the CA), and identity certificates, which identify devices such as servers and other devices that want to participate in PKI.

Root Certificate

A root certificate contains the public key of the CA server and the other details about the CA server. Figure 5-8 shows an example of one.

Figure 5-8 A Root Certificate Example

The output in Figure 5-8 can be seen on most browsers, although the location of the information might differ a bit depending on the browser vendor and version.

Here are the relevant parts of the certificate:

• Serial number: This is the number issued and tracked by the CA that issued the certificate.

• Issuer: This is the CA that issued this certificate. (Even root certificates need to have their certificates issued from someone, perhaps even themselves.)

• Validity dates: These dates indicate the time window during which the certificate is considered valid. If a local computer believes the date to be off by a few years, that same PC may consider the certificate invalid due to its own error about the time. Using the Network Time Protocol (NTP) is a good idea to avoid this problem.

• Subject of the certificate: This includes the organizational unit (OU), organization (O), country (C), and other details commonly found in an X.500 structured directory (more on that later in the chapter, in the “Public Key Cryptography Standards” section). The subject of the root certificate is the CA itself. The subject for a client’s identity certificate is the client.

• Public key: The contents of the public key and the length of the key are often both shown. After all, the public key is public.

• Thumbprint algorithm and thumbprint: This is the hash for the certificate. On a new root certificate, you could use a phone to call and ask for the hash value and compare it to the hash value you see on the certificate. If it matches, you have just performed out-of-band verification (using the telephone) of the digital certificate.

Identity Certificates

An identity certificate describes the client and contains the public key of an individual host (the client). Identity certificates are used by web servers, APIs, VPN clients, and web browsers (in some cases).

For instance, a web application using the TLS protocol for encryption over HTTPS is assigned an identity certificate. The certificate you see in your browser for that web application (or website) includes the public key for the server. Any device that wants to verify a digital signature must have the public key of the sender. Your browser verifies the CA’s signature on the digital certificate of the web application also using the public key of the root certificate authority (CA) that issued the certificate. In practice, this public key for the root CA is built in to most browsers.

X.500 and X.509v3

X.500 is a series of standards focused on directory services and how those directories are organized. Many popular network operating systems have been based on X.500, including Microsoft Active Directory. This X.500 structure is the foundation from which you see common directory elements such as CN=Batman (CN stands for common name), OU=engineering (OU stands for organizational unit), O=cisco.com (O stands for organization), and so on, all structured in an “org chart” way (that is, shaped like a pyramid). X.509 Version 3 is a standard for digital certificates that is widely accepted and incorporates many of the same directory and naming standards. A common protocol used to perform lookups from a directory is the Lightweight Directory Access Protocol (LDAP). A common use for this protocol is having a digital certificate that’s used for authentication, and then based on the details of that certificate (for example, OU=sales in the certificate itself), the user can be dynamically assigned the access rights associated with that group in Active Directory or some other LDAP-accessible database. The concept is to define the rights in one place and then leverage them over and over again. An example is setting up Active Directory for the network and then using that to control what access is provided to each user after he or she authenticates.

As a review, most digital certificates contain the following information:

• Serial number: The number assigned by the CA and used to uniquely identify the certificate

• Subject: The person or entity that is being identified

• Signature algorithm: The specific algorithm used for signing the digital certificate

• Signature: The digital signature from the certificate authority, which is used by devices that want to verify the authenticity of the certificate issued by that CA

• Issuer: The entity or CA that created and issued the digital certificate

• Valid from: The date the certificate became valid

• Valid to: The expiration date of the certificate

• Key usage: The functions for which the public key in the certificate may be used

• Public key: The public portion of the public and private key pair generated by the host whose certificate is being looked at

• Thumbprint algorithm: The hash algorithm used for data integrity

• Thumbprint: The actual hash

• Certificate revocation list location: The URL that can be checked to see whether the serial number of any certificates issued by the CA have been revoked

Authenticating and Enrolling with the CA

Using a new CA as a trusted entity, as well as requesting and receiving your own identity certificate from this CA, is really a two-step process, as demonstrated in Figure 5-9.

Figure 5-9 Authenticating and Enrolling with the CA

The following steps are illustrated in Figure 5-9:

Step 1. The first step is to authenticate the CA server (in other words, to trust the CA server). Unfortunately, if you do not have the public key for a CA server, you cannot verify the digital signature of that CA server. This is sort of like the chicken and the egg story because you need the public key, which can be found in the root’s CA certificate, but you cannot verify the signature on a certificate until you have the public key.

To start, you could download the root certificate and then use an out-of-band method, such as making a telephone call, to validate the root certificate. This can be done after downloading the root certificate and looking at the hash value by calling the administrators for the root CA and asking them to verbally tell you what the hash is. If the hash that they tell you over the phone matches the hash you see on the digital certificate (and assuming that you called the right phone number and talked with the right people), you know that the certificate is valid, and you can then use the public key contained in a certificate to verify future certificates signed by that CA.

Step 2. After you have authenticated the root CA and have a known-good root certificate for that CA, you can then request your own identity certificate. This involves generating a public-private key pair and including the public key portion in any requests for your own identity certificate. An identity certificate could be for a device or person. Once you make this request, the CA can take all of your information and generate an identity certificate for you, which includes your public key, and then send this certificate back to you. If this is done electronically, how do you verify the identity certificate you got is really from the CA server that you trust? The answer is simple, because the CA has not only issued the certificate but has also signed the certificate. Because you authenticated the CA server earlier and you have a copy of its digital certificate with its public key, you can now verify the digital signature it has put on your own identity certificate. If the signature from the CA is valid, you also know that your certificate is valid so you can install it and use it.

Public Key Cryptography Standards

Many standards are in use for the PKI. Many of them have Public-Key Cryptography Standards (PKCS) numbers. Some of these standards control the format and use of certificates, including requests to a CA for new certificates, the format for a file that is going to be the new identity certificate, and the file format and usage access for certificates. Having the standards in place helps with interoperability between different CA servers and many different CA clients.

Here are a few standards you should become familiar with; these include protocols by themselves and protocols used for working with digital certificates:

• PKCS #1: The RSA cryptography standard.

• PKCS #3: The Diffie-Hellman key exchange.

• PKCS #7: A format that can be used by a CA as a response to a PKCS #10 request. The response itself will very likely be the identity certificate (or certificates) that had been previously requested.

• PKCS #10: A format of a certificate request sent to a CA that wants to receive its identity certificate. This type of request would include the public key for the entity desiring a certificate.

• PKCS #12: A format for storing both public and private keys using a symmetric password-based key to “unlock” the data whenever the key needs to be used or accessed.

Simple Certificate Enrollment Protocol

The process of authenticating a CA server, generating a public-private key pair, requesting an identity certificate, and then verifying and implementing the identity certificate can take several steps. Cisco, in association with a few other vendors, developed the Simple Certificate Enrollment Protocol (SCEP), which can automate most of the process for requesting and installing an identity certificate. Although it is not an open standard, it is supported by most Cisco devices and makes getting and installing both root and identity certificates convenient.

Revoking Digital Certificates

If you decommission a device that has been assigned an identity certificate, or if the device assigned a digital certificate has been compromised and you believe that the private key information is no longer “private,” you could request from the CA that the previously issued certificate be revoked. This poses a unique problem. Normally, when two devices authenticate with each other, they do not need to contact a CA to verify the identity of the other party. The reason is that the two devices already have the public key of the CA and can validate the signature on a peer’s certificate without direct contact with the CA. So here’s the challenge: If a certificate has been revoked by the CA, and the peers are not checking with the CA each time they try to authenticate the peers, how does a peer know whether the certificate it just received has been revoked? The answer is simple: It has to check and see. A digital certificate contains information on where an updated list of revoked certificates can be obtained. This URL could point to the CA server itself or to some other publicly available resource on the Internet. The revoked certificates are listed based on the serial number of the certificates, and if a peer has been configured to check for revoked certificates, it adds this check before completing the authentication with a peer.

If a certificate revocation list (CRL) is checked, and the certificate from the peer is on that list, the authentication stops at that moment. The three basic ways to check whether certificates have been revoked are as follows, in order of popularity:

• Certificate revocation list (CRL): This is a list of certificates, based on their serial numbers, that had initially been issued by a CA but have since been revoked and as a result should not be trusted. A CRL could be very large, and the client would have to process the entire list to verify a particular certificate is not on the list. A CRL can be thought of as the naughty list. This is the primary protocol used for this purpose, compared to OSCP and AAA. A CRL can be accessed by several protocols, including LDAP and HTTP. A CRL can also be obtained via SCEP.

• Online Certificate Status Protocol (OCSP): This is an alternative to CRLs. Using this method, a client simply sends a request to find the status of a certificate and gets a response without having to know the complete list of revoked certificates.

• Authentication, Authorization, and Accounting (AAA): Cisco AAA services also provide support for validating digital certificates, including a check to see whether a certificate has been revoked. Because this is a proprietary solution, it is not often used in PKI.

Using Digital Certificates

Digital certificates aren’t just for breakfast anymore. They can be used for clients who want to authenticate a web server to verify they are connected to the correct server using HTTP Secure, Transport Layer Security, or Secure Sockets Layer. For the average user who does not have to write these protocols but simply benefits from using them, they are all effectively the same, which is HTTP combined with TLS/SSL for the security benefits. This means that digital certificates can be used when you do online banking from your PC to the bank’s website. It also means that if you use SSL technology for your remote-access VPNs, you can use digital certificates for authenticating the peers (at each end) of the VPN.

You can also use digital certificates with the protocol family of IPsec, which can also use digital certificates for the authentication portion.

In addition, digital certificates can be used with protocols such as 802.1X, which involves authentication at the edge of the network before allowing the user’s packets and frames to progress through it. An example is a wireless network, controlling access and requiring authentication, using digital certificates for the PCs/users, before allowing them in on the network.

PKI Topologies

There is no one-size-fits-all solution for PKI. In small networks, a single CA server may be enough, but in a network with 30,000 devices, a single server might not provide the availability and fault tolerance required. To address these issues, let’s investigate the options available for implementation of the PKI, using various topologies, including single and hierarchical. Let’s start with the single CA and expand from there.

Single Root CA

If you have one trusted CA, and you have tens of thousands of customers who want to authenticate that CA and request their own identity certificates, there might be too large of a demand on a single server, even though a single CA does not have to be directly involved in the day-to-day authentication that happens between peers. To offload some of the workload from a single server, you could publish CRLs on other servers. At the end of the day, it still makes sense to have at least some fault tolerance for your PKI, which means more than just a single root CA server.

Hierarchical CA with Subordinate CAs

One option for supporting fault tolerance and increased capacity is to use intermediate or subordinate CAs to assist the root CA. The root CA is the king of the hill. The root CA delegates the authority (to the subordinate CAs) to create and assign identity certificates to clients. This is called a hierarchical PKI topology. The root CA signs the digital certificates of its subordinate or intermediate CAs, and the subordinate CAs are the ones to issue certificates to clients. Figure 5-10 shows a hierarchical CA deployment with a root and three subordinate CAs.

Figure 5-10 Hierarchical CA Deployment with Subordinate CAs

For a client to verify the “chain” of authority, a client needs both the subordinate CA’s certificate and the root certificate. The root certificate (and its public key) is required to verify the digital signature of the subordinate CA, and the subordinate CA’s certificate (and its public key) is required to verify the signature of the subordinate CA. If there are multiple levels of subordinate CAs, a client needs the certificates of all the devices in the chain, from the root all the way to the CA that issued the client’s certificate.

Cross-Certifying CAs

Another approach to hierarchical PKIs is called cross-certification. With cross-certification, you would have a CA with a horizontal trust relationship over to a second CA so that clients of either CA can trust the signatures of the other CA.

Exam Preparation Tasks

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 5-2 lists a reference of these key topics and the page numbers on which each is found.

Table 5-2 Key Topics for Chapter 5

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

block ciphers

symmetric algorithms

asymmetric algorithms

hashing algorithms

digital certificates

certificate authority

AES

OCSP

Review Questions

The answers to these questions appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.” For more practice with exam format questions, use the exam engine on the website.

1. Which of the following files have the same contents based on their SHA checksum?
bash-3.2$ shasum *
b0f8ff8d3c376f802dd615e8a583d4df7306d02b cat.txt
88e513e9186d5f71453115ce8ae3c16057c827d8 chair.txt
b0f8ff8d3c376f802dd615e8a583d4df7306d02b chicken.txt
1f95e28fc1aaef50f1987237a73c8b5f1429d375 dog.txt
09bf76d43e9e04ab55884bf01740ea88fa15f4da table.txt

2. What is the problem of collision attacks?

3. Among MD5, SHA-1, and SHA-2, which is the most secure?

4. Certificate authorities can be deployed in a hierarchical way. Root CAs can delegate their authority to what type of CA to create and assign identity certificates to clients?

5. What is a certificate revocation list (CRL)?

6. What is a format for storing both public and private keys using a symmetric password-based key to “unlock” the data whenever the key needs to be used or accessed?

7. What is a format of a certificate request sent to a CA that wants to receive its identity certificate? This type of request would include the public key for the entity desiring a certificate.

8. What are examples of symmetric encryption algorithms?

9. Provide examples of asymmetric encryption algorithms.

10. Provide examples of hashing algorithms.