1. Introduction:
We are witnessing a huge interest for wireless devices (phones and PDAs) and services especially from professionals and people “on the move”. The Short Message Service (SMS), or paging, can be considered as a significant market success either for business or entertainment purposes. The ability to exchange SMS messages provides the convenience of being able to reach anyone anytime and anywhere in urgent situations. Unfortunately, SMS has fundamental limitations that make it an unsuitable technology above which to layer collaborative services. On the other hand, as wireless networks are bringing the idea of the “unplugged Internet”, a new standard, called Wireless Application Protocol (WAP), is emerging and making a significant impact in the mobile market.
2. System Description:
In recent times, chat rooms and instant messaging have proved enormously popular services. The predecessor to these services is Internet Relay Chat (IRC), which is an IP based service with sophisticated support for distributed collaboration. IRC provides a variety of mechanisms for users to collaborate across the internet with friends, colleagues and others both publicly and privately by creating and subscribing to various “channels”, or chat rooms, to exchange text message and file transfers.
2.1User Scenario:
From an end user point of view, the scenario we consider enables mobile users to chat by sending to each other instant messages. They can interact according to the instant responses of their friends/colleagues (“bodies”). In terms of functionality, the users interact with our WAP Chat application that supports a Wireless Markup Language (WML) interface enabling them to:
• Select and connect to a given chat server: users can choose among a list of available servers, the closest server to his/her current location (for best performance).
• Once connected to the chat server, the user can choose from a list of open channels provided by the server the discussion room (channel) that they wish to join.
• Scroll through the messages sent by other users on a channel.
• Type and send messages to the channel.
• Join another channel.
• Disconnect from the chat server.
At the start of a session, users are asked to input their contact information [optional]: name, email, photo, WML home page, etc. (figure 1A). When the user joins a channel, a hyperlinked list of the current subscribers to the channel is presented. The user can follow any of these links to view the contact information [optionally] entered by each subscriber. Once the user has joined a channel, he or she will be able to view the messages that have been sent to this channel. Accompanying each message is the name of the person that sent that message, with the name of the person hyperlinked back to their contact information (figure 1B).The user also receives a notification message indicating when others users join and leave the channel (figure 1C)
Figure 1a.User input before connection. Figure 1b. User’s WML page. Figure 1c. WML chat room.
2.2 System Architecture
The system is based on a three tier architecture, but not in the traditional sense. A WAP client (tier 1) connects, via a WAP gateway, to the WWW server hosting the WAP Chat service (tier 2) which manages collaborators on a per-user-session basis. The WWW server hosting the WAP-Chat service then connects to the IRC server (tier 3) as specified by the user at the start of the session. The WAP-Chat WWW hosted application server manages user chat sessions which, in turn, can interact with multiple IRC servers. The WAP-Chat application server is also responsible for dynamically generating a rich WML interface for the WAP clients.
Figure 2. WAP Collaboration Model
3.Security Hole At The WAP Gateway:
In general, the mobile customer and the e-merchant involved in an m-commerce transaction want (or should want) to ensure:
Confidentiality: Those messages are kept secret.
Authentication: That each party knows whom the other party is.
Message integrity: Those messages are passed unaltered from sender to receiver.
Replay attack prevention: That any unauthorized resending of messages is detected and rejected.
Non-repudiation: That neither party can later reject that the exchange took place.
All these issues must be addressed in a secure system. Indeed, it is the ambition of the WAP Forum to develop WAP into a standard that covers all relevant aspects of security, and some steps have been taking already with version 1.2.1 while version 2.0 goes a little bit further. For security, WAP provides a secure protocol for data transport: WTLS, Wireless Transport Layer Security. WTLS also contains features for authentication of both parties, as well as for non repudiation using message digests and digital signatures. Authentication of the user of a GSM phone may utilize the phone’s SIM card.
Finally, the definition of WML-Script includes a specification of a function library called a “crypto package”. This library contains a signing function, which can be used by a user to digitally sign a message, in the conventional manner in a Public Key Infrastructure. Thus WAP supports nonrepudiation of messages (such as a placement of an order) sent by a mobile WAP user. In the sequel, we merely discuss to what extent WAP achieves message confidentiality.
WAP’s two-stage security model: The basic security feature of WAP provides secrecy in the two half parts of the path that connects the WAP client and the web server: the (presumed) wireless path between the WAP client and WAP gateway, and the (presumed) wired path between the gateway and the web server (Figure 4). In the middle point constituted by the gateway, incoming data is decrypted; then while the data is in its original, un-encrypted form, it is subjected to some processing; and finally it is encrypted again before it is sent off along the other path. For encryption over the wired path, WAP simply relies on the Transport Layer Security (TLS) protocol, a widely used Internet standard. For encryption over the wireless path, WAP uses WTLS, which is in essence an adoption for wireless communication of the TLS protocol.
Figure 4. Security zones using standard security services (WTLS and TLS)
Thus prompted by the WAP client, the WSP layer at the gateway will initiate a TLS connection to the web server, in a way completely similar to setting up a connection between an ordinary web client and the server. This combination of WTLS and TLS provides secrecy (indeed, also integrity) over both halves of the WAP client / web server connection.
The crucial weakness is, of course, that all data transferred between the WAP client and the web server is decrypted at the WAP gateway, i.e., all data such as credit card numbers, etc. exists as free text in the memory of the gateway. Technical solutions, such as various programming techniques applied to the software that implements the WAP gateway, can make it somewhat difficult to get access to the data, but not impossible. Organizational solutions, such as tightening the security policy of the organization that hosts the WAP gateway, may limit access to the gateway and it’s data; but from the point of view of the two “end users” it is unsatisfactory that the privacy of their data is not under their own direct control.
4. Solutions For The WAP Security Problem:
4.1 Putting the gateway inside the “vault”:
The WAP gateway can be placed at the web server end of the connection, that is, inside the same security zone. When residing inside the local network of the merchant the gateway is protected against the outside world in a similar fashion to the way the web server is protected. A closer look at the business potential for the three stakeholders reveals that this solution does introduce further problems as well. Whether these will be solved is hard to say at the moment.
1. The Mobile Service Provider
For the Mobile Service Provider the main problem is a possible loss of business opportunities, e.g. “locking in” the customer to the provider’s m-portal. There are a number of possible WAP services that the MSP can offer only if it hosts the gateway, this being the MSP’s only way of ensuring that all data used in those services stays within the mobile network that the MSP is in control of. For instance, location dependent services utilize the MSP’s access to information from its own network about the exact location (cell) of the mobile phone. There may be strong business and security reasons for the MSP to not want such data to be available outside of the network. In the case of location information, the data is clearly sensitive, at the same time; the data may have a high business value, exactly because it is a prerequisite for certain services.
Moreover, this solution challenges the MSP to open its network to outsiders like the merchants running their own gateway. Each limitation on the MSP’s full control over the usage of its networks may introduce further traffic management problems.
2. The User
The user of the WAP client may witness degraded performance: The WAP protocols, which are tailored for the characteristics of wireless networks, are now used for the entire transport of the web content to the WAP client, instead of merely for the wireless part as intended. This may incur increased delays if there is congestion in the wired network. The end-user interface becomes less friendly, because the user of the WAP client will be forced to swap between gateways during Internet browsing. For example, the user that wants to buy from two distinct websites needs to use the WAP gateways of those sites. Swapping gateways raises two problems when changing the gateway profile of the phone. The gateway profile includes a dial-up phone number, the IP number of the gateway, etc.
3. The Merchant
The e-merchant is burdened with a complex piece of additional software (the gateway) that must be acquired and maintained. For a WAP gateway, maintenance work includes, for example, ensuring that the security-related software in the gateway is up-to-date, and updating the gateway to new versions of the WAP protocols. It is, however, not clear, whether the merchant will be further “burdened with handset provisioning and activation issues”.
4.2 Solution 2: Application level security on top of WAP:
This amounts to introducing security at a software layer above WAP, and considering WAP merely as a potentially insecure communication means (figure 5). Instead of using WAP’s protocol for secure transport (WTLS), security is taken care of by means of dedicated software running at the two “ends”, the mobile phone and the e-merchant’s web server. Such software could perform encryption in a way that eliminated the security hole at the gateway. In general, the approach would be in line with the conjecture about protocol design made in an end-to-end function, must be placed at a level where end-to-end control is available, i.e., at the application level.
While technically possible, above said solution would add a burden of extra complexity in the mobile phone. Indeed, the implementation of application-level security on top of WAP requires that sophisticated cryptographic functionality is made available to applications on the mobile WAP phone, either in the form of future enhancements of the WML Script Crypto Library or in other ways. It should be noted that the single function for digitally signing a message, which is presently the only function contained in the library is insufficient. Specifically, the Crypto Library’s signing function is not useful for encryption of data, because in principle, everyone in possession of the WAP user’s public key can read a message that she has signed digitally.
Moreover, this approach would partly neutralize most of the optimization provided by the WAP gateway: there will be a loss of the benefits of the data conversion and compression taking place in the gateway to accommodate the limited bandwidth of the wireless network. To minimize this, a balanced approach may be to encrypt only small fragments of the data, not the data as a whole. This would allow the WAP gateway to perform compression, decompression, and compilation by providing access to the WML tags and WSP/HTTP commands in their original, unencrypted form.
Figure 5. Security zones using application level encryption
4.3 Solution 3: Enabling internet on the mobile device:
The third and last approach is to re-design the WAP protocol to not use a gateway, and employ the existing Internet standards, including the transport protocol (TCP), for the entire wired and wire-less part of a connection. By definition, this solves the security problem introduced by the gateway. This change of design has been proposed by the WAP Forum for version 2.0 of the WAP protocol. The standard now allows a range of different gateways, corresponding to having the conversion between the two protocol stacks anywhere from the top to the bottom of the stack.
At the top layers, the gateway works like the traditional WAP gateway taking care of the functions mentioned, and at the bottom layer it works like a traditional bridge/router. Whereas a TCP level gateway allows for two versions of TCP, one for the wired and another for the wireless network, on the top of which a TLS channel can be established all the way from the mobile device to the server.
The move away from top level conversion constitutes a fundamental change of design, which does away not only with security problem, but also the optimization for the wireless network, made possible by the gateway. Discarding the WAP gateway makes it possible to attain the same high level of security for an m-commerce transaction as that of an e-commerce transaction on the ordinary web using full end-to-end encryption. Indeed, for WAP to discard the WAP gateway would turn the (fully) WAP enabled mobile phone into an ordinary Internet device.
Besides the cost of deploying a full Internet protocol stack in the mobile phone, this solution enforces additional messages to be send between the device and the Internet. A simple request for a WML document must – in contrast to the gateway-based WAP solution – wait for a DNS-lookup to derive the appropriate IP-number from the symbolic name in the original request. The gateway based solution only has this cost over the wired Internet, when the gateway converts the WAP request to an HTTP-request. A minor optimization would be to utilize a caching DNS server at the border between the wired and the wireless network.
5.Conclusion:
Mobile SMS messaging (or paging) can be considered as a significant market success. The ability to send text messages has proved enormously popular across many sectors of the market, in particular among younger people. A tremendous improvement over SMS, WAP-Chat is a novel service to be offered by operators for exchanging messages between mobile users. As we move forward to ubiquitous information access, the convergence of WAP and collaboration services will yield a range of new and exciting approaches for supporting mobile groups that may be potentially distributed around the world.
Although the security hole associated with the gateway is commonly recognized, the WAP Forum did not release its previous deliberations as to why it felt the gateway’s advantages would outweigh its disadvantages. The introduction and subsequent de-route of the WAP gateway – whether preconceived or not – has increased the complexity of the WAP standard, comprising variations both with and without the gateway. We foresee a future where all the communication oriented WAP standards are replaced by Internet standards, leaving only the application level protocols in WAE as WAP specifications. It is also interesting to observe how the old and open Internet technology is able to outperform a vendor provided network solution like WAP. One may hope that the significance of a fully open discussion and standardization process will be learned also by the vendors behind the semi-opened WAP Forum
Share this on your favourite network
Great Post! Thanks a lot
ReplyDeletewelcome aditya...
ReplyDelete