Sri Raghavendra Educational Institutions Society (R)

(Approved by AICTE, Accredited by NAAC, Affiliated to VTU, Karnataka)

Sri Krishna Institute of Technology

www.skit.org.in

Module-3:

Addressed: CO3

Course: Cryptography & Network Security

Presented by: SHWETA SINGH

Department: Computer Science & Engineering

Hash Function�

2

A hash function H accepts a variable-length block of data M as input and produces a fixed-size hash value h = H(M).

• A large set of inputs will produce outputs that are evenly distributed and apparently random.
• In general terms, the principal object of a hash function is data integrity. A change to any bit or bits in M results, with high probability, in a change to the hash value.
• The kind of hash function needed for security applications is referred to as a cryptographic hash function.

APPLICATIONS OF CRYPTOGRAPHIC HASH FUNCTIONS

3

1. Message Authentication

​

Message authentication is a mechanism or service used to verify the integrity ofa message. Message authentication assures that data received are exactly as sent (i.e., there is no modification, insertion, deletion, or replay).

In many cases, there is a requirement that the authentication mechanism assures that purported identity of the sender is valid. When a hash function is used to provide message authentication, the hash function value is often referred to as a message digest.

The essence of the use of a hash function for message integrity is as follows.

• The sender computes a hash value as a function of the bits in the message and transmits both the hash value and the message.
• The receiver performs the same hash calculation on the message bits and compares this value with the incoming hash value . If there is a mismatch, the receiver knows that the message (or possibly the hash value) has been altered.

The hash value must be transmitted in a secure fashion. That is, the hash value must be protected so that if an adversary alters or replaces the message, it is not feasible for adversary to also alter the hash value to fool the receiver.

4

Alice transmits a data block and attaches a hash value. Darth intercepts the message, alters or replaces the data block and calculates and attaches a new hash value. Bob receives the altered data with the new hash value and does not detect the change. To prevent this attack, the hash value generated by Alice must be protected.

5

A variety of ways in which a hash code can be used to provide message authentication, as follows

1. The message plus concatenated hash code is encrypted using symmetric encryption. Because only A and B share the secret key, the message must have come from A and has not been altered. The hash code provides the structure or redundancy required to achieve authentication. Because encryption is applied to the entire message plus hash code, confidentiality is also provided
2. Only the hash code is encrypted, using symmetric encryption. This reduces the processing burden for those applications that do not require confidentiality.

6

c. It is possible to use a hash function but no encryption for message authentication. The technique assumes that the two communicating parties share a common secret value S. A computes the hash value over the concatenation of M and S and appends the resulting hash value to M. Because B possesses S, it can recompute the hash value to verify. Because the secret value itself is not sent, an opponent cannot modify an intercepted message and cannot generate a false message.

d. Confidentiality can be added to the approach of method (c) by encrypting the entire message plus the hash code.

7

When confidentiality is not required, method (b) has an advantage over methods (a) and (d), which encrypts the entire message, in that less computation is required. There has been growing interest in techniques that avoid encryption . Several reasons for this interest are pointed out in .

​

• Encryption software is relatively slow. Even though the amount of data to be encrypted per message is small, there may be a steady stream of messages into and out of a system.
• Encryption hardware costs are not negligible. Low-cost chip implementations of DES are available, but the cost adds up if all nodes in a network must have this capability.
• Encryption hardware is optimized toward large data sizes. For small blocks of data, a high proportion of the time is spent in initialization/invocation overhead.
• Encryption algorithms may be covered by patents, and there is a cost associated with licensing their use.

​

Message authentication is achieved using a message authentication code (MAC), also known as a keyed hash function. Typically, MACs are used between two parties that share a secret key to authenticate information exchanged between those parties. A MAC function takes as input a secret key and a data block and produces a hash value, referred to as the MAC, which is associated with the protected message. If the integrity of the message needs to be checked, the MAC function can be applied to the message and the result compared with the associated MAC value. An attacker who alters the message will be unable to alter the associated MAC value without knowledge of the secret key. Note that the verifying party also knows who the sending party is because no one else knows the secret key.

8

2. Digital Signatures

The operation of the digital signature is similar to that of the MAC. In the case of the digital signature, the hash value of a message is encrypted with a user’s private key. Anyone who knows the user’s public key can verify the integrity of the message that is associated with the digital signature.

In this case, an attacker who wishes to alter the message would need to know the user’s private key.In a simplified fashion, how a hash code is used to provide a digital signature.

​

1. The hash code is encrypted, using public-key encryption with the sender’s private key.This provides authentication. It also provides a digital signature, because only the sender could have produced the encrypted hash code. In fact, this is the essence of the digital signature technique.
2. If confidentiality as well as a digital signature is desired, then the message plus the private-key-encrypted hash code can be encrypted using a symmetric secret key. This is a common technique.

9

Other Applications

• Hash functions are commonly used to create a one-way password file. A scheme in which a hash of a password is stored by an operating system rather than the password itself. Thus, the actual password is not retrievable by a hacker who gains access to the password file. In simple terms, when a user enters a password, the hash of that password is compared to the stored hash value for verification. This approach to password protection is used by most operating systems.
• Hash functions can be used for intrusion detection and virus detection. Store H(F) for each file on a system and secure the hash values. One can later determine if a file has been modified by recomputing H(F). An intruder would need to change F without changing H(F).
• A cryptographic hash function can be used to construct a pseudorandom function (PRF) or a pseudorandom number generator (PRNG). A common application for a hash-based PRF is for the generation of symmetric keys. We discuss this application.

10

TTWO SIMPLE HASH FUNCTIONST

​

To get some feel for the security considerations involved in cryptographic hash functions, we present two simple, insecure hash functions in this section. All hash functions operate using the following general principles. The input (message, file, etc.) is viewed as a sequence of n -bit blocks. The input is processed one block at a time in an iterative fashion to produce an n-bit hash function. One of the simplest hash functions is the bit-by-bit exclusive-OR (XOR) of every block. This can be expressed as

​

Ci = bi1 ⊕bi2 ⊕ g ⊕bim

where

Ci = ith bit of the hash code, 1 … i … n

m = number of bit blocks in the input

bij = ith bit in jth block

⊕ = XOR operation

​

This operation produces a simple parity bit for each bit position and is known as a longitudinal redundancy check. It is reasonably effective for random data as a data integrity check. Each n-bit hash value is equally likely. Thus, the probability that a data error will result in an unchanged hash value is 2-n. With more predictably formatted data, the function is less effective. For example, in most normal text files, the high-order bit of each octet is always zero. So if a 128-bit hash value is used, instead of an effectiveness of 2-128, the hash function on this type of data has an effectiveness Of.NS

11

A simple way to improve matters is to perform a one-bit circular shift, or rotation, on the hash value after each block is processed. The procedure can be summarized as follows.

​

1. Initially set the n-bit hash value to zero.

2. Process each successive n-bit block of data as follows:

a. Rotate the current hash value to the left by one bit.

b. XOR the block into the hash value.

​

This has the effect of “randomizing” the input more completely and overcoming any regularities that appear in the input. these two types of hash functions for 16-bit hash values.

Although a simple XOR or rotated XOR (RXOR) is insufficient if only the hash code is encrypted, you may still feel that such a simple function could be useful when the message together with the hash code is encrypted

12

Security Requirements for Cryptographic Hash Functions

These are the six properties

13

The fourth property, preimage resistant, is the one-way property: it is easy to generate a code given a message, but virtually impossible to generate a message given a code. This property is important if the authentication technique involves the use of a secret value . The secret value itself is not sent. However, if the hash function is not one way; an attacker can easily discover the secret value: If the attacker can observe or intercept a transmission, the attacker obtains the message M, and the hash code h = H(S }M). The attacker then inverts the hash function to obtain S }M = H-1(MDM). Because the attacker now has both M and

SAB }M, it is a trivial matter to recover SAB.

​

The fifth property, second preimage resistant, guarantees that it is infeasible to find an alternative message with the same hash value as a given message. This prevents forgery when an encrypted hash code is used. If this

property were not true, an attacker would be capable of the following sequence: First, observe or intercept a message plus its encrypted hash code; second, generate an unencrypted hash code from the message; third, generate an alternate message with the same hash code.

14

15

​

A hash function that satisfies the first five properties in Table 11.1 is referred to as a weak hash function. If the sixth property, collision resistant, is also satisfied, then it is referred to as a strong hash function. A strong hash function protects against an attack in which one party generates a message for another party to sign.

For example, suppose Bob writes an IOU message, sends it to Alice, and she signs it. Bob finds two messages with the same hash, one of which requires Alice to pay a small amount and one that requires a large payment. Alice signs the first message, and Bob is then able to claim that the second message is authentic.

​

pseudorandomness, has not traditionally been listed as a requirement of cryptographic hash functions but is more or

less implied. cryptographic hash functions are commonly used for key derivation and pseudorandom number generation, and that in message integrity applications, the three resistant properties depend on the output of the hash function appearing to be random. Thus, it makes sense to verify that in fact a given hash function produces pseudorandom output.

16

There are two categories of attacks on hash functions:

1. brute-force attacks
2. cryptanalysis

​

• A brute-force attack does not depend on the specific algorithm but depends only on bit length. In the case of a hash function, a brute-force attack depends only on the bit length of the hash value.
• A cryptanalysis is an attack based on weaknesses in a particular cryptographic algorithm.

​

Brute-Force Attacks

PREIMAGE AND SECOND PREIMAGE ATTACKS

For a preimage or second preimage attack, an adversary wishes to find a value y such that H(y) is equal to a given hash value h. The brute-force method is to pick values of y at random and try each value until a collision occurs. For an m-bit hash value, the level of effort is proportional to 2m. Specifically, the adversary would have to try, on average, 2m-1 values of y to find one that generates a given hash value h.

​

COLLISION RESISTANT ATTACKS For a collision resistant attack, an adversary wishes to find two messages or data blocks, x and y, that yield the same hash function: H(x) = H(y). This turns out to require considerably less effort than a preimage or second preimage attack. The effort required is explained by a mathematical result referred to as the birthday paradox. In essence, if we choose random variables from

a uniform distribution in the range 0 through N - 1, then the probability that a repeated element is encountered exceeds 0.5 after 2N choices have been made. Thus, for an m-bit hash value, if we pick data blocks at random, we can expect to find two data blocks with the same hash value within 22m = 2m/2 attempts.

​

17

Cryptanalysis

cryptanalytic attacks on hash functions seek to exploit some property of the algorithm to perform some attack other than an exhaustive search. The way to measure the resistance of a hash algorithm to cryptanalysis is to compare its strength to the effort required for a brute-force attack.

That is, an ideal hash algorithm will require a cryptanalytic effort greater than or equal to the brute-force effort.

In recent years, there has been considerable effort, and some successes, in developing cryptanalytic attacks on hash functions. To understand these, referred to as an iterated hash function, was proposed by Merkle and is the structure of most hash functions

The hash function takes an input message and partitions it into L fixed-sized blocks of b bits each. If necessary, the final block is padded to b bits. The final block also includes the value of the total length of the input to the hash function. The inclusion of the length makes the job of the opponent more difficult. Either the opponent must find two messages of equal length that hash to the same value or two messages of differing lengths that, together with their length values, hash to the same value.

The hash algorithm involves repeated use of a compression function, f, that takes two inputs (an n-bit input from the previous step, called the chaining variable, and a b-bit block) and produces an n-bit output. At the start of hashing, the chaining variable has an initial value that is specified as part of the algorithm. The final value of the chaining variable is the hash value. Often, b 7 n; hence the term compression.

The hash function can be summarized as

CV0 = IV = initial n-bit value

CVi = f(CVi-1, Yi-1) 1 … i … L

H(M) = CVL

where the input to the hash function is a message M consisting of the blocks

Y0, Y1, c, YL-1.

​

18

Cryptanalysis of hash functions focuses on the internal structure of f and is based on attempts to find efficient techniques for producing collisions for a single execution of f. Once that is done, the attack must take into account the fixed value of IV. The attack on f depends on exploiting its internal structure. Typically, as with symmetric block ciphers, f consists of a series of rounds of processing, so that the attack involves analysis of the pattern of bit changes from round to round.

any hash function there must exist collisions, because we are mapping a message of length at least equal to twice the block size b (because we must append a length field) into a hash code of length n, where b Ú n. What is required is that it is computationally infeasible to find collisions.

19

Key Management and Distribution

​

Key Management :Key management refers to the entire process of handling cryptographic keys throughout their life cycle.�It includes:

Generation -Creating secure, random keys.

​

Distribution- Delivering keys securely to the intended parties.

​

Storage - Keeping keys safe from unauthorized access.

​

Usage - Using keys only for their intended purpose.

​

Rotation/Update - Periodically changing keys to reduce risk.

​

Revocation/Destruction - Securely deleting keys when they are no longer needed.

​

Key Management ensures that cryptographic keys remain secret, valid, and protected.

​

​

20

Key Distribution

​

Key distribution is a part of key management, focused on how cryptographic keys are securely shared between parties.

​

SYMMETRIC KEY DISTRIBUTION USING SYMMETRIC ENCRYPTION

​

• symmetric encryption
• confidential
• changed frequently

​

21

Methods of Key Distribution

Manual

A generates the key and physically hands it to B. Useful for link encryption (point-to-point). But impractical for end-to-end encryption in large, distributed networks.

​

Trusted Third Party

A third party generates the key and securely delivers it to both A and B.

​

Using a Previous Key

If A and B already share a key, they can send a new key encrypted with the old . Convenient, but if one key is compromised, all future keys are at risk

​

Trusted Server (KDC)

A secure central server that creates and shares secret session keys with users so they can communicate safely.

22

KEY HIERARCHY

A Key Distribution Center (KDC) uses a hierarchy of keys to manage security

• At a minimum, two levels of keys are used (Figure 14.2). Communication between end systems is encrypted using a temporary key, often referred to as a session key.

​

• Typically, the session key is used for the duration of a logical connection, such as a frame relay connection or transport connection and then discarded.

​

• Each session key is obtained from the key distribution center over the same networking facilities used for end-user communication.

​

• Accordingly, session keys are transmitted in encrypted form, using a master key that is shared by the key distribution center and an end system or user.

23

A Key Distribution Scenario

​

The scenario assumes that each user shares a unique master key with the key distribution centre (KDC).

​

• Let us assume that user A wishes to establish a logical connection with B and requires a one-time session key to protect the data transmitted over the connection.
• A has a master key, Ka, known only to itself and the KDC; similarly, B shares the master key Kb with the KDC.

​

24

The following steps occur.

STEP1 A issues a request to the KDC for a session key to protect a logical connection to B.

IDA || IDB || N1

• The message includes the identity of A and B and a unique identifier, N1, for this transaction, which we refer to as a nonce.
• The nonce may be a timestamp, a counter, or a random number;
• The minimum requirement is that it differs with each request.
• Also, to prevent masquerade, it should be difficult for an opponent to guess the nonce. Thus, a random number is a good choice for a nonce.

25

STEP 2

The KDC responds with a message encrypted using Ka. Thus, A is the only one who can successfully read the message, and A knows that it originated at the KDC.

​

E(Ka, [Ks || IDA || IDB || N1])|| E(Kb, [Ks || IDA])

The message includes two items intended for A:

■ The one-time session key, Ks, to be used for the session

■ The original request message, including the nonce, to enable A to match this response with the appropriate request.

Thus, A can verify that its original request was not altered before reception by the KDC and, because of the nonce, that this is not a replay of some previous request.

In addition, the message includes two items intended for B:

​

■ The one-time session key, Ks, to be used for the session

■ An identifier of A (e.g., its network address), IDA

These last two items are encrypted with Kb (the master key that the KDC shares with B). They are to be sent to B to establish the connection and prove A’s identity.

26

STEP 3

• A stores the session key for use in the upcoming session and forwards to B the information that originated at the KDC for B,
• E(Kb,[Ks }IDA])
• Because this information is encrypted with Kb, it is protected from eavesdropping.
• B now knows the session key (Ks), knows that the other party is A (from IDA), and knows that the information originated at the KDC (because it is encrypted using Kb).
• At this point, a session key has been securely delivered to A and B, and they may begin their protected exchange.

27

4. Using the newly minted session key for encryption, B sends a nonce, N2, to A.

​

E(Ks, N2)

​

5. Also, using Ks, A responds with f(N2), where f is a function that performs some

transformation on N2 (e.g., adding one).

​

E(Ks, f(N2))

sends it back

28

Hierarchical Key Control

​

• It is not necessary to limit the key distribution function to a single KDC .Indeed, for very large networks, it may not be practical to do so.
• A hierarchy of KDCs can be established.
• For example, there can be local KDCs, each responsible for a small domain of the overall internetwork, such as a single LAN or a single building.
• For communication among entities within the same local domain, the local KDC is responsible for key distribution.
• If two entities in different domains desire a shared key, then the corresponding local KDCs can communicate through a global KDC.
• In this case, any one of the three KDCs involved can actually select the key.
• The hierarchical concept can be extended to three or even more layers, depending on the size of the user population and the geographic scope of the internetwork.

29

Session Key Lifetime

How long should a session key remain valid?

