WAP

WAP

The Wireless Application Protocol (WAP) is considered by some to be the standard in wireless communications. WAP specifications were developed by members of the WAP Forum. (Those who sit in opposition to the assertion that WAP is or will become the standard in wireless communications find themselves on the WAP Is Crap bandwagon.) The WAP Forum was started by Phone.com (then Unwired Planet, now Open Wave) and joined shortly thereafter by Nokia, Ericsson, and Motorola. Although its pricey admission fee of $27,500 did prevent other companies from initially investing in the development of the WAP standard, the WAP Forum is open to any group that pays the admission fee. Currently, there are nearly 1,000 members, including a variety of smaller companies representing different interests from those of the four founding members.

There is great debate in the development community whether WAP, because it is a protocol standard like 802.x, should be open for comment and criticism from individuals other than members of the WAP Forum. Still, the members keep their doors closed to outside comments. WAP is in its early stages, with planned updates to be released periodically over time. Whether its critics are right and whether it does succeed, WAP is a technology that has had and will continue to have an effect on the wireless industry.

The WAP Forum published this global wireless protocol specification based on existing Internet standards, such as XML and IP, for all wireless networks. WAP is primarily used in Europe, although it sees a small penetration in U.S. wireless markets. More than 75 percent of cellular phones are shipped with it worldwide. Fewer wireless-enabled PDAs, however, implement WAP than cell phone manufacturers. This could be due, in part, to the main products produced by the founding members of the WAP Forum or could be merely coincidental.

Several components of WAP are essential to understanding its security features and limitations. First is its protocol stack. WAP functions higher on the protocol stack than does Bluetooth or 802.11b. Because these three technologies do not function at the same level, drawing salient parallels among the three is difficult. In wireless markets, however, these three are the forerunners in the race for the most pervasive wireless system paradigm.

After studying WAP's protocol stack, it is imperative that you become familiar with the workings of WAP architecture. Its devices, languages, gateways, and networks lend insight into how to best prepare a system for protection against its security limitations. First, we will examine the protocol stack, shown in Table 3.1.

Table 3.1 illustrates a mapping between wired Internet components and WAP components. Although the WAP stack is, in large part, derived from the ISO OSI reference model, it describes only five layers to the OSI model's seven. It is similar to the Web or Internet model, as shown in Table 3.1. The WAP specifications define each layer of the protocol stack by designing mechanisms that facilitate communication from smaller devices through slower connection speeds over networks with high degrees of latency, with the intent of enabling them to integrate with other wired infrastructures.

Table 3.1. The WAP protocol stack
Functionality	Internet	WAP
Application layer	HTML JavaScript	Wireless Application Environment (WAE) WML, WMLScript
Session layer	HTTP	Wireless Session Protocol (WSP)
Transaction layer	HTTP	Wireless Transaction Protocol (WTP)
Security layer	TLS-SSL	Wireless Transport Layer Security (WTLS)
Transport layer	TCP UDP	Wireless Datagram Protocol (WDP) User Datagram Protocol (UDP)
Network layer	IP	Bearers: GSM, SMS, USSD, GPRS, CSD, CDPD, etc.

The top layer in Table 3.1, the Wireless Application Environment (WAE), provides a framework for the development of portable applications and services. The WAE provides residence for WAP's native languages: the Wireless Markup Language (WML) and its partner script, WMLScript. The two languages are based on ECMA script (a predecessor to JavaScript) and are designed to allow development in small chunks to save costly transmission time. Both languages are discussed in further detail in Chapter 5, "Languages."

The next lower layer in the protocol stack is home to the Wireless Session Protocol (WSP). This layer provides definition for exchanging content by way of sessions between clients and servers. In the Internet realm, this is handled by HTTP. HTTP also handles the transactions in wired network applications, but in WAP, transactions are handled by the Wireless Transaction Protocol (WTP). WTP offers several methods by which devices can perform transactions; variations among methods are mostly in degree of reliability.

Of particular interest is the Wireless Transport Layer Security (WTLS). This wireless equivalent to Transport Layer Security (TLS) or Secure Socket Layer (SSL) provides authentication, privacy, and secure connections between applications. In WAP specifications, as in Internet communications, this layer is optional. The problem with WTLS is that it does not provide end-to-end security, as might be expected. At a certain point during a communication cycle structured according to WAP specifications, a server, called a WAP gateway, has to decrypt the WTLS packets and encrypt them in TLS or SSL to transmit them securely across network channels that follow wired Internet specifications. For an instant, that information resides in the clear on the gateway and is vulnerable to attack.

The next lower layer in the WAP stack is the transport layer. The Wireless Datagram Protocol (WDP) serves as a divider between the upper layers of the protocol stack and the bearer services provided by the service operator.

WAP Overview

The easiest way to explain WAP is to follow a communication cycle. This example describes how a user with a WAP-enabled cell phone can execute an application that runs via a server-side script on a standard Web server. Figure 3.8 illustrates the process. The user presses a key on her phone that has an assigned URL request. The user agent on the phone sends an URL request to a WAP gateway in the form specified via WTP. The WAP gateway receives the request and translates it into an HTTP request for the same URL. If the transmission is sent using WTLS, the gateway also translates the data into HTTPS. The gateway forwards the HTTP or HTTPS request for the specified URL to the Web server. The Web server processes the request. If the URL refers to a static file, the Web server retrieves that file. If the URL refers to a script application, however, the Web server runs the application and returns its output. This completes one half of the communication cycle. Now the data begins its return trip to the phone.

Figure 3.8. WAP architecture

The Web server passes the requested file or output, along with any HTTP or SSL headers, via HTTP back to the gateway. Again, the gateway performs translations. If the returned information is in a language readable by the phone (in this case, WML), the data is simply forwarded. If the data is in HTML or another language not readable by the phone, a translation server must translate the information into WML. Sometimes this translation is performed on a server other than the gateway, and other times it is performed by the gateway itself. (The search engine Google, www.google.com, currently searches all HTML pages and performs the translation for the user. Other wired Internet engines currently search only the smaller subset of Web pages coded in WML and do not perform translations on behalf of mobile device users.)

Another translation may occur on the WAP gateway when the data is sent via SSL. In this case, the WAP gateway decrypts the SSL-encrypted data and encrypts it in WTLS standard. After the appropriate translations are performed, the WAP gateway verifies the WML content and encodes it, along with companion HTTP headers, into a binary form. This binary form serves one purpose: to minimize bandwidth usage. Now the gateway sends the data as a WAP request over WTP via bearers, finally ending at the phone.

After the phone receives the WAP response, it begins another set of conversions. It parses the WML response and displays the first card of the WML deck on the phone's display screen.

Wireless Application Environment (WAE)

The application environment is the only place security can be anchored with any strength in wireless systems. The WAE is where this must take place in a WAP architecture. The WAE gives developers the tools to construct applications suited for small, limited platforms and wireless communication. Two user agents on the devices compose the WAE: The WAE user agent includes the microbrowser and the text message editor, and the Wireless Telephony Application (WTA) user agent is responsible for the receipt and execution of telephony functions.

The WAE specifications do not provide guidance on implementation or design of user agents. They simply offer formats that can be used for images or text messages with which user agents must comply. The different components of a user agent can vary greatly among manufacturers of both devices and software resident on those devices.

When exploring the WAE, assessing its languages and their potential security risks is important. WML and WMLScript are investigated in greater detail in Chapter 5. In brief, WML is analogous to HTML and based on XML. It uses a deck of cards metaphor. Instead of pages, as they are called in HTML, contained slices of WML are called cards. Each card contains a small amount of text or data to provide smaller chunks of information that need to be displayed at any given time. A group of cards that are packaged together for transmission is called a deck. The encoded WML sent to a user agent from the WAP gateway is decoded into a deck of cards for display to limit network roundtrips.

WMLScript is based on ECMAScript (the same language on which JavaScript is based). WMLScript enables WML to offer value-added services. WMLScript provides the functionality to validate user input and access local functions in a wireless device (for example, WTAI) and supports local messaging in the form of alerts or errors resident on a device to save communication time. WMLScript supports six standard libraries, which are explained in Chapter 5. WMLScript is called via URLs and is not embedded in WML, as in <a href="calling.wmls#calculate(2,3)">. No type checking is done at either compile time or runtime, and no variable types are explicitly declared. WML/WMLScript developers can and must develop their own libraries to maximize the capabilities of these minimalist languages.

Another significant component of the WAE is the Wireless Telephony Application (WTA). The WTA provides access to the phone's telephony facilities, allowing service providers to accept and initiate calls, send and receive text messages, add, search, and remove phonebook entries, examine call logs, send tones during calls, or press keys on a keypad during a call. It allows the Internet to access mobile phone functionality resident either on the client itself or in the mobile network. A framework for WTAs allows access to telephony functionality from within WMLScript applets. This enables operators to develop secure telephony applications integrated into WML/WMLScript services. For example, services such as call forwarding may provide a user interface that prompts the user to make a choice between accepting a call, forwarding it to another person, or forwarding it to voice mail.

Each of the telephony features appears attractive to would-be attackers of wireless systems. To protect against the dangers of unauthorized use, WTA services assume that users will visit only trusted WAP gateways, where they then connect to WTA servers. The WTA servers regulate the WMLScript functions that can be passed to a device that accesses WTA functions and stores the libraries used to invoke WTA functions. These servers are controlled by wireless operator networks and are assumed to be trusted.

The WTA and WAE specifications do not dictate any native security on the mobile device beyond this minimal precaution. If a WTA server or WAP gateway was compromised, the regulation of WTA functions for phones would be inept and would leave all devices communicating through the system open to compromise. It would be possible for scripts to erase phonebooks, steal phonebook data, place unwanted phone calls, or otherwise tamper with telephony functions. The Wireless Telephony Application Interface (WTAI) facilitates the interoperation of the WTA user agent with either the telephony functions residing on the device itself or those housed on the wireless operator's network.

