But commerce is not so laid-back. At first, vendors were quite anxious about online transactions; credit card companies initially did not want their numbers used in cyberspace—at least, not until cyberspace changed. From the start commerce has pushed for changes in the architectures of the Net to enable more secure and safer commerce.

Of course, there is nothing new about this or about commerce on the wires. As Jane Winn puts it, electronic commerce is “arguably as old as the telegraph.”¹ The 1970s saw a vast increase in closed architecture systems that used the wires (either proprietary or not) to exchange data to facilitate commerce. The significance of the recent birth of e-commerce is that it takes place on an open, unsecured network.² The challenge for commerce on the early Net was to develop architectures that, while sharing in the network advantages of the Internet,³ would restore some of the security that commerce requires.

A kind of “open-system” security was needed, and the most successful early example was Netscape’s secure socket layer (SSL) protocol.⁴ Beginning with Netscape Enterprise Server 2.0, secure servers could exchange encrypted transactional information with Internet browser clients. For example, you could send your credit card number across the Net, and neither you nor Visa would have to worry that it would be intercepted and republished.

The great advantage of SSL was its simplicity and economy, benefits it gained by mixing the best of two different encryption key techniques, symmetric and asymmetric encryption algorithms. The advantage of symmetric encryption is efficiency—it is easier for the computer to decrypt using a symmetric key. The disadvantage is security—you have to pass the symmetric key around, and sometimes it gets lost. The advantage of asymmetric, or public key, encryption is security—you do not have to pass around a private key and risk the key being compromised. The disadvantage is efficiency—it takes a lot of computing power to decrypt an asymmetrically encrypted message.

SSL mixes these two techniques by encrypting the symmetric key asymmetrically. Once encrypted, the symmetric key is safe to use on an insecure network. But because a key is relatively small, it is not a terrible computational burden to decrypt it on the other side. By using asymmetric encryption to protect the key, there is no danger that the key will be revealed in transmission, but by using a symmetric key to encrypt all other data exchanged, the computational burden on both sides is reduced.

The trouble with SSL, however, is that it is trustworthy only if you can trust the merchant on the other side. Your information is not likely to leak in the transmission from client to server. But if the owner of the server is not to be trusted, then the risk you should worry about is not a leaky pipeline.

Other protocols have been proposed to deal with the problem of the untrustworthy merchant, the most prominent of which is the secure electronic transaction (SET) protocol.⁵ SET is a standard adopted by a consortium of credit card companies for exchanging credit card data to facilitate greater security, using a protocol that still simply sits on top of the basic Internet protocol.⁶ With SET, you can be confident that your credit card number will not be overheard and that the merchant cannot misuse your number.

These two protocols are just the first steps in constructing an architecture of security for e-commerce. (Though SET may be a misstep: developed by committee, it is a standard that has proven too complicated to implement effectively.)⁷ They are significant improvements, but they do not represent the real change to come. For e-commerce to develop fully, the Net will need a far more general architecture of trust—an architecture that makes possible secure and private transactions.

The elements of any such architecture are summarized well by Gail L. Grant.⁸ This architecture would have to provide (1) authentication, to ensure the identity of the person you are dealing with; (2) authorization, to ensure that the person is sanctioned for a particular function; (3) privacy, to ensure that others cannot see what exchanges there are; (4) integrity, to ensure that the transmission is not altered en route; and (5) nonrepudiation, to ensure that the sender of a message cannot deny that he sent it.

In real space we achieve each of these elements through familiar real-space architectures of trust. So familiar have these become that we are likely not only to forget the efforts originally made to erect some of them, but also to ignore the features of real space that make these architectures possible. It is usually obvious if an envelope has been opened. If a signature has been changed, we can usually tell. People we know self-authenticate, since we recognize them when they come into a store. If we do not know them, we can check a driver’s license or the validity of their credit card. (Possessing a valid credit card is another kind of self-authentication, though obviously an imperfect one.) We check authorization with structures such as purchase orders or letters of introduction. We protect privacy by using secure envelopes, and we protect integrity by checking for evidence of tampering on a letter that has been received. We use systems of certified exchange (certified mail, guaranteed delivery) to avoid the problem of repudiation of receipt or sending.

[UPDATE POSSIBILITY: describe the important real-world authentication that comes from guarantees credit card companies provide for their customers against 3rd party mis-use.  Essentially, holders "authenticate" themselves by agreeing to pay for all the charges listed on their credit card statement at the end of each month.  If they have been "mis-identified" at any point (ie, unauthorized charges have been made), they can dispute those charges.  Card companies respond with some combination of reversing charges from the merchant and/or investigating who perpetrated the fraud.  These investigations help "authenticate" those who mis-used the card.  It's a klugey system, but it seems to work well enough, perhaps because stiff penalities for credit card fraud discourage mis-identifying oneself.]

Footnotes

¹ Jane Kaufman Winn, “Open Systems, Free Markets, and Regulation of Internet Commerce,” Tulane Law Review 72 (1998): 1177, 1238. Edit Delete

² Once again, of course, even that idea is not new. Telephones have been used to sell things since the birth of phones; they too are an open and insecure network. The same was true of telegraphs before them; see Tom Standage, The Victorian Internet (New York: Walker & Co., 1998). Edit Delete

³ See Mark A. Lemley and David McGowan, “Legal Implications of Network Economic Effects,” California Law Review 86 (1998): 479, 484, 552–53. Edit Delete

⁴ See Richard E. Smith, Internet Cryptography (Reading, Mass.: Addison-Wesley, 1997), 218–28. Edit Delete

⁵ Winn (“Open Systems,” 1210) reports that the SET “protocol developed by Visa and MasterCard [is] currently being marketed . . . as a secure Internet application for any type of bank or credit card.” See also the introduction to the concept of “secure electronic commerce” on the Visa web site at http://www.visa.com/cgi-bin/vee/nt/ecomm/main.html (visited May 30, 1999). Edit Delete

⁶ See Winn, “Open Systems,” 1210–11. Edit Delete

⁷ See C. Bradford Biddle, “Legislating Market Winners: Digital Signature Laws and the Electronic Commerce Marketplace,” San Diego Law Review 34 (1997): 1225, 1242, n.37. Edit Delete

⁸ See Grant, Understanding Digital Signatures, 14; see also Smith, Internet Cryptography, 295–319. Edit Delete