Context-Based Privacy Protection forLocation-Based Mobile Services using Pseudonyms

Joachim Zeiss and Oliver JornsTelecommunications Reseach Center ViennaDonau-City Strasse 1, 1220 Vienna, Austria

Email: {zeiss, jorns}@ftw.at

Abstract—This paper discusses the combination of a niftypseudonym generation mechanism that is used to veil the realworld identity of users with semantic user context descriptionsand policy reasoning to express decisions of users and thusprotects their sensitive location information. The expected devel-opment of a new class of mobile applications is further fostered bythe underlying service architecture that makes use of the privacyprotection means and allows the implementation of the highlypostulated pay-as-you-go model. Means for privacy protectionare not only an ultimate requirement for the development ofsuccessful location-based services and applications. It furthermeans an incentive for network service operators to enrichlocation-based services by making available their localizationcapabilities to at the same time to open new sources of revenue.

I. INTRODUCTION

One strategy network operators face to hold against theconstantly growing market pressure is to provide interfacesto allow third party application services providers access topreviously hidden services such as location, messaging or pres-ence services. This strategy enables in the near future the de-velopment of large scale context-aware applications, the mostprevailing subset of this kind of applications is also known aslocation-based services and applications which is the matter inquestion in this paper. Regarding the high expectations in thelocation-based service market, efforts in standardizing opennetwork interfaces such as those undertaken by the ParlayGroup[2] group represent one step forward on the way topromote the use of network operators resources. Meanwhile,a variety of commercial tracking, navigation and localizationsolutions that provide users with location information of otherpersons or allow to retrieve information about the surroundingarea are available. Research in the field of location-basedservices and applications has made significant progress duringthe last years. In this regard over the time one question turnedout to be crucial for the success of location-based services,that is, how to protect the the users privacy.

With regard to privacy, recent cases in the US and Europethat unveiled the sloppy handling of personal data resulted notonly in an increased reluctance of customers to provide anyother information than that they are obliged to. Even worse,this tendency affects even other industrial and governmentsectors. Especially the mobile telephony industry and thus thedevelopment and distribution of mobile services.

Generally, there is an observable tendency that users aban-don the use of services that lead to the collection of larger

amounts of personal data. At the same time compliancerequirements on companies and government agencies aregrowing, resulting in a situation where they are caught inbetween the necessity to collect more and more data to fulfillthese requirements and an increasing reluctance of consumersand citizens to provide personal information. A very typicalrepresentative of the increasingly problematic situation is thelatest legislation which European mobile phone operators arecurrently confronted with. While it is highly desirable to bettersupport law enforcement agencies in their efforts to preventserious crime, the cost of the systems for businesses and thefears of consumers are steadily growing. It has in some casesreached a level at which consumers refuse new services outof fear the data possibly collected about them through theservices might be open to abuse. As an abundance of caseshas shown this fear is not unjustified. With a steady streamof serious blunders being reported in the media, it is obviousthat consumers and citizens are starting to distrust IT-basedproducts and services. An uneasy feeling that has previouslybeen limited to the Internet is now affecting RFID chips,mobile end user devices and navigation systems. The legalobligation to collect data and store it for a certain amount oftime is reinforcing the already negative attitude of consumersand citizens.

The rest of this paper is organized as follows. In the nextsection we give a brief overview of related work. We thendiscuss the core components of our system architecture whichis followed by an explanation about our pseudonym generationmechanism. The next section illustrates the interplay of thecomponents and discusses in particular how semantic webtechnology can be utilized to automatically update policyfiles and generate semantic descriptions of machine readableprivacy policies which at the same time represents the corecontribution of this paper. Finally, we wrap up with someconclusions.

II. RELATED WORK

Research on privacy for location-based services has ledto numerous solutions that aim to protect the users privacy.In this section we give a short overview about some novelexisting technical solutions. They all aim at providing theusers location information private. Many of them focus onthe location data and try to enhance user privacy by makinglocation information anonymous or by location cloaking which

81

is based on the concept of k-anonymity which means that ina certain time interval at least k users are within a certainrectangular area. A user is k-anonymous if his location cannotbe distinguished from the location of the k-1 users [4].

Other solutions are based on the notion of pseudonyms [9].Users who are in charge of randomly generated pseudonymsmay control which 3rd party application provider has access totheir location information. Therefore, users store their locationinformation together with a time stamp and an associatedpseudonym at a location server. Service providers that do notknow the actual pseudonym are not able to access locationinformation. Each user is in charge of who may access locationinformation by simply changing the respective pseudonyms.

