Skip Left Navigation Links
Communications Bookshelves 
    Wireless Center
    3G Wireless
    Optical Networks
    Fiber Optics
    IP Telephony
    See all Engineering Bookshelves by Discipline
Category Searches 
    Analog Electronics
    Digital Signal Processors
    Electrical Engineering
    Network Engineering
    Optical Networks
    Protocols & Standards
    Radar Technologies
Something for Everyone 
    Engineering Classics
    New & Noteworthy

Engineering & Science Bookstore > WAP > The WAP Gap
The WAP Gap: Wireless Security and the Wireless Application Protocol

By Khurram Zafar, co-author of Essential WAP for Web Professionals

According to InformationWeek, the estimated cost of damages caused by viruses and computer cracking in US firms in 1999 is estimated to be $266 billion. That represents almost 2.5% of the nation's Gross National Product. The same source reports that the global loss in 1999 due to downtime resulting from security breaches and virus attacks is estimated to be $1.6 trillion.

As the reach of the Internet based applications grows to billions of users, and the overall architecture incorporates another vast source of intruder penetration - the wireless networks - the need for security in WAP based applications grows even faster than in the wired world. The WAP Forum, wireless network operators, device manufacturers, software infrastructure vendors, and application developers all are working to address the security needs of these new breeds of applications. They have done a great job so far, but the work continues to evolve the growing demands of an increasing number of demanding security architects and system administrators.

The Five Tenets of Digital Security

So what is security? A good, reasonably secure system always ensures that the following five basic tenets of security are all well accounted for in the infrastructure, procedures, policies, and people that are associated with the deployment of a system:

  1. Authentication - the process, like a password challenge, used to validate the true identity of the other party;
  2. Authorization - the method of establishing the rights and privileges of a party during its interaction with the system, typically implemented through use of Access Control Lists or ACLs;
  3. Confidentiality - the means of ensuring that any sensitive data being transmitted between the communicating parties can only be read by those parties, for example, by using public key or symmetric encryption techniques;
  4. Integrity - the process of preventing third parties from tampering with the integrity of the message by use of message digests, for example;
  5. Non-repudiation - the means of proving the occurrence of a transaction and the fact that the two parties involved, indeed, take part in its occurrence. Digital signatures and proper logging practices ensure the application of this last security tenet.
WAP Security Architecture

The WAP Forum has made every effort to leverage the existing standards, specifications, protocols, and solutions to develop the wireless application development standard. The same principles are applied to the security provisions incorporated into the WAP architecture as well.

Part of the security architecture is already covered by WAP Forum's decision to leverage the Internet as part of a complete end-to-end WAP solution. WAP uses the newly developed protocol stack to implement the part of the wireless transmission from the WAP client to a WAP Gateway. Existing and proven Internet standards are used for all communications between the WAP Gateway and the application server. The following figure illustrates this a little more clearly.

WAP Security Architecture

New standards and specifications were developed for the WAP zone because most Internet based protocols required high bandwidth, low latency, and stable connections with devices that have a high level of processing power. Due to the absence of all of these features in the wireless world these standards could not be used as is in the WAP zone.

Every effort was made to keep the new standards as close as possible to the corresponding Internet standards, so they can be evolved with relative ease as the Internet standards evolve and to ensure compatibility between them. This is where the gray zone comes into the picture. It consists of everything that happens at the WAP gateway that is responsible for transforming a WAP session into an Internet session, and doing the appropriate data transformations.

Internet Zone: Gateway to Application Server

The Internet security zone is not different in a WAP based architecture than it is in a typical Internet application, where the client is a browser on a user's desktop PC. The only difference is that the WAP architecture replaces the browser with a WAP Gateway that implements the Internet protocol stack on behalf of the WAP client device. Standard TCP/IP based internet security protocols like TLS are employed to secure the communication in this zone.

WAP Zone: WAP Device to Gateway

Since TCP/IP is not used for communication between the WAP client and the WAP Gateway, SSL or TLS could not be used to implement the security. What was needed was a protocol that could sustain the low bandwidth, high latency transport layer. The WAP Forum decided to base that protocol on the proven TLS protocol by removing the overhead where possible without compromising security that would make the protocol suitable for the wireless environment. The result was WTLS or Wireless Transport Layer Security.

Like the TLS in the Internet model, the WTLS operates on top of the wireless transport layer also called the WDP, and below the session layer called WSP. The fact that WTLS runs on top of an unreliable datagram service, and not a reliable transport protocol like TCP/IP, mandates some special provisions to be incorporated to ensure reliable message exchanges during several WTLS operations.

