Table of Contents for

Cryptography and Network Security

Chapter 13

Application Layer Security

Application layer security discusses about the methods of guarding web applications at the application layer from malicious attacks that might discover private information. Security is applied to the application layer, especially to defend against unauthorized access and attacks.

13.1 WEB SECURITY

Web security protects web applications from the harmful events performed by the attackers. The web security measures can be provided only after knowing the threats that can affect the web applications by identifying the vulnerabilities. Threats can be from outside through the Internet or inside from an authorized user.

To build a secure web application, there should be a secure network and transport layer. The main function of secure network was to provide protection against Transmission Control Protocol/Internet Protocol (TCP/IP) attacks. In transport layer, this can be achieved by Secure Sockets Layer/Transport Layer Security (SSL/TLS). Then, secure web applications can be designed by analysing the categories of threats and thereby incorporating security in the developed application. Secure Electronic Transaction (SET) is a key example for a web application with secure features.

13.1.1 Web Security Threats and Countermeasures

Threats occurring due to the web application vulnerabilities can be classified as follows:

1. Input validation: The input entered by the user may become a security issue if it is not properly validated. Some of the threats arising due to input validation are buffer overflow, cross-site scripting, SQL injection and canonicalization. To overcome these types of threats, the input entered by a user should not be accepted blindly. Thorough validation of input regarding type, length, keywords and built-in functions must be performed before using the input value.
2. Parameter handling: Query string, form fields, cookies and Hyper Text Transfer Protocol (HTTP) header constitute different parameters values passed between the web browser and the web application. Attackers can manipulate these parameters and thereby threat can occur. These threats can be handled by using HTTP POST for form submission and session identifiers can be utilized instead of using hidden form fields. The countermeasures can be enhanced by encrypting the query string parameters and cookies.
3. Authentication: The failure of authentication leads the attacker to acquire access to the system. The major attacks due to lack of authentication check are network eavesdropping, brute-force attack, dictionary attack, cookie replay and credential theft. These attacks can be prevented by using strong, complex and encrypted passwords.
4. Session management: Application layer is responsible for managing sessions of web applications which are crucial to provide security. The threats in the session management include ­session hijacking, session replay and man-in-the-middle attack. Secure communication ­channel, re-authentication and cryptographic techniques can be employed to prohibit these threats.
5. Auditing and logging: Through auditing and logging all the actions carried out by the user can keep tracked. The major threats encountered are users deleting the history files after performing some operation or refuses to take the responsibility for the action performed. Threats can be avoided by secure logging of all the events occur and relocate the log files regularly.

13.2 Secure Electronic Transaction

Global reach of Internet encourages online transactions. Secured encryption technology is needed to support secure E-commerce in the Internet. Cryptanalysis or code breaker and US export restrictions on ­encryption are some of the challenges in encryption technology to provide Secure Electronic Transactions in the Internet. In order to provide solution to these challenges, Secure Electronic Transaction (SET) was developed. SET is an open encryption and security standard specification that ensures secure financial transactions performed in the Internet through a debit or credit card received from a bank. SET was ­developed by VISA and MasterCard with the support of GTE, ­Microsoft, IBM and Netscape. It is difficult to provide privacy, confidentiality and authentication when two users such as cardholders and merchant are communication. In order to provide this, each user receives a digital certificate and digital signature from a Certification Authority (CA). In other way, it is represented as public and private key. For each transaction, both digital wallets (certificate and signature) are verified by each actor.

The SET uses Netscape’s SSL, Microsoft’s Secure Transaction Technology (STT), Secure Hyper Text Transfer Protocol (S-HTTP) and some aspects of public key infrastructure. The cardholder’s information is secured by the SET since it travels across an insecure network (Internet). The main advantage of SET is that, it securely conceals the Order Information (OI) and Payment Information (PI), so that bank cannot find order information and the merchant cannot find the details of payment information.

13.2.1 Actors in SET

The main actors in SET are merchant (recipient), acquirer, customer (cardholder), issuer (bank), ­payment gateway and CA, which are illustrated in Figure 13.1.