The use of pseudonyms used to veil the users identity inlocation-based services and applications raises further ques-tions concerning the design and operation of such systems.Concerning the distinction between online identities that arerepresented as pseudonyms and offline identities that arereal world identities discussed by Acquisti [1] lead to theconclusion that pseudonyms should be used in favour of realworld identities.

However, simply replacing the real world identity by apseudonym is not enough. In other words, the use of staticpseudonyms does not provide sufficient privacy protectionand suggests the use of changing pseudonyms [3]. Thus,we make use of a novel pseudonym generation mechanismthat overcomes these deficiencies and generates a new uniquepseudonym for each request [7].

Gruteser et al. [6] focus on the definition, distribution andenforcement of privacy policies. However, privacy solutionsthat are based on privacy-policies presume that users trusttheir carrier to a certain degree [8]. In the same regard it isdifficult for users to control the adherence to privacy rules andpolicies. Their proposed solution uses anonymisation in thesense that instead of global positions only relative distancesbetween users are used. By dint of shared keys members ofcommunities shall be able to change their location informationthrough distance-retentive transformations of coordinates.

Another proposal defines a message format that allowstransport of authorisation policy rules to support differentlocation data transformations so that it is possible to adjustthe resolution of location information and make authorisationdecisions that are based on the current location [10]. As anexample, the presence of a certain user located in a specificarea or when the altitude is within a certain range.

Finally, the use of semantic web based policy frameworksand languages as discussed in [12], [13], [14] allow thedeclaration of facts about context data and also user profiles.For that descriptive logics and logic programming is used forthe definition of machine readable policies. These policies areexpressed under the same paradigm as human readable policiesand opens new possibilities for system designers to provideusers means to express and enforce their wishes with regardto control and protection of their privacy.

III. SYSTEM ARCHITECTURE

In this section we discuss the system architectures com-ponents as they are depicted in figure 2 and figure 1. Itconsists of four building blocks that are the user agent, the3rd party service provider, a context service and a locationservice. The semantic reasoning part, which represents thecore component of the system further explains how privacydecisions are generated.

A. Client

The client implements amongst other components a socalled privacy agent which is the client side implementationof the corresponding server side agent that is implementedby the context service. These modules are responsible for thegeneration and the administration of pseudonyms. We givea detailed description about how the pseudonym generationscheme works in the following subsection.

Depending on the respective application requested by theuser it is conceivable that the needed components are down-loaded on demand. Thus, the client side implementation pro-vides basically only a small set of some core components thatare necessary to meet some basic requirements such as theobligatory communication and presentation capabilities as wellas some basic logic.

B. Service Provider

The 3rd party service provider is considered to be untrustedper se. Thus, it receives requests from users that only containpseudonyms which cannot be used to unveil any real worldidentity, neither that of the requester nor of the requestee.Similar to the context service, the service provider may alsoprovide the functionality of combining context retrieval andstorage functionality with semantic web reasoning technolo-gies. The information that is necessary for that is received fromthe context service only. In the ideal case it thus operates onlyon anonymous data. The use of pseudonyms and appropriatesimple interfaces for service requests avoid the necessity toregister for service usage and thus allow the realization of theso called pay-as-you-go concept.

C. Context Service

The context service mainly generates and administers policyfiles of users. Amongst the user preferences each such policyfile further contains user preferences such as the respectivetrust level. Each policy file is archived under the current userpseudonym since for each request the pseudonym changes,also the relation between the pseudonyms and the policy filesare maintained by the context service.

D. Location Service

The location service is not necessarily part of the untrusteddomain. Usually, network service providers offer this serviceto service providers for the realization of different location-based applications. The quality of such services depends onthe accuracy of the received location information. Whereasin rural areas the accuracy is low, it is for most applications

82

ctx prof 

Decision Space: Complete set of N3 defini5ons 

Context and Profile instances, Privacy rules   

key file App

 B 

key file App

 A 

No5

fica5

on rules 

and instances 

Context u

pdate rules 

Context retriever 

priv rule 

priv rule 

priv rule 

prof 

ctx 

prof 

ctx 

prof 

ctx 

Requ

est h

andler 

Fig. 1. Semantic Decision System Layout

sufficiently high. Whereas other localization technologies suchas the popular global positioning system (GPS) provide veryhigh accuracy in rural areas it may decrease in some urbanareas and is not available indoor.

E. Semantic Reasoning

