Secure Electronic Transaction (SET)

• A standard protocol for securing credit card transactions over the insecure Internet.
• Developed by Visa and MasterCard, in conjunction with IBM.
➢ Data confidentiality: Without data confidentiality, consumer protection cannot
be guaranteed
➢ Authentication: Without authentication, neither the merchant nor the consumer
can be sure that valid transactions are being made.
• A protocol such as SSL keeps the card details safe from eavesdroppers, but does
nothing to protect customers from dishonest merchants.
S/MIME PGP SET
HTTP FTP SMTP
Kerberos
SSL or TLS SMTP HTTP
UDP TCP
TCP
IP
IP

(a) Transport level (b) Application level

Location of Security Facilities in the TCP/IP Protocol Stack

1
Services provided by SET
• A secure communications channel among all parties involved in a transaction
• Authentication by digital certificates
• Privacy because the information is only available to parties in a transaction when and
where necessary

Requirements
• Provide confidentiality of payment and ordering information:
o Assure cardholders that their information is safe and accessible only to the
intended recipient.
o SET uses DES to provide confidentiality.
• Ensure the integrity of all transmitted data:
o Ensure that no changes in content occur during transmission of SET messages.
o RSA digital signatures using SHA-1 hash codes
• User authentication: provide authentication that a cardholder is a legitimate user of a
credit card account
o A mechanism that links a cardholder to a specific account number reduces the
incidence of fraud
o Digital certificates with RSA signatures.

2
 • Merchant authentication: provide authentication that a merchant can accept credit
card transactions through its relationship with a financial institution
o Cardholders need to be able to identify merchants with whom they can conduct
secure transactions.
o Digital certificates with RSA signatures.

SET provides only one choice for each cryptographic algorithm.

3
SET Participants

Cardholder: an authorized holder of a payment card (e.g., MasterCard, Visa) that has been
Secure Electronic Commerce Components
issued by an issuer.
Payment gateway: a function operated by the acquirer that processes merchant payment
messages. The payment gateway interfaces between merchant and the payment networks for
authorization and payment functions.

4
SET Transactions

Customer
• Opens an account with “issuer”
• Customer’s public key certificate.

Mechant
• Mechant’s Public Key Certificate
• A copy of Payment Gateway’s Key
Exchange Certificate

5
Dual Signature for SET
• Link Two Messages Intended for two different receivers:
– Order Information (OI): Customer to Merchant
– Payment Information (PI): Customer to Bank
• Goal: Limit Information to A “Need-to-Know” Basis:
– Merchant does not need credit card number.
– Bank does not need details of customer order.
- The merchant passes the payment information (PI) to the bank.
– Afford the customer extra protection in terms of privacy by keeping these items
separate. However, the two items must be linked in a way that can be used to resolve
disputes if necessary.
• This link is needed to prove that payment is intended for this order and not some other
one.
Example: if the merchant captures another order information (OI) from this customer,
the merchant could claim this order goes with the payment information (PI) rather than the
original.
The linkage prevents this. Also, merchant and bank authenticate the cardholder with the
signature.

6
Dual Signature Operation (DS)

–Take the hash (SHA-1) of the payment and order information.

–These two hash values are concatenated [H(PI) || H(OI)] and then the result is hashed.
–Customer encrypts the final hash with a private key creating the dual signature.
DS = EKRC [ H(H(PI) || H(OI)) ]

7
DS Verification by Merchant

• Suppose that the merchant is in possession of the dual signature (DS), the OI, and the message
digest for the PI, H(PI).

• The merchant has the public key of the customer obtained from the customer’s certificate.

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

• The merchant can compute two values:

H(H(PI) || H(OI))
DKUc[DS]
D: Decryption KUc: customer’s public key

• If these two quantities are equal, then the merchant has verified the signature of customer.

8
DS Verification by Bank
If the bank is in possession of DS, PI, the message digest for OI, and the customer's public
key

H(H(PI) || H(OI)) and DKUc [DS]

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

What did we accomplish?

1. The merchant has received OI and verified the signature.
2. The bank has received PI and verified the signature.
3. The customer has linked the OI and PI and can prove the linkage.

9
SET Transactions

10
Purchase Request
(1) Initiate Request
(2) Initiate Response
(3) Purchase Request
(4) Purchase Response
Initiate Request
• Requires customer must have certificates of merchant and payment gateway
• Customer sends the following to merchant
– Brand of Credit Card
– ID assigned to this request/response pair by customer
– Nonce: random number used once to ensure timeliness

Initiate Response• Merchant generates a response signed with private key

– Nonce from Customer
– Nonce from Merchant
– Transaction ID for Purchase Transaction
• In Addition …
– Merchant’s Public Key Certificate
– Payment Gateway’s Key Exchange Certificate
The customer
• Verifies the merchant and payment gateway certificates by means of their respective CA signatures
• Creates the OI and PI.

11
 • The transaction ID assigned by the merchant is placed in both the OI and PI.

Purchase Request Message

• Purchase-related Information
• Order-related Information
1. Purchase-related information. This information will be forwarded to the payment gateway by the
merchant and consists of
• The PI
EKS • The dual signature
• The OI message digest (OIMD): needed for the payment gateway to verify the dual signature.

