| content |
 |
This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed. (August 2007) |
Secure Electronic Transaction (SET) is a standard protocol for securing credit card transactions over insecure networks, specifically, the Internet. SET is not itself a payment system, but rather a set of security protocols and formats that enables users to employ the existing credit card payment infrastructure on an open network in a secure fashion.
SET was developed by VISA and MasterCard (involving other companies such as GTE, IBM, Microsoft, Netscape, RSA and VeriSign) starting in 1996. SET is based on X.509 certificates with several extensions. SET makes use of cryptographic techniques such as digital certificates and public key cryptography to allow parties to identify themselves to each other and exchange information securely. SET uses a blinding algorithm that, in effect, lets merchants substitute a certificate for a user's credit-card number. This allows traders to credit funds from clients' credit cards without the need of the credit card numbers.
SET was heavily publicized in the late 1990's as the credit card approved standard, but 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, adequate SSL based alternative.
- Client-side certificate distribution logistics.
SET was said to become the de facto standard of payment method on the Internet between the merchants, the buyers, and the credit-card companies. When SET is used, the merchant itself never has to know the credit-card numbers being sent from the buyer, which provide a benefit for e-commerce.
Contents |
The SET Protocol
People today pay for online purchases by sending their credit card details to the merchant. A protocol such as SSL or TLS keeps the card details safe from eavesdroppers, but does nothing to protect merchants from dishonest customers or vice-versa. SET addresses this situation by requiring cardholders and merchants to register before they may engage in transactions. A cardholder registers by contacting a certificate authority, supplying security details and the public half of his proposed signature key. Registration allows the authorities to vet an applicant, who if approved receives a certificate confirming that his signature key is valid. All orders and confirmations bear digital signatures, which provide authentication and could potentially help to resolve disputes.
A SET purchase involves three parties: the cardholder, the merchant, and the payment gateway (essentially a bank). The cardholder shares the order information with the merchant but not with the payment gateway. He shares the payment information with the bank but not with the merchant. A set dual signature accomplishes this partial sharing of information while allowing all parties to confirm that they are handling the same transaction. The method is simple: each party receives the hash of the withheld information. The cardholder signs the hashes of both the order information and the payment information. Each party can confirm that the hashes in their possession agrees with the hash signed by the cardholder. In addition, the cardholder and merchant compute equivalent hashes for the payment gateway to compare. He confirms their agreement on the details withheld from him.
SET is a family of protocols. The five main ones are cardholder registration, merchant registration, purchase request, payment authorization, and payment capture. There are many minor protocols, for example to handle errors. SET is enormously more complicated than SSL, which merely negotiates session keys between the cardholder’s and merchant’s Internet service providers. Because of this complexity, much of which is unnecessary, the protocol is hardly used. However, SET contains many features of interest:
* The model is unusual. In the registration protocols, the initiator possesses no digital proof of identity. Instead, he authenticates himself by filing a registration form whose format is not specified. Authentication takes place outside the protocol, when the cardholder’s bank examines the completed form. * The dual signature is a novel construction. The partial sharing of information among three peers leads to unusual protocol goals. * SET uses several types of digital envelope. A digital envelope consists of two parts: one, encrypted using a public key, contains a fresh symmetric key K and identifying information; the other, encrypted using K, conveys the full message text. Digital envelopes keep public-key encryption to a minimum, but the many symmetric keys complicate the reasoning. Most verified protocols distribute just one or two secrets.
Business requirements
Book 1 of the SET specification lists the following business requirements for secure payment processing with credit cards over the Internet and other networks:
- Provide confidentiality of payment and ordering information
- Ensure the integrity of all transmitted data
- Provide authentication that a cardholder is a legitimate user of a credit card account
- Provide authentication that a merchant can accept credit card transactions through its relationship with a financial institution
- Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an electronic commerce transaction
- Create a protocol that neither depends in transport security mechanisms nor prevents their use
- Facilitate and encourage interoperability among software and network providers
Key features
To meet the business requirements, SET incorporates the following features:
- Confidentiality of information
- Integrity of data
- Cardholder account authentication
- Merchant authentication
Participants
A SET system includes the following participants:
- Cardholder
- Merchant
- Issuer
- Acquirer
- Payment gateway
- Certification authority
Transaction
The sequence of events required for a transaction are as follows:
- The customer obtains a credit card account with a bank that supports electronic payment and SET
- The customer receives an X.509v3 digital certificate signed by the bank.
- Merchants have their own certificates
- The customer places an order
- The merchant sends a copy of its certificate so that the customer can verify that it's a valid store
- The order and payment are sent
- The merchant requests payment authorization
- The merchant confirms the order
- The merchant ships the goods or provides the service to the customer
- The merchant requests payment
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.
See also
External links
- Secure Electronic Transactions: An Overview
- More information on SET
- Secure data transaction standard
