Understanding Basic Cryptography Concepts

Chapter 1 introduces confidentiality and integrity (in the context of the CIA security triad of confidentiality, integrity, and availability). Cryptography includes confidentiality and integrity, but it’s worth stressing that many cryptography processes provide authenticity too. Confidentiality from access controls starts with proper identification and authentication as described in Chapter 2. Appropriate access controls then grant personnel access to data based on their proven identity. As an introduction for this chapter, the following list describes confidentiality, integrity, and authenticity within the context of cryptography:

•  Confidentiality   The goal of confidentiality is to prevent unauthorized access to data. Beyond access controls, the primary method of preventing loss of confidentiality is with encryption. This chapter focuses on encryption techniques to protect the confidentiality of data. Two common encryption techniques are symmetric encryption (with one key) and asymmetric encryption (with two keys).

•  Integrity   The goal of integrity is to prevent unauthorized modifications to data and systems. Beyond access controls, hashing is one of the primary methods of providing assurances that data has not lost integrity. A hash is calculated on data at different times, such as on Monday and then again on Tuesday. If the two hashes are the same, it proves that the data is the same and has maintained integrity. This chapter describes hashing and covers several hashing protocols.

•  Authenticity   Validation processes provide assurances that data is coming from a known source and is valid or reliable. Many encryption and hashing protocols provide authenticity. Additionally, some processes, such as digital signatures, have authenticity as a key goal. This chapter covers all of these concepts.

Cryptography Terminology

Cryptography has many terms that might not be familiar to you. The following list introduces some of these terms and topics, all of which are covered in greater depth in this chapter:

•  Plaintext   Data that is not in an encrypted format. Plaintext data (sometimes called cleartext data) is easily readable by anyone. You can think of it as ordinary text, such as what you’re reading on this page.

•  Ciphertext   Data that is in an encrypted, or scrambled, format. Authorized personnel can decrypt ciphertext to return it to plaintext and read it. When strong encryption protocols are used, unauthorized personnel cannot read ciphertext.

•  Encryption   The process of converting plaintext data into ciphertext data to prevent loss of confidentiality. Figure 14-1 shows the overall process of encrypting plaintext data into ciphertext data using an encryption algorithm. Decryption reverses the process by decrypting the ciphertext data with a decryption algorithm to re-create the original plaintext data.

Figure 14-1   Encryption and decryption process

•  Encryption algorithm   A mathematical process that converts plaintext data to ciphertext data. Encryption algorithms include a process to decrypt the data. Encryption algorithms are often published so that anyone can see how they work. This allows experts to analyze and test the algorithms to verify their strength. For example, you can find the algorithm for Advanced Encryption Standard (AES) by doing an Internet search on “Advanced Encryption Standard algorithm” or “AES algorithm.”

•  Symmetric encryption   Data is encrypted and decrypted with the same key. For example, if an encryption algorithm uses a key of 101 to encrypt data, it will use the same key of 101 to decrypt the data. The algorithm would use a different key (such as 234) to encrypt and decrypt a different set of data. In practice, keys are much longer than three digits, such as 256, 512, 1024, or 2048 bits long.

•  Asymmetric encryption   Data is encrypted and decrypted with two keys. These two keys are a matched pair known as a public key and a private key. A private key can decrypt data that has been encrypted with the matching public key. Similarly, a public key can decrypt data that has been encrypted with the matching private key. The private key is always kept private and the public key is freely shared.

•  Cryptography   The science of scrambling, or encrypting, data. Cryptography includes the study of algorithms and other methods that help protect the confidentiality of data.

•  Cryptographic system   A system that includes the algorithms needed to support a particular method of encryption or decryption. Although most systems support standard algorithms, administrators sometimes need to add features to a computer to support a newer algorithm.

•  Cryptanalysis   The science of studying cryptographic methods. Security experts and attackers often use cryptanalysis methods to discover weaknesses in existing algorithms. Attackers attempt to use cryptanalysis to defeat a cryptosystem with the goal of compromising the confidentiality or integrity of protected data.

•  Hashing   The process of creating a hash from a file or a message with a hashing algorithm. A hash is simply a number. A hashing algorithm will always produce the same hash when executed against the same data. In other words, as long as a file or message never changes, a recalculated hash will always be the same no matter when it is calculated.

Data Sensitivity

The primary purpose of encrypting data is to preserve its confidentiality. However, this isn’t required for all data. For example, Chapter 11 discusses data classifications such as Top Secret, Secret, Confidential, and Unclassified. Data that is classified as Top Secret, Secret, or Confidential is sensitive, so it’s appropriate to protect this data with encryption protocols. Similarly, organizations often use encryption methods to protect intellectual property, personally identifiable information (PII), and protected health information (PHI), all of which are also covered in Chapter 11.

Additionally, the data sensitivity drives the selection of the encryption protocols. Higher data classifications (such as Top Secret) warrant the use of the strongest encryption protocols. In contrast, lower data classifications (such as Confidential) do not need the strongest encryption protocols.

You might be wondering, “Why not use the strongest encryption protocols for everything?” The reason is the performance cost. It takes processing power to encrypt and decrypt data, and if all data is encrypted and decrypted, it can slow the system down. Also, encrypted data typically consumes a lot more space than unencrypted data. As an example, Figure 14-1 shows the plaintext data as a single sentence, but the ciphertext data is about five times as many characters. The size difference varies with different algorithms, but ciphertext data is larger than plaintext data. This takes more space when the encrypted data is saved on media such as a hard disk and consumes more bandwidth when transferred over a network.

Regulatory Requirements

Many jurisdictions have implemented regulatory requirements related to cryptography. Chapter 13 covers some of the laws that mandate protection of privacy information. This includes the protection of personally identifiable information (PII) and protected health information (PHI), though some jurisdictions use different labels than PII and PHI. As a reminder, PII is any information that can personally identify an individual. PHI is similar but it also includes information concerning the health status, provision of health care, or payment of health care for an individual. One of the ways that organizations protect PII and PHI is by encrypting data at rest (stored on media such as a hard drive) and data in motion (transmitted over a network).

The Payment Card Industry Data Security Standard (PCI DSS) applies to any organizations that process credit card payments. Chapter 10 provides an overview of PCI DSS in the context of security audits and lists the 6 control objectives and 12 supporting requirements. The overall goal is to protect credit card data. This includes data at rest and data in motion, and PCI DSS discusses the use of encryption as one of the methods to protect the data.

For data in motion, PCI DSS stresses the use of strong cryptography and security protocols such as Transport Layer Security (TLS), Internet Protocol security (IPsec), and Secure Shell (SSH). PCI DSS version 3.1 specifically discourages the use of SSL and early TLS versions because they are not strong cryptographic protocols.

Chapter 11 discusses the Health Insurance Portability and Accountability Act (HIPAA) of 1996. It mandates the protection of protected health information (PHI), and one method to do so is encryption of PHI data at rest and in transit. Another method of protecting personal data is by using the Safe Harbor method. This uses anonymization and de-identification processes to eliminate 18 patient identifiers (such as names, telephone numbers, social security numbers, and more) to ensure that the data does not identify an individual. This is useful when collecting and analyzing data for research.

Chapters 11 and 13 discuss the General Data Protection Regulation (GDPR). It strongly recommends the use of encryption to protect all personal data. If an organization chooses not to encrypt data, it needs to use alternative mechanisms to protect the data. However, if the organization suffers a data breach and it hasn’t encrypted personal data, the organization may have difficultly proving that its alternative mechanisms were adequate.

Participating in Security Awareness and Training

As a security expert in your organization, you may be asked to participate in security awareness and training events to share your knowledge. For example, your organization may require users to encrypt certain data and digitally sign all of their e-mails. However, users may not understand the importance of these actions. By sharing your knowledge, you can help raise the overall security awareness within your organization.

User training isn’t always formal. Many times, technicians and administrators provide informal training to end users while troubleshooting problems. Even though this is informal, it can often provide lasting meaning to the users.

Enforcing Integrity with Hashing

Chapter 1 introduced hashing as one of the methods used to enforce integrity. Recall that a hash is simply a number created by executing an algorithm against a file or message. As long as the original data is not changed, the hash will always be the same. Knowing this, you can execute the hashing algorithm on the file or message at one point to create a hash, and then later execute the same hashing algorithm again. If the hashes are the same, you know the original data has not been modified. It has retained integrity.

In contrast, if the hashes are different, you know that the file or message has lost integrity. You don’t necessarily know why the file is different. A virus may have infected it, someone may have purposely modified it, or it may have simply lost a bit or two as it traveled over a network. However, you do know it is different and you should treat it with suspicion.

Consider Figure 14-2. Lisa is sending a message (“You will pass the SSCP Exam”) to Homer. Before sending it, she calculates the hash and then sends both the message and the hash. Homer receives both the message and the hash. He can then recalculate the hash on the received message and compare the two hashes.

Figure 14-2   Using a hash to verify integrity

If the recalculated hash is the same as the sent hash, then the message has not lost integrity. If the recalculated hash is different, Homer knows that the message Lisa sent is not the same as the message that he received.

Hashing Algorithms Provide One-Way Encryption

An important point about hashing algorithms is that they provide one-way encryption of data. They create a hash by reducing the message or file to a message digest, which is a fixed-length number. However, in most cases, you can’t reverse this process to discover the original data.

For example, the message “You will pass the SSCP Exam” results in a hash of 1bac44709cd712e194c43df798c2ebdb. However, you can’t use this hash to determine the original message. The hash could have come from a 10KB message, a 5MB file, or data of any other size and content. As an example, consider this hash: df076ba5c4ac4d04cb286bde900c68f2. Just looking at the hash, there’s no way that you could determine that it is a hash of a computer file on my computer.

Hashing Algorithms

The following list describes some common hashing algorithms:

•  Message Digest 5 (MD5)   This creates a 128-bit hash, typically displayed as 32 hexadecimal numbers. It was widely used in applications, but security experts identified vulnerabilities with it in 2004. The U.S. government and security experts consider MD5 cryptographically broken, and it is not recommended for use in applications. The hash shown in Figure 14-2 is the actual MD5 hash of the statement “You will pass the SSCP Exam” created from an online MD5 generator.

