The SET Protocol

The Secure Electronic Transaction (SET) is an open encryption and security specification that is designed for protecting credit card transactions on the Internet. The pioneering work in this area was done in 1996 by MasterCard and Visa jointly. They were joined by IBM, Microsoft, Netscape, RSA, Terisa and VeriSign. Starting from that time, there have been many tests of the concept, and by 1998 the first generation of SET-compliant products appeared in the market. The need for SET came from the fact that MasterCard and Visa realized that for ecommerce payment processing, software vendors were coming up with new and conflicting standards. Microsoft mainly drove these on one hand, and IBM on the other. To avoid all sorts of future incompatibilities, MasterCard and Visa decided to come up with a standard, ignoring all their competition issues, and in the process, involving all the major software manufacturers. SET is a very complex specification. In fact, when released, it took 971 pages to describe SET across three books! (Just for the record, SSL Version 3 needs 63 pages to describe). Thus, it is not possible to discuss it in great detail. First, let us list down the parties involved in an SET transaction:

Cardholder: Using the Internet, consumers and corporate purchasers interact with merchants for buying goods and services. A cardholder is an authorized holder of a payment card such as MasterCard or Visa that has been issued by an Issuer (discussed subsequently).

Merchant: A merchant is a person or an organization that wants to sell goods or services to cardholders. A merchant must have a relationship with an Acquirer (discussed subsequently) for accepting payments on the Internet.

Issuer: The issuer is a financial institution (such as a bank) that provides a payment card to a cardholder. The most critical point is that the issuer is the ultimately responsible for the payment of the cardholders debt.

Acquirer: This is a financial institution that has a relationship with merchants for processing payment card authorizations and payments. The reason for having acquirers is that merchants accept credit cards of more than one brand, but are not interested in dealing with so many bankcard organizations or issuers. Instead, an acquirer provides the merchant an assurance (with the help of the issuer) that a particular cardholder account is active and that the purchase amount does not exceed the credit limits, etc. The acquirer also provides electronic funds transfer to the merchant account. Later, the issuer reimburses the acquirer using some payment network.

Payment Gateway: This is a task can be taken up by the acquirer or it can be taken up by an organization as a dedicated function. The payment gateway processes the

payment messages on behalf of the merchant. Specifically in SET, the payment gateway acts as an interface between SET and the existing card payment networks for payment authorizations. The merchant exchanges SET messages with the payment gateway over the Internet. The payment gateway, in turn, connects to the acquirers systems using a dedicated network line in most cases.

Certification Authority (CA): This is an authority that is trusted to provide public key certificates to cardholders, merchants and payment gateways. In fact, CAs are very crucial to the success of SET. Page 1 of 2

Dual Signature
SET works in a very interesting manner. The SET protocol makes use of the concept of dual signature. The idea is like this:

1. The cardholder takes the Payment Information (PI), containing the cardholders credit card number, expiry date, etc and hashes (digests) it to produce Payment Information Message Digest (PIMD). 2. Similarly, the cardholder digests the Order Information (OI) to obtain Order Information Message Digest (OIMD) 3. The cardholder combines PIMD and OIMD to produce Payment and Order Message Digest (POMD). 4. The cardholder encrypts the POMD with its private key. The output of this process is the Dual Signature (DS). It is called dual, because it has inputs coming from PI as well as OI. The cardholder now sends:

OI, PIMD, and DS to the merchant PI, OIMD, and DS to the payment gateway As we can see, the merchant does not get access to PI, and hence, cannot know the cardholders credit card number. However, it has access to OI to process the order. Also, to validate the card holders order, the merchant can decrypt DS using the cardholders public key to obtain the first POMD; and separately combine OIMD and

PIMD to also compute the second POMD. If the two POMD values match, the merchant is happy that the order was indeed sent by the cardholder.

Analyzing SET We can see that SET helps protect the credit card number from the merchant. Moreover, the cardholder signs the transaction. Hence, the cardholder cannot claim later that her credit card was misused by someone else. This is indeed what we expect from a credit card payment protocol. However, there is a very dangerous possibility in this model. The user would be held liable for any transaction performed by the SET software on the users computer. This is because all outgoing transactions will have the users digital signature. What if a malicious program exploits some flaw in the users computer, and subverts the SET software? The SET software might sign an incorrect transaction, causing financial losses to the user.

In the traditional credit card transaction (without SET), the user can at least claim that her credit card details were stolen and misused.