MNPA: a mobile network privacy architecture

Computer Communications 23 (2000) 1777±1788

www.elsevier.com/locate/comcom

MNPA: a mobile network privacy architecture B. Askwith*, M. Merabti, Q. Shi Distributed Multimedia Systems Group, Liverpool John Moores University, Byrom Street, Liverpool L3 3AF, UK 1 Due to unfortunate circumstances, this paper was omitted from the previous issue, a special titled ªAdvanced Security Techniques for Network Protectionº

Abstract This paper presents a mobile network privacy architecture (MNPA) that enables the provision of very strong user privacy against external and internal threats within mobile networks. The MNPA extends the mobile networking model with two new components. The ®rst, privacy routing capability, enables untraceable communications between hosts. The second, privacy token issuing authority, is a third party application that manages the ¯ow of MNPA user authorisation tokens in the system. The operations of these two components are detailed. We follow this by demonstrating how these components can be used to implement protocols for privacy enhanced network operations. New secure methods for location registration, remote host communication and billing are presented. We ®nish with a discussion of issues of collusion and trust within the architecture and look brie¯y at public key infrastructure requirements. q 2001 Elsevier Science B.V. All rights reserved. Keywords: MNPA; Privacy enhanced network operations; Location registration

1. Introduction Over the past decade use of computer communications has increased at an incredible rate. In addition to around 180 million Internet users in mid-1999 [19], there are around 350 million mobile phone users [22]. By 2005 it is expected that this number will rise to over 1 billion users. In parallel the next generation of mobile networks, known as third generation networks, will be introduced to aim to provide high bandwidth multimedia services at any time and at any location globally. These networks are likely to converge, creating a single highly heterogeneous global network. A serious implication of moving towards the `information society' is the potential lack of control that users have over personal information stored in computer communication systems. Many authors suggest that self-regulation and legislation are not enough to ensure user privacy. However, control can be returned to the user through privacy enhancing technologies. In this paper we consider the problem of achieving very high levels of privacy for users of mobile networks by ®rst setting out a series of requirements on security for both users and service providers. These requirements consider mobile * Corresponding author. E-mail addresses: [email protected] (B. Askwith), [email protected] (M. Merabti), [email protected] (Q. Shi). 1 http://www.cms.livjm.ac.uk/research/dms.

privacy to include all the information associated with a user. Such information can be categorised as: identity, location, action and message content information. We therefore consider our aim to be to protect all user information from both external and internal attacks. Existing techniques, while achieving much for privacy, are shown to fail to meet our requirements. These techniques focus on either speci®c application domains or on particular parts of the system security. Others fail because they aim for a lower level of protection against internal attacks. This paper presents a framework for meeting our requirements in a general mobile network setting. Our framework, called the mobile network privacy architecture (MNPA), overcomes the dif®culty of providing high levels of internal privacy. To achieve this the MNPA extends the mobile networking paradigm by adding two new components and modifying security procedures. The two new components are privacy routing capability (PRC) and privacy token issuing authority (PTIA). The PRC allows messages between two users to be untraceable, while the PTIA helps bootstrap anonymity by issuing authorisation tokens that are used to gain access. The MNPA provides the ability to de®ne secure and privacy enhancing mechanisms for network users behaviour. We identify location update, accounting, and host-to-host communications as the most essential tasks a user performs. For each of these tasks we present new protocols that take advantage of the MNPA components. These are shown to

0140-3664/00/$ - see front matter q 2001 Elsevier Science B.V. All rights reserved. PII: S 0140-366 4(00)00347-9

1778

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

Fig. 1. Communications in a mobile network.

allow users to move location, use network services and communicate with other users in an accountable and highly private way. Such high privacy is evidence that users have control over their data trail. In order to provide a useful system we also consider how users might set their own privacy levels by controlling the release of data to the parties they trust. The remainder of this paper is as follows: Section 2 lays out the set of requirements for mobile network security, followed in Section 3 by a survey of related work. We introduce the MNPA in Section 4 and detail the new components in Section 5. We show how to use the architecture to implement privacy by presenting protocols for location registration, anonymous communication and accountable anonymity in Section 6. An analysis of associated issues is carried out in Section 7, including trust analysis and collaboration analysis. The analysis shows that the MNPA can achieve our aims given a reasonable level of trust in the network elements. Finally, we conclude the paper in Section 8. 2. Requirements for mobile network security The fundamental difference between mobile and ®xed networks is the mobility of users. This has the consequence that as users move around, their points of connection may change. 2 In this section we outline the operation of mobility management in mobile networks and then discuss user and system requirements for security. 2.1. Mobile networking Although the terminology may differ (we have chosen GSM [17] terminology here) between systems a mobile network typically consists of a set of users who carry mobile stations (MSs), e.g. a cell phone. These MSs are connected 2 If a user moves a short distance the connection may remain static, e.g. within the same room.

to the mobile network via a base station (BS) that is physically local to the users. A BS is responsible for managing the connection point (e.g. radio interface) for the users. A mobile switching centre (MSC) controls all BSs within a set area. The MSC is responsible for mobility management of all users currently connected to the part of the network under its control (i.e. the domain of the MSC). This includes recording location information, managing address space and authentication of users. Fig. 1 illustrates a logical layout of a mobile network. Each user is registered with a speci®c domain, known as the ªhome domainº or ªhome networkº. Fig. 1 shows an MS that the user has activated within a foreign domain (a domain other than the home domain). In order to manage mobility an association is created between the current location of a user, as managed by the MSC the user is connected to, and his registered account details. A user wishing to initiate communications with another user must do so by tunnelling through his local domain, to the other's home domain, and ®nally to the other's local domain. In some systems (e.g. MobileIP [20]) a user can cache the other's location, once known, and communicate directly between their respective local domains. If a user moves to a new point of connection then the system must perform a location update (also called location registration). This means that the previous association must be deleted and a new one created. For the home domain this is simply a case of altering the location of the user. Locally the previous location must be deleted from the database and a new one entered. This new one may or may not be in the same domain. Having outlined the basic operation of a mobile network we shall now examine relevant security requirements. 2.2. System security requirements The secure operation of a mobile network can be usefully thought of as ful®lment of two sets of criteria, those concerning the system operators and those concerning the users of the system. System operators allow authorised users to access the system in an authorised manner, i.e. fraud prevention. Users wish to keep their behaviour hidden from unauthorised parties, i.e. privacy. 2.2.1. Fraud protection Service providers need to be able to prevent misuse of their networks. Such misuse might involve attempting to gain service without payment or intruders trying to gain access to services via an existing account. Authentication of users is needed. This can occur either when a user requires a location update, or when a user accesses some service in the network. Fraud protection can also be aided by using encryption of user messaging (particularly for control data, e.g. billing). Additionally networks may choose to provide equipment security such as smart cards, and biometric access. We do

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

not consider these measures further as we are more concerned with providing user privacy. 2.2.2. User privacy Concern over user privacy is constantly mounting as the role of the Internet grows [5]. In addition to the desire to keep message contents private, users are concerned about the commercial misuse of their personal data for marketing (and possibly other) means. In many situations, therefore, the entire behaviour of a user may be considered private. For mobile environments we can identify four types of sensitive user information: ² ² ² ²

message contents; identity; location; actions (e.g. connection to services).

The level of protection of this information may also vary depending on the trust the user has in various parts of the system. These levels are as follows: 0: no privacy; 1: hiding information from external attackers; 2: hiding identity from foreign networks; 3: hiding the relationship between the user and the home network; 4: hiding identities of home and foreign networks; 5: hiding user behaviour from home authority. Note that each category protects more information than the previous and is more dif®cult to achieve. In order to achieve privacy at level 5, the behaviour of a user is hidden from all parties, including the home network. This is the level we wish to achieve with the MNPA. In order to reach this level we must provide the network with the ability to mutually authenticate users, register location updates and perform service provision and billing. Having considered the requirements for mobile networks privacy and security from both the user and system perspective, we now examine related work in the area. 3. Related work There has been considerable interest in mobile network security over the past few years. In this section we ®rst look brie¯y at the basics of cryptography. We follow this with a discussion of general results concerning anonymity and privacy. Finally we look speci®cally at results aimed at mobile networking. 3.1. Cryptography basics The goal of security engineering is to achieve the requirements for con®dentiality, integrity and availability within a given system. Con®dentiality is primarily the user require-

1779

ments for privacy whilst the integrity requirements are mainly those for the system operators, though the relationship is not quite this simple. In order to focus on the user privacy aspects of mobile networking we have chosen to leave alone availability requirements. Typically such requirements are dealt with by different techniques such as intrusion detection, another exciting and expanding branch of computer security [6,7]. The foundation tool for achieving con®dentiality and integrity is encryption. Encryption can be used to build secure protocols for communications. In our research we have made the assumption that there exist suitably secure encryption algorithms. This allows us to concentrate on the building of protocols while remaining neutral about encryption algorithm implementation. The reasons for this are that ®rstly, we intend to offer no new ideas regarding encryption and secondly, it is the design of protocols that pose the greater problem within this system. Encryption algorithms are either symmetric (a single key) or asymmetric (two keys, one private and one public). It is commonplace to use symmetric algorithms for message con®dentiality and asymmetric algorithms for protocols such as symmetric key distribution. Another major use of asymmetric encryption is that of providing digital signatures. Such signatures link a message to a private key of an asymmetric scheme. Chaum [8] discovered a useful way of using RSA [23] signatures, which they called blind signatures. These signatures allow one party to submit a message for signing by another party without that party being able to read the message. Blind signatures work in principle as follows; assume one party, A, has a message, m, which he wants another party, B, to blind sign. First A sends the message m 0 to B where m 0 is equal to (m p r b) where r is the random blinding factor chosen by A and b is the public key of B. The next step is for B to sign m 0 and return it to A. The random blinding factor can now be divided out using b revealing a signature, m b on the message m. Note whether B did see m. 3.2. Anonymity-based results There has been a great deal of interest in the subject of anonymity in both technical and social terms. We have chosen to leave the social debate about privacy and anonymity for others to solve. The goal of technical solutions to anonymity is to hide the identity of a sender from all other parties (though not necessarily including the recipient). Typically this is achieved by sending the message via one or more intermediaries in order to confuse any traf®c analysis. Chaum [10] formally described this idea, which they called a digital mix. A digital mix is a network host with an input message set and an output message set. The transformation performed at the mix is to decrypt the input message set and then batch, pad and re-order messages to produce the output message set. By considering each

1780

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

message and its associated header information in this process, the relationship between input and output is known only to the digital mix itself. By chaining a series of mixes together a user can foil any traf®c analysis within the network so long as at least one digital mix is uncompromised. While this concept has proven to be useful in e-mail remailer systems, e.g. Babel [12], it has some major drawbacks for use in real-time communications. The batching and reordering of messages place potentially unacceptable delays on some messages. Computation in terms of the message senders being required to perform multiple layers of encryption on the initial messages is a particularly inef®cient distribution of load. This point is particularly pertinent in a mobile environment where terminals may have certain constraints on resources such as computation speed and energy consumption. Some mix-based solutions have attempted to address these concerns. An ISDN-based system known as realtime mixes [15] has recently been developed and been shown to operate favourably. This system uses features of the ISDN system to create mix connections. Unfortunately this system is not suitable for all types of communications systems. Another recent solution is the Onion routing project [21]. This is an Internet-based solution that draws the computational complexity away from the user and into the network by proxying the anonymity process. Each trusted network operates a proxy onto the outside network that performs the layering of encryption into `onion' data types, which then form an anonymous connection. The proxy is required to be trusted since it has full knowledge of the source and destination addresses. This causes a problem since we assume that users may be in an untrusted network at any time. Nevertheless, onion routing has been demonstrated at near real-time speeds. Other signi®cant research in anonymity includes anonymous auctions (e.g. [10]) and e-cash systems. This latter category tends to focus on achieving anonymity within the protocols and the coinage rather than the network itself. A common theme is the use of blind signatures, which we use in our architecture. Much of the recent work has attempted to build on the initial work by Chaum et al. [15]. 3.3. Mobility-based results Attempts to secure user privacy in mobile communications are quite widespread in the literature. In this section we shall look brie¯y at the most signi®cant results. Initially we shall examine the privacy in GSM [17], since this is the most widely deployed mobile communications system in the world. Privacy is not a major goal of GSM, however `over-the-air' privacy is achieved. Each user identity, international mobile subscriber identity (IMSI), is masked by a temporary identity, temporary mobile subscriber identity (TMSI), during each session. Encryption is