Ks is a one-time symmetric encryption key generated by the customer.

• The digital envelope. This is formed by encrypting Ks, with the payment gateway's public
key-exchange key. It is called a digital envelope because this envelope must be opened
(decrypted) before the other items listed previously can be read.

The value of Ks, is not made available to the merchant. Therefore, the merchant cannot read any of this
payment-related information.

12
13
2. Order-related information
• The PI message digest (PIMD)
• The OI
• The dual signature
• Customer certificate.

Merchant Verifies Purchase Request 1. Verifies the customer certificates by means of its CA
signatures.
2. Verifies the dual signature using the customer's public key certificate. This ensures that the
order has not been tampered with in transit and that it was signed using the cardholder's private key.
3. Processes the order and forwards the payment information to the payment gateway for
authorization.
4. Sends a purchase response to the cardholder.

14
Purchase Response Message
• Message that acknowledges the order and references corresponding transaction number
• Block is
–Signed by merchant using its private key
–Block and signature are sent to customer along with merchant’s Public Key Certificate

• Upon Reception
–Verifies merchant certificate
–Verifies signature on response block
–Takes the appropriate action
displaying a message to the user or updating a database with the status of the order.

Payment Process
– Payment authorization
During the processing of an order from a customer, the merchant authorizes the transaction with
the payment gateway. The payment authorization ensures that the transaction was approved by the
issuer.
This authorization guarantees that the merchant will receive payment; the merchant can therefore
provide the services or goods to the customer.

15
– Payment capture: obtain payment from issuer of the customer

Payment Authorization• The merchant sends an authorization request message to the payment
gateway consisting of the following:
– Purchase-related information
• PI
• Dual signature
• The OI message digest (OIMD)
• The digital envelop
– Authorization-related information
• An authorization block

16
 –A transaction ID (assigned by the merchant and placed in both the OI and PI).
--Signed with merchant’s private key
–Encrypted by one-time session key generated by the merchant.
• A digital envelope. Formed by encrypting the one-time key with the payment gateway's public
key from its key exchange certificate.
– Certificates
• Customer’s public key certificate (used to verify the dual signature)
• Merchant’s public key certificate (used to verify the merchant's signature)
• Merchant’s key exchange certificate (needed in the payment gateway's response).

Payment: Payment GatewayThe payment gateway performs the following tasks:

1. Verifies all certificates
2. Decrypts the digital envelope of the authorization block to obtain the symmetric key and then
decrypts the authorization block
3. Verifies the merchant's signature on the authorization block
4. Decrypts the digital envelope of the payment block to obtain the symmetric key and then
decrypts the payment block
5. Verifies the dual signature on the payment block
6. Verifies that the transaction ID (an item in PI) received from the merchant matches that in the PI
received (indirectly) from the customer. (They should both refer to the same transaction).
7. Requests and receives an authorization from the issuer of the customer.

17
Having obtained authorization from the issuer of the customer, the payment gateway returns an
Authorization Response message to the merchant.

Authorization Response
1.Authorization-related information.
- An authorization block, signed with the gateway's private key and encrypted with a one-time
symmetric key generated by the gateway.
- A digital envelope that contains the one-time key encrypted with the merchant’s public
key-exchange key.

2. Certificate. The gateway's public key certificate.

With the authorization from the gateway, the merchant can provide the goods or service to the
customer.

Payment Capture

To obtain payment, the merchant engages the payment gateway in a payment capture transaction
• Capture Request

18
• Capture Response.

Capture Request
• The merchant generates, signs, and encrypts a capture request block (the payment amount
and the transaction ID) with one-time symmetric key.
• A digital envelope that contains the one-time key encrypted with the payment gateway’s
public key-exchange key.
• The message also includes the merchant's public key and key-exchange key certificates.

When the payment gateway receives the capture request message

• It decrypts and verifies the capture request block.
• It creates a clearing request that is sent to the issuer of the customer over the private
payment network. This request causes funds to be transferred to the merchant's account in
acquirer.
• It notifies the merchant of payment in a Capture Response message.

Capture Response
• A capture response block that the gateway signs and encrypts with one-time symmetric
key.
• A digital envelope that contains the one-time key encrypted with the merchant’s public

19
 key-exchange key.
• The gateway's public key certificate.
The merchant software stores the capture response to be used for reconciliation with payment received
from his bank.

SSL and SET

Two main standards for secure financial transactions over the Internet

At the present time, almost all online credit card orders involve the SSL protocol, because Microsoft
Internet Explorer feature built-in support SSL for online transactions.

How does SET differ from SSL?

The bank card company gets involved in the middle of the transaction, essentially acting as middleman.
The commerce site might never see your actual credit card number. Instead, that info would go to the
financial institution, who would verify the card and the amount, then make payment to the commerce
site.
SSL encrypts the communication channel between the cardholder and the merchant website and is not backed by any financial
institution. As a result, SSL is unable to ensure the security of a transaction. SET was created with the sole purpose of securing and
ultimately guaranteeing a payment transaction

20