There are three primary properties of information, whether in a computer network or not, that may be desirable from an information security point of view: confidentiality, integrity, and availability (the CIA triad) [L01], summarized here:

  • Confidentiality means that information is made known only to its intended users (which could include processing systems).

  • Integrity means that information has not been modified in an unauthorized way before it is delivered.

  • Availability means that information is available when needed.

These are core properties of information, yet there are other properties we may also desire, including authentication, nonrepudiation, and auditability.

  • Authentication means that a particular identified party or principal is not impersonating another principal.

  • Nonrepudiation means that if some action is performed by a principal (e.g., agreeing to the terms of a contract), this fact can be proven later (i.e., cannot successfully be denied).

  • Auditability means that some sort of trustworthy log or accounting describing how information has been used is available.

    Such logs are often important for forensic (i.e., legal and prosecuritorial) purposes.

These principles are applicable to information in physical (e.g., printed) form, for which mechanisms such as safes, secured facilities, and guards have been used for thousands of years to enforce controlled sharing, storage, and dissemination. When information is to be moved through an unsecured environment, additional techniques are required.

1. Threats to Network Communication

Attacks can generally be categorized as either passive or active.

  • Passive attacks are mounted by monitoring or eavesdropping on the contents of network traffic, and if not handled they can lead to unauthorized release of information (loss of confidentiality).

  • Active attacks can cause modification of information (with possible loss of integrity) or denial of service (loss of availability).

    Logically, such attacks are carried out by an "intruder" or adversary.

Passive and active attacks
Figure 1. The principals, Alice and Bob, attempt to communicate securely, but Eve may eavesdrop and Mallory may modify messages in transit.

Eve is able to eavesdrop (listen in on, also called capture or sniff) and perform traffic analysis on the traffic passing between Alice and Bob.

  • Capturing the traffic could lead to compromise of confidentiality, as sensitive data may be available to Eve without Alice or Bob knowing.

    In addition, traffic analysis can determine the features of the traffic, such as its size and when it is sent, and possibly identify the parties to a communication. This information, although it does not reveal the exact contents of the communication, could also lead to disclosure of sensitive information and could be used to mount more powerful active attacks in the future.

While the passive attacks are essentially impossible for Alice or Bob to detect, Mallory is capable of performing more easily noticed active attacks. These include message stream modification (MSM), denial-of-service (DoS), and spurious association attacks.

  • MSM attacks (including so-called called man-in-the-middle or MITM_attacks) are a broad category and include any way traffic is modified in transit, including deletion, reordering, and content modification.

  • DoS might include deletion of traffic, or generation of such large volumes of traffic so as to overwhelm Alice, Bob, or the communication channel connecting them.

  • Spurious associations include masquerading (Mallory pretends to be Bob or Alice) and replay, whereby Alice or Bob’s earlier (authentic) communications are replayed later, from Mallory’s memory.

Table 1. Attacks on communication are broadly classified as passive or active. Passive attacks are ordinarily more difficult to detect, and active attacks are ordinarily more difficult to prevent.
Passive Active

Type

Threats

Type

Threats

Eavesdropping

Confidentiality

Message stream modification

Authenticity, integrity

Traffic analysis

Confidentiality

Denial of service (DoS)

Availability

Spurious association

Authenticity

With effective and careful use of cryptography, passive attacks are rendered ineffective, and active attacks are made detectable (and to some degree preventable).

2. Basic Cryptography and Security Mechanisms

Cryptography evolved from the desire to protect the confidentiality, integrity, and authenticity of information carried through unsecured communication channels.

The use of cryptography, at least in a primitive form, dates back to at least 3500 BCE. The earliest systems were usually codes.

Codes involve substitutions of groups of words, phrases, or sentences with groups of numbers or letters as given in a codebook. Codebooks needed to be kept secret in order to keep communications private, so distributing them required considerable care.

More advanced systems used ciphers, in which both substitution and rearrangement are used.

2.1. Cryptosystems

Symmetric and asymmetric key cryptosystem
Figure 2. The unencrypted (cleartext) message is passed through an encryption algorithm to produce an encrypted (ciphertext) message. In a symmetric cryptosystem, the same (secret) key is used for encryption and decryption. In an asymmetric or public key cryptosystem, confidentiality is achieved by using the recipient’s public key for encryption and private (secret) key for decryption.

  • In each case, a cleartext message is processed by an encryption algorithm to produce ciphertext (scrambled text).

  • The key is a particular sequence of bits used to drive the encryption algorithm or cipher.

  • With different keys, the same input produces different outputs. Combining the algorithms with supporting protocols and operating methods forms a cryptosystem.

  • In a symmetric cryptosystem, the encryption and decryption keys are typically identical, as are the encryption and decryption algorithms.

  • In an asymmetric cryptosystem, each principal is generally provided with a pair of keys consisting of one public and one private key.

    The public key is intended to be known to any party that might want to send a message to the key pair’s owner.

    The public and private keys are mathematically related and are themselves outputs of a key generation algorithm.

RSA is based on the mathematical properties of large prime numbers and their modular arithmetic, while ECC relies on the algebraic structure of elliptic curves over finite fields. As a result, the key pairs generated for each algorithm are incompatible with each other.

Without knowing the symmetric key (in a symmetric cryptosystem) or the private key (in a public key cryptosystem), it is (believed to be) effectively impossible for any third party that intercepts the ciphertext to produce the corresponding cleartext. This provides the basis for confidentiality.

For the symmetric key cryptosystem, it also provides a degree of authentication, because only a party holding the key is able to produce a useful ciphertext that can be decrypted to something sensible.

  • A receiver can decrypt the ciphertext, look for a portion of the resulting cleartext to contain a particular agreed-upon value, and conclude that the sender holds the appropriate key and is therefore authentic.

  • Furthermore, most encryption algorithms work in such a way that if messages are modified in transit, they are unable to produce useful cleartext upon decryption.

Thus, symmetric cryptosystems provide a measure of both authentication and integrity protection for messages, but this approach alone is weak. Instead, special forms of checksums are usually coupled with symmetric cryptography to ensure integrity.

A symmetric encryption algorithm is usually classified as either a block cipher or a stream cipher.

  • Block ciphers perform operations on a fixed number of bits (e.g., 64 or 128) at a time,

  • and stream ciphers operate continuously on however many bits (or bytes) are provided as input.

For years, the most popular symmetric encryption algorithm was the Data Encryption Standard (DES), a block cipher that uses 64-bit blocks and 56-bit keys.

Eventually, the use of 56-bit keys was felt to be insecure, and many applications turned to triple-DES (also denoted 3DES or TDES—applying DES three times with two or three different keys to each block of data).

Today, DES and 3DES have been largely phased out in favor of the Advanced Encryption Standard (AES), also known occasionally by its original name the Rijndael algorithm (pronounced “rain-dahl”), in deference to its Belgian cryptographer inventors Vincent Rijmen and Joan Daemen.

Different variants of AES provide key lengths of 128, 192, and 256 bits and are usually written with the corresponding extension (i.e., AES-128, AES-192, and AES-256).

Symmetric-key algorithm: From Wikipedia, the free encyclopedia

Symmetric-key encryption: the same key is used for both encryption and decryption

Examples of popular symmetric-key algorithms include Twofish, Serpent, AES (Rijndael), Camellia, Salsa20, ChaCha20, Blowfish, CAST5, Kuznyechik, RC4, DES, 3DES, Skipjack, Safer, and IDEA.

When used with asymmetric ciphers for key transfer, pseudorandom key generators are nearly always used to generate the symmetric cipher session keys.

Asymmetric cryptosystems have some additional interesting properties beyond those of symmetric key cryptosystems.

  1. Assuming we have Alice as sender and Bob as intended recipient, any third party is assumed to know Bob’s public key and can therefore send him a secret message—only Bob is able to decrypt it because only Bob knows the private key corresponding to his public key.

  2. However, Bob has no real assurance that the message is authentic, because any party can create a message and send it to Bob, encrypted in Bob’s public key.

  3. Fortunately, public key cryptosystems also provide another function when used in reverse: authentication of the sender.

  4. In this case, Alice can encrypt a message using her private key and send it to Bob (or anyone else).

  5. Using Alice’s public key (known to all), anyone can verify that the message was authored by Alice and has not been modified.

  6. However, it is not confidential because everyone has access to Alice’s public key.

  7. To achieve authenticity, integrity, and confidentiality, Alice can encrypt a message using her private key and encrypt the result using Bob’s public key.

  8. The result is a message that is reliably authored by Alice and is also confidential to Bob.

    Asymmetric (Public Key) Cryptosystem
    Figure 3. The asymmetric cryptosystem can be used for confidentiality (encryption), authentication (digital signatures or signing), or both. When used for both, it produces a signed output that is confidential to the sender and the receiver. Public keys, as their name suggests, are not kept secret.

When public key cryptography is used in "reverse" like this, it provides a digital signature.

  • Digital signatures are important consequences of public key cryptography and can be used to help ensure authenticity and nonrepudiation.

  • Only a party possessing Alice’s private key is able to author messages or carry out transactions as Alice.

In a hybrid cryptosystem, elements of both public key and symmetric key cryptography are used.

  • Most often, public key operations are used to exchange a randomly generated confidential (symmetric) session key, which is used to encrypt traffic for a single transaction using a symmetric algorithm.

  • The reason for doing so is performance—symmetric key operations are less computationally intensive than public key operations.

  • Most systems today are of the hybrid type: public key cryptography is used to establish keys used for symmetric encryption of individual sessions.

Public-key cryptography: From Wikipedia, the free encyclopedia

Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys. Each key pair consists of a public key and a corresponding private key which are generated with cryptographic algorithms based on mathematical problems termed one-way functions.

Public key crypto 1
Figure 4. An unpredictable (typically large and random) number is used to begin generation of an acceptable pair of keys suitable for use by an asymmetric key algorithm.

In a public-key encryption system, anyone with a public key can encrypt a message, yielding a ciphertext, but only those who know the corresponding private key can decrypt the ciphertext to obtain the original message.

Public key encryption
Figure 5. In an asymmetric key encryption scheme, anyone can encrypt messages using a public key, but only the holder of the paired private key can decrypt such a message. The security of the system depends on the secrecy of the private key, which must not become known to any other.

In a digital signature system, a sender can use a private key together with a message to create a signature. Anyone with the corresponding public key can verify whether the signature matches the message, but a forger who does not know the private key cannot find any message/signature pair that will pass verification with the public key.

Private key signing
Figure 6. In this example the message is digitally signed with Alice’s private key, but the message itself is not encrypted. 1) Alice signs a message with her private key. 2) Using Alice’s public key, Bob can verify that Alice sent the message and that the message has not been modified.
Public key shared secret
Figure 7. In the Diffie–Hellman key exchange scheme, each party generates a public/private key pair and distributes the public key of the pair. After obtaining an authentic (n.b., this is critical) copy of each other’s public keys, Alice and Bob can compute a shared secret offline. The shared secret can be used, for instance, as the key for a symmetric cipher which will be, in essentially all cases, much faster.