provided over-the-air in order to provide message content privacy and authentication. However, a user may be required to reveal his IMSI during set-up at the networks' request. This is problematic since authentication is not mutual, meaning the user does not know who is asking for the IMSI. Research efforts in this area are divided into privacy enhanced authentication protocols and those based on mixes. The major results in authentication protocols are [4,13,16]. These methods achieve privacy up to level 3, as de®ned in Section 2.2. Samfat et al. [19] proposed an interesting protocol, which enables level 4 privacy protections by allowing a recently visited domain to provide authentication (which in turn may have been authenticated without contacting the home domain). However, this is primarily concerned with local authentication and does not address the issue of secure location update with the home network. Work in the area of mixes is typi®ed by Ref. [14] which allows a mobile user to register location updates anonymously. While this is a promising advance it does not cover authentication, a clear goal of our system. Our system is required to provide a framework for both authentication and privacy. As we have seen from this survey, no one solution provides the highest levels of user privacy set out in Section 2. We note that the solutions themselves are not at fault, but more simply they have a different set of initial requirements. In general these solutions require too much trust in the network. 4. Architecture overview This section presents our proposed framework, the MNPA to achieve the requirements for mobile user privacy outlined in Section 2. We limit this section to discussion of the overall concepts, aims and reasoning for the architecture. Details of the elements of the MNPA are given in the following section. Fig. 2 shows a logical view of the MNPA extensions to the mobile network depicted in Fig. 1. The PTIA is a distributed third party with a low trust requirement that manages the life cycle of user privacy tokens. A user privacy token allows a user to gain access to services on a network without being identi®ed. Any PTIA subscriber can verify tokens. The distributed nature of the PTIA means that a particular token may have been created by one of a number of PTIA processes, each with a different key. In order to allow a network to verify any token the PTIA must also handle distribution of these keys. The tokens are collected by service providers who subscribe to the PTIA, on behalf of their users, without a link being made between the user and token (using blind signatures). By pre-computing tokens in batches we aim to relieve the network and the user of this task in real-time. These tokens may be used for various purposes where some form of assurance is required by the network.

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