Another security precaution inherent in WTA specifications is that the device manufacturers (both hardware and software) appropriately assign permissions for scripting on the phone. Three permission types are available to access WTA functionality:

1.       Blanket permission to access all functions within a WTAI library

2.       Context permission to run a given WTA function within the current execution context

3.       Single-action permission to access a given WTA function once

The WAP specifications do not require these permissions to be established or configured at a certain point in the creation of a device or application. Caution in its implementation is left up to developers. WTA specifications do not even specify default settings, so if left unconfigured, the telephony functions appear wide open. The settings are potentially determined by the wireless service provider. If history is any indication, service providers will preconfigure devices with liberal permissions to permit access to their own scripts without regard for other potentially malicious scripts.

To understand the role of WTA and WTAI more clearly, it is helpful to step through a communication procedure. When there is a need to access a WTA function, the WTA user agent on the mobile device sends a request to the WAP gateway with the name of the library and specific function desired. The gateway then solicits help from the WTA server to obtain the requested function and determine permissions for its use. After receiving a response from the WTA server, it forwards the appropriate code back to the WTA user agent on the mobile device. On the device, the code is run when the WTAI allows it to interface with the phone or network telephony functionality initiated from the code. WTA functions can be stored (in an abbreviated subset) on the device itself to save expensive communication trips to the WTA server. The danger in this is that if the software on the device is tampered with, the permissions and regulatory actions normally performed by the WTA are left to the phone's security.

This possibility presents an interesting dilemma. Trust the WTA gateway, and store more functions on it (allowing it to control all telephony activity on a device), or trust the phone hardware and software manufacturers to implement permissions appropriately, and leave more WTA functions on the phone (affording less trust to a WTA server). There are no easy answers. Without any foundational security model, the severity of attacks against wireless devices will increase as these devices become more critical to users and businesses in storing and processing confidential information. Telephony functions will likely be an area of amateur attacks. Much like e-mail viruses, the types of attacks that target telephony functions will be directed at damaging information, usurping pricing models, or otherwise wreaking havoc on current structure. E-mail viruses do not (typically) exploit sensitive data or seek to steal or alter sensitive data. That class of attack falls elsewhere in our discussion of WAP security than exploiting WTA functionality.

WAP Security

After close inspection of the technical specifications for all aspects of WAP, paying special attention to the WTLS specifications, it becomes increasingly apparent that one major design flaw exists. There is a glaring lack of security design specifications in the WAP framework. The security built in to WAP systems is left entirely to architects and developers. WTLS provides an important piece of the puzzle, but in no way does it provide end-to-end security in theory or in practice. Wired system architects are no strangers to insecure platforms. Smart wired system architects recognize that even if a platform is labeled or advertised as secure, it shouldn't be trusted not if any information it touches holds value or is sensitive.

WAP has the same limitations as other wireless technologies. It is limited by size, space, speed, and cost. The requirements for building a secure system must be tailored when these factors come into play. As some Web application developers are tricked into a false (not to mention, dangerous) sense of security by employing SSL and encryption, so too can wireless developers fall victim to a similar fate. WTLS certainly adds a layer of protection to transmitted data in WAP systems. However, it does not provide any assurance against malicious content that runs on the device or for online application exploits of WAP servers. For this reason, it is necessary to focus the discussion of WAP security on the WAE layer, and specifically on WML scripts that run in the application layer of wireless devices. The scripting threat to WAP-enabled wireless devices is likely imminent. Malicious scripts can infect mobile devices just as they do devices plugged in to the wired Internet.

Many security features in WAP are heavily rooted in trust of entities out of your control. WAP gateways are trusted to decrypt and encrypt data, rendering it open to compromise from various methods of attack. A WAP gateway can be a simple NT server with the necessary applications running, sitting in an unlocked closet in an unlocked hallway of a national wireless service provider's regional office. There is no guarantee that the security proffered by the regional office is sufficient to protect data to the standard you require. Too many links in this chain are variable and unknown for you to assume that all of it can be trusted.

WTLS is employed so that the system is secure, end to end. Partial security is, in reality, insecurity. The security features inherent in the WAE place requirements on WML and WMLScript, as well as on WTA functionality, but their effectiveness is directly tied to the state of their implementation. In WTA functionality, either the device manufacturers or the WTA server must be trusted, both of which are typically out of a developer's control. WML and WMLScript are limited subsets of languages with known security problems. By stripping down already faulty languages, security paradigms for development must be altered. In their current state, WML and WMLScript have to be coded extremely securely to offer the appropriate level of security required in most corporate wireless systems and demanded by consumers who are paying bills, checking secure e-mail, or initiating stock trades via their mobile devices.

In too many places in the WAP architecture, the sole option for designing security is to trust an entity that is out of your control. The only viable solution is to develop security into applications so that your own resources are protected from system compromises and inadvertent or malicious attacks.