A core component of the system is the semantic webtechnology based decision space (see figure 1). It is used notonly for making privacy decisions and filtering of contextdata to guarantee privacy, but also to support context dataupdate and notification mechanisms. The technical backgroundis based on N3 (Notation3, see [15]) a semantic web definitionlanguage and Euler a backward reasoning engine for N3(see [16]). This decision space is represented by the PrivacyProtection Reasoner component explained in section V-C.Each request towards the decision system is handled by theEuler reasoner. The reasoning process operates on the entiredata in the decision space and the data given in each respectiverequest. Therefore, the information in the request is expressedin N3 as well.

When the request handler deals with a subscription forlocation info it uses the received pseudonyms to query thedecision space.. We distinguish two kinds of pseudonyms.One kind expresses a particular watcher-presentity relation-ship. It is generated by the requesters terminal and denotesthere one particular buddy. Users can select one or morebuddies and thus send one or more pseudonyms respectively.The second kind relates to the applications pseudonym. Thiskind of pseudonyms is generated by the serving application

and is exclusively used by the application for identificationpurposes. Technically both kinds of pseudonyms are equal.The pseudonym generation scheme is discussed in detail insection IV. The response will determine if subscription isallowed and to what detail context data can be forwarded to thewatcher. Based on this information the request handler createsa watcher session and adds the rules necessary for notificationdecisions to the decision space.

The application pseudonym is used to determine the filewhere to look for the key into the related context informationrecord. Such key definitions link peudonyms with contextinstances and would look like:

:c1 :pseu "4gmjl894fgb328g6nmk0d2sd5436hn8523s1dfh8".:c2 :pseu "fghmjk89sb6l132sc54jnmfggo80tbmhk4532sdg".

Where :c1 and :c2 would be context and profile instancesfor the pseudonyms 4gm... and fgh.... As can be seenin figure 1, for application ftw.at this information would bestored in key file for application ftw.at in the decision space.After the request, file names and pseudonym text strings insidethe file are to be changed and represent the pseudonym valuesfor the next request.

Session definitions and rules for notifications look like::s1 :id 0001.:s1 :pseu "4gmjl894fgb328g6nmk0d2sd5436hn8523s1dfh8".:s1 :callback "http://www.ftw.at:8080/track_me.wsdl".:s1 :data :LocEntry.

{?s :data ?t. ?s :pseu ?hmac. ?s :callback ?addr.?c :pseu ?hmac. ?c :prop ?var. ?var a ?t}=>

{:notify :addr ?addr}

Where the predicate :pseu ties the session instance to the

83

pseudonym of the subscription request. The :callbackpredicate tells whom to call if the context has changed andthe :data predicate indicates what piece of context shouldbe sent. These data are stored in the Notification rules andinstances file in figure 1.

If new sensor or location data is reported to the contextretriever it will act according to the rules in file Context updaterules that is depicted in figure 1. These rules determine whichcontext and profile data instances need to be updated withthe actual information. A small context instance looks like thefollowing:

:c1 a :UserContext.:c1 :prop "ftw.at".:c1 :prop :l1.

:l1 a :LocEntry.:l1 :loc_lon 16.418492.:l1 :loc_lat 48.233322.:l1 :loc_sym "Vienna".

Where :c1, as described above, represents the reference tothe pseudonym. The :prop predicate may occur more thanonce holding different kinds of data types containing thecontext info. The predicate :l1 here represents a complexdata type that stores the location information. Furthermore, the:l1 location instance is defined as being a :LocEntry. Byadding this type-information to the session data, the contextretriever knows that this information needs to be send to the:callback address in the session data. Before forwardingthis info, privacy rules apply to filter, manipulate or augmentthe information to be transported to the watcher.

IV. PSEUDONYMS

In this section we describe how pseudonyms that veil thereal world identity are generated and used in our system. Forour system we distinguish two different kinds of pseudonyms.One identifies only the requester. We call this type self-identifying pseudonyms. The second type denotes on theone hand the identities of both, the requester and a certainrequestee that is one buddy of the requester and, as will bediscussed later, on the other hand the relation between them.Technically, both kinds of pseudonyms are equal.

Regarding Beresford (2005) concluding that staticpseudonyms do not provide sufficient privacy protection,our pseudonyms are generated according to a scheme thatgenerates a new pseudonym for each request and which isdiscussed in the following.

A. The Pseudonym Generation Scheme

