Food & Beverages

A Privacy Enhancement Mechanism for Location Based Service Architectures Using Transaction Pseudonyms

Description
A Privacy Enhancement Mechanism for Location Based Service Architectures Using Transaction Pseudonyms
Published
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  A Privacy Enhancement Mechanism forLocation Based Service Architectures usingTransaction Pseudonyms Oliver Jorns, Oliver Jung, Julia Gross, and Sandford Bessler Telecommunications Research Center Vienna (ftw.),Donau-City-Strasse 1, 1220 Vienna, Austria { jorns, jung, gross, bessler } @ftw.at ,WWW home page:  http://www.ftw.at Abstract.  Third party service providers are starting to use advanced lo-cation services based on area or periodical notification in order to developinnovative applications. However, such functions can be easily misusedfor tracking users and building their activity profiles, if privacy enhance-ment mechanisms are not integrated into the service architecture. In thispaper we present a protocol based on transaction pseudonyms that pro-tects the user’s address from being disclosed and associated with theirlocation. Based on hash chains, the pseudonymsare used to authorize ser-vice and the localization requests, making possible ad hoc service usagewithout registration. We further analyze security aspects of the proposedprotocol. 1 Introduction Increasingly, applications for mobile users take advantage of user personalizeddata, such as online status (presence), location, contact address, user preferences,etc. These applications are only the beginning of a new class of context-awareser-vices which will ”know” how, where and when to contact the user without theirexplicit intervention. Such applications raise however serious privacy concerns,especially in cases where the trustworthiness of   Application Providers   cannot bethoroughly investigated prior the service invocation.The scenarios that motivated this work were related to Location Based Ser-vices, although other privacy information, such as presence, user addresses forreceiving messages or phone calls turned out to be equally important and pri-vacy sensitive. In the rest of the paper we assume that location information canbe provided to the application by the Network Operator. Therefore, the applica-tion provides advanced notification functions which allows automatic recurrentnotifications or asynchronous callbacks when the user enters or leaves a certainarea. The main contributions of this work are to develop a protocol that allows: This work was supported by the Austrian K plus   program.  II 3rd Party Application Provider    P  a  r   l  a  y   X   A   P   I ClientUser ProfilePrivacyAgentApplicationLocationServiceMessagingServicePaymentServicePrivacyService ... OSA ParlayNetwork LayerNetwork Operatorregistration,subscription,presencelocation SOAP/XML-RPC/HTTP Terminal    P   R   I   V   E   S   A   P   I   P   R   I   V   E   S   A   P   I   P  a  r   l  a  y   X      A   P   I Fig.1.  System Architecture –  a user to transfer to an application a request under a pseudonym that ispassed from the application to the network and is recognized by the latter –  the application logic (workflow) to call different Network Services using itsown and the user’s pseudonym –  the Network Services (e.g location, messaging) to authorize requests fromthe application based on the contained pseudonyms –  a user to invoke a service without prior registration (and event to pay for itvia the network user account) –  certain protection against security attacksThe remainder of the paper is organized as follows: in section 2 we give ageneral description of the system architecture, its components and the interfacesbetween them. We go on with a detailed description of the service protocol inter-actions in section 3 and analyze the security of the protocol and its underlyingmechanisms in section 4. In section 5 we conclude with further research topics. 2 System Architecture As stated in the previous section, the privacy enhancing architecture invokesthree actors: the (third party) Application Provider, the Network Operator andthe User (terminal), see Fig. 1. The architecture makes use of Parlay X Web Ser-vice interfaces, specified recently by the OSA/Parlay Group [1], which promiseto open the Network Services for Third Party Application Providers. Amongthese SOAP [2] APIs, there are location, presence, payment, call control, andmessaging interfaces [1]. All these interfaces use an  EndUserIdentifier to iden-tify a certain user for a location request or for sending an SMS message. Cur-rently, the Network Operator has to check the authorization to perform eachrequested operation. The check could also be part of the new  Privacy Service  .Similar to the  Identity Broker   entity in [3] which translates identity attributesinto pseudonyms, a  Privacy Agent   generates pseudonyms on the basis of at-tributes that are stored in the  User Profile   database. The Privacy Agent in the  III 5.b. calculationof firstpseudonymp 1 = HMAC(watcher_secret, anchor) PrivacyService 3. generation of anchor5.a. calculation of first pseudonymp 1 = HMAC(watcher_secret, anchor)7. check validity of pseudonyms:received p 1 = stored p 1 8.a. calculationof nextpseudonym:p 2 = HMAC(watcher_secret, p 1 )… watcher 1. subscriptionrequest Telecom Server presentity 2. subscriptionaccept4. anchor6. servicecallwithp 1 8.b. calculationof nextpseudonymp 2 = HMAC(watcher_secret, p 1 )…9. servicecallwithp 2 terminal terminal 1.1.subscriptionrequest Fig.2.  Transaction Pseudonym Initialisation user terminal and its counterpart, the Privacy Service, exchange at the begin-ning secret information allowing the Privacy Service to authorize requests andtranslate the pseudonyms back to the public user addresses without disclosureto the application.In the protocol analysis presented in the next section, we use the roles of  watcher   and  presentity  , which are derived from the presence terminology andwhich denote the user that localises and the localised user, respectively. In mostapplications in which a user seeks location privacy, both roles are contained inthe same terminal. 3 Service Protocol Interactions This section describes messages exchanged between services used in this archi-tecture. First, we describe the interactions that allow a user to contact anotheruser and in this context apply for authorisation of subsequent location requestsby applications. In the same way, we describe the subscription process of ap-plications. Then, we go into deails of services that receive location informationfrom the Location Service at regular intervals. 3.1 User Subscription Phase The general model is based on the subscription of a user to private informationof themself or other users. The subscription interaction has a two-fold objective:first, to initialize a pseudonym exchange phase between two entities (betweenuser’s Privacy Agent and Network Operator’s Privacy Service or between anapplication and Privacy Service) and second, to request the authorization fromthe presentity for subsequent private information (location) delivery. 3.2 Service Initialisation As the presentity receives and accepts a  subscription request   from the watcher(Message 1 - 2 in Figure 2), the Privacy Service generates a random number  r  wesubsequently call  anchor   (Step 3). Each anchor is the arithmetical basis for all Presentity Transaction Pseudonym   (PTP) calculations regarding one particular  IV Application store correlator,calculate ATP 1 watcher start PeriodicNotificationwith: command watcher || PTP 1 || correlator Application Server correlatorand „message“per SMS, MMS ornetwork terminal start PeriodicNotification LocationServicePrivacyService Telecom Server presentityMSISDNlocalisationof MSISDN(correlator, lat, long)   process location data -> filter conditonfulfilled MessagingService messagingrequestaccesssessionATP …Application Transaction PseudonymPTP ... Presentity Transaction Pseudonymcalculate ATP 2 check: ATP,correlator,PTPs,store: sessionaccess sessionwatcherMSISDNstoresession under correlatorstoresessiongeneratemessageaccesssessionmessage: ATP 2 || “messagetext“|| command app || correlator|| appsig 2 ATP 1 || command watcher || PTP 1 || correlator|| appsig 1 Fig.3.  Periodic Notification Service Interactions presentity. The first PTP is calculated on the basis of this anchor and the secretshared with the watcher:  PTP  1  =  h kwatcher ( r ) (Step 5.1). Each  PTP  1 ...PTP  n is associated with just one particular presentity. Next, the user’s Privacy Agentreceives the anchor from the Privacy Service and thereupon also computes  PTP  1 (Message 4, Step 5.b). It therefore applies the same calculation as the PrivacyService with the result that both the user’s Privacy Agent and the PrivacyService share the same PTP to address one particular presentity. Since each ap-plication needs to exchange pseudonyms with the Privacy Service as well andprovided that business contracts between the application Provider and the Net-work Operator already exist, the exchange of the anchor and the shared key canalso be done offline and in advance to the first serivce invocation. However, fromthe cryptographic point of view the  Application Transaction Pseudonym   (ATP)is calculated in the same way as PTPs, starting with the initial  ATP  1  =  h kapp ( r )with anchor  r  and the shared secret  k app . 3.3 Service Invocations In order to initiate a service request (e.g. the periodic notification service), theclient first generates a  transport message   (e.g. SOAP or XML-RPC) which con-tains the command (in this case  startPeriodicNotification(.) ). Further,this message includes PTPs of each presentity the periodic notification processshall be started for. Additionally, each message appends a signature we denote correlator  . The client uses the signature as a session identifier which allows himlater to controll and terminate active localisation processes. As the applicationreceives the transport message from the watcher, it uses the appended signaturecorrelator as session identifier and computes the next ATP. The newly gener-ated ATP is appended to the client’s transport message and again signed for dataintegrity reasons. This extended transport message is then forwarded to the re-spective Location Service. Upon receipt, the Location Service first contacts thePrivacy Service which checks the validity of the ATP signature. Next, given  V all pseudonyms are valid, that is all PTPs are found in the Privacy Service’sdatabase, it queries the respective watcher’s password to recalculate and verifythe correlator and hence prove the integrity of the transport message. After thePrivacy Service translated each PTP, the corresponding MSISDNs are sent backto the Location Service which may now start localisations on a continuing basis.Each time the location of one or more presentities changes, the Location Servicesends a notification message back to the application. Eventually, the presentitieslocations fulfil the watchers predefined trigger conditions. Thereupon, the user isnotified either via a SOAP message or SMS. If for whatever reason the watcherdecides to stop an active periodic notification process ahead of time, the PrivacyAgent computes all required PTP for each presentity. In order to stop distinc-tive periodic localisations of presentities, the client may also select a subset of those presentities for which a localisation process is active. Until localisationsof all presenties are terminated all information that is stored in the context of a correlator i.e. starting with the Privacy Service or the Location Service, theapplication and the user’s client delete all relevant data such as correlators. 3.4 Single Location Requests If a watcher wants to know the actual position of one or more presentities, shesends a location request for one particular presentity. In contrast to periodic lo-cation notifications, single localisation requests do not require additional sessionmanagement activities. Neither does the client need to generate a correlator,nor is any session information to be administered throughout the system. Be-side single location requests which may include only one particular presentitiy,a watcher may also ask for the position of several presentities at the same time.A watcher may ask for the position of one or more presentities even if he hasalready started a periodic notification process for at least one presentity re-spectively up to all presentities involved in a periodic localisation process. Sincefrom a watcher’s point of view each PTP denotes exactly one presentity, differentkinds of localisations may be performed by several watchers at the same timewithout interference even if they address the same presentities. 3.5 Interlinked Application Services Each application service call requires the watcher to provide exactly one PTPfor each presentity. Since PTPs can be used only once, this prevents applica-tions from calling several services consecutively with the same PTP. However,applications that provide periodic notifications need to call different services,possibly multiple times. Hence, each subsequent application’s service call pro-vides the correlator and an ATP which is computed the same way as PTPs, thatis, by applying the HMAC function. Before transmission, the application gener-ates a message signature. For this purpose, it concatenates the command (e.g. sendMessage(.) ), the actual ATP, the  correlator  as well as the whole user’stransport message. The secret shared between the application and the PrivacyService is the key for the HMAC function. Thereupon, the Privacy Service can
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks