The SET Standard & E-Commerce

The Secure Electronic Transaction (SET) is an open encryption and security specification designed to protect credit-card transactions on the Internet.


November 01, 2000
URL:http://www.drdobbs.com/the-set-standard-e-commerce/184404309

Nov00: The SET Standard & E-Commerce

William is a consultant, lecturer, and author of books on data communications and computer networking. His most recent book is Operating Systems: Internals and Design Principles, Fourth Edition (Prentice Hall, 2000). He can be contacted at williamstallings.com or [email protected].


Secure Electronic Transaction (SET) is an open encryption and security specification (available at http:// www.setco.org/) designed to protect credit-card transactions on the Internet. The current version, SET 1.0, emerged from a call for security standards by MasterCard and Visa in February 1996. A wide range of companies were involved in developing the initial specification, including IBM, Microsoft, Netscape, RSA, Terisa, and Verisign. Beginning in 1996, there have been numerous tests of the concept, and by 1998, the first wave of SET-compliant products was available.

SET is not itself a payment system. Rather, it is a set of security protocols and formats that enables users to employ the existing credit-card payment infrastructure on an open network, such as the Internet, in a secure fashion. In essence, SET provides three services:

The SET Scene

SET involves interaction among credit-card holders, merchants, issuing banks, payment processing organizations, and public-key certificate authorities. SET is a complex specification defined in three "books" (also available for download at http:// www.setco.org/), including a programmer's guide, issued in May of 1997 and running nearly 1000 pages. SET incorporates important features needed for secure credit-card transactions over the Internet:

SET Participants

Figure 1 illustrates the participants in the SET system, which includes:

SET in Action

SET is a dynamic, automated scheme that lets customers with a credit card order items over the Internet from merchants in a secure fashion. A typical scenario goes like this:

1. The customer opens an account. The customer obtains a credit-card account, such as MasterCard or Visa, with a bank that supports electronic payment and SET.

2. The customer receives a certificate. After suitable verification of identity, the customer receives an X.509v3 digital certificate, which is signed by the bank. The certificate verifies the customer's RSA public key and its expiration date. It also establishes a relationship, guaranteed by the bank, between the customer's key pair and his or her credit card.

3. Merchants have their own certificates. A merchant who accepts a certain brand of card must be in possession of two certificates for two public keys owned by the merchant: one for signing messages, and one for key exchange. The merchant also needs a copy of the payment gateway's public-key certificate.

4. The customer places an order. This is a process that may involve the customer first browsing through the merchant's web site to select items and determine the price. The customer then sends a list of the items to be purchased to the merchant, who returns an order form containing the list of items, their price, a total price, and an order number.

5. The merchant is verified. In addition to the order form, the merchant sends a copy of its certificate, so that the customer can verify that he or she is dealing with a valid store.

6. The order and payment are sent. The customer sends both order and payment information to the merchant, along with the customer's certificate. The order confirms the purchase of the items in the order form. The payment contains credit-card details. The payment information is encrypted in such a way that it cannot be read by the merchant. The customer's certificate enables the merchant to verify the customer.

7. The merchant requests payment authorization. The merchant sends the payment information to the payment gateway, requesting authorization that the customer's available credit is sufficient for this purchase.

8. The merchant confirms the order. The merchant sends confirmation of the order to the customer.

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

10. The merchant requests payment. This request is sent to the payment gateway, which handles all of the payment processing.

Dual Signature

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.

To see the need for the link, suppose that the customer sends the merchant two messages: a signed OI and a signed PI, and the merchant passes the PI on to the bank. If the merchant can capture another OI from this customer, the merchant could claim that this OI goes with the PI rather than the original OI. The linkage prevents this.

Figure 2 shows the use of a dual signature to meet the requirement of the preceding paragraph. The customer takes the hash (using SHA-1) of the PI and the hash of the OI. These two hashes are then concatenated and the hash of the result is taken. Finally, the customer encrypts the final hash with his or her private signature key, creating the dual signature. The operation can be summarized as DS= EKRc[H(H(H(PI)||H(OI)), where KRc is the customer's private signature key. Now, suppose that the merchant is in possession of the dual signature (DS), the OI, and the message digest for the PI (PIMD). The merchant also has the public key of the customer, taken from the customer's certificate. Then the merchant can compute the following two quantities: H(PIMD|| H(OI) and DKUc[DS], where KUc is the customer's public signature key. If these two quantities are equal, then the merchant has verified the signature. Similarly, if the bank is in possession of DS, PI, the message digest for OI (OIMD), and the customer's public key, then the bank can compute H(H(PI)||OIMD and DKUc[DS]. Again, if these two quantities are equal, then the bank has verified the signature. In summary,

1. The merchant has received OI and verified the signature.

2. The bank has received PI and verified the signature.

3. The customer has linked the OI and PI and can prove the linkage.

For example, suppose the merchant wishes to substitute another OI in this transaction to its advantage. It would then have to find another OI with a hash that matches the existing OIMD. With SHA-1, this is deemed not to be feasible. Thus, the merchant cannot link another OI with this PI.

Details of a Purchase Request

To get some feel for the complexity of SET, consider one of the most common transaction types: the purchase request. Before the Purchase Request exchange begins, the cardholder has completed browsing, selecting, and ordering. The end of this preliminary phase occurs when the merchant sends a completed order form to the customer. All of the preceding occurs without the use of SET.

The Purchase Request exchange consists of four messages: Initiate Request, Initiate Response, Purchase Request, and Purchase Response.

To send SET messages to the merchant, the cardholder must have a copy of the certificates of the merchant and the payment gateway. The customer requests the certificates in the Initiate Request message, sent to the merchant. This message includes the brand of the credit card that the customer is using. The message also includes an ID assigned to this request/response pair by the customer.

The merchant generates a response and signs it with its private key. The response includes a transaction ID for this purchase transaction. In addition to the signed response, the Initiate Response message includes the merchant's certificate and the payment gateway's certificate.

The cardholder verifies the merchant and gateway certificates by means of their respective CA signatures and then creates the OI and PI. The transaction ID assigned by the merchant is placed in both the OI and PI. The OI does not contain explicit order data such as the number and price of items. Rather, it contains an order reference generated in the exchange between merchant and customer during the shopping phase before the first SET message. Next, the cardholder prepares the Purchase Request message (see Figure 3). For this purpose, the cardholder generates a one-time DES encryption key, known as a "session key." The message includes:

When the merchant receives the Purchase Request message, it performs the following actions:

1. Verifies the cardholder certificates by means of its CA signatures.

2. Verifies the dual signature using the customer's public signature key. This ensures that the order has not been tampered with in transit and that it was signed using the cardholder's private signature key.

3. Processes the order and forwards the payment information to the payment gateway for authorization (described later).

4. Sends a purchase response to the cardholder.

The Purchase Response message includes a response block that acknowledges the order and references the corresponding transaction number. This block is signed by the merchant using its private signature key. The block and its signature are sent to the customer, along with the merchant's signature certificate.

When the cardholder software receives the Purchase Response message, it verifies the merchant's certificate and then verifies the signature on the response block. Finally, it takes some action based on the response, such as displaying a message to the user or updating a database with the status of the order.

SET in Practice

Purchase by credit card over the Internet involves many functions and actions, of which only a few are implemented in SET. SET provides a payment protocol that defines the communication among cardholder, merchant, and payment gateway for purchases and refunds. It also provides a key exchange protocol, by which the various parties exchange public-key certificates. A number of activities beyond this scope are required. Both cardholders and merchants must obtain certificates that verify their public keys. The process of browsing and selecting goods for purchase is also outside the scope of SET.

On the cardholder side, the cardholder must obtain and install the SET software and arrange a credit-card account that supports SET and provides the needed certificate. The merchant must install the merchant-side SET software and integrate this with a web-based product or service ordering system. The merchant's software requirements are more complex, as communication is required both with the cardholder and the payment gateway.

Thus, for SET to work, the supporting software and certification functions must be in place. But with the backing of the two largest credit-card organizations, Visa and MasterCard, SET is poised to become the standard means for credit-card transactions via the Internet.

DDJ

Nov00: The SET Standard & E-Commerce

Figure 1: SET components.

Nov00: The SET Standard & E-Commerce

Figure 2: Construction of dual signatures.

Nov00: The SET Standard & E-Commerce

Figure 3: Cardholder sends purchase request.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.