A Privacy Enhanced Service Architecture for Mobile Users - CiteSeerX

11 downloads 247825 Views 120KB Size Report
tion providers and independent software vendors that will design innovative ... media messaging, payment and account management, user status, terminal ...
A Privacy Enhanced Service Architecture for Mobile Users Sandford Bessler, Oliver Jorns ftw. Telecommunications Research Center Vienna Donau-City-Strasse 1, 1220 Vienna, Austria {bessler, jorns}@ftw.at

Abstract Location, presence and messaging services provide the essential ingredients for emerging information and communications services. Nevertheless, the users are concerned about revealing their actualized location, presence or contact address information, especially to non-trusted third party applications. In this paper we propose a privacy architecture to achieve unlinkability between services related to a certain user and the user identity itself. The architecture is based on a privacy service which is integrated in the telecom service architecture Parlay-X, currently being standardized by the Parlay Group, and a chained hash technique called PRIVES, well suited to run in small mobile devices.

1. Introduction The next-generation service architecture aims for the establishment of a new class of 3rd party service and application providers and independent software vendors that will design innovative services accessing the networks through open and standardized interfaces such as OSA/Parlay. A success factor for these services is their personalization, i.e. the ability to take into account user’s preferences, his/her presence, location, etc. Therefore, for a better service, the user would have to reveal personal information to basically non-trusted 3rd parties. In order to meet these apparently contradictory requirements, the system has to integrate privacy and identity management mechanisms. In this work we concentrate mainly on the protection of location, presence and address privacy in context of Web Services for telecom operators specified by the Parlay Group [5] and called Parlay X. The privacy architecture we present in this work is specialized for next generation mobile networks and services. Our main contributions are twofold: • specification of a privacy service, integrated in a telecommunications service architecture

• a lightweight pseudonym creation scheme in which the degree of linkability can be controlled by the user and can be optimized for each application The rest of the paper is organized as follows: we cite a few related approaches for privacy in a service context, then review the Parlay-X services: location presence, messaging and payment. In section 2 we describe the architecture of the proposed system, the interface of the introduced privacy service and the privacy protocol. In section 3 we sketch the message flows of a travel navigation guide application, then we conclude and give further research topics. Privacy enhancement technologies (PET) [1] address four basic ISO requirements: anonymity, pseudonymity, unlinkability and unobservability that are subject of a number of research projects dealing with address privacy, location privacy, service access privacy or authentication privacy [2]. In the context of mobile services, the authors in [4] identify two building blocks, an Identity Broker that translates the identity of the client requesting the service into pseudonyms and a Profile Broker that controls the service access to (part of) the user profile in a controlled way. In [6] a privacy enabled architecture for the upcoming 4G services is discussed: the key element is the Personal Virtual Agent (PVA) running in a trusted environment. It protects the identity and stores the profile of the user. Concerning the anonymity of mobile users, the authors in [12] state that anonymity in a web browsing application can be achieved, using for example the mCrowds system. Finally, the EU project PRIME [3] aims to develop a complete framework and architecture for privacy and identity management to cover all identified requirements.

1.1. Parlay X Overview Parlay X Web Services are intended to stimulate the development of next generation network applications by developers in the IT community who are not necessarily experts in telephony or telecommunications. The selection of Web Services is driven by commercial utility and not necessarily by technical elegance. The goal is to define a

set of powerful yet simple, highly abstracted, imaginative telecommunications capabilities that developers in the IT community can both quickly comprehend and use to generate new, innovative applications. Among the interfaces specified until now (version 2.0) there are functions for: third party call, short and multimedia messaging, payment and account management, user status, terminal location, presence. The interfaces defined between an application and the service are specified in WSDL (Web Service Definition Language) [7] and use both synchronous calls as well as asynchronous callbacks (notifications). Relevant for privacy is the addressing of users in most Parlay-X methods with the EndUserIdentifier, specified as an URI (RFC 2396, amended by RFC 2732). Example schemes are tel (RFC 2806) and sip (RFC 3261). In order to implement our privacy scheme, pseudonyms (hash-values) would have also to be recognized as valid EndUserIdentifiers. Among the services that could be privacy enhanced are location, presence, messaging, payment, and call control. In the next section we shortly explain the advantages of privacy protection for a few relevant services 1.1.1 Location Service This service is used when an application wants to obtain the location of a user. In addition to the simple location polling, the new version of location API will include more powerful functions such as: notification when the user enters or leaves an area defined by the radius and a center (given by coordinates), notification when the position changes, etc. In the network layer, the localization is performed by using the signal strength of a few neighboring cells listening to the terminal. The location information (expressed for example in geographical coordinates) can be used by the localized user himself to ask for example a service application for the nearest pharmacy, or by another user (a watcher) who may run an application that schedules a service team. The scenario we are interested in includes an application owned by a third party commercial organization. The 3GPP [8] and IETF have activities on location privacy as well. The IETF Geopriv group has defined location privacy requirements [9] in which a Location Object (LO) [10] plays the main role: it contains the location information to be transmitted from the Location Server entity (a part of the network operator) to the location requestor (watcher). The LO contains also the access rules for different users, it is itself cryptographically protected. While this proposal is general and powerful, it implies that a large data amount has to be transmitted and requires from the watcher a lot of processing power. Also 3GPP tries to improve privacy by tightening the access control of users and

