Scribd
Upload
112 views11 pages

Unit 4 Secure Electronic Transaction

Unit 4 describes the Secure Electronic Transaction (SET) protocol, which was developed in 1996 to securely facilitate online credit card transactions. SET uses digital certificates and digital signatures to authenticate parties and protect sensitive payment information. The protocol specifies a process where the customer's payment information is sent to the payment gateway instead of the merchant, so the merchant does not learn card details. Both the customer and merchant digitally sign linked order and payment messages to confirm the relationship between them.

Uploaded by

downloadsrk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
112 views11 pages

Unit 4 Secure Electronic Transaction

Unit 4 describes the Secure Electronic Transaction (SET) protocol, which was developed in 1996 to securely facilitate online credit card transactions. SET uses digital certificates and digital signatures to authenticate parties and protect sensitive payment information. The protocol specifies a process where the customer's payment information is sent to the payment gateway instead of the merchant, so the merchant does not learn card details. Both the customer and merchant digitally sign linked order and payment messages to confirm the relationship between them.

Uploaded by

downloadsrk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

Unit 4

SET
• open encryption & security specification
• to protect Internet credit card transactions
• developed in 1996 by Mastercard, Visa etc Mastercard Visa 1996
• not a payment system
• rather a set of security protocols & formats
• secure communications amongst parties
• trust from use of X.509v3 certificatesX.509v3
• privacy by restricted info to those who need it
• Merchant does not get to know the credit card details of the
cardholder

• Requires software set up on the client as well as server


1. customer opens account
2. customer receives a certificate
3. merchants have their own certificates
4. customer places an order
5. merchant is verified
6. order and payment are sent
7. merchant requests payment authorization
8. payment gateway authorizes payment
9. merchant confirms order
10. merchant provides goods or service
11. merchant requests payment
• customer creates dual messages
order information (OI) for merchant
– payment information (PI) for bank
• neither party needs details of other

• but must know they are linked

• use a dual signature for this


– signed concatenated hashes of OI & PI
1. Purchase-related information
（a) PI
DS[PI+OI]
OIMD
(b)All above are encrypted with K
(c)Digital envelope is created by encrypting K with the payment gateway’s
public key
2. Order-related information
QI
DS[PI+OI]
PIMD
3. Cardholder certificate
PI H PIMD

H POMD E
+

OI H OIMD
Dual Signature
(DS)

Fig 6.31
Please verify the Please verify the
cardholder’s certificate merchant’s certificate
Certificate
Authority
Group
You can act as a CA You can act as a CA

Certificate Certificate
Authority Authority
A B

Request for Merchant’s Cardholder’s Request for


a certificate Certificate Certificate a certificate

Purchase Response
Merchant Cardholder
Purchase Request

Authorization Request

Payment
Gateway
Authorization Response
Issue SSL SET

Main aim Exchange of data in an E-commerce related payment


encrypted form mechanism
Certification Tw o p a r t i e s e x c h a n g e All the involved parties must
certificates be certified by a trusted third
party
Authentication Mechanisms in place, but not Strong mechanisms for
very strong authenticating all the parties
involved
Risk of merchant fraud Possible, since customer gives U n lik e ly, s i n c e c u s t o m e r
financial data to merchant gives financial data to
payment gateway
Risk of customer fraud Possible, no mechanisms exist Customer has to digitally
if a customer refuses to pay sign payment instructions
later
Action in case of customer Merchant is liable Payment gateway is liable
fraud
Practical usage High Low at the moment, expected
to grow

You might also like