1. Merchant (Recipient): Merchant is a person or an enterprise that has goods to sell to the customers in an electronic environment. Merchant will have a tie-up with acquirer through payment gateway.
2. Acquirer: Merchant has an account with the acquirer for payment and payment card authorization. Merchant accepts various types of payment cards with the assurance of acquirer. The ­acquirer provides payment authorization to transfer the payment to the merchant account after delivering the goods to the customer.
3. Customer (Cardholder): Cardholder or customer is a person who interacts with the merchant to buy some products. In order to initiate purchase request, he/she holds a payment card which is provided by an issuer.
4. Issuer (Bank): A financial organization such as bank who provides payment card to the customer with authentication.
5. Payment Gateway: The Payment Gateway is an interface between the merchant and Acquirer. It supports money transfer and settlement.
6. Certification Authority: An entity that issues X.509v3 public key certificates to cardholders, merchants, acquirer, issuer and payment gateways.

In Figure 13.1, initially, the customer sends order request to the merchant. The merchant verifies the ­order request and confirms the order to the customers. After getting confirmation from the merchant, the customer sends payment related information and order related information to the merchant. The merchant extracts order related information and forwards the payment related information to the ­acquirer through payment gateway. The acquirer communicates with the issues and gets confirmation from the issuer that the customer does not exceed his/her limit. After that the acquirer gives ­payment authorization message to the merchant through payment gateway. Finally merchant delivers the goods to the customer. The CA takes the responsibility of providing private and public keys to all the ­components in the form of certificates.

13.2.2 Functionality of SET

Initially, both the customer and the merchant should register their details with the CA. Then, the SET enables the merchant to authorize the user as a legitimate user with a valid card by checking the public key received from the CA. It uses X.509v3 digital certificate and rivest, shamir and ­adleman (RSA) signatures to provide authentication in the SET. As initialization procedure, the cardholder and ­merchant exchange their public keys to each other as digital certificates provided by the CA. In the SET, information sent from customer to the merchant are PI and order information. The SET ensures that the information sent from customer to merchant is not altered during the time of transaction. The information is protected to provide the facility of confidentiality, privacy and authentication. The ­cardholder enters his/her private key to create a Dual Signature (DS) on the order and the payment ­Message Digest (MD).

The DS is a new concept which is introduced in the SET to provide the facility of privacy. The DS is used for concatenating two different messages that are intended for two different persons in a single message. Hence, the customer creates the DS in such a way that the merchant can view the order information and hence merchant cannot view the payment-related information. Similarly, the bank can view the payment-related information and hence the bank cannot view the order-related information. In order to do that, the customer initially computes MDs of payment- and order-related information. For computing the MD, Secure Hashing Algorithm-1 (SHA-1) is used. These MDs are denoted as PIMD (Payment Information Message Digest) and OIMD (Order Information Message Digest). After creating the PIMD and OIMD values, these two values are concatenated and the result is sent into a hash function. The final result is called Payment Order Message Digest (POMD). This POMD is further encrypted using the private key of card hold to produce the DS. The process of creating the DS is shown in Figure 13.2.

The SET consists of two phases, namely purchase request and purchase response. During the purchase request, the cardholder has to send order- and payment-related information to the merchant and to the bank. In the purchase response, the merchant responds with the cardholder. If the cardholders transaction is valid, then the merchant delivers the goods to the cardholder. For creating the purchase request message, the cardholder initially creates the DS. After creating the DS, it generates a ­random session key value K_s to encrypt the payment-related information as shown in Figure 13.3. After generating the session key, it encrypts the session key using the public key of bank Ku_b. This can be decrypted by using the private key of bank Kr_b. This is called digital envelope and is used for finding the randomly generated session key by the bank. This digital envelope is created based on encryption performed using the public key of the bank with the RSA algorithm. After creating the digital envelope, the customer encrypts the PI, DS and OIMD using the session key generated by the customers browser software. This provides additional confidentiality to the PI of the transaction. This result is denoted as encrypted PI. Finally, the customer sends encrypted PI, digital envelope, PIMD, OI, DS and certificate of customer (cardholder) to the merchant as shown in Figure 13.3.

