ELECTRONIC CASH AND SET
Tony Watson Edith Cowan University
Paper presented at the conference: Internet Crime
Electronic Commerce: Is it Safe?
The concept of electronic commerce is much wider than electronic funds transfer between banks and placing orders for products via an electronic format. What has emerged as economerce is the full range of commercial activities where transactions are partially or wholly undertaken in cyberspace. This paper does not address the environment known as Electronic Data Interchange (EDI) which incorporates the direct exchange of data between institutions and organisations and represents a different set of issues than those associated with business dealings with the public on the Internet.
For years citizens have been seeking assurances that their money is safe both during a transaction and at the source and destination. The failure of banks and financial institutions has clearly indicated some of the dangers involved. The questions as to whether it is safe to conduct business on the Internet, or at the bank, or at a small store in Asia all have the same short answer,
No. All of these examples and many more have resulted in fraud or loss to the individual, but history has shown our society is based on the concept of trade between individuals and nations. Over the centuries the development of trade mirrors the growth of transport and communications. The extension to Cyberspace and the Internet is a natural and inevitable option, but like Marathon Man, the movie, one asks “is it safe?’ The answer of course is relative and like the Troglodytes in the caves in France discovered, hiding from the world as it changes is not a realistic option. The Internet is here and is used by more than 50 million people, so its extension to business is not only inevitable, it represents a change in society’s infrastructure such as the development of shipping and the invention of the airplane.
How safe?
The question we are to consider is how safe is safe? Ross Anderson1 has provided a variety of examples where conventional commercial and banking practices have been shown to be less than safe. In fact his collection of horror stories of the first order demonstrate where the individual has limited rights and almost no power over the infrastructure of the payments systems and their account transactions. We are at the whim and the generosity of the banking system and the apparent lack of understanding of the legal system. Any system where the individual has more apparent control and rights must be attractive.
In Australia the cavalier attitude to interest rates following irresponsible lending policies in the mid-1980s, which lost hundreds of millions of dollars, resulted in banks seeking recovery of their losses with extremely high interest charged to ordinary citizens who were trapped in long-term loans. Was it safe? Lots of small business and farms went bankrupt. Trust in the banking system by the person in the street was irreparably damaged. Part of the issue to be addressed in financial transactions then is the question, Safe for whom?
It is argued that the individual seeks freedom to move money around and obtain ease of access. But can we guarantee this function? Building a cyberspace with this
Figure 1
Transactions in cyberspace
Electronic commerce for the masses in cyberspace essentially means using the Internet for conducting transactions which involves the movement of money in some form.
The growth of interest in the Internet as a commercial environment can be shown on the Internet Host Growth Trends graph:2 The rapid growth of the commercial (.com) domain since 1995 reflects the use of the Web for business activities.
What is really interesting from a marketing perspective is the growth of Internet Access Providers (.net domain) which represent a new group of seriously wealthy consumers. According to an IBM site3 the demographic characteristics of this group are “a consumer marketing specialist’s dream” being:
33 years old
Lives in US or northern Europe
Household income between US$50K-$85K/annum College educated.
In addition to identifying and concentrating attractive user populations to sell goods and services the Internet provides the mechanism to undertake an agreed transaction immediately. Impulse buying becomes a reality.
By most estimates, online commerce is growing dramatically. By 2001 consumers are expected to spend more than $220 billion for products and services online, up from $2.6 billion in 1996, according to International Corporation (IDC) market research. Future growth promises $1 trillion by 20104. It is suggested that no financial institution will be left unaffected by the expansion of electronic commerce and to be absent from the arena will severely curtail the business
opportunities.
The obstacle most likely to inhibit this growth, however, is the lack of secure electronic payments infrastructure. Consumers and merchants are wary of transmitting their payment information over open networks such as the Internet and this caution affects the interest of merchants and financial institutions to trade in this environment. There have been perceived barriers to buying and selling over the Internet as consumers don’t want their credit card data to be recorded inappropriately or stolen and there is the question of validating the owner from the merchants perspective. The major obstacle seen for cyberspace commerce is the inability to undertake a secure guaranteed financial transaction for any participant, whether it’s the merchant, provider, or customer.
One option is the Secure Electronic Transactions, or SET, protocol designed to help breakdown these major barriers to electronic commerce. SET was jointly developed by MasterCard, VISA, IBM and other technology companies. It’s an industry-wide open standard for online credit card transactions. SET is not the only electronic payment system designed for the World Wide Web. It is, however, emerging as the only significant standard for credit card transactions.5
SET helps ensure the privacy and integrity of real time credit card payments transactions over the Internet. The SET protocol only addresses the transaction payment phase -- from the individual, to the merchant, to the acquirer (the merchant’s current credit card processor).6
There is some argument that another option is becoming an alternative de facto standard as merchants have found plenty of ways to collect money over the Internet without SET. The Secure Sockets Layer (SSL) protocol, built into all current browsers, does a fine job of securing the transmission of credit card information.7
The rapid technological changes in the support for the SSL tend to address weaknesses observed in the protocol itself and the universal use of the environment enables the users to remain informed.
Basically the value and importance of a transaction will determine the secrecy and integrity required which in turn will define the authorisation and authentication necessary. In the physical world purchasing an ice cream requires little more than “eyeballing” the vendor and exchanging money for goods. The purchase of a house requires identification of the user, the seller, the property, the freedom of title, mortgage papers and exchange of money (usually via a bank) and is a substantially more valuable and dangerous process. In the latter case some authentication certificates (i.e. title and money transfer) are usually required to provide some form of safety for all parties and yet there still instances where the system fails to adequately protect the parties. Expanding the idea to cyberspace raises the question as to how much authentication is required to handle a $50 purchase and how much for a $50 000 purchase.
Electronic Cash
There are several different options for cyberspace cash ranging from the transaction of real cash into electronic coupons, to artificially created purchasing power and the variations on the conventional credit/debit card transaction options.
Cash is anonymous and to many people this is a fundamentally important requirement and any form of electronic cash should incorporate this basic premise. Cash on a card is now widely used (Mondex, Visa, Mastercard, Europay, HK Jockey Club) giving rise to the term Electronic Purse.
To be favoured by the consumer electronic cash has to possess at least the features of physical cash and preferably some additional benefits. The benefits of cash is anonymity and acceptability to all parties in the trading process. The danger is that it can be lost or stolen. Ecash
therefore has to guarantee anonymity and be acceptable to a broad range of participants in the process , not just merchants, and hopefully improve on the lost or stolen weaknesses of cash. In the broad trading arena banks and similar organisations are the usual source of cash exchange and these bodies are leading in the Ecash arena too with hundreds already operating with an
Ecash offering. These should not be confused with conventional banking which does not cater for the anonymity component, usually by law.
Any payment made by credit card can be linked directly back to the individual cardholder. Even if you are not concerned about the way this may infringe your privacy in general, there are probably some payments you would rather the rest of the world did not know about so the long term secrecy of the transaction is required.
Conventional Credit and debit cards are not the answer to all payment requirements. For small amounts of money the process of authorization and funds capture is too much of an overhead. Exactly what constitutes a small payment is an open question, but the consensus seems to be that anything under $10 U.S. falls into that category. This concept should not be confused with
micropayment options where a fraction of a cent is the value of the transaction. How much protection is required for a $5 payment?
Out in the real world the answer to these difficulties is to pay with cash. On the Web there are a number of initiatives that provide electronic cash payment methods emulating coins and notes in various ways. Some of them use digital coins which are tokens that represent some small monetary amount that are authenticated by the digital signature of a financial institution (bank). Others are closer to the credit card model, with a third party that manages the cash on behalf of a customer.
Here is a sample of some electronic cash schemes:
DigiCash
From the Netherlands this is the largest electronic cash scheme, based on electronic coins. It has a large number of subscribers, both buyers and merchants, and is supported by a number of banks. It uses an innovative blind signature scheme to protect the anonymity of the buyer. DigiCash is located at http://www.digicash.com.
NetBill
This is a scheme developed at Carnegie Mellon University. In this case the cash is not held directly by the buyer, but by a NetBill server. It is primarily designed for delivering for-fee data content. When the buyer elects to buy the data or service the seller sends the data in an encrypted form. It also sends a billing request to the NetBill server. If there are sufficient funds in the buyer's account, the server sends the buyer the key to unlock the data. If the buyer accepts, the cost is deducted from his or her account. Details of NetBill can be found at http://www.netbill.com.
Minipay
This is a scheme proposed by IBM research. It is similar in some ways to NetBill, but its unique feature is that for small payments there is no need for the seller to request funds from the server that holds the account. Each buyer has a daily spending limit and, as long
as it is not exceeded, the seller can be relatively sure that the bill will be paid. The advantage of this scheme is faster, lighter transactions, at the cost of a small additional risk. Minipay is described at http://www.ibm.net.il/ibm_il/int-lab/mpay.8
The bottom line in these cases is that there is a third party underwriting the payment guarantee in some fashion usually as a consequence of deposited funds. There are millions of transactions completed in this fashion. In the likely future these are the services to be provided by banks, else why have a bank?
Secure Socket Layer
The Secure Socket Layer is a program layer created by Netscape for managing the security of message transmissions in a network. Its development is as a response to concerns over the apparent vulnerability of message interception and duplication on the Internet. The Netscape concept requires that the programming for keeping your messages confidential ought to be contained in a program layer between an application (such as your Web browser or HTTP) and the Internet's TCP/IP layers.
The SSL is a protocol providing data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection.
It was designed for transmitting private documents via the Internet. SSL works by using a private key to encrypt data that's transferred over the SSL connection. Both Netscape Navigator and Internet Explorer support SSL, and many Web sites use the protocol to obtain confidential user information, such as credit card numbers. By convention, Web pages that require an SSL connection start with https: instead of http:
The "sockets" part of the term refers to the sockets method of passing data back and forth between a client program and a server program in a network or between program layers in the same computer. A socket is defined as "the endpoint in a connection." Sockets are created and used with a set of programming requests or "function calls" sometimes called the sockets application programming interface (API). The most common sockets API is the Berkeley UNIX C language interface for sockets. Sockets can also be used for communication between processes within the same computer.
The SSL uses the public-and-private key encryption system from RSA, which also includes the use of a digital certificate.
Netscape includes the client part of SSL as part any Netscape Web browser. If a Web site is on a Netscape server, SSL can be enabled and specific Web pages can be identified as requiring SSL access. Other servers can be enabled by using Netscape's SSLRef program library which can be downloaded for noncommercial use or licensed for commercial use. The success of the system requires all parties to agree to use this environment and have trust in the server ownership.
Netscape has offered SSL as a proposed standard protocol to the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) as a standard security approach for Web browsers and servers.9
There is another protocol option for transmitting data securely over the Web known as Secure HTTP (S-HTTP). Whereas SSL creates a secure connection between a client and a server, over which any amount of data can be sent securely, S-HTTP is designed to transmit individual
messages securely. SSL and S-HTTP, therefore, can be seen as complementary rather than competing technologies. Both protocols have been submitted to the Internet Engineering Task Force (IETF) for approval as a standard.10
Just how safe is this Secure Sockets Layer technology? Depends where you are? If you are using a United States version of one of these browsers, then you are taking advantage of "128-bit encryption." This is as secure as Internet transactions need to get with current technology. If you aren't using a United States version of one of these browsers, you are likely to be safeguarded by 40-bit encryption, which offers some protection.
In order to use this Secure Sockets Layer technology, a Web server has what is called a "Server ID" or "Server Certificate". A major vendor in this field is VeriSign, Inc., a leading provider of digital authentication services to companies such as America Online, Microsoft, and Netscape. Typically when one enters an online store using this system your browser changes in appearance. Netscape Navigator displays a blue line at the top of the window and a key in the lower left corner. Microsoft Internet Explorer, AT&T's WorldNet Service browser, and Netscape Communicator display a closed padlock at the bottom of the window. These changes indicate that when you entered the store, VeriSign checked the Server ID and verified the store, and that it is qualified to accept credit card information.11
Design: One-way (and soon two-way) Authentication via RSA and X.509 Certificates which provides an encrypted channel for sending such data as Credit Card numbers .
Figure 2 Protocol:
1. Client sends server a "hello" message
2. Server sends over certificate (includes server's public key)
3. Client creates a session key and sends it encrypted in server's public key
4. Session is encrypted using RC4 with the session key thereafter, HTTP is spoken as usual.12 The first available full strength Java implementation of the SSL v. 3.0 and TLS protocol standards in Europe. It is intended for use by systems integrators and independent software vendors in implementing secure messaging over public networks. Full strength implementation of SSL v. 3.0 Available as Java Socket Extension for both client and server. Provides full strength encryption, integrity checking and authentication X.509 v3 certificate compliant.13
Secure Electronic Transactions
The lifecycle of an electronic transaction includes the browsing (selection), purchase, payment authorisation and payment capture process and the Secure Electronic Transactions (SET) protocols were proposed to undertake the latter three functions using a mixture of public key cryptography and digital certificates. The driving force is Visa and Mastercard and several
leading technology players including IBM, Microsoft, Netscape, SAIC, GTE, Terisa Systems, HP and Verifone.
The major business requirements leading to the development of SET include: Confidentiality
We do not want any details about the payment and the order to which it applies to be visible to someone listening in on the session, whether they are monitoring the network path or lurking on one of the systems involved in the transfer.
Authentication
We want to be sure of the identity of all of the parties involved in the transaction. Integrity
We want to be sure that the data received in a SET transaction is identical to what was sent. Otherwise it may be vulnerable to a man-in-the-middle attack.
Interoperability
We do not want to have multiple versions of the SET software installed, particularly on the customer's browser. Therefore it is important that the protocol will allow implementations from different manufacturers to interoperate with each other.
Note that there is nothing in the specification that mandates this latter outcome and all the vendors could do something different. One should also keep in mind that SET is solely concerned with payments. There are many other pieces of sensitive information that may flow in a Web session, such as names and addresses, personal details, and bank account information. The Web server must use other techniques to protect this kind of data in addition to implementing SET for credit card transactions.14
SET was designed to be comparable to conventional credit card transaction security with these functions:
Privacy of payment data and confidentiality of order information transmission.
Authentication of a cardholder for a branded bankcard account. Cardholder account authentication is ensured by the use of digital signatures and cardholder certificates.
Authentication of the merchant to accept credit card payments. Merchant authentication is ensured by the use of digital signatures and merchant certificates.
Payment information integrity is ensured by the use of digital signatures. Special purpose certificates.
Nonrepudiation for dispute resolution.
The major advantage of SET over existing security systems is the addition of digital certificates (X.509 version 3) that associates the cardholder and merchant with a financial institution and the Visa and MasterCard payment systems. These certificates are a defined sequence of bits based on key cryptography. Digital certificates will prevent a level of fraud that the existing systems do not address. The certificates will also provide cardholders and merchants with the confidence that transactions will be processed in the same high quality manner that Visa and MasterCard transactions are being handled today.15
We are talking about a recent innovation with US Nations Bank announced today (13/1/1998) the successful execution of the bank's first SET Secure Electronic Transaction™, which enables a customer to securely use their credit card over the Internet without fear of another party
intercepting, monitoring or changing the transactions.16
In Australia on the 10th November 1997 Westpac Banking Corporation announced its SET trial. Banks and financial institutions have had networks for electronic payment processing for many years. These networks connect highly secure, trusted computer systems, using dedicated links and powerful cryptographic hardware. A number of international standards exist to define the protocol for messages exchanged over the network.
The challenge for Internet credit card processing lies in producing a scheme that can provide adequate protection at a reasonable cost without compromising trust in any of the existing systems.
During 1995, various financial organizations and technology companies formed a number of alliances aimed at producing standards for credit card payment. This was a confusing time, with a number of competing standards and consortia. The technical community would probably still be arguing the merits of one solution or another, but the two largest credit card companies, Visa and Mastercard, forced the issue of standards. They joined forces with the key software companies to produce a single proposal resulting in SET.
SET is based on ideas from previous proposed standards and is also heavily influenced by Internet Keyed Payment Protocols (iKP), which is the result of research carried out at IBM Zurich Laboratory.
Other credit card payment systems do exist, but they are generally not aimed at the broad market, as SET is. For example, First Virtual Internet Payments System (FVIPS), operated by First Virtual Holdings Inc. is a scheme by which the prospective buyer registers credit card details with First Virtual and receives a personal identification number (PIN). The buyer can then use the PIN in place of a card number at any merchant that has an account with First Virtual. Payment details must be confirmed by e-mail before any purchase is completed. Although this scheme has been successful it is limited due to the requirement for both buyer and seller to be affiliated to the same service. SET more closely follows the model of normal credit card payments, in which the only relationship between the organization that issues the card and the one that processes the purchase is that they subscribe to the same clearing network.17
The cardholder accesses an electronic store, browses the products and services and prepares to order with confidence that the information passed back and forth will be encoded otherwise it could be read. The cardholder software receives the information about the order, as the description of the products or services and the total price including the shipping and handling. The user must confirm this order and supply the payment instruction. The merchant accepts the order and then uses the payment instruction to create authorization and capture requests to send to the payment gateway. The payment gateway translates the request and forwards it to the appropriate bankcard network. If the authorization is given, the payment gateway will send a response to the merchant, who will ship the goods or perform the services indicated in the order. The merchant uses the capture request to initiate the payment from the payment gateway. As in the case of authorization, the payment gateway translates the capture request into a funds transfer to the merchant's account.18
Although making a purchase over the Internet using SET is a relatively simple procedure, the technology operating in the background is complex. There are a number of different types of
cryptography operating to verify the information and the identities of the participants of a transaction and these are of varying degrees of effectiveness. That is weak encryption weakens the SET.
Your transaction is first run through a one-way algorithm that generates a unique value called the Message Digest. This digest is like a digital fingerprint of the transaction that is used later on to test the integrity of the message contents, ensuring that it hasn't been altered since you initiated it.
The message digest is then encrypted using your private signature key, producing a digital signature.
Next, the users system generates a random symmetric key that encrypts the transaction, your digital signature and a copy of your digital certificate provided by a reputable certificate authority, which contains your public signature key. The merchant will require a secure copy of the random symmetric key. Now we are back to is it safe depending upon the reputable authority.
The merchant's certificate has been already been obtained by the electronic wallet, and contains a copy of their public key-exchange key. To ensure that the transmission of the symmetric key is secure, the computer software encrypts the symmetric key using the merchant's public key exchange key. The now encrypted key, referred to as the digital envelope, is sent along to the merchant with the encrypted transaction itself.
The complete message sent to the merchant contains the following items: your symmetrically encrypted transaction, digital signature and certificate, as well as the asymmetrically encrypted key (the digital envelope).
The merchant receives this message and decrypts the digital envelope using their private key-exchange key, allowing them to retrieve the symmetric key.
Using the symmetric key, the merchant decrypts the transaction, your digital signature and digital certificate.
They then decrypt your digital signature with the public signature key you provided via your digital certificate. This recovers the original message digest of the transaction.
The transaction is then run through the same one-way algorithm you used and produces a new message digest of the decrypted transaction.
Finally, this message digest is compared to the one obtained from your digital signature. If they are exactly the same, it provides confirmation that the message content, in this case the transaction information, has not been altered during transmission and it was indeed signed using your private signature key. This step is essential to prevent an insertion attack and a fraudulent transaction replacing the original one.
If the message digests are not the same, then the merchant knows that the message either originated somewhere else or was altered after you signed it. They would notify you that the transaction was not completed and must be repeated.19 Of course this assumes the merchant is honest.
There is some concern on the Internet with research showing that people will pay a premium for a secure transaction. Backed by the Electronic Frontier Foundation, CommerceNet, and auditor Coopers & Lybrand, the eTrust group plan to have a SET implementation.20 Early findings of third-party research funded by eTrust indicates consumers worry about undisclosed online data collection, and will pay more for a transaction that is secure. "Until these issues are addressed, [consumer fears] will inhibit electronic commerce," says Lori Fena, executive director of the Electronic Frontier Foundation.
According to Fena, electronic commerce standards will evolve in the same way that standardized accounting practices gained worldwide acceptance over time. That's why Coopers & Lybrand is investing in the nonprofit venture and setting up processes for notice, consent, and assurance by which eTrust companies will abide.
SET is specifically a payment protocol. It defines the communication between cardholder, merchant and payment gateway for card purchases and refunds. It defines the communication between the different parties and certification authorities for public key signature. It does not define anything beyond that.21
Step Description Defined
in SET
1 Cardholder receives and installs software.
2 Cardholder connects to Certification Authority and requests a certificate
3 Cardholder SET software invoked by CA.
4 Cardholder provides public key and details yes
5 Certificate signed by CA and returned to cardholder yes 6 Cardholder connects to merchant Web site and selects goods to
purchase
7 Cardholder selects payment option
8 Cardholder SET software invoked by merchant
9 Payment request sent to merchant yes
10 Authorization request sent to payment gateway yes 11 Gateway forwards authorization to bankcard network and receives
response
12 Authorization response returned to merchant yes
13 Payment response sent to cardholder yes
Major Players
It is worth noting some of the major players in the SET authentication field. There are now thousands of banks beginning to use this protocol.
VeriSign Inc. is a leading Internet Certification Authority, claiming to be a trusted third party that authenticates, issues and manages digital certificates on the Internet. VeriSign's Digital IDs enable trusted electronic commerce by authenticating the individuals, organizations and content involved in an electronic transaction. VeriSign has issued its branded Digital IDs to nearly 25,000 Web sites and 1,000,000 individuals who use Netscape and Microsoft's Internet products. VeriSign, headquartered in Mountain View, Calif., was founded in April 1995. For more information, please visit the VeriSign Web site at www.verisign.com.22
About Europay
Europay International, headquartered in Waterloo, Belgium, is the European banks' leading provider of personal payment and related services. Presently, 149.9 million cards (edc/Maestro, eurocheque, Cirrus and Eurocard-MasterCard) provide European and global debit and credit services, and offer cash access to Europe's largest network of nearly 168,000 ATMs in 35 countries. Through its alliance with MasterCard International, Europay offers banks products accepted at over 324,000 ATMs and over 13 million locations worldwide. Europay's Web site at http://www.europay.com provides much more information about Europay as well as the possibility of receiving our press releases via E-Mail.
About MasterCard
MasterCard International, a payments company with one of the world's most recognized brands, is dedicated to helping more than 23,000 financial institutions around the world offer consumers a variety of payment options. MasterCard remains focused on helping shape the future of money by expanding acceptance of its global brands (MasterCard®, Maestro® and Cirrus®, the world's largest ATM network) and maintaining reliable, secure networks facilitating global value exchange. MasterCard has 400 million credit and debit cards that are accepted at more than 13 million acceptance locations worldwide. In 1996, gross dollar volume generated exceeded $550 billion. MasterCard can be reached through its World Wide Web site at http://www.mastercard.com.23
Conclusion
There are still some difficulties to be overcome such as the agreed level of encryption to be used and whether in fact we all agree to use the same SET standard for interoperability. However the SET standard looks promising in that it is likely to provide an adequate infrastructure to allow the world to trade globally at an individual level. There is of course no enforcing mechanism and vendors and merchants do not have to comply other than by choice because it offers such a great advantage.
Some questions arising include : Will it be free to the user? For how long? Will the political system allow free trade in this way? What will be the role of banks? What are the international legal implications in the event of a deliberate Internet fraud by a user of the SET? Can we operate without this option? How will the world standardise on encryption strength.
References
1 Anderson, R. (1994) Making Smartcard Systems Robust. Cardis 94. IFIP. Anderson, R. Liability and Computer Security - Nine Principles. In Ellis, B. (ed.) Computer Security.
2 Error! Reference source not found.
3 Error! Reference source not found.
4 http;//www.internet.ibm.com/commercepoint/payment/set-paper.html 5 http;//www..redbooks.ibm.com/SG244978/setbk14.html 6 http://www.redbooks.ibm.com/SG244978/setbk12.htm#Header_1 7 http://www.zdnewsletters.com/eca/981/eca981a.html 8 http://www.redbooks.ibm.com/SG244978/setbk14.htm#Header_1 9 http;//www.whatis.com/ssl.htm 10 http://www.pcwebopedia.com/SSL.htm 11 http://www.family-tree.com/storsecr.html 12 http://www.ncsa.uiuc.edu/InformationServers/WebSecurity/iw3_tut/NETSCAP1.HTM 13 http://java.sun.com/products/commerce 14 http://www.redbooks.ibm.com/SG244978/setbk20.html 15 http;//www.internet.ibm.com/commercepoint/payment/set-paper.html 16 http://www.mastercard.com/press/980113a.html 17 http://www.redbooks.ibm.com/SG244978/setbk14.htm 18 http://www.redbooks.ibm.com/SG244978/setbk22.htm#Header_38 19 http://www.bofa.com/spare_change/set_technology.html 20 http;//www.zdnet.com/cshopper/content/9706/cshp0086.html 21 http://www.redbooks.ibm.com/SG244978/setbk18.htm#Header_2.html 22 http://www.verisign.com/pr/pr_atc.html 23 http://www.mastercard.com/press/970417a.html
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