• The more frequently session keys are exchanged, the more secure they are, because
• the opponent has less ciphertext to work with for any given session key.
• On the other hand, the distribution of session keys delays the start of any exchange and places a burden on network capacity. A security manager must try to balance these competing considerations in determining the lifetime of a particular session key.
• For connection-oriented protocols, one obvious choice is to use the same session key for the length of time that the connection is open, using a new session key for each new session.
• If a logical connection has a very long lifetime, then it would be prudent to change the session key periodically, perhaps every time the PDU (protocol data unit) sequence number cycles.
• For a connectionless protocol, such as a transaction-oriented protocol, there is no explicit connection initiation or termination. Thus, it is not obvious how often one needs to change the session key.
• The most secure approach is to use a new session key for each exchange. However, this negates one of the principal benefits of connectionless protocols, which is minimum overhead and delay for each transaction.
• A better strategy is to use a given session key for a certain fixed period only or for a certain number of transactions.

30

A Transparent Key Control Scheme

A Transparent Key Control Scheme is a method of automatically managing session keys so that users don’t have to worry about encryption or key management.

The approach assumes that communication makes use of a connection- oriented end-to-end protocol, such as TCP. The noteworthy element of this approach is a session security module (SSM), which may consist of functionality at one protocol layer, that performs end-to-end encryption and obtains session keys on behalf of its host or terminal.

• The steps involved in establishing a connection.
• When one host wishes to set up a connection to another host, it transmits a connection request packet (step 1). The SSM saves that packet and applies to the KDC for permission to establish the connection (step 2).
• The communication between the SSM and the KDC is encrypted using a master key shared only by this SSM and the KDC.

31

• If the KDC approves the connection request, it generates the session key and delivers it to the two appropriate SSMs, using a unique permanent key for each SSM (step 3).
• The requesting SSM can now release the connection request packet, and a connection is set up between the two end systems (step 4).
• All user data exchanged between the two end systems are encrypted by their respective SSMs using the one-time session key.
• The automated key distribution approach provides the flexibility and dynamic characteristics needed to allow a number of terminal users to access a number of hosts and for the hosts to exchange data with each other.

32

Decentralized Key Control

• The use of a key distribution center(KDC) imposes the requirement that the KDC be trusted and be protected from subversion. This dependency can be avoided if key distribution is fully decentralized.
• Although full decentralization is not practical for larger networks using symmetric encryption only, it may be useful within a local context.
• A decentralized approach requires that each end system be able to communicate in a secure manner with all potential partner end systems for purposes of session key distribution. Thus, there may need to be as many as [n(n - 1)]/2 master keys for a configuration with n end systems.

​

33

A session key may be established with the following sequence of steps

1. A issues a request to B for a session key and includes a nonce, N1.

2. B responds with a message that is encrypted using the shared master key. The response includes the session key selected by B, an identifier of B, the value f(N1), and another nonce, N2.

3. Using the new session key, A returns f(N2) to B

although each node must maintain at most (n - 1) master keys, as many session keys as required may be generated and used. Because the messages transferred using the master key are short, cryptanalysis is difficult.

34

Controlling Key Usage

The concept of a key hierarchy and the use of automated key distribution techniques greatly reduce the number of keys that must be manually managed and distributed.

It also may be desirable to impose some control on the way in which automatically distributed keys are used.

For example, in addition to separating master keys from session keys, we may wish to define different types of session keys based on use, such as

■ Data-encrypting key, for general communication across a network

■ PIN-encrypting key, PINs used in electronic funds transfer and point-of-sale applications

■ File-encrypting key, for encrypting files stored in publicly accessible locations

The value of separating keys by type, consider the risk that a master key is imported as a data-encrypting key into a device.

Normally, the master key is physically secured within the cryptographic hardware of the key distribution center and of the end systems.

Session keys encrypted with this master key are available to application programs, as are the data encrypted with such session keys.

However, if a master key is treated as a session key, it may be possible for an unauthorized application to obtain plaintext of session keys encrypted with that master key.

Thus, it may be desirable to institute controls in systems that limit the ways in which keys are used, based on characteristics associated with those keys.

35

There are a few techniques to implement such restrictions

key tagging and control vector

​

​

​

The proposed technique is for use with DES and makes use of the extra 8 bits in each 64-bit DES key. That is, the eight non-key bits ordinarily reserved for parity checking form the key tag.

One simple plan is to associate a tag with each key.

The bits have the following interpretation

■ One bit indicates whether the key is a session key or a master key

■ One bit indicates whether the key can be used for encryption

■ One bit indicates whether the key can be used for decryption

■ The remaining bits are spares for future use.

The drawbacks of this scheme are

1. The tag length is limited to 8 bits, limiting its flexibility and functionality.

2. Because the tag is not transmitted in clear form, it can be used only at the point of decryption, limiting the ways in which key use can be controlled.

​

36

A more flexible scheme, referred to as the control vector,

In this scheme, each session key has an associated control vector consisting of a number of fields that specify the uses and restrictions for that session key. The length of the control vector may vary.

The control vector is cryptographically coupled with the key at the time of key generation at the KDC.

The coupling and decoupling processes are shown in fig.

• As a first step, the control vector is passed through a hash function that produces a value whose length is equal to the encryption key length.
• A hash function maps values from a larger range into a smaller range with a reasonably uniform spread.

37

The hash value is then XORed with the master key to produce an output that is used as the key input for encrypting the session key. Thus,

Hash value = H = h(CV) Key input = Km ⊕ H

Ciphertext = E([Km ⊕ H], Ks)

where Km is the master key and Ks is the session key. The session key is recovered in plaintext by the reverse operation:

D([Km ⊕ H], E([Km ⊕ H], Ks))

When a session key is delivered to a user from the KDC, it is accompanied by the control vector in clear form. The session key can be recovered only by using both the master key that the user shares with the KDC and the control vector.

Thus, the linkage between the session key and its control vector is maintained .

38

Use of the control vector has two advantages over use of an 8-bit tag.

​

• First, there is no restriction on length of the control vector, which enables arbitrarily com- plex controls to be imposed on key use.

• Second, the control vector is available in clear form at all stages of operation. Thus, control of key use can be exercised in multiple locations.

39

SYMMETRIC KEY DISTRIBUTION USING ASYMMETRIC ENCRYPTIONSYMMETRIC KEY DISTRIBUTION USING

ASYMMETRIC ENCRYPTION

Simple Secret Key Distribution

If A wishes to communicate with B, the following procedure is employed:

1. A generates a public/private key pair {PUa, PRa} and transmits a message to B consisting of PUa and an identifier of A, IDA.

2. B generates a secret key, Ks, and transmits it to A, which is encrypted with A’s public key.

3. A computes D(PRa, E(PUa, Ks)) to recover the secret key. Because only A can decrypt the message, only A and B will know the identity of Ks.

4. A discards PUa and PRa and B discards PUa.

• A and B can now securely communicate using conventional encryption and the session key Ks. At the completion of the exchange, both A and B discard Ks.
• No keys exist before the start of the communication, and none exist after the completion of communication. Despite its simplicity, this is an attractive protocol.
• Thus, the risk of compromise of the keys is minimal. At the same time, the communication is secure from eavesdropping.

​

40

The protocol is insecure against an adversary who can intercept messages and then either relay the intercepted message or substitute another message. Such an attack is known as a man-in-the-middle attack.

if an adversary, D, has control of the intervening communication channel, then D can compromise the communication in the following fashion without being detected.

41

1. A generates a public/private key pair {PUa, PRa} and transmits a message

intended for B consisting of PUa and an identifier of A, IDA.

2. D intercepts the message, creates its own public/private key pair {PUd, PRd}

and transmits PUd }IDA to B.

3. B generates a secret key, Ks, and transmits E(PUd, Ks).

4. D intercepts the message and learns Ks by computing D(PRd, E(PUd, Ks)).

5. D transmits E(PUa, Ks) to A.

42

Secret Key Distribution with Confidentiality and Authentication

An approach suggested it provides protection against both active and passive attacks. We begin at a point when it is assumed that A and B have exchanged public keys by one of the schemes .

Then the following steps occur.

1. A uses B’s public key to encrypt a message to B containing an identifier of A(IDA) and a nonce (N1), which is used to identify this transaction uniquely.

2. B sends a message to A encrypted with PUa and containing A’s nonce (N1) as well as a new nonce generated by B (N2). Because only B could have decrypted message (1), the presence of N1 in message (2) assures A that the correspondent is B.

3. A returns N2, encrypted using B’s public key, to assure B that its correspondent is A.

4. A selects a secret key Ks and sends M = E(PUb, E(PRa, Ks)) to B. Encryption of this message with B’s public key ensures that only B can read it; encryption with A’s private key ensures that only A could have sent it.

5. B computes D(PUa, D(PRb, M)) to recover the secret key.

43

A Hybrid Scheme

• Combines public-key encryption and symmetric key encryption methods for better security and efficiency.
• Used on IBM mainframes to manage key exchange securely.

Role of the Key Distribution Center (KDC) in Hybrid scheme

• A Key Distribution Center (KDC) shares a master key with each user.
• The KDC distributes session keys (temporary keys) encrypted with the master key.
• Public-key encryption is used only to send or update the master keys

Advantages:�Performance:

Public-key operations are heavy; this scheme reduces their use - faster transactions.

Ideal for systems where session keys change often.

Backward Compatibility:

• Can easily fit into existing KDC systems without major software changes.
• Adds a secure layer for master key distribution.

Security:

Provides both confidentiality and authentication.

Reduces risk of key compromise across large networks.

44

DISTR

DISTRIBUTION OF PUBLIC KEYSI

BU

Several techniques have been proposed for the distribution of public keys. Virtually all these proposals can be grouped into the following general schemes:

■ Public announcement

■ Publicly available directory

■ Public-key authority

■ Public-key certificatesTION OF PUBLIC KEYS

45

1.Public Announcement of Public Keys

In public-key encryption, the public key is shared openly, and it is used by other to send you encrypted message.

• Any user can send or broadcast their public key to others.
• Commonly used with RSA algorithm.

Example:

• In PGP (Pretty Good Privacy) encryption software, users often attach their public key to emails or post it in public forums for easily access.

Advantage: Simple and convenient way to share public keys.

No third party required

Easy for small groups or casual secure messaging.

Major Weakness: Forgery Risk – Anyone can:

• Pretend to be another user ,send or publish a fake public key in A’s name and read all messages meant for A or impersonate A . Until A discovers the forgery, the attacker can misuse the key.

46

2. Publicly Available Directory

A greater degree of security can be achieved by maintaining a publicly available dynamic directory of public keys. Maintenance and distribution of the public directory would have to be the responsibility of some trusted entity or organization. Such a scheme would include the following elements:

1. The authority maintains a directory with a {name, public key} entry for each participant.

2. Each participant registers a public key with the directory authority. Registration would have to be in person or by some form of secure authenticated communication.

3. A participant may replace the existing key with a new one at any time, either because of the desire to replace a public key that has already been used for a large amount of data, or because the corresponding private key has been compromised in some way.

4. Participants could also access the directory electronically. For this purpose, secure, authenticated communication from the authority to the participant is mandatory.

47

3. Public-Key Authority

Stronger security for public-key distribution can be achieved by providing tighter control over the distribution of public keys from the trusted directory. A typical scenario has shown.

As before, the scenario assumes that a central authority maintains a dynamic directory of public keys of all participants. In addition, each participant reliably knows a public key for the authority, with only the authority knowing the corresponding private key. The following steps occur.

1. A sends a timestamped message to the public-key authority containing a request for the current public key of B.

2. The authority responds with a message that is encrypted using the authority’s private key, PRauth. Thus, A is able to decrypt the message using the authority’s public key. Therefore, A is assured that the message originated with the authority. The message includes the following:

■ B’s public key, PUb, which A can use to encrypt messages destined for B

■ The original request used to enable A to match this response with the corresponding earlier request and to verify that the original request was not altered before reception by the authority

■ The original timestamp given so A can determine that this is not an old message from the authority containing a key other than B’s current public key

.

48

3. A stores B’s public key and also uses it to encrypt a message to B containing an identifier of A (IDA) and a nonce (N1), which is used to identify this transaction uniquely.

​

4, 5. B retrieves A’s public key from the authority in the same manner as A retrieved B’s public key. At this point, public keys have been securely delivered to A and B, and they may begin their protected exchange. However, two additional steps are desirable:

​

6. B sends a message to A encrypted with PUa and containing A’s nonce (N1) as well as a new nonce generated by B (N2). Because only B could have decrypted message (3), the presence of N1 in message (6) assures A that the correspondent is B.

​

7. A returns N2, which is encrypted using B’s public key, to assure B that its correspondent is A

49

4. Public-Key Certificates

The scenario is attractive, yet it has some drawbacks.

The public-key authority could be somewhat of a bottleneck in the system, for a user must appeal to the authority for a public key for every other user that it wishes to contact.

As before, the directory of names and public keys maintained by the authority is vulnerable to tampering. An alternative approach, , is to use certificates that can be used by participants to exchange keys without contacting a public-key authority, in a way that is as reliable as if the keys were obtained directly from a public-key authority.

In essence, a certificate consists of a public key, an identifier of the key owner, and the whole block signed by a trusted third party.

Typically, the third party is a certificate authority, such as a government agency or a financial institution, that is trusted by the user community. A user can present his or her public key to the authority in a secure manner and obtain a certificate. The user can then publish the certificate. Anyone needing this user’s public key can obtain the certificate and verify that it is valid by way of the attached trusted signature.

50

Requirements of a Public-Key Certificate Scheme

A participant can also convey its key information to another by transmitting its certificate. Other participants can verify that the certificate was created by the authority.

We can place the following requirements on this scheme:

​

1. Any participant should be able read a certificate to determine the name and public key of the certificate’s owner.

​

2. Any participant can verify that the certificate originated from the certificate authority and is not counterfeit.

​

3. Only the certificate authority can create and update certificates.

​

4. Any participant can verify the time validity of the certificate.

​

51

How it works

Application for Certificate:

A certificate scheme is, Each participant applies to the certificate authority, supplying a public key and requesting a certificate. Application must be in person or by some form of secure authenticated communication.

​

Certificate Creation by CA:

For participant A, the authority provides a certificate of the form

CA = E(PRauth, [T}IDA }PUa])

​

Verification by Others: when B receive that certificate, decrypt CA using PRauth where PRauth is the private key used by the authority and T is a timestamp. A may

then pass this certificate on to any other participant, who reads and verifies the

certificate as follows:

​

D(Puauth , CA) = D(Puauth , E(Prauth , [T}IDA }PUa])) = (T}IDA }PUa)

​

52

If the decryption works, B knows:

1. The certificate is genuine (issued by the CA).
2. The public key PUa really belongs to A.
3. The timestamp (T) shows the certificate is still valid (not expired).

53

Why Timestamp (T) Is Important

The timestamp counters the following scenario.

• A’s private key is learned by an adversary.
• A generates a new private/public key pair and applies to the certificate authority for a new certificate.
• attacker tries to use A’s old certificate to trick others.
• But the timestamp (T) shows it’s expired, so others reject it.

​

In this context, the compromise of a private key is comparable to the loss of a credit card. The owner cancels the credit card number but is at risk until all possible communicants are aware that the old credit card is expire. Thus, the timestamp serves as something like an expiration date. If a certificate is sufficiently old, it is assumed to be expired.

.

54

There is one widely accepted international standard for how public-key certificates (digital certificates) should be structured and formatted, and that standard is called X.509.

These X.509 certificates are used in almost all major network security systems, such as:

• IP Security (IPsec) for secure internet communication,
• TLS (Transport Layer Security)which secures websites (HTTPS),
• S/MIME (Secure/Multipurpose Internet Mail Extensions) which secures email.

55

X.5X.509 CERTIFICATES09 CERTIFICATES

ITU-T recommendation X.509 is part of the X.500 series of recommendations that define a directory service.

The directory is, in effect, a server or distributed set of servers that maintains a database of information about users. The information includes a mapping from username to network address, as well as other attributes and information about the users.

X.509 defines a framework for the provision of authentication services by the X.500 directory to its users. The directory may serve as a repository of public-key certificates. Each certificate contains the public key of a user and is signed with the private key of a trusted certification authority.

In addition, X.509 defines alternative authentication protocols based on the use of public-key certificates.

X.509 is based on the use of public-key cryptography and digital signatures. The standard does not dictate the use of a specific digital signature algorithm nor a specific hash function

56

57

X.509 scheme for generation of a public-key certificate. The certificate for Bob’s public key includes unique identifying information for Bob, Bob’s public key, and identifying information about the CA, plus other information as explained subsequently. This information is then signed by computing a hash value of the information and generating a digital signature using the hash value and the CA’s private key. X.509 indicates that the signature is formed by encrypting the hash value. This suggests the use of one of the RSA schemes discussed in Section 13.6. However, the current version of X.509 doesnot dictate a specific digital signature algorithm. If the NIST DSA (Section 13.4) or the ECDSA (Section 13.5) scheme is used, then the hash value is not encrypted but serves as input to a digital signature generation algorithm.

58

Certificates

The heart of the X.509 scheme is the public-key certificate associated with each user. These user certificates are assumed to be created by some trusted certification authority (CA) and placed in the directory by the CA or by the user. The directory server itself is not responsible for the creation of public keys or for the certification function; it merely provides an easily accessible location for users to obtain

certificates.

A shows the general format of a certificate, which includes the following elements.

​

Version: Differentiates among successive versions of the certificate format; the default is version 1. If the issuer unique identifier or subject unique identifier are present, the value must be version 2. If one or more extensions are present, the version must be version 3. Although the X.509 specification is currently at version 7, no changes have been made to the fields that make up the certificate since version 3.

Serial number: An integer value unique within the issuing CA that is unambiguously associated with this certificate.

■ Signature algorithm identifier: The algorithm used to sign the certificate together with any associated parameters. Because this information is repeated in the signature field at the end of the certificate, this field has little, if any, utility.

59

Issuer name: X.500 name of the CA that created and signed this certificate.

■ Period of validity: Consists of two dates: the first and last on which the certificate is valid.

■ Subject name: The name of the user to whom this certificate refers. That is, this certificate certifies the public key of the subject who holds the corresponding private key.

■ Subject’s public-key information: The public key of the subject, plus an identifier of the algorithm for which this key is to be used, together with any associated parameters.

60

■ Issuer unique identifier: An optional-bit string field used to identify uniquely the issuing CA in the event the X.500 name has been reused for different entities.

■ Subject unique identifier: An optional-bit string field used to identify uniquely the subject in the event the X.500 name has been reused for different entities.

■ Extensions: A set of one or more extension fields. Extensions were added in version 3 and are discussed later in this section.

■ Signature: Covers all of the other fields of the certificate. One component of this field is the digital signature applied to the other fields of the certificate. This field includes the signature algorithm identifier. The unique identifier fields were added in version 2

61

The standard uses the following notation to define a certificate:

CA<<A>>= CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}

where

Y <<X>> = the certificate of user X issued by certification authority Y

Y {I} = the signing of I by Y. It consists of I with an encrypted hash code appended

V = version of the certificate

SN = serial number of the certificate

AI = identifier of the algorithm used to sign the certificate

CA = name of certificate authority

UCA = optional unique identifier of the CA

A = name of user A

UA = optional unique identifier of the user A

Ap = public key of user A

TA = period of validity of the certificate

The CA signs the certificate with its private key. If the corresponding public

key is known to a user, then that user can verify that a certificate signed by the CA is

valid.

62

OBTAINING A USER’S CERTIFICATE

​

User certificates generated by a CA have the following characteristics:

​

■ Any user with access to the public key of the CA can verify the user public key that was certified.

■ No party other than the certification authority can modify the certificate without this being detected.

If all users subscribe to the same CA, then there is a common trust of that CA.

• All user certificates can be placed in the directory for access by all users. In addition, a user can transmit his or her certificate directly to other users. In either case, once B is in possession of A’s certificate, B has confidence that messages it encrypts with A’s public key will be secure from eavesdropping and that messages signed with A’s private key are unforgeable.
• If there is a large community of users, it may not be practical for all users to subscribe to the same CA. Because it is the CA that signs certificates, each participating user must have a copy of the CA’s own public key to verify signatures. This public key must be provided to each user in an absolutely secure (with respect
• to integrity and authenticity) way so that the user has confidence in the associated certificates. Thus, with many users, it may be more practical for there to be a number of CAs, each of which securely provides its public key to some fraction of the users.

63

• Now suppose that A has obtained a certificate from certification authority X1 and B has obtained a certificate from CA ,X2.
• If A does not securely know the public key of X2, then B’s certificate, issued by X2, is useless to A.
• A can read B’s certificate, but A cannot verify the signature. However, if the two CAs have securely exchanged their own public keys, the following procedure will enable A to obtain B’s public key.

​

Step 1 A obtains from the directory the certificate of X2 signed by X1. Because

A securely knows X1’s public key, A can obtain X2’s public key from its certificate and verify it by means of X1’s signature on the certificate.

​

Step 2 A then goes back to the directory and obtains the certificate of B signed by X2. Because A now has a trusted copy of X2’s public key, A can verify the signature and securely obtain B’s public key.

A has used a chain of certificates to obtain B’s public key. In the notation of X.509, this chain is expressed as

X1 <<X2>> X2 <<B>>

In the same fashion, B can obtain A’s public key with the reverse chain:

X2 <<X1>>.X1 <<A>>

This scheme need not be limited to a chain of two certificates. An arbitrarily long path of CAs can be followed to produce a chain. A chain with N elements would be expressed as

X1 <<X2>> X2 <<X3>> ...........XN. <<B>>

64

All these certificates of CAs by CAs need to appear in the directory, and the user needs to know how they are linked to follow a path to another user’s public-key certificate. X.509 suggests that CAs be arranged in a hierarchy so that navigation is straightforward. The connected circles indicate the hierarchical relationship among the CAs; the associated

boxes indicate certificates maintained in the directory for each CA entry. The directory entry for each CA includes two types of certificates:

​

■ Forward certificates: Certificates of X generated by other CAs

■ Reverse certificates: Certificates generated by X that are the certificates of other Cas user A can acquire the following certificates from the directory to establish a certification path to B:

​

Z<<Y>> Y <<V>>V <<Y>>Y <<Z>>Z<<A>>

​

When A has obtained these certificates, it can unwrap the certification path in sequence to recover a trusted copy of B’s public key. Using this public key, A can send encrypted messages to B.

65

If A wishes to receive encrypted messages back from B, or to sign messages sent to B, then B will require A’s public key, which can

be obtained from the following certification path:

Z<<Y>> Y<< V>> V<<W >> W<< X>> X<<A>>

B can obtain this set of certificates from the directory, or A can provide them as part of its initial message to B.

66

REVOCATION OF CERTIFICATES

Each certificate includes a period of validity, much like a credit card. Typically, a new certificate is issued just before the expiration of the old one. In addition, it may be desirable on occasion to revoke a certificate before it expires, for one of the following reasons.

​

1. The user’s private key is assumed to be compromised.

2. The user is no longer certified by this CA. Reasons for this include that the subject’s name has changed, the certificate is superseded, or the certificate was not issued in conformance with the CA’s policies.

3. The CA’s certificate is assumed to be compromised.

​

Each CA must maintain a list consisting of all revoked but not expired certificates issued by that CA, including both those issued to users and to other CAs. These lists should also be posted on the directory.

67

X.509 Version 3

The X.509 version 2 format does not convey all of the information that recent design and implementation requirements not satisfied by version 2.

​

1. The subject field is inadequate to convey the identity of a key owner to a public-key user. X.509 names may be relatively short and lacking in obvious identification details that may be needed by the user.

​

• The subject field is also inadequate for many applications, which typically recognize entities by an Internet email address, a URL, or some other Internet related identification.

​

• There is a need to indicate security policy information. This enables a security application or function, such as IPSec, to relate an X.509 certificate to a given policy.

​

• There is a need to limit the damage that can result from a faulty or malicious CA by setting constraints on the applicability of a particular certificate.

​

• It is important to be able to identify different keys used by the same owner at different times. This feature supports key lifecycle management: in particular, the ability to update key pairs for users and CAs on a regular basis or under exceptional circumstances.

​

68

KEY AND POLICY INFORMATION

These extensions convey additional information about the subject and issuer keys, plus indicators of certificate policy. A certificate policy is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.

​

This area includes:

■ Authority key identifier: Identifies the public key to be used to verify the signature on this certificate or CRL (Certificate Revocation List). Enables distinct keys of the same CA to be differentiated. One use of this field is to handle CA key pair updating.

■ Subject key identifier: Identifies the public key being certified. Useful for subject key pair updating. Also, a subject may have multiple key pairs and, correspondingly, different certificates for different purposes (e.g., digital signature and encryption key agreement).

■

69

■ Key usage: Indicates a restriction imposed as to the purposes for which, and the policies under which, the certified public key may be used. what operation are allowed May indicate one or more of the following:

digital signature, key encryption, data encryption, key agreement, CA signature verification on certificates, CA signature verification on CRLs.

■ Private-key usage period: Indicates the period of use of the private key corresponding to the public key. Typically, the private key is used over a different period from the validity of the public key. For example, with digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key.

■ Certificate policies: Certificates may be used multiple policies apply. This extension lists policies that the certificate is recognized as supporting, together with optional qualifier information.

■ Policy mappings: Used only in certificates for CAs issued by other CAs. Policy mappings allow an issuing CA to indicate that one or more of that issuer’s policies can be considered equivalent to another policy used in the subject CA’s domain.

70

CERTIFICATE SUBJECT AND ISSUER ATTRIBUTES

These extensions support alternative names, in alternative formats, for a certificate subject or certificate issuer and can convey additional information about the certificate subject to increase a certificate user’s confidence that the certificate subject is a particular person or entity.

For example, information such as postal address, position within a corporation, or picture image may be required.

​

The extension fields in this area include:

■ Subject alternative name: Contains one or more alternative names, using any of a variety of forms. This field is important for supporting certain applications, such as electronic mail, EDI, and IPSec, which may employ their own name forms.

■ Issuer alternative name: Contains one or more alternative names, using any of

a variety of forms.

■ Subject directory attributes: Conveys any desired X.500 directory attribute

values for the subject of this certificate.

71

CERTIFICATION PATH CONSTRAINTS

These extensions allow constraint specifications to be included in certificates issued for CAs by other CAs. The constraints may restrict the types of certificates that can be issued by the subject CA or that may occur subsequently in a certification chain.

​

The extension fields in this area include:

■ Basic constraints: Indicates if the subject may act as a CA. If so, a certification

path length constraint may be specified.

​

■ Name constraints: Indicates a name space within which all subject names in

subsequent certificates in a certification path must be located.

​

■ Policy constraints: Specifies constraints that may require explicit certificate

policy identification or block policy mapping for the remainder of the certification path.

72

PUBLIC-KEY INFRASTRUCTURE

RFC 4949 (Internet Security Glossary) defines public-key infrastructure (PKI) as the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography.

The principal objective for developing a PKI is to enable secure, convenient, and efficient acquisition of public keys. This section describes the PKIX model.

the interrelationship among the key elements of the PKIX model.

73

These elements are

■ End entity: A generic term used to denote end users, devices (e.g., servers, routers), or any other entity that can be identified in the subject field of a public-key certificate. End entities typically consume and/or support PKI related services.

​

■ Certification authority (CA): The issuer of certificates and (usually) certificate

revocation lists (CRLs). It may also support a variety of administrative functions, although these are often delegated to one or more Registration Authorities.

​

■ Registration authority (RA): An optional component that can assume a number of administrative functions from the CA. The RA is often associated with the end entity registration process but can assist in a number of other areas as well.

​

■ CRL issuer: An optional component that a CA can delegate to publish CRLs. publishes lists of revoked certificates. If any one private key is stolen, the CA adds his certificate to the CRL

​

■ Repository: A generic term used to denote any method for storing certificates and CRLs so that they can be access this repository to by end entities.

74

​

​

PKIX Management Functions

PKIX identifies a number of management functions that potentially need to be supported by management protocols. These are the following:

​

■ Registration: This is the process whereby a user first makes itself known to a CA (directly or through an RA), prior to that CA issuing a certificate or certificates for that user. Registration begins the process of enrolling in a PKI. Registration usually involves some offline or online procedure for mutual authentication. Typically, the end entity is issued one or more shared secret keys used for subsequent authentication.

​

■ Certification: This is the process in which a CA issues a certificate for a user’s public key, returns that certificate to the user’s client system, and/or posts that certificate in a repository.

​

75

■ Key pair recovery: Key pairs can be used to support digital signature creation and verification, encryption and decryption, or both. When a key pair is used for encryption/decryption, it is important to provide a mechanism to recover the necessary decryption keys when normal access to the keying material is no longer possible, otherwise it will not be possible to recover the encrypted data. Loss of access to the decryption key can result from forgotten passwords/PINs, corrupted disk drives, damage to hardware tokens, and so on. Key pair recovery allows end entities to restore their encryption/decryption key pair from an authorized key backup facility (typically, the CA that issued the end entity’s certificate).

76

■ Key pair update: All key pairs need to be updated regularly (i.e., replaced

with a new key pair) and new certificates issued. Update is required when the

certificate lifetime expires and as a result of certificate revocation.

■ Revocation request: An authorized person advises a CA of an abnormal situation requiring certificate revocation. Reasons for revocation include private key compromise, change in affiliation, and name change.

■ Cross certification: Two CAs exchange information used in establishing a cross-certificate. A cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key used for issuing certificates.

.

77

PKIX Management Protocols

The PKIX working group has defines two alternative management protocols between PKIX entities that support the management functions listed in the preceding subsection.

​

1. RFC 2510 defines the certificate management protocols (CMP). Within CMP, each of the management functions is explicitly identified by specific protocol exchanges. CMP is designed to be a flexible protocol able to accommodate a variety of technical, operational, and business models.

​

• RFC 2797 defines certificate management messages over CMS (CMC), where CMS refers to RFC 2630, cryptographic message syntax. CMC is built on earlier work and is intended to leverage existing implementations. Although all of the PKIX functions are supported, the functions do not all map into specific protocol exchanges

78

Module-4:

Addressed: CO4

Course: Cryptography & Network Security

Presented by: SHWETA SINGH

Department: Computer Science & Engineering

79

Module 4: Authentication Applications

​

In this module, we will study the following topics:

​

1. Remote User Authentication

Principles: Verifies user identity over a network.

Asymmetric Encryption: Uses public/private key pairs for secure user authentication.

Kerberos: Trusted third-party authentication using secret-key cryptography.

�2. Web Security

Protects data exchanged over the web.

Transport Layer Security (TLS): Ensures encrypted and secure communication between browser and server.

�3. Email Security

Email Threats: Spam, phishing, malware, impersonation.

Comprehensive Security Measures: Anti-virus, digital signatures, encryption.

�4. Secure Email Technologies

S/MIME (Secure/Multipurpose Internet Mail Extensions): Uses encryption & digital signatures for secure email.

Pretty Good Privacy (PGP): User-level encryption using a web of trust and public key cryptography.

80

SREMOTE USER-AUTHENTICATION PRINCIPLES

​

In most computer security contexts, user authentication is the building block and the primary line of defense. User authentication is the basis for most types of access control and for user accountability.

This happens in two steps:

Identification step:

The user provides an identifier (like username, email, or ID).

This ID is not secret and helps the system recognize the user.

Verification step:

The user provides authentication information (like a password, fingerprint, or token).

This confirms that the person really is who they claim to be.

So in Alice’s case:

Her user ID (ABTOKLAS) is public (known to others).

Her password is secret (known only to her and the system).�If someone doesn’t know her password, they cannot act as Alice.

That’s why the ID is used for identification, and the password is used for authentication.

Finally, note that user authentication (verifying a person) is different from message authentication (verifying that a message hasn’t been changed during communication).

​

81

The NIST Model for Electronic User Authentication

• NIST(National Institute of Standards and Technology ) defines electronic user authentication as the process of establishing confidence in user identities that are presented electronically to an information system.
• Systems can use the authenticated identity to determine if the authenticated individual is authorized to perform particular functions, such as database transactions or access to system resources.
• In many cases, the authentication and transaction or other authorized function takes place across an open network such as the Internet. Equally authentication and subsequent authorization can take place locally, such as across a local area network.

It defines a general model for user authentication that involves a number of entities and procedures.

The following is a typical sequence for registration. An applicant applies to a registration authority (RA) to become a subscriber of a credential service provider (CSP).

82

• The RA is a trusted entity that establishes and relible for the identity of an applicant to a CSP.
• The CSP then engages in an exchange with the subscriber.
• Depending on the details of the overall authentication system, the CSP issues some sort of electronic credential to the subscriber.
• The credential is a data structure that authoritatively binds an verified identity and additional attributes to a token possessed by a subscriber, and can be verified when presented to the verifier in an authentication transaction.
• The token could be an encryption key or an encrypted password that identifies the subscriber. The token may be issued by the CSP, generated directly by the subscriber, or provided by a third party.
• The token and credential may be used in subsequent authentication events.

​

83

• Once a user is registered as a subscriber, the actual authentication process can take place between the subscriber and one or more systems
• that perform authentication and, subsequently, authorization. The party to be authenticated is called a claimant and the party verifying that identity is called a verifier.
• When a claimant successfully shows possession and control of a token to a verifier through an authentication protocol, the verifier can verify that the claimant is the subscriber named in the corresponding credential. The verifier passes on an assertion about the
• identity of the subscriber to the relying party (RP). That assertion includes identity information about a subscriber, such as the subscriber name, an identifier assigned at registration, or other subscriber attributes that were verified in the registration process

84

• The RP can use the authenticated information provided by the verifier to make access control or authorization decisions.
• An implemented system for authentication will differ from or be more complex than this simplified model, but the model illustrates the key roles and functions needed for a secure authentication system.

85

Means of Authentication

There are four general means of authenticating a user’s identity, which can be used alone or in combination:

​

■ Something the individual knows: Examples include a password, a personal identification number (PIN), or answers to a prearranged set of questions.