After receiving the payment request from the customer, the merchant uses the customer’s public key, to verify the cardholder’s DS. In order to do that, the merchant decrypts the DS using the ­public key of the customer. The public key of the customer can be obtained from the certificate of the ­customer. After decrypting, the merchant obtains POMD. This POMD is compared with the hash value of concatenated PIMD and OIMD as shown in Figure 13.4. If both are equal, then the merchant accepts the received DS as a valid one. In this phase, the merchant cannot find any payment-related information since it is in encrypted form when it is sent to the merchant. Moreover, merchant obtains only the PIMD from which the merchant cannot perform attacks to find payment-related information and thus security of the PI (credit card details) is preserved.

Once the DS is verified, the merchant forwards the encrypted PI and digital envelope to the bank (issuer) through the payment gateway and waits for payment authorization from the bank side. In order to do that, the merchant forwards the encrypted PI through the payment gateway to the acquirer. The acquirer in turn forwards that information to the bank to check whether the debit/credit card used for transaction contains sufficient amount for completing the transaction. In this case, the order details are removed by the merchant so that bank cannot find the order-related information. In addition to that, bank obtains only the OIMD from which the bank cannot perform any attack to find order-related information and thus security of the order information is preserved. After receiving the encrypted PI and digital envelope, the bank decrypts the digital envelope to find the session key using the private key of the bank. After finding the session key, the bank decrypts the encrypted PI to get PI, OIMD and DS. Using the PI and OIMD, the bank computes the POMD as shown in Figure 13.5. After that, the bank decrypts the DS to get POMD. Finally, it compares both the POMD values. If both are equal, then the bank gives reply to merchant through the acquirer.

After receiving the payment authorization reply from the acquirer, the merchant delivers the goods or products to the cardholder. After some time, the merchant can claim the amount from the acquirer for all the transactions for which the acquirer has given authorization reply. The strength of encryption used in SET is measured by how hard to break it, which depends on factors such as the length of the key, configuration of computer, the algorithms used for encryption, etc.

13.2.3 SET Algorithms

Both symmetric and asymmetric algorithms are used in the SET and are mentioned in Table 13.1. In symmetric encryption, a secret key is used to encrypt the data. The secret key may be a string of numbers or letters.

Table 13.1 Commonly used algorithms in SET

For symmetric encryption, the SET uses DES algorithm. Asymmetric encryption has two related keys which are considered as a key pair. A public key can be used by anyone who sends messages. The encrypted message can be decrypted with a receiver’s private key that makes the secret message.

13.3 E-MAIL SECURITY

E-mail is the electronic substitute of a postcard, because of this, it needs extraordinary policy considerations. E-mail security represents the collective measures used to protect the access and content of an E-mail account. It permits an individual or organization to defend the complete access to one or more ­E-mail account. While making policies for E-mail account management, the organizations have to ­consider many perspectives of E-mail like archiving the E-mails and framing constraints for content of the E-mail. The following aspects should be considered while framing E-mail policies:

1. Guidelines for using E-mail: Policies must be fixed to stipulate the responsible utilization of E-mail that helps the organization’s goals and business needs. E-mail policy should contain at least the guidelines for the content, general usage and it performs according to the accepted ­standards of E-mail security.
2. 2. Management of E-mail: Managerial policies must launch the right to test messages passing over the E-mail system. This testing could be for viruses or content. Irrespective of the testing type, there should be a policy in place that utters the name of an organization which is doing this. E-mail policies might hold mechanisms to bind the size of messages to avoid the overloading of servers and network bandwidth. To alleviate further problems, the organization might need to comprise a policy that permits them to use proxies, gateways and other means to support the diffusion of messages.
3. Usage of E-mail for confidential communication: Policies for directing confidential communication contain a facility for encoding the data before transmission and authorizing them with digital signatures. Encoding policies are really not the scope of E-mail policies. The policy statements should denote the user to the organization’s encoding policy for that information.