Examples of well-regarded asymmetric key techniques for varied purposes include:

  • Diffie–Hellman key exchange protocol

  • DSS (Digital Signature Standard), which incorporates the Digital Signature Algorithm

  • ElGamal

  • Elliptic-curve cryptography

    • Elliptic Curve Digital Signature Algorithm (ECDSA)

    • Elliptic-curve Diffie–Hellman (ECDH)

    • Ed25519 and Ed448 (EdDSA)

    • X25519 and X448 (ECDH/EdDH)

  • Various password-authenticated key agreement techniques

  • Paillier cryptosystem

  • RSA encryption algorithm (PKCS#1)

  • Cramer–Shoup cryptosystem

  • YAK authenticated key agreement protocol

2.2. Rivest, Shamir, and Adleman (RSA) Public Key Cryptography

The most common approach used for both digital signatures and confidentiality is called RSA in deference to its authors' names, Rivest, Shamir, and Adleman. The security of this system hinges on the difficulty of factoring large numbers into constituent primes.

2.3. Diffie-Hellman-Merkle Key Agreement (aka Diffie-Hellman or DH)

The Diffie-Hellman-Merkle Key Agreement protocol (more commonly called simply Diffie-Hellman or DH) provides a method to have two parties agree on a common set of secret bits that can be used as a symmetric key, based on the use of finite field arithmetic.

DH techniques are used in many of the Internet-related security protocols [RFC2631] and are closely related to the RSA approach for public key cryptography.

2.4. Signcryption and Elliptic Curve Cryptography (ECC)

When using RSA, additional security is provided with larger numbers. However, the basic mathematical operations required by RSA (e.g., exponentiation) can be computationally intensive and scale as the numbers grow. Reducing the effort of combining digital signatures and encryption for confidentiality, a class of sign-cryption schemes (also called authenticated encryption) provides both features at a cost less than the sum of the two if computed separately. However, even greater efficiency can sometimes be achieved by changing the mathematical basis for public key cryptography.

In a continuing search for security with greater efficiency and performance, researchers have explored other public key cryptosystems beyond RSA. An alternative based on the difficulty of finding the discrete logarithm of an elliptic curve element has emerged, known as elliptic curve cryptography (ECC, not to be confused with error-correcting code).

For equivalent security, ECC offers the benefit of using keys that are considerably smaller than those of RSA (e.g., by about a factor of 6 for a 1024-bit RSA modulus). This leads to simpler and faster implementations, issues of considerable practical concern.

ECC has been standardized for use in many of the applications where RSA still retains dominance, but adoption has remained somewhat sluggish because of patents on ECC technology held by the Certicom Corporation. (The RSA algorithm was also patented, but patent protection lapsed in the year 2000.)

2.5. Key Derivation and Perfect Forward Secrecy (PFS)

In communication scenarios where multiple messages are to be exchanged, it is common to establish a short-term session key to perform symmetric encryption.

The session key is ordinarily a random number generated by a function called a key derivation function (KDF), based on some input such as a master key or a previous session key. If a session key is compromised, any of the data encrypted with the key is subject to compromise. However, it is common practice to change keys (rekey) multiple times during an extended communication session.

A scheme in which the compromise of one session key keeps future communications secure is said to have perfect forward secrecy (PFS). Usually, schemes that provide PFS require additional key exchanges or verifications that introduce overhead. One example is the STS protocol for DH mentioned earlier.

2.6. Pseudorandom Numbers, Generators, and Function Families

In cryptography, random numbers are often used as initial input values to cryptographic functions, or for generating keys that are difficult to guess. Given that computers are not very random by nature, obtaining true random numbers is somewhat difficult. The numbers used in most computers for simulating randomness are called pseudorandom numbers. Such numbers are not usually truly random but instead exhibit a number of statistical properties that suggest that they are (e.g., when many of them are generated, they tend to be uniformly distributed across some range). Pseudorandom numbers are produced by an algorithm or device known as a pseudorandom number generator (PRNG) or pseudorandom generator (PRG), depending on the author.

Simple PRNGs are deterministic. That is, they have a small amount of internal state initialized by a seed value. Once the internal state is known, the sequence of PNs can be determined.

For example, the common Linear Congruential Generator (LCG) algorithm produces random-appearing values that are entirely predictable if the input parameters are known or guessed. Consequently, LCGs are perfectly fine for use in certain programs (e.g., games that simulate random events) but insufficient for cryptographic purposes.

A pseudorandom function family (PRF) is a family of functions that appear to be algorithmically indistinguishable (by polynomial time algorithms) from truly random functions. A PRF is a stronger concept than a PRG, as a PRG can be created from a PRF.

PRFs are the basis for cryptographically strong (or secure) pseudorandom number generators, called CSPRNGs. CSPRNGs are necessary in cryptographic applications for several purposes, including session key generation, for which a sufficient amount of randomness must be guaranteed [RFC4086].

2.7. Nonces and Salt

A cryptographic nonce is a number that is used once (or for one transaction) in a cryptographic protocol. Most commonly, a nonce is a random or pseudorandom number that is used in authentication protocols to ensure freshness. Freshness is the (desirable) property that a message or operation has taken place in the very recent past.

For example, in a challenge-response protocol, a server may provide a requesting client with a nonce, and the client may need to respond with authentication material as well as a copy of the nonce (or perhaps an encrypted copy of the nonce) within a certain period of time. This helps to avoid replay attacks, because old authentication exchanges that are replayed to the server would not contain the correct nonce value.

A salt or salt value, used in the cryptographic context, is a random or pseudorandom number used to frustrate brute-force attacks on secrets. Brute-force attacks usually involve repeatedly guessing a password, passphrase, key, or equivalent secret value and checking to see if the guess was correct. Salts work by frustrating the checking portion of a brute-force attack.

The best-known example is the way passwords used to be handled in the UNIX system. Users' passwords were encrypted and stored in a password file that all users could read. When logging in, each user would provide a password that was used to double encrypt a fixed value. The result was then compared against the user’s entry in the password file. A match indicated that a correct password was provided.

At the time, the encryption method (DES) was well known and there was concern that a hardware-based dictionary attack would be possible whereby many words from a dictionary were encrypted with DES ahead of time (forming a rainbow table) and compared against the password file. A pseudorandom 12-bit salt was added to perturb the DES algorithm in one of 4096 (nonstandard) ways for each password in an effort to thwart this attack. Ultimately, the 12-bit salt was determined to be insufficient with improved computers (that could guess more values) and was expanded.

However, there are limitations in the protections that a salt can provide. If the attacker is hitting an online service with a credential stuffing attack, a subset of the brute force attack category, salts won’t help at all because the legitimate server is doing the salting+hashing for you. [auth0-salt-hasing]

2.8. Cryptographic Hash Functions and Message Digests

In most of the protocols, including Ethernet, IP, ICMP, UDP, and TCP, we have seen the use of a frame check sequence (FCS, either a checksum or a CRC) to determine whether a PDU has likely been delivered without bit errors. When considering security, ordinary FCS functions are not sufficient for this purpose.

A checksum or FCS can be used to verify message integrity if properly constructed using special functions, which are called cryptographic hash functions.

  • The output of a cryptographic hash function H, when provided a message M, is called the digest or fingerprint of the message, H(M).

  • A message digest is a type of strong FCS that is easy to compute and has the following important properties:

    • Preimage resistance: Given H(M), it should be difficult to determine M if not already known.

    • Second preimage resistance: Given H(M1), it should be difficult to determine an M2 ≠ M1 such that H(M1) = H(M2).

    • Collision resistance: It should be difficult to find any pair M1, M2 where H(M1) = H(M2) when M2 ≠ M1.

    If a hash function has all of these properties, then if two messages have the same cryptographic hash value, they are, with negligible doubt, the same message.

    The two most common cryptographic hash algorithms are at present the Message Digest Algorithm 5 (MD5, [RFC1321]), which produces a 128-bit (16-byte) digest, and the Secure Hash Algorithm 1 (SHA-1), which produces a 160-bit (20-byte) digest.

    More recently, a family of functions based on SHA called SHA-2 [RFC6234] produce digests with lengths of 224, 256, 384, or 512 bits (28, 32, 48, and 64 bytes, respectively). Others are under development.

Cryptographic hash functions are often based on a compression function f, which takes an input of length L and produces a collision-resistant but deterministic output of size less than L. The Merkle-Damgård construction, which essentially breaks an arbitrarily long input into blocks of length L, pads them, passes them to f, and combines the results, produces a cryptographic hash function capable of taking a long input and producing an output with collision resistance.

2.9. Message Authentication Codes (MACs, HMAC, CMAC, and GMAC)

A message authentication code (unfortunately abbreviated MAC or sometimes MIC but unrelated to the link-layer MAC addresses) can be used to ensure message integrity and authentication. MACs are usually based on keyed cryptographic hash functions, which are like message digest algorithms but require a private key to produce or verify the integrity of a message and may also be used to verify (authenticate) the message’s sender.

MACs require resistance to various forms of forgery.

  • For a given keyed hash function H(M,K) taking input message M and key K, resistance to selective forgery means that it is difficult for an adversary not knowing K to form H(M,K) given a specific M.

  • H(M,K) is resistant to existential forgery if it is difficult for an adversary lacking K to find any previously unknown valid combination of M and H(M,K).

Note that MACs do not provide exactly the same features as digital signatures. For example, they cannot be a solid basis for nonrepudiation because the secret key is known to more than one party.

A standard MAC that uses cryptographic hash functions in a particular way is called the keyed-hash message authentication code (HMAC) [FIPS198][RFC2104].

  • The HMAC "algorithm" uses a generic cryptographic hash algorithm, say H(M).

  • To form a t-byte HMAC on message M with key K using H (called HMAC-H), we use the following definition:

    HMAC-H (K, M)t = Λt (H((K ⊕ opad)||H((K ⊕ ipad)||M)))

    In this definition, opad (outer pad) is an array containing the value 0x5C repeated |K| times, and ipad (inner pad) is an array containing the value 0x36 repeated |K| times. ⊕ is the vector XOR operator, and || is the concatenation operator.

    Normally the HMAC output is intended to be a certain number t of bytes in length, so the operator Λt(M) takes the left-most t bytes of M.

More recently, other forms of MACs have been standardized, called the cipher-based MAC (CMAC) [FIPS800-38B] and GMAC [NIST800-38D].

  • Instead of using a cryptographic hash function such as HMAC, these use a block cipher such as AES or 3DES.

  • CMAC is envisioned for use in environments where it is more convenient or efficient to use a block cipher in place of a hash function.

2.10. Cryptographic Suites and Cipher Suites

The combination of the mathematical or cryptographic techniques used in a particular system, especially the Internet protocols, defines not only an enciphering (encryption) algorithm but may also include a particular MAC algorithm, PRF (pseudorandom function family), key agreement algorithm, signature algorithm, and associated key lengths and parameters, are called a cryptographic suite or sometimes a cipher suite, although the first term is more accurate.

$ openssl ciphers -v -s -tls1_3
TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any      Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(128)            Mac=AEAD

From Wikipedia, the free encyclopedia

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its now-deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm. [CSWIKIPEDIA]

The key exchange algorithm is used to exchange a key between two devices. This key is used to encrypt and decrypt the messages being sent between two machines. The bulk encryption algorithm is used to encrypt the data being sent. The MAC algorithm provides data integrity checks to ensure that the data sent does not change in transit. In addition, cipher suites can include signatures and an authentication algorithm to help authenticate the server and or client.

Table 2. Algorithms supported in TLS 1.0–1.2 cipher suites
Key exchange/agreement Authentication Block/stream ciphers Message authentication

RSA

RSA

RC4

Hash-based MD5

Diffie–Hellman

DSA

Triple DES

SHA hash function

ECDH

ECDSA

AES

SRP

IDEA

PSK

DES

Camellia

ChaCha20

  1. For more information about algorithms supported in TLS 1.0–1.2, see also: Transport Layer Security § Applications and adoption

  2. In TLS 1.3, many legacy algorithms that were supported in early versions of TLS have been dropped in an effort to make the protocol more secure.

Table 3. TLS Cipher Suites: https://www.iana.org/assignments/tls-parameters/tls-parameters.xml
Value Description DTLS-OK Recommended Reference

0x13,0x01

TLS_AES_128_GCM_SHA256

Y

Y

[RFC8446]

0xD0,0x05

TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256

Y

Y

[RFC8442]

0xD0,0x01

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256

Y

Y

[RFC8442]

0xC0,0x2F

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Y

Y

[RFC5289]

0xC0,0x2B

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Y

Y

[RFC5289]

Usually, an encryption algorithm is specified by its name and description, how many bits are used for its keys (often a multiple of 128 bits), along with its operating mode.

Diagram that shows a single string for a Cipher Suite.
Figure 8. https://learn.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel

  • Encryption algorithms that have been standardized for use with Internet protocols include AES, 3DES, NULL [RFC2410], and CAMELLIA [RFC3713].

    The NULL encryption algorithm does not modify the input and is used in certain circumstances where confidentiality is not required.

  • The operating mode of an encryption algorithm, especially a block cipher, describes how to use the encryption function for a single block repeatedly (e.g., in a cascade) to encrypt or decrypt an entire message with a single key.

    • When performing encryption using CBC (cipher block chaining) mode, a cleartext block to be encrypted is first XORed with the previous ciphertext block (the first block is XORed with a random initialization vector or IV).

    • Encrypting in CTR (counter) mode involves first creating a value combining a nonce (or IV) and a counter that increments with each successive block to be encrypted.

      The combination is then encrypted, the output is XORed with a cleartext block to produce a ciphertext block, and the process repeats for successive blocks.

      In effect, this approach uses a block cipher to produce a keystream, a sequence of (random-appearing) bits that are combined (e.g., XORed) with cleartext bits to produce a ciphertext. Doing so essentially converts a block cipher into a stream cipher because no explicit padding of the input is required.

    • CBC requires a serial process for encryption and a partly serial process for decryption, whereas counter mode algorithms allow more efficient fully parallel encryption and decryption implementations. Consequently, counter mode is gaining popularity.

    • In addition, variants of CTR mode (e.g., counter mode with CBC-MAC (CCM), Galois Counter Mode, or GCM) can be used for authenticated encryption [RFC4309], and possibly to authenticate (but not encrypt) additional data (called authenticated encryption with associated data or AEAD) [RFC5116].

    • When an encryption algorithm is specified as part of a cryptographic suite, its name usually includes the mode, and the key length is often implied.

      For example, ENCR_AES_CTR refers to AES-128 used in CTR mode.

When a PRF (pseudorandom function family) is included in the definition of a cryptographic suite, it is usually based on a cryptographic hash algorithm family such as SHA-2 [RFC6234] or a cryptographic MAC such as CMAC [RFC4434][RFC4615].

For example, the algorithm AES-CMAC-PRF-128 refers to a PRF constructed using a CMAC based on AES-128. It is also written as PRF_AES128_CMAC. The algorithm PRF_HMAC_SHA1 refers to a PRF based on HMAC-SHA1.

Key agreement parameters, when included with an Internet cryptographic suite definition, refer to DH group definitions, as no other key agreement protocol is in widespread use. When DH key agreement is used in generating keys for a particular encryption algorithm, care must be taken to ensure that the keys produced are of sufficient length (strength) to avoid compromising the security of the encryption algorithm.

A signature algorithm is sometimes included in the definition of a cryptographic suite. It may be used for signing a variety of values including data, MACs, and DH values. The most common is to use RSA to sign a hashed value for some block of data, although the digital signature standard (written as DSS or DSA to indicate the digital signature algorithm) [FIPS186-3] is also used in some circumstances. With the advent of ECC, signatures based on elliptic curves (e.g., ECDSA [X9.62-2005]) are also now supported in many systems.

The concept of a cryptographic suite evolved in the context of Internet security protocols because of a need for modularity and decoupled evolution.

  • As computational power has improved, older cryptographic algorithms and smaller key lengths have fallen victim to various forms of brute-force attacks.

  • In some cases, more sophisticated attacks have revealed flaws that necessitate the replacement of the underlying mathematical and cryptographic methods, but the basic protocol machinery is otherwise sound.

  • As a result, the choice of a cryptographic suite can now be made separately from the communication protocol details and depends on factors such as convenience, performance, and security.

  • Protocols tend to make use of the components of a cryptographic suite in a standard way, so an appropriate cryptographic suite can be “snapped in” when deemed appropriate.

3. Certificates, Certificate Authorities (CAs), and PKIs

Key management, how keys are created, exchanged, and revoked, remains one of the greatest challenges in deploying cryptographic systems on a widespread basis across multiple administrative domains.

One of the challenges with public key cryptosystems is to determine the correct public key for a principal or identity.

Passive and active attacks
Figure 9. The principals, Alice and Bob, attempt to communicate securely, but Eve may eavesdrop and Mallory may modify messages in transit.

In our running example, if Alice were to send her public key to Bob, Mallory could modify it in transit to be her own public key, and Bob (called the relying party here) might unknowingly be using Mallory’s key, thinking it is Alice’s. This would allow Mallory to effectively masquerade as Alice.

To address this problem, a public key certificate is used to bind an identity to a particular public key using a digital signature.

At first glance, this presents a certain “chicken-egg” problem: How can a public key become signed if the digital signature itself requires a reliable public key?

One model, called a web of trust, involves having a certificate (identity/key binding) endorsed by a collection of existing users (called endorsers).

  • An endorser signs a certificate and distributes the signed certificate.

    The more endorsers for a certificate over time, the more reliable it is likely to be.

    An entity checking a certificate might require some number of endorsers or possibly some particular endorsers to trust the certificate.

  • The web of trust model is decentralized and “grassroots” in nature, with no central authority. This has mixed consequences.

    Having no central authority suggests that the scheme will not collapse because of a single point of failure, but it also means that a new entrant may experience some delay in getting its key endorsed to a degree sufficient to be trusted by a significant number of users.

  • The web of trust model was first described as part of the Pretty Good Privacy (PGP) encryption system for electronic mail [NAZ00], which has evolved to support a standard encoding format called OpenPGP, defined by [RFC4880].

A more formal approach, which has the added benefit of being provably secure under certain theoretical assumptions in exchange for more dependence on a centralized authority, involves the use of a public key infrastructure (PKI).

  • A PKI is a service that operates with a collection of certificate authorities (CAs) responsible for creating, revoking, distributing, and updating key pairs and certificates.

  • A CA is an entity and service set up to manage and attest to the bindings between identities and their corresponding public keys. There are several hundred commercial CAs.

    A CA usually employs a hierarchical signing scheme. This means that a public key may be signed using a parent key which is in turn signed by a grand-parent key, and so on. Ultimately a CA has one or more root certificates upon which many subordinate certificates depend for trust.

    ISRG Certificate Hierarchy Diagram, as of December 2020
    Figure 10. Let’s Encrypt’s Hierarchy as of August 2021

  • An entity that is authoritative for certificates and keys (e.g., a CA) is called a trust anchor, although this term is also used to describe the certificates or other cryptographic material associated with such entities [RFC6024].

3.1. Public Key Certificates, Certificate Authorities, and X.509

While several types of certificates have been used in the past, the one of most interest to us is based on an Internet profile of the ITU-T X.509 standard [RFC5280].

In addition, any particular certificate may be stored and exchanged in a number of file or encoding formats. The most common ones include DER, PEM (a Base64 encoded version of DER), PKCS#7 (P7B), PKCS#12 (PFX), and PKCS#1 [RFC3447].

Today, Internet PKI-related standards tend to use the cryptographic message syntax [RFC5652], which is based on PKCS#7 version 1.5.

Certificates are primarily used in identifying four types of entities on the Internet: individuals, servers, software publishers, and CAs. Certificate classes are primarily a convenience for grouping and naming types of certificates and for defining different security policies associated with them.

In practice, systems requiring public key operations have root certificates for popular CAs installed at configuration time (e.g., Microsoft Internet Explorer, Mozilla’s Firefox, and Google’s Chrome are all capable of accessing a preconfigured database of root certificates), to solve the chicken-egg PKI bootstrapping problem.

The openssl command, available for most common platforms including Linux and Windows, allows us to see the certificates for a Web site:

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
$ openssl s_client -CApath /usr/lib/ssl/certs/ -connect www.digicert.com:443 > digicert.out 2>1
^C (to interrupt)

  • The first command determines where the local system stores its preconfigured CA certificates. This is usually a directory that varies by system.

  • The next makes a connection to the HTTPS port (443) on the www.digicert.com server and redirect the output to the digicert.out file.

  • The openssl command takes care to print the entity identified by each of the certificates, and at what depth they are in the certificate hierarchy relative to the root (depth 0 is the server’s certificate, so the depth numbers are counted bottom to top).

    $ head digicert.out
CONNECTED(00000003)
---
Certificate chain
 0 s:jurisdictionC = US, jurisdictionST = Utah, businessCategory = Private Organization, serialNumber = 5299537-0142, C = US, ST = Utah, L = Lehi, O = "DigiCert, Inc.", CN = www.digicert.com
   i:C = US, O = DigiCert Inc, CN = DigiCert EV RSA CA G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 26 00:00:00 2023 GMT; NotAfter: Jun 25 23:59:59 2024 GMT
 1 s:C = US, O = DigiCert Inc, CN = DigiCert EV RSA CA G2
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256

  • It also checks the certificates against the stored CA certificates to see if they verify properly.

    In this case, they do, as indicated by “verify return” having value 0 (ok).

    $ grep 'return code' digicert.out
Verify return code: 0 (ok)

To get the certificate into a more usable form, we can extract the certificate data, convert it, and place the result into a PEM-encoded certificate file:

$ openssl x509 -in digicert.out -out digicert.pem

Given the certificate in PEM format, we can now use a variety of openssl functions to manipulate and inspect it. At the highest level, the certificate includes some data to be signed (called the To Be Signed (TBS) certificate) followed by a signature algorithm identifier and signature value.

$ openssl x509 -in digicert.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            09:fc:b7:40:3f:fd:79:b6:8f:e2:4f:74:80:5f:5d:00
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = DigiCert Inc, CN = DigiCert EV RSA CA G2
        Validity
            Not Before: Jun 26 00:00:00 2023 GMT
            Not After : Jun 25 23:59:59 2024 GMT
        Subject: jurisdictionC = US, jurisdictionST = Utah, businessCategory = Private Organization, serialNumber = 5299537-0142, C = US, ST = Utah, L = Lehi, O = "DigiCert, Inc.", CN = www.digicert.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:98:df:33:59:c1:3b:a7:38:8c:5d:9e:2f:e3:cf:
                    ...
                    c0:ca:25:49:9d:45:d0:67:7e:d9:78:c9:0e:34:95:
                    88:39
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                6A:4E:50:BF:98:68:9D:5B:7B:20:75:D4:59:01:79:48:66:92:32:06
            X509v3 Subject Key Identifier:
                D4:38:B0:9D:E2:63:52:91:C7:82:03:F0:1F:00:CE:EE:A0:FA:B7:93
            X509v3 Subject Alternative Name:
                DNS:www.digicert.com, DNS:digicert.com, DNS:admin.digicert.com, DNS:api.digicert.com, DNS:content.digicert.com, DNS:order.digicert.com, DNS:login.digicert.com, DNS:ws.digicert.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl3.digicert.com/DigiCertEVRSACAG2.crl
                Full Name:
                  URI:http://crl4.digicert.com/DigiCertEVRSACAG2.crl
            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114412.2.1
                Policy: 2.23.140.1.1
                  CPS: http://www.digicert.com/CPS
            Authority Information Access:
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertEVRSACAG2.crt
            X509v3 Basic Constraints:
                CA:FALSE
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 76:FF:88:3F:0A:B6:FB:95:51:C2:61:CC:F5:87:BA:34:
                                B4:A4:CD:BB:29:DC:68:42:0A:9F:E6:67:4C:5A:3A:74
                    Timestamp : Jun 26 17:26:00.704 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:89:EB:FD:DB:D0:80:4F:31:30:73:D8:
                                ...
                                27:74:33:78:C4:AC:AF:18
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 48:B0:E3:6B:DA:A6:47:34:0F:E5:6A:02:FA:9D:30:EB:
                                1C:52:01:CB:56:DD:2C:81:D9:BB:BF:AB:39:D8:84:73
                    Timestamp : Jun 26 17:26:00.754 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:79:AB:36:3F:F9:22:B1:E1:2D:F4:57:16:
                                ...
                                55:46:5E:B2:83:16
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 3B:53:77:75:3E:2D:B9:80:4E:8B:30:5B:06:FE:40:3B:
                                67:D8:4F:C3:F4:C7:BD:00:0D:2D:72:6F:E1:FA:D4:17
                    Timestamp : Jun 26 17:26:00.748 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:3A:F4:92:55:82:0E:1D:06:A6:21:90:C3:
                                ...
                                CB:3A:14:83:07:27
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        5d:f7:f6:45:62:22:7e:93:dc:9e:5a:62:2b:3c:8a:f1:06:9b:
        ...
        e6:4d:4e:9f
-----BEGIN CERTIFICATE-----
MIIHbDCCBlSgAwIBAgIQCfy3QD/9ebaP4k90gF9dADANBgkqhkiG9w0BAQsFADBE
...
qL35PG7dfEKrx6fD8xlYnWOYSnqNet6EZBCFe+ZNTp8=
-----END CERTIFICATE-----

The decoded version of the certificate followed by an ASCII (PEM) representation of the certificate (between the BEGIN CERTIFICATE and END CERTIFICATE indicators) shows a data portion and a signature portion.

Within the data portion is some metadata including:

  • a Version field, indicating the particular X.509 certificate type (3, the most recent, is encoded using hex value 0x02),

  • a Serial Number of the particular certificate, a number assigned by the CA unique to each certificate,

  • and a Validity field that gives the time during which the certificate should be treated as legitimate, starting with the Not Before subfield and ending with the Not After subfield.

  • The certificate metadata also indicates which signature algorithm is used to sign the data portion.

    In this case (i.e. sha256WithRSAEncryption), it is signed by computing a hash using SHA-2 and signing the result using RSA. The signature itself appears at the end of the certificate.

  • The Issuer field indicates the distinguished name (jargon from the ITU-T X.500 standard) of the entity that issued the certificate and may have these special subfields (based on X.501): C (country), L (locale or city), O (organization), OU (organizational unit), ST (state or province), CN (common name).

  • The Subject field identifies the entity this certificate is about, and the owner of the public key contained in the subsequent Subject Public Key Info field.

    In this example, the Subject field is a somewhat complex structure like the Issuer field and contains multiple object IDs (OIDs) [ITUOID]. Most are decoded with names (e.g., O, C, ST, L, CN), but some are not because the particular version of openssl that printed the output did not understand them.

    Note that the CN subfield tends to be an important one when identifying subjects and issuers for certificates used on the Internet.

    For this certificate, it gives the correct matching name for the server (along with any names included in the Subject Alternative Name (SAN) extension). Nonmatching names or URLs (e.g., https://digicert.com instead of https://www.digicert.com) referring to the same server, when accessed, is also ok.

    Note that CN is not really the field for holding a DNS name; SANs are intended for this purpose.

    When a certificate needs to be validated, a recursive process works up the certificate hierarchy to a root CA certificate by matching the issuer distinguished name in one certificate with the subject name in another.

    In this case, the certificate was issued by DigiCert EV RSA CA G2 (the issuer’s CN subfield). Assuming all certificates are current in their validity periods and are being used in appropriate ways, some parent certificate (immediate parent, grandparent, etc., but usually a root CA certificate) to the Subject field of the certificate we are evaluating must be trusted for validation to be successful.

    • The Subject Public Key Info field gives the algorithm and public key belonging to the entity specified in the Subject field.

      In this case, the public key is an RSA public key with a 2048-bit modulus and public exponent of 65537. The subject is in possession of the matching RSA private key (modulus plus private exponent) that is paired to the public key. If the private key is compromised, or if the public key needs to be changed for other reasons, the public and private keys must be regenerated and a new certificate issued. The old certificate is then revoked.

  • Version 3 X.509 certificates may include zero or more extensions.

    Extensions are either critical or noncritical, and some are required by the Internet profile in [RFC5280]. If critical, an extension must be processed and found acceptable by the relying party’s (CPS jargon) policy. Noncritical extensions are processed if supported but do not otherwise cause errors.

    • The Basic Constraints extension, a critical extension, indicates whether the certificate is a CA certificate.

      In this case it is not, so it cannot be used for signing other certificates. A certificate indicating that it is a CA certificate may be used in a certificate validation chain at a location other than a leaf. This is common for root CA certificates or for other certificate-signing certificates (“intermediate” certificates, such as the DigiCert EV RSA CA G2 certificate referenced in this example).

    • The Subject Key Identifier extension identifies the public key in the certificate.

      It allows different keys owned by the same subject to be differentiated.

    • The Key Usage extension, a critical extension, determines the valid usage for the key.

      Possible usages include digital signature, nonrepudiation (content commitment), key encipherment, data encipherment, key agreement, certificate signing, CRL signing, encipher only, and decipher only.

      Because server certificates of this kind are primarily used for identifying the two endpoints of a connection and encrypting a session key, the possible usages may be somewhat limited, as in this case.

    • The Extended Key Usage extension, which may be critical or noncritical, may provide further restrictions on the key use.

      Possible values of this extension when used in the Internet profile include the following: TLS client and server authentication, signing of downloadable code, e-mail protection (nonrepudiation and key agreement or encipherment), various IPsec operating modes, and timestamping.

    • The SAN extension allows a single certificate to be used for multiple purposes (e.g., for multiple Web sites with distinct DNS names).

      This alleviates the need to have a separate certificate for each Web site, which can significantly reduce cost and administrative burden.

      In this case, the certificate can be used for either of the DNS names www.digicert.com or content.digicert.com (and also digicert.com), and so on.

    • The CRL Distribution Points (CDP) extension gives a list of URLs for finding the CA’s certificate revocation list (CRL), a list of revoked certificates used to determine if a certificate in a validation chain has been revoked.

    • The Certificate Policies (CP) extension includes certificate policies applicable to the certificate [RFC5280].

      In this example, the CP extension contains three qulifiers, that is, two policies, and a CPS qualifier. The Policy value of 2.16.840.1.114412.2.1, a DigiCert Object Identifier (OID), and the Policy value of 2.23.140.1.1, a CABF OID, both indicate that the certificate complies with an EV policy. The CPS qualifier gives a pointer to the URI where the particular applicable CPS for the policy may be found.

    • The Authority Key Identifier identifies the public key corresponding to the private key used to sign the certificate. It is useful when an issuer has multiple private keys used for generating signatures.

    • The Authority Information Access (AIA) extension indicates where information may be retrieved from the CA.

      In this case, it indicates a URI used to determine if the certificate has been revoked using an online query protocol. It also indicates the list of CA issuers, which includes a URL containing the CA certificate responsible for signing the example server certificate.

    • Following the extensions, the certificate contains the signature portion. It contains the identification of the signature algorithm (SHA-2 with RSA here), which must match the Signature Algorithm field we encountered earlier.

      In this case, the signature itself is a 256-byte value, corresponding to the 2048-bit modulus used for this use of RSA.

3.2. Validating and Revoking Certificates

Within the IETF, [RFC5280] defines the use of X.509 version 3 certificates with X.509 version 2 CRLs for the Internet that a certificate may have to be revoked and possibly replaced with a freshly issued certificate.

To validate a certificate, a validation or certification path must be established that includes a set of validated certificates, usually up to some trust anchor (e.g., root certificate) that is already known to the relying party. One of the key steps involves determining if one or more of the certificates in a chain have been revoked. If so, the path validation fails.

In the Internet, there are two primary ways to ensure that entities that wish to use a certificate become aware if it has been revoked: CRLs and the Online Certificate Status Protocol (OCSP) [RFC2560].

When the CRL Distribution Point extension includes an HTTP or FTP URI scheme, as it does in the preceding example, the complete URL gives the name of a file encoded in DER format containing an X.509 CRL. In our example, we can retrieve the CRL corresponding to the certificate using the following command:

$ wget -q http://crl3.digicert.com/DigiCertEVRSACAG2.crl

and print it out as follows:

$ openssl crl -inform DER -in DigiCertEVRSACAG2.crl -text
Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = DigiCert Inc, CN = DigiCert EV RSA CA G2
        Last Update: Jul 31 19:48:27 2023 GMT
        Next Update: Aug  7 19:48:27 2023 GMT
        CRL extensions:
            X509v3 Authority Key Identifier:
                6A:4E:50:BF:98:68:9D:5B:7B:20:75:D4:59:01:79:48:66:92:32:06
            X509v3 CRL Number:
                1121
Revoked Certificates:
    Serial Number: 06AA5017961021B47CA95CE01C312405
        Revocation Date: Jul  8 17:31:01 2022 GMT
    Serial Number: 02FDC9206F81D00E3311F7B6D920B1A2
        Revocation Date: Jul 13 15:19:23 2022 GMT
    ...
    Serial Number: 0C2C2310AFDFF58F2E4A6454FA7B7801
        Revocation Date: Jul 31 17:32:07 2023 GMT
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        1f:ee:29:c7:fa:46:03:85:4a:cc:e0:c4:0b:9d:cd:cf:ea:4c:
        ...
        27:ca:42:1b
-----BEGIN X509 CRL-----
MIMCHE8wgwIbNgIBATANBgkqhkiG9w0BAQsFADBEMQswCQYDVQQGEwJVUzEVMBMG
...
3gwZtF3ABgkVW2jJCbM5+tDZzf/jSapQ3fOoPMNqCEknykIb
-----END X509 CRL-----

Here we can see the format of an X.509 v2 CRL.

  • The format is very similar to that of a certificate, and the entire message is signed by a CA as certificates are.

    This is useful because CRLs can be distributed like certificates: using otherwise untrusted communication channels and servers.

  • In comparison with a certificate, the validity period is replaced by a list of the previous and next CRL updates.

  • There is no subject and no public key but instead a list of serial numbers for revoked certificates plus the time and reason for revocation.

  • There may also be CRL extensions that are unique to CRLs.

    In this example, the Authority Key Identifier extension gives a number identifying the key used by the CA in signing the CRL. The CRL Number extension gives the sequence number of the CRL. Other values are given in [RFC5280].

OCSP (Online Certificate Status Protocol), the other primary method for determining if a certificate has been revoked, is an application-level request/response protocol usually operated over HTTP (i.e., using the HTTP protocol with TCP/IP on TCP port 80).

  • An OCSP request includes information identifying a particular certificate, plus some optional extensions. A response indicates whether the certificate is not revoked, unknown, or revoked. An error may be returned if the request cannot be parsed or otherwise acted upon.

  • The key used for signing the OCSP response need not necessarily match the key used to sign the original certificate. This is possible if the issuer included a Key Usage extension indicating an alternate OCSP provider.

  • To see an OCSP request/response exchange, we can execute the following commands:

    $ # CONNECTED COMMANDS: Q   End the current SSL connection and exit.
$ echo "Q" | \
> openssl s_client -connect www.digicert.com:443 2>1 | openssl x509 -out DigiCert.pem

$ echo "Q" | \
> openssl s_client -connect www.digicert.com:443 2>1 | openssl x509 -noout -subject -issuer -ext authorityInfoAccess
subject=jurisdictionC = US, jurisdictionST = Utah, businessCategory = Private Organization, serialNumber = 5299537-0142, C = US, ST = Utah, L = Lehi, O = "DigiCert, Inc.", CN = www.digicert.com
issuer=C = US, O = DigiCert Inc, CN = DigiCert EV RSA CA G2
Authority Information Access:
    OCSP - URI:http://ocsp.digicert.com
    CA Issuers - URI:http://cacerts.digicert.com/DigiCertEVRSACAG2.crt
$ wget -q http://cacerts.digicert.com/DigiCertEVRSACAG2.crt

$ CA=DigiCertEVRSACAG2.crt
$ CERT=DigiCert.pem
$ OSCPURL=http://ocsp.digicert.com
$ openssl ocsp -issuer $CA -cert $CERT -url $OSCPURL -VAfile $CA -no_nonce -text
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: D613075FB6DEA11BDF0182D397E1D37C6E925509
          Issuer Key Hash: 6A4E50BF98689D5B7B2075D45901794866923206
          Serial Number: 09FCB7403FFD79B68FE24F74805F5D00
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 6A4E50BF98689D5B7B2075D45901794866923206
    Produced At: Aug  1 20:19:18 2023 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: D613075FB6DEA11BDF0182D397E1D37C6E925509
      Issuer Key Hash: 6A4E50BF98689D5B7B2075D45901794866923206
      Serial Number: 09FCB7403FFD79B68FE24F74805F5D00
    Cert Status: good
    This Update: Aug  1 20:03:02 2023 GMT
    Next Update: Aug  8 19:03:02 2023 GMT

    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        49:59:d8:0f:6c:e4:12:41:ab:0e:7a:4a:ad:94:7c:20:04:5e:
        ...
        bf:cf:a4:ad:95:2b:4b:16:f8:8c:61:79:63:48:42:57:d3:d2:
        21:6a:d3:fe
Response verify OK
DigiCert.pem: good
	This Update: Aug  1 20:03:02 2023 GMT
	Next Update: Aug  8 19:03:02 2023 GMT

    • The request included the identification of a hash algorithm (SHA-1), a hash of the issuer name, a number identifying the issuer’s key (the same as the Authority Key Identifier extension in the certificate), plus the certificate’s serial number.

    • The responder, identified by the responder ID, identifies itself and signs the response. The response includes the hashes and numbers from the request, as well as the certificate status of “good” (i.e., not revoked).

    OCSP-based revocation is not an effective technique to mitigate against the compromise of an HTTPS server’s private key. [OCSPWIKIPEDIA]

3.3. Attribute Certificates

In addition to public key certificates (PKCs) used to bind names to public keys, X.509 defines another type of certificate called an attribute certificate (AC).

  • ACs are similar in structure to PKCs but lack a public key.

  • They are used to indicate other information, including authorization information that may have a lifetime different from (e.g., shorter than) a corresponding PKC [RFC5755].

  • ACs contain other structures similar to PKCs, including extensions and AC policies.

4. TCP/IP Security Protocols and Layering

Protocols involving cryptography can (and do) exist at a number of different layers in the protocol stack.

  • Security services at the link layer protect information only as it flows across a single communication hop,

  • security at the network layer protects information flowing between hosts,

  • security at the transport layer protects process-to-process communication, and

  • security at the application layer protects information manipulated by applications.

It is also possible to protect the data manipulated by applications independently of the communication layers (e.g., files can be encrypted and sent as e-mail attachments).

Security protocols exist at essentially every OSI stack layer
Figure 11. Security protocols exist at essentially every OSI stack layer, plus some “in-between” layers.

TLS and IPsec are the most prevalent, as TLS is used with all secure Web communications (HTTPS) and IPsec is used with most network-layer security, including VPNs.

4.1. Network Access Control: 802.1X, 802.1AE, EAP, and PANA

Network Access Control (NAC) refers to methods used to authorize or deny network communications to particular systems or users.

Defined by the IEEE, the 802.1X Port-Based Network Access Control (PNAC) standard is commonly used with TCP/IP networks to support LAN security in enterprises, for both wired and wireless networks.

Used in conjunction with the IETF standard Extensible Authentication Protocol (EAP) [RFC3748], 802.1X is sometimes called EAP over LAN (EAPoL).

EAP, supported by 802.11i and 802.1X
Figure 12. EAP, supported by 802.11i and 802.1X, allows for a peer (supplicant) to be authenticated by an authenticator that is separate from an (authentication, authorization, and accounting) AAA server. The authenticator can operate in “pass-through” mode in which it does little more than forward EAP packets. It can also participate more directly in the EAP protocol. The pass-through mode allows authenticators to avoid having to implement a large number of authentication methods. The most common approach is to make a VLAN mapping adjustment so that the authenticated peer is assigned to the protected VLAN or to another VLAN that provides connectivity to the protected VLAN using a router (layer 3).

In 802.1X, the protocol between the supplicant and the authenticator is divided into a lower and upper sublayer. The lower layer is called the port access control protocol (PACP). The higher layer is ordinarily some variant of EAP. For use with 802.1AR (X.509 certificates for secure device identities), the variant is called EAP-TLS [RFC5216]. PACP uses EAPoL frames for communication, even if EAP authentication is not used (e.g., when MKA is used). EAPoL frames use an Ethertype field value of 0x888E.

Moving to IETF standards, EAP is not a single protocol but rather a framework for achieving authentication using a combination of other protocols, such as TLS and IKEv2.

EAP Frame Header
Figure 13. The EAP header includes a Code field for demultiplexing packet types (Request, Response, Success, Failure, Initiate, Finish). The Identifier helps match requests to responses. For request and response messages, the first data byte is a Type field. The Length field gives the number of bytes in the EAP message, including the Code, Identifier, and Length fields.
EAP message authentication flow
Figure 14. The baseline EAP messages carry authentication material between the peer and the authenticator. In many deployments, the authenticator is a relatively simple device that acts in a “pass-through” mode. In such cases, most of the protocol processing takes place on the peer and AAA server. IETF standard AAA-specific protocols such as RADIUS or Diameter may be used to encapsulate EAP messages carried between the AAA server and authenticator.

EAP is a layered architecture that supports its own multiplexing and demultiplexing. Conceptually, it consists of four layers: the lower layer (for which there are multiple protocols), EAP layer, EAP peer/authenticator layer, and EAP methods layer (for which there are many methods).

EAP Stack
Figure 15. The EAP stack and implementation model. In the pass-through mode, the peer and AAA server are responsible for implementing the EAP authentication methods. The authenticator need only implement EAP message processing, the authenticator processing, and enough of an AAA protocol (e.g., RADIUS, Diameter) to exchange information with the AAA server.

4.2. Layer 3 IP Security (IPsec)

IPsec is an architecture and collection of standards that provide data source authentication, integrity, confidentiality, and access control at the network layer for IPv4 and IPv6 [RFC4301], including Mobile IPv6 [RFC4877]. It also provides a way to exchange cryptographic keys between two communicating parties, a recommended set of cryptographic suites, and a method for signaling the use of compression.

Each communicating party may be an individual host or a security gateway (SG) that provides a boundary between a protected and an unprotected portion of a network.

Thus, IPsec can be used in applications such as remote access to a corporate LAN (forming a VPN), to interconnect different portions of an enterprise securely across the open Internet, or to secure the communications of hosts or routers acting as hosts when exchanging routing information.

A host implementation of IPsec may be integrated within the IP stack itself or may act as a driver sitting “below” the rest of the network stack (called the “Bump in the Stack” or BITS implementation).

Alternatively, it may reside inside an inline SG, which is sometimes called the “Bump in the Wire” or BITW implementation approach. For BITW implementations, both host and SG functionality is generally required, as the device typically needs to be managed remotely.

IPsec deployments
Figure 16. IPsec is applicable to securing host-to-host communications, host-to-gateway communications, and gateway-to-gateway communications. It also supports multicast distribution and mobility.

The operation of IPsec can be divided into the establishment phase,

where key material is exchanged and a security association (SA) is built,

followed by the data exchange phase,

where different types of encapsulation schemes, called the Authentication Header (AH) and Encapsulating Security Payload (ESP), may be used in different modes such as tunnel mode or transport mode to protect the flow of IP datagrams.

Each of these IPsec components uses a cryptographic suite, and IPsec is designed to support a wide range of suites.

A complete IPsec implementation includes the SA establishment protocol, AH (optionally), ESP, and a collection of appropriate cryptographic suites, configuration information, and setup tools [RFC6071].

IPsec operates only selectively on certain packets based on policies set by administrators, contained in a security policy database (SPD), logically resident with each IPsec implementation.

IPsec also requires two additional databases called the security association database (SAD) and peer authorization database (PAD), which are consulted when determining how packets are to be handled.

IPsec packet processing
Figure 17. In a security gateway, IPsec packet processing takes place at layer 3 in a logical entity separating a protected and an unprotected network. The security policy database dictates the disposition of packets: bypass, discard, or protect. Protection generally involves applying or validating integrity protection or encryption. An administrator configures the SPD to achieve desired security goals.

4.2.1. Internet Key Exchange (IKEv2) Protocol

The first step in using IPsec is to establish an SA. An SA is a simplex (one-direction) authenticated association established between two communicating parties, or between a sender and multiple receivers if IPsec is supporting multicast. Most frequently, communication is bidirectional between two parties, so a pair of SAs is required to use IPsec effectively.

A special protocol called the Internet Key Exchange (IKE) is used to accomplish this task automatically. The current version of the protocol is called IKEv2 [RFC5996]. We will refer to it simply as IKE.

To establish an SA, IKE begins with a simple request/response message pair that includes a request to establish the following parameters: an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a PRF (pseudorandom function family) that gives a random-appearing output given any input bit string. In IKE, a PRF is used for generation of session keys. IKE first establishes an SA for itself (called an IKE_SA) and can subsequently establish SAs for either AH or ESP (called CHILD_SAs). IKE is also capable of negotiating the use of IP Payload Compression (IPComp) [RFC3173] with each CHILD_SA, because applying compression at other layers after performing encryption is ineffective.

IKE operates using pairs of messages called exchanges that are sent between an initiator and a responder.

  • The first two exchanges, called IKE_SA_INIT and IKE_AUTH, establish an IKE_SA and a single CHILD_SA.

  • Subsequently, CREATE_CHILD_SA exchanges, used to establish additional CHILD_SAs, and INFORMATIONAL exchanges, used to initiate changes in or gather status information about an SA, may occur.

In most cases, a single IKE_SA_INIT and IKE_AUTH exchange (a total of four messages) is sufficient. Messages used in an exchange contain payloads identified by type numbers that identify the type of information carried in each payload. Multiple payloads per message are common, and some long messages may require IP fragmentation.

IKE messages are sent encapsulated in UDP using port number 500 or 4500. However, because IKE traffic may pass through a NAT where the port number is rewritten, an IKE receiver should be prepared to receive traffic originating from any port. Port 4500 is reserved for UDP-encapsulated ESP and IKE [RFC3948]. IKE messages appearing on port 4500 are required to have their initial 4 data bytes set to 0 (the “non-ESP marker”) to differentiate them from other (i.e., ESP or WESP) messages.

IKE initiators perform timer-based retransmissions when IKE messages appear to have been lost. Responders perform retransmissions only when triggered by an incoming request. An exponentially increasing retransmission timer is used for retransmissions, but the total number of retransmissions is left unspecified. Both initiators and responders keep track of their last transmitted messages and corresponding sequence numbers. Sequence numbers are used to match requests with responses, and to identify message retransmissions. This makes IKE a window-based protocol with a maximum window size given by a responder that is initialized when an SA is first set up but can be increased later. The maximum window size limits the total number of outstanding requests.

4.2.1.1. IKEv2 Message Formats

IKE messages contain a header followed by zero or more IKE payloads.

IKEv2 header
Figure 18. The IKE v2 header. All IKE messages contain a header followed by zero or more payloads. IKE uses 64-bit Security Parameter Index (SPI) values. The Exchange Type gives the purpose of the exchange and the payloads that may be expected in the message. The Flags field indicates whether the message was sent from an initiator or a responder. The Message ID associates requests with responses and is used for detecting replay attacks.

  • In the headers of IKE messages, the Security Parameter Index (SPI) is a 64-bit number that identifies a particular IKE_SA (other IPsec protocols use a 32-bit SPI value).

    Both the initiator and the responder have an SA for their peer, so each provides the SPI it is using, and this pair of values, combined with the IP addresses of the endpoints, can be used to form an effective connection identifier.

  • The Majoe Version and Minor Version fields are set to 2 and 0, respectively, for this version of IKE.

    The major version number is changed when interoperability cannot be maintained between versions.

  • The Exchange Type field gives the type of exchange of which the message is part: IKE_SA_INIT (34), IKE_AUTH (35), CREATE_CHILD_SA (36), INFORMATIONAL (37), and IKE_SESSION_RESUME (38; see [RFC5723]).

    Other values are reserved; the range 240–255 is reserved for private use.

  • Three bit fields are defined for the Flags field (bits are labeled right to left, starting from 0): I (Initiator, bit 3), V (Version, bit 4), and R (Response, bit 5).

    The I bit field is set by the original initiator and cleared by the recipient for return messages.

    The V bit field indicates that the sender supports a higher major version number of the protocol than is currently being used.

    The R bit field indicates that the message is a response to a previous message using the same message ID.

  • The Message ID field in IKE acts somewhat like the Sequence Number field in TCP, except the message ID starts with 0 for the initiator and 1 for the responder.

    The field is incremented by 1 for each subsequent transmission, and responses use the same message ID as the requests. The I and R bit fields differentiate requests from responses.

    Message IDs are remembered when sent or received. Doing so allows each end to perform replay detection. Old message IDs are not processed. Wrapping of the Message ID field (possible, but not likely with 4 billion IKE messages) is handled by reinitiating the IKE_SA_INIT exchange.

  • The other fields (Next Payload and Length) help describe what the IKE message contains.

    Each message contains zero or more payloads, and each payload has its own particular structure. The Length field gives the size (in bytes) of the header plus all payloads in the message. The Next Payload field gives the type of the following payload. At present, 16 nontrivial types are defined (value 0 indicates no next payload).

    Table 4. IKEv2 payload types. A value of 0 indicates no next payload. The ranges 1–32 and 49–255 are reserved; the range 128–255 is reserved for private use. Each IKE payload begins with an IKE generic payload header.
    Value Notation Purpose Value Notation Purpose

    33

    SA

    Security association

    41

    N

    Notify

    34

    KE

    Key exchange

    42

    D

    Delete

    35

    IDi

    Identification (initiator)

    43

    V

    Vendor ID

    36

    IDr

    Identification (responder)

    44

    TSi

    Traffic selector (initiator)

    37

    CERT

    Certificate

    45

    TSr

    Traffic selector (responder)

    38

    CERTREQ

    Certificate request (indicates trust anchors)

    46

    SK { }

    Encrypted and authenticated (contains other payloads)

    39

    AUTH

    Authentication

    47

    CP

    Configuration

    40

    Ni, Nr

    Nonces (initiator, responder)

    48

    EAP

    Extensible authentication (EAP)
    IKEv2 generic payload header
    Figure 19. A “generic” IKEv2 payload header. Each payload begins with a header of this form.

    • The generic payload header is fixed at 32 bits, and the Next Payload and Payload Length fields provide for a “chain” of variable-size payloads (up to 65,535 bytes each, including the 4-byte payload header) to be present in a single IKE message. Each payload type has its own set of special headers.

    • The C (critical) bit field indicates that the current payload (not the one identified by the Next Payload field) is deemed “critical” for a successful IKE exchange.

      Receivers of critical payloads that do not understand the type code (provided in the previous payload’s Next Payload field or in the IKE header’s Next Payload field) must abort the IKE exchange.

4.2.1.2. The IKE_SA_INIT Exchange

The first of two exchanges, IKE_SA_INIT and IKE_AUTH, constituting the “initial exchanges” of IKE, formerly known as Phase 1 in earlier versions of IKE. Other exchanges (CREATE_CHILD_SA and INFORMATIONAL) may be initiated by either party only after the initial exchanges have completed, and they are always secured (encrypted and integrity-protected) based on the parameters established using the first two exchanges.

IKE_SA_INIT and IKE_AUTH exchange
Figure 20. The IKE_SA_INIT and IKE_AUTH exchange involves payloads used to establish the first two security associations (IKE_SA and one CHILD_SA). Certificates and certificate request payloads (with trust anchors) may also be included, as may Notification and Configuration payloads (not shown).

As shown, IKE_SA_INIT negotiates the choice of cryptographic suite, exchanges nonces, and performs a DH key agreement. It may also include additional information, depending on the particular implementation and deployment scenario.

  • It begins when the initiator sends an IKE message containing its set of supported cryptographic suites, DH information, and nonce using three payloads (SA, KE, and Ni).

  • Upon receiving the first message, the responder becomes aware that an IKE transaction is requested by the initiator, the initiator’s supported cryptographic suites, and configuration parameters.

    The responder selects an acceptable cryptographic suite and expresses this in the SAr1 payload. It also provides its portion of the DH key agreement parameters in KEr, its nonce in Nr, and an optional request for the initiator’s certificate in the CERTREQ payload.

    CERTREQ payloads include an indication of CAs the responder finds acceptable for validating certificates that may be used in subsequent exchanges (i.e., it indicates the responder’s trust anchors).

    A message containing the responder’s IKE header and all of these payloads is then sent in response to the initiator, completing the IKE_SA_INIT exchange.

4.2.1.3. Security Association (SA) Payloads and Proposals

SA payloads contain an SPI value and a set of proposals (often one).

Proposals are built using proposal structures that are somewhat complex. Each proposal structure is numbered and contains an IPsec protocol ID. A protocol ID indicates one of the following IPsec protocols: IKE, AH, or ESP.

Multiple proposal structures using the same proposal number are considered to be part of the same proposal (an “AND” of the specified protocols). Proposal structures with different proposal numbers are considered different proposals (an “OR” of the specified protocols).

Each proposal/protocol structure contains one or more transform structures that describe algorithms to be used with the specified protocols.

Typically, AH has a single transform (integrity check algorithm), ESP has two (integrity check and encryption algorithms), and IKE has four (DH group number, PRF, integrity check, and encryption algorithms).

4.2.1.4. Key Exchange (KE) and Nonce (Ni, Nr) Payloads

In addition to SA payloads, IKE_SA_INIT messages include a KE (Key Exchange) and Nonce payload (written as Ni, Nr, or sometimes No).

The KE payload contains the DH group number and key exchange data representing the public numbers used in forming an ephemeral Diffie-Hellman key (initial shared secret). The DH group number gives the group in which the public value was computed. The Nonce payload contains a recently generated nonce between 16 and 256 bytes in length. It is used in generating key material to ensure freshness and protect against replay attacks.

Once the DH exchange completes, each side can compute its SKEYSEED value, which is used for all subsequent key generation associated with the IKE_SA (unless a key-generating EAP method is used for this purpose), a total of seven secret values: SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr.

The SK_d key is used for deriving keys for CHILD_SAs. The SK_a and SK_e keys are for authentication and encryption, respectively. The SK_p keys are used in generating AUTH payloads during the IKE_AUTH exchange.

4.2.1.5. Notification (N) and Configuration (CP) Payloads

The N payload is a Notification or Notify payload. It can be used for conveying error messages and indications of various processing capabilities with most of the IKE exchange types. It contains a variable-length SPI field and a 16-bit field to indicate the notification type. Values below 8192 are used for standard errors, and values above 16383 are used for status indicators.

For example, when requesting the creation of a transport mode SA instead of the default tunnel mode, a Notify payload containing the USE_ TRANSPORT_MODE value (16391) is used. If IP compression [RFC3173] is supported, this fact can be indicated by the IPCOMP_SUPPORTED value (16387). Notify payloads may contain a variable-length data portion whose content depends on the notification type.

A CP or Configuration payload also contains additional information like a Notify payload but is used primarily for initial system configuration. For example, obtaining information that might ordinarily be conveyed using DHCP can be carried over IKE using a CP.

4.2.1.6. Algorithm Selection and Application

IKE divides the set of transforms forming a cryptographic suite into four types: encryption (type 1, used with IKE and ESP), PRF (type 2, used with IKE), integrity protection (type 3, used with IKE and AH and optional in ESP), and DH group (type 4, used with IKE and optional in AH and ESP).

Table 5. Mandatory-to-implement algorithms for use with IKEv2, grouped by type number. [RFC4307]
Purpose Name Number Status Original Defining RFC/Reference

IKE Transform

Type 1 (encryption)

ENCR_3DES

ENCR_NULL

ENCR_AES_CBC

ENCR_AES_CTR

3

11

12

13

Required

Optional

Recommended

Recommended

[RFC2451]

[RFC2410]

[RFC3602]

[RFC3686]

IKE Transform

Type 2 (for PRFs)

PRF_HMAC_MD5

PRF_HMAC_SHA1

PRF_AES128_CBC

1

2

4

Optional

Required

Recommended

[RFC2104]

[RFC2104]

[RFC4434]

IKE Transform

Type 3 (integrity)

AUTH_HMAC_MD5_96

AUTH_HMAC_SHA1_96

AUTH_AES_XCBC_96

1

2

5

Optional

Required

Recommended

[RFC2403]

[RFC2404]

[RFC3566]

IKE Transform

Type 4 (DH groups)

1024 MODP (Group 2)

2048 MODP (Group 14)

2

14

Required

Recommended

[RFC2409]

[RFC3526]
4.2.1.7. The IKE_AUTH Exchange

As mentioned earlier, the SKEYSEED value is used to derive encryption and authentication keys that are in turn used to secure payloads during the IKE_AUTH exchange. These keys are called SK_e and SK_a, respectively. The notation SK{P1, P2, …​, PN} indicates that payloads P1, …​, PN are encrypted and integrityprotected using these keys.

The primary purpose of the IKE_AUTH exchange is to provide identity validation for each peer. It also exchanges sufficient information to establish the first CHILD_SA.

To begin the IKE_AUTH exchange, the initiator sends the payload SK{IDi, AUTH, SAi2, TSi, TSr}. Given the proper decryption key, it provides the initiator’s identity, authentication information validating the initiator’s identity, another SA payload for the first CHILD_SA called SAi2, and a pair of traffic selectors (payloads TSi and TSr). The initiator may also include its certificate in a CERT payload, a certificate request in a CERTREQ payload that identifies its trust anchors, and identification of the responder in the IDr payload. Sending the responder’s identity is useful in the case where the responder has multiple identities associated with the same IP address and needs to ensure that the proper SA is set up. Several different identity types are supported for ID payloads, including IP address, FQDN, e-mail address, and distinguished name (to be used with X.509 certificates).

The final message of the exchange includes the responder’s identity (IDr), authentication material to prove the responder’s identity (AUTH), the other SA constituting the CHILD_SA (SAr2), and a set of traffic selectors (TSi and TSr), which may be subsets of the original TSi and TSr values. All payloads in the IKE_AUTH exchange are encrypted and integrity-protected. A certificate payload (CERT) containing one or more certificates may also be sent at this point. If so, any public key required to validate the AUTH payload appears first in the certificate list. The specific contents vary depending on the cryptographic suite selected. During the exchanges, both sides must check all applicable signatures in order to be safe from compromise, including MITM attacks.

4.2.1.8. Traffic Selectors and TS Payloads

Traffic selectors indicate the fields and corresponding values of an IP datagram that cause it to be "selected" for IPsec processing. They are used in combination with an IPsec SPD to determine whether the containing datagram should be protected using IPsec.

The contents of a TS payload may include IPv4 or IPv6 address ranges, port number ranges, and an IPv4 protocol ID or IPv6 header value. Ranges are sometimes denoted with wildcard notation.

For example, the notation 192.0.2.* or 192.0.2.0/24 would represent the range 192.0.2.0–192.0.2.255.

Traffic selectors can be used to help implement policies such as which cryptographic suite is required to establish an SA to a particular host or port range. Most of these details are handled in the management interface to the SPD.

During an IKE_AUTH exchange, each party specifies a TSi and TSr payload containing TS values. When one range is smaller than another, the smaller range is selected for use in a process called “narrowing.”

4.2.1.9. EAP and IKE

Although IKE includes its own authentication methods (see Section 2.15 of [RFC5996]), it can also make use of EAP (see Sections 2.16 and 3.16 of [RFC5996]). With EAP, a wide array of authentication methods can be used beyond the relatively limited set of pre-shared keys or public key certificates otherwise required by IKE.

4.2.1.10. Better-than-Nothing Security (BTNS)

A relatively recent development with IKE and IPsec is called better-than-nothing security (BTNS, pronounced “buttons”). BTNS aims to address some of the usability and ease of deployment issues with IPsec, especially the need to establish a PKI or other deployed authentication system [RFC5387] to use certificates.

Technically, BTNS is essentially unauthenticated IPsec [RFC5386], and it can be supported when IKE is used to establish an SA. With BTNS, public keys are used, but their containing certificates are not checked against a chain or root certificate. Consequently, an SA can ensure that the same entity is communicating over time but cannot ensure that any particular, validated entity established the SA. This form of authentication is called continuity of association and is weaker than the data origin authentication present in ordinary IPsec.

BTNS makes no other substantive changes to IPsec; the formats of IKE, AH, and ESP messages remain the same.

4.2.1.11. The CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA exchange is used to create CHILD_SAs for ESP or AH, or to rekey existing SAs (either IKE_SAs or CHILD_SAs) once the initial exchanges have completed.

It uses a single exchange of packets and may be initiated by either side of the IKE_SA established during the initial exchanges. There are two variants, depending on whether a CHILD_SA or IKE_SA is being modified.

CREATE_CHILD_SA exchange
Figure 21. The CREATE_CHILD_SA exchange can be used to create or rekey a CHILD_SA, or to rekey an IKE_SA. A Notification payload is used when modifying a CHILD_SA to indicate the SPI of the SA to modify.

  • The first exchange depicts a CREATE_CHILD_SA used to create a new CHILD_SA or rekey an existing one.

    Rekeying is indicated by the presence of an N(REKEY_SA) Notification payload sent by the initiator. To complete the rekey operation, a new SA is first created, and the old one is subsequently deleted. The new SA and traffic selector (TS) information allows most of the connection parameters to be altered.

    If desired, new DH values can also be exchanged at this point using KE payloads. This provides better forward secrecy for the new SA.

  • Rekeying an IKE_SA uses a similar exchange, except the KE payloads are required and the TS payloads are not used, as shown in the second part.

4.2.1.12. The INFORMATIONAL Exchange

The INFORMATIONAL exchange is used for conveying status and error information, usually using Notify (N) payloads. It is also used for deleting SAs using a Delete (D) payload and therefore constitutes one portion of the SA rekeying procedure.

An INFORMATIONAL exchange can take place only after successful completion of the initial exchanges. It includes an optional set of notifications, Delete (D) payloads that specify SAs to delete by SPI value, and Configuration (CP) payloads.

Some response is always required for any message received from an initiator, even if it is an empty IKE message (i.e., contains only a header). Otherwise, the initiator would retransmit its message unnecessarily.

In unusual cases, INFORMATIONAL messages may be sent outside the context of an INFORMATIONAL exchange, usually to signal the receipt of an IPsec message containing an unrecognized SPI value or unsupported IKE major version number.

INFORMATIONAL exchange
Figure 22. The INFORMATIONAL exchange is used to convey status information and delete SAs. It makes use of Notification (N), Delete (D), and Configuration (CP) payloads.
4.2.1.13. Mobile IKE (MOBIKE)

Once the IKE_SA has been established, it is ordinarily used until no longer required. However, when IPsec operates in an environment where IP addresses may change because of mobility or interface failure, a variant of IKE has been specified in [RFC4555] called MOBIKE. MOBIKE augments the basic IKEv2 protocol to include additional “address change” options available in INFORMATIONAL exchanges. MOBIKE specifies what to do when the changed addresses are known. It does not address the discovery problem of how to determine these addresses.

4.2.2. Authentication Header (AH)

Defined in [RFC4302], the IP Authentication Header (AH), one of the three major components of IPsec, is an optional portion of the IPsec protocol suite that provides a method for achieving origin authentication and integrity (but not confidentiality) of IP datagrams. By providing only integrity and not confidentiality (and not working with NAT), AH is the (far) less popular of the two primary IPsec data-securing protocols.

In transport mode, AH uses a header placed between the layer 3 (IPv4, IPv6 base, or IPv6 extension) header and the following protocol header (e.g., UDP, TCP, ICMP). With IPv6, AH may appear immediately before a Destination Options extension header, if present.

In tunnel mode, the “inner” IP header carries the original IP datagram, containing the ultimate IP source and destination information, and a newly created “outer” IP header contains information describing the IPsec peers. In this mode, AH protects the entire inner IP datagram.

Generally speaking, transport mode is used between end hosts that are directly connected, and tunnel mode is used between SGs or between a single host and an SG (e.g., for supporting a VPN).

IPsec Authentication Header (transport mode)
Figure 23. The IPsec Authentication Header is used to provide authentication and integrity protection for IPv4 and IPv6 datagrams. In transport mode (depicted here with TCP), a conventional IP datagram is modified to include the AH.

In the figure, the IPv4 encapsulation uses a special IPv4 protocol number (51). For IPv6, the AH is placed between the destination and other options. In either case, the resulting datagram has a mutable portion of its header and an immutable portion of its header.

  • The mutable portion is changed as the datagram moves through the network. Modifications include changing the IPv4 TTL or IPv6 Hop Limit field, IPv6 Flow Label field, DS Field, and ECN bits.

  • The immutable portion, containing the source and destination IP addresses, is not changed by the network and is integrity-protected using fields in the AH. This prevents transport mode AH datagrams from being rewritten by NATs, a potential problem for many deployments.

  • Transport mode cannot be used with fragments (IPv4 or IPv6).

IPsec Authentication Header (tunnel mode)
Figure 24. The IPsec tunnel mode AH encapsulations provide authentication and integrity protection for IPv4 and IPv6 datagrams. In tunnel mode (depicted here carrying TCP), a conventional IP datagram is encapsulated inside a new “outside” IP datagram that carries the original datagram.

In tunnel mode, the entire original IP datagram is untouched, encapsulated and protected with the AH. The “inner” header is unmodified, and the “outer” header is created using the source and destination IP addresses associated with an SG or host.

In such cases, AH protects all of the original datagram, plus some portions of the new header (which prevents it being modified by a NAT).

IPsec Authentication Header
Figure 25. The IPsec AH is used to provide authentication and integrity protection for IPv4 and IPv6 datagrams in either transport or tunnel mode. The SPI value indicates which SA the AH belongs to. The Sequence Number field is used for countering replay attacks. The ICV provides a form of MAC over the immutable portions of the payload.

Both modes of AH use the same AH, and identifies the datagram length and associated SA and includes integrity check information.

  • The Payload Length specifies the length of the AH in 32-bit-word units minus 2.

  • The Security Parameters Index (SPI) field contains a 32-bit identifier of an SA at the receiver that contains SA-derived information relating to the association. For multicast SAs, the SPI value is handled in a special way.

  • The Sequence Number is a 32-bit field that increments by 1 for each packet sent on the SA.

    This field is used for replay protection if enabled by the receiver (but it is always included by the sender, even if not checked by the receiver).

    An extended sequence number (ESN) operating mode is also defined and recommended and is negotiated during the IKE_SA_INIT exchange. If enabled, the sequence number is calculated using 64 bits, but only the lower-order 32 bits are included in the Sequence Number field.

  • The length of the Integrity Check Value (ICV) field is variable and depends on the cryptographic suite used. This field is always an integral multiple of 32 bits in length.

    The algorithm used for integrity protection is specified in the corresponding SA as a type 3 transform and can be established manually or by using some automatic method such as IKE.

    The optional, recommended, and mandatory algorithms for AH (and ESP, later) are provided in [RFC4835] and include HMACMD5-96 (optional), AES-XCBC-MAC-96 (recommended), and HMAC-SHA1-96 (mandatory).

    The integrity check is computed over the following portions of the datagram: header fields before the AH that are either immutable in transit or predictable in value when arriving at the destination AH SA endpoint, the AH, everything after the AH, high-order bits of the ESN (if employed, even though they are not sent), plus any padding.

4.2.3. Encapsulating Security Payload (ESP)

The ESP protocol of IPsec, defined in [RFC4303] (where it is called ESP (v3) even though ESP provides no formal version numbers), provides a selectable combination of confidentiality, integrity, origin authentication, and anti-replay protection for IP datagrams.

It can employ a NULL encryption method [RFC2410], which is mandatory to support, if only integrity is to be used. Conversely, encryption can be used for confidentiality without integrity protection, although this combination is effective only against passive attacks and is highly discouraged.

In the context of ESP, integrity includes data origin authentication. Given its flexibility and feature set, ESP is (far) more popular than AH.

4.2.3.1. Transport and Tunnel Modes

Like AH, ESP has transport and tunnel modes. In tunnel mode, an “outer” IP packet includes an “inner” IP packet that may be entirely encrypted. This provides for a limited form of traffic flow confidentiality (TFC) because the “inner”datagram’s size and contents can be hidden using encryption.

ESP may be used in combination with AH, if desired, and supports both IPv4 and IPv6. Using ESP in “integrity-only” mode may be preferable to AH in some cases for performance reasons (ESP may be more amenable to pipelining) and is a required configuration option for IPsec implementations.

IPsec ESP transport mode
Figure 26. The IPsec ESP is used to provide confidentiality (encryption), authentication, and integrity protection for IPv4 and IPv6 datagrams. In transport mode (depicted here with TCP), a conventional IP datagram is modified to include the ESP head er. ESP in transport mode allows the transport payload to be encrypted, authenticated, and integrity-protected.
IPsec ESP tunnel mode
Figure 27. In tunnel mode (depicted here with TCP), ESP encapsulates a conventional IP datagram inside a new “outside” IP datagram that carries the original datagram. ESP allows the outer datagram to be modified (e.g., for NAT traversal) while the inner datagram remains intact. ESP is more popular than AH for most applications.

The transport mode structure is similar to AH transport mode, except ESP trailer structures are used in support of ESP’s encryption and integrity protection methods. As with AH, ESP transport mode cannot be used with fragments. The tunnel mode encapsulations for ESP, similar to those for AH.

IPsec ESP message structure
Figure 28. The ESP message structure includes the encrypted payload in the middle. The SPI and Sequence Number constitute the ESP header, and the combination of the Pad, Pad Length, and Next Header fields constitutes the ESP trailer. An optional ESP ICV trailer is also used when integrity protection is employed.

ESP does not use a strict header in the same way AH does. Instead, there is an overall ESP structure that includes a header and trailer portion. There is an optional (second) trailer structure if ESP is used with an integrity protection mechanism that requires space for additional check bits (labeled ESP ICV).

ESP-encapsulated IP datagrams use the value 50 in the Protocol (IPv4) or Next Header (IPv6) header fields.

The ESP payload structure, includes the SPI and sequence numbers, used in the same way as with AH. The primary difference is in the payload area. This area may be confidentiality-protected (encrypted) and can include a variable-length pad portion required by some encryption algorithms.

  • The payload is required to end on a 32-bit boundary (64 for IPv6) and have the last two 8-bit fields identify the Pad Length and Next Header (Protocol) field values. The Pad, Pad Length, and Next Header fields constitute the ESP trailer.

  • Certain cryptographic algorithms may employ an IV. If present, the IV appears at the beginning of the payload area (not shown).

  • Additional padding for TFC purposes (called TFC padding) is permitted to appear within the payload area in front of the ESP trailer.

    It is used to disguise the length of the datagram to help resist traffic analysis attacks, although this features does not appear to be widely used.

  • The Next Header field contains values chosen from the same space used in the IPv4 Protocol field or IPv6 Next Header field (e.g., 4 for IPv4, 41 for IPv6).

    It may contain the value 59, indicating “no next header,” when carrying a dummy packet that is to be discarded. Dummy packets are another method sometimes used for resisting traffic analysis attacks.

  • The ESP ICV is a variable-length trailer used if integrity support is enabled and required by the integrity-checking algorithm.

    It is computed over the ESP header, payload, and ESP trailer. Implicit values (e.g., high-order ESN bits) are also included.

    The length of the ICV is known as a consequence of selecting the particular integrity-checking method. It is therefore established at the time the corresponding SA is set up and not changed as long as the SA exists.

Anti-replay is supported provided integrity protection is enabled.

  • This is accomplished using a sequence number derived from a running counter. The counter is initialized to 0 when an SA is first set up and incremented before being copied into each datagram sent on the SA.

  • When anti-replay is enabled (the normal default), the sender checks to see that the counter has not wrapped and creates a new SA if wrapping is about to occur.

  • The receiver implementing anti-replay keeps a valid window of sequence numbers (similar in some ways to the TCP receiver’s window).

    Datagrams containing out-of-window sequence numbers are dropped.

For systems that implement auditing, ESP processing can result in one or more auditable events.

  • These events include the following: no valid SA exists for a session, the datagram given to ESP for processing is a fragment, the anti-replay counter is about to wrap, a received packet was out of the valid anti-replay window, the integrity check failed.

  • Auditable events are recorded in a logging system. These events include metadata such as the SPI value, current date and time, source and destination IP addresses, sequence number, and IPv6 flow ID (if present).

4.2.3.2. ESP-NULL, Wrapped ESP (WESP), and Traffic Visibility

ESP ordinarily provides privacy using encryption, but it can also operate in an integrity-only mode using the NULL encryption algorithm.

  • Integrity-only mode (also called ESP-NULL) may be desirable in some circumstances, especially in enterprise environments where sophisticated packet inspection takes place within the network and confidentiality may be addressed in other ways.

    For example, some network infrastructure devices inspect packets for unwanted content (e.g., malware signatures) and are capable of providing alerts or shutting down network access when policy is violated. Such devices are essentially disabled if ESP is used with encryption in an end-to-end fashion (i.e., the way it was designed). Said another way, unless they have traffic visibility, they cannot do their jobs.

When a packet inspection device is faced with ESP traffic, it needs to make a decision about whether the traffic is encrypted (i.e., whether NULL encryption is being used or not).

Given that the negotiation of an IPsec cryptographic suite is handled outside ESP (e.g., manually or using a protocol such as IKE), there are two current methods for doing so.

  • The first is simply to use a set of nonstandard heuristics to make a guess [RFC5879]. Use of these has the benefit of not requiring any modification to ESP for supporting traffic visibility.

  • The other method is to add a special description to ESP to indicate whether encryption is used.

    Wrapped ESP (WESP) [RFC5840], a standards-track RFC, defines a header that is placed ahead of the ESP packet structure. WESP uses a different protocol number (141) from ESP and can be negotiated with IKE using the USE_WESP_MODE (value 16415) Notify payload.

    The variable-length WESP header includes fields to indicate the location of payload information, along with a Flags field (maintained by the IANA [IWESP]) containing a bit indicating whether ESP-NULL is being used.

    Although WESP makes the job of determining whether ESP-NULL is being used or not easier for network infrastructure, its utility also depends on end hosts using the WESP header appropriately.

    Given that WESP is relatively new, this is not yet the case today. On the other hand, the WESP format is extensible, so once implemented it could be adapted for other purposes in the future.

4.2.4. Multicast

IPsec optionally supports multicast operations [RFC5374], although this capability is not often used. The most basic form involves using manual key configuration, but there are also multicast group key establishment methods called group key management (GKM) protocols managed by group controller/key servers (GCKSs).

4.2.5. L2TP/IPsec

The Layer 2 Tunneling Protocol (L2TP) supports tunneling of layer 2 traffic such as PPP through IP and non-IP networks.

It relies on authentication methods that provide some authentication during connection initiation, but no subsequent per-packet authentication, integrity protection, or confidentiality.

To address this concern, L2TP can be combined with IPsec [RFC3193]. The combination, called L2TP/IPsec, provides a recommended method to establish remote layer 2 VPN access to enterprise (or home) networks.

L2TP can be secured with IPsec using either a direct L2TP-over-IP encapsulation (protocol number 115) or a UDP/IP encapsulation that eases NAT traversal.

L2TP/IPsec uses IKE by default, although other keying methods are possible.

  • It uses an ESP SA in either transport mode (support required) or tunnel mode (support optional). The SA is used to secure the L2TP traffic, which is then responsible for establishing the layer 2 tunnel.

  • Because it is really a combination of two protocols, both of which involve authentication, L2TP/IPsec often requires two distinct authentication procedures: one for the machine (using IPsec with pre-shared keys or certificates) and another for the user (e.g., using a name and password or access token).

L2TP/IPsec is supported on most modern platforms.

  • On Windows, creating a new connection with the “Connect to a workplace” option can be used to enable L2TP and L2TP/IPsec.

  • Some smartphones (e.g., Android, iPhone) support L2TP in their networking configuration setup screens.

  • Mac OS X includes an L2TP/IPsec network adapter type that can be added using the system preferences.

  • On Linux, it may be necessary to configure both IPsec and L2TP for them to work together.

If L2TP is not required on such systems, direct IPsec may be preferable.

4.2.6. IPsec NAT Traversal

Using NATs with IPsec can present something of a challenge, primarily because IP addresses have traditionally been used in identifying communication endpoints and are assumed to not change. These assumptions were not entirely avoided (or obviated) when IPsec was first designed, so NAT has posed a problem. This is one factor contributing to the relatively slow deployment of IPsec. However, today IPsec supports both changing addresses (with MOBIKE) and NAT traversal.

4.2.7. IPsec implementations

There are several open-source and proprietary IPsec implementations.

  • Windows 7 supports IKEv2 and MOBIKE in Microsoft’s Agile VPN subsystem.

  • Linux includes kernel-level IPsec support in kernel version 2.6 and later, and the OpenSwan and StrongSwan packages can be used to implement complete VPN solutions.

4.3. Transport Layer Security (TLS and DTLS)

The most widely used protocol for security just above the transport layer is called Transport Layer Security (TLS), which is used for securing Web communications and other popular protocols, including POP and IMAP (called POP3S and IMAPS, respectively, when protected with TLS).

TLS is implemented within or underneath applications that ride on top of the lower layers, whereas protocols such as EAP and IPsec usually require capabilities within the operating systems and protocol implementations of hosts and embedded devices.

There are several versions of TLS and its predecessor, the Secure Sockets Layer (SSL) [RFC6101].TLS version 1.2 [RFC5246], which operates over a stream-oriented protocol (usually TCP), is the most recent at the time of writing.

Transport Layer Security | From Wikipedia, the free encyclopedia

TLS is a proposed Internet Engineering Task Force (IETF) standard, first defined in 1999, and the current version is TLS 1.3, defined in August 2018. TLS builds on the now-deprecated SSL (Secure Sockets Layer) specifications (1994, 1995, 1996) developed by Netscape Communications for adding the HTTPS protocol to their Navigator web browser.

TLS 1.2 can support backward compatibility with most older versions of TLS and SSL (e.g., TLS 1.0, 1.1, and SSL 3.0). However, SSL 2.0 is weaker, and while interoperability with it is possible, it is now prohibited [RFC6176].

The Datagram Transport Layer Security (DTLS) [RFC4347], a datagram-oriented variant, is slowly gaining popularity for some applications such as VPN implementations that do not use IPsec.

4.3.1. TLS 1.2

The security goals of TLS are not unlike those for IPsec, but TLS operates at a higher layer.

  • Confidentiality and data integrity are provided based on a variety of cryptographic suites that use certificates that can be provided by a PKI.

  • TLS can also establish secure connections between two anonymous parties (without using certificates), but this application is vulnerable to a MITM attack (not surprising, given that each end is not even strongly identified).

  • The TLS protocol has two layers of its own, called the record layer and the upper layer.

    The Record protocol implements the record (lower) layer and is assumed to be layered on a reliable underlying protocol (e.g., TCP).

TLS protocol stack
Figure 29. The TLS protocol “stack” has a lower record layer and three of its own upper-layer protocols called handshaking protocols. A fourth upper-layer protocol is the application protocol using TLS. The record layer provides fragmentation, compression, integrity protection, and encryption. The handshaking protocols perform many of the same tasks for TLS that IKE does for IPsec.

TLS is a client/server protocol, designed to support security for a connection between two applications.

  • The Record protocol provides fragmentation, compression, integrity protection, and encryption for data objects exchanged between clients and servers,

  • and the handshake protocols establish identities, perform authentication, indicate alerts, and provide unique key material for the Record protocol to use on each connection.

    The handshaking protocols comprise four specific protocols: the Handshake protocol, the Alert protocol, the Change Cipher Spec protocol, and the application data protocol.

    Like IPsec, TLS is extensible and can accommodate existing or future cryptographic suites, which TLS calls cipher suites (CS).

  • Modern variants of TLS are based on SSL 3.0, originally developed by Netscape.

    TLS and SSL do not directly interoperate, but there are negotiation mechanisms that allow clients and servers to dynamically discover which protocol to use when a connection is first established.

  • TLS depends on five cryptographic operations: digital signing, stream cipher encryption, block cipher encryption, AEAD, and public key encryption.

    For integrity protection, the TLS record layer uses HMAC. For key generation, TLS 1.2 uses a PRF based on HMAC with SHA-256.

    TLS also integrates an optional compression algorithm that is negotiated when a connection is first established.

4.3.1.1. TLS Record Protocol

The Record protocol uses an extensible set of record content type values to identify which message type (i.e., which of the higher-layer protocols) is being multiplexed.

At any given point in time, the Record protocol has an active current connection state and another set of state parameters called the pending connection state.

  • Each connection state is further divided into a read state and a write state.

  • Each of these states specifies a compression algorithm, encryption algorithm, and MAC algorithm to be used for communication, along with any necessary keys and parameters.

  • When a key is changed, the pending state is first set up using the Handshake protocol, and then a synchronization operation (usually accomplished using the Cipher Change protocol) sets the current state equal to the pending state. When first initialized, all states are set up with NULL encryption, no compression, and no MAC processing.

TLS Record protocols processing flow
Figure 30. The TLS record layer starts with a TLSPlaintext record, which is compressed by a lossless compression algorithm to form a TLSCompressed record. The TLSCompressed record is encrypted (and has a MAC applied) to form a TLSCiphertext record, which is sent for transmission. Conventional stream and block ciphers require a MAC, and block ciphers may include padding. When using AEAD ciphers, a nonce is included with the encrypted and integrity-protected content, but no separate MAC is used.

  • The Record protocol’s processing flow divides (fragments) higher-layer information blocks into records called TLSPlaintext records, which can be at most 214 bytes in length (but are usually much less).

    The choice of record size resides within TLS; higher-layer message boundaries are not preserved.

  • Once formed, TLSPlaintext records are compressed using a compression algorithm [RFC3749] identified in the current connection state.

    There is always one compression protocol active, although it may be (and usually is) the NULL compression protocol (which, not surprisingly, provides no compression gain). The compression algorithm converts a TLSPlaintext record into a TLSCompressed structure.

    Compression algorithms are required to be lossless and may not produce an output that is larger than the input by more than 1KB.

  • To protect the payload from disclosure and modification, encryption and integrity protection algorithms convert a TLSCompressed structure into a TLSCiphertext structure, which is then sent on the underlying transport connection.

    When producing a TLSCiphertext structure, a sequence number is first computed (but not placed in the message), then a MAC is computed if necessary, and finally symmetric encryption is performed.

    Prior to encryption, the message may be padded (up to 255 bytes) to meet any block length requirements imposed by the encryption algorithm (e.g., for block ciphers).

    A MAC is not required for AEAD algorithms that provide both integrity and encryption (e.g., CCM, GCM), but a nonce is used in such cases.

Keys for the Record protocol are derived from a master secret provided by some method outside the Record protocol, most often by the Handshake protocol.

Mc | Ms | Dc | Ds | IVc | IVs = PRF(master_secret, "key expansion", server_random + client_random)

Mc denotes the MAC write key for the client, Ms denotes the MAC write key for the server, Dc denotes the client’s data write key, Ds denotes the server’s data write key, IVc denotes the client’s IV, and IVs denotes the server’s IV.

4.3.1.2. TLS Handshaking Protocols

There are three subprotocols to TLS, which perform tasks roughly equivalent to those performed by IKE in IPsec. More specifically, these other protocols are identified by numbers used for multiplexing and demultiplexing by the record layer and are called the Handshake protocol (22), Alert protocol (21), and Cipher Change protocol (20).

  • The Cipher Change protocol is very simple. It consists of one message containing a single byte that has the value 1. The purpose of the message is to indicate to the peer a desire to change from the current to the pending state. Receiving such a message moves the read pending state to the current state and causes an indication to the record layer to transition to the pending write state as soon as possible. This message is used by both client and server.

  • The Alert protocol is used to deliver status information from one end of a TLS connection to another. This can include terminating conditions (either fatal errors or controlled shutdowns) or nonfatal error conditions. As of the publication of [RFC5246], 24 alert messages were defined in standards. More than half of them are always fatal (e.g., bad MACs, missing or unknown messages, algorithm failures).

  • The Handshake protocol sets up the relevant connection operating parameters. It allows the TLS endpoints to achieve six major objectives: agree on algorithms and exchange random values used in forming symmetric encryption keys, establish algorithm operating parameters, exchange certificates and perform mutual authentication, generate a session-specific secret, provide security parameters to the record layer, and verify that all of these operations have executed properly.

TLS connection initiation exchange
Figure 31. The normal TLS connection initiation exchange consists of several messages that may be pipelined. Required messages have solid arrows and are shown in boldface type. An abbreviated exchange takes place if a previously existing connection can be restarted. This avoids endpoint authentication, which can be costly for systems with limited processing capabilities.

  • The ClientHello message is usually the first message sent from client to server, that contains a session ID, proposals for the cryptographic suite number (CS), and a set of acceptable compression algorithms, also contains the TLS version number and a random number called ClientHello.random.

  • Upon receiving the ClientHello message, the server checks to see if the session ID is present in its cache, and may agree to continue a previously existing connection (called a “resume”) by performing an abbreviated handshake.

    The abbreviated handshake is key to TLS performance and avoids having to repeatedly verify the authenticity of each endpoint, but it does require synchronization with respect to the cipher specification.

    • The ServerHello message completes the first part of the exchange by carrying the server’s random number (ServerHello.random) to the client.

    • The ServerHello message also contains a session ID value.

      • If the session ID value is the same as that provided by the client, it indicates the server’s willingness to resume.

      • If not, it has the value 0 and a full handshake is required.

    • If a full (non-abbreviated) handshake is executed, the exchange of Hello messages results in each end becoming aware of the cipher suites, compression algorithms, and random values of its peer.

      • The server selects among the cryptographic suites specified by the client and may be required to provide its certificate chain in a Certificate message if it is to be authenticated (which is the typical case for secure Web traffic or HTTPS).

      • The server may also send a ServerKeyExchange message if its certificate is not valid for signing, it has no certificate, or a temporary or ephemeral key is to be used to generate session keys.

        The ServerKeyExchange message is used only in cases where the Certificate (server) message does not contain enough information to establish a premaster secret.

        Such cases include anonymous or ephemeral DH key agreement (i.e., cipher suites starting with TLS_DHE_anon, TLS_DHE_DSS, TLS_ DHE_RSA).

        The ServerKeyExchange message is not used for other suites, including those starting with TLS_RSA, TLS_DH_DSS, or TLS_DH_RSA.

    • At this point, the server may require client authentication. If so, it generates a CertificateRequest message.

    • Once this message is sent, the server completes the second portion of the exchange by sending the mandatory ServerHelloDone message.

  • Upon receiving this (possibly pipelined) message from the server, the client may be required to prove its identity (i.e., knowledge of an appropriate private key corresponding to a certificate).

    • If so, it first sends its certificate using a Certificate message in the same format used by the server.

    • It then sends the mandatory ClientKeyExchange message.

      The contents of this message depend on the cryptographic suite used, but it generally contains either an RSA-encrypted key or Diffie-Hellman parameters that may be used to create a type of seed for creating new keys (called the premaster secret).

    • Finally, it sends a CertificateVerify message to demonstrate that it possesses the private key corresponding to the previously provided certificate, if the server requested client authentication.

      This message contains a signature on the hash of all of the handshake messages the client has received and sent up to this point.

  • The final portion of the exchange includes a ChangeCipherSpec message, which is an independent TLS protocol content type (i.e., technically not a Handshake protocol message).

    However, the mandatory Handshake protocol Finished messages can be exchanged only after a successful exchange of ChangeCipherSpec messages.

  • The Finished messages are the first ones to be protected using the parameters exchanged up to this point, and contain “verify data,” which consists of the following value:

    verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))

    • where finished_label has the value “client finished” for the client and “server finished” for the server.

    • The particular hash function Hash is associated with the selection of the PRF made during the initial Hello exchange.

    • The 48-byte master_secret value is computed as follows, where + is the concatenation operator

      master_secret = PRF(premaster secret, “master secret”, ClientHello.random + ServerHello.random)

      The Finished message is important because it can be used to know with a high degree of certainty that the Handshake protocol has completed successfully and subsequent data exchange can take place.