1781

Fig. 2. Mobile network privacy architecture. PRC: Privacy routing capability; PTIA: Private token issuing authority.

Once issued to a user, a token can be submitted for various purposes (such as registration). During submission the token is cancelled from the systems, disabling any further use. Attempts to reuse tokens are discovered by the PTIA and reported to the relevant network. This gives the PTIA a `watchdog'-like position in the architecture. This turns out to be a bene®t since anonymous accounts can be arbitrated by the PTIA, a natural role for this third party. Communications between the MSCs are performed using the PRC. Privacy routing is achieved through an anonymity scheme such as onion routing [21]. In the MNPA we describe a new method more suitable for mobile environments. When users register their locations they substitute their PRC address for their physical identities. Similarly the local network makes an association between a temporary identity and real location for a user registered with a network based on a PRC entry point. The PTIA and PRC are discussed in detail in Section 5. By designing suitable protocols (described in Section 6) for location registration and accounting, we are able to utilise the PRC and PTIA to provide high levels of user privacy without undue complexity. By unlinking the identity of a user from the token a user is able to mutually authenticate with a remote network by ®rstly showing that a token is authentic and secondly by using the PRC to authenticate with the home network (for mutual authentication and location update). Although we claim to achieve high levels of user privacy using this architecture, it must be noted that a potential compromise can occur if certain combinations of parties collaborate to share information. We examine these combinations in Section 7 in addition to examining the trust required of the components of the architecture.

Fig. 3. Example route of a message between two hosts using the PRC.

5. Architecture components In the previous section we introduced the MNPA. We now discuss the functionality of the PRC and PTIA. Following this, in Section 6, we are able to demonstrate how these components facilitate in the implementation of privacy enhancing protocols for location registration, user communications and billing. The results in this and the following section extend our work previously published in Refs. [1±3]. 5.1. Privacy routing capability (PRC) In Section 3.2 we discussed various anonymity solutions to privacy. We noted various problems with these solutions. In this section we discuss our proposed solution to this problem, which we call PRC. A solution to the PRC problem must solve the following problems with existing `mix' schemes. Firstly it must remove as much encryption overhead as possible from the user. Secondly it must not rely upon any underlying network technology. Finally it must not require excessively trusted components. The solution we have developed mainly utilises symmetric encryption. This is achieved by ®rst pre-computing a symmetric key, KUX (or optionally, more than one), for each available node in the PRC. The key is then encrypted using the public key, KX, of X. This message is denoted as KX {KUX }; where K{m} is the encryption of m using key K. This pre-computation can occur at any convenient time, one possibility is for the user to download the results from a home computer before roaming. In order to send a message through the PRC the user must now choose a route and apply the appropriate layers of encryption using the pre-computed keys. The method to choose a route is outside the scope of this paper, but a simple method might be to choose at random a route from a set of pre-selected routes. Once a route is selected then the message to be sent is ®rst encrypted with the key for the destination. Then, for each node in the PRC, the resulting message is encrypted with the symmetric key for that node and concatenated with the encrypted form of the key for that node and the address of the next destination.