•  Secure Hashing Algorithm 1 (SHA-1)   This is a 160-bit hash. It was commonly used by U.S. government agencies such as the U.S. military until 2010. Due to vulnerabilities, it is no longer recommended for use.

•  Secure Hashing Algorithm 2 (SHA-2)   This is an improvement over SHA-1 and can create hashes of 224, 256, 384, or 512 bits. Although SHA-2 hasn’t been broken, it functions similarly to SHA-1, and many experts believe it’s just a matter of time before it is cracked. It’s worth noting that SHA-256 is a version of SHA-2.

•  Secure Hashing Algorithm 3 (SHA-3)   The U.S. National Institute of Standards and Technology (NIST) sponsored the NIST hash function competition from 2007 to 2012. NIST selected a subset of the Keccak algorithm as SHA-3. The algorithm is completely different from SHA-1 and SHA-2 and creates hashes of 224, 256, 384, or 512 bits.

•  Hash-based Message Authentication Code (HMAC)   The HMAC algorithm works with other hashing algorithms such as MD5 and SHA versions. It uses a shared secret key that adds some randomness to the hash. Only the sender and the receiver know the shared secret key. A primary benefit of HMAC over other hashing protocols is that it adds authenticity to the message. This also provides nonrepudiation because it verifies to the recipient that the message was sent by the other entity that knows the secret key.

While MD5 and the SHA algorithms provide integrity, HMAC provides both integrity and authenticity. Figure 14-3 shows the extra step used with HMAC-MD5. In this example, both Lisa and Homer know the secret key is “You Can Pass.” Lisa’s system first calculates the MD5 hash on the message and then uses the secret key to create the HMAC-MD5 hash. She then sends both the message and the hash. Homer’s system then calculates the MD5 hash and uses the secret key to calculate the HMAC-MD5 hash. As long as both hashes are the same, Homer knows that the message has not lost integrity and that Lisa sent it.

Figure 14-3   Using HMAC to provide integrity and authenticity

In contrast, imagine Bart wanted to impersonate Lisa and send a message to Homer. Because Bart doesn’t know the secret key, he might guess one (such as “I won’t write on chalkboards”). However, this secret key creates a completely different HMAC-MD5 hash. Homer’s system would calculate the HMAC-MD5 hash using the secret key of “You Can Pass.” After comparing both, his system would recognize that the keys are different and show an error. This indicates to Homer that Lisa did not send the message.

Verifying Integrity with a Hash

Hashes can be verified automatically or manually. For example, applications that use digital signatures will automatically check the hash to verify the integrity of a message and report the results to the user. The section “Digital Signatures” later in this chapter shows the process used to check the hash automatically.

Other times, you might want to verify the hash of a file manually. For example, if you download a file from a website, you may want to verify that the file you downloaded is the same as the file that the website developers posted. Website developers sometimes calculate the hash of the file before posting it. They then post both the hash and the file. After you download the file, you can manually calculate the hash to see whether it’s the same as the posted hash.

As an example, imagine you download a file named runthis.exe from a website. On the website, you see that the SHA-1 hash is posted as 286bde900c68f2df076ba5c4ac4d04cb27a61ffb. After you download the file, you can calculate the SHA-1 hash of the file and verify it is the same as the posted hash. If it is, you know the file hasn’t lost integrity. If it is different, you know the file you downloaded isn’t the same as it was when the web developer posted it.

There are many free hashing tools available on the Internet. I’ve downloaded the sha1sum tool, which you can access here: http://gcgapremium.com/data/sha1sum.zip. Figure 14-4 shows a command prompt window with three commands executed. The first one is dir, which shows the files in this folder (or directory). I’ve copied the downloaded file (runthis.exe) and the two files used by the sha1sum tool to the SSCP folder. The second command (sha1sum compute runthis.exe) calculates the hash on the downloaded file. If I compare this to the file posted on the website, I can see that it is the same. This tells me the file has not lost integrity.

Figure 14-4   Calculating the hash with sha1sum.exe

As a reminder, no matter how many times I calculate the hash on the same data, I will always get the same hash. You can see this in the commands labeled 3 and 4 in Figure 14-4.

If the hash of the downloaded file is different from the posted hash, you would know that the file you downloaded has lost integrity. You don’t necessarily know what caused the problem, but you do know that you shouldn’t trust this file. It may have just lost a bit or two during the download, but it also might be infected with malware.

Salting Passwords

Chapter 5 discusses rainbow table attacks and how salting passwords helps prevent rainbow table attacks. Salting adds a random number of bits to a password. To get a better picture of this, it’s valuable to understand how passwords are stored.

Passwords are rarely stored on a system in cleartext. A common way that systems and applications store passwords is in a hashed format. For example, each of the following bullets shows a password and the corresponding SHA-1 hash of the password. Instead of storing the passwords, systems store the hashes.

•  123456   7c4a8d09ca3762af61e59520943dc26494f8941b

•  IW1llP@33SSCP   f281f938734ccbb10aaf2a17f6ced2198be5582d

•  YouW1llP@33SSCP   c33d3e769a77776bd2557029d0e9a1d6e0db4a28

When a user logs on and enters a password, the system hashes the password and compares the hash of the entered password with the hash of the stored password. If they’re the same, the system knows the user entered the correct password. This is also useful when transmitting the user’s credentials over a network. Instead of sending the user’s password, a system can send the hash of the password that the user sent.

While a hash of 7c4a8d09ca3762af61e59520943dc26494f8941b looks secure (certainly more secure than the weak password of 123456), attackers found that they could reverse-engineer the hash to discover the password. As mentioned in Chapter 5, they developed rainbow tables, which are large tables of passwords (created from predefined character sets), and calculated hashes of the passwords. Attackers can then perform a simple rainbow table lookup process that compares the hash of a captured password with each of the hashes in the rainbow table. When they have a match, they have discovered the password.

A salt is a set of random bits added to a password before hashing it. These additional bits significantly change the password. For example, by adding the hexadecimal number 9 (1001 in binary), it changes the hash of the previous three passwords as shown in the following bullets. You can see that just a few bits changes the hash significantly. This makes it difficult for attackers to discover even the weak password of 123456.

•  123456   99e2b89f3cda731add47da0c4a7698c1e4c80ba3

•  IW1llP@33SSCP   52d02acb0467a856f56c2974cb0d1d5d675042e7

•  YouW1llP@33SSCP   949245c0ab1c894eaa8ac42263c8747070707acb

Exploring Symmetric Encryption

Symmetric encryption uses a single key to encrypt and decrypt data. Symmetric encryption algorithms are constant, but the keys used to encrypt different sets of data are changed frequently to avoid compromising security. For example, the Advanced Encryption Standard (AES) always uses the same algorithm to encrypt and decrypt data, no matter how many times it’s used. The key used to encrypt a set of data is also used to decrypt that data.

However, symmetric encryption algorithms use different keys to encrypt and decrypt other sets of data. For example, the algorithm might use a key of 123456 to encrypt and decrypt one block of data, but then use a key of 789321 to encrypt and decrypt another block of data. These keys are shortened for brevity but would be much longer. For example, AES has a default key length of 128 bits.

Many applications use symmetric encryption. For example, Chapter 2 presents Kerberos as a network authentication protocol and discusses how it uses tickets for authentication. Kerberos uses symmetric encryption to protect the confidentiality of these tickets.

ROT13

The simplest way to demonstrate symmetric encryption is with ROT13, an encryption scheme similar to that used by ancient Romans. I’ve seen it used occasionally online by people attempting to make their messages harder to read. For example, if someone posts movie spoilers in online forums using ROT13, a reader can’t easily read them.

ROT13 rotates letters 13 spaces. If you wanted to post a message saying, “The butler did it,” with ROT13, you would rotate each letter forward 13 spaces. If you get to Z, then you continue with A. T rotated 13 spaces is G, h rotated 13 spaces is u, and so on. The ultimate message is “Gur ohgyre qvq vg.” Anyone receiving this ciphertext can rotate the letters backward 13 spaces to read the plaintext. The ancient Romans used the same rotation method, but always rotated it 13 spaces.

There are variations on ROT13. For example, you could use a rotation algorithm to encrypt and decrypt the data, but instead of always using the key of 13, you could use a different key at different times. On Monday, for instance, you might use a key of 3 to rotate the letters three spaces forward. To decrypt the data, you would use the same key of 3 but rotate three spaces backward. This allows you to modify the key regularly so that if other people discover the data, they won’t necessarily know what the key is and may have trouble decoding it. Although this is a very weak encryption algorithm compared to what’s in use today, it does allow you to easily see the difference between the algorithm and the key.

This symmetric rotation algorithm could be defined as follows:

•  Encryption   Rotate X spaces forward to encrypt, where X is the key.

•  Decryption   Rotate X spaces backward to decrypt, where X is the key.

•  Key   The key is any number. Data encrypted with a key of X can be decrypted with the same key of X. In other words, if you use a key of 3 to encrypt the data, you would use the same key of 3 to decrypt the data. The challenge is to ensure that all authorized entities know what key to use.

Encryption algorithms are usually published and well known. For example, if you wanted to look up the encryption algorithm used for any of the symmetric encryptions discussed in this chapter, you could probably find them on the Internet. However, because data is encrypted with different keys, attackers will not be able to read ciphertext with only the algorithm. They also need the key.

Creating Strong Keys

Strong encryption algorithms create longer keys and change them often. This prevents attackers from cracking the encryption by guessing the key and ensures that the algorithm can use different keys. This is difficult to conceptualize with large keys, but consider keys of 2 bits, 3 bits, and 4 bits as shown in Table 14-1.

Table 14-1   Number of Bits Used in Keys

If an algorithm used only 2 bits, it could only create four keys, and attackers could easily crack the code in a brute-force attack using each of the four keys. However, with more bits, the algorithm can create more keys. Notice that adding a bit doubles the number of keys you can create. This is consistent with each bit you add.

