Web Security

Internet based applications are very popular and widely used in E-commerce activities. These
are extremely vulnerable to various threats and attacks. This chapter presents two important
security protocols used in the Internet for facilitating commerce i.e., these protocols are mainly
related with E-commerce related activities for example, smooth payment to the merchant over
web, railway reservation, online payment of telephone bills, use of credit/debit cards etc. The
first protocol is Secure Socket Layer (SSL) and the second one is Secure Electronic
Transaction (SET). The former is concerned with providing security services to the
applications that use TCP as the underlying protocol and hence functions between TCP and
application layer. Its Internet standard version is referred to as Transport Layer Security (TLS).
Therefore, the protocol is commonly referred as SSL/TLS. SSL/TLS protects messages of two
users (sender and receiver) via symmetric encryption and message authentication code. The
latter protocol i.e., SET is used for securing credit card transactions. Both these protocols are
discussed and presented in details in this unit.

SECURITY THREATSFACED BY WEB

On web, the user uses client software (browser) to access the server software (web server).
An important issue in the web is to understand the notion that the web security requirements
are different from the normal computer and network security requirements. This can be
understood from the following [1]:
 The traditional publishing environment is not prone to severe security threats. In
comparison, the electronic publishing on the web (via web servers) is exposed to
severe threats and attacks.
 The corporate try to keep product information and business transactions safe while
providing the controlled information outflow via website but in the unsafe web
environment their reputation and money can be affected via compromise of Web
servers by the attackers.
 Web browsers, web servers and web contents are easy to manage and their
functionality is well understood by the less technical users. This is not the case with
the underlying code which is usually complex (not easily understood by the users who
operate upon) and as such may hide many potential security flaws at several locations.
Thus, many a times, new, properly installed and safe systems are easily subverted by
the attackers who find flaws in code to break or intrude the systems.
 A compromised web server may be used by the attacker to intrude or gain access to
data and systems not part of the web itself but connected to the server locally.
 Novice and untrained users who interact with servers using browsers are usually
unaware of the security risks, security tools and effective countermeasures.
Thus, web related threats and attacks are to be analyzed separately and therefore, thissection
is dedicated to overview of web security threats.

As classified in unit 1, web related threats are classified into: active and passive.

Active attacks target - website alteration, message alteration between client and server, user
impersonation etc.

Passive attacks target - eavesdropping on web traffic, restricted website information leakage
etc.
The web threats target mainly integrity, confidentiality, availability and authentication.

Integrity threats use modification strategies to endanger user data, memory contents and
message traffic in transit. These may result in loss of information, compromise of machine
and vulnerability to other threats. Such threats are nullified by applying cryptographic
checksums.

Confidentiality threats use sniffing, eavesdropping and theft strategies to endanger server
information, client information (regarding which client/user is talking to server), network
configuration details and client’s communicated data. These may result in loss of
information and loss of privacy. Such threats are nullified by applying encryption and using
web proxies.

Denial of Service threats consider killing of user threads, flooding of a machine with bogus
requests, filling up disk or memory, isolation of machine by DNS attacks to hamper
availability. These may disrupt the user’s work and may cause user annoyance. These
threats can be detected but are difficult to nullify and prevent.

Authentication threats use spoofing, impersonation and forgery to endanger the

authenticity. These may result in acceptance of false information and misrepresentation of
user. Such threats are nullified by applying cryptographic checksums.

WEB TRAFFIC PROTECTION METHODS

Web related threats are also classified depending upon location of the threat: Web server,
Web browser, and web traffic between browser and server. First two falls under computer
system security.

Web Traffic Security approaches differ depending upon their relative position in the
protocol stack. The approaches fall under following three categories [2]:
(1) Using IP security (IPSec) below TCP (Figure 1(a)). This has following advantages:
 IPsec is a general-purpose solution.
 It is transparent to end users and applications.
 Use of filtering in IPSec implies less processing overhead is required.
 HTTP FTP SMTP HTTP FTP SMTP

TCP SSL or TLS

IP/IPSec TCP/IP

(a) Network Level (b) Transport Level

S/MIME SET

Kerberos SMTP HTTP

UDP TCP

IP

(c) Application Level

Figure 1 Various methods for web security and their relative position in the TCP/IP
Protocol Stack