For example, the initial handshake that is used to establish security parameters and authenticate the parties to each other requires that all messages going in one direction be concatenated and transmitted as a single Service Data Unit (SDU). If there is a need, the entire SDU is retransmitted again to ensure that the server receives the multiple messages that comprise the one-way communication in the correct order. More information on the details of the WTLS protocol can be found in the WTLS specifications at

WTLS also uses digital certificates to provide for server or client side authentication, but due to the memory limitation of WAP devices certain attributes are omitted from the X.509 digital certificate specifications. For example, WTLS digital certificates do not contain the Serial Number and Issuer ID fields. Moreover, there is work underway to develop tamper resistant devices called WIMs or Wireless Identity Modules that can be used to store client certificates and other security related information specific to the user. These modules, similar to smart cards, will be portable and the users will be free to use them with any WAP enabled phone.

WTLS implementations are not required to cover all of the security features that have been discussed. Instead the WAP Forum has established three different classes of security implementation, with each defining the required and optional features for its class. Depending on the class of device or gateway being used, the security features can be determined according to this table taken from the WAP-199 Wireless Transport Layer Security Specification document:

The most recent WTLS specifications cover all features in Class 1, except for compression and the smart card interface.

The Gray Zone and The WAP Gap

So then how and where does the translation from WTLS to TLS and vice versa happen and how secure is that process? The fact that the WAP security architecture allows for this question to be asked makes a lot of security architects very nervous.

The simple answer is that the WAP Gateway is responsible for the translation of messages from one protocol to another. Just like it encodes text based WML content into binary WML format before sending it on its way on the air, it has to decrypt TLS encoded messages, convert the content into binary format, encrypt it using WTLS and then send it on its way.

The same happens when the message arrives from the WAP device. It needs to be decrypted, decoded and the resulting WML is encrypted using TLS specifications and then forwarded to the applications server. This clearly implies that the WAP Gateway process gets to see all messages in clear text. There are quite a few things that are ensured to make it hard to damage the confidentiality of the messages. For example,

  • The Gateways at the Network Operator premises are typically secured in a high security data center with very restricted access. It is the customer's responsibility to ensure that it happens before allowing access to its application through that gateway.
  • The message translation including encryption, decryption, and encoding all happen in the memory without the use of any temp files or explicit writes to the disk.
  • No details of this translation are ever logged to disk.

For most security needs this is a good enough assurance provided these points are validated with the network operator (or whoever is hosting the gateway). Regardless, the fact is that in a typical deployment of a secure WAP application, the messages intended to be confidential throughout the transmission do become clear text, even though for a split second, and that is what is known as the WAP Gap! This article wouldn't have been written if a solution did not exist to this problem - it does; provided the enterprises are willing to invest enough time, money, and resources to implement a secure end-to-end communication infrastructure without trusting any intermediary.

Filling the WAP Gap - End to End Security

In a typical WAP deployment, the WAP Gateway is hosted by the network operator. All applications outside the secure network of the operator need to trust the network operator with the security of its content. The network operators do everything to make application developers and content providers confident of the security provisions under which the gateway operates and for most companies that is sufficient security.

Filling the WAP Gap - End to End Security

For those that are not willing to take any chances, the only option is to host the WAP Gateways in their own secure networks. The above figure depicts a possible network and hardware configuration of a WAP based solution.

In this case, the application developer is essentially responsible for setting up its own infrastructure for handling the mobile users that will be accessing the application. Aside from investing in setting up the infrastructure like modem pools, a WAP Gateway, and rack space, monitoring tools and human resources will need to be deployed to manage the system.

Additionally, the WAP devices will have to be configured to use the new gateway for access to WAP content. Although some of the recent WAP devices support multiple gateway configurations, setting one up and then switching between them as the users navigate from one application to another can be a challenging task.

Most institutions that do deploy an end-to-end secure solution like this require their users to carry company-sponsored phones with pre-configured gateway configurations and access to WAP applications hosted on their app servers only. Currently this is the only way to ensure end-to-end secure communications between a WAP device and an application server and it has its obvious pros and cons.

Some gateways, like the OpenWave's Up.Link server support the deployment of proxy gateways at the customer premises. In this model, selected incoming calls can be temporarily routed to the proxy gateways installed within the secure premises of the customer hosting an application. The network operator retains the control of the calls at the cost of sharing the burden of supporting the infrastructure required for end-to-end secure communications.


As the reach of the Internet based applications grows to billions of users, and the overall architecture incorporates another vast source of intruder penetration - the wireless networks - the need for security in WAP based applications grows even faster than in the wired world. But last year's Denial of Service attacks on some of the most prestigious internet web sites like eBay and Amazon are evidence of the fact that no matter how hard one tries, one can only make a publicly accessible system secure enough - never absolutely secure. Every organization needs to define what good enough security is for the company and the online applications and put in place software, hardware, procedures and practices to ensure that those good enough security standards are not breached.