Dr. Dobb's Journal June 2001
The Secure Electronic Transaction (SET) protocol is in place to become the global standard for secure credit-card purchases over the Internet. Developed by Visa and MasterCard as a way of facilitating secure payment transactions over the Internet, SET is an open technical standard for the commerce industry. Digital certificates create a trust chain throughout the transaction, verifying cardholder and merchant validity — a process unparalleled by other Internet security solutions. (For more information on SET, see http://www.setco.org/ and "The SET Standard and E-Commerce," by William Stallings, DDJ, November 2000.)
On the other hand, the Wireless Application Protocol (WAP; http://www .wapforum.org/) is the de facto standard for the presentation and delivery of wireless information and telephony services on mobile phones and other wireless terminals. Handset manufacturers representing 90 percent of the world market across all technologies have committed to shipping WAP-enabled devices. WAP has been covered extensively by DDJ; see, for instance, "The Wireless Application Protocol," by Steve Mann (DDJ, October 1999) and "Creating WAP Services," by Luca Passani (DDJ, July 2000).
While SET software has been primarily implemented in desktop and server environments, demands are increasingly being made for it to be implemented on WAP-enabled mobile clients. However, SET "wallet" software (that is, a cardholder's application) needs to be "thin" because WAP mobile clients run on less powerful CPUs with less memory than on the desktop. Also, SET under WAP needs to provide greater security and more convenience.
In this article, we examine both the SET and WAP protocols, then present a model that uses WAP to support SET with a SET thin client and smartcard technology.
SET operation depends on software that implements a series of protocols installed in the workstations or servers of cardholders, merchants, payment gateways/acquirers, and certification authorities (CA). The processes involved are complex because of the need for multiple security risks to be addressed, for multiple parties to authenticate one another, for the approaches of multiple payment processing services providers to be accommodated, and to reflect the needs and practices of multiple countries around the world.
The representation we present describes the establishment of the necessary framework, and the conduct of a payment transaction. Each of the participants has to create a key-pair, store the private key in a secure manner, and make the public key available to organizations that seek it. SET envisages a hierarchy of certification authorities, independent from other CA hierarchies.
Cardholders acquire a certificate from the CA of their card issuer, a copy of which they can provide whenever they make a purchase. Each card issuer acquires a certificate from the CA of each payment-processing organization they use. Each payment-processing organization acquires a certificate from the root CA.
To effect a transaction, cardholders invoke software on their workstations that initiates the following sequence:
1. Cardholders state that they wish to make a payment.
2. The merchant responds.
3. Cardholders provide details of the amount to be paid, together with a copy of their certificate.
4. The merchant sends to the payment-processing organization (via the payment gateway or acquirer) a request for authorization.
5. Authorization is handled by existing processes using existing networks.
6. The merchant receives authorization.
7. The merchant sends a capture request (to actually commit the transaction).
8. The merchant receives confirmation that the transaction has been accepted.
9. The merchant sends cardholders confirmation that the payment has been accepted.
The scheme uses accepted technologies (including public-key encryption, digital signatures, and certificates) and established protocols (the secure hashing algorithm, SHA, RSA's asymmetric encryption algorithm, DES symmetric encryption algorithm, and X.509 Version 3 certificates). The scheme promises secure transmission, and a considerable level of confidence that the participants have the authority to undertake the transaction.
The WAP architecture provides a scalable and extensible environment for application development for mobile communication devices. This is achieved through a layered design of the entire protocol stack; see Figure 1. Each of the layers of the architecture is accessible by the layers above, as well as by other services and applications.
The WAP layered architecture lets other services and applications utilize the features of the WAP stack through a set of well-defined interfaces. External applications may access the session, transaction, security, and transport layers directly.
The Wireless Transport Layer Security (WTLS) is a security protocol based upon the industry-standard Transport Layer Security (TLS) protocol (formerly known as Secure Sockets Layer, or SSL). WTLS is intended for use with the WAP transport protocols and has been optimized for use over narrow-band communication channels. WTLS provides the following features:
WTLS may also be used for secure communication between terminals; for example, for authentication of electronic business-card exchange.
Applications are able to selectively enable or disable WTLS features depending on their security requirements and the characteristics of the underlying network (for example, privacy may be disabled on networks already providing this service at a lower layer).
Wireless data networks present a more constrained communication environment compared to wired networks. Because of fundamental limitations of power, available spectrum, and mobility, wireless data networks tend to have less bandwidth, more latency, less connection stability, and less predictable availability. Furthermore, as bandwidth increases, the handset's power consumption also increases, further taxing the already limited battery life of a mobile device. Therefore, even as wireless networks improve their ability to deliver higher bandwidth, the power availability at the handset will still limit the effective throughput of data to and from the device. A wireless data solution must be able to overcome these network limitations and still deliver a satisfactory user experience.
Similarly, mass-market, handheld wireless devices present a more constrained computing environment compared to desktop computers. Because of fundamental limitations of battery life and form factor, mass-market handheld devices tend to have less powerful CPUs, less memory (ROM and RAM), restricted power consumption, smaller displays, and different input devices (phone keypads, voice input, and so on). Because of these limitations, the wireless handset user interface (UI) is fundamentally different than that of a desktop computer. The limited screen size and lack of a mouse requires a different UI metaphor than the traditional desktop GUI.
These conditions are not likely to change dramatically in the near future. The most popular wireless handsets have been designed to be lightweight and fit comfortably in the palm of a hand. Furthermore, consumers desire handsets with longer battery life, which will always limit available bandwidth, and the power consumption of the CPU, memory, and display.
Because there will always be a performance gap between the best desktop computers and best handheld devices, the method used to deliver wireless data to these devices must effectively address this gap. As this gap changes over time, standards have to evolve to keep pace with available functionality and market needs.
The web architecture provides a flexible and powerful programming model. Applications and content are presented in standard data formats and are viewed by browsers. The web browser is a networked application — it sends requests for named data objects to a network server, which responds with the data encoded using the standard formats.
The WAP programming model (Figure 2) is similar to the web model. This provides several benefits to developers, including a familiar programming model, proven architecture, and ability to leverage existing tools (web servers, XML tools, and so on). Optimizations and extensions have been made to match the characteristics of the wireless environment. Wherever possible, existing standards have been adopted or have been used as the starting point for the WAP technology.
Figure 3 describes how WAP client support can be implemented with the SET payment protocol. There is end-to-end security between a WAP client and server-based wallet with WTLS-like SSL channel protocol. Server-based wallets serve as cardholder software and connect with SET's CA, payment gateway, and merchant server. Because normal SET cardholder software is almost 4 MB, WAP clients cannot install it.
To support SET under WAP, the current "fat" (client-based) SET electronic wallets that reside on cardholder's PCs have demonstrated problems. WAP clients have less powerful CPUs and memory, and cannot install large software packages.
These deployment barriers can be directly addressed with a server-based wallet strategy. A server-based wallet with a thin client has its functionality divided into two parts: a 50-KB thin wallet interface residing as a client on the WAP client and a larger wallet engine residing as a server at the operations center of the issuing bank ("issuer") or financial institution.
Thin wallets let users enter purchase instructions and view account information stored on the wallet engine server. Because of the thin wallet's size, it is easy to download and maintain the wallet engine at the operation center, which handles SET transaction messages, manages the cardholder's account information, and the cardholder's purchase (transactions) histories. The engine also communicates with the other SET components managing the cardholder's digital keys and certificates, which support the SET security protocol. Because it resides at the ops center, the wallet engine can offer better security, improved disaster recovery, improved transaction accounting, reduced support costs, and other significant operational benefits. In addition, this product offers marketing benefits such as simplified branding and international customization.
In the simplest terms, a server-based wallet replaces a distributed wallet strategy with a centrally managed wallet supporting multiple wallet interfaces. That is to say, with the fat wallet strategy, many wallets are distributed to cardholders from the issuer. With server-based wallets, a single wallet engine at the issuer's operations center can support many cardholders who communicate with the central wallet engine though a thin-wallet user interface.
Figure 4 describes a current fat wallet. Each cardholder receives a fully featured wallet from the issuing bank. Account information, as well as keys and certificates, are stored in the wallet on the cardholder's PC.
Figure 5 describes the server-based wallet. A thin-wallet interface is downloaded or distributed from the bank. SET functionality is managed by a centrally located server engine supporting multiple users in the field. User account information is securely stored on the issuing bank's operations server.
A server-based wallet divides the wallet functionality into:
WAP enables a flexible security infrastructure that focuses on providing connection security between a WAP client and a wallet server. WAP can provide end-to-end security between WAP protocol endpoints. If a browser and origin server desire end-to-end security, they must communicate directly using the WAP protocols. End-to-end security can also be achieved if the WAP proxy is trusted or, for example, located at the same physically secure place as the origin server. Figure 6 shows how a WAP client securely connects a SET wallet server.
The Security layer protocol in the WAP architecture is based on WTLS. The WTLS layer operates above the transport protocol layer. The WTLS layer is modular and depends on the required security level of the given application to determine whether it is used. WTLS provides the upper level layer of WAP with a secure transport service interface that preserves the transport service interface below it. In addition, WTLS provides an interface for managing (creating and terminating) secure connections.
The primary goal of the WTLS layer is to provide privacy, data integrity, and authentication between two communicating applications. WTLS provides functionality similar to TLS 1.0 and incorporates features such as datagram support, optimized handshake, and dynamic key refreshing. The WTLS protocol is optimized for low-bandwidth bearer networks with relatively long latency.
The server-based wallet supports four primary methods of authentication between the wallet-interface and server-based wallet. Cardholder authentication does not take the place of normal, in-band SET authentication. Authentication of all end entities still occurs in the normal certificate processing transaction flows. The only difference in SET authentication is that the SET cardholder certificates are now stored at the server-based wallet instead of the cardholder's machine.
For authentication, the server-based wallet contains a general-purpose certificate authority application. This CA subsystem should not be confused with a SET CA product. This CA subsystem is used exclusively for generating, issuing, and managing certificates used for server-based wallet authentication. The server-based wallet first generates its own root certificate. The root certificate is then used to issue the key exchange and signature certificates used for server-based wallet authentication. These certificates are maintained in the CA subsystem and are also known as "server-side certificates."
The CA subsystem is also used to issue authentication certificates for user wallets at the cardholder's machine. These certificates are signed by the server-based wallet and issued to cardholders at registration. These are not SET certificates but general-purpose certificates used for authentication of user wallets. These cardholder certificates are managed through the standard WTLS implementation within the cardholder's browser. These certificates are also known as "client-side certificates."
Four methods of authentication from wallet interface to server-based wallet can be supported:
In the first authentication method, usernames and passwords are assigned to cardholders by the issuing bank after registration. When the cardholder's browser receives a wake-up message from the merchant SET POS, the cardholder wallet initiates a WTLS connection with the server-based wallet. The server-based wallet sends its WTLS certificates to the browser for validation. Once the cardholder's browser authenticates the server-based wallet instance, an HTML form is sent to the browser asking the user to log in via username and password. This is the lightest form of authentication that the server-based wallet can offer.
The second authentication method process is nearly the same as in the first. The difference occurs after the cardholder's browser authenticates the server-based wallet instance. At that point, the cardholder's browser sends its certificates to the server-based wallet for validation against the CA subsystem. Thus, two levels of public-key authentication occur here. After certificate validation by the server wallet, users log into the server-based wallet, and the wallet interface passes control to the server-based wallet to initiate and complete the SET transaction.
The third authentication method process is nearly the same as the second except that the cardholder's private keys and certificates are stored on a cardholder's smartcard. At the certificate validation time, a message window appears asking cardholders to insert their server-based wallet smartcard. Cardholders then insert the chipcard into a standard card-reader on their PC and the authentication takes place by the server-based wallet via WTLS as in the second method.
The final authentication method is the same process as the third, but the cardholder's certificates and private keys are stored on a signature card. Signature cards are generally less expensive than smartcard because they don't contain a cryptographic engine on the card.
Wireless data networks present a more constrained communication environment compared to wired networks. Because of fundamental limitations of power, available spectrum, and mobility, wireless data networks tend to have less bandwidth, more latency, less connection stability, and less predictable availability. Similarly, mass-market, handheld wireless devices present a more constrained computing environment compared to desktop computers. Because of fundamental limitations of battery life and form factor, mass-market handheld devices tend to have less powerful CPUs, less memory, restricted power consumption, smaller displays, and different input devices (a phone keypad, voice input, and the like). Due to these limitations, the user interface of a wireless handset is fundamentally different than that of a desktop computer. Still, the SET protocol is on its way to becoming the global standard for secure credit-card purchases over the Internet.
DDJ