Special Concerns In Wireless Networks

The two primary considerations application developers must consider when developing mobile applications are that radio signals travel through open space and can be intercepted by people who are constantly moving, and that wireless solutions are dependent on public, shared infrastructure where you have less control and awareness of security employed.

Unfortunately, not all radio systems are equal when it comes to security; some are significantly more secure than others. For example, the spread spectrum employed by CDMA is potentially much more secure than TDMA's simple time multiplexing. Spread spectrum techniques were first developed during World War II because the U.S. military was concerned that an ordinary radio signal's carrier waves were very easy to detect. The goal was to make radio signals appear like random noise so it was difficult to tell a transmission was taking place. The carrier waves of these radio signals are not random in reality and are actually agreed on by the transmitter and receiver in advance. The spread spectrum technique used by CDMA is Direct Sequence Spread Spectrum (DSSS).

In addition to the underlying radio signaling of a mobile network, commercial operators employ several methods to ensure the confidentiality, integrity, and availability of communications, including encryption and digital signatures. To authenticate users on the network, GSM uses a digital signature that is stored on the SIM card located in the phone. To masquerade as another user requires gaining access to the SIM card and copying it. GSM uses an algorithm called A5 to encrypt all communications from the mobile device to the base station. Wireless data protocols such as WAP that ride on top of a mobile network such as GSM should also encrypt at the protocol or application level to better secure the communications.

GSM and Security

To understand the security mechanisms that exist in mobile networks, it is worthwhile to look at how GSM handles security. GSM has several security mechanisms that include user anonymity, user authentication, and data and signaling encryption.

When a user first turns on a mobile device, his or her real identity is used for authentication and then a temporary ID is issued. All further communications between the handset and the mobile network use the temporary ID.

A mobile device must authenticate to the network using an encrypted challenge and response mechanism. A random challenge is sent to the mobile device, which it then encrypts using the GSM authentication algorithm and the key issued to the mobile device, and then returns it. The authentication algorithm is implemented in the SIM card installed in the user's mobile device. The mobile operator then verifies that the response to the challenge was correctly encrypted with the key issued to the mobile device.

Once the operator has authenticated the mobile device, a key is generated from the mobile device's response that is used to encrypt all further communications between the mobile operator and the mobile device. This encryption algorithm is known as A5.

Other security precautions include an International Mobile Equipment Identifier (IMEI) to prevent the use of stolen or nonapproved mobile devices. Operators are able to monitor a central equipment identity register for enforcement. GPRS security is equivalent to the security used in GSM. WAP provides additional security mechanisms that we analyze next.

Wireless Transport Layer Security (WTLS): Security for WAP

The Wireless Transport Layer Security (WTLS) provides a security layer for WAP wireless data in addition to the security the mobile operator might employ in its radio signaling. Similar to other security mechanisms, WTLS focuses on:

  • Privacy: Encrypting data to prevent unauthorized users from seeing content transferred using WAP.

  • Data Integrity: Using digital signatures to make sure content is not tampered with.

  • Authentication: Verification that both sender and receiver are who they say they are.

  • Non-repudiation: A provision to prevent users or providers from denying they having performed a transaction.

The basic WTLS end-to-end security process is shown in Figure 6.2.

Figure 6.2. Transport Layer: End-to-End Security Overview. © 2002 Open Mobile Alliance.


Figure 6.3 provides an example of the sequence involved in WTLS end-to-end security. As detailed in Figure 6.3, a typical WTLS process is as follows:

  • The user selects a service provider (i.e., a bank) on a client device.

  • The client user agent sends a Wireless Session Protocol (WSP) method that requests the selected URL (using its default pull proxy).

  • The default pull proxy then forwards the method request to the origin server.

  • The origin server sends back an HTTP status 300 response to the default pull proxy. The reply includes an XML navigation document in the body section.

  • The master pull proxy functionality of the default pull proxy gets the error reply message and analyzes the navigation document to ensure that it contains valid parameters that comply with the policies defined in this document and the master pull proxy owner policies. The master pull proxy also checks the cache control headers and directives for the document.

  • Once validated, the navigation document is forwarded to the handset user agent (using an HTTP 300 error).

  • After being accepted by the user agent, the navigation document is then cached according to the cache control headers and directives specified for each document, and the appropriate configuration data is made available to the proxy selection mechanism.

  • When the user next requests a URL, the user agent uses the proxy selection mechanism to determine which subordinate pull proxy it should use to complete the request.

  • If no secure session exists between the user agent and the selected subordinate pull proxy, the user agent will establish a WTLS session with the selected proxy.

  • The user agent then informs the user that the session is secure. It also shows the information available in the certificate.

  • The originally requested method is then sent on to the selected subordinate pull proxy.

  • The subordinate pull proxy forwards the request to the origin server.

  • The origin server then replies to the user agent via the subordinate pull proxy.

Figure 6.3. Sequence Diagram Overview. © 2002 Open Mobile Alliance.


When the document finally expires, the navigation document and its associated configuration data (if there is any) are invalidated.