4.3.2. TLS Extensions

To provide an extensible mechanism for TLS, like IKE using Notify and Configuration payloads to carry information, various extensions can be included with TLS 1.2 messages in a standard way.

The baseline specification for TLS 1.2 [RFC5246] includes a signature algorithms extension that a client uses to specify to a server what types of hash and signature algorithms it supports.

MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 for hashes and RSA, DSA, ECDSA for digital signatures.

4.3.3. Renegotiation

TLS supports the ability to renegotiate cryptographic connection parameters while maintaining the same connection. This can be initiated by either the server or the client. If the server wishes to renegotiate the connection parameters, it generates a HelloRequest message, and the client responds with a new ClientHello message, which begins the renegotiation procedure. The client is also able to generate such a ClientHello message spontaneously, without prompting from the server.

4.3.4. Example

# Create a self-signed CA cetrifacate
openssl req -x509 \
    -subj "/CN=work.icu" \
    -addext "subjectAltName=DNS:work.icu,DNS:*.work.icu" \
    -addext "keyUsage=digitalSignature,cRLSign,keyCertSign" \
    -addext "extendedKeyUsage=serverAuth,clientAuth" \
    -days 365 \
    -nodes -newkey rsa:2048 \
    -keyout work.icu.key \
    -out work.icu.crt \
    > /dev/null 2>&1