Some older encryption algorithms used 56-bit keys, allowing them to create as many as 72,057,594,037,927,936 keys (over 72 quadrillion keys). While the number looks large, it is quite small by today’s cryptographic standards. Attackers using basic computers can use a brute-force attack to guess the correct key and crack a code in minutes, if not seconds. Of course, faster computers can go through the keys quicker.

When using the same algorithm (such as AES), longer keys provide stronger encryption and take longer to crack. For example, Advanced Encryption Standard (AES, covered in more depth later in this section) can use keys of 128 bits, 192 bits, or 256 bits. Imagine that an attacker could identify a 128-bit key using current computers within about 100 years. If you used AES-256 instead (with a 256-bit key), it would increase the time required to identify the key to a trillion years or so. The point is that using a longer key with the same encryption algorithm makes it theoretically impossible for an attacker to discover the key.

In addition to using longer encryption keys, the encryption algorithm should create random keys and rotate between different keys. Ideally, the algorithm wouldn’t ever use the same encryption key twice within the same set of data. If the algorithm did use the same key twice while encrypting a set of data, the code would be easier for an attacker to crack.

Comparing Block and Stream Ciphers

Two common types of ciphers used in symmetric encryption are block ciphers and stream ciphers. Both ciphers use a single key to encrypt and decrypt specific pieces of data, but they divide the data differently.

A block cipher encrypts fixed-length groups of bits, or blocks of data, individually. It starts by dividing the plaintext data into fixed-length sizes, such as 128-bit blocks of text. It then encrypts each block individually.

In contrast, a stream cipher encrypts the bits as a stream of data rather than as fixed-length blocks. Stream ciphers are susceptible to more vulnerabilities when not implemented properly. For example, an important rule related to stream ciphers is never to reuse a key. Wired Equivalent Privacy (WEP) is an early wireless security protocol that broke this rule, making it easy to crack. It’s worth stressing that stream ciphers are secure when used properly.

Advanced Encryption Standard

Advanced Encryption Standard (AES) is one of the most popular symmetric encryption algorithms. It is a fast, efficient, 128-bit block cipher. NIST spent five years examining multiple encryption algorithms looking for a replacement for an older encryption algorithm. NIST ultimately selected the Rijndael algorithm, and both public and private sectors have adopted it for use. This is similar to how NIST selected a subset of the Keccak algorithm as SHA-3 to replace SHA-1 and SHA-2.

Many different applications use AES for encryption. For example, Wi-Fi Protected Access 2 (WPA2) uses AES to encrypt wireless transmissions. AES is used to encrypt entire hard drives with Trusted Platform Modules (TPMs) and can encrypt data on USB flash drives. These are just a few examples of AES’s popularity as a symmetric encryption standard, and it is important to realize why—AES is strong and efficient.

AES uses keys of varying sizes to add strength to the cipher:

•  AES is sometimes listed as AES-128 and uses 128-bit keys.

•  AES-192 uses a 192-bit key.

•  AES-256 uses a 256-bit key.

Larger key sizes make the encryption significantly harder to break, but there is an associated resource cost. For example, AES-256 is stronger than AES-128, but systems can encrypt and decrypt AES using 128-bit keys quicker than they can encrypt and decrypt AES-256.

The U.S. National Security Agency (NSA) requires the use of AES-256 (256-bit keys) for data classified up to Top Secret.

Other Symmetric Encryption Algorithms

The following list shows many of the other symmetric encryption algorithms that you may come across. However, none of these have the combined strength and efficiency of AES, so their usage is significantly less common today than it has been in years past. Additionally, attackers and security experts have discovered vulnerabilities in some protocols, so experts recommend discontinuing their use. This includes DES and RC4.

•  DES   DES is an older 64-bit block cipher that uses 56-bit keys. It has been broken and is rarely used anymore. It was a standard selected by the National Bureau of Standards (now known as NIST) but was replaced by AES.

•  3DES   Triple DES (or three DES) improves DES by encrypting data in three passes with three separate keys. It is also a 64-bit block cipher and it was one of the standards evaluated by NIST with AES but was not selected. It supports 56-bit, 112-bit, or 168-bit keys. It is a slower and processor-intensive block cipher but it is strong.

•  Blowfish   Blowfish is a 64-bit block cipher that is still used in many applications. It supports 32-bit to 448-bit keys and was another standard evaluated by NIST as a replacement for DES. It is a strong cipher and is still in use, although its use is being overshadowed by AES.

•  Bcrypt   Many Unix and Linux distributions use bcrypt to protect passwords stored in the shadow password file. It salts the password with additional bits before encrypting it with Blowfish. Bcrypt is one of many key-stretching techniques. Key stretching transforms a potentially weak password into a more secure password.

•  Password-Based Key Derivation Function 2 (PBKDF2)   PBKDF2 is another key-stretching technique. It adds a salt of at least 64 bits and then applies a cryptographic function (such as a cipher or hashing algorithm) multiple times. PBKDF2 can be used for passwords similar to bcrypt or to create stronger cryptographic keys used for symmetric encryption.

•  IDEA   The International Data Encryption Algorithm (IDEA) is a 64-bit block cipher using 128-bit keys that was also submitted as a replacement for DES. Many implementations of Pretty Good Privacy (PGP) used IDEA for encrypting e-mails, but IDEA is rarely used with current implementations of PGP.

•  RC4   Ron Rivest invented Rivest’s Cipher (RC4), and it has been a widely used symmetric stream cipher. It has been used with Transport Layer Security (TLS) to encrypt Hypertext Transfer Protocol Secure (HTTPS) traffic. Security experts have identified multiple vulnerabilities in RC4, and it is no longer recommended for use.

Table 14-2 summarizes key points about some popular symmetric encryption algorithms.

Table 14-2   Symmetric Encryption Algorithms

Exploring Asymmetric Encryption

Asymmetric encryption (also known as public key cryptography) uses two matched keys identified as a public key and a private key. There are several important points to remember related to these keys:

•  Anything encrypted with the public key can only be decrypted with the matching private key.

•  Anything encrypted with the private key can only be decrypted with the matching public key.

•  The private key is always kept private and never shared.

•  The public key is freely shared and publicly available.

Asymmetric encryption requires a public key infrastructure (PKI, described in more detail later in this chapter) to create, manage, distribute, validate, and revoke certificates. A public key is embedded in a freely shared certificate. For example, Figure 14-5 shows a certificate provided by www.gcgapremium.com after a user requests a secure session. This certificate is using a 2048-bit public key, and the matching private key is stored privately on the www.gcgapremium.com web server.

Figure 14-5   Certificate with public key selected

A common question people ask is, “Which key encrypts and which key decrypts?” The answer depends on the goal. The following are two common uses of these keys in asymmetric encryption:

•  Privately share a symmetric key between parties over a public network   In this case, the public key encrypts and the private key decrypts. The “Transport Layer Security” section later in this chapter describes how this works.

•  Digitally sign an e-mail   In this case, the private key encrypts and the public key decrypts. The “Digital Signatures” section describes how this works.

RSA

RSA is widely used in public key cryptography for privately sharing symmetric keys (key exchange) and digital signatures (described later in this chapter). Ron Rivest, Adi Shamir, and Leonard Adleman publicly described the RSA algorithm in 1978, and its name is derived from the first letters of their last names. In the field of cryptography, it is rather amazing that an algorithm created in 1978 is still in use today.

The reason why it has lasted so long is that it can adapt to using larger keys as computing power increases. Early implementations used smaller keys such as 512 bits. These were secure for a very long time but can be cracked relatively quickly today. NIST recommended using 1024-bit keys for any data that needed to be protected through the year 2015. Beyond 2015, NIST recommends using 2048-bit keys. Security experts predict that 2048-bit keys will likely be secure until 2030. Beyond 2030, 3072-bit keys are currently recommended. However, processing power will be much greater in 2030, so applications may use 4096-bit keys instead. These recommendations are based on computing power and the likelihood that cryptanalysis techniques will be able to crack 2048-bit keys in the future.

RSA uses large prime numbers to create secure, matching public and private keys. These large prime numbers are multiplied together to create a composite number that is then manipulated to create the public and private keys. Although it’s easy to multiply the two large prime numbers together to create the composite number, it is not easy to factor the composite number to discover the original two prime numbers.

In other words, when the prime numbers are large enough, it’s not possible to use the composite number to identify them, as least not in a reasonable amount of time. The original prime numbers remain secret, and more importantly, the private key derived from these numbers remains secret. Due to the increasing speed of computers, the goal of “large enough” prime numbers has been a moving target. Similarly, the size of public and private keys has been steadily increasing to stay ahead.

Secure Sockets Layer

Secure Sockets Layer (SSL) is the original protocol used to encrypt HTTPS sessions. Version 1 was never released due to security flaws. Version 2 was released in 1995, but it also had several security flaws. Netscape released version 3 in 1996, but there wasn’t any formal method of updating it. The Internet Engineering Task Force (IETF) ultimately created Transport Layer Security (TLS) as the replacement and has been steadily updating and improving TLS over the years.

A Google security team disclosed a vulnerability with SSL named POODLE (Padding Oracle On Downgraded Legacy Encryption) in late 2014. While many organizations had already switched to TLS by this time, this announcement prompted more to do so. Soon afterward, many organizations disabled SSL in their applications, and many applications now specifically block its use.

Transport Layer Security

Transport Layer Security (TLS) version 1.0 is an upgraded version of SSLv3, and just as SSLv3 has vulnerabilities, TLSv1.0 has vulnerabilities and should not be used. TLSv1.1 was defined in April 2006 and upgraded as TLSv1.2 in August 2008. While TLSv1.1 and v1.2 initially included some backward compatibility with SSL, the IETF recommended in 2011 that this “be phased out with all due haste.” This helps eliminate potential downgrade attacks such as the POODLE attack mentioned previously.

As of mid-2018, TLSv1.3 is in draft stage. While some web browsers began implementing it as the default TLS version, some incompatibilities caused most of them to revert to TLSv1.2. This could change as TLSv1.3 goes through the draft stage and these issues are resolved.

TLS encrypts Internet transmissions as HTTPS over port 443. TLS is also used for other purposes, such as securing virtual private network (VPN) transmissions, but this section is focused on TLS’s use within HTTPS. It describes how TLS uses asymmetric encryption to share a symmetric key privately.

