The document provides an overview of the Secure Electronic Transaction (SET) protocol. It discusses: - SET is an open encryption standard designed to securely process credit card transactions over the internet. It uses digital certificates and signatures. - Key components of SET include confidentiality of information, integrity of data, cardholder authentication, and merchant authentication. - A SET transaction involves a cardholder, merchant, issuer, acquirer, payment gateway, and certification authority going through an initiate request, initiate response, purchase request, and purchase response process. - Payment authorization and capture are also part of the SET transaction flow. Digital signatures and certificates are used to authenticate parties and messages.

1. Secure
Electronic
Transaction
(SET)
PRESENTED BY
HARSH MEHTA

2. What Is SET?
• SET is an open encryption and security specification designed to protect credit card
transactions on the Internet.
• SET is not itself a payment system. Rather it is a set of security protocols and
formats that enables users to use the credit card payment infrastructure on an
open network, such as the Internet, in a secure fashion.
• It was first used in February 1996 and was proposed by Visa and Master Card. A
wide range of companies were involved in developing the initial specification,
including IBM, Microsoft, Netscape, RSA, Terisa, and Verisign

3. Key Features of SET
• Confidentiality of information.
• Integrity of Data.
• Cardholder account authentication.
• Merchant authentication.

4. Confidentiality of
Information
• A credit card holder’s personal and payment information is secured as it travels
across the network.
• An interesting feature of SET is that the merchant never sees the credit card
number.
•This is only provided to the issuing bank. Conventional encryption using DES is used
to provide confidentiality.

5. Integrity of Data
• Payment information sent from cardholders to merchants include
i. personal information,
ii. payment instructions.
iii. order information.
• SET guarantees that these message contents are not altered in transit. Using SHA-1
hash codes, data integrity provided.

6. Cardholder Account
Authentication
• SET enables merchants to verify that a cardholder is legitimate user of a valid card
account number.
• SET uses X.509v3 digital certificates with RSA signatures for this purpose.

7. Merchant Authentication
• SET enables cardholders to verify that a merchant has a relationship with a
financial institution which allow it to accept payment cards.
• SET uses X.509v3 digital certificates with RSA signatures for this purpose.

8. SET Components and Participants

9. SET Participants
• Cardholder
• Merchant
• Issuer
• Acquirer
• Payment Gateway
• Certification Authority

10. Cardholder & Merchant
Cardholder
◦ This is an authorized holder of a payment card (e.g., MasterCard, Visa) that has been
issued by an issuer.
Merchant
◦ This is a person or organization who has things to sell to the cardholder.
Ex.flipcart,ebay.

11. Issuer & Acquirer
Issuer
◦ This is a financial institution such as a bank that provides the card holder with the payment
card. Ex: mastercard,visa card.
Acquirer
◦ This is a financial institution that establishes an account with the merchant and processes
credit card authorizations and payments.
◦ The acquirer provides authorization to the merchant that a given card account is active.
◦ The Acquirer also provides electronic payments transfers to the merchant’s account.

12. Payment Gateway
• This is a function that can be undertaken by the acquirer that processes merchant
payment messages.
• The payment gateway interfaces between SET and the existing bankcard payment
networks for authorization and payment functions.

13. Certification Authority(CA)
• This is an entity that is entrusted to issue X.509v3 public-key certificates for
cardholders, merchants, and payment gateways.

14. SET Transactions

15. Events required for a
Successful SET
Transaction
The customer opens an account with a card issuer.
◦MasterCard, Visa, etc.
The customer receives a X.509 V3 certificate signed by a bank.
◦X.509 V3
A merchant who accepts a certain brand of card must possess two X.509 V3
certificates.
◦One for signing & one for key exchange
The customer places an order for a product or service with a merchant’s website.
The merchant sends a copy of its certificate for verification.

16. Events required for a
Successful SET Transaction
Cont’d
The customer sends order and payment information to the merchant.
The merchant requests payment authorization from the payment gateway prior to
shipment.
The merchant confirms order to the customer.
The merchant provides the goods or service to the customer.
The merchant requests payment from the payment gateway.

17. SET’s Dual Signature
The purpose of the dual signature is to link two messages that are going to
different recipients.
◦ Order Information (OI): Customer to Merchant
◦ Payment Information (PI): Customer to Bank
The customer needs to send OI and PI to merchant and bank respectively.
The merchant does not need to know the customers credit card number.
The bank does not need to know what the customer is buying.
however the two items must be linked in a way that can be used to resolve
disputes if necessary.

18. Dual Signature
The operation for dual signature is as follows:
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)) ]

19. DS Verification by Merchant
• The merchant has the public key of the customer obtained from the customer’s
certificate.
• Now, the merchant can compute two values:
H(PIMD || H(OI))
DKUC[DS]
• Should be equal!

20. DS Verification by Bank
• The bank is in possession of DS, PI, the message digest for OI (OIMD), and
the customer’s public key, then the bank can compute the following:
H(H(PI) || OIMD)
DKUC [ DS ]

21. purchase request exchange consists of four messages:
1. Initiate Request
2. Initiate Response
3. Purchase Request
4. Purchase Response
Purchase Request

22. Initiate Request
Basic Requirements:
◦ Cardholder Must Have Copy of Certificates for Merchant and Payment
Gateway
Customer Requests the Certificates in the Initiate Request
Message to Merchant
◦ Brand of Credit Card
◦ ID Assigned to this Request/response pair by customer.
◦ nonce(timestamp) used to ensure timeliness.

23. Initiate Response
Merchant Generates a Response
• Signs with Private Signature Key.
• Transaction ID for Purchase Transaction
• Merchant’s Signature Certificate
• Payment Gateway’s Key Exchange Certificate
• the nonce from the customer
• another nonce for the customer to return in the next message

24. Purchase Request
Cardholder Verifies Two Certificates(merchant and gateway) Using
Their CAs and Creates the OI and PI.
First SET Message Includes:
◦Purchase-related Information
◦Order-related Information
◦Cardholder Certificate

25. Purchase Request –
Customer

26. Purchase Request –
Merchant

27. Purchase Response
Message
Message that Acknowledges the Order and References Corresponding
Transaction Number
Response Block is
◦Signed by Merchant Using its Private Key
◦Block and Signature Are Sent to Customer Along with Merchant’s
Signature Certificate
Upon Reception
◦Verifies Merchant Certificate
◦Verifies Signature on Response Block
◦Takes the Appropriate Action

28. Payment Process
The payment process is broken down into two steps:
◦Payment authorization
◦Payment capture

29. Payment Authorization
The merchant sends an authorization request message to the
payment gateway consisting of the following:
Purchase-related information
◦PI
◦Dual signature calculated over the PI & OI and signed with
customer’s private key.
◦The OI message digest (OIMD)
◦The digital envelop

30. Continue..
◦Authorization-related information
An authorization block including:
◦A transaction ID
◦Signed with merchant’s private key
◦Encrypted one-time session key
◦Certificates
◦Cardholder’s signature key certificate
◦Merchant’s signature key certificate
◦Merchant’s key exchange certificate

31. Payment Gateway
Authorization
• verifies all certificates
• decrypts digital envelope of authorization block to obtain symmetric key & then
decrypts authorization block
• verifies merchant's signature on authorization block
• decrypts digital envelope of payment block to obtain symmetric key & then decrypts
payment block
• verifies dual signature on payment block
• verifies that transaction ID received from merchant matches that in PI received
(indirectly) from customer
• requests & receives an authorization from issuer
• sends authorization response back to merchant

32. Authorization Response
Authorization Response Message
◦Authorization-related Information
◦Capture Token Information
◦Certificate