# Create a sever/client certificate and sign it by CA
openssl req -subj "/CN=996.icu" \
    -addext "subjectAltName=DNS:996.icu,DNS:*.996.icu" \
    -addext "basicConstraints=CA:false" \
    -addext "keyUsage=digitalSignature,keyEncipherment" \
    -addext "extendedKeyUsage=serverAuth,clientAuth" \
    -nodes -newkey rsa:2048 \
    -x509 \
    -CA work.icu.crt -CAkey work.icu.key \
    -copy_extensions copy \
    -keyout 996.icu.key \
    -out 996.icu.crt \
    > /dev/null 2>&1

# Install the root CA ceretificate into local trust store
sudo cp work.icu.crt /usr/local/share/ca-certificates/extra/
sudo update-ca-certificates
$ # Create a server for 996.icu
$ cat /etc/nginx/sites-enabled/996.icu
server {
	listen 80;
	listen [::]:80;

    server_name  *.996.icu;

    return 308 https://$host:443$request_uri;
}

server {
	listen 443 ssl;
	listen [::]:443 ssl;

    server_name  *.996.icu;

    ssl_certificate     996.icu.crt;
    ssl_certificate_key 996.icu.key;

	root /var/www/html;

	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;

	server_name _;

	location / {
		try_files $uri $uri/ =404;
	}
}