Nowadays both formal and informal communication are done through E-mails. The personal and ­confidential communication needs security since it passes through various unsecured channels. ­Malicious software like viruses, worms and Trojan Horses can damage the information in various ways. Both Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extensions (S/MIME) are standards which provide security to send and receive E-mail in a secure way.

13.3.1 Pretty Good Privacy

Encryption is the process of encoding information in such a way that only an authorized person can read it. Due to the ease of handling digital data in databases, hard drives or other media, E-mail can be accessed, seized and watched. The data in digital form can be manipulated, but cannot be kept in the same form for a long time, because in the meantime it can be easily duplicated and shared. For the above reasons, most of the organizations are considering to encrypt all the information they have.

As an encryption program, PGP has turned out to be a common tool for routine encryption to ­provide security. The PGP application helps for modest, informal and complete verification and encryption of files and messages. There are numerous versions of PGP and several different tools that can be used for a wide diversity of operating systems.

PGP is a digital data encryption program shaped by Phil Zimmermann, a special director at ­Computer Professionals for Social Responsibility (CPSR) from 1997 to 2000. Phil Zimmermann ­created PGP to support awareness of the privacy problem in a digital era. Encryption makes the concealed communication possible and one of the resilient encryption tools available is PGP.

13.3.1.1 Working of PGP

In PGP the sender of the E-mail generates two different key values for encrypting and decrypting the E-mail. Among the two keys one key is a public key which is shared with someone to whom the sender wants to exchange E-mail in a secure way. The receivers can use this public key to encrypt the E-mail using any encryption technique.

The next one is a private key, which is guarded by not sharing with anyone. The private key is used to decrypt the data that have been encrypted using public key of the owner (receiver). This means that the message encrypted using public key of owner ‘X’ can only be decrypted by the corresponding private key of ‘X’. The two keys, Key 1 and Key 2 are generated randomly. A key is a block or string of alphanumeric text, letters, numbers and other characters such as !, ?, or %, that is produced by PGP on demand using special key generation algorithms.

13.3.1.2 Functional Operation of PGP

The supreme usage of PGP is to sign and encrypt the E-mail and attachment files. The signing process of a document is used for confirming the integrity of the original file.

The process is as follows:

1. Create a digest or hash value of the file or E-mail using hash algorithm. A hash algorithm is an ­algorithm that produces a unique hash value (output) from a given message (input). In PGP, E-mail is given as message to hash algorithm.
2. Add the hash to the rear of the message. In PGP message and plaintext represents same value.
3. When somebody needs to verify that the message has not been modified, they run the same hash algorithm on the message and match it to the hash value which is placed at the end of the message. If the hash values are equal, then the message has not been changed.

This is demonstrated in the following example:

13.3.1.3 PGP Message Generation

PGP is a hybrid cryptosystem which associates few of the best features of both conventional and ­public key cryptography. When PGP is used to encrypt an E-mail which is considered as a plaintext, it compresses the plaintext first. Data ­compression saves up modem transmission time, disk space and strengthens cryptographic security. Cryptanalysis techniques exploit patterns originate in the plaintext to flaw the ciphertext. Compression ­decreases these patterns in the plaintext, thus prominently increasing resistance to cryptanalysis. The PGP formerly generates a session key, which is a one-time secret key. From the random movements of mouse and the keystrokes of the sender, a random number is generated and used as a key. This session key and fast encryption algorithm are used to encrypt the plaintext and transform it to ciphertext. Once the message is encrypted, the session key is then encrypted using the recipient’s public key. The ciphertext and the encrypted session key are sent to the recipient. Figure 13.6 shows the message generation in PGP.

13.3.1.4 PGP Message Reception

In the receiver side, the temporary session key is retrieved by PGP using the private key of the receiver and it is used to decrypt the conventionally encrypted ciphertext. Working of PGP reception is shown in Figure 13.7.

The mixture of the two encryption methods combine the appropriateness of public key encryption with the speed of conventional encryption. Conventional encryption is about 1000 times faster than public key encryption. Public key encryption in turn delivers a resolution to key distribution and data transmission issues. Used together, performance and key distribution are improved without any loss in security when an E-mail is sent from one place to another place.