It’s important to realize that TLS uses both symmetric and asymmetric encryption, as follows:

•  TLS uses asymmetric encryption to share the session key privately   The public and private asymmetric keys are used to encrypt and decrypt the session key.

•  TLS uses symmetric encryption to encrypt session data   The session key is then used to encrypt and decrypt the data within the session.

Figure 14-6 shows the overall process. In this example, Bart is establishing a secure session with a web-based server, such as a web-based e-mail site. Bart establishes an HTTPS session before entering his credentials to access the e-mail, and the session ensures his credentials aren’t sent over the Internet in cleartext. As you look at the figure, you can trace the following steps:

Figure 14-6   Creating a secure HTTPS session with TLS

1. Bart initiates the process by requesting an HTTPS session. For example, he could simply click a link on a website page, such as an account logon page.

2. The server responds by sending its certificate with the server’s public key embedded within it. This public key is matched with a private key known only by the server.

3. After receiving the certificate, the client (Bart’s computer) creates a session key (which will be used as a symmetric key) that will be used later to encrypt session data. At this point, only the client knows the session key. For brevity, this discussion is using a simplistic session key of 1357, but it would be much larger in practice. For example, TLS can use a 256-bit AES key.

4. The client encrypts the session key with the server’s public key. Recall that only the matching private key (which only the server knows) can decrypt the encrypted session key.

5. The client sends the encrypted session key to the server over the Internet. Even if an attacker captures this encrypted session key, it won’t be of any use because the attacker won’t have the matching private key needed to decrypt the session key.

6. When the server receives the encrypted session key, it decrypts it with its private key. At this point, both the client and the server know the session key, but no one else knows it.

7. The session key encrypts data within the HTTPS session using symmetric encryption. If attackers intercept any of these pages, they won’t be able to read the data because they don’t have the session key. After the session ends, the client and server discard the session key. If the user initiates another HTTPS session, the two systems repeat the process. Session keys have the shortest lifespan when compared to other keys.

A logical question to ask here is why not use asymmetric encryption to encrypt the entire session. The reason is that symmetric encryption is much faster than asymmetric encryption. Depending on the algorithm used, symmetric encryption can be as much as 100 times faster than asymmetric encryption.

SSL Decryptors

An SSL decryptor (sometimes called a TLS decryptor) is placed between user systems and the Internet. Organizations often use them to decrypt TLS session traffic and examine the decrypted data. SSL decryptors can often help detect potential problems.

Imagine a user goes to a website and establishes a secure session using HTTPS. By default, the session is created between the user’s computer and the website and the data is encrypted along the entire path.

However, if you add an SSL decryptor between the user’s computer and the Internet, it will establish two TLS sessions. One session is between the user’s computer and the SSL decryptor. The second session is between the website and the SSL decryptor. These two sessions are encrypted but the data on the SSL decryptor is in an unencrypted format. The SSL decryptor can then inspect this unencrypted data for potential issues. In some scenarios, the SSL decryptor sends the unencrypted data to an intrusion detection system (IDS) for analysis.

Consider the following two issues that may not be detected without an SSL decryptor:

•  Botnet traffic   After a computer has been joined to a botnet, it will often exchange data and commands with a command and control server. This data is often encrypted in a TLS session and unreadable unless it is decrypted.

•  Drive-by downloads   When users click a malicious link, they are often taken to a server that attempts to download malware. When the session is encrypted, antimalware software won’t be able to detect the malware until it is decrypted.

In contrast, with an SSL decryptor in place, the botnet traffic and malware are likely to be detected after they are decrypted. An SSL decryptor can only decrypt TLS sessions. It can’t decrypt traffic that was encrypted on client computers outside of a TLS session.

As an example, advanced persistent threat (APT) attackers often collect data within a network, encrypt it, and then send it to an APT-controlled server. This data is typically encrypted on client computers before being sent. Even if the infected computer establishes a secure TLS session with the APT-controlled server, the SSL decryptor will see the data in an encrypted format because it was encrypted before the TLS session. However, this can still provide a warning. It isn’t common to encrypt data before encrypting it again and sending it in a TLS session.

Diffie-Hellman

Diffie-Hellman is one of the first public key algorithms used to privately share symmetric keys between two systems. Whitfield Diffie and Martin Hellman published the method in 1976, and it has been adopted in many public key algorithms. For example, TLS supports the use of Diffie-Hellman to exchange session keys.

The focus of Diffie-Hellman is on secure key exchange. As a comparison, RSA provides secure key exchange and is also a digital signature algorithm used to create digital signatures. The “Digital Signatures” section later in this chapter describes digital signatures.

Elliptic Curve Cryptography

Elliptic curve cryptography (ECC) uses a mathematically defined curve to create public and private keys. A benefit of ECC is that it provides strong security with smaller key sizes when compared to other methods such as RSA. As an example, a 256-bit ECC key provides similar strength as a 3072-bit RSA key. ECC is often used in smaller mobile devices because the smaller keys require less processing power.

Several algorithms support ECC. For example, the Elliptic Curve Digital Signature Algorithm (ECDSA) uses ECC methods for digital signatures. Similarly, elliptic curve Diffie-Hellman (ECDH) is a variant of Diffie-Hellman that uses ECC for key exchange.

Advances in quantum computing have raised some concerns about the security of ECC. Experts predict that a sufficiently strong (hypothetical) quantum computer will be able to discover keys used in public key cryptography. Because ECC uses smaller keys, ECC is likely to be a target of attackers as quantum computing capabilities increase. However, as of mid-2018, this remains theoretical because quantum computers are not sufficiently strong to solve the complex mathematical problems associated with cracking public key cryptography.

Secure Shell

Secure Shell (SSH) uses public key cryptography to encrypt data in motion. Chapter 3 discusses the use of SSH in more depth. It is a secure alternative to Telnet and similar protocols such as rlogin, rsh, and rexec, which all send credentials over a network in cleartext. Secure File Transfer Protocol (SFTP) and Secure Copy (SCP) both use SSH to encrypt the data transfers.

Protecting E-mail with S/MIME

Secure/Multipurpose Internet Mail Extensions (S/MIME) is the standard used to encrypt and digitally sign e-mail. Almost all e-mail applications that support encryption and digital signatures use S/MIME. The following sections describe how S/MIME uses digital signatures and encrypts e-mail.

Nonrepudiation

Nonrepudiation prevents individuals from believably denying they took an action. This is similar to how you cannot believably deny making a charge on your credit card if you provided your signature during the transaction. Of course, you can deny it, but your claim isn’t believable.

Electronic signatures provide another example of nonrepudiation. Mortgage companies, banks, realtors, and many other organizations use electronic signatures when sharing documents over the Internet. Electronic signatures are valid and legally binding, just as a signature made with a pen on paper is legally binding.

DocuSign is one of the companies many organizations use for online electronic signatures. Here’s how it works. A company representative uploads documents to a DocuSign site and identifies the customer that needs to sign it, using the customer’s e-mail address. The representative then marks the document where the customer needs to initial or sign it. The customer receives an e-mail with a link for the document. They agree to use the electronic signature and follow the instructions to sign and initial the document. The customer cannot later say they never received the document, because the electronic signature provides legal proof that they did.

Digital signatures (described in the next section) are another method used for nonrepudiation. Chapter 10 discussed audit logs and audit trails. When secure identification and authentication processes are in place, these audit logs and audit trails also provide nonrepudiation.

Digital Signatures

A digital signature is an encrypted hash of a message. It uses asymmetric encryption and is encrypted with the sender’s private key. Digital signatures provide several security benefits, including authentication, integrity, and nonrepudiation.

•  Authentication   The digital signature provides proof to the recipient that the claimed sender is the actual person who sent the e-mail. In this context, the digital signature provides authenticity.

•  Integrity   The e-mail is hashed before it is sent, and the hash is included with the e-mail. The recipient hashes the received message and verifies that the hashes are the same. If the hashes are the same, that verifies that the message has not been modified. In other words, it verifies the message has not lost integrity.

•  Nonrepudiation   The sender creates the digital signature with the sender’s private key. Because only the sender has the sender’s private key, the sender cannot deny sending it.

Figure 14-7 shows the overall process of creating and using a digital signature. In this example, Maggie is sending an e-mail to Lisa and using the digital signature for authentication, integrity, and nonrepudiation. As you look at the figure, you can trace the following steps:

Figure 14-7   Creating a digital signature

1. Maggie, the sender, first creates the message. In this example the message is, “A secret to success is setting goals.”

2. A hashing algorithm creates a hash from the message.

3. The hash is encrypted with the sender’s private key, creating the digital signature. As mentioned in the “Enforcing Integrity with Hashing” section earlier in this chapter, this hash provides integrity.

There are two key points to remember at this point:

• Only the sender has the sender’s private key.

• Only the sender’s public key can decrypt the encrypted hash.

4. Maggie sends both the message and the encrypted hash to Lisa, the recipient.

Note that the message isn’t encrypted as part of the digital signature. In other words, the digital signature does not provide confidentiality. However, if it is important to maintain confidentiality of the message, you can encrypt an e-mail. The “Encrypting E-mail” section later in this chapter shows the encryption process. While it is possible to encrypt and digitally sign the same e-mail message, this section focuses only on the digital signature.

When the recipient receives a digitally signed e-mail, the receiving system verifies the digital signature. Figure 14-8 shows the steps taken after a user receives a digitally signed e-mail. As you look at the figure, you can trace the following steps:

Figure 14-8   Verifying a digital signature

1. The recipient retrieves the sender’s public key by retrieving the sender’s certificate. Within an internal network (such as in a Microsoft domain), this process is automated without requiring any user interaction. In other situations, users may be required to install the sender’s certificate on their system manually. The certificate only needs to be retrieved once.

2. The digital signature is decrypted with the sender’s public key. When successful, this step shows the original hash of the message created on the sender’s system. This is an important step. It will succeed only if the sender’s private key encrypted the hash.