$ # Test and reload Nginx
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo nginx -s reload
2023/08/09 17:44:53 [notice] 142427#142427: signal process started

$ # Test the configuration
$ curl -iIL localhost -H 'Host: 996.icu'
HTTP/1.1 308 Permanent Redirect
Server: nginx/1.22.1
Date: Wed, 09 Aug 2023 09:46:48 GMT
Content-Type: text/html
Content-Length: 171
Connection: keep-alive
Location: https://996.icu:443/

HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Wed, 09 Aug 2023 09:46:48 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Fri, 25 Oct 2019 06:07:47 GMT
Connection: keep-alive
ETag: "5db29133-264"
Accept-Ranges: bytes
# Use `tcpdump` to capture HTTPS traffic on local lookback interface
sudo tcpdump -i lo port 443 -w 996.v1.2.icu.pcap
$ curl -v --tlsv1.2 --tls-max 1.2 -iI https://996.icu --resolve 996.icu:443:127.0.0.1
* Added 996.icu:443:127.0.0.1 to DNS cache
* Hostname 996.icu was found in DNS cache
*   Trying 127.0.0.1:443...
* Connected to 996.icu (127.0.0.1) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=996.icu
*  start date: Aug  9 09:06:00 2023 GMT
*  expire date: Aug  8 09:06:00 2024 GMT
*  subjectAltName: host "996.icu" matched cert's "996.icu"
*  issuer: CN=996.icu
*  SSL certificate verify ok.
* using HTTP/1.1
> HEAD / HTTP/1.1
> Host: 996.icu
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.22.1
Server: nginx/1.22.1
< Date: Wed, 09 Aug 2023 10:51:30 GMT
Date: Wed, 09 Aug 2023 10:51:30 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 612
Content-Length: 612
< Last-Modified: Fri, 25 Oct 2019 06:07:47 GMT
Last-Modified: Fri, 25 Oct 2019 06:07:47 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "5db29133-264"
ETag: "5db29133-264"
< Accept-Ranges: bytes
Accept-Ranges: bytes

<
* Connection #0 to host 996.icu left intact
A ClientHello message in TLS 1.2
Figure 32. A ClientHello message in TLS 1.2 contains version information, supported cipher suites and compression algorithms, random data, and a number of extensions.
A ServerHello message in TLS 1.2
Figure 33. A ServerHello message in TLS 1.2 contains version information, supported cipher suites and compression algorithms, and a number of extensions. Here, the client supports EC Diffie-Hellman key agreement. It uses AES-256-GCM for encryption and SHA-384 for integrity protection.

4.3.5. TLS with Datagrams (DTLS)

The TLS protocol assumes a stream-based underlying transport protocol for delivering its messages. A datagram version (DTLS) relaxes this assumption but aims to otherwise achieve the same security goals as TLS using essentially all the same message formats. It was originally motivated by protocols such as SIP that run on UDP but do not care to use IPsec [RFC5406]. DTLS has also been adapted for use with DCCP [RFC5238] and SCTP [RFC6083].

5. DNS Security (DNSSEC)

Security for DNS covers both data within the DNS (resource records or RRs) as well as security of transactions that synchronize or update contents of DNS servers. A major effort has been undertaken to deploy these security mechanisms are called the Domain Name System Security Extensions (DNSSEC) and are discussed in a family of RFCs [RFC4033][RFC4034][RFC4035].

Appendix A: FAQs

A.1. AES, AES-128, AES-192, and AES-256?

AES (Advanced Encryption Standard) is a symmetric block cipher used for encrypting and decrypting data. It operates on fixed-size blocks of data (128 bits) and uses a secret key for both encryption and decryption.

The only way to find out if a decryption will fail is by attempting to decrypt it using the key you have. If the key is incorrect or the ciphertext is corrupted, the decryption will produce garbled or meaningless output. In some cases, you can also get an error or an exception while trying to decrypt, depending on the padding scheme used and the library you’re using.

AES is available in three different key lengths: AES-128, AES-192, and AES-256. The differences among AES, AES-128, and AES-256 are mainly related to the key length and the number of encryption rounds.

  1. AES-128:

    • Key length: 128 bits (16 bytes)

    • Number of rounds: 10

    AES-128 uses a 128-bit key and performs 10 rounds of encryption and decryption. It is the fastest and requires the least amount of memory among the three AES key lengths, making it suitable for applications with limited resources or where performance is critical.

  2. AES-192:

    • Key length: 192 bits (24 bytes)

    • Number of rounds: 12

    AES-192 uses a 192-bit key and performs 12 rounds of encryption and decryption. It provides a higher security level compared to AES-128, but it is slower and requires more memory.

  3. AES-256:

    • Key length: 256 bits (32 bytes)

    • Number of rounds: 14

    AES-256 uses a 256-bit key and performs 14 rounds of encryption and decryption. It provides the highest security level among the three key lengths, making it suitable for applications requiring strong encryption. However, it is the slowest and requires the most memory.

In summary, the differences among AES, AES-128, and AES-256 are related to the key length and the number of encryption rounds.

  • AES-128 is the fastest and requires the least memory, while AES-256 provides the highest security level but is slower and requires more memory.

  • AES-192 offers a balance between performance and security.

  • The choice of which AES key length to use depends on the specific requirements of the application and the desired balance between security, performance, and memory usage.

The Initialization Vector (IV) length for all AES variants (AES-128, AES-192, and AES-256) is the same because the IV size depends on the block size of the cipher, not the key size.
For AES, the block size is 128 bits. Therefore, the IV length for AES-128, AES-192, and AES-256 is 128 bits or 16 bytes.
Remember that the IV should be unique and random for each encryption operation to maintain the security of the encrypted data. Although the IV can be public, ensure that the encryption key remains secret and secure.

A.2. AES and AES-GCM

AES (Advanced Encryption Standard) and AES-GCM (Advanced Encryption Standard with Galois/Counter Mode) are related concepts in cryptography, but they serve different purposes.

  1. AES (Advanced Encryption Standard): AES is a symmetric key encryption algorithm that operates on blocks of fixed size (128 bits) with key sizes of 128, 192, or 256 bits. It is widely used for encrypting and decrypting data to ensure confidentiality. AES itself is a block cipher and does not specify how the blocks should be processed. To process multiple blocks, a block cipher mode of operation is used, such as ECB (Electronic Code Book), CBC (Cipher Block Chaining), CTR (Counter), or GCM (Galois/Counter Mode).

  2. AES-GCM (Advanced Encryption Standard with Galois/Counter Mode): AES-GCM is a specific mode of operation for the AES block cipher. It combines the AES block cipher with the Galois/Counter Mode (GCM) to provide both encryption and authentication. AES-GCM is an authenticated encryption with associated data (AEAD) scheme, which means it not only ensures the confidentiality of the encrypted data but also provides integrity checks and authentication. This is achieved by generating an authentication tag during the encryption process, which is verified during decryption to ensure that the data has not been tampered with.