13.3.2 Secure/Multipurpose Internet Mail Extensions

The popularity, functionality and necessity of E-mail need secure mail transfer. MIME (Multipurpose Internet Mail Extensions) is an Internet Engineering Task Force (IETF) standard. It is a specification for formatting non-ASCII messages in order to send them through the Internet. E-mail clients like ­Outlook Express handle E-mail messages efficiently with the help of MIME. In Request For ­Comments (RFC1521), the MIME standard defines the syntax for the attachments of E-mail messages. Some of the MIME programs help the user to set their type of attachments for E-mails, how to interpret that messages, how to configure other programs with it. Users are advised to disable the automatic ­E-mail functions like interpretation, execution.

The spam E-mails also look like the E-mails that are sent by the authenticated users which tempt us to open. Internet malpractices like changing the message, spoofing an address, hacking an account are still happening. The technical experts and government organization need secure MIME message for their communication.

S/MIME is a standard that provides a consistent way to send and receive MIME data in an encrypted way through the Internet. It is based on the X.509 certificate standard and ASN.1 (Abstract Syntax Notation) syntax. It allows the user to send the encrypted E-mails with the digital signature. It makes the authenticated recipients to see the messages and ensures that the message has not changed in any circumstance. S/MIME is a protocol used to encrypt and digitally sign E-mail messages. Since many people are involved in E-mail communication, symmetric key cryptosystems (i.e. The same key is used for encryption and decryption) are not practically suitable. The main reason is that, in symmetric key systems, it is required to exchange n(n - 1)/2 keys before sending E-mails to everyone else. But, symmetric key cryptosystems have fast processing abilities compared to asymmetric keys. Due to this advantage, symmetric key cryptosystem is used in S/MIME where a temporary session key is used for providing confidentiality. For providing the facility of key distribution, asymmetric key cryptosystem is also used in S/MIME where permanent keys are used. Normally, S/MIME employs public key cryptography (an asymmetric system) for signing and encrypting E-mails and messages. Therefore, each user in the system receives two keys: A private key, which is maintained as secret and a public key, which is made as public to everyone. The E-mails are encrypted using somebody’s private key for providing authentication and it can be decrypted only using his/her public key. For providing confidentiality, the E-mail message is encrypted using the randomly generated session key. This session key can be encrypted using the public key of the receiver which is called as a digital envelope. When a receiver receives this message, he/she first decrypts the digital envelope using the receivers public key to find the session key. After that the E-mail message is decrypted using the session key.