• If the decryption of the digital signature is successful, it proves that it was encrypted with the sender’s private key. Because only the sender has the sender’s private key, the sender must have encrypted it. This provides both authentication and nonrepudiation. The recipient knows the sender sent the message (authentication), and the sender cannot later deny sending the message (nonrepudiation).

• In contrast, if someone tried to impersonate the sender and included a bogus digital signature, this step would fail. The impersonated sender’s public key would not decrypt the digital signature, so the process would show an error.

3. The recipient’s system calculates the hash on the received message. It then compares the calculated hash with the decrypted hash from the digital signature.

• If both the received hash and the calculated hash are the same, the message has not been modified (or has not lost integrity).

• If the hashes are different, the recipient knows that the received message is not the same as the sent message. The recipient wouldn’t know how the message was modified. The differences could be due to tampering from an attacker, a problem with the network, hardware, or software, or something else. However, the recipient knows the content of the message should not be trusted.

Encrypting E-mail

You can also use asymmetric encryption to encrypt e-mail. In simplistic terms, here’s what happens:

1. The sender retrieves the recipient’s public key.

2. The sender encrypts the e-mail with the recipient’s public key.

3. The recipient decrypts the e-mail with the recipient’s private key.

Although the preceding steps simplify the process, e-mail applications implement the encryption process with some additional steps. The following explanation provides the underlying details.

In the “Transport Layer Security” section, you saw how TLS uses public key cryptography to privately share a session key and how the session key is used to encrypt the session data. E-mail encryption typically uses a similar process. The primary difference is in how the sender retrieves the certificate holding the recipient’s public key.

The certificate retrieval process is automated in many internal networks. For example, in a Microsoft domain, the user could use Microsoft Outlook to draft an e-mail similar to that shown in Figure 14-9 and click the Encrypt button. When the user clicks Send, Microsoft Outlook attempts to retrieve the certificate of the recipient based on the e-mail address. In other situations, users may be required to install the recipient’s certificate on their system manually.

Figure 14-9   Encrypting an e-mail in Microsoft Outlook

Once the sender’s system has the recipient’s certificate, it uses the steps shown in Figure 14-10 and described in the following list to encrypt the e-mail:

Figure 14-10   Encrypting an e-mail with symmetric and asymmetric encryption

1. The sender’s system creates a session key. This is similar to how TLS creates a session key. For brevity, this discussion is using a simplistic session key of 2468, but the key would be much larger in practice.

2. The sender’s system uses symmetric encryption to encrypt the e-mail with the session key.

3. The sender’s system uses asymmetric encryption to encrypt the session key with the recipient’s public key.

4. The sender’s system sends the encrypted e-mail and the encrypted session key to the recipient.

5. The recipient’s system retrieves the recipient’s private key.

6. The recipient’s system uses the private key to decrypt the encrypted session key.

7. The recipient’s system decrypts the e-mail content by using the decrypted session key.

Like the encryption process, the decryption process is automated. For example, the recipient may only need to open the e-mail to view the decrypted content.

Protecting E-mail with DKIM

DomainKeys Identified Mail (DKIM) is an e-mail authentication mechanism that helps detect e-mail spoofing. It was derived as a combination of enhanced DomainKeys created by Yahoo and Identified Internet Mail created by Cisco.

Attackers often send e-mails with forged sender addresses to trick users into thinking that the e-mails are valid. DKIM allows other e-mail servers to easily detect that these e-mails are forged.

If you get an e-mail that indicates it is from an e-mail address of [email protected], you will likely think it came from amazon.com. However, it’s a trivial matter to change the From address of any e-mail. Any attacker can change the From address, use a subject line related to an order, and ask the recipient to click a link to verify something. The link from an attacker is very likely malicious. Someone who receives this e-mail but is not an Amazon customer may accuse Amazon of sending out malicious spam, even though Amazon was not involved.

However, with DKIM, this type of forged e-mail is thwarted. An organization would first publish a DKIM DNS record. Next, it would configure its e-mail servers to attach a DKIM signature to every e-mail it sends out. Any e-mail server that receives an e-mail can match the DKIM DNS record with the signature in the e-mail. If they match, the e-mail is known to be valid. If the signature verification fails, servers send messages indicating a failure.

DKIM isn’t mandatory, so an e-mail without a DKIM signature doesn’t clearly indicate it is forged. Domain-based Message Authentication, Reporting and Conformance (DMARC) helps with this. DMARC allows organizations to publish a policy indicating if they are using DKIM, SPF, or both on outgoing e-mail. DMARC also tells a receiving server what to do if the DKIM and/or SPF methods fail, such as marking it as junk or rejecting the message.

While DKIM can use keys ranging from 512 bits to 2048 bits, RFC 6376 recommends using keys at least 1024 bits long. Mathematician Zach Harris found that many organizations use short 384-bit keys. In October 2012, he found that he could spoof these keys in as little as 24 hours on his laptop, and spoof 512-bit keys in about 72 hours using more sophisticated resources.

PGP and GPG

Pretty Good Privacy (PGP) can encrypt, decrypt, and digitally sign e-mails between individuals. PGP is an application, originally created by Philip Zimmermann, that provides confidentiality through encryption, as well as authentication, with the use of digital signatures.

For example, if you and I wanted to be able to send e-mails between each other and keep them confidential, we could use PGP. I could send you my certificate, including my public key, and you could add it to PGP running on your system. Similarly, you would send me your certificate.

PGP creates a session key, encrypts the e-mail with it, and then uses the public key to encrypt the session key. When my system receives the encrypted e-mail and the encrypted session key from you, PGP uses my matching private key to decrypt the session key and decrypts the e-mail with the decrypted session key. Of course, I could use the same process to send you an encrypted e-mail.

In addition, either of us could digitally sign our e-mails to prove that we sent them. For example, I could use PGP to create a digital signature with my private key. If you had a certificate with my public key, PGP would use it to decrypt the digital signature, providing you with assurances that it was created from my private key.

PGP started as open source software freely available to anyone. However, it has gone through several iterations of ownership and is currently proprietary software owned by Symantec.

GNU Privacy Guard (GnuPG or GPG) was later developed as a free, open source alternative to PGP. It complies with the specification for OpenPGP defined in RFC 4880.

A significant difference between S/MIME, PGP, and GPG is how certificates are validated. Remember that a certificate has a public key and is freely shared. This public key is matched to a private key held by the certificate owner. S/MIME uses a centralized certificate authority within a PKI. Certificate authorities and PKI systems are described in more detail in the “Understanding Public Key Infrastructure Systems” section.

PGP and GPG use a decentralized web of trust (WOT). In a WOT, several individuals vouch for the trustworthiness of certificates. When enough people indicate that the certificate is trustworthy, others trust it. A WOT is also discussed in more detail in the “Understanding Public Key Infrastructure Systems” section to provide a better comparison between a centralized PKI and a decentralized WOT.

Other Encryption Schemes

Many encryption schemes fit neatly into the symmetric or asymmetric categories, but a few fall outside the scope of these categories. For example, cryptographers can use steganography to manipulate files and embed detailed messages within them. However, steganography simply hides the data within the file. IPsec is another encryption scheme that doesn’t fit neatly into the symmetric and asymmetric categories, but it is important in the context of cryptography.

Steganography

Steganography is the practice of hiding data within data or hiding data in plain sight. It doesn’t actually encrypt the data, but it can provide a level of confidentiality. If others know that the message is embedded in the data, they can retrieve it.

As an example, some programs modify the least significant bit of individual bytes within a file. For example, consider the byte represented in Table 14-3. The value of the byte is 255 (eight 1’s), but if you modify the value of the least significant bit (2⁰), the new value is 254. If this value is used to represent the tint of a color or one of the values in a sound file, the change between 255 and 254 is so slight that it is indistinguishable.

Table 14-3   Modifying the Least Significant Bit

If someone modified the last bit of each byte in a 1MB file, he or she could embed a message in these 1 million bits. As an example, the letter A is represented in hexadecimal as 41 and binary as 0100 0001. A person could embed the letter A by ensuring the least significant bit in 8 bytes in a row includes these bits as the least significant bit in each of the 8 bytes.

Table 14-4 shows the least significant bit from 8 bytes in a graphics file. To embed the letter A in these bytes, a steganography tool ensures that the last bit in these 8 bytes is 0100 0001. Notice that the first byte ends with a 1, so it is changed to a 0. The second byte ends in a 1, so it doesn’t need to be changed. The steganography tool would change the last bit in bytes 1, 4, and 7, and leave the other bits the same. This shows how you can embed the letter A in a file. It’s possible to repeat this process for a full message.

Table 14-4   Embedding the Letter A

The changes are not distinguishable to most users. However, when people know what to look for, they will be able to find and read the message. For example, it’s possible for someone in one country to post a picture on a website with an embedded message and enable someone in another country to retrieve the picture and read the message.

While most people will overlook the hidden message, security professionals use steganalysis techniques to detect the use of steganography. A common method is the use of hashing. If you have a hash of the original file, you can create a hash from the modified version. If the two hashes are different, it indicates that the file has been modified and may have a hidden message embedded within it. Additional tools allow experts to analyze the bytes within the file to detect the message.

IPsec

Chapter 3 introduces Internet Protocol security (IPsec) and explains how IPsec provides security for data traveling over a network. The two protocols within IPsec are Authentication Header (AH) and Encapsulating Security Protocol (ESP). AH provides authentication and integrity, while ESP provides confidentiality, authentication, and integrity. You can use AH alone, ESP alone, or both protocols together.

AH provides data origin authentication by assuring both systems of the identity of the other system. It creates a hash derived from packet data and uses this hash to provide integrity in addition to authentication. AH does not encrypt the data or provide confidentiality.

ESP encrypts the data within the packets to provide confidentiality. Although it’s possible to configure ESP without integrity, it is not recommended. In other words, when you use ESP for encryption, you will also include the same features provided by AH (authentication and integrity).

Chapter 4 presents IPsec as a tunneling protocol for VPNs. IPsec can be used with Layer 2 Tunneling Protocol (L2TP/IPsec) or by itself to create a secure connection between a VPN client and a VPN server.

Understanding Public Key Infrastructure Systems

