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.
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.
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 ]
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
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
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
The customer takes the hash (using SHA-1) of the PI and the hash of the OI, concatenates them, and hashes the result. Finally,the customer encrypts the final hash with his or her private signature key, creating the dual signature. This can be summarized as: DS=E(PRc, [H(H(PI)||H(OI))])
Stallings Figure 17.10 shows the details of the contents of the Purchase Request message generated b y the customer.
The message includes the following:
Purchase-related information, which will be forwarded to the payment gateway by the merchant and consists of: PI, dual signature, & OI message digest (OIMD).
2. Order-related information, needed by the merchant and consists of: OI, dual signature, PI message digest (PIMD).
3. Cardholder certificate. This contains the cardholder’s public signature key.
The Purchase Response message includes a response block that acknowledges the order and references the corresponding transaction number. This block is signed by the merchant using its private signature key.The block and its signature are sent to the customer, along with the merchant’s signature certificate.
During the processing of an order from a cardholder, the merchant authorizes the transaction with the payment gateway (step 3 in merchants list previously).
The payment authorization ensures that the transaction was approved by the issuer, guarantees the merchant will receive payment, so merchant can provide services or goods to customer.
The payment authorization exchange consists of two messages: Authorization Request and Authorization response.
The payment gateway performs the tasks shown on receiving the Authorization Request message.