Seeing as how a lot of security is based on cryptography, it makes sense that you need to understand cryptography and PKI for the COMPTIA Security+ certification. Cryptography ubiquitous in computing and is involved in:
- Data Integrity: Provides assurances that data has not been modified through hashing, a number derived from performing a calculation on data, such as a message, patch, or file;
- Hashing creates a fixed-size string of bits or hexadecimal characters, which cannot be reversed to re-create the original data.
- Confidentiality: Ensures data is only viewable by authorized users as encryption scrambles, or ciphers, data to make it unreadable if intercepted.
- Symmetric encryption uses the same key to encrypt and decrypt data.
- Asymmetric encryption uses two keys (public and private) created as a matched pair, requires a Public Key Infrastructure (PKI) to issue certificates.
- 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.
- Stream ciphers encrypt data 1 bit at a time.
- Block ciphers encrypt data in blocks.
- Steganography provides a level of confidentiality by hiding data
within other files.
- Authentication: validates an identity.
- A digital signature provides authentication, non-repudiation, and integrity.
- Non-repudiation prevents a party from denying an action.
- Users sign emails with a digital signature, which is a hash of an email message encrypted with the sender’s private key.
- Only the sender’s public key can decrypt the hash, providing verification it was encrypted with the sender’s private key.
Read more on the topic:
How Hashing Ensuring Data Integrity
Hashing, which runs data through an algorithm to produce a number called a hash or checksum is used to verify data integrity by confirming that data was not modified, tampered with, or corrupted; no matter how many times you execute the hashing algorithm against the same data, the hash will always be the same if the data is the same.
Hashes are created at least twice so that they can be compared. When a developer releases an application that customers can download, they calculate the hash of the patch and post both a link to the patch file and the hash on their site. Customers can download the file and then calculate the hash on the downloaded file. If the calculated hash is the same as the hash posted on the web site, it verifies the file has retained integrity.
While rare for executable files to be modified, some malware modifies executable files by adding malicious code into the file. Rootkits will often modify system-level files.
Some host-based intrusion detection systems (HIDSs) and antivirus software capture hashes of files on a system when they first scan it and include valid hashes of system files in signature definition files. When they scan a system again, they can capture hashes of executable and system files and compare them with known good hashes. If the hashes are different for an executable or system file, it indicates the file has been modified, and it may have been modified by malware.
Common Hashing Algorithms
The table below summarizes the common hashing algorithms as well as their general use case.
| Algorithm | Use Case | Output |
|---|---|---|
| MD5 | Hashing – Integrity | 128 bit hash |
| SHA -1 | Hashing – Integrity | 160 bit hash |
| SHA -2 | Hashing – Integrity | 224/256/384/512 hash |
| SHA – 3/Keccak | Hashing – Integrity | 224/256/384/512 hash |
| MHAC – MD5 | Hashing – Integrity/Authenticity | 128 bit hash |
| HMAC – SHA1 | Hashing – Integrity/Authenticity | 160 bit hash |
Message Digest 5 (MD5): In use since 1992 as an encryption algorithm, vulnerabilities were found in MD5 in 2004 and as the processing power of computers increased, it became easier and easier to exploit these vulnerabilities so security experts discourage its use. It is still used to verify the integrity of files as a hashing algorithm, which creates a 128-bit hash shown in hexadecimal format (32 hexadecimal characters) instead of a stream instead of 128 bits of 1s and 0s. Hexadecimal characters are composed of 4 bits and use the numbers 0 through 9 and the characters a through f.
Secure Hash Algorithm (SHA): Another hashing also used to verify file integrity and comes several variations :
- SHA-0: Not used.
- SHA-1: Similar to the MD5 hash except that it creates 160-bit hashes instead of 128-bit hashes.
- SHA-2: An improvement over SHA-1 and includes four versions.
- SHA-256 creates 256-bit hashes
- SHA-224 (224-bit hashes), which creates truncated versions of SHA-256
- SHA- 512 creates 512-bit hashes.
- SHA-384 (384-bit hashes) creates truncated versions of SHA- 512
- SHA-256 creates 256-bit hashes
- SHA-3/ Keccak: An alternative to SHA-2 created outside of the NSA and was selected in a non-NSA public competition; creates hashes of the same size as SHA-2
Hash-based Message Authentication Code (HMAC): A fixed-length string of bits similar to other hashing algorithms such as MD5 and SHA-1 but with the use of a shared secret key to add some randomness to the result that only the sender and receiver know, providing both integrity and authenticity of messages. The work flow is like this:
- One server sends a message to another server using HMAC- MD5.
- The MD5 portion of the hash provides integrity
- It starts by first creating a hash of a message with MD5 and
- Then uses a secret key to complete another calculation on the hash.
- The server then sends the message and the HMAC-MD5 hash to the second server.
- The second server performs the same calculations and compares the received HMAC-MD5 hash with its result; if the two hashes are the same, the message retained integrity, but if the hashes are different, the message lost integrity. This is because only the server and receiver know the secret key, so if the receiver calculates the same HMAC-MD5 hash as the sender, it knows that the sender used the same key.
- If an attacker was trying to impersonate the sender, the message wouldn’t pass this authenticity check because the attacker wouldn’t have the secret key.
- Internet Protocol security (IPsec) and Transport Layer Security (TLS) often use a version of HMAC such as HMAC-MD5 and HMAC-SHA1.
File Hashing
As part of their standard operating procedures, many applications calculate and compare hashes automatically without any user intervention. As hashes are one-way functions, you can calculate a hash on a file or a message, but you can’t reverse the hash to reproduce the original data. Any given hashing algorithms always create a fixed- size bit string regardless of the size of the original data, but doesn’t give you a clue about the size of the file, the type of the file, or anything else. When hashing a file with the same algorithm, remember:
- The hash will always be the same no matter how many times you calculate it as long as the file itself has not been changed
- Hashing verifies the file has retained integrity. Often when you download a file, you are also given a posted hash to test against. As long as the calculated hash is the same as the hash posted on the download site, it verifies the file has not lost integrity. If hashing created a different hash than the one posted on the web site, be aware that the file lost integrity and should not be trusted.
Password Hashing and Key Stretching
From a security point of view, at the vary least, passwords should be stored as hashes. The process works like this:
- When a user creates a new password, the system calculates the hash for the password and then stores the hash.
- When the user authenticates by entering a username and password, the system calculates the hash of the entered password, and then compares it with the stored hash.
- If the hashes are the same, it indicates that the user entered the correct password.
As previously discussed, many password attacks work by calculating a hash on a guessed password, and then comparing it with the stored hash of the password, so while using complex passwords helps prevent these types of attacks, it doesn’t completely stop them.
Key stretching/strengthening: Increases the strength of stored passwords, helping to thwart brute force and rainbow table attacks by salting the passwords with additional random bits to make them even more complex. Two common key stretching techniques are:
- Bcrypt: Used to protect the passwords in the shadow password file on many Unix/Linux distributions and is based on the Blowfish block cipher. It salts the password by adding additional random bits before encrypting it with Blowfish. Bcrypt goes through this process multiple times to further protect against attempts to discover the password, resulting in a 60-character string.
- When authenticating with a username/password, the
application runs bcrypt on the supplied password and compares it with the stored bcrypt-encrypted password. - If the bcrypt result of the supplied password is the same as the stored bcrypt result, the user is authenticated.
- When authenticating with a username/password, the
- Password-Based Key Derivation Function 2/PBKDF2: Uses salts of at least 64 bits and a pseudo-random function such as HMAC to protect passwords. Some applications send the password through the PBKDF2 process as many as 1,000,000 times to create the hash so the size of the resulting hash varies with PBKDF2 depending on how it is implemented. Bit sizes of 128 bits, 256 bits, and 512 bits are most common.
- Some believe that PBKDF2 is more susceptible to brute force attacks than bcrypt.
Message Hashing
Hashing provides integrity for messages. It provides assurance to someone receiving a message that the message has not been modified. The process is as follows and is similar to what has been described with the other hashing applications
- When the sender creates a message, the run the message through a hashing algorithm
- The message and hash are sent to the recipient
- The recipient runs the message through the same hashing algorithm used to create the first hash
- If the output matches the hash sent by the originator, the message has not changed in transit.
- If the output does not match the hash sent by the message originator, the message has changed
One thing that is left unresolved by this process is that if the message was changed, a hash could be changed to match. The solution to this problem lies in the use of Hash-based Message Authentication Code or HMAC.
Hash-based Message Authentication Code or HMAC: Uses a shared secret key to hash the message along with the hashing algorithm. An attacker can modify the message in transit just as before. While the message can be modified, the attacker doesn’t know the secret key, so they can’t calculate the HMAC hash.
Data Confidentiality and Encryption
Data encryption prevents unauthorized disclosure of data, providing confidentiality as encrypted data is in a ciphertext format that is unreadable. Contrasted with data sent in cleartext, which an attacker can capture/read using a protocol analyzer, attackers can’t read encrypted traffic sent over a network or stored on a system.
Data-at-rest: Any data stored on media and it’s common to encrypt sensitive data on a field by field basis in a database if needed.
Data-in-transit: Data sent over a network. Common to encrypt sensitive data-in-transit with Hypertext Transfer Protocol Secure (HTTPS) sessions to encrypt transactions that include credit card data. If attackers intercept the transmissions, they only see ciphertext.
Data-in-use: Unencrypted data being used by a computer that was decrypted by the system and store it in memory while in use and encrypt again before being saved.
The two primary encryption methods are:
- Symmetric encryption encrypts and decrypts data with the same key.
- Asymmetric encryption encrypts and decrypts data using a matched key pair of a public key and a private key.
Encryption methods typically include two parts:
- Algorithm: transform data based on mathematical transformation of data. The algorithm is always the same.
- Key: A numeric input providing variability for the encryption. It is either kept private and/or changed frequently. In general, the size of the key for any encryption directly corresponds to the key strength. Longer keys for a specific algorithm result in stronger key strength. When more bits are used, it makes it more difficult to discover the key and decrypt the data.
Basic Encryption Terminology
- Confusion: Ciphertext is significantly different than the plaintext.
- Diffusion: Ensure that small changes in the plaintext result in large changes in the ciphertext. Just changing a single character in the plaintext results in completely different ciphertext.
- High resiliency: Refers to the security of an encryption key even if an attacker discovers part of the key. Ideally, keys are not susceptible to leakage, preventing attackers from gaining information on any part of a key. However, there are many situations that can cause leakage. A strong algorithm implements high- resiliency techniques that ensure this leakage does not compromise the encryption key.
- Initialization vector (IV): A fixed-size random/pseudo-random number that helps create random encryption key by providing a starting value for a cryptographic algorithm. The IV should be large enough so that the algorithm doesn’t reuse the same IV and re-create the same encryption keys.
- Nonce: A number used once; Many cryptographic algorithms use a random or pseudo- random nonce as a seed or a starting number.
- Random and pseudo-random numbers: Many encryption schemes require a random or pseudo-random number as an input. If you’re able to pick a number completely by chance, it is a random number. However, computers don’t do things by chance, so it’s often difficult to get a true random number. Instead, computers often use techniques to obtain pseudo-random numbers. A pseudo-random number appears to be random, but it is created by a deterministic algorithm. In other words, given the same input, a pseudo-random number generator will produce the same output
- Secret algorithm: A discouraged practice of keeping an algorithm secret and not reviewed by experts and mathematicians to discover any flaws or potential weaknesses.
- Weak/deprecated algorithms: Easily cracked, allowing an attacker to easily convert ciphertext back to plaintext. When flaws are discovered in algorithms, experts and authorities recommend deprecating the weak algorithm.
- XOR: A logical operation used in some encryption schemes to compare two inputs. If the two inputs are the same, it outputs True (or a binary 1). If the two inputs are different, it outputs False (or a binary 0).
Symmetric Encryption
Defined by its use of the same key to encrypt and decrypt data, symmetric encryption is also called secret-key encryption or session-key encryption; the Advanced Encryption Standard (AES) symmetric algorithm typically uses 128-bit keys, but can use keys with 256 bits. Symmetric encryption algorithms doesn’t use the same key to encrypt and decrypt all data and change keys many times per day. If symmetric encryption always used the same key the encryption is easier to crack and all data encrypted with this key is compromised. Remote Authentication Dial-In User Service (RADIUS) encrypts password packets using shared keys for symmetric encryption; after users authenticate, RADIUS servers and clients use the shared key to encrypt and decrypt data exchanged in a challenge/response session. Without the shared key, clients are unable to decrypt the data and respond appropriately. The table below summarizes the symmetrical encryption algorithms:
| Algorithm | Method | Key Size |
|---|---|---|
| AES | 128-bit block cipher | 128/192/256 bit key |
| 3DES | 64-bit block cipher | 56/112/168 bit key |
| Blowfish | 64-bit block cipher | 32 to 448 bit key |
| Twofish | 128-bit block cipher | 128/192/256 bit key |
| RC4 | Stream cipher | 40 to 2048 bit key |
| DES | 64-bit block cipher | 56 bit key |
What Are Block and Stream Ciphers
You can classify most symmetric algorithms as either a block cipher or a stream cipher as they both use the same key to encrypt or decrypt data.
Block cipher: Encrypts data in specific-sized blocks, such as 64-bit blocks or 128-bit blocks, by dividing large files into these blocks and encrypting individual blocks separately. More efficient than stream ciphers when the size of the data is known, such as when encrypting a file or a specific-sized database field. Block ciphers include
- AES/Advanced Encryption Standard: Adopted by the National Institute of Standards and Technology (NIST) from the Rijndael encryption algorithm after the evaluation of 15 different symmetric algorithms over 5 years, it is a strong symmetric block cipher that encrypts data in 128-bit blocks.
- Can use key sizes of 128 bits, 192 bits, or 256 bits, and referred to as AES-128, AES-192, or AES-256 to identify how many bits are used in the key
- Adopted in a wide assortment of applications.
- The strengths of AES are:
- Speed: Uses elegant mathematical formulas and only requires one pass to encrypt and decrypt data.
- Efficient: Less resource intensive than other encryption algorithms
- Strong
- Data Encryption Standard (DES): Began its life in the 1970s and encrypts data in 64- bit blocks using a relatively small key of only 56 bits. Recent technology allows it to be broken with brute force attacks so it is not recommended for use today.
- 3DES: A 64-bit block cipher with key sizes of 56 bits, 112 bits, or 168 bits intended as an improvement over the known weaknesses of DES; it encrypts data using the DES algorithm in three separate passes using multiple keys. Although strong, it isn’t used as often as AES as AES is less resource intensive. However, if hardware doesn’t support AES, 3DES is a suitable alternative.
- RC4: Developed by Ron Rivest and is a symmetric stream cipher that uses between 40 and 2,048 bits. Used to be the recommended encryption mechanism in SSL and TLS, when encrypting HTTPS connections on the Internet but has been regarded as insecure since 2013 as agencies such as the U.S. National Security Agency (NSA) can break RC4, even when implemented correctly such as in TLS. Recommend disabling RC4 and using AES instead.
- Blowfish: Designed by Bruce Schneier to replace DES, it is a strong symmetric block cipher that encrypts data in 64-bit blocks with key sizes between 32 and 448 bits. Is faster than AES in some instances, especially when comparing Blowfish with AES-256 as Blowfish encrypts data in smaller 64-bit blocks, whereas AES encrypts data in 128-bit blocks.
- Twofish: Related to Blowfish, but it encrypts data in 128-bit blocks
and it supports 128-, 192-, or 256-bit keys. It was one of the finalist algorithms evaluated by NIST for AES.
Block ciphers can use a variety of different modes of operation:
- The Electronic Codebook (ECB) mode: Divides plaintext into blocks, encrypting each block using the same key.
- Not recommended for use in any cryptographic protocols today as key reuse is a security weakness because if any plaintext blocks are the same, the resulting ciphertext is the same, making it much easier to crack.
- Cipher Block Chaining (CBC) mode: Uses an IV for randomization when encrypting the first block and then uses an XOR operation to combines each subsequent block with the previous block. Sometimes suffers from pipeline delays, because encryption of each block is dependent on the encryption of previous blocks, making it less efficient than other modes.
- Counter (CTM) mode: Widely used, it converts a block cipher into a stream cipher by combining an IV with a counter to encrypt each plaintext block. While each block uses the same IV, it is combined with the counter value, resulting in a different encryption key for each block. Multiprocessor systems can encrypt or decrypt multiple blocks at the same time, allowing the algorithm to be quicker on multiprocessor or multicore systems. CTM is widely used and respected as a secure mode of operation.
- Galois/Counter Mode (GCM): Widely used due to its efficiency and performance, allowing systems to quickly encrypt/decrypt data, it is a mode of operation used by many block ciphers, combines the Counter mode of operation with the Galois mode of authentication to provide data authenticity (integrity) and confidentiality. In addition to encrypting the data for confidentiality, it includes hashing techniques for integrity.
Stream cipher: Encrypts data as a stream of bits or bytes rather than dividing it into blocks and more efficient than block ciphers when the size of the data is unknown or sent in a continuous stream, such as when streaming audio and video over a network.
- An important principle when using a stream cipher is that encryption keys should never be reused, as if it is reused, it makes cracking the encryption easier.
Asymmetric Encryption
Uses two keys, a public key and a private key, in a matched pair to encrypt and decrypt data. Although very strong, asymmetric encryption is is also very resource intensive. It takes a significant amount of processing power to encrypt and decrypt data, especially when compared with symmetric encryption.There are several important points to remember with asymmetric encryption keys pairs:
- Private keys are private and never shared.
- Public keys are freely shared by embedding them in a shared certificate.
- If the public key encrypts information, only the matching private key can decrypt the same information.
- If the private key encrypts information, only the matching public key can decrypt the same information.
Most asymmetric encryption protocols are used only in key exchange, a cryptographic method used to share cryptographic keys between two entities, as it is a resource intensive process. In this context, asymmetric encryption uses key exchange to share a symmetric key. The cryptographic protocol then uses the symmetric encryption to encrypt and decrypt data because symmetric encryption is much more efficient.
The public key encrypts information that can only be decrypted with the matching private key. While many copies of the public key are available, there is just one private key exists, and is always stays private.
A common question is “which key encrypts and which key decrypts?” The answer depends on the task at hand:
- Email digital signatures
- The sender’s private key encrypts (or signs).
- The sender’s public key decrypts.
- Email encryption
- The recipient’s public key encrypts.
- The recipient’s private key decrypts.
- Web site encryption
- The web site’s public key encrypts.
- The web site’s private key decrypts.
- The symmetric key encrypts data in the web site session.
Email and web site encryption commonly use a combination of both asymmetric and symmetric encryption.
- They use asymmetric encryption for key exchange, privately sharing a symmetric key.
- Symmetric encryption encrypts the data.
Certificates
A key element of asymmetric encryption is a certificate, a digital document issued and managed by certificate authorities that includes the public key and information on the owner of the certificate. Used for a variety of purposes beyond just asymmetric encryption, including authentication and digital signatures, certificates contain more information than just the public key, including:
- Serial number: Uniquely identifies the certificate and used validate a certificate. If the CA revokes the certificate, it publishes this serial number in a certificate revocation list (CRL).
- Issuer: Identifies the CA that issued the certificate.
- Validity dates:. Certificates include “Valid From” and “Valid To dates, ensuring a certificate expires at some point.
- Subject: Identifies the owner of the certificate.
- Public key: RSA asymmetric encryption uses the public key in combination with the matching private key.
- Usage: Some certificates are only for encryption or authentication, whereas other certificates support multiple usages.
RSA
Static Versus Ephemeral Asymmetrical Keys
Asymmetric keys are classified as either:
- Static: Semipermanent and stays the same over a long period of time. RSA uses these. A certificate includes an embedded public key matched to a private key and this key pair is valid for the lifetime of a certificate, such as a year. Certificates have expiration dates and systems continue to use these keys until the certificate expires. A benefit of static keys is that a CA can validate them.
- Ephemeral: Has a very short lifetime and is re-created for each session; a ephemeral key pair includes a private ephemeral key and a public ephemeral key that are used for a single session and then discarded.
- Perfect forward secrecy: Requires that a cryptographic system do not use a deterministic algorithm to generates random public keys for each session. So given the same input, the algorithm creates a different public key, ensuring systems do not reuse keys so that the compromise of a long-term key does not compromise any past keys.
Elliptic Curve Cryptography
Elliptic curve cryptography (ECC) is a low power cryptographic method and is often used with low-power devices. It uses mathematical equations to formulate an elliptical curve and then graphs points on the curve to create keys.
Diffie-Hellman
First published in 1976, Diffie-Hellman is a scheme key exchange algorithm used to share a symmetric key privately between two parties as once the two parties know the symmetric key, they use symmetric encryption to encrypt the data. When using Diffie-Hellman, two parties negotiate the strongest group that both parties support. There are currently more than 25 Diffie Hellman groups in use, defined as DH Group 1, DH Group 2, etc, with higher numbers indicating more security.
Diffie-Hellman methods support both static keys and ephemeral keys.
- RSA is based on the Diffie-Hellman key exchange concepts using static keys.
- Two Diffie-Hellman ephemeral key methods are:
- Diffie-Hellman Ephemeral (DHE): Uses ephemeral keys, generating different keys for each session. Some documents list this as Ephemeral Diffie-Hellman (EDH).
- Elliptic Curve Diffie-Hellman Ephemeral (ECDHE): Generates ephemeral keys using ECC.
- Elliptic Curve Diffie-Hellman (ECDH), uses static keys.
Steganography
Steganography obfuscates data by hiding it inside other data in such a way that no one suspects there is a hidden message. Steganalytic techniques detect steganography, the most common of which is hashing. If a single bit of a file is modified, the hashing algorithm creates a different hash. Regularly taking the hashes of different files and comparing them with previous hashes detect when a file has been modified. Steganographic methods include:
Manipulation of bits: A method of embedding data in large files is modifying the least significant bit but the changes are so small that they are difficult to detect, unless you know there is a hidden message.
Hiding data in the white space of a file: Files have unused space (called white space) at the end of file clusters and it’s possible to fill this white space with a message without altering the file size.
Cryptographic Use Cases
Many applications use a combination of hashing, symmetric encryption, and asymmetric encryption. These applications include:
- Website encryption
Protecting Email with Cryptography
There are two primary cryptographic use for email that can be used alone or in tandem:
- Digital signatures
- Encryption
Digital Signatures
The digital signature algorithm (DSA) encrypts the hash of a senders message with the sender’s private key. Signatures are often used for emails rather than encrypting the entire email because it is less resource intensive. It doesn’t take much processing power to encrypt 256 bits in a SHA- 256 hash compared to the processing power to encrypt a lengthy email and its attachments.
Hash decryption by the recipient of a digitally signed email provides three security benefits:
- Authentication: This identifies the sender of the email so recipients have assurances the email actually came from who it appears to be coming from.
- Non-repudiation: The sender cannot later deny sending the message. This is sometimes required with online transactions.
- Integrity: This provides assurances that the message has not been modified or corrupted. Recipients know that the message they received is the same as the sent message.
As previously described, digital signatures rely on the following concepts:
- Hashing: Digital signatures start by creating a hash of the message with a hashing algorithm.
- Certificates: Digital signatures need certificates, and certificates include the sender’s public key.
- Public/private keys: The sender uses their private key to encrypt the hash of the message. The recipient uses the sender’s public key, distributed in an S/MIME.p7s formatted file, to decrypt the hash of the message.
The diagram above shows the digital signature process when a user sends an email with an application set up to sign the message:
- The application hashes the message.
- The application retrieves the sender’s private key and encrypts the hash using this private key.
- The application sends both the encrypted hash digital signature (the digital signature) and the unencrypted message to the recipient.
When the recipient’s system receives the message, it verifies the digital signature using by:
- Retrieving the sender’s public key in their public certificate.
- Using the senders public key to decrypt the encrypted hash with the sender’s public key.
- Calculates the hash on the received message.
- Compares the decrypted hash with the calculated hash.
If the calculated hash of the received message is the same as the encrypted hash of the digital signature, it validates several important checks:
- Authentication: As only the public key can decrypt something encrypted with the private key, and only sender has the private key, if decryption succeeds, the sender’s private key must have encrypted the hash.
- If another key was used to encrypt the hash, the sender’s public key can’t decrypt it so the recipient will see an error indicating a problem with the digital signature.
- Non-repudiation: Which is valuable in managing online transaction, occurs when a sender cannot later deny sending a particular message if their public key decrypted a hash of the message; this indicates the hash was encrypted with their private key.
- Integrity: Because the hash of the sent message matches the hash of the received message, the message has maintained integrity. It hasn’t been modified.
Encrypting Email
While using encryption to generate a digital signature ensures authentication, if you want to ensure that an email message is only readable by authorized users, you can encrypt it.
Encrypting Email with Only Asymmetric Encryption: In contrast to a digital signature which only uses the sender’s keys but not the recipient’s keys, the sender’s keys are not involved asymmetrical encryption of email. Most of the time, the public key encrypts a symmetric key used to encrypt the email and not the message itself. The recipient then uses the private key to decrypt the symmetric key, and then uses the symmetric key to decrypt the email. The following steps provide a simplified explanation of the process if only asymmetric encryption is used:
- The sender retrieves a copy of recipient’s certificate that contains their public key.
- The sender encrypts the email with the recipient’s public key.
- The sender sends the encrypted email to recipient.
- The recipient decrypts the email with their private key.
This works because recipient is the only person who has access to their private key. If attackers intercepted the email, they couldn’t decrypt it without the private key.
Encrypting Email with Asymmetric and Symmetric Encryption: Most email applications combine both asymmetric and symmetric encryption as asymmetric encryption is slow and inefficient, while symmetric encryption is very quick. As mentioned above, most email applications use asymmetric encryption to privately share a session key and then use symmetric encryption to encrypt the data.
- The sender identifies a symmetric key to encrypt their email, like AES would use 128- bit or larger keys.
- The sender encrypts the email contents with the symmetric key
- The sender retrieves a copy of the recipient’s certificate that contains their public key
- The sender uses the recipient’s public key to encrypt the symmetric key
- The sender sends the encrypted email and the encrypted symmetric key to the recipient.
- The recipient decrypts the symmetric key with their private key.
- The recipient then decrypts the email with the decrypted symmetric key.
Unauthorized users who intercept the email can’t read it because it’s encrypted with the symmetric key and they can’t read the symmetric key because it’s encrypted with the recipient’s public key, and only their private key can decrypt it.
Secure/Multipurpose Internet Mail Extensions(S/MIME): Popular standards used to digitally sign and encrypt email as most email applications that support encryption and digital signatures use S/MIME standards.
- Uses RSA for asymmetric encryption and requires a PKI to distribute and manage certificates.
- Uses AES for symmetric encryption.
- Can encrypt email at rest (stored on a drive) and in transit (data sent over the network).
Pretty Good Privacy (PGP): Designed in 1991 by Phillip Zimmerman, it can encrypt, decrypt, and digitally sign email. OpenPGP is a PGP-based standard created to avoid any conflict with existing licensing. Some versions of PGP follow S/MIME standards. Other versions follow OpenPGP standards. GNU Privacy Guard (GPG) is free software that is based on the OpenPGP standard.
- Uses the RSA algorithm and public and private keys for encryption and decryption.
- Uses both asymmetric and symmetric encryption.
HTTPS Transport Encryption
Transport encryption methods encrypt data-in-transit to ensure transmitted data remains confidential. This includes data transmitted over the Internet and on internal networks.
Secure Sockets Layer (SSL), deprecated by most organizations in favor of Transport Layer Security (TLS), are encryption protocols used to encrypt data-in- transit, ensuring confidentiality of data transmitted over the Internet. They can also be used to encrypt other transmissions such as File Transfer Protocol Secure (FTPS).
Prior to the the Internet Engineering Task Force (IETF) which created/maintains TLS to standardize improvements with SSL, Netscape created SSL for its web browser and maintained it to version SSL 3.0. Many commonly refer to TLS as SSL/TLS as if they are the same so you can consider any reference to SSL as a reference to TLS. As TLS and SSL require certificates, a internal or external certificate authority is required to issue, manage and support TLS and SSL.
SSL/TLS provide certificate-based authentication and encryption of data with a combination of:
- Asymmetric encryption for the session key exchange.
- Symmetric encryption to encrypt data displayed on the web page and transmitted during the session.
TLS 1.0 is based on SSL 3.0 and is referred to as SSL 3.1. Similarly, each update to TLS indicates it is an update to SSL. For example, TLS 1.1 is called SSL 3.2 and TLS 1.2 is called SSL 3.3;
Encrypting HTTPS Traffic with TLS: HTTP Secure (HTTPS), used on the Internet to secure web traffic, commonly uses TLS to symmetrically and asymmetrically encrypt the it. As asymmetric encryption isn’t efficient to encrypt large amounts of data, symmetric encryption is used to encrypt the session data. However, both the client and the server must know what this symmetric key is before they can use it. HTTPS uses asymmetric encryption to transmit a symmetric key using a secure key exchange method. It then uses the symmetric key with symmetric encryption to encrypt all the data in the HTTPS session.
• TLS uses asymmetric encryption to securely share the symmetric key.
• TLS uses symmetric encryption to encrypt the session data.
- The client requests an HTTPS session to begin the process by either entering an HTTPS address in the URL or by clicking on an HTTPS link.
- The server responds by sending the server’s certificate, including the server’s public key.
- The client creates a symmetric key and encrypting it with the server’s public key. This symmetric key will be used to encrypt data in the HTTPS session, so it is sometimes called a session key.
- The client sends the encrypted session key to the web server. Only the server’s private key can decrypt this. If attackers intercept the encrypted key, they won’t be able to decrypt it because they don’t have access to the server’s private key.
- The server receives the encrypted session key and decrypts it with the server’s private key.
- All the session data is encrypted with this symmetric key using symmetric encryption.
Cipher Suite
A combination of cryptographic algorithms providing several layers of security for TLS (and SSL). When two systems connect, they identify a cipher suite that is acceptable to both systems, using the suite highest on their lists and common to both lists to provide three primary cryptographic solutions:
- Encryption: Provides confidentiality of data using:
- Asymmetric cryptography to privately exchange a symmetric key
- A symmetric algorithm to encrypts the data ; TLS supports several types of symmetric encryption, including 3DES and AES.
- Authentication:. TLS uses certificates for authentication that can be verified by querying the CA that issued the certificate.
- Integrity: TLS uses a message authentication code (MAC) for integrity
There hundreds of named cipher suites, identified by a cipher identifier as a string of hexadecimal characters and a coded name like:
0x00C031. TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
0x00003C. TLS_RSA_WITH_AES_128_CBC_SHA256
The cipher identifiers above break down as follows:
- Protocol: Both are using TLS.
- Key exchange method: The first one is using ECDH and the second one is using RSA.
- Authentication: Both are using RSA, though, they shortened the code in the second one. Instead of listing RSA twice (for both the key exchange method and authentication), it is only listed once.
- Encryption: Both are using 128-bit AES, though in different modes of operation. Galois/ Counter Mode (GCM) and Cipher Block Chaining (CBC) are the two modes identified here.
- Integrity: Both are using the SHA-256 hashing algorithm.
When software developers implement cryptographic functions in their programs, they use software libraries to do so; rather than starting from zero, they access a crypto service provider, which is a library of different implementations of cryptographic standards and algorithms. This involves:
- Crypto module: A set of hardware, software, and/or firmware that implements cryptographic function, including algorithms for encryption and hashing, key generation, and authentication techniques such as a digital signature.
- Python includes a rich assortment of crypto modules developers can use. The Python Cryptography Toolkit includes a library of both hashing functions and encryption algorithms. Developers simply follow the syntax defined within the library to implement these hashing functions and encryption algorithms.
- Crypto service providers: A software library of cryptographic standards and algorithms distributed within crypto modules.
Developers should know about the different cryptographic algorithms, along with the different modes of operation. Administrators implement algorithms via cipher suites on servers. Their responsibility is to ensure that deprecated and weak cipher suites are disabled on servers, otherwise it makes the servers susceptible to attacks such as downgrade attacks.
Downgrade Attacks on Weak Implementations: Most often associated with cryptographic attacks due to weak implementations of cipher suites, a downgrade attack forces a system to downgrade its security so an attacker can exploit the lower security control. As many servers have both SSL and TLS installed, if a client is unable to use TLS, the server will downgrade its security and use SSL, attackers exploit this vulnerability by configuring their systems so that they cannot use TLS; the server downgrades security to use SSL instead of TLS, allowing attackers to launch SSL-based attacks such as the well-known Padding Oracle On Downgraded Legacy Encryption (POODLE) attack.
A way to prevent a downgrade attack is to modify the server’s protocol list, ensuring that SSL is disabled. Similarly, cipher suites with known vulnerabilities should be disabled. If weak cipher suites are enabled on a server, it increases the vulnerabilities.
Public Key Infrastructure Components
Public Key Infrastructure (PKI) refers to a set of technologies involved in the management (request, create, manage, store, distribute, and revoke) of digital certificates, with particular regards to asymmetric encryption.
As previously discussed, a primary benefit of a PKI is that it allows two people or entities to communicate securely, across an insecure medium without previously knowing each other. A key element in a PKI is a Certificate Authority.
A Certificate Authority (CA): Issues, manages, validates, and revokes certificates. CAs can be very large or also be very small, such as a single service running on a server within a private network.
Public CAs make money by selling certificates. For this to work, the public CA must be trusted. If the CA is trusted, all certificates issued by the CA are trusted, so the question is why would a computer trust a CA? The answer is based on the certificate trust path.
Certificate Chaining and Trust Models: CAs are trusted by placing a copy of their root certificate into a trusted root CA store.
- The root certificate: The first certificate created by the CA that identifies it
- The store: A collection of these root certificates; if the CA’s root certificate is placed in this store, all certificates issued by this CA are trusted.
Public CAs such as Symantec negotiate deals with web browser developers to have their certificates included with the web browser, so any certificates that they sell to businesses are automatically trusted.
The hierarchical/centralized trust model: The most common trust model; in this model, the public CA creates the first CA, known as the root CA and if the organization is large, it can create intermediate and child CAs. A large trust chain works like this:
- The root CA issues certificates to intermediate CAs.
- Intermediate CAs issue certificates to child.
- Child CAs issue certificates to devices or end users.
Certificate chaining combines all the certificates from the root CA down to the certificate issued to the end user.
Web of trust or decentralized trust model: Sometimes used with PGP and GPG, a web of trust uses self-signed certificates, and a third party vouches for these certificates. For example, if five of your friends trust a certificate, you can trust the certificate. If the third party is a reliable source, the web of trust provides a secure alternative. However, if the third party does not adequately verify certificates, it can result in the use of certificates that shouldn’t be trusted.
Registration and Certificate Signing Requests (CSRs): Users and systems request certificates from a CA using a registration process.
- Manual Process: A user enters information manually into a web site form.
- Automated Process: A user sends a specifically formatted file to the CA. Within a domain, the system handles much of the process automatically. In order to purchase a certificate for a domain to provide secure HTTPS sessions:
- Create a public and private key pair.
- Create a certificate signing request (CSR) for the certificate that covers the purpose of the certificate, information about the web site, the public key and formatted using the Public-Key Cryptography Standards (PKCS) #10 specification.
- Upon receiving the CSR, the CA validates the users identity and creates a certificate with the public key. Validation steps different based on the usage of the certificate as sometimes it includes extensive checking, and others, verification comes from the credit card I use to purchase it.
- Register the certificate with the web site along with the private key.
- When someone initiates a secure HTTPS connection, the web site sends the certificate with the public key and the TLS/SSL session creates the session.
- Certificates use object identifiers (OIDs), a string of numbers separated by dots, to identify specific objects within the certificates; some CAs require OIDs within the CSR for certain items.
- If the CA is online, meaning it is accessible over a network, it’s possible to submit the CSR using an automated process. However, an organization may choose to keep some CAs offline to protect them from attacks. Offline CAs can only accept CSRs manually.
Revoking Certificates: Normally certificates expire based on the Valid From and Valid To dates. In general, any time a CA does not want anyone to use a certificate, the CA revokes with the most common reasons being due to:
- A private key is publicly available, the key pair is compromised. It no longer provides adequate security because the private key is no longer private.
- The CA being compromised through a security breach, certificates issued by the CA may be compromised, so the CA can revoke certificates.
- As well as:
- Change of affiliation
- Superseded
- Cease of operation
- Certificate hold
CAs use certificate revocation lists (CRLs) to revoke a certificate. The CRL is a version 2 certificate that includes a list of revoked certificates by serial number. CRLs are typically cached after being downloaded the first time. Instead of requesting another copy of the CRL, clients use the cached copy.
Certificate Issues: As there are many different certificate issues resulting in an invalid certificate, so before using a certificate, clients first verify it is valid with some checks:
- Browsers typically display an error describing the issue and encouraging users not to use the certificate.
- Applications that detect a certificate issue might display an error using a certificate, but they are typically coded to not use it.
Some of common issues are:
- Expired: The first check is to ensure that it isn’t expired and if it is expired, the computer system typically gives the user an error indicating the certificate is not valid.
- Certificate not trusted:. The next check is to see if the certificate was issued by a trusted CA.Windows systems look in the Trusted Root Certification Authority store and the Intermediate Certification Authorities store and if the system doesn’t have a copy of the CA’s certificate, it will indicate the certificate is not trusted.
- Improper certificate and key management: Private keys should remain private as they are stored in an encrypted format and never shared. Poor management of the certificates holding the private keys can compromise the certificate.
- Revocation: A common method of validating a certificate is by requesting a copy of the CRL with the following process:
- The client initiates a session requiring a certificate.
- The server responds with a copy of the certificate, including the public key.
- The client queries the CA for a copy of the CRL.
- The CA responds with a copy of the CRL
- The client then checks the serial number of the certificate against the list of serial numbers in the CRL.
- If the certificate is revoked for any reason, the application gives an error message to the user.
Another method of validating a certificate is with the Online Certificate Status Protocol (OCSP) that allows the client to query the CA with the serial number of the certificate. The CA then responds with an answer of “good,” “revoked,” or “unknown.” A response of “unknown” could indicate the certificate is a forgery.
As OCSP provides a real-time response, it is an excellent example of supporting a common use case of low latency. If a CA revokes a certificate, clients using OCSP will know immediately. In contrast, if clients are using a cached CRL, they will be unaware of the revoked certificate until another copy of the CRL is downloaded.
As a result, OCSP generates a lot of real- time traffic because it requires a CA to respond to every request that is minimized with “OCSP stapling“:
- The certificate presenter obtains a timestamped OCSP response from the CA.
- Before sending it, the CA signs it with a digital signature.
- The certificate presenter then appends (or metaphorically staples) a timestamped OCSP response to the certificate during the TLS handshake process, eliminating the need for clients to query the CA.
Public Key Pinning: Prevents attackers from impersonating a web site using fraudulent certificates. When configured on a web site server, the server responds to client HTTPS requests with an extra header including a list of hashes derived from valid public keys used by the web site as well as a max-age field specifying how long the client should store and use the data
- When clients connect to the same web site again, they recalculate the hashes and then compare the recalculated hashes with the stored hashes.
- If the hashes match, it verifies that the client is connected to the same web site.
Key Escrow: The process of placing a copy of a private key in a safe environment. This is useful for recovery as f the original is lost, the organization retrieves the copy of the key to access the data. Key escrow isn’t required, but if an organization determines that data loss is unacceptable, it will implement a key escrow process.
In some cases, an organization provides a copy of the key to a third party. Another method is to designate employees within the organization who will be responsible for key escrow. These employees maintain and protect copies of the key, and if the original key is lost, they check out a copy of the key to an administrator or user.
Recovery Agent: Designated individual (security professional, administrator, or anyone designated by the company) who can recover or restore cryptographic keys, including private keys needed to access encrypted data.
Comparing Certificate Types: Certificates are identified based on their usage. The following bullets describe some common certificate types:
- Machine/Computer: Issued to a device or a computer are commonly called machine certificates or computer certificates and used to identify the computer within a domain.
- User: Certificates can also be issued to users for encryption, authentication, smart cards, etc.
- Email: Used for encryption of emails and digital signatures.
- Code signing: Used by developers to validate the authentication of executable applications or scripts and verifies the code has not been modified.
- Self-signed: Self-signed certificates from private CAs eliminate the cost of purchasing certificates from public trusted CAs. While private CAs within an enterprise often create self-signed certificates, they aren’t trusted by default. System administrators can place copies of the self-signed certificate into the trusted root CA store for enterprise computers.
- Wildcard: Starts with an asterisk (*) and can be used for multiple domains, as long as they each have the same root domain.
- Subject Alternative Name (SAN): Used for multiple domains that have different names, but are owned by the same organization. It is most commonly used for systems with the same base domain names, but different top-level domains.
- Domain validation: Indicates that the certificate requestor has control over a DNS domain. The CA takes extra steps to contact the requestor such as by email or telephone. The intent is to provide additional evidence to clients that the certificate and the organization are trustworth
- Extended validation: Use additional steps beyond domain validation. If you visit a domain with an extended validation certificate, the address bar includes the name of the company before the actual URL. This helps prevent impersonation from phishing attacks.
Certificate Formats: Most certificates, except for the certificates used to distribute certificate revocation lists, use one of the X.509 v3 formats and are typically stored as:
- Binary files: Stored as 1s and 0s.
- BASE64 American Standard Code for Information Interchange (ASCII) encoded files: BASE64 encoding converts the binary data into an ASCII string format.
Additionally, some certificates are also encrypted to provide additional confidentiality.
The base format of certificates is either:
- Canonical Encoding Rules (CER): A binary format that do not have headers and footers.
- Distinguished Encoding Rules (DER): An ASCII format of certificates that include headers and footers to identify the contents.
- Each header starts with five dashes (—–), BEGIN, a “label”, and five more dashes.
- The footer starts with five dashes, End, the same “label”, and five more dashes.
- Labels include CERTIFICATE, PUBLIC KEY, PRIVATE KEY, ENCRYPTED PRIVATE KEY, CERTIFICATE REQUEST, and X509 CRL.
Both are defined by the International Telegraph Union Telecommunication Standardization Sector (ITU-T) in the X.690 standard and use a variant of the Abstract Syntax Notation One (ASN.1) format to defines data structures commonly used in cryptography.
| Type | Common Extension | Format | Purpose | Can Contain |
|---|---|---|---|---|
| CER | .cer | Binary | Binary Certificates | Varies |
| DER | .der | ASCII | ASCII Certificates | Varies |
| PEM | .pem/.cer/.crt/.key | Binary(CER)/ASCII(DER) | Any certificate purpose. | Server certificates, certificate chains, CRL. |
| P7B | .p7b/.p7c | ASCII(DER) | Used to share public keys | Server certificates, certificate chains, CRL, no private keys. |
| P12/PFX | .p12/.pfx | Binary(CER) | Used o store private keys with certificates | Certificates, certificate chains and private keys. |
The table above outlines the different certificate formats and demonstrates the files can have many extensions, however, a certificate with the “.cer” extension doesn’t necessarily mean that it is using the CER format.
PEM/Privacy Enhanced Mail format: The name is misleading as PEM-based certificates can be used for just about anything. You might see a PEM-encoded certificate with the “.pem” extension, but it’s more common for the certificate to use other extensions; a PEM-encoded file holding the certificate with the public key typically uses the “.cer” or “.crt” extension. A PEM file holding just the private key typically uses the “.key” extension.
- They can be formatted as CER (binary files) or DER (ASCII files).
- They can also be used to:
- Share public keys within a certificate,
- Request certificates from a CA as a CSR,
- Install a private key on a server,
- Publish a CRL, or
- Share the full certificate chain.
P7B certificates: Use the PKCS version 7 (PKCS#7) format and are DER-based (ASCII).
- They are commonly used to share public keys with proof of identity of the certificate holder.
- Recipients use the public keys to encrypt or decrypt data. For example, a web server might use a P7B certificate to share its public key.
- P7B certificates can also contain a certificate chain or a CRL. However, they never include the private key.
P12 certificates: CER-based (binary) and use the PKCS version 12 (PKCS#12) format; commonly used to hold certificates with the private key, like when installing a certificate on a server to supports HTTPS sessions. Because it holds the private key, it’s common to encrypt P12 certificates. It’s also possible to include the full certificate chain in a P12 certificate. Personal Information Exchange (PFX) is a predecessor to the P12 certificate and it has the same usage. Administrators often use this format on Windows systems to import and export certificates.
Summary: Cryptography and PKI for COMPTIA Security+
- Hashing verifies integrity for data such as email, downloaded files, and files stored on a disk. A hash is a number created with a hashing algorithm, and is sometimes listed as a checksum.
- Two popular hashing algorithms used for integrity verification are MD5 and SHA. HMAC verifies both the integrity and authenticity of a message with the use of a shared secret. Other protocols such as IPsec and TLS use HMAC-MD5 and HMAC-SHA1.
- Encryption provides confidentiality and helps ensure that data is viewable only by authorized users. This applies to any data-at-rest (such as data stored in a database) or data- in-transit being sent over a network.
- Stream ciphers encrypt data a single bit, or a single byte, at a time in a stream. Block ciphers encrypt data in a specific-sized block such as 64-bit or 128-bit blocks. Stream ciphers are more efficient than block ciphers when encrypting data in a continuous stream.
- RC4 is a strong symmetric stream cipher, but most experts recommend using AES instead today. Blowfish is a 64-bit block cipher and Twofish is a 128-bit block cipher. Although NIST recommends AES as the standard, Blowfish is faster than AES-256.
- Diffie-Hellman is a secure method of sharing symmetric encryption keys over a public network. Elliptic curve cryptography is commonly used with small wireless devices. ECDHE is a version of Diffie-Hellman that uses elliptic curve cryptography to generate encryption keys.
- A digital signature is an encrypted hash of a message. The sender’s private key encrypts the hash of the message to create the digital signature. The recipient decrypts the hash with the sender’s public key. If successful, it provides authentication, non-repudiation, and integrity. Authentication identifies the sender. Integrity verifies the message has not been modified. Non-repudiation prevents senders from later denying they sent an email.
- Administrators should disable weak cipher suites and weak protocols on servers. When a server has both strong and weak cipher suites, attackers can launch downgrade attacks bypassing the strong cipher suite and exploiting the weak cipher suite.
- You request certificates using a certificate signing request (CSR) by first creating an RSA-based private key, which is used to create the public key; then include the public key in the CSR and the CA will embed the public key in the certificate.
- CAs revoke certificates for several reasons such as when the private key is compromised or the CA is compromised. The certificate revocation list (CRL) includes a list of revoked certificates and is publicly available. An alternative to using a CRL is the Online Certificate Status Protocol (OCSP), which returns answers such as good, revoked, or unknown. OCSP stapling appends a digitally signed OCSP response to a certificate.
- Certificate stapling is an alternative to OCSP. The certificate presenter (such as a web server) appends the certificate with a timestamped digitally signed OCSP response from the CA. This reduces OCSP traffic to and from the CA. Public key pinning helps prevent attackers from impersonating a web site with a fraudulent certificate. The web server sends a list of public key hashes that clients can use to validate certificates sent to clients in subsequent sessions.
- CER is a binary format for certificates and DER is an ASCII format. PEM is the most commonly used certificate format and can be used for just about any certificate type. P7B certificates are commonly used to share public keys. P12 and PFX certificates are commonly used to hold the private key.
