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:
- Provides a secure communications channel among all parties involved in a transaction.
- Provides trust by the use of X.509 Version 3 digital certificates.
- Ensures privacy because the information is only available to parties in a transaction when and where necessary.
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:
- Confidentiality of information. Cardholder account and payment information is secured as it travels across the network. An interesting and important feature of SET is that it prevents merchants from learning the cardholder's credit-card number; this is only provided to the issuing bank. Conventional encryption by DES is used to provide confidentiality.
- Integrity of data. Payment information sent from cardholders to merchants includes order information, personal data, and payment instructions. SET guarantees that these message contents are not altered in transit. RSA digital signatures, using SHA-1 hash codes, provide message integrity. Certain messages are also protected by the message authentication code HMAC, using SHA-1.
- Cardholder account authentication. SET lets merchants verify that a cardholder is a legitimate user of a valid card account number. SET uses X.509v3 digital certificates with RSA signatures for this purpose.
- Merchant authentication. SET lets cardholders verify that a merchant has a relationship with a financial institution allowing it to accept payment cards. SET uses X.509v3 digital certificates with RSA signatures for this purpose.
SET Participants
Figure 1 illustrates the participants in the SET system, which includes:
- Cardholder. In the electronic environment, consumers and corporate purchasers interact with merchants from personal computers over the Internet. A cardholder is an authorized holder of a payment card (for example, MasterCard or Visa) that has been issued by an issuer.
- Merchant. A person or organization who has goods or services to sell to cardholders. Typically, these goods and services are offered via web sites or e-mail. Merchants who accept payment cards must have a relationship with an acquirer.
- Issuer. A financial institution, such as a bank, that provides cardholders with payment cards. Typically, accounts are applied for and opened by mail or in person. Ultimately, it is the issuer that is responsible for the payment of the debt of the cardholder.
- Acquirer. A financial institution that establishes an account with merchants and processes payment and card authorizations. Merchants usually accept more than one credit-card brand but do not want to deal with multiple bank-card associations or with multiple individual issuers. Acquirers provide authorization to merchants that a given card account is active and that the proposed purchase does not exceed the credit limit. Acquirers also provide electronic transfer of payments to merchant accounts. Subsequently, acquirers are reimbursed by the issuer over some sort of payment network for electronic funds transfer.
- Payment gateway. A function operated by acquirers or a designated third party that processes merchant payment messages. The payment gateway interfaces between SET and the existing bank-card payment networks for authorization and payment functions. Merchants exchange SET messages with the payment gateway over the Internet, while the payment gateway has some direct or network connection to the acquirer's financial processing system.
- Certification authority (CA). An entity that is trusted to issue X.509v3 public-key certificates for cardholders, merchants, and payment gateways. The success of SET will hinge on the existence of a CA infrastructure available for this purpose. A hierarchy of CAs is used, so that participants need not be directly certified by a root authority.
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:
- Purchase-related information. This information will be forwarded to the payment gateway by the merchant and consists of the PI and a dual signature. The dual signature is a signature that covers both the PI and the OI. It is constructed in such a way that both the merchant and the payment gateway can verify the signature, even though the merchant only sees the OI, and the payment gateway only sees the PI. Both the PI and the dual signature are encrypted using the one-time session key. Finally, the session key is encrypted with the public key of the payment gateway, and added to the message; only the payment gateway will be able to decrypt and read the session key, and therefore, only the payment gateway will be able to recover the PI.
- Order-related information. This information is needed by the merchant and consists of the OI and the dual signature. The merchant uses the dual signature to verify that the OI is valid.
- Cardholder certificate. This contains the cardholder's public key. It is needed by the merchant and by the payment gateway.
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