The pseudonym generation scheme [7] discussed in thissection is used as basis for the authentication mechansim.The scheme uses HMAC (keyed-Hash Message AuthenticationCode) [19] as the underlying cryptographic function. Thisfunction requires two parameters. One parameter is the inputvalue whereas the second parameter is a secret key K sharedbetween two communication parties, which are in our case thelogic module and a user. In general, every emergency accesspseudonym ηUi

, which is unique for each participant, is theresult of an earlier cryptographic calculation that is based on

its respective successor pseudonym ηUi−1 . The only exceptionis the calculation of the initial pseudonym ηU1 . This uses arandom number or a random string r as input value, which maybe exchanged even in clear text between the communicationparties, because the key K is not disclosed.

As depicted in equation (1), we denote the HMAC crypto-graphic function as hK . This function allows the initializationof the first value ηU1 = hK(r) of the transaction pseudonymchain by firstly applying a random number or random stringr as the argument.

ηUi := hiK(r) = hK(hi−1

K (r)), i = 1, 2... (1)

Menezes et al. [21] define the the following general require-ments for the security of hash functions:• Pre-image Resistance: given a secure hash function

h(x) = y it is impossible to find x for the given hashvalue y.

• Second Pre-image Resistance: it is computationally im-possible to find two different values x1, x2 such thath(x1) = h(x2).

• Collision Resistance: it is computationally infeasible tofind a pair x1 and x2 such that h(x1) = h(x2).

As stated in the position paper [5] the security of HMAC re-lies on the security of the respective underlying hash function.Given a hash function η = hK(r), an attacker would be ableto calculate the output η without knowledge of the secret keyby either finding a collision of the underlying hash functionor by finding the output of the compression function with arandom and secret initial value. Attacks like these are currentlynot accomplishable even with the use of SHA-2. Furthermoreat this time, known collisions of other hash functions do notshow any significant implications on the security of the HMACscheme, which allows the assumption that the HMAC can beconsidered as secure [5], [19].

V. SERVICE OPERATIONS

This service combines context retrieval and storage func-tionality with semantic web reasoning and logic programming.On top of those two functionalities a context request handlercoordinates the queries towards the context service.

Privacy polices are enforced by means of semantic reason-ing. These policies produce an intersection of requesters andrequestees context profiles based on the current request. Thecontext service returns this intersection as result of the query.The set can be empty, contain all stored data or anything in-between depending on the respective privacy policy rules.

The mechanism of matching context data for a bilateralrelationship follows a concept that has been described fora client server relationship under [20]. The architecture ofcombining a context data base with a semantic reasoner hasbeen described under [22] for privacy protection of personalnetworks and under [23] for privacy protection of presencedata.

In the following sub-sectionswe continue with a detaileddescription of the above mentioned components of the contextservice:

84

User 's Privacy Agent

Buddy list: User B‘s pseudonyms

h1 = HMAC (anchorB, pwA) h2 = HMAC (h1, pwA) … hn = HMAC (hn-1, pwA)

Pseudonyms of user A subscribed to B

h1 = HMAC (anchorB, pwA) h2 = HMAC (h1, pwA) … hn = HMAC (hn-1, pwA)

3rd Party Service Provider

Request Handler

service request (pseudonym hu, hv ,...) pseudonym(s)

request context profiles with pseudonyms hu and hv

extract (anonym) identificators

Context Retriever

subscribe location update(s) for identificator(s)

location(s) update

context and profile data

retrieve context and profile data from pseudonyms

reasoner creates context description context update notification(s)

context reasoning in applications context

Context Database

store Context/Location updates

Privacy Protection Reasoner

context and profile data

generate new pseudonyms

pseudonym(s) retrieve context profile from pseudonyms

context and profile data context and profile data

update pseudonyms

Context Service

Fig. 2. System Architecture and Interworking

A. Request Handler

This component handles context and profile data retrieval,semantic reasoning and communication with context sourcessuch as the location service.

To trigger context retrieval, the request handler receivesrequests that contain either one or more self-identifyingpseudonyms or pseudonyms that denote buddies of the re-quester (see figure 2). If needed the request handler nowsubscribes for updates by the context data sources such asthe location service. These updates are stored in the contextdatabase to be obtained by the context retriever when forward-ing context updates.

Each time a context data change has been reported bythe context data sources the context retriever (see V-B: Con-text Retriever) is called to obtain all data sets containingcontext and profile data stored for the relationships denotedby the pseudonyms. These data are now handed over tothe privacy protection peasoner (see V-C: Privacy ProtectionReasoner). It produces the content to be send in the context

