Security for Wireless Web Services
Directed Study, Fall 2002
Supervisor: Dr. Jens Jahnke
By: Jeffrey Hui
1. Introduction
The past year has seen wireless usages starting to cross the early adoption phase. Wireless ISPs in many countries, e.g US, Finland, Korea, Singapore…etc, are planning to deploy hundreds of Wi-Fi hotspot networks at public places like coffee shops and airports. Some businesses and universities have also started pilot projects involving 802.11b and Bluetooth. On the consumer side, earnings reports by wireless hardware manufacturers like Intersil and Texas Instrument show that the use of 802.11b in residential networking has grown almost 10% from last year in spite of the economic slowdown.
At the same time, many firms are starting to experiment with Web Services for their IT applications, e.g. web services for synchronizing data on a notebook PC with corporate databases. Some researchers have also proposed Web Services for controlling the home network that connects computer peripherals, home electronics, lighting systems and security systems [7]. It seems likely that these two emerging technologies will intersect in the near future. It is thus the focus of this directed study to explore the security implications of this intersection.
In section two I describe a new category of wireless devices that could possibly become dominant in the next few years. In section three I give an overview of security solutions that promise to make wireless web services access safer, and might even enable a new category of wireless “Killer Apps”. Section four describes user scenarios of Bluetooth and 802.11a/b I envision for the next few years. No security system is perfect, so in section five I recommend the functional requirements of an intrusion detection system for wireless LANs.
2. Wireless “Fat PDAs” for 2005
Cell phones and PDAs are the traditional wireless devices for mobile access to the Web, e.g. corporate emails, SMS…etc. However, with advances in hardware technologies, the weight and price of notebook computers and tablet PCs’ are rapidly shrinking. I envisage that PDAs and Notebook PCs will eventually converge in a new category called “Fat PDA” or “Superslim Notebook” in the near future. Emerging examples are the Danger’s Sidekick and Sony’s Superslim Vaio PC. They could eventually become a dominant handheld wireless device for both mobile workers and home use. Battery power constraints are not as important in this type of “Fat PDA” so there are more options for security solutions.
Diagram 2.1 Examples of future “Superslim Notebook” or “Fat PDA” that are equipped with dual wireless mode (Bluetooth and 802.11a/b).
Most data inputs will be done with pen or voice. However, if substantial data entry is needed, portatable Bluetooth-enabled keyboards or Bluetooth-enabled docking stations should be available at Wi-Fi hotspots.
3. Overview of Emerging Wireless Security Solutions
The WEP standard currently used in 802.11a/b was originally designed with home use in mind. It is an adequate scheme for one way authentication of wireless clients and encrypting relatively less sensitive data in a home network. However, with the increasing deployment of 802.11a/b at Wi-Fi hotspots and business buildings, the future requirements on wireless security services will increase. Diagram 3.1 shows a list of important security services for residential WLANs and Wi-Fi hotspots [3].
Services / DescriptionAuthentication / Integrity / Provides integrity of the message and guarantee that the sender is who he or she claims to be.
Confidentiality / Privacy / Provides resistance to eavesdropping and interception.
Availability / Ensures that resources and communications are not prevented from access by malicious entities.
Authorization / Allows a user or communcation command to execute certain operations.
Diagram 3.1 Security services necessary for wireless Web Services access
These fundamental requirements are very similar to those of wired networks and ubiquitous computing.
3.1 TKIP (Temporal Key Integrity Protocol)
TKIP is an interim solution for enhancing the Confidentiality security service of 802.11a/b. The TKIP process begins with a 128-bit “temporal key” shared among clients and access points. It uses RC4 to perform encryption just like WEP. However, TKIP changes temporal keys every 10,000 packets. This solves the key reuse problem of WEP, and protects against key-recovery software like Airsnort, which can passively monitor packets and break the WEP password through “Weak Key” attacks.
TKIP is backward compatible with WEP, and can be easily configured by firmware upgrade.
The new WPA protocol proposed by the Wi-Fi Alliance has a similar algorithm as TKIP.
3.2 802.11x
802.11x provides a framework for authentication and key management [5]. It allows a supplicant (client device) to communicate with an authentication server via the EAP protocol. It adds scalability to the authentication service in 802.11a/b. The Access Point basically acts as an intermediate that forwards the EAP packets, and the authentication server has the flexibility to run any methods, e.g. Kerberos, certificates, shared secret password…etc.
Once the supplicant is authenticated, the controlled port on the Access Point is opened to its additional network traffic.
This standard is expected to be approved by the 802.11i committee by the end of this year. It will likely raise the demand for RADIUS servers, 802.11x compliant hardware, and enable a whole new category of wireless “Killer Apps”
3.3 AES (Advanced Encryption Standard)
The popular DES and RC4 encryption algorithms both have known vulnerabilities to timing attacks, power attacks and DES-cracker. Triple DES is much stronger than DES and RC4, but also 3 times slower than DES.
The 802.11i committee has been looking into AES, the new standard that was recently adopted by NIST as a replacement for DES. AES is based on the Rijndael algorithm, which is as strong as Triple DES, but with very low memory requirements and fast key setup time. This is very important for mobile devices like PDAs where these attributes translate into longer battery life. For a general performance comparison between AES and DES, please refer to diagram 3.2 [11].
Algorithm
/ Speed (Mb/s)DES (56 bits) / 28
Triple-DES (112 bits) / 10
AES (128 bits) / 70.2
AES (256 bits) / 51.2
Diagram 3.2 Performance Comparison between AES and DES on a Pentium Pro 200MHZ machine.
3.4 Virtual Private Network
VPN is a very popular way for mobile workers to access the corporate LAN via the public Internet. Traditionally, VPN clients primarily connect to the Internet via dial-up, cable or ADSL. The growth of Wi-Fi hotspots could provide them with another connection method.
VPN emulates a private network by using tunneling. The three most common tunnelling protocols are PPTP, L2TP and IPSec. In order for a VPN to be established, the server and client must use the same protocol.
There are pros and cons for each protocol, and they are summarized in diagarm 3.3.
PPTP / L2TP / IPSecPros / · Lightweight and easily available in many operating systems.
· Allows multiple types of traffic, e.g. IP, IPX…etc to be encrypted / · Allows multiple types of traffic, e.g. IP, IPX…etc to be encrypted and then sent over any point to point datagram newtork. / · Stronger packet by packet authentication, integrity and encryption.
· Replay protection.
· IKE provides scalability and mutual authentication.
Cons / · User-level authentication only.
· Data encryption begins after the PPP connection process. The PPTP authentication exchange could be vulnerable to “dictionary attacks”. / · User-level authentication only. / · Computer certificate authentication only.
· Many current implementation do not work behind NAT. New versions of VPN products are adding NAT-traversal capabilities.
· Allows IP traffic only.
Diagram 3.3 Pros and Cons of Tunnelling Protocols
4. Future Wireless Scenarios
As the cost for wireless hardware comes down and their security solutions become more mature, more and more new usage scenarios will emerge. This section describes some scenarios which I envision for the next few years.
4.1 Bluetooth Gateway for Controlling & Managing Local Component Networks at Home
Local component networks are defined as local networks of micro-controllers with relatively high interdependency [8]. In the near future, many houses will likely have sophisticated local component networks like the following:
· Alarm systems e.g. motion sensors, contact sensors…
· Comfort/Environmental control system, e.g. heating system, lighting system, humidity controller…
· Entertainment system, e.g. video on demand, online game console, MP3 player…
· Child/Senior emergency system, e.g. wireless tracking devices for children, wireless panic buttons for seniors…
Most people are frustrated by the VCR control, not to mention all the new control interfaces that will be introduced by the above new systems. Some Nokia researchers have suggested embedding wireless Web microservers into all kinds of electronic devices so they will have a consistent and user-friendly user interface [7]. A Bluetooth enabled cell phone will then discover, connects to these devices and download the appropriate UI from the Web. I believe this will work for a small number of devices. However, in the near future, a house could have literally hundreds of devices. Imagine having a hundred wireless Web microservers in your house. Ask any system administrator, the task to administer and secure one web server is already no small job!
Diagram 4.1 Hybrid wired/wireless local component networks centrally controlled by a Bluetooth Gateway.
Wired networks are inherently more secured than wireless networks, so most home systems will probably continue to connect using powerline, twisted pairs or coaxial cables. However, these systems can be centrally controlled by a wireless gateway as shown in diagram 4.1. The gateway should have a plug-in architecture so different vendors can easily provide a control component/UI for their devices. For examples, to enable the alarm system before leaving the house, you can enter your activation password on your Bluetooth-enabled “Fat PDA”. Another example is when a senior stumbles and falls in the garden, and pushes his wireless panic button. The gateway will connects to a Bluetooth-enabled telephone, and sends out emergency paging to other family members.
In diagram 4.1, the communciations between the gateway and the various local component networks are wire-based, so no new security risks are introduced by the gateway setup. The Entertainment system communicates with the gateway via Bluetooth. Since there is no sensitive traffic in this particular system, the wireless link does not pose any risk. In the worst case, RF jamming from a malicious entity will deactivate control of your VCR, MP3 player… However, you can always use manual override. For maintaining a reasonable level of privacy, perhaps running security mode 2 or mode 3 of Bluetooth will be adequate.
The possible intrusion entry point is at the wireless link between the gateway and the “Fat PDA”. Wetzel identified 4 possible attacks of a Bluetooth link as listed below [1]:
· Eavesdropping and exhaustively guessing the Bluetooth secret PIN up to a certain length.
· Location attack
· Offline PIN crunching and middle-person attack (middle MIG attack).
· Cipher attack
Wetzel also suggested countermeasures to mitigate these vulnerabilities. First, user should choose a PIN that is at least 64 bits long and sufficiently random. Secondly, policies that ensure the gateway will always be a Bluetooth “slave”, and the “Fat PDA” always a “master” will prevent middle-person attacks. To prevent location attacks, the “discoverable mode” of of the gateway should be disabled. And lastly, by choosing Bluetooth hardware that implements AES, the Cipher attack can be avoided.
With these countermeasures in place, the Bluetooth gateway will add great user-friendliness to the home control interfaces while maintaining almost comparable security as the traditional wired approach. Last but not least, Bluetooth’s short range (up to 10m) has an inherent security advantage over 802.11a/b (up to 300m).
4.2 Accessing Corporate Intranet via a WLAN
Many mobile workers have been accessing their corporate intranets via dial-up connections or broadband for some time now. Some log on to their intranets using passwords (Challenge Handshake Protocol) while others use VPNs. They can continue doing what they do at an 802.11a/b wireless LAN. However, some measures are necessary in order to maintain comparable security levels as the traditional wired connections.
For mobile workers who use password logins, the following are recommended:
· Use a Challenge Handshake protocol with mutual authentication. This will guard against rogue access points that impersonate as a legitimate access point near your company building or a wireless hotspot.
· Make sure the WLAN you are using has, at the minimum, enabled either WEP or the new WPA. This will prevent an eavesdropper from capturing your Challenge-Response packets, and attempts to recover your login name and password by “offline attacks”. Also, if you follow the common password guidelines of including digits and words not in the dictionary, “offline attacks” will become ineffective.
For mobile workers who use VPNs, you would need to upgrade your VPN client software to a version that supports NAT-traversals, as most access points perform NAT (Network Address Translation). It is also recommended that you use the combined L2TP/IPSec tunnelling protocol so somebody who steals your handheld device will not be able to automatically log into your company’s intranets. L2TP/IPSec requires both computer certificates and user password/certificates.
4.3 “Fat PDA” Based Anonymous E-Cash for Wi-Fi Hotspot Billing
E-Cash has been in academic research for some years now. While it does not have widespread adoption in North America, it seems to be gaining momentum in several European and Asian countries. One example is the Octopus system in Hong Kong. It is an anonymous smartcard that stores e-cash up to a limit of C$200, and can be refilled at self-service kiosks or banks. The smartcard has been in use at buses, trains, subways, supermarkets, coffee shops…for about 5 years without any security incidents. At almost 7 million e-cash transactions a day, the Octopus system has demonstrated that smartcard e-cash can be a viable and secured system for micropayment.
I envision that smartcard e-cash can be extended to become handlheld device based, and is especially suitable for application in Wi-Fi Hotspot billing. For examples, in the near future, a mobile worker can purchase e-cash that is accepted at many Wi-Fi hotspots in the world. The e-cash is stored as a digital object in his notebook PC. When he enters a Wi-Fi enabled coffee shop, his Notebook PC will automatically display a login screen asking him to choose a connection time. After he makes a selection, say 15 minutes, the e-cash authentication server will charge $1 from his digital object and he can start Web surfing right away. At the end of the 15 minutes, he can either buy more time or finishes up his espresso and hit the road. All these without the hassles of keying in passwords or credit card numbers. Moreover, e-cash can be anonymous so you will have the benefit of privacy, too. Also, imagine the coffee shop is in another country other than Canada, the e-cash digital object can even do currency exchange for you. And with Web Services getting popular, it is conceivable that you can even shop for a favourable exchange rate before sending the e-cash to the coffee shop!