Secure Electronic Transaction
Secure Electronic Transaction (SET) was a communications protocol standard for securing credit card transactions over insecure networks, specifically, the Internet. SET was not itself a payment system, but rather a set of security protocols and formats that enabled users to employ the existing credit card payment infrastructure on an open network in a secure fashion. However, it failed to gain attraction in the market. VISA now promotes the 3-D Secure scheme.
History and development
SET was developed by the SET Consortium, established in 1996 by VISA and MasterCard in cooperation with GTE, IBM, Microsoft, Netscape, SAIC, Terisa Systems, RSA, and VeriSign. The consortium’s goal was to combine the card associations' similar but incompatible protocols (STT from Visa/Microsoft and SEPP from MasterCard/IBM) into a single standard.
The first review draft of the protocol was published February 1996 and the v1.0 standard document was published in May 1997. Although there were several attempts to update or revise the protocol, no official version was produced beyond 1.0. An official reference implementation developed by Terisa Systems was announced in 1997.
In December 1997 Visa and MasterCard created an independent company, SET Secure Electronic Transaction LLC (a.k.a. SETco), announcing American Express and JCB as cooperating members. SETco managed the development and deployment of the protocol and was responsible for branding and certification. Unofficial and informal interoperability testing among vendors occurred during 1997. Formal pilot tests began in 1998, but they were reportedly problematic.
SET allowed parties to identify themselves to each other and exchange information securely. Binding of identities was based on X.509 certificates with several extensions. SET used a cryptographic 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 payment method on the Internet between the merchants, the buyers, and the credit-card companies. Despite heavy publicity to win market share, it failed to gain widespread use. Reasons for this include:
- Network effect - need to install client software (an e-wallet).
- Cost and complexity for merchants to offer support, contrasted with the comparatively low cost and simplicity of the existing SSL based alternative.
- Client-side certificate distribution logistics.
To meet the business requirements, SET incorporates the following features:
- Confidentiality of information
- Integrity of data
- Cardholder account authentication
- Merchant authentication
A SET system includes the following participants:
The sequence of events required for a transaction is as follows:
- The customer places an order with the merchant.
- The merchant sends the customer his public key and a copy of his certificate so that the customer can verify that it's a valid store.
- The customer sends the merchant:
- His certificate.
- His order details, unencrypted.
- His bank account details encrypted with the bank's public key.
- The merchant requests payment authorization by sending the bank:
- The payment details encrypted with the bank's public key.
- The customer's bank account details encrypted with the bank's public key.
- Note that the merchant doesn't know the client's payment and bank account details.
- The bank sends the merchant a confirmation encrypted with the merchant's public key.
- The merchant sends the client the bank's response encrypted with the client's public key.
- The merchant ships the goods or provides the service to the customer.
- The merchant sends the bank a transaction request encrypted with the bank's public key.
- The bank transfers the payment to the merchant.
As described in (Stallings 2000):
An important innovation introduced in SET is the dual signature. The purpose of the dual signature is to link 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 customer is afforded extra protection in terms of privacy by keeping these two items separate. However, the two items must be linked in a way that can be used to resolve disputes if necessary. The link is needed so that the customer can prove that this payment is intended for this order and not for some other goods or service.
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.
Stallings, William (Nov 1, 2000). "The SET Standard & E-Commerce". Dr. Dobbs.
SET Secure Electronic Transaction Specification (V1.0) Book 1 (PDF). Mastercard and Visa. May 1997.
SET Secure Electronic Transaction Specification (V1.0) Book 2 (PDF). Mastercard and Visa. May 1997.
SET Secure Electronic Transaction Specification (V1.0) Book 3 (PDF). Mastercard and Visa. May 1997.
External Interface Guide to SET Secure Electronic Transaction (PDF). Mastercard and Visa. September 1997.