9
Network Security
1. Explain the working principle of the Kerberos protocol.
Ans.: Kerberos is an authentication protocol that has been designed to be used in an open distributed environment, where the users at workstations request for the services on the servers distributed throughout the network. It basically provides a centralized authentication server that is responsible for authenticating users to servers and servers to users. Its name has been derived from Greek mythology after the name of a three-headed dog that guarded the gates of Hades. Kerberos has become very popular as it can also act as a KDC in addition to being an authentication protocol. It was originally developed as a part of Project Athena at the MIT. Several versions of Kerberos have evolved. However, the most commonly used version of Kerberos is version 4. The Kerberos protocol has four components, namely, client workstation, authentication server (AS), ticket-granting server (TGS) and real server.
Client workstation is an entity that wants to access services from a server.
Authentication server (AS) acts as a KDC in the Kerberos protocol. It is responsible for the verification of the identity of users during login. To get verified, the users first need to register themselves with the AS. Each registered user is assigned a unique ID and a password. All the IDs and their corresponding passwords are stored in a centralized database of AS. In addition to verifying the users, it also issues a session key to the requesting user, which is to be used between the user and the TGS, and sends a ticket for the TGS. AS also shares a unique secret key with each server, and hence, all the servers also need to register themselves with AS.
Ticket-granting server (TGS) is responsible for issuing tickets for establishing connection with the real server. It also issues the session key, which is to be used between the user and the real server. Once a user has got verified by AS, he or she can contact TGS any number of times to obtain the tickets for different real servers.
Real server provides the required services to the user. Here, the user uses its own process (client process) to access the server process using a client-server program (e.g. FTP).
The working of Kerberos is shown in Figure 9.1. To understand how the Kerberos protocol operates, consider a user A who wants to access the services of a real server B. The user A can access the processes running on B by performing the following steps.
1. The user A logs in to the workstation by entering his or her user ID (say, IDA). The workstation then sends IDA in plaintext to AS.
Figure 9.1 Kerberos Protocol
2. In response, the AS creates a message that includes two items: a randomly generated session key KA−TGS and the ticket for TGS, which is encrypted with the secret key shared between the AS and TGS (KAS−TGS). This whole message is encrypted with the symmetric key of A (KA). The session key KA−TGS is used by the user to contact the TGS. Now, this encrypted message is sent to A.
3. On receiving the message, A's workstation asks him or her for the password. When A enters the correct password, the workstation generates the symmetric key (KA) by applying an appropriate algorithm (generally a hash function) on the password. The password is then immediately destroyed, so that it cannot be stolen by anyone. The symmetric key KA is now used to decrypt the received message. Once the message is decrypted, the ticket for TGS and the session key KA−TGS are extracted. Since the ticket is encrypted with the symmetric key of TGS, only TGS can open it. A now sends a message to TGS containing the ticket received from AS, the name of the real server (B) and a timestamp T encrypted with the session key KA−TGS. This timestamp prevents replay attacks from any other user.
4. The TGS now sends two tickets each for A and B. Both these tickets contain the session key (KA−B) to be used between A and B. A's ticket is encrypted with the secret key (KA−TGS) shared between A and TGS, while the ticket for B is encrypted with the secret key (KTGS−B) shared between TGS and B. This mechanism provides security for the whole process. No other user can extract KA−B, as he or she does not know KA−TGS or KTGS−B. Moreover, step 3 cannot be replayed, since an unauthorized user cannot replace the timestamp with a new one (as he or she does not know KA−TGS).
5. A now sends B's ticket with a timestamp encrypted with KA−B.
6. B acknowledges the receipt of the ticket by adding 1 to the timestamp. It also encrypts the message with KAB and sends it to A.
Now, suppose A wishes to receive services from different servers, then it only has to repeat steps 3 to 6. The first two steps involve the verification of A's identity, which remains same for all the servers. Thus, steps 1 and 2 need not be repeated.
2. Discuss the basic requirements for Kerberos.
Ans.: There are four basic requirements that have been defined for Kerberos. These requirements are as follows:
Security: Kerberos should be secure enough to prevent eavesdroppers from obtaining any kind of information that is necessary to impersonate a user.
Reliability: Kerberos should be highly reliable and should support distributed server architecture so that, in case of failure of one system, some other system can act as a backup.
Transparency: Kerberos should be transparent, such that the user is not able to know that authentication is taking place; the user should only be required to enter his or her password.
Scalability: Kerberos should support a modular, distributed architecture, so that it can support a large number of clients and servers.
3. Define the terms ‘Kerberos realm’ and ‘Kerberos principal’.
Ans.: A typical Kerberos environment consists of an authentication server (or a Kerberos server), a number of clients all registered with the authentication server and a number of application servers that provide several services. The Kerberos server must maintain a centralized database that contains the user IDs and hashed passwords of all the users registered with the Kerberos server. It must also share a unique secret key with each application server. All servers need to get registered with the Kerberos server. Such an environment is called Kerberos realm. It is basically a single administrative domain.
The computer system where the Kerberos database is stored (referred to as Kerberos master computer system) should be kept in a physically secure room. The person having the Kerberos master password is only authorized to modify the contents of the Kerberos database. Though several read-only copies of this database can be kept on other Kerberos computer systems, changes can only be made on the master computer system. If there exist several Kerberos realms, then they must share secret keys and trust among themselves.
Kerberos principal is a unique identity to which Kerberos can assign tickets. In other words, all the services or the users known to a Kerberos system are referred to as Kerberos principals. Each Kerberos principal is identified by its principal name. A Kerberos principal has the following form:
primary[/instance]@REALM
Principal is divided into three parts: the primary (service or user name), the instance, and the realm.
Primary: This is the first part of the principal. For a user, the primary is the username and, for a host, the primary is the word host.
Instance: This is an optional string that qualifies the primary, and is separated from the primary by a slash (/). In case of a user, the instance is generally NULL; however, in some cases, it can have some value (e.g. admin).
Realm: This is the last component of the principal, and is basically the Kerberos realm. It is generally separated from the rest of the principal by the ‘@’ symbol. In most cases, it is your domain name and must be specified in upper-case letters.
For example, consider the following principals:
[email protected] robert/[email protected]
In the first principal, robert is primary, instance is NULL and ATHENA.MIT.EDU is realm. In the second principal, robert is primary, admin is instance and ATHENA.MIT.EDU is realm.
4. Discuss the steps involved in inter-realm communication in Kerberos.
Ans.: In a system that crosses organizational boundaries, it is not feasible for all users to be registered with a single AS; rather, multiple ASs will exist with each AS responsible for the registration and authentication of the users and servers within a single realm. In case two users (say, A and B) of
different realms want to communicate with each other, they need to obtain service tickets to access resources in foreign realms. In order to access such services, these steps are followed:
1. The user A contacts the AS of their realm asking for a ticket that will be used with the TGS of the foreign realm. If both the realms share keys and have established a trusted relationship between them, the corresponding AS of A's realm delivers the requested ticket to A.
2. In case A's realm does not share keys with the foreign realm, the AS of A's realm will provide a ticket for an intermediary foreign realm that may be sharing the keys with the target realm.
3. The client can use this ‘intermediary ticket’ to communicate with the AS of the intermediary foreign realm, which will either follow step 2, or it will issue a ticket that can be used with the AS of the target realm (in case it shares keys with the target realm).
4. The client uses this ticket to obtain the service ticket from the TGS of the foreign realm.
5. The user can now use this service ticket to obtain the services of the desired server.
5. How is the encryption key generated from the password in Kerberos?
Ans.: In Kerberos, the user can enter a password of any length; however, the password is restricted to contain only those characters that can be represented in a 7-bit ASCII format. This password is used to generate the symmetric key of the user that is to be used for decrypting the messages received from AS. The steps involved in password-to-key transformation are as follows:
1. The user enters his or her password in the form of a character string (say, s).
2. The character string s is converted into a bit string (say, b) in such a way that the first character of s is stored in the first seven bits of b, the second character is stored in next seven bits and so on, as shown in Figure 9.2(a). That is:
b[0]represents bit 0 ofs[0]…b[6]represents bit 6 ofs[0]b[7]represents bit 0 ofs[1]…b[13]represents bit 6 ofs[1]…b[7i+j]represents bitjofs[i]where, 0 <=j<= 6
3. The bits in the bit string b are aligned in a ‘fanfold’ manner, such that the bits 0 to 55 form the first row, then the bit 56 is placed below the bit 55, bit 57 is placed below 54, bit 58 is placed below 53 and so on, as shown in Figure 9.2(b).
4. A bitwise XOR operation is performed to compact the bit string to 56 bits. For example, if the bit string is of length 60, then
b[55] = b[55] 
b[56]
b[54] = b[54] b[57]
b[53] = b[53] b[58]
b[52] = b[52] b[59]
This creates a 56-bit DES key [see Figure 9.2(b)]. Note that steps 3 and 4 are performed to compact the bit string.
5. The 56-bit string is then expanded to a 64-bit input key K. For this, the 56-bit key is divided into 7-bit blocks (total 8 blocks), and then each 7-bit block is mapped to a corresponding block of 8 bits, thus creating a 64-bit key.
Figure 9.2 Password-to-key transformation in Kerberos
6. The password supplied by the user is encrypted with the key K using the cipher block chaining (CBC) mode of DES [see Figure 9.2(c)]. This process results in a 64-bit block, referred to as CBC checksum, which becomes the encryption key (say, Kpw) associated with the user's password.
6. Explain the differences between Kerberos version 4 and Kerberos version 5.
Ans.: Though Kerberos version 4 is most commonly used, it suffers from some environmental shortcomings and technical deficiencies. Kerberos version 5 attempts to overcome these problems. The differences between Kerberos versions 4 and 5 based on the environmental shortcomings are listed in Table 9.1.
| Issue | Kerberos 4 | Kerberos 5 |
|---|---|---|
| Encryption system dependence | Requires the use of DES algorithm. | Any encryption algorithm can be used. To make this possible, an encryption type identifier is attached with the ciphertext. |
| Internet protocol dependence | Uses only IP addresses, and no other address can be used in it. | Allows the use of any network address, such as the ISO network address. This is possible due to the reason that the network addresses are labelled with type and length. |
| Message byte ordering | The byte ordering in the message is not uniform. The sender can include either the least significant byte or the most significant byte in the lowest address. That is, the sender has the freedom of choosing his or her own byte ordering. | The byte ordering in the message is uniform. All the message structures are defined using two standards, namely, Abstract Syntax Notation One (ASN.1) and Basic Encoding Rules (BER), thereby providing unambiguous byte ordering. |
| Ticket lifetime | The lifetime of the ticket is limited. The lifetime values are encoded in 8-bit quantities, in units of 5 minutes. Thus, the maximum possible lifetime is 28 * 5 = 1280 minutes or 21 hours, approximately. This time limit may not be sufficient for some applications, such as a long-running simulation. | The tickets can have arbitrary lifetime values. To allow this, an explicit start and end time is included with each ticket. |
| Authentication forwarding | The credentials issued to one client cannot be forwarded to some other host or some other client. | The credentials issued to one client can be forwarded to another. This would allow a client to access a server, and that server to access another server on behalf of the client's credentials. This technique is termed as transitive cross-realm authentication. For example, a print server can access the file server to retrieve the file to be printed on behalf of the client. |
| Inter-realm authentication | The number of Kerberos-to-Kerberos relationships required for interoperability among N realms is calculated as N2 , where N is the number of realms. |
A lesser number of relationships are required. |
In addition to the environmental shortcomings mentioned in the preceding text, version 4 suffers from some technical deficiencies. Version 5 is intended to address these deficiencies. These deficiencies are listed in Table 9.2.
| Issue | Kerberos 4 | Kerberos 5 |
|---|---|---|
| PCBC encryption | Uses a nonstandard mode of the DES algorithm known as propagating cipher block chaining (PCBC) for encryption. The PCBC was supposed to provide an integrity check as part of the encryption operation; however it is found to be prone to an attack that involves the interchange of ciphertext blocks. | Uses the standard cipher block chaining (CBC) mode for encryption. It provides explicit integrity mechanisms such as attaching hash code or checksum to the message before encryption using CBC. |
| Session keys | The session key included in each ticket serves two purposes. First, it is used by the client to encrypt the authenticator sent to the server associated with that ticket. Second, it can be used to encrypt the messages between a client and a server. Since the same ticket is used more than once for accessing a particular server, it leads to the possibility of a replay attack by a third party. | Allows a client and a server to negotiate a sub-session key, which is to be used only for the current session. Thus, if the client wishes to access the server again, he or she would require a new sub-session key. |
| Password attacks | Does not provide a secured mechanism for preventing password attacks. Whenever AS sends a message to the client, it is encrypted with the key based on the client's password. This message can be captured by an opponent who may then attempt to decrypt it by trying various passwords. If the opponent chooses the right mechanism to acquire the password, then he or she can use it to acquire the authentication credentials from Kerberos. | Though version 5 does not completely prevent the password attacks, it provides a preauthentication mechanism that makes the password attacks more difficult. |
7. Define the terms forwardable, renewable and postdatable tickets.
Ans.: Kerberos version 5 supports the use of forwardable, renewable and postdatable tickets.
Forwardable ticket: This ticket can be used by the user to get a new ticket on behalf of the current credentials. This allows the user to get validated on other machines also. However, the user has to use a different IP address.
Renewable ticket: As the name suggests, this ticket can be renewed by asking the KDC to issue a new ticket with an extended lifetime. Note that a ticket can only be renewed before the expiration of its time limit. It is similar to renewing an insurance policy or a credit card before the validity is expired.
Postdatable ticket: This ticket is similar to a postdated cheque, which bears a starting time as some time in the future. Thus, the ticket is initially invalid. A postdatable ticket can only be used after getting it validated from the KDC during its valid lifetime.
8. Explain the X.509 authentication service and its certificates.
Ans.: X.509 was designed by ITU-T to describe the public-key certificates in a structured way. It is a part of the X.500 series of recommendations that define a directory service. A directory is basically a server or a set of servers distributed over a network that maintains a database of information about the users, such as mappings from user names to network addresses. X.509 provides authentication services to its users through the X.500 directory, which may act as the repository of public-key certificates associated with each user. Each certificate contains the public key of the user and is signed by the private key of the trusted certification authority (CA). It may be noted that only the CA can create the user certificates and place them in the directory. The directory server itself is not responsible for creating public keys or certificates; it simply acts as a warehouse of certificates for the users.
X.509 also defines a set of alternative authentication protocols based on the use of public-key certificates. The format of the certificate and the authentication protocols defined in X.509 are used in several contexts such as IP Security, S/MIME, SSL/TLS and SET, and hence it is considered to be an important standard.
The first version of X.509 was issued in 1988. Then, in 1993, its second version came out, to address some of the security concerns. A third version was released in 1995, which was revised in 2000. X.509 makes uses of the ASN.1 (Abstract Syntax Notation One) protocol, which defines the general format of the X.509 certificate with several fields, as shown in Figure 9.3. The description of these fields is as follows:
Version number: This field differentiates among the various versions of the certificate format. That is, the version of X.509 is specified in this field. The first version number was 0, and the current version (third version) is 2.
Figure 9.3 X.509 Certificate Format
Serial number: This field contains an integer value assigned to each certificate. This value is unique within the issuing CA.
Signature algorithm ID: This field specifies the algorithm used by CA to sign the certificate, together with any associated parameters.
Issuer name: This field specifies the name of the CA that has created and signed the certificate. The name is usually specified as a hierarchy of strings that include the name of the country, state, organization, department and so on.
Validity period: This field specifies the lifetime of the certificate. It includes the earliest time and latest time; the certificate is invalid before the earliest time and after the latest time.
Subject name: This field specifies the entity to which this certificate refers. That is, this certificate certifies the public key of the user who is holding the corresponding private key. This field is also specified as a hierarchy of strings; one of the strings is called the common name, which is the actual name of the user.
Subject public key: This field specifies the main content of the certificate, which is the public key. It also specifies the corresponding public-key algorithm and its associated parameters.
Issuer unique identifier: This is an optional field that specifies the unique identifier of the authority issuing the certificate. This field allows having the same value in the issuer name field of two different certificates, provided they have different values in the issuer unique identifier field.
Subject unique identifier: This is also an optional field, which specifies the unique identifier of the subject to which the certificate is issued. This field allows having the same value in the subject name field of two different certificates, provided they have different values in the subject unique identifier field.
Extensions: This field is used by the issuers to add more private information to the certificate. The extensions were added in the third version of X.509. This is also an optional field.
Signature: This field is divided into three sections as discussed in the following:
The first section includes all the other fields in the certificate.
The second section contains the digest of the first section, which is encrypted with the private key of CA.
The third section includes the algorithm identifier that has been used to create the second section.
9. Explain the terms certificate renewable and certificate revocation with respect to X.509. Also, discuss how the format of the X.509 certificate is different from that of the certificate revocation list?
Ans.: The X.509 certificates have a validity associated with them. If everything goes smoothly, then the certificates can be renewed by the CA. A new certificate is issued before the validity of the old one expires. This process is known as certificate renewal. However, sometimes, the certificate has to be revoked before the validity of the certificate expires. This is known as certificate revocation. The certificates can be revoked due to several reasons. Some of them are as follows:
The private key of the user might have been compromised.
The private key of the CA that can verify the certificates might have been compromised. In this case, the CA must revoke all unexpired certificates.
The certificate authority is no longer willing to issue a certificate to the user.
The certificate revocation is implemented by periodically issuing a Certificate Revocation List (CRL), which contains all the revoked certificates that have not expired till the issue date of the CRL. A typical format of CRL is shown in Figure 9.4. It contains many fields, some of which are the same as in the X.509 certificate. The fields common to both X.509 certificates and CRL are signature algorithm ID, issuer name and signature. The fields that are new in CRL are as follows:
Figure 9.4 Certificate Revocation List Format
This update date: This field defines the issue date of CRL.
Next update date: This field specifies the date when the list will be issued next.
Revoked certificate: This is a repeated list of all the certificates that are not expired and have been revoked. Each list is divided into two sections, namely, user certificate serial number and revocation date.
10. What do you understand by directory authentication service?
Ans.: The directory authentication service is used when two entities wish to communicate with each other, and each of them needs to authenticate the other. That is, both the sender and receiver need to ensure that the other communicating party is the one that it claims to be. There are two types of directory authentication services, namely, peer entity authentication and data origin authentication.
Peer entity authentication: This authentication service enables the user to verify the identity of a peer entity involved in the communication process. It prevents an entity from masquerading as another entity or an unauthorized replay of a previously established connection. The peer entity service can be used during the establishment phase or occasionally during the data transfer phase of a connection. Note that there must be an association between the two parties for peer entity authentication.
Data origin authentication: This authentication service enables the recipient to verify that the message has not been tampered with in transit (data integrity) and that it has originated from the expected sender (authenticity). That is, it is used to verify the original source of a received message. The data origin authentication services allow the receiver to verify the identity of the message as belonging to the original message creator even if the message has passed through one or more intermediaries before arriving at the receiver. Note that unlike peer entity authentication, no association between the sender and receiver is required. Thus, this type of service is suitable for e-mail service in which there is initially no communication between the entities.
11. Discuss the authentication procedures of X.509.
Ans.: X.509 includes three authentication procedures, namely, one-way authentication, two-way authentication and three-way authentication. These authentication procedures make use of public-key signatures and can be used across a variety of applications. While working with these procedures, it is assumed that two communicating nodes know each other's public key. These procedures are discussed in the following.
One-way authentication: This involves a single transfer of information from user A to user B [see Figure 9.5(a)]. This information is transferred in order to confirm that the message is generated by user A, and that the message is intended for user B and has not been altered or replayed by any intruder. Thus, this procedure only verifies the identity of A. At a minimum, the message includes the following and is signed with the private key of A.
Timestamp (tA): This indicates the time when the message was generated, along with the validity or expiration time of the message.
Nonce (rA): This is a random number used to protect the message from replay attacks. The value of nonce must be unique during the validation period. This is done so that B can discard any new messages having the same nonce value.
Identity of B (IDB): This is included so that the user B can access the X.509 directory and be sure that the message is intended for him or her only.
Signed data (sgnData): This is the information that is actually conveyed between the two users. This information is included within the scope of the signature, thus ensuring its authenticity and integrity.
Encrypted data (EBPUB[KAB]): This includes the session key KAB, encrypted with B's public key (BPUB). This key is used after the authentication process gets over.
Two-way authentication: This involves a two-way transfer of information; first from user A to B, and then from user B to A. This two-way transfer allows both users to verify each other's identity. First, A sends a message containing the same fields as described in one-way authentication to B. Then, B replies to A with a message including tB, rB, IDA, rA, sgnData and optionally EAPUB[KAB], and the message is signed by B [see Figure 9.5(b)]. The inclusion of nonce rA in the reply message ensures that the reply is valid and has come from B, whereas rB protects the information being transferred by B from replay attacks.
Figure 9.5 Authentication Procedures
Three-way authentication: This involves the three-way transfer of information from A to B. In this procedure, a third message from A to B is included, in addition to two messages that are the same as described in two-way authentication. The third message contains a signed copy of the nonce rB signed by A [see Figure 9.5(c)]. Since both the nonces are echoed back by the other side, each user can check the returned nonce to detect replay attacks. This approach is useful when synchronized clocks are not available.
12. Explain the services of PGP.
Ans.: PGP (stands for pretty good privacy) is a simple protocol that was invented by Phil Zimmermann to provide confidentiality, authentication and integrity services for electronic mail and other file storage applications. PGP offers various services, which are discussed as follows:
Authentication only
PGP provides digital signature service for authentication. Suppose user A wants to send a message to B, then, to achieve authentication, these steps are followed.
1. A creates a message, and applies the SHA-1 algorithm to find the 160-bit hash code of the message.
2. The generated hash code is encrypted with RSA using A's private key. The resultant encrypted code is then added to the beginning of the message.
3. On receiving the message, B decrypts the message with RSA using A's public key and extracts the hash code.
4. A new hash code for the message is also generated at B's end, and it is compared with the decrypted hash code. If both are same, the message is accepted as authentic; otherwise it is rejected.
Due to the use of both SHA-1 and RSA, the digital signature scheme becomes effective. The use of RSA assures the receiver that the signature can only be generated by the owner of the private key, whereas SHA-1 ensures that no intruder can create a new message with the same hash code, and hence, the signature of the original message. Alternatively, signatures can also be generated using DSS/SHA-1.
Confidentiality only
The confidentiality service is provided by encrypting the messages that are to be transmitted, or to be stored on the local server. The three commonly used symmetric encryption algorithms are CAST-128, IDEA and 3DES. Note that, in PGP, each session key is used only once, and hence, a new key needs to be generated each time a message is to be transmitted. The key is generated as a random 128-bit number, bound to the message and transmitted with it. To provide protection for the key, it is encrypted with the receiver's public key. The steps to achieve confidentiality are as follows.
1. A creates a message and a random 128-bit number. This number is used as a session key K for this message.
2. A encrypts the message using the CAST-128 (or IDEA or 3DES) encryption algorithm with the session key K.
3. The session key K is encrypted with B's public key using RSA (or ElGamal). The encrypted key is then added to the beginning of the message.
4. On receiving the message, B uses its private key to decrypt and recover the session key K.
5. The message is finally decrypted using the session key K.
Confidentiality and Authentication
In some cases, both the confidentiality and authentication services are required for the same message. In such situations, the following sequence is used:
1. The sender A first signs the plaintext message using his or her private key. The signature is then added to the beginning of the message.
2. The signature and the plaintext message together are encrypted with the session key using CAST-128, IDEA or the 3DES algorithm.
3. The session key is encrypted with B's public key using the RSA or ElGamal algorithm.
4. On receiving the message, B uses its private key to decrypt and recover the session key K.
5. B then decrypts with session key K to recover the plaintext message and signature.
6. To verify the signature, a new hash code for the message is computed at B's end and compared with the decrypted hash code. If both are the same, the message is accepted as authentic; otherwise, it is rejected.
Compression
By default, PGP compresses the messages using the ZIP compression algorithm after applying the signature, however, before encrypting them. This saves space for e-mail transmission as well as for file storage. There are two reasons for signing an uncompressed message, which are discussed in the following:
Generally, the signed messages along with signatures need to be stored for future verification. If an uncompressed message is signed, then the message and the signature can be stored together and retrieved when verification is required. However, if a compressed message is signed, then either the compressed message needs to be stored or the message needs to be recompressed when verification is required.
Even if the user is ready to recompress the message dynamically for verification, then also PGP's compression algorithm presents certain problems. The main problem is that the algorithm is nondeterministic in nature; that is, the various implementations of the algorithm produce different compressed forms at different times. This is because they achieve different tradeoffs in running speed versus compression ratio. However, all the implementations are interoperable as any version of the algorithm can correctly decompress the output of any other version. If the signature is created after compression, it would restrict all PGP implementations to use the same version of the compression algorithm.
Encrypting the message after encryption strengthens the cryptographic security. Since, the compressed message contains less redundancy than the plaintext (or uncompressed) message, it would be more difficult to perform cryptanalysis.
E-mail Compatibility
When PGP is used, the encryption has to be done in at least a portion of the message to be transmitted. These encrypted blocks are made of a stream of arbitrary 8-bit octets that are not supported by many e-mail systems as they permit the use of only ASCII text. To make the encrypted blocks compatible with e-mail systems, PGP converts the 8-bit octets into a stream of printable ASCII characters. For this, it uses the radix-64 conversion scheme. In this scheme, each group of three octets is converted into four ASCII characters. A CRC is also added at the end of the block for detecting any transmission errors.
One problem with this conversion scheme is that it expands a message by 33%. Thus, the message needs to be more compressed so that it compensates for the radix-64 expansion. Another main disadvantage of the radix-64 format is that it blindly performs the conversion regardless of the content, even if the input is ASCII text. Thus, when a message containing ASCII text is signed but not encrypted will be converted by radix-64, the output becomes unreadable for the normal user. To overcome this, PGP can be configured to convert only the signature part to radix-64 format, thus making the message readable by normal users without using PGP. The signature would still have to be verified using PGP.
Segmentation and Reassembly
E-mail facilities generally impose a restriction on the maximum length of the message to be transmitted (generally 50,000 octets). Thus, to send a message having length longer than maximum specified, it has to be broken down into smaller parts, and each part needs to be mailed individually. To achieve this, PGP uses segmentation and reassembly functions. If a PGP message is too large, then it is broken down into smaller segments that are of standard e-mail message size. The segmentation is performed after all other processing on the message has been done (even after radix-64 conversion); otherwise, all the processing needs to be done on each segment. Thus, only the first segment contains the session key component and signature component of the message. The segmented message is reassembled at the receiver's end, removing the e-mail headers from each segment. It must be noted that reassembling is performed before applying radix-64 conversion, decryption and decompression.
13. Discuss the steps that are followed for the transmission and reception of PGP messages.
Ans.: The PGP messages are transmitted from the sender to receiver using the following steps:
1. If signature is required, the hash code of the uncompressed plaintext message is created and encrypted using the sender's private key.
2. The plaintext message plus the signature are compressed using the ZIP compression algorithm.
3. The compressed plaintext message plus compressed signature (if present) are encrypted with a randomly generated session key to provide confidentiality. The session key is then encrypted with the recipient's public key and is added to the beginning of the message.
4. The entire block is converted to radix-64 format.
On receiving the PGP message, the receiver follows the reverse process, as described in the following:
1. The entire block is first converted back to binary format.
2. The recipient recovers the session key using his or her private key, and then decrypts the message with the session key.
3. The decrypted message is then decompressed.
4. If the message is signed, the receiver needs to verify the signature. For this, he or she computes a new hash code and compares it with the received hash code. If they match, the message is accepted; otherwise, it is rejected.
14. What are key rings in PGP?
Ans.: When a sender needs to send messages to many people, then he or she requires the key rings. In this case, a sender needs to have two sets of rings—one is a ring of private/public keys, and other is a ring of public keys. The ring of private/public keys includes different key pairs of public and private keys that are owned by the sender, and the ring of public keys includes public key of each user with whom the sender wants to communicate. There are two reasons for keeping various pairs of private/public keys, which are discussed as follows:
The sender might wish to change his private/public key pair from time to time for more secured communication.
The sender may want to use different key pairs for different community of people such as friends, colleagues, etc.
Note that the private/public key ring is stored only on the machine of the user who owns the key pairs, so that it is accessible to that user only.
15. How does PGP use the concept of trust and legitimacy?
Ans.: Like other protocols, PGP also makes use of certificates to authenticate public keys. However, the process is completely different. In PGP, no certification authority (CA) is involved; rather, anyone in the ring can sign a certificate for others in the ring. Thus, PGP certificates are not issued by any certification authority; rather, the users themselves are responsible for issuing certificates to each other. The entire working of PGP is based on the introducer trust, the certificate trust and the key legitimacy.
Introducer (or producer) trust levels: Since there is no certification authority that the PGP users can trust, the users have to maintain a level of trust among each other. The introducer trust level
indicates the trustworthiness of the introducer (the user who issues certificates to other users). PGP defines three levels of trusts, namely, none, partial, and full. For example, user A can have full trust on user B, partial trust on users C and D and no trust on user E. It must be noted that there is no way in PGP to determine the trustworthiness of the introducer; it entirely depends on the user who makes an assessment of the trust to be assigned to the introducer.
Certificate trust levels: When a user A receives a certificate signed by the introducer, it assigns a level of trust to this certificate. Thus, the certificate trust level indicates the extent to which a PGP user can trust the certificate issued by an introducer. It is generally the same as that of the introducer trust level. For example, suppose B issues a certificate for E, and A receives that certificate, then A assigns a full level of trust to this certificate, as A fully trusts B. However, if A receives a certificate from E, then A can either discard this certificate or assign a zero level of trust to it, as A has no trust on E.
Key legitimacy: This indicates the level of legitimacy of public key of a user. That is, the extent to which one can trust that a particular key is a valid key for a particular user. PGP defines certain weighted trust levels to determine the level of legitimacy of the key for the user. The higher the weight, the stronger the binding of the user ID to his or her key. For example, a weight of 0 indicates a nontrusted certificate, weight of ½ indicates a partially trusted certificate and, finally, a weight of 1 indicates a fully trusted certificate. For example, A can use E's public key because B has issued a certificate (with a trust level of 1) for E. However, A cannot use any certificate issued by E, as for A, E has a trust level of none. Thus, it is clear from our example that the legitimacy of the public key of a particular user does not depend on the trust level of that user; rather, it depends on the trust level of the introducer who has issued this certificate.
16. What is the structure of the key rings of PGP? Explain how messages are exchanged with the help of key rings.
Ans.: The structure of a private/public key ring can be represented as a table where each row represents one of the public/private key pairs owned by the user. Each row contains various entries, which are as follows:
Timestamp: This field specifies the date and time when that particular private/public key pair was generated.
Key ID: This field contains the least significant 64 bits of the public key for this entry. Since the user can have multiple public keys, this field helps in uniquely identifying each key.
Public key: This field contains the public key portion of the pair.
Private key: This is an encrypted field that contains the private key portion of the pair.
User ID: This field generally contains the e-mail address of the user. However, in some cases, the user may wish to associate different names with each pair or to reuse the same user ID.
The public key ring contains the public keys of the other users who are known to this user. The fields of the public-key ring are explained as follows:
Timestamp: This field contains the date and time when the entry was generated.
Key ID: This field contains the least significant 64 bits of the public key for this entry.
Public key: This field contains the public key for this entry.
Producer trust: This field specifies the introducer level of trust. It can take one of the three values: none, partial or full.
Certificate(s): This field contains one or more certificates signed by other users for this user.
Certificate Trust(s): This field contains the trust level of certificates. If A has signed a certificate for B, then the value in the certificate trust field for B is equal to the value in the producer trust field for A.
Key legitimacy: This field stores a value that is computed on the basis of the value contained in the certificate trust field and the predefined weight for each certificate trust.
User ID: This field specifies the owner of this public key, and generally contains the e-mail address of the user. There may be more than one user IDs associated with a single public key.
The general structure of private/public ring and public ring is shown in Figure 9.6. Both the private/public and public ring can be indexed by either User ID or Key ID.
Figure 9.6 General Structure of Private/public and Public Ring
To understand the working of key rings, let us suppose that user A wants to send a message to many users and also wants to receive messages from the others. For this, A would have many pairs of private/public keys belonging to him or her and various public keys belonging to the other people with whom he or she wants to communicate. Now, when A wants to send a message to another person in the community, it needs to perform the following steps.
1. A signs the message digest using its private key. The private key of A is retrieved from the private/public key ring using the User ID field as an index.
2. A encrypts a newly created session key using the desired recipient's public key. The public key is retrieved from the public key ring using the User ID of the intended recipient as an index.
3. A encrypts the message and the signed digest using the newly created session key.
When A receives a message from another person in the community, it needs to perform the following steps.
1. A decrypts the session key using its private key. The private key of A is retrieved from the private/public key ring using the Key ID field included in the signature key component as an index.
2. A decrypts the message and the digest using the session key.
3. A verifies the digest using its public key. To retrieve the public key, the Key ID field included in the signature key component is used as an index.
17. What is the need of the Key ID field in the private/public and public key rings in PGP, if the public keys for a user are themselves unique?
Ans.: When a user (say, A) wants to send a message to another user (say, B), then it sends the message and digest encrypted with the session key K. The session key encrypted with the recipient's public key is sent along with the message. However, as in PGP, every user has multiple pairs of private/public keys, then, how does the recipient know which of its public keys has been used for encrypting the session key? One solution is to send the used public key of the recipient along with the message. This approach is fine; however, it results in wastage of space, as public keys are very long. Another solution is to attach a Key ID with each public key, which consists of its least significant 64 bits. The key ID is much shorter than the public key, and uniquely identifies each public key. Now, instead of sending the whole public key, the sender can transmit only the Key ID of the public key. Thus, the Key ID field is included in the private/public and public rings in PGP.
18. Discuss the general format of a PGP message.
Ans.: A PGP message consists of three components: a session key component, a signature and the message (see Figure 9.7). The entire block containing these components is generally encoded with radix-64 encoding. These components are discussed as follows:
Figure 9.7 PGP message format
Session key component: This component includes the session key and Key ID of the recipient's public key that the sender has used to encrypt the session key.
Signature component: This component includes the following fields.
Timestamp: This is 4-byte field that defines the time of creation of the signature.
Key ID: This is an 8-byte field that contains the Key ID of the signer's public key. This enables the recipient to identify the public key to be used for decrypting the message digest.
Message digest: This field contains the 160-bit SHA-1 digest, which is computed over the timestamp of the signature along with the data portion of the message component. The inclusion of the timestamp safeguards against replay attacks. The message digest is signed by the sender using its private key.
Leading two octets of message digest: This field contains the first 2 bytes of digest in plaintext. These 2 bytes are included as a kind of checksum. These bytes ensure that the recipient is using the correct public key to decrypt the message digest. The recipient compares the plaintext copy of these two octets with the first two octets of the decrypted digest. If they match, it is verified that the recipient is using the correct public key.
Message component: This component contains the actual data to be transmitted. It also includes a filename and a timestamp that specifies the time of creation.
19. How are PGP certificates different from X.509 certificates?
Ans.: Both PGP and X.509 certificates are standard security certificates. The main differences between PGP and X.509 are discussed in Table 9.3.
| PGP | X.509 |
|---|---|
| PGP certificates contain a self signature, and also support multiple signatures. The public key in a PGP certificate is associated with several fields, which are used to identify the key owner in different ways. | X.509 certificates contain only a single digital signature to verify the key's validity. Moreover, only one field is used for identifying the key owner. |
| PGP certificates can be created by a normal user; no CA is involved in the creation of certificates. The keys are managed by the users, and a user can validate another user. This process eventually results in a web of trust between groups of people. | X.509 certificates have to be issued by a certification authority. The keys here are managed by the CA only. |
| In PGP, multiple paths can exist from fully trusted or partially trusted authorities to any certificate. | In X.509, only a single path exists from the fully trusted authority (CA) to any certificate. |
| In PGP, the certificates can be revoked by the owner of the certificate or the revoker. | In X.509, the certificate can be revoked only by the issuer of the certificate, that is, the CA. |
20. Explain the S/MIME protocol.
Ans.: S/MIME (stands for secure/multipurpose Internet mail extension) is a protocol designed for e-mail that enhances the standard MIME protocol by providing the security features. The S/MIME is similar to PGP as far as IETF standards are concerned, however, it is assumed that, in future, S/MIME is most likely to be used for commercial and organizational purposes, while PGP will be used for personal e-mail security purpose. S/MIME uses the same standards that were used in MIME, along with a few security enhancements. The MIME overview and the S/MIME features are discussed in the following sections.
MIME Overview
MIME (stands for multipurpose Internet mail extensions) is a protocol that enables transferring non-ASCII data through e-mails, and thus, overcomes the limitations of SMTP (simple mail transfer protocol), which only allows sending text messages over the Internet. MIME converts non-ASCII messages to a 7-bit NVT (network virtual terminal) ASCII format at the sender's side. The converted message is then forwarded to the client message transfer agent (MTA), so that it can be sent over the Internet to the receiver. At receiver's side, the message is converted to its original format. MIME can also be used to send messages in different languages such as French, German, Chinese, etc. The structure of MIME defines five new headers that were included in the original e-mail header section. These headers are described as follows.
MIME-Version: This header specifies the MIME version and tells the receiver that the sender is using MIME message format. The version number 1.1 is being used nowadays.
Content-Type: This header defines the type and subtype of the data used in the message body. The type of the data is followed by its subtype, separated by a slash, that is, type/subtype. Some of the types and their subtypes used by MIME are listed in Table 9.4.
| Type | Subtype | Description |
|---|---|---|
| Text | Plain | Unformatted |
| HTML | HTML format | |
| Image | JPEG | Image is in JPEG format |
| GIF | Image is in GIF format | |
| Video | MPEG | Video is in MPEG format |
| Audio | Basic | Single-channel encoding of voice at 8 kHz |
Content-Transfer-Encoding: This header defines the different methods used in encoding the messages into various formats so that it can be transmitted over a network. Some schemes used for encoding the message body are listed in Table 9.5.
| Type | Description |
|---|---|
| 7-bit | NVT ASCII characters and short lines |
| 8-bit | Non-ASCII characters and short lines |
| Binary | Non-ASCII characters with unlimited length |
Content-Id: This header uniquely identifies the message content.
Content-Description: This header tells what the body of the message contains, that is, whether it contains picture, audio or video. It is an ASCII string that helps the receiver decide whether the message needs to be decoded.
S/MIME Functionality
The basic functionality of S/MIME is similar to that of PGP, that is, it mainly supports digital signature and encryption of e-mail messages. However, apart from these basic functionalities, it also supports some other functions, which are as follows.
Enveloped data: S/MIME supports enveloped data, which consists of the message containing any type of contents in encrypted form and the encryption key encrypted with receiver's public key.
Signed data: This consists of the message digest encrypted using the sender's private key. S/MIME provides more confidentiality to the message by encoding the message and the signature using base64 encoding. This signed message can only be viewed by the receivers who have S/MIME capability.
Clear-signed data: This functionality is similar to the signed data and forms a digital signature of the message. The only difference is that, in this case, only the digital signature is encoded using base64 encoding. This allows the receivers to view the contents of the message even if they do not have S/MIME capability. However, they cannot verify the signature.
Signed and enveloped data: This is a mixture of the previously mentioned functions. In this case, S/MIME allows nesting of signed-only and encrypted-only entities, so that the encrypted data can be signed, and signed or clear-signed data can be encrypted.
S/MIME Messages
S/MIME makes the MIME entity (such as a message or a part of it) secure either with a signature or with encryption, or both. Initially, a MIME entity is prepared according to the general rules for MIME message preparation. The MIME entity can either be the entire message, or a part of it (in case the content type is multipart). Then, the MIME entity along with the security-related data, such as algorithm identifiers and digital certificates, are processed by S/MIME. The output generated from this process is the PKCS (public key cryptography standard) object. The PKCS is now wrapped in MIME, and proper MIME headers are added to it.
To add security features such as digital signatures and encryption, S/MIME defines two new content types, which are listed in Table 9.6.
Table 9.6 S/MIME content types
S/MIME Certificate Processing
S/MIME makes use of digital certificates that conform to the third version of X.509. The key-management scheme of S/MIME is a mixture of X.509 certification hierarchy and PGP's web of trust. As with the PGP model, S/MIME users are responsible for maintaining the certificates needed to verify the incoming signatures and for encrypting the outgoing messages, and as with X.509, only CAs are allowed to sign the certificates.
An S/MIME user performs three key-management functions, namely, key generation, registration and certificate storage and retrieval. In the key generation process, the user having administrative capabilities must be able to generate key pairs using DSS and Diffie-Hellman, and should be able to generate the key pairs using RSA. In the registration process, the user receives an X.509 digital certificate. To receive an X.509 certificate, the user has to first register its public key with the CA. The certificate storage and retrieval process deals with maintaining a local list of certificates, so that the users can retrieve their certificates to validate the incoming signatures and encrypt the outgoing messages. This list can be maintained either by the users or by some local administrative entity on behalf of the users.
S/MIME Enhanced Security Services
The S/MIME provides three enhanced security services, which are discussed as follows:
Signed receipts: This is an acknowledgement message that is used to inform the sender about the delivery of the message. The entire message, including the original message and signature of the
sender, is signed by the receiver, and the new signature is appended to form a new S/MIME message.
Security labels: Each signed object can also include a security label in the authenticated attributes. This security label basically includes information regarding the confidentiality (sensitivity) of the message being protected by S/MIME. In addition to confidentiality, the labels can also be used for access control (which users are authorized to access the object), for defining priority of the message (secret, confidential, restricted, etc.) or for defining role-based access (which category of users are allowed to see the information).
Secure mailing lists: When a sender wants to send a message to a recipient, he or she needs to encrypt the message using recipient's public key. In case the same message needs to be sent to several recipients, then the sender has to encrypt the message with every recipient's public key before sending it to these recipients. This is very time-consuming task. To simplify this process, S/MIME provides a Mail List Agent (MLA), who is responsible for performing recipient-specific encryption of the message for each recipient. The creator of the message needs to send the original message to MLA, only once, encrypted with the MLA's public key, and the rest is done by MLA itself.
21. Give an overview of IP security along with its applications and benefits.
Ans.: The Internet community has developed many application-specific security protocols such as Kerberos (for client/server), PGP and S/MIME (for electronic mail) and many others. These protocols provide security only at higher network layers, such as the application and transport layer. However, some applications such as routing protocols that use IP services need security service at the network layer or Internet protocol (IP) layer. To provide security at the IP layer, the IETF developed a collection of protocols referred to as IP security (IPSec). Before IPSec was initiated, the IP packets were prone to security failure. The data in the IP packets were in plaintext form, which allowed anyone to access or change the contents of the packets during transmission.
The overall idea of IPSec protocol is to encrypt and seal the transport and application layer during transmission, and also to provide integrity protection in the Internet layer itself. IPSec provides three security functions, namely, authentication, confidentiality and key management. Authentication ensures that the packets are arriving from the actual source as specified in the packet header. It also ensures that the packet has not been altered during transmission. The confidentiality function allows two communicating nodes to transfer messages in an encrypted form in order to prevent any third-party intervention. The key management provides a platform for exchanging keys in a secured manner. All these security measures are incorporated in both the versions of IP, namely, IP version 4 (IPv4) and IP version 6 (IPv6).
The IPSec enables secure communication across different types of networks such as LANs and WANs. It also secures the Internet. The applications of IPSec are discussed as follows:
Secure remote access over the Internet: An end user using IPSec protocols can make a local call to an Internet Service Provider (ISP) and request it to provide a secure access to a company network. This reduces travelling cost and time wastage of employees and telecommuters.
Enhancing electronic commerce security: Though many e-commerce sites provide in-built security services, the use of IPSec further increases the level of security.
Secure branch office connectivity over the Internet: IPSec can be used to create a secured virtual private network over the Internet or over a public WAN, connecting all the branches of a company. This will save the cost of creating a private network that needs expensive leased lines.
Establishing extranet and intranet connectivity with partners: IPSec can be used to make secure connections with other organizations, since it addresses all the three security issues: authentication, confidentiality and key management.
IPSec has got many advantages, which are as follows:
IPSec is very transparent to end users. There is no need to provide any kind of training to the users. It also does not require to issue or revoke keys to and from the users.
When IPSec is implemented in a firewall or router, it provides more security as it becomes the only entry/exit point for all the traffic. However, the internal traffic does not have to use IPSec and is, thus, free from the overhead of any security-related processing.
Since IPSec is implemented at the network layer, there is no need to make any changes at the upper layers such as application and transport layer.
IPSec can provide security to individual users also. Individuals can set up secure virtual sub-networks within an organization for sensitive applications. These types of connections are useful for offsite workers.
22. Write a short note on transport and tunnel mode.
Ans.: IPSec operates in two different modes, namely, transport mode and tunnel mode. The transport mode is used to provide protection mainly for the upper layer protocols. In this mode, IPSec protects the packets coming from the transport layer to the network layer. That is, it only protects the IP layer payload and not the IP header. It does not protect the whole IP packet. In this mode, the IPSec header and IPSec trailer are added to the packet coming from the transport layer, which becomes the IP payload in network layer, and later the IP header is added to the payload. This mode is used for secured host-to-host communication. The sender authenticates and/or encrypts the payload received from the transport layer using IPSec. The receiver verifies the authenticity and/or decrypts the IP packet using IPSec and forwards it to the transport layer.
The tunnel mode is used to provide security to the entire IP packet. Here, the IP packet is totally protected, including the IP header. Also, a new IP header is added to the protected packet. The tunnel mode is used when either or both of the communicating parties are security gateways, such as routers. That is, tunnel mode provides secure communication between two routers, or between a router and a host or between a host and a router. The packets transmitting from sender to receiver are protected from intrusion as if the packets pass through an imaginary tunnel.
The main difference between the transport mode and the tunnel mode is that, in the former case, the IPSec layer comes between the transport layer and the network layer. However, in case of tunnel mode, the information flows from the network layer to the IPSec layer and then back to the network layer.
23. Write a short note on IPSec RFC documents.
Ans.: In 1995, the Internet Engineering Task Force (IETF) published several security standards related to IPSec in the form of RFC documents. The most important of these are RFCs 2401, 2402, 2406, and 2408. RFC 2401 gives an overview of security architecture, RFC 2402 contains a description of a packet authentication extension to IPv4 and IPv6, RFC 2406 consists of a description of a packet encryption extension to IPv4 and IPv6, and finally RFC 2408 includes specification of key management capabilities. In addition to these four RFCs, several additional drafts have been published by IP security Protocol Working Group set up by IETF. These documents are divided into seven groups, as shown in Figure 9.8.
Figure 9.8 Overview of IPSec Document
Architecture: This includes the general concepts, requirements for security, definitions and the mechanisms needed for defining IP security.
Encapsulating security payload (ESP): This includes the packet format and issues related to the use of ESP. The issues deal with the encryption of packets by ESP and, occasionally, with authentication.
Authentication Header (AH): This includes the packet format and issues related to the use of AH for authentication of packets.
Encryption algorithm: This is a set of documents describing the use of various encryption algorithms for ESP.
Authentication algorithm: This is a set of documents specifying the use of authentication algorithms for AH. It also deals with the authentication option used in ESP.
Key management: This is a set of documents describing the various key management schemes.
Domain of interpretation (DOI): This contains the values that are used to relate all the documents with each other. The values include identifiers for the authentication and encryption algorithms that have already been approved, and operational parameters such as key lifetime.
24. Name the two protocols defined by IPSec.
Ans.: The two protocols defined by IPSec are the Authentication Header (AH) protocol and the Encapsulating Security Payload (ESP) protocol. These protocols provide the authentication and/or encryption for the packets at the IP level.
25. Explain the Authentication Header (AH) protocol.
Ans.: The Authentication Header (AH) protocol is used to provide source authentication, and also to ensure the integrity of the payloads being carried in the IP packets.
The authentication feature allows the receiver to authenticate the sender, and accept or reject packets, accordingly. In addition, it prevents the address spoofing attacks.
The integrity feature ensures that the contents of the IP packets are not altered during transmission.
This protocol is based on the message authentication code (MAC), which implies that the two parties must share a secret key. First, a message digest is created with the help of a hash function and a symmetric key. The message digest is then inserted into the AH. This AH is finally placed in the appropriate location as per the mode used (transport or tunnel). The AH format is shown in the Figure 9.9.
Figure 9.9 Authentication Header format
The various fields of the AH are discussed in the following:
Next header: This is an 8-bit field that specifies
the type of header immediately following this
header. If ESP header follows the AH, this field contains the value 50, and if another AH follows
this AH, it contains the value 51.
Payload length: This is an 8-bit field that specifies the length of the AH in 32-bit words (in 4-byte multiples) minus 2. For example, if the length of the authentication data field is 96 bits (or three 32-bit words), then with a three-word fixed length, we have a total of six words in the header. Thus, the value of this field is 4.
Reserved field: This is a 16-bit field that has been kept reserved for future use.
Security parameter index (SPI): This is a 32-bit field that uniquely identifies the security associations (discussed later) for the traffic to which the IP datagram belongs. It plays the role of a virtual circuit identifier. This field is used in combination with the source and destination addresses, as well as the IPSec protocol used (AH or ESP).
Sequence number: This is a 32-bit field that contains a monotonically increasing number (a counter) that specifies the ordering of the IP datagrams. The sequence number is capable of preventing the replay attacks. The sender must always transmit this field, but the receiver need not always act upon it. The first packet transmitted has a sequence number of 1, and once it reaches the value 232, a new connection must be established and the sender's and receiver's counter must be reset.
Authentication data: This is a variable-length field that contains the authentication data, called the Integrity Check Value (ICV), for the datagram. For IPv4 datagrams, this value must be an integral multiple of 32, and for IPv6, this value must be an integral multiple of 64. The ICV is generated by applying a hash function to the whole IP datagram. The fields that are changed during transmission are not included while applying the hash function.
26. How does the AH protocol prevent the replay attack?
Ans.: The sequence number field in the IPSec AH protocol is designed to prevent the replay attacks. Initially, the value of this field is set to 1. Now, each time the sender sends a packet to the receiver over the same security association (or connection), the value is incremented by one. When the value of the sequence reaches 232, it is not set back to 1 in order to prevent the use of the same sequence numbers again. Rather, a new connection with a new secret key must be established between the sender and the receiver.
Since IP is connectionless and unreliable, it does not guarantee that all the packets will be delivered and that the packets will be delivered in the correct sequence. To ensure this, the IPSec authentication document prescribes the receiver to implement a window of size W. The default value of W is 64. The
right edge of the window specifies the highest sequence number N of a valid packet, received so far. After receiving a packet, the receiver takes one of the following actions, depending on the sequence number of the packet:
The receiver determines whether the received packet is new, and falls in the range of the window, that is, if its sequence number lies between N−W+1 and N. If both the conditions are satisfied, then the receiver checks the authenticity of the packet. If the packet is authenticated, the corresponding slot in the window is marked.
If the sequence number of the newly received packet is greater than N, and if the packet is authenticated, then the receiver advances the window and makes this new sequence number the right edge of the window. Finally, the corresponding slot in the window is marked.
If the received packet is to the left of the window, that is, its request number is less than N−W, or if it is not authenticated, the receiver discards the packet and triggers an auditable event.
The third action prevents the replay attacks, because if the receiver receives a packet with a sequence number less than N−W, then he or she concludes that some attacker is attempting to impersonate the sender and resend an already received packet.
27. Describe how AH is used in transport and tunnel modes in IPSec protocol.
Ans.: The AH protocol can operate in both transport mode and tunnel mode. In transport mode, authentication is provided directly between the server and client workstations. The server and client workstations can be present either on the same network or on different networks. In tunnel mode, a workstation present on a remote network authenticates itself to the corporate firewall. Let us have a look at the scope of authentication provided by AH and the location of AH for the two modes. These two modes further vary for IPv4 and IPv6.
AH Transport Mode
In transport mode AH, when IPv4 packet is used, the AH is inserted after the original IP header but before the IP payload. The entire packet except the mutable fields of IPv4 is authenticated. On the other hand, when IPv6 is used, the AH is inserted after the base header and the hop-by-hop, routing and fragment extension headers. However, the destination options extension header can be placed either before the AH or after it, depending on the desired semantics. The authentication covers the entire IPv6 packet, except the mutable fields. The AH transport mode for both IPv4 and IPv6 packets is shown in Figure 9.10.
Figure 9.10 Transport mode AH
AH Tunnel Mode
In the tunnel mode AH, a new outer IP header is inserted into the packet, and the AH is inserted in between the original IP header and the new outer IP header. The addresses of the original source and destination are included in the inner IP header, while the addresses of firewalls or other security gateways are included in the new outer IP header. AH protects the entire inner IP packet, including the inner IP header. The new outer IP header is also protected, except for the mutable and unpredictable fields. The AH tunnel mode for both IPv4 and IPv6 packets is shown in Figure 9.11.
Figure 9.11 Tunnel mode AH
28. Explain the ESP protocol.
Ans.: The ESP protocol provides confidentiality and integrity of the messages. Optionally, this protocol can also provide an authentication service. The ESP packet format (containing a header and a trailer) is made up of seven fields (see Figure 9.12). These fields are discussed in the following text:
Security parameters index (SPI): This is a 32-bit field that uniquely identifies the security associations for traffic to which the datagram belongs. It is used in combination with the source and destination IP addresses, as well as the security protocol used (AH or ESP). The SPI value ranges from 1 to 255, and these values have been reserved by the Internet Assigned Numbers Authority (IANA) for future use.
Sequence number: This is a 32-bit field that contains a number that increases monotonically. Initially, counter of both the sender and receiver is set to zero. This field prevents the replay
attacks similar to the AH. The sender must always transmit the field, but the receiver has the freedom to ignore it.
Figure 9.12 IPSec ESP format
Payload data: This is a variable-length field that contains the transport-layer segment (transport mode) or IP packet (tunnel mode), which is protected using an encryption mechanism.
Padding (0–255 bytes): This field contains the padding bits, if any. These bits are mainly used in encryption algorithms for expanding the plaintext to the required length. These can also be used for right-aligning the padding length and next header fields within the 32-bit word. This field also ensures that the ciphertext is an integer multiple of 32 bits.
Padding length: This is an 8-bit field that indicates the number of bytes padded in the previous field. It can have a value between 0 and 255. A zero value indicates the absence of any padding bytes. This field is mandatory.
Next header: This is an 8-bit field that indicates the type of data contained in the payload data field by identifying the first header in that payload (e.g. an upper layer protocol such as TCP in IPv4 and an extension header in IPv6). This field is mandatory.
Authentication data: This is a variable-length field that contains the Integrity Check Value (ICV). The ICV value is computed by subtracting the authentication data field from the length of the ESP packet. The authentication data must always be an integral multiple of 32-bit words.
29. Describe the transport and tunnel mode of ESP.
Ans.: As with the AH protocol, ESP can also operate in transport and tunnel modes. Considering both IPv4 and IPv6 packets, the working of ESP in transport and tunnel modes is explained in the following:
Transport Mode ESP
The ESP in the transport mode is used to encrypt and optionally authenticate the data carried by IP. In case of IPv4 packets, the ESP header is inserted between the original IP header and transport-layer header (such as TCP, UDP and ICMP). An ESP trailer, consisting of padding, padding length and next header fields, is also placed after the IP packet (see Figure 9.13). If authentication is also used, the ESP authentication data field is also added at the end. The encryption is performed at the entire transport level segment, including the ESP trailer. The ciphertext and the ESP header are then authenticated.
Figure 9.13 Transport mode ESP
In case of IPv6, the ESP header is inserted after the base header and the hop-by-hop, routing and fragment extension headers. Depending on the semantics, the destination options extension header can be inserted either before or after the ESP header. Here, the transport-level segment, the ESP trailer and the destination options extension header (if present) are encrypted, whereas the ciphertext and the ESP header are authenticated.
The operation of ESP transport mode is summarized as follows:
1. At the sender's end, the IP packet is formed by encrypting the plaintext of data containing the ESP trailer and the entire transport-layer segment (TCP header plus data): The authentication can also be added to the IP packet if this option is selected.
2. The packet is transmitted to the destination. The routers falling in the route examine and process only the IP header and the plaintext IP extension headers (if present) and not the ciphertext.
3. When the IP packet is received by the destination, the IP header and the plaintext IP extension headers are processed. After this, the destination decrypts the rest of the packet based on SPI in the ESP header in order to retrieve the plaintext transport layer segment.
Tunnel Mode ESP
In tunnel mode ESP, the entire IP packet is encrypted. The ESP header is prefixed to the packet, and the packet is then encrypted including the ESP trailer (see Figure 9.14). In this mode, the entire block (ESP header, ciphertext and authentication data, if present) is encapsulated with a new IP header because the original IP header contains the destination address and possibly intermediate routing information and, thus, cannot be transmitted as it is. Therefore, a new IP header is needed that will contain the necessary information for routing and not for traffic analysis.
The difference between transport mode ESP and tunnel mode ESP is that the former is used to protect connections between two hosts supporting the ESP feature, while the latter is suitable for protecting connections in configurations when some sort of security gateway or firewall is used. The encryption process in the tunnel mode involves only the external hosts and security gateways. The hosts on the internal network are not involved in this process, thus relieving them from the extra burden of encryption. This makes the key distribution task simpler, as lesser number of keys would be required, and prevents traffic analysis based on the ultimate destination.
Figure 9.14 Tunnel Mode ESP
The operation of the ESP tunnel mode is summarized as follows.
1. At the sender's end, the inner IP packet is prepared using the destination address of the target host on the internal network. The ESP header is prepended to the packet. The packet and ESP trailer are then encrypted, and authentication data is added (if required) to form a block. The block is encapsulated with a new IP header that consists of the base header and some other extension headers such as routing and hop-by-hop options. This forms the outer IP packet, which contains the destination address of a firewall.
2. The outer IP packet is forwarded to the destination firewall. The routers falling in the route examine and process only the IP header and the plaintext IP extension headers (if present) and not the ciphertext.
3. At the receiver's end (i.e., firewall), the IP header and the plaintext IP extension headers are processed once again by the destination firewall. The ciphertext is then decrypted on the basis of SPI in the ESP header to recover the plaintext inner packet.
4. The inner packet is routed through zero or more routers in the internal network to reach the destination host.
30. Explain the Internet Key Exchange protocol and security association.
Ans.: Internet Key Exchange (IKE) is another supporting protocol that is used for the key management procedures in IPSec. It is the first phase of IPSec, where the cryptographic algorithms and keys to be later used by AH and ESP are decided. After the IKE phase, actual AH and ESP operations are carried over. The output of the IKE phase is Security Association (SA), which is a logical relationship agreement between the sender and receiver that allows both the communication parties to agree upon some factors such as IPSec protocol version in use, mode of operation (transport or tunnel mode), cryptographic algorithms and keys, lifetime of keys, etc.
The main objective of IKE is to build an SA between the sender and the receiver, which is further used by AH and ESP for their actual operation. Note that in case both AH and ESP are in use, then each communicating party requires two sets of SA: one for AH and other for ESP. Moreover, SA allows only one-way communication, and hence, the communicating parties require two more sets of SA; one for incoming messages and other for outgoing messages. Thus, in total, they require four sets of SA, if both AH and ESP are in use.
31. What are the services provided by IPSec?
Ans.: The services provided by IPSec are as follows:
Access control
Connectionless integrity
Data origin authentication
Rejection of replayed packets
Confidentiality
Limited traffic flow confidentiality
The AH and ESP protocols of IPSec are responsible for providing some or all of these services. The AH protocol provides the first four services, that is, access control, connectionless integrity, data origin authentication and rejection of replayed packets. However, for ESP protocol, there are two cases, which are as follows:
If the ESP protocol allows encryption only, then it provides access control, rejection of replayed packets, confidentiality and limited traffic flow confidentiality.
If the ESP protocol allows both encryption and authentication, then it provides all these services.
32. Describe the features of Oakley algorithm used for key determination in IPSec.
Ans.: The Oakley algorithm is a key exchange protocol developed by Hilarie Orman. It is based on Diffie-Hellman algorithm, and is designed to retain the advantages of Diffie-Hellman while overcoming its limitations. Oakley is a free-formatted protocol, in the sense that it does not define any specific format for the message to be transmitted. It also provides more security than Diffie-Hellman algorithm. There are five features in Oakley algorithm that are used for key determination. These features are discussed in the following text:
The clogging attack encountered in the Diffie-Hellman algorithm is removed in Oakley using the cookie mechanism. In this attack, the victim's system is clogged with useless work as it remains busy in generating secret keys for forged public keys sent by the intruder. In cookie exchange mechanism, a pseudo-random number, called a cookie, is generated by applying a hash function (such as MD5) over the source and destination address, the UDP source and destination ports, and a locally generated secret value. The cookie is sent from each side in the initial message, which is acknowledged by the other side. This acknowledgement must be repeated in the first message of the Diffie-Hellman key exchange. If the source address was forged, the intruder gets no answer. Thus, the intruder can only force a user to generate acknowledgements and not to perform useless calculations.
The Oakley algorithm allows two parties to negotiate a group for specifying global parameters of Diffie-Hellman key exchange. Oakley supports the use of different groups for the Diffie-Hellman key exchange, where each group specifies the two global parameters (one is p, a large prime number and second is q, a primitive root of p), and the identity of the Diffie-Hellman algorithm. The present specification includes five groups, which are as follows:
Modular exponentiation with a 768-bit modulus
Modular exponentiation with a 1024-bit modulus
Modular exponentiation with a 1536-bit modulus
– Parameters to be determined
Elliptic curve group over 2155
– Generator (hexadecimal): X = 7B, Y = 1C8.
– Elliptic curve parameters (hexadecimal): A = 0, Y = 7338F
Elliptic curve group over 2185
– Generator (hexadecimal): X = 18, Y = D
– Elliptic curve parameters (hexadecimal): A = 0, Y = 1EE9
The Oakley algorithm prevents replay attacks by using nonces. The nonce is a pseudo-random number that is generated locally. Nonces are included in response messages, and are encrypted during certain portion of the exchange to secure their use.
The Oakley algorithm facilitates the exchange of Diffie-Hellman public key values (discussed in Chapter 5).
The Oakley algorithm authenticates the Diffie-Hellman exchange to prevent man-in-the-middle attacks. It can apply various authentication mechanisms such as digital signatures, public-key encryption and symmetric-key encryption on some important parameters such as user IDs and nonces to authenticate the key exchange.
33. Explain the header format for an ISAKMP message.
Ans.: Internet Security Association and Key Management Protocol (ISAKMP) is designed to carry messages for Internet key exchange in IPSec. It defines procedures and formats for establishing, maintaining and deleting information regarding security associations. An ISAKMP message consists of an ISAKMP header followed by one or more payloads. This entire block is encapsulated inside a transport segment (such as a TCP segment). The header format for an ISAKMP message is shown in Figure 9.15. It consists of the following fields.
Figure 9.15 ISAKMP header format
Initiator cookie: This is a 64-bit field
defining the cookie of the entity that initiates
the SA establishment, notification or deletion.
Responder cookie: This is also a 64-bit field defining the cookie of the entity responding to the initiator. This field contains the value 0 in the first message sent by the initiator.
Next payload: This is an 8-bit field indicating the type of the first payload of the message.
Major version: This is a 4-bit field indicating the major ISAKMP version as used in the current exchange. The current value of this field is 1.
Minor version: This is also a 4-bit field indicating the minor ISAKMP version as used in the current exchange. The current value of this field is 0.
Exchange type: This is an 8-bit field indicating the type of exchange that is being carried by the ISAKMP packets.
Flags: This is an 8-bit field indicating the specific set of options for this ISAKMP exchange. Each bit in this field defines a single option. So far, only 3 bits have been defined, which are as follows.
Encryption bit is set to 1, if all the payloads following the header are encrypted using the encryption algorithm for this SA.
Commit bit is set to 1 to ensure that the encrypted packet is not received until the SA is established.
Authentication bit is set to 1 to ensure that the rest of the payload, which is not encrypted, is still authenticated for integrity.
Message ID: This is a 32-bit field specifying a unique ID for this message.
Message length: This is a 32-bit field specifying the total length of the packet (including the header and all payloads) in octets.
34. What is SSL? Discuss its architecture.
Ans.: The Secure Socket Layer (SSL) protocol was developed by Netscape Corporation in 1994 to provide exchange of information between a web browser and a web server in a secure manner. As with other protocols, its main aim is to provide entity authentication, message integrity and confidentiality. SSL is an additional layer located between the application layer and the transport layer of the TCP/IP protocol suite. All the major web browsers support SSL. It comes in three versions: 2, 3 and 3.1. Among these, version 3, which was released in 1995, is the most popular version.
SSL architecture
SSL is not a single protocol; rather, it is two layers of protocols, as shown in Figure 9.16. The higher-layer protocols include Handshake protocol, Change Cipher Spec protocol and Alert protocol. These three protocols are defined as part of SSL, and are used in the SSL management process. The lower layer includes the SSL Record protocol, which is used for providing various basic security services to the higher-layer protocols. HTTP, which enables the web browser to interact with the web server, can work on the top of SSL.
Figure 9.16 SSL Architecture
These protocols are discussed as follows:
SSL Record protocol: This protocol acts as a carrier. That is, it is used for carrying the messages from the higher-layer protocols as well as data coming from the application layer. It receives the data to be transmitted from the application layer, and operates on it as follows:
1. Fragmentation: The data is first divided into the blocks of 214 bytes or less.
2. Compression: This is an optional phase in which each fragment of data is compressed using one of the lossless compression techniques agreed upon between the client and server.
3. Message integrity: A keyed-hash function is applied on the compressed data to compute a message authentication code (MAC). This ensures the integrity of the message.
4. Confidentiality: The original data and the MAC are encrypted using symmetric-key cryptography to ensure confidentiality.
5. Framing: Finally, an SSL header is added to the encrypted payload, which is then transmitted to a reliable transport layer protocol.
Handshake protocol: This protocol is the most complex part of SSL. It allows authentication between the server and the client. It allows the server and the client to negotiate on an encryption and MAC algorithm, and cryptographic keys to be used for encrypting the data in an SSL record. In this protocol, several messages are exchanged between the server and the client. All of these messages have a fixed format with three fields [see Figure 9.17(a)], as listed in the following:
Type: This is a 1-byte field indicating one of the ten possible message types. The ten message types are hello_request, client_hello, server_hello, certificate, server_key_exchange, certificate_request, server_done, certificate_verify, client_key_exchange and finished.
Length: This is a 3-byte field specifying the length of the message in bytes.
Content: This field contains the parameters associated with this message, depending on the message type. For example, in case of hello_request and server_done messages, the parameter list is null. In case of certificate message, the parameter list contains a list of X.509v3 certificates.
The Handshake protocol consists of four phases. These phases are:
1. Establish security capabilities: In this phase, a logical connection is initiated and the security capabilities associated with that connection are established. This is done with the help of two messages, the client_hello and server_hello.
2. Server authentication and key exchange: This phase is initiated by the server. In this phase, the server is authenticated to the client, and the client is made aware of the public key of the server if needed. In this phase, only the server sends the messages, while the client only receives the messages. The messages used in this phase are: certificate, server_key_exchange, certificate_request and server_done.
3. Client authentication and key exchange: This phase is initiated by the client. In this phase, the client is authenticated to the server, and both the client and server know the pre-master secret. In this phase, the client sends the messages, and the server only receives the messages. The messages used in this phase are: certificate, client_key_exchange, certificate_request and certificate_verify.
4. Finish: This is last phase in the SSL handshake protocol, which completes the setting up of a secure connection. It is initiated by the client and terminated by the server. First, two messages, change_cipher_spec and finished, are sent by the client, and then the server responds with two similar messages change_cipher_spec and finished message.
Change cipher spec protocol: Once the server and the client have negotiated on the cryptographic secrets during the Handshake protocol, the next step is to use these secrets. The change cipher spec is the simplest protocol that is used to signal that the cryptographic secrets are ready for use. This protocol consists of only one message, which consists of a single byte with the value 1 [see Figure 9.17(b)]. This value causes the pending state to be changed to the active state. The pending state is the one in which two communicating parties keep track of the parameters and secrets. The active state is the one in which the two parties use these parameters and secrets to sign/verify or encrypt/decrypt the messages. The change cipher spec protocol is responsible for moving values between the pending state and active state.
Figure 9.17 Message Format of SSL Protocols
Alert protocol: This protocol is used to signal errors or any abnormal conditions to the nodes. It enables the nodes to exchange the error or warning information. The type of message associated with alert protocol is the Alert message. There are two bytes in each message of the alert protocol [see Figure 9.17(c)]. The first byte conveys the severity of the error. It can take either the value 1 or 2, where value 1 indicates warning and value 2 indicates fatal. In case of fatal error, the connection is immediately terminated. The second byte contains a code that indicates the specific alert. Some of the possible alert codes are unexpected_message, handshake_failure, decompression_failure, no_certificate, certificate_revoked and certificate_expired.
35. What are the differences between an SSL connection and an SSL session?
Ans.: The differences between an SSL connection and an SSL session are discussed in the following:
A session is established between a client and a server, while a connection is established between two peers having equal roles.
A session can consist of many connections, while a connection is associated with only one session.
A connection can be terminated and re-established within the same session. When a connection is terminated, the session between the two parties may or may not be terminated. However, when the session is terminated, all the connections of that session also terminate. A session may be suspended or resumed again.
Data can be exchanged only when the connection between the two parties is established; mere establishment of session is not enough for exchange of data.
To create a new session, the communicating parties have to go through a negotiation process. However, to create a new connection within the same session, the negotiation process can be skipped.
36. Describe briefly the TLS protocol. Also, differentiate between the SSL and TLS protocols.
Ans.: The Transport Layer Security (TLS) protocol is the Internet standard version of the SSL protocol by IETF. Netscape wanted to have a standardized version of SSL, and hence handed over it to IETF. The core idea and implementation of both the protocols are quite similar; however, there are some minor differences. These differences are listed in Table 9.7.
| Property | SSL | TLS |
|---|---|---|
| Version | The commonly used version of SSL is 3.0. | The current version of TLS is 1.0. |
| Cipher suite | An algorithm called Fortezza is used. | The algorithm Fortezza is not used. |
| Cryptography secret | It uses the standard SSL encryption to create a master secret. | A pseudorandom function (PRF) is used to create a master secret. |
| Alert protocol | It uses the standard SSL alert protocol. | The no_certificate alert message is not supported. Some new messages are added, such as decryption_failed, record_overflow, access_denied, unknown_CA, export_restriction, decode_error, protocol_version, insufficient_security and internal_error. |
| Handshake protocol | It uses the standard SSL handshake protocol. | The details of the certificate_verify message and finished message are changed. |
| Record protocol | Uses MAC | Uses HMAC |
37. What is SET? How does SET work? Also, discuss the dual signature for SET and its purpose.
Ans.: The Secure Electronic Transaction (SET) protocol is used for secured credit card transactions over the Internet. SET itself is not a payment system; rather, it contains the security protocols and formats that are used to provide security to the credit card payments made by a user on a public network such as the Internet. The SET concept was started as early as the year 1996, but the first product came to be available only in the year 1998. SET mainly provides three services, which are as follows:
It provides a secured medium of communication for all the parties involved in a communication.
It provides trust by the use of X.509v3 digital certificates.
It provides complete privacy as the parties involved in the communication can access the information only when and where necessary.
To understand the working of SET, it is important to know the participants of the SET system. The main participants of SET system are:
Cardholder: The person who owns the card (such as MasterCard, Visa) and does the purchasing on the Internet.
Merchant: The organization or the individual who sells goods or offers services to the cardholder. Usually, these goods and services are offered via a website.
Issuer: The financial institutions (such as banks) that issue the credit cards and are responsible for the payment of purchases made by the cardholder.
Acquirer: This is also a financial institution that is responsible for establishing an account with the merchant and processing payment card authorizations and payments. Generally, a merchant accepts many credit cards issued by different banks. Since the merchant cannot deal with all the banks, or it cannot have account in all the banks, therefore, it needs an acquirer who provides authorization to the merchant that the card account is valid and active. The acquirer also transfers the payments electronically to the merchant's account. The issuer subsequently reimburses the acquirer over some kind of payment network for electronic funds transfer.
Acquirer payment gateway: This is an interface between SET and the computer networks of banks for authorization and payment functions.
Certification authority (CA): This is an organization that offers different classes of certificates for cardholders, merchants and payment gateways.
Working of SET
Before using SET, both the cardholder and the merchant must register with the CA. After the registration process, the working of SET involves many steps, which are as follows:
1. The customer browses the merchant's website to evaluate the products offered by the merchant. He or she then selects the products to be purchased and adds them to the shopping cart.
2. The customer then uses a single message to communicate with the merchant and payment gateway. The message has two parts, namely, purchase order, which is used by the merchant, and card information, which is used by the merchant's bank (acquirer).
3. The card information is then forwarded to the acquirer.
4. The acquirer contacts the issuer and checks about payment authorization.
5. If the purchase is authorized, the issuer sends the authorization to the acquirer.
6. A copy of the authorization is also forwarded to the merchant.
7. The merchant completes the order and informs the customer about it.
8. Merchant captures the transaction from its bank.
9. Finally, the credit card invoice is printed by the issuer and provided to the customer.
Dual Signatures
As stated in step 2 of SET, the customer uses a single message to communicate with the merchant and the payment gateway. Therefore, the customer has to ensure that the merchant will not be able to view the payment instruction, and that the acquirer will not be able to view the order instruction. Also, the order and payment has to be linked together, so that the customer can prove that the payment is for the particular order. This whole process is implemented using a concept known as dual signature. The creation of dual signature involves five steps, which are as follows:
1. The customer creates the Payment Information Message Digest (PIMD) by taking the hash (using SHA-1) of the Payment Information (PI).
2. The customer creates another digest, that is, the Order Information Message Digest (OIMD) by taking the hash (again using SHA-1) of the Order Information (OI).
3. Both the PIMD and OIMD are combined together.
4. The combined result is again passed through the hash algorithm SHA-1, and a new digest, Payment Order Message Digest (POMD), is created.
5. Finally, the customer encrypts the POMD with his or her private key using the RSA algorithm, thereby creating the dual signature (DS). This POMD is available to both the merchant and the payment gateway.
Now, the cardholder sends OI, DS and PIMD to the merchant. The merchant verifies that the order information has come from the cardholder, and not from any imposter, by following these steps:
1. The merchant computes its own OIMD by taking hash of OI.
2. The PIMD received from the customer and the computed OIMD are then combined to form a new POMD (say, POMD1).
3. The merchant decrypts the received DS to recover the original POMD.
4. The merchant then compares POMD and POMD1. If both are equal, the message is accepted; otherwise, it is rejected.
Similarly, the payment gateway receives PI, DS and OIMD from the cardholder. Then, it verifies that the payment information has come from the cardholder and not from anyone else. For this, it uses a similar process as used by the merchant to verify the order information. To protect the payment information from the merchant, the cardholder encrypts PI, DS and OIMD with one-time session key K. The key K is also encrypted with the private key of the payment gateway. These two together form a digital envelope, which is sent to the merchant. The merchant is supposed to send this envelope to the payment gateway. Since the merchant does not know the public key of the payment gateway, it cannot decrypt the envelope to obtain the payment details. The payment gateway verifies the authenticity of the cardholder by following these steps.
1. The payment gateway computes its own PIMD by taking hash of PI.
2. The OIMD received from the customer and the computed PIMD are then combined to form a new POMD (say, POMD1).
3. The payment gateway decrypts the received DS to recover the original POMD.
4. The payment gateway then compares the POMD and POMD1. If both are equal, it is verified that the message has come from the cardholder, and not from any imposter.
38. Differentiate between SSL and SET.
Ans.: SSL and SET are both Internet security protocols. However, they differ in some aspects as SET is more secured than SSL. The authentication mechanism used in SET is very complex, which makes it almost impossible for both the sender and receiver to commit any kind of fraud. In a nutshell, SET has been specifically designed for secured e-commerce transactions involving online payments, while SSL has been designed only for exchanging messages over the Internet. The main differences between SSL and SET are listed in the Table 9.8.
| Issue | SSL | SET |
|---|---|---|
| Main objective | To allow exchange of data in an encrypted form | To support e-commerce-related payment mechanisms |
| Certification | The certificates are exchanged between the two parties. | A trusted third party certifies all the parties involved in the communication process. |
| Authentication | The authentication mechanism is not very strong. | The authentication mechanism is very strong. |
| Risk of merchant fraud | It is prone to merchant fraud as financial data is provided to the merchant. | It is free from this fraud as financial data is given to the payment gateway only. |
| Risk of customer fraud | It is prone to this kind of fraud as the customer can refuse to pay later; there is no mechanism that can prevent such kind of fraud. | The payment instructions are digitally signed by the customer. Thus, there is less chance of such fraud. |
| Action in case of customer fraud | Merchant is responsible if a customer later refuses to pay | Payment gateway is responsible in case of customer fraud. |
| Practical usage | High | Less |
Multiple-choice Questions
1. Which server acts as KDC in the Kerberos protocol?
(a) TGS
(b) AS
(c) Real server
(d) None of these
2. Which encryption algorithm is used in the Kerberos 4 protocol?
(a) AES
(b) Block cipher
(c) DES
(d) Triple DES
3. In which year was X.509 first issued?
(a) 1988
(b) 1978
(c) 1982
(d) 1994
4. Who issues the PGP certificates?
(a) ITU-T
(b) IEEE
(c) IETF
(d) The users themselves
5. What are the two modes that IPSec protocol works on?
(a) On and Off
(b) Transport and Tunnel
(c) Forward and Backward
(d) Linked and Unlinked
6. Which of the following are IPSec protocols?
(a) PGP and S/MIME
(b) Kerberos 4, Kerberos 5
(c) AH and ESP
(d) SSL and SET
7. Which algorithm solves the man-in-the-middle attack problem?
(a) Diffie-Hellman
(b) RSA
(c) Oakley
(d) ISAKMP
8. Which of the following Internet security protocols is used for secure credit card payments?
(a) SET
(b) PGP
(c) SSL
(d) TLS
9. The _________ protocol uses the Fortezza algorithm.
(a) TLS
(b) SET
(c) ESP
(d) SSL
10. In which protocol is the payment gateway used?
(a) SET
(b) PGP
(c) TLS
(d) SSL
Answers
1. (b)
2. (c)
3. (a)
4. (d)
5. (b)
6. (c)
7. (c)
8. (a)
9. (d)
10.(a)