17.3. Secure Electronic TransactionSET is an open encryption and security specification designed to protect credit card transactions on the Internet. The current version, SETv1, 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:
This is a total of 971 pages of specification. In contrast, the SSLv3 specification is 63 pages long and the TLS specification is 80 pages long. Accordingly, only a summary of this many-faceted specification is provided in this section. SET OverviewA good way to begin our discussion of SET is to look at the business requirements for SET, its key features, and the participants in SET transactions. RequirementsBook 1 of the SET specification lists the following business requirements for secure payment processing with credit cards over the Internet and other networks:
Key Features of SETTo meet the requirements just outlined, SET incorporates the following features:
Note that unlike IPSec and SSL/TLS, SET provides only one choice for each cryptographic algorithm. This makes sense, because SET is a single application with a single set of requirements, whereas IPSec and SSL/TLS are intended to support a range of applications. SET ParticipantsFigure 17.8 indicates the participants in the SET system, which include the following:
Figure 17.8. Secure Electronic Commerce Components |
Cardholder registration | Cardholders must register with a CA before they can send SET messages to merchants. |
Merchant registration | Merchants must register with a CA before they can exchange SET messages with customers and payment gateways. |
Purchase request | Message from customer to merchant containing OI for merchant and PI for bank. |
Payment authorization | Exchange between merchant and payment gateway to authorize a given amount for a purchase on a given credit card account. |
Payment capture | Allows the merchant to request payment from the payment gateway. |
Certificate inquiry and status | If the CA is unable to complete the processing of a certificate request quickly, it will send a reply to the cardholder or merchant indicating that the requester should check back later. The cardholder or merchant sends the Certificate Inquiry message to determine the status of the certificate request and to receive the certificate if the request has been approved. |
Purchase inquiry | Allows the cardholder to check the status of the processing of an order after the purchase response has been received. Note that this message does not include information such as the status of back ordered goods, but does indicate the status of authorization, capture and credit processing. |
Authorization reversal | Allows a merchant to correct previous authorization requests. If the order will not be completed, the merchant reverses the entire authorization. If part of the order will not be completed (such as when goods are back ordered), the merchant reverses part of the amount of the authorization. |
Capture reversal | Allows a merchant to correct errors in capture requests such as transaction amounts that were entered incorrectly by a clerk. |
Credit | Allows a merchant to issue a credit to a cardholder's account such as when goods are returned or were damaged during shipping. Note that the SET Credit message is always initiated by the merchant, not the cardholder. All communications between the cardholder and merchant that result in a credit being processed happen outside of SET. |
Credit reversal | Allows a merchant to correct a previously request credit. |
Payment gateway certificate request | Allows a merchant to query the payment gateway and receive a copy of the gateway's current key-exchange and signature certificates. |
Batch administration | Allows a merchant to communicate information to the payment gateway regarding merchant batches. |
Error message | Indicates that a responder rejects a message because it fails format or content verification tests. |
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.
In order 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 and a nonce used to ensure timeliness.
The merchant generates a response and signs it with its private signature key. The response includes the nonce from the customer, another nonce for the customer to return in the next message, and a transaction ID for this purchase transaction. In addition to the signed response, the Initiate Response message includes the merchant's signature certificate and the payment gateway's key exchange 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 (Figure 17.10). For this purpose, the cardholder generates a one-time symmetric encryption key, Ks. The message includes the following:
Purchase-related information. This information will be forwarded to the payment gateway by the merchant and consists of
- The PI
- The dual signature, calculated over the PI and OI, signed with the customer's private signature key
- The OI message digest (OIMD)
The OIMD is needed for the payment gateway to verify the dual signature, as explained previously. All of these items are encrypted with Ks. The final item is
- The digital envelope. This is formed by encrypting Ks with the payment gateway's public key-exchange key. It is called a digital envelope because this envelope must be opened (decrypted) before the other items listed previously can be read.
The value of Ks is not made available to the merchant. Therefore, the merchant cannot read any of this payment-related information.
Order-related information. This information is needed by the merchant and consists of
- The OI
- The dual signature, calculated over the PI and OI, signed with the customer's private signature key
- The PI message digest (PIMD)
The PIMD is needed for the merchant to verify the dual signature. Note that the OI is sent in the clear.
Cardholder certificate. This contains the cardholder's public signature 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 (Figure 17.11):
Verifies the cardholder certificates by means of its CA signatures.
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.
Processes the order and forwards the payment information to the payment gateway for authorization (described later).
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.
During the processing of an order from a cardholder, the merchant authorizes the transaction with the payment gateway. The payment authorization ensures that the transaction was approved by the issuer. This authorization guarantees that the merchant will receive payment; the merchant can therefore provide the services or goods to the customer. The payment authorization exchange consists of two messages: Authorization Request and Authorization response.
The merchant sends an Authorization Request message to the payment gateway consisting of the following:
Purchase-related information. This information was obtained from the customer and consists of
- The PI
- The dual signature, calculated over the PI and OI, signed with the customer's private signature key
- The OI message digest (OIMD)
- The digital envelope
Authorization-related information. This information is generated by the merchant and consists of
- An authorization block that includes the transaction ID, signed with the merchant's private signature key and encrypted with a one-time symmetric key generated by the merchant
- A digital envelope. This is formed by encrypting the one-time key with the payment gateway's public key-exchange key.
Certificates. The merchant includes the cardholder's signature key certificate (used to verify the dual signature), the merchant's signature key certificate (used to verify the merchant's signature), and the merchant's key-exchange certificate (needed in the payment gateway's response).
The payment gateway performs the following tasks:
Verifies all certificates
Decrypts the digital envelope of the authorization block to obtain the symmetric key and then decrypts the authorization block
Verifies the merchant's signature on the authorization block
Decrypts the digital envelope of the payment block to obtain the symmetric key and then decrypts the payment block
Verifies the dual signature on the payment block
Verifies that the transaction ID received from the merchant matches that in the PI received (indirectly) from the customer
Requests and receives an authorization from the issuer
Having obtained authorization from the issuer, the payment gateway returns an Authorization Response message to the merchant. It includes the following elements:
Authorization-related information. Includes an authorization block, signed with the gateway's private signature key and encrypted with a one-time symmetric key generated by the gateway. Also includes a digital envelope that contains the one-time key encrypted with the merchants public key-exchange key.
Capture token information. This information will be used to effect payment later. This block is of the same form as (1), namely, a signed, encrypted capture token together with a digital envelope. This token is not processed by the merchant. Rather, it must be returned, as is, with a payment request.
Certificate. The gateway's signature key certificate.
With the authorization from the gateway, the merchant can provide the goods or service to the customer.
To obtain payment, the merchant engages the payment gateway in a payment capture transaction, consisting of a capture request and a capture response message.
For the Capture Request message, the merchant generates, signs, and encrypts a capture request block, which includes the payment amount and the transaction ID. The message also includes the encrypted capture token received earlier (in the Authorization Response) for this transaction, as well as the merchant's signature key and key-exchange key certificates.
When the payment gateway receives the capture request message, it decrypts and verifies the capture request block and decrypts and verifies the capture token block. It then checks for consistency between the capture request and capture token. It then creates a clearing request that is sent to the issuer over the private payment network. This request causes funds to be transferred to the merchant's account.
The gateway then notifies the merchant of payment in a Capture Response message. The message includes a capture response block that the gateway signs and encrypts. The message also includes the gateway's signature key certificate. The merchant software stores the capture response to be used for reconciliation with payment received from the acquirer.