​

■ Something the individual possesses: Examples include cryptographic keys, electronic keycards, smart cards, and physical keys. This type of authenticator is referred to as a token.

​

■ Something the individual is (static biometrics): Examples include recognition by fingerprint, retina, and face.

​

■ Something the individual does (dynamic biometrics): Examples include recognition by voice pattern, handwriting characteristics, and typing rhythm.

86

All of these methods, properly implemented and used, can provide secure user authentication. However, each method has problems.

• An adversary may be able to guess or steal a password. Similarly,
• An adversary may be able to forge or steal a token.
• A user may forget a password or lose a token.

​

Furthermore, there is a significant administrative overhead for managing password and token information on systems and securing such information on systems. With respect to biometric authenticators, there are a variety of problems, including dealing with false positives and false negatives, user acceptance, cost, and convenience. For network-based user authentication, the most important methods involve cryptographic keys and something the individual knows, such as a password.

87

Mutual Authentication

An important application area is that of mutual authentication protocols. Such protocols enable communicating parties to satisfy themselves mutually about each other’s identity and to exchange session keys.

Central to the problem of authenticated key exchange are two issues:

• Confidentiality
• Timeliness.
• To prevent masquerade(pretending to be someone else) and to prevent compromise of session keys, essential identification and session-key information must be communicated in encrypted form. This requires the prior existence of secret or public keys that can be used for this purpose.
• The second issue, timeliness, is important because of the threat of message replays. Such replays, at worst, could allow an opponent to compromise a session key or successfully impersonate another party. At minimum, a successful replay can disrupt operations by presenting parties with messages that appear genuine but are not.

88

The following examples of replay attacks:

​

1. The simplest replay attack is one in which the opponent simply copies a message and replays it later.

​

• An opponent can replay a timestamped message within the valid time window. If both the original and the replay arrive within then time window, this incident can be logged.

​

• An opponent can replay a timestamped message within the valid time window, but in addition, the opponent suppresses the original message. Thus, the repetition cannot be detected.

​

• Another attack involves a backward replay without modification. This is a replay back to the message sender. This attack is possible if symmetric encryption is used and the sender cannot easily recognize the difference between messages sent and messages received on the basis of content.

​

89

One approach to coping with replay attacks is to attach a sequence number to each message used in an authentication exchange. A new message is accepted only if its sequence number is in the proper order. The difficulty with this approach is that it requires each party to keep track of the last sequence number for each claimant it has dealt with. Because of this overhead, sequence numbers are generally not used for authentication and key exchange. Instead, one of the following two general approaches is used

:

• Timestamps: Party A accepts a message as fresh only if the message contains a timestamp that, in A’s judgment, is close enough to A’s knowledge of current time. This approach requires that clocks among the various participants be synchronized.

​

• Challenge/response: Party A, expecting a fresh message from B, first sends B a nonce (challenge) and requires that the subsequent message (response) received from B contain the correct nonce value.

90

91

One-Way Authentication

1. One application for which encryption is growing in popularity is electronic mail (email). The very nature of electronic mail, and its chief benefit, is that
2. It is not necessary for the sender and receiver to be online at the same time. Instead, the email message is forwarded to the receiver’s electronic mailbox, where it is buffered until the receiver is available to read it.
3. The “envelope” or header of the email message must be in the clear, so that the message can be handled by the store-and-forward email protocol, such as the Simple Mail Transfer Protocol (SMTP) or X.400. However,
4. It is often desirable that the mail-handling protocol not require access to the plaintext form of the message, because that would require trusting the mail-handling mechanism. Accordingly, the email message should be encrypted such that the mail-handling system is not in possession of the decryption key. A second requirement is that of authentication. Typically, the recipient wants some assurance that the message is from the alleged sender.

92

REMOTE USER-AUTHENTICATION USING SYMMETRIC ENCRYPTIONU

Mutual Authentication

A two-level hierarchy of symmetric encryption keys can be used to provide confidentiality for communication in a distributed environment.

In general, this strategy involves the use of a trusted key distribution centerS(KDC). Each party in the network shares a secret key, known as a master key, with the KDC. The KDC is responsible for generating keys to be used for a short time over a connection between two parties, known as session keys, and for distributing

those keys using the master keys to protect the distribution..

The protocol can be summarized as

follows.1

1. A- KDC: IDA //IDB //N1

