Infrastructure for a Secure Interface between
Wireless and Data Networks

CS 261 Fall 1998
Chen-Nee Chuah & Mark D. Spiller

(14 December 1998)

Paper Outline

  1. Introduction
  2. GSM Security & Service Access
  3. Accessing the Service Gateway
  4. Prototype Implementation
  5. Related Work
  6. Conclusion
  7. Acknowledgements
  8. References

1.0 Introduction

The explosive growth of the Internet and wireless ad-hoc networks has fueled a need for the integration of heterogeneous networks. Mobile users want to be able to access services and information available on the Internet as well as their desktop machines. In such an environment, it would be handy if wireless devices such as cellular phones could be used to activate services in the network, and thus empower mobile users.

However, the type of access desired will not be used without various degrees of privacy and authentication. A security infrastructure that protects the communication between the wireless device and the servers in the network is required. This project explores the design criteria and issues in securely accessing network services from a cellular phone (using GSM), and presents a simple prototype that demonstrates cross-network security.

1.1 Target Applications

We envision that in the future mobile users may use their personal communication devices to invoke many different kind of services, which can be classified under several categories according to the functionality involved:

Mode:

Examples

Access
  • Information databases (Stock quotes, weather forecast, web...)
  • Check status (ping machines, car, home, etc.)

Control
  • Remote home control (activate/deactivate: e.g. doors, lights, appliances,...)
  • Reconfiguration of services (e.g. call forwarding)

Communication
  • Voice connection to IP Phone
  • Mobile shopping (e.g. rent movies, place orders)
  • Specific online services and data applications (e.g. translation and conversion proxies, cell phone whiteboard)

Reactive
  • Callbacks (e.g. return paging messages, respond to alarms or emergencies)

It should be noted that the user will have different levels of trust and desired security for different services, for example weather forecast vs. controlling actions in a house. One required system feature is user-selectable trust, security, and revokation.

Given this scenario, we assume the following:

 Our main objective was to explore the issues involved in providing secure services to mobile users. The contraints included (listed in order of importance to us):
  1. The number of required changes to the existing protocols (especially GSM) and/or participants' equipment
  2. Potential attacks (spoofing, eavesdropping, replay, DOS, ...)
  3. Trust extent/duration for participants
  4. Memory/functionality required
  5. Complexity
  6. The execution time/delay for service access and the number of control messages or hops involved
Our work focussed on the first three constraints. The following sections (2 and 3) first look at the GSM area, and then at ways in which the service gateway could be integrated in and the trust relationships between the participants in each case. Section 4 discusses our implementation efforts, Section 5 mentions related work, and Section 6 contains our conclusions.

2.0 GSM Security & Service Access

Groupe Special Mobile(GSM) is the first mobile digital cellular network architecture that provides security services, as detailed in GSM 11.14 V5.1.0 (GSM references). Since GSM is originally designed with voice applications in mind, it does not provide for facilities to access services or transmit data securedly. A new packet data service called GPRS (General Packet Radio Service) has been standardized and implemented in the GSM system. However, the security functionality for GPRS is equivalent to the existing GSM security. An agent in the fixed network performs authentication and cipher setting procedures based on the same algorithms, keys, and criteria as in existing GSM. GPRS uses a ciphering algorithm optimized for packet data transmission.

In this section, we will briefly describe the GSM security model in and several possible solutions to integrate it with existing network security modules.

2.1 GSM Security Overview

The real identity of a GSM subscriber is a permanently attached number (IMSI) stored in the SIM (Subscriber Identity Module) card. There are four basic security services provided by GSM: The establishment of communication between mobile users and fixed phone networks is controlled by the authentication center (AS), which is co-located with the local message switching center (MSC). When the user turns on the handset and makes a phone call, the MS sends a call set-up message to the MSC, and transmits its own identity and IMSI. Upon every call the MSC/VLR allocates to the IMSI a new TMSI and transmits it to the MS with the order to substitute the TMSI for the IMSI in all future communications within the GSM system. From then on, the IMSI is not sent over the radio path again. After the IMSI is known by the network, the AS generates a "challenge" in the form of a triplet: (RAND, SRES, Kc) and forwards it back to the base station, BS. RAND is a 128-bit random value generated by the AS. The SRES (Signed RESponse authentication result) and ciphering key, Kc are computed with the A3 and A8 algorithms, respectively, using RAND and the secret key Ki: RAND is forwarded by the BS to the MS, where it is used to generate (SRES, Kc). Another input required is Ki which is stored in the SIM card. The BS compares the SRESs from the AS and the MS. If they agree, user authentication is complete. All the subsequent traffic between the MS and the fixed network (BS/MSC) is encrypted with Kc using the A5 algorithm. Note that the BS/MSC are trusted per session by the handset and the AS, because they know the ciphering key, Kc. One weakness in the GSM authentication approach is its reliance on the security of the links in internal GSM networks (MSC-HLR, VLR-HLR, HLR-AS, some of which may be air links). Another weakness is the security of the SIM card itself. However, in this project, we assume that GSM authentication and data encryption are reliable for service access purposes.

