Scribd
Upload
49 views2 pages

Secure Electronic Transaction

SET was a security standard developed in the 1990s for securing credit card transactions over the internet. It used digital certificates and encryption to authenticate parties and securely transmit payment information without revealing credit card numbers. However, SET failed to gain widespread adoption due to the need for additional client software, high costs for merchants, and complex certificate distribution. It was intended to be the standard for online payments but lost out to simpler SSL-based alternatives.

Uploaded by

Aashish Sutar
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
49 views2 pages

Secure Electronic Transaction

SET was a security standard developed in the 1990s for securing credit card transactions over the internet. It used digital certificates and encryption to authenticate parties and securely transmit payment information without revealing credit card numbers. However, SET failed to gain widespread adoption due to the need for additional client software, high costs for merchants, and complex certificate distribution. It was intended to be the standard for online payments but lost out to simpler SSL-based alternatives.

Uploaded by

Aashish Sutar
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Secure Electronic Transaction

From Wikipedia, the free encyclopedia

Secure Electronic Transaction (SET) was a standard protocol for securing credit card transactions over insecure networks, specifically, theInternet. SET was not

itself a payment system, but rather a set of security protocols and formats that enable users to employ the existing credit card payment infrastructure on an open

network in a secure fashion. However, it failed to gain traction. VISA now promotes the 3-D Secure scheme.

SET was developed by SETco, led by VISA and MasterCard (and involving other companies such as GTE, IBM, Microsoft, Netscape, RSAand VeriSign) starting

in 1996. SET was based on X.509 certificates with several extensions. The first version was finalised in May 1997 and a pilot test was announced in July 1998.

SET allowed parties to cryptographically identify themselves to each other and exchange information securely. SET used a blinding algorithm that, in effect, would

have let merchants substitute a certificate for a user's credit-card number. If SET were used, the merchant itself would never have had to know the credit-card

numbers being sent from the buyer, which would have provided verified good payment but protected customers and credit companies from fraud.

SET was intended to become the de facto standard of payment method on the Internet between the merchants, the buyers, and the credit-card companies.

Despite heavy publicity, it failed to win market share. Reasons for this include:

 Network effect - need to install client software (an e-wallet).

 Cost and complexity for merchants to offer support and comparatively low cost and simplicity of the existing SSL based alternative.

 Client-side certificate distribution logistics.


Contents

 [hide]

1 Key

features

2 Particip

ants

3 Transact

ion

4 Dual

signature

[edit]Key features

To meet the business requirements, SET incorporates the following features:

 Confidentiality of information

 Integrity of data

 Cardholder account authentication

 Merchant authentication
[edit]Participants

A SET system includes the following participants:

 Cardholder

 Merchant

 Issuer

 Acquirer

 Payment gateway

 Certification authority

[edit]Transaction

The sequence of events required for a transaction are as follows:

1. The customer obtains a credit card account with a bank that supports electronic payment and SET

2. The customer receives a X.509v3 digital certificate signed by the bank.

3. Merchants have their own certificates

4. The customer places an order

5. The merchant sends a copy of its certificate so that the customer can verify that it's a valid store

6. The order and payment are sent

7. The merchant requests payment authorization

8. The merchant confirms the order

9. The merchant ships the goods or provides the service to the customer

10. The merchant requests payment

[edit]Dual signature

An important innovation introduced in SET is the dual signature. The purpose of the dual signature is the same as the standard electronic signature: to guarantee

the authentication and integrity of data. It links two messages that are intended for two different recipients. In this case, the customer wants to send the order

information (OI) to the merchant and the payment information (PI) to the bank. The merchant does not need to know the customer's credit card number, and the

bank does not need to know the details of the customer's order. The link is needed so that the customer can prove that the payment is intended for this order.

The message digest (MD) of the OI and the PI are independently calculated by the customer. The dual signature is the encrypted MD (with the customer's secret

key) of the concatenated MD's of PI and OI. The dual signature is sent to both the merchant and the bank. The protocol arranges for the merchant to see the MD

of the PI without seeing the PI itself, and the bank sees the MD of the OI but not the OI itself. The dual signature can be verified using the MD of the OI or PI. It

doesn't require the OI or PI itself. Its MD does not reveal the content of the OI or PI, and thus privacy is preserved.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy