0blivion nº1:(SET.txt):15/03/2000 << Back To 0blivion nº 1

<< Prev file: RAAP.txt

Next file: SSL.txt >>

+------------------------------------------------------+ ▌ Oblivion Underground Magazine - Issue 1 - 15/03/2000 ▌ ▌ Secure Electronic Transactions by Slider ▌ ▌ E-Mail : slider_100@hotmail.com ▌ +------------------------------------------------------+ Secure Electronic Transactions (SET) SET is the outcome of an agreement by MasterCard International and Visa International to cooperate on the creation of a single electronic credit card system. Prior to SET, each organization had proposed its own protocol and each had received support from a number of networking and computing companies. Now, most of the major players are behind the SET specification (for example, IBM, Microsoft, Netscape and GTE). The following sections describes at a high level the components and processes that make up the specification. Please refer to MasterCard and Visa home pages for more information about SET. SET Roles The SET specification defines several roles involved in the payment process: - The merchant This is any seller of goods, services or information. - The acquirer This is the organization that provides the credit card service and keeps the money flowing. The most widely known acquirers are MasterCard and Visa. - The issuer This is the organization that issued the card to the purchaser in the first place. Usually this is a bank or some other financial institution who should know better. - The cardholder This is the Web surfer, who has been given a credit card by the issuer and now wants to exercise his or her purchasing power on the Web. - The acquirer payment gateway This provides an interface between the merchant and the bankcard network used by the acquirer and the issuer. It is important to remember that the bankcard network already exists. The acquirer payment gateway provides a well-defined, secure interface to that established network from the Internet. Acquirer payment gateways will be operated on behalf of the acquirers, but they may be provided by third-party organizations, such as Internet services providers (ISPs). - The certificate authority SET processing uses public key cryptography, so each element of the system need one or more public key certificates. Several layers of CA are described in the specification. SET Transactions The SET specification describes a number of transaction flows for purchasing, authentication, payment reversal, etc. The figure below shows the transactions involved in a typical online purchase. CARD HOLDER MERCHANT Acquirer *********** PInitReq ****************> 1. <********** PInitRes ***************** *********** PReq ********************> 2. * ************************************** * ************ AuthReq *********> * ************ AuthReq *********> 3. <*********** AuthRes ********** <********** PRes ******************** *********** InqReq *****************> 4. <********** InqRes ****************** ************ CapReq ***********> 5. <*********** CapRes ************ The diagram shows the following transactions (each transaction consists of a request/response pair): 1. PInit This initializes the system, including details such as the brand of card being used and the certificates held by the cardholder. SET does not insist that cardholders have signing certificates, but it does recommend them. A cardholder certificate binds the credit card account number to the owner of a public key. If the acquirer receives a request for a given card number signed with the cardholder's public key, it knows that the request came from the real cardholder. To be precise, it knows that the request came from a computer where the cardholder's keyring was installed and available. It could still be a thief who had stolen the computer and cracked the keyring password. 2. Purchase Order This is the actual request from the cardholder to buy something. The request message is in fact two messages combined, the order instruction (OI), which is sent in the clear to the merchant and the purchase instruction (PI), which the merchant passes on to the acquirer payment gateway. The PI is encrypted in the public key of the acquirer, so the merchant cannot read it. The merchant stores the message for later transmission to the acquirer. The PI also includes a hash of the OI, so the two messages can only be handled as a pair. Note that the card number is only placed in the PI portion of the request. This means that the merchant never has access to it, thereby preventing a fraudulent user from setting up a false store front to collect credit card information. The purchase order has a response, which is usually sent (as shown here) after acquirer approval has been granted. However, the merchant can complete the transaction with the cardholder before authorization, in which case the cardholder would see a message that the request was accepted pending authorization. 3. Authorization In this request the merchant asks the acquirer, via the acquirer payment gateway, to authorize the request. The message includes a description of the purchase and the cost. It also includes the PI from the purchase order that the cardholder sent. In this way the acquirer knows that the merchant and the cardholder both agree on what is being purchased and the amount. When the acquirer receives the request it uses the existing bank card network to authorize the request and sends back an appropriate response. 4. Inquiry The cardholder may want to know how his or her request is getting on. The SET specification provides an inquiry transaction for that purpose. 5. Capture Up to this point, no money has changed hands. The capture request from the merchant tells the acquirer to transfer the previously authorized amount to its account. In fact, capture can be incorporated as part of the authorization request/response (see above). However there are situations in which the merchant may want to capture the funds later. For example, most mail order operations do not debit the credit card account until the goods have actually been shipped. There are several other transactions within the SET specification, but the summary above shows the principles on which it is based. 5.14.3 The SET Certificate Scheme The SET specification envisions hundreds of thousands of participants worldwide. Potentially, each of these would have at least one public key certificate. In fact the protocol calls for an entity to have multiple certificates in some cases. For example, the acquirer payment gateways need one for signing messages and another for encryption purposes. Key management on such a large scale requires something beyond a simple, flat certification structure.The organization of certifying authorities proposed for SET is shown in a chain. At the top of the certificate chain, the root certifying authority is to be kept offline under extremely tight arrangements. It will only be accessed when a new credit card brand joins the SET consortium. At the next level in the hierarchy, the brand level CAs are also very secure. They are administered independently by each credit card brand. Under each brand there is some flexibility permitted for different operating policies. It would be possible to set up CAs based on region or country for example. At the base of the CA hierarchy are the CAs that provide certificates for merchants, cardholders and acquirer payment gateways. The SET specification provides protocols for merchants and cardholders to request certificates online. It is important to have a simple process because SET aims to encourage cardholders to have their own certificates. It envisions the cardholder surfing to the CA Web site, choosing a Request Certificate option to invoke the certificate request application on the browser and then filling in a form to send and receive the certificate request. Of course, if the system allows certificates to be created easily it must also be able to revoke them easily, in the event of a theft or other security breach. The SET specification includes some certificate update and revocation protocols for this purpose. Although the mechanism for requesting a certificate may be simple, there is still a need for user education. For example, it is obvious that a cardholder should notify the credit card company if his or her wallet is stolen, but less obvious that he or she should also notify them if his or her computer is stolen. However, if the computer includes his keyring file containing the private key and certificate, it could allow the thief to go shopping at the cardholder's expense. Slider.