Secure Electronic Transaction

From Wikipedia, the free encyclopedia

  (Redirected from Secure electronic transaction)
Jump to: navigation, search

Secure Electronic Transaction (SET) was a standard protocol 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 enables users to employ the existing credit card payment infrastructure on an open network in a secure fashion. However, it failed to gain traction.

SET was developed by SETco, led by VISA and MasterCard (and involving other companies such as GTE, IBM, Microsoft, Netscape, RSA and 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

[edit] 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 payment gateway 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 envelopes. 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.

[edit] 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

[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:

[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 an 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.

[edit] References

Retrieved from "http://en.wikipedia.org/wiki/Secure_Electronic_Transaction"
Personal tools