07 SET Secure Electronic Transaction__ By Rupesh Jain

SET Secure Electronic Transaction
Abstract
With the business of ecommerce booming, more and more sensitive transaction information is being passed around on the web. Even using secure channel, Credit card information are constantly at risk of being stolen from merchant side. The purpose of this paper is to discuss salient features of Secure Electronic Transaction protocol to avoid this problem.
Introduction
SET is a protocol designed to ensure that merchant and cardholders can conduct business over insecure networks.
SET uses cryptography to provide confidentiality and security ,ensure payment integrity, and authenticate both the merchant and the cardholder .this security means that merchants are protected from purchases with an authorized payment card and can deny purchases to cardholders are protected from merchant imposters or theft of their of their payment card numbers.
SET Roles
The participants listed below plays an important role in a SET Transaction
Card Holder: The cardholder is analogous to the average person who uses a payment card to purchase goods or services
Merchant: This is the business or organization who sells goods or services to the cardholder in the case of a SET transaction over the internet.
Issuer: The issuer is a financial institution that provides the cardholder with payment card. The issuer responsibility to guarantee payment on behalf of its cardholder.
Acquirer: The acquirer is the financial institution that processes payment card authorizations and payment for the merchant. The acquirer’s responsibility is to obtain payment authority from the cardholder’s issuer.
Payment Gateway: A payment gateway is an institution that works on the behalf of the acquirer to process the merchant’s payment messages, including payment instruction from the cardholders. The gateway bridges communication between SET and the existing credit card.
Certificate Authority: The certificate authority provides certification for the merchant, cardholder, and payment gateway. Certification provides a means of assuring that the parties involved in a transaction
•The diagram is from IBM ITSO Secure Electronic transactions
SET Purchase Transaction
Fig shows what might happen in SET purchase transaction.
Card holder Merchant Gateway Certificate Authority
Fig 1: Basic transaction flow
1)
The gateway obtains the certificates it need from the certificate authority.
2)The merchant obtain from the certificate authority.
3)The cardholder obtains its certificates from the certificate authority.
4)The cardholder shops at the merchant’s shopping experience and decides what
goods or services he /she wishes to buy.
5)The merchant sends the cardholder certificates needed in the purchase transaction.
6)The cardholder sends a request to purchase the item that he/she has selected. This
message contains information about and the cardholders order and the cardholder’s payment information – such as the cardholder’s card information.
The merchant gets the order information and sends the cardholder’s payment card information onto the payment gateway. The merchant is never privy to the cardholder’s payment information and therefore has no way of obtaining the cardholder’s payment information payment card information. This security measure is designed to protect the cardholder.
7)The merchant and payment gateway share authorization information. This
consists of the merchant sending the payment gateway information such as the cardholder’s payment card information and the amount the transaction. The payment gateway can either authorize or decline the transaction based on the information received from the merchant later, no money changes hands during the authorization phase.
8)The merchant sends a message to the cardholder ‘finalizing’ the transaction. The
card-holder sees this at the end of the transaction.
9)This step is optional but allows the merchant to change or eliminate money
authorized in step #7.
10)The merchant and the gateway share capture information. A request is send from
the merchant to the gateway to capture money that has been authorized- this capture request can be for a single authorization amount or multiple amounts. The gateway processes the capture request through its existing payment card financial network.
11)If an error has occurred capturing cardholder funds, messaging between the
merchant and the gateway takes place in order to reverse the capture. This step is optional and only happens if there has been a capture error has been occurred. 12)The merchant and payment gateway exchange messages in order to credit a
cardholder’s account.
13)If a credit has been granted by mistake the merchant and payment gateway can
exchange message in order to reverse the granted credit.
SET Software Components:
Each of the participants in the SET transaction uses a piece of software that works on their behalf to perform transaction. Basically four participants can be involved: the cardholder, the merchant, the certificate authority and the banking institutions.
The brief list of the software components
The Wallet – the front end for the cardholder
The Merchant Server – the merchant’s SET Software
The Certificate Authority – handles the SET participant’s certificates
The Gateway – bridges the merchant with its acquirer legacy systems
The Wallet:
A wallet is the cardholder’s SET application. If the cardholder wishes to purchase goods or services from a SET-enabled merchant, he/she needs to have a wallet. The wallet allows the card –holder to make secure payment card transactions over the internet using SET protocol.
It is a plug –in program that is separate from your browser, but works in conjunction with your browser to perform certain tasks. The wallet performs the task of handling the cardholder’s SET purchase.
Fig 2- Software components of SET
The Merchant Server (POS):
A merchant server, or point of sale (POS), is the merchant’s SET software –it is the link between the merchant and the cardholders SET software, and the merchant and the financial payment gateways.
1)The cardholder browses the merchant’s shopping experience. The Web pages that
are part of the shopping experience present a ‘virtual catalog’ of goods and services the merchant has for sale to the cardholder. The cardholder selects the items that he/she wishes to purchase.
2)The cardholder selects to pay for the goods and services selected, usually by
clicking a ‘pay now’ button on a webpage.
3)The shopping experience informs the merchant server of the details of the
transaction.
4)The merchant server sends a message to the cardholder via the shopping
experience for starting the wallet.
5)The wallet and merchant server process the transaction according to the rules of
the set .At this point ,other entities start to get involved (the gateway , the acquiring bank etc) but this is the beginning of the actual SET transaction
The Certification Authority
A certificate authority is responsible for issuing digital certificates serve to identify participants in a SET transaction; therefore certificate authorities are responsible for guaranteeing that the individuals or organizations that have the certificates are who claim to be.
A certificate authority is generally a third party organization, and is not associated with the other entities involved in the SET transaction. The certificate authority grants certificates to the card holder (wallet), the merchant (merchant server), and the merchant’s issuing bank (gateway).
SET uses Dual Signature
The purpose of the dual signature is to link two different recipients. In online transaction
1)The Order Information is send to the merchant.
2)The Payment Information is send to the Bank.
Fig 3: Construction of Dual Signature
PI = Payment Information PIMD = PI message digest OI = Order Information OIMD = OI message digest
H = Hash Function (SHA -1) POMD = Payment Order message digest || = Concatenation E = Encryption (RSA) KRc = Customers private signature Key
As from the fig, the customer sends the merchant two messages – a signed OI and a signed PI – and the merchant passes on to bank. To keep the OI and PI integrated, the customer takes the hash (using SHA-1) of the PI and the hash of the OI. These two hashes are then concatenated and the hash of the result is taken. Finally, the customer encrypts the final hash with his or her private signature key, creating the dual signature.
()()()[]
OI H PI H H Ekrc DS ||=
Where krc is the customer’s private signature key
Case 1: Merchant is in possession of the dual signature, OI, the message digest for the PI
(PIMD) and the public key of the customer taken from customer certificate. Using this merchant can compute the following two quantities:
()()[]DS andDkuc OI H PIMD H ||
Where kuc is the customer customer’s public signature key.
If these two quantities are equal then merchant has verified the signature.
Case 2: Bank is in possession of the dual signature, PI, the message digest for the OI
(OIMD) and the public key of the customer taken from customer certificate. Using this bank can compute the following two quantities
()()[]DS andDkuc OIMD PI H H ||
If these two quantities are equal then the bank has verified the signature.
Fig 5: Cardholder sends Purchase Request
All of the above items are encrypted with Ks. The final item is the Digital envelope. This is formed by encrypting payment gateway public key-exchange key. Digital envelope must be opened (decrypted) before the other items listed previously can be read. The value of the Ks is not available to the merchant. Therefore the merchant cannot read any
of this payment related information.
Fig 6: Merchant verifies Customer Purchase Request
Reference:
1)Section 17.3 Secure Electronic Transactions in Cryptography and Network
Security
2)Using SET for Secure Electronic Commerce .Upper Saddle River
3)IBM Red Book :Credit Card Payment on the web in theory and practice。