(2) Using Secure Sockets Layer (SSL)/Transport Layer Security (TLS) above TCP
(Figure 1b). SSL/TLS can be implemented as part of the underlying protocol suite or
it can be embedded in specific packages e.g. web browsers and servers can embed
SSL. In former implementation, SSL remains transparent to the applications.
(3) Embedding the security methods within the particular application (Figure 1c). In this
case application-specific security method can be tailored as per the application’s
requirements. For example, SET* on top of HTTP for securing credit card
transactions, S/MIME on top of SMTP for securing E-mail services.

* This is a common implementation; it is also possible that SET makes use of TCP directly in some other implementation.

OVERVIEW OF SECURE SOCKET LAYER PROTOCOL

Secure Socket Layer (SSL) is one of the most popular Web security mechanisms, following
are some of the interesting facts regarding SSL protocol:
 SSL is implemented as a transport layer security service.
 It was originally developed by Netscape.
 It’s version 3 (SSLv3) was designed by taking public and industry input.
  Upon reaching a consensus, TLS working group was formed in IETF for developing
the Internet standard and hence it was subsequently named as TLS (Transport Layer
Security). The first TLS version is essentially represented as SSLv3.1
 It uses TCP to provide a reliable end-to-end service.
 SSL does not represent a single protocol but various protocols at two layers as shown
in the SSL Protocol stack (Figure 2).

The SSL Record Protocol lies above TCP and provides basic security services to various
higher-layer protocols like Hypertext Transfer Protocol (HTTP).

Three higher-layer protocols that manage SSL exchanges exist as part of SSL. These are:
the Handshake Protocol, Change Cipher Spec Protocol, and Alert Protocol [2-4].

SSL Handshake SSL Change SSL Alert HTTP

Protocol Cipher Spec Protocol
Protocol

SSL Record Protocol

TCP/IP

Figure 2 SSL Protocol stack

SSL Architectural Design

SSL maintains connection and session:
 SSL Connection: A connection is built to provide a particular type of service. It is a
transient, peer-to-peer relationship. It is associated with a session.
 SSL Session: The Handshake Protocol creates an association between a client and a
server which is termed as SSL session. A Session defines a set of cryptographic
security parameters. These security parameters can be shared among multiple
connections thereby avoiding negotiation of new security parameters for each
connection.
A pair of parties (e.g. HTTP client application and server) may have multiple secure
connections.
There are a number of states associated with each session. Each state has set of parameters
for both receive (read) and send (write). The Handshake Protocol creates pending read and
write states during its execution and after its successful completion, the pending states are
copied to the current states.
Record Protocol Services in SSL
SSL Record Protocol is mainly used to provide confidentiality and message integrity. These
services are provided for each SSL connections. The secret keys required for these services
are exchanged and evolved during Handshake Protocol. Confidentiality is provided through
encryption of SSL payload by using various ciphers while message integrity is provided
through message authentication code (MAC).

The entire operation of SSL Record Protocol is shown in Figure 3.The Record Protocol
fragments the application message into manageable blocks of fragments. The fragments
may optionally be compressed. The protocol then computes MAC (similar to HMAC),
concatenates MAC with the fragment. It is then followed by message encryption using
shared symmetric secret key. The header (Fig 4) containing SSL details, major/minor
version, and compressed length is added to the message before putting it into the TCP
segment. Receiver performs decryption, MAC verification, decompression, and
reassembling of fragments before delivering the message to application layer.

Fragmentation of Application Data takes place

Fragment 1 Fragment i
…. ….

Fragment compressed

Addition of MAC to
compressed fragment

Encryption of both MAC &

message fragment

Addition of SSL
Record Header

Fig 3 Operations (in sequences) of SSL Record Protocol

 Fig 4 Record Format of SSL Protocol

The three SSL-specific protocols utilize the SSL Record Protocol. These protocols are SSL
Change Cipher Spec Protocol, SSL Alert Protocol, SSL Handshake Protocol. These are
discussed next.

(a) Change Cipher Spec Protocol of SSL

1 byte
1 byte 1 byte
1 Level Alert
(a) Change Cipher Spec Protocol (b) Alert Protocol

1 byte 3 bytes  0 bytes

Type Length Content

(c) Handshake Protocol

Figure 5 SSL Record protocol

The Change Cipher Spec Protocol is the simplest among the three SSL-specific protocols
utilizing SSL Record Protocol. It has a single message having a single byte (Fig 5 (a))
which is initialized to a value of 1. The message causes copying of pending state into the
current state. Thus, main intension of this protocol is to update the cipher suite of the
connection.

(b) Alert Protocol of SSL

This protocol is meant for conveying the alerts (related with SSL) to the peers. The alert
messages are compressed and encrypted in accordance with the current connection state.
The protocol message (Fig 5 (b)) has two bytes, the first byte indicates level of alert i.e., it
conveys the severity of the message. The permitted values in first byte are: warning (1) or
fatal (2). The second byte is used for indicating the specific alert via codes. These can be
listed as:
 Fatal alerts: unexpected message, bad record MAC, decompression failure, handshake
failure, illegal parameter.
 Warnings: close notify, no certificate, bad certificate, unsupported certificate,
certificate revoked, certificate expired, certificate unknown.

(c) Handshake Protocol of SSL

SSL Handshake Protocol is used between client and server before sending any data for the
following purposes:
 Server & client authentication to each other.
 Negotiation between server & client for deciding encryption & MAC algorithms.
 Negotiation of cryptographic keys to be used for encryption & MAC calculations.
The protocol’s message consists of 3 fields: type (1 byte), length (3 bytes) and content (≥ 0
byte).
The Handshake Protocol has 4 phases (Fig 6) during which several messages are exchanged
between client and server. These can be briefly described as:
 Establishment of Security Capabilities (Phase 1) - The client initiates a logical
connection with server. In this phase, client sends client_hello whereas server replies
with server_hello for exchanging the security capabilities to be associated with SSL
connection.
 Server Authentication and Key Exchange (Phase 2) - The server sends negotiation
parameters (key exchange values) to the client and server certificate for
authentication.
 Client Authentication and Key Exchange (Phase 3) - The client verifies the server
certificate and checks that the server parameters are acceptable.
 Finish (Phase 4) – Both client and server exchange ‘finish’ and ‘change_cipher_spec’
messages. Both copies the pending CipherSpec into the current CipherSpec. This
completes the handshake and setting up of a secure connection. Now onwards, the
client and server may engage themselves in secure data transfer.
 Phase 1

Phase 2
Phase 3

Client Phase 4 Server

Phase 1

Initialization and Establishment of security capabilities between

Client and Server. This includes sharing of protocol version, session
ID, cipher suite, compression method and initial random numbers
with each other

Phase 2

After establishing initial capabilities, Server may send (i) Its own
certificate (ii) Key exchange parameters and (iii) Its request for Client
certificate ((i), (ii) and (iii) are optional or situation-dependent
messages). Towards end, Server signals end of hello message phase.

Phase 3

Depending upon Server’s request for certificate, Client sends its

certificate (optional or situation-dependent message) along with its own
key exchange parameters. Client may also send certificate verification
status (optional or situation-dependent message) to indicate that the
sever certificate is verified

Phase 4

Both Client and Server exchange their cipher suite specifications to

confirm initially exchanged cipher suite specifications. Both update their
state including keys updates. Finished messages exchanged in the end
indicate (to each other) regarding finishing of handshake protocol.

Fig 6 Handshake Protocol

 Cryptographic Computations
During SSL Handshake, a shared master secret is evaluated via key exchange. Based upon
the shared master secret, other cryptographic parameters like keys for encryption and MAC
are also evaluated.
Using secure key exchange, a one-time 48-byte value (384 bits) termed as shared master
secret is calculated. The creation is in two stages. Using either RSA or Diffie-Hellman key
exchange, first - a pre_master_secret is exchanged, second - based upon this
pre_master_secret a master_secret (shared master secret key) is calculated as:

master_secret=MD5(pre_master_secret||SHA('A'||pre_master_secret||ClientHello.random||Se
rverHello.random))||MD5(pre_master_secret||SHA('BB'||pre_master_secret||ClientHel
lo.random||ServerHello.random))||MD5(pre_master_secret||
SHA('CCC'||pre_master_secret||ClientHello.random||ServerHello.random))

Here, ClientHello.random and ServerHello.random represents the client and server nonce
values exchanged via initial hello messages.
A, BB, CCC represents constant values.

This shared master secret key is calculated by both the peers.

CipherSpecs require client’s and server’s: MAC secret, symmetric encryption key and
initial vector (IV). All of these are generated from the master secret by hashing the master
secret and then selecting the sequence of sufficient length.

TLS (Transport Layer Security)