1782

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

The following example shows a message, m, being transferred between two hosts A and B via PRC nodes X, Y and Z. Fig. 3 shows a representation of the route taken by the message. A ! X : KX {KAX }; KAX {Y; KY {KAY }; KAY {Z; KZ {KAZ }; KAZ {B; KAB {m}}}} X ! Y : KY {KAY }; KAY {Z; KZ {KAZ }; KAZ {B; KAB {m}}} Y ! Z : KZ {KAZ }; KAZ {B; KAB {m}} Z ! B : KAB {m} This method has several advantages over existing methods that make it suitable for use within the MNPA. Firstly the use of symmetric encryption removes considerable overhead from the user. By computing a series of keys in advance only symmetric encryption computations occur at the time of communications. Secondly, the ability to alter the route through the PRC enables the user to optimise routes as they move (again, we do not consider how this might be achieved). Also sending the keys at communications time means that forward secrecy is achieved since no state information is stored by the PRC nodes. If each node had to record state information, i.e. identity and key material, then the overhead for the PRC may become excessive, in addition to introducing extra security risks involved in storing keying data. The PRC overcomes the major problems of onion routing, namely that onion routing requires a trusted proxy to provide the routing and encryption facilities on behalf of the user and that a connection must be set up prior to sending data (our method is stateless). To allow messages to be returned through the PRC to the user a return address is required. This can be achieved by including with the outbound message a series of PRC addresses and encrypted keys formatted as a PRC message. This is then sent with the return message and processed as described above. Alternatively, where the sender is aware of the sender, the sender may request that the recipient perform the task independently. Experience with the onion routing network suggests that ®ve hops offer suf®cient security. We currently see no reason to suggest any other number in this paper. What we would suggest is that each node used be operated by different domains, such as different commercial PRC providers. We have now described a PRC that enables untraceable routing of messages through the network. This is the ®rst building block to providing privacy services in the MNPA. The other major component of the MNPA is the PTIA, which we describe next. 5.2. Privacy token issuing authority (PTIA) In Section 4 we outlined the basic operation of the PTIA within the MNPA. Now we expand on this by detailing

token's structure and life cycle including the operation of the PTIA. The PTIA is a distributed application that manages the privacy token lifecycle. A privacy token is provided by the PTIA to networks that can then provide tokens to their users. The purpose of tokens is ®rst to provide secure and unlinkable access to networks in order to allow users to achieve their privacy requirements. Secondly, they remove computation from users by simplifying authentication. Thirdly they facilitate a novel method of anonymous billing (see Section 6). Finally, they provide assurance of authorisation, backed up by the PTIA-network service agreement, to service providers and each token reveals no information about the user. A token is a special type of public key certi®cate. Normal certi®cates create trust in an identi®ed public key. With PTIA tokens we create an anonymous public key certi®cate for the user that is also bound to the home network public key associated with that user. Only the home network is aware of the binding between the two keys, though the PTIA sees the public key of the home network. This allows tracing at a later stage (e.g. for billing disputes). The process operates as follows: Home ! PTIA : KHP {KH ; {KH ; KM }RKP } PTIA ! Home : KHP {KP21 {Id; {KH ; KM }RKP }}} To request a token the home network, Home, constructs a message containing it's own public key, KH, and the section to be signed by the PTIA. This latter section contains both KH and the public key of the user, KM. These are multiplied by the blinding factor that is computed by raising a random number, R, to the power KP, where KPis the public key of the PTIA. The result is encrypted with the shared key between the home network and the PTIA, KHP, to prevent external attacks, before ®nally being sent to the PTIA. The home network retains the random number whilst the token is still in use as it may be required during a dispute. Upon receipt of the token request the PTIA decrypts the message using the shared key, KHP. The remainder of the message is concatenated with a unique token identi®er, Id, and signed using KP21 : Finally the message is encrypted with KHP before being sent to the home network. The home network produces the blind signature by dividing out R KP, leaving KP21 {Id=RK P; KH ; KM }; which becomes the token. The home network records the token along with the random blinding factor, R. Tokens provided to network for network use are similar but only provide a single key (for the network) rather than two keys. It is preferable that this key is different from that used for user tokens to lessen the risk of disclosure. When a token is submitted to a network it must contain an identi®er for the PTIA element that created the blind signature. This enables the network element to decide which PTIA key to use to verify the token. The combination of the PTIA and PRC does not in itself

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