In summary, AES is the underlying block cipher used for encryption and decryption, while AES-GCM is a specific mode of operation that combines AES with the GCM mode to provide both encryption and authentication.

Using AES-GCM is recommended for modern applications as it provides both data confidentiality and integrity, ensuring that the encrypted data is not tampered with.

A.3. What’s the SALT and IV in AES?

In AES (Advanced Encryption Standard), "salt" and "IV" (Initialization Vector) serve different purposes and are used in different contexts.

  • Salt: A salt is a random value that is combined with a password or secret key during the key derivation process. The purpose of using a salt is to prevent attacks that use precomputed tables (such as rainbow tables) to find the original password or key.

    By adding a unique, random salt to the input, the output of the key derivation function becomes unique for each salt value, making precomputed attacks infeasible.

    In the context of AES, salts are typically used when generating a key from a password using a key derivation function like PBKDF2, bcrypt, or scrypt.

  • IV (Initialization Vector): An IV is a random value used as the starting point for certain block cipher modes of operation, such as CBC (Cipher Block Chaining) or GCM (Galois/Counter Mode). The purpose of using an IV is to ensure that the same plaintext encrypted with the same key results in different ciphertexts each time. This adds an extra layer of security and prevents attackers from recognizing patterns in the encrypted data.

    The IV should be unique and random for each encryption operation with the same key.

    In AES, the IV is used in conjunction with the chosen mode of operation (e.g., AES-CBC or AES-GCM) and is not part of the core AES algorithm itself.

In AES (Advanced Encryption Standard), the Initialization Vector (IV) size depends on the block size of the cipher and the mode of operation used, such as AES-CBC (Cipher Block Chaining) or AES-GCM (Galois/Counter Mode). For AES, the block size is always 128 bits, regardless of the key size (128, 192, or 256 bits).

  • AES-CBC (Cipher Block Chaining): In AES-CBC mode, the IV size must be equal to the block size of the cipher, which is 128 bits (16 bytes) for AES.

    The IV is combined with the first block of plaintext using an XOR operation before encryption and should be unique and random for each encryption operation with the same key.

  • AES-GCM (Galois/Counter Mode): In AES-GCM mode, the recommended IV size is 96 bits (12 bytes).

    Using a 96-bit IV is considered the most efficient and secure option for GCM mode because it avoids the need for additional processing to generate the internal counter block.

    However, it is possible to use other IV sizes with AES-GCM, but this requires an additional step called GHASH to compute a new IV based on the original IV.

In summary, the salt is used during the key derivation process to add randomness and prevent precomputed attacks, while the IV is used during encryption with specific block cipher modes of operation to ensure the uniqueness of the resulting ciphertexts. The IV size for AES-CBC is 128 bits (16 bytes), and for AES-GCM, the recommended size is 96 bits (12 bytes). Both salt and IV contribute to the overall security of AES encryption.

Using a unique and random IV for each encryption operation with the same key is essential for maintaining the security of the encryption scheme.

A.4. OpenSSL: Cryptography and SSL/TLS Toolkit

The OpenSSL Project develops and maintains the OpenSSL software - a robust, commercial-grade, full-featured toolkit for general-purpose cryptography and secure communication. [OPENSSL]

A good starting point for understanding some of the key concepts in OpenSSL 3.0 is the libcrypto manual page. Information and notes about migrating existing applications to OpenSSL 3.0 are available in the OpenSSL 3.0 Migration Guide. The frequently-asked questions (FAQ) page is available.

The OpenSSL crypto library ("libcrypto") implements a wide range of cryptographic algorithms used in various Internet standards. The services provided by this library are used by the OpenSSL implementations of TLS and CMS, and they have also been used to implement many other third party products and protocols.

The functionality includes symmetric encryption, public key cryptography, key agreement, certificate handling, cryptographic hash functions, cryptographic pseudo-random number generators, message authentication codes (MACs), key derivation functions (KDFs), and various utilities.

$ openssl version
OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023)
$ echo "Hello, 世界"  > plaintext.txt

$ # Encrypt a message using a passphrase, a randomly generated salt, and a key derived with PBKDF2:
$ openssl enc -aes-256-cbc -pbkdf2 -salt -in plaintext.txt -out ciphertext.txt -pass pass:123456

$ # Decrypt the encrypted message with the encrypted key derived with PBKDF2 from the same passphrase
$ openssl enc -aes-256-cbc -pbkdf2 -d -in ciphertext.txt -out message.txt -pass pass:123456
$ cat message.txt
Hello, 世界
$ # Generate a private and public key pair for Alice (RSA)
$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out alice.key -quiet
$ openssl rsa -in alice.key -pubout -out alice.pub
writing RSA key

$ cat alice.pub
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAw+BE9N6B2sz4MaM0aOZe
...
DwCtw8HP1vA5BEsOcogjCV8CAwEAAQ==
-----END PUBLIC KEY-----

$ cat alice.key
-----BEGIN PRIVATE KEY-----
MIIJQQIBADANBgkqhkiG9w0BAQEFAASCCSswggknAgEAAoICAQDD4ET03oHazPgx
...
Fb4D3jFp0r9UrlYIM1mtEI3wZbvg
-----END PRIVATE KEY-----
$ # Generate a private and public key pair for Bob (ECC)
$ openssl genpkey -algorithm EC -out bob.key -pkeyopt ec_paramgen_curve:secp384r1 -pkeyopt ec_param_enc:named_curve
$ openssl pkey -in bob.key -pubout -out bob.pub

$ cat bob.key
-----BEGIN PRIVATE KEY-----
MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDCnOkyORJs4ESXkkdIM
...
3c7TzHSDQLACE8hp4slbh6BeatQMyuzZlSY+ajIfPyiiHhsaD3a5qC0=
-----END PRIVATE KEY-----
$ cat bob.pub
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEEFQE3OsITjygGFvfg0qjwK1SZJJXUOZM
...
XmrUDMrs2ZUmPmoyHz8ooh4bGg92uagt
-----END PUBLIC KEY-----

$ ls
alice.key  alice.pub  bob.key  bob.pub
$ # Encrypt a message using a public key.
$ openssl pkeyutl -encrypt -pubin -inkey alice.pub -in message.txt -out ciper.txt

$ # Decrypt the encrypted data using a private key.
$ openssl pkeyutl -decrypt -inkey alice.key -in ciper.txt
Hello, 世界
$ # Sign a message using a private key
$ openssl pkeyutl -sign -inkey alice.key -in message.txt -out sig.txt

$ # Verify the signature (e.g. a DSA key)
$ openssl pkeyutl -verify -inkey alice.pub -pubin -sigfile sig.txt -in message.txt
Signature Verified Successfully
$ # The digest functions output the message digest of a supplied file or files in hexadecimal.
$ openssl dgst -sha256 -hex -out dgst.txt message.txt
$ cat dgst.txt
SHA2-256(message.txt)= a281e84c7f61393db702630c2a6807e871cd3b6896c9e56e22982d125696575c
$ cat message.txt | sha256sum
a281e84c7f61393db702630c2a6807e871cd3b6896c9e56e22982d125696575c  -

$ # The digest functions also generate and verify digital signatures using message digests.
$ openssl dgst -sha256 -sign alice.key -out sig.txt.0 message.txt
$ openssl dgst -sha256 -verify alice.pub -signature sig.txt.0 message.txt
Verified OK
$ # When signing a file, dgst will automatically determine the algorithm (RSA, ECC, etc) to use for signing \
$ # based on the private key's ASN.1 info.
$ openssl asn1parse -in alice.pub
    0:d=0  hl=4 l= 546 cons: SEQUENCE
    4:d=1  hl=2 l=  13 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   17:d=2  hl=2 l=   0 prim: NULL
   19:d=1  hl=4 l= 527 prim: BIT STRING

$ openssl asn1parse -in bob.pub
    0:d=0  hl=2 l= 118 cons: SEQUENCE
    2:d=1  hl=2 l=  16 cons: SEQUENCE
    4:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   13:d=2  hl=2 l=   5 prim: OBJECT            :secp384r1
   20:d=1  hl=2 l=  98 prim: BIT STRING
$ echo "Hello, 世界" > message.txt
$ openssl rand -hex 16 | tee key.txt
40921c47c8086ad7a10059c94b35eb3d
$ # Create a hex-encoded (two hex digits per byte) HMAC-SHA256 MAC of a file and write to stdout
$ openssl mac -digest sha256 -macopt hexkey:$(cat key.txt) -in message.txt HMAC
7508EA0525F0F40CDF263089D5B4826D23342AAAE97EA77DAB44A325DE83AAE1

A.5. How to generate an encrypted key for AES using OpenSSL?

The best way to generate an encrypted key for AES using OpenSSL involves creating a strong, random symmetric key and then securely storing it.

You can use the openssl rand command, which generates cryptographically secure random bytes. The key size depends on the AES variant you want to use: AES-128, AES-192, or AES-256. Here’s how to generate a key for each AES variant:

$ # 1. Generate a 128-bit key for AES-128:
$ openssl rand -out aes128_key.bin 16

$ # 2. Generate a 192-bit key for AES-192:
$ openssl rand -out aes192_key.bin 24

$ # 3. Generate a 256-bit key for AES-256:
$ openssl rand -out aes256_key.bin 32

These commands will generate random binary files with the specified number of bytes (16 bytes for AES-128, 24 bytes for AES-192, and 32 bytes for AES-256). You can then use these keys with the openssl enc command or other AES encryption tools.

It is essential to protect the confidentiality of the generated AES keys, as anyone with access to the key can decrypt the encrypted data.

If you want to encrypt the generated key using a passphrase, you can use the openssl enc command with a suitable encryption algorithm like AES-256-CBC. For example:

$ openssl enc -aes-256-cbc -salt -in aes_key.bin -out encrypted_aes_key.bin -pass pass:your_secure_passphrase

  • This command encrypts the aes_key.bin file using AES-256-CBC with a provided passphrase, adding a random salt for key derivation, and saves the encrypted key in the file encrypted_aes_key.bin.

  • Make sure to replace "your_secure_passphrase" with a strong, unique passphrase.

To decrypt the encrypted key when needed, use the following command:

$ openssl enc -d -aes-256-cbc -in encrypted_aes_key.bin -out decrypted_aes_key.bin -pass pass:your_secure_passphrase

  • This command decrypts the encrypted_aes_key.bin file using the provided passphrase and saves the decrypted key in the file decrypted_aes_key.bin.

Remember to protect the key file and passphrase, as they are required to decrypt the data encrypted with the generated AES key. Store them securely and restrict access to only the users or systems that need them.

You can also derive an AES key from a human-readable passphrase using a KDF (Key Derivation Function), such as PBKDF2 (Password-Based Key Derivation Function 2), which takes a passphrase, salt, and iteration count to generate a secure encryption key.

Here’s how to use the openssl enc command to derive an AES key from a passphrase and use it for encryption with OpenSSL:

$ # print out the key and IV used a randomly generated salt then immediately exit: don't do any encryption or decryption.
$ openssl enc -aes-192-cbc -pbkdf2 -salt -P -pass pass:your_passphrase > salt_iv_and_key.txt
$ cat salt_iv_and_key.txt
salt=76D7E6752358F5B3
key=CBE904342A2BB0C2385B01187EF5115FCBB6027521416708
iv =BF5BCA68D74A0FE3592913420A8F24F3

$ # encrypt a message using a passphrase, a randomly generated salt, and a key derived with PBKDF2:
$ echo "Hello, 世界" | openssl enc -aes-256-cbc -pbkdf2 -salt -out encrypted.bin -p -pass pass:your_passphrase
salt=361CA8EF534E1219
key=7ED20774DE6A4369103736C851506B0E216BD52EA21C2CE00299EE3C98568CA7
iv =455AA565070AEFBD51230D532C347627

$ # to decrypt the encrypted message, use the following command:
$ openssl enc -aes-256-cbc -pbkdf2 -d -in encrypted.bin -p -pass pass:your_passphrase
salt=361CA8EF534E1219
key=7ED20774DE6A4369103736C851506B0E216BD52EA21C2CE00299EE3C98568CA7
iv =455AA565070AEFBD51230D532C347627
Hello, 世界
Make sure to replace "your_passphrase" with a strong, unique passphrase.
Remember to securely store the passphrase and salt, as they are required to decrypt the data encrypted with the derived AES key. Share them only with the users or systems that need them.

A.6. How to encrypt a message with AES?

To generate a key and encrypt a message using AES with OpenSSL, follow these steps:

$ # 1. Generate a random key:
$ openssl rand -base64 32 > key.txt
$ # This will generate a random 256-bit key and save it to a file called "key.txt".

$ # 2. Encrypt a message using the key:
$ echo "Hello, 世界" > message.txt
$
$ # This will encrypt the message using AES-256 in CBC mode with a random IV and the key from "key.txt".
$ # The encrypted message will be saved to a file called "cipher.txt".
$ openssl enc -aes-256-cbc -pbkdf2 -salt -in message.txt -out cipher.txt -pass file:key.txt

$ # 3. Decrypt the message using the key:
$ # This will decrypt the message from "cipher.txt" using the same key from "key.txt"
$ # and save the decrypted message to a file called "decrypted.txt".
$ openssl enc -aes-256-cbc -pbkdf2 -d -in cipher.txt -pass file:key.txt -out decrypted.txt
Note: Make sure to keep the key file secure and do not share it with anyone who should not have access to the encrypted message.

In the previous example, when you run the following command:

$ openssl enc -aes-256-cbc -pbkdf2 -salt -in message.txt -out cipher.txt -pass file:key.txt

  • OpenSSL automatically generates a random IV and uses it for the encryption.

    The IV is stored alongside the encrypted data in the output file (cipher.txt). When decrypting the data, OpenSSL will automatically extract the IV from the input file and use it for decryption.

    If you want to specify a custom IV, you can do so using the -iv option, but this is generally not recommended as it can weaken the security of the encryption. It is best to let OpenSSL generate a random IV for each encryption operation.

  • OpenSSL automatically generates a salt and uses it by default when you encrypt data using a password.

    The salt is stored in the output file along with the encrypted data, making it possible to derive the same key during decryption.

    When decrypting the data, OpenSSL will automatically extract the salt from the input file and use it along with the password to derive the correct encryption key.

    It is important to note that while the salt can be stored and transmitted alongside the encrypted data, the password must be kept secret and secure to maintain the confidentiality of the encrypted data.

  • By default, the output file contains the salt and the IV along with the ciphertext with the following format:

    Salted__[8-byte salt][IV + ciphertext]

    The salt and IV is often transmitted alongside the encrypted data, and it is necessary for the decryption process.

To extract the IV from the ciphertext file, you can use the dd command.

  • Before doing that, make sure you know the size of the salt and the IV for the specific encryption method you used.

  • For AES, the default salt size if 8 bytes, and the IV size is 16 bytes, and the recommended IV size for AES-GCM is 12 bytes.

Here’s how to extract the IV:

  1. First, remove the Salted__ part and the 8-byte salt from the ciphertext file:

    $ dd if=cipher.txt of=data_without_salt.bin bs=1 skip=16

    This command reads from cipher.txt, skips the first 16 bytes (8 for Salted__ and 8 for the salt), and writes the result to data_without_salt.bin.

  2. Next, extract the IV (16 bytes for AES) from the output file:

    $ dd if=data_without_salt.bin of=iv.bin bs=1 count=16

    This command reads the first 16 bytes from data_without_salt.bin and writes them to a file called iv.bin.

Keep in mind that you should not share the IV with unauthorized parties, as it is essential for the decryption process.

A.7. How to determine if AES cannot decrypt a ciphertext?

AES is a symmetric encryption algorithm, which means that it uses the same key for both encryption and decryption. If you have the correct key and the ciphertext is not corrupted, you should be able to decrypt the ciphertext without any issues.

However, you cannot determine if AES cannot decrypt a ciphertext only by looking at the ciphertext itself, without trying to decrypt it. The only way to find out if a decryption will fail is by attempting to decrypt it using the key you have. If the key is incorrect or the ciphertext is corrupted, the decryption will produce garbled or meaningless output. In some cases, you can also get an error or an exception while trying to decrypt, depending on the padding scheme used and the library you’re using.

However, AES-GCM can help determine whether AES can decrypt the ciphertext or not because it provides both encryption and authentication. If the key, IV (nonce), or ciphertext is incorrect or tampered with, the authentication tag verification will fail during decryption, and an exception will be thrown. In this case, you can conclude that the decryption failed.

Here’s a step-by-step process to encrypt and decrypt a message using AES-GCM:

$ # 1. Generate a 256-bit key for AES-256:
$ openssl rand -out aes256_key.bin 32

$ # 2. Generate a random 96-bit (12-byte) nonce (also called IV - Initialization Vector) for GCM:
$ openssl rand -out nonce.bin 12

$ # 3. Encrypt a message using AES-256-GCM:
$ openssl enc -aes-256-gcm -in plaintext.txt -out encrypted.bin \
   -K $(cat aes256_key.bin | xxd -p) \
   -iv $(cat nonce.bin | xxd -p) \
   -aead

This command will encrypt the file plaintext.txt and create an encrypted file encrypted.bin.

  • The -K and -iv options specify the key and nonce in hexadecimal format, respectively.

  • The -aead option indicates that an authentication tag will be generated and appended to the encrypted message.

Decrypt the message and verify its integrity:

$ openssl enc -d -aes-256-gcm -in encrypted.bin -out decrypted.txt \
    -K $(cat aes256_key.bin | xxd -p) \
    -iv $(cat nonce.bin | xxd -p) \
    -aead

This command will decrypt the file encrypted.bin and create a decrypted file decrypted.txt. If the message has been tampered with, OpenSSL will display an error message like bad decrypt or error reading input file.

Remember, you should securely share the AES key and nonce/IV with the recipient, but do not transmit them alongside the encrypted message. The nonce/IV should be unique for each encryption operation with the same key.

In real-world applications, you should handle these sensitive values securely, such as using secure key storage solutions and secure channels for key exchange.

A.8. How to encrypte a message with AES using a specific salt and an IV?

For OpenSSL, the default salt size is 8 bytes (64 bits). This size provides a reasonable balance between security and efficiency. A larger salt size would increase the number of unique salts, making it more difficult for attackers to precompute tables for dictionary or rainbow table attacks. However, it would also require more storage space and processing time.

For AES, the block size is 128 bits, which is why the IV size is 16 bytes (128 bits). The IV must be the same size as the block size to ensure that the encryption process works correctly and securely.

  • To create a salt and an IV using OpenSSL, you can use the openssl rand command. Here’s how to create them:

    $ # These commands generate random salt and IV values in hexadecimal format and save them to separate files.

$ # For OpenSSL, the salt is 8 bytes (64 bits) long.
$ # To generate a random salt and save it to a file called salt.txt, use the following command:
$ openssl rand -hex 8 > salt.txt

$ # For AES, the IV is 16 bytes (128 bits) long.
$ # To generate a random IV and save it to a file called iv.txt, use the following command:
$ openssl rand -hex 16 > iv.txt

  • To encrypt a message with AES using a specific salt and IV in OpenSSL, you can use the following steps:

    1. Derive the encryption key from the password and salt using a key derivation function, such as PBKDF2:

      $ # This command generates the key and IV using the password from `password.txt` and the salt from `salt.txt`.
$ # The key and IV are stored in a file called `key_and_iv.txt`.

$ # Print out the key and IV used then immediately exit: don't do any encryption or decryption.
$ openssl enc -aes-256-cbc -pbkdf2 -S "$(cat salt.txt)" -P -pass file:password.txt > key_and_iv.txt
$ cat key_and_iv.txt
salt=967D5441CD75BA53
key=F29DCDB2D054B75CC380606B3FED28DF0FD84F3452EA6B0D759B412C22AF9D84
iv =0029B6227C554F1AC120CB414708F08C
      Note that this command will generate a new IV, but we’ll replace it with our specific IV in the next step.

    2. Replace the generated IV in key_and_iv.txt with your specific IV:

      • Open key_and_iv.txt and locate the line that starts with "iv =". Replace the IV value with the contents of the iv.txt file.

        salt=8F585A18C70FBC06
key=7E60368294A3223978F440BDC4A424DF03D281699F1BF3C38D461559E4A595F4
iv =2b9233c61a92f9becc6af13b68747ad2

    3. Encrypt the message using AES, the key, and the specific IV:

      $ # This command encrypts the message in `plaintext.txt`  \
$ # using AES-256-CBC with the key and specific IV from `key_and_iv.txt`.
$ # The encrypted data is stored in a file called `ciphertext.txt`.

$ echo "Hello, 世界" | openssl enc -aes-256-cbc -out ciphertext.txt \
     -K "$(grep -oP '(?<=key=).+' key_and_iv.txt)" \
    -iv "$(grep -oP '(?<=iv =).+' key_and_iv.txt)"

    4. Decrypt the message using AES, the key, and the specific IV:

      $ openssl enc -aes-256-cbc -d -in ciphertext.txt \
     -K "$(grep -oP '(?<=key=).+' key_and_iv.txt)" \
    -iv "$(grep -oP '(?<=iv =).+' key_and_iv.txt)"
Hello, 世界

A.9. EC, ECC, ECDH and ECDSA?