A public key infrastructure (PKI) includes all the components necessary to create, manage, distribute, validate, and revoke certificates. The “Exploring Asymmetric Encryption” section earlier in this chapter explained the use of public and private keys to encrypt information and digitally sign e-mails. The PKI provides the necessary support for these processes, including distributing public keys in digital certificates.

Although you aren’t expected to create and manage a PKI for the SSCP exam, you should understand the basic components. This section covers certificates, certificate authorities (CAs), and certificate validation.

Certificates

The “Exploring Asymmetric Encryption” section earlier in this chapter presented some information on certificates. For example, Figure 14-5 showed a certificate with the public key selected. Although the distribution of the public key is an important purpose of certificates, they do have many other uses. Figure 14-11 shows a certificate from VeriSign with multiple purposes.

Figure 14-11   Certificate with multiple purposes

The following are some of the common purposes of certificates:

•  Authentication   Certificates can prove the identity of users and computers. For example, smart cards have embedded certificates used to prove the identity of the user. Remote systems can prove their identity to your system, and your system proves its identity to remote systems with the use of certificates.

•  Encryption   Certificates can be used to assist with encryption. For example, the public and private keys encrypt a symmetric key so that it can be privately shared.

•  Protecting e-mail   This protection includes both encryption and digital signatures.

•  Code signing   Applications and scripts can be digitally signed. This provides authentication of the developer and integrity for the code. If the code is modified (such as with malware), the signature embedded in the certificate will no longer match.

•  Wildcard   A wildcard certificate can be used for multiple domains that share a common root domain and start with an asterisk (*). As an example, a single wildcard certificate of *.getcertifiedgetahead.com can be used for blogs.getcertifiedgetahead.com and training.getcertifiedgetahead.com.

•  Domain validation   A domain-validated certificate indicates that the certificate requestor has some control over the DNS domain associated with the certificate. This control can be validated by responding to an e-mail or publishing a DNS record.

•  Extended validation   An extended validation certificate provides additional validation beyond a domain-validated certificate. Before issuing the certificate, the CA takes additional steps to verify the requesting entity’s identity. Web browsers display the company name next to the URL or instead of the URL.

When entities want a certificate, they provide the required information to a CA in the form of a request. The CA embeds this information in the certificate.

Figures 14-12, 14-13, and 14-14 show the different tabs of a certificate, giving you an idea of the information that is available. Figure 14-14 shows that GlobalSign issued this certificate to www.gcgapremium.com.

Figure 14-12   Viewing the General tab of a certificate

Figure 14-13   Viewing the Details tab of a certificate

Figure 14-14   Viewing the Certification Path tab of a certificate

Certificates include the following information:

•  Who it was issued to (such as a website, a server, or a user)

•  Who issued it (the CA)

•  Validity dates (which allow the certificate to expire)

•  Serial number (used to uniquely identify the certificate)

•  Public key (matched to a private key that is not included in the certificate)

•  A certification path showing the trust chain of the certificate to the root CA

Certificate Authority

A CA issues and manages certificates through their lifetimes. CAs can be public (such as VeriSign) or private within an organization. Public CAs sell and validate certificates and provide assurances to users that certificates are valid.

For example, if you wanted to do business on the Internet via your own website, you could purchase a certificate from a public CA to create a secure HTTPS session. Then when a customer wanted to make a purchase, your website would send the certificate to the customer’s computer to initiate the secure session.

First, you would create a matching public key and private key. Many applications are available to create these matching keys. You would then send the public key and other required information to the CA. The CA would create the certificate and send it back to you, and you would then use it to configure your website.

It’s also possible to create a private CA and issue certificates internally. The benefit is that the organization with a private CA doesn’t need to purchase certificates from a public CA. However, the drawback is that certificates issued by a private CA aren’t trusted by default. If external clients receive these certificates, they will receive an error indicating that the certificate is not trusted.

Understanding the Certificate Trust Chain

An important part of the PKI is the trust chain, also known as a hierarchy of trust. For example, if you look back to Figure 14-14, you can see that the Certification Path tab shows two levels. GlobalSign is the top level and in this example is the root CA. The root CA issues certificates to other CAs in the trust chain, known as intermediate CAs.

In Figure 14-14, GlobalSign Domain Validation CA SHA256 - G2 is an intermediate CA. The intermediate CA then issued a certificate to www.gcgapremium.com. Systems that trust the root CA or the intermediate CA will automatically trust the certificate issued to www.gcgapremium.com.

As long as one of the CAs in the certificate trust chain is trusted, certificates issued by the CAs are also trusted. For example, if the root CA is trusted, certificates issued by any of the CAs in the trust chain are also trusted.

Understanding Trusted Root Certification Authorities

You may be wondering how a CA is trusted. The primary method is by installing certificates from the root CA onto a system’s trusted certificate authorities store. For example, Figure 14-15 shows the Trusted Root Certification Authorities store for a Windows 7 system. Certificates in this store are from root CAs, and each certificate represents a certificate trust chain. Any certificate issued by any CA in this trust chain is automatically trusted.

Figure 14-15   Trusted root certification authorities store

This is similar in concept to a driver’s license issued by a Department of Motor Vehicles (DMV). If you need to prove your name or age, you can show your driver’s license. Because people trust that the DMV has verified your information before giving you a driver’s license, and your driver’s license was issued by the DMV, most people trust the validity of your driver’s license. On the other hand, if you bought an identification card from Darril’s Cheap IDs, many people may question the validity of information on that ID card.

The root CA is similar to the DMV. Any certificates issued by the root CA are trusted because the root CA is trusted, just as licenses issued by the DMV are trusted because the DMV is trusted.

Revoking Certificates

Most certificates will have a lifetime identified in the validity dates. However, in some situations the certificate is revoked before it expires. For example, the CA will revoke the certificate if the matching private key of a certificate is compromised. The CA maintains a list of all revoked certificates in a certification revocation list (CRL) and publishes the CRL as a V2 certificate. Most other certificates are V3 certificates. The CRL lists the serial numbers of certificates revoked by the CA.

Certificates include a list of CRL distribution points. Clients can request a copy of the CRL through these distribution points and verify that the certificate they are using is not listed on the CRL. This verification is often done as part of the normal process of validating a certificate.

Validating Certificates

When systems receive certificates from a website, they go through several checks to ensure that the certificate is valid. Figure 14-16 shows the overall steps that occur, which are as follows:

Figure 14-16   Validating a certificate

1. The user requests the HTTPS session.

2. The server responds with the certificate.

3. The user’s system examines the certificate. It ensures that the certificate hasn’t expired (based on the validity dates) and ensures that the website that issued the certificate is the same as the one identified in the certificate. It will also ensure that a CA in the certificate trust chain is trusted.

4. The user’s system checks with the CA to ensure that the certificate has not been revoked. A common method is by requesting a copy of the CRL through a CRL distribution point. If the CRL includes the serial number of the certificate provided by the website, the client system knows the CA has revoked the certificate and it shouldn’t be trusted.

Another method of checking to see whether the certificate is revoked is with the Online Certificate Status Protocol (OCSP). The client system first identifies the serial number of the certificate received from the website. Then, instead of requesting a copy of the CRL, the client sends the serial number to a server known as an OCSP responder (maintained by the CA). The OCSP responder identifies the health of the certificate with an answer of “good,” “revoked,” or “unknown.” A response of “unknown” might indicate the certificate is a forgery. The benefit of OCSP over a CRL is that the entire CRL doesn’t need to be transmitted.

If any of these checks fails, the user will see an error indicating what check failed. The errors are different based on the browser that the user is using.

Key Escrow

Key escrow refers to storing a copy of a private key for safekeeping or creating an alternative key to be used if necessary. The key can be retrieved if the original key is lost or unavailable. As an example, if an employee encrypts data and then leaves the organization, the data may not be accessible if the organization hasn’t enabled a key escrow method.

Recovery agents are the individuals authorized to recover keys held in escrow. Typically, keys held in escrow are kept within the organization. However, there are some situations where the keys are held in escrow by a third party. If the keys are kept within the organization, the recovery agent is someone within the organization. If the keys are held by a third party, the recovery agent is typically someone in the third-party organization.

Alternative Certificate Trusts

The “Understanding the Certificate Trust Chain” section described a hierarchical trust chain, which provides centralized certificate management. A hierarchical trust chain allows CAs to issue certificates and for entities to verify the certificates are valid. For example, imagine a client trusts a root CA. The client will automatically trust certificates from the root CA or any intermediate CAs in the trust chain. Additionally, the client can validate the certificate by either retrieving the CRL or using OCSP. However, this isn’t the only type of trust.

Two additional trust methods are a web of trust and a cross-certification trust.

Web of Trust

A web of trust (WOT) is a decentralized trust model allowing anyone to create self-signed certificates. Because a person who creates a self-signed certificate also signs the certificate, it isn’t possible to easily validate its authenticity. A web of trust provides one way to solve this problem and is used with PGP and GPG (described earlier in this chapter) for encryption and digital signatures.

As a simple example, imagine that Lisa, Homer, Marge, and Bart each create their own self-signed certificates to encrypt e-mails and create digital signatures. They exchange these certificates with each other and ask everyone in their group to trust them. This is a web of trust.

Later, Lisa and Krusty exchange certificates and start exchanging secure e-mails. Lisa chooses to trust Krusty’s certificate and could introduce Krusty’s certificate to the group, encouraging everyone to trust it. If Bart (or anyone else in the web of trust) sends a certificate to Krusty, Krusty might not trust it because Bart is unknown to him. However, because Lisa trusts it, this might be enough for Krusty to trust it.

In the early days of PGP, its biggest challenge was the distribution of certificates. Phil Zimmermann, the creator of PGP, recognized that there wasn’t a reliable method of proving identities. He introduced the web of trust concept in an early manual for PGP. Admittedly, the details are more technical than described in the example with Lisa’s group, but the concept is similar. Designated individuals are authorized to introduce certificates to the web of trust. If enough people trust a certificate, it provides a level of assurance. For example, if six of your friends trust a certificate, you might choose to trust it.