applications on location information. Thus, in a privacy enhancement specification for UMTS Release 6 [5], a complete authorization relationship between three entities: requestor (watcher), application and presentity has to be defined in the telecom server in order to allow access to location information. This increased responsibility of the Location Based Service (LBS) leads to complex database tables, much processing effort and a tight coupling of all participating entities. The protection of the presentity identity is handled only vaguely in the 3GPP document by proposing the use of aliases. 1.1.2 Presence Service This service allows an application to watch different presence attributes of a user and receive notifications, when a selected attribute changes. Applications would react to such changes and configure services, change the incoming or outgoing traffic to that user or perform other actions. The following list of attributes gives us an idea of the potential sensitivity of that information: activity, location type, mood, privacy (e.g. cannot talk), communication means, contact addresses (e-mail, SIP, phone no., etc.). As in the case of location, we would prefer in certain cases to deliver presence information to the application without disclosing the identity of the presentity user. The actions and information resulted from processing the presence information can be delivered either to the presentity itself or to a watcher user entitled to receive that presence information. 1.1.3 Messaging The messaging service allows an application to send to an user or to receive from an user a SMS or MMS message. It is clear that the destination address (MSISDN number, SIP address, email address, etc.) can be associated with the name and physical address of the user. Therefore, the protection of user’s location alone does not make sense, if the application can associate the cellular phone number to the location history. The privacy enhancement solution should prevent the application from using the real destination address for sending a message to the presentity. 1.1.4 Payment Service Parlay X provides a simple application and content based charging Web Service that uses the billing infrastructure of the network operator. The methods of this interface need the user address in order to access his account at the network operator. To protect the privacy of the user, we have to anonymize the user address as mentioned for the previous services.

2.1. Privacy API description Network Operator

Parlay X API

3rd party Application

Presence Service

HTTP/XML-RPC/SOAP

user

Privacy Agent

Location Service

PRIVES API

User Profile

Location, Presence Messaging

Client

...

Messaging Service

Payment Service

Privacy Service

OSA Parlay

Network Layer

Figure 1. System Architecture

privacyAgent A

privacyAgent B

privacyService

logon logon

subscribe (self) ok(r) calc(h1_A)

calc(h1_A)

subscribe(user B) subscribe(from A) ok(r_AB)

calc(h1_AB)

accept calc(h1_AB)

Figure 2. Initialization of the privacy service

2. System Architecture Figure 1 shows the proposed architecture with four identified Parlay-X services that expose their SOAP interfaces to an application. Conceptually, the mobile user terminal consists of a client program used to access the application, to receive messages or to supply own location and presence information. For the purpose of our discussion, we denote with user profile the data to be protected such as current location, presence status and contact address information. In order to access the application, the user terminal queries the privacy agent, which maps different identity attributes like addresses into pseudonyms. The novel part in the architecture is the privacy service, which is the only entity capable of translating the pseudonyms found in the service calls back to the real addresses needed by OSA and the network layers below Parlay X. As described in detail in the next section, the creation of pseudonyms in the agent and privacy service sites is dynamic: in one extreme case, the client can create a new pseudonym for each request, for many applications however, the pseudonym can remain unchanged for the session duration.

