Wireless Internet Security

In the past few years, there has been an explosive growth in the popularity and availability of small, handheld devices (mobile phones, PDAs, pagers), that can wirelessly connect to the Internet. These devices are predicted to soon outnumber traditional Internet hosts like PCs and workstations [1]. With their convenient form factor and falling prices, these devices hold the promise of ubiquitous (“anytime, anywhere”) access to a wide array of interesting services. However, these batterydriven devices are characterized by limited storage (volatile and non-volatile memory), minimal computational capability, and screen sizes that vary from small to very small. These limitations make the task of creating secure, useful applications for these devices especially challenging.

It is easy to imagine a world in which people rely on connected handheld devices not only to store their personal data, check news and weather reports, but also for more security sensitive applications like on-line banking, stock trading and shopping - all while being mobile. Such transactions invariably require the exchange of private information like passwords, PINs and credit card numbers and ensuring their secure transport through the network becomes an important concern.

On the wired Internet, Secure Sockets Layer (SSL) [3] is the most widely used security protocol.Between its conception at Netscape in the mid-90s and standardization within the IETF in the late-90s, the protocol and its implementations have been subjected to careful scrutiny by some of the world’s foremost security experts [5]. No wonder then, that SSL (in the form of HTTPS which is simply HTTP over SSL) is trusted to secure transactions for sensitive applications ranging from web banking to securities trading to e-commerce. One could easily argue that without SSL, there would be no e-commerce on the web today. Almost all web servers on the Internet support some version of SSL [6]. Unfortunately, none of the popular wide-area wireless data services today offer this protocol on a handheld device. Driven by perceived inadequacies of SSL in a resource constrained environment, architects of both WAP [7] and Palm.net [8] chose a different (and incompatible) security protocol (e.g., WTLS[9] for WAP) for their mobile clients and inserted a proxy/gateway in their architecture to perform protocol conversions. A WAP gateway, for instance, decrypts encrypted data sent by a WAP phone using WTLS and re-encrypts it using SSL before forwarding it to the eventual destination server. The reverse process is used for traffic flowing in the opposite direction.

Such a proxy-based architecture has some serious drawbacks. The proxy is not only a potential performance bottleneck, but also represents a “man-in-the-middle” which is privy to all “secure” communications. This lack of end-to-end security is a serious deterrent for any organization thinking of extending a security-sensitive Internet-based service to wireless users. Banks and brokerage houses are uncomfortable with the notion that the security of their customers’ wireless transactions depends on the integrity of the proxy under the control of an untrusted third party [10].

We found it interesting that the architects of WAP and Palm.net made tacit assumptions about the unsuitability of standard Internet protocols (especially SSL) for mobile devices without citing any studies that would warrant such a conclusion [11]. This prompted our experiments in evaluating standard security algorithms and protocols (considered too “big” by some) for small devices. We sought answers to some key questions: Is it possible to develop a usable implementation of SSL for a mobile device and thereby provide end-to-end security? How would near-term technology trends impact the conclusions of our investigation?

The rest of this report describes our experiments in greater detail. Section 2 reviews the security architecture of current wireless Internet offerings and analyses its shortcomings. Section 3 provides an overview of the SSL protocol. In particular, we highlight aspects that make it easier to implement SSL on weak CPUs than it might appear at first. Section 4 discusses our implementation of an SSL client, called KSSL, on a Palm PDA and evaluates its performance. Section 5 describes an application we’ve developed for secure, mobile access to enterprise resources through sun. netTM based on KSSL. Section 6 talks about mobile technology trends relevant to application and protocol developers