TLS is standardization initiative for SSL. It is defined in RFC 2246. RFC 2246 is similar to
SSLv3, with small differences like change in record format version number, use of HMAC
for MAC calculation, use of pseudo-random function for expanding secrets, use of
additional alert codes, some changes in supported ciphers, changes in certificate types &
negotiations and changes in crypto computations & padding [2-5].
OVERVIEW OF SECURE ELECTRONIC TRANSACTION
PROTOCOL

Secure Electronic Transaction (SET) provides security specifications describing set of

security protocols and formats for credit card transactions over the Internet.

The original specification was developed by group of companies like IBM, Microsoft,
Netscape, RSA, Terisa, and Verisign upon a call from MasterCard and Visa in the mid
90s.This specification (summing to a total of 971 pages) was written in three books (in
1997) namely, Business Description, Programmer's Guide and Formal Protocol
Definition.By the year 1998, the SET complaint products were available.

SET provides three services: secure communication, trust and privacy. As many parties are
involved during communication, SET uses secure communication channel between them for
securing the data exchange. It uses X.509v3 digital certificates for providing trust. It
provides information to only the trusted parties involved in the transaction for enhancing
privacy [2][6][7].

SET defines business requirements, features, and the participants for secure credit card
transactions and processing. These are presented next.

SET Business Requirements

The following business requirements are imposed on SET protocol:
(i) Provide confidentiality to both: payment and ordering information.
(ii) Provide data integrity to each and every data packet.
(iii) Linkage between user of card and his account such that it is ensured that user of the
card is legitimate and that he own the corresponding account.
(iv) Linkage between merchant and his financial institution such that it is ensured that
merchant can accept transaction via credit card.
(v) Use of best available security practices and system design techniques for protecting
the users and their transactions.
(vi) The protocol should function separately independent of any existing security methods.
(vii) The protocol should assist and support the interoperability issues.

For meeting (i) and (ii) SET uses encryption and digital signatures thereby ensuring:
All information between the communicating parties is safe, authentic and is accessible only
by the authorized users. This also reduces the chances of fraud by either sender or receiver
or by any third party.

For meeting (iii) and (iv) digital signatures and digital certificates are used. Thus, card
holders only identify the merchants for transactions while the merchants have confidence
that the card holder is not fake and has an associated account.

For meeting requirement (v), SET uses well tested, reliable and highly secure algorithms.
For meeting requirement (vi), SET functions independently i.e., without interfering with
IPSec and SSL/TLS. For meeting requirement (vii), SET defines formats and methods that
are independent of any hardware or software.
Striking Features of SET
The striking features of SET can be listed as:
 Information Confidentiality: In SET, DES symmetric encryption is used to protect the
following information from access by others.
(i) Cardholder account and other details.
(ii) Payment information.
(iii)Cardholder's credit card number; even merchant is prevented from learning it. The
number is supplied only to the issuing bank.
 Data Integrity: For protecting the payment information sent from cardholders to
merchants by any alterations, SET uses either RSA digital signatures with SHA-1 or
HMAC using SHA-1.
 Cardholder account authentication: SET enables merchants to verify that a cardholder
is a legitimate user of a valid card account number. SET uses X.509v3 digital
certificates with RSA signatures for this purpose.
 Merchant authentication: SET enables cardholders to verify that a merchant has a
relationship with a financial institution allowing it to accept payment cards. Again,
SET uses X.509v3 digital certificates with RSA signatures for this purpose.
In comparison to IPSec and SSL/TLS, SET does not give any options for selecting among
various cryptographic algorithms. This is due to the fact that SET is a single application and
is specifically used for one purpose that of securing credit card based transactions whereas
IPSec and SSL/TLS support a range of applications and provides general security to
applications.

SET Participant Details

SET has 06 participants (Figure 7) [2]. These are:
 Cardholder (also termed as consumer or purchaser)- owns a credit card (e.g.,
MasterCard, Visa) issued by an issuer and is responsible for interaction with merchant
via Internet enabled devices.
 Merchant (may be a person or an organization) - enjoys relationship with an acquirer
and who has goods or services to sell on Internet (via website or by E- mail). He
accepts payment cards of the cardholders.
 Issuer (financial institution - a bank) - who is responsible for the payment of the debt
of the cardholder. Issuer opens the account and issues the payment card to the
cardholder.
 Acquirer (financial institution) - establishes an account with a merchant and eases the
merchant’s work by dealing with multiple bankcard associations or with multiple
individual issuers. Thus, merchant is not supposed to interact and involve in
transaction with different individual issuers.
The functions/processing provided by the acquirer are:
(1) Inform the merchant that the (i) given card account is active and (ii) proposed
purchase does not exceed the credit limit.
(2) Provides electronic transfer of payments to the merchant's account. These
electronic funds transfers are later reimbursed by the issuer using payment
network.
 Payment gateway(either acquirer or a designated third party fits in this role) -
processes merchant payment messages. The merchant interacts with the payment
gateway (via SET message) over the Internet. The payment gateway links (directly or
indirectly) to the financial processing system of the acquirer.
  Certification authority (CA)(or a hierarchy of CAs) - who is a trusted third party that
issues public-key certificates (X.509v3) for all other major parties (cardholders,
merchants, and payment gateways) in SET.

Purchase of items
Merchant

Cardholder

Internet

Certificate
Authority (CA)

Payment
gateway
Payment
Issuer network

Acquirer

Figure 7 Participants (Components) in a Secure Electronic Commerce

STEPS involved in SET use are:

1. The first step is opening of customer account in a bank that supports electronic
payment/SET and obtaining credit card (MasterCard, Visa etc.) for payment.
2. Bank issues a digital certificate (X.509v3) to the customer after verifying the
customer’s identity. The certificate is signed by the bank and it contains customer's
RSA public key along with the expiration date. It establishes a relationship between
the customer's key pair and credit card.
3. Merchants own two certificates for two different public keys: one for signing
messages and other for key exchange. They also keep payment gateway's public-key
certificate.
4. The customer browses the merchant's Web site and selects items. The selected list of
items is send to the merchant or submitted online. The merchant replies with an order
form containing order number & associated details (list of items, their price and total
price) along with its digital certificate.
5. The customer verifies the merchant using merchant’s certificate.
6. The customer sends certificate and order form to the merchant for confirming the
purchase of the items. The merchant confirms the customer via certificate and
considers the order. Customer also sends payment information (containing credit card
 details) in encrypted form to the merchant. The encryption is done so that merchant
cannot read payment related information.
7. The merchant forwards the payment information to the payment gateway for verifying
- whether the customer has available credit to make the current purchase or not.

Dual Signature (DS) = Encryption of payment order message digest (POMD) using customer’s
private signature key (KC)
= EKC ( POMD )

POMD = Hash of (PI message digest (PIMD) concatenated with OI message digest (OIMD))
= H(PIMD||OIMD)

PIMD = Hash of PI = H(PI) PIMD OIMD

OIMD = Hash of OI = H(OI)
||

Hash
POMD

Encrypt using KC

Dual Signature

8. Upon verification of the customer’s request at the payment gateway, merchant sends
order confirmation.
9. The merchant provides the demanded goods or service to the customer.
10. The merchant requests to the payment gateway regarding payment processing.

Figure 8 Process of creating a Dual Signature

Concept of Dual Signature (DS)

