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. For instance, a simple substitution cipher can change a letter from the alphabet with another letter. To make it more challenging, we can shift more than just a single character and only chose certain letters to substitute. The exact method of substitution could be referred to as the “key.” If both parties involved in the encrypted communication channel understand the key, they can both encrypt and decrypt data. An example of substitution is shown in Figure 2-1.

  

• 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 Figure 2-2.

  

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 Figure 2-2 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.

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 might 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.

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 given algorithm ciphertext 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.

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.

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 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.

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 and 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 macOS.

SHA512 checksum (512 bits) output is represented by a 128-digit hexadecimal number, whereas MD5 produces a 128-bit (16-byte) hash value, typically expressed in text format as a 32-digit hexadecimal number.

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.

Let’s take a look at Example 2-1. In Example 2-1, the contents of three files (file1.txt, file2.txt, file3.txt) are shown using the cat Linux command. As you can see, the contents of file1.txt and file3.txt are the same. The contents of file2.txt is different from file1.txt and file3.txt.

Example 2-1 The Contents of file1.txt, file2.txt, and file3.txt

Click here to view code image

$cat file1.txt
The rabbit is fast.
The turtle is slow.
$cat file2.txt
This is file 2. File two. File dos...
$cat file3.txt
The rabbit is fast.
The turtle is slow.

In Example 2-2, the shasum Linux command is used to obtain the SHA checksum of each file and the md5sum Linux command is used to obtain the MD5 checksum of each file. As you can see, the checksums of files file1.txt and file3.txt are identical, since the contents of the files are the same (despite their different filenames).

Example 2-2 The SHA and MD5 Checksums

Click here to view code image

$shasum file1.txt file2.txt file3.txt
9a88d5f65e6136d351b20bc750038254c2ff6533 file1.txt
04aebe7d04587fad725588c1a8a49f7c7558252c file2.txt
9a88d5f65e6136d351b20bc750038254c2ff6533 file3.txt
$ md5sum file1.txt file2.txt file3.txt
738316215d0085ddb4c3ca4af2c928a1 file1.txt
3bb237acac848be493cdfb005d27c0f0 file2.txt
738316215d0085ddb4c3ca4af2c928a1 file3.txt

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). The 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.

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) use 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. Consequently, there is the possibility of two different inputs producing the same output hash.

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

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.

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, 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.

HMAC is a construction that uses a secret key and a hash function to provide a message authentication code (MAC) for a message. HMAC is used for integrity verification. HMAC-MD5, which uses MD5 as its hash function, is a legacy algorithm. MD5 as a hash function itself is not secure. It provides adequate security today, but its keys should be renewed relatively often. Alternatively, the NIST-recommended HMAC function is HMAC-SHA-1.

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

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 Thor, Ironman, and Thanos. In Figure 2-3, all three entities are illustrated. Thor wants to send an encrypted message to Ironman without Thanos being able to read it.

Thor and Ironman also want to verify each other to make sure they are talking to the right entity by using digital signatures. This process is illustrated in Figure 2-4.

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

As a little setup beforehand, you should know that both Thor and Ironman 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 2-5.

In Figure 2-5, Thor requests a digital certification from (enrolls with) a CA, and the CA assigns one to Thor. If you and I were to open the digital certificate, we would find the name of the entity (in this case, Thor). We would also find Thor’s public key (which Thor gave to the CA when applying for the digital certificate).

Both Thor and Ironman trust the CA and have received their certificates.

Let’s assume that now Thor and Ironman want to create a VPN tunnel. Thor takes a packet and generates a hash. Thor then takes this small hash and encrypts it using Thor’s private key. (Think of this as a shipping container, and Thor is using the small key in the small keyhole to lock the data.) Thor attaches this encrypted hash to the packet and sends it to Ironman. The fancy name for this encrypted hash is digital signature.

When Ironman receives this packet, it looks at the encrypted hash that was sent and decrypts it using Thor’s public key. (Think of this as a big keyhole and the big key being used to unlock the data.) Ironman 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 Ironman just calculated matches the hash just received (after Ironman decrypted it using the sender’s public key), then Ironman knows two things: that the only person who could have encrypted it was Thor with Thor’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 (sometimes this is referred to as rsa-signatures in the configuration).

At this point you might be wondering how Ironman got Thor’s key (Thor’s public key) to begin with. The answer is that Thor and Ironman also exchanged digital certificates that contained each other’s public keys. Thor and Ironman 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 Thor and Ironman 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 2-6 shows the “System Roots” keychain on macOS.

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 Galois/Counter Mode (GCM) of operation.

• ECC digital signature algorithm.

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

IPsec

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 use 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, 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, 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 and TLS

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.

TLS is the preferred method of encrypted communication. At the time of writing, TLS version 1.3 is the latest version of TLS. TLS version 1.3 is defined in RFC 8446 (https://tools.ietf.org/html/rfc8446).

TLS 1.3 provides several benefits and improvements in comparison to previous versions, such as separating key agreement and authentication algorithms from the cipher suites. TLS 1.3 also removes support for weak and less-used named elliptic curves. It also removes the use of MD5 and SHA-224 cryptographic hash functions.

The NIST Special Publication (SP) 800-52 Revision 2 (https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final) provides detailed guidance for the selection, configuration, and use of TLS implementations. It also provides the minimum requirements for TLS implementations. For instance, it dictates that the TLS server should be configured with one or more public-key certificates and the associated private keys. TLS server implementations should also use multiple server certificates with their associated private keys to support algorithm and key size agility. TLS servers must be deployed with certificates issued by a CA that publishes revocation information in Online Certificate Status Protocol (OCSP) responses. The certificate authority may also publish revocation information in a certificate revocation list (CRL). The CRL includes a list of the serial numbers of the certificates that have been revoked.

Even if the user does not type in HTTPS, the website can redirect the user 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.

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.

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

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.

Let’s take a look at another example. Thor and Ironman now want to send an encrypted email to each other using Pretty Good Privacy (PGP). In order for Thor to encrypt the email to Ironman, he needs Ironman’s public key. Ironman can just send the key to Thor or alternatively publish his public key to a public repository or server.

Once Thor encrypts and sends the message to Ironman, Ironman decrypts the message using his private key.

More About 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 the two users Thor and Ironman. 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 Thor and Ironman, respectively. The CA also digitally signed each certificate.

When Thor and Ironman 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 Thor and Ironman 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 Thor) and proving its identity to the other computer (in this case, Ironman).

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

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

Figure 2-8 shows an example of a digital certificate, which, in this case, is for the website ccnpsecurity.org. You also see the digital signature of the CA.

Now let’s go back to our scenario. Thor and Ironman’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 Thor and Ironman. 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 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.

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

The output in Figure 2-9 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. 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 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 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

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=Thor (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 2-10.

The following are the steps illustrated in Figure 2-10:

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 and therefore 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 #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 #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 #1: The RSA cryptography standard.

• 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.

• PKCS #3: Diffie-Hellman key exchange.

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. CRL 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.

Digital Certificates in Practice

Digital certificates 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.

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 2-11 shows a hierarchical CA deployment with a root and three subordinate CAs.

For a client to verify the “chain” of authority, the 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 root 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.