update notification for the given relationships defined by thepseudonyms. After each such update new pseudonyms aregenerated according to the previously discussed pseudonymgeneration mechanism and reported to the context retrieverwhich then updates the database accordingly.

B. Context Retriever

The context retriever receives calls from the request handler(see V-A Request Handler). Each call contains of a set ofpseudonyms whereby each basically represents the relationshipof a requester and a requestee. Therefore, the pseudonymsare used as the primary keys to obtain the complete data setsof both, the requester and requestee, from the database. Thisdatabase can be a plain set of files or a relational databaseserver which stores semantically tagged data as strings. A dataset for each user contains context data updated by the contextsources, profile data and a set of rules for privacy protection.

The context retriever scans the privacy rules for referencesto other users data stored in the database. It returns the data

85

set of those users as well. The privacy protection reasoner willneed them later on to execute the formulae of the privacy ruledefinitions.

If it receives a pseudonym update the context retrieverchanges the primary key of the related users data set.

C. Privacy Protection ReasonerThe request handler calls the privacy protection reasoner

with the data obtained by the context retriever. It is called toproduce a context update response based on a set of seman-tically enriched context data and privacy rules. Genericallyspoken, it calculates the intersection of requesters and reques-tees context profiles based on privacy rules. This intersectionis depicted in figure 2 as transparent document as a resultof the indicated profile update. These rules are defined in asemantic way as logic terms. The intersection of data is theresult of applying these terms on the context profile data ofboth involved parties. This data set is returned to the requesthandler.

Context data and privacy policies are expected to be definedin N3 (Notation3) a semantic web description language (see[15]). N3 has a simple human readable syntax as opposed toRDF [17] or OWL [18] which have a complex XML basedstructure. N3 is capable of mapping OWL and RDF definitions.

Rule definition itself is done by means of logic pro-gramming. Defining goals as logical implications using Hornclauses can be combined with interpreting semantic facts inlanguages such as Notation3 [15]. These rules are instantiatedas N3 formulae. One formula can be built on top of others.Implications of clauses can be combined to define morecomplex rules. Different categories of rules and policies canbe identified for processing a request.

To declare policies, Toninelli et al. [11] suggest a combi-nation of description logic and logic programming. The latterallows specifications of policies based on context variableswhose value is unknown at policy definition time. Our ap-proach using N3 rules [15], is capable of both: it enablescontext/policy classification, comparison, static conflict detec-tion and it uses context variables with values only available atruntime.

VI. CONCLUSION

In this paper we show how the combination of pseudonymsthat veil the real world identity of users with semantic usercontext descriptions and policy reasoning can be used toprotect the location information of users. Furthermore, whilethe use of pseudonyms allows the secure transmission ofrequests and the expression of user relations, the application ofsemantic technology allows the definition of rules that includecontext information. This information is processed on behalf ofthe user through inference of context and profile information.The most valuable benefit of such a policy engine is that newcontext data and rules are generated even without the need ofthe user.

Concerning the service architecture an important aspect isthat even if all the involved parties such as the 3rd party ap-plication service provider, the context service and the location

service are not part of a trusted domain, the combined useof pseudonyms with the reasoning capabilities of the contextservice and the service providers guarantee total anonymityof the users. In other words this means, the less trusted thewhole system is, the more the applied privacy mechanismsmake sense and, the more privacy can be provided at all. Inthis spirit, even if all the system components are untrusted,the system as a whole is still trustworthy.

As soon as one party such as the location service has tobe considered as being trustworthy the protection of the usersprivacy becomes more difficult. The reason for that is thatif the location service requires some additional informationsuch as the MSISDN (Mobile Subscriber International ISDNNumber) to query the location of the terminal, this can befurther used for the identification of the owner of the terminal.

In this case either the context service needs know theMSISDN of every user to request locations from users or thelocation service provides some function that allows a mappingfrom an anonymous identifier, that is used by the contextservice, to the respective MSISDN. If the location service doesnot provide such a mapping function, it can be easy for anattacker to retrieve the location information of all MSISDNsstored in the context service.

While the service architecture, pseudonyms and the policyengine are implemented and the operation is verified, thequestion is now how users shall define such policies. Thisis one point we want to investigate in our future work, alsoin order to be able to verify our findings for representativeapplications.

REFERENCES

[1] A. Acquisti, Privacy and Security of Personal Information - EconomicIncen- tives and Technological Solutions, In Camp, J.L., Lewis, S., eds.:Economics of Information Security, Kleuwer, 2004

