What's New In CyberTalk

by Jean Gora
March, 1998

Note: CyberTalk is a column that appears monthly in LOMA's Resource, the magazine for insurance and financial services management. To see more contents of the magazine and to see how to subscribe, click on Resource.

Ready, SET, Go

1998 may be the year when the insurance industry really begins to sell insurance on the Internet—instead of using it for promotion or to generate agent referrals. One reason may be the evolving Secure Electronic Transaction or SETÔ protocol, which provides an increased level of security to the transmission of credit card numbers via the Internet. Use of the Internet to sell insurance is likely to depend on such transmissions for payment of initial premiums. This issue of CyberTalk reports on the results of a confidential LOMA mini-survey of nine North American insurers (of varying sizes) regarding current Internet activity and planned usage of SET. It also describes SET and how it builds on the existing credit card authorization and settlement systems.

Of the nine companies that participated in the survey, all but one already have Web sites. Only one offers price quotations through its own site or through the site of someone else (e.g., InsWeb, InsureMarket, RightQuote). Only one offers online applications on its Web site, but another plans to do so in 1998. None presently accepts payment of initial premiums by credit card number transmitted over the Internet.

The future is very different. Two of these companies plan to start accepting credit card payments of initial premiums in 1998. Two more plan to do so in 1999, and another may do so in 2000.

The immature legal environment governing insurance sales by the Internet is a major reason so few insurers presently attempt to make direct sales there. In the U.S., state insurance regulators have not yet completely spelled out the rules under which insurance distribution will occur. Much progress in this area is likely to occur in 1998.

Another barrier to insurance sales over the Internet is technological rather than legal, and it is the relative insecurity of the transmission of credit card numbers via the Internet. In the middle of 1997, MasterCard, VISA, IBM and assorted major technology companies announced their approval of the Secure Electronic Transaction (SET ) open-standard multi-party protocol for the encryption of credit card numbers transmitted on the Internet.

LOMA asked the participants in its mini-survey whether they currently engage in any systems development projects that would make their internal systems able to accommodate the SET protocol. All respondents indicated that they did not. However, three of them plan to begin development using SET in 1998. Another may do so in 1998. One will do so in 1999, and another may do so in 2000.

Two respondents offered comments indicating how the availability of SET has influenced their plans for Internet sales. The first said, "SET definitely has a positive influence in the organization’s decision on implementing aggressive Internet marketing." The second said, "SET increases the probability that my organization will sell insurance via the Internet."

Most credit card numbers now transmitted over the Internet use a session-layer encryption method developed by Netscape called Secure Socket Layer (SSL). Built into Web browsers, it provides a lower level of protection than SET does. SSL does not offer authentication that both parties in a transaction are actually who they say they are. Although many retail merchants are happy to take credit card payments over the Internet protected by SSL, insurance companies and other financial institutions tend to want authentication. Hence their interest in SET.

To understand how SET works, one needs some understanding of how the present credit card payment system works. (Note: The following discussion uses the term, "merchant." An insurance company is a type of merchant.) Credit card transactions normally involve two different banks—the bank that issues the credit card (the issuing or cardholder bank) and the bank of the merchant where the card is used to make a purchase (the acquiring or merchant bank). For each card transaction, the two banks must talk to one another twice, in an authorization stage and a settlement stage.

The first stage is authorization. When a cardholder seeks to pay for a purchase by credit card, the merchant’s terminal contacts the merchant’s bank, which in turn contacts the cardholder’s bank to verify that the credit card has not exceeded the customer’s credit limit and has not been lost or stolen. If the issuing bank indicates there is no problem, the merchant’s bank authorizes the transaction and so informs the merchant, who then executes the transaction.

The second stage is settlement. The merchant’s bank credits the merchant with the payment amount minus a small fee and then contacts the cardholder’s bank to secure reimbursement of the amount. This process is called settlement. The cardholder’s bank then bills the cardholder for the amount.

The credit card organizations operate private networks through which authorization and authentication occur.

SET Protocol

