Chapter 7: Smart Client Overview

WAP Security

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:

• Transport-level security. This aspect deals with the communication between the client applications and the enterprise servers. This involves two protocols: WTLS is used over the air, while SSL or TLS is used over the wire. This change in protocols is the basis of the major WAP security problem.

• Application-level security. This aspect deals with the security of the client application. This involves digital signatures and encryption.

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.

Note 

Though this section focuses on WAP, most of the concepts and issues relate to other forms of thin client applications as well. Depending on the protocols and networks being used, other wireless Internet applications will be similar to either the WAP 1.x or WAP 2.x architecture.

Transport-Level Security

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.

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:

• Support for other cryptographic algorithms. SSL and TLS primarily use RSA encryption. WTLS supports RSA, Diffie-Hellman (DH), and Elliptic Curve Cryptography (ECC).

• Definition of a new compact public key certificate, WTLS certificates. These are a more efficient version of X.509 certificates.

• UDP datagram support. This impacts many areas of the protocol, from how data is encrypted to extra support for message handling, to ensure messages do not get lost, duplicated, or delivered out of order.

• A key refresh option. This is renegotiated periodically, based on the number of messages sent.

• An expanded set of alerts. This adds clarity for error handling.

• Optimized handshakes. This reduces the number of round-trips required in high-latency networks.

In addition to these changes, WTLS also introduced three levels of authentication between the client and the gateway. They are listed in ascending order:

• Class I WTLS. Anonymous interactions between the client and WAP gateway; no authentication takes place.

• Class II WTLS. The server authenticates itself to the client using WTLS certificates.

• Class III WTLS. Both the client and the WAP gateway authenticate to each other. This is the form of authentication used with smartcards. GSM Subscriber Identity Modules (SIM), for example, can store authentication details on the device for two-way authentication.

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:

• Accept that the gateway is a vulnerable point and make every effort to protect it using firewalls, monitoring equipment, and a stringent security policy.

• Move the WAP gateway within your corporate firewall and manage it yourself.

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.

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.")

Application-Level Security

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:

• Any WML card that requests access to sensitive data should set sendreferer=true in the <go> element.

• The script that handles requests for sensitive information should check the URL specified by the REFERER header HTTP request to make sure that requests being handled are from friendly domains.

• Use HTTPS and require basic authentication. Relying on the phone's identity alone is not sufficient.

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.