One of the major requirements of SET is that the customer’s order information should not
be visible to the bank and the payment information (e.g., customer's credit card number)
should not be visible to merchant. For this requirement, SET introduces the concept of dual
signature (Figure 8). The dual signature is used to link two messages of two different
recipients (Bank and merchant). The message corresponding to order information (OI) is
send to the merchant whereas message corresponding to the payment information (PI) is
send to the bank. The following is ensured:
(1) The merchant remains unaware of the PI and the bank remains unaware of details of
the customer's order (OI).
(2) The customer privacy is enhanced by keeping PI and OI separate.
(3) OI and PI are linked with each other and hence can be used under dispute cases. Using
this linkage the customer can prove that PI corresponds to this OI and not for some
other order. Thus, linkage eliminates the confusion that a particular PI forwarded by
merchant to bank corresponds to which of the OI’s (in case different orders are given
by same customer to this merchant).
As shown in Figure 12.8, the process of purchase of goods and services is initiated by the
customer who takes individual hashes of PI and OI, then concatenates them and again takes
the hash of the resultant. The final hash is encrypted with customer’s private key and this
finally encrypted hash is termed as dual signature (DS). Considering KC as the customer's
private key, DS is calculated as:
DS = E K [H(H(PI)||H(OI))]
C

Processingof Payment in SET

SET supports many transaction types, major among them are:

Purchase request: Customer’s message to merchant. It contains order and purchase

information.

Payment authorization: Refers to merchant and payment gateway interactions for

authorizing a purchase via a given credit card account for payment amount.

Payment capture: Refers to merchant’s request to the payment gateway regarding payment.
These are considered next in details.

Purchase Request Transaction in SET

Steps taken in the preliminary phase between customer and merchant without involving
SET:
(i) Customer performs browsing, selecting, and ordering of goods/services to merchant.
(ii) Merchant returns a completed order form.

The entire purchase request (SET enabled) interaction involves four messages. The
customer having credit card also requires public key certificates of the merchant and the
payment gateway. For this first two messages i.e., Initiate Request and Initiate Response are
used.

Initiate Request: Customer’s message requesting the merchant’s certificate. It includes:

The brand of the credit card – required to link at the time of payment with the card issuer.
An ID - to indentify the request and its corresponding response.
A nonce - to ensure timeliness and must be returned by merchant in the reponse.

Initiate Response: Merchant’s reply message containing signed response (signed by

merchant using his private key) and certificates. It is includes:
The customer’s nonce – to indicate that this response corresponds to previous request.
A fresh nonce - to ensure timeliness and must be returned by customer in the next message.
A transaction ID – to identify the purchase transaction.
This message also includes merchant and payment gateway certificates.

Purchase Request: Customer’s Purchase Request messagegiven to merchant.

Preprocessing:
(i) Customer verifies the merchant and gateway certificates using CA signatures
(ii) Creates the OI and PI containing transaction ID (send by the merchant in Initiate
Response)
(iii)An order reference generated in the preliminary phase before starting the SET enabled
interaction.
After completing preprocessing tasks, the customer/cardholder generates a one-time
symmetric encryption key, KS and creates Purchase Request message (Fig 9) containing:
1. Purchase-related information to be forwarded to the payment gateway by the
merchant and it contains the following:
(i) The PI.
(ii) The Dual Signature (DS).
(iii) The OI Message Digest (OIMD).
(i), (ii) and (iii) are encrypted using one time secret key Ks.
The OIMD is used to verify the DS. The bank possesses DS, PI, OIMD along with
the customer's public key and can calculate:
(i) H(H[PI]||OIMD)
(ii) D P (DS) where, Pc is the customer’s public key and D stands for decryption.
C

If (i) and (ii) are equal, the DS is verified by the bank.

The key Ks is encrypted using payment gateway's public key and is hence, hidden
from the merchant. Thus, merchant cannot read PI. The encrypted Ks is termed as
digital envelope as it must be decrypted for reading other items in the message.
2. Order-related information required by the merchant and it consists of the following:
(i) The OI, send in clear without encryption.
(ii) The DS.
(iii)The PI Message Digest (PIMD).

The PIMD is used to verify the DS. The merchant possesses DS, OI, PIMD along
with the customer's public key and can calculate:
(i) H(PIMD||H[OI])
(ii) D P (DS) where, PC is the customer’s public key and D stands for decryption.
C

If (i) and (ii) are equal, the DS is verified by the merchant.

3. Cardholder public key certificate required by merchant and payment gateway.
From (1) – (3), it is clear that:

1. The merchant receives OI and verifies DS.

2. The bank receives PI and verifies DS.
3. The customer ensures the linkage between OI and PI and can prove it later. Also,
neither merchant nor bank can change this linkage by changing either OI or PI
 Request message for merchant

Encrypted purchase related information

I
Encrypted (purchase info) PI, Dual Signature
(DS) and Order Info Message Digest
(OIMD).Encryption done using temporary
symmetric key (KS)
 EK ( PI  DS  OIMD )
S

(I + II) to be
+
passed to
Digital Envelope payment gateway
II by merchant
Encrypted KS
Encryption done using Bank’s public key -
exchange key (PB)
 E PB ( K S )

+
III
(Purchase Information Message Digest (PIMD))
OI + DS + card holder certificate

Figure 9 A Cardholder Purchase Request details

Processing steps executed by the merchant upon receiving the Purchase Request message
(Fig 10):
1. Verification of the cardholder’s certificates by verifying CA signatures and extraction
of customer’s public key.
2. Verification of the DS (using the customer's public key), indicating that the message
was indeed sent by the customer and is not tampered in between.
3. OI processing and forwarding of the PI to the payment gateway for authorization.
4. Reply the customer via purchase response.
 Customer’s request message for merchant

Encrypted Purchase relate information + PIMD + OI + DS + Cardholder certificate

+ Digital Envelope

Calculate Hash of OI Extract PC

= H (OI)
Calculate Hash of concatenated = OIMD
PIMD & OIMD
= H (PIMD||OIMD) Decrypt DS using extracted P C
= POMD Compare = POMD

PIMD = PI Message Digest

OIMD = OI Message Digest
OI = Order Information
DS = Dual Signature
PC = Customer’s public signature key

Figure 10 Verification of Customer Purchase Request by Merchant

Purchase Response: Merchant sends purchase response message to customer which

contains:
(i) a response block and (ii) merchant's signature certificate. Former is signed by merchant
using his private key and is used to acknowledge the purchase order. It also contains the
transaction number. Latter contains the merchant’s key which is used to verify the
signature.

Upon receiving the purchase response message, customer verifies the merchant's certificate.
It is then followed by verification of the merchant signature on the response block.
Customer may display the message or update the order status based on the response
conveyed via response block.

Payment Authorization Transaction in SET

The payment authorization is a process governed by payment gateway and it ensures (i)
approval of the transaction by the issuer and (ii) surety regarding payment to the merchant.

Because the transaction is approved by the gateway, the merchant can supply services or
goods to the customer. The payment authorization involves: Authorization Request message
and Authorization Response message. Former is send by merchant to the payment gateway
while latter is send by payment gateway to the merchant.

The Authorization Request message contains:

1. Purchase-related information received from the customer containing PI, DS, OI
message digest (OIMD) and digital envelope.
2. Authorization-related information generated by the merchant having an authorization
block and a digital envelope. Former has the signed transaction ID encrypted with a
one-time symmetric key generated by the merchant. The transaction ID is signed
 using merchant's private signature key. Latter contains one-time symmetric key
encrypted by payment gateway's public key-exchange key.
3. Three Certificates: customer’s/cardholder's signature key certificate (for verifying
DS), the merchant's signature key certificate (for verifying merchant's signature), and
the merchant's key-exchange certificate (to be used in payment gateway's response).

