Chapter 6. Fundamentals of Cryptography and Public Key Infrastructure (PKI)
The learning objectives of this chapter are as follows:
Describe the uses of a hash algorithm
Explore the uses of encryption algorithms
Compare and contrast symmetric and asymmetric encryption algorithms
Describe the processes of digital signature creation and verification
Describe the operation of a PKI
Describe the security impact of the commonly used hash algorithms (SHA and MD5)
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 helps you identify your strengths and deficiencies in this chapter’s topics. The eight-question quiz, derived from the major sections in the “Foundation Topics” portion of the chapter, helps you determine how to spend your limited study time. You can find the answers in Appendix A Answers to the “Do I Know This Already?” Quizzes and Q&A Questions.
Table 6-1 outlines the major topics discussed in this chapter and the “Do I Know This Already?” quiz questions that correspond to those topics.
1. Which of the following are examples of common methods used by ciphers?
a. Transposition
b. Substitution
c. Polyalphabetic
d. Polynomial
2. Which of the following are examples of symmetric block cipher algorithms?
a. Advanced Encryption Standard (AES)
b. Triple Digital Encryption Standard (3DES)
c. DSA
d. Blowfish
e. ElGamal
3. Which of the following are examples of hashes?
a. ASH-160
b. SHA-1
c. SHA-2
d. MD5
4. Which of the following are benefits of digital signatures?
a. Authentication
b. Nonrepudiation
c. Encryption
d. Hashing
5. Which of the following statements are true about public and private key pairs?
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.
6. Which of the following entities can be found inside of a digital certificate?
a. FQDN
b. DNS server IP address
c. Default gateway
d. Public key
7. 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.
c. A root certificate contains the public key of the CA.
d. Root certificates never expire.
8. Which of the following are public key standards?
a. IPsec
b. PKCS #10
c. PKCS #12
d. ISO33012
e. AES
Cryptography
The word cryptography or cryptology comes from the Greek word kryptós, which means a secret. It 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), ecommerce, 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 we have the message “This is secret,” we could write it out (top to bottom, left to right) as shown in Example 6-1.
Example 6-1 Transposition Example
T S S R
H I E E
I S C T
We then encrypt it as RETCSIHTSSEI, which involves starting at the top right and going around like a clock, spiraling inward. In order for someone to know how to encrypt/decrypt this correctly, the correct key is needed.
Keys
The key in Example 6-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 only used once. Using this method, if we want to encrypt a 32-bit message, we 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 our message, and the results are our 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. (Another use of the acronym OTP is for a user’s one-time password, which is a different topic altogether.)
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 is 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 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 we protect 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. We usually 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 we 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. (I’ll let you 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, we use asymmetric algorithms sparingly. Instead of using them to encrypt our bulk data, we use asymmetric algorithms for things such as authenticating a VPN peer or generating keying material that we can use for our 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. An example of when a public-private key pair is used is visiting a secure website. In the background, the public-private key pair of the server is being 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: Named after Rivest, Shamir, and Adleman, who created the algorithm. 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. Regarding security, bigger is better.
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 Triple Digital Encryption Standard (3DES) and Advanced Encryption Standard (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).
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 device or a checksum verification in an operating system such as Microsoft Windows, Linux, or Mac OS X.
SHA512 checksum (512 bits) output is represented by 128 characters in hex format, whereas MD5 produces a 128-bit (16-byte) hash value, typically expressed in text format as a 32-digit hexadecimal number. Example 6-2 provides a comparison of the output of an SHA512 checksum with an MD5 checksum for a Cisco ASA software image (asa941-smp-k8.bin).
Example 6-2 Hash Verification of a Cisco ASA Software Image
SHA512 checksum
1b6d41e893868aab9e06e78a9902b925227c82d8e31978ff2c412c18ac99f49f7035471544
1385e0b96e4bd3e861d18fb30433d52e12b15b501fa790f36d0ea0
MD5 checksum
6ddc5129d43a22490a3c42d93f058ffe
NOTE
You can find a blog post explaining hash verification of Cisco software at http://blogs.cisco.com/security/sha512-checksums-for-all-cisco-software.
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). Message Digest 5 (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 his 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 6-3 is another example that verifies the integrity of three files, as well as compares the contents of each one. In Example 6-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 6-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
72ff6c32b9d2b0ff288382f8f07a8556fa16ccb3ef4672c612a1ec4a9a397b195b4ac993dca710d-
bebbd72b7f72da3364da444d7d64580f035db405109b6f6e1 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, in order 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 in order to find two input strings of a hash function that produce the same hash result. This is because 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.
TIP
During the last few years there has been a lot of discussion on quantum computers and their potential impact on current cryptography standards. This is an area of active research and growing interest. The industry is trying to label what are the post-quantum ready and next-generation cryptographic algorithms. AES-256, SHA-384, and SHA-512 are believed to have post-quantum security. Other public key algorithms are believed to also be resistant to post-quantum security attacks; however, not many standards support them.
Cisco provides a great resource that explains the next-generation encryption protocols and hashing protocols at http://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 it kicks it up a notch. Instead of using a hash that anyone can calculate, it 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 he cannot recalculate the correct hash for the modified packet because he 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
When you sign something, this 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 the 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 6-1, all three entities are illustrated. Batman wants to send an encrypted message to Robin without the Joker being able to read it.
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 6-2.
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 6-3.
In Figure 6-3, Batman requests a digital certification from (enrolls with) a CA, and the CA assigns one to Batman. If you and I were to open the digital certificate, we would find the name of the entity (in this case, Batman). We would also find Batman’s public key (which Batman gave to the CA when applying for the digital certificate). Figure 6-4 shows an example of a digital certificate. In this case, Cisco’s website (cisco.com) digital certificate is shown. Also, the digital signature of the CA is shown.
NOTE
You will learn more about CAs and the certificate enrollment process later in the “Certificate Authorities” section.
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 6-5 shows the “System Roots” keychain on Mac OS X.
Key Management
Key management is huge in the world of cryptography. We have symmetric keys that can be used with symmetric algorithms for hashing and encryption. We have asymmetric keys such as public-private key pairs that 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 we have taken a look at 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. An example of why this is critical is 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.
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 (ECC) 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
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 is the new kid on the block in its application with remote-access VPNs. Let’s take a closer look at both these options.
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 pre-shared 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, 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, we do not frequently see AH being used.
Encryption algorithms for confidentiality: DES, 3DES, and AES.
Hashing algorithms for integrity: MD5 and SHA.
Authentication algorithms: Pre-shared keys (PSKs) 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.
SSL
Information transmitted over a public network needs to be secured through encryption to prevent unauthorized access to that data. An example is online banking. Not only do you want to avoid an attacker seeing your username, password, and codes, you also do not want an attacker to be able to modify the packets in transit during a transaction with the bank. This would seem to be a perfect opportunity for IPsec to be used to encrypt the data and perform integrity checking and authentication of the server you are connected to. Although it is true that IPsec can do all this, not everyone has an IPsec client or software running on their computer. What’s more, not everyone has a digital certificate or a PSK they could successfully use for authentication.
You can still benefit from the concepts of encryption and authentication by using a different type of technology called Secure Sockets Layer (SSL). The convenient thing about SSL is that almost every web browser on every computer supports it, so almost anyone who has a computer can use it.
To use SSL, the user connects to an SSL server (that is, a web server that supports SSL) by using HTTPS rather than HTTP (the S in HTTPS stands for Secure). Depending on whom you talk to, SSL may also be called Transport Layer Security, or TLS. 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.
NOTE
If the signature is not valid, or at least if the browser does not think the certificate is valid, a pop-up is usually presented to the user asking whether he or she wants to proceed. This is where user training is important. Users should be trained never to accept a certificate that the browser does not trust.
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 in the next section, “Fundamentals of PKI.”
As mentioned previously, understanding the terminology is important for you in mastering encryption and VPN technologies. Figure 6-6 explains the key components and their functions as well as provides examples of their implementation.
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 (CA).
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 6-2 and 6-3, they both generated their own public-private key pair, and they both enrolled with a certificate authority (CA). 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 6-7, which shows the certificate for the website example.org.
Figure 6-7 Example.org Certificate
In Figure 6-7, you can see the CRL (certificate revocation list) Distribution Points URLs and other extensions such as the Certificate Authority Information Access and 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, their address, and the 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 6-8 shows an example of one.
The output in Figure 6-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: Issued and tracked by the CA that issued the certificate.
Issuer: The CA that issued this certificate. (Even root certificates need to have their certificates issued from someone, perhaps even themselves.)
Validity dates: 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 Certificate
An identity certificate is similar to a root certificate, but it describes the client and contains the public key of an individual host (the client). An example of a client is a web server that wants to support Secure Sockets Layer (SSL) or a router that wants to use digital signatures for authentication of a VPN tunnel.
Basically, any device that wants to verify a digital signature must have the public key of the sender. So, as an example, let’s say that you and I want to authenticate each other, and we both trust a common CA and have previously requested and received digital certificates (identity certificates) from the CA server. We exchange our identity certificates, which contain our public keys. We both verify the CA’s signature on the digital certificate we just received from each other using the public key of the CA. In practice, this public key for the CA is built in to most of the browsers today for public CA servers. Once we verify each other’s certificates, we can then trust the contents of those certificates (and most important, the public key). Now that you and I both have each other’s public key, we can use those public keys to verify each other’s digital signatures.
X.500 and X.509v3 Certificates
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: 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 6-9.
The following are the steps illustrated in Figure 6-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 get the ball rolling, 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. This process of getting the root CA certificate installed is often referred to as authenticating the CA . Current web browsers automate this process for well-known CAs.
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: Diffie-Hellman key exchange.
PKCS #7: This is 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: This 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.
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. This is because 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 (HTTPS), Transport Layer Security (TLS), or Secure Sockets Layer (SSL). 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 to us for implementation of the PKI, using various topologies, including single and hierarchical. Let’s start off 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 6-10 shows a hierarchical CA deployment with a root and three 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.
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 6-2 lists a reference of these key topics and the page numbers on which each is found.
Complete Tables and Lists from Memory
Print a copy of Appendix B, “Memory Tables,” (found on the book website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” also on the website, includes completed tables and lists to check your work.
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
Q&A
The answers to these questions appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Q&A 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
a. cat.txt, dog.txt, and table.txt
b. table.txt and chair.txt
c. chicken.txt and cat.txt
d. chicken.txt and dog.txt
2. Which of the following statements is true about collision attacks?
a. A collision attack is an attack against databases that causes a collision of data and results in data corruption.
b. A collision attack is a type of denial-of-service (DoS) attack.
c. Collision attacks are a form of web application attack that leverage the collision of data types and data models.
d. A collision attack is an attempt to find two input strings of a hash function that produce the same hash result.
3. Among MD5, SHA-1, and SHA-2, which is the most secure?
a. SHA-1.
b. SHA-2.
c. MD5.
d. They are all equally secure.
4. Certificate authorities can be deployed in a hierarchical way. Root CAs can delegate their authority to what type of CAs to create and assign identity certificates to clients?
a. Sub-root CAs
b. Subordinate CAs
c. Client CAs
d. Enrollment CAs
5. What is a certificate revocation list (CRL)?
a. A list of root certificates of CA servers that can revoke certificates.
b. A list of certificates, based on their serial numbers, that had initially been issued by a CA but have not been revoked and are trusted.
c. 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.
d. A list of serial numbers of CA servers that can participate in a certificate revocation process.
6. Which of the following 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?
a. PKCS #12
b. PKCS #10
c. PKCS #7
d. PKCS #2
7. Which of the following 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.
a. PKCS #1
b. PKCS #7
c. PKCS #10
d. PKCS #12
8. Which of the following are examples of symmetric encryption algorithms?
a. AES
b. IDEA
c. Diffie-Hellman
d. MD5
9. Which of the following are examples of asymmetric encryption algorithms?
a. AES
b. SHA
c. Diffie-Hellman
d. RSA
10. Which of the following are examples of hashing algorithms?
a. SHA
b. AES
c. MD5
d. RC4