The privacy API describes the interactions between a privacy user agent and the privacy service. The selected technology is SOAP over HTTP. The first interaction at startup, logon(password) is used for authentication of the user agents. The password is a shared secret which is defined at registration time (see Table 1). The privacy agent subscribes then to his own privacy information or to that of another user, depending of the application as illustrated in Figure 2. The subscription is either explicitly accepted or processed automatically by policy rules in the privacy service. Following the subscription, the privacy agent receives a seed code word r and can create pseudonyms. The operations parameter allows to restrict the subscription to a part of the private information (location, contact address, presence, etc.). The interaction between the user client and the application is not subject to standardization, the protocol can be HTTP, XML-RPC or SOAP. The client invokes the application with some ”start application”message without necessarily authenticating himself. The pseudonym h1A received by the application in this start message is used as EndUserIdentifier, across the Parlay X interfaces (see Figure 3). At the service side, the privacy service translates the pseudonym back to the real username or address, so that the Parlay X telecommunication service can work properly. Basically, a new pseudonym can be created each time the user client addresses the application. However frequent change of pseudonyms does not necessarily increase the anonymity of the user, since most applications keep anyway a session with the current state of the application workflow and the message history. To control the establishment of a new pseudonym at both sides, the privacy agent calls the method nextKey(). The problem encountered when switching to a new pseudonym is a synchronization one: the application has to have closed the transactions towards the services and the user, so that the latter can establish with the privacy service a new pseudonym (with nextKey). The most common synchronization cases are easy to realize with the help of the messaging service: • the application completes a transaction and sends a final message using the messaging service to the user (for example informing him about the payment, see Figure 3). • the user decides stop or abort the application, which first causes all the telecommunication services to finish, then sends a last message to the user. This message is used to trigger the nextKey() message. A summary of the privacy service methods is given in the Table 1.

Method logon subscribe accept refuse block nextKey translate

Parameters username, password username, operations username, operations username username, operations current pseudonym pseudonym

Privacy Agent A

B

privacyAgent

Application

TelcoService

translate(h1_A) user A

result invokeServ(h1_A)

= HMAC(rAB , pwA)

h2

= HMAC(h1 , pwA)

Privacy Service

6. result

A, B

h1

= HMAC(rAB , pwA)

h2

= HMAC(h 1, pwA)

… = HMAC(hn-1, pwA)

hn

= HMAC(h n-1, pwA)

Figure 4. The PRIVES scheme it checks its validity and determines from h(1), who the watcher and the target user are. Once the request is processed, the requesting user and the privacy service have already prepared the next hash value h(2) for the subsequent request and so on.

PrivacyService

h1_A invokeServ(h1_A)

3rd party application

h1

hn

getPseudonym(user)

startApplication(h1_A)

7. result



Table 1. Summary of privacy service methods

UserCLient

5. query(hn )

4. query(hn)

runService

translate(h1_A) user A

result invokeServ(h1_A)

3. Application Examples

runService

translate(h1_A) user A runService

result message getPseudonym(user) h2_A

nextKey(h1_A) calc(h2_A)

calc(h2_A)

continueApplication(h2_A)

Figure 3. Invocation of the application and underlying services

2.2. Pseudonym generation algorithm In this section we shortly introduce the privacy enhancement scheme PRIVES, that has been proposed in the context of Location Based Services in [11]. PRIVES is based on hash value calculation using the HMAC [13] scheme that makes it useful for small devices such as smart phones and PDAs. HMAC uses the known hash schemes MD5 [14] and SHA-1 [15] with comparable computation times. It allows to create a hash value from a previous one, using in addition the password as a shared secret between the privacy service and the watcher. In Figure 4, user A creates hash values to allow the application to query the profile of user B. The hash values are created in a synchronized way by the privacy agent of A and the privacy service from the previous hash value h(n1) and A’s password by applying the HMAC operator H(). The only information the user A needs is the anchor r(AB), which is initially created by the privacy service and is a function of the password, and a random number. When the privacy service receives from the application a localization request for the user identified by the hash value h(1),

In this section we give two service examples to illustrate the applicability of the system described above. In the Travel and Navigation Guide scenario, a car driver selects this service to get maps, traffic conditions and navigation assistance towards his destination. The user first logs on at the privacy service (run by the network operator), so that the client can create pseudonyms. In Figure 5 we show a simplified message flow diagram in which the user sends one request and the messaging service delivers the map and traffic conditions. A more useful function (not shown in the diagram) would be to notify the user (using the messaging service), each time the traffic conditions have changed. In the diagram we also suggest that the user can stop anytime the application, that in turn performs charging and sends a final acknowledgement message. The second example is the Friend Finder - a popular peer to peer service that notifies a user if one of her friends (buddies) is in her proximity. Useful for group collaboration, this service may also have many variations. Basically, the user client (A) subscribes first to her friends f1, f2, fn and receives the pseudonyms (h1A , h1f 1 , h1f 2 , ...h1f n ). She passes that information to the application which calls a location service to check the proximity of user A and of each of her friends. Again, the application can be based on a single query or on a monitoring mode for which the user specifies also a duration. This example illustrates the case in which the user requesting service protects with pseudonyms the identities of other users (the friends).

