2023年6月27日发(作者：)

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.

1Payment 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

2SET Purchase Transaction

Fig shows what might happen in SET purchase transaction.

Card holder Merchant Gateway Certificate Authority

Certificate

Retrieval

Purchase

13

24

5

76

Authorization

98

10

Capture

11

12

13

Credit

SET Message

Non SET Message

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.

34) 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.

413) 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.

5

Fig 2- Software components of SET

The Merchant Server (POS):

Wallet

Internet

Financial

Networks

Certificate Authority

Certificate Authority

Gateway

Internet

Internet

Merchant Server

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.

6

SET Message

Non SET Message

Browser

4

5WalletMerchant

Server

34

12Merchant

Shopping

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.

75) 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.

HPOMDPIPIMDKRcDual

Signature

HEOI ||

H

Fig 3: Construction of Dual Signature

OIMD

8 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.

DS=Ekrc[H(H(PI)||H(OI))]

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:

H(PIMD||H(OI))andDkuc[DS]

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

H(H(PI)||OIMD)andDkuc[DS]

If these two quantities are equal then the bank has verified the signature.

9

+

PI

E

+

Digital Envelope

Passed on

by

merchant

to

payment

tDual Signature

++

PIMD

E

+

OI

OIMD

KUb

+

Dual Signature

+

Cardholder Certificate

Request Message

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.

Received by

merchant

10Request Message

+

Digital Envelope

Passed on

by

merchant

to

payment

t

+

POMD

H

|| ||

PIMD

+

OI

E OIMD

Compare

+

Dual Signature

D

POMD

+

Cardholder Certificate

KUc

Reference:

Fig 6:

Merchant verifies Customer Purchase Request

11

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

12