The Wireless Application Protocol, or WAP, has been widely criticized by the media and corporations alike for its security shortcomings. What are the security issues with WAP? How can organizations overcome them? This section attempts to answer those questions, by explaining where WAP excels and where it falls short. After we examine the security model of WAP 1.x, we will look at the improvements made in WAP 2.x.
In the WAP 1.x security architecture, two aspects of security need to be addressed:
Together, these two security areas will address the security concerns that are typical in any security model, including authentication, data integrity, confidentiality, authorization, and nonrepudiation.
Transport-level security, also known as channel security, deals with the point-to-point communication between a wireless client and the enterprise data source. This involves communication over both wireless and wireline channels. With WAP, data is encrypted during over-the-air transport using Wireless Transport Layer Security (WTLS) protocol, and over-the-wire transport using Internet security protocols such as SSL and TLS. This discrepancy leads to one of the main WAP security issues. But before we discuss that topic, we will examine the features of WTLS.
Wireless Transport Layer Security (WTLS) protocol was developed to address the unique characteristics of wireless networks, namely low bandwidth and high latency. It is a variation of the Transport Layer Security (TLS) protocol, which is the IETF standard for security on Internet. Unfortunately, TLS cannot be used directly because it is not efficient enough for a wireless environment. WTLS improved on the efficiency of the protocol while adding new capabilities aimed at wireless users. The following are some of the major features added to WTLS, which are not in TLS:
In addition to these changes, WTLS also introduced three levels of authentication between the client and the gateway. They are listed in ascending order:
The WAP Gap
Unfortunately, at the same time WTLS improved on TLS for wireless communication, it also caused a major problem: Now that both TLS and WTLS are required within the WAP architecture, there is a point at which a translation between the two protocols occurs. It is from this point, not from the WTLS protocol itself, that the security issues arise. The translation occurs on the WAP gateway: From the client device to the WAP gateway, WTLS is used; from the gateway to the enterprise server, TLS is used. At this point, the WTLS content is decrypted and then reencrypted using TLS. The content exists as plaintext while this transfer takes place, creating the so-called WAP gap. Keep in mind that the amount of time that the content is unencrypted is minimal, and that the WAP gateway is not in the public domain, so there is still security in place. However, for many corporations, this risk is still too great, as it presents a vulnerable point in the network, preventing end-to-end security.
There are two options for alleviating the WAP gap:
Choosing between these two options is a business decision that will depend on the individual enterprise. It is a trade-off between the extra resources required to maintain a WAP gateway and the potential security threat to corporate data. Fortunately, a solution is available, in the form of WAP 2.x.
There are many new features in WAP 2.0, but none is as important as the move to standard Internet protocols. This move to using HTTP, TCP, and IP allows the TLS protocol to be used for data communication, thereby removing the need for WTLS. Once a single protocol can be used from the client device to the enterprise server, WAP can enable true end-to-end security, making the WAP gap a thing of the past. Suffice to say, this is a major change in the WAP, and it will take some time for wireless carriers to move to WAP 2.x gateways. Nevertheless, it provides new life for WAP in the wireless Internet space. (For a complete summary of WAP 1.x and the changes made in WAP 2.x, see Chapter 11, "Thin Client Overview.")
With so much attention given to the WAP gap and transport-level security, developers often forget about application-level security altogether. Application-level security is important for two main reasons: (1) when security is required past the endpoints of transport-level security, and (2) when presentation content needs to be accessed but enterprise data does not. This can happen during transcoding, that is, when another markup language (often HTML) is being transformed into WML.
The first scenario can be addressed using the techniques provided in the WML specification. In general, the default settings are set to the highest security, but the following are a few things to keep an eye on:
The second scenario can be addressed using WMLScript and the Crypto API. Using this signText function in the API, digital signatures can be created, opening the door for wireless PKI to manage and issue public key certificates. This technology allows for end-to-end encryption between the content provider (usually the enterprise) and the client.