4. Concluding Remarks In this paper we address the problem of privacy of mobile users in the context of a modern, web service based service

UserCLient

privacyAgent

Application

[3]

LocationService PaymentService MessagingService PrivacyService

getPseudonym(user A) h1_A requestService(h1_A, destination)

reserveAmount(h1_A, amount) getLocation(h1_A)

translate(h1_A) translate(h1_A)

[4] T. Alam¨aki, M.Bj¨orksten, P. Dornbach, C. Gripenberg, N. Gyoerbio, G. Marton, Z. Nemeth, T. Skyttae: Privacy Enhancing Service Architectures, 2003, pp.99-109

getMap getTrafficConditions sendMessage(h1_A, map, trafficConditions)

translate(h1_A)

message(map, traffic conditions) stop (h1_A)

chargeReservation(h1_A)

[5] The Parlay Group, URL: http://www.parlay.org, accessed 2. Sept. 2004

translate(h1_A)

sendMessage(h1_A, end of service, charged amount)) message(end of service, charged amount) getPseudonym(user A) h2_A

translate(h1_A)

nextKey(h1_A) calc(h2_A)

Privacy and Identity Management for Europe (PRIME), WP14.2 Architecture Version 0, URL: http://www.prime project.eu.org/public/primeproducts/deliverables Oct. 2004

h2

[6] Harold Teunissen Jeroen Van Bemmel, Mario Hoffmann: Privacy and 4G services: Who do you trust?, 2004, Wireless World Research Forum (WWRF), WG3 contribution [7]

Web Services Description Language (WSDL), http://www.w3.org/TR/wsdl, accessed 2. Sept. 2004

URL:

[8]

The 3rd Generation Partnership Project (3GPP), http://www.3gpp.org, accessed 2. Sept. 2004

URL:

Figure 5. Travel guide application example architecture. We assume that the network operator hosting the new introduced privacy service can be trusted and that the communication channel between the user mobile terminal and the privacy service is secure. Furthermore, we assume that PKI methods do not perform well on mobiles, leading us to search for a lightweight solution for certain privacy problems. The presented architecture takes into account the existence of standardized interfaces between applications and telecom services (e.g Parlay X). The main contribution of this work is the introduction of the privacy service, a candidate for interface standardization. The presented examples show that privacy-enhanced and flexible applications can be designed using the privacy functionality. Users are referred to through transaction and session pseudonyms, making it impossible for the application to link the information the telecom services deliver (location, presence, contact address, message content, etc.) to the real user name or address. Further research is needed to investigate the impact of other security and privacy requirements on the privacy mechanisms described here.

5. Acknowledgement This work has been done at the Telecommunications Research Center Vienna (http://www.ftw.at) within the project ”Service Platforms beyond OSA”, and has been partially funded by the Austrian Kplus Program.

References [1]

ISO IS 15408, URL: http://www.commoncriteria.org, accessed 2. Sept. 2004.

[2]

PET in infrastructures, RAPID IST Project, URL: http://www.commoncriteria.org, accessed 2. Sept. 2004”

[9] J. Cuellar, John B. Morris Jr., D. Mulligan: Geopriv requirements, June, 2002, URL: http://www.ietf.org/proceedings/02nov /I-D/draft-ietfgeopriv-reqs-00.txt, accessed 2. Sept. 2004 [10] A Presence-based GEOPRIV Location Object Format, URL: http://www.ietf.org/internet-drafts/draft -ietf-geopriv-pidf-lo02.txt, accessed 2. Sept. 2004 [11] Oliver Jorns, Sandford Bessler: An efficient mechanism to ensure location privacy in telecom service applications, Proceedings of the Net-Con Conference, Palmas, Spain, November, 2004 [12] Christer Andersson, Simone Fischer-H¨ubner, Reine Lundin: Enabling anonymity for the mobile Internet using the mCrowds system FIP WG 9.2, 9.6, 11.7 Summer School on Risks and Challenges of the Network Society, 2004 [13] Mihir Bellare, Ran Canetti, Hugo Krawczyk: Message Authentication using Hash Functions - The HMAC Construction, CryptoBytes, 1, 1996, 2 [14] Hans Dobbertin: Cryptoanalysis of MD5 Compress, Announcement on Internet, May, 1996, URL: http://citeseer.ist.psu.edu/dobbertin 96cryptanalysis.html [15] National Institute of Standards and Technology: Secure Hash Standard, Federal Information Processing Standards (FIPS), 2002