The SET protocol builds on the system described above. Thus, it represents an elaboration of the existing credit card authorization and settlement system, not a substitute for it. Under the present system, when a cardholder presents a card to a merchant and if the authorization process shows no indication the card has been lost or stolen, there is a presumption that the person in possession of the card is the lawful cardholder. There is the presumption that the number on the card is the cardholder’s own account number.

Because the Internet is an open network, others may gain access to the cardholder’s account number. One cannot safely assume that the person who enters a card number at a merchant is in fact the person entitled to that number. (Similarly, the cardholder cannot be sure that an Internet site purporting to be that of a particular merchant is so.) SET attempts to address this problem. Here is how it does so:

• In addition to giving a credit card to a customer, the issuing bank also gives a digital certificate that contains encrypted information confirming that the card belongs to the particular customer. It authenticates the customer. The customer has an "electronic wallet" on his computer integrated into his browser, and the digital certificate goes into it. (The wallet may be accessible via an icon on the customer’s browser.)

• The merchant’s bank also issues the merchant a digital certificate verifying the merchant’s identity. The merchant’s SET-enabled Web server carries the certificate.

• A trusted third party operates a payment gateway, which serves as a bridge between the Internet and the existing credit card authorization and settlement network. It too has a digital certificate. Credit card companies, banks, or other third parties operate payment gateways.

• *When the cardholder visits the merchant’s Internet site and decides to make a purchase, digital signatures are exchanged. The cardholder encrypts his order (the specific merchandise or service he wishes to purchase), attaches his digital certificate to it, and wraps it in the merchant's public key. (See sidebar, How Public/Private Key Encryption Works.) He then encrypts his credit card information, attaches his digital signature to it, and wraps it in the public key of the payment gateway. He transmits both to the merchant.

The merchant uses his private key to decrypt only the order information. He wraps the customer’s encrypted payment information and credit card number in his own digital certificate and forwards it to the payment gateway. (Note: the merchant never sees the cardholder’s real credit card number.)

The payment gateway operator then processes the transaction, which now includes the cardholder’s encrypted payment information and card number plus the merchant’s certificate. The following steps take place: The operator decrypts the transaction and verifies the cardholder and merchant certificates, translates the transaction into the format used by the existing credit card networks, and encrypts it for transmission through them.

The normal credit card authorization process then follows. When the issuing bank indicates its approval, the merchant’s bank so informs the merchant and credits the merchant’s account with the appropriate amount.

At present VISA and MasterCard treat Internet credit card transactions involving SET as "card-not-present" transactions similar to card transactions initiated by telephone. In card-not-present transactions, when a dispute between a cardholder and a merchant arises, the merchant is responsible for proving an order is valid. Beginning on April 1, 1998, VISA and MasterCard will alter their rules and treat SET transactions like card-present transactions. When disputes arise, the cardholder and the cardholder’s bank will have the burden of proof. This change in treatment should make merchants more interested in SET.

There are indications that SET technologies remain somewhat immature. The technology press has reported the following problems:

• The number of calculations involved in encryption causes delays. The whole process reportedly takes 15-20 seconds.

• There are conflicting vendor interpretations of the SET protocol and problems with interoperability.

• The SET protocol continues to be revised.

• Vendor tool development continues.

• In order to participate in SET, vendors must have their SET-enabled software products tested for SET compliance by a neutral third party. Each software component (cardholder wallet, merchant server, payment gateway, and certificate authority) must be tested.

An assortment of SET pilot projects are underway around the world. In addition to VISA and MasterCard, organizations that have particpated in SET development include Microsoft, Netscape, RSA Data Security, VeriSign, GTE CyberTrust, Terisa Systems, SAIC GlobeSET (formerly Interval Systems), COST Computer Security Technology, IBM, and Hewlett-Packard’s VeriFone subsidiary.

How Public/Private Key Encryption Works

Public key encryption offers a secure way for two parties to communicate over an insecure network. When public key encryption is used, everyone has two keys—a public key and a private key. Here, in brief, is how they are used:

• When I want you to communicate with me, I give you my public key.

• You use my public key to encrypt your message to me.

• When I receive your message, I use my private key to unlock it.

• Once you use my public key to encrypt your message to me, you cannot decrypt it, nor can any third party. My private key offers the only way to decrypt it.