achieve privacy for users within the MNPA. Instead they provide a framework for privacy enhancing protocols. We have developed protocols to achieve location registration, user communications and billing. These are described next. 6. Implementing privacy In this section we detail how the MNPA can be used to implement privacy enhanced services for a user. Firstly we show how a user can anonymously update his location in both the local and home network databases. Then we show how a user can communicate with another user in an anonymous fashion. Following this, we look at how accountability can be introduced into the architecture by presenting a method of creating a post-payment account between a user and a service provider. Finally we discuss our prototype implementation of the MNPA. 6.1. Location management In order for a mobile user to maintain a presence on the network it is required that his location is registered at appropriate intervals (e.g. when a terminal is activated). We term this procedure registration. This is achieved by the mobile terminal making a request for registration, which causes the local network to mutually authenticate the user before recording a location address in the local database. The home network needs to be informed of the registration so it can also record the update. To maintain the privacy of the user within the MNPA during registration the user submits a privacy token. This token gives assurance to the local network. The network must now inform the user's home network of the user registration request. In addition a network token is used to provide authentication to the home network, which is then used to form a reply for the user. Communication between the networks is conducted via a PRC connection to hide the location of each network, and thus information about the user. The aim is therefore to enable identi®cation-location pairs to be recorded as (Real Identi®cation, PRC Address) at the home address register, and (Pseudonym, Current Address) at the local address register. We now present the registration protocol followed by an explanation of the contents of each message. Note that other implementation speci®c message components might be present but we are only concerned with those that are required for the security of the MNPA. 21 {mt; fma; KMH {rma}} Mobile ! Local : reg; mt; KM 21 Local ! Home : reg; lt; KL {lt; mt; rand; KMH {rma}} Home ! Local : reg; KH21 {rand; KMH {KL }} Local ! Mobile : reg; KH21 {rand; KMH {KL }}; KL21 {KM {KML }}

To begin with the user, Mobile, sends a registration request message, reg, to the local network, Local. This

1783

message contains a token, mt, followed by two encrypted sections. The local network ®rst attempts to validate the token. If the token is valid then the public key, KM, in the token is used to decrypt the ®rst section. The ®rst encrypted section contains a copy of the token and the PRC forwarding address, fma. The local network cannot read the second encrypted message that is encrypted under the key shared between the user and the home network. It contains a PRC return address. This section is forwarded to the home network as part of the second message. Following the ®rst message the local network sends a message to the address given in fma, which is actually bound for the home network, Home, via the PRC. This message includes a network token for the local network, lt, followed by an encrypted section. The encrypted section contains lt and the second encrypted section from the previous message. Also included is a random number used as a challenge for the home network. These are encrypted under the secret key of the local network, ML21 : The token lt contains the public key (without identity) of the local network. This enables the home network to decrypt the remainder of the message to reveal the user information. The home network must validate mt and lt before continuing. If they are valid then the return address rma is entered into the user's record in the location database. Now the home network constructs a message containing two encrypted sections. The random challenge, rand, and an encrypted copy of the local network public key (encrypted under the shared key between the user and home network) are encrypted under the secret key of the home network. Upon receipt of this message the local network ®rst checks the challenge response evaluates to rand, and if it does, it then sends the encrypted public key and the session key to the user. The session key is encrypted under the public key of the user and the secret key of the local network. The user can check the validity of this key by using the key encrypted by the home network, KMH {KL }: 6.1.1. Discussion of protocol The objectives of this protocol are to allow privacy enhanced location registration, mutual authentication between the three parties, and session key distribution between the user and local network. This section discusses how this is achieved by the protocol. In the ®rst message the presence of mt enables the local network to recover a certi®ed public key and provides authentication of the user. The signature provides the message with integrity and authenticity. Use of the shared key (between user and home network) provides origin authentication to the receiving party. The second message provides authentication of the local network to the home network via lt. The public key extracted from lt allows the home network to witness the integrity of the message. The home network can now provide authentication of the local network to the user by

1784

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

sending the retrieved public key in the third message. This message also provides mutual authentication to the local network via the encrypted challenge, rand. The ®nal message securely distributes the session key to the user. This is achieved by encrypting it with the public key of the user obtained in message one. In order to check the origin authenticity of the key it is signed by the local network. This signature is checked by the user using the key extracted by the home network from lt in message two. So far this analysis demonstrates that session key distribution and mutual authentication occur. We now need to show that location registration occurs in a privacy-enhanced manner. The use of tokens combined with the PRC provides the support for this property. In the ®rst message the local network has access to a certi®ed public key in the user token. This provides no identifying information about the user. Similarly the PRC address, fma, provides no information. Messages two and three supply the respective networks with network tokens for authentication. Contained in these are the public keys for verifying tokens. In view of the relatively small number of service providers it might be argued that the network could identify the key. However, these keys are only used for tokens since they are blinded by the PTIA no identifying information is revealed. Moderately frequent replacement of these keys would reduce such a risk even further. 6.2. Remote host communications We have demonstrated how a user can anonymously register his location. We now demonstrate how a user can maintain user privacy during communication with other users or service providers. Both these operations turn out to be fairly trivial and do not require any special protocols. Much depends on the exact requirements for privacy of each party. Several levels of privacy are possible, as discussed in Section 2.2. However, these levels of privacy do not address privacy between two remote hosts. There are four possible levels of privacy between two remote hosts. From highest level to lowest these are: reveal no information (total privacy); reveal location (identi®cation privacy); reveal identi®cation (location privacy); and reveal both location and identi®cation (no privacy). Note that while a user may reveal information to a remote host we assume that they use protocols that do not leak identi®cation information to the network. Following registration a mobile user obtains a pseudonym. Thus a user can achieve identi®cation privacy using a direct connection to the remote host (thus avoiding the possible performance cost of the PRC). In most implementations this still represents a very high level of privacy since the location is only revealed to the granularity of the location area provided by the local network. If the remote host also requires total or identi®cation privacy, and is not

