| ELECTRONIC COMMERCE: On-Line Ordering and Digital Money |
|
Protocols for the Public Transport of Private Information
"Defense, however, is of much more consequence than opulence."
-Adam Smith, Wealth of Nations, 1776
No matter how attractive the shopping venue, it will fail if customers do not feel comfortable and secure coming in and doing business. The Internet is rapidly becoming the universal medium for exchange of transaction information, but there must be standards for the way that information is transmitted. These standards are necessary to make the regular, unsecure channels safe and secure.
Security Protocols
Until very recently, people wishing secure communications over the Internet had to find products implementing security at the application level. In practice, this meant that protected communications had to be protected explicitly by the user before being sent across the Internet, usually in the form of encrypted e-mail. Although it is quite effective when properly used, the consensus of consumers and merchants is that this approach to security is unacceptable. Only when security is built into Internet applications and requires an absolute minimum of interaction by the user will it become acceptable to a mass market.
The Secure Hypertext Transport Protocol (S-HTTP), an extension of the World Wide Web protocol, adds security features just below the application layer. The Secure Sockets Layer (SSL) protocol was originally proposed by Netscape Communications and implemented in their Netscape Navigator Web browser. SSL operates at the transport layer, which means it can be used for private Internet transmissions between systems and programs supporting it.
MasterCard International and Visa International have released protocols to support secure credit card transactions on the Internet, and companies involved with electronic commerce have generally pledged to comply with the standards they produce. Netscape Communications has offered a "digital envelope" protocol called Secure Courier, to secure transactions through digital certification and encryption.
Figure 4-1 illustrates how these different security solutions fit into the Internet data architecture. The Secure HTTP option adds security directly to the application, while the Secure Sockets Layer adds security to the entire stream of data between server and client because it operates just above the transport layer. Secure Courier and other transaction-level protocols operate on the transaction data itself, so it can be transmitted between merchants and financial institutions without compromising that data's security or authenticity even when it awaits transmission from intermediate systems (like the merchant's server).
There are other mechanisms and protocols devised for transmitting transaction information across the Internet, and there will undoubtedly be more in the months and years to come. However, these protocols should represent the type of standards that will eventually define the way business is done over the Internet.
These protocols will be discussed briefly, mostly to examine how they use the Internet, the World Wide Web, and security technologies to make secure commerce possible over the Internet.
Secure Hypertext Transfer Protocol
The Secure Hypertext Transfer Protocol (S-HTTP) is the logical extension of the Hypertext Transfer Protocol (HTTP), which is the basis of the World Wide Web. HTTP defines the interactions between Web browsers and Web servers, determining how requests from browsers (also known as clients) are handled by Web servers. Very simply, a Web browser sends requests for information stored on a Web server, and if that server is connected and the information is available, the server will respond by sending the information back to the browser.
HTTP did not originally include any security features at all, other than those provided by resources accessed through the World Wide Web. For example, HTTP can be used to provide a more user-friendly interface to File Transfer Protocol (FTP) and terminal emulation (Telnet) services, both of which challenge users for user ID and password before providing service. However, the content of Telnet or FTP sessions is transmitted in plain text, and eavesdroppers could intercept the content being sent.
S-HTTP Security Features
The S-HTTP protocol was designed to add security at the application level. The objective was to add support for a wide range of security mechanisms on top of the interactions between Web browser and Web server. Protection mechanisms include the following:
These mechanisms are used as negotiated between browser and server. Any one or more of these mechanisms may be used. The protocol also allows unprotected transmissions.
The S-HTTP specification includes support for many cryptographic formats, including private key and public key cryptography, as well as key distribution schemes like Kerberos. S-HTTP supports use of prearranged and predistributed private keys between individuals, public key encryption in one direction (using the server's public key only and not requiring the browser to have a public key), and two-way public key encryption. Each interaction between an S-HTTP browser/server pair is negotiated to determine what protection is available, needed, and capable of being used. Option negotiation can be driven by the requirements of the browser or the server, so either end of the transmission can request protection of some sort for that transmission.
The S-HTTP specification was written to offer the widest latitude in implementing security, with a variety of different cryptographic methods to ensure compatibility across national boundaries (using technologies approved for export from the United States) or between browser and server supporting other technologies.
Secure HTTP Data Transport
S-HTTP encapsulates the HTTP interactions between browser and server. This means that data being sent from browser to server (or vice versa) is contained within a special S-HTTP chunk of data. Figure 4-2 shows the concept of encapsulation. This chunk uses the same basic format as HTTP (which is also the basis for data sent via e-mail and Usenet news communications), indicating the source and destination systems and other information required by TCP/IP.
Encapsulated data sent across the Internet is comparable to a package that has been wrapped in plain brown paper and addressed for delivery by an express service. The contents of the package are irrelevant, and intermediate handlers do not know (nor do they need to know) exactly what is inside. However, the package will have delivery instructions printed on the outside - headers are the parallel structure for Internet data. When a package of data arrives at its destination, the recipient program takes the headers off and interprets the data inside as appropriate.
The typical HTTP session starts out with a user starting up a Web browser. This browser may be pointed to a home page at a remote Web server. On startup, the browser application program sends out an HTTP request to that server for the information on that home page. Assuming the server (and specified home page) is able to respond, it sends back the requested hypertext document (a document created with the Hypertext Markup Language - HTML).
S-HTTP Explained
For the details of the S-HTTP implementation, the reader is referred to the appropriate Internet RFC and Internet-Draft documents (see Appendix B for more details). This section summarizes the extra headers that S-HTTP defines for data connections between servers and browsers on the World Wide Web.
Secure HTTP Header Lines
There are two required header lines for S-HTTP, one identifying the type of content contained within the S-HTTP message ("Content-Type") and the other identifying the general cryptographic implementation being used ("Content-Privacy-Domain").
Other headers are optional, and have the following uses:
The Content-Privacy-Domain header allows the use of digital signatures alone, encryption alone, both signatures and encryption, or neither. Encryption options include use of public key pairs, or encryption with a prearranged key (previously exchanged off-line or by some other mechanism).
S-HTTP Message Contents
The message sent by an S-HTTP browser or server can itself be simple data (a protocol request or response to a request). It could also be HTTP data (a response to an HTTP request for a Web document) or another S-HTTP message (a message that has been digitally signed could actually be an encrypted message).
The contents of an S-HTTP message are interpreted by the receiving entity (browser or server) based on how the data package is labeled, and what kind of security treatment has been negotiated.
S-HTTP Security Negotiation Headers
S-HTTP adds a set of security negotiation headers used to negotiate security options. Four different issues are negotiated between server and browser:
The negotiating process allows two S-HTTP compliant participants (a browser and a server) to negotiate secure transmissions using the cryptographic facilities that both support, and that both require to transmit sensitive information securely.
Related Protocol Extensions
Data is requested and delivered across the World Wide Web using HTTP and S-HTTP; after all, those are Hypertext Transfer Protocols. However, there are two other important protocols without which the World Wide Web would not exist: the Uniform Resource Locator (URL) protocol, defining the syntax of web documents and locations; and the Hypertext Markup Language (HTML) protocol, defining the syntax of the documents themselves.
URLs follow a very specific format, usually consisting of three parts: the scheme designation (indicating the protocol used by the underlying document), the Internet host and domain name of the resource hosting system, and the location on that system of the resource document file. Most current World Wide Web resources look something like this:
http://www.loshin.com/home.html
This example indicates a file called home.html residing on a server called www.loshin.com using the HTTP protocol.
Now, URLs can use a protocol designator of SHTTP to designate a resource using Secure HTTP.
The Hypertext Markup Language uses tags, as discussed in Chapter 2, to indicate the different functional portions of a hypertext document. For example, a paragraph of text is set off by a paragraph tag; a bullet list of items is set off by tags indicating that it is a bullet list.
Security enhancements are not necessary for every piece of data sent from a secure server to a secure browser, so new HTML tags have been defined to mark certain hypertext elements as requiring some kind of security treatment, and to store supporting security information. This information includes the type of security enhancements to use when sending data, cryptographic options to be negotiated, and other options.
Secure Sockets Layer
In a way, S-HTTP can be considered to be typical of a traditional Internet application solution: It adds security and reliability functions to an application, at the application level. In other words, the browser on one side and the server on the other negotiate their own security independent of the underlying network protocols. The result is that the underlying network protocols need not be reliable or secure to support reliable and secure interaction at the application level, and it is not necessary to make any changes to the basic underlying network implementation.
However, another approach to security is to add a layer on top of the existing network transport protocol and beneath the application. The Secure Sockets Layer (SSL) protocol takes this approach by adding an intermediate step, requiring negotiation of secure transmission options, to the establishment of a network connection. Data flowing between the client and the server on that connection is encrypted before transmission and decrypted before it can be used by the receiving system, as shown in Figure 4-3.
One advantage of this approach is that SSL can be applied to any Internet application, not just the World Wide Web (although it was initially implemented only under HTTP). A second advantage is that once the SSL connection has been negotiated between a server and a client, the resulting data communication channel is private, authenticated, and reliable.
SSL links are initiated with a handshaking exchange between the server and the client, during which the two systems exchange necessary cryptographic information to support the secure channel. After this information has been exchanged, the application programs must subject their transmissions to the required cryptographic treatment and then send them on to a destination application program - which must then subject that data to the cryptographic treatment necessary to decrypt and authenticate it.
SSL was originally developed by Netscape as the basis of its secure World Wide Web server. It is implemented in Netscape browsers which have been distributed widely. Netscape has made the SSL specification publicly available as an Internet draft document to insure compatibility between its browsers and servers and other vendors' products. Because by definition Internet applications must be able to interoperate with other implementations of the same applications in order to succeed, there is no benefit to Netscape in making SSL proprietary - if it were not widely implemented, there would be no benefit to purchasing servers or browsers from Netscape.
SSL Record Specification
As with other underlying network protocols (and similar to the way in which S-HTTP encapsulates HTTP data), SSL encapsulates the data transmitted between the client and the server in an SSL record. However, the SSL header is only two or three bytes long, and is primarily used to indicate how much data has been encapsulated and whether that includes data padding to fill out the SSL record. Data padding is often necessary to make sure that the "real" data can be properly encrypted with certain types of cipher.
SSL requires a reliable network transport protocol (one which provides some level of confidence that data is being received by the destination host), which means that data is transmitted using the Transmission Control Protocol (TCP) across the Internet. The TCP headers identify the source and destination of the data, while the application headers that have been encapsulated with the rest of the application data (in other words, the HTTP headers and data) remain secure until it reaches its destination.
Initiating an SSL Session
An SSL session begins after the TCP session is initiated. SSL uses a handshaking protocol, with the client and the software exchanging specific pieces of information in order to build a secure channel for transmitting data. The very first exchange between client and server is in plain text, and contains enough information for the two systems to initiate an encrypted and authenticated data stream.
Figure 4-4 shows a typical exchange of SSL information between a client and a server. Because SSL requires the use of TCP, which itself uses a reliable three-way handshake protocol to initiate a connection, the server begins the session by awaiting the opening transmission from the client. This is called a "client-hello" message, and includes some challenge data (data which is to be used later to authenticate the server) and specifications of supported ciphers.
Upon receipt of this message, the server responds with a random connection ID, its own cipher specifications, and its own digitally signed public key certificate. In response, the client sends off two messages in succession: first, it sends a "client-master-key" message, in which a master key is delivered to the server as the basis for further communication. This master key is encrypted with the server's public key, meaning that it can only be decrypted with the server's private key. The client follows this message with a "client-finish" message, indicating that it is ready to start receiving SSL data. This message includes the connection ID supplied by the server, but encrypted using the client's private key, meaning that it can be decrypted using the client's public key - this authenticates the message as coming from that client.
Completing the handshake, the server responds with a "server-verify" message, followed by a "server-finish" message. The server-verify message functions as the server's digital signature and includes the challenge data mentioned above in the client-hello message - but encrypted with the server's private key. This message can be decrypted using the server's public key, and this authenticates the server to the client. The server-finish message includes a new session identifier, also encrypted with the server's private key.
Other SSL Options
SSL provides a mechanism for a client and server that have already initiated a connection to reconnect without having to renegotiate encryption options. This process starts with the client sending a client-hello message that refers to a previous session identifier. Both client and server maintain a cache of session identifiers which include encryption options received from the other system. If the server recognizes the client and the specified session ID, the SSL channel can be initiated without the need to resend any keys.
The connections described so far will authenticate the server to the client, but client authentication is also possible with SSL. The server can request authentication information with a "request-certificate" message after the server-verify message, which includes a different bit of challenge data. The client must encrypt this new data with its own private key, which the server will be able to decrypt using the client's declared public key, thus authenticating the client.
Integrating Security Protocols Into the Web
Using SSL or S-HTTP is a matter of using special identifiers to indicate World Wide Web documents that require them. For example, a URL indicating a document defined with the Hypertext Transfer Protocol would look something like this:
http://www.loshin.com/MAIN.html
The first part of the URL identifies the scheme which must be used to transmit that document. To require S-HTTP to transmit a document, its URL must be defined in the form
shttp://www.loshin.com/SECURE.html
In this case, the scheme, SHTTP, is defined as Secure HTTP; any browser which supports Secure HTTP will respond appropriately to initiate a connection.
Documents requiring the browser to support SSL use a different scheme, HTTPS, with a resulting URL that looks like this:
https://www.loshin.com/SECURE.html
It should be noted that browsers which have been written to the HTTP specification are supposed to handle schemes which they don't support gracefully. A browser that does not support S-HTTP would not be able to negotiate with the server to access a document defined with S-HTTP - but it should be able to access any HTTP document on the same server. The same goes for SSL, so merchants should be able to maintain secure information and insecure information on the same server.
Secure Courier
SSL and S-HTTP address the issue of security only as it relates to the communication channel between the client and the server. This may be acceptable for certain applications, but it leaves a very wide security hole: the processing of the transaction information that is done after the customer's order and payment information are received (securely) at the server.
In July of 1995, shortly after announcements by Visa and MasterCard that the two credit card giants would cooperate on secure card transaction specifications, Netscape made public a proposed secure credit card transaction protocol. Netscape trademarked the name "Secure Courier" for its protocol, which describes a set of procedures for placing sensitive data in "digital envelopes" which can be opened only by authorized individuals or organizations. This allows a customer to make a purchase from an on-line merchant using a credit card, confident that the credit card account information can be seen only by the financial institutions that need to know it.
While it is too soon to predict whether the Secure Courier protocol will gain acceptance or not, it is useful to examine it as an example of the type of protocol used to secure and guarantee commercial transactions over public networks. Secure Courier is most useful in this instance as an example of how digital envelope protocols operate rather than as a definitive operational protocol. It should be noted that CyberCash, Inc., created and implemented a similar protocol as early as April 1994, which has the additional advantage of being a browser-independent implementation.
Securing Electronic Payments
Netscape's electronic commerce payment protocol addresses the needs of three different parties to electronic transactions:
It is assumed that the customer and the merchant are communicating over a secure channel (SSL, for example), and that the merchant and the payment gateway are also using a secure channel to communicate, as Figure 4-5 illustrates. The problem, however, is that a channel will work securely only between its two end points. The data transported on a secure channel is decrypted once it arrives at its destination.
An electronic payment protocol must provide these important end-to-end security features in a way that persists even if the payment information passes over more than one secure channel:
These functions are required by an electronic payment protocol in order to fulfill the needs of all the participants (customer, merchant, payment gateway). These needs include:
Electronic Payment Requirements
Electronic commerce participants have different levels of concern about any given transaction, yet it is to everyone's benefit to make sure the transaction is secure. This includes protecting the actual information carried by any given transaction, as well as ensuring that each participant can be held accountable for his, her, or its activities through non-deniable, digitally signed communications.
The customer is assumed to want transaction information kept private wherever possible. All of it should be kept from eavesdroppers through the use of a secure transmission channel, but banks may also want to keep credit card information out of the hands of the merchant to avoid the possibility of its unauthorized use. However, in the event of a disputed transaction it is the merchant's obligation to produce supporting information, which includes the credit card number. Likewise, the customer as well as the merchant may also want to avoid having order information available to anyone else, including the payment gateway - or the financial institution issuing the credit card.
The merchant wants to be able to communicate enough customer information to the payment gateway to be able to get back authorization for the transaction. The payment gateway wants to be able to receive transaction information from the merchants subscribing to its service, interpret it correctly, and authorize as required.
Using Secure Courier
This protocol makes certain assumptions about how electronic commerce happens. First, all merchants and payment gateways will have their own public keys, while customers may or may not have them. Next, it is assumed that on-line transactions take place across secured channels on the Internet, particularly using SSL. Finally, this protocol assumes that the customer browses the merchant's electronic store and selects items for purchase by credit card.
This process uses several different cryptographic structures to assure reliability and security:
This protocol combines these various constructs to create structures which can be passed between different participants in the process as if they were sealed envelopes, signed forms, or a combination of both.
The Digital Envelope
The most important construct for this protocol is the "digital envelope." Figure 4-6 shows how this works. The data to be placed in the digital envelope is encrypted using some secret key. This becomes the contents of the envelope. That key is then encrypted itself, using the public key of the intended recipient. Now, only the intended recipient can decrypt the key used to encrypt the data within the envelope.
The result is that the on-line customer can use the public key of the payment gateway organization to encrypt an envelope containing credit card information. The merchant does not need to be concerned with that information, only whether or not the payment gateway returns an authorization on the credit card. However, allowances have been made to permit the merchant access to this information - for example, where the purchase is a subscription, partial fulfillment, or payment over time, and requires re-authorization over time.
Secure Courier Transactions
Figure 4-7 illustrates the flow of information among the participating entities. The transaction process starts when the customer is finished shopping and has made a selection. The customer sends a purchase request message to the merchant, who responds with an offer for purchase. Once the offer has been made, the payment processing protocol begins - up to that point, existing security protocols are relied on, like SSL and S-HTTP.
If the customer deems the offer acceptable, a purchase order and "Slip" are sent back to the merchant. The purchase order contains information about the purchase to be made:
Since this information goes over a secure channel, it is not necessary to treat it further, beyond adding a message digest.
However, the sales slip, or Slip, contains some more sensitive information about the transaction:
This information is necessary to authorize and clear credit card transactions, but it is needed by the clearing entity, not the merchant. Therefore, this can be encrypted through the customer's client software (e.g., Web browser) and sent on to the merchant along with the purchase order.
When the merchant receives these messages, they can be forwarded to the payment gateway with a request to authorize the payment. The payment gateway responds with a digitally signed authorization code (or a denial).
The protocol also provides for optional acknowledgments for all messages between all participants. It also specifies other types of messages:
The merchant can apply for authorization codes on a purchase separately from the clearing of the transaction - for example, when a charge is being made in advance, as with a hotel stay. Returns are dealt with in a manner similar to purchases, except the amount to be authorized/cleared is a negative sum in those cases.
The Visa/MasterCard Standards
At the end of June, 1995, Visa International and MasterCard International announced jointly that they would integrate their efforts to offer a method for securing bank credit card purchases across the Internet and other open networks. The press release stated that the two organizations would support a set of open protocols to be published by September 1995. This agreement fell apart by late September, and each organization released its own separate specification.
The specifications rely on the use of RSA public key encryption technologies (as do most of the other protocols discussed here) and support the deployment of personal computer software supporting the payment security protocol. It is widely expected that companies providing Internet commerce services will rapidly adapt to these standards.
Back to ELECTRONIC COMMERCE: On-Line Ordering and Digital Money
© 1996-2003 Charles River Media. All Rights Reserved