[Section 7.7.2 of the First Edition]
Secure electronic transactions (SET) is a protocol specifically
designed to secure payment-card transactions over the Internet. It was
originally developed by Visa International and MasterCard International
in February 1996 with participation from leading technology companies
around the world. SET Secure Electronic Transaction LLC (commonly
referred to as SETCo) was established in December 1997 as a legal entity
to manage and promote the global adoption of SET [SetCo 1999]. Some of
the principle characteristics of SET are as follows:
- SET is designed to encrypt specific kinds of payment-related
messages; it cannot be used to encrypt arbitrary data (such as text and
images) as can SSL.
- The SET protocol involves all three players mentioned at
the beginning of this section, namely, the customer, the merchant, and the
merchant's bank. All sensitive information sent between the three
parties is encrypted.
- SET requires all three players to have certificates. The
customer's and merchant's certificates are issued by their banks,
thereby assuring that these players are permitted to make and receive
payment-card purchases. The customer certificate provides merchants with
assurance that transactions will not be fraudulently charged back. It
is an electronic representation of the customer's payment card. It
contains information about the account, the issuing financial
institution, and other cryptographic information. The merchant
certificate assures the consumer that that merchant is authorized
to accept payment-card purchases. It contains information about the
merchant, the merchant's bank, and the financial institution issuing the
certificate.
- SET specifies the legal meaning of the certificates held
by each party and the apportionment of liabilities connected with a
transaction [Abbott 1999].
- In a SET transaction, the customer's payment-card number
is passed to the merchant's bank without the merchant ever seeing the
number in plain text. This feature prevents fraudulent or careless
merchants from stealing or accidentally leaking the payment-card number.
A SET transaction uses three software components:
- Browser wallet. The browser wallet application is integrated
with the browser and provides the customer with storage and management
of payment cards and certificates while shopping. It responds to SET
messages from the merchant, prompting the customer to select a payment
card for payment.
- Merchant server. The merchant server is the
merchandising and fulfillment engine for merchants selling on the Web.
For payments, it processes cardholder transactions and communicates with
the merchant's bank for approval and subsequent payment capture.
- Acquirer gateway. The acquirer gateway is the
software component at the merchant's bank. It processes the merchant's
payment card transaction for authorization and payment.
In what follows, we give a highly simplified overview of the SET
protocol. In reality, the protocol is substantially more complex.
Steps in Making a Purchase
Suppose Bob wants to purchase a good over the Internet from Alice
Incorporated using SET.
- Bob indicates to Alice that he is interested in making a credit card
purchase.
- Alice sends Bob an invoice and a unique transaction
identifier.
- Alice sends Bob the merchant's certificate, which includes
the merchant's public key. Alice also sends the certificate for her
bank, which includes the bank's public key. Both of these certificates
are encrypted with the private key of a certifying authority.
- Bob uses the certifying authority's public key to decrypt
the two certificates. Bob now has Alice's public key and the bank's
public key.
- Bob generates two packages of information: the order
information (OI) package and the purchase instructions (PI)
package. The OI, destined for Alice, contains the transaction identifier
and brand of card being used; it does not include Bob's card number.
The PI, destined for Alice's bank, contains the transaction identifier,
the card number, and the purchase amount agreed to by Bob. The OI and PI
are dual encrypted: the OI is encrypted with Alice's public key;
the PI is encrypted with Alice's bank's public key. (We are bending the
truth here in order to see the big picture. In reality, the OI and PI
are encrypted with a customer-merchant session key and a customer-bank
session key.) Bob sends the OI and the PI to Alice.
- Alice generates an authorization request for the card
payment request, which includes the transaction identifier.
- Alice sends to her bank a message encrypted with the bank's
public key. (Actually, a session key is used.) This message includes
the authorization request, the PI package received from Bob, and Alice's
certificate.
- Alice's bank receives the message and unravels it. The bank
checks for tampering. It also makes sure that the transaction
identifier in the authorization request matches the one in Bob's PI
package.
- Alice's bank then sends a request for payment authorization
to Bob's payment-card bank through traditional bank-card channels--just
as Alice's bank would request authorization for any normal payment-card
transaction.
- Once Bob's bank authorizes the payment, Alice's bank sends a
response to Alice, which is (of course) encrypted. The response
includes the transaction identifier.
- If the transaction is approved, Alice sends her own
response message to Bob. This message serves as a receipt and informs
Bob that the payment was accepted and that the goods will be delivered.
One of the key features of SET is the nonexposure of the credit number
to the merchant. This feature is provided in Step 5, in which the
customer encrypts the credit-card number with the bank's key. Encrypting
the number with the bank's key prevents the merchant from seeing the
credit card. Note that the SET protocol closely parallels the steps
taken in a standard payment-card transaction. To handle all the SET
tasks, the customer will have a so-called digital wallet that runs the
client-side of the SET protocol and stores customer payment-card
information (card number, expiration date, etc.). Readers interested in
learning more about SET are encouraged to see the SETCo page [SetCo
1999] or the SET documentation at the MasterCard site [MasterCard 1999].
There are also several good books on SET [Merkow 1998; Loeb 1998].