Upon receiving Authorization Request, the payment gateway executes following operation
sequence:
1. All three certificates are verified.
2. Decrypts the digital envelope payment gateway's private key-exchange key.
3. Obtains the symmetric key from digital envelope and then decrypts the authorization
block to obtain signed transaction ID.
4. Verifies the merchant's signature from the signed transaction ID.
5. As done in step 3 extract the symmetric key from digital envelope of the payment
block and use it to decrypt the payment block.
6. Verifies the DS from payment block
7. Compares the transaction ID received from the merchant with that received from the
customer via PI.
8. Upon successful comparison, requests an authorization from the issuer.
9. Upon receiving authorization from the issuer, gateway creates and sends an
Authorization Response message to the merchant.
The Authorization Response includes the following elements:
1. Authorization-related information generated by the payment gateway having the
signed authorization block and digital envelope. Signature on authorization block
done using gateway's private signature key while encryption is done using a one-time
symmetric key generated by the gateway. The one-time symmetric key is encrypted
by merchant’s public key-exchange key to form the digital envelope.
2. Capture token information having a signed, encrypted capture token and a digital
envelope. This token is returned as such by the merchant for payment in the payment
request.
3. Gateway's signature key certificate.
After being authorized from the gateway, the process of goods or service delivery to the
customer can proceed ahead.

Payment Capture Transaction in SET

For receiving payment, the merchant and gateway exchanges - capture request and a capture
response message (together termed as Payment Capture Transaction).

The Capture Request message is created by the merchant and it contains: (i) Capture request
block having payment amount and the transaction ID. This capture request block is signed
and encrypted, (ii) Encrypted capture token received via Authorization Response from the
gateway and, (iii) Merchant's signature key and key-exchange key certificates.

Upon receiving Capture Request message, the payment gateway - decrypts and verifies (i)
the capture request block and (ii) the capture token block. Both capture request and capture
token are checked for consistency of information. A clearing request is sent depending upon
success of checking to the issuer over the private payment network for transferring the
funds to the merchant's account.
Finally, the gateway sends payment notification to the merchant using Capture Response
message which contains (i) a signed and encrypted capture response block and, (ii)
gateway's signature key certificate. The capture response is stored by the merchant
(software) for future reconciliation with the acquirer’s details regarding payment [2].