- Introduction
- The SET Scene
- Details of a Purchase Request
- SET in Practice
From the author of
From the author of
From the author of
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" issued in May 1997, and running to nearly 1,000 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 the merchant from learning the cardholder's credit card number; this is provided only 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 enables merchants to 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 enables cardholders to 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 shows the participants in the SET system:
){kind=link}
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 (MasterCard, Visa, and so on) that has been issued by an issuer.
Merchant: A merchant is a person or organization with goods or services to sell to the cardholder. Typically, these goods or services are offered via a web site or by electronic mail. A merchant that accepts payment cards must have a relationship with an acquirer.
Issuer: This is a financial institution, such as a bank, that provides the cardholder with the payment card. Typically, accounts are applied for and opened by mail or in person. Ultimately, the issuer is responsible for the payment of the debt of the cardholder.
Acquirer: This is a financial institution that establishes an account with a merchant and processes payment card authorizations and payments. Merchants will usually accept more than one credit card brand but don't want to deal with multiple bankcard associations or with multiple individual issuers. The acquirer provides authorization to the merchant that a given card account is active and that the proposed purchase does not exceed the credit limit. The acquirer also provides electronic transfer of payments to the merchant's account. Subsequently, the acquirer is reimbursed by the issuer over some sort of payment network for electronic funds transfer.
Payment Gateway: This is a function operated by the acquirer or a designated third party that processes merchant payment messages. The payment gateway interfaces between SET and the existing bankcard payment networks for authorization and payment functions. The merchant exchanges 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): This is an entity that is trusted to issue X.509v3 public-key certificates for cardholders, merchants, and payment gateways. The success of SET will depend 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.
Figure 1 Secure electronic commerce components.
SET in Action
SET is a dynamic, automated scheme that allows a customer with a credit card to order items over the Internet from merchants, in a secure fashion. A typical scenario goes like this:
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.
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.
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.
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 from the merchant, who returns an order form containing the list of items, their individual prices, a total price, and an order number.
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.
The order and payment are sent. The customer sends both an 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.
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.
The merchant confirms the order. The merchant sends confirmation of the order to the customer.
The merchant provides the goods or service. The merchant ships the goods or provides the service to the customer.
The merchant requests payment. This request is sent to the payment gateway, which handles all of the payment processing.
Dual Signature
Before looking at the details of the SET protocol, let's discuss an important innovation introduced in SET: 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 doesn't need to know the customer's credit card number, and the bank doesn't 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 services.
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 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 this requirement.
){kind=link}
Figure 2 Construction of dual signature.
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 shown in Figure 3, where KRc is the customer's private signature key:
){kind=link}
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 two quantities shown in Figure 4, where KUc is the customer's public signature key:
){kind=link}
If these two quantities are equal, 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, the bank can compute the following (see Figure 5):
){kind=link}
Again, if these two quantities are equal, the bank has verified the signature. In summary,
The merchant has received OI and verified the signature.
The bank has received PI and verified the signature.
The customer has linked the OI and PI and can prove the linkage.
For example, suppose the merchant wants to substitute another OI in this transaction, to its advantage. It would then have to find another OI whose hash matches the existing OIMD. With SHA-1, this is deemed not to be feasible. Thus, the merchant cannot link another OI with this PI.