ch 2 Mike Meyers CompTIA Security+ Certification Guide, Third Edition_nodrm.pdf

Chapter 2: Cryptography 78 Module 2-1: Cryptography Basics This module covers the following CompTIA Security+ objectives: r
2.1 Explain the importance of security concepts in an enterprise environment r
2.8 Summarize the basics of cryptographic concepts Cryptography provides methods and technologi...

Chapter 2: Cryptography 78 Module 2-1: Cryptography Basics This module covers the following CompTIA Security+ objectives: r
2.1 Explain the importance of security concepts in an enterprise environment r
2.8 Summarize the basics of cryptographic concepts Cryptography provides methods and technologies to enable people and systems to exchange information securely, from local connections to enterprise environments that span the globe. Cryptography ensures confidentiality—the encrypted data can be unencrypted and read only by the intended recipient. Cryptography also affords integrity, so the recipient can know that the data received matches the data sent—that the data hasn’t been altered in some way. To accomplish these tasks, developers and programmers have created immensely complicated and awesome systems…and those systems come with a ton of epic jargon and details. This module begins the exploration into the systems that make up modern cryptographic methods. It starts with basic building block concepts, such as plaintext and ciphertext. You’ll look at early cryptography to understand the methods with simple examples. The module finishes with an overview of the essential components of every cryptographic system. Essential Building Blocks Cryptography has terms that describe the state of data, tools used to affect that data, and the movement of data from one state to another. This section discusses these terms: r
Plaintext and ciphertext r
Code and cipher r
Data at rest, data in use, data in transit Plaintext and Ciphertext IT professionals use the terms plaintext and ciphertext to describe the current readability of data. Humans and machines can easily read plaintext. Ciphertext, on the other hand, is unreadable. The process of converting plaintext information into ciphertext information is called encryption. The goal of encryption is to obfuscate the plaintext—to make it unreadable, to look as though it were simply a random jumble of data. Essentially, encryption is about data protection. The reverse of encryption, converting ciphertext back into plaintext, is called decryption. Figure 2-1 shows the icons used here when discussing plaintext and ciphertext. NOTE Don’t mistake the “text” portion of the words plaintext and ciphertext to mean only letters of the alphabet. Any form of easily readable binary data is plaintext. Any form of encrypted binary data is ciphertext. Module 2-1: Cryptography Basics 79 Figure 2-1 Plaintext and ciphertext Plaintext Ciphertext Lorem ipsum dolor sit amet, conse ctetur adipiscing elit, sed do eius mod 12 46 5e 4e f0 5a fd c4 9f db 50 10 2b ff 26 08 c2 2a 9b ab a5 78 65 95 d1 14 9c 67 a9 47 39 db f8 d2 90 83 a6 Code and Cipher IT professionals use the terms code and cipher to describe generically the ways tools encrypt and decrypt. A code is a representation of an entire phrase or sentence, whereas a cipher tends to represent text on a character-by-character basis. For example, a coded version of the phrase “We attack at dawn” might be “Mother bought some brown eggs at the store.” Codes are not typically transformative; that is, there is usually no formal process to convert the true meanings of messages into their coded equivalents or back. Codes usually require a codebook, a predefined dictionary that translates codes to their plaintext messages and back. The need for a codebook limits the range of messages that can be sent and received via codes. Codes were common before computers, but are not at all common today in modern cryptography. Ciphers, on the other hand, use some form of formal, usually mathematical process to work instead of a fixed codebook. This makes the range of potential messages that can be sent using ciphers essentially unlimited, because these processes are usually done on the fly. Modern cryptographic methods with computers tend to use ciphers. You may sometimes hear the terms encode and decode (as well as encipher and decipher) thrown around. In encoding, data transforms, changes from one form to another. For example, you can encode a sound file from uncompressed WAV format into an MP3 file format. This saves space, but has nothing to do with security. In cryptography, encipher and encrypt mean the same thing, although the former is not in common use. Since IT security focuses on ciphers, this book sticks to the terms that apply to ciphers: encrypt and decrypt. NOTE Codes are entire words and phrases; ciphers are individual characters. The cryptography methods discussed in this book focus on ciphers. Data at Rest, Data in Use, and Data in Transit Dealing with cryptography for computer data depends on the location of the data and the actions of that data at any given moment. The process of encrypting and decrypting data sitting on a hard drive, for example, differs from the process of encrypting and Chapter 2: Cryptography 80 decrypting data moving wirelessly between a wireless access point and a wireless client. Three terms define the current state of data: r
Data at rest r
Data in use r
Data in transit Data at Rest Data at rest describes data that resides in storage. This data is not currently accessed, transmitted, or received, nor used by the computer. Data at rest is normally represented by data stored in static files on a hard drive or other storage media, when the device that holds that media is powered down. In other words, data on a laptop computer, powered down and sitting in Steve’s bag, is data at rest. NOTE Once Steve has logged into his computer at the airport lounge, the data on the laptop’s SSD could change at any time. So is it truly data at rest? Cybersecurity professionals argue this point a lot, and some call the data subject to change data at rest (inconstant). You won’t see that phrase on the CompTIA Security+ exam. Data in Use Data in use describes data currently in use by a computing device and not at rest or in transit. Data in a computer’s RAM and accessed by the computer’s CPU, operating system, and applications is data in use. Operating systems and applications take data at rest and put it into use on a constant basis, transforming it, using it as input to processes, and so on. A Microsoft Word document Susan is currently editing is an obvious example. Lots of techniques target data in use. Shoulder surfing—a social engineering technique where someone literally or figuratively looks over a user’s shoulder to view/record the contents on the screen—can grab data in use. A fairly simple USB keycatcher—easy to install when a user isn’t looking—can record or transmit via wireless everything the user types. Data in use is very much data in danger! EXAM TIP The CompTIA Security+ objectives use the term data in processing as an alternative label for data in use. Don’t be thrown off by the odd term. Data in Transit Data in transit describes data currently in transport. This data is being transmitted or received from one person or host to another. Examples of data in transit include information moving over a network, over an Internet connection, from computer to computer over an Ethernet connection, or even over wireless networks. The data is not in storage; it has been transformed and formatted to be transmitted and received. Data in transit has high requirements for confidentiality. It’s relatively easy for malicious actors to intercept transmitting data, so we need good encryption. Data in Module 2-1: Cryptography Basics 81 transit also has very high requirements for integrity. The recipient must have assurance that the data received is the same as the data sent. EXAM TIP The CompTIA Security+ objectives describe a key facet of data protection as dealing with data in transit/motion. The industry term used here, data in transit, means the same thing. Don’t get tripped up by the wording. Outstanding! The module has covered enough terms to enable a brief survey of the history of cryptography. Pay attention here, as almost everything done hundreds of years ago is still used today on modern computers. Early Cryptography People throughout the past few thousand years have used cryptography to protect personal secrets, military troop movements, diplomatic messages, and so on. Historians have discovered several examples of the uses of crude, but effective, cryptographic methods, such as the Spartan scytale, which was a baton or stick with a strip of parchment wound around it several times, from one end of the stick to the other (Figure 2-2). After the parchment was wrapped on the baton, a person wrote a message in plaintext. Once the parchment was removed from the stick, the words on the strip of parchment made no sense, since they were effectively encrypted. To “decrypt” the message, the receiver had to know the exact dimensions of the baton and have an identical one so that he could rewrap the parchment the same way around the baton and read the message. Figure 2-2 Author’s homemade scytale (Attack at dawn) Chapter 2: Cryptography 82 Other historical uses of cryptography involved using different techniques to scramble letters of the alphabet so that only the sender and recipient would know how to unscramble and read them. The next sections of the chapter discuss those methods. Still other, more modern ways of using cryptography involved the use of specially built machines to encrypt and decrypt messages. The classic example is the Enigma machine used by the Germans during World War II. This machine used encryption techniques that were considered unbreakable, until Dr. Alan Turing, a British mathematician, figured out how the machine worked and the methods it used to encrypt its information. Turing, now considered the father of modern cryptography and, to a large degree, computers, decrypted intercepted German messages. The capability of the British government to decrypt German military communications gave the Allies incredible insight into enemy troop movements, invasion plans, and so forth, effectively turning the tide of the war. Alan Turing didn’t invent cryptography, but many of the concepts used today were quantified by him in the huge number of academic papers Turing wrote. Turing clarified the ideas of substitution and transposition, the two pillars of cryptography. Substitution A substitution cipher swaps letters of the alphabet for other letters. To make a substitution cipher work, rotate the letters of the alphabet by some number of characters, then swap the letters that will substitute for them. A typical rotation shifts the alphabet 13 characters, called ROT13. Here’s the standard alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ And here’s the same alphabet with ROT13 applied: NOPQRSTUVWXYZABCDEFGHIJKLM Note that the letter N replaces letter A. Letter G replaces letter T. Line the two up so you can see the full replacement scheme: ABCDEFGHIJKLMNOPQRSTUVWXYZ NOPQRSTUVWXYZABCDEFGHIJKLM Now apply an example. The plaintext phrase, WE ATTACK AT DAWN, would change to JRNGGNPXNGQNJA in ROT13 encryption. NOTE ROT13 is not the only ROT cipher. You can do ROT2, ROT10, ROT25, and so on. This type of cipher is also called a shift cipher because it essentially shifts the entire alphabet down 13 spaces and then starts over with the first letter. Still other methods of using substitution ciphers might use different words to begin the substitution alphabet and then follow those words with the rest of the alphabet in normal order. Module 2-1: Cryptography Basics 83 NOTE Julius Caesar used a substitution cipher in his military campaigns for sensitive communications. Thus, a substitution cipher is commonly referred to as a Caesar cipher. A Vigenère cipher takes the Caesar cipher to its extreme. Figure 2-3 shows a tabula recta, a table of all 26 possible ROT ciphers that creates a grid. The Vigenère cipher uses a repeating key word to determine which row to use for encryption. Here’s how to use the tabula recta and key word to encrypt the plaintext. Find the plaintext letter at the top (column), then use the key word letter along the side (row). The matching column and row intersection provides the encrypted letter. An example will make this clear. Again our plaintext is WE ATTACK AT DAWN. And we’ll use a key word of MIKE (repeated here to match the text): WEATTACKATDAWN MIKEMIKEMIKEMI Figure 2-3 Vigenère cipher table, or tabula recta Chapter 2: Cryptography 84 Use the tabula recta to create the encrypted phrase. Here are the first five letters: W E A T T → → → → → M I K E M = = = = = I M K X F And so on... Note that the second “T” encrypts to a different letter than the first “T” because of the difference in the key word letter. Sweet! Here’s the fully encrypted phrase: IMKXFIMOMBNEIV If the recipient knows the key word, he or she can quickly decipher the code. Without the key word, deciphering becomes more difficult (and relies on repetition analysis and so forth). Vigenère ciphers were popular for centuries. Examples of substitution ciphers can be found in the standard word puzzle books you see on magazine racks in supermarkets and bookstores. In cryptography, confusion means that every character in a key is used to make the ciphertext more random looking. Adding a key to change the ROT value of every character adds confusion, making a Vigenère cipher much harder to crack than a ROT. Vigenère ciphers have a weakness. Encrypt the plaintext WE ATTACK AT NOON with the MIKE key, but each letter in the key only affects the plaintext character directly underneath it. A better encryption should act in such a way that even the smallest change in the key makes for very different ciphertext. This is called diffusion. The Vigenère cipher lacks diffusion. Modern codes do not! Transposition A transposition cipher transposes or changes the order of characters in a message using some predetermined method that both the sender and recipient know. The sender transposes the message and sends it. The recipient applies the same transposition method in reverse, decrypting the message. There are a variety of different transposition methods, including columnar, rail fence, and route ciphers. Current computer-based cryptography uses both substitution and transposition together in wildly complex ways. Cryptanalysis For as long as people have encrypted and decrypted data (or messages or whatever), others have tried to crack those messages. Cryptanalysis is the study of breaking encryption, the opposite of cryptography. You perform cryptanalysis on ciphertext data to reverse it to a plaintext state when you do not have access to the methods used to encrypt the data in the first place. Both security professionals and malicious actors perform cryptanalysis when attempting to decrypt ciphertext. There are hundreds, if not thousands, of methods for performing cryptanalysis, but many of them depend upon having a piece of plaintext that can be compared to its corresponding ciphertext, and vice versa, when you have some knowledge of the methods used to encrypt and decrypt the text. The next few modules discuss various methods of cryptanalysis. Module 2-1: Cryptography Basics 85 Cryptography Components Cryptography has several basic components that make the process work. These include algorithms, keys, XOR functions, shifts, rounds, and cryptosystems. While this module covers only the basics of these components, the remaining modules on cryptography discuss in depth how these different components work together. Algorithms and Keys Algorithms and keys work together to create cryptographic methods used to encrypt and decrypt messages. (They also can create cryptographic hash functions, used for digital signatures and more, a subject covered in depth in Module 2-5.) Algorithms are mathematical constructs that define how to transform plaintext into ciphertext, as well as how to reverse that process during decryption. An individual algorithm might be very simple or very complex. A very simple algorithm used in a substitution cipher, for example, only requires shifting a letter several spaces to the right. Almost all the real-world algorithms used in IT encryption/decryption are extraordinarily complex. A single algorithm will contain a dizzying number of mathematical manipulations. A key applies a variable used by the algorithm for the final cryptosystem (see the upcoming section “Cryptosystems”). In a ROT13 cryptosystem, ROT is the algorithm— to implement the encryption/decryption, shift letters of the alphabet. The 13 is the key or cryptovariable that defines how many letters to shift. Algorithms often don’t change. Keys change to keep bad actors guessing. Keys are kept secret. Keys are typically not simplistic numbers. They are often complex, lengthy strings of numbers or characters. A key might also be a password, passphrase, personal identification number (PIN), code word, and so on. Algorithms and keys are used to encrypt or decrypt text, as illustrated in Figure 2-4. Figure 2-4 Algorithms and keys Key Plaintext Algorithm Ciphertext Chapter 2: Cryptography 86 Algorithms are generally well known and tested, giving cryptographers and security professionals a level of confidence in their strength and ability to protect data. Kerckhoffs’ principle states that the algorithm should not be the secret part of the cryptographic process or method used; the key should be kept secret, not the algorithm. Most security professionals follow this principle. NOTE Dutch cryptographer Auguste Kerckhoffs developed Kerckhoffs’ principle in the late 19th century. This stuff has been around for a while! Key escrow grants knowledge or copies of keys to a third party. Businesses and other organizations use key escrow to store keys securely in the event that they are lost, they become corrupt, or an individual in the company with the only knowledge of the keys is terminated or quits. Key escrow provides an exception to Kerckhoffs’ principle. EXAM TIP An algorithm is a mathematical construct or rule that dictates how data will be encrypted and decrypted. Algorithms are generally well known and not kept secret. Secret algorithms are not needed. Keys are the variables that algorithms use to ensure secrecy and randomness in the cryptographic process. Keys should be kept secret. Key length or key size refers to the number of bits in a key; this number implies security—a hacker can readily break a short key, for example. With the unbelievable growth in computing power today, on the other hand, a long key doesn’t necessarily equate to better security. You’ll see various key lengths used in practical cryptography in Modules 2-3 and 2-4. The most secure keys would come from truly randomly generated numbers, numbers that no one could predict. Such a number would have an entropy value of 1, meaning full entropy or complete unpredictability. The reverse of this, with a completely deterministic system, would have an entropy value of 0. The ROT13 system discussed earlier, for example, with its predictable, fixed system, is such a deterministic system. Computers are not random, though, but very much predictable. Many will use software to generate pseudorandom numbers based on some mathematical system. Not surprisingly, the type of software used in cryptography is called a cryptographically secure pseudorandom number generator (CSPRNG), or simply cryptographic random number generator (CRNG). The factor to keep in mind here is that the keys come from some system and thus provide a place for threat actors to attack. We’ll see more of this in Module 2-8, “Cryptographic Attacks.” Block and Streaming Algorithms Algorithms have a wide variety of characteristics that include mathematical foundation, strength, and how they operate on plaintext. Modules 2-3 and 2-4 go into detail about specific algorithms used in cipher suites (groups of algorithms used to secure network connections), but for now, let’s discuss an important distinction within algorithms: block and streaming. Module 2-1: Cryptography Basics 87 Remember the distinction between codes and ciphers and how they work with entire phrases (codes) or on individual characters (ciphers)? The algorithms discussed in this book work on binary digits (bits) of plaintext, either individually or in specified groups. A block algorithm operates on a predefined size of a group of bits, known as a block. Different block algorithms use different block sizes, but typical sizes are 16-, 64-, and 128-bit blocks. Most of the algorithms discussed in this book are block algorithms. Streaming algorithms operate on individual bits, one bit at a time. Streaming algorithms don’t work on blocks of text; instead, they look at each individual bit and perform a mathematical operation on that bit and then move on to the next bit. Streaming algorithms tend to work much faster than block algorithms and are used in cryptographic methods that support fast communications requirements, such as wireless technologies. EXAM TIP Block algorithms work on predefined sizes of plaintext blocks, while streaming algorithms work on single bits of plaintext. CompTIA refers to streaming algorithms as stream algorithms. Streaming algorithms have a problem. Since they only encrypt one bit at a time, they need a piece of arbitrary value or string to get the encryption process started. This code, called an initialization vector (IV), provides the necessary randomness for the algorithms. There are also some interesting situations where IVs work in a block protocol as well. See “DES” in Module 2-3 for more. XOR Functions Computing devices use binary data. Hard drives store Word documents in binary format. YouTube videos stream to a browser in binary format. Caesar ciphers use alphabets, not bits, so they don’t readily apply to binary data. Computers need mathematical tools to encrypt, to transpose and substitute ones and zeros. The most commonly used binary math function used in cryptography is called eXclusive OR (XOR). XOR compares two bits to determine difference. With XOR, any bits that compare and are the same (two binary 0’s, for example) yield a resultant bit of false (and produce a 0-bit as the output). Any bits that compare and are different (a binary 1 and a binary 0) produce a true value, and an output bit of 1 is generated. Figure 2-5 illustrates this process. (If you’ve taken the CompTIA Network+ exam, then you know about XOR comparison from subnetting. The 1’s in the subnet mask compare to the IP address to differentiate the network ID from the host ID.) NOTE XOR results might seem a little weird at first. Keep in mind that XOR determines differences in compared data. A true result means that the compared data is not the same. A false result means the data is the same. Here’s an example of XOR in action, encrypting the randomly selected name, Mike, as the data: MIKE Chapter 2: Cryptography 88 Keystream Ciphertext XOR Plaintext Input Plaintext Keystream Value Text Value XOR’d Value 1 1 0 0 0 0 1 0 1 0 1 1 Figure 2-5 The XOR function in action As a first step, convert these four letters into binary. For this example, we’ll use ASCII code. ASCII converts every letter of the English alphabet in 8-bit binary values: M I K E = = = = 01001101 01001001 01001011 01000101 So, MIKE in binary is 01001101010010010100101101000101. This string of bits is the plaintext. The XOR function compares two binary values, right? To encrypt with XOR requires another value to compare with the plaintext. To XOR encrypt this binary data, therefore, we need a binary key. Let’s arbitrarily choose the ridiculously easy key of 0110. To encrypt, repeatedly place the key under the plaintext, as follows: 01001101010010010100101101000101 (plaintext) 01100110011001100110011001100110 (key repeated) Now go one bit at a time, using XOR to encrypt: 01001101010010010100101101000101 01100110011001100110011001100110 00101011001011110010110100100011 (ciphertext) Module 2-1: Cryptography Basics 89 Congrats! You’ve just done binary encryption, in this example using XOR. Want to decrypt the ciphertext? Just XOR it against the repeated key, as follows: 00101011001011110010110100100011 (ciphertext) 01100110011001100110011001100110 (key repeated) 01001101010010010100101101000101 (plaintext) Using XOR solely, especially with such a short key, creates an easily cracked ciphertext. Let’s make it harder by adding a shift. Shifts As the name implies, a shift in binary means moving the ciphertext left or right. Let’s shift the ciphertext four digits to the left. Here’s the initial ciphertext: 00101011001011110010110100100011 Now, take the first four binary values on the far left and move them to the end on the far right, as follows: 10110010111100101101001000110010 Adding a shift increases the complexity involved in decrypting. You need the key, plus knowledge of the shift. A simple shift makes better encryption, but a powerful computer can figure out this shifty trick in milliseconds! Let’s enhance the encryption by doing the whole XOR/leftshift multiple times. Rounds Repeating the XOR/left-shift iteration more than once—such as five times—makes the encryption harder to crack. It also means it will take longer to encrypt and decrypt, because every encryption and decryption must repeat the iteration five times. (That’s the price required for security.) Each of these XOR/left-shift iterations is called a round. Most modern algorithms use multiple rounds, repeating the process several times to ensure that the process is effective. Cryptosystems A cryptosystem includes everything in a cryptographic process, such as the algorithms, keys, functions, methods, and techniques. The example used here—the Mike Meyers Excellent Cryptosystem—includes four components: r
A four-bit key r
An XOR r
A four-digit left shift of the ciphertext r
The XOR/left-shift iteration repeated in five rounds Chapter 2: Cryptography 90 Cryptosystems use algorithms and keys as basic components to stir up the binary data and also implement them in ways that enable the encryption/decryption to be faster, more efficient, or stronger. Module 2-2: Cryptographic Methods This module covers the following CompTIA Security+ objectives: r
2.1 Explain the importance of security concepts in an enterprise environment r
2.8 Summarize the basics of cryptographic concepts You can differentiate cryptographic methods by the encryption method used, either symmetric or asymmetric. These two types of cryptography focus more on the aspect of the keys used than the algorithms, although each type has its own algorithms, as discussed in later modules. This module explores symmetric cryptography first, followed by asymmetric cryptography. The third section in the module describes a unique type of cryptography called hashing. The fourth section explores the relative limitations between symmetric and asymmetric cryptographic systems. The fifth section puts symmetric cryptographic systems, asymmetric cryptographic systems, and hashing together in hybrid cryptography. The final section discusses what makes a perfect cryptosystem. Symmetric Cryptography Symmetric cryptography uses a single key that both encrypts and decrypts data. All parties that require access to a piece of encrypted data know that key. If someone encrypts a file or sends a secure message to another person, both persons must have the key used to encrypt the data to decrypt it. NOTE The industry uses the terms “symmetric cryptography” and “symmetric-key cryptography” interchangeably. You’ll see that here and in a similar form with “asymmetric cryptography” used interchangeably with “asymmetric-key cryptography.” Symmetric keys are sometimes called secret keys or session keys. Session keys, more specifically, are created and used for a single communications session. They are not reused after the communications session ends. If the parties want to communicate again using symmetric cryptography, new session keys are generated by either party or by the cryptosystem in use. Figure 2-6 shows how two parties use symmetric keys to exchange sensitive data. EXAM TIP Symmetric key cryptography uses a single key that both encrypts and decrypts data. Module 2-2: Cryptographic Methods 91 Figure 2-6 Symmetric keys in use Symmetric Key Symmetric Key Plaintext Ciphertext Symmetric Algorithm Symmetric Algorithm Plaintext Symmetric key cryptography is both low latency (quick to respond) and good at handling large amounts of data, such as storage or transmission of large files. Symmetric keys require minimal computational overhead. Since only one key is involved, in communications limited to only two parties, symmetric key cryptography works great. Symmetric key cryptography has a couple of weaknesses in scaling and key exchange. First, when multiple parties require access to the same encrypted data (such as a group of friends or business associates), the exchange uses the same key. The more people who have the key, the greater the chances that it will get inadvertently disclosed to an unauthorized person. Second, getting the key into the hands of only the desired users presents challenges. Let’s look at an example of the scaling problem. User Meghan wants to communicate with user Amy. Both need only one secret key. Adding more users, such as Tim, Bobby, and Dawn, means each must have the same key to access the encrypted data. What if, however, Meghan wants only Amy to view a piece of data, and she doesn’t want Tim, Bobby, or Dawn to see it? Meghan must maintain separate symmetric keys for each party with whom she wants to communicate. Among a few people this scenario might be manageable. But imagine what happens if Meghan needs to maintain separate keys for 100 people? Meghan has a lot of keys! Worse yet, what if each of the 100 people required secure, unique communication with every other user? How many total keys must be generated? Chapter 2: Cryptography 92 Math comes to the rescue here. The total number of keys required is equal to the number of people in the group, multiplied by that same number less 1, and then divided by 2. Here’s the formula: K = N × (N – 1)/2 r
K is the total number of keys required. r
N is the number of people in the group. So: K = 100 × (100 – 1)/2 = 4950. As you can see, with 100 users, a lot of keys must be generated, issued, and exchanged among each pair of users in the group who must securely communicate. Symmetric key cryptography does not scale very well in larger groups or entities that must securely communicate with one another. Key exchange refers to the process used to exchange keys between users who send a message and those who receive it. Without the key, an authorized user or message recipient can’t decrypt the message; the message will simply remain as ciphertext. Since only one key is used in a symmetric communication, there must be a way to deliver the key securely to the right users, with an assurance that it won’t be intercepted and compromised. E-mail is usually not the most secure way, although sometimes people send their secret keys via an e-mail message. Manual methods offer a little more security, such as giving someone a key stored on a USB memory stick. Most of the time, especially in large organizations or when communicating with someone over greater distances, manual exchange isn’t practical. The problem with key exchange, therefore, is getting the key to someone using a means that is considered secure—so that the key will not be intercepted and used by an unauthorized person, rendering the entire process useless. Symmetric key cryptography has problems with secure key exchange. Key exchange has two terms to describe the exchange methods: r
In-band r
Out-of-band In-band key exchange involves using the same communications channel you are using to send the message to send the key. This may not be the most secure way, since that channel may be monitored by a malicious person. Out-of-band key exchange involves the use of a separate, independent channel, such as snail mail, USB stick, or even a different network connection, to send the key to the authorized users. In smaller groups of users that reside near each other, key exchange may not be much of a problem. In large organizations, however, in which users may be geographically separated, key exchange can be an issue, especially when using only symmetric key cryptography. EXAM TIP Symmetric key cryptography excels in speed, efficiency, and the ability to handle large amounts of data easily. The disadvantages primarily involve scalability and key exchange. Module 2-2: Cryptographic Methods 93 Asymmetric Cryptography Asymmetric cryptography uses two separate keys—a key pair—for secure communication. Data encrypted with one key requires the other key in the key pair for decryption. In public key cryptography—the primary asymmetric implementation—these keys are called a public key and a private key. Each user is issued or generates a key pair for his or her own use. The user gives the public key to anyone, even posting it on the Internet. The user keeps the private key, on the other hand, secret. With public key cryptography, what one key encrypts, only the other key can decrypt, and vice versa. If the key in the pair is used to encrypt a message, it cannot decrypt the same message. This makes the cryptography process, particularly sending and receiving confidential messages, different from the process used in symmetric key cryptography. EXAM TIP Public key cryptography uses two mathematically related keys in a pair, a public key and a private key. What one key encrypts, only the other key in the pair may decrypt, and vice versa. In current systems, the public key encrypts and the private key decrypts. (See Module 2-6 for the only use for reversing this process, validating a certificate by viewing the digital signature.) Jack and Jill want to communicate using public key cryptography. They need to follow specific steps. First, each must generate a unique key pair. Second, each user makes his or her public key readily available, such as posting it to the Internet. Jack acquires Jill’s public key, encrypts a message using that key, and sends it to Jill. Jill receives the message and decrypts it with her private key. Her private key is the only way to decrypt a message encrypted with her public key. For Jill to send a message to Jack securely, she reverses the process. She gets his public key and uses it to encrypt the message. Upon receipt, Jack decrypts the message using his private key. It’s an elegant system. Figures 2-7 and 2-8 demonstrate this process. Asymmetric key cryptography has several advantages over symmetric key cryptography, the major one being key exchange. The process eliminates key exchange issues, since no Private Keys Kept Secret Figure 2-7 Distribution of public and private keys Jill’s Private Key Jack’s Private Key Jack’s Public Key Public Keys Exchanged Jill’s Public Key Chapter 2: Cryptography 94 Figure 2-8 Using asymmetric key cryptography Jill’s Public Key Jack’s Public Key Jack’s Private Key Jill’s Private Key Jack Jill one really has to exchange a key. Anyone can acquire the public key. The sending party encrypts the message with the receiving person’s public key, and only the recipient who possesses the private key can decrypt it. Asymmetric key cryptography has a couple of disadvantages as well. First, it’s slower than symmetric key cryptography and more computationally intensive to generate keys. Second, it works well only with small amounts of data; it’s not suited for bulk data encryption or transmission. Module 2-7 will discuss the primary uses of asymmetric key cryptography, which involve public key infrastructure, or PKI, and uses of digital certificates and signatures. EXAM TIP Asymmetric key cryptography does great key exchange, but features slower speed compared to symmetric key cryptography and doesn’t handle large amounts of data very efficiently. Expect a question or two on the CompTIA Security+ exam that asks you to contrast symmetric vs. asymmetric encryption concepts and methods. Hashing Hashing provides integrity in the confidentiality, integrity, availability (CIA) triad of security by creating unique numbers for data and originators of information. Hashing helps verify that data came from a specific source and that the data did not change from what was sent. In the hashing process, variable-length text, such as a document or spreadsheet, or even a password, is exposed to a cryptographic algorithm that produces a cryptographic sum, or hash (also sometimes called a message digest), of the document. This hash is only a representation of the text; it is not the same thing as the text itself. Think of a hash as a unique fingerprint that identifies a very specific piece of plaintext. The piece of plaintext can be any length, and it generally does not matter how large the input plaintext is. The resulting hash will always be a fixed-length piece of ciphertext, usually expressed in a hexadecimal format. An example of a typical hash is shown in Figure 2-9. Module 2-2: Cryptographic Methods 95 Figure 2-9 A hash value computed for a file Unlike the encryption and decryption process, hashing was not designed to be reversible. In other words, you don’t simply encrypt text with a hashing function with the expectation of decrypting it later. Hashing is a one-way mathematical function whose sole purpose is to produce the cryptographic sum of the input plaintext. Think of the hashing process as sort of a measuring process for the data, with the resultant hash being the actual measurement itself. Although its purpose is not to decrypt text, the cryptographic sum produced by hashing has some uses. First, hashing is used to provide for integrity of data. A hash is unique to a particular piece of text. If one letter or word of the text is altered in any way, if even one binary digit changes, the resulting hash will differ from the original hash. Hashing assures the integrity of a piece of plaintext, since any changes would produce an easily detected different sum. Figure 2-10 shows the hashing process. Data transmitted over a network can be hashed before transmission and after reception, and the two resulting hashes can be compared. If the hashes match, you have unaltered data. If they differ, you can assume that the data has changed in some way during transmission. We’ll discuss hashing in more depth in Module 2-5, with specific examples of hashing methods. NOTE The term “message” generically refers to any piece of variable-length text, be it a password, text document, spreadsheet, picture file, or any other type of data. Figure 2-10 The hashing process Variable-Length Text Hashing Algorithm Fixed-Length Hash or Message Digest Chapter 2: Cryptography 96 Limitations in Symmetric vs. Asymmetric Cryptography You need to have clarity on the relative strengths and weaknesses of symmetric and asymmetric cryptography in concept before you delve into the next two modules, which layer on all the specific implementations of those systems. Limitations of systems include r
Speed r
Size r
Weak keys r
Time r
Longevity r
Predictability r
Reuse r
Entropy r
Computational overheads r
Resource vs. security constraints The module has discussed several of these limitations already, notably speed, size, weak keys, and computational overheads, noting that symmetric encryption is faster and has lower computational overhead than asymmetric encryption and that small-sized keys are weak keys. Size also relates to symmetric encryption handling larger files more efficiently than asymmetric encryption. The other limitations require a little more discussion. No encryption scheme is unbreakable. Developers instead strive to create an encryption scheme that provides strong enough security to make it too difficult—in terms of time and computational power needed—to crack. Because technology advances rapidly increase the computing power available to hackers, on the other hand, the relative security of any cryptosystem is a moving target. Folks at the National Institute of Standards and Technology (NIST) keep track of these things, rating the longevity of each active cryptosystem, as in how many years a cryptosystem remains secure in the current computing environment. We’ll save the details for the next couple of modules, but current cryptosystems are pretty awesome, and increasing the size of keys by just a single bit makes a cryptosystem twice as hard to crack. Modern cryptographic systems generate some kind of key to encrypt and decrypt messages, but those keys usher in limitations and vulnerabilities. We discussed the entropy level of pseudorandom numbers in the previous module, a measure of how predictable those numbers can be. The four characters in the Mike Meyers Excellent Cryptosystem, for example, have a very low entropy level, meaning a hacker could predict or guess them pretty quickly. Other cryptosystems might seem to have much tougher keys, such as 64-bit keys, but if 32 bits of the key have high predictability, the overall key is vulnerable to attack. There’s also the reuse factor for keys. An 8-bit key, for example, would generate numbers between 0 and 255, which means the numbers would quickly be reused, making the 8-bit key weak. In contrast, a one-time password that’s never reused? Almost uncrackable. Module 2-2: Cryptographic Methods 97 Finally, resource vs. security constraints boils down to the relationship between how much computing power goes into the system and the security of the system. Higher key lengths offer more security but require more computing power to deal with. A millioncharacter one-use key would be utterly secure, but to generate that every time a message gets encrypted/decrypted would kill modern systems. Every cryptosystem works on this balancing principle, defining an inherent limitation. Hybrid Cryptography Many modern implementations of cryptography combine symmetric key and asymmetric key functions with hashing to create a highly secure mashup generically called hybrid cryptography. Symmetric key cryptography handles large data well, but is weak at key exchange. Asymmetric does key exchange well, but encrypts/decrypts more slowly than symmetric. Both pretty much define confidentiality, but lack integrity. Hashing provides the missing integrity aspect. Here’s an example of hybrid key cryptography in action. A common method of key exchange involves the creation of a “secret” between the two parties. This secret is then run through a hash to create the one-and-only unique, cannot-be-reversed (supposedly) key to be used on the symmetric side. Encrypt and send this hash via your asymmetric system and voilà! You’ve securely exchanged a viable key for your symmetric side. Nothing is perfect, of course, and there are many variables—using certificates to identify each party, encryption streams within the exchange, and so on. But for the purposes of this discussion, just remember hybrid encryption means to use combinations of symmetric, asymmetric, and hashing to ensure better confidentiality and integrity. EXAM TIP Hybrid cryptography leverages the advantages of both symmetric and asymmetric key cryptography and eliminates their disadvantages. The Perfect Cryptosystem Cryptosystems should render unclear or unintelligible—obfuscate—any plaintext into what anyone who can’t decrypt would see as nothing more than random data. This obfuscation makes data secure. Security through obfuscation is what cryptography is all about! EXAM TIP Look for questions on the CompTIA Security+ exam that ask you to recognize common use cases of cryptography supporting obfuscation. You’ll see more use cases when we tackle specific cryptosystems in Modules 2-3 and 2-4. Proponents of security through obscurity argue that hiding how cryptosystems work hardens those systems. If you invent a great cryptosystem, full of interesting math using all kinds of substitutions, transpositions, and shifts over lots of rounds, and, in the implementation, count on the fact that no one else knows the algorithm, you have the perfect, uncrackable cryptosystem. Chapter 2: Cryptography 98 NOTE Many IT security professionals argue that making a target appear uninteresting adds a level of protection. This differently nuanced definition of security through obscurity applies to situations such as a bank versus a would-be robber. The robber might spend all of his time on the vault door, so storing vital stuff in a simple locked janitor closet would work. Security through obscurity misses one essential fact: every cryptosystem is crackable over time. What seems impossible today becomes child’s play with tomorrow’s technologies. Rather than hiding how cryptosystems work, modern cryptography makes algorithms public. Making the systems available for everyone to attack exposes vulnerabilities and weaknesses that can be addressed. Make the underlying algorithm unassailable, as Kerckhoffs suggested, but keep the specific key used secret. Because of this attitude, new, more resilient cryptosystems come out every few years. The creators of these cryptosystems happily send them out for academic rigor, making sure the code has high resiliency, that it holds up against cracking. Finally, that elusive perfect cryptosystem should hold up over time. In some cases, keys might be used for weeks, months, or even years perhaps. Forward secrecy means to protect a cryptosystem from one key giving away some secret that makes it easier to crack. If an algorithm achieves this, we call it perfect forward secrecy. There is no such thing as perfect forward secrecy other than using a key only once and throwing it away—a one-time pad. Module 2-3: Symmetric Cryptosystems This module covers the following CompTIA Security+ objective: r
2.8 Summarize the basics of cryptographic concepts Developers have created and deployed numerous symmetric key cryptosystems over the years to provide fast and secure data communications. This module explores the six most common symmetric cryptosystems. Some of the data here is historical, but all of it informs modern cryptosystems. Let’s look at these cryptosystems: r
DES r
3DES r
AES r
Blowfish r
Twofish r
RC4 DES The Data Encryption Standard (DES) is an older, now obsolete standard for commercialgrade encryption within the United States. DES uses an algorithm called Lucifer, developed by IBM. In the DES implementation, Lucifer has a 64-bit key size. Eight of those Module 2-3: Symmetric Cryptosystems 99 bits are used for computational overhead, so the true key size is only 56 bits. DES is a symmetric block algorithm and uses 64-bit block sizes. Blocks that are less than 64 bits in size are padded. EXAM TIP The CompTIA Security+ exam will quiz you on block sizes, so make notes throughout this module! DES works in modes of operation, defined methods that determine how a plaintext block is input and changed to produce ciphertext. Each of these modes processes input blocks of text in different ways to encrypt the data. Modes also use certain mathematical functions to transform the data for stronger encryption. DES uses 16 rounds for each mode. So, for whichever mode is used, that process is repeated 16 times on a block of plaintext to produce the output ciphertext. DES uses five different block cipher modes of operation: r
ECB r
CBC r
CFB r
OFB r
CTR In the electronic code book (ECB) mode, plaintext blocks of 64 bits are manipulated to produce ciphertext. With ECB mode, a given piece of plaintext will always produce the same corresponding piece of ciphertext. Unfortunately, this makes ECB mode very predictable, and it can easily be broken if an attacker has specific pieces of plaintext and ciphertext to compare. The cipher block chaining (CBC) mode produces much stronger encryption by XORing the previous block to the block being encrypted. The very first block introduces an initialization vector (IV) into the process. This ensures that every block of plaintext input into the process produces a uniquely different piece of ciphertext. So even when the same block of plaintext is input repeatedly, the resultant ciphertext will not be identical to any previous outputs. Cipher feedback (CFB) mode is like CBC except the plaintext is XORed into the IV after each round. Output feedback (OFB) mode is very similar to CFB mode, but instead of the previous block’s ciphertext being the next block’s IV, it takes the result of the previous encryption of the IV and key before the plaintext is XORed. In DES, counter (CTR) mode uses a random 64-bit block as the first IV, then increments a specified number or counter for every subsequent block of plaintext. CTR mode offers the best performance. Figure 2-11 illustrates how complex even the simple ECB mode is in DES; this screenshot was taken from the freely available open-source CrypTool cryptography learning program (www.cryptool.org). Chapter 2: Cryptography 100 Permuted input L2 R2 … … 2×32-bit … K R15 f Input block X Key K IP PC1 Permuted input PC2(K) 16 DES rounds 16 subkeys round 3–15 K L15 Overview 64-bit Pre-output K IP–1 L16 R16 R16 L16 Pre-output Output block Y 2×32-bit 64-bit – The permuted input is split in two halves called L0 and R0, each 32-bit wide. – For i =1,..., 16 (16 DES rounds) let Li = Ri–1 and Ri = Li–1 f (Ri–1, Ki) – Ki is the subkey index and means bitwise addition modulo 2 (also called) (XOR) – In this schematic round 3 to 15 are abbreviated, but they run just the same. Figure 2-11 Illustration of how DES ECB mode works (screenshot from the CrypTool cryptography learning program) EXAM TIP You need to know the different characteristics of DES for the exam—16 rounds of encryption, 64-bit blocks, 56-bit keys, and five cipher modes of operation. Authenticated Encryption The modes of operation used in symmetric cryptosystems can run in a couple of different ways, as unauthenticated or authenticated. The strength of the encryption doesn’t change either way, but unauthenticated modes offer a flaw when used in online applications. An attacker can use an attack called a chosen ciphertext attack to intercept, modify, and, eventually, decrypt messages. You can implement cryptosystems that fix this flaw in a couple of ways, but such implementations have traditionally been optional, presumably because the encryption standards were good enough and faster without the added layers of protections. The most common way today to secure modes of operation is to use authenticated encryption (AE) modes that both encrypt and authenticate messages. (See the description of GCM in the upcoming discussion of AES for a very commonly used AE mode.) Alternatively, you could use the more complicated message authentication code to add more protection. (See “HMAC” in Module 2-5 for more details.) Module 2-3: Symmetric Cryptosystems 101 EXAM TIP Look for questions on the Security+ exam that ask about unauthenticated vs. authenticated encryption modes of operation. Bottom line? Unauthenticated = bad. Authenticated = good. 3DES Triple DES (3DES or TDES) is a later iteration of DES designed to fix some of the problems found in DES. It basically puts plaintext blocks through the same type of DES encryption process, but it does so in three distinct iterations. Where DES uses single 56-bit keys, 3DES uses three 56-bit keys. Many IT folks—and the CompTIA Security+ exam—combine the three keys, so describe 3DES as having a 168-bit key. 3DES uses the same modes that DES uses; it just repeats them three times using three different keys. Other than the number of iterations, there are no differences between the two algorithms. This similarity causes 3DES to suffer from some of the same weaknesses as DES. These weaknesses motivated the industry to replace 3DES with more modern algorithms, particularly AES, discussed next. EXAM TIP 3DES made up for some of DES’s weaknesses, but it did not significantly change the algorithm. It puts plaintext through more iterations than DES, but it still suffers from some of the same weaknesses. AES The Advanced Encryption Standard (AES) is a symmetric block cipher that can use block sizes of 128 bits, with key sizes of 128, 192, and 256 bits. It uses 10 rounds for 128-bit keys, 12 rounds for 192-bit keys, and 14 rounds for 256-bit keys. Like DES, AES can use different modes to encrypt and decrypt data. Most attacks on AES are theoretical in nature—referred to as side-channel attacks, which take advantage of ineffective implementations of the AES algorithm in the cryptosystem, versus the algorithm itself. EXAM TIP AES is the de jure encryption standard for the US government and the de facto standard for private and commercial organizations. It is a block cipher that uses 128-bit block sizes, with 128-bit, 192-bit, and 256-bit keys. It uses 10, 12, and 14 rounds, respectively, for these keys. AES supports all the modes listed under DES, but tends to use the much lowerlatency mode called Galois/Counter Mode (GCM). GCM starts with CTR mode, but adds a special data type known as a Galois field to add integrity. GCM is an authenticated encryption mode of operation. NOTE You’ll sometimes hear AES called by its original name, Rijndael, derived from the last names of its two Belgian developers, Vincent Rijmen and Joan Daemen. Chapter 2: Cryptography 102 Blowfish Blowfish is a block cipher that accepts 64-bit blocks and has a wide range of variable key links, from 32 bits all the way up to 448 bits. It uses 16 rounds of encryption, just as DES does. It is widely implemented in different software encryption solutions and is considered a good choice for a strong encryption algorithm, since there have been no more effective complete cryptanalysis solutions published to date. The designer, Bruce Schneier, placed Blowfish in the public domain, free for all to use. Twofish Twofish is a symmetric block algorithm that uses a 128-bit block size. It can use 128-bit, 192-bit, or 256-bit keys. Like DES, it uses 16 rounds of encryption. It is viewed as a successor to Blowfish. Although there have been some published partial theoretical attacks against Twofish, there are currently no publicly known attacks against it. Like Blowfish, Twofish has been placed in the public domain, making it freely available for anyone to use. EXAM TIP Although AES is the official US standard, both Blowfish and Twofish are exceptionally good encryption algorithms. Both use 64-bit blocks, and both perform 16 rounds of encryption. Blowfish can use key sizes from 32 to 448 bits, and Twofish uses key sizes of 128 bits, 192 bits, and 256 bits. Longer keys provide better key strength. RC4 Rivest Cipher 4 (RC4) is a streaming symmetric algorithm (unlike the block algorithms discussed previously in the module). Because it is a streaming cipher, it uses only one round of encryption. RC4 can use key sizes from 40 to 2048 bits in length. It’s a very fast protocol, as all streaming ciphers are. RC4 uses a key stream (stream of pseudorandom bits injected into the encryption process), which is then combined with plaintext using the XOR function to encrypt them into ciphertext. RC4 is most popularly used in wireless encryption with the older, now obsolete and cryptographically broken Wired Equivalent Privacy (WEP) protocol. It can also be found in versions of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. RC4 has some documented weaknesses, which makes it unsuitable for future implementations. Current software vendors advise against its use, and the Internet Engineering Task Force’s (IETF) RFC 7465 eliminated its use in TLS. EXAM TIP RC4 is likely the only example of a streaming cipher you will see on the exam. All the other symmetric algorithms discussed throughout this book are block ciphers. Summary of Symmetric Algorithm Characteristics Table 2-1 summarizes the characteristics of the different symmetric algorithms. Module 2-4: Asymmetric Cryptosystems 103 Symmetric Algorithm Block or Streaming Block Size Rounds Key Size Notes DES Block 64-bit 16 56 bits (64 bits total, with 8 bits for parity overhead) Uses five modes of operation: ECB, CBC, CFB, OFB, and CTR. 3DES Block 64-bit 16 168 bits (three 56-bit keys) Repeats DES process three times. AES Block 128-bit 10, 12, and 14 (based on key size) 128, 192, and 256 bits Encryption standard for the US government; GCM mode is popular. Blowfish Block 64-bit 16 32–448 bits Public domain algorithm. Twofish Block 128-bit 16 128, 192, and 256 bits Public domain algorithm. RC4 Streaming N/A 1 40–2048 bits Used in WEP, SSL, and TLS; largely deprecated in current technologies. Table 2-1 Summary of Symmetric Algorithms Module 2-4: Asymmetric Cryptosystems This module covers the following CompTIA Security+ objective: r
2.8 Summarize the basics of cryptographic concepts Developers have created and deployed numerous asymmetric key cryptosystems over the years to provide robust key exchange and secure data communications. This module explores the five most common asymmetric cryptosystems. Some of the data here is historical, but all of it informs modern cryptosystems. Let’s look, in order, at these cryptosystems: r
RSA r
Diffie-Hellman r
PGP/GPG r
ECC r
ElGamal RSA The RSA cryptosystem enables you to create and use a public-private key pair. It generates keys based on the mathematical problem of the difficulty of factoring two very large prime numbers (each generally up to several hundred digits in length). RSA uses one round of encryption, and its typical key sizes range from 1024 to 4096 bits. Chapter 2: Cryptography 104 Although RSA is considered very secure, keys of smaller sizes have been broken in various published attacks. Still, these attacks are largely based upon faulty implementations of the protocol, rather than the protocol itself. RSA is pretty much the de facto asymmetric algorithm used in most public key cryptography implementations today. Figure 2-12 demonstrates how RSA works, using simple prime numbers and the CrypTool learning program. NOTE RSA is the de facto asymmetric protocol used for generating publicprivate key pairs. The name RSA reflects the first letters of its creators, Ron Rivest, Adi Shamir, and Leonard Adleman. Figure 2-12 Simple demonstration of the RSA algorithm (screenshot from the CrypTool cryptography learning program) Module 2-4: Asymmetric Cryptosystems 105 Diffie-Hellman The Diffie-Hellman (DH) protocols enable you to use asymmetric key exchange to give both sides of a conversation a single symmetric key. This means that two parties can use a nonsecure channel to establish a secure communications session. This secure key exchange works even when the parties have no previous relationship. DH offers a much faster connection compared to RSA. RSA provides great security, but requires a lot of computation and complex key exchange procedures. If you prefer speed over security, DH is the asymmetric algorithm for you! DH uses discrete logarithms, modulo arithmetic, and prime numbers to generate key pairs randomly that derive a symmetric key without ever sending any private information. Part of the DH key exchange process requires each side to create a temporary key, called an ephemeral key, which is used in only one exchange and then discarded. This ephemeral key usage is called Diffie-Hellman Ephemeral (DHE). DH relies on pseudorandom number generation to create the ephemeral keys. In most cases, this relies on pseudorandom number code that uses aspects of the underlying system like dates, MAC address of the network interface card (NIC), and other seemingly random information to make these values. Unfortunately, dates and MAC addresses really aren’t random; in theory, a malicious actor can use this against you. To fight against this, several alternatives exist. One alternative is to use a larger modulus: an important value that helps DH derive keys. A preset modulus of a specific size is called a DH group. As long as both sides agree to a group size, we can improve DH while still providing backward support for systems that only can derive smaller keys. Here are a few examples of DH groups: r
Group 1 r
Group 2 r
Group 5 r
Group 14 768-bit modulus 1024-bit modulus 1536-bit modulus 2048-bit modulus Another alternative is to skip ephemeral keys with DH and use something more resilient, such as Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE). ECDHE skips pseudorandom number generation and instead uses ephemeral keys calculated using elliptic-curve cryptography, discussed later in this module. ECDHE is negotiated by groups as well: r
Group 19 25-bit elliptic curve r
Group 20 384-bit elliptic curve r
Group 21 521-bit elliptic curve NOTE Many applications (such as secure Web sites) use RSA for authentication and DH for key exchange. Chapter 2: Cryptography 106 PGP/GPG Pretty Good Privacy (PGP) is a cryptography application and protocol suite used in asymmetric cryptography. PGP can use both asymmetric and symmetric keys for a wide variety of operations, including bulk encryption, data at rest encryption (including both file and full disk encryption), key-pair generation, and key exchange. Unlike other public key cryptography schemes, PGP uses a web-of-trust rather than a public key infrastructure. (See Module 2-7 for details.) Although PGP is considered a commercialized, proprietary version, it has an open-source equivalent, Gnu Privacy Guard (GPG). The various versions of PGP and GPG comply with the OpenPGP standard, an IETF standard published as RFC 4880. EXAM TIP With PGP/GPG, think e-mail here. That’s where you’ll see these standards in play. ECC Elliptic-curve cryptography (ECC) is an asymmetric method of cryptography based on problems involving the algebraic structure of elliptic curves over finite fields. (Say that three times fast!) ECC has many uses, including variations that apply both to encryption and digital signatures. ECC has special uses involving mobile devices. It requires low computational power and memory usage, so ECC has been widely implemented in smartphones and other low-power mobile devices. EXAM TIP Expect a question on common use cases involving low-power devices, such as smartphones, on the exam. ECC provides the answer. ECC typically uses much smaller key sizes than other asymmetric algorithms, but these smaller-sized ECC keys are also harder to break. The largest known ECC key broken to date is only a 112-bit key, for example, compared to a 768-bit key size that has been broken with RSA. ElGamal ElGamal is an asymmetric algorithm that can be used for both digital signatures and general encryption. (See Module 2-6 for the details on digital signatures.) Taher Elgamal based his eponymous algorithm partially on Diffie-Hellman key exchange algorithms. ElGamal uses mathematical problems related to computing discrete logarithms. You’ll see ElGamal used in hybrid cryptosystems, where ElGamal encrypts the comparatively tiny symmetric key and some other (faster) scheme encrypts the message. It’s also widely used in open standards and cryptosystems, including PGP and GPG. Module 2-5: Hashing Algorithms 107 The US government’s Digital Signature Algorithm (DSA) is based upon the ElGamal signature scheme. Module 2-5: Hashing Algorithms This module covers the following CompTIA Security+ objectives: r
2.1 Explain the importance of security concepts in an enterprise environment r
2.8 Summarize the basics of cryptographic concepts IT professionals use several hashing algorithms to ensure the integrity of data and source. This module starts with a brief discussion of how hashing works—a rehash of the introduction in Module 2-2, so to speak. [Insert groan here at bad pun.] Then we’ll explore the four most common hashing algorithms: r
MD5 r
SHA r
RIPEMD r
HMAC Hashing Process Encryption necessarily implies decryption. Plaintext transformed through encryption into an unreadable state can be decrypted and returned to a plaintext state. Hashing does not encrypt text; it generates a representation of that text, which is the hash or message digest. A hash is not the plaintext itself, but rather a unique identifier for the text, like a fingerprint. Note that hashing does not use keys at all, only algorithms, also making it less like encryption and decryption. Theoretically, an identical piece of plaintext will always produce the same hash value, assuming that you use the same hashing algorithm. Likewise, no two different pieces of plaintext should ever produce the same hash, given the same algorithm, although it happens. These accidentally matching hashes, called collisions, can enable a miscreant in theory to generate a piece of data with the right hash to fool others as to its integrity. Figure 2-13 illustrates the collision process a bit more clearly, where two differing texts run through the hashing algorithm, but result in identical hashes. Several older hashing algorithms can produce collisions. As this module addresses the different hashing algorithms, we’ll point out the older, collision-prone algorithms. NOTE Hashing is not the same thing as encryption and decryption. Hashes cannot be reversed or decrypted; they can only be compared to see if they match. Chapter 2: Cryptography 108 AC 68 53 0B E5 FF 26 34 E9 F2 7C E8 1F 62 4D 5A 9F C1 E7 89 14 05 F0 7A AC 0D 69 A9 7A A2 6C 0F Variable-Length Text #1 Hashing Algorithm Fixed-Length Hash or Message Digest #1 AC 68 53 0B E5 FF 26 34 E9 F2 7C E8 1F 62 4D 5A 9F C1 E7 89 14 05 F0 7A AC 0D 69 A9 7A A2 6C 0F Variable-Length Text #2 Hashing Algorithm Fixed-Length Hash or Message Digest #2 Figure 2-13 The hashing process and collisions Hashing supports confidentiality (in the case of hashing passwords, for instance) and integrity. For confidentiality, you can hash a password (run it through the hashing algorithm) and send the resulting hash over an untrusted network for authentication. You would not need to transmit the actual password (Figure 2-14). When the authenticating server receives the hash, it takes the password hash it has stored in the credentials database and compares it to the hash it received. If they match, the server knows that the user also knew the correct password, and it allows authentication. If the hashes don’t match, the server refuses authentication, because the user obviously did not know the correct password, which in turn did not generate the correct hash. Hashing thus supports authentication as well as confidentiality and integrity. EXAM TIP Expect questions on common use cases for supporting authentication, confidentiality, or integrity. Hashing provides all three. Some systems encrypt password hashes during transmission using symmetric key cryptography and then decrypt them on the receiving end to protect the hash during transmission. This action blocks an obvious attack option. Figure 2-14 Sending a password’s hash instead of the password itself I can’t read the password if it’s sent as a hash! 1ad487ce2354b5ff69211be87e Module 2-5: Hashing Algorithms 109 An attacker can intercept a password hash as it travels over a network. The attacker won’t have the actual password at that point, of course, and can’t reverse the hash to get it, but she can use various methods to perform the same type of hash comparisons against a list of potential passwords and generate an identical hash, letting her discover the original password. An encrypted hash blunts that capability. Because identical pieces of plaintext always produce the same hash value, using the same hashing algorithm on both enables you to tell if a piece of text has changed, even by one binary digit (bit). If even a single 1 or 0 bit changes in the text, the hash produced will differ from the hash of the original piece of text. In this way, comparing hashes of two supposedly identical pieces of plaintext can verify the integrity of the original. If the hashes match when compared, the samples of text are identical and have not been altered. If the hashes differ when compared, however, then a change has occurred between the original text and what was received, violating integrity. EXAM TIP Hashing can be used to assure both confidentiality and integrity. MD5 The Message Digest 5 (MD5) algorithm generates a 128-bit hash, 32 hexadecimal characters long, and it replaced an earlier version of the MD series, MD4. MD5 has weaknesses, however, and researchers have demonstrated collisions (and thus vulnerability to collision attacks) many times, even using off-the-shelf consumer laptops. Despite deprecation by security experts—as in, “don’t use this broken thing!”—many low-security situations still use it, even in 2020. MD5 is also used as part of other cryptographic methods, including the Extensible Authentication Protocol (EAP), as part of its EAP-MD5 implementation. EXAM TIP MD5 produces a 128-bit message digest, consisting of 32 hexadecimal characters, regardless of the length of the input text. SHA The US National Security Agency (NSA) developed the Secure Hash Algorithm (SHA) standards to provide cryptographic hash functions, starting in 1993. Since the initial release—SHA-0, SHA has seen several iterations, including SHA-1, SHA-2, and SHA-3. The 160-bit SHA-1 algorithm, originally designed as the standardized Digital Signature Algorithm for the United States, produces 40-character hashes. SHA-1 was a contemporary of MD5 and had similar cryptographic flaws. SHA-2 is made up of two separate algorithms, SHA-256 and SHA-512, but each has minor versions that include SHA-224 and SHA-384. SHA-3 uses a hash function called Keccak that makes it different internally than SHA-1 and SHA-2. It has the same hash lengths as the SHA-2 versions. Chapter 2: Cryptography 110 EXAM TIP SHA-1 and SHA-2 have been replaced by the latest iteration of SHA, known as SHA-3, which is an implementation of the Keccak hashing function. Also, you might see SHA on the exam as Secure Hashing Algorithm, so don’t get confused. The exam means SHA. RIPEMD RACE Integrity Primitives Evaluation Message Digest (RIPEMD) is a hashing algorithm not often seen in practical implementation. It was developed in an open-standard type of environment, as opposed to SHA. RIPEMD comes in 128-, 160-, 256-, and 320-bit versions. Again, it is not in widespread use, despite the relatively stable and secure implementation of the RIPEMD-160 iteration, which is the most common. HMAC Hash-based Message Authentication Code (HMAC) is used in conjunction with a symmetric key both to authenticate and verify the integrity of the message. HMAC can use either MD5 or SHA series of hashing algorithms (and noted as HMAC-MD5 or HMAC-SHA1/2/3, respectively). The HMAC process produces a hash value, the message authentication code (MAC), whose length and strength correspond to whichever hashing algorithm was used to create it. Here’s how it works. You already know that a given piece of plaintext or message produces the same hash every time, as long as you use the same hashing algorithm. This can be used to verify integrity; however, anyone can send a message that can be verified in terms of integrity, if the hashes match. But you cannot verify the authenticity of the message—that is, who sent it—and you cannot verify who will be able to receive it. HMAC uses a secret (symmetric) key with the hashing process, so that a given message produces a unique hash using that symmetric key. If someone does not have the key, she cannot reproduce the hash of the message, so that neither integrity nor authenticity can be verified. Only someone who has the secret key can successfully produce the same hash. This verifies not only integrity but also authenticity, since only the person having the secret key could have produced that unique hash and sent the message. EXAM TIP HMAC can use hashing functions and symmetric keys to produce a message authentication code (MAC), used to ensure both integrity and authenticity of a message. Module 2-6: Digital Signatures and Certificates This module covers the following CompTIA Security+ objectives: r
2.8 Summarize the basics of cryptographic concepts r
3.9 Given a scenario, implement public key infrastructure Module 2-6: Digital Signatures and Certificates 111 Figure 2-15 Secure Web site, Hello! Hello, www.totalsem.com! Hello! I want this to be Secure HTTP. OK! Here’s my public key: 1ab4e88d923cc13d4aa…. Asymmetric encryption relies heavily on trust. When you access a secure Web site to make a purchase, for example, you need to trust in the security of the connection between the Web server and your client before putting in a credit card number. Two related cryptographic functions create this security, digital signatures and digital certificates. Digital Signatures Secure Web sites use RSA keys for asymmetric encryption. Every connection to a secure Web site requires a key exchange. At the very least, the Web server provides its public key to the client so the client can encrypt messages securely. In some cases, the client will share its public key (Figure 2-15). The challenge to key exchange isn’t handing out the keys. The Web server and client can automatically share their public keys the moment they connect. The problem comes with the key itself. Imagine a scenario where a third party intercepts the data and tries to send a bogus public key to the client (Figure 2-16). Digital signatures address this scenario. To send a message in a typical asymmetric encryption cryptosystem, the sender encrypts using the recipient’s public key; the recipient decrypts using her private key. The reverse, however, can also work. The sender can encrypt with his private key; the only key that would enable decryption is his public key. This concept makes digital signatures possible. Here’s the full process of creating a digital signature. Figure 2-16 Third parties can be evil! OK! Here’s my (evil) public key: 9c5bba277d1aa2003d4a8c…. www.totalscam.com Chapter 2: Cryptography 112 To prove that the public key your client receives came from the proper server, the Web server adds a digital signature. The Web server takes the current Web page and does the following: 1. Encrypts the page with the client’s public key. 2. Hashes the page. 3. Encrypts the hash with the server’s private key. 4. Sends the page, the public key, and the hash to the client. Now it’s the client’s turn: 1. The client decrypts the hash using the server’s public key to verify it really came from the server. (Only the server’s public key can decrypt something encrypted with the server’s private key.) 2. The client decrypts the message with the client’s private key. Figure 2-17 helps describe this process. The hash value encrypted with the private key and that accompanies the public key is a digital signature. NOTE Digital signatures are one of the very few places where private keys are used to encrypt. Normally, public keys encrypt and private keys decrypt. Digital signatures alone work great to verify the identity of a source. Successfully decrypting the message using the source’s public key means the message could only have come from that source. Figure 2-17 Proof that the message came from the owner of the private key I’ll take the current page you’re looking at… Encrypt it with my PRIVATE key and HASH the result… Encrypt the HASH with my private key Then send you the page as well as my public key and the HASH If you can decrypt it with the public key and generate the same HASH You’ll know that only I, the holder of the private key, sent it. Module 2-6: Digital Signatures and Certificates 113 Who do I trust? NO! NO! HERE is the totalsem.com public key, digitally signed. Here’s the totalsem.com public key, digitally signed. Figure 2-18 Who can you trust? Digital Certificates A digital signature is only good for verifying that the entity who sent you a public key is legitimately the one who possesses the corresponding private key. But how do you know that public key really came from the Web site, or the owner of that e-mail address, or the VPN service, or whatever other thing you want to connect to that you need to know you can trust? You need something more than a digital signature (Figure 2-18). You might at this point say, “I know I’m on the right Web site because it says so in the address bar” or, “I know this e-mail came from [email protected], because that’s who the e-mail said it came from.” This is not acceptable. First, it’s easy to make another Web site look just like one you know (Figure 2-19). Equally, it’s easy to make another service—e-mail is a great example—look like it came from a known source. This process But the Web site said www.totalsem.com! Figure 2-19 It’s easy to deceive. Oh, really? Chapter 2: Cryptography 114 Figure 2-20 A certificate should have a third-party signature. And I, Trusted Third Party, add my digital signature as well, signifying this is www.totalsem.com! Here’s the totalsem.com public key, digitally signed. Digital Certificate is called spoofing. Simply relying on the fact that something looks like it’s a legitimate source isn’t good enough. (And how closely do most people look at URLs anyway?) Worse, a fiend can use Unicode to whack out URLs to the point where you could swear you know where you are, but you are at a completely different URL. To create trust in this scenario requires a digital certificate, an electronic file specifically formatted using industry standards that contains identifying information. That’s a mouthful! Think of a digital certificate like a Word document with a bunch of spaces to fill in with specific information. There are different digital certificate “forms” for different jobs (e-mail, Web servers, code signing, and many more). Any digital certificate will store a public key with a digital signature, personal information about the resource (URL, e-mail address, phone numbers, whatever), and a second digital signature from a third party you both trust (Figure 2-20). The rest of this module concentrates on the types of digital certificates and their formats and tours a typical certificate on a PC. NOTE Module 2-7 goes into depth on maintaining digital certificates. Touring a Certificate Let’s look at a digital certificate. In Windows, you can see your certificates by opening any Web browser’s Settings and locating a certificates option. In Microsoft Edge, for example, click the icon with three horizontal dots in the upper-right corner and choose Settings. Select Privacy and Services, then click the Manage Certificates button to open the Certificates dialog box (Figure 2-21). Module 2-6: Digital Signatures and Certificates 115 Figure 2-21 Getting to the Certificates dialog box in Microsoft Edge NOTE All Web browsers have a certificate location. Take your time, you’ll find it. The Certificates dialog box features several tabs. For this module, pick any tab, select any certificate on that tab, and then click View (or whatever your system says) to see the certificate in detail. You should see something like Figure 2-22. Now click the Details tab at the top. On the Show pull-down menu, select Version 1 Fields Only to see something like Figure 2-23. Click each field as you read through the following descriptions to see what each value stores. r
Version The common certificate format is X.509. It started with version 1. Modern certificates are version 3. This field shows the X.509 version of this certificate. r
Serial number A unique number given to this certificate by the issuing body. r
Signature algorithm The type of encryption and hash used by this certificate. r
Signature hash algorithm Same as signature algorithm. (It’s a Microsoft thing.) r
Issuer X.509 formatted name of issuer of this certificate. (See “Certificate Attributes” next.) r
Valid from Time the certificate was granted. r
Valid to Time the certificate expires. r
Subject To what this certificate is issued in X.509 format. r
Public key The public key for the certificate. Chapter 2: Cryptography 116 Figure 2-22 Certificate view in Windows There’s a lot more to see if you change Show: to , but there are two fields that warrant note here: r
Thumbprint The certificate’s digital signature. r
Authority Key Identifier The third party’s digital signature. Module 2-6: Digital Signatures and Certificates 117 Figure 2-23 Typical certificate details in Windows Certificate Attributes Digging deeper into certificates reveals a lot more information, specifically certificate attributes that vary according to the purpose of the certificate. Figure 2-24 shows a local Trusted Root Certification Authority certificate from COMODO ECC Certification Authority. Chapter 2: Cryptography 118 Figure 2-24 Local Trusted Root CA certificate Note the Issuer details in the bottom pane: r
CN The canonical name, the full name of the issuing body r
O The organization, COMODO CA Limited r
L The locality, Salford r
S The state or province, Greater Manchester r
C The country or origin, Great Britain Contrast the certificate shown in Figure 2-24 with the certificate shown in Figure 2-25, which comes from the Chrome Web browser connected to https://www.amazon.com. The Details tab is selected again, but the Subject is chosen in the top pane rather than Issuer. As you might expect, it reveals the details about Amazon, including the CN, O, L, S, and C; Amazon’s headquarters are in Seattle, Washington, United States of America. Module 2-6: Digital Signatures and Certificates 119 Figure 2-25 Web certificate attribute details Getting a Certificate Virtually all cryptosystems that use asymmetric cryptography require a certificate. Probably the best example is a secure Web site. Let’s say you want to set up a secure (HTTPS) Web server. You can spin up your own server and load some Web server software on your own, but if you want to use HTTPS, you’ll need a certificate. To get a certificate, submit information to a certificate issuing organization, called a certificate authority (CA). There are a handful of these organizations, though three dominate the market: IdenTrust, DigiCert, and Sectigo (formerly Comodo). Before you give a certificate issuing organization your credit card details, you need to generate a certificate signing request (CSR) on your Web server, as described in the “Certificate Life Cycle” section of Module 2-7. Figure 2-26 shows part of this process in Microsoft Internet Information Services (IIS). Once you create the CSR, cut and paste the information into an online form. Depending on the certificate, you’ll get your certificate sent via e-mail or through a Web interface. In most cases, the certificate installs itself. You can import if necessary. Chapter 2: Cryptography 120 Figure 2-26 Creating a CSR in IIS NOTE You don’t have to pay for third parties to sign certificates (e.g., Let’s Encrypt, https://letsencrypt.org, is a popular free certificate issuer, backed by IdenTrust). Self-signed certificates work just fine within your network for services that require certificates—applications and such on the corporate intranet, for example. There’s no reason to pay for certificates for internal use. Make certain those self-signed or untrusted-signed certificates never see the rest of the world. Module 2-7: Public Key Infrastructure This module covers the following CompTIA Security+ objectives: r
2.8 Summarize the basics of cryptographic concepts r
3.9 Given a scenario, implement public key infrastructure Public key infrastructure (PKI) implementations combine symmetric and asymmetric key cryptographic methods with hashing to create robust and secure systems. This module puts together all the information in Modules 2-1 through 2-6 of this chapter to describe these systems. The module starts with keys, algorithms, and standards. The second section explores PKI services. The third section discusses digital certificates and PKI structure. We’ll look at key safety next and then finish with trust models. Module 2-7: Public Key Infrastructure 121 PKI puts cryptography into practical application. IT professionals use PKI to implement strong authentication and encryption schemes to protect data confidentiality and integrity and to ensure non-repudiation. Let’s get started. Keys, Algorithms, and Standards Hybrid cryptographic systems incorporate the advantages of asymmetric and symmetric algorithms, while at the same time making up for the disadvantages each has. Symmetric algorithms are fast, and they can encrypt large amounts of data efficiently. Symmetric cryptography suffers from key exchange and scalability problems. Asymmetric cryptography, on the other hand, has no issues with key exchange. It’s also very scalable, since it only requires that each individual have a public and private key pair. Unfortunately, asymmetric cryptography doesn’t do very well with speed or encrypting large amounts of data. PKI takes advantage of these different positive aspects of both asymmetric and symmetric key cryptography and uses each, along with hashing algorithms, for different aspects of identification, authentication, encryption, and non-repudiation. Let’s look now at keys and algorithms that relate to PKI. EXAM TIP PKI is composed of several components and technologies, as well as the infrastructure and processes used to manage certificates. Keys Asymmetric cryptographic systems use a public and private key pair. Both keys are mathematically related, but you cannot use one to derive the other. The keys are generated using various mathematical algorithms. What one key in a pair encrypts, only the other key in the same pair can decrypt. Public keys are given to anyone who wants them, and private keys are kept confidential, protected by the individuals who own them. To exchange messages between two parties, each must have a public and private key pair. Each party must also possess the public key of the other party. When one person wants to send an encrypted message to the other, the sender encrypts the message using the receiver’s public key. Then, the receiver decrypts it using the receiver’s private key, since that’s the only key in the pair that can decrypt what the public key encrypts. This is demonstrated in Figure 2-27. Figure 2-27 Communicating using public and private keys Meghan’s Public Key Amy’s Public Key Amy’s Private Key Meghan’s Private Key Amy Meghan Chapter 2: Cryptography 122 Symmetric cryptography, on the other hand, uses only one key. Both parties must possess that same key to encrypt and decrypt data. Getting the same key to each party securely poses the major obstacle in symmetric cryptography. In a hybrid cryptographic system, party A generates a symmetric key—often called a session key—and encrypts that key using party B’s public key, and then sends the encrypted key to party B. Party B, the receiving party, decrypts the encrypted session key with party B’s private key. After that, faster communications can take place using the symmetric session key. Using this hybrid approach with asymmetric and symmetric keys ensures confidentiality, since both data and the session keys are encrypted. It doesn’t, however, ensure authenticity or integrity of the message, nor does it provide for non-repudiation. Adding hashing algorithms into the process provides those services; we’ll discuss those momentarily. EXAM TIP The CompTIA Security+ SY0-601 objectives use specific wording on this topic. So a common use case for cryptography is supporting confidentiality. The hybrid cryptographic system clearly accomplishes this goal. Algorithms Previous modules discussed the algorithms, both symmetric and asymmetric, employed in PKI. These include symmetric algorithms such as AES and asymmetric algorithms such as RSA for key generation and Diffie-Hellman for key exchange. PKI also uses hashing algorithms, such as MD5, RIPEMD, and the SHA family of algorithms. Let’s look at specific PKI standards to see how they put the algorithms together. PKI Standards PKI implementations use one of several standards. The primary standard is X.509; other standards apply to specific industries. The ITU Telecommunication Standardization Sector (ITU-T) X.509 standard describes how digital certificates are constructed, including what information they will contain, their uses, and their formatting. The X.509 standard also describes processes involved with issuing certificates, as well as other processes in the certificate life cycle. NOTE The initialism “ITU” has changed meaning over the years, from International Telegraph Union, formed in 1865, to the International Telecommunication Union, created in 1932. ITU-T morphed from the Comité consultatif international téléphonique et télégraphique (CCITT), formed in 1956, to the current initialism, created in 1993. (And none of this brief history lesson shows up on any CompTIA exam.) Other somewhat proprietary standards that you’ll encounter in PKI come from different industry segments, but usually comply with open standards. One set of these standards is the Public Key Cryptography Standards (PKCS), developed by RSA Security. Module 2-7: Public Key Infrastructure 123 The PKCS describe certificate construction and use. Cryptosystems use a PKCS #7 file digital certificate, for example, to sign or encrypt messages, such as e-mail. A PKCS #12 file contains public and private keys and is encrypted for secure key storage. Other vendors, such as Microsoft and Apple, for example, also have proprietary ways of issuing and managing certificates throughout the certificates’ life cycle, although these standards usually comply with the X.509 standards. EXAM TIP The primary standard used in PKI is the X.509 standard, which describes the certificate format and how it is used. PKI Services In addition to confidentiality, PKI provides for secure key exchange, message authentication and integrity, and non-repudiation. The next few sections discuss how PKI provides these different services. We’ll also revisit digital signatures. Key Generation and Exchange PKI has technologies and methods built in for several different processes. Among those are key generation and key exchange. Key generation is the process of creating a public and private key pair, which is then issued to an individual, based upon his or her confirmed identity. RSA is the most popular key generation algorithm, although there are others. Key exchange is a process, typically using Diffie-Hellman algorithms, that assists in the creation and secure exchange of symmetric keys, typically session keys used for one communications session only. After keys are generated, public and private keys are used to encrypt and decrypt session keys once they are transmitted and received, respectively, by both parties. Non-repudiation Non-repudiation means that a person cannot deny that he or she took a specific action. The person’s identity has been positively verified, and any actions that person takes are traced back to that identity. PKI assures non-repudiation by using public and private keys. The certificate authority must positively identify and authenticate an individual before the CA issues a key pair. After issuing that key pair, the CA digitally signs the individual’s certificate using the CA’s private key. This signing confirms the CA has validated the user’s identity. Finally, because only the issuing organization can sign with its private key, this verifies that the certificate came from a valid issuing organization. Once Jack gets his key pair from the certificate authority, any message he signs using his private key verifies he sent the message. This assumes that Jack did the right thing and protected his private key, of course. If a message is signed using a key pair owned by Jack, in other words, he cannot deny that he sent the message. This assures non-repudiation. EXAM TIP The CompTIA Security+ SY0-601 objectives use specific wording on this topic. So a common use case for cryptography is supporting nonrepudiation. PKI clearly accomplishes this goal. Chapter 2: Cryptography 124 Message Integrity PKI can provide message integrity through hashing algorithms. Using hashing algorithms such as SHA-512, for instance, you can hash messages to generate unique fingerprints, or hashes, that can be checked both before transmission and after the message is received. If the hashes compare and match, you can be assured of data integrity. If they compare and do not match, you know that something (or someone) has changed the integrity of the message. Message integrity can be altered accidentally through simple “bit-flipping” during bad transmission conditions or intentionally by some malicious actor. Message integrity is assured by also incorporating hashing algorithms into the PKI process. Although there are several possible ways to do this, the simplest way is to hash the message and encrypt both the message and the hash and send them on to the recipient, so that when the recipient gets the message, he can simply decrypt the message with his private key and then rehash the message to generate a hash that he can compare to the hash he received. The recipient doesn’t do this manually; the automatic PKI processes take care of these steps at the application level. EXAM TIP The CompTIA Security+ SY0-601 objectives use specific wording on this topic. So a common use case for cryptography is supporting integrity. PKI clearly accomplishes this goal. Digital Signatures PKI systems incorporate digital signatures to authenticate the source of a message. Encrypting a message with a private key assures the recipient of the source when the corresponding public key decrypts that message. Add in the hashing component of digital signatures and you’ve got a winning combination, as discussed back in Module 2-6. Digital Certificates and PKI Structure This section explores how a basic public key infrastructure organization works, describing some of the elements in a PKI, such as the certificate and registration authorities, as well as the certificate revocation list. First, however, we’ll take another look at digital certificates and describe them in more detail. Digital Certificates As mentioned earlier, digital certificates are simple electronic files. The X.509 and PKCS standards determine the specific formats for digital certificates, as well as the file types and formats. Digital certificates come in a variety of file formats, including those with.cer and.pem file extensions. (We’ll cover all of these in detail in Module 11-5.) Additionally, there is a variety of types of certificate files, and each of these may fulfill a unique function in a PKI, such as a certificate request file. Digital certificates can be stored on several types of media, such as USB sticks, mobile devices, internal computer storage, and even centralized repositories on a network or the Internet. Module 2-7: Public Key Infrastructure 125 Certificates come in a variety of types, each type serving one or more purposes such as the following: r
Signing and encrypting e-mails r
Identifying and authenticating networks r
Identifying servers r
Digitally signing software, verifying its authenticity from a publisher Certificates typically contain a variety of information, known as certificate attributes, including the public key of the individual and information that identifies that person, the issuing organization, and valid dates and functions for the certificate to be used (Figure 2-28). Cryptographic systems can use certificate attribute filters to allow or deny specific access. A filter might examine the organization (O) attribute and allow only traffic that comes from Total Seminars, for example. EXAM TIP The CompTIA Security+ SY0-601 objectives use specific wording on this topic. So a common use case for cryptography is supporting authentication. Certificates clearly accomplish this goal. Figure 2-28 A digital certificate Chapter 2: Cryptography 126 Certificate Life Cycle Managing a digital certificate from issuance, through use, and finally disposal refers to the process of managing the certificate over its life cycle. That life cycle follows four main stages: 1. Registration by an entity 2. Issuance of certificate from certificate authority 3. Maintenance by the certificate authority 4. End of life through expiration, suspension, or revocation The sections below explore both the life cycle stages and the entities involved. We’ll look at certificate registration, certificate authorities, certificate servers, and certificate end of life features. Certificate Registration A certificate’s life cycle begins when a user registers to receive a certificate. The person requesting the certificate must provide valid identification to the certificate authority (CA), the entity that issues and controls the digital certificates. Registration usually means the user must present identification that the issuing organization authenticates, thus verifying the person’s identity. Valid forms of identification that a requester may submit include her driver’s license, birth certificate, passport, photographs, and any other identification that the issuing organization requires. Once a user has submitted the required identification, the CA decides whether to issue the certificate and under what circumstances. NOTE Before issuing a certificate to an individual, the certificate authority must verify the individual’s identity. Certificate Authority As just mentioned, the certificate authority issues and controls digital certificates. The CA might be a commercial organization, such as GoDaddy, or it could be the user’s organization. Often, private organizations have internal CAs that issue digital certificates used specifically within the logical bounds of the organization. The CA also manages the certificate server (sometimes called the CA server), the host computer that generates keys and produces digital certificate files. The CA normally handles all user registration, identification, and validation processes, and it issues digital certificates to the user. In larger organizations, to help balance the workload for the CA, registration functions may be delegated to a separate registration authority (RA), which verifies user identities and then passes the information on to the CA for certificate generation. The CA makes decisions on whether to issue the certificate, under what circumstances, and with what caveats. When an entity requests a certificate, it submits a certificate signing request (CSR). The CA reviews the CSR, which contains the information that will be embedded in the digital certificate, including the public key, organization name, common Module 2-7: Public Key Infrastructure 127 Root CA Root CA Intermediate CA Subordinate CA Subordinate CA Subordinate CA End entity certificate End entity certificate End entity certificate Subordinate CA End entity certificate End entity certificate End entity certificate Figure 2-29 Simple CA hierarchy name, and so on. The CA then generates a certificate for the requesting entity. That certificate is called an end entity certificate. After generating certificates, the CA must also perform actions on them, such as renewing, suspending, or revoking them, as needed. EXAM TIP A certificate authority (CA) is the primary element in PKI. Depending on a host of factors, such as geographical considerations, su