S/MIME version 1 was developed in 1995 by security vendors. During that period, there was no single standard rather than several competing standard to send secure E-mails. In 1998, two IETF RFCs strengthened S/MIME version 2. RFC 2311 which established the standard for message and RFC 2312 which established the standard for certificate handling. With these RFCs, Version 2 emerged as a standard for message security. Version 3 was introduced in 1999, to enhance its capability. RFC 2311 improved as RFC 2632 and RFC 2312 improved as RFC 2633. RFC 2634 is extended with additional feature like triple wrapping, security labels to provide more security in acknowledgement and in labels. Version 3.1 specifies about compressed data. Version 3.2 provides more interoperability with agents than prior versions. S/MIME ensures authentication, integrity and confidentiality of the E-mail by following Public-Key Cryptography Standard (PKCS #7) syntax. It is used in mail user agents (MUAs) and automated message transfer agents.

13.3.2.1 S/MIME in Mobile OS

With the advancement in telecommunication technology, now S/MIME is used in mobile OS (­operating system) also. The following describes the utility of S/MIME in different mobile OS.

1. IOS (iPhone OS), the Apple’s mobile OS, has features like iMessage, iCloud (personal cloud ­storage), S/MIME, etc. The S/MIME functions can be enabled or disabled for each user account. IOS ­permits to tap the unknown users for later use.
2. Windows phone 8.1 is one of the best smartphones in the market. Though it has several important features like no rootkits, no malware, no jailbreaks ability, etc., secure E-mail data with secure communication makes it worth. The mobile device management capability provides support for S/MIME in outlook express. It adds S/MIME policies with the enterprise policies since it does not need additional software.
3. In Android, the software DJIGZO allows S/MIME. The existing Android application can be connected with DJIGZO to send and receive encrypted E-mails. DJIGZO is used with Gmail applications and it is compatible with other applications like Outlook Express, Thunderbird, etc.
4. Encryption in Mac is done with lock icon and signing with a checkmark icon. When S/MIME is automated, E-mail considers all the certificates found in the keychain.

13.3.2.2 Advantages and Disadvantages of S/MIME

S/MIME is a stable open standard encryption system and can deploy on mobile OS. It is not only meant for E-mail but also can support any MUA, automated message transfer agents and transport mechanisms like HTTP. It takes advantages of object-based features of MIME messages.

Sometimes S/MIME may affect the E-mail functionality in an enterprise like damaging the anti-virus scanners, data loss prevention tools, E-mail archives in retrieval systems, etc. Encryption in S/MIME makes the normal mail search as difficult in certain circumstances. S/MIME certificates are more expensive. Not all E-mail software handles S/MIME signatures. Once the private key or certificate stored is lost, the encrypted messages cannot be decrypted. Apart from that, the S/MIME cannot transmit executable files or data that contains national language characters.

13.3.2.3 Installation of S/MIME

The web-based applications such as Gmail, Yahoo cannot apply S/MIME directly. These services are induced with Internet Message Access Protocol (IMAP) or Post Office Protocol (POP). S/MIME ­installation steps are specified in Figure 13.8. The client machine requests the CA to provide public key and private key. Then they are installed as a .pfx (personal information exchange) file in the ­client machine. Registration Authority is an entity that is responsible for some administrative tasks like ­registration of subject. It verifies the identification of the subject through a trusted authority.

A mechanism to provide certification and authentication should be easy to process. The following steps are to be considered during certificate handling:

1. The third party should provide the certificate.
2. It should be in a sharable format.
3. Issue date and expire date must be considered.
4. It should be flexible with E-mail applications.
5. Use separate keys for digital signature and encryption.
6. It should be easy to verify its validity by the agent.
7. It should be in X.509 format and it should accept PKCS #7 syntax.
8. Reason for issuing, issuer details must also be included.

13.3.2.4 Functionality of S/MIME

The Functionality of S/MIME is explained in this section with respect to authentication and confidentiality services provided by S/MIME.

Authentication in S/MIME

Authentication is an essential security service that must be provided in S/MIME to ensure that the E-mail has come from a legitimate user. For example, when Alice sends an E-mail to bob to transfer $1000 amount, bob must ensure that this E-mail has not come from eve to empty his account. The authentication process used in S/MIME is shown in Figure 13.9.

Sender side:

1. In the Figure 13.9, the sender’s message is denoted as plaintext (P) and the sender hashes the plaintext message (E-mail) using the hash function to produce the hash value.
2. This hash value is encrypted by the sender using its private key (Kr_A) to produce the digital signature.
3. The plaintext of the sender together with the digital signature is then sent to the receiver.

Receiver side:

1. The receiver uses the same hash function on the plaintext to produce the same hash value.
2. The receiver uses the public key of the sender (Ku_A) to decrypt the digital signature to produce the hash value.
3. Finally, the receiver checks the equality of both the newly computed hash value and already received hash value to authenticate the plaintext.

Authentication and Confidentiality in S/MIME

Confidentiality is also an essential security service that must be ensured when an E-mail is sent from one user to another user. Figure 13.10 shows the way in which both authentication and confidentiality services are used in S/MIME.

Sender side:

1. The sender wants to communicate an E-mail (plaintext) with the receiver securely. In the Figure 13.10, the sender’s E-mail is denoted as plaintext (P). The sender hashes her message using the hash function to produce the hash value.
2. The sender uses its private key (Kr_A) to encrypt the hash value to produce the hash code.
3. The sender chooses a 128-bit session key (K_s) to encrypt the plaintext of the sender together with the hash code.
4. The sender encrypts the session key using the public key of the receiver (Ku_B) and produce the ciphertext as

Receiver side:

1. After receiving the cipher text, the receiver first uses its private key (Kr_B) to decrypt the session key.
2. The receiver uses the session key to get the plaintext and the hash code.
3. The receiver uses the same hash function on the plaintext to produce the hash value.
4. The receiver uses the public key of the sender (Ku_A) to decrypt the hash code to produce the hash value.
5. Finally, the receiver checks the equality of both the hash values to authenticate the message.

In this procedure, the session key is used to provide confidentiality and then it can be discarded by the receiver after decrypting the plaintext in the receiver side.

13.4 CASE STUDY

The following subsection discusses a case study of how PGP and S/MIME are used in E-mail security.

13.4.1 Case Study of PGP

In this case study, Alice is the receiver of an encrypted E-mail message, Bob is the transmitter and Eve is the eavesdropper. Alice first wants an encryption key pair. She needs to choose two prime numbers to generate her encryption keys. A prime number can be divided only by itself and the number one, without any remainders. So, Alice picks 7639 and 7919 as prime numbers. She now generates her public key by multiplying these values together to make 60,493,241. Now Alice shares this key or value with everybody but does not disclose the two numbers she formerly chose.

Bob transfers Alice a secure message using her public key composed with his message after processing them with a one-way function. Now Alice is the only one who can decrypt Bob’s message as she only has her private key—only she knows the two values which she used to generate her public key.

If Eve interrupted the message sent to Alice and desired to read it, Eve would have to factor 60,493,241 to discover the two values that were multiplied together. If she worked quickly and could factor four primes a minute, it would take her almost five hours to determine the values of Alice’s ­private key and read the message Bob sent.

13.4.2 Case Study of S/MIME

Almost all E-mail clients like Outlook Express have options to set their encryption algorithms. During the period of Outlook 2010, SHA-256 and SHA-512 were considered as strongest signing algorithm. Later it was found that Whilst options of algorithms are more limited in legacy versions and showed that it may not work well in some situations. But the signing algorithm SHA-1 balances both ubiquitous technology and hash algorithms. The 3DES and AES-256 encryption algorithms can satisfy many of the clients but it is also viable in many circumstances.

For more compatibility, Outlook 2011 designed with SHA-1 signing algorithm and 3DES or AES-256 is considered as an encryption algorithm for greater security. These options are available under preference tab. Mulberry mail users can find the same settings under preference tab. Select ‘Use MIME Multipart Security with PGS’ option to verify and send messages.

Outlook 2007 users can locate their security setting through tools options. Thunderbird users can fix their options for signing and encryption algorithms when it limits the permission to change their settings.

13.5 Secure Hypertext Transfer Protocol

Secure Hyper Text Transfer Protocol (S-HTTP) is a protocol that provides application layer security. It was introduced to work in combination with HTTP that enables the users and the server to connect with the confidentiality and authorized sort of environment. Therefore, S-HTTP provides an additional room to HTTP which permits the secure exchange of data on the World Wide Web. It was introduced in the year 1994 by EIT (Enterprise Integration Technologies). The working of S-HTTP is based on public key cryptography infrastructure. Range of cryptographic algorithms such as DES, International Data Encryption Algorithm (IDEA), RC2 and RSA supports S-HTTP. In working of S-HTTP, it ­encrypts a page that is submitted to the server by encrypting the fields such as post field, header field, etc. Mainly S-HTTP messages are based on four components that are listed as follows:

1. HTTP message
2. Browsers (users) cryptographic choice
3. Servers cryptographic choice
4. Single (or) double-directed security

In the above four components, HTTP message is the actual message that has to be submitted to the server. This HTTP message requires confidentiality and authentication since it passes over an insecure channel. Browser cryptographic choice determines the algorithm used by the browser in which the HTTP message is encrypted. This choice depends upon the browser that the user is using. Moreover, browsers cryptographic choice and the server’s cryptographic choice must be same in such a way that they can correctly encrypt and decrypt the messages. Using the same cryptographic choice, the server decrypts the HTTP message sent by the browser. Direction of security depends on both browser and server and it can be a single/double directions security. Using these four components, the S-HTTP ­securely transfers the messages. S-HTTP header permits the use of digital signatures for authentication and encryption for confidentiality. Inspite of using all these security parameters, the S-HTTP discloses the actual protocol that is used while transferring the message from users to the server and hence this becomes a security flaw in S-HTTP. Owing to this reason, the S-HTTP is less efficient in terms of security when compared with HTTPS. Many web browsers such as Mozilla Firefox, Internet Explorer and Google Chrome, etc. have migrated to HTTPS because of this security constraints.

Key Terms

CMS

Cryptographic choice

DES

Digital certificate

Dual signature

E-commerce

E-mail security

OIMD

PGP

PIMD

POMD

S-HTTP

S/MIME

SET

SHA-1

Summary

• • Secured transactions play a vital role in E-commerce. Online frauds, cryptoanalysis and ­scepticism are crucial issues and need to be considered nowadays. SET is a comprehensive standard that utilizes cryptography to provide confidentiality to payment transaction. It ensures payment integrity and authentication. Authentication is provided to individual participants with digital certificates by the CA. The encrypted message is covered with digital envelope that is digitally signed by the sender ensuring it is sent by him and it is not known by anyone. Message data is encrypted with randomly generated key and it is further encrypted using the recipient’s public key. The recipient decrypts encrypted message using a private key and then uses the symmetric key to unlock the original message. Digital certificates are also called electronic credentials or public key. The digital certificate ensures that the cardholder obtains electronic credentials and is trustworthy. The same happens for merchant also. When the customer purchases goods, then their credentials are exchanged. If both are satisfied, then the transaction occurs. Credentials are renewed in regular intervals to prevent E-fraud.
• • Messaging applications like E-mail could not be completely protected by network security ­measures alone. PGP is widely used protection for E-mail security by casual Internet user community. PGP is a data encryption and decryption protocol that offers cryptographic privacy and authentication for data communication. Encryption of the message is done using public key. The private key is used to decrypt the data that have been encrypted using public key of the owner.
• • S/MIME provides a consistent way to send and receive MIME data in the Internet safely. It secures messages with authentication, provides confidentiality. It ensures guarantee for the message. It is performed in two levels. First level checks the authentication to provide digital sign and to check the digital sign in the receiving time. Private keys play a major role in this level. The algorithm used for this purpose is referred as signing algorithm. The second level handles encryption. These are called encryption algorithms. 3DES and AES-256 are commonly used encryption algorithms. Public keys are used in the encryption level. Private and public keys are provided by the third party in the form of digital certificate. The expense of this certificate diminishes the spectrum of S/MIME considerably.
• • S-HTTP provides an additional room to HTTP which permits the secure exchange of data on the World Wide Web. S-HTTP is less efficient in terms of security when compared with HTTPS.

Review Questions

1. Describe briefly the different web security threats and its countermeasures.
2. What is the need of E-mail security?
3. With a neat diagram, explain the different actors of SET.
4. Explain the functionality of SET in E-commerce.
5. Outline SET operations involved during E-transaction with credit card.
6. John started a tutorial class to handle electronic gadgets easily in a shopping mall. His business runs well. He planned to conduct online classes in Internet and hosted an application. He got a merchant account from national credit card company. To provide more payment options to his customer, he wants to go with PayPal. What are the various kind of operations that happen with PayPal and in its absence? Suggest your overall opinion to John in this scenario.
7. State the basic steps in PGP.
8. Discuss the role of PGP in E-mail security.
9. Give a sample for hash algorithm.
10. What is the role of session key in PGP encryption?
11. Brief the origin of PGP.
12. What is meant by ‘signing’ a document?
13. Explain the importance of random numbers in PGP message generation.
14. List out the components contained in the outcome of PGP encryption.
15. What are the shortcomings of S/MIME, and how can it be rectified?
16. Mention any features to add with S/MIME or enhance any feature of S/MIME and How?
17. Explain cryptographic message syntax.
18. Explain briefly about S-HTTP.