currently pseudonymous, then a PRC connection must be used. Also, if the remote host is aware of the user identi®cation and the user requires location privacy then a PRC connection must be used. 6.3. Billing In certain instances a mobile user may wish to acquire services locally from the network and pay for these at a later date through their standard home network service provision account. This poses a problem for both the local network and the user. The user must be able to acquire such services without revealing information about themselves, yet must also be able to provide assurance of post-payment to the local network. We achieve this by developing an account of the service provision that we cryptographically tie to a user token. The local network then submits this resulting account in order to gain payment. Our protocol to achieve this comes in three sections. Firstly, account setup where the user presents a token that is then cryptographically bound to a service agreement to create the account. This is followed by the service provision phase where the account is passed repeatedly between the user and the network for each unit of service. Each round provides a further binding for that unit of provision. The ®nal stage of the protocol is the settling phase where the account is submitted for payment. The home network can evaluate the account by reversing the cryptographic process to reveal the user token and total billing details. Payment is made if the check succeeds, and otherwise a dispute occurs and the PTIA is called to arbitrate. We now present the three phases of the accounting protocol followed by an explanation of the contents of each message after each phase is presented. Account setup 21 {mt}} Mobile ! Local : M; L; KML {M; sr; sp; KM 21 21 {mt}}} Local ! Mobile : M; L; KML {L; sc; sp; KL {KM 21 Mobile ! Local : M; L; KML {M; sa; sp; KM 21 {KL21 {KM {mt}}}}

In the ®rst message the mobile sends an encrypted service request to the local network. This request consists of the request, sr, any service parameters required, sp, followed by a user token, mt, encrypted by the private key of the 21 : This message is encrypted with the key shared user, KM between the user and the local network, distributed during location registration. The second message allows the local network to con®rm the service provision, sc, and any parameters, sp, with a similar encrypted message. The private key of the local network, KL21 ; which forms the basis of the account, encrypts the user token again. Note that the account is bound to both parties and neither can now tamper with it. The ®nal message in the setup is a con®rmation by the

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

user of the terms (a negative con®rmation would simply have the sa ¯ag set accordingly, e.g. 0). Once again the user applies a layer of encryption to the token. To simplify the expression of this process we shall use the term, account, to refer to the layers of encryption performed on the token in previous messages. The network stores the original token in order to submit it to the home network along with the ®nal account. An account can only be honoured if the token matches the processed account. An account is processed by recursively removing the signatures, leaving the initial token. The network cannot cheat since the signature of the user is required after each round. Service provision Local ! Mobile : M; L; KML {M; ss; sb; KL21 {sb; account}} 21 {sb; account}} Mobile ! Local : M; L; KML {L; sd; KM One round of this section of the protocol occurs after each round of service. Firstly the network provides the service, ss, and any billing data, sb. The network encrypts the account and the billing details together. The user encrypts again and includes a data acknowledgement, sd, which may be more complex (e.g. inclusion of service performance indicators). Failure to encrypt the account will result in service termination. Note that the network can only receive payment for units that have an associated account. A weakness in this method is that by neglecting to sign the last service unit the user can gain this unit for free. We suggest that to lessen this risk service providers should think carefully about the size of service units and particularly those at towards the end of a session. The protocol is compact (only one public key encryption required), tamperproof (neither party can add, modify or remove a round and defraud the other), self-contained (an account is complete after each round) and of constant size (the account data passed remains the same size regardless of the number of units). Account settling Local ! Home : L; KH {KLH }; KLH {mt; KL ; KM ; account; ad} Home ! Local : KLH {mt; nPayment} Once the service provision has terminated (either naturally or otherwise) the local network submits the account with the service details, ad, the initial user token, mt, and the veri®cation keys, KM and KL. These are encrypted with the respective secret key, KLH. The service details, ad, are the full collection service parameters, sp, from each round of service provision. This message is now sent to the home network, via the PRC. The home network can now verify the submission by

1785

repeatedly applying the veri®cation keys to account until mt is recovered (or not in the case of misuse). This veri®cation process is compared with the claimed details, ad. If successful the home network will forward payment to the local network via the PTIA. We have simpli®ed this for the purpose of this paper to nPayment. In reality this will be a more complex expression ensuring security between the local and home networks, of which a variety of methods are possible. Dispute Home ! PTIA : KHP {mt; KL; KM; account; ad} PTIA ! Local : KPL {mt; Dispute} or PTIA ! Home : KHP {mt; Disagree} Failure to compute the original token results in the PTIA being asked to arbitrate the account. The PTIA must process the submission, identi®ed by mt, in the same manner as described above and either produce a Dispute or a Disagree message. A Dispute means that the local network is at fault. This can either require a reassessment by the local network or no further action. A Disagree means the home network is falsely claiming a dispute, which would probably result in payment being made as requested by the local network. The actual mechanisms to solve disputes are dependent on the contractual agreements between the parties and are outside the scope of this paper. This protocol allows post-payment of services between a user and a local network. It is possible to modify it to provide post-payment between a user and any service provider by modifying the account setup phase. We assume that the new provider is subscribed to the PTIA. The changes to the protocol must allow the user and provider to share a token each and one session key. We can achieve this by modifying the ®rst two messages of the protocol as follows (we have included the last message of the account setup phase for completeness but note that no changes have been made): Mobile ! Provider : M; P; KP {M; mt; KMP ; sr; sp; 21 {mt; KMP }} KM Provider ! Mobile : M; P; KMP {P; pt; sc; sp; 21 {mt}}} KP21 {KM Mobile ! Provider : M; P; KMP {M; sa; sp; 21 21 {KP21 {KM {mt}}}} KM Note that the initial encryption is done using the public key of the new service provider, KP. Inside this encryption we have now included a mobile token, mt, and a shared session key, KMP. The second message now contains a token from the provider, pt. This will contain a different public key from KP in order to allow the users' service provision to remain anonymous.

1786

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

6.4. Implementation An experimental implementation of the MNPA has been conducted in order to evaluate the performance overhead and general viability of the system. This implementation runs on a small network of Intel-based machines running Linux. Each component of the MNPA was implemented as an independent program. We treated each machine as a separate domain; therefore each machine operates a local network and home network module, as well as PTIA and PRC modules. Any number of user modules is present within the system and we allow the tester to run these arbitrarily as required. We are currently testing the architecture by implementing a series of modules to collect communication data and report results based on overhead to security and information revealed at various points. We are also designing a series of test modules to simulate potential attacks on the system. Whilst this can never hope to be a complete test procedure we hope to at least demonstrate some security properties. We have demonstrated how a user can maintain privacy during location registration, remote host communications, and service provision. In the next section we shall examine the trust relationships in the MNPA and how collaboration may be used to reduce the privacy of the user. We also discuss the related issues of privacy con®gurability, PKI constraints and law enforcement requirements. 7. Analysis This section examines the possible problems in providing user privacy in the MNPA with reference to possible collaborations between parties and the trust required of each party. Further, we take a look at how users might con®gure different levels of privacy. Finally, we look at the public key infrastructure (PKI) requirements and how this might affect the running of the system. 7.1. Collaboration threat analysis The various parties in the MNPA all have access to certain user data during the operation of providing communications under our scheme. In this section we examine the ways in which collaboration between parties can erode users privacy. First we shall recap on what data each party has access to: ² PTIA. The PTIA has no information on identi®able users since the tokens have the identities of users blinded. During service provision the PTIA learns a link between two network providers only when a dispute occurs. The account details of the service provided contain billing details but not the actual service provided (unless the user agreed to this content). ² PRC. A requirement of all mix-based systems is that at least one host in each route must remain honest [7]. If this

requirement is met then little information is leaked. The PRC only ever deals with routing of information, so no details of content are vulnerable to the PRC. If we assume this requirement to be met then no fruitful collaboration may occur. ² Home network. The users home network is aware of the user identity but the location remains pseudonymous. It learns service details, including billing information; however, the actual service content is not revealed to the home network unless the user agreed to this content. ² Local network. The local network records the location of the user in order to route messages to the user; however, the user remains anonymous to the local network. Service details are recorded in full where anonymous accounting takes place. We have demonstrated that each individual component cannot compromise user privacy alone. However it is possible that two or three parties may collude in order to determine more information. We shall brie¯y analyse the threats to user privacy of such collusion. ² PTIA±Home. In the event of a dispute the PTIA could reveal to the home network the local network currently being used by the user. User privacy would be reduced to from level 5 to 4. ² PTIA±Local. In the event of a dispute the home network of a user can be revealed to the local network. This reduces privacy from level 5 to 4. ² Local±Home. This collaboration would completely compromise user privacy. However, these two parties cannot collaborate normally without the collaboration of the PTIA since the PRC masks the identities from each other. Only if networks had some pre-arranged method of collaboration through the PRC then compromise would be possible. ² Local±Home±PTIA. By drawing the possibilities for compromise from the above three scenarios we see that collaboration between all three parties could connect all possible user data allowing a complete trace to occur. User privacy could be reduced to level 1 (note that message contents remain secure where the user is employing end-to-end encryption). 7.2. Trust analysis The security and privacy afforded by any system requires each party to place some level of trust on other parties to act in an honest way. Dishonest behaviour may include failure to operate protocols in the correct manner, failure to take adequate protection of user data, and collaboration with other parties to link information. Here we examine the trust model the user has in the elements of the MNPA. ² Home network. The user's home network is the most trusted component of the MNPA as it is the only party

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

to have authorised access to the user identity. Therefore, the main trust required of the home network is to handle identi®cation information in a secure manner. Trust in operating protocols is reduced to the ability to process messages correctly and to manage its own cryptographic material securely. Failure to follow protocols will be noticed by other parties. The user must trust that its home network will not collaborate. We suggest that these trust requirements are relatively easy to meet since the user has a direct relationship with their provider, and should have access to information about the performance in this area (e.g. market surveys). ² Local network. Trust in a local network is lower than that required of the home network since a user is registered only pseudonymously. Incorrect operation of protocols will be detected either by the home network (for registration) or by the user itself (for billing). While collaboration is a problem, serious privacy compromise can only occur with collaboration with the home network, which as we noted can be fairly highly trusted by a user. ² PTIA. The user must trust the PTIA to handle disputes correctly and not to be involved in collaboration during dispute. Since a major purpose of the PTIA is to act as an arbitration centre for disputes between service providers it is likely that this will necessitate a certain level of trust, such as a tightly regulated independent body. ² PRC. The PRC is trusted to operate in such a way that at least one host in each route remains honest. Since each route through a PRC may potentially involve hosts in several diverse domains the possibility of all hosts being dishonest is severely reduced. A user is likely to trust the PRC based on market reputation information about particular PRC providers.

7.3. Con®gurability The main aim of the MNPA is to enable the user to gain high levels of privacy. This does not imply that all users must maintain high privacy levels at all times. With this in mind we shall now discuss how the user might lower privacy levels. A user can lower its privacy by avoiding the PRC. This will have the effect of linking the home and local network identities. This can be extended to allow the home network access to detailed location information. The user may choose not to reveal identi®cation information to the local network. Alternatively a user may reveal to the local network its identi®cation but to instruct the local network to continue operating as though privacy were required. This would protect location information reaching the home network. Similarly by not using the PRC in this situation the home network could be informed of a user's current local network but have detailed location remain private. Privacy of billing details may be reduced in a similar way.

1787

The main additional issue here is to reveal to the home network some or all details of the service used. During the account setup stage of the billing protocol the user agrees to a certain set of service parameters. A lower level of privacy would be achieved by accepting identi®able parameters. 7.4. Public key infrastructure (PKI) Operation of a PKI is problematic partly due to the scale of the problem but also due to the dif®culty of revocation [24]. While these problems do not go away completely they are considerably reduced within the MNPA. Each home network must maintain a PKI for its users. This PKI involves managing a key for each of its registered users. For the purposes of the MNPA no inter-domain PKI is required. Since the home network and the user are in regular contact, revocation may be less of a problem. Key management between the PTIA and a network involves no PKI, in the strict sense. Firstly the interaction between the PTIA and network operates using symmetric encryption (a shared key), and secondly the PTIA validation keys are distributed to the networks in a regular timely fashion. The smaller number of keys (one per client) allows this simpli®cation.

8. Conclusions This paper presents an architecture, the MNPA, which solves the problem of securing all user information from external and internal threats to user privacy. This improves on exiting efforts, which generally have much lower requirements regarding internal threats. The MNPA combines the traditional mobile network paradigm as found in systems such as MobileIP and GSM, with two additional privacy enhancing components. These components are the PRC and the PTIA. The PRC enables the untraceable routing of messages between remote hosts. The PTIA controls the use of anonymous authorisation tokens on behalf of a users home network. The MNPA allows the creation of protocols to achieve high levels of privacy for different user activities within the mobile network. We present new protocols for location management, remote host communication, and billing. Given these mechanisms it is shown that a user can move location, communicate with other users and receive network services in a highly private and accountable way. Potential problems with the architecture include the required trust user need in various components and collaborations between these components, which may reveal information. Analysis of the architecture is performed with respect to these issues. We demonstrate that user privacy can be maintained given reasonable requirements from a user. Finally we examine the requirements for PKI within the system. We show how the PKI problem is reduced in this architecture.

1788

B. Askwith et al. / Computer Communications 23 (2000) 1777±1788

References [1] NUA Ltd, How Many Online?, http://www.nua.ie/, 1999. [2] J. Riley, A brave new mobile world, Computer Weekly, London, 17 June 1999, p. 14. [3] M. Mouly, M. Pautet, Current evolution of the GSM systems, IEEE Personal Communications 2 (1995) 9±19. [4] C.E. Perkins, Mobile IP, IEEE Communications Magazine 35 (1997) 84±99. [5] L.F. Cranor, J. Reagle, M.S. Ackerman, Beyond Concern: Understanding Net Users' Attitudes About Online Privacy, AT&T Research Technical Report TR 99.4.3, 14 April 1999. [6] B. Mukherjee, L.T. Heberlein, K.N. Levitt, Network intrusion detection, IEEE Network 8 (1994) 26±41. [7] D. Gregory, Q. Shi, M. Merabti, An intrusion detection system based upon autonomous mobile agents, in IFIP TC 11 14th International Conference in Information Security (SEC 98), Vienna, Austria and Budapest, Hungary, 1998. [8] D. Chaum, Security without identi®cation: transaction systems to make big brother obsolete, Communications of the ACM 28 (1985) 1030±1044. [9] R.L. Rivest, A. Shamir, L. Adleman, A method for obtaining digital signatures and public-key cryptosystems, Communications of the ACM 21 (1978) 120±126. [10] D.L. Chaum, Untraceable electronic mail, return addresses, and digital pseudonyms, Communications of the ACM 24 (1981) 84±88. [11] C. Gulcu, G. Tsudik, Mixing e-mail with BABEL, in SNDSS, San Diego, CA, 1996. [12] A. Jerichow, J. Muller, A. P®tzmann, B. P®tzmann, M. Waidner, Real-time mixes: a bandwidth-ef®cient anonymity protocol, IEEE Journal on Selected Areas in Communications 16 (1998) 495±509.

[13] M.G. Reed, P.F. Syverson, D.M. Goldschlag, Anonymous connections and onion routing, IEEE Journal of Selected Areas in Communications 16 (1998). [14] M.K. Franklin, M.K. Reiter, The design and implementation of a secure auction service, IEEE Transactions on Software Engineering 22 (1996) 302±312. [15] D. Chaum, A. Fiat, M. Naor, Untraceable electronic cash, in CRYPTO '88, 1988. [16] R. Molva, D. Samfat, G. Tsudik, Authentication of mobile users, IEEE Network 8 (1994) 26±34. [17] M.J. Beller, L. Chang, Y. Yacobi, Privacy and authentication on a portable communications system, IEEE Journal on Selected Areas In Communications 11 (1993) 821±829. [18] A. Herzberg, H. Krawczyk, G. Tsudik, On travelling incognito, in IEEE Workshop on Mobile Systems and Applications, 1994. [19] D. Samfat, R. Molva, N. Asokan, Untraceability in mobile networks, in MobiCom '95, Berkeley, CA, 1995. [20] S. Hoff, K. Jakobs, D. Kesdogan, Anonymous mobility management for third generation mobile networks, in IFIP/TC6 and TC11 Communications and Multimedia Security, Essen, Germany, 1996. [21] B. Askwith, M. Merabti, Q. Shi, K. Whiteley, Achieving user privacy in mobile networks, in Computer Security Applications Conference, San Diego, CA, 1997. [22] B. Askwith, M. Merabti, Q. Shi, Accountable anonymity in mobile communications, in MoMuC '98, Berlin, Germany, 1998. [23] B. Askwith, Privacy and Security in Mobile Networks, Liverpool John Moores University, Liverpool, UK, Technical, 26 February 1998. [24] D.A. Cooper, A closer look at revocation and key compromise in public key infrastructures, in NISSC '98, Crystal City, VA, 1998.