2. KDC -A: E(Ka, // Ks // IDB // N1 // E(Kb, [Ks // IDA])

3. A -B: E(Kb, [Ks // IDA])

4. B -A: E(Ks, N2)

5. A -B: E(Ks, f(N2)) where f() is a generic function that modifies the value of the nonce.

Secret keys Ka and Kb are shared between A and the KDC and B and the KDC, respectively.

The purpose of the protocol is to distribute securely a session key Ks to A and B. Entity A securely acquires a new session key

in step 2. The message

in step 3 can be decrypted, and hence understood, only by B.

Step 4 reflects B’s knowledge of Ks, and step 5 assures B of A’s knowledge of Ks and assures B that this is a fresh message because of the use of the nonce N2. Recall from our discussion in

​

93

steps 4 and 5 is to prevent a certain type of replay attack.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

To overcome this weakness by a modification to the the addition of a timestamp.

master keys, Ka and Kb, are secure, and it consists of the following step.

• An opponent who captures and replays message (step 3) can disrupt operations at B.
• Even with the handshake in steps 4 and 5, the protocol remains vulnerable to replay under certain conditions.
• If an opponent X has compromised an old session key, X can: cannot detect that this is a replay.
• If X can also intercept B’s handshake message (step 4), X can impersonate A’s response (step 5).
• After that, X can send bogus messages to
• Replay the captured step-3 message containing that old key, and thereby trick B into using the old (compromised) key.
• Unless B remembers all previous session keys used with A indefinitely, B B that appear to come from A, authenticated under the (replayed) session key.

94

1. A -KDC: IDA //IDB

2. KDC -A: E(Ka, [Ks //IDB //T // E(Kb, [Ks // IDA // T])])

3. A -B: E(Kb, [Ks //IDA //T])

4. B -A: E(Ks, N1)

5. A -B: E(Ks, f(N1))

T is a timestamp that assures A and B that the session key has only just been generated. Thus, both A and B know that the key distribution is a fresh exchange. A and B can verify timeliness by checking that

Clock - T < Δt1 + Δt2

where Δt1 is the estimated normal error between the KDC’s clock and the local clock (at A or B).

Δt2 is the expected network delay time. Each node can set its clock against some standard reference source.

Because the timestamp T is encrypted using the secure master keys, an opponent, even with knowledge of an old session key, cannot succeed because a replay of step 3 will be detected by B as untimely.

A final point: Steps 4 and 5 were not included in the original presentation but were added later . These steps confirm the receipt of the session key at B.

95

It increased degree of security .

There are network points where risk is involved. The risk is based on the fact that

1. The distributed clocks can become unsynchronized
2. The problem occurs when a sender’s clock is ahead of the intended recipient’s clock. In this case, an opponent can intercept a message from the sender and replay it later when the timestamp in the message becomes current at the recipient’s site. This replay could cause unexpected results. It refers to such attacks as suppress-replay attacks.

One way to counter suppress-replay attacks is to enforce the requirement that parties regularly check their clocks against the KDC’s clock.

The other alternative, which avoids the need for clock synchronization, is to rely on handshaking protocols using nonces.

96

The protocol is

1. A -B: IDA //Na

2. B -KDC: IDB //Nb //E(Kb, [IDA //Na //Tb])

3. KDC -A: E(Ka, [IDB //Na //Ks //Tb]) // E(Kb, [IDA //Ks //Tb]) //Nb

4. A -B: E(Kb, [IDA //Ks //Tb]) // E(Ks, Nb)

​

Let us follow this exchange step by step.

1. A initiates the authentication exchange by generating a nonce, Na, and sending that plus its identifier to B in plaintext. This nonce will be returned to A in an encrypted message that includes the session key, assuring A of its timeliness
2. B alerts the KDC that a session key is needed. Its message to the KDC includes its identifier and a nonce, Nb. This nonce will be returned to B in an encrypted message that includes the session key, assuring B of its timeliness. B’s message to the KDC also includes a block encrypted with the secret key shared by B and the KDC. This block is used to instruct the KDC to issue credentials to A; the block specifies the intended recipient of the credentials, a suggested expiration time for the credentials, and the nonce received from.
3. A KDC passes on to A B’s nonce and a block encrypted with the secret key that B shares with the KDC. The block serves as a “ticket” that can be used by A for subsequent authentications, as will be seen. The KDC also sends to A a block encrypted with the secret key shared by A and the KDC. This block verifies that B has received A’s initial message (IDB) and that this is a timely message and not a replay (Na), and it provides A with a session key (Ks) and the time limit on its use (Tb).

97

4. A transmits the ticket to B, together with the B’s nonce, the latter encrypted with the session key. The ticket provides B with the secret key that is used to decrypt E(Ks, Nb) to recover the nonce. The fact that B’s nonce is encrypted with the session key authenticates that the message came from A and is not a replay. This protocol provides an effective, secure means for A and B to establish a session with a secure session key. Furthermore, the protocol leaves A in possession of a key that can be used for subsequent authentication to B, avoiding the need to contact the authentication server repeatedly. Suppose that A and B establish a session using the a forementioned protocol and then conclude that session. Subsequently, but within the time limit established by the protocol, A desires a new session with B.

The following protocol ensues:

1. A -B: E(Kb, [IDA //Ks //Tb]) //Na’

2. B -A: Nb ‘// E(Ks, Na ‘ )

3. A -B: E(Ks, Nb' )

When B receives the message in step 1, it verifies that the ticket has not expired. The newly generated nonces Na ‘and Nb ‘ assure each party that there is no replay attack.

In all the foregoing, the time specified in Tb is a time relative to B’s clock.Thus, this timestamp does not require synchronized clocks, because B checks only self-generated timestamps.

98

One-Way Authentication

Using symmetric encryption, the decentralized key distribution scenario. This scheme requires the sender to issue a request to the intended recipient, await a response that includes a session key, and only then send the message. With some refinement, the KDC strategy is a candidate for encrypted electronic mail. Because we wish to avoid requiring that the recipient (B) be on line at the same time as the sender (A), steps 4 and 5 must be eliminated. For a message with content M, the sequence is as follows:

1. A -KDC: IDA //IDB //N1

2. KDC -A: E(Ka, [Ks//IDB //N1 // E(Kb, [Ks //IDA])])

3. A -B: E(Kb, [Ks //IDA]) // E(Ks, M)

This approach guarantees that only the intended recipient of a message will be able to read it. It also provides a level of authentication that the sender is A. As specified, the protocol does not protect against replays. Some measure of defense could be provided by including a timestamp with the message. However, because of the potential delays in the email process, such timestamps may have limited usefulness.

99

KER KERBEROS BEROS

What is Kerberos?

Kerberos is an authentication system developed at MIT as part of Project Athena.It helps verify that the person (user) or computer trying to access a network service is actually who they claim to be.

The Problem It Solve In an open distributed network, many users work on different computers (workstations) and want to use services (like file servers, printers, etc.) spread across the network. But these workstations and networks cannot be fully trusted.

​

Three Main Security Threats

Impersonation (Fake User Login):�Someone can sit at a workstation and pretend to be another user.

Spoofing (Fake Workstation Address):�A hacker can change their workstation’s network address to make it look like requests are coming from a trusted machine.

Replay Attack:�A hacker can capture and reuse (replay) old valid messages to gain unauthorized access.

100

​

Type of Encryption Used

Kerberos uses only symmetric encryption (same secret key for encryption and decryption).�It does not use public-key (asymmetric) encryption.

​

Versions of Kerberos

There are two main versions:

Kerberos Version 4: The older version still used in some systems.

Kerberos Version 5: Improved version fixes security weaknesses found in Version 4.�It is also standardized as RFC 4120 and RFC 4121 (Internet standards).

101

Kerberos Design Requirements Secure:

No eavesdropper should be able to steal information and pretend to be someone else.

Kerberos itself should not be the weak point.

​

Secure: A network eavesdropper should not be able to obtain the necessary information to impersonate a user. More generally, Kerberos should be strong enough that a potential opponent does not find it to be the weak link.

​

■ Reliable: For all services that rely on Kerberos for access control, lack of availability of the Kerberos service means lack of availability of the supported services. Hence, Kerberos should be highly reliable and should employ a distributed server architecture with one system able to back up another.

​

■ Transparent: Ideally, the user should not be aware that authentication is taking place beyond the requirement to enter a password.

​

■ Scalable: The system should be capable of supporting large numbers of clients and servers. This suggests a modular, distributed architecture.

102

Kerberos Architecture

Works in a client/server environment.

Uses Kerberos servers for authentication.

Acts as a trusted third party both clients and servers trust Kerberos to verify each other’s identity.

103

A SIMPLE AUTHENTICATION DIALOGUE

1. Unprotected Network Environment

In an open or unprotected network, any client can connect to any server and ask for a service.

This freedom creates a serious security risk because there is no restriction or authentication.

2. Risk of Impersonation

Without protection, an attacker (opponent) can pretend to be another legitimate client.

By doing so, the attacker can gain unauthorized access to data or services on the server.

This is called an impersonation attack — pretending to be someone else to steal privileges.

3. Need for Server-side Verification

To prevent impersonation, every server must verify the identity of each client that requests a service.

This means the server must authenticate the client before granting access.

For example, before giving access to files or data, the server must be sure “this client is real.”

4. Problem with Individual Authentication

If every server performs authentication individually, it increases the workload on all servers.

In large or open networks with many users, this becomes inefficient and difficult to manage.

Each server would have to maintain a list of users, passwords, and verification methods — causing duplication and confusion.

104

�

5. Centralized Solution: Authentication Server (AS)

To solve this, a centralized Authentication Server (AS) is introduced.

The AS is a trusted third party responsible for verifying the identity of all users.

Instead of each server checking passwords, servers trust the AS’s authentication results.

​

6. Role of Authentication Server

The AS maintains a central database containing usernames and passwords for all users.

When a client logs in or requests access, the AS confirms their identity using this information.

After authentication, the AS helps the client securely communicate with other servers.

�7. Shared Secret Keys

The AS shares a unique secret key with each server in the network.

These keys are distributed beforehand in a secure or physical way (for example, during setup).

These keys allow encrypted communication between the AS and each server.

�8. Purpose of This Setup

The purpose is to reduce the burden on individual servers.

Servers don’t need to verify passwords themselves; they simply trust the authentication done by the AS.

This approach increases security, simplicity, and efficiency in the overall network authentication process.

105

• The user logs on to a workstation and requests access to server V.
• The client module C in the user’s workstation requests the user’s password.
• Then sends a message to the AS that includes the user’s ID, the server’s ID, and the user’s password.
• The AS checks its database to see if the user has supplied the proper password for this user ID and whether this user is permitted access to server V.
• If both tests are passed, the AS accepts the user as authentic and must now convince the server that this user is authentic.
• To do so, the AS creates a ticket that contains the user’s ID and network address and the server’s ID.
• This ticket is encrypted using the secret key shared by the AS and this server.
• This ticket is then sent back to C.
• Because the ticket is encrypted, it cannot be altered by C or by an opponent.
• With this ticket, C can now apply to V for service.
• C sends a message to V containing C’s ID and the ticket.

​

(1) C - AS: IDC // PC //IDV

(2) AS - C: Ticket

(3) C - V: IDC // Ticket

Ticket = E(Kv, [IDC //ADC // IDV])

where

C = client

AS = authentication server

V = server

IDC = identifier of user on C

IDV = identifier of V

PC = password of user on C

ADC = network address of C

Kv = secret encryption key shared by AS and V

106

• V decrypts the ticket and verifies that the user ID in the ticket is the same as the unencrypted user ID in the message.
• If these two match, the server considers the user authenticated and grants the requested service.
• The ticket is encrypted to prevent alteration or forgery.
• The server’s ID (IDV) is included in the ticket so that the server can verify that it has decrypted the ticket properly.
• IDC is included in the ticket to indicate that this ticket has been issued on behalf of C.
• ADC serves to counter the following threat: an opponent could capture the ticket transmitted in message (2), then use the name IDC and transmit a message of form (3) from another workstation.
• The server would receive a valid ticket that matches the user ID and grant access to the user on that other workstation.
• To prevent this attack, the AS includes in the ticket the network address from which the original request came.
• Now the ticket is valid only if it is transmitted from the same workstation that initially requested the ticket.

107

Problems in the Earlier Scenario

1. Too many password entries – User had to re-enter the password for every service (mail, print, file, etc.).
2. Password sent in plaintext – Anyone could capture it and misuse it.

​

​

​

To fix these issues: New Element Introduced

• A new server called the Ticket Granting Server (TGS) is added.
• Plaintext passwords are eliminated.
• Reusable tickets are introduced for convenience and security.

108

There are three levels of communication:

​

Once per User Logon Session

C - AS

• The client (C) sends:
• its user ID (IDC)
• and the ID of the Ticket Granting Server (IDtgs)�to the Authentication Server (AS).
• This means the client is saying:

Hi AS, I am this user, and I want to talk to the TGS.

AS - C

The AS checks if the user is valid and creates a ticket-granting ticket (Tickettgs).

Then it sends this back to the client in two parts:

Tickettgs = E(Ktgs, [IDC, ADC, IDtgs, TS1, Lifetime1])

This part is encrypted with Ktgs, a secret key known only to AS and TGS.

It means only the TGS can read it.

The outer message sent to the client is encrypted with Kc,�which is a key derived from the user’s password.

​

109

Once per Type of Service

C - TGS

• The client now wants to use a service (for example, a mail server).
• It sends to TGS:
• its user ID (IDC)
• the ID of the requested service (IDv)
• and the Tickettgs it got earlier.
• This proves that this user was already authenticated by AS.

TGS - C

• The TGS decrypts the Tickettgs using its secret key Ktgs.
• It verifies:
• ticket validity (not expired),
• user ID and network address (ADC),
• and permissions.
• If everything is correct, it creates a service-granting ticket (Ticketv):�Ticketv = E(Kv, [IDC, ADC, IDv, TS2, Lifetime2])
• This is encrypted with Kv, known only to TGS and the target server (V).
• The client receives and stores this Ticket v for future use with that service. Now the client can use this ticket multiple times for that particular service (until it expires).

110

Once per Service Session

Step 5 → C → V

• The client now contacts the actual service server (V).
• It sends:
• its user ID (IDC)
• and the service-granting ticket (Ticketv).
• The server (V) decrypts Ticketv using its secret key Kv.
• It checks:
• the user identity,
• timestamp and lifetime,
• and the source address (ADC).

If all is valid .The user is authenticated and allowed to use the service.

111

112

113

• Client sends its ID (IDC), TGS ID (IDtgs), and timestamp (TS1) to Authentication Server (AS) to request a ticket-granting ticket.
• AS replies with a message encrypted using user’s secret key (Kc) containing a session key (Kc,tgs), TGS ID, timestamp, lifetime, and the ticket-granting ticket (Tickettgs).
• The Tickettgs is encrypted with Ktgs, shared only between AS and TGS, and includes Kc,tgs, IDC, ADC, IDtgs, TS2, and Lifetime2.
• The client now has a reusable TGT and does not need to send the password again during the session.
• Client sends to TGS the service ID (IDv), Tickettgs, and an Authenticatorc encrypted with Kc,tgs containing IDC, ADC, and TS3.
• TGS decrypts Tickettgs using Ktgs, verifies it, and if valid, sends back a message encrypted with Kc,tgs, containing a new session key (Kc,v), service ID, timestamp, and Ticketv.
• The Ticketv is encrypted with Kv (known only to TGS and service server V) and contains Kc,v, IDC, ADC, IDv, TS4, and Lifetime4.
• Client now has Ticketv and session key Kc,v to communicate securely with service V.
• Client sends Ticketv and Authenticatorc (encrypted with Kc,v, containing IDC, ADC, TS5) to the service server (V).
• Server decrypts Ticketv using Kv, checks the authenticator, and confirms the client’s identity and freshness of request.
• Server sends back E(Kc,v, [TS5 + 1]) to the client to prove its own identity (mutual authentication).
• Both client and server are now authenticated to each other; the connection is secure without sending any password in plaintext.

114

KERBEROS REALMS AND MULTIPLE KERBERI

A full-service Kerberos environment consisting of a Kerberos server, a number of clients requires the following:

​

1. The Kerberos server must have the user ID and hashed passwords of all participating users in its database. All users are registered with the Kerberos server.

2. The Kerberos server must share a secret key with each server. All servers are registered with the Kerberos server.

Other Kerberos systems can hold read-only copies of the database, but all updates are made only on the master.

Any modification in the Kerberos database requires the Kerberos master password.

A Kerberos principal is any user or service known to the Kerberos system.

​

115

• Different organizations or administrative domains usually have different realms.
• It’s not practical for one realm’s users and servers to register with another realm’s Kerberos server.
• However, users in one realm may still need access to services in another realm.
• For this, Kerberos supports inter realm authentication — a way to trust users from another realm.
• To enable inter realm authentication, the Kerberos servers of both realms must share a secret key.
• This means each Kerberos server is registered with the other, establishing trust.
• The Kerberos server in one realm must trust the other realm’s server to authenticate its users correctly.
• Servers in the second realm must also accept the authentication done by the first realm’s Kerberos server.
• When a user needs a service from another realm:�  - The client first gets a ticket-granting ticket (TGT) from its local TGS.�  - Then requests a TGT for the remote TGS (in the other realm).�  - Finally, it asks the remote TGS for a service-granting ticket to access the remote server.
• The ticket given to the remote server shows which realm originally authenticated the user.
• The remote server may choose to accept or reject the request based on trust policies.

​

A major limitation: This inter realm setup doesn’t scale well for many realms.

If there are N realms, then N(N - 1)/2 secure key pairs are required which becomes complex for large networks.

116

(1) C → AS: IDc, IDtgs, TS1

• Client sends its ID, local TGS ID, and a timestamp to the Authentication Server (AS).

​

(2) AS → C: E(Kc, [Kc,tgs, IDtgs, TS2, Lifetime2, Tickettgs])

• AS responds with a message encrypted using the client’s secret key (Kc).
• It includes a session key (Kc,tgs) and a Ticket Granting Ticket (Tickettgs).

(3) C → TGS: IDtgsrem, Tickettgs, Authenticator c

• Client sends a request to the local TGS asking for access to a remote TGS (TGSrem).
• Includes remote TGS ID, its local ticket, and authenticator.

(4) TGS → C: E(Kc,tgs, [Kc,tgsrem, IDtgsrem, TS4, Tickettgsrem])

• Local TGS responds with data encrypted using session key (Kc,tgs).
• Contains a new session key (Kc,tgsrem) and a remote TGS ticket (Tickettgsrem).

(5) C → TGSrem: IDvrem, Tickettgsrem, Authenticator c

• Client sends request to remote TGS for a service in the remote realm.
• Includes ID of desired remote server, the remote TGS ticket, and authenticator.

�

.

117

(6) TGSrem → C: E(Kc,tgsrem, [Kc,vrem, IDvrem, TS6, Ticketvrem])

• Remote TGS responds with message encrypted using (Kc,tgsrem).
• Contains a new session key (Kc,vrem) and Ticketvrem for the remote server.

(7) C → Vrem: Ticketvrem, Authenticatorc

• Client sends the remote server its ticket and authenticator.
• Server decrypts and verifies the client’s identity.

118

Kerberos Version 5

Kerberos version 5 is specified in RFC 4120 and provides a number of improvements over version 4. To begin, we provide an overview of the changes from version 4 to version 5 and then look at the version 5 protocol.

Encryption system dependence:

• Version 4 uses only DES (Data Encryption Standard).
• Version 5 allows multiple encryption algorithms ciphertexts are tagged with encryption-type identifiers and keys have type and length fields.

Internet protocol dependence:

• Version 4 supports only IP addresses.
• Version 5 supports any type of network address (e.g., ISO), with address type and length tagging.

Message byte ordering:

• Version 4 uses system-specific byte ordering and tags messages manually.
• Version 5 uses ASN.1 and BER standards, ensuring consistent and unambiguous message formats.

Ticket lifetime:

• Version 4 uses an 8-bit lifetime field (max ≈ 21 hours).
• Version 5 allows explicit start and end times, supporting tickets with arbitrary lifetimes.

Authentication forwarding:

• Version 4 cannot forward credentials to another host.
• Version 5 allows forwardable credentials, enabling one server to access another on behalf of the client.

Interrealm authentication:

• Version 4 needs about N² trust relationships for N realms.
• Version 5 introduces a more efficient interrealm authentication method, reducing the number of trust relationships required.

119

There are technical deficiencies in the version 4 protocol itself.

The deficiencies are the following.

​

1. Double encryption: Tickets provided to clients are encrypted twice once with the secret key of the target server and then again with a secret key known to the client. The second encryption is not necessary and is computationally wasteful.
2. PCBC encryption: Encryption in version 4 makes use of a nonstandard mode of DES known as propagating cipher block chaining (PCBC).9 It has been demonstrated that this mode is vulnerable to an attack involving the interchange of ciphertext blocks [KOHL89]. PCBC was intended to provide an integrity check as part of the encryption operation. Version 5 provides explicit integrity mechanisms, allowing the standard CBC mode to be used for encryption. In particular, a checksum or hash code is attached to the message prior to encryption using CBC

​

120

3. Session keys: Each ticket includes a session key that is used by the client to encrypt the authenticator sent to the service associated with that ticket. In addition, the session key may subsequently be used by the client and the server to protect messages passed during that session. However, because the same ticket may be used repeatedly to gain service from a particular server, there is the risk that an opponent will replay messages from an old session to the client or the server. In version 5, it is possible for a client and server to negotiate a sub session key, which is to be used only for that one connection. A new access by the client would result in the use of a new sub session key.

​

4. Password attacks: Both versions are vulnerable to a password attack. The message from the AS to the client includes material encrypted with a key based on the client’s password.10 An opponent can capture this message and attempt to decrypt it by trying various passwords. If the result of a test decryption is of the proper form, then the opponent has discovered the client’s password and may subsequently use it to gain authentication credentials from Kerberos. This is the same type of password attack described, with the same kinds of countermeasures being applicable. Version 5 does provide a mechanism known as pre authentication, which should make password attacks more difficult, but it does not prevent them.

121

THE VERSION 5 AUTHENTICATION DIALOGUE

122

(a) Authentication Service Exchange

When a client wants to log in and start communication securely, it first needs a Ticket-Granting Ticket (TGT) from the Authentication Server (AS).

1. The client (C) sends a request to the Authentication Server (AS) containing its identity (IDC), the name of the realm (RealmC), the identity of the Ticket Granting Server (IDtgs), timestamps (Times), and a random value (Nonce1) for freshness.�C - AS : Options || IDC || RealmC || IDtgs || Times || Nonce1
2. The AS verifies the client’s identity and responds with a message encrypted using the client’s secret key (Kc). It includes a session key (Kc,tgs) for communication with the TGS, timestamp (Times), and the Ticket-Granting Ticket (Tickettgs).�AS - C : RealmC || IDC || Tickettgs || E(Kc, [Kc,tgs || IDtgs || Times || Nonce1 || RealmC || IDC])�Tickettgs = E(Ktgs, [Flags || Kc,tgs || RealmC || IDC || ADc || Times])�This step gives the client a TGT that will be used to request access to other services.

123

Ticket-Granting Service Exchange

Next, the client uses the TGT to obtain a Service-Granting Ticket (SGT) from the Ticket Granting Server (TGS).

The client (C) sends a request to the TGS, including the desired service’s ID (IDv), timestamp (Times), the TGT (Tickettgs), and an Authenticator (proof of identity encrypted with Kc,tgs).�C -TGS : Options || IDv || Times || Nonce2 || Tickettgs || Authenticatorc

3. The TGS checks the authenticity of the client using the authenticator and then replies with a service ticket (Ticketv) and a new session key (Kc,v) encrypted with Kc,tgs.�TGS - C : RealmC || IDC || Ticketv || E(Kc,tgs, [Kc,v || Times || Nonce2 || RealmC || IDv])�Ticketv = E(Kv, [Flags || Kc,v || RealmC || IDC || ADc || Times])�Now, the client has a ticket for the specific service it wants to use.

124

(c) Client/Server Authentication Exchange

Finally, the client authenticates itself to the target server (V) to access the desired service.

The client (C) sends a message to the server (V) that includes the Ticketv and a new Authenticator (encrypted using the session key Kc,v).�C -V : Options || Ticketv || Authenticator c

The server (V) verifies the ticket and authenticator. If valid, it confirms mutual authentication by sending back a response encrypted with the same session key (Kc,v) containing a timestamp (TS5) and an optional subkey or sequence number.�V - C : E(Kc,v, [TS5 || Subkey || Seq#])

125

15.4 REMOTE USER-AUTHENTICATION USING

ASYMMETRIC ENCRYPTION

REMOTE USER-AUTHENTICATION USING ASYMMETRIC ENCRYPTION

THERE ARE TWO TYPES OF AUTUSER-AUTHENTICATION USING

ASTHYMMETRIC ENCRYPTION

1. Timestamp-Based Mutual Authentication (DENN81)

Uses public-key encryption and timestamps to ensure message freshness.

Involves an Authentication Server (AS) that provides public-key certificates for users.

Steps:

A → AS: Sends its own and B’s identity (IDA, IDB).

AS → A: Sends back certificates for both A and B, signed with AS’s private key.

A → B: Sends both certificates and a session key Ks encrypted with A’s private key and B’s public key.

The session key (Ks) is chosen by A and never revealed to AS — enhancing security.

Timestamps prevent replay attacks (old messages being reused).

126

2. Nonce-Based Mutual Authentication (Woo & Lam, 1992)

• Replaces timestamps with nonces (Na, Nb) — random numbers used once to ensure freshness.
• Involves a Key Distribution Center (KDC) (sometimes called an Authentication Authority).
• Steps (simplified):
• A - KDC: Requests to communicate with B.
• KDC - A: Sends B’s public-key certificate.
• A - B: Sends Na (A’s nonce) and identity encrypted with B’s public key.
• B - KDC: Requests A’s certificate and asks for a session key, including A’s nonce.
• KDC - B: Sends A’s certificate and {Na, Ks, IDA, IDB} encrypted with its private key and B’s public key.
• B - A: Sends the triple {Na, Ks, IDA, IDB} and a new nonce Nb, all encrypted with A’s public key.
• A - B: Sends back Nb encrypted with the session key Ks to confirm possession of Ks.
• This ensures both A and B are mutually authenticated and share a fresh session key Ks.
• The revised version (WOO92b) added IDA inside encrypted fields to tightly bind the key to both identities — preventing impersonation.

127

6. B SA: E(PUa, [E(PRauth, [(Na }Ks }IDB)]) }Nb])

7. A SB: E(Ks, Nb)

One-Way Authentication

Confidentiality Only

• Message encrypted using a one-time secret key (Ks). Ks encrypted with B’s public key.� A - B: E(PUb, Ks) || E(Ks, M) .

Only B can read the message.

​

Authentication Only

A signs the message using A’s private key.� A - B: M || E(PRa, H(M))�Confirms sender’s identity, no confidentiality.

​

Authentication + Confidentiality

• A encrypts both message and signature with B’s public key.�A - B: E(PUb, [M || E(PRa, H(M))]) Ensures authenticity + secrecy.

​

With Certificate

• A also sends a digital certificate signed by the Authentication Server (AS).
• A - B: M || E(PRa, H(M)) || E(PRas, [T || IDa || PUa])
• Confirms A’s public key is valid and fresh.

128

WEB SECURITY CONSIDERATIONS

• Complex Software
• Web browsers, servers, and web applications are more secure and easy to use or develop.
• But underneath, they are very complex, which hides many possible security flaws.
• Even properly configured new systems have often been found vulnerable to attacks.
• Example: A web server (like Apache or IIS) may have a small coding mistake . Hackers find that bug and use it to run their own code on the server.
• Web Server as a Launching Pad
• Once a web server is hacked, attackers can use it to enter the entire internal network of an organization.
• This means sensitive internal data or connected systems can also be compromised.
• Example attack: SQL Injection — attackers put special code in the website’s search box to get private data from the database.
• Untrained Users
• Most web users are not security experts.
• They are unaware of the risks and don’t know how to protect themselves.
• This makes it easier for attackers to exploit them.
• Example: A user gets an email saying: “Your bank account is locked. Click here to unlock it.” The link opens a fake website that looks real . The user enters their password, which goes to the attacker.

​

129

Based on Type of Attack

​

Web Security Threats

130

A Comparison of Threats on the Web

131

Web Traffic Security Approaches

Web security can be added at three levels

• Network
• Transport
• Application�depending on how wide or specific the protection needs to be.

• Network Level (a) – Uses IPsec to secure all traffic (like HTTP, FTP, SMTP). Works below TCP, providing general security for all data.
• Transport Level (b) – Uses SSL/TLS between TCP and applications. Commonly used in HTTPS for secure web communication.
• Application Level (c) – Security is built directly into applications like S/MIME for email and Kerberos for authentication.

132

TRANSPORT LAYER SECURITY

• Introduction
• TLS architecture
• How TLS Works
• TLS Handshake Protocol
• Where TLS Is Used
• TLS Architecture / Components

TRANSPORT LAYER SECURITY

• Transport Layer Security (TLS) is a cryptographic protocol that provides secure communication over the Internet.
• It ensures that data sent between a client (like a web browser) and a server (like a website) is private, authenticated, and tamper-proof.
• TLS is the successor to SSL (Secure Sockets Layer) it is more secure and widely used today.

TLS Architecture

TLS is designed to make use of TCP to provide a reliable end-to-end secure service. TLS is not a single protocol but rather two layers of protocols.

133

TLS Record Protocol Services is the main part of TLS.

1. Confidentiality:
1. Uses symmetric encryption (AES, 3DES, RC4).
2. Key generated during the Handshake Protocol.
2. Message Integrity:
• Uses HMAC (MD5 or SHA-1) for data integrity and authentication.

(Sender Side)

1.Fragmentation: Split data into ≤16 KB blocks.

2. Compression (optional): Reduce data size.

3.Add MAC: Create HMAC over data using shared key.

4.Encrypt: Encrypt (data + MAC) using the session key.

5.Add Header: Add 5-byte header (type, version, length).

6.Send via TCP.

(reciver Side)

1.Use session key to decrypt ciphertext.�2.Verify MAC – Recompute and compare MAC for integrity.�3.Decompress – Restore original data (if compression used).� 4.Reassemble – Combine record fragments into full message.� 5.Deliver to Application – Pass verified plaintext to application layer.

134

Change Cipher Spec Protocol (TLS)

​

Purpose – To inform the other party that all future messages (encrypted, ) will use the newly negotiated cipher suite.

Message Format – Contains only one byte.

Alert Protocol (TLS)

​

Purpose – Used to convey warnings or errors related to the TLS session to the peer entity.

Message Structure – Each message is 2 bytes:

• 1st byte: Severity level warning (1) or fatal (2)
• 2nd byte: Alert description code

Encryption Alert messages are compressed and encrypted according to the current state.

Action on Fatal Alerts If level = fatal, TLS immediately terminates the connection.

• Ongoing connections may continue, but no new connections on the same session are allowed.

• Function:�It moves the new security settings (keys, algorithms) from the pending box to the active box so they start being used.
• Effect:�After this, all data is encrypted and protected using the new settings.
• Usage:�Both the client and server send this message during the handshake right before starting secure communication.

135

�Fatal Alerts

• unexpected message – Wrong type of message received.
• bad_record_mac – Incorrect MAC detected.
• Decompression failure – Error in decompression process.
• Handshake failure – Could not negotiate acceptable security parameters.
• Illegal parameter – Invalid or inconsistent field in a message.
• Decryption failed – Invalid ciphertext or incorrect padding.
• Record overflow – Record size exceeds allowed length.
• Unknown ca – Certificate Authority not recognized.
• Access denied – Certificate valid, but access not granted.
• Decode error – Message fields invalid or length incorrect.
• Export restriction – Violation of export rules on key length.
• Protocol version – Unsupported TLS version.
• Insufficient security – Server demands stronger ciphers than client supports.
• Internal error – Internal failure unrelated to peer.

Non-Fatal (Warning) Alerts

• Close notify – Sender will not send more messages; connection closing.
• Bad certificate – Certificate is corrupt or invalid.
• Unsupported certificate – Certificate type not supported.
• Certificate revoked – Certificate has been revoked.
• Certificate expired – Certificate has expired.
• Certificate unknown – Unspecified certificate issue.
• Decrypt error – Failure in cryptographic operation during handshake.
• User canceled – Handshake canceled by user.
• No renegotiation – Sender cannot perform renegotiation.

136

Handshake Protocol

• Phase 1 – Hello Messages:�Client and server exchange hello messages to agree on the TLS version, cipher suite, and random numbers.
• Phase 2 – Server Authentication:�Server sends its certificate to prove identity and shares key exchange info.
• Phase 3 – Client Authentication and Key Exchange:�Client (if asked) sends its certificate and key exchange message.�Both sides generate a shared secret key.
• Phase 4 – Finish:�Both send change_cipher_spec and finished messages.�Secure, encrypted communication starts.

137

SSL/TLS Attacks

Since SSL (1994) and TLS were introduced, many attacks have been discovered.�These attacks forced updates in the protocol and software to make them stronger.

�Main Categories of Attacks

1. Attacks on the Handshake Protocol

• The handshake is where client and server agree on keys and encryption.
• Attackers try to break this process to encryption or keys.
• Example:
• Bleichenbacher attack (1998) – used flaws in RSA encryption during handshake.

Protection - Use the latest TLS 1.3 version and modern key exchange methods like ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).�

2. Attacks on the Record / Application Data Protocol

• These attacks target the actual data being sent (like cookies, messages).
• Goal: Read or change the data secretly.
• Examples:
• BEAST (Browser Exploit Against SSL/TLS) (2011) – guessed method of the encrypted data.
• CRIME (2012) (Compression Ratio Info-leak Made Easy) – stole secret cookies using compression leaks.

Protection-

Turn off TLS compression.

Use latest TLS versions — TLS 1.2 or TLS 1.3.

138

3. Attacks on the PKI (Public Key Infrastructure)

• PKI checks and verifies digital certificates.
• Attackers exploit fake or weak certificates to pretend to be a real website.
• Example:
• Some SSL/TLS libraries didn’t properly check certificate validity hackers could bypass security.

​

�

​

​

4. Other Attacks (DoS and Implementation Bugs)

• Some attacks don’t target encryption directly.
• Example:
• DoS Attack (Denial of Service) – sends too many handshake requests so the server slows down or crashes.
• Heartbleed (2014) – a bug in OpenSSL leaked sensitive server memory.

​

​

​

​

PROTECTION -Always use updated libraries.

Enforce strict certificate validation.

139

What is TLS 1.3?

• TLS 1.3 is the new and improved version of TLS, developed in 2014 by the IETF.
• The main goal: Make TLS faster and more secure than older versions .

�

Major Improvements in TLS 1.3

Removes Old and Weak Features

• Many outdated or risky functions are removed to reduce attacks.�These include:

Compression – Can leak secrets , so it’s turned off.�Old ciphers – Not safe , so use AES-GCM (Advanced Encryption Standard – Galois/Counter Mode)�Static RSA/DH – Same RSA key used for all session. If key is stolen, all sessions break, so use ECDHE.�32-bit timestamp – provide the info of time, Useless and risky, so removed.�Change Cipher Spec – Made things complex, so simplified.�RC4 cipher – Over time, researchers found biases in its keystream, Weak and leaks data, so banned.�MD5 & SHA-224 – it produce same hash value means create collision . Not secure, so use SHA-256 or SHA-384.�

Uses Only Secure Key Exchange Methods

• Uses Diffie Hellman (DH) or Elliptic Curve Diffie–Hellman (ECDH).
• No more RSA for key exchange.
• This provides Forward Secrecy – even if one key is stolen, old sessions stay safe.

140

EMAIL THREATS & SECURITY

What is it about?

Email is used by everyone, but it is not always safe.�Hackers can use email to steal information, spread viruses, or trick users.

�

MAIN TYPES OF EMAIL THREATS

Authenticity Threats –�Someone pretends to be a real person or company.�Example: Fake email from “your bank” asking for passwords.

Integrity Threats –�The message is changed or edited by an attacker.�Example: Hacker changes the payment details in an email.

Confidentiality Threats –�Your private or secret emails are read by others.�Example: Hacker reads your confidential documents.

Availability Threats –�You cannot send or receive emails.�Example: Email server attacked by spam or overload.

141

WAYS TO SECURE EMAIL (Recommended by NIST SP 800-177)

​

1. STARTTLS

• Makes normal email (SMTP) secure using encryption (TLS).
• Keeps your message safe while traveling on the internet.98
• Protects from spying and fake servers.

​

2. S/MIME

• Secures the content of your email.
• Uses:
• Digital Signature to prove the sender is real.
• Encryption to keep the message secret.
• Ensures no one can read or change your mail.

​

3. DNSSEC (Domain Name System Security Extensions)

• Protects the address system (DNS) used to find mail servers.
• Makes sure emails go to the right destination, not to a hacker’s server.

​

4. DANE (DNS-based Authentication of Named Entities)

• Works with DNSSEC to check the real identity of the email server.
• Confirms that the server’s certificate is genuine.

142

This figure shows how different email security components (like STARTTLS, S/MIME, DNSSEC, DANE, etc.) work together to make email safe and trustworthy.

​

User/Client

The person sending or receiving the email (for example, using Gmail or Outlook).

The user’s mail program can use S/MIME to:

Encrypt the email message.

Add a digital signature to prove the sender’s identity.

�Mail Server (SMTP Server)

The server that sends and receives mail over the Internet.

It uses SMTP protocol (Simple Mail Transfer Protocol).

To make SMTP secure, the server uses STARTTLS . this encrypts the email while it’s being sent from one mail server to another.

�

​

143

DNS (Domain Name System)

Converts domain names like example.com into IP addresses.

But DNS can be attacked or faked, so we use:

DNSSEC → protects the DNS records (authentic and unmodified).

DANE → stores and verifies the public key (certificate) of the mail server in DNS using DNSSEC.

�

Recipient’s Mail Server

The mail reaches the receiver’s mail server securely (still using STARTTLS).

Then the receiver’s client uses S/MIME to:

Verify the sender’s digital signature.

Decrypt the message to read it safely.

144

The Whole Process

Sender writes an email� Adds digital signature + encryption using S/MIME.

Email sent to mail server�Server uses STARTTLS to encrypt the connection while sending to another server.

DNSSEC + DANE�Help verify that the mail is going to the real, trusted mail server (not a fake one).

Receiver’s mail server gets the email�Delivers it securely to the user.

Receiver opens the email�Uses S/MIME to check signature and decrypt message.

145

What is S/MIME

S/MIME stands for Secure / Multipurpose Internet Mail Extensions.�It is a security enhancement to the standard MIME format used for Internet email.

S/MIME protect ways :

​

• Authentication – verifies the sender’s identity.
• Message integrity – ensures the message is not altered.
• Non-repudiation – sender cannot deny sending the message.
• Privacy – encrypts the content of emails.

​

It is based on RSA Data Security technology and uses public key cryptography.

146

Operational Description

​

S/MIME provides for four message-related services:

1. Authentication,
2. Confidentiality
3. Authentication and Confidentiality
4. Email compatibility

147

1. Authentication in S/MIME (Using Digital Signature)

To make sure the message really came from the sender and was not changed during transmission.

​

How It Works

Sender creates a message.

1. The sender runs SHA-256 on the message this produces a message digest (hash) a short, fixed-size digital fingerprint of the message.
2. The message digest is then encrypted using the sender’s private RSA key this forms the digital signature.
3. The digital signature and sender’s public key information are attached to the message.
4. The receiver:
1. Decrypts the signature using the sender’s public key (to get the original hash).
2. Computes a new hash of the received message using SHA-256.
3. If both hashes match the message is authentic and unchanged.

​

Why It’s Secure

• RSA Only the sender’s private key can create that signature, proving who sent it.(authentication)
• SHA-256 ensures no one can change the message without changing its hash.(integrity)

�

148

Detached Signatures

Normally, the signature is attached to the message,�but S/MIME also supports detached signatures, which are stored separately.

​

Uses:

• To keep a signature log of messages sent/received.
• To check program files for virus infection later.

​

​

149

2. S/MIME Confidentiality

​

S/MIME (Secure/Multipurpose Internet Mail Extensions) ensures that email messages stay private and unreadable to anyone except the intended receiver.�It is using mainly AES (128-bit) for encryption in CBC mode.

​

How It Works

1. Message creation and key generation
1. The sender writes the mail.
2. Then generates a random 128-bit key (called Content Encryption Key – CEK)
3. This key will be used only for this one mail.
2. Message encryption
• The mail is encrypted using the content-encryption key (CEK) and a symmetric algorithm (AES).
3. Key encryption and attachment
• The content-encryption key itself is encrypted using RSA and the receiver’s public key.
• This encrypted key is attached to the mail.
4. Decryption at the receiver side
• The receiver uses their private key to decrypt and recover the content-encryption key.
5. Message decryption
• The receiver uses the recovered content-encryption key to decrypt the original message.

�

150

3. CONFIDENTIALITY AND AUTHENTICATION

​

Both confidentiality and encryption may be used for the same message.

​

1. Sign first then encrypt

The figure shows a sequence in which a signature is generated for the plaintext message and appended to the message. Then the plaintext message and signature are encrypted as a single block using symmetric encryption and the symmetric encryption key is encrypted using public-key encryption.

2. Encrypt first then sign

If encryption is done first, it is possible to verify a signature without exposing the message content. This can be useful in a context in which automatic signature verification is desired, as no private key material is required to verify a signature. However, in this case the recipient cannot determine any relationship between the signer and the unencrypted content of the message.

151

SENDER SIGNS, THEN ENCRYPT MESSAGE

​

1. Sender side (Alice sending secure email):

1. Alice writes the message (plaintext).
2. She applies SHA-256 to generate a message digest (hash value).
3. The hash is encrypted using her private RSA key this creates a digital signature.
4. The signature is attached to the message now we have “message + signature.”
5. Alice generates a random symmetric key (called content-encryption key).
6. The message + signature are encrypted using this symmetric key (for speed).
7. The symmetric key itself is encrypted using the receiver’s (Bob’s) public RSA key.
8. Alice sends the encrypted message and the encrypted symmetric key to Bob.

152

RECEIVER DECRYPTS MESSAGE,THEN VERYFY THE SENDER’S SIGNATURE

​

Receiver side (Bob receiving secure email):

1. Bob receives the encrypted message and encrypted symmetric key.
2. He uses his private RSA key to decrypt and recover the symmetric key.
3. Then he uses that symmetric key to decrypt the message and recover the plaintext + signature.
4. To verify authenticity:
1. Bob decrypts the digital signature using Alice’s public key (from her certificate).
2. He generates his own hash (SHA-256) of the received message.
3. If both hashes match message is authentic and unmodified.

153

4. S/MIME Email Compatibility (Base64 / 7-bit Encoding)

• Problem: Encrypted messages produce binary data (8-bit), but many email systems only handle ASCII text (7-bit).
• Solution: S/MIME converts binary data into printable ASCII using Base64 encoding.
• Every 3 bytes 4 ASCII characters.
• Even plain ASCII text is converted, which adds minor confidentiality.
• Rules:
• If only signature is used the message digest is encrypted with sender’s private key.
• If confidentiality is used the message + signature are encrypted with a one-time symmetric key.
• Base64 ensures the message can be safely sent
• .

154

S/MIME Message Content Types

It defines

How secure email content is formatted and

What operations (sign/encrypt/compress) can be applied to a message.

There are 4 main content types:

1.Data

• It is the original email content (text, attachment, etc.).
• No encryption or signature — just plain data.

2.Signed Data

• Used when a digital signature is added to the message.
• Ensures authenticity (who sent it) and integrity (not changed).

3.Enveloped Data

• Used for encryption of the message using a symmetric key (e.g., AES).
• Provides confidentiality — only the receiver can read it.

4.Compressed Data –

• Used to compress the message.
• Makes the email smaller and faster to send.

155

Approved Cryptographic Algorithms (S/MIME)

​

S/MIME defines which encryption and hashing algorithms can be used to ensure secure email communication . It also defines rules for how to choose the right algorithm.

​

Rules to Follow:

1. Known recipient preferences:
1. If the recipient has shared a list of preferred algorithms,� use the highest preferred one that the sender supports.
2. Based on previous messages:
• If the sender has earlier received encrypted messages from the recipient,� use the same algorithm as before.
3. Unknown capabilities (low risk):
• If the sender doesn’t know the recipient’s capabilities but is okay with risk,�use Triple DES (3DES).
4. Unknown capabilities (no risk wanted):
• If the sender wants to ensure decryptability ,�MUST use RC2 with 40-bit key (RC2/40) (a weak but widely supported algorithm).
5. Multiple recipients issue:
• If different recipients support different algorithms,� the sender must send separate messages for each group.
• Using the weaker algorithm for some recipients reduces overall message security.

156

S/MIME Messages

General Procedures for S/MIME Message Preparation

​

Before sending any secure email, S/MIME follows some general preparation steps to make the message ready for signing, encrypting, or both.

�

1. Identify the MIME Entity

• A MIME entity can be:
• The entire email message (except headers like “To”, “From”)
• Or a part of a multipart message (like an attachment or text part)

Example:�If you are sending a mail with text , image, each can be a MIME entity.

�

2. Convert the MIME Entity to Canonical Form

• Every MIME type has a canonical (standard) format.
• Canonicalization ensures the message looks exactly the same for both sender and receiver before applying security operations.

Example: Line endings, spaces, and encoding are standardized.�This avoids signature mismatch due to formatting differences.

157

3. Add Security Information

• Depending on what security is applied (signing, encryption, or both), extra information is added:
• Algorithm identifiers (RSA, SHA-256)
• Certificates (public-key info)
• Recipient information

This combined block = PKCS object�

4. Create PKCS (Public-Key Cryptography Standards) Object

• Once the message is prepared (plain text or MIME entity), S/MIME processes it to produce a PKCS (Public-Key Cryptography Standards) object . This object contains both the message content and security-related information (like algorithms, keys, or certificates).

Types of PKCS objects:

• Enveloped Data for encryption(Confidentiality)
• Signed Data for digital signature (authentication, integrity, or non-repudiation)
• certs-only for sending certificates (only certificates)

158

5. Encode the PKCS Object

• PKCS objects are binary (contain random bytes).
• To make them email-safe, S/MIME uses Base64 encoding (also called 7-bit encoding).

This ensures compatibility with systems that don’t handle 8-bit data.

�

6. Wrap in MIME Headers

• The Base64-encoded PKCS object is then wrapped inside MIME headers,
• MIME headers tell the email client how to interpret and handle the data.

for example:

smime-type=enveloped-data

name=smime.p7m

Content-Transfer-Encoding: base64

�

159

Enhanced Security Services (S/MIME)

RFC 2634 adds 4 extra security features to make S/MIME more secure and flexible:�

1. Signed Receipts:
1. Proves that the recipient received and read the message.
2. The recipient signs the original message + sender’s signature and sends it back.
3. Gives proof of delivery to the sender.�
2. Security Labels:
• Adds a label showing the sensitivity or access level of the message.
• Examples: Secret, Confidential, Restricted.
• Can control who is allowed to read or handle the message.�
3. Secure Mailing Lists:
• Helps when sending mail to many recipients.
• A Mail List Agent (MLA) handles encryption for all recipients.
• The sender only encrypts once using the MLA’s public key.�
4. Signing Certificates:
• Binds (links) the sender’s certificate to their digital signature.
• Ensures the signature really belongs to the correct person.

160

Pretty Good Privacy (PGP)

​

​

1. What it is:
1. PGP is another email security protocol similar to S/MIME.
2. Created by Phil Zimmermann in 1991.
3. It was free to use and became popular among individuals.

​

• Evolution:
• In 1996, version 5.x of PGP was standardized (RFC 1991).
• Later improved and renamed as OpenPGP.
• Defined in:
1. RFC 4880: OpenPGP Message Format
2. RFC 3156: MIME Security with OpenPGP

161

Difference Between S/MIME and OpenPGP

162

Module-5:

Addressed: CO5

Course: Cryptography & Network Security

Presented by: SHWETA SINGH

Department: Computer Science & Engineering

163

1. DomainKeys Identified Mail (DKIM)

Verifies email sender’s domain and message integrity using a digital signature stored in DNS.

�

2. IP Security (IPSec) Overview

Secures IP communication by providing authentication, integrity, confidentiality, and anti-replay at the network layer.

�

3. IP Security Policy

Rules that define which IP traffic needs protection and how (using AH or ESP).

�

4. Encapsulating Security Payload (ESP)

Provides encryption, integrity, and authentication for IP packets in transport or tunnel mode.

�

5. Combining Security Associations

Uses multiple SAs for stronger protection — e.g., AH + ESP or nested tunnels (for VPNs).

�

6. Internet Key Exchange (IKE)

Protocol that negotiates keys and security associations for IPSec in two phases (authentication + SA setup).

164

DOMAINKEYS IDENTIFIED MAILEYS IDENTIFIED MAIL

DKIM (DomainKeys Identified Mail)

​

1. Purpose
1. DKIM allows a domain to take responsibility for an email by attaching a cryptographic signature.
2. Helps verify that the email has not been altered in transit and is legitimately from the claimed domain.

​

• How It Works
• The sending domain signs the email using its private key.
• The signature is added to the email header.
• The recipient (or their email server) retrieves the public key from the sending domain’s DNS records.
• Using the public key, the recipient can verify the signature, confirming the message was indeed sent by the claimed domain and was not tampered with.

​

• Key Points
• DKIM is cryptographic: relies on asymmetric cryptography .
• It does not encrypt the email, only ensures authenticity and integrity.
• Widely supported by major email providers like Gmail, Yahoo!, ISPs, and government organizations.

​

• Standard
• DKIM is defined as an Internet Standard in RFC 6376.

165

Email Threats

RFC (Request for Comments):�A document series published by the Internet Engineering Task Force (IETF) that defines internet standards, protocols, and technical guidelines.

RFC 4686 describes the threats being addressed by DKIM in terms of the

• Characteristics
• Capabilities
• Location

CHARACTERISTICS

RFC 4686 characterizes the range of attackers on a spectrum of three levels of threat.

1. At the low end are attackers who simply want to send email that a recipient does not want to receive. The attacker can use one of a number of commercially available tools that allow the sender to falsify the origin address of messages.

This makes it difficult for the receiver to filter spam on the basis of originating address or domain.

​

2. At the next level are professional senders of bulk spam mail. These attackers often operate as commercial enterprises and send messages on behalf of third parties. They employ more comprehensive tools for attack, including Mail Transfer Agents (MTAs) and registered domains and networks of compromised computers (zombies), to send messages and (in some cases) to harvest addresses to which to send.

​

3. The most sophisticated and financially motivated senders of messages are those who stand to receive substantial financial benefit, such as from an email-based fraud scheme. These attackers can be expected to employ all of the above mechanisms and additionally may attack the Internet infrastructure itself, including DNS cache-poisoning attacks and IP routing attacks.

166

CAPABILITIES

RFC 4686 lists the following as capabilities that an attacker might have.

• Attackers can send emails from many places on the Internet.�This means they can use lots of computers or mail servers around the world to send fake or bad emails. For example, a hacker might use hundreds of infected computers to send spam.
• They can make fake email headers.�Attackers can write anything in the “From” or “Reply-To” lines. So, an email may look like it came from your bank or teacher, but it’s actually fake.
• They can sign emails for domains they control.�If the attacker owns some website or domain, they can sign their messages using that domain name. This makes the message look more real, even though it’s not from a trusted source.
• They can send a huge number of emails.�Attackers might flood mail servers with many emails to slow them down or cause them to crash. This is called a denial-of-service (DoS) attack.
• They can resend old signed messages.�Suppose a company sent a real signed message once. The attacker can copy that old message and send it again later to confuse people.
• They can change the envelope information.�The “envelope” is what mail servers use to send and deliver messages. Attackers can make the envelope say one thing while the visible “From” address says something else.

167

• They can use a hacked computer to send mail.�If an attacker infects a computer in a company, they can use it to send fake emails that look like they come from real employees.
• They can play with Internet routing.�Attackers might change how emails travel on the Internet. This can make the email look like it came from a certain country or make messages go through attacker-controlled systems.
• They can trick the DNS system.�DNS helps find where emails should go. Attackers can change or fake DNS information (for example, by cache poisoning) to send mail to the wrong server or to show fake security keys.
• They can listen to network traffic.�If an email connection is not secure, attackers can spy on it. On a public Wi-Fi, for example, they might see your login details or read your messages.

168

LOCATION

Location here tells us where the attacker is inside or outside the trusted parts of an organization’s network.

Inside the Organization (Trusted Area)

This is the safe zone of the email system your own organization or email provider (like Gmail’s or Outlook’s internal network).

Inside this zone, emails are sent using authenticated systems meaning, users log in, and the system knows exactly who sent what.

So, DKIM is not needed much here because other security checks (like login, passwords, or SMTP authentication) are already in place.

Example : When a company employee sends mail from their official Gmail account (user@company.com) the Gmail system already knows who the user is.�No need for DKIM to verify them again.

​

• DKIM mainly protects against outside attackers, not people inside the organization.
• Outside the trusted network, anyone can send emails to anyone attackers use this to send fake mails.
• They may send emails:
• Without DKIM signatures
• With wrong signatures
• Or from fake domains that look real

DKIM helps check if the email really comes from the domain it claims.

Example:�A fake mail from info@bank.com DKIM can verify if it’s truly from the real bank’s domain or not.

169

​

DKIM Strategy

Purpose

DKIM is a system that allows an email domain (like gmail.com or yahoo.com) to take responsibility for a message it sends.�It helps the receiver verify whether the message really came from that domain and wasn’t changed during transmission.

​

• Email Creation:�A user writes and sends an email using an email client (MUA – Mail User Agent).
• Message Submission:�The email goes to the Mail Submission Agent (MSA) within the sender’s administrative domain (like Gmail is controlled by google).
• Signing the Message:�The email provider (domain) signs the message using its private key.
• The signature covers the message content and some RFC 5322 headers (like “From,” “To,” “Subject”).
• This signature is then added to the message as a DKIM-Signature header.
• Transmission Across Internet:�The signed email passes through various Mail Transfer Agents (MTAs) across the Internet until it reaches the recipient’s domain.

​

170

• Receiving and Verification:�At the destination, the Mail Delivery Agent (MDA) retrieves the sender’s public key from the DNS record of the sending domain.
• Signature Verification:�The MDA uses the public key to verify the DKIM signature.
• If valid The email is confirmed to come from the claimed domain and is delivered.
• If invalid The email may be marked as suspicious or rejected.
• Algorithms Used:
• Default: RSA with SHA-256
• Optional: RSA with SHA-1 (for backward compatibility)

171

The motivation for DKIM is based on the following reasoning:

• S/MIME depends on both the sending and receiving users employing S/MIME. For almost all users, the bulk of incoming mail does not use S/MIME, and the bulk of the mail the user wants to send is to recipients not using S/MIME.

​

• S/MIME signs only the message content. Thus, RFC 5322 header information concerning origin can be compromised.

​

• DKIM is not implemented in client programs (MUAs) and is therefore transparent to the user; the user need not take any action.

​

• DKIM applies to all mail from cooperating domains.

​

• DKIM allows good senders to prove that they did send a particular message and to prevent forgers from masquerading as good senders.

172

• An RFC 5322 email message is created by the sender.
• The originating or relaying ADMD signs the message using its private key and includes the SDID (Signing Domain Identifier).
• The signed message is transmitted through the Internet to the recipient’s domain.
• The receiving or delivering ADMD checks whether the message is signed.
• If the message is signed, the public key is retrieved from DNS and the signature is verified.
• If the verification passes, the message is authenticated and goes through further assessment.
• If the verification fails, the message is checked against the sender’s signing practices.

173

• Unsigned messages are also checked for signing practices to decide how to handle them.
• The system uses remote sender practices and local information on sender behavior to evaluate trust.
• Reputation or accreditation data may be used to assess the credibility of the sender’s domain.
• The message filtering engine uses the verification result, sender practices, and reputation data to decide whether to accept, reject, or flag the message.

174

IP SECURITY OVERVIEW

• In 1994, the Internet Architecture Board (IAB) issued RFC 1636 titled “Security in the Internet Architecture.”
• This document reviewed the weaknesses of the Internet and suggested how to make it secure for the future .

• End-to-end user communications through authentication and encryption.
• The IAB recommended adding authentication and encryption as essential features in IPv6.
• These features were also made compatible with IPv4, allowing early implementation.
• This led to the development of IPsec (Internet Protocol Security).
• IPsec provides authentication, data integrity, and encryption for secure communication.

IP SECURITY OVERVIEWCURITY OVERVIEW

175

Applications of Ipsec

​

1. Secure branch office connectivity over the Internet
1. Allows companies to create secure Virtual Private Networks (VPNs) over the Internet or public WANs. IPsec creates an encrypted tunnel (VPN) between routers at both sites.
2. Reduces costs and simplifies network management by minimizing the need for private leased lines.
2. Secure remote access over the Internet
• Enables remote users to securely connect to the company network through an Internet Service Provider (ISP).
• Helps reduce toll charges for traveling employees and telecommuters.
3. Extranet and intranet connectivity with partners
• Provides secure communication between organizations and business partners.
• Ensures authentication, confidentiality, and secure key exchange.
4. Enhancing electronic commerce security
• Strengthens the security of web and e-commerce applications. Protect online transactions .
• Encrypts and authenticates all administrator-designated traffic, adding another layer of protection

176

An IPSec VPN Scenario

​

The figure illustrates how IPsec (Internet Protocol Security) operates in tunnel mode to create a secure Virtual Private Network (VPN) between two or more geographically separated networks over an untrusted network such as the Internet. IPsec provides authentication, integrity, and confidentiality at the network layer (Layer 3) of the OSI model, making it a fundamental protocol for secure IP communications.

An organization has multiple LANs (Local Area Networks) for example:

One in Bangalore ,One in Delhi, One in Mumbai

Each LAN has normal users, servers, and printers communicating internally using regular, unsecured IP

problem

When these LANs need to communicate with each other across the Internet or a public WAN:

• The data travels through untrusted networks.
• Without protection, outsiders could intercept, modify, or spoof the data.

177

The IPsec Solution

At each LAN’s boundary (the point where it connects to the Internet or WAN), there is a security gateway, such as:

• A router
• A firewall

These devices implement the IPsec protocols.

​

How it works

Inside the LAN:

• Normal IP packets flow freely unencrypted between local hosts.�When data leaves the LAN:
• The packet reaches the IPsec-enabled router/firewall.
• The device encrypts the packet (using ESP in IPsec).
• It may also authenticate it (using AH or ESP with authentication).
• The encrypted packet is sent over the Internet or WAN to the destination site.

At the receiving LAN:

1. The destination site’s IPsec device receives the packet.
2. It decrypts and verifies it.
3. The original IP packet is delivered into the LAN as normal traffic.

​

178

Benefits of IPsec

Some of the benefits of IPsec:

​

■ When IPsec is implemented in a firewall or router, it provides strong security that can be applied to all traffic crossing the perimeter. Traffic within a company or workgroup does not incur the overhead of security-related processing.

​

■IPsec in a firewall is resistant to bypass if all traffic from the outside must use IP and the firewall is the only means of entrance from the Internet into the organization.

​

■ IPsec is below the transport layer (TCP, UDP) and so is transparent to applications. There is no need to change software on a user or server system when IPsec is implemented in the firewall or router. Even if IPsec is implemented in

end systems, upper-layer software, including applications, is not affected.

■ IPsec can be transparent to end users. There is no need to train users on security mechanisms, issue keying material on a per-user basis, or revoke keying material when users leave the organization.

​

■ IPsec can provide security for individual users if needed. This is useful for offsite workers and for setting up a secure virtual subnetwork within an organization for sensitive applications.

179

Routing Applications

Routing means finding the best path for data packets to travel from one network to another .

Routers use routing protocols to exchange information about which paths exist in a network.

In addition to supporting end users and protecting premises systems and networks, IPsec can play a vital role in the routing architecture required for internetworking.

​

lists the following examples of the use of IPsec.

IPsec can assure that

■ A router advertisement (a new router advertises its presence) comes from an authorized router.

​

■ A neighbor advertisement (a router seeks to establish or maintain a neighbor relationship with a router in another routing domain) comes from an authorized router.

​

■ A redirect message comes from the router to which the initial IP packet was sent.

​

■ A routing update protocol about the network path. Without such security measures, an opponent can disrupt communications or divert some traffic.

180

IPsec Documents

IPsec (Internet Protocol Security) covers three main functional areas:

1. Authentication – verifying that data comes from a trusted source.
2. Confidentiality – encrypting data so that outsiders can’t read it.
3. Key Management – securely exchanging and managing encryption keys.

Categories of IPsec Documents

1. Architecture

• Explains how IPsec works — its basic design, rules, and concepts.
• It defines how packets are secured, how Security Associations (SAs) are built, and what services (encryption, authentication) are offered.

Example:�It explains when to use ESP or AH, how to manage security policies, and how routers or firewalls apply IPsec.

2. Authentication Header (AH)

• AH is a special header added to the IP packet.
• It provides:

Authentication – verifies sender identity

Integrity – ensures data not modified

No encryption (so data is still visible).

• It’s now deprecated (old) because ESP can also do authentication.

Example:�If Router A sends a message to Router B, AH ensures it really came from A and wasn’t changed — but the message content is not encrypted.

181

3. Encapsulating Security Payload (ESP)

• ESP adds encryption and optional authentication.
• It hides (encrypts) the data and ensures it’s not modified.

Example:�When a user connects to a company VPN, ESP encrypts all traffic so no one can read it while it travels across the internet.

4. Internet Key Exchange (IKE)

• IKE is the protocol used to create and manage keys for IPsec communication.
• It securely exchanges encryption keys between two systems (using Diffie-Hellman, for example).

Example:�Before Host A and Host B can start an IPsec session, they use IKE to:

1. Authenticate each other.
2. Agree on which encryption and hash algorithms to use.
3. Generate secret keys.

5. Cryptographic Algorithms

• These are separate documents that define which algorithms IPsec can use for:
• Encryption (like AES, 3DES)
• Authentication (like HMAC-SHA256)
• Random number generation (PRF)
• Key exchange (Diffie-Hellman)

Example:�RFCs define exactly how AES or HMAC should be used in IPsec — so all systems follow the same standard.

182

Transport Mode and Tunnel Mode

​

Transport Mode and Tunnel Mode, both are modes of IPsec they define how IPsec protects data during transmission

1. Transport Mode

What it does

• Protects only the payload (data) part of the IP packet.
• The IP header remains unchanged routers can still see where the packet is going.

So, it’s used for end-to-end communication between two individual hosts.

​

Working Steps

SA (Security Association) set of security parameters created between Host A and B .

Both agree on encryption (e.g., AES) and authentication methods and key exchange method.

When Host A sends a packet payload encrypted.

Host B receives and decrypts the payload.

Data travels safely, but IP addresses are visible to routers.

​

183

2. TUNNEL MODE

​

What it does

• Protects the entire IP packet (both header + payload).
• Adds a new outer IP header so routers only see the outer addresses.
• Commonly used between gateways/firewalls (like VPNs).
• Used for network-to-network or host-to-network communication

​

Working Steps

1. Gateways A & B create a secure IPsec tunnel (IKE).
2. Packets from internal hosts are encapsulated (wrapped).
3. The whole packet is encrypted and sent through the tunnel.
4. Receiving gateway decrypts and forwards the inner packet to its local host.

184

Difference table between Transport Mode and Tunnel Mode in IPsec

​

185

IP SECURITY POLICYIP SECURITY POLICY

IPsec uses a security policy to decide how to handle each IP packet

• DISCARD policy: Packet is dropped.
• BYPASS policy: Packet is sent without IPsec processing.
• PROTECT policy: Packet needs IPsec protection.

​

• This policy is managed using two databases:

​

1. SPD (Security Policy Database): Decides what to do with each packet protect, bypass, or discard.
2. SAD (Security Association Database): Stores details of active secure connections keys, algorithms, and SPI.

​

186

SA Identification

SAs are like rules that tell IPsec how to secure traffic between two points . A security association is uniquely identified by three parameters.

Each SA is uniquely identified by three things

​

■ Security Parameters Index (SPI): A 32-bit number inside the IPsec header (ESP/AH) that identifies which SA to use. The SPI is carried in AH and ESP headers to enable the receiving system to select the SA under which a received packet will be processed.

​

■ IP Destination Address: This is the address of the destination endpoint of the SA, which may be an end-user system or a network system such as a firewall or router.

​

■ Security Protocol Identifier: This field from the outer IP header indicates whether the association is an AH or ESP security association.

187

Security Association Database

In each IPsec implementation, there is a nominal Security Association Database that defines the parameters associated with each SA.

A security association is normally defined by the following parameters in an SAD entry.

Security Parameter Index (SPI):

A 32-bit value that identifies the SA.

Used to construct outbound packets and map inbound traffic to the correct SA.

Sequence Number Counter:

A 32-bit counter for generating sequence numbers in AH or ESP headers. how many packets have been sent and ordering.

Sequence Counter Overflow:

Flag indicating whether an overflow should trigger an event and stop packet transmission. It creates an alert when packets reaches out of it’s limit.

Anti-Replay Window:

Helps detect and prevent replay attacks on incoming packets.

AH Information (if using AH):

Authentication algorithm, keys, key lifetimes, and related parameters.

ESP Information (if using ESP):

Encryption/authentication algorithm, keys, initialization vectors, key lifetimes, and related parameters.

Lifetime of the SA:

Time or data limit after which the SA must be replaced or terminated.

IPsec Protocol Mode:

Tunnel, Transport, or wildcard mode.

Path MTU:

Maximum packet size that can be transmit with outspliting unit observed on the path and aging information.

​

188

Security Policy Database (SPD)

​

The SPD is a database that determines which IP traffic should use IPsec and which does not need protection. Each entry in the SPD specifies a subset of traffic and maps it to a Security Association (SA).

​

How SPD Works

For each outgoing IP packet, the following steps occur:

1. Match Packet to SPD Entry:
1. Check packet fields (selectors) against the SPD to find a matching entry.
2. This entry points to one or more SAs or may allow traffic to bypass IPsec.

Selectors in an SPD Entry

Selectors are fields used to filter traffic and decide which SA to apply:

Selectors are like filters that help SPD decide which rule applies to this packet:

Source IP (who is sending)

Destination IP (who is receiving)

Protocol (TCP/UDP)

Port numbers

User name if system uses per-user IPsec

SPD matches the packet details with one of its rules.

2. Select the SA:

• If a matching entry is found, the corresponding SA and its SPI are used.

3. Apply IPsec Processing:

• Perform AH or ESP operations as specified by the SA.

��

189

IP Traffic Processing

​

IPsec works on each IP packet individually, both when sending and receiving data.

​

Outbound packets (sending):�Each packet is checked and processed by IPsec before it leaves the device. This ensures the packet is encrypted, authenticated, or both, depending on the security policy.

​

Inbound packets (receiving):�Each packet is checked and processed by IPsec after it arrives, before delivering the data to the next layer (like TCP or UDP). This ensures the packet is legitimate and, if encrypted, is properly decrypted.

190

Outbound Packet Processing in IPsec

When a device sends data (like TCP or UDP):

1. Form the packet:�The data from a higher layer is packaged into an IP packet with a header and payload.
2. Check the Security Policy Database (SPD):�IPsec looks for a policy that matches this packet.
3. If no match:�The packet is discarded, and an error message may be generated.
4. If a match is found:
1. DISCARD policy: Packet is dropped.
2. BYPASS policy: Packet is sent without IPsec processing.
3. PROTECT policy: Packet needs IPsec protection.
5. Check the Security Association Database (SAD):
• If no SA exists for this packet, the Internet Key Exchange (IKE) creates a new SA with the necessary keys.
• If an SA exists, it defines the IPsec processing.
6. Apply security:
• The packet is encrypted, authenticated, or both.
• The chosen mode can be transport (protect only payload) or tunnel (protect entire packet).
7. Transmit:�The processed packet is sent out to the network.

191

Inbound Packet Processing in IPsec

When a device receives a packet from a n/w:

1. Check the packet type:�IPsec looks at the IP Protocol (IPv4) or Next Header (IPv6) field to see if the packet is secured (ESP or AH) or unsecured.
2. Unsecured packet:
1. IPsec checks the SPD for a matching policy.
2. BYPASS policy: The IP header is removed, and the packet body is delivered to the higher layer (like TCP).
3. PROTECT or DISCARD policy, or no match: The packet is discarded.
3. Secured packet (with ESP or AH):
• IPsec checks the SAD for a matching Security Association.
• No match: The packet is discarded.
• Match found IPsec applies the required authentication and/or decryption, removes the IP header, and passes the payload to the higher layer (like TCP or UDP).

192

1. ESP (Encapsulating Security Payload)

ESP (Encapsulating Security Payload) is a part of IPsec that protects data sent over the Internet.

1. It provides these security services:
1. Confidentiality: Keeps the data secret by encrypting it.
2. Authentication: Confirms who sent the data.
3. Integrity: Ensures the data was not changed during transmission.
4. Anti-replay: Blocks attackers from resending old packets.
5. Traffic flow confidentiality: Hides the real pattern or size of communication.
2. The type of protection ESP gives depends on what options are chosen when the Security Association (SA) is set up.
3. ESP works with many encryption and authentication algorithms, including advanced ones like GCM (Galois/Counter Mode), which does both encryption and authentication together.

193

ESP Format

This is top-level format of an ESP packet. It contains the following fields.

■ Security Parameters Index (32 bits): Identifies a security association.

■ Sequence Number (32 bits): A 32-bit counter for generating sequence numbers in AH or ESP headers. how many packets have been sent and ordering.Helps prevent replay attacks.

■ Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption.

■ Padding (0–255 bytes): The purpose of this field is discussed later.

■ Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.

■ Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first header in that payload (e.g., an extension header in IPv6, or an upper-layer protocol such as TCP).

■ Integrity Check Value (variable): A variable-length field (must be an integral number of 32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field.

194

Combined Mode Algorithms in ESP

​

When a combined mode algorithm (like AES-GCM (Galois/Counter Mode) or ChaCha20-Poly1305) is used, it handles both encryption and integrity checking together.

1. Decryption and Integrity Check:�The algorithm returns:
1. The decrypted plaintext, and
2. A pass/fail result to show whether the integrity check succeeded.
2. ICV Omission:�Normally, ESP adds an Integrity Check Value (ICV) at the end of the packet.�But when a combined mode algorithm is used, the ICV can be omitted because the algorithm already ensures data integrity internally.
3. ICV Inside Payload:�If integrity is required but ICV is omitted, the combined mode algorithm includes an equivalent integrity check mechanism inside the payload data.
4. Additional Fields:�Two extra fields may appear in the ESP payload:
• Initialization Value (IV) or Nonce — Used when required by the encryption algorithm. Ensures that even if you send the same message twice, the ciphertext looks different.
• Traffic Flow Confidentiality (TFC) Padding — Added (in tunnel mode) after payload data to hide actual data length and provide extra privacy.

195

Encryption and Authentication Algorithms in ESP

ESP encrypts the following parts of the packet:

• Payload Data
• Padding
• Next Header
2. Use of Initialization Vector (IV):
• Some encryption algorithms need a random starting value to make each encryption unique and synchronization data, like an Initialization Vector (IV) even data is sent twice.
• The IV is placed at the start of the Payload Data field.
• The IV is not encrypted but is still considered part of the ciphertext.
3. ICV (Integrity Check Value):
• The ICV field is optional used only when the integrity service is selected.
• It may come from:
1. A separate integrity algorithm, or
2. A combined mode algorithm that includes ICV internally.
4. Order of Operations:
• Encryption is done first, then ICV is calculated.
• This helps the receiver to :
• Quickly reject replayed or fake packets before decryption.
• Reduce DoS impact (since no need to decrypt invalid data).
• Allow parallel processing, i.e., decryption and integrity checking can happen at the same time.
5. Security Note:
• Because the ICV itself is not encrypted, it must be generated using a keyed integrity algorithm (like HMAC-SHA).

196

Padding

​

The Padding field serves several purposes:

​

■ If an encryption algorithm requires the plaintext to be a multiple of some number of bytes (e.g., the multiple of a single block for a block cipher), the Padding field is used to expand the plaintext (consisting of the Payload Data, Padding, Pad Length, and Next Header fields) to the required length.

​

■ The ESP format requires that the Pad Length and Next Header fields be right aligned within a 32-bit word. Equivalently, the ciphertext must be an integer multiple of 32 bits. The Padding field is used to assure this alignment.

​

■ Additional padding may be added to provide partial traffic-flow confidentiality

by concealing the actual length of the payload.

197

Anti-Replay Service in IPsec (ESP)

1. What is a Replay Attack?

• A replay attack happens when an attacker captures a valid, authenticated IP packet and sends it again later.
• This can cause service disruption or undesired effects e.g., repeating transactions or commands.

�

2. Purpose of Anti-Replay Service:

• To detect and block duplicate packets.
• Ensures each packet is unique and used only once.

�

3. Sequence Number by Sender:

• When a new Security Association (SA) is created, the sender starts a sequence number counter at 0.
• Every time a packet is sent:
• The sender increases the counter by 1.
• Puts the new number in the Sequence Number field.
• The first packet has sequence number 1.

�

198

​

4. Sequence Number Limit:

• If anti-replay is enabled (default ON):
• The sender cannot let the number go beyond 2³² - 1.
• If it reaches that limit → the SA must be terminated and a new one established with a new key.
• This avoids having duplicate sequence numbers.

�

5. Receiver’s Window Mechanism:

• Because IP is not reliable (packets can come late or out of order),�IPsec uses a “sliding window” method to track which packets have already been received.

199

Transport and Tunnel Modes (ESP)

1. Transport Mode:

• Used for end-to-end communication (host to host).
• Only the payload (data) is encrypted.
• Original IP header remains visible.
• Each host handles encryption/decryption.

Example: Secure link between two computers.

�

2. Tunnel Mode:

• Used for network-to-network communication (VPN).
• Entire IP packet (header + data) is encrypted and put inside a new IP packet.
• Gateways (firewalls/routers) handle encryption/decryption.

Example: Secure VPN between two offices.

200

Transport Mode ESP (Encapsulating Security Payload)

Meaning:�Used to provide encryption and optional authentication for data sent directly between two hosts (end-to-end).

�

How It Works :

1. Encryption at Source:
1. ESP header is placed before the transport layer (like TCP/UDP).
2. ESP trailer (Padding, Pad Length, Next Header) is added after the data.
3. The transport-layer segment + ESP trailer are encrypted.
4. Extension header provide security, routing ,fragmentation details.
5. If authentication is used, ESP adds Authentication Data at the end.
2. Routing:
• The encrypted packet is sent normally.
• Routers only read the IP header, not the encrypted data.
3. Decryption at Destination:
• Destination reads the SPI (Security Parameter Index) in ESP header.
• It uses the correct key to decrypt and recover the original transport data.

�

201

202

What It Protects:

• Encrypts transport-layer data (like TCP segment).
• Provides confidentiality and optional authentication.

�

Advantages:

Protects data without changing the original IP header.�Can secure any application (no need to add encryption in each app).

�

Drawback:

Vulnerable to traffic analysis attackers can still see who is communicating with whom, even if the content is hidden.

203

Tunnel Mode ESP

Tunnel Mode encrypts the entire original IP packet (both header and data).�Then, a new outer IP header is added for routing.�This mode is mainly used for VPNs or communication between gateways/firewalls.

�

How It Works

1. Create Inner Packet:

• The source forms a complete IP packet (original IP header + data).
• This is called the inner IP packet.

2. Encrypt Entire Packet:

• ESP header is added before the inner packet.
• The entire inner IP packet (header + data) is encrypted.
• contains SPI and Sequence Number.

3. Add Outer IP Header:

• A new IP header (outer header) is added in front of the encrypted data.
• This new header has:
1. Source: Sending gateway/firewall.
2. Destination: Receiving gateway/firewall.
• It contains gateway source and destination, hiding real endpoints.

204

205

4. Send Over Internet:

• Intermediate routers read only the outer header for routing.
• The inner header (true source/destination) stays hidden prevents traffic analysis.

5. At Destination Gateway:

• The gateway uses the SPI in ESP header to find the correct SA.
• Decrypts the inner packet and forwards it into the internal network.

6.Deliver to Final Host:

• The inner IP packet is now sent to the final internal destination.
• Used between:
• Two security gateways (firewalls/VPN routers), or
• A gateway and an external host.
• Commonly used in VPNs to securely connect two private networks across the Internet.

� Advantages

Hides both the payload and original IP addresses (protects against traffic analysis).�Reduces the encryption burden on individual hosts.�Simplifies key management (keys shared between gateways only).

206

207

What is a Security Association (SA)

A Security Association (SA) is like a security tunnel or agreement between two devices.�It tells:

• Which protocol to use (AH or ESP),
• Which keys,
• Which encryption or authentication algorithms.

One SA can use only one protocol either AH or ESP, not both.

COMBINING SECURITY ASSOCIATIONSCOMBINING SECURITY ASSOCIATIONS

​

Why do we combine them

Sometimes, one SA is not enough.�For example:

• You want encryption (ESP) and authentication (AH).
• Or you need protection between two firewalls and between the end hosts themselves.

So, we use more than one SA together for the same data.�That is called a Security Association Bundle.

SA Bundle = More than one SA working together for one data flow.

208

How to combine SA

Two Ways to Combine

There are two main ways SAs can be combined:

�Security associations may be combined into bundles in two ways:

■ Transport adjacency: Refers to applying more than one security protocol to the same IP packet without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the processing is performed at one IPsec instance: the (ultimate) destination.

​

■ Iterated tunneling: Refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path.

209

Authentication Plus Confidentiality

Encryption and authentication can be combined to transmit an IP packet that has both confidentiality and authentication between hosts.

We look at several Approaches .

​

ESP WITH AUTHENTICATION OPTION

​

In this approach, the user first applies ESP to the data to be protected and then appends the authentication data field.

There are two subcases:

​

■ Transport mode ESP: Authentication and encryption apply to the IP payload delivered to the host, but the IP header is not protected.

​

■ Tunnel mode ESP: Authentication applies to the entire IP packet delivered to the outer IP destination address (e.g., a firewall), and authentication is performed at that destination. The entire inner IP packet is protected by the privacy mechanism for delivery to the inner IP destination.

For both cases, authentication applies to the ciphertext rather than the plaintext

210

Transport Adjacency

Two IPsec protocols are applied together on the same IP packet in transport mode

1. Two IPsec protocols are used together:
1. ESP (Encapsulating Security Payload) for encryption
2. AH (Authentication Header) for authentication

​

• ESP is applied first it encrypts the payload (data).

​

• AH is applied next it authenticates the whole packet, including
• the IP header (except changing fields)
• the ESP part (which contains encrypted data)

​

• Benefit:
• Gives both confidentiality (ESP) and authentication (AH).
• AH also protects source and destination IP addresses.

​

• Disadvantage:
• More processing overhead because two Security Associations (SAs) are needed.

211

Transport–Tunnel Bundle

​

Two IPsec protocols are used together:

• AH (Authentication Header) for authentication
• ESP (Encapsulating Security Payload) for encryption

AH is applied first it authenticates the original IP packet (IP header + data).�ESP is applied next in tunnel mode; it encrypts the entire authenticated packet and adds a new outer IP header.

​

Benefit:

• Authentication data is protected by encryption.
• Both confidentiality (ESP) and authentication (AH) are achieved.
• Receiver can store and verify authentication information later.

​

Disadvantage:

• Requires two Security Associations (SAs).
• More processing and overhead.

212

Basic Combinations of Security Associations

​

The IPsec architecture defines

​

1. Four main cases (or ways) in which Security Associations (SAs) can be combined between hosts and gateways.
2. Each SA can be either AH (Authentication Header) or ESP (Encapsulating Security Payload), and can work in Transport Mode or Tunnel Mode depending on the situation.

213

214

Case 1 – Host-to-Host Security

​

• Security is provided directly between two end systems (hosts).
• Both hosts implement IPsec.
• Each host must share secret keys to communicate securely.
• Possible combinations:�a. AH in Transport Mode�b. ESP in Transport Mode�c. ESP followed by AH in Transport Mode (ESP inside AH)�d. Any of the above inside a Tunnel Mode (AH or ESP)
• Supports:
• Authentication
• Encryption
• Authentication before or after encryption