EC, ECC, ECDH, and ECDSA are all related to elliptic curve cryptography, but they serve different purposes and functions. Here’s an explanation of each term:

  1. EC (Elliptic Curve): An elliptic curve is a mathematical construct used in cryptography for creating cryptosystems that are based on the algebraic structure of elliptic curves over finite fields. Elliptic curves provide the basis for elliptic curve cryptography (ECC).

  2. ECC (Elliptic Curve Cryptography): ECC is a public-key cryptosystem that is based on the algebraic structure of elliptic curves over finite fields. It offers the same security level as other public-key cryptosystems like RSA, but with smaller key sizes, which makes it more efficient in terms of computation and memory usage. ECC can be used for encryption, decryption, digital signatures, and key exchange. ECDH and ECDSA are both cryptographic schemes based on ECC.

  3. ECDH (Elliptic Curve Diffie-Hellman): ECDH is a key exchange protocol that is based on elliptic curve cryptography. It allows two parties, each having an elliptic curve public-private key pair, to establish a shared secret over an insecure channel. This shared secret can then be used to encrypt and decrypt messages between the two parties or to generate symmetric keys for symmetric encryption algorithms like AES. ECDH provides a secure way to establish a shared secret key without directly transmitting the key itself.

  4. ECDSA (Elliptic Curve Digital Signature Algorithm): ECDSA is a digital signature algorithm that is based on elliptic curve cryptography. It is used for signing and verifying digital signatures to ensure the integrity and authenticity of data. In ECDSA, a private key is used to generate a digital signature, and a public key is used to verify the signature. ECDSA provides similar functionality to other digital signature algorithms like RSA, but with smaller key sizes and more efficient operations.

In summary, EC and ECC are related to the underlying mathematical concepts and the overall cryptography approach based on elliptic curves. ECDH and ECDSA are specific cryptographic schemes based on ECC, with ECDH being used for secure key exchange and ECDSA being used for digital signatures.

A.10. RSA, DH, and ECDH

RSA, DH, and ECDH are cryptographic algorithms that serve different purposes and are based on different mathematical foundations:

  1. RSA (Rivest-Shamir-Adleman): RSA is an asymmetric cryptographic algorithm used for encryption, decryption, and digital signatures. It is based on the mathematical properties of large prime numbers and modular exponentiation. In RSA, a key pair (private key and public key) is generated, and the security relies on the difficulty of factoring the product of two large prime numbers. RSA is widely used in various security protocols and systems, such as TLS, SSH, and PGP.

  2. DH (Diffie-Hellman): DH is a key exchange algorithm that allows two parties to establish a shared secret over an insecure communication channel. It is based on the mathematical properties of modular exponentiation and the discrete logarithm problem. In DH, both parties generate their own private keys and public keys, exchange the public keys, and perform calculations to derive the shared secret. The security relies on the difficulty of solving the Discrete Logarithm Problem (DLP). DH does not provide encryption, decryption, or digital signature capabilities by itself but enables secure key agreement to establish symmetric keys for use in encryption or authentication.

  3. ECDH (Elliptic Curve Diffie-Hellman): ECDH is a key exchange algorithm that is based on elliptic curve cryptography. It is the elliptic curve counterpart of the Diffie-Hellman algorithm. ECDH allows two parties to establish a shared secret using elliptic curve operations instead of modular exponentiation. Like DH, both parties generate their own private keys and public keys, exchange the public keys, and perform calculations to derive the shared secret. The security relies on the difficulty of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP). ECDH provides the same key exchange functionality as DH but with smaller key sizes and better performance.

In summary, RSA is an asymmetric cryptographic algorithm used for encryption, decryption, and digital signatures, while DH and ECDH are key exchange algorithms that allow parties to establish a shared secret securely. DH is based on modular exponentiation, while ECDH uses elliptic curve cryptography.

A.11. Digital signatures and public key encryption/decryption

Digital signatures and public key encryption/decryption are both concepts that rely on public key cryptography (also known as asymmetric cryptography). They serve different purposes and have distinct properties:

Digital Signatures:

  • Purpose: Digital signatures are used to verify the authenticity, integrity, and non-repudiation of a message or document. They confirm that the message has not been altered during transmission and that it comes from a specific sender.

  • Process: The sender generates a digital signature by applying a cryptographic hash function to the message and then encrypting the hash using their private key. The recipient verifies the signature by decrypting the hash using the sender’s public key, and then independently hashing the message and comparing the two hashes. If they match, the signature is considered valid.

  • Properties: Digital signatures provide message integrity, authentication, and non-repudiation.

Public Key Encryption/Decryption:

  • Purpose: Public key encryption is used to ensure the confidentiality of a message or document. It ensures that only the intended recipient can read the message.

  • Process: The sender encrypts the message using the recipient’s public key. The encrypted message can only be decrypted by the recipient using their private key, ensuring that the message remains confidential.

  • Properties: Public key encryption provides message confidentiality.

In summary, digital signatures are used for verifying the authenticity and integrity of a message, while public key encryption is used for ensuring the confidentiality of a message. Both concepts rely on public key cryptography, where each user has a pair of keys: a public key for encryption or signature verification, and a private key for decryption or signature generation.

A.12. Is it possible to encrypt a message with a private key and decrypt it with the corresponding public key, or vice versa?

In theory, it is possible to encrypt a message with a private key and decrypt it with the corresponding public key, or vice versa, depending on the specific public key cryptosystem being used. However, this approach is not recommended for ensuring confidentiality, as it has different security implications.

  • Encrypting a message with a private key and decrypting it with a public key is essentially the concept behind digital signatures.

    When you sign a message with your private key, anyone with your public key can verify the signature, effectively decrypting the encrypted hash. This process is used to provide authentication and integrity, not confidentiality.

  • Encrypting a message with a public key and decrypting it with a private key is the standard method for ensuring confidentiality in public key cryptography.

    This method ensures that only the intended recipient, who possesses the private key, can decrypt and read the message.

In summary, while it is technically possible to encrypt a message with a private key and decrypt it with a public key or vice versa, it is not the recommended approach for ensuring confidentiality. Instead, use the standard method of encrypting with a public key and decrypting with the corresponding private key for secure communication.

$ echo "Hello, 世界" > message.txt

$ openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048 -quiet
$ openssl rsa -in private_key.pem -pubout -out public_key.pem
writing RSA key
$ # Encrypt a message using the public ke
$ openssl pkeyutl -encrypt -in message.txt -out encrypted_message.bin -pubin -inkey public_key.pem
$ # Decrypt the encrypted message using the private key
$ openssl pkeyutl -decrypt -in encrypted_message.bin -out decrypted_message.txt -inkey private_key.pem
$ cat decrypted_message.txt
Hello, 世界
$ openssl dgst -sha256 -sign private_key.pem -out signature.bin message.txt
$ openssl dgst -sha256 -verify public_key.pem -signature signature.bin message.txt
Verified OK

A.13. It seems that the text length of private key is larger than public key in PEM?

Yes, that is correct. The text length of a private key in PEM format is generally larger than the public key. This is because the private key contains more information than the public key.

In the case of RSA, for example, the private key includes the following components: modulus (n), public exponent (e), private exponent (d), prime1 (p), prime2 (q), exponent1 (d mod (p-1)), exponent2 (d mod (q-1)), and coefficient (q^-1 mod p). The public key, on the other hand, contains only the modulus (n) and the public exponent (e).

Similarly, in the case of ECC, the private key includes the curve parameters and the private scalar, while the public key only includes the curve parameters and the public point.

When represented in PEM format, these additional components in the private key result in a larger text length compared to the public key. However, it’s important to note that the actual key lengths (e.g., 256-bit for ECC or 2048-bit for RSA) refer to the mathematical properties of the keys and not their text representations.

A.14. How does OpenSSL determine the algorithm (RSA or ECC)?

When you create a digital signature with openssl dgst, the command reads the private key file and extracts the relevant information, such as the algorithm used (RSA, ECC, etc.) from the ASN.1 encoded data. Based on this information, it selects the appropriate signing algorithm and creates the digital signature.

ASN.1 (Abstract Syntax Notation One) is a standardized notation used to describe the structure and encoding of data in telecommunications and computer networking. Private keys are often stored in the PEM (Privacy Enhanced Mail) format, which contains the ASN.1 encoded data in a base64 representation.

When OpenSSL reads a key, it decodes the base64 data and parses the ASN.1 structure. This structure includes an identifier called "Object Identifier" (OID) that indicates the algorithm associated with the key. OpenSSL uses this OID to determine the correct algorithm.

For example:

  • For RSA keys, the OID is 1.2.840.113549.1.1.1.

  • For EC (Elliptic Curve) keys, the OID is 1.2.840.10045.2.1.

Here’s a high-level view of how OpenSSL determines the algorithm:

  1. Read the private key file.

  2. Decode the base64 data and parse the ASN.1 structure.

  3. Locate the OID in the ASN.1 structure.

  4. Compare the OID with known algorithm OIDs.

  5. Use the corresponding algorithm for signing or other operations.

This process allows OpenSSL to automatically determine the algorithm used for signing and verification based on the ASN.1 information in the private and public keys.

A.15. How to use OpenSSL to show the ASN.1 OID in a key file?

You can use the openssl asn1parse command to display the ASN.1 structure of a key file, which includes the OID (Object Identifier). Here’s an example for both RSA and ECC keys:

$ # Generate a private and public key pair for Alice (RSA)
$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out alice.rsa.key -quiet

$ # Generate a private and public key pair for Bob (EC)
$ openssl genpkey -algorithm EC -out bob.ecc.key -pkeyopt ec_paramgen_curve:secp384r1 -pkeyopt ec_param_enc:named_curve
$ openssl asn1parse -in alice.rsa.key
    0:d=0  hl=4 l=2370 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=2 l=  13 cons: SEQUENCE
    9:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   20:d=2  hl=2 l=   0 prim: NULL
   22:d=1  hl=4 l=2348 prim: OCTET STRING      [HEX DUMP]: <...>

$ openssl asn1parse -in bob.ecc.key
    0:d=0  hl=3 l= 182 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim: INTEGER           :00
    6:d=1  hl=2 l=  16 cons: SEQUENCE
    8:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   5 prim: OBJECT            :secp384r1
   24:d=1  hl=3 l= 158 prim: OCTET STRING      [HEX DUMP]: <...>

In the output, you should see an entry with the OID 1.2.840.113549.1.1.1 corresponding to the RSA algorithm, like this:

9:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption

And, similarly, an entry with the OID 1.2.840.10045.2.1 corresponding to the ECC algorithm, like this:

8:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey

A.16. How to derive a shared key using key exchange algorithm?

Here’s an example of how to use the openssl pkeyutl command to derive a shared key using the Elliptic Curve Diffie-Hellman (ECDH) key exchange.

$ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out alice.key
$ openssl pkey -in alice.key -pubout -out alice.pub

$ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out bob.key
$ openssl pkey -in bob.key -pubout -out bob.pub

$ openssl pkeyutl -derive -inkey alice.key -peerkey bob.pub -out alice.secret.bin
$ openssl pkeyutl -derive -inkey bob.key -peerkey alice.pub -out bob.secret.bin

$ cmp -s alice.secret.bin bob.secret.bin && echo "Shared secrets match" || echo "Shared secrets don't match"
Shared secrets match

Note that the derived shared secret is a binary file. In practice, you may want to use a key derivation function (KDF) to generate a symmetric key from the shared secret for use in encryption or authentication.

Digital Signature Algorithm (DSA) is designed for digital signatures and not for key agreement or key exchange protocols like Diffie-Hellman or Elliptic Curve Diffie-Hellman, which are specifically designed for secure key agreement purposes.

Note that the shared key derived from a static key pair will always be the same.

  • To mitigate the risk of the shared key being compromised, you can use ephemeral (temporary) key pairs in the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) key exchange process.

  • This approach is called Ephemeral Diffie-Hellman (DHE) or Ephemeral Elliptic Curve Diffie-Hellman (ECDHE).

  • In DHE or ECDHE, each party generates a new temporary key pair for each key exchange session, derives the shared secret, and then discards the temporary keys.

  • This approach provides forward secrecy, meaning that even if an attacker compromises a shared key for one session, they cannot use it to decrypt past or future sessions.

Remember to generate new ephemeral key pairs for each session and securely delete the temporary keys after use to maintain forward secrecy.

A.17. Can I derive a shared key using two different cipher algorithm keys?

No, you cannot use the openssl pkeyutl command to derive a shared key using two different cipher algorithm keys. Key derivation requires both parties to use keys generated with the same algorithm and compatible parameters.

For example, if you want to derive a shared key using the Elliptic Curve Diffie-Hellman (ECDH) key exchange, both parties must use ECC key pairs with the same elliptic curve. Similarly, for Diffie-Hellman (DH) key exchange, both parties must use key pairs with compatible parameters (prime modulus and generator).

Attempting to derive a shared key using keys from different algorithms, such as RSA and ECC, will result in an error because their underlying mathematical structures and key generation processes are fundamentally different and not compatible with each other.

If you want to derive a shared key, make sure both parties use compatible keys generated with the same algorithm and appropriate parameters.

A.18. Can I derive a shared key with RSA?

No, you cannot use openssl pkeyutl to directly derive a shared key with RSA in the same way as you would with Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH). This is because RSA is not designed as a key agreement or key exchange algorithm like DH or ECDH.

However, you can use RSA to encrypt and decrypt a shared secret, which can then be used as a shared key for symmetric encryption. Here’s an example of how to do this with OpenSSL:

$ # Generate an RSA key pair for the server
$ openssl genpkey -algorithm RSA -out server.key.pem -pkeyopt rsa_keygen_bits:2048

$ # Extract the public key from the server's private key:
$ openssl pkey -in server.key.pem -pubout -out server.pub.pem

$ # Generate a random pre-master secret (shared secret) on the client side:
$ openssl rand -out pre_master_secret.bin 48

$ # Encrypt the pre-master secret using the server's RSA public key:
$ openssl pkeyutl -encrypt -in pre_master_secret.bin -pubin -inkey server.pub.pem -out encrypted_pre_master_secret.bin

$ # Decrypt the encrypted pre-master secret using the server's RSA private key:
$ openssl pkeyutl -decrypt -in encrypted_pre_master_secret.bin -inkey server.key.pem -out decrypted_pre_master_secret.bin

At this point, both the client and the server have the same pre-master secret (shared secret). You can use this shared secret to derive symmetric encryption keys using a key derivation function.

Please note that this process does not provide forward secrecy, as mentioned in previous responses, and it is recommended to use modern key exchange algorithms like ECDHE or DHE for better security.

Although RSA key exchange is supported in TLS 1.0 - TLS 1.2, it has some drawbacks:

  1. It does not provide forward secrecy.

    If an attacker manages to compromise the server’s RSA private key, they can decrypt past recorded TLS sessions that used the same key.

  2. The server must have an RSA key pair, which might not be the case if the server uses an ECDSA certificate for digital signatures.

Due to these limitations, modern TLS configurations often prefer using ephemeral key exchange algorithms like DHE (Diffie-Hellman Ephemeral) or ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), which provide forward secrecy and work independently of the server’s certificate type.

In TLS 1.3, RSA key exchange has been removed, and only ephemeral key exchange algorithms like ECDHE and DHE are supported.

A.19. How to compute the digest and sign it from a CSR separately?

The origin data of the digest in a CSR (Certificate Signing Request) is the DER-encoded data of the CertificationRequestInfo structure, which contains information about the subject, public key, and optional attributes.

$ # Create a Certificate Signing Request (CSR)
$ openssl req -subj "/CN=955.wlb" \
    -addext "subjectAltName=DNS:955.wlb,DNS:*.955.wlb" \
    -addext "basicConstraints=CA:false" \
    -addext "keyUsage=digitalSignature,keyEncipherment" \
    -addext "extendedKeyUsage=serverAuth,clientAuth" \
    -nodes -newkey rsa:2048 \
    -keyout 955.wlb.key \
    -out 955.wlb.csr \
    2>/dev/null
$ # Verify the self-signed signature of a request:
$ openssl req -verify -in 955.wlb.csr -noout
Certificate request self-signature verify OK

A certification request shall have ASN.1 type CertificationRequest: [RFC2986]

CertificationRequest ::= SEQUENCE {
     certificationRequestInfo CertificationRequestInfo,
     signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
     signature          BIT STRING
}
$ # Parse the CSR information in ASN1
$ openssl asn1parse -in 955.wlb.csr -i
    0:d=0  hl=4 l= 702 cons: SEQUENCE
    4:d=1  hl=4 l= 422 cons:  SEQUENCE
    ...
   31:d=2  hl=4 l= 290 cons:   SEQUENCE
   35:d=3  hl=2 l=  13 cons:    SEQUENCE
   37:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
    ...
  430:d=1  hl=2 l=  13 cons:  SEQUENCE
    ...
  445:d=1  hl=4 l= 257 prim:  BIT STRING

$ # Extract the certificationRequestInfo
$ openssl asn1parse -in 955.wlb.csr -strparse 4 -out 955.wlb.cri -noout
$ # Extract the signature vaule (ignore the error, because it's the raw signature bytes instead of ASN.1 encoded.
$ openssl asn1parse -in 955.wlb.csr -strparse 445 -out 955.wlb.sig.o > /dev/null 2>&1
$ # Determine the signature algorithm
$ openssl req -in 955.wlb.csr -noout -text | grep 'Signature Algorithm:'
    Signature Algorithm: sha256WithRSAEncryption
$ # Sign the raw request information using the private key
$ openssl pkeyutl -sign -inkey 955.wlb.key \
    -digest sha256 -rawin \
    -in 955.wlb.cri \
    -out 955.wlb.sig.1
$ # Compare the signatures
$ diff 955.wlb.sig.o 955.wlb.sig.1
<nothing is ok>

$ # Extract the public key
$ openssl pkey -in 955.wlb.key -pubout -out 955.wlb.pub
$ # or
$ openssl asn1parse -in 955.wlb.csr -strparse 31 -out /dev/stdout -noout \
    | openssl pkey -pubin -inform DER -outform PEM -out 955.wlb.pub.1
$ diff 955.wlb.pub 955.wlb.pub.1
<nothing is ok>
$ # Verify the signature using the publick key
$ openssl pkeyutl -verify -pubin -inkey 955.wlb.pub \
    -rawin -digest sha256 -in 955.wlb.cri \
    -sigfile 955.wlb.sig.o
Signature Verified Successfully

A.20. How to create, issue and verify a certificate?

$ # Create a self-signed CA root certificate
$ openssl req -x509 \
    -subj "/CN=996.icu" \
    -addext "subjectAltName=DNS:996.icu,DNS:*.996.icu" \
    -addext "keyUsage=digitalSignature,cRLSign,keyCertSign" \
    -addext "extendedKeyUsage=serverAuth,clientAuth" \
    -days 365 \
    -nodes -newkey rsa:2048 \
    -keyout 996.icu.key \
    -out 996.icu.crt \
    > /dev/null 2>&1
$ openssl x509 -in 996.icu.crt -noout -ext keyUsage,extendedKeyUsage,basicConstraints
X509v3 Basic Constraints: critical
    CA:TRUE
X509v3 Key Usage:
    Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication
$ # Create a Certificate Signing Request (CSR)
$ openssl req -subj "/CN=955.wlb" \
    -addext "subjectAltName=DNS:955.wlb,DNS:*.955.wlb" \
    -addext "basicConstraints=CA:false" \
    -addext "keyUsage=digitalSignature,keyEncipherment" \
    -addext "extendedKeyUsage=serverAuth,clientAuth" \
    -nodes -newkey rsa:2048 \
    -keyout 955.wlb.key \
    -out 955.wlb.csr \
    2>/dev/null
$ # Sign a certificate signing request with a root certificate
$ openssl x509 -req \
    -CA 996.icu.crt -CAkey 996.icu.key -CAcreateserial \
    -days 180 \
    -in 955.wlb.csr \
    -copy_extensions copy \
    -out 955.wlb.crt \
    2>/dev/null
$ openssl x509 -in 955.wlb.crt -noout -ext keyUsage,extendedKeyUsage,basicConstraints
X509v3 Basic Constraints:
    CA:FALSE
X509v3 Key Usage:
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication
$ # Verify a certificate using the root certificate
$ openssl verify -CAfile 996.icu.crt 955.wlb.crt
955.wlb.crt: OK

Remember that the openssl verify command checks the trust chain up to the provided root certificate, so ensure that the certificate you are trying to verify is indeed signed by the provided root certificate.

If there are intermediate certificates involved, you may need to include them in the command as well, using the -untrusted option.

$ openssl verify -CAfile 996.icu.crt 955.wlb.crt -untrusted

Appendix B: FQAs: IPsec

B.1. IKEv2 (Internet Key Exchange version 2)

IKEv2 (Internet Key Exchange version 2) is a protocol used for negotiating and authenticating IPsec (Internet Protocol Security) connections. It is used to establish secure communication between two devices before the actual data exchange takes place. IKEv2 is responsible for setting up the encryption keys, authentication keys, and other security parameters needed for the IPsec connection.

IKEv2 uses a series of messages to perform the negotiation and authentication process. The messages are exchanged between the two devices in a defined sequence. The first message is the IKE_SA_INIT message, which initiates the negotiation process. The second message is the IKE_AUTH message, which is used for authentication.

During the negotiation process, the two devices exchange information about their security capabilities and agree on a set of encryption algorithms, authentication methods, and other security parameters. Once the negotiation process is complete, the devices exchange the actual data packets using the agreed-upon encryption and authentication methods.

To terminate the session, either one of the devices can send an IKE_DELETE message to the other device. This message instructs the other device to delete the IPsec security association and end the connection.

The IKEv2 protocol uses a variety of packet types and formats to perform the negotiation and authentication process. Some of the most important packet types include:

  1. IKE_SA_INIT: This is the initial packet sent by the initiator to start the negotiation process.

  2. IKE_AUTH: This packet is used for authentication and exchange of keying material.

  3. CREATE_CHILD_SA: This packet is used to create a new child security association within an existing IKEv2 security association.

  4. INFORMATIONAL: This packet is used to exchange information about the status of the connection, such as when terminating the session.

Overall, IKEv2 is a critical component of IPsec security. It is responsible for setting up the secure connection between two devices, establishing the encryption and authentication methods to be used, and maintaining the security association during the data exchange.

B.2. Transport mode and tunnel mode in IPsec

In IPsec, data exchange is encapsulated in IP datagrams to provide confidentiality, integrity, and authenticity of the data being transmitted. IPsec operates in two modes: transport mode and tunnel mode.

Transport mode is used when both the source and destination hosts are using IPsec. In this mode, only the payload (data) of the IP datagram is encrypted and authenticated, while the IP header remains untouched.

Tunnel mode is used when at least one of the hosts does not support IPsec. In this mode, the entire IP datagram, including the IP header and payload, is encapsulated within another IP datagram. The outer IP header is used for routing while the inner IP header is used to establish the security association and provides the necessary security services.

The packet format for IPsec depends on the mode being used. In transport mode, the original IP datagram remains unchanged, except for the addition of an Authentication Header (AH) or Encapsulating Security Payload (ESP) header. The AH header provides data integrity and authenticity, while the ESP header provides confidentiality, integrity, and authenticity.

The packet format for transport mode IPsec is as follows:

Original IP Header | ESP/AH Header | Payload

In tunnel mode, the original IP datagram is encapsulated within another IP datagram. The outer IP header is used for routing, while the inner IP header is used to establish the security association. The ESP or AH header is added after the new outer IP header and before the original IP header. The ESP or AH header provides the necessary security services.

The packet format for tunnel mode IPsec is as follows:

New Outer IP Header | ESP/AH Header | Original IP Header | Payload

Overall, IPsec provides secure communication over IP networks by encapsulating IP datagrams with additional headers that provide confidentiality, integrity, and authenticity. The choice of transport mode or tunnel mode depends on the specific requirements of the network and the devices being used.

B.3. Tunnel mode in IPsec as an overlay network

Tunnel mode in IPsec can be considered as an overlay network, as it creates a virtual secure tunnel between two security gateways (such as VPN gateways, firewalls, or routers) over an existing IP network, allowing the secure transmission of data between two networks or between a host and a network.

Tunnel mode can bypass some network firewalls and restrictions because it encapsulates the entire original IP packet (including the original IP header and payload) within a new IP packet. The new outer IP header is used for routing between the security gateways, and the inner IP header (along with the encrypted payload) is protected by IPsec. Since the original IP packet is hidden inside the encrypted payload, firewalls and other security devices may not be able to inspect the contents of the packet and apply filtering rules based on the original IP addresses or protocols.

This feature of tunnel mode is beneficial in scenarios where secure communication is needed across restrictive networks or when establishing VPN connections for remote access to corporate resources. However, it’s important to note that some firewalls and security devices can still detect and block IPsec tunnel mode traffic by inspecting the outer IP header, identifying the use of IPsec protocols, or employing deep packet inspection techniques.

B.4. AH (Authentication Header) and ESP (Encapsulating Security Payload) headers

Not all IPsec packets in IP datagrams require both the AH (Authentication Header) and ESP (Encapsulating Security Payload) headers. Depending on the security requirements, one of these headers can be used.

  • If only data integrity and authentication are needed, the AH header can be used. In this case, the payload remains unencrypted, but its integrity and authenticity are ensured.

  • If confidentiality is also required, the ESP header should be used. With ESP, the payload is encrypted, ensuring confidentiality, and the ESP header provides data integrity and authentication.

  • In transport mode, the IPsec packet format will have the original IP header, followed by the AH/ESP header, and then the payload. The payload will be encrypted if ESP is used:

Original IP Header | AH/ESP Header | (Encrypted) Payload

  • In tunnel mode, the IPsec packet format will have a new outer IP header, followed by the AH/ESP header, the original IP header, and the payload. The payload, along with the original IP header, will be encrypted if ESP is used:

New Outer IP Header | AH/ESP Header | (Encrypted) Original IP Header | (Encrypted) Payload

In both cases, if confidentiality is required, the payload will be encrypted. The choice of using AH or ESP depends on the specific security requirements of the network and the devices being used.

B.5. The scenarios where using IPsec without confidentiality (i.e., without encryption)

There are scenarios where using IPsec without confidentiality (i.e., without encryption) can still be useful. In these cases, IPsec can provide data integrity and authentication, ensuring that the data has not been tampered with and that it comes from a trusted source. This can be achieved using the Authentication Header (AH) protocol.

Some scenarios where IPsec without confidentiality can be employed include:

  1. Network management and monitoring: In situations where data confidentiality is not crucial, but ensuring data integrity and authenticity is essential, IPsec with AH can be used. This is common in network management and monitoring systems, where administrators need to trust the information coming from devices without necessarily requiring the data to be encrypted.

  2. Environments with strict data privacy regulations: In certain industries or countries, data privacy regulations might restrict the use of encryption. In such cases, IPsec with AH can be used to provide data integrity and authentication while complying with the regulations.

  3. Performance-sensitive applications: Encrypting and decrypting data can add processing overhead and latency to network communications. In performance-sensitive applications where the data being transmitted is not sensitive, but data integrity and authentication are still required, IPsec with AH can be a suitable choice.

  4. Interoperability with legacy systems: Some older systems might not support encryption due to hardware limitations or outdated software. In these cases, IPsec with AH can provide a measure of security by ensuring data integrity and authentication.

It is important to note that using IPsec without confidentiality does not protect the data from eavesdropping or unauthorized access. It only ensures that the data has not been tampered with and that it comes from a trusted source. In scenarios where data confidentiality is crucial, using IPsec with the Encapsulating Security Payload (ESP) protocol is recommended, as it provides encryption in addition to data integrity and authentication.

B.6. IPsec (Internet Protocol Security) and TLS (Transport Layer Security)

While both IPsec and TLS (Transport Layer Security) provide secure communication over networks, they operate at different layers of the networking stack and have some differences in their use cases, implementation, and features.

  1. Layer of operation: IPsec operates at the network layer (Layer 3) of the OSI model, while TLS operates at the transport layer (Layer 4). This means IPsec secures the entire IP packet, whereas TLS secures the data within a specific transport layer protocol, such as TCP.

  2. Applicability: IPsec can secure any protocol that uses IP, whereas TLS is limited to securing TCP-based protocols, such as HTTP, SMTP, and IMAP.

  3. Connection setup: IPsec sets up a security association (SA) between two hosts or networks to ensure secure communication, while TLS establishes a secure connection between a client and server using a handshake process.

  4. Modes of operation: IPsec can operate in two modes, transport mode (securing end-to-end communication between hosts) and tunnel mode (securing communication between networks or between a host and a network). TLS does not have different modes of operation but secures communication between a client and a server.

  5. Implementation: IPsec is typically implemented within the operating system or as part of network hardware (routers, firewalls), while TLS is typically implemented within applications or as part of application-level libraries.

  6. Granularity of control: IPsec provides more fine-grained control over security policies and can be applied to a wide range of traffic types. TLS is more focused on securing specific application-level protocols.

In summary, while both IPsec and TLS provide secure communication, they operate at different layers and have some differences in use cases, implementation, and features. IPsec is more versatile in securing a wider range of network traffic, while TLS is mainly used for securing specific application-level protocols over TCP.

B.7. How to identify the type of an IP datagram, that contains normal IPsec data, an IKEv2 message, or something else?

To identify the type of an IP datagram, you can examine the "Protocol" field in the IP header. The Protocol field is an 8-bit field that indicates the type of payload carried by the IP datagram. Here’s how you can identify if the IP datagram contains normal IPsec data, an IKEv2 message, or something else:

  1. Normal IPsec data: IPsec uses two main protocols for securing data: Authentication Header (AH) and Encapsulating Security Payload (ESP). In the Protocol field of the IP header, the value 51 represents AH, and the value 50 represents ESP.

  2. IKEv2 message: IKEv2 (Internet Key Exchange version 2) is used for negotiating and establishing Security Associations (SAs) for IPsec. IKEv2 uses the User Datagram Protocol (UDP) for communication. In the Protocol field of the IP header, the value 17 represents UDP. To further confirm that the UDP payload contains an IKEv2 message, you need to check the UDP source or destination port. The standard port for IKEv2 is 500 or 4500 (when using NAT-Traversal).

  3. Something else: If the Protocol field in the IP header contains a value other than the ones mentioned above, it represents a different protocol. For example, the values 6 and 17 represent TCP and UDP, respectively.

To summarize, you can identify the type of an IP datagram by checking the Protocol field in the IP header. If the value is 50 (ESP) or 51 (AH), it is an IPsec data packet. If the value is 17 (UDP) and the source or destination port is 500 or 4500, it is likely an IKEv2 message. If the value is different from these, it is something else, such as a non-IPsec packet for another protocol.

While it is true that IKEv2 typically uses UDP ports 500 and 4500, there can be other non-IKEv2 traffic on the same ports in rare cases.

To be more certain about the identification of an IKEv2 message within a UDP packet, you can inspect the payload of the UDP packet for the specific structure of an IKEv2 message. IKEv2 messages have a well-defined format, starting with an IKE header, followed by one or more IKE payloads.

An IKEv2 header has the following structure:

  1. Initiator’s SPI (64 bits): Security Parameter Index (SPI) of the initiator.

  2. Responder’s SPI (64 bits): Security Parameter Index (SPI) of the responder.

  3. Next Payload (8 bits): Indicates the type of the first payload in the message.

  4. Major Version (4 bits): Indicates the major version of the IKE protocol (for IKEv2, it is 2).

  5. Minor Version (4 bits): Indicates the minor version of the IKE protocol (for IKEv2, it is 0).

  6. Exchange Type (8 bits): Indicates the type of the IKE exchange (e.g., IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, etc.).

  7. Flags (8 bits): Contains various flags, such as initiator/response flag and higher-order bits reserved for future use.

  8. Message ID (32 bits): Used to identify and match request and response pairs.

  9. Length (32 bits): Indicates the total length of the IKE message, including the header and all the payloads.

By examining the contents of the UDP payload and looking for the specific structure of an IKEv2 message, you can more accurately determine whether a UDP packet contains an IKEv2 message for IPsec.

In IPsec, the Internet Key Exchange (IKE) protocol is used to negotiate and establish security parameters between two parties. IKE typically uses UDP datagrams for its communication, with the standard ports being 500 and 4500 (when using NAT-Traversal).

During the IKE negotiation process, the two parties exchange IKE messages to establish a secure channel called the IKE Security Association (SA). Once the IKE SA is established, the parties negotiate IPsec Security Associations (SAs) for the actual data exchange. These IPsec SAs define the cryptographic algorithms, keys, and other security parameters to be used for data protection.

The data exchange in IPsec uses normal IP datagrams with either the Authentication Header (AH) or Encapsulating Security Payload (ESP) header, depending on the chosen mode of operation. AH provides data integrity and authentication, while ESP provides confidentiality, data integrity, and authentication.

In summary, IKE is responsible for negotiating and establishing security parameters using UDP datagrams, while the actual data exchange in IPsec uses normal IP datagrams with AH or ESP headers to provide the desired security services.

B.8. What are IKEv2 and OpenVPN?

IKEv2 and OpenVPN are two different VPN protocols used to establish a secure and encrypted connection between a user’s device and a remote server.

  • IKEv2 (Internet Key Exchange version 2) is a protocol used to set up a secure connection between two devices. It is a widely used protocol that supports various encryption algorithms and authentication methods. IKEv2 is known for its high performance and ability to quickly reconnect when a connection is lost, which makes it suitable for mobile devices that frequently switch between Wi-Fi and cellular networks. It is also considered very secure and is natively supported by many operating systems, including Windows, macOS, and iOS.

  • OpenVPN is an open-source VPN protocol that is known for its flexibility, security, and stability. It uses a custom security protocol based on SSL/TLS (Secure Socket Layer/Transport Layer Security) for key exchange, authentication, and encryption. OpenVPN supports a wide range of encryption algorithms, authentication methods, and is highly configurable, making it suitable for various use cases and security requirements. It works well on various platforms, including Windows, macOS, Linux, Android, and iOS, but may require third-party software for setup on some devices.

Both IKEv2 and OpenVPN are popular choices for VPN users due to their strong security features, compatibility with multiple platforms, and overall performance. However, the choice between the two may depend on specific needs, device compatibility, and user preference.

B.9. What’re P2S (Point-to-Site) and S2S (Site-to-Site)?

P2S (Point-to-Site) and S2S (Site-to-Site) are two types of VPN (Virtual Private Network) connections used to create secure and encrypted communication channels.

  • P2S (Point-to-Site) VPN: A P2S VPN connection is designed to establish a secure connection between a single client (user) and a remote network, such as a corporate network or data center. In this setup, the user’s device acts as the "point" and connects to the remote "site." P2S VPNs are typically used by remote workers or employees who need to access company resources securely from home or while traveling. P2S VPNs often use SSL/TLS or IPsec-based VPN protocols, such as OpenVPN or IKEv2, for secure communication.

  • S2S (Site-to-Site) VPN: An S2S VPN connection is used to establish a secure connection between two separate networks or "sites." These sites can be two different offices, data centers, or even cloud environments. The purpose of an S2S VPN is to allow devices on both networks to securely communicate with each other as if they were on the same local network. S2S VPNs typically use IPsec or other dedicated VPN protocols for secure communication and are often set up using dedicated VPN hardware or routers on both ends.

Both P2S and S2S VPNs help to ensure secure and encrypted communication over the internet while providing access to remote resources. However, they cater to different use cases: P2S VPNs are meant for individual users, while S2S VPNs connect entire networks or sites.

Appendix C: Extended Validation Certificate

An Extended Validation Certificate (EV) is a certificate conforming to X.509 that proves the legal entity of the owner and is signed by a certificate authority key that can issue EV certificates. EV certificates can be used in the same manner as any other X.509 certificates, including securing web communications with HTTPS and signing software and documents. Unlike domain-validated certificates and organization-validation certificates, EV certificates can be issued only by a subset of certificate authorities (CAs) and require verification of the requesting entity’s legal identity before certificate issuance. [EVCWIKIPEDIA]

  • Removal of special UI indicators

    In May 2018, Google announced plans to redesign user interfaces of Google Chrome to remove emphasis for EV certificates. Chrome 77, released in 2019, removed the EV certificate indication from omnibox, but EV certificate status can be viewed by clicking on lock icon and then checking for legal entity name listed as "issued to" under "certificate". Firefox 70 removed the distinction in the omnibox or URL bar (EV and DV certificates are displayed similarly with just a lock icon), but the details about certificate EV status are accessible in the more detailed view that opens after click on the lock icon.[EVCWIKIPEDIA]

  • Extended Validation certificate identification

    EV certificates are standard X.509 digital certificates. The primary way to identify an EV certificate is by referencing the Certificate Policies extension field. Each issuer uses a different object identifier (OID) in this field to identify their EV certificates, and each OID is documented in the issuer’s Certification Practice Statement. As with root certificate authorities in general, browsers may not recognize all issuers. [EVCWIKIPEDIA]

    $ openssl s_client -connect www.globalsign.com:443 2>1 | openssl x509 -noout -ext certificatePolicies
X509v3 Certificate Policies:
    Policy: 1.3.6.1.4.1.4146.1.1
      CPS: https://www.globalsign.com/repository/
    Policy: 2.23.140.1.1
    Table 6. CA/Browser Forum CP OID
    Certificate Policy (CP) CA/Browser Forum CP OID [CABFOID] DigiCert CP (OID) [Legacy] [DIGICERTCPS] GlobalSign CP (OID) [Legacy] [GLOBALSIGNCP]

    Extended Validation Certificate Policy

    2.23.140.1.1

    2.16.840.1.114412.2.1

    1.3.6.1.4.1.4146.1.1

    EV Code Signing Certificates Policy

    2.23.140.1.3

    1.3.6.1.4.1.4146.1.2

    Domain Validation Certificates Policy

    2.23.140.1.2.1

    2.16.840.1.114412.1.2

    1.3.6.1.4.1.4146.1.10

    Organization Validation Certificates Policy

    2.23.140.1.2.2

    2.16.840.1.114412.1.1

    1.3.6.1.4.1.4146.1.20

    Individual Validation Certificate Policy

    2.23.140.1.2.3

    2.16.840.1.114412.1.1

    EV certificates represent an industry response to certain phishing attacks involving malicious Web sites that were issued certificates without rigorous identity proofing. Issuing of an EV certificate takes place only under an agreed-upon set of stringent criteria, and a user visiting a Web site using EV certificates and a modern browser typically sees a green title bar and CA information to indicate the enhanced level of rigor.

One of the requirements for EV certificates placed upon each CA is to provide a certification practice statement (CPS), which outlines the practices used in issuing certificates. Considerations for authors of CPSs (and certificate policies or CPs that apply on a per-certificate basis) are given in [RFC5280].

Note that although EV certificates may provide higher assurance (e.g., for some Web sites), most users do not pay careful attention to the cues provided by Web browsers that reveal this fact [BOPSW09].

References

  • [1] Kevin Fall, W. Stevens TCP/IP Illustrated: The Protocols, Volume 1. 2nd edition, Addison-Wesley Professional, 2011

  • [BOPSW09] R. Biddle et al., “Browser Interfaces and Extended Validation SSL Certificates: An Empirical Study,” Proc. ACM Cloud Security Workshop, Nov. 2009.

  • [CABF09] CA/Browser Forum, “Guidelines for the Issuance and Management of Extended Validation Certificates (v1.4.6),” 2009, https://cabforum.org/wp-content/uploads/EV-SSL-Certificate-Guidelines-Version-1.4.6.pdf

  • [CABFOID] https://cabforum.org/object-registry/

  • [CSWIKIPEDIA] https://en.wikipedia.org/wiki/Cipher_suite

  • [DIGICERTCPS] https://www.digicert.com/content/dam/digicert/pdfs/legal/DigiCert-CPS-V.5.6.pdf

  • [EVCWIKIPEDIA] Extended Validation Certificate - Wikipedia [online]. https://en.wikipedia.org/wiki/Extended_Validation_Certificate

  • [FIPS186-3] National Institute for Standards and Technology, “Digital Signature Standard (DSS),” FIPS PUB 186-3, June 2009.

  • [FIPS198] National Institute for Standards and Technology, “The Keyed-Hash Message Authentication Code (HMAC),” FIPS PUB 198, Mar. 2002.

  • [FIPS800-38B] National Institute for Standards and Technology, “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication,”NIST Special Publication 800-38B, May 2005.

  • [GLOBALSIGNCP] https://www.globalsign.com/en/repository/GlobalSign_CP_v6.6_final.pdf

  • [ITUOID] http://www.itu.int/ITU-T/asn1

  • [NAZ00] Network Associates and P. Zimmermann, Introduction to Cryptography, Part of PGP 7.0 Documentation, available from http://www.pgpi.org/doc/guide/7.0/en

  • [NIST800-38D] National Institute for Standards and Technology, “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC,”NIST Special Publication 800-38D, Nov. 2005.

  • [OCSPWIKIPEDIA] https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

  • [OPENSSL] https://www.openssl.org/

  • [RFC1321] R. Rivest, “The MD5 Message-Digest Algorithm,”Internet RFC 1321 (informational), Apr. 1992.

  • [RFC2104] H. Krawczyk, M. Bellare, and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,”Internet RFC 2104 (informational), Feb. 1997.

  • [RFC2410] R. Glenn and S. Kent, “The NULL Encryption Algorithm and Its Use with IPsec,” Internet RFC 2410, Nov. 1998.

  • [RFC2631] E. Rescorla, “Diffie-Hellman Key Agreement Method,” Internet RFC 2631, June 1999.

  • [RFC3447] J. Jonsson and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” Internet RFC 3447 (informational), Feb. 2003.

  • [RFC3713] M. Matsui, J. Nakajima, and S. Moriai, “A Description of the Camellia Encryption Algorithm,”Internet RFC 3713 (informational), Apr. 2004.

  • [RFC4086] D. Eastlake 3rd, J. Schiller, and S. Crocker, “Randomness Requirements for Security,”Internet RFC 4086/BCP 0106, June 2005.

  • [RFC4309] R. Housley, “Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP),” Internet RFC 4309, Dec. 2005.

  • [RFC4434] P. Hoffman, “The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE),” Internet RFC 4434, Feb. 2006.

  • [RFC4615] J. Song, R. Poovendran, J. Lee, and T. Iwata, “The Advanced Encryption Standard-Cipher-Based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE),” Internet RFC 4615, Aug. 2006.

  • [RFC4880] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer, “Open-PGP Message Format,” Internet RFC 4880, Nov. 2007.

  • [RFC5116] D. McGrew, “An Interface and Algorithms for Authenticated Encryption,”Internet RFC 5116, Jan. 2008.

  • [RFC5280] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” Internet RFC 5280, May 2008.

  • [RFC5652] R. Housley, “Cryptographic Message Syntax (CMS),”Internet RFC 5652/STD 0070, Sept. 2009.

  • [RFC5755] S. Farrell, R. Housley, and S. Turner, “An Internet Attribute Certificate Profile for Authorization,”Internet RFC 5755, Jan. 2010.

  • [RFC6024] R. Reddy and C. Wallace, “Trust Anchor Management Requirements,” Internet RFC 6024 (informational), Oct. 2010.

  • [RFC6234] D. Eastlake 3rd and T. Hansen, “US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF),”Internet RFC 6234 (informational), May 2011.

  • [SSLDVOVEV] DV, OV, IV, and EV Certificates - SSL.com [online]. https://www.ssl.com/article/dv-ov-and-ev-certificates/

  • [SSLGREENBAR] Why the green bar is gone for good | SSLs.com Blog [online]. https://www.ssls.com/blog/why-the-green-bar-is-gone-for-good/

  • [X9.62-2005] American National Standards Institute, “Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA),” ANSI X9.62, 2005.

  • [RUBLONIKEOVPN] https://rublon.com/blog/ikev2-openvpn-difference/