With OpenPGP, users can digitally sign other OpenPGP identity certificates to endorse them. As an example, if you know me, you can digitally sign my certificate to endorse it. Similarly, if I know you, I can digitally sign your certificate to endorse it. When a certificate has enough endorsements, other users can choose to trust it. In some cases, merely having the endorsement of a key individual may be enough to trust it. For example, if you are well-known in cybersecurity circles and you have digitally signed my certificate, someone else may choose to trust my certificate based on your endorsement.

Cross-Certification Trust

Cross-certification allows organizations with a private PKI and private CA to trust entities in another private PKI. As an example, imagine that Globex Corporation has created its own PKI to issue and manage certificates for Globex employees. Similarly, imagine that the Springfield University has created a private PKI for its students, staff, and faculty. By default, these certificates are not trusted outside the organization. If an employee at Globex sends a certificate to someone at Springfield University, it creates errors because the certificate isn’t trusted and cannot be validated.

However, if the two organizations create a cross-certification agreement, it creates a mutual trust relationship. Users in both organizations automatically trust the certificates from the other organization. A cross-certification agreement will also implement methods allowing systems to validate the certificates.

Comparing Cryptanalysis Attacks

Cryptanalysis is the process of deciphering codes through analysis to compromise the confidentiality or integrity of data. Authorized users of encrypted data have the tools to decrypt and access data when needed. However, unauthorized users need to use cryptanalysis to decrypt and access the data.

Most cryptographic algorithms are published, allowing anyone to study them. Security experts often perform cryptanalysis on protocols to identify weaknesses based on new data available. As an example, SSL was thought to be secure for many years. However, a security team at Google discovered a significant vulnerability and published a paper on the POODLE attack in late 2014. This prompted many organizations to switch over to TLS sooner than they might have otherwise done. Similarly, the federal Canadian Cyber Incident Response Centre issued a security bulletin about the Heartbleed bug in April 2014 that affected many sites using specific versions of OpenSSL.

If vulnerabilities don’t exist in the algorithm, attackers often look for weak keys or poorly implemented keys. For example, one of the core rules related to stream ciphers is to never reuse keys. If a protocol ignores this rule, the protocol is easier to crack. This emphasizes the importance of following fundamental key-management concepts.

Fundamental Key Management Concepts

While SSCPs are not expected to design encryption algorithms, (ISC)² does expect you to understand some of the underlying concepts, especially related to the use of keys. Some of these concepts were covered in more depth earlier in this chapter but are included here as a summary.

•  Key rotation   Key rotation refers to periodically replacing an old key with a new key. This is similar in concept to changing a password regularly. The length of time between using a different key varies for different algorithms. However, the important point here is that keys should be changed regularly.

•  Key composition   Key composition refers to creating strong keys. Strong keys are random and of sufficient length that they cannot be guessed. The length of the key varies for different algorithms. For example, AES-256 uses 256-bit keys and is very strong. However, the use of 256-bit keys for RSA is very weak. Instead, strong RSA keys are typically 2048 bits in length.

•  Key creation   Keys should be random. Most algorithms include code to ensure keys are random.

•  Key exchange   Keys should be exchanged in a secure manner. It’s common to exchange symmetric keys using asymmetric cryptography.

•  Key revocation   The cryptography method should include a method of revoking compromised keys and informing users when a key has been revoked. Within a PKI, users can verify if a key is valid using a CRL or with OCSP.

•  Key escrow   Key escrow ensures that encrypted data can be retrieved even if the original key is somehow lost.

Known-Plaintext Attack

A known-plaintext (or known-text) attack is possible when the attacker has samples of both plaintext and ciphertext data. For example, if an attacker has plaintext from an encrypted message, the attacker can then use different methods to try to decrypt the ciphertext to the known text. If the known text is decrypted, the same method can be used to decrypt similar data.

The chosen-plaintext attack is a variant of the known-plaintext attack. In this attack, the cryptanalyst doesn’t have access to all of the plaintext but either has access to some plaintext or is able to predict plaintext that is included in the ciphertext. For example, if messages are frequently preceded with the phrase “From:” then the analyst can assume that “From:” is the known plaintext and use this information in the attack.

Ciphertext-Only Attack

In contrast, a ciphertext-only attack is one where the attacker has only ciphertext for analysis without any useful information about the plaintext data. If the attacker can discover any of the plaintext by analyzing the ciphertext, the attack is successful.

This type of attack is usually successful only when weak cryptographic methods are used. For example, if the same key is used for too long a period, or the key isn’t protected, or a weak key is used, it makes it much easier for an attacker to break the code. WEP was cracked using a ciphertext-only attack due to poor key-management techniques used with WEP (among other vulnerabilities).

Hashing and Collisions

A hash collision occurs when two different inputs to a hashing function produce the same hash. A hash collision is not possible in a sufficiently strong hashing algorithm. However, as computing power has grown, methods have been identified that create collisions with algorithms previously thought to be secure.

As an example, security experts have successfully used hash collision attacks on MD5 and SHA-1. This is a significant vulnerability and one of the reasons these two hashing functions are no longer recommended for use.

Researchers identified collisions with MD5 in 1996. In 2005, researchers were able to create pairs of documents and pairs of certificates with the same hash. In 2012, Microsoft reported that attackers used an MD5 collision to forge a Windows code-signing certificate.

SHA-1 was thought to be vulnerable to collisions since 2005, though researchers didn’t successfully create a collision until 2017. They spent two years developing the technique and used multiple computers and processors working together performing over 9 quintillion computations (about 1 million trillion computations). It would equate to about 6,500 years of CPU time if a single computer were used. A well-funded attacker could use multiple computers each with multiple cores, to shorten the time required to create a SHA-1 collision.

Countermeasures Against Cryptanalysis Attacks

The primary protection against cryptanalysis attacks is to use strong algorithms and follow fundamental key management practices. Both are moving targets.

Strong algorithms from 2001 are not necessarily strong algorithms in 2018. Similarly, strong algorithms in 2018 won’t necessarily be strong in 2030. When security experts identify vulnerabilities in cryptographic algorithms and recommend taking them out of use, IT personnel should do so as soon as possible.

The “Fundamental Key Management Concepts” section in this chapter covered the importance of using strong keys. It also covered management concepts such as rotating keys regularly, exchanging them securely, and ensuring there are methods to revoke them when they are compromised.

Chapter Review

Cryptography provides several important security benefits. You can encrypt data to prevent the loss of confidentiality, and you can use hashing algorithms to help ensure integrity. Many encryption and hashing protocols also provide authenticity, providing assurances that data is coming from a known source and is valid or reliable.

Organizations use cryptographic methods to secure sensitive data. In general, all nonpublic data should be encrypted to help ensure its protection. Additionally, regulations require organizations to protect certain data, such as personally identifiable information (PII) and protected health information (PHI). Encryption is a primary method of doing so.

Hashing provides one-way encryption to create a fixed-length hash (a number) from a file or message of any size. The created hash will always be the same as long as the file or message has not been modified. By comparing hashes at different times (such as before and after downloading a file), you can tell whether the original data has been modified or has lost integrity. If the hashes are the same, the data has not lost integrity. Message Digest 5 (MD5) and Secure Hashing Algorithm 1 (SHA-1) have been popular hashing algorithms, but both have been cracked and should not be used. NIST recommends the use of SHA-3, which can create hashes of 224, 256, 384, or 512 bits.

Encryption converts plaintext data into ciphertext data. The two primary categories of encryption are symmetric encryption and asymmetric encryption.

Symmetric encryption uses a single key to encrypt and decrypt data. Keys used with symmetric encryption need to be protected and changed often. If the key is not protected, an attacker can use it to decrypt the data.

Advanced Encryption Standard (AES) is a strong, efficient symmetric encryption algorithm. NIST identified it in 2002 as a standard to be used by the U.S. government agencies, and it has been adopted in many different commercial applications. AES can use key sizes of 128 bits (AES or AES-128), 192 bits (AES-192), or 256 bits (AES-256). AES is the designated replacement for Data Encryption Standard (DES). DES has been cracked and is not recommended for use today. Other symmetric encryption algorithms include 3DES, Blowfish, International Data Encryption Algorithm (IDEA), and RC4 (though RC4 is not recommended for use today).

Asymmetric encryption uses two keys (a public key and a private key) created as matched pairs. Information encrypted by one of the keys can only be decrypted with the matching key. The public key is embedded in a certificate and freely shared, but the private key always remains private. RSA is used for asymmetric encryption and employs large prime numbers to create matching public and private keys. Transport Layer Security (TLS) uses asymmetric encryption to share a symmetric key privately, and then it uses symmetric encryption to encrypt session data.

Secure/Multipurpose Internet Mail Extensions (S/MIME) is a popular standard used to protect e-mail. It supports encryption and digital signatures. Digital signatures are created by hashing an e-mail message and then encrypting the hash with the sender’s private key. The recipient uses the sender’s public key to decrypt the hash, and if the decryption succeeds, the digital signature provides authentication, integrity, and nonrepudiation. DomainKeys Identified Mail (DKIM) helps detect e-mail spoofing by verifying the e-mail was sent by an authorized mail server.

Two other encryption schemes include steganography and Internet Protocol security (IPsec). Steganography is the practice of hiding data within data. IPsec is used to secure data going over a network and uses Authentication Header (AH) and Encapsulating Security Protocol (ESP). AH provides authentication and integrity, and ESP provides authentication, integrity, and confidentiality.

A public key infrastructure (PKI) includes all the components needed to issue and manage certificates, which follow the X.509 standard. The certificate authority (CA) issues the certificates. Certificates have expiration dates, but the CA can revoke the certificate earlier if necessary, such as if the matching private key is compromised. The CA publishes a list of revoked certificates by serial number in a certificate revocation list (CRL). Clients can request a copy of the CRL to validate a certificate. The Online Certificate Status Protocol (OCSP) is an alternative method used to validate certificates. The first CA in a certificate trust chain is called the root CA. If the root CA is trusted, all certificates issued by any CAs in the trust path are also trusted.

S/MIME depends on a centralized PKI for certificates. Pretty Good Privacy (PGP), GNU Privacy Guard (GPG), and OpenPGP are alternatives to S/MIME and can use a decentralized web of trust (WOT). A WOT allows individuals to create their own self-signed certificates and share them. When enough people endorse a certificate, it indicates a high level of trust that it is valid.