2.2 Ideal GSM Service Access

Ideally, we would like to limit the trust we put in the phone company (both the BS and the AS, as well as the links). In this section, we develop a solution for service access authentication that only assumes data confidentiality of the GSM air link.


Basic Protocol

This solution requires the SIM card to have two sets of keys, Ki1 and Ki2. The service gateway is fully trusted and has knowledge of all keys (although it doesn't really need Ki1 - in this case, we assume the SG is trusted completely by the MS). For instance, another key is added to the SIM card at a later time. The phone company (HLR) only knows Ki1. We assume the traditional security model of GSM. Therefore the BS only knows the authentication key, Kc (generated the same way as described in the previous section) for authentication and billing purposes. On call connect, we assume the mobile user is authenicated with a traditional GSM challenge-based authentication. The air link is now encrypted using Kc. The BS then detects service requests (i.e. when the user dials special phone number) and notifies the service gateway (SG) for secondary authentication.

In detail:

Trust models

Required Changes

Advantages & Limitations

One of the main advantages of this approach is the end-to-end protection from the MS to the SG, and therefore limiting the trust of the phone company. In addition there are no replay attacks possible. The only possible attack is the denial of service attack. The third advantage is that although this solution works only for known SIM cards, users can use any GSM phones that support the double encryption.

However, we there are numerous limitations that make this approach less attractive, as listed below:

2.3 Realistic GSM Service Access

The inherent limitations of the GSM phones force some trust to be put in the BS. We rely on the GSM user authentication mechanism and some shared secret between the phone company and the service gateway, SG. The remaining questions are There are several solutions to the problem of authenticating users for service access. One possibility is to somehow use the rechallenge capability in GSM to get a second SRES or key that could be uses for the service. It is crucial to be able to distinguish a service request versus a voice call in progress in the challenge. (Please refer to Section 3 for further discussion of the design of service gateways and interaction between the SG with the BS/AS).

2.3.1 Fully Trusted SG & AS (a la Rechallenge)

Basic Protocol

This approach is similar to the previous case, where a call still goes through the AS for billing/authentication. The encrypted channel is set up between the BS and the MS in the same way as described in Section 2.1. Upon the service request, a GSM re-challenge, i.e. a new triplet (RAND2, SRES2, Kc2) is sent by the SG to the BS, and the phone re-authenticates itself, this time to the SG.

In details:

An alternative scheme might be to have the handset send the new Kc2 to the BS via the encrypted (still with Kc1) air channel. At that point, the air channel can switch over to Kc2 without Kc2 ever having been exposed to the BS-SG or BS-AS links. Kc2 could then also be used to encrypt the BS-SG channel. (The BS could decrypt the information, check control data, and then forward a copy of the encrypted voice/data). This set-up would, of course, depend on how the GSM standard handles re-challenge. We could not find sufficient data on this.

Trust Model

Required Changes

Advantages & Limitations

One of the obvious advantages is that we do not need double encryption in this approach. However the trade off is that we have to trust the BS more. Other disadvantages include the following:

2.3.2 Semi Trusted SG & Fully Trusted AS

Basic Idea

To work around the inherent limitation of the GSM network, we introduce some modifications to the previous cases. In this approach, the SG is no longer completely trusted by the user - now the phone company (AS) is trusted to negotiate with the SG, using some shared secret. Optionally, the AS could pass a temporary ticket of some sort to the BS/MSC/WCP, to improve performance. We make the same assumptions: a phone number indicates the service, and user authentication is as in the GSM spec.

Trust models

Required Changes

Advantages

Limitations

Possible Extensions

2.3.3 Open Trust

There is no need to protect the communication with the service proxy, and the services do not require authentication of any sort. Everything follows GSM authentication, and a special phone number indicates service request.

This approach does not require any changes beyond the BS detection and forwarding of the service request. It is simple! No modifications to handset, SIM, or AS. Of course, there are lots of limitations - it's totally unsafe. (i.e. after authentication, the BS can invoke services...)

2.4 Other (Infeasible) Cases Considered

While brain-storming for GSM we came upon two other possibilities that we thought had merit, but are currently not feasible. The first would be to change the handling of Kc so that the handset-AS link would be end-to-end encrypted. Unfortunately, since all of the signaling data is encrypted using Kc, and since the encrypted air link is the first thing set up, the base station has to know Kc.

The second option was to have a separate set of base stations for services, that would then do their own authentication and bypass the phone company completely. The cost of infrastructure for this would clearly be majorly prohibitive, but the possibility of dual-band digital phones or perhaps having the handset and base station determine whether something is a phone call or service or types of services based on frequency seems somewhat interesting.

3.0 Accessing the Service Gateway

The role of the service gateway is slightly ambiguous. The service gateway could be, among other things, Clearly, there are multiple types of re-authentication and security that one would want depending on the situation. In some of the cases the user may not care whether anyone else sees the requests and it doesn't matter who the user is, but in many this is an important issue. Since, from section 2, we know that we need to trust the base station a great deal, the danger of a compromised base station is potentially very large - it would be nice to have some way of allowing the user to generate a temporary session key that would become obsolete soon after the service access was complete. One notion that we had was to use a personal hardware number generator such as those used for authenticating logins in some companies (perhaps someday make that part of the phone?) and have the service send a challenge to the phone. Unfortunately, this is not an option with the current batch of phones, but the capability really isn't that far out in the future.

3.1 Different Levels of Security (aka The Security Access Slider)

(Slider notion borrowed from Dave Wagner :)

Model

Basic Idea / Features

1. Keys/tickets (a la Charon)
Proxy-assisted Kerberos,
BS gets a ticket
  • Infeasible due to current GSM capabilities (double encryptions)
  • Encrypted end-to-end from handset to the Service Gateway (SG). Handset-entered password gets a ticket, gives it to the Base Station.
  • Handset only trusts the BS for length of time-out period.

2. Keys/tickets (a la Kerberos)
BS knows the password
  • The BS uses handset-entered password to get service ticket, and acts on user's behalf (BS-to-SG link encrypted)
  • The set of trusted base stations reduced to those in use when password used, out-of-band method for changing passwords allows simple (but perhaps delayed) revokation.

3. Keys and Certificates
(e.g. SSL, Public
Key or SSH)
  • A central authority signs service certificates, which are used to build an encrypted channel between the BS and the SG. (SSL-like) [or]
  • The BS downloads service key once, uses that to build future encrypted channels to that service, (SSH-like) [or]
  • Public keys for all required parties (BS & SG) are known beforehand, and are used to build an encrypted channel between the BS and SG. (Public Key-like, phone company and services negotiate exchange of key lists).
  • The BS sees all the user actions in the open and can impersonate user indefinitely.

4. Open
  • No password, no encrypted channel, the BS forwards request in the open.

The first two models are clearly more secure, since the length of time during which the base station is trusted is limited. The user must, of course, trust the service gateway with some sort of shared secret. Eavesdroppers may be able to get a general idea of which services users are accessing, and very technology-equipped eavesdroppers may be able to figure out who is accessing which service based on the setup times and connections - an option would be to have some sort of noise traffic as well. Finally, the phone network provider can cause denial of service.

The third model can use several different methods to set up an encrypted channel between base stations and services, but requires greater (= complete) trust in the phone company to handle access properly and not leak secrets or access patterns. Something similar to SSL would work if there was a common trusted agency that authorized services, but it is not clear at this point that such an agency will ever exist. Public key distribution is difficult, but if the number of phone companies and service gateways (perhaps a "service gateway portal", and some sort of hierarchical system?) is small, the exchange of key lists might be feasible. Something like SSH might work, with a per-SG key downloaded when used the first time, but then one needs to deal with the issue of attackers intercepting the initial and subsequent communications (up until they miss one...). The same eavesdropping and DOS attacks as in models 1 and 2 apply.

4.0 Prototype Implementation

We began our project with grand dreams and visions of the interesting services that we would soon be able to access via our phones. While the benefit of simulating in software was suggested instead of implementing using the actual hardware, we thought that it would be much more interesting to have a working proof-of-concept. Thus, our goal was to: Our experience in building this infrastructure and dealing with the complexity of the available GSM infrastructure was a bit frustrating.

In the ICEBERG setup, the base station is connected via an E1 (European standard ethernet) line to two machines, the UPSIM and the IPPAD. The base station exchanges control packets with the UPSIM, which can run programs written in a proprietary language to control the base station. When a connection is made, the base station forwards the actual (voice) data to the IPPAD, which can then format it for other applications (for example, the IPPAD can support the RTP format for realtime vat audio. The ICEBERG group has implemented proxies that handle the timing and convert the European ethernet packets coming into the IPPAD from the base station into udp packets.). The current ICEBERG prototype system does not provide any authentication, but that is not a problem, since all of our prototyping occurs only after the connection event itself, which the base station simulates.

Given the limited means of indicating the desire to access a service, we decided that the logical initial step would be to use a special phone number (numeric data) to indicate a service request, since using GSM messaging and voice recognition would add too much complexity to the situation. However, getting even the dialed phone number proved to be a significant challenge. After spending some time trying to understand the proprietary language used to control the base station, which is very verbose and fairly low-level, we were fortunate to be able to gain access to a piece of code just completed by another ICEBERG member that allowed us to get three digits of the phone number punched into the mobile handset. This code simplified the data streams by gathering together both the control and data streams in an intermediate java proxy, which we incorporated into our system flow. We added another component, still considered part of the base station in our model in section 2.3, that looked at the phone number and determined the service type based on the number. The base station service intelligence uses the service type to determine whether it should connect to a kerberos server (using the rest of the number as the password) and then connect to the service using the ticket, or just connect to a service in the open. The secure prototype code is based on and works with kerberos 4, since that was the security set up on the cluster, but we also confirmed that it can be easily extended to kerberos 5. The implementation, while simple, does work, and can be demonstrated upon request.

Prototype System Diagram:

5.0 Related Work/Analysis

The need for wireless access to fixed networks is evident, but there are difficult issues in designing a secure communication protocol that provides for both the confidentiality of wireless data communications and authenticity of the communicating parties. Besides the additional risks posed by the wireless medium, the existing wireless devices usually have limited capabilities and impose software/hardware constraints.

It is not enough just to secure the wireless link itself, but one also needs to integrate the security model of the wireless applications seamlessly into existing wired networks. There are two likely alternatives that the research community has looked at: end-to-end security at the application layer and end-to-end security at the transport layer. However, either approach would require modifying the software base of either the fixed-node network, or the wireless infrastructure.

The lack of satisfactory solutions and standard protocol stacks across heterogencous networks has gradually drawn the attention of researchers from both academia and industry, especially now that PDAs such as the Pilot have become extremely popular, and have begun to be integrated into cell phones. The following are some of the related research efforts we came across:

6.0 Conclusion

In conclusion, we believe that extending the capabilities of wireless clients to be able to access the Internet securely will enable a vast number of useful and beneficial services to mobile users. However, our project, which ended up exploring the design space more than the implementation space, indicated that both the protocols as well as the basic (hardware and software) capabilities in this area are still somewhat lacking (although improving). Device advances that have brought cell phones to the level of PDAs promise to make secure mobile service access much more feasible. It is not clear that trying to adapt currently deployed protocols and soon-to-be-outdated hardware is worthwhile when technology is advancing so rapidly. Hopefully the next generation of protocols will have built-in support for services and more robust security.

We were not able to implement the ideal level of security that we wished for because of protocol and device limitations, but we were able to pinpoint some options that could be easily deployed to improve the existing (open) trust model. Our implementation requires only time-limited trust in the base station while securing a channel between the base station and the services.

Future Trends

We expect that, as the cost of handsets drops and capabilities and usage increase, there will be phenomenal progress in this area. It will be crucial to have a clear set of service APIs and standard protocols for choosing and interacting with services. One important future issue will be how to fit proxies into the trust model for secure mobile services - proxies will certainly be very useful for providing device- or user-specific service enhancements, but fitting them into the security picture looks like a daunting task.

Acknowledgements

We would like to thank Bhaskar Raman for his help and especially for sharing his base station control code with us!!! It would have taken us months to duplicate his work. Sreedhar Mukkamalla was helpful in answering questions about the base station as well. Finally, we would like to thank Dave Wagner and Randy Katz for their input and feedback...

Links
References

Chen-Nee Chuah
Mark D. Spiller