7.7 Internet Commerce
In the previous section, we considered the application-layer use (in secure
e-mail) of the various security technologies that we studied earlier in
this chapter: encryption, authentication, key distribution, message integrity
and digital signatures. In this section we'll continue our case study
of various security mechanisms by dropping down a layer in the protocol
stack an covering secure sockets and a secure transport layer.
We'll take Internet commerce as a motivating application, since business
and financial transactions are an important driver for Internet security.
We consider Internet commerce to be the purchasing of "goods"
over the Internet. Here we'll use the term "goods" in a very broad
sense to include books, CDs, hardware, software, airline tickets, stocks
and bonds, consulting services, etc. In the 1990s many schemes were
designed for Internet commerce, some providing minimal levels of security
and others providing a high-level of security along with customer anonymity
(similar to the anonymity provided by ordinary person-to-person cash transactions
[Loshin
1997].) In the late 1990s, however, there was a major shake out, as
only a few of these schemes were widely implemented in Web browsers and
servers. As of this writing, two schemes have taken hold: SSL, which is
currently used by the vast majority of Internet transactions; and SET,
which is to expected to fiercely compete with SSL in the upcoming years.
There are three major players in this infrastructure: the customer who
is purchasing a good, the merchant who is selling the good, and the
merchant's bank, which authorizes the purchase. We shall see in our discussion
below that Internet commerce with SSL provides security for communication
between the first two of these three players (i.e., the customer and the
merchant), whereas SET provides security for communication among all three
players.
7.7.1 Internet Commerce Using SSL
Let's walk through a typical Internet commerce scenario. Bob is surfing
the Web and arrives at the Alice Incorporated site which is selling some
durable good. The Alice Incorporated site displays a form in which Bob
is supposed to enter the quantity desired, his address and his payment
card number. Bob enters this information, clicks on "submit", and then
expects to receive (say, from, ordinary mail) the good; he also expects
to receive a charge for the good in his next payment card statement. This
all sounds good, but if no security measures are taken -- such as encryption
or authentication -- Bob could be in for a few surprises:
-
An intruder could intercept the order and obtain Bob's payment card information.
The intruder could then make purchases at Bob's expense.
-
The site could display Alice Incorporated famous logo, but actually be
a site maintained by Trudy, who is masquerading as Alice Incorporated.
Trudy could take Bob's money and run. Or Trudy could make her own purchases
and have them billed to Bob's account.
Many other surprises are possible, and we will discuss a few of these in
the next subsection. But the two problems listed above are among the most
serious. Internet commerce using the SSL protocol can address both these
problems.
Secure sockets layer (SSL), originally developed by Netscape, is a protocol
designed to provide data encryption and authentication between a Web client
and a Web server. The protocol begins with a handshake phase that negotiates
an encryption algorithm (e.g., DES or RSA) and keys, and authenticates
the server to the client. Optionally, the client can also be authenticated
to the server. Once the handshake is complete and the transmission of application
data begins, and all data is encrypted using session keys negotiated during
the handshake phase. SSL is widely used in Internet commerce, being implemented
in almost all popular browsers and Web servers. Furthermore, it is also
the basis of the Transport Layer Security (TLS) protocol [RFC
2246].
Figure 7.7-1: Secure socket layer
SSL and TLS are not limited to the Web application; for example, they
are also used for authentication and data encryption for IMAP mail access.
SSL can be viewed as a layer that sits between the application layer and
the transport layer, as shown in Figure 7.7-1. On the sending side,
SSL receives from the application raw application data (such as an HTTP
or IMAP message), encrypts the data and directs the encrypted data to a
TCP socket. On the receiving side, SSL reads from the TCP socket, decrypts
the data, and directs the data to the application. Although SSL can be
used with many Internet applications, we shall discuss it in the
context of the Web, where it is principally being used today for Internet
commerce.
SSL provides the following features:
-
SSL server authentication, allowing a user to confirm a server's
identity. An SSL-enabled browser maintains a list of trusted certifying
authorities (CAs) along with the public keys of the CAs. When the browser
wants to do business with an SSL-enabled Web server, the browser obtains
from the server a certificate containing the server's public key. The certificate
is issued (i.e., digitally signed) by a certificate authority (CA) listed
in the client's list of trusted CAs. This feature allows the browser to
authenticate the server before the user submits a payment card number.
In the context of the earlier example, this server authentication
enables Bob to verify that he is indeed sending his payment card number
to Alice Incorporated, and not to someone else who might be masquerading
as Alice Incorporated.
-
An encrypted SSL session, in which all information sent between
browser and server is encrypted by sending software (browser or Web server)
and decrypted by the receiving software (browser or Web server). This confidentially
may be important to both the customer and the merchant. Also, SSL provides
a mechanism for detecting tampering of the information by an intruder.
-
SSL client authentication, allowing a server to confirm a user's
identity. Analogous to server authentication, client authentication makes
use of client certificates, which have also been issued by CAs. This authentication
is important if the server, for example, is a bank sending confidential
financial information to a customer and wants to check the recipient's
identity. Client authentication, although supported by SSL, is optional.
To keep our discussion focused, we will henceforth ignore it.
How SSL Works
A user, say Bob, surfs the Web and clicks on a link that takes him to a
secure page housed by Alice's SSL-enabled server. The protocol part of
the URL for this page is "https" rather than the ordinary "http". The browser
and server then run the SSL handshake protocol, which (1) authenticates
the server and (2) generates a shared symmetric key. Both of these tasks
make use of the RSA public-key technology. The main flow of events in the
handshake phase is shown in Figure 7.7-2. During this phase, Alice
sends Bob her certificate, from which Bob obtains Alice's public key. Bob
then creates a random symmetric key, encrypts it with Alice's public key,
and sends the encrypted key to Alice. Bob and Alice now share a symmetric
session key. Once this handshake protocol is complete, all data sent between
the browser and server (over TCP connections) is encrypted using the symmetric
session key.
Figure 7.7-2: High-level overview of the handshake phase of
SSL.
Having given a high-level overview of SSL, let's take a closer look
at some of more important details. The SSL handshake performs the following
steps:
-
The browser sends the server the browser's SSL version number and cryptography
preferences. The browser sends its cryptography preferences because the
browser and server negotiate which symmetric key algorithm they are going
to use.
-
The server sends the browser the server's SSL version number, cryptography
preferences and its certificate. Recall that the certificate includes the
server's RSA public key and is certified by some CA, that is, the certificate
has been encrypted by a CA's private key.
-
The browser has an entrusted list of CAs and a public key for each CA on
the list. When the browser receives the certificate from the server, it
checks to see if the CA is on the list. If no, the user is warned of the
problem and informed that an encrypted and authenticated connection cannot
be established. If yes, the browser uses the CA's public key to decrypt
the certificate and obtain the server's public key.
-
The browser generates a symmetric session key, encrypts it with the server's
public key, and sends the encrypted session key to the server.
-
The browser sends a message to the server informing it that future messages
from the client will be encrypted with the session key. It then sends a
separate (encrypted) message indicating that the browser portion of the
handshake is finished.
-
The server sends a message to the browser informing it that future messages
from the server will be encrypted with the session key. It then sends a
separate (encrypted) message indicating that the server portion of the
handshake is finished.
-
The SSL handshake is now complete, and the SSL session has begun. The browser
and the server use the session keys to encrypt and decrypt the data they
send to each other and to validate its integrity.
SSL handshake actually has many more steps than listed above. You can find
more information about SSL at Netscape's Security Developer Central [NetscapeSecurity
1999]. In addition to payment card purchases, we point out here that
SSL can (and is) used for other financial transactions including online
banking and stock trading.
SSL in Action
We recommend that you visit a secure Web site, such as a Quebec maple syrup
site [Quebec 1999]. When you enter a secure
section of such a site, SSL will perform the handshake protocol. Assuming
that the server's certificate checks out, the browser will notify you,
for example by displaying a special icon.. All information sent between
you and the server will now be encrypted. Your browser should let you actually
see the certificate for the merchant. (For example, with Internet Explorer,
go to File, Properties, Certificates.) In April 1999, the maple syrup site's
certificate included the following information:
Company: Netfarmers Enterprises Inc.
Certification Authority: Thawte Certification
Public Key (in hexadecimal): 88:79:85:D5:D0:7D:60:39:10:51:31:EC:17:DE:E7:80
If your browser lets you do secure transactions with the merchant, then
you should also be able to see the certificate for CA, i.e., Thawte Certification.
(For example, with Internet Explorer, go to View, Internet Options, Content,
Certificate Authorities.)
The Limitations of SSL in Internet Commerce
Due to its simplicity and early development, SSL
is widely implemented in browsers, servers and Internet commerce products.
These SSL-enabled servers and browsers provide a popular platform for
payment card transactions. Nevertheless, we should keep in mind that SSL
was not specifically tailored for payment card transactions, but instead
for generic secure communication between a client and server. Because of
this generic design, SSL lacks many features that payment-card industry
would like to see in an Internet commerce protocol.
Consider once again what happens when Bob makes
a purchase from Alice Incorporated over SSL. The signed certificate that
Bob receives from Alice assures Bob that he is really dealing with Alice
Incorporated, and that Alice Incorporated is a bona fide company. However,
the generic certificate does not indicate whether Alice Incorporated is
authorized to accept payment-card purchases nor if the company is a reliable
merchant. This opens the door for merchant fraud. And there is a similar
problem for client authorization. Even if SSL client authentication is
used, the client certificate does not tie Bob to a specific authorized
payment card; thus, Alice Incorporated has no assurance about whether Bob
is authorized to make a payment-card purchase. This opens the door to all
kinds of fraud, including purchases with stolen credit cards and customer
repudiation of purchased goods [Abbott 1999].
Of course, this kind of fraud is already rampant
in mail order and telephone order (MOTO) purchases. With MOTO transactions,
the law dictates that the merchant accepts liability for fraudulent transactions.
Thus, if a customer makes a MOTO purchase with a payment card and claims
to have never made the purchase, then the merchant is liable, that is,
the merchant is legally bound to return the money to the customer (unless
the merchant can prove that the customer actually ordered and received
the goods). Similarly, if a MOTO purchase is made with a stolen payment
card, the merchant is again liable. On the other hand, with physically-present
transactions, the merchant's bank accepts the liability; as you might expect,
it is more difficult for a customer to repudiate a physcially-present purchase
which involves a hand-written signature or a PIN (personal identification
number).
SSL purchases are similar to MOTO purchases, and naturally the merchant
is liable for a fraudulent SSL purchase. It would be preferable, of course,
to use a protocol that provides superior authentication of the customer
and of the merchant, something that is as good or better than a physically-present
transaction. Authentication involving payment-card authorization would
reduce fraud and merchant liability.
7.7.2 Internet Commerce Using SET
SET (Secure Electronic Transactions) 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 include:
-
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 basically contains information about
the account, the issuing financial institution, and other cryptographic
information. The merchant certificate assures the consumer 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
merchandizing and fulfillment engine for merchants selling on the Web.
For payments, it processes cardholder transactions and communicates with
the merchant's bank or 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.
-
Bob indicates to Alice that he is interested in making a credit card purchase.
-
Alice sends the customer 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 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
the Alice, which is (of course) encrypted. The response includes the transaction
identifier.
-
If the transaction is approved, Alice sends its 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 non-exposure 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 SETCo page [SETCo 1999] or the SET documentation
at the MasterCard site [Master 1999]. There are
also several good books on SET [Merkow 1998] [Loeb
1998].
References
[Abbott 1999] S. Abbott, "The Debate for Secure
E-Commerce," Performance Computing, February 1999, http://www.performancecomputing.com/features/9902f1.shtml
[Loeb 1998] L. Loeb, Secure Electronic Transactions
: Introduction and Technical Reference," Artech House, New York,
1998.
[Loshin 1997] P. Loshin, P. Murphy, "Electronic
Commerce : On-Line Ordering and Digital Money", Charles River Media, August
1997
[Merkow 1998] M. Merkow, K. Wheeler, and J.
Breithaupt, "Building SET Applications for Secure Transactions," John Wiley
and Sons, New York, 1998.
[Master 1999] SET Secure Electronic Transaction,
MasterCard Web site, http://www.mastercard.com/shoponline/set/
[NetscapeSecurity 1999] Security Developer
Central, Netscape Site, http://developer.netscape.com/tech/security/
[Quebec 1999] Quebec Maple Syrup homepage,
http://www.jam.ca/syrup/
[RFC 2246] T. Dierks
and C. Allen, The TLS Protocol, [RFC
22246], January 1999.
[Setco1999] SETCo LLC Website, http://www.setco.org/
Return to
Table Of Contents
Copyright Keith W. Ross and Jim Kurose 1996-2000