Cryptanalysis is the process of deciphering codes through analysis. Two common cryptanalysis attacks are a known-plaintext attack and a ciphertext-only attack. A known-plaintext (or known-text) attack is possible when the attacker has samples of both plaintext and ciphertext data. A ciphertext-only attack is one where the attacker has only ciphertext for analysis.

A hash collision occurs when two different inputs to a hashing function produce the same hash. When collisions are possible, it indicates the hashing function is not secure and should not be used.

Common countermeasures against cryptanalysis attacks start with using known strong algorithms. When flaws are found, organizations should replace older algorithms with recommended replacements. Additionally, organizations should ensure that they are implementing common key management concepts. This includes using strong keys, rotating them as recommended, exchanging them securely, and revoking them when they are compromised.

Questions

1.  What basic security function does asymmetric encryption provide?

A.  Integrity

B.  Authentication

C.  Confidentiality

D.  Availability

2.  Which of the following choices allows you to verify that a file has not been modified?

A.  AES

B.  SHA

C.  PKI

D.  IDEA

3.  Which of the following choices provides one-way encryption of data?

A.  Symmetric

B.  Asymmetric

C.  Transport Layer Security

D.  Hashing

4.  Which of the following uses a single key to encrypt and decrypt data?

A.  Symmetric

B.  Asymmetric

C.  Public key cryptography

D.  SHA-1

5.  Which of the following keys is changed the most often?

A.  Public key

B.  Private key

C.  Symmetric key

D.  Session key

6.  Which of the following are used primarily for symmetric encryption? (Select all that apply.)

A.  AES

B.  Blowfish

C.  3DES

D.  RSA

7.  Which of the following is a symmetric 128-bit block cipher?

A.  Data Encryption Standard (DES)

B.  Triple Data Encryption Standard (3DES)

C.  Advanced Encryption Standard (AES)

D.  Blowfish

8.  Of the following choices, which one is considered a strong, efficient symmetric encryption algorithm?

A.  TLS

B.  DES

C.  3DES

D.  AES

9.  What type of cryptography does public cryptography use?

A.  Asymmetric encryption

B.  Symmetric encryption

C.  Steganography

D.  One-way functions

10.  Which of the following is an accurate statement related to asymmetric encryption?

A.  It is used to privately share a private key.

B.  It is used to privately share a public key.

C.  It is used to privately share a secret key.

D.  It is faster than symmetric encryption.

11.  What is a common standard used to encrypt and digitally sign e-mail?

A.  Symmetric encryption

B.  S/MIME

C.  TLS

D.  Steganography

12.  Of the following choices, what does a digital signature provide when it is used with e-mail? (Select all that apply.)

A.  Authentication

B.  Integrity

C.  Confidentiality

D.  Nonrepudiation

13.  What is used to create a digital signature used with e-mail?

A.  The public key of the sender

B.  The private key of the sender

C.  The public key of the recipient

D.  The private key of the recipient

14.  Which of the following would most likely be used to encrypt data in an e-mail message before it is sent?

A.  The public key of the sender

B.  The private key of the sender

C.  The public key of the recipient

D.  The private key of the recipient

15.  Someone has embedded a secret code within a picture used on a web page. What is the best description of this?

A.  Symmetric encryption

B.  Asymmetric encryption

C.  Hashing

D.  Steganography

16.  How are public keys distributed to clients from Internet websites?

A.  As e-mail attachments

B.  Embedded in certificates

C.  As cookies

D.  Embedded in the HTML code for the page

17.  How are public keys shared with other entities?

A.  Published in a certificate

B.  Encrypted by a private key

C.  Encrypted by a session key

D.  Public keys are not shared

18.  A website sent a user a certificate to initiate a secure web session over the Internet. Of the following choices, what information would be in the certificate? (Select all that apply.)

A.  Name of the website

B.  Name of the issuing CA

C.  Private key

D.  Expiration date

19.  Of the following choices, what is used to determine whether a certificate has been revoked?

A.  OCSP

B.  Digital signature

C.  CARL

D.  Trust chain

20.  Researchers are attempting to discover weaknesses in an encryption algorithm using a known-plaintext attack. What is this called?

A.  Cryptography

B.  Cryptanalysis

C.  Criminal behavior

D.  Hashing

Answers

1.  C. Encryption (any type of encryption, including both asymmetric and symmetric encryption) provides confidentiality for data. Hashing methods provide integrity. Authentication proves the identity of a user or system. Availability ensures that systems and data are available when needed.

2.  B. Secure Hashing Algorithm (SHA) is a hashing algorithm, and hashing is a key method of ensuring integrity (or verifying a file has not been modified). SHA-3 should be used instead of SHA-1 and SHA-2. The hash is calculated at two different times, and if the hash is the same, the file has not been modified. Advanced Encryption Standard (AES) is a strong symmetric encryption protocol. A public key infrastructure (PKI) is used to support the creation, management, and distribution of certificates. International Data Encryption Algorithm (IDEA) is an older symmetric encryption protocol.

3.  D. Hashing algorithms use a one-way encryption method to create a hash from the data. They are also known as one-way functions. The hashing algorithm creates a fixed-length hash from a file, but the hash cannot be used to re-create the file. Symmetric encryption and asymmetric encryption are both two-way, because data can be encrypted and decrypted. Transport Layer Security (TLS) is widely used to encrypt Internet traffic and uses both symmetric and asymmetric encryption.

4.  A. Symmetric encryption uses a single key to encrypt and decrypt data. Asymmetric encryption uses two keys (a public key and a private key) to encrypt and decrypt information and is often referred to as public key cryptography. Secure Hashing Algorithm 1 (SHA-1) is a hashing algorithm and it doesn’t use a key.

5.  D. A session key is only used for a session (such as a web browsing session) and is changed more often than the other keys. Public and private keys typically last for a year or longer. Symmetric encryption uses a symmetric key (also called a secret key), which can stay the same for a specific piece of data as long as the data remains encrypted. While a session key is a symmetric key, all symmetric keys are not session keys.

6.  A, B, C. Advanced Encryption Standard (AES), Blowfish, and Triple DES (3DES) are all used for symmetric encryption. RSA is an asymmetric encryption standard using public and private keys and is widely used with Transport Layer Security (TLS). The other choices are all symmetric encryption standards using a single key to encrypt and decrypt the data.

7.  C. AES is a 128-bit block cipher. All of the other answers are 64-bit block ciphers.

8.  D. The Advanced Encryption Standard (AES) is considered a strong, efficient symmetric encryption algorithm and it is widely used. DES is an older algorithm that has been cracked. 3DES is strong but takes more processing power and is less efficient than AES. Transport Layer Security (TLS) uses both symmetric and asymmetric encryption, and calling it a symmetric encryption algorithm is inaccurate.

9.  A. Public key cryptography uses asymmetric encryption with two matched keys (a public key and a private key) to encrypt and decrypt information. Symmetric encryption uses a single key (often called a session key) to encrypt and decrypt data. Steganography hides data within data. Hashes are also known as one-way functions and they provide integrity.

10.  C. Asymmetric encryption is used to privately share a secret key (or session key). Asymmetric encryption uses a matched pair of keys known as a private key and a public key. The private key is never shared, and the public key is publicly shared in a certificate. Symmetric encryption is faster than asymmetric encryption.

11.  B. Secure/Multipurpose Internet Mail Extensions (S/MIME) is the standard used to encrypt and digitally sign e-mail. Symmetric encryption uses a single key to encrypt and decrypt data but cannot digitally sign e-mail. Transport Layer Security (TLS) encrypts data sent over a network and is used with HTTPS. Steganography is the practice of hiding data within data or in plain sight.

12.  A, B, D. A digital signature provides authentication, integrity, and nonrepudiation. It does not provide confidentiality because the digital signature does not encrypt the data. It is possible to digitally sign an e-mail without encrypting it.

13.  B. A digital signature is created by hashing a message and encrypting the hash with the sender’s private key. The recipient can then decrypt the hash with the sender’s public key. The recipient’s keys are not used for a digital signature, but they are used to encrypt and decrypt e-mail.

14.  C. E-mail is encrypted using the recipient’s public key. The recipient’s public key actually encrypts a symmetric key and uses the symmetric key to encrypt the e-mail. The recipient uses the recipient’s private key to decrypt the symmetric key and then decrypts the message with the symmetric key. The sender’s keys are not used to encrypt or decrypt e-mail.

15.  D. Steganography is the practice of hiding data within data, such as embedding a secret code within a picture. Symmetric encryption uses a single key for encryption and decryption of data, while asymmetric encryption uses two keys (a public key and a private key) for encryption and decryption. Hashing creates a hash that can be used for integrity.

16.  B. Public keys are embedded in certificates and distributed to clients in the certificate. Although users can send certificates to each other as e-mail attachments, a website does not use this method. Public keys are not included in cookies or in HTML code.

17.  A. Public keys are published in certificates. They are never encrypted. They are shared so that other entities can use them for asymmetric encryption.

18.  A, B, D. The certificate would include the name of the website, the name of the CA that issued the certificate, the expiration date of the certificate, and more. While the certificate would include a public key, it would not include the private key. The private key would be kept private on the server.

19.  A. The Online Certificate Status Protocol (OCSP) is used to verify the health of a certificate. An OCSP responder will indicate whether a certificate has been revoked when queried with the certificate’s serial number. A digital signature uses certificates but doesn’t determine whether a certificate is revoked. CAs issue a certificate revocation list (CRL), but CARL isn’t a valid acronym in the context of checking certificates. A trust chain determines if the CA that issued the certificate is trusted but it doesn’t indicate if a certificate is revoked.

20.  B. Cryptanalysis is the process of deciphering codes through analysis, and a known-plaintext attack is one method of cryptanalysis. Cryptography is the science of using different methods and techniques to encrypt data. It is not criminal to search for weaknesses, but the action taken after these weaknesses are discovered can be criminal. Hashing is the process of creating a hash from a file or a message with a hashing algorithm, and it is used to prevent the loss of integrity.