[2] The Parlay Group, The Parlay X 2.0 Specification, URL:http://www.parlay.org/en/specifications/, 2008

[3] A.R. Beresford, Location Privacy in Ubiquitous Computing, TechnicalReport 612, University of Cambridge, 2005

[4] R. Cheng and Y. Zhang and E. Bertino and S. Prabhakar, PreservingUser Location Privacy in Mobile Data Management Infrastructures, In6th Workshop on Privacy Enhancing Technologies (PET06), Cambridge,UK, 2006

[5] Network of Excellence in Cryptology, Recent collision attacks on hashfunctions In ECRYPT Position Paper, 2005

[6] M. Gruteser and D. Grunwald, Anonymous Usage of Location-BasedServices Through Spatial and Temporal Cloaking, in Proc. of The FirstACM/USENIX International Conference on Mobile Systems, Applica-tions, and Services (MobiSys), San Francisco, USA, pp. 31–42, 2003

[7] O. Jorns and O. Jung and G. Quirchmayr, Transaction Pseudonyms inMobile Environments, In Journal in Computer Virology, Springer Paris,2007

[8] G. Treu and A. Kpper, Datenschutzmechanismen fur Ortsinformationenaus der Sicher zukunftiger Anwendungen, Tagungsband des zweitenGI/ITG KuVS Fachgesprachs ber Ortsbezogene Anwendungen und Dien-ste, Informatikbericht 324, pages 66-71, Fernuniversitat Hagen, Stuttgart,Germany, June, 2005

[9] T. Rodden and A. Friday and H. Muller and A. Dix, A LeightweightApproach to Managing Privacy in Location-Based Services, TechnicalReport Equator-02-058, University of Nottingham and Lancaster Univer-sity and University of Bristol, 2002

[10] H. Schulzrinne and H. Tschofenig and J. Morris and J. Cuellar andJ. Polk, A Document Format for Expressing Privacy Preferences forLocation Information, Internet Draft, draft-ietf-geopriv-policy08, 2006

86

[11] A.Toninelli, R. Montanari, L. Kagal, O. Lassila, A Semantic Context-Aware Access Control Framework for secure Collaborations in PervasiveComputing Environments, Proceedings of ISWC 2006, I. Cruz. et al.(Eds), LNCS 4273, 2006

[12] R. Masuoka et. al., Policy-based Access Control for Task ComputingUsing Rei, Proceedings of the Policy Management for the Web Workshop,page 37-43, W3C, WWW 2005, 2005

[13] L. Kagal and T. Berners-Lee and D. Connolly and D. Weitzner, UsingSemantic Web Technologies for Policy Management on the Web, 21stNational Conference on Artificial Intelligence, AAAI, 2006

[14] L. Kagal and T. Berners-Lee and D. Connolly and D. Weitzner, Self-describing Delegation Networks for the Web, IEEE Workshop on Policyfor Distributed Systems and Networks, IEEE Policy, 2006 wap/doc/

[15] Tim Berners-Lee, Notation 3 Logic,http://www.w3.org/DesignIssues/N3Logic, 2005

[16] Jos De Roo, Euler Proof Mechanism http://www.agfa.com/w3c/euler/[17] W3C, Resource Description Framework (RDF),

http://www.w3.org/RDF/[18] W3C, OWL Web Ontology Language, http://www.w3.org/TR/owl-

features/[19] National Institute of Standards and Technology. Secure Hash Standard

(SHS), In Federal Information Processing Standards Publication 180-2,2002

[20] S. Bessler and J Zeiss, Semantic Modelling of policies for context awareservices, 17th Wireless World Research Forum, Heidelberg, November,2006

[21] A.J. Menezes and P.C. Van Oorschot and S.A. Vanstone, The Handbookof Applied Cryptography, CRC Press series on discrete mathematics andits applications, CRC Press, 2000 N.W. Corporate Blvd., Boca Raton, FL33431-9868, 1997

[22] J. Zeiss, L. Sanchez and S. Bessler, Policy driven formation of fed-erations between personal networks, 16th IST Mobile and WirelessCommunications Summit, Budapest, July, 2007

[23] S. Bessler and J Zeiss, Using Semantic Policies to reason overAvailability, Personalized Networks (n conjunction with the 4th AnnualInternational Conference on Mobile and Ubiquitous Systems: Networksand Services), Philadelphia, June, 2007

87