DOTTORATO DI RICERCA IN I XX CICLO SETTORE...

DOTTORATO DI RICERCA IN INFORMATICAXX CICLO

SETTORE SCIENTIFICO DISCIPLINARE INF/01 INFORMATICA

Privacy and Security in Distributed andPervasive Systems

Tesi di Dottorato di Ricerca di:

Claudio Agostino Ardagna

Relatore:Prof. Pierangela Samarati

Correlatori:Prof. Marco CremoniniProf. S. De Capitani di Vimercati

Coordinatore del Dottorato:Prof. Vincenzo Piuri

Anno Accademico 2006/07

A chi mi ha sempre sostenuto

Abstract

Technical improvements of Web and location technologies have fostered the developmentof online applications that use private information of users to offer enhanced services. Asa consequence, the vast amount of personal information thus available on the Web hasled to growing concerns about privacy of its users. Today global networked infrastruc-ture requires the ability for parties to communicate in a secure environment while at thesame time preserving their privacy. Support for digital identities and definition of privacy-enhanced protocols and techniques for their management and exchange become then fun-damental requirements. A number of useful privacy enhancing technologies (PETs) havebeen developed for dealing with privacy issues and previous works on privacy protectionhave focused on a wide variety of topics. Among them, for helping users in maintainingcontrol over their personal information, access control solutions have been enriched withthe ability of supporting privacy requirements, by regulating access to and release of userspersonal information. Despite the benefits of such solutions few proposals have addressedthe problem of how to regulate use of personal information in secondary applications.Moreover, this large number of solutions is causing some confusion and seems increasingthe effort for developers to build online services.

In this thesis, the notions of privacy and access control are fully integrated within acommon framework, and a privacy-aware access control system supporting digital identi-ties, anonymous interactions, and fine-grained context information is defined together withan evaluation infrastructure. The defined models and languages, which provide authoriza-tions based on digital certificates, include support for obligations constraints and datahandling policies that regulate secondary use and dissemination of private informationexchanged among parties.

The proposed privacy-aware access control system is however of little values if locationprivacy is not protected. Location information in fact has achieved a level of accuracy thatmakes straightforward its adoption within an access control system to define restrictionsbased on physical position of users. By contrast, location information can cause loss ofprivacy on users whereabouts and can easily permit to re-identify the users by looking atinformation, such as the place in which users stay during the night. Special attention isthen devoted to protection of location information with respect to privacy threats that canhappen in today pervasive environment, where location information of users is available to

vi

external parties without restrictions. A further complicating factor is that while protectinglocation privacy, the quality of service of location-based applications plays an importantrole and should be preserved. In this thesis, we propose an obfuscation-based solutionto location privacy protection that balances the need of privacy of users and the need oflocation information accuracy of location-based services. This solution is then validated inthe context of our location-based access control (LBAC) system, which is responsible forthe evaluation and management of an innovative access control language supporting a newclass of location-aware conditions. This approach coupled with the privacy-aware accesscontrol system guarantees flexible and reliable access control evaluation and enforcementwhile protecting the privacy of the users.

In summary, the contribution of this thesis is twofold: first we develop a privacy-awareaccess control system for Web transactions; then we propose a LBAC system and a loca-tion privacy solution to be validated in the context of such a system. With respect to thedevelopment of a privacy-aware access control system, the original results are: the defi-nition of an access control model, composed of attribute-based access control and releasepolicies, which on the one side regulates access to service provider resources, and on theother side manages release of user data. Our model supports requests for certified anduncertified data, ontology definition, anonymous interactions, and zero-knowledge proofs;the definition of a data handling model and language for specification and enforcementof policies aimed at protecting secondary use of private information of users after theirrelease to external parties; an architecture for the composition of access control, release,and data handling policies. With respect to the definition of a location privacy solution tobe integrated in the context of our location-based access control model and language, theoriginal results are: the definition of an infrastructure for the evaluation and enforcementof LBAC policies, which manages the uncertainty of location-based information; the def-inition of a location privacy solution based on obfuscation techniques balancing privacyneed of users and accuracy need of location-based services; a privacy-aware LBAC sys-tem integrating our privacy-aware access control system, our location-based access controlsystem, and our location privacy solution.

Acknowledgements

I would like to use this opportunity to thank all the people who have helped me, indifferent ways, during my PhD.

First of all, I would like to sincerely thank Pierangela Samarati, my advisor, not onlyfor introducing me to scientific research and for all the opportunities she gave me duringthese last three years, but also for the constant presence, guidance, and advice. Herleadership, support, attention to details, hard work, and scholarship have set an exampleI hope to match some day. I also wish to express my gratitude to Sabrina De Capitanidi Vimercati and Marco Cremonini, my co-advisors, for their continuing help, and support.

I am particularly grateful to Ernesto Damiani, for always being there to offer supportwhen I needed it and for cheering me up.

I would like to thank Marco Cremonini, Ernesto Damiani, Sabrina De Capitani diVimercati, and Pierangela Samarati, for working with me in different parts of thisthesis. I would like to thank Alberto Colombo and Eros Pedrini who worked on theimplementation of the system described in Chapter 3.

I would like to thank Marco Casassa Mont, Stefanos Gritzalis, and Javier Lopez-Munozfor their time and dedication in reviewing my work and for their valuable feedback.

I would like to thank Marco Anisetti, Valerio Bellandi, Alberto Colombo, Sara Foresti,Fulvio Frati, Eros Pedrini, Umberto Raimondi, my colleagues at the Dipartimento di Tec-nologie dell’Informazione of the University of Milan, for their friendship during these years.

Last but not least, my family, especially my mother Angela, my father Gaetano, my brotherNino, my grandmother Lucia, and my girlfriend Erika, deserve all my gratitude for givingme the opportunity to undertake this work in the first place, constantly supporting meover the years, and for always being there.

Contents

Abstract v

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Contributions of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Privacy-aware access control system . . . . . . . . . . . . . . . . . . 51.2.2 Location-based access control and location privacy . . . . . . . . . . 6

1.3 Organization of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Related work 92.1 Privacy-aware access control systems for distributed environments . . . . . 9

2.1.1 eXtensible Access Control Markup Language (XACML) . . . . . . . 132.1.2 Platform for Privacy Preferences Project (P3P) . . . . . . . . . . . . 192.1.3 Comparison with our privacy-aware access control system . . . . . . 20

2.2 Location-based access control systems . . . . . . . . . . . . . . . . . . . . . 232.2.1 Location-Based Access Control (LBAC) . . . . . . . . . . . . . . . . 242.2.2 Location privacy protection . . . . . . . . . . . . . . . . . . . . . . . 25

2.3 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 A privacy-aware access control system 333.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.1 Outline of the chapter . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Privacy-aware access control: key aspects . . . . . . . . . . . . . . . . . . . 35

3.2.1 Privacy policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3 Scenario and basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4 Access control model and language . . . . . . . . . . . . . . . . . . . . . . . 42

3.4.1 Description of the access control language . . . . . . . . . . . . . . . 433.4.2 A XML-based syntax for access control and release policies . . . . . 47

3.5 Data handling model and language . . . . . . . . . . . . . . . . . . . . . . . 513.5.1 Description of the data handling language . . . . . . . . . . . . . . . 543.5.2 A XML-based syntax for data handling policies . . . . . . . . . . . . 57

3.6 Proposed privacy-aware access control system . . . . . . . . . . . . . . . . . 593.6.1 Interplay between parties . . . . . . . . . . . . . . . . . . . . . . . . 613.6.2 A privacy-aware access control architecture . . . . . . . . . . . . . . 63

x Contents

3.6.3 Policies evaluation and enforcement . . . . . . . . . . . . . . . . . . 663.7 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4 Supporting location-based conditions in access control policies 694.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.1 Outline of the chapter . . . . . . . . . . . . . . . . . . . . . . . . . . 704.2 Basic concepts and reference scenario . . . . . . . . . . . . . . . . . . . . . . 71

4.2.1 LBAC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2.2 Location measurements and techniques . . . . . . . . . . . . . . . . 734.2.3 Relevance metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.3 Location-based conditions and predicates . . . . . . . . . . . . . . . . . . . 764.3.1 Expressing location-based conditions . . . . . . . . . . . . . . . . . . 764.3.2 Location-based predicates . . . . . . . . . . . . . . . . . . . . . . . . 78

4.4 Location-based access control policies . . . . . . . . . . . . . . . . . . . . . 814.5 Policy evaluation and enforcement . . . . . . . . . . . . . . . . . . . . . . . 83

4.5.1 From relevance to truth values . . . . . . . . . . . . . . . . . . . . . 834.5.2 Access control enforcement . . . . . . . . . . . . . . . . . . . . . . . 86

4.6 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5 Location privacy protection in LBAC systems: an obfuscation-basedsolution 895.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.1.1 Outline of the chapter . . . . . . . . . . . . . . . . . . . . . . . . . . 915.2 Working assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.3 Location relevance and privacy preferences . . . . . . . . . . . . . . . . . . . 93

5.3.1 Location accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.3.2 Relevance metric for privacy protection . . . . . . . . . . . . . . . . 945.3.3 User privacy preferences . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.4 Obfuscation techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.4.1 Obfuscation operators . . . . . . . . . . . . . . . . . . . . . . . . . . 985.4.2 Obfuscation by enlarging the radius . . . . . . . . . . . . . . . . . . 995.4.3 Obfuscation by reducing the radius . . . . . . . . . . . . . . . . . . . 1005.4.4 Obfuscation by shifting the center . . . . . . . . . . . . . . . . . . . 1015.4.5 Obfuscation examples . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.5 Double obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.5.1 Operators composition . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.5.2 Available obfuscation processes . . . . . . . . . . . . . . . . . . . . . 1075.5.3 Obfuscation algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.5.4 Double obfuscation examples . . . . . . . . . . . . . . . . . . . . . . 112

5.6 Adversary model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.6.1 Contextual information . . . . . . . . . . . . . . . . . . . . . . . . . 114

Contents xi

5.6.2 R-family de-obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . 1155.6.3 E-family de-obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . 1185.6.4 S-family and *-family de-obfuscation . . . . . . . . . . . . . . . . . . 1205.6.5 Using entropy to evaluate the degree of robustness . . . . . . . . . . 122

5.7 A privacy-aware LBAC system . . . . . . . . . . . . . . . . . . . . . . . . . 1245.7.1 A privacy-aware LBAC architecture . . . . . . . . . . . . . . . . . . 1255.7.2 LBAC predicates evaluation: REval calculation . . . . . . . . . . . . 1275.7.3 The privacy-aware middleware . . . . . . . . . . . . . . . . . . . . . 132

5.8 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6 Conclusions 1376.1 Summary of the contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 1376.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6.2.1 Privacy-aware access control . . . . . . . . . . . . . . . . . . . . . . 1386.2.2 Location-based access control and location privacy . . . . . . . . . . 139

6.3 Closing remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Bibliography 141

A Access control and release language: XML Schema 155

B Data handling language: XML Schema 159

C Distance between centers of circular areas given the overlap 163

D Publications 165

xii Contents

List of Figures

2.1 Overview of XACML dataflow [56] . . . . . . . . . . . . . . . . . . . . . . . 142.2 An example of XACML policy . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 An example of P3P policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Reference scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 BNF syntax of the access control policies . . . . . . . . . . . . . . . . . . . 473.3 An example of recipient hierarchy (a) and PII abstraction (b) . . . . . . . . 553.4 BNF syntax of the DHP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 583.5 User-Service Provider interplay (a) and External Party-Service Provider

interplay (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.6 Privacy-aware access control architecture . . . . . . . . . . . . . . . . . . . 63

4.1 LBAC Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2 LBAC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3 Function Solve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.1 Obfuscation by enlarging the radius (a), reducing the radius (b), and shift-ing the center (c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.2 Obfuscation operators composition . . . . . . . . . . . . . . . . . . . . . . . 1065.3 Example of SE obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.4 Examples of ES obfuscation (partial overlapping (a) or inclusion (b)) . . . . 1085.5 Example of SE obfuscation process producing an area impossible for ES

obfuscation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.6 Function Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.7 Example of ES and RS obfuscation on a large scale . . . . . . . . . . . . . . 1125.8 Example of de-obfuscation of SR combination . . . . . . . . . . . . . . . . . 1155.9 Adversary gains in de-obfuscation attempts against R-family obfuscation:

(a) R, (b) RS(partial overlapping)/SR, (c) RS(inclusion). . . . . . . . . . . . . 1175.10 De-obfuscation of E-family obfuscations: (a) ES (inclusion), (b) SE . . . . . 1205.11 Adversary gains in de-obfuscation attempts against E-family obfuscation:

(a) E, (b) ES (inclusion), (c) SE and ES (partial overlapping) . . . . . . . . . 1215.12 Adversary gain in de-obfuscation attempt against E-family obfuscation . . . 1225.13 Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235.14 Privacy-Aware LBAC Architecture . . . . . . . . . . . . . . . . . . . . . . . 1255.15 An example of LM evaluation (a), and ACE evaluation (b) . . . . . . . . . 1305.16 Area selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

xiv List of Figures

5.17 Location Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.18 LM inarea predicate evaluation . . . . . . . . . . . . . . . . . . . . . . . . 1345.19 LM distance predicate evaluation . . . . . . . . . . . . . . . . . . . . . . . 135

6.1 Variable-based restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

C.1 Parameters to calculate the distance between centers . . . . . . . . . . . . . 163

List of Tables

3.1 An example of access control policies (release policies, resp.) . . . . . . . . . 503.2 An example of data handling policies that protect Alice’s data stored by

ACME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.3 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.4 Bob’s profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.1 Examples of location-based predicates . . . . . . . . . . . . . . . . . . . . . 794.2 Examples of access control policies regulating access to mobile network

console and databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.3 An example of Extended Truth Table for location predicates . . . . . . . . . 84

5.1 Obfuscation operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.2 Obfuscation operators refinement . . . . . . . . . . . . . . . . . . . . . . . . 1055.3 Double obfuscation types and operations . . . . . . . . . . . . . . . . . . . . 110

xvi List of Tables

1Introduction

Human activities are increasingly based on the use of remote resources and services, andon the interaction between different, remotely located, mobile, and unknown parties. Thevast amount of personal information thus available on the Web has led to growing concernsabout the privacy of its users. Effective information sharing and dissemination, and onlinetransactions can take place only if the users have some assurance that, while releasinginformation, disclosure of sensitive information is not a risk. In such a scenario, privacyprotection is repeatedly identified as one of the main issues that needs to be addressed.This thesis is concerned with the definition of a privacy-aware access control system. Inthe remainder of the chapter, we give the motivation of our thesis and its outline.

1.1 Motivation

Accessing information on the global Internet has become an essential requirement of themodern economy. In the last decade, focus has shifted from access to traditional infor-mation stored in WWW sites to access to large e-services such as e-government services,remote banking, or airline reservation systems. Recently the pervasive diffusion of mobilecommunication devices and technical improvements of location technologies have fosteredthe development of a new wave of applications that use the physical position of individualsto offer enhanced location-based services for business, social, or informational purposes.The increasing amount of personal data available and the decreasing cost of data storageand processing make it technically possible and economically justifiable to gather and an-alyze large amount of data. Also, information technology gives organizations the powerto manage and disclose personal information of users without restrictions. In the past,this is resulted in security incidents, faulty data management practices and unauthorizedtrading of users personal information, which exposed victims to ID theft and unautho-rized profiling [8]. Privacy is then repeatedly identified as one of the main concerns thatprevents users from using the Internet for transactions, and it becomes one of the hottesttopics in computer security. In this scenario, traditional access control systems do not holdanymore since: there is the need of providing enhanced access control models that take

2 1. Introduction

advantages from context information, such as location information; there is the need toprovide a privacy-aware access control system that allows the users to protect their privacyand to maintain a level of control over their personal data released during a transaction.Some real-life examples of scenarios that point out the need to provide a privacy-awareaccess control system are as follows.

E-commerce. A major factor in the evolution of the Web has been the widespreaddiffusion of electronic commerce (e-commerce), that is, the ability of purchase, sell, anddistribute goods and services to customers. A primary concern in the development of e-commerce was to provide a secure Global infrastructure through solutions for secure dataexchange and systems for protecting e-services from unauthorized accesses. However, inthe last years, the focus is shifted from the protection of server-side resources to theprotection of users privacy. If users do not have confidence that their private data aremanaged in a privacy-oriented way by the server, they will refuse participation in e-commerce [83].

Online healthcare system. Healthcare systems support interactions among patients,medical and emergency personnel, insurance companies, and pharmacies. These systemsallow for anonymous access to general information and advice, and enforces access controlto individual patient records according to general rules, context (e.g., treatment, emer-gency), and the patient’s specific choices (e.g., primary care physician, health insurance).In this context, it is important to ensure to the patients enhanced privacy functionalitiesto define restrictions regulating access and management of their data.

Location-Based Service (LBS). Technical improvements of location technologies per-mit to gather location information with high accuracy and reliability. Physical locationof individuals is then rapidly becoming easily available as a class of personal informationthat can be processed for providing a new wave of online and mobile services, such aslocation-based access control (LBAC) services. In addition to LBAC services, many mo-bile network providers offer a variety of location-based services such as point of interestsproximity, friend-finder, or location information transfer in case of an accident (e.g., 911emergency service). Such services naturally raise privacy concerns. Users consider theirphysical location and movements as highly privacy sensitive, and demand for solutionsable to protect such an information in a variety of environments.

Privacy-preserving customer databases. Today many enterprises, which organizetheir customer databases by primary identifiers, are not able to offer personalized privacyservices under multiple and a priori unlinkable pseudonyms. The privacy of the users isthen at risk, and consumers protect themselves by refusing participation in Web trans-actions or by inventing fake identities on the fly, which are bad for enterprises as they

1.1. Motivation 3

reduce the number of potential customers and data quality. Supporting multiple unlink-able pseudonyms, with optional anonymity revocation, and solutions allowing the users totake control over their data offer different advantages: i) increase privacy of consumers,ii) enterprises can be less concerned about how to protect specific customer data againstunwanted accesses by other parties.

Privacy-enhancing ambient intelligence. Ambient intelligence is not a dream, butrather a reality. Individuals will soon be surrounded by a variety of devices/sensors at-tached to any everyday object, or even implanted into the individual’s body. These devicescollect personal information, implicitly or explicitly, and communicate it to other devices,in many cases without the individuals aware of the existence of the devices. This type ofscenario presents a situation in which privacy is not just important, but a sine qua non[3].

Federated identity management. As technology improves and becomes a fundamen-tal business part, it provides solutions to share information and services between organi-zations in a simple, secure, and intuitive manner. However, the ability of sharing infor-mation between remote parties comes with the responsibility of protecting it. Businesslosses, identity theft, and government regulations are at the base of solutions that protectinformation disclosure and unauthorized accesses to services. From a user-centric pointof view, the need of an identity management solution simplifying access to distributedresources that improves control over sensitive data arises. Federated identity managementprotocols allow for distributing identity information of a user among multiple federatedservice providers. Within the set of federated service providers, user attributes may beprovided from one service provider to the other thus minimizing the effort of the user inmanaging her identity. Examples of federated identity management approaches are theLiberty Alliance 2.0 [90], SAML 2.0 [101], and WS-Federation [134]. In this context, anidentity management solution is not sufficient anymore. Users are always concerned abouttheir privacy and ask for solutions that improve the control over their sensitive data.

Communities, collaborative working environment, social network. Thewidespread diffusion of systems and services joining users together for a variety of purposesmakes the problems of privacy and identity management urgent. Communities, Collab-orative Working Environments, Social Networks support people that are tied by one ormore specific types of interdependency, such as work, visions, idea, financial exchange,friends, trade, and so on. Research involves organizational, technical, and social issues,among which the problems of privacy and anonymity of users stand out.

4 1. Introduction

1.1.1 Objectives

From the above scenarios, it is clear that the huge success of the Web as a platform forthe distribution of services and dissemination of information makes the protection of usersprivacy a fundamental requirement. Also, the improvements in mobile technologies makethe need of privacy much more urgent and difficult than before. The privacy issues affectdifferent aspects of today Internet transactions, among which access control represents themost critical. An important step towards the protection of the privacy is then the defi-nition of a privacy-aware access control system that, in addition to server-side resourcesprotection, provides the users with solutions for preserving their privacy and managingtheir data. Although considerable works have been done in the field of access control fordistributed services [20, 21, 32, 56, 128], access control mechanisms available today are atan early stage from a privacy protection point of view. This situation reflects the fact thatin the last years the variety of security requirements focused on addressing server-side se-curity concerns (e.g., communication confidentiality, unauthorized access to services, dataintegrity). In this thesis, we focus on the development of a privacy-aware access control sys-tem regulating access to resources and protecting privacy of the users. Our privacy-awareaccess control models and languages take advantages from the integration with location-based conditions. To this aim, we focus on the definition of an infrastructure managinglocation-based conditions evaluation, and on a solution protecting location privacy. Themain objectives of our work can then be summarized as follow. First, we want to definean enhanced access control model and language managing anonymous users, supportingrequests for certified and uncertified data, supporting location information, and providingattribute-based access control. Second, we want to integrate the defined access controlmodel and language with a data handling model and language allowing the users to definerestrictions on the management of their sensitive data at the receiving parties. To thispurpose, we focus on the development of an architecture implementing a privacy-awareaccess control system that integrates access control and data handling policies. Finally,the last objective we want to achieve is to provide an infrastructure for the evaluationof location-based conditions that can be integrated with our privacy-aware access controlsystem.1

1.2 Contributions of the thesis

The contributions of the thesis are centered on two related topics: definition of a privacy-aware access control system, and protection of location privacy in the context of a privacy-aware access control system that supports location-based conditions. The works of thisthesis have been made and validated in the context of the Privacy and Identity Manage-

1An access control system integrating and managing location-based conditions is called location-basedaccess control system.

1.2. Contributions of the thesis 5

ment for Europe (PRIME) [108], an international and collaborative R&D project. In theremainder of this section, we discuss the contributions more in details.

1.2.1 Privacy-aware access control system

We define a privacy-aware access control system that on one side regulates access to serviceprovider resources and release of user data [7, 17], and on the other side allows the usersto restrict the secondary use of their personal data [18]. The main characteristics of oursystem can be summarized as follow.

Definition of an attribute-based access control model. We define an access controlmodel and a XML-based access control language that support traditional authorizationsprotecting access to service provider resources and authorizations regulating release ofusers private data during a Web transaction. Organizations in fact may need to enforcesecurity policies on their resources, dynamically evaluated on users’ profiles, while users areconcerned about their privacy, and then require full control on private data managementand release. The basic features of the system that guarantee the satisfaction of theserequirements are the following.

• Access control vs. release policies. The protection requirements posed by users andservice providers require the definition of different policies for protecting access toseveral resources and data. Our access control system supports both access controlpolicies that regulate access to services and release policies that manage the releaseof users data.

• Minimal disclosure. Our model supports the principle of the minimal disclosure. Aservice provider must require and gather all the users data that are both sufficientand necessary to provide the access to the requested resources. Support for minimaldisclosure is improved by the integration with ontologies, which provides an infras-tructure to reason about service provider requests and find out the less costly way,in terms of amount of data released, to fulfill the requests [16].

• Interactive enforcement. Traditional access control models require the users to makeavailable all their data at policy evaluation time to access a service. However, thisis in contrast with the principle of minimal disclosure. Our model defines an in-frastructure supporting the interactive enforcement of access control policies. Usersare potentially unknown to the service provider at the transaction startup, that is,service provider has collected no information about the users. The access controlprocess is then based on a bidirectional negotiation protocol composed of multiplerequest-response messages exchange between users and service providers, aimed atestablishing the least set of information that the users/service providers have todisclose to reach a successful negotiation state, i.e., service is released to users.

6 1. Introduction

Management of secondary use of personal data. The definition of access con-trol and release policies allows to protect access to data/services and release of prop-erties/Personal Identifiable Information (PII), respectively. However, the users cannotmanage and restrict the secondary use of their personal data, that is, user cannot decidehow PII must be used and processed after their release. A contribution of our work is thenthe definition of a data handling model and a XML-based data handling language thatallow the users to pose restriction on the management of their private data whenever theyare released to external entities. Released data are tagged with at least a data handlingpolicy, and each party receiving the data has to satisfy the attached data handling policiesbefore any access or disclosure is permitted. For the enforcement of data handling policies,it is needed that they always follow the corresponding data when they are manipulatedby applications or transferred between systems. The explicit definition of data handlingpolicies gives to the users the possibility of exercise a finer-grained and larger control onsecondary use of their data.

Access control and data handling policies composition. In the context of ourprivacy-aware access control system has been developed an infrastructure providing func-tionalities for the composition of access control and data handling policies. This infrastruc-ture provides access control functionality that enforces secondary use restrictions posedby the users. When users data stored at a service provider are requested by an externalentity, access control policies of the service provider are evaluated first. If access controlevaluation is positive, data handling policies attached to the requested data are evalu-ated. A positive decision applies when both access control and data handling policies aresatisfied.

1.2.2 Location-based access control and location privacy

An important contribution of this thesis is the definition of a location-based access controlmodel and language supporting the specification and evaluation of location-based condi-tions [8, 9], by exploiting location information of the users. Location-based access controlmodel and language are fully integrable with our privacy-aware access control system. Asolution for protecting the location privacy of the users is then provided and validatedin the context of such a system [10, 11, 13]. The original results of our work can besummarized as follow.

Location-Based Access Control (LBAC) model. A location-based access controlmodel differs from traditional models since it must manage and evaluate location-basedconditions. In this case, we need to consider that location-based information is radi-cally different from other context-related knowledge inasmuch it is both approximate andtime-variant. We then define a set of predicates and conditions based on the peculiar char-acteristics of location information. An infrastructure for managing location uncertainty is

1.3. Organization of the thesis 7

then provided based on the concept of relevance, which is a metric of the accuracy andreliability of each location information. Finally, an architecture supporting location-basedevaluation and enforcement is designed. The main feature of such an architecture is tocalculate the truth value that corresponds to the uncertain evaluation of a location-basedcondition. This allows to integrate the evaluation of location-based conditions with theevaluation of traditional conditions that returns a boolean value.

Location privacy protection. Although our privacy-aware access control system pro-vides functionalities for managing sensitive data after their release, this is not enough forprotecting location privacy of users, since location information is considered high-sensitive.Special attention is then devoted to the protection of this information with respect to pri-vacy threats that can happen in today pervasive environments. We introduce a solutionthat protects location privacy when location information is released to services includingour location-based access control system. Our contribution is threefold: i) we define a sim-ple and intuitive mechanism to define users preferences based on the relevance concept;ii) we allow to balance the need of privacy of the users and the need of accuracy of theservice providers for high quality services provisioning; iii) we define multiple obfuscationtechniques and a method to combine them to provide a solution that preserves users pri-vacy by artificially perturbing location information. Our solution permits to achieve, andquantitatively estimate through the relevance metric, different degrees of location privacyand accuracy. To conclude, this privacy solution is used and validated in the context of ourlocation-based access control model, which is further integrated with our privacy-awareaccess control system.

Characterization of adversary model. An aspect often neglected by privacy enhanc-ing techniques (PET) is the evaluation of the real degree of privacy. Usually, the estimationof the degree of privacy provided to the users does not consider the ability of an adversaryin reducing the effects of privacy techniques. This results in a reduced privacy protection.Another contribution of our work is to deeply study an adversary that tries to reduce theeffects of our location privacy solution. To this aim, we introduce the concept of robustnessof obfuscation techniques. To measure the robustness of our techniques and then the realdegree of privacy protection provided to users, awareness of the adversary with respect tothe outcome of its manipulations must be considered. The concept of entropy is used tomeasure the uncertainty holds by an adversary guess.

1.3 Organization of the thesis

The chapter has discussed the motivation and the main objectives of our work andoutlined the major contributions of this thesis. The remaining chapters are structured as

8 1. Introduction

follow.

Chapter 2 discusses the state of the art of security and privacy techniques related tothe objectives of the thesis. It presents the current proposals for providing privacy-awareaccess control systems, location-based access control, and location privacy protection.

Chapter 3 illustrates our privacy-aware access control system. The system includesan access control model and language, a data handling model and language, and anarchitecture for the evaluation and enforcement of privacy policies.

Chapter 4 describes the integration of location-based conditions in the context of accesscontrol languages, such as the language described in Chapter 3. This chapter discussesall the issues introduced by a location-based access control system, including definitionand evaluation of location-based conditions and enforcement of related policies.

Chapter 5 discusses the problem of protecting location privacy of the users. Thischapter presents a location privacy solution based on obfuscation techniques, which isvalidated in the context of our location-based access control system.

Chapter 6 summarizes the contributions of this thesis and outlines future work.

Appendix A and B present the XML schemas of access control and data handlingpolicies.

Appendix D reports a list of publications related to the thesis work with the correspond-ing abstracts.

2Related work

This chapter discusses related work in the area of privacy-aware access control systems fordistributed environments, and location-based access control systems focusing on locationinformation protection.

2.1 Privacy-aware access control systems for distributed en-vironments

A number of projects and research works about privacy and identity management havebeen presented in the last few years, although not many of them have addressed the issueof privacy-aware access control. Three lines of research are closely related to the topicsof this thesis: i) the definition and development of credential-based access control modelsand trust negotiation solutions, ii) the definition and development of access control andprivacy-aware languages, and iii) the definition of infrastructures to protect and preserveprivacy of either services or clients and to provide functionalities for identity management.

Access control models exploiting digital credentials make access decisions on whetheror not a party may execute an access on the basis of properties that the requestingparty may have. These properties can be proven by presenting one or more certifi-cates [32, 78, 89, 99, 139]. The first proposals that investigate the application of credential-based access control regulating access to a server are done by Winslett et al. [119, 132].Access control rules are expressed in a logic language, and rules applicable to a service ac-cess can be communicated by the server to the clients. A first attempt to provide a uniformframework for attribute-based access control specification and enforcement is presented byBonatti and Samarati [32]. Access rules are specified as logical rules, with some predi-cates explicitly identified. Attribute certificates are modeled as credential expressions.Besides credentials, this proposal also permits to reason about declarations (i.e., unsignedstatements) and user’s profiles that a server can make use of to reach an access decision.Communication of requisites to be satisfied by the requester is based on a filtering andrenaming process applied to server’s policies, which exploits partial evaluation techniquesin logic programs. Besides solutions for uniform frameworks supporting credential-based

10 2. Related work

access control policies, different automated trust negotiation proposals have been devel-oped [118, 137, 138]. Trust is established gradually by disclosing credentials and requestsfor credentials [60]. In [112, 126, 131, 136, 137, 139], the authors investigate trust nego-tiation issues and strategies that a party can apply to select credentials to submit to theopponent party during a negotiation. It is however important to note that different partiesmay have different requirements for how such a negotiation process should be performedand each party can therefore rely on its trust negotiation strategy . Trust-management sys-tems (e.g., Keynote [29], PolicyMaker [30], REFEREE [42], and DL [88]) use credentialsto describe specific delegation of trusts among keys and to bind public keys to autho-rizations. They therefore depart from the traditional separation between authenticationand authorizations by granting authorizations directly to keys (bypassing identities). Re-cently, some works have been done in the context of anonymous credential system [76] andpublic key infrastructure [19]. IDEntity MIXer (Idemix) [34, 35] is a privacy-enhancingpseudonym-based public key infrastructure. It provides an anonymous credential system,where an organization can issue a credential to a pseudonym, and the corresponding usercan prove possession of this credential to another organization without revealing the con-tent of such a credential [76]. The Simple Public Key Infrastructure (SPKI) [55] has bornas a joint effort to overcome the complication and scalability problems of traditional X.509public key infrastructure. SPKI has then been merged with Simple Distributed SecurityInfrastructure (SDSI) that bounds local names to public keys. The combined SPKI/SDSIallows the naming of principals, creation of named groups of principals and the delegationof rights or other attributes from one principal to another. SPKI is mainly used in accesscontrol and emphasizes decentralization using keys instead of names. Different permis-sions can be freely defined in SPKI certificates, which can be used as name certificatesthat provide a mechanism to get public keys according to names or attributes. The mostimportant implementation of SPKI/SDSI is E-speak, a middleware product developed byHewlett-Packard (HP). Both credential-based access control and trust-management sys-tems provide interesting frameworks for securing Web-based transactions between remoteparties. Although the benefits of all these works, none provides functionalities for pro-tecting privacy of users and regulates the use of their personal information in secondaryapplications.

Some languages, which provides preliminary solutions to privacy protection issue, havebeen defined starting from access control languages [56, 129], to data handling languages(i.e., languages regulating how personal information could be managed once collected)[2, 21, 128]. eXtensible Access Control Markup Language (XACML) [56], which is theresult of OASIS standardization effort, proposes a XML-based language to express andinterchange access control policies. In addition to the language, XACML defines both anarchitecture for the evaluation of policies and a communication protocol for messages ex-change. Platform for Privacy Preferences Project (P3P) [46, 128] is a W3C (World WideWeb Consortium) project that addresses the need of a user to assess that the privacy prac-tices adopted by a server provider comply with her privacy requirements. P3P provides

2.1. Privacy-aware access control systems for distributed environments 11

a XML-based language and a mechanism for ensuring that users can be informed aboutprivacy policies of the server before the release of personal information. The correspondinglanguage that would allow users to specify their preferences as a set of preference-rulesis called A P3P Preference Exchange Language (APPEL) [133]. APPEL can be used byusers agents to make automated or semi-automated decisions regarding the acceptability ofmachine-readable privacy policies from P3P enabled Web sites. Unfortunately, as stated in[1], interactions between P3P and APPEL result in serious problems when using APPEL:users can only directly specify what is unacceptable in a policy, simple preferences are dif-ficult to specify, and writing APPEL preferences is error prone. PReference Expression forPrivacy (PREP) [2] is another XML-based privacy preference expression language used forrepresenting the user’s privacy preferences with Liberty Alliance. Privacy Preferences Ex-pression Language (PPEL) [92] provides a solution to manage privacy preferences withinLiberty Alliance’s ID-WSF framework [91]. PPEL gives a high-level example based onP3P of how privacy preferences can be managed in the communication between a ServiceProvider and Web Services Provider (acting on the Principal’s behalf). In this context,where a multi-leveled policy approach is adopted, a limited, hierarchical set of privacypolicies is used to describe the privacy practices of a Service Provider, and the privacypreferences of a Principal. Enterprise Privacy Authorization Language (EPAL) [20, 21]is an XML-based markup language and architecture for formalizing, defining, and enforc-ing enterprise-internal privacy policies. It addresses the problem on the server side andsupports the need of a company to specify access control policies, with reference to at-tributes/properties of the requester, to protect private information of its users. EPAL isdesigned to enable organizations to translate their privacy policies into IT control state-ments and to enforce policies that may be declared and communicated in P3P. XACML,however, includes most (if not all) of the expressive power of EPAL. Additionally, EPALdoes not allow protection of users data released outside enterprises boundaries. Looking atstandardization efforts WS-* specifications stand out [75]. In particular, WS-* is focusedon a strategy for addressing security in a Web service environment and provides severalspecifications supporting security functionalities at different levels of abstraction. It de-fines a comprehensive Web service security model that supports, integrates, and unifiesdifferent security models, mechanisms, and technologies to enables a variety of systemsto securely interoperate. Finally, Casassa Mont et al. [39] discuss a privacy-aware accesscontrol model to enforce privacy policies on personal data. The model includes handlingof the purpose of data, checking of data requesters’ intent against data purposes, and en-forcement of data subjects’ consent. The authors also analyze basic aspects and conceptsrelated to privacy obligations that pose restrictions on how users data should be managed.

Several projects are focused on developing architectures that preserve security andprivacy of the involved parties. International Security, Trust, and Privacy Alliance(ISTPA) [77] is an open, policy-configurable model consisting of several privacy servicesand capabilities, intended to be used as a template for designing solutions and coveringsecurity, trust, and privacy requirements. The goal of the framework is to set the basis for

12 2. Related work

developing products and services that support current and evolving privacy regulationsand business policies. Reasoning on the Web (REWERSE) [111] is a project whose ob-jective is to strengthen Europe in the area of reasoning languages for Web systems andapplications aiming at enriching the current Web with so-called intelligent capabilities fordata and service retrieval, composition, and processing. REWERSE’s research activitiesare devoted to several objectives, a part of those is overlapped with our work: rule markuplanguages aiming at unified markup and tools for reasoning Web languages, policy specifi-cation, composition, and conformance aiming at user-friendly high-level specifications forcomplex Web systems, Web-based decision support for event, temporal, and geographicaldata aiming at enhancing event, temporal, and location reasoning on the Web. EnterprisePrivacy Architecture (EPA) [82] is an IBM project that wants to improve enterprises e-business trust. EPA represents a new approach to privacy that tries to help organizationsto understand how privacy impacts business processes. EPA defines privacy parties, rules,and data for new and existing business processes and provides privacy management con-trols based on consumer preferences, privacy best practices, and business requirements.TRUSTe [125] enables trust based on privacy protection of personal information on theInternet. It certifies and monitors Web site privacy practices.

Many other projects are focused on providing enhanced identity management systemprotecting privacy and security of identity information and giving to the users much morepower in controlling their private sphere [91, 108, 130]. Liberty Alliance [91] project isaimed at providing a networked world based on open standards where consumers, citizens,and governments are able to manage online transactions still protecting the privacy andsecurity of their identity information. In the Liberty Alliance vision identities are linkedby federation and protected by strong authentication. Also Liberty Alliance project triesto address end user privacy and confidentiality concerns, allowing them to store, maintain,and categorize online relationships. Users can manage all of their information using privacycontrols built into the system based on Liberty platform. Windows CardSpace [130] isan identity management component or identity selector that enables users to providetheir digital identity to online services in a simple, secure, and trusted way. WindowsCardSpace is based on visual “cards” that have several identity information associated(e.g., name, phone number, e-mail address). These cards are released to the users byidentity providers,1 such as public administration or users themselves, and are used tofulfill the request stated in the Web forms of the service providers. Therefore the usersmaintain control over the information flow, and are responsible for choosing to releaseor not information to the online services. Privacy and Identity Management for Europe(PRIME) [108] is a large-scale research effort aimed at developing a privacy-enhancingIdentity Management System able to protect users personal information and providing aframework that can be smoothly integrated with current architectures and online services.The goal of PRIME project is to provide the users with solutions allowing them to keep

1Identity Providers retain a copy of managed infocards and are involved in the disclosure flow.


their autonomy and to retain control over their personal information in interactions withother parties. In PRIME vision, the user should have control of personal informationand negotiate its disclosure for access to a service. The result of such a negotiation isan agreement between the user and the service provider, whereby the provider collectspersonal data for a stated, legitimate purpose.

The works closest to our are represented by XACML [56] and P3P [46, 128]. XACMLrepresents the most accepted, complete, and flexible solution in terms of access controllanguages, which could be adapted and integrated with privacy preference-based solutions.P3P represents the most important work done in the context of privacy protection andsecondary use management. In the following, we describe these two proposals in moredetails.

2.1.1 eXtensible Access Control Markup Language (XACML)

XACML [56] is a XML-based language used to express and interchange access controlpolicies. XACML is designed to express authorization policies in XML against objectsthat are themselves identified in XML. The language can represent the functionalities ofmost policy representation mechanisms and has standard extension points for defining newfunctions, data types, policy combination logic, and so on. In addition to the language,XACML defines both an architecture for the evaluation of policies and a communicationprotocol for messages interchange. The major functionalities offered by XACML can besummarized as follows.

• Policy combination. XACML provides a method for combining policies indepen-dently specified. Different entities can then define their policies on the same resource.When an access request on that resource is submitted, the system has to take intoconsideration all these policies.

• Combining algorithms. Since XACML supports the definition of policies indepen-dently specified, there is the need for a method for reconciling such policies whentheir evaluation is contradictory. XACML supports different combining algorithms,each representing a way of combining multiple decisions into a single decision.

• Attribute-based restrictions. XACML supports the definition of policies based onproperties (attributes) associated with subjects and resources rather than their iden-tities. This allows the definition of powerful policies based on generic properties as-sociated with subjects (e.g., name, address, occupation) and resources. XACML in-cludes some built-in operators for comparing attribute values and provides a methodof adding nonstandard functions.

• Multiple subjects. XACML allows the definition of more than one subject relevantto a decision request.

14 2. Related work

AccessRequester

2.AccessRequest

// PEP 13.Obligations //

3.Request

ObligationsService

PDP 5.AttributeQueries

//

11.ResponseContext

//

ContextHandler

12.Response

OO

6.AttributeQuery

4.RequestNotification

oo

10.Attributesoo

Resource9.ResourceContent

oo

7c.ResourceAttributes

zzuuuuuuuuuuuuuuuuuuu

PIP

8.Attribute

OO

PAP

1.Policy

OO

Subjects

7a.SubjectAttributes

OO

Environment

7b.EnvironmentAttributes

ddHHHHHHHHHHHHHHHHHH

Figure 2.1: Overview of XACML dataflow [56]

• Policy distribution. Policies can be defined by different parties and enforced atdifferent enforcement points. Also, XACML allows one policy to contain or refer toanother.

• Implementation independence. XACML provides an abstraction layer that isolatesthe policy-writer from the implementation details. This means that different im-plementations should operate in a consistent way, regardless of the implementationitself.

• Obligations. XACML provides a method for specifying some actions, called obliga-tions, which must be fulfilled in conjunction with the policy enforcement.2

2Actually, XACML does not define obligations in terms of a formal language but, rather, it primarlycontains a placeholder for them.


A typical scenario involving XACML is when someone wants to perform an action ona resource. For instance, suppose that a physician wants to access a patient’s record forinquiry only. The physician would log on to the hospital information system, enter the pa-tient identifier, and retrieve the corresponding record. Data flow through a XACML modelcan be summarized as follow (see the entities involved and the data flow in Figure 2.1).

• The requester sends an access request to the policy evaluation point (PEP) module,which has to enforce the access decision that will be taken by the policy decisionpoint.

• The PEP module sends the access request to the context handler that translates theoriginal request into a canonical format, called XACML request context , by queryingthe policy information point (PIP) module. The PIP provides attribute values aboutthe subject, resource, and action. To this purpose, PIP interacts with the subjects,resource, and environment modules. The environment module provides a set ofattributes that are relevant to take an authorization decision and are independentof a particular subject, resource, and action.

• The context handler sends the XACML request to the policy decision point (PDP).The PDP identifies the applicable policies by means of the policy administration point(PAP) module, and retrieves the required attributes and, possibly, the resource fromthe context handler.

• The PDP then evaluates the policies and returns the XACML response context tothe Context Handler. The context handler translates the XACML response contextto the native format of the PEP and returns it to the PEP together with an optionalset of obligations.

• The PEP fulfills the obligations and, if the access is permitted, it performs the access.Otherwise, the PEP denies access.

As described above, XACML defines a canonical form of the request/response managedby the PDP, allowing policy definition and analysis without taking into account applicationenvironment details. Any implementation has to translate the attribute representations inthe application environment (e.g., SAML, .NET, Corba [102]) into the XACML context.For instance, an application can provide a SAML [101] message that includes a set ofattributes characterizing the subject making the access request. This message has to beconverted to the XACML canonical form and, analogously, the XACML decision has thento be converted to the SAML format.

Policy Set, Policy and Rule XACML relies on a model that provides a formal rep-resentation of the access control security policy and its working. This modeling phase is

16 2. Related work

essential to ensure a clear and unambiguous language, which could otherwise be subjectto different interpretations and uses. The main concepts of interest in the XACML policylanguage model are rule, policy , and policy set .

A XACML policy has, as root element, either Policy or PolicySet. A PolicySetis a collection of Policy or PolicySet elements. A XACML policy consists of a target ,a set of rules, an optional set of obligations, and a rule combining algorithm. A Targetbasically consists of a simplified set of conditions for the subject, resource, and action thatmust be satisfied for a policy to be applicable to a given request. If all the conditions of aTarget are satisfied, then its associated Policy (or PolicySet) applies to the request. Ifa policy applies to all entities of a given type, that is, all subjects, actions, or resources, anempty element, named AnySubject, AnyAction, AnyResource, respectively, is used. Thecomponents of a rule are a target , an effect , and a condition. The target defines the setof resources, subjects, and actions to which the rule is intended to apply. The effect ofthe rule can be permit or deny. The condition represents a boolean expression that mayfurther refine the applicability of the rule. Note that the target element is an optionalelement: a rule with no target applies to all possible requests. An Obligation specifies anaction that has to be performed in conjunction with the enforcement of an authorizationdecision. For instance, an obligation can state that all accesses to medical data have to belogged. Note that only policies that are evaluated and have returned a response of permitor deny can return obligations. Each Policy also defines a rule combining algorithmused for reconciling the decisions each rule makes. The final decision value, called theauthorization decision, inserted in the XACML context by the PDP is the value of thepolicy as defined by the rule combining algorithm. XACML defines different combiningalgorithms, i.e., deny overrides, permit overrides, first applicable, only-one-applicable.According to the selected combining algorithm, the authorization decision returned to thePEP can be permit, deny, not applicable (when no applicable policies or rules can befound), or indeterminate (when some errors occurred during the access control process).The deny overrides algorithm states that, if there exists a rule that evaluates to denyor if all rules evaluate to not applicable, the result is deny. If all rules evaluate topermit, the result is permit. If some rules evaluate to permit and some evaluate to notapplicable, the result is permit. The permit overrides algorithm states that, if thereexists a rule that evaluates to permit, the result is permit. If all rules evaluate to notapplicable, the result is deny. If some rules evaluate to deny and some evaluate to notapplicable, the result is deny. The first applicable algorithm states that each rule has tobe evaluated in the order in which it appears in the Policy. For each rule, if the targetmatches and the conditions evaluate to true, the result is the effect (permit or deny) ofsuch a rule. The only-one-applicable algorithm states that, if more than one rule applies,the result is indeterminate. If no rule applies, the result is not applicable. If only onepolicy applies, the result coincides with the result of evaluating that rule.

An important feature of XACML is that a rule is based on the definition of attributescorresponding to specific characteristics of a subject, resource, action, or environment.


For instance, a physician at a hospital may have the attribute of being a researcher,a specialist in some field, or many other job roles. According to these attributes, thephysician can be able to perform different functions within the hospital. Attributesare identified by the SubjectAttributeDesignator, ResourceAttributeDesignator,ActionAttributeDesignator, and EnvironmentAttributeDesignator elements. Theseelements use the AttributeValue element to define the requested value of a particu-lar attribute. Alternatively, the AttributeSelector element can be used to specifywhere to retrieve a particular attribute. Note that both the attribute designator andAttributeSelector elements can return multiple values. For this reason, XACML pro-vides an attribute type called bag , an unordered collection that can contain duplicatesvalues for a particular attribute. In addition, XACML defines other standard value typessuch as string, boolean, integer, time, and so on. Together with these attribute types,XACML also defines operations to be performed on the different types such as equalityoperation, comparison operation, string manipulation, and the like.

As an example of XACML policy, suppose that a hospital defines a high-level pol-icy stating that “any user with role head physician can read the patient recordfor which she is designated as head physician”. Figure 2.2 illustrates the XACMLpolicy corresponding to this high-level policy. The policy applies to requests on thehttp://www.example.com/hospital/patient.xsd resource. The policy has one rulewith a target that requires a read action, a subject with role head physician and acondition that applies only if the subject is the head physician of the requested patient.

XACML Request and Response. XACML defines a standard format for expressingrequests and responses. The original request submitted by the PEP is then translatedthrough the context handler in a canonical form, and forwarded to the PDP to be evalu-ated. Such a request contains attributes for the subject, resource, action, and, optionally,for the environment. Each request includes exactly one set of attributes for the resourceand action, and at most one set of environment attributes. There may be multiple sets ofsubject attributes each of which is identified by a category URI.

A response element contains one or more results corresponding to an evaluation.Each result contains three elements, namely Decision, Status, and Obligations. TheDecision element specifies the authorization decision (i.e., permit, deny, indeterminate,not applicable), the Status element indicates if some error occurred during the evalu-ation process, and the optional Obligations element states the obligations that the PEPmust fulfill. For instance, suppose that a user, belonging to role head physician andwith ID 354850273 wants to read resource www.example.com/hospital/patient.xsdwith patient ID equal to 123a45d. This request is compared with the XACML policy inFigure 2.2. The result of this evaluation is that the user is allowed (permit) to access therequested patient record if she is the head physician of the requested patient.

18 2. Related work

<Policy PolicyId="Pol1" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:

rule-combining-algorithm:permit-overrides"><Target>

<Subjects> <AnySubject/> </Subjects><Resources>

<Resource><ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:stringmatch">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://www.example.com/hospital/patient.xsd

</AttributeValue><ResourceAttributeDesignator

DataType="http://www.w3.org/2001/XMLSchema#string"

AttributeId="urn:oasis:names:tc:xacml:1.0:resource:target-namespace"/></ResourceMatch>

</Resource></Resources><Actions> <AnyAction/> </Actions>

</Target><Rule RuleId="ReadRule" Effect="Permit">

<Target><Subjects>

<Subject><SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">head physician

</AttributeValue><SubjectAttributeDesignator

AttributeId= "urn:oasis:names:tc:xacml:2.0:example:attribute:role"

DataType="http://www.w3.org/2001/XMLSchema#string"/></SubjectMatch>

</Subject></Subjects><Resources> <AnyResource/> </Resources><Actions>

<Action><ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read

</AttributeValue><ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string"

AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/></ActionMatch>

</Action></Actions>

</Target><Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string"

AttributeId="urn:oasis:names:tc:xacml:1.0:subject:head-physicianID"/><AttributeSelector RequestContextPath="/ctx:Request/ctx:Resource/ctx:

ResourceContent/hospital:record/hospital:patient/hospital:

patient-head-physicianID" DataType="http://www.w3.org/2001/XMLSchema#string"/ ></Condition>

</Rule></Policy>

Figure 2.2: An example of XACML policy


2.1.2 Platform for Privacy Preferences Project (P3P)

P3P [46, 128] allows Web sites to declare their privacy practices in a standard and machine-readable XML format known as P3P policy. Designed to address the need of the users toassess that the privacy practices adopted by a server provider comply with their privacyrequirements, P3P has been developed by the World Wide Web Consortium (W3C). Sup-porting data handling policies in Web-based transactions allows users to automaticallyunderstand and match server practices against their privacy preferences. Thus, users neednot read the privacy policies at every site they interact with, but they are always awareof the server practices in data handling. In summary, the goal of P3P is twofold. Onone side, it allows Web sites to state their data-collection practices in a standardized,machine-readable way. On the other side, it provides to users a solution to understandwhat data will be collected, how those data will be used, and what data/uses they may“opt-in” to or “opt-out” of.

Policy, Disputes, Statement P3P provides a formal model for representing privacypractices of service providers. The main concepts of interest in the P3P policy languageare Policy , Disputes, and Statement .

A P3P policy has, as root element, Policy. A Policy element consists of an Entity,an Access, a Dispute-Group, and one or more Statement elements. More in details,the Entity element gives some information about the legal entity responsible for therepresentation of the privacy practices. The Access element indicates whether the usersare allowed to access their information stored at the Web sites, and it can assume differentvalues as for instance: i) nonident: no identified data are collected, ii) all: access isprovided to all data, iii) ident-contact: access is given to contact data, iv) none: no accessto identified data is given. The Dispute-Group element consists of one or more optionalDisputes elements, which describe the procedures that may be followed for disputes aboutan entity’s privacy practices. Finally, the Statement element describes the real privacypractices used in the management of the data referenced by the Data-Group element.All data are handled according to the Purpose, Recipient, Retention, and optionallyConsequence elements, which are discussed below.

• Data-Group. It contains one or more Data elements describing the type of data atwhich the policy applies. Each Data element can provide hints about the intendeduses of the data by specifying a Categories element. Categories make P3P useragents easier to implement and use.

• Purpose. It contains one or more purposes for which data are collected or used. Sitesmust classify their data practices into one or more of the predefined purpose values,as for instance: i) current, data are used to complete the activity for which have beenreleased; ii) individual-decision, data are used to calculate statistics and determineinterests and characteristics of the users; iii) contact, data are used to communicate

20 2. Related work

with the users. Purpose elements provide to the users a mean to consent or notto some purposes, by defining an attribute “required” with three possible values:i) always (default), purpose is required; ii) opt-in, data can be used for the statedpurpose only when the user explicitly requests this use; iii) opt-out, data can beused for the stated purpose unless the user requests otherwise. Also, an elementnamed primary purpose is defined. It indicates the primary reason for which thedata recipient is collecting data.

• Recipient. It defines one or more entities that can potentially collect users data.These recipients must respect the constraints defined in the policy. Some predefinedrecipient values are defined as for instance: i) ours, data can be collected by thecollector itself or by entities related to it; ii) same, data can be collected by legalentities following collector practices. Same opt-in/opt-out functionality of Purposeelement is provided for Recipient one.

• Retention. It indicates the kind of retention policy that applies to the data ref-erenced in the statement. It provides a set of predefined values that restrict datacollection to a certain period of time as for instance: i) stated-purpose, data aredeleted as soon as possible; ii) indefinitely, data are retained without temporal re-strictions.

• Consequence. It represents a human-readable description that provides an explana-tion of the site’s privacy practices.

Users specify their privacy preferences through a policy language, called A P3P Pref-erence Exchange Language (APPEL) [133], and enforce privacy protection by means ofan agent. A user agent compares a user’s privacy policy with a service provider’s P3Ppolicy and verifies whether the P3P policy conforms to user privacy preferences. Agrawalet al. [1] propose another language, called XPref, for user preferences definition.

As an example of P3P policy (see Figure 2.3), suppose that a company ACME providesa book a flight service. To complete the service release, the company requires to therequester attributes name, address, credit card number. Also, with explicit permissiononly, ACME uses e-mail addresses of the users to provide them with special offers.

2.1.3 Comparison with our privacy-aware access control system

Although the differences between XACML and P3P approaches and our system will beclearer after reading Chapter 3, we anticipate some differences, both at language andinfrastructure level.

XACML. The main differences between XACML approach and our system can be sum-marized as follow.


<POLICY><ENTITY>

<DATA-GROUP><DATA ref="#business.name">ACME</DATA><DATA ref="#business.contact-info.postal.street">9, West 46Th Street</DATA><DATA ref="#business.contact-info.postal.city">New York</DATA><DATA ref="#business.contact-info.postal.stateprov">NY</DATA><DATA ref="#business.contact-info.postal.postalcode">10036</DATA><DATA ref="#business.contact-info.postal.country">USA</DATA><DATA ref="#business.contact-info.online.email">[email protected]</DATA><DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA><DATA ref="#business.contact-info.telecom.telephone.loccode">303</DATA><DATA ref="#business.contact-info.telecom.telephone.number">7463914</DATA>

</DATA-GROUP></ENTITY><ACCESS><all/></ACCESS><DISPUTES-GROUP>

<DISPUTES resolution-type="independent" service="http://www.example.org"><REMEDIES><correct/></REMEDIES>

</DISPUTES></DISPUTES-GROUP><STATEMENT>

<CONSEQUENCE>We use this information to provide the service.

</CONSEQUENCE><PURPOSE><current/></PURPOSE><RECIPIENT><ours/><same/></RECIPIENT><RETENTION><stated-purpose/></RETENTION><DATA-GROUP>

<DATA ref="#user.name"/><DATA ref="#user.home-info.postal"/><DATA ref="#dynamic.miscdata">

<CATEGORIES><purchase/></CATEGORIES></DATA>

</DATA-GROUP></STATEMENT><STATEMENT>

<CONSEQUENCE>We use this information to provide special offers.</CONSEQUENCE><PURPOSE>

<individual-decision required="opt-in"/><contact required="opt-in"/>

</PURPOSE><RECIPIENT><ours/></RECIPIENT><RETENTION><business-practices/></RETENTION><DATA-GROUP>

<DATA ref="#user.home-info.online.email"/><DATA ref="#dynamic.miscdata">

<CATEGORIES><purchase/></CATEGORIES></DATA>

</DATA-GROUP></STATEMENT>

</POLICY>

Figure 2.3: An example of P3P policy

22 2. Related work

• Support for privacy constraints. XACML does not explicitly support privacy fea-tures. By contrast, our solution integrates traditional access control policies withdata handling policies. In particular, data handling policies allow the users to providerestrictions on how their private data should be managed at the receiving parties.This allows the users to retain a level of control over their data also after chains ofreleases.

• Credential definition and integration. Although XACML supports digital credentialsexchange, it does not provide request for certified credentials. Our access controlmodel and language allow requests for certified data, issued and signed by authoritiestrusted for making the statement, and uncertified data, signed by the owner itself.

• Support for context-based conditions. Our system is more expressive than XACML,since it allows the definition of conditions based on physical position of the usersand context information, and the integration with metadata identifying and pos-sibly describing entities of interest, such as subjects and objects, as well as anyambient parameter concerning the technological and cultural environment where atransaction takes place.

• Ontology integration. Differently from XACML, our policy definition is fully in-tegrated with subject and object ontologies in defining access control restrictions.Also, the language takes advantages from the integration with credentials ontologythat represents relationships among attributes and credentials.

• Definition of privacy-aware architecture. An important difference between theXACML’s system design and architecture and our proposal is that XACML assumesto have all the information about a requester available at the time of policy evalu-ation and access control decision. In our solution a bidirectional negotiation phasebetween a requester and a service provider is carried out to establish the number andtype of credentials that, on the one hand, are sufficient for the service provision and,on the other hand, minimize the disclosure of personal information. Also, supportfor anonymous interactions is provided.

P3P. The main differences between P3P approach and our system can be summarizedas follow.

• Policy negotiation. P3P does not support privacy practices negotiation. The usersin fact can only accept the server privacy practices or stop the transaction. By con-trast our solution is general enough to support full negotiation, and our architectureprovides a first solution based on data handling policy template customization (seefor more details Section 3.5).

2.2. Location-based access control systems 23

• Attribute-based restrictions. Our system is more expressive than P3P, since it allowsthe definition of attribute-based restrictions on recipients’ profiles, and can be inte-grated with obligations [28] that define actions to be performed after an access hasbeen granted (e.g., notification, deletion, obfuscation). P3P allows the definition ofcategories of recipients only.

• Privacy practices enforcement. P3P does not provide a solution to demonstrate thatthe Web site enforces the privacy practices presented to the users. Although oursolution suffers of the same problem, its integration in the context of the PRIMEinfrastructure mitigates this problem, since PRIME can be considered as a trustedplatform [108].

• Sticky policies. P3P does not provide protection against chains of releases. In oursolution personal data are tagged with data handling policies (i.e., sticky policies[82]). In this way, data handling policies physically follow the data when they aremanipulated by different applications and transferred between different systems.

2.2 Location-based access control systems

The diffusion and reliability that mobile technologies have achieved provide the means toexploit location information for improving current location-based services in a novel way.Location awareness supports an extended context of interaction for each user and resourcein the environment, eventually modeling a number of spatial-temporal relationships amongusers and resources. In a location-aware environment, context is not the static situationof a predefined environment; rather, it is a dynamic part of the process of interacting witha changing environment, composed of mobile users and resources [45].

Location-related information can be classified as follows.

• Punctual location, absolute longitude-and-latitude geographical location provided bysystems like GPS (Global Positioning System). In outdoor and rural environmentsGPS, when at least three satellites are visible, delivers position information with anacceptable accuracy.3 Today, GPS chipsets are integrated into most mainstream cellphones and PDAs; when it is not available, the cellular network itself can be usedas a basic geo-location service [6].

• Logical or local location, composed of location assertions with different levels ofprecision, for example, specifying that the user is in a specific country, city, buildingor room.

3In dense urban areas or inside buildings, localization with GPS may becomes critical because thesatellites are not visible from the mobile terminal. By 2008 the European Union will deploy Galileo, anext-generation GPS system that promises greater accuracy and operation covering both indoors and out,due to stronger radio signals that should penetrate most buildings.

24 2. Related work

Obviously, given the necessary background information (e.g., in the form of a map withgeographical coordinates) there may be a function that maps punctual locations to logicalones. Recent research has proposed many location techniques producing a user’s logicallocation, punctual location or both, depending on application requirements. Locationtechniques have been proposed for local wireless networking: for example, Microsoft Re-search’s RADAR system requires an initial calibration in which 802.11 readings are madeon a 1 meter (1m) grid. Then, this grid is used for positioning 802.11 access points (APs).If the APs are positioned correctly, knowing the readings of a device is sufficient for esti-mating its location. The Place Lab project [117] does not rely on the availability of a gridof previous readings; rather, it predicts location via the positions of the APs, read froma database cached on each device. Today, the public database wigle.net contains theposition of more than 2 million APs in the US and in Europe, providing quick-and-dirty lo-cation in some key urban areas. Location techniques have also been proposed for GSM/3Gmobile networks. Technical improvements of GSM/3G and the widespread adoption oftheir mobile devices make GSM/3G positioning systems some of the most suitable tech-nologies for the delivery of physical locations of users. Several location techniques havebeen studied and developed for achieving a good level of performance and reliability inany environment with few limitations [68, 123].

As a secondary effect of such innovative services, however, privacy concerns are increas-ing, raising a demand for more sophisticated solutions for granting users different levelsof location privacy. In this section, we present the existing literature on location-basedaccess control systems, and then we discuss existing privacy solutions aimed at protectinglocation information privacy.

2.2.1 Location-Based Access Control (LBAC)

The definition of a LBAC model is an emerging research issue that has not been addressedby the security and access control research community yet. The notion of location-basedaccess control is however in itself not new. Some early mobile networking protocols al-ready incorporate the notion of linking the physical position of a terminal device and itscapability of accessing network resources [4]. Widespread adoption of wireless local net-works has triggered new interest in this topic: some recent studies focus on location-basedinformation for monitoring users movements on Wireless Lan [57] and 802.11 Networks[59], while Myllymaki and Edlund [96] describe a methodology for aggregating locationdata from multiple sources and improve this way location tracking features. Other re-searchers choose a line closer to our approach by describing the architecture and operationof an access server module for LBAC in local wireless networks [100, 127]. Access controlto wireless networks complying with IEEE 802.11 family of protocols is currently beingstandardized. However, these contributions are addressed to strengthen the well-knownsecurity weaknesses of wireless network protocol rather than defining a general, protocol-independent model for LBAC. The need for a protocol-independent location technique has


been underlined by an interesting study exploiting heterogeneous positioning sources likeGPS, Bluetooth and WaveLAN for designing location-aware applications [100]. Location-based information and their management are also the topics of a recent study by Varsh-ney [127] in the area of mobile commerce applications. This is a related research area thathas strong connection with location systems and is a promising source of requirementsfor LBAC models, for instance when particular purchase options or taxation exemptionsmust be applied to customers of a specific region or country.

Few papers consider location information as a mean to improve security. Damiani etal. [47] present new ideas and open issues related to location-based access control andpredicates, discussing dynamic context representations and their integration with currentapproaches to access negotiation in mobile scenarios. Other contributions (e.g., [116])exploit location-based access control in sensor networks. Zhang and Parashar [140] pro-pose a location-aware extension to Role-Based Access Control (RBAC) [115] suitable forgrid-based distributed applications. All these contributions, however, do not address theuncertainty-related features of location information.

Finally, other researchers took a different approach, regarding location information asa resource to protect against unauthorized access or disclosure. In this context, the needof location privacy protection arises. We discuss on this issue in the next section.

2.2.2 Location privacy protection

Location privacy can be defined as the right of the users to decide how, when, and for whichpurposes their location information can be released to other counterparts [12]. Locationprivacy can assume several meanings and pursue different objectives depending on thescenario in which the users are moving and on the services the users are interacting with.The following categories of location privacy can then be identified [12].

• Identity privacy. The main goal is to protect the identities of the users associatedwith or inferable from location information. To this purpose, protection techniquesaim at minimizing the disclosure of data that can let an attacker infers a user identity,such as home and work addresses. Identity privacy is suitable in application contextsthat do not require the identification of the users as a fundamental information forservice provisioning. For instance, many online services provide a person with theability to establish a relationship with some other entities (e.g., anonymous chats)or with some applications (e.g., allergy warning) without her personal identity beingdisclosed to those entities. The best possible location measurement can be providedto others entities but the identity of the users must be preserved.

• Position privacy. The main goal is to protect the position information of individualusers, by perturbing corresponding information and decreasing the accuracy of loca-tion information. Position privacy is suitable for environments where users’ identitiesare required for a successful service provisioning. A technique that most solutions

26 2. Related work

exploit, either explicitly or implicitly, consists in reducing the accuracy by scalinga location to a coarser granularity (e.g., from meters to hundreds of meters, from acity block to the whole town, and so on).

• Path privacy. The main goal is to protect the privacy of information associated withusers motion, such as the path followed while traveling or walking in a urban area.There are several location-based services (e.g., personal navigation systems) thatcould be exploited to subvert path privacy or to illicitly track users. Path privacyis the most complex category of location privacy and can refer to identity privacyand/or position privacy.

Accordingly to the categories of location privacy described, three different classes oflocation privacy techniques can be introduced: anonymity-based, obfuscation-based, andpolicy-based. These classes are partially overlapped in scope and could be potentiallysuitable to cover requirements coming from one or more of the categories of location pri-vacy. Anonymity-based and obfuscation-based techniques can be usually regarded as dualcategories. Whereas anonymity-based techniques have been primarily defined to protectidentity privacy and are less suitable for protecting position privacy, obfuscation-basedtechniques are well suited for position protection and less appropriate for identity pro-tection. Anonymity-based and obfuscation-based techniques are well-suited for protectingpath privacy. Nevertheless, more studies and proposals have been focused on anonymity-based rather than on obfuscation-based techniques. Policy-based techniques are in generalsuitable for all the location privacy categories. However, they can be difficult to understandand manage for end users. No technique is able to provide a general solution satisfying allthe privacy requirements. In the following, the major privacy preserving techniques aimedat location privacy protection are analyzed and compared with our solution (see Chapter5).

Anonymity-based techniques. This class of techniques gathers solutions based on thenotion of anonymity [26, 28, 61, 66]. Anonymity typically refers to an individual, and itstates that an individual (i.e., her identity or personally identifiable information) shouldnot be identifiable.

Beresford and Stajano [25, 26] propose a method, called Mix zones, which uses ananonymity service based on an infrastructure that delays and reorders messages fromsubscribers within pre-defined zones. The Mix zone model is based on the concepts ofapplication zone and mix zones. An application zone represents homogeneous applicationinterests in a specific geographic area, while a mix zone represents an area where a usercannot be tracked. Within mix zones, a user is anonymous in the sense that the identitiesof all users coexisting in the same zone are mixed and become indiscernible. The Mix zonemodel is managed by a trusted middleware that lies between the positioning systems andthe third party applications and is responsible for limiting the information collected by


applications. Furthermore, the infrastructure makes a user entering the mix zone unlink-able from other users leaving it. The authors provide an analysis of an attacker behaviorby defining and calculating the anonymity level assured to the users, that is, the degreeof privacy protection in terms of uncertainty. They show that the success of an attackaimed at recovering users identities is an inverse measure of the anonymity provided bythe privacy service. The authors argue that an attacker aiming at reducing the anonymitylevel within a mix zone can determine the mapping between ingress and egress paths thatexhibits the highest probability. It is however necessary to measure how the probabilityof the selected mapping varies when this mapping is compared with all the other possiblemappings. The anonymity level is then calculated by measuring the level of uncertaintyof the selected mapping between inbound and outbound paths. The uncertainty is com-puted through traditional Shannon’s entropy measure [120]. If the entropy is equal to bbits, 2b users are indistinguishable. A lower bound to the level of anonymity of a user uis calculated as the level of anonymity provided by assuming that all users exit the mixzones from the location that has highest probability. To conclude, the Mix zones modelis aimed at protecting long-term user movements still allowing the interaction with manylocation-based services. Mix zones effectiveness is strongly dependent on the number ofusers joining the anonymity service and on the number of users physically co-located inthe same mix zone at the same time.

Other works are based on the concept of k -anonymity meaning that the observed datacannot be related to fewer than k respondents [43, 113]. In other words, the conceptof k -anonymity tries to capture a traditional requirement followed by statistical agenciesaccording to which the released data should be indistinguishably related to no less than acertain number (k) of users. Traditionally, k -anonymity is based on the definition of quasi-identifier that is a set of attributes exploitable for linking. The k -anonymity requirementthen states that each release of data must be such that every combination of values of quasi-identifiers can be indistinctly matched to at least k individuals. Bettini et al. [28] proposea framework able to evaluate the risk of sensitive location-based information dissemination,and introduces a technique aimed at supporting k-anonymity. Their proposal puts forwardthe idea that the geo-localized history of the requests submitted by a user can be consideredas a quasi-identifier that can be used to discover sensitive information about the user. Forinstance, a user tracked during working days is likely to commute from her house to theworkplace in a specific time frame in the morning and to come back in another specifictime frame in the evening. This information could be used to re-identify the user. Inthe framework proposed in [28], based on the concepts of quasi-identifier and historicalk-anonymity, the service provider, which gathers both the users’ requests for services andthe sequence of updates to users’ locations, should never be able to link a subset of requeststo a single user. To make this possible, there must exist k users having a personal historyof locations consistent with the set of these requests that have been issued. Intuitively, apersonal history locations of a user is consistent with a set of service requests when foreach request there exists a location in the personal history of locations where the user

28 2. Related work

could have made the request. The kind of solution is highly dependent on the actualavailability of indistinguishable histories of locations: if k indistinguishable histories donot exist, k -anonymity cannot be preserved. The worst case happens when a given userhas a history different from all the others, meaning that the user cannot be anonymizedand she is always identifiable.

Gruteser and Grunwald [66] propose a middleware architecture and an adaptive al-gorithm to adjust location information resolution, in spatial or temporal dimensions, tocomply with the specified anonymity requirements. To this purpose, the authors introducethe concepts of spatial and temporal cloaking used to transform a user location to complywith the requested level of anonymity. Spatial cloaking guarantees the k -anonymity re-quired by the users by enlarging the area where a user is located until the area contains kindistinguishable users. The same reasoning could be applied to temporal cloaking, whichis an orthogonal process with respect to the spatial one. Temporal cloaking could providespatial coordinates with higher accuracy, but it reduces the accuracy in time. The keyfeature of the adaptive cloaking algorithm is that the required level of anonymity can beachieved for any location.

Gedik and Liu [61] describe another k-anonymity model aimed at protecting locationprivacy against various privacy threats, and provide a framework supporting location k-anonymity. Each user is able to define the minimum level of anonymity and the maximumacceptable temporal and spatial resolution for her location measurement. A messageperturbation engine provides location anonymization of request messages sent by usersthrough identity removal and spatio-temporal obfuscation of location information. Thisengine is composed of four major components that process each incoming message: i) thezoom-in component identifies all pending messages; ii) the detection component identifiesthe k messages that can be used in the anonymization process; iii) the perturbation compo-nent applies a perturbation algorithm on messages identified by the detection componentand forwards the generated messages to the location-based service; and iv) the expirationcomponent deletes all expired messages. The suitability of this method depends on thenumber of messages received by the location protection component, responsible for mes-sage perturbation, and on the message expiration. If the expiration timeout is too short,many messages will be dropped; if it is too long, many useless messages will be processed.

Mokbel et al. [94] present a framework, named Casper, aimed at changing traditionallocation-based servers and query processors to provide the users with anonymous services.Users can define their privacy preferences through a k, which is the number of users tobe indistinguishable, and Amin representing the minimal area that the user is willing torelease. Casper framework is composed by a location anonymizer, responsible for perturb-ing the users location to achieve the privacy preferences of users, and by a privacy-awarequery processor, responsible for the management of anonymous queries and spatial cloakedareas.

Another line of research that relies on the concept of anonymity is aimed at protectingthe path privacy of the users [65, 67, 71]. This research area is relevant since many


location tracking applications have been designed and developed also for devices withlimited capabilities (e.g. cellular phones). In addition, data about users moving in aparticular area are collected by external services, such as navigation systems, which usethem to provide their services effectively. In such a worrisome scenario the need for privacytechniques protecting the privacy of the path becomes urgent.

Gruteser et al. [65] propose a solution to path privacy protection based on pathanonymization. A path is anonymized by associating a pseudonym with a user location.However, an attacker that gains access to this information is able to associate a path anda pseudonyms with a single user by looking at path information such as the place in whichthe user stays during the night. To the purpose of strengthening the anonymity, multiplepseudonyms, which change over time, can be associated with a single user. The authorsargue that it is difficult to provide strong anonymity for path protection because it wouldrequire the existence of several users traveling along the same path at the same time, anassumption that often cannot be satisfied in a real world scenario. Hence, they providestwo techniques for weaker anonymity: path segmentation and minutiae suppression. Withweaker anonymity users could potentially be linked to their identities, but this requireshuge efforts. Path segmentation partitions a user’s path in a set of smaller paths andchanges, at the same time, the associated pseudonym. Path segmentation is usually im-plemented by defining a segment duration and mean pause. After the segment durationtime, location updates are suppressed for the given pause period. Minutiae suppressioninstead suppresses those parts of a path that are more distinctive and could bring to aneasy association between a path and an identity. The suitability of these techniques ishighly dependent on the density of users in the area in which the adversary collects lo-cation samples. In areas with low density of users, an adversary has a good likelihood oftracking individuals, whereas in areas with many overlapping paths, linking segments toidentities can be extremely difficult.

Other relevant works consider path protection as a process whose outcome must bemanaged by a service provider. Privacy techniques then have to preserve a given level ofaccuracy to permit a good quality of service provisioning. Gruteser and Liu [67] present asolution based on the definition of a sensitivity map composed by sensitive and insensitivezones. The work defines three algorithms aimed at path privacy protection: base, bounded-rate, and k -area. The base algorithm is the simplest algorithm; it releases location updatesthat belong to insensitive areas only, without considering possible inferences made byadversaries. The bounded-rate algorithm permits the customization of location updatesfrequency to reduce the amount of information released near a sensitive zone and to makethe adversary process more difficult. Finally, the k -area algorithm is built on top ofsensitivity maps that are composed of areas containing k sensitive zones. Location updatesof a user entering a region with k sensitive areas are temporarily stored and not released. Ifa user leaving that region has visited at least one of the k sensitive areas, location updatesare suppressed; otherwise they are released. Experiments show that the k -area algorithmgives the best performance in terms of privacy, minimizing the number of location updates

30 2. Related work

suppression. Ho and Gruteser [71] introduce a path confusion algorithm. This algorithmis aimed at creating cross paths of at least two users. In this case, the attacker cannotrecognize which path has followed a specific user.

Summarizing, anonymity-based techniques are suitable for all those contexts in whichthe identity of the users is not relevant. A major drawback shared by techniques basedon anonymity is that their applicability and performances depend on the number of usersphysically located in a particular area. By contrast, our solution focuses on the protectionof location privacy in those cases where identification of users is required and, conse-quently, anonymity is not suitable [52, 113]. Our approach then is complementary, ratherthan alternative, to anonymity-based solutions because it is focused on situations wherelocations cannot be anonymized.

Obfuscation-based techniques. This class of techniques gathers solutions based onthe notion of obfuscation. Obfuscation is the process of degrading the accuracy of theinformation, to provide privacy protection. Differently from anonymity-based techniques,the main goal of obfuscation-based techniques is to perturb the location information stillmaintaining a binding with the identity of the users.

Duckham and Kulik [52] define a framework that provides a mechanism for balancingthe individual needs for high-quality information services and for location privacy. Theproposed solution is based on the imprecision concept, which indicates the lack of specificityof location information (e.g., a user located in Milan is said to be in Italy). The authorspropose to degrade location information quality and to provide obfuscation features byadding n points, at the same probability, to the real user position. The algorithm assumesa graph-based representation of the environment. When a user accesses a service askingfor proximity information (e.g., asking for the closest restaurant), her location is perturbedby releasing a set O of points containing the real user position. The service receiving therequest calculates the query result that is returned to the user: in the best case the userreceives a single response, in other cases, depending also on the degree of obfuscation, itcould receive a set of closest points of interest. Duckham and Kulik [53] present someobfuscation methods that are validated and evaluated through a set of simulations. Theresults show that obfuscation can provide at the same time both high quality of serviceand high privacy level.

Other proposals are based on the definition of a gateway that mediates between locationproviders and location-based services. Openwave [104], for example, includes a locationgateway that obtains location information of users from multiple sources and delivers them,possibly modified according to privacy requirements, to other parties. Openwave assumesthat users specify their privacy preferences in terms of a minimum distance representingthe maximum accuracy they are willing to provide.

Bellavista et al. [24] present a solution based on a middleware that balances the levelof privacy requested by users and the need of service precision. The location information is


then provided at a proper level of granularity depending on privacy/efficiency requirementsnegotiated by the parties. A downscaled location information (with lower precision andlower geographical granularity) is returned, instead of exact user positions. This solutionhowever only considers a context based on points of interest, and it relies on the adoptionof symbolic location granularity (e.g., city, country, and so on), forcing the privacy levelto the predefined choices.

In summary, current obfuscation-based solutions have some shortcomings that ourproposal tries to address. First, they do not provide a quantitative estimation of theactual privacy level, which makes them highly dependent on the application contextsand difficult to integrate into a full fledged location-based application scenario [9, 22].Next, just a single obfuscation technique is usually implemented. By contrast, our workintroduces an estimator of the privacy level, defines more obfuscation techniques anddemonstrates the benefits of their composition.

Policy-based techniques. This class of techniques gathers solutions based on the no-tion of privacy policies. Privacy policies define restrictions that must be enforced whenlocation of users is used by or released to external parties.

Hengartner and Steenkiste [70] describe a method based on digital certificates combinedwith rule-based policies to protect location information.

Hauser and Kabatnik [69] address the location privacy problem in a privacy-awarearchitecture for a global location service, which allows users to define rules that will beevaluated to regulate access to location information. By means of these rules, a user candefine the entities allowed to access her location data at a specified granularity level.

The IETF Geopriv working group [62] addresses privacy and security issues relatedto the disclosure of location information over the Internet. The main goal is to definean environment (i.e., an architecture, protocols, and policies) supporting both locationinformation and policy data. Geopriv defines the Presence Information Data Format Lo-cation Object (PIDF-LO) [107] as an extension of the XML-based Presence InformationData Format (PIDF) that provides presence information about a person (e.g., if a useris online or offline, busy or idle, away from communication devices or nearby). PIDF-LOis used to carry a location object, that is, a location information associated with privacypolicies, within PIDF. The Geopriv infrastructure relies on both authorization policiesand privacy rules. Authorization policies pose restrictions on location management andaccess by defining conditions, actions, and transformations. In particular, a transfor-mation specifies how the location information should be modified before its release, bycustomizing the location granularity (e.g., city neighborhood, country, and so on), or bydefining the altitude, latitude, and longitude resolution. Privacy rules are associated withlocation information and define restrictions on how the information can be managed. Forinstance, an authorization can state that a recipient is allowed to share a piece of locationinformation that is associated with an expiration time.

32 2. Related work

Other works used the Platform for Privacy Preferences (P3P) [128] to encode usersprivacy preferences. P3P enables Web-sites to define privacy practices in a XML-basedformat, and users to check these privacy practices to decide whether they are compatiblewith their privacy preferences. Hong et al. [72] provide an extension to P3P for represent-ing user privacy preferences for context-aware applications. Langheinrich [85] proposesthe pawS system that provides a privacy enabling technology for end users. The pawSsystem allows data collectors to state and implement data usage policies based on P3P,and it provides data owners with technical means to manage and check their personalinformation.

In summary, policy-based techniques allow the definition of policies that can be simplyadapted to the user needs restricting the location information management and disclosure.Although the adoption of policies-based preferences is probably, from a privacy point ofview, the most powerful and flexible technique, it can be very complex and unmanage-able for end users. Often, users are not willing to directly manage complex policies andrefuse participation in pervasive environments. Also, the users remains not aware of theconsequences of potential side-effects in policies evaluation.

2.3 Chapter summary

This chapter has examined related work and anticipated some comparisons with our so-lution. In particular, we have seen that our work has points in common with two mainclasses of work. The first class is the work on access control, related to our privacy-awareaccess control system (see Chapter 3). More precisely, the works closest to ours are rep-resented by the works in XACML [56] and in P3P [21, 128]. The second class is the workon location-based services and location privacy protection, related to our location privacysolution validated in the context of our location-based access control system (see Chapter4 and 5). In this case, the works closest to ours are represented by the works developedin the context of obfuscation-based techniques for location privacy.

3A privacy-aware access control

system

This chapter presents our privacy-aware access control system designed and developed inthe context of the European PRIME project [108]. This system allows the evaluationand enforcement of access control and release policies regulating access to service/dataand release of personal identifiable information, respectively, and provides a mechanismto define data handling constraints for the protection of users sensitive data, after theirrelease to external parties.

3.1 Introduction

The increased power and interconnectivity of computer systems available today providethe ability of storing and processing large amounts of data, including personal informationof users and customers of commercial and public services. The vast amount of personalinformation thus available on the Web has led to growing concerns about the privacy of itsusers, which has been recognized as one of the main reasons that prevents users from usingthe Internet for accessing online services. Users in fact prefer not to be under the controlof anyone at anytime. In this context, the concept of privacy control is introduced, andit should encompass two aspects: to guarantee the desired level of privacy of informationexchanged between different parties by controlling the access to services/resources; andto control all secondary uses of information disclosed for the purpose of access control en-forcement. This scenario poses an entirely new set of challenges to access control systems,since an important service for helping users to keep the control over their personal infor-mation is represented by access control solutions enriched with the ability of supportingprivacy requirements [17]. Some of the main requirements are discussed below [31].

• Interchangeable policy format. Parties need to specify protection requirements on thedata they make available using a format both human- and machine- readable, easy toinspect and interchange. This format should be simple to complement and check on

34 3. A privacy-aware access control system

the part of parties for being compliant with externally defined privacy regulations;also, it should be simple enough to be readily understood by non-specialists.

• Interactive enforcement. Traditional access control systems operate in two phases:1

an evaluation phase evaluates the access policy and makes a decision (granted ordenied), and an enforcement phase applies the decision. However, the result of theevaluation phase often is more than just granting or denying an action. In fact, theassumption that the users make available all their data at policy evaluation time toaccess a service does not hold anymore. Therefore, rather than providing a simple yesor no decision, the evaluation phase should provide a way of interactively applyingcriteria to retrieve the correct sensitive information, possibly managing complex userinteractions such as the acceptance of written agreements and/or online payment.

• Metadata support. Semi-structured metadata formats are increasingly important forWeb-based systems, and are at the basis of the ongoing Semantic Web initiative ofthe World Wide Web Consortium (W3C) (http://www.w3.org/2001/sw). Privacy-aware access control systems should allow to specify access restrictions based onconditions on metadata describing (meta)properties of the stored data and the users.Metadata are usually considered important for information discovery and retrievalin a networked environment. However, it is also widely recognized that metadatacan be used for controlling access to data.

Traditional access control systems, which are based on regulations (policies) that estab-lish who can, or cannot, execute which actions on which resources [114], result limiting anddo not satisfy all the above requirements. Although recent advancements allow the speci-fications of policies with reference to generic attributes/properties of the parties and theresources involved (e.g., XACML [56]), access control systems are not designed for enforc-ing privacy policies. Additional privacy requirements that are not addressed by traditionalapproaches include protecting user identities by providing anonymity , pseudonymity , un-linkability , and unobservability of users at communication, system, or application level.Also, selective disclosure of credentials is normally not implemented, because users’ at-tributes, for example inserted into X.509 identity certificates [79] or collected as attributecertificates [58], are defined according to functional needs, making it easier to collectall credentials in a row instead of iteratively asking for the ones strictly necessary for agiven service only. Finally, few proposals have tried to address the problem of how toregulate the use of personal information in secondary applications. The consideration ofprivacy issues introduces the need for rethinking authorization policies and models, andthe development of new paradigms for access control and authorizations specification andenforcement. Two major issues to be looked at are:

1Note that usually an access control system makes use of both authentication and access control servicesto control access of system resources; here we consider only the access control process.

3.2. Privacy-aware access control: key aspects 35

1. access control needs to operate even when interacting parties wish to remain anony-mous or to disclose only specific attributes about themselves;

2. data collected/released during access control as well as data stored by the differ-ent parties may contain sensitive information on which privacy policies need to beapplied.

3.1.1 Outline of the chapter

The remainder of this chapter is organized as follow. Section 3.2 discusses the key as-pects of our privacy-aware access control system. Section 3.3 presents our scenario andbasic concepts. Section 3.4 describes an access control model and language for definitionand enforcement of powerful and flexible access restrictions based on generic propertiesassociated with subjects and objects. Section 3.5 presents a data handling model andlanguage allowing the users to define restrictions on management of their private data insecondary applications. Section 3.6 gives an overview of our privacy-aware access controlsystem prototype that integrates access control and data handling policies evaluation andenforcement. Section 3.7 presents a chapter summary.

3.2 Privacy-aware access control: key aspects

An environment well-suited for users needing a private and secure way for using e-servicesshould support at least the following basic requirements.

• Privacy. A digital identity solution should be respectful of the users rights to privacyand should not disclose and manage personal information without explicit consent.

• User-driven constraints. In addition to traditional server-side access control rules,users should be able to specify constraints and restrictions about the usage that willbe done of their information once released to external parties.

• Minimal disclosure. Service providers must require the least set of credentials neededfor service provision, and users should be able to provide credentials selectively,according to the type of online services they wish to access.

• Interactive enforcement. A new way of enforcing the access control process shouldbe defined based on a negotiation protocol aimed at establishing the least set ofinformation that the requester has to disclose to access the desired service.

• Anonymity support. As a special but notable case of minimal disclosure, manyservices do not need to know the real identity of a user. Pseudonyms, multipledigital identities, and even anonymous accesses must be adopted when possible.


• Legislation support. Privacy-related legislation is becoming a powerful driver towardsthe adoption of digital identities. The exchange of identity data should not violategovernment legislations such as the Health Insurance Portability and AccountabilityAct (HIPAA) or Gramm-Leach-Bliley Act (GLB).

These new requirements regarding an improved management of digital identities andprotection of privacy are among the motivations of this thesis, which has been carried outin the context of PRIME project [108], a large-scale research effort aimed at developing anidentity management system able to protect users personal information and to provide aframework that can be smoothly integrated with current architectures and online services.More specifically, providing the users with the control of their personal data and permittinganonymous interactions are some of the main goals of this thesis. Another goal of thisthesis is to define privacy policies governing the system usage to provide a privacy-awareaccess control system. The policies should establish how to use the system, and shouldallow to define trust relationships, privacy preferences, and authorization rules.

A privacy-aware access control system is a framework that, in addition to traditionalaccess control functionalities, guarantees on one side the privacy of information exchangedbetween different parties and, on the other side, provides a solution to control the sec-ondary use of information disclosed in the context of an access control process.

Our privacy-aware access control system deals with five main key aspects: i) resourcerepresentation, writing access control policies where resources to be protected are pointedat via data identifiers and access conditions are evaluated against their attribute valuesis not sufficient anymore. Rather, it is important to be able to specify access controlrequirements about resources in terms of available metadata describing them; ii) subjectidentity, evaluating conditions on the subject requesting access to a resource often meansaccessing personal information either presented by the requester as a part of the authen-tication process or available elsewhere. Identifying subjects raises a number of privacyissues, since electronic transactions (e.g., purchases) require release of a far greater quan-tity of information than their physical counterparts; iii) secondary use, although usersprovide personal information for use in one specific context, they often have no idea onhow such a personal information may be used subsequently. Users should be able to definerestrictions on how their information will be used and processed by external parties. Tothis purpose, an automatic negotiation of preferences between users and servers needs tobe supported; iv) context representation, context information is a set of metadata iden-tifying and possibly describing entities of interest, such as subjects and objects, as wellas any ambient parameter (including location) concerning the technological and culturalenvironment where a transaction takes place. As far as policy enforcement is concerned,context contains information enabling verification of policy conditions and, therefore, itshould be made available to any authorized service/application at any time and in a stan-dard format. Still unauthorized information leaks should be prevented to avoid loss ofprivacy, for example, on the user’s whereabouts [8, 9]. A major factor harnessing the

3.2. Privacy-aware access control: key aspects 37

potential of context representation is lack of a standard context representation metadatalayer. Privacy-aware access control needs a sound standard model for context representa-tion, semantically rich but unambiguous. From the technological point of view, contextmust be highly interoperable, human-readable and processable by machines; v) ontologyintegration, a privacy-aware access control should exploit the Semantic Web to allow thedefinition of access control rules based on generic assertions defined over concepts in theontologies that control metadata content and provide abstract subject domain concepts[16]. A central element of semantic-aware privacy policies is the use of semantic portfoliosupporting controlled access to contextual resources (e.g., personal, company, and publicservices) subject to user-specified privacy constraints.

3.2.1 Privacy policies

To fully address the requirements posed by a privacy-aware access control system, a newprivacy-aware access control model together with the following different types of privacypolicies have been introduced.

• Access control policies. They govern access/release of data/services managed by theparty (as in traditional access control) [114].

• Release policies. They govern release of properties/credentials/personal identifiableinformation (PII) of the party and specify under which conditions they can be re-leased [32].

• Data handling policies. They define how personal information will be (or should be)dealt with at the receiving parties [128].

• Sanitized policies. They provide filtering functionalities on the response to be re-turned to the counterpart to avoid release of sensitive information related to thepolicy itself.

Access control policies. Access control policies define authorization rules concerningaccess to data/services [114]. Authorizations correspond to traditional (positive) rulesusually enforced in access control systems. For instance, an authorization rule can requirea user of age and a credit card number (condition) to read (action) a specific set ofdata (object). When an access request is submitted to a service provider, it is evaluatedagainst the authorization rules applicable to it. If the conditions for the required access areevaluated to true, access is permitted. If none of the specified conditions that might grantthe requested access can be fulfilled, access is denied. Finally, if the current information isinsufficient to determine whether the access request can be granted or denied, additionalinformation is needed, and the requester receives an undefined response with a list ofrequests that she must fulfill to gain the access. For instance, if some of the specified


conditions can be fulfilled by signing an agreement, then the party prompts the requesterwith the actions that would result in the required access.

Release policies. Release policies define the party’s preferences regarding the release ofits PII by specifying to which party, for which purpose/action, and under which conditionsa particular set of PII can be released [32]. For instance, a release policy can state thatcredit card information can be released only in the process of a purchase and to a partymember of Better Business Bureau (BBB). The release of PII may only be performed ifthe release policies are satisfied.

Data handling policies. Data handling policies regulate how PII will be handled at thereceiving parties (e.g., information collected through an online service may be combinedwith information gathered by other services for commercial purposes). Users exploit thesepolicies to define restrictions on secondary use of their personal information. In thisway, users can manage the information also after its release. Data handling policies willbe attached to the PII or data they protect, and transferred as sticky policies to thecounterparts [82].

Sanitized policies. Sanitized policies provide filtering functionalities on the responseto be returned to the counterpart to avoid release of sensitive information related to thepolicy itself (or to the status against which the policy has been evaluated). This happenswhen an undefined decision, together with a list of alternatives (policies) that must befulfilled to gain the access to the data/services, is returned to the counterpart as a resultof an access request evaluation. For instance, suppose that the policy neither satisfied nordenied yet is equal(citizenship,‘EU’). The party can decide to return to the user eitherthe policy as it is or a modified policy (obtained by applying the sanitized policies) simplyrequesting the user to declare its nationality (then protecting the information that accessis restricted to EU citizens).

3.3 Scenario and basic concepts

Our reference scenario is a distributed infrastructure that includes three parties (see Figure3.1):

• users are human entities that request online services;

• service provider is the entity that provides online services to the users and collectspersonal information before granting an access to its services;

• external parties are entities (e.g., business partners) to which the service providermay want to share or trade personal information of users.

3.3. Scenario and basic concepts 39

Figure 3.1: Reference scenario

Although each party can act interchangeably as a user, a service provider, or an ex-ternal party during different transactions, they usually have well defined, fixed roles whenone specific access request is considered. We assume that the service provider collectspersonal data that are necessary to provide access to services and stores them into profilesassociated with each user. A profile can therefore be seen as a container of pairs of theform 〈attribute name,attribute value〉, where attribute name is the name of the attributeprovided by the user and attribute value is its value.

When a user needs to access a service, she is often required to complete a registrationprocess. Registered users are characterized by a unique user identifier (user id, for short).When registration is not mandatory, non-registered users are characterized by a persistentuser identifier (pseudonym) that is generated by the service provider. The pseudonymis automatically sent by the client (e.g., a web browser) to the service provider wheneverthe user submits a request. In this case, personal information is stored under pseudonymsand not users’ real identities.

The set of messages exchanges between a user and a service provider is called negoti-ation [32]. A negotiation always starts with a user request to a service provider and endsexplicitly (done or stop) or implicitly, for example, assumed after a certain timeout period.A negotiation intuitively corresponds to the classical concept of session. During a nego-tiation a user may, similarly to a service provider, require the counterpart to fulfill somerequirements (i.e., provide information) for it to proceed. In others words, a bidirectionalnegotiation is considered where both parties can require the other party to provide themwith certain information or digital certificates necessary for service request or fulfillment.Each party has a portfolio of credentials (digital certificates) and declarations (unsigneddata). Access to services and release of portfolio information are managed according tothe rules specified by the parties. In particular, at service provider side a set of rules (i.e.,access control policies) regulates service access, defining credentials and declarations thatusers must submit to gain the access. At both user and service provider side, rules (i.e.,


release policies) manage the release of personal information that may be requested fromthe counterpart. Such release policies may also allow release of information only if thecounterpart presents some credentials and declarations. For instance, service provider’saccess control policies may require users to submit a credit card number and contact infor-mation to complete a purchase. Since user’s release policies state that contact informationcan be released to other parties without any constraints and credit card information canbe released only to parties that are members of the Better Business Bureau (BBB), theonline transaction can be completed only if the service provider is able to prove that itbelongs to BBB. We assume anonymous communications to be in place. Therefore, at thebeginning of a negotiation, the user is unknown to the service provider, meaning that noinformation about the user has been collected by the service provider.

The same discussion is still valid when an external party wants to access personalinformation of the users stored at the service provider. The only differences are that, inthis case, service provider must be responsible for protecting the privacy of users data,and users are assumed to trust the service provider to faithfully maintain and managetheir personal information, according to their privacy requirements.

In the following, we illustrate the basic concepts of our model in details.

Portfolio

Since we are considering open environments where the decision to grant access to a resourceis often based on different attributes of the requester rather than its specific identity, weassume that each party has a portfolio of declarations and credentials [64], which is usedto gain (or offer) services [32]. The portfolio may also represent views of certificates thatare not actually stored at the party site but can be obtained if needed [122]. This way,the model allows a party to refer to the set of all its possible credentials without need ofmaintaining a copy of each of them. The definition of portfolio introduces the distinctionbetween two types of attributes [32]:

• certified attributes are specified in an electronic credential that is characterized bythe credential’s name, the issuer ’s public key, the subject ’s public key, a validityperiod , a list (possibly empty) of pairs 〈attribute name, attribute value〉 representingthe certified party’s attributes, and a digital signature (e.g., name and surnamecontained in an electronic passport). The subject ’s public key, that is, the public keyof the party to whom the credential was released, can be challenged by parties towhich the credential is presented to make sure that the credential holder is the sameparty to whom the credential was released. This feature is particularly importantin cases where a zero-knowledge credential [34, 35] is submitted. Examples of suchcases are certificates, which certify properties (e.g., membership in a group) of akeyholder without necessarily identifying it, or identity certificates, which certifythe identity of a keyholder. Other examples are those cases where user’s anonymity

3.3. Scenario and basic concepts 41

is to be preserved and therefore no identity information is presented at the servernor stated in the credential [32].

• declared attributes represent statements of a party, with no certification from anylegal authority. A declared attribute is a pair 〈attribute name, attribute value〉 corre-sponding to the party’s attribute (e.g., the professional status of a user communicatedby the user herself).

The set of certified and declared attributes released by a party to the service providerare then stored in the profile associated with the party. To define restrictions or to identifya party based on its attributes, we introduce the concepts of credential term and declarationterm. Let C be a set of credential names and Q a set of predicates including standard built-in mathematical predicates (e.g., equal, notEqual, greaterThan). We define a credentialterm as follows.

Definition 3.3.1 (Credential term). Given a credential name cred name ∈ C, a creden-tial term over cred name is an expression of the form cred name(condition list), wherecondition list is a list of expressions of the form math-pred(attribute name,value) withmath-pred ∈ Q a mathematical predicate, attribute name the attribute’s name as appearsinto the credential cred name, and value is the corresponding attribute’s value.

Expression condition list permits to define a list of conditions that are treated asif ANDed and that allow to define restrictions on a single credential without introducingvariables in the language. We then define a binary predicate credential(ct ,K)∈Q, wherect is a credential term cred name(condition list), and K is the public key or the name ofa trusted authority. Predicate credential is evaluated to true if and only if there existsa credential cred name issued by authority K and such that condition list is satisfied.

Example 3.3.1. An example of credential term is passport(equal(nationality,‘Italian’))denoting a passport credential whose attribute nationality has value Italian. Predicatecredential(passport(equal(nationality,‘Italian’)),K1) is then evaluated to true if thereexists the passport credential issued by K1 certifying that the nationality of the credential’ssubject is Italian.

A declaration term is defined as follow.

Definition 3.3.2 (Declaration term). A declaration term is an expression of the formpredicate name(arguments), where predicate name ∈ Q is the name of a generic predi-cate, and arguments is a list, possible empty, of constants or attributes.

We define a unary predicate declaration(d) ∈ Q, where d is a declaration termpredicate name(arguments). Predicate declaration is evaluated to true if and only ifthere exists a set of attributes such that predicate name(arguments) is satisfied.


Example 3.3.2. An example of declaration term is equal(name,‘Bob’) denoting thename declared attribute whose value is Bob. A corresponding declaration predicate is thendeclaration(equal(name,‘Bob’)).

Declarations and credentials in a portfolio may be organized into a partial order.For instance, an identity-document can be seen as an abstraction for credentialsdriver-license, passport, and identity-card.

Ontologies and abstractions

Our model provides the support for ontologies that permit to make generic assertions onsubjects and objects [48]. More precisely, we use three ontologies: a subject ontology, anobject ontology, and a credential ontology. A subject ontology contains terms that canbe used to make generic assertions on subjects and to define relationships among them(e.g., in a medical scenario possible terms are Physician, Patient, assists). An objectontology contains domain-specific terms that are used to describe resources content suchas Video and shows how. Finally, a credential ontology represents relationships amongattributes and credentials (part-of and is-a relationships) to establish which credentialscan be provided to fulfill a declaration or credential request, and more complex rela-tionships between attributes and abstractions. For instance, an ontology can state thatattributes birth date and nationality are part of driver-license, identity-card,and passport, or that the age of a person can be retrieved by solving “today – birthdate”. In this way, the reasoning process can identify all credentials that a user, for exam-ple, should provide to satisfy a given condition. For instance, suppose that a user can usean online car rental service only if she is an European citizen and she proves the ownershipof a driver license. According to the credential ontology, nationality can be proved eitherby showing the driver-license, identity-card, or passport. The principle of the min-imum information release suggests the user to present her driver-license, to prove boththe requirements. Abstractions can also be defined within the domains of users as wellas of objects. Intuitively, abstractions allow to group together users (objects, resp.) withcommon characteristics and to refer to a whole group with a name.

3.4 Access control model and language

The main functionalities offered by our access control model and language are summarizedas follow.

• Attribute-based restrictions. The language supports the definition of powerful andexpressive policies based on properties (attributes) associated with subjects (e.g.,name, address, occupation) and objects (e.g., owner, creation date). The languageincludes some operators for comparing attribute values and could be extended byadding nonstandard functions.

3.4. Access control model and language 43

• XML-based syntax. The language provides a XML-based syntax for the definition ofpowerful and interoperable access control and release policies.

• Credential definition and integration. The language supports requests for certifieddata, issued and signed by authorities trusted for making the statement, and uncer-tified data, signed by the owner itself.

• Anonymous credentials support. The language supports definition of conditions thatcan be satisfied by means of zero-knowledge proof [34, 35].

• Support for context-based conditions. The language allows the definition of conditionsbased on physical position of the users [9] and context information, and integrationwith metadata identifying and possibly describing entities of interest, such as sub-jects and objects, as well as any ambient parameter concerning the technological andcultural environment where a transaction takes place.

• Ontology integration. Policy definition is fully integrated with subject and objectontologies in defining access control restrictions. Also, the language takes advantagesfrom the integration with credentials ontology that represents relationships amongattributes and credentials.

3.4.1 Description of the access control language

Basic elements of the language

We describe our access control model discussing the basic constructs of the languageused to define access control and release policies.2 First we have identified the followingpredicates that constitute the basic literals that can be used in access control and releasepolicies specification:

• a binary predicate credential(ct ,K)∈Q, where ct is a credential term (see Defini-tion 3.3.1), and K is the name or the public key of a trusted certification authority(CA);

• a predicate declaration(d) ∈ Q, where d is a list of declaration term (see Defini-tion 3.3.2);

• a set of standard built-in mathematical predicates, such as equal(),greater than(), lesser than(), and so forth;

• a set of state-based predicates of the form predicate name(arguments);

• a set of location-based predicates of the form predicate name(arguments);2Although semantically different, access control and release policies are syntactically identical.


• a set of trusted-based predicates of the form predicate name(arguments);

• a set of non predefined predicates that evaluate information stored at the site.

Then we have identified three main basic elements of the language: subject expression,object expression, and conditions. Below, single properties belonging to users and objectsprofiles are referenced through the dot notation. Also, to refer to the requester (i.e., thesubject) and the target (i.e., the object) of the request being evaluated without the needof introducing variables in the language, we use keywords user and object, respectively,whose appearances in a conditional expression are intended to be substituted with actualrequest parameters during run-time evaluation of the access control policy. For instance,Alice.Address indicates the address of user Alice. Here, Alice is the pseudonym of theuser (and therefore the identifier for the corresponding profile), and Address is the nameof the property.

Subject expression. These expressions allow the reference to a set of subjects depend-ing on whether they satisfy given conditions that can be evaluated on the subject’s profile.More precisely, a subject expression is a boolean formula of terms of the form:

• credential(ct ,K), where ct is a credential term (see Definition 3.3.1) and K is apublic key or a trusted CA;

• declaration(d), where d is a list of declaration term (see Definition 3.3.2).

The predicates specified as arguments of the declaration and credential predicatescan be: i) the standard built-in mathematical predicates, ii) location-based predicates,and iii) the non predefined predicates that evaluate information stored at the server. Thefollowing are examples of subject expressions:

• credential(passport(equal(user.job,‘prof’),greater than(user.age,35)),K1)denoting requests made by users with age greater than 35 who are professors. Theseproperties should be certified by showing the passport credential verifiable withpublic key or released by CA K1;

• declaration(equal(user.name,‘Bob’)) denoting requests made by a user whosename is Bob.

Object expression. These expressions allow the reference to a set of objects depend-ing on whether they satisfy given conditions that can be evaluated on the object’s pro-file. More precisely, an object expression is a boolean formula of terms of the formpredicate name(arguments), where arguments is a list, possible empty, of constants orattributes.


The predicates specified in an object expression can be: i) the standard built-in math-ematical predicates, and ii) the non predefined predicates that evaluate information storedat the server. The type of predicates that can be specified in the object expression fieldcan be extended by adding, for example, location-based predicates.

The following are examples of object expressions:

• equal(object.owner,user) denoting all objects created by the requester;

• lesserThan(object.creation date,1971) denoting all objects created before 1971;

• greaterThan(object.age,18) denoting all objects whose attribute age is greaterthan 18.

Conditions. Conditions element specifies conditions that can be brought to satisfactionsat run-time processing of the request. More precisely, conditions are boolean formula ofterms of the form predicate name(arguments), where arguments is a list, possible empty,of constants or attributes.

The predicates specified in the conditions element can be state-based, location-based,trusted-based, standard built-in mathematical, and non predefined predicates. Based onthose predicates four different types of conditions can be stated inside a rule:

• state-based conditions: restrictions based on the environment state. Examples ofthese conditions could be the role adopted inside a particular application, the numberof access to a given data, or time/date restrictions;

• location-based conditions: restrictions based on location information. We extensivelydiscuss on this in Chapter 4;

• trusted-based conditions: restrictions based on the assurance/trust of the environ-ment;

• others conditions: conditions that do not belong to any of the other conditionsclasses.

An example of condition is fill in form(form1) that checks if the form form1 hasbeen filled.

Policy and rule definition

After introducing the basic elements of the language, we define the access control/releasepolicy and rule. An access control policy (release policy, resp.) is composed by one or morerules, composed in OR logic between them, directly associated with an object componentand the related set of actions. Syntactically, an access control policy (release policy, resp.)can be formalized as follows.


Definition 3.4.1 (Access control policy). An access control policy is an expression of theform 〈actions〉 ON 〈object〉 with 〈object expression〉 if 〈rules〉, where:

• actions is the set of actions to which the rules refer (e.g., read, write, and so on);3

• object identifies the object to which the rules refer and corresponds to an objectidentifier or a named abstraction of values, if abstractions are defined on objects;

• object expression is a boolean expression that allows the reference to a set of objectsdepending on whether they satisfy given conditions that can be evaluated on theobject’s profile;

• rules is a set of rules as defined in Definition 3.4.2.

An access control rule (release rule, resp.) represents the basic element used to regulatethe access to the objects at which it is associated. Syntactically, an access control rule(release rule, resp.) can be formalized as follows.

Definition 3.4.2 (Access control rule). An access control rule is an expression of the form〈subject〉 with 〈subject expression〉 can 〈actions〉 for 〈purposes〉 if 〈conditions〉,where:

• subject identifies the subject to which the rule refers and corresponds to a user iden-tifier or a named abstraction of values, if abstractions are defined on subjects;

• subject expression is a boolean expression that allows the reference to a set of subjectsdepending on whether they satisfy given conditions that can be evaluated on the user’sprofile;

• actions is the set of actions to which the rule refers (e.g., read, write, and so on).Note that, at rule level, the actions field can only be a specialization of the actionsfield defined at policy level;

• purposes is the purpose or a group thereof to which the rule refers and representshow the data is going to be used by the recipient;

• conditions is a boolean expression of conditions that an access request to which therule applies has to satisfy.

Fig. 3.2 reports the BNF syntax of the access control language.

3Note that inside the rules the actions field can be refined. Abstractions can also be defined on actions,specializing actions or grouping them in sets.


policy ::= actions ON object WITH object expression IF rulesrules ::= ε | rule | rule or rulesrule ::= subject WITH subject expression CAN actions FOR purposes

IF conditionsactions ::= identifier | abstractionobject ::= identifier | ontology-termobject expression ::= simple-condition | complex-condition and complex-condition |

complex-condition or complex-condition | not complex-conditionsubject ::= identifier | ontology-termsubject expression ::= simple-condition | complex-condition and complex-condition |

complex-condition or complex-condition | not complex-conditionpurposes ::= identifier | abstractionconditions ::= simple-condition | complex-condition and complex-condition |

complex-condition or complex-condition | not complex-conditioncomplex-condition ::= simple-condition | complex-condition and complex-condition |

complex-condition or complex-condition | not complex-condition |ontology-term implied by complex-condition

simple-condition ::= predicate | ontology-term | declaration | credentialpredicate ::= predicate name(attributes)attributes ::= ε | attribute | predicate | attribute, attributes | predicate, attributespredicate name ::= stringattribute ::= stringontology-term ::= stringidentifier ::= stringabstraction ::= string

Figure 3.2: BNF syntax of the access control policies

3.4.2 A XML-based syntax for access control and release policies

Beside the formal definition of the access control model and language, we provide a XML-based syntax for access control and release policies specification. This syntax has beenused in the development of our privacy-aware access control system prototype carried outin the context of the European PRIME project [108] (see Section 3.6). XML appearsa natural choice as the basis for the common security policy languages, due to the easewith which its syntax and semantics can be extended and the widespread support that itenjoys from all the main platform and tool vendors. Also, XML-based languages fosterinteroperability and scalability. In this section, we briefly review the XML-based syntax(see Appendix A) used for specifying the elements of access control and release policies.

Subject and subject expression. Based on the syntax provided in Appendix A,subject and subjectExprs elements are used to specify the subject and the sub-ject expression fields of a policy. These XML elements define an identifier or an ab-straction that refer to a set of users, and the set of conditions to be evaluated againstrequester’s profile, respectively. An example is provided in the following where any user


must provide her name (i.e., name.given) and surname (i.e., name.last) proofed by a X.509identity-document released by the Italian public administration, and must be of age (nocertification is requested) to gain the access to a particular object.

<subject>any</subject>

<subjectExprs>

<group>

<condition name="exist">

<argument isLiteral="false">name.given</argument>

</condition>

<condition name="exist">

<argument isLiteral="false">name.last</argument>

</condition>

<evidence>

<issuer>ItalianPublicAdministration</issuer>

<proofMethod>X.509</proofMethod>

<type>identity-document</type>

</evidence>

</group>

<group>

<condition name="greaterThan">

<argument isLiteral="false">age</argument>

<argument isLiteral="true">18</argument>

</condition>

<evidence/>

</group>

</subjectExprs>

To conclude, group element groups different conditions that have to be satisfied bythe same evidence element (i.e., the same credential), which in turn defines restrictionson the certification type. This avoids, for instance, that a request for name.given andname.last is satisfied by two different credentials.

Object and object expression. Based on the syntax provided in Appendix A, objectand objectExprs elements are used to specify object and object expression fields of apolicy. These elements identify an object or a set of objects at which the policy rulesrefer, by specifying the object identifier or abstraction and the set of conditions to beevaluated against object’s profile.

As an example, the set of all the credit cards (i.e., cc info) with VISA circuit andwhose expiration date was before the December 2000 is specified by the following XMLelements.

<object>cc_info</object>

<objectExprs>

<condition name="equal">

<argument isLiteral="false">circuit</argument>


<argument isLiteral="true">VISA</argument>

</condition>

<condition name="lesserThan">

<argument isLiteral="false">expiration</argument>

<argument isLiteral="true">12/00</argument>

</condition>

</objectExprs>

Conditions. Each condition type in the conditions field of a policy (i.e., stated-based,location-based, trusted-based, and generic conditions) is defined by means of an ad-hocXML element (see Appendix A): stateExprs, lbsExprs, trustExprs, genericExprs. Inthe following, we provide an example of location-based condition stating that the countryunder which the roaming phone of the requester (i.e., SIM ) is registered should be ‘Italy’to have the request satisfied.

<lbsExprs>


<argument isLiteral="false">SIM</argument>

<argument isLiteral="true">Italy</argument>

</condition>

</lbsExprs>

The same syntax of lbsExprs element is used for all types of conditions.

Actions. A set of actions is defined by an actions element as follow.

<actions>

<action>read</action>

<action>write</action>

</actions>

Purposes. A purpose or a group thereof are defined by a purposes element as follow.

<purposes>

<purpose>scientific</purpose>

<purpose>research</purpose>

</purposes>

Example 3.4.1. In the following, for sake of clarity and conciseness, access control andrelease policies will be provided in the simplified form showed in Table 3.1, rather thanwith our complete XML-based syntax (see Appendix A). As an example, suppose that ACMEcompany provides a set of services such as rent-a-car, book-a-flight, and flight+hotel toits users. Users release their data to ACME to gain access to the services. ACME definesthe access control policies in Table 3.1 to protect the access to the data stored locally. Inparticular, AC1 is composed by three rules that regulate access to valid cc info. An access


Access Control Policiesobject action AC Rules Description

AC1 cc info withgreaterThan( ob-ject.expiration,today)

read any withˆcredential(employeeCard(equal(

user.job,‘Director’)),ACME) anddeclaration(equal(user.company,‘ACME’))

˜can read forˆ

marketing and service release˜

ifˆin area(user.sim,‘ACME’) and

log access()˜

ACME’s directors are au-thorized to read valid(i.e., not yet expired)cc info for marketingand service release pur-poses, if they are locatedinside the ACME companyand access is logged.

any withˆcredential(employeeCard(equal(

user.job,‘Seller’),equal(user.jobLevel,‘A’)),ACME) and declaration(

equal(user.company,‘ACME’))˜

can read for service release iflog access()

Sellers of level A of ACMEare authorized to readvalid cc info for servicerelease purpose if accessis logged.

any withˆcredential(employeeCard(

equal(user.job,‘BusinessConsultant’)),ACME)

˜can read for

reimbursement

ACME’s business consul-tants are authorized toread valid cc info for re-imbursement purpose.

AC2 personal info withgreaterThan( ob-ject.age, 18)

read any withˆcredential(employeeCard(equal(

user.job,‘BusinessConsultant’),greater than(user.jobLevel,‘C’)),ACME) and declaration(equal(

user.company,‘ACME’))˜

can read

for fiscal duties

A business consultantof ACME, with job levelgreater than C, can readpersonal info of users ofage for attempting fiscalduties.

AC3 email read any withˆcredential(identity card(

exist(user.name.given),exist(user.name.last)),K1) anddeclaration(equal(user.company,‘ACME’))

˜can read

for notification iffill in form(‘Notification Form’)

ACME’s users providing anidentity card certifyinggiven and last name canread email for notifica-tion purpose after fillingnotification form.

Table 3.1: An example of access control policies (release policies, resp.)

control policy is evaluated to true if at least one rule is satisfied, that is. subject expressionand conditions of the rule are satisfied. AC2 and AC3 are both composed by a single rulethat regulates access to personal info of users of age and email, respectively.

To conclude, although the definition of access control and release policies permits toprotect access to data and services and release of personal data, respectively, no solutionis provided for regulating how PII must be used and processed after its release. To thispurpose, we define data handling model and language.

3.5. Data handling model and language 51

3.5 Data handling model and language

Today information technology gives organizations the power to gather and disclose vastamounts of personal information. Privacy has been often identified as one of the majorconcern that prevents users from fully accessing to online transactions. To tackles with thisproblem, in addition to solutions protecting access and usage of users sensitive information[32], those who collect and disseminate data should be responsible for maintaining privacy[128].

A number of useful privacy enhancing technologies (PETs) has been developed fordealing with privacy issues and previous works on privacy protection have focused on anumber of related topics [17, 40, 46, 81, 124, 135]. Despite the benefits of such solutions,few proposals have addressed the problem of how to regulate the use of personal infor-mation in secondary applications. Users do not always realize that the information theydisclose for one purpose (e.g., name, date of birth, and address within an online transac-tion) may also have secondary uses (e.g., access to existing data for purposes of groupingtogether users on the basis of common characteristics such as age or geographic location).Therefore, even if users consent to the initial collection of their personal information,they must also be provided with the possibility to specify whether or not to consent tothe future uses of that information in secondary applications. To address this issue, itis widely recognized that a standardized format for privacy policies would allow users toquickly assess whether a particular site’s privacy policy satisfies their privacy goals. Thisidea was behind the development of approaches like the Platform for Privacy PreferencesProject (P3P) [128] and PReference Expression for Privacy (PREP) [2]. Although theseapproaches represent a first step towards the development of a solution for supportinguser privacy preferences, a much deeper integration between privacy and access controlrequirements is needed. In particular, a privacy-aware access control solution supportingrestrictions on secondary use should be simple and expressive enough to support, amongothers, the following privacy requirements [50, 105].

• Openness. Policies and privacy practices should be transparent and fully under-standable for all parties.

• Individual control. Users should be able to specify who can see what informationabout them and when.

• Collection limitation. Parties collecting personal data for the purposes of a trans-action must gather no more data than what strictly needed for carrying out thetransaction itself.

• Purpose specification. Those who collect and disseminate personal data must specifythe purposes for which they need these data. Collected data must therefore be usedonly for specified purposes.


• Consent. Users should be able to give their explicit and informed consent on how touse their personal data.

• Data quality. Those who collect and disseminate personal data must maintain accu-rate information. Users, therefore, should be able to verify their personal informationand modify it when needed.

• Data security. Adequate security mechanisms for data protection have to be applied,according to the sensitivity of collected personal data.

Our privacy-aware access control solution is based on data handling policies (DHPs, forshort), respectful of the above requirements, which provide the users with the possibilityto define how their PII can be subsequently used by the service provider and/or externalparties. A data handling policy physically follows the data when they are released to anexternal party, thus building a chain of control coming from the data owner.

In the data handling policy specification, two issues need to be discussed: by whom andhow a policy is defined. With respect to the first issue, different strategies are possible,each one requiring different levels of negotiation between a user and a service provider.We consider the following three possibilities.

• Server-side. A service provider defines its data handling policies and a user canaccept or reject them according to her privacy preferences. This “all or nothing”approach to secondary use is similar to what happen in a P3P-like scenario andtherefore has the same drawbacks.

• User-side. A user defines its data handling policies and a service provider can acceptor reject them according to its privacy preferences. This approach could not beapplicable in a real scenario since it is unlikely that service providers are willing toaccept whatever privacy preference policy from users.

• Customized. When a user requires a service, a predefined policy template is providedby the service provider as a starting point for creating data handling policies. Thetemplate is customized to meet different privacy requirements. A user can directlycustomize the template or it can be supported by a customization process thatautomatically applies some user privacy preferences. If the customized data handlingpolicy will be accepted by the service provider, the personal information provided bythe user will be labeled with the customized data handling policy. This representsthe most flexible and balanced strategy for the definition of a data handling policy.

In summary, server-side and user-side are the opposite endpoints of all possible ap-proaches in the definition of privacy rules that balance between service providers andusers needs. Since the customized approach represents a good trade-off between the power


given to the service providers and the protection assured to the users, we adopt it in thefollowing.

With respect to the second issue (i.e., how a DHP is defined), we first need to considerhow data handling policies relate to traditional access control policies. Every access requestany party makes has to be first checked against access control policies of service provider.If an access request satisfies at least one access control policy, then the service providerhas to verify data handling policies possibly attached to the requested information. Inparticular, there may exist one or more data handling policies and each of them canimpose different restrictions on how such data can be used in secondary applications.Syntactically, access control policies and data handling policies are similar, since a datahandling policy regulates which subject can execute which actions on which resourcesand under which conditions. Similarities and relations with access control policies let toconsider two approaches in the definition of a data handling policy.

• Integrated policies. Traditional access control policies are extended by adding a DHPcomponent that should specify additional conditions (e.g., research purpose only, nodisclosure, delete after 10 days, and so on) regulating under which circumstancesthe personal information disclosed by the server can be used. This approach has themain disadvantage to make the overall policy less clear and requires some specificmechanisms to transfer DHP rules together with data.

• Stand-alone policies. Data handling policies are defined as independent rules. There-fore, a data handling policy should represent the users’ privacy preferences andshould then include different components that allow to define how the external par-ties can use personal data. Personal data are then tagged with such data handlingpolicies.

Although the stand-alone option can introduce some redundancy in policy definition,it provides a good separation between policies that are used with two different purposes.This clear separation makes data handling policies more intuitive and user-friendly, andimplicitly suggests the differences with access control policies. Also, the definition of stand-alone policies reduces the risks of unprotected data types and allows the customizationof additional components such as recipients, actions, and so on. Finally, an additionalmotivation to prefer stand-alone data handling policies is that some of the conditions (e.g.,some obligations) do not necessarily depend on access control events, and then cannot beenforced just by an access control system. For instance, the obligation condition “deletedata after 10 days” has to be enforced, independently from the fact that the data haveever been accessed. In this case, stand-alone data handling policies enable building asolution with multiple enforcement points, some of them outside the control of the accesscontrol system (e.g., an obligation manager), but orchestrated/configured by the accesscontrol system. In the following, we assume a customized stand-alone approach for thedata handling policies specification.


3.5.1 Description of the data handling language

Basic elements of the language

We describe our model discussing the basic constructs of the language used to define thedata handling policies. First we have identified the following predicates that constitutethe basic literals that can be used in data handling policies specification:

• a binary predicate credential(ce,K)∈Q, where ce is a credential term (see Defini-tion 3.3.1), and K is the name or the public key of a trusted certification authority(CA);

• a predicate declaration(d) ∈ Q, where d is a list of declaration term (see Defini-tion 3.3.2);

• a set of standard built-in mathematic predicates, such as equal(), greater than(),lesser than(), and so forth;

• a set of provision predicates of the form predicate name(arguments);

• a set of obligation predicates of the form predicate name(arguments);

• a set of non predefined predicates that evaluate information stored at the site.

Then we have identified four basic elements: recipients, purposes, PII abstraction, andrestrictions.

Recipients. A recipient is an external party to which PII of users can be disclosedby the service provider (see Figure 3.1) [50]. Since external parties may be unknown tothe user, she should define to which entities her data may be disclosed without knowingtheir identity. Our approach supports the definition of recipients according to three op-tions: identity-based , category-based , and attribute-based . Identity-based means that theexternal parties may be identified by their unique identity. Category-based means thatthe external parties are grouped into different categories, which represent recipients ofdifferent domains and with different access rights on personal data. Categories can behierarchically organized and within the hierarchy, a category may inherit from its ances-tors all permissions (see Figure 3.3(a)). A critical aspect for scalability is represented bythe ability of defining an external party based on its attributes, instead of its identity.Attribute-based means that the recipient is defined through conditions that it has to sat-isfy. Conditions are evaluated on the recipient’s profile. Similarly to subject expressionof access control policies, recipients is a boolean formula of credential (see Definition3.3.1) and declaration (see Definition 3.3.2).


Recipient

Internal

External

MMMMMMMMMM

Administrative

Seller

,,,,,,BusinessPartners

MarketAgencies

777777

(a)

PII

cc info

ppppppppppppersonal info

BBBBBBBB

number

circuit expiration

;;;;;;;SSN

contact info birth date

LLLLLLLLLLname

TTTTTTTTTTTTTTTTT

snailmail

||||||||email

<<<<<<<first

last

......

(b)

Figure 3.3: An example of recipient hierarchy (a) and PII abstraction (b)

Purposes. The term purposes is used to denote those purposes for which the infor-mation can be used. Abstractions can be defined within the domain of purposes, so asto refer to purposes showing common characteristics and to refer to a whole group witha name. Abstractions can therefore correspond to generalization/specialization relation-ships. For instance, pure research and applied research can be seen as a specializationof research.

PII abstraction. Data types can be introduced as abstractions of PII to let data han-dling policies being expressed in terms of data types, rather than single properties of theusers only. Data types can be organized hierarchically. For instance, in Figure 3.3(b),cc info can be seen as an abstraction for the credit card information, which can includethe number, circuit, and expiration attributes, personal info as an abstraction forthe personal information, which can include the name, birth date, and SSN attributes,and contact info as an abstraction for the contact information (i.e., the snailmail andemail attributes).


Restrictions. A privacy statement specifies restrictions that have to be satisfied beforeaccess to personal data is granted. If just one condition is not satisfied, the access shouldnot be granted. We distinguish between three types of conditions of the form:

• generic conditions either evaluate properties of recipients’ profiles, like membershipof requester, or represent conditions that can be brought to satisfaction at run-time when the request is processed. Generic conditions may include, for example,conditions on the granularity of data disclosure (e.g., data would only disclosed inaggregate form), on the time frame for possible data disclosure, and so on;

• provision represents actions that have to be performed before an access can begranted [27]. For instance, a data handling policy can state that a business partnercan read the email address of the users provided that it has paid a subscription fee;

• obligation represents actions that have to be either performed after an access hasbeen granted [27] or actions that need to be performed in the future, based onthe occurrence of well defined events, e.g. time-based events or context-basedevents [36, 37]. For instance, a data handling policy can state that users will benotified whenever their personal information is disclosed. Another policy can im-pose a restriction on how long personal data should be retained (data retention).

Syntactically these conditions are boolean expressions of terms having the formpredicate name(arguments), where arguments is a list, possibly empty, of arguments onwhich predicate predicate name is evaluated. From the evaluation point of view genericconditions, provisions, and obligations are different: generic conditions are conditions thatan access request has to satisfy before the access is granted; provisions are preconditionsthat need to be evaluated as pre-requisites before a decision can be taken; obligations areadditional steps that must be taken in account after the policy evaluation. For instance,in area(user,‘New York’), is a generic condition requiring user to be located within themetropolitan area of New York; fill in form(form) and log access() are provisionsthat require to fill in a form and to log the access, respectively; and notify(contact info)and delete after(num days) are obligations that require to notify the owner of the data(or other persons) after releasing them and to delete the data after a specific number ofdays, respectively.

Policy and rule definition

Syntactically, a data handling policy has the form “〈PII 〉 managedBy 〈DHP rules〉”,where: PII identifies a PII abstraction that represents the name of an attribute or thename of a data type, in case of a data handling policy template, a set of pairs of the form〈attribute name,attribute value〉 (possibly represented by an abstraction) belonging to aprivacy profile, in case of a customized data handling policy; and DHP rules identifies


one or more rules, composed in OR logic, governing the use of PII to which they refer.Syntactically, a DHP rules can be formalized as follow.

Definition 3.5.1 (Data handling rule). A DHP rules is an expression of the form〈recipients〉 can 〈actions〉 for 〈purposes〉

[if 〈gen conditions〉

] [provided 〈prov〉

][follow 〈obl〉

], where:

• recipients can be an identifier, a category, or a boolean formula of credentialand/or declaration predicates;

• actions is the set of actions;

• purposes is the purpose or a group thereof;

• provisions, obligations, and generic conditions are optional boolean expressions ofterms having the form predicate name(arguments), where arguments is a list, pos-sibly empty, of arguments on which predicate predicate name is evaluated.

A data handling rule specifies that recipients can execute actions on PII for purposesprovided that prov is satisfied, gen conditions is satisfied, and with obligations obl . Fig.3.4 reports the BNF syntax of the DHP rules.

3.5.2 A XML-based syntax for data handling policies

As for access control language, we provide a XML-based syntax for data handling policiesspecification. This makes the integration of the defined privacy languages straightfor-ward. In this section, we briefly review the XML-based syntax (see Appendix B) used forspecifying data handling policies.

Recipients. Based on the syntax provided in Appendix B, recipients element is usedto specify the recipients fields of a policy. This element defines the constraints that haveto be satisfied by an external party to gain the access to users data. An example ofrecipients is provided in the following where an external party can access users dataproviding that it belongs to the Public Administration or it is a No-profit Organization.

<recipients>

<recipient>


<argument isLiteral="false">type</argument>

<argument isLiteral="true">PublicAdministration</argument>

</condition>

</recipient>

<recipient>


<argument isLiteral="false">type</argument>


DHP rules ::= recipients CAN actions FOR purposes IF gen conditionsPROVIDED prov FOLLOW obl

recipients ::= identifier | simple-condition | complex-condition andcomplex-condition | complex-condition or complex-condition |not complex-condition

actions ::= identifier | abstractionpurposes ::= identifier | abstractiongen conditions ::= simple-condition | complex-condition and complex-condition |

complex-condition or complex-condition | not complex-conditionprov ::= simple-condition | complex-condition and complex-condition |

complex-condition or complex-condition | not complex-conditionobl ::= simple-condition | complex-condition and complex-condition |

complex-condition or complex-condition | not complex-conditioncomplex-condition ::= simple-condition | complex-condition and complex-condition |

complex-condition or complex-condition | not complex-condition |ontology-term implied by complex-condition

simple-condition ::= predicate | ontology-term | declaration | credentialpredicate ::= predicate name(attributes)attributes ::= ε | attribute | predicate | attribute, attributes | predicate, attributespredicate name ::= stringattribute ::= stringontology-term ::= stringidentifier ::= stringabstraction ::= string

Figure 3.4: BNF syntax of the DHP rules

<argument isLiteral="true">No-ProfitOrg</argument>

</condition>

</recipient>

</recipients>

To conclude, recipients element groups different recipient that are composed in ORlogic among them, that is, an external party has to satisfy at least one of the recipientelements.

Actions and Purposes. Actions and purposes fields in a policy are defined by actionsand purposes elements, respectively, which are identical to the ones defined in the accesscontrol language.

<actions>

<action>read</action>

<action>disclose</action>

</actions>

3.6. Proposed privacy-aware access control system 59

<purposes>

<purpose>marketing</purpose>

</purposes>

Restrictions. Each condition type (i.e., prov, obl, and gen conditions fields in the policydefinition) is defined by means of an ad-hoc XML element (see Appendix B): obligations,provisions, gen conditions. In the following we provide an example of provision statingthat before access is given, it must be logged, an example of obligation stating that eachaccess must be notified at email address [email protected], and an example of genericcondition restricting the access from 10 am to 2 pm.

<provisions>

<condition name="log_access">

<argument/>

</condition>

</provisions>

<obligations>

<condition name="notify">

<argument isLiteral="true">[email protected]</argument>

</condition>

</obligations>

<gen_conditions>

<condition name="time">

<argument isLiteral="true">10am</argument>

<argument isLiteral="true">2pm</argument>

</condition>

</gen_conditions>

Example 3.5.1. In the following, examples of data handling policies will be providedin the simplified form showed in Table 3.2. Suppose that ACME provides the rent-a-car,book-a-flight, and flight+hotel services. Table 3.2 shows an example of customized datahandling policies that regulate the secondary use of personal information of Alice storedby the ACME company. In particular, DHP1 is composed by three rules that are associatedwith and protect the name and the contact info of Alice; DHP2 is composed by a singlerule that protects the cc info of Alice; DHP3 is composed by two rules that protect thepersonal info of Alice.

3.6 Proposed privacy-aware access control system

In this section, we present our architecture and Java-based prototype of a privacy-awareaccess control system that has been developed in the context of the European PRIMEproject [108]. The prototype integrates traditional access control mechanisms with release


Data Handling PoliciesPII DHP Rules Description

DHP1 Alice.name,Alice.contact info

credential(partnerCard(equal(

user.type,‘BusinessPartners’)),ACME) canread for marketing provided pay a fee()

Business partners ofACME can read formarketing purposethe name and thecontact info of Alice

provided that theyhave paid a fee.


user.type,‘BusinessPartners’)),ACME) canread and write for service release followdelete after(30 days)

Business partners ofACME can read andwrite for service re-lease the name and thecontact info of Alice.name and contact info

must be deleted afterthirty days.ˆ

declaration(equal(user.type,‘MarketAgencies’))and credential(IMB Cert(equal(

user.speciality.category, ‘computer’)), IMB)˜

can read for statistic

Market agenciesspecialized for distri-bution of computersand whose specializa-tion has been certifiedby the InternationalMarket Board (IMB)authority can readthe name and thecontact info of Alice

for statistic purpose.

DHP2 Alice.cc infoˆcredential(employeeCard(equal(user.job,‘Seller’)),

ACME) anddeclaration(equal(user.company,‘ACME’))

˜can

read for service release if time(8:30am,6:00pm)

provided log access()

Sellers of ACME can readcredit card informationof Alice for service re-lease purpose duringthe working hours (i.e.,from 8:30 am to 6:00pm) provided that theaccess is logged.

DHP3 Alice.personal infoˆ(credential(partnerCard(equal(

user.type,‘BusinessPartners’)),ACME) anddeclaration(equal(user.country,‘EU’))) or(declaration(equal(user.type,‘GovAuth’)))

˜can

read for research follow notify()

European businesspartners of organiza-tion ACME or govern-ment authorities canread personal info ofAlice for research withthe obligation of notifyAlice at each access.


user.type,‘Administrative’)),ACME) can read

for marketing if in area(user, ACMEBuilding)

Administrative staff ofACME can read the per-sonal information ofAlice for marketingpurpose only if they arein the building of ACME.

Table 3.2: An example of data handling policies that protect Alice’s data stored by ACME

and data handling policies evaluation and enforcement, and relies on the concepts of


portfolio, profile, ontologies, and abstraction defined in Section 3.3. Our discussion isbased on the parties interplay defined in Section 3.6.1.

3.6.1 Interplay between parties

The infrastructure depicted in Figure 3.1 is aimed at managing two different interactionsbetween the parties (see Figure 3.5):

• User-Service Provider interplay, when a user submits an access request for a resourcemanaged by the service provider;

• External Party-Service Provider interplay, when an external party submits an accessrequest for sensitive information of a user stored by the service provider.

The access request submitted by a user or an external party can be defined as follow.

Definition 3.6.1 (Access request). An access request is a 4-uple of the form 〈user id,action, object, purposes〉, where user id is the optional identifier/pseudonym of the re-quester, action is the action that is being requested, object is the object on which therequester wishes to perform the action, and purposes is the purpose or a group thereof forwhich the object is requested.

For instance, the access request 〈Alice,execute,book a flight,service access〉 states thatAlice wants to execute the service book a flight for the purpose of accessing the requestedservice (service access).

The two interplays previously mentioned work as follows.

• User-Service Provider Interplay. The User-Service Provider interplay is depicted inFigure 3.5(a) (step 1-4). Upon the reception of a service request (step 1), the serviceprovider evaluates its access control policies and, if needed, asks some PII to the user(DataRequest(PIIU ) in step 2). In addition, the service provider presents a datahandling policy template to the user for customization (DHPTemplate(DHPS) instep 2). The user receives the service provider request, evaluates her release policiesand customizes the data handling policy template. If the PII request satisfies atleast one (user-side) release policy, the user sends back the required PII (PIIU ) alongwith the customized data handling policy (DHPS) (step 3). Otherwise, if the user’srelease policies deny the PII release, the transaction aborts. Finally, the serviceprovider stores the user’s data 〈PIIU ,DHPS〉 and re-evaluates the access controlpolicies based on PIIU . If the evaluation succeeds, the service is granted to the user(step 4). In a more general setup, both the release of PII and the data handlingpolicy customization could require multiple negotiation steps [138], rather than asingle request-response exchange. The user, for example, may require the serviceprovider to release some PII as well, and, in turn, the service provider may want tospecify a data handling policy for such a PII.


1:Service RequestKKKKKKKKKKK

%%KKKKKKKK

Access Control

2:DataRequest(PIIU )+DHPTemplate(DHPS)

rrrrrr

yyrrrrrr

ReleaseControl

DHPCustomization

3:DataResponse(PIIU )+DHPCustomized(DHPS)

LLLLLL

%%LLLLLL

Storing〈PIIU ,DHPS〉

Access Control

4:Service Grantedmmmmmmmm

vvmmmmmmmmmmmmm

(a)

1:DataRequest(PIIU )LLLLLLLLLLL

%%LLLLLLLL

Access Control

Data Handling

2:DataResponse(〈PIIU ,DHPS〉)

rrrrrr

xxrrrrrr

Storing〈PIIU ,DHPS〉

(b)

Figure 3.5: User-Service Provider interplay (a) and External Party-Service Provider in-terplay (b)

• External Party-Service Provider Interplay. External party-service provider interplay(see Figure 3.5(b)) is temporally subsequent to the interplay between the user andthe service provider. Suppose that an external party asks the access to personal in-formation of a user, that is, PIIU , stored at the service provider (DataRequest(PIIU )in step 1). External party-service provider interplay begins with a mutual identifica-tion, followed, in the most general case, by a negotiation of the data to be released


Figure 3.6: Privacy-aware access control architecture

and of attached data handling policies.4 Differently to the user-service providerscenario, in this case the service provider must protect the privacy of the user,with respect to the external party, by enforcing the access control policies of serviceprovider and the data handling policies attached to the requested information. Ifthe evaluation of access control and data handling policies returns a positive answer,the external party obtains the pair 〈PIIU ,DHPS〉 (step 2). Otherwise, the access isdenied.

3.6.2 A privacy-aware access control architecture

Figure 3.6 shows the privacy-aware access control architecture [38, 121], which is com-posed of three main components: a Policy Repository , a Context Manager , and a PrivacyControl Module. The Policy Repository contains access control, release, and data handlingpolicies. Its core technology is a relational database that provides functionalities for policyadministration such as searching facilities, modify, insert, and delete operations. The Con-text Manager is the component that keeps track of all contextual information, combinesinformation from various context sources and deducts new contextual information fromthis aggregation [38, 121]. The main tasks of the Context Manager are to provide con-textual information from various sources in a standardized way, and to provide reasoningfunctionalities for boosting the evaluation process. Finally, the Privacy Control Moduleoperates on top of the Context Manager and contains two submodules: a Policy DecisionPoint (PDP) and a Policy Enforcement Point (PEP). PDP is responsible for taking anaccess decision for all access requests directed to data/services. It retrieves and evaluatesall policies (both access control, release, and data handling) applicable to a request and

4For the sake of clarity, Figure 3.5(b) does not show these steps that are similar to steps 2 and 3 of theuser-service provider interplay in Figure 3.5(a).


includes: a Decision Maker that produces the final response possibly combining severalaccess decisions coming from the evaluation of different policies; a Policy Handler thatis in charge of managing all communications with the Policy Repository to retrieve allpolicies applicable to an access request; a Context Administrator that manages access andcommunication with the Context Manager component, which contains the informationassociated with the requester during a session and the ontology engine to reason aboutthe evaluation of policies conditions. PEP is responsible for enforcing access control de-cisions by intercepting accesses to resources and granting them, only if they are part ofan operation for which a positive decision has been taken. PEP also interacts with theObligation Manager [36, 37], a component responsible for enforcing obligation conditionsspecified inside data handling policies. We shall not elaborate on Obligation Manager andPEP infrastructures since our work is focused on the PDP part; complementary Obliga-tion Manager and PEP works have been provided in the context of the PRIME project[38, 121].

The architecture is also composed of a LBS Evaluator and a Credential VerificationComponent. The LBS evaluator is in charge of evaluating location-based conditions [9].5

Our policies, in fact, allow the definition of LBS conditions related to the subject, suchas in area(user.sim,‘Milan’), that is, the requester must be located in downtown Milanwhen the request is generated. The Credential Verification Component is in charge ofverifying X.509 certificates and IDEMIX credentials [34, 35] (i.e., anonymous credentials).Only verified certificates should be stored by the Context Manager, and used for policyevaluation.

Our model and prototype implementation provide also the support for ontologies thatpermit to make generic assertions on subjects and objects [48]. We use the ontologiesdefined in Section 3.3, that is, a subject ontology, an object ontology, and a credentialontology. A subject ontology contains terms that can be used to make generic assertionson subjects and to define relationships among them. An object ontology contains domain-specific terms that are used to describe resources content. Finally, a credential ontologyrepresents relationships among attributes and credentials (part-of and is-a relation-ships) to establish which credentials can be provided to fulfill a declaration or credentialrequest, and more complex relationships between attributes and abstractions.

Access request enforcement flow

Given an access request (see Definition 3.6.1) where the object can be a service or somePII associated with a user, the access request is first received by the PEP and then isevaluated by the PDP in two steps as follows.

Step 1. The access request is evaluated against the applicable access control (or release)policies. Note that, if no policy is selected the access is denied (i.e., the default access

5The evaluation of location-based conditions is treated in Chapter 4.


decision is deny-all). Our implementation is based on policies specified in a disjunctivenormal form (DNF), meaning that rules inside the policies are ORed and conditions insidethe rules are ANDed. After collecting applicable rules, all conditions are inserted in aReverse Polish Notation (RPN) stack that is used to boost the evaluation and to makethe infrastructure independent from policies syntax. Then, each rule is evaluated. Atthe end of this evaluation step the system reaches a “yes”, “no”, or “undefined” accessdecision.

In case of a negative (no) access decision, the access request is denied, and the processterminates.

In case of an undefined access decision, the information submitted by the requesteris insufficient to determine whether the request can be granted or denied. Additionalinformation is required by communicating filtered queries to the requester. Such requestsare called claim requests. It is important to highlight that, a claim request could containsensitive information. In this case, a sanitization process is performed before the claimrequest is sent to the counterpart. This process provides filtering functionalities on theresponse to be returned to the counterpart, which avoid the release of sensitive informationrelated to the policy itself. For instance, suppose that a policy which has been neithersatisfied nor denied yet is greaterThan(user.age,18). The sanitization process can decideto return to the user either the policy as it is or a modified filtered query simply requestingthe user to declare its age (then protecting the information that access is restricted to usersof age only). From the implementation viewpoint, a claim request is a Java class that hasto be serialized before its release to the involved parties.

Finally, in case of a positive (yes) access decision, the system has to verify whetherthere exists some restrictions on the secondary use of the requested target (see Step 2).

Step 2. The PDP submodule of the Privacy Control Module asks the Policy Repositoryto retrieve all data handling policies attached to the object of the request. If no datahandling policy is applicable to the request, Step 2 is skipped and the access is granted.Otherwise, applicable data handling rules are retrieved by using the action, and purposesspecified in the access request as keys. For each applicable data handling rule, the systemevaluates the conditions specified in the recipients, gen conditions, and prov fields. Again,a RPN stack is used for the evaluation of the rules. At the end of this evaluation step thesystem reaches a “yes”, “no”, or “undefined” access decision.6

Finally, the PEP enforces the access control decision. In case of a positive (yes)access decision, the requested data/service is released to the counterpart together withcorresponding data handling policies, and the relevant obligation conditions are sent tothe Obligation Manager. The requester is then responsible for managing the receiveddata/service following the attached data handling policies.

In the next section, the evaluation and enforcement processes are formalized and dis-cussed more in details.

6“No” and “undefined” decisions are managed as described in Step 1.


Label Description

PAC Set of access control policies.

AAC Set of access control policies applicable to the request.

RAC Set of access control rules applicable to the request.

PDHP Set of data handling policies attached to the target of an access request.

RDHP Set of data handling rules applicable to the access request.

object(pi) Object of the i-th access control policy.

obj expr(pi) Object expression of the i-th access control policy.

action(pi) Set of actions of the i-th access control policy.

action(ri,j) Set of actions of the j-th rule of the i-th access control policy.

purpose(ri,j) Group of purposes of the j-th rule of the i-th access control policy.

subj expr(ri,j) Subject expression of the j-th rule of the i-th access control policy.

cond(ri,j) Conditions of the j-th rule of the i-th access control policy.

action(sk) Set of actions of the k-th data handling rule.

purpose(sk) Group of purposes of the k-th data handling rule.

recipient(sk) Recipients of the k-th data handling rule.

cond(sk) Provisions and generic conditions of the k-th data handling rule.

Table 3.3: Terminology.

3.6.3 Policies evaluation and enforcement

We now discuss how access control and data handling policies are evaluated and enforcedtogether at the service provider side. Table 3.3 summarizes the terminology used in thefollowing.

Let 〈user id, action, object , purposes〉 be an access request sent by an external party,where object represents a set of users PII collected by the service provider during previ-ous transactions (see Section 3.6.1). In the first phase, the set of policies AAC ⊆ PAC

applicable to the request are collected. The set AAC of applicable policies contains thosepolicies pi ∈ AAC , with i=1 . . . n, for which action(pi) and object(pi) include the actionand object specified in the access request, and object satisfies all conditions specified inobj expr(pi). Then, considering policies in AAC , the set of applicable rules RAC is calcu-lated, where ri,j ∈ RAC , with ri,j the j-th rule of i-th policy, if action(ri,j) and purpose(ri,j)include the action and purposes specified in the access request. If there exists at least onerule ri,j ∈ RAC such that subj expr(ri,j) and cond(ri,j) evaluate to true based on therequester’s profile, the access control evaluation succeeds and the process moves to evalu-ating data handling policies. For instance, suppose that subj expr(ri,j) of an applicable ruleri,j ∈ RAC has the form equal(user.Company,‘ACME’) ∧ equal(user.Job,‘seller’) andthat cond(ri,j) is empty. If the requester is a seller of ACME, subj expr(ri,j) is evaluatedto true, rule ri,j and then policy pi are satisfied, and the evaluation process continues.

In the second phase, the data handling policies PDHP of the users attached to therequested data are evaluated. In particular, the set PDHP identifies a set of applicable


Attribute Value

Pseudonyms ciks2ss4skkFirst Name BobLast Name Smith

Age 35Job Seller

Company ACMEJobLevel A

Table 3.4: Bob’s profile

rules sk ∈ RDHP , with k = 1 . . .m, for which action(sk) and purpose(sk) include the actionand purposes specified in the access request, respectively. If there exists a rule sk ∈ RDHP

such that recipient(sk) and cond(sk) (both gen conditions and provisions) evaluate to true,the access is granted and the evaluation process is completed successfully. For instance,suppose that the second rule of DHP1 in Table 3.2 belongs to the set of applicable rulesRDHP . If the requester is a business partner of ACME, the data handling rule is evaluatedto true.

In the third phase, the final access control decision is returned. Access is granted,if at least one service provider’s access control policy and one data handling policy at-tached to requested data are evaluated to true. At this point, data are released togetherwith data handling policies of the user. As soon as the requester receives users’ data,the relevant obligations inside the data handling policies attached to the data must beenforced. For instance, the obligation field of DHP1 ’s second rule in Table 3.2 statesdelete after time(30 days). Therefore, as soon as the 30 days are expired, the datamust be deleted.

Example 3.6.1. Let Alice be a user that releases her PII information to the ACME com-pany, together with the data handling policies showed in Table 3.2. Assume now that Bob,which is a seller of ACME, needs to read Alice’s cc info. Bob sends a request of this form:〈ciks2ss4skk,read,Alice.cc info,service release〉. Suppose also that the ACME’s access controlpolicies correspond to the policies in Table 3.1.

First, the set of applicable access control policies to Bob’s request AAC=AC1 iscomputed. AC1 is selected because its actions and object include the action and objectspecified in the access request, respectively, and the object of the access request satisfies theobject expression in the access control policies since Alice.cc info is not yet expired. Theset of applicable rules in policy AC1, that is, RAC=r1,1,r1,2, is retrieved. The accesscontrol rules are then evaluated with respect to the Bob’s profile showed in Table 3.4. SinceBob is not a Director, r1,1 evaluates to false, while r1,2, which requires an ACME’s sellerof level A, is evaluated to true and therefore the evaluation process continues by evaluatingthe data handling policies in Table 3.2 relevant to the access request.


DHP2 is the only policy that regulates the access to the cc info of Alice and thecorresponding rule applies to the access request since its actions and purposes include theaction and purposes specified in the access request, respectively. DHP2’s rule is satisfied byBob’s profile (see Table 3.4) only if the request is sent between 8.30 am and 6.00 pm andthe access is logged. Suppose that the request is sent at 1.00 pm and the access is logged.Bob satisfies this rule and receives the cc info of Alice together with the data handlingpolicies in Table 3.2.

3.7 Chapter summary

The definition of a privacy-aware access control system for regulating access todata/services still preserving the privacy of the involved parties is an important researchdirection and a practical pressing need. Existing proposals and traditional access controlsystems focus on server-side needs of securing access to their resources. As a consequence,access control models and languages turn out to be very limited from a privacy pointof view. We have defined an access control model and language for restricting access toresources/data managed by a service provider and release of PII managed by the users,which take advantages from integration with credentials, ontologies, and context infor-mation. Afterwards, we have defined a data handling model and language allowing theusers to pose restrictions on secondary use of their private data when they are released toexternal parties. Finally, we have developed a prototype providing functionalities for inte-grating access control and data handling policies evaluation and enforcement. The resultis a powerful access control system protecting the privacy of the involved parties. In thenext chapter, we describe how a generic access control model and language, including theone described in this chapter, can be improved by defining conditions based on locationinformation of the users. In this context, we define the infrastructure for the specification,evaluation, and enforcement of such location-based conditions.

4Supporting location-based conditions

in access control policies

This chapter presents a location-based access control (LBAC) model. The LBAC modelallows the definition and evaluation of location-based restrictions on the physical positionof the users and can be integrated with a privacy-aware access control system.

4.1 Introduction

Conventional access control mechanisms rely on the assumption that requesters’ profilesfully determine what they are authorized to do. In Chapter 3, we introduced a privacy-aware access control system based on privacy languages that allow the definition of context-based conditions. As a consequence, a requester’s profile is not anymore the only thingthat matters: context information and, in particular, physical location of users may alsoplay an important role in determining access rights. In this chapter, we describe theintegration of access control policies with location-based conditions, focusing on policiesevaluation and enforcement challenges that such an extension to access control policiesinevitably carries. Location-based Access Control (LBAC) is an intuitive concept [9]: forexample, being able to operate a mechanical device located in a particular room requireshaving a physical presence in that room. The very design of the device interface, in-cluding no remote control, is what enforces the security policy. Achieving the same kindof guarantee with software applications reachable via a telecommunication infrastructurelike a wireless network requires a way to perform location verification, where location ofa user is securely verified to meet certain criteria, for example, being inside a specificroom or within a geographical area. The rapid development in the field of wireless andmobile networking fostered a new generation of devices suitable for being used as sensorsby location technologies able to compute the relative position and movement of users intheir working environment. Once a user’s location has been verified using a protocol forlocation verification, the user can be granted access to a particular resource according tothe desired policy. The location verification process must be able to tolerate rapid context

70 4. Supporting location-based conditions in access control policies

changes, because mobile users can wander freely while initiating transactions by means ofterminal devices like cell phones (GSM and 3G) and palmtops with wi-fi cards. To thisend, well known location sensing techniques like the Global Positioning System (GPS) ortechniques based on measuring signal power losses or transmission delays between ter-minals and wireless base stations can be exploited. Regardless of the specific technology,location verification can provide a rich context representation regarding both the users andthe resources they access. Location-based information now potentially available to accesscontrol modules includes the position and mobility of the requester when a certain accessrequest is submitted. In the near future, location-based services will provide a wealth ofadditional environment-related knowledge (e.g., is the user sitting at her desk or walkingtoward the door? Is she alone or together with others?). This kind of fine-grained con-text information potentially supports a new class of location-aware conditions regulatingaccess to and fruition of resources. A requester then could be granted or denied access byvalidating location-based credentials.

When evaluating location-aware conditions, however, we need to consider that location-based information is radically different from other context-related knowledge inasmuchit is both approximate (all location systems have a margin of error) and time-variant(location is subject to fast changes, especially when the user is in motion). Our approachto LBAC includes a novel way of taking into account the specific techniques and algorithmsused to ascertain the location of the requester. We represent the underlying locationtechnologies in terms of a set of standard interfaces and semantically uniform service levelagreement (SLA) parameters, called relevance and timeout .1 Specifically, we describe theinterface between an Access Control Engine (ACE) and a Location Service. We thendescribe how the SLA parameters of a Location Service can be taken into account bythe ACE. Our solution fully addresses both uncertainty and time-dependency of location-based information; furthermore, it has the ability to seamlessly integrate location-basedand privacy-aware access control, providing the exact level of security needed for pervasiveand distributed resources. Our architecture is highly distributed and relies on externalWeb services to perform functions like estimation of location of a requester.


The remainder of this chapter is organized as follow. Section 4.2 presents our LBACarchitecture and the basic concepts introducing a location-based scenario. Section 4.3formally illustrates and defines location-based conditions and predicates. Section 4.4 de-scribes location-based access control policies, and Section 4.5 presents the working of theAccess Control Engine enforcing LBAC policies. Section 4.6 presents a chapter summary.

1Relevance parameter will also be at the base of the solution, described in Chapter 5, aimed at protectingthe location privacy of users.

4.2. Basic concepts and reference scenario 71

Figure 4.1: LBAC Infrastructure

4.2 Basic concepts and reference scenario

We briefly describe the reference LBAC architecture and some basic concepts on location-based access control systems.

4.2.1 LBAC architecture

In a LBAC scenario, there are more parties involved than in conventional access control.Evaluation of LBAC policies involves context data about location and timing that are madeavailable by third parties through service interfaces called Location Service. In other words,a LBAC system evaluating a policy does not have direct access to the location information;rather, it sends location requests to external services and waits for the correspondinganswers [9]. The characteristics of a Location Service will depend on the communicationenvironment where the user transaction takes place. Here, we focus on mobile networks,where Location Service is provided by mobile phone operators. Figure 4.1 represents thegeneral infrastructure that is introduced when dealing with location-based access control.

Based on such an infrastructure, in Figure 4.2, we present the LBAC architecturethat involves four logical components implementing the interfaces exposed by the ServiceProvider and the Location Service.

User. The entity whose access request to a service must be authorized by a LBAC system.We make no assumption about users, besides the fact that they carry terminalsenabling authentication and some form of location verification.

Business application. Customer-oriented application that offers resources protected byaccess control policies supporting location-based conditions.


Figure 4.2: LBAC Architecture


Access Control Engine (ACE). The entity that implements the LBAC system. Itis logically included in the Service Provider and is responsible for evaluating accessrequests according to some policies containing location-based restrictions. ACE mustcommunicate with a Location Provider for acquiring location information, and it isnot restricted to a particular access control model. Therefore, ACE can implementthe privacy-aware access control model described in Chapter 3 integrated with theLBAC model described here.

Location Provider (LP). The trusted entity that provides the location information byimplementing Location Service interfaces. The types of location requests that it cansatisfy depend on the specific mobile technology, the methods applied for measuringusers positions, and environmental conditions.

Interactions among the User, the Business Application, the Access Control Engine, andthe Location Provider is carried out via request/response message exchanges. The AccessControl Engine receives via Business Application (step 3) access requests submitted by theUser (steps 1-2), evaluates policies (step 8) and returns answers (steps 9-10), invoking theLocation Service interfaces when necessary (steps 4-5-6-7). This functional decompositionis due to the fact that location functionalities are fully encapsulated within remote servicesthat are set up and managed by the mobile operators. Therefore, no assumption can bemade on these services besides their interfaces.

4.2.2 Location measurements and techniques

A location-based condition is a condition involving a predicate whose value depends onlocation measurements performed by a Location Provider. Location-based predicates havebeen investigated since long by the research community [4], trying to address critical issueslike time and space dependency. Two key issues are specific to LBAC:

• interoperability : location tracking can rely on different sources of location informa-tion, depending on availability and cost;

• accuracy : each location measurement, which a Location Provider performs, has adegree of accuracy affected by technological limitations (i.e., measurement errors)and possible environmental effects.

While the former issue largely depends on roaming agreements between mobile phoneoperators and is more business-oriented in nature, the latter needs to be tackled effectivelyfor LBAC to reach its goals. Today, in mobile network scenario, no technology is availableensuring fully exact user location [74]. The location accuracy is always less than 100%, sonormally a position is specified as a range, locating the user within an area.2 For a given

2Although elevation also counts, for the sake of simplicity we disregard it. Our results can be readilyextended to incorporate 3D intervals, at the price of some additional complexity.


location request, the area of a location measurement may depend on the number of nearbyantennas and on the surrounding landscape features. Also, a location measurement is oftenunstable because of changing environmental conditions, such as reflection or interferencesthat may corrupt the signal. In our model, we take into account these aspects by assumingthat the result provided by a Location Provider is always affected by a measurement error.This fact is relevant to the syntax and semantic of the Location Service interfaces becausethe outcome of the evaluation of an access request determined by the Access ControlEngine will depend on such an uncertainty, which must then be explicitly represented andprocessed in terms of accuracy.

Here, we introduce our first working assumption defining the shape of a location mea-surement returned by a Location Provider as follow.

Assumption 1. The area returned by a location measurement is planar and circular.

This assumption simplifies the analysis with no loss of generality because: i) it repre-sents a particular case of the general requirement of considering convex areas (areas mustbe convex to easily compute integrals over them); ii) circular areas approximate well theactual shape resulting from many location technologies (e.g., cellular phones location).

It is worth noting that performance-related properties of a location service largelydepend on the underlying technology. We use GSM/3G technologies as our reference dueto their widespread usage and recent advancements that have sensibly improved locationcapabilities.3 Other technologies like 802.11 WiFi and AGPS/GPS [63, 106] could alsobe exploited although some limitations reduce their applicability. WiFi, for example,has a limited coverage and its usage is restricted to indoor environments (e.g., buildings,airports, malls) or in urban areas covered by many hotspots. GPS, on the contrary, doesnot work indoor or in narrow spaces but has no coverage limitation, a feature which makesit an ideal location technology for open, outdoor environments. The main techniques usedin GSM/3G technologies for location are the following.

Cell Identification. It is the simplest technique and is based on the identification of themobile terminal serving cell. The coordinates of the cell provide a broad estimationof a user position, depending on the radius of the cell, which can vary from hundredsof meters to few kilometers in urban areas, to 3-20 km in suburban/rural areas. Intowns, cells are much smaller than in the countryside.

Signal Level. It is based on measuring the signal attenuation. Assuming free space prop-agation and omni-directional antennas, signal level contours around a base stationare concentric circles where smaller circles enjoy more powerful signal. Directionalantennas lead to more complex geometrical shapes. Unless advanced (and com-putationally heavy) ray-tracing algorithms are used, the signal level metric is notwell-suited indoor or for urban areas.

3In cooperation with Siemens Mobile, our group has recently patented a high-accuracy method forlocating mobile phones suitable for indoor environments [5].


Angle of Arrival (AoA). It assumes that several base stations are used for signal re-ception. A user position can be calculated by computing the angle of arrival atseveral base stations. Note, however, that if there is no line-of-sight between themobile terminal and the base stations, the calculated angle do not correspond withthe actual directional vector from the base station to the mobile.

Time of Arrival (ToA). The distance between a base station and a mobile phone iscalculated by measuring the time a signal takes to make a round-trip between thetwo. Geometrically, this provides a circumference, centered at the base station. Ifmore than three base stations are available, the intersection of their circles providesa mobile phone position. However, signal arrival can be delayed by walls or naturalobstacles, decreasing location accuracy.

Time Difference of Arrival (TDoA). Assuming that base stations within the networkare synchronized or propagation delays between them are known, the differencebetween station-to-terminal propagation times can be computed, increasing locationaccuracy. This can either be realized by measuring the differences between the arrivaltime of a certain burst sent by the mobile to several base stations or by recordingthe time differences of impinging signals at the mobile.

The accuracy and measurement error of all location methods may vary in differentenvironments. In particular, TDoA and (enhanced) signal level methods are the mostaccurate in urban and indoor environments, while AoA is well-suited for outdoor loca-tion because urban environments involve refraction and reflection phenomena that maycompromise its performance.

4.2.3 Relevance metric

The notion of relevance is strictly related to the one of accuracy. The relevance is definedas an adimensional, technology-independent metric of location information accuracy. Lo-cation information is derived from actual positions measured by sensing technology orfrom positions obfuscated for privacy reason. The relevance is a value R ∈ (0, 1] that:

• tends to 0 when location information must be considered unreliable. This representsthe limit condition of very large values of measurement errors or obfuscations thatdegrade the information so that no relation with the original location information ispreserved;

• is equal to 1 when location information has best accuracy. This represents thesecond limit condition of a measurement error equal to the one introduced by thebest sensing technology and no obfuscation applied;


• falls in (0,1) when the location information accuracy is less than optimal either formeasurement errors larger than the minimum and/or for degradations artificiallyintroduced by obfuscation techniques.

In our reference scenario, a LP provides the ACE with location measurements and/orlocation-based predicate evaluations that have an intrinsic measurement error. By con-trast, an ACE could require to have an accuracy not below a threshold to preserve acertain quality of service. To support such requirements, two relevance values characterizeour solution to LBAC predicates evaluation.

• Evaluation relevance (REval). The relevance that represents the level of reliabilityor accuracy that the Location Provider is willing to guarantee to a location-basedpredicate evaluation, according to environmental and weather conditions, granularityof the requested location, and measurement technique.

• LBAC relevance (RLBAC ). The relevance that represents the minimum accuracyrequired by the ACE for a location measurement or for a location-based predicateevaluation (see Section 4.5).

In general, the relevance is more than a metric of the accuracy of location information.In Chapter 5, where the relevance will be used to protect location privacy of the users, weextensively discuss on this.

4.3 Location-based conditions and predicates

4.3.1 Expressing location-based conditions

A first step to support location-based conditions in an authorization language is to identifyhow location information is queried and what kind of response the Location Providerreturns. Traditional location-based services [87] usually assume queries to the LocationProvider to be of the form of range queries asking for an estimated range of values (possiblycollapsing to a single value) for a predicate. Range queries can be modeled as functionsof the form:

predicate(parameters)→[range,accuracy,timeout]

stating that the evaluation of a location predicate over parameters returns a result of range.The range has a given accuracy that models the uncertainty of a location-based predicateevaluation. For instance, in case of a query asking for the position of a user, the accuracyrepresents the radius of the circular area, where range is the center of such an area. Inthis example, range and accuracy represent the area where a terminal is located. Theaccuracy is therefore an upper bound of the deviation with respect to the true location

4.3. Location-based conditions and predicates 77

of the terminal, guaranteed by the Location Provider,4 and is to be considered validwithin the timeframe specified by the timeout . For the sake of simplicity, in our model weconsider queries to be of a simpler (although largely equivalent) form; namely, we shalldeal with boolean queries asking the Location Provider to assess whether a given value (orrange thereof) of a location predicate is true or false. Boolean queries can be modeled asfunctions of the form:

predicate(parameters,value)→[bool value,REval ,timeout]

stating whether or not (depending on whether bool value is True or False) predicate overparameters has the stated value. For instance, a query may ask whether a terminal islocated inside a given region. Here, the assessment (True or False) has again a timevalidity specified by a timeout parameter. This timeout takes into account that locationvalues may change rapidly, even during policy evaluation. If the evaluation of a condi-tion involving a predicate happens to start after the predicate timeout is expired, predicatere-evaluation is triggered. Then, differently from range queries, instead of providing a mea-sure of accuracy, we assume that the Location Provider attaches to answers an evaluationrelevance REval , which represents the level of reliability or accuracy that the LocationProvider is willing to guarantee to the assessment (True or False). While relevance isassociated with measurement accuracy , which in turn depends on the technology used forlocating the requester, the quality of the Location Provider and so forth, the form of thisdependency is encapsulated within the Location Service.

Limiting ourselves to boolean queries simplifies the format of policy rules but doesnot represent a constraint on expressive power. A range query with a condition on thereturned range can be expressed as a boolean query where the condition is moved withinthe predicate itself. For instance, a condition requesting the area where the user is andthen evaluating whether the area is in Milan, can be represented as a condition requestingwhether it is true or not that the user is in Milan area.

It is worth noting that in range queries the Location Provider can respond with differentranges and accuracy levels, thus varying the granularity of the response. For instance,the service can choose between a low-accuracy answer specifying a wide range (e.g., acity) or a high-accuracy answer specifying a smaller region (e.g., a building). In booleanqueries, the accuracy is essentially established by the Access Control Engine, which setsthe granularity at which the request is to be evaluated (e.g., asking the Location Providerwhether the user is located within a building or within a city, depending on the granularityneeded for evaluating the access control policy). The Location Provider answers statingwhether the predicate is true or false, together with the level of reliability REval of such aresponse. The rationale behind our choice (i.e., boolean queries with a level of relevance)is to decouple the physical measurement error from the access control condition that theAccess Control Engine has to evaluate. The Location Provider is in the best position

4Accuracy is a qualitative concept and should not be confused with precision, that is, the closeness ofagreement between independent test results obtained under stipulated conditions.


for providing a relevance estimate, because associating relevance with a range requireseducated guesses about the measured variable probability distribution, as well as theknowledge of the number of physical measurements actually taken by the sensors.5 TheAccess Control Engine evaluates location-based conditions without taking into accounttechnological details of the location measurement process. An additional benefit is tofoster interoperability between the Access Control Engine and multiple Location Providers,possibly relying on different location technologies. Given a certain relevance REval in theevaluation of a location-based predicate (e.g., saying that a requester has been positivelylocated in a given area with a relevance level of 0.9), the Access Control Engine willcompute the final outcome of the boolean location-based condition by defining its localLBAC relevance (RLBAC ) that represents the minimum accuracy required by the ACEfor a location measurement or for a location-based predicate evaluation (see Section 4.5).The relevance REval and timeout with which a Location Provider responds to queries canbe set via Service Level Agreements (SLAs) between the Access Control Engine and theLocation Provider [8].

4.3.2 Location-based predicates

The definition of location-based predicates requires the identification of the kind of con-ditions that it might be useful to include in access control policies and whose evaluationis possible with today’s technology. We identified three main classes of conditions:

• position-based conditions on the location of the user; for instance, to evaluate whethera user is in a certain building or city or in the proximity of other entities;

• movement-based conditions on the mobility of the users, such as their velocity, ac-celeration, or direction where they are headed;

• interaction-based conditions relating multiple users or entities; for instance, the num-ber of users within a given area.

We have defined some specific predicates corresponding to specific conditions of thekind identified by the classes above. Our language is extensible with respect to the pred-icates and other predicates can be added as the need arises and technology progresses.The language for location-based predicates assumes the following two elements.

• Users is the set of user identifiers (UID) that unambiguously identify users knownto the Location Providers. This includes both users of the system (i.e., potentialrequesters) as well as any other known physical and/or moving entity which mayneed to be located (e.g., a vehicle with an on-board GPRS card). A typical UID for

5The details about REval calculation will be provided in Chapter 5.

4.3. Location-based conditions and predicates 79

Table 4.1: Examples of location-based predicatesType Predicate Description

Position inarea(user, area) Evaluate whether user is located within area.disjoint(user , area) Evaluate whether user is located outside area.distance(user , entity, min dist , max dist) Evaluate whether the distance between user

and entity is within interval [min dist ,max dist ].

Movement velocity(user , min vel , max vel) Evaluate whether user ’s speed falls withinrange [min vel , max vel ].

Interaction density(area, min num, max num) Evaluate whether the number of users cur-rently in area falls within interval [min num,max num].

local density(user , area, min num, max num) Evaluate the density within a ‘relative’ areasurrounding user .

location-based applications is the SIM number linking the user’s identity to a mobileterminal.6

• Areas is a set of map regions identified either via a geometric model (i.e., a range in an-dimensional coordinate space) or a symbolic model (i.e., with reference to entitiesof the real world such as cells, streets, cities, zip code, buildings, and so on) [93].

In the following, we will refer to elements of Users and of Areas as user and area terms,respectively. While we assume such elements to be ground in the predicates, our languagecould be readily extended to support variables for them.

All our predicates are expressed as boolean queries, and therefore have the form pred-icate(parameters, value) as illustrated in Section 4.3.1. Their evaluation returns a triple[bool value, REval , timeout ]. Whenever there is no risk of confusion, we will omit thepredicates result. Our core set of location predicates includes the following predicates (seeTable 4.1).

• A binary position predicate inarea whose first argument is a user term and secondargument is an area term. The predicate’s semantics is evaluating whether a user islocated within a specific area (e.g., a city, a street, a building).

• A binary position predicate disjoint whose first argument is a user term and secondargument is an area term. The predicate’s semantics is evaluating whether a user isoutside a specific area. Intuitively, disjoint is equivalent to the negation of inarea.

• A 4-ary position predicate distance whose first argument is a user term, secondargument is either a user or area term (identifying an entity in the system), while

6Individual users may carry multiple SIMs and SIMs may be passed over to other users. We shall notelaborate on these issues, as strong identity management in mobile networks is outside the scope of thisthesis.


the third and fourth arguments are two numbers specifying the minimum (min dist)and maximum (max dist) distance, respectively. The semantics of this predicate isto request whether the user lies within a given distance from the specified entity. Theentity involved in the evaluation can be either stable or moving, physical or symbolic,and can be the resource to which the user is requesting access. Exact distance canbe evaluated by setting the same value for min dist and max dist , “closer than”conditions can be evaluated by setting min dist to 0, “farther than” conditions canbe evaluated by setting max dist to infinity.

• A ternary movement predicate velocity whose first argument is a user term, whilethe second and third arguments are two numbers specifying a minimum (min vel)and maximum (max vel) velocity, respectively. The semantics of the predicate isto request whether the user speed lies within a given range of velocity. Similarly towhat happens for distance, exact velocity can be requested by setting the same valuefor min vel and max vel , while “smaller than” or “greater than” conditions can beevaluated by setting min vel equal to 0 or max vel equal to infinity, respectively.

• A ternary interaction predicate density whose first argument is an area term, whilesecond and third arguments are numbers specifying a minimum (min num) andmaximum (max num) number of users. The semantics of the predicate is to requestwhether the number of users currently in an area lies within the interval specified.

• A 4-ary interaction predicate local density whose first argument is a user term, thesecond argument is a “relative” area with respect to the user, while the third andfourth arguments specify a minimum (min num) and maximum (max num) numberof users, respectively. The semantics of the predicate is to evaluate the density withinan area surrounding the user.

Example 4.3.1. Let Alice.sim be an element of Users, and Milan and Director Officebe two elements of Areas (specifying two symbolic characterizations corresponding to twoknown ranges of spatial coordinates).

inarea(Alice,Milan) = [True,0.9,2005-11-09 11:10am]states that the Location Provider assesses as true the fact that Alice.sim is located inMilan with a relevance REval=0.9, and that such an assessment is to be considered validuntil 11:10am of November 9, 2005.

velocity(Alice.sim,70,90) = [True,0.7,2005-11-03 03:00pm]states that the Location Provider assesses as true the fact that Alice.sim is travelingat a speed included in the range [70,90] with a relevance REval=0.7, and that such anassessment is to be considered valid until 3:00pm of November 3, 2005.

density(Director Office,0,1) = [False,0.95,2005-11-21 06:00pm]

4.4. Location-based access control policies 81

states that the Location Provider assesses as false the statement that there is at most oneperson in the Director Office and believes that two or more persons are in the officewith a relevance REval=0.95. Such an assessment is to be considered valid until 06:00pmof November 21, 2005.

4.4 Location-based access control policies

We now discuss how location-based access control policies can be expressed. Note that wewill not attempt to develop a new language for specifying access control policies. Ratherwe rely on a simplified version of the language proposed in Section 3.4. In general, ourproposal can be thought of as a general solution for enriching the expressive power ofexisting languages (e.g., [17, 32, 80, 56, 126]), by exploiting location information, withoutincreasing the computational complexity of their evaluation. As usual each user is assignedan identifier or pseudonym. Besides their identifiers/pseudonyms, users usually have otherproperties such as name, address, and date of birth. To capture and reason about theseproperties, we assume that each user is associated with a user profile. Objects are thedata/services on which users can make requests. For the sake of simplicity and generalityof the approach, we assume access control policies to be triples whose elements are genericboolean formula over the subject requesting access, the object to which access is requested,and the actions the subjects wants to perform on it. Considering boolean formula overgeneric predicates and/or properties makes our approach applicable to (and compliantwith) various proposals existing in the literature. Formally, our simplified access controlpolicy is defined as follows.

Definition 4.4.1 (Access control policy). An access control policy is a triple of the form〈subject expression, object expression, actions〉, where:

• subject expression is a boolean formula of terms that allows referring to a set ofsubjects depending on whether they satisfy or not certain conditions, where condi-tions can evaluate the user’s profile, location predicates, or the user’s membership ingroups, active roles, and so on;

• object expression is a boolean formula of terms that allows referring to a set ofobjects depending on whether they satisfy or not certain conditions, where conditionsevaluate membership of the object in categories, values of properties on metadata,and so on;

• actions is the action (or set of actions) to which the policy refers.

Similarly to our privacy-aware access control system (see Chapter 3), single propertieswithin users and objects profiles are referenced with the traditional dot notation. Again,to make it possible to refer to the user and object of the request being evaluated without


Table 4.2: Examples of access control policies regulating access to mobile network consoleand databases

subject expression actions object expressiongeneric conditions location conditions

1 equal(user.Role, inarea(user.sim, Server Room) ∧ Execute equal(object.name,‘MNC’)‘Admin’) ∧ density(Server Room, 1, 1) ∧Valid(user.Username, velocity(user.sim, 0, 3)user.Password)

2 equal(user.Role, inarea(user.sim, Inf. System Dept.) ∧ Read equal(object.category,‘Admin’) ∧ local density(user.sim, Close By, 1, 1) ∧ ‘Log&Bill’)Valid(user.Username, velocity(user.sim, 0, 3)user.Password)

3 equal(user.Role, inarea(user.sim, Corp. Main Office) ∧ Read equal(object.category,‘CEO’) ∧ local density(user.sim, Close By, 1, 1) ∧ ‘customer’)Valid(user.Username, velocity(user.sim, 0, 3)user.Password)

4 equal(user.Role, local density(user.sim, Close By, 1, 1) ∧ Read equal(object.category,‘CEO’) ∧ disjoint(user.sim, Competitor Location) ‘StatData’)Valid(user.Username,user.Password)

5 equal(user.Role, local density(user.sim, Close By, 1, 1) ∧ Read equal(object.category,‘Guest’) ∧ inarea(user.sim, Corporate Location) ‘StatData’)Valid(user.Username,user.Password)

need of introducing variables in the language, we use the user and object keywords. Forinstance, user.Affiliation indicates the property Affiliation within the profile of theuser whose request is being processed.

Conditions specified in the subject expression field can be classified in two categories:generic conditions and location-based conditions. Generic conditions evaluate membershipof subjects in classes or properties in their profiles. For simplicity, we can assume thatinformation stored at a service provider is sufficient to evaluate generic conditions. Ifthe Access Control Engine does not have any a priori knowledge of the user, we canassume a negotiation/communication process between the two, eventually yielding to astate where the Access Control Engine has all the information it needs (or it decidesto deny the access) (e.g., [32, 139]). Location-based conditions are expressed using thelocation predicates described in Section 4.3.

Example 4.4.1. Let us consider a company responsible for the management of a mobilenetwork that needs both strong authentication methods and expressive access control poli-cies. Suppose that the Mobile Network Console (MNC) is the software that permits toreconfigure the mobile network. Managing a nation-wide mobile network is an extremelycritical activity because reconfiguration privileges must be granted to strictly selected per-sonnel only and must be performed according to high security standards (see policy 1 inTable 4.2). In addition to reconfiguration privileges, access to mobile network’s databases

4.5. Policy evaluation and enforcement 83

must be managed carefully and according to different security standards depending on thelevel of risk of the data to be accessed. In particular, access to logging and billing datais critical, because they include information about the position and movements of mobileoperator’s customers (see policy 2 in Table 4.2). Access to customer-related informationare usually less critical but still to be handled in a highly secured environment and to begranted only to selected personnel, according to the laws and regulations in force (see pol-icy 3 in Table 4.2). Finally, access to statistical data about the network’s operations areat a lower criticality level, whereas they are still private information to be protected, forexample, from disclosure to competitors (see policy 4 and 5 in Table 4.2).

4.5 Policy evaluation and enforcement

4.5.1 From relevance to truth values

Before illustrating how the access control process operates, we need to solve a basic prob-lem: location-based predicates appear in policies as parts of a boolean formula, while theresponses to boolean location queries are in the form of a triple [bool value, REval , timeout].Then to process a response from the Location Provider, the Access Control Engine willneed to assign a truth value to it.7 Intuitively, the transformation of a location predicatevalue into a boolean one requires the Access Control Engine to determine whether or notthe value returned by the Location Provider can be considered valid for the purpose ofcontrolling access. Such an evaluation will depend on parameters timeout and relevanceREval returned by the Location Provider.

First, responses with a timeout that has already expired automatically trigger the re-evaluation of the predicate regardless of the other parameter values because consideredas unreliable for any decision. Responses with a timeout that has yet not expired areevaluated with respect to the relevance REval .

Then, relevance REval is compared with two thresholds derived from RLBAC (i.e.,(1-RLBAC ) and RLBAC ), which is specified for each location predicate by the ACE. Inthis context, we assume that RLBAC > (1 − RLBAC ), i.e., RLBAC > 0.5. According tothe result of this comparison (i.e., whether REval ≥ RLBAC , REval ≤ (1 − RLBAC ), or(1−RLBAC ) < REval < RLBAC ), the boolean value contained in the response to a booleanquery will be treated differently by the ACE.

Before proceeding further it is important to remark that, as anticipated in Section 4.3,our relevance REval is a metric for measuring the degree of accuracy in predicates evalu-ation; namely a response returning a boolean value v with a relevance REval of α is to beconsidered equivalent to a response returning ¬v with a relevance REval of 1−α. Anotherimportant observation is that RLBAC threshold above which the Access Control Enginewill consider as valid the result returned by the Location Provider may vary depending on

7Alternative solutions are possible, for example defining a fuzzy or probabilistic reasoning on the policies.


Table 4.3: An example of Extended Truth Table for location predicatesPredicate RLBAC Thresholds MaxTries

lower (1-RLBAC ) upper (RLBAC )

inarea 0.1 0.9 10

disjoint 0.1 0.9 10

distance 0.2 0.8 5

velocity 0.2 0.8 5

density 0.3 0.7 3

local density 0.3 0.7 3

different predicates (since more or less information might be required) as well as on howmuch the Access Control Engine trusts the relevance assessment of the Location Provider(e.g., REval=0.8 stated by a very reliable Location Provider could be considered almost asa true value, while REval=0.9 stated by another - less reliable - Location Provider can beconsidered as not reliable).8 Our solution for assigning a truth value to a location-basedpredicate evaluation is then based on the definition of an Extended Truth Table (ETT).Table 4.3 illustrates an example of an ETT featuring custom relevance RLBAC for eachpredicate.

The ETT is used as follows: if REval ≥ RLBAC then the boolean value returned by theLocation Provider will be confirmed. If REval ≤ (1−RLBAC ) the boolean value returnedis not confirmed and the location-based condition is evaluated to ¬bool value. Otherwise,if (1 − RLBAC ) < REval < RLBAC neither the returned value nor its negation can beconsidered sufficiently reliable to take a decision about the location-based condition andpredicate re-evaluation is triggered. The same happens when the timeout has expiredprior to evaluation. To avoid deadlock, a MaxTries number is defined for each locationpredicate (column MaxTries in the ETT table), expressing the max number of predicatere-evaluations that the Access Control Engine will request either because the relevancelevel is not reliable enough or due to a timeout. If after MaxTries re-evaluations ofthe predicate, the outcome remains unreliable, the evaluation process ends and the finalresponse is Unknown. Predicates whose evaluation is more time consuming are likely to bere-evaluated fewer times than others. In our case, density and local density are the mosttime consuming predicates because their evaluation depends on the position of multipleentities. On the other hand, inarea and disjoint are the least time consuming predicatessince they depend on the position of a single entity; distance and velocity depend on thelocation measurement of two entities and on two location measurements of a single entity,respectively.

With respect to the RLBAC values set in Table 4.3, the rationale is that since theyrepresent SLA defined terms, they should reflect the overall bounds to the reliability of

8This behavior is similar to reputation-based approaches developed for peer to peer environments, wherepeers’ votes are weighted with respect to the credibility of the voters [49].


Function Solve(pred-name(p1, . . . , pn, value),LP): True, False, Unknownupper:=ETT[pred-name, upper];lower:=ETT[pred-name, lower];maxtries:=ETT[pred-name, MaxTries];response:= Unknown;tries := 0;repeat

Send query pred-name(p1, . . . , pn, value) to LPReceive Reply = [bool value, REval , timeout ]if current-time < timeout then

case REval of≥ upper : response := bool value;≤ lower : response := ¬ bool value;

endiftries := tries + 1;

until (response 6=Unknown) or (tries > maxtries)return response

Figure 4.3: Function Solve

a location measurement/predicate evaluation provided by a specific Location Provider.RLBAC thresholds are empirical values that an expert should estimate when SLA agree-ments are set. They should encapsulate both an evaluation of the technical difficulty ofproviding the measurement required by the specific location predicate and the LocationProvider reliability. Examples of technical aspects that may influence the measurements(relevance REval ) are the sensitivity of the predicate to external conditions, such as en-vironmental and weather conditions, and measurement techniques adopted. Examplesof factors that may affect a Location Provider reliability are the expertise with the spe-cific measurement techniques, and the distribution and number of sensors of the LocationProvider infrastructure. According to this rationale, inarea and disjoint are the predicatesthat most suffer from environmental changes and consequently we should set a big rele-vance RLBAC for reducing the uncertainty. Predicate density and local density are the lesssensitive and we may accept smaller relevance RLBAC to confirm the result returned bythe Location Provider. Predicates distance and velocity are in the middle with respect torelevance too.

Actual values of Table 4.3 represent educated guesses only.

To perform the mapping of boolean queries responses into boolean values we define afunction Solve that enforces the semantics just described. The function, illustrated in Fig-ure 4.3, takes as input a predicate name pred-name with its parameters p1, . . . , pn, value,


and a Location Provider LP to be queried, and returns as output a value in the set True,False, Unknown.

Example 4.5.1. Let Alice.sim be an element of Users and LP be the Location Provider.Suppose that the ETT is as illustrated in Table 4.3 and that the current time is 10:45AM ofNov. 9, 2005. Consider then the following calls of function Solve.

• Solve(inarea(Alice.sim,Inf. System Dept.),LP)

Suppose that inarea(Alice.sim,Inf. System Dept.) =[True,0.95,2005-11-09 11:00AM], the function returns True.

• Solve(velocity(Alice.sim,0,3),LP)

Suppose that velocity(Alice.sim,0,3) = [True,0.9, 2005-11-09 10:50AM], the func-tion returns True.

• Solve(local density(Alice.sim,Close By,1,1),LP)

Suppose that a first query evaluates local density(Alice.sim,Close By, 1,1) =[True,0.6, 2005-11-09 11:10AM]. Since the relevance falls within the uncertainrange the query is submitted a second time.

Suppose that the second attempt returns [True,0.65,2005-11-09 11:12AM]. Again,since the relevance falls within the uncertain range, a third attempt is performed.

Suppose that the third attempt returns [True,0.63,2005-11-09 11:13AM]. Again,the relevance falls within the uncertain range. Since MaxTries has been reached, nofurther query is requested and the function returns Unknown.

4.5.2 Access control enforcement

To describe how the access control process operates, we start by characterizing the accessrequests submitted to the Access Control Engine.

Definition 4.5.1 (Access request). An access request is a triple of the form 〈user id,action, object〉, where user id is the optional pseudonym/identifier of the user who makesthe request, action is the action that is being requested, and object is the object on whichthe user wishes to perform the action.

We then use P to denote the set of access control policies stored at the Access Con-trol Engine. Given an access control policy p ∈ P, subj expr(p), obj expr(p), action(p)will denote the subject expression, object expression, and actions, respectively, of p. Wefinally assume that the Access Control Engine first evaluates whether a decision can betaken locally (i.e., based on policies evaluating only generic conditions). If no decisioncan be taken locally (all applicable authorizations involve location-based predicates), the


corresponding queries are sent to the involved Location Provider. The reason for such anassumption is that location-based predicates evaluation usually bears cost and thereforeis to be avoided whenever possible.

The policy evaluation and enforcement process (involving the communications illus-trated in Figure 4.1) can be described as a three-phases process as follows.

Let 〈user id, action, object〉 be an access request. In the first phase, the Access ControlEngine collects all the policies A ∈ P that are applicable to the request. The set A ofapplicable policies contains those policies p ∈ P for which action(p) includes the actionspecified in the access request, and object satisfies the conditions specified in obj expr(p).Let Ag ⊆ A be the set of applicable policies, where the subject expressions contain genericconditions only, and Alp ⊆ A be the set of applicable policies where the subject expres-sions contain also location-based predicates. If there exists a policy p ∈ Ag such thatsubj expr(p) evaluates to true, then the access is granted and the evaluation process ends.For instance, suppose that the subject expression of an applicable policy p ∈ Ag is of theform equal(user.Company,‘ACME’) ∧ equal(user.Job,‘employee’). In this case, eitherthe requester is an ACME’s employee and the access is granted, or the evaluation continueswith the second phase.

In the second phase, for each policy p ∈ Alp, the Access Control Engine simplifiessubj expr(p) applying the usual rules of propositional calculus. More precisely, subjectexpression subj expr(p) is first simplified by evaluating all the generic conditions. Forinstance, suppose that the subject expression of an applicable policy p ∈ Alp is of theform equal(user.Citizenship,‘EU’) ∧ inarea(user.sim,Venice) and the requester is Ital-ian. In this case, the residual subject expression is True ∧ inarea(user.sim,Venice), thatis, inarea(user.sim,Venice). In general the residual subject expression, called residualcondition, cannot be further simplified and the access request cannot be immediatelygranted or denied. Consequently, the Access Control Engine proceeds evaluating location-based conditions. More precisely, for each predicate pred-name(p1, . . . , pn, value), theAccess Control Engine determines the Location Provider LP involved and calls functionSolve(pred-name(p1, . . . , pn, value),LP).

In the third phase, all conditions’ outcomes are put together to reach the final accesscontrol decision. There is a slight complication here: the resolution of predicates in thesubject expression can have three possible values, namely True, False, Unknown. Theboolean expression outcome then results from the application of the classical truth tablesof propositional connectives ¬, ∨, and ∧ defined in the 3-valued logic. In particular:Unknown ∧ False=False, Unknown ∨ True=True. Other disjunctions or conjunctionsinvolving Unknown, as well as the negation of Unknown itself, have as result Unknown.

Access is granted, if for at least an applicable policy the subject expression evaluatesto True; it is denied otherwise.


Example 4.5.2. Let Alice be a user and Alice.sim her SIM number. Assume now thatAlice requests Read access to the ‘StatData’ of a mobile network whose access is regulatedby the set of policies P in Table 4.2.

The access control proceeds as follows. First, the set of applicable policies A is retrieved.This set contains authorizations 4 and 5, both of which fall in Alp. Then, the authorizationsare simplified by evaluating all the generic conditions to retrieve residual (location-based)conditions.

Suppose Alice’s active role is CEO and that Alice is logged in with a valid account.Consequently, the generic conditions in authorization 5 evaluate to False, making thewhole authorization evaluates to False. The generic conditions in authorization 4, in-stead, evaluate to True, resulting in the following residual condition to be evaluated:“ local density(Alice.sim,Close By,1,1) ∧ disjoint(Alice.sim,Competitor Location)”.

For each of the predicates in the residual conditions, function Solve is called. Assumefunction Solve to follow the process illustrated in Example 4.5.1, producing:

• Solve(local density(Alice.sim, Close By, 1, 1), LP) = Unknown

• Solve(disjoint(Alice.sim,Competitor Location), LP) = True

Hence, Unknown ∧ True = Unknown and the access is denied.

4.6 Chapter summary

We presented an access control model for representing and evaluating LBAC conditions.The proposed approach encapsulates time-dependency and accuracy of location measure-ments as important features of location information in a small set of semantically uniformservice level agreement (SLA) parameters based on the notions of relevance and temporalvalidity of each access request. The ability to evaluate conditions on a set of authorizedlocations has a number of well-known advantages, including enriching access control ex-pressiveness. However, when location information is used, especially in combination withpersonal identities, users privacy is seriously threatened and must be protected. The nextchapter studies the issue of protecting privacy of users when their location informationis managed by location-based services. A location privacy solution based on obfuscationtechniques is introduced and validated in the context of our location-based access controlsystem. Finally, the mechanism used to generate the relevance REval of a location-basedpredicate evaluation is described.

5Location privacy protection in LBAC

systems: an obfuscation-basedsolution

This chapter discusses the problem of protecting the privacy of users in a location-basedservice scenario, and presents a new and comprehensive privacy solution, based on privacypreferences of users and obfuscation techniques, which permits to achieve, and quantita-tively estimate, different degrees of location privacy. In addition, some issues arising bythe application of such techniques are described, providing a formal analysis of the adver-sary problem, where an adversary tries to reduce the level of location privacy provided tothe users by means of de-obfuscation attempts. Finally, the location privacy solution isvalidated in the context of our LBAC system, discussing the privacy-aware evaluation oflocation-based conditions in details.

5.1 Introduction

The physical location of individuals is rapidly becoming easily available as a class ofpersonal information that can be processed for providing a new wave of online and mobileservices, generally called Location-Based Services (LBSs). Customer-oriented applications,social networks, and monitoring services can be greatly enriched with data reporting wherepeople are, how they are moving, or whether they are close by specific locations. Severalcommercial and enterprise-oriented LBSs are already available and have gained popularity[23, 51], driven by the relevant enhancements achieved in the field of sensing technologies.Location technologies today permit to gather location information with good precision andreliability at costs that most people (e.g., the cost of current mobile devices like cellularphones or GPS receivers) and companies (e.g., the cost of integrating location technologiesin existing telecommunication infrastructures) can economically sustain.

In this context, it comes with no surprise that personal privacy, which is alreadythe center of many concerns for the risks posed by current online services [23, 109], is

90 5. Location privacy protection in LBAC systems: an obfuscation-based solution

considered seriously threatened by LBSs. The publicity gained by recent security incidents,which have targeted individuals privacy, revealed faulty data management practices andunauthorized trading of users personal information. For instance, some legal cases havebeen reported, where rental companies used GPS technology to track their cars and chargeusers for agreement infringements [41], or where an organization used a “Friend finder”service to track its own employees [86]. In addition, research on privacy issues has gaineda relevant boost since providers of online and mobile services, often, largely exceeded incollecting personal information as a requirement for service provision.

In such a worrisome scenario, the concept of location privacy can be defined as the rightof individuals to decide how, when, and for which purposes their location information couldbe released to other parties. The lack of location privacy protection could result in severeconsequences that make users the target of fraudulent attacks [54]:

• unsolicited advertising, the location of the user could be exploited, without herconsent, to provide advertisements of products and services available nearby theuser position;

• physical attacks or harassment, the location of the user could be used to carry phys-ical assaults to individuals;

• users profiling, the location of the user, which intrinsically carries personal infor-mation, could be used to infer other sensitive information such as state of health,personal habits, professional duties, and the like;

• denial of service, the location of the user could be used to deny accesses to servicesunder some circumstances.

The main branch of current research on location privacy focuses on supportinganonymity or partial identities [26, 28, 61, 66], for those online and mobile services thatdo not require users identification for their provision. Although important, anonymity orpartial identification are not always viable in the provision of an online service [73, 84].To a certain extent, anonymity and complete knowledge of personal information are theopposite endpoints of all degrees of personal information knowledge managed by onlineservices. Location information is just one class of personal information that often needsto be bound to a user identity. Therefore, in those cases where identification of users isrequired and, consequently, anonymity is not suitable, a solution to protect users privacyis to decrease the accuracy of personal information [52, 113]. Several online services do notneed to associate personal information as accurate as possible with identities to guaranteea certain quality of service. This is often the case of LBS, which, in many real applications,can deal with location information of lower accuracy and still offer an acceptable qualityof service to end users.

5.2. Working assumptions 91

In this chapter, we present a management process and an analysis of techniques aimedat preserving location privacy of users by artificially perturbing location information mea-sured by sensing technologies. Our perturbation process is usually called obfuscation andthe corresponding techniques are called obfuscation techniques. Key for our reference sce-nario is, on the one side, to let users express their privacy preferences in a simple andintuitive way, and, on the other side, to manage privacy preferences for location-basedservices preserving the quality of online services. To this end, we rely on the concept ofrelevance as a metric of location information accuracy by abstracting from any physicalattribute of sensing technology.1 Here, a relevance value permits to quantitatively evalu-ate the degree of privacy introduced into a location measurement and is used by users todefine their privacy preferences. Based on this metric, it is also possible to strike a balancebetween service providers requiring a certain level of location accuracy for LBS provisionand users willing to minimize the disclosure of personal location information. Both needscould be expressed as relevances and either quality of online services or location privacycan be adjusted, negotiated or specified as contractual terms to meet a certain locationmeasurement relevance. Finally, the robustness of our obfuscation techniques is evaluatedwith respect to possible de-obfuscation attempts made by adversaries, which may adoptdifferent strategies and make use of contextual information in an attempt to reverse anobfuscation technique.


The remainder of this chapter is organized as follow. Section 5.2 discusses our workingassumptions. Section 5.3 illustrates our approach for defining location privacy preferencesand introduces the concept of relevance in the context of location privacy. Section 5.4presents our obfuscation techniques. Section 5.5 describes how the obfuscation techniquescan be composed and presents some examples of their application. Section 5.6 models theadversary trying to reverse the effects of obfuscation techniques and gives an evaluationof the robustness of our techniques. Section 5.7 validates our privacy solution in thecontext of a privacy-aware LBAC system integrating the privacy-aware and location-basedaccess control systems introduced in the previous chapters. Section 5.8 presents a chaptersummary.

5.2 Working assumptions

The first factual evidence that must be considered is that location information of users,as each physical measurement, is always affected by an intrinsic measurement error intro-duced by sensing technologies. Direct consequence of such an inaccuracy is that location

1The relevance concept has been already defined in Chapter 4, where relevance REval and RLBAC havebeen introduced.


measurements should not be expressed as geographical points, which would imply to as-sume that no error is introduced. Rather, we express users positions through spatial areas.2

Therefore, to simplify the presentation of the results of our work, we introduce two work-ing assumptions. Both assumptions, if relaxed, make the calculations more complex butdo not imply any loss of generality of the results.

The first working assumption has been already introduced in Chapter 4 (see Assump-tion 1), and it states that the shape of a location measurement returned by a locationservice is planar and circular.

According to this assumption, a location measurement returned by a sensing technol-ogy can be defined as follow.

Definition 5.2.1 (Location measurement). A location measurement of a user u isa circular area Area(rmeas, xc, yc), centered on the geographical coordinates (xc, yc)and with radius rmeas, which includes the real user position (xu, yu) with probabilityP ((xu, yu) ∈Area(rmeas, xc, yc))=1.

Definition 5.2.1 comes from observing that sensing technologies based on cellularphones usually guarantee that the real user location is into the returned area [47]. Asa consequence, a location measurement function (fLM ) can be defined as follow.

Definition 5.2.2 (Location measurement function). Let A be the set of circular areas,and Users the set of user identifiers. A location measurement function fLM : Users → Ais a function that takes as input a user identifier u ∈ Users, and produce as output thelocation measurement area of the user u, Area(rmeas, xc, yc)∈ A.

To discuss the effects of obfuscation techniques and consistently with other propos-als [94], we introduce the second assumption.

Assumption 2. Consider a random location within a location measurementArea(rmeas, xc, yc), where a random location is a neighborhood of random point(x,y)∈Area(rmeas, xc, yc). The probability that the real user position (xu, yu) belongs toa random location is uniformly distributed over the whole location measurement.

Accordingly, the joint probability density function (pdf) of the real user position canbe defined as follows [103].

Definition 5.2.3 (Joint pdf). Given a location measurement Area(rmeas, xc, yc), the jointprobability density function (joint pdf) frmeas(x, y) of real user position (xu, yu) to be inthe neighborhood of point (x,y) is:

2Some works approximate positions as geographic points [26, 52, 66, 94], which is only acceptable as asimplification when the purpose is to analyze techniques that are not affected by such intrinsic measurementerrors. In general, however, it is an unrealistic assumption, since location measurement errors are oftena relevant factor of the measurement accuracy and not easily predictable since greatly influenced by thecharacteristics of the environment.

5.3. Location relevance and privacy preferences 93

frmeas(x, y) =

(1

πr2meas

if x, y ∈ Area(rmeas, xc, yc)

0 otherwise.

5.3 Location relevance and privacy preferences

The ultimate goal of this chapter is to design a solution that permits to manage locationprivacy as a functional term, required or adjusted by users according to their preferencesand application context, and negotiated as a service attribute by LBSs. To this end,location privacy must be measured and quantified with regard to the accuracy of a userposition: the more accurate the position, the least the privacy. Furthermore, locationprivacy must be measured regardless of specific application contexts and must be expressedquantitatively as a service parameter without sticking on some coarse-grained preset meta-locations such as “city” or “department”, which represent just simplified instances ofprivacy preferences that should be supported by a most general and flexible solution.The metric we adopt for this purpose is called relevance. However, before discussing therelevance metric, the preliminary concept of location accuracy is introduced.

5.3.1 Location accuracy

The accuracy of a location measurement returned by a sensing technology depends onthe radius of the measured circular area, which, in turn, depends on the unavoidablemeasurement error of the location technology. To evaluate the quality of a given locationmeasurement, its accuracy must then be compared to the best accuracy that locationtechnologies are able to provide.

Several works describe and discuss different location techniques and the best accu-racy that can be achieved [68, 123]. In [123], the authors provide a survey of standardpositioning solutions for the cellular network such as, E-OTD for GSM, OTDOA for Wide-band CDMA (WCDMA), and Cell-ID. E-OTD location method is based on the existingobserved time difference (OTD) feature of GSM systems. The accuracy of the E-OTDestimation, in recent studies, has been found to range from 50m to 125m. Observed TimeDifference Of Arrival (OTDOA) is designed to operate over wideband-code division mul-tiple access (WCDMA) networks. The positioning process achieves a location accuracy of50m at most. Finally, Cell-ID is a simple positioning method based on cell sector infor-mation where cell size varies from hundreds of meters/few kilometers in urban areas to3-20km in suburban/rural areas.3

3Several other non-standard methods [33, 44] are able to further improve the accuracy of standardpositioning methods.


Therefore, calling rmeas the radius of the measured area and ropt the radius of the areaproduced with best accuracy, the ratio r2

opt/r2meas is a good estimation of the quality of a

location measurement.To show an example of a positioning process using the three techniques described

above, suppose that a user position is located with accuracy rmeas=62.5m using E-OTDmethod, accuracy rmeas=50m using OTDOA, and accuracy rmeas=1km using Cell-ID.Optimal accuracy is ropt=50m. The three location measurements result in three differentareas. In particular, the area with best accuracy, provided by OTDOA, has a measurementquality of 1, whereas the others have a quality proportionally reduced to 0.8 for the areacalculated by means of E-OTD, and 0.05 for the one measured through Cell-ID. This way,based on the optimal location accuracy, we can distinguish between different measurementaccuracies and reward the best techniques available.

5.3.2 Relevance metric for privacy protection

The relevance metric has been introduced in Section 4.2.3 as an adimensional, technology-independent metric of the location information accuracy, where the location informationis derived from actual positions measured by sensing technology or from position dataobfuscated for privacy reason.

Here, we focus on relevance values that evaluate the accuracy of physical positionsof users (possibly obfuscated) to protect location privacy of users. The location privacyprovided by an obfuscated location is evaluated by (1-R). In different terms, the notion ofrelevance is useful to normalize the accuracy value of a physical position by expressing it asan adimensional value, independently from any physical scale or from a reference area (ifgiven as a percentage of loss), and to represent the lack of accuracy of obfuscated positionsregardless to the specific applied obfuscation techniques. This way, the relevance is thegeneral functional term used to qualify the accuracy (and correspondingly the privacy)of a physical position when a LBS interacts with users or application service providers,which, in general, are unaware of the technicalities of both location sensing technologiesand obfuscation techniques.

In our reference scenario, a LBS has to manage locations that, on the one side, couldbe perturbed for privacy reasons, while on the other side could be required to have anaccuracy not below a threshold to preserve a certain quality of service. To support suchrequirements, all locations have an associated relevance attribute, from the initial locationaffected by a measurement error of sensing technologies to all possible subsequent manip-ulations introduced for privacy reason. All management decisions, either related to usersprivacy or to quality of information, are carried out by considering or possibly negotiatingrelevance values associated with location information. Three relevance values characterizeour solution:

• Initial relevance (RInit). The relevance of a user location measurement as returned

5.3. Location relevance and privacy preferences 95

by a sensing technology. This is the initial value of the relevance that only dependson the intrinsic measurement error.

• Final relevance (RFinal). The relevance of a final obfuscated area produced bysatisfying a user’s privacy preference. It is derived, starting by the initial relevance,through the application of one or more obfuscation techniques.

• Intermediate relevance (RInter ). The relevance associated with the intermediateobfuscated area when a double obfuscation is applied. In that case, starting froma location measurement with relevance RInit , an intermediate area with relevanceRInter is calculated, and from this, the final obfuscated area with relevance RFinal

is obtained. We extensively discuss on double obfuscation in Section 5.5.

With regard to RInit , its value is calculated by normalizing the best accuracy thatcould have been achieved with respect to the technical accuracy resulting from the specificmeasurement. This is represented by the ratio of two measurement errors, respectively,the area that would have been returned if the best accuracy was achieved (i.e., havingradius ropt) and the actual measured area (i.e., having radius rmeas). In other words,RInit measures the relative accuracy loss of a given measure (e.g., due to particular envi-ronmental conditions) with respect to the best accuracy that the technology would havepermitted. This is the only relevance value that is directly calculated from physical val-ues (i.e., measurement errors). RFinal is derived from RInit by considering the accuracydegradation introduced for privacy reason. We use a scalar factor λ ∈ (0, 1] to representit. Accordingly, the location area associated with RInit will be perturbed with the obfus-cation techniques so that a resulting area having relevance RFinal is obtained. RInit andRFinal are formally defined as follow.

Definition 5.3.1 (RInit and RFinal ). Given a location measurement area of radius rmeas

measured by a sensing technology, a radius ropt representing the best accuracy of sensingtechnologies, and an accuracy degradation λ ∈ (0, 1], initial relevance RInit and finalrelevance RFinal are calculated as:

RInit =r2

opt

r2meas

(5.1)

RFinal = λRInit (5.2)

5.3.3 User privacy preferences

Systems that want to let users express their privacy preferences must strike a balancebetween the two traditionally conflicting requirements of usability and expressiveness.Complex policy specifications, fine-grained configurations and explicit technological de-tails often discourage users from fully exploiting advanced functionalities, like privacy


management. For this reason, we set as a requirement that users should be able to expresstheir privacy preferences in an intuitive and straightforward way.

Today, many academic projects and commercial tools [52, 104] assume that usersspecify their privacy preferences as a minimum distance. According to this setting, forexample, a user can define “100 meters” as her privacy preference, which means that shecan be located with an accuracy not better than 100 meters. Considering measurementsthat produce circular areas, such a preference corresponds to an area of radius 100 metersat least. Although this solution is certainly intuitive and easily understandable by users,it does not come with no drawbacks: i) a minimum distance is meaningful in a specificapplication context only, and ii) it is suitable only for the application of obfuscationtechniques that scale a location measurement to a coarser granularity.

With respect to the first drawback, the value “100 meters” is only meaningful when itis a good trade-off between ensuring a sufficient level of privacy to the user and permittingto location-based applications to provide their services effectively. For instance, it couldbe well suited for applications that provide touristic or commercial information to a userwalking in a city center. By contrast, applications working in smaller contexts, like insidean industrial department, are likely to require granularities much finer than 100 meters.Again, 100 meters can be largely insufficient for preserving user privacy in high sensitivecontexts.

The second drawback is less evident while not less critical. Traditional location ob-fuscation solutions often neglect the possibility to use and compose different obfuscationtechniques to increase the robustness of the obfuscation process with respect to possiblede-obfuscation attempts performed by adversaries. Our work addresses this issue by allow-ing the composition among different obfuscation techniques and by analyzing the overallrobustness. With regard to user preferences, the application of obfuscation techniquesdifferent from the simple scaling of the radius makes the concept of “minimum distance”often not meaningful.

Our privacy preference solution then is to allow users to specify a value for the finalrelevance RFinal that the obfuscated area must exhibit. The complexity of privacy man-agement and specification is not directly exposed to users, whose burden is limited to thechoice of RFinal , which is a rating in the (0,1] interval.

However, while this solution is straightforward, the choice of a certain relevance valuecould be seen as unclear since not explicitly mapped to any physical attribute of locations,like, for example, a greater granularity of returned positions. To address the requirementof intuitiveness of privacy preference specification, the concept of minimum distance couldbe reused, although its meaning must be slightly changed. By considering the scalar factorλ (see equation (5.2)) and an obfuscation produced by scaling up the radius of the originallocation measurement (the technique for which the concept of “minimum distance” ismeaningful), the factor λ can be derived from the radius of the obfuscated area, whichwe call robf , and the radius rmeas of the original measurement. Since we assume circularareas, the relative increasing of privacy obtained by producing an area with radius robf is

5.4. Obfuscation techniques 97

calculated as the original area times the obfuscated area. Formally, the relation can bewritten as follows.

λ =r2meas

r2obf

Thus, substituting this expression in (5.2), we can write the term robf as a function ofRFinal :

RFinal = λRInit =r2meas

r2obf

RInit =⇒ robf = rmeas

√RInit

RFinal(5.3)

We observe that the value robf represents the actual “minimum distance” only whenobfuscation is performed by scaling up the radius. Instead, for all other obfuscationtechniques that we introduce in the following, the radius of the obfuscated area will bedifferent than robf in (5.3). However, given a certain value of λ, the accuracy degradationproduced by different techniques is the same, thus, robf in (5.3) represents the minimumdistance provided by an equivalent obfuscation produced by scaling up the radius. Thisstatement represents a logical constraint that can be refined as: the location area producedby one or more a priori undetermined obfuscation techniques is equivalent, in term ofprivacy, to the one produced by enlarging the radius of the original measurement up torobf . The user then has a concrete meaning of RFinal definition. This is the key point forthe intuitiveness of our solution.

In summary, we accommodate users needs of expressing privacy preference in a:

• straightforward way since users specify a value of RFinal for the resulting obfuscatedarea;

• intuitive way since we can derive robf as the minimum distance provided by anequivalent obfuscation produced by scaling up the radius.

The users have then a tangible physical reference for the accuracy degradation intro-duced by their privacy preference.

5.4 Obfuscation techniques

We present three basic obfuscation techniques, starting from the traditional radius enlarge-ment followed by radius reduction and center shifting [10]. For each technique we definea logical operator representing physical transformations implemented by different obfus-cation techniques, which permits to calculate an obfuscated area respecting the privacypreferences RFinal of the users.


For each technique, we analyze the obfuscation effect based on its geometric and prob-abilistic characteristics and formally define the term that allows to quantify the reductionof the relevance, from RInit to RFinal , as a result of an obfuscation. Such a term, specificof each obfuscation technique, depends on the user privacy preference RFinal and is usedto calculate the value of the physical parameter (i.e., an enlarged radius, a reduced radius,or a distance between centers) that lets to generate the obfuscated area. It is importantto highlight that in case RFinal>RInit no obfuscation is applied to the location measure-ment, since the measurement error introduced by a sensing technology already satisfiesthe privacy preference of the user.

5.4.1 Obfuscation operators

An obfuscation operator is a logical operator representing the transformation that permitsto calculate an obfuscated area, qualified by RFinal , starting from a location measurementArea(rmeas, xc, yc) qualified by RInit . Formally, a generic obfuscation operator is definedas follow.

Definition 5.4.1 (Obfuscation operator). Let A be the set of circular areas. An obfusca-tion operator op : A× (0, 1]× (0, 1] → A takes a circular area and two relevance values asinput and produces an obfuscated area as output such that:

1. ∀A,R,R′ : A ∈ A, R ∈ (0, 1] is the relevance associated with A, R′ ∈(0, 1], and R′ ≤ R ⇒ op(A,R,R′) = A′ ∈ A;

2. A′ ∩A 6= ;

3. A′ has relevance R′.

In this chapter, we introduce three obfuscation techniques and the related operators. Theoperators are presented in the following and summarized in Table 5.1.

• Enlarge (E). It degrades the accuracy of a location measurement by en-larging its radius. Given a location measurement Area(rmeas, xc, yc), withrelevance RInit , and relevance RFinal , the corresponding obfuscated areaArea(r′, x′, y′) = E(Area(rmeas, xc, yc),RInit ,RFinal ) is an area such that r′ ≥ rmeas,and (x′, y′) = (xc, yc).

• Reduce (R). It degrades the accuracy of a location measurement by re-ducing its radius. Given a location measurement Area(rmeas, xc, yc), withrelevance RInit , and relevance RFinal , the corresponding obfuscated areaArea(r′, x′, y′) = R(Area(rmeas, xc, yc),RInit ,RFinal ) is an area such that r′ ≤ rmeas,and (x′, y′) = (xc, yc).


Table 5.1: Obfuscation operatorsOperator Operator Syntax Output Description

Enlarge (E) E(Area(rmeas, xc, yc),RInit ,RFinal) Area(r′, xc, yc) withr′ ≥ rmeas

Derive an obfuscatedarea by enlarging theoriginal radius.

Reduce (R) R(Area(rmeas, xc, yc),RInit ,RFinal) Area(r′, xc, yc) withr′ ≤ rmeas

Derive an obfuscatedarea by reducing theoriginal radius.

Shift (S) S(Area(rmeas, xc, yc),RInit ,RFinal) Area(rmeas, x′, y′)

with (x′, y′) = (xc +d sin θ, yc + d cos θ)

Derive an obfuscatedarea by shifting theoriginal center.

Figure 5.1: Obfuscation by enlarging the radius (a), reducing the radius (b), and shiftingthe center (c)

• Shift (S). It degrades the accuracy of a location measurement by shift-ing its center. Given a location measurement Area(rmeas, xc, yc), withrelevance RInit , and relevance RFinal , the corresponding obfuscated areaArea(r′, x′, y′) = S(Area(rmeas, xc, yc),RInit ,RFinal ) is an area such that r′ = rmeas,and (x′, y′) = (xc + d sin θ, yc + d cos θ).

5.4.2 Obfuscation by enlarging the radius

As already observed, obfuscating a location measurement area by increasing its radius (seeFigure 5.1(a)) is the technique that most solutions exploit, either explicitly or implicitlyby scaling a location to a coarser granularity (e.g., from meters to hundred of meters, froma city block to the whole town and so on). The obfuscation is a probabilistic effect due to adecreasing of the corresponding joint pdf, which can be expressed as ∀rmeas, r

′, rmeas ≤ r′ :frmeas(x, y) ≥ fr′(x, y). Key to calculate the obfuscated area is the following proposition.

Proposition 1. Given a location measurement of radius rmeas with relevance RInit , andan obfuscated area of radius r′ derived by enlarging the radius of the location measure-


ment, relevance RFinal of the obfuscated area is calculated by multiplying RInit by the ratiofr′ (x,y)

frmeas (x,y) of the corresponding joint pdf.

From the definition of uniform distribution over a circular area, the relation can bewritten as:

RFinal =fr′(x, y)

frmeas(x, y)RInit =

1πr′2

1πr2

meas

RInit =r2

meas

r′2RInit =

8><>:RInit r′ = rmeas

(RInit , 0) r′ > rmeas

→ 0 r′ → +∞(5.4)

Given two relevances, RInit and RFinal , and radius rmeas of a location measurement,an obfuscated area calculated with this technique has a final radius:

r′ = rmeas

rRInit

RFinal. (5.5)

This relation permits to calculate an obfuscated area by enlarging radius rmeas toradius r′, which satisfies, according to our semantics, the user privacy preference RFinal .

5.4.3 Obfuscation by reducing the radius

Another possible way of obfuscating a user location consists in reducing the radius rmeas

of one location measurement to a smaller radius r′, as showed in Figure 5.1(b). Theobfuscation effect, in this case, is produced by a correspondent reduction of the probabilityto find the real user location within the returned area, whereas the joint pdf is fixed.

To state it formally, consider the unknown real user position coordinates (xu, yu).Given a location area of radius r, the probability that the real user position falls in thearea is denoted P ((xu, yu) ∈ Area(r, x, y)). When we obfuscate by reducing the radius, anarea of radius r′ ≤ rmeas is returned, which implies that P ((xu, yu) ∈ Area(r′, xc, yc)) ≤P ((xu, yu) ∈Area(rmeas, xc, yc)), because a circular ring having joint pdf greater than zerohas been excluded. The obfuscated area, derived by a radius reduction, can be calculatedby considering the following proposition.

Proposition 2. Given a location measurement of radius rmeas with relevance RInit , andan obfuscated area of radius r′ derived by reducing the radius of the location measure-ment, relevance RFinal of the obfuscated area is calculated by multiplying RInit by the ratio

P ((xu,yu)∈Area(r′,xc,yc))P ((xu,yu)∈Area(rmeas,xc,yc))

of corresponding probabilities.

In Cartesian coordinates, a probability P ((x, y) ∈ A), for all subsets A ⊆ R2, iscalculated as

∫∫A f(x, y)dxdy, being f(x, y) the corresponding joint pdf. Changing to polar

coordinates (s, θ) and solving the double integral requires the transformation (x, y) →(s, θ), which gives dxdy = sdsdθ [103]. The pdf, instead, remains unchanged to the valueobtained from the original location measurement, that is, f(s, θ) = 1

πr2meas

. According tothese observations, we have that:


P ((xu, yu) ∈ Area(r′, xc, yc)) =

Z 2π

0

Z r′

0

f(s, θ)sdsdθ = 2π

Z r′

0

s

πr2meas

ds =2

r2meas

Z r′

0

sds =

=r′2

r2meas

Analogously, P ((xu, yu) ∈Area(rmeas, xc, yc)) can be calculated as

P ((xu, yu) ∈ Area(rmeas, xc, yc)) =

Z 2π

0

Z r′

0

f(s, θ)sdsdθ +

Z 2π

0

Z rmeas

r′f(s, θ)sdsdθ =

=r′2

r2meas

+2

r2meas

Z rmeas

r′sds =

r′2

r2meas

+r2

meas − r′2

r2meas

=

=r2

meas

r2meas

= 1 (5.6)

resulting in a probability equals to 1 of having the user u inside the location mea-surement Area(rmeas, xc, yc). This result was expected by Definition 5.2.1. Therefore, therelation stated in the proposition can be written as:

RFinal = P ((xu,yu)∈Area(r′,xc,yc))P ((xu,yu)∈Area(rmeas,xc,yc))

RInit = r′2

r2meas

RInit =

8><>:RInit r′ = rmeas

(RInit , 0) r′ < rmeas

→ 0 r′ → 0

(5.7)

Given two relevances, RInit and RFinal , and radius rmeas of the location measurement,an obfuscated area calculated with this technique has a final radius:

r′ = rmeas

rRFinal

RInit. (5.8)

This relation permits to calculate an obfuscated area by reducing radius rmeas to radiusr′, which satisfies, according to our semantics, the privacy preference RFinal .

5.4.4 Obfuscation by shifting the center

Location obfuscation can also be achieved by shifting the center of the location measure-ment area and returning the displaced area, as showed in Figure 5.1(c). Intuitively, theobfuscation effect depends on the intersection of the two areas, that is, the smaller theintersection, the highest the obfuscation. In this work, we do not consider acceptable toproduce obfuscated areas disjoint from the original measured location areas. The reasonis that all disjoint areas would have probability equal to zero of including the real userlocation, and then they would be indistinguishable for our relevance estimator. Such casesare considered as just false location information, which, by design, our system does not


produce, assuming that LBS and related applications (e.g., LBAC [9, 10, 22]) cannot dealwith false information in the provision of a business service.

We call rmeas the radius of the original and the obfuscated areas, here assumed tobe the same, and d the distance between the centers. Since the two areas cannot bedisjoint, d ∈ [0, 2rmeas]. In particular, if d=0, there is no privacy gain; if d=2rmeas, thereis maximum privacy; and if 0 < d < 2rmeas, there is an increment of privacy. In additionto distance d, a rotation angle θ must be specified to derive an obfuscated area by shiftingthe center. Angle θ can be assumed to be generated randomly with no loss of generality.Strategies for selecting a value of angle θ depends on the application context and aredeeply analyzed in Section 5.7.2 [10, 11].

Given d and θ, we denote the obfuscated area as Area(rmeas, xc + d sin θ, yc + d cos θ)and the intersection between the location measurement and the obfuscated area asAreaInit∩Final =Area(rmeas, xc, yc)

⋂Area(rmeas, xc + d sin θ, yc + d cos θ).

To measure the obfuscation effect and define the relation between relevances,two probabilities must be composed. The first is the probability that thereal user position falls in the intersection AreaInit∩Final, that is, P ((xu, yu) ∈AreaInit∩Final|(xu, yu) ∈Area(rmeas, xc, yc)). The second is the probability that onepoint selected from the whole obfuscated area belongs to the intersection, that is,P ((x′, y′) ∈ AreaInit∩Final|(x′, y′) ∈ Area(rmeas, xc + d sin θ, yc + d cos θ)). The productof these two probabilities estimates the reduction of the relevance due to the obfuscation.The obfuscated area, derived by shifting the center, can be calculated by considering thefollowing proposition.

Proposition 3. Given a location measurement of radius rmeas with relevance RInit , andan obfuscated area of same radius derived by shifting the original center of distance d andangle θ, relevance RFinal of the obfuscated area is calculated by multiplying RInit by:

P ((xu, yu) ∈ AreaInit∩Final|(xu, yu) ∈Area(rmeas, xc, yc)) · P ((x′, y′) ∈ AreaInit∩Final|(x′, y′) ∈Area(rmeas, xc + d sin θ, yc + d cos θ)).

Since the two probabilities can be expressed as:

P ((xu, yu) ∈ AreaInit∩Final|(xu, yu) ∈ Area(rmeas, xc, yc)) =AreaInit∩Final

Area(rmeas, xc, yc)

P ((x′, y′) ∈ AreaInit∩Final|(x′, y′) ∈ Area(rmeas, xc + d sin θ, yc + d cos θ)) =

=AreaInit∩Final

Area(rmeas, xc + d sin θ, yc + d cos θ)

it follows that:


RFinal =AreaInit∩Final ·AreaInit∩Final

Area(rmeas, xc, yc) ·Area(rmeas, xc + d sin θ, yc + d cos θ)RInit = (5.9)

=

8><>:RInit d = 0

(RInit , 0) 0 < d < 2rmeas

→ 0 d = 2rmeas

This represents correctly our concept of relevance and, from Equation (5.10), it followsthat RFinal

RInit= AreaInit∩Final·AreaInit∩Final

Area(rmeas,xc,yc)·Area(rmeas,xc+d sin θ,yc+d cos θ) . Given RFinal , and πr2meas as the

value of both areas, the overlapping can be expressed as: AreaInit∩Final = πr2meas·

√RFinalRInit

.Expanding the term AreaInit∩Final as a function of distance d between the centers, dis-tance d can be calculated numerically by solving the following system of equations whosevariables are d and σ.

(σ − sin σ =

√δπ with δ = AreaInit∩F inal·AreaInit∩F inal

Area(rmeas,xc,yc)·Area(rmeas,xc+d sin θ,yc+d cos θ)

d = 2rmeas cos σ2

(5.10)

Variable σ represents the central angle of the circular sector identified by the tworadii connecting the center of the original area with the intersection points of the originaland the obfuscated areas. These two equations represent the solution to the problem ofcalculating the distance d between the centers of two partially overlapped circumferences,in the special case of same radius. Note that, the same proposition holds also whenlocation measurement and obfuscated area have different radii. The only difference in thediscussion is that the system of equations (C.2), reported in Appendix C, has to be solvedrather than the one in (5.10).

Having distance d and angle θ, this relation permits to calculate an obfuscated areaby shifting the center, which satisfies, according to our semantics, the privacy preferenceof user RFinal .

5.4.5 Obfuscation examples

We provide three examples, one for each obfuscation technique, showing how startingfrom the privacy preference RFinal and a location measurement Area(rmeas, xc, yc) withrelevance RInit , the obfuscated area with relevance RFinal is calculated.

Example 5.4.1 (Obfuscation by enlarging the radius). Suppose that a user specifies herprivacy preference as RFinal=0.16. Suppose that the location measurement of the userhas radius rmeas=0.5 km, and the optimal measurement accuracy is ropt=0.4 km. Giventhis information, relevance RInit associated with the location measurement is calculated

as RInit=r2opt

r2meas

=0.64. The application of operator E produces an obfuscated area with


relevance RFinal , and radius derived by calculating r′ = rmeas

√RInitRFinal

=1 km from equation(5.5).

Example 5.4.2 (Obfuscation by reducing the radius). Suppose that a user specifies herprivacy preference as RFinal=0.16. Suppose that the location measurement of the userhas radius rmeas=0.5 km, and the optimal measurement accuracy is ropt=0.4 km. Giventhis information, relevance RInit associated with the location measurement is calculated as

RInit=r2opt

r2meas

=0.64. The application of operator R produces an obfuscated area with rele-

vance RFinal , and radius derived by calculating r′ = rmeas

√RFinalRInit

=0.25 km from equation(5.8).

Example 5.4.3 (Obfuscation by shifting the center). Suppose that a user specifies herprivacy preference as RFinal=0.4. Suppose that the location measurement of the user hasradius rmeas=1 km, and the optimal measurement accuracy is ropt=0.895 km.4 Giventhis information, relevance RInit associated with the location measurement is calculated as

RInit=r2opt

r2meas

=0.8. The application of operator S produces an obfuscated area with relevanceRFinal , by calculating distance d=0.464 km solving the system of equations (5.10). Finally,an angle θ is randomly selected and the obfuscated area is generated.

Examples 5.4.1 and 5.4.2 show that, starting from the same privacy preference of a user,two obfuscation processes may result in different areas while guaranteeing the requesteddegree of privacy. In conclusion, by definition, given Area(rmeas, xc, yc) qualified by RInit

and the privacy preferenceRFinal , the location area produced by one obfuscation techniqueis equivalent, in term of privacy, to the area produced by the others obfuscation techniques,even though the returned areas are different.

5.5 Double obfuscation

We now discuss how our obfuscation techniques can be composed to increase the robustnessof the obfuscation process with respect to possible de-obfuscation attempts performedby adversaries. Given the obfuscation techniques just introduced, privacy preferences ofthe users can be satisfied either by using one technique individually or composing twotechniques. Recalling that the ultimate goal of an obfuscation process is to reduce thelocation accuracy estimated by an initial relevance RInit to a final relevance RFinal , in caseof double obfuscation, we need one intermediate value to represent the relevance achievedby the first obfuscation. Although in theory it is possible to compose an arbitrary numberof obfuscation steps by combining operators E, R, and S, we have never any convenienceto combine more than two techniques, as we will demonstrate in the following of this

4We are aware that ropt=0.895km is far from reality, but it was assumed for simplicity.

5.5. Double obfuscation 105

Table 5.2: Obfuscation operators refinementOperator Operator Syntax Output

Enlarge (E) EA,R(Area(r, x, y),R′) Area(r′, x, y) with r′ ≥ r

Reduce (R) RA,R(Area(r, x, y),R′) Area(r′, x, y) with r′ ≤ r

Shift (S) SA,R(Area(r, x, y),R′) Area(r, x′, y′) with (x′, y′) = (x + d sin θ, y +d cos θ)

section. For this reason, only a single intermediate relevance RInter for the intermediateobfuscation is introduced.

5.5.1 Operators composition

Using double obfuscation, the obfuscated area produced by one obfuscation technique(operator h) is further obfuscated by the application of another technique (operator k).Double obfuscation introduces an important additional requirement that must be consid-ered. The obfuscation effect produced by the second operator k must always be evaluatedwith respect to the location measurement of the user together with its relevance RInit ,rather than the area produced by the first operator. The reason is that when two obfusca-tion operators are composed, the second obfuscation has to produce an area that respectsthe privacy preference RFinal , which is a relative accuracy degradation of the original loca-tion measurement. As a consequence, the second obfuscation step is always applied withrelevances RInit and RFinal . This slightly changes the definition of our operators, sincethe operators used at the second step of a double obfuscation are applied to the area gen-erated at the first step of obfuscation, but they always refer to the location measurementin generating the final obfuscated area. Operators definition is refined as follow.

Definition 5.5.1 (Obfuscation operator). Let A be the set of circular areas, and A ∈ Athe referenced area with relevance R. An obfuscation operator opA,R : A× (0, 1] → A overA and R takes an area and a relevance as input and produces an obfuscated area as outputsuch that:

1. ∀A′,R′ : A′ ∈ A, A′ ∩A 6= , R′ ∈ (0, 1], and R′ ≤ R ⇒ opA,R(A′,R′) = A′′ ∈ A;

2. A′′ ∩A 6= ;

3. A′′ has relevance R′.

From Definition 5.4.1 and Definition 5.5.1, it follows thatop(Area(r, x, y),R,R′) ≡ opA,R(Area(r, x, y),R′) for a single obfuscation or a firststep of double obfuscation since, in those cases: i) A = Area(r, x, y), ii) opR(.) ≡op(R, .).Refined obfuscation operators are summarized in Table 5.2 with A=Area(rmeas, xc, yc),R=RInit , R′=RFinal ∨ RInter .


Figure 5.2: Obfuscation operators composition

In the following, the operators composition is discussed in details. Consider two ob-fuscation operators hA,R and kA,R defined over the same area A with relevance R. If thetwo operators are combined, the result is kA,R(hA,R(.)) = kA,R(hA,R(A,RInter ),RFinal ),where A=Area(rmeas, xc, yc) and the area produced by applying the operator hA,R to thelocation measurement A is the input to the second operator kA,R, which finally producesthe obfuscated area. Figure 5.2 shows the composition with input and output parametersof the operators.

Figure 5.3 illustrates an example of double obfuscationSE=SA,R(EA,R(A,RInter ),RFinal ), with A = Area(rmeas, xc, yc). Considering thefirst obfuscation E, the radius of area B is calculated as seen for the enlargement, thatis, RInter=

r2measr′2 · R, with R =RInit . In applying the second step S, operator Shift is

used with an important constraint: the domain of the Shift operator must be restrictedto those areas that have an intersection with the location measurement (i.e., intersectionbetween area C and area A in Figure 5.3). To calculate the final obfuscated area C,it is the overlap between C and the original area A that determines the value d ofthe center-shifting, rather than the overlap between C and B. In this example, whereEquation (5.10) is used to calculate the distance of a center-shifting, the relevance RFinal

is calculated as RFinal=(A∩C)·(A∩C)

A·C · R, with R =RInit .As a second example, consider the composition ES between operator S (1st step) and

E (2nd step). This case, and in general all double obfuscations with an E or R operatoras a second step, requires a different management process. The obfuscation process could


Figure 5.3: Example of SE obfuscation

result either in a final area C that is partially overlapped with the location measurement(see Fig. 5.4(a)) or in a final area C that fully includes the location measurement (seeFig. 5.4(b)). In particular, if area C is partially overlapped with area A (Fig. 5.4(a)),RFinal=

(A∩C)·(A∩C)A·C ·R, withR =RInit , must be solved. In this case, however, distance d is

known and the enlarged radius r′ is the variable that has to be computed. If area C includesarea A (Fig. 5.4(b)), instead, the obfuscation must be calculated as RFinal=

r2measr′2 ·R, with

R =RInit . This equation, however, directly derives from the partially overlapped case,since the scalar factor (A∩C)·(A∩C)

A·C is equal to AC = r2

measr′2 . Although, the calculation of the

final obfuscated areas is the same in both cases, the double obfuscation ES must treat thetwo cases, partial overlapping and inclusion, separately, since they have different behaviorswhen analyzed with respect to an adversary that tries to reduce the obfuscation effectsby means of de-obfuscation attempts (see Section 5.6). Similar observation holds for thecomposition RS between operator S (1st step) and R (2nd step).

In the following, we discuss the peculiarities of obfuscation composition providing thelist of available obfuscation processes.

5.5.2 Available obfuscation processes

The combinations of obfuscation operators E, R, and S, in theory, could be extended to anundefined number of subsequent steps, each one achieving an intermediate relevance, untilrelevance RFinal is reached. Although theoretically possible, a number of steps greaterthan two is useless. To demonstrate this result and calculate the minimum set of availableobfuscation processes, we rely on the geometric properties of the circles showing that,given two circles C1, with radius r1 and centered in (x1, y1), and C2, with radius r2 andcentered in (x2, y2), C2 can be generated starting from C1 with just two operations: i)a center shifting such that (x1, y1) = (x2, y2), and ii) a radius enlargement or reductionsuch that r1 = r2. This property is independent from the operations order.

What it can be easily demonstrated is that, given an area A with relevance R, all


Figure 5.4: Examples of ES obfuscation (partial overlapping (a) or inclusion (b))

possible obfuscated areas A∗A,R, that is, all the possible areas generated by the application

over area A with relevance R of obfuscation processes composed by an arbitrary numberof steps, can be generated by applying single obfuscation steps (E, R, S) and double ob-fuscation processes composing a S operator and an E or R operator. The only differencewith the geometry is that, in calculating the available set of obfuscation processes thatproduces all the possible areas A∗

A,R, the steps order must be considered. As a result, theavailable set of obfuscation processes Σ is defined as follow.

Definition 5.5.2. The available set of obfuscation processes is defined asΣ=E,R,S,SE,ES,SR,RS.

Definition 5.5.3. Consider a referenced area A with relevance R. Let Σ be the set ofavailable obfuscation processes and AΣ

A,R be the set of areas generated by applying anyobfuscation process in Σ over A. The set Σ is:

• complete, meaning that ∀Ω ⊃ Σ,AΩA,R = AΣ

A,R = A∗A,R;

• minimum, meaning that ∀Γ ⊂ Σ, ∃A′ ∈ AΣA,R : A′ /∈ AΓ

A,R.

Below, we demonstrate that two obfuscation processes applying the same techniquesbut in different order (e.g., ES and SE) are different and must be managed separately. Thesteps order of obfuscation processes affect the set of areas that can be produced by theapplication of the processes themselves. Considering ES and SE processes, the followingtheorem is introduced.


Figure 5.5: Example of SE obfuscation process producing an area impossible for ES obfus-cation process

Theorem 5.5.1. Given obfuscation processes ES and SE, the set of areas AESA,R,ASE

A,R ⊂ A,which can be produced by applying these obfuscation processes over area A with relevanceR, are such that:

1. AESA,R 6⊆ ASE

A,R, and

2. ASEA,R 6⊆ AES

A,R.

Proof. The above theorem is proofed by contradiction. First, suppose that AESA,R ⊆ ASE

A,R.This assumption is false since ES can produce obfuscated areas including the original area,which cannot be generated by SE. This confutes the assumption resulting in AES

A,R 6⊆ ASEA,R.

Then, assume that ASEA,R ⊆ AES

A,R and that the obfuscation process SE depicted in Figure5.5 is applied. By the assumption made above, there should exist an equivalent ES processthat produces the same area. However, this is not possible, since a suitable S operatordoes not exist. By our definition, in fact, the S operator must always produce an areahaving a partial overlapping with the original area. Therefore, as showed in Figure 5.5,an ES process producing the same area of the SE process is not available. This confutesthe original assumption and, therefore, ASE

A,R 6⊆ AESA,R.

The same discussion holds also for SR and RS obfuscation processes. In particular, thefollowing theorem is introduced.

Theorem 5.5.2. Given two obfuscation processes RS and SR, the set of areasARSA,R,ASR

A,R ⊂ A, which can be produced by applying these obfuscation processes overarea A with relevance R, are such that:


Table 5.3: Double obfuscation types and operationsOperators Schema 1st obfuscation 2nd obfuscation

SEEnlarge

RInter =r2

measr′2 RInit

ShiftRFinal = (A∩C)2

A·C RInit

SRReduceRInter = r′2

r2meas

RInit

ShiftRFinal = (A∩C)2

A·C RInit

ES

ShiftRInter = (A∩B)2

A·B RInit

Enlarge

RFinal = (A∩C)2

A·C RInit

r′ to be derived


A·B RInit

Enlarge

RFinal =r2

measr′2 RInit

RS


A·B RInit

ReduceRFinal = (A∩C)2

A·C RInit

r′ to be derived


A·B RInit

ReduceRFinal = r′2

r2meas

RInit

1. ARSA,R 6⊆ ASR

A,R, and

2. ASRA,R 6⊆ ARS

A,R.

To conclude, the available obfuscation processes are seven: i) three single obfuscations:E, R, S, and ii) four double obfuscations: ES, SE, RS, SR. Table 5.3 shows, for each com-


Function Obfuscation(locationArea,RInit ,RFinal)/* Random selection of the process and RInter init (for double obfuscation only) */obf:=random(E,R,S,SE,SR,ES,RS);if ((obf6=E)∧(obf6=R)∧(obf6=S))RInter :=random(RFinal ,RInit);

endif/* Obfuscated area calculation*/obfuscatedArea=locationArea;case obf of

= E: obfuscatedArea := enlarge(locationArea,obfuscatedArea,RInit ,RFinal);= R: obfuscatedArea := reduce(locationArea,obfuscatedArea,RInit ,RFinal);= S: obfuscatedArea := shift(locationArea,obfuscatedArea,RInit ,RFinal);= SE: obfuscatedArea := enlarge(locationArea,obfuscatedArea,RInit ,RInter );

obfuscatedArea := shift(locationArea,obfuscatedArea,RInit ,RFinal);= SR: obfuscatedArea := reduce(locationArea,obfuscatedArea,RInit ,RInter );

obfuscatedArea := shift(locationArea,obfuscatedArea,RInit ,RFinal);= ES: obfuscatedArea := shift(locationArea,obfuscatedArea,RInit ,RInter );

obfuscatedArea := enlarge(locationArea,obfuscatedArea,RInit ,RFinal);= RS: obfuscatedArea := shift(locationArea,obfuscatedArea,RInit ,RInter );

obfuscatedArea := reduce(locationArea,obfuscatedArea,RInit ,RFinal);endcasereturn (obfuscatedArea, RFinal);

Figure 5.6: Function Obfuscation

position of one operator E or R and one operator S, the operations needed to produce thefinal obfuscated area achieving user privacy preference RFinal .

5.5.3 Obfuscation algorithm

Figure 5.6 illustrates our obfuscation algorithm. We assume that relevance RInit and lo-cation measurement locationArea are given, and the selection of the obfuscation processis carried out randomly for increasing robustness with respect to possible de-obfuscationattempts.5 The algorithm takes the location privacy preference RFinal and the locationmeasurement area with relevance RInit as input, selects and applies an obfuscation pro-cess, and returns the obfuscated area with relevance RFinal . In particular, the first stepconsists in choosing randomly one obfuscation process. Then, if a double obfuscation isselected, relevance RInter is set with a value between RInit and RFinal . Finally, accordingto the chosen obfuscation process, the corresponding obfuscation techniques are executed,producing the obfuscated area.

5The study and design of advanced strategies for selecting a specific obfuscation process by considering,for example, contextual and environmental information will be the subject of future research.


Figure 5.7: Example of ES and RS obfuscation on a large scale

5.5.4 Double obfuscation examples

We describe two examples of possible application of double obfuscation. For the sake ofclarity, we consider an user located in Manhattan, around the Empire State Building. Weassume ropt=0.895km and a location measurement to have radius rmeas=1km (see the areawith filled line in Figure 5.7). The user has specified her privacy preference as RFinal=0.2.

Given this information RInit =r2opt

r2meas

=0.8 is calculated before applying any obfuscation.For the first example, an ES obfuscation has been applied. The obfuscation process

starts by setting RInter=0.4 and θ = π/4.Distance d=0.464km is calculated by solving the system of equations (5.10), and loca-

tion measurement area is shifted accordingly generating an obfuscated area of relevanceRInter . Finally, the Enlarge operator is applied, and final radius r′=2 km is computedto achieve relevance RFinal . In this way, when the user location is released to a LBS sheresults positioned in a bigger area that includes nearly all Central Manhattan (see the

5.6. Adversary model 113

area with dotted line in Figure 5.7).For the second example, suppose that we apply a SR obfuscation. Again, for simplicity

we set RInter=0.4 and θ = 3π/2. Radius r′=0.707 km is computed from (5.8) and the firstobfuscated area is produced. Then, the system of equations (C.2) is solved numericallyresulting in d =0.679 km, and the center is shifted. In this way, when the user location isreleased to a LBS, the user seems located just around Madison Square (see the area withdashed line showed in Figure 5.7).

5.6 Adversary model

The concept of relevance as a metric for location accuracy and privacy is needed to bal-ance privacy preferences of users and accuracy required in location-based applications.However, a sound definition of such a metric is not enough to measure the real privacyprotection provided by obfuscation techniques. In particular, the degree of robustnessof each obfuscation technique must be evaluated with respect to de-obfuscation attemptsperformed by adversaries. Accordingly, we say that an obfuscation technique is robust ifand only if it cannot be reversed by an adversary to obtain a location information thatapproximates the original measurement better than the obfuscated one. It follows that twoissues must be considered when obfuscation robustness is analyzed:

• whether an adversary can manipulate an obfuscated area and obtain a more accuratelocation;

• whether an adversary can evaluate the resulting accuracy gain or loss after the de-obfuscation attempt.

As discussed in the following, while it is relatively straightforward to de-obfuscate anarea by applying some transformations, the uncertainty associated with the outcome (i.e.,understanding whether the de-obfuscated area is more or less accurate than the obfuscatedone) could be irresolvable for an adversary. In such a case, the adversary has no additionalinformation about the location of the users. We call this situation blind de-obfuscationbecause it forces an adversary to act randomly and only obfuscation techniques thatpermit just this possibility will be considered strongly robust. We will show that such acondition does not always apply. Some techniques provide the adversary with a preferredde-obfuscation strategy. In that case, obfuscation techniques will be considered weaklyrobust.

The adversary model that we take into account is based on the following assumptions.First, all parties that receive or manage an obfuscated location without knowing theoriginal measurement are considered untrusted and could behave as adversaries. Second,an adversary is assumed to be aware of: the obfuscated location, the location sensingtechnology adopted by the specific location service, and all available obfuscation techniques.


Conversely, the specific obfuscation technique applied to produce the obfuscated location(one among those described in Section 5.5), is assumed to be unknown.

The first consequence of such an adversary model is that an obfuscation process cannotbe limited to just increasing the granularity of a measurement (e.g., from meters to hun-dreds of meters or by applying our E operator). Given the information an adversary owns,it is likely to be able to reverse the obfuscation effect by guessing a reasonable reductionof the radius of an obfuscated area. For instance, let us assume that the location of a userwalking in an urban area has been obfuscated by just increasing the radius to return anarea that covers the whole city, rather than a circular area with radius of some hundreds ofmeters. It would be reasonable for an adversary to reduce the obfuscated area to one thatcovers just few neighborhoods. Whereas such a trivial de-obfuscation does not produceexactly the original measurement, it provides the adversary with a better approximationof the original measurement than the obfuscated area, hence, reducing the user’s locationprivacy.

In general, the same discussion applies to each obfuscation technique that scale up ordown the extension of a location area, like our E and R operators, because given somecontextual information, a de-obfuscation could be easily performed. However, the combi-nation of different techniques provides a higher degree of robustness.

5.6.1 Contextual information

Contextual information is important for an adversary trying to de-obfuscate a locationmeasurement because it can provide hints for focusing on some obfuscation techniques anddisregarding others. However, collecting reliable application context information could bedifficult and time-consuming in many circumstances.

To increase the odds of successfully de-obfuscating a location, an adversary could iden-tify the subset of those obfuscation techniques that are compatible with the obfuscatedlocation it has observed. For instance, if the adversary observes a location area with a ra-dius apparently unusually small, it could infer that the location area has been obfuscatedapplying at least a R operator. Therefore, the subset of suitable obfuscation operatorscan be restricted to R, RS, SR. Analogously if the radius of observed location area ap-pears unusually large, the subset of obfuscation operators possibly applied is restricted toE, ES, SE. Given their importance in the analysis, we call such two subsets as: R-familyand E-family, which are all those techniques that use a reduction and an enlargement,respectively. The ability to recognize the actual subset is key to an adversary, becauseit makes a clear cut between de-obfuscation attempts based on enlarging or reducing theradius of the obfuscated area.

Recalling that, to make such a distinction the adversary must recognize “unusuallysmall” or “unusually large” radii, this could be a costly and time-consuming process dueto the very nature of location measurements, whose accuracy strongly depends on environ-mental factors, such as weather conditions or building materials. Therefore, “unusually


Figure 5.8: Example of de-obfuscation of SR combination

small” or “unusually large” radii, except for evidently abnormal values, must be evaluatedwith respect to the average measurement errors produced by the specific location tech-nology in the specific area of interest (and possibly in the same measurement conditions).Performing this evaluation implies, in general, the availability of a reliable statistic ofmeasurement errors in the observed area, which can be collected as a result of field testsduring different days with different environmental conditions. Without such a statistic,the above inference could bring to erroneous guesses and an adversary behaving rationallyis no longer able to distinguish between R- and E-family.

In the following, we evaluate the degree of robustness of each family of obfuscationtechniques with respect to de-obfuscation attempts performed by adversaries.

5.6.2 R-family de-obfuscation

Under the worst assumption that an adversary can infer that an observed obfuscated areahas been generated by a technique belonging to the R-family, de-obfuscation efforts arefocused on reversing the obfuscation effects through an enlargement of the radius of theobfuscated area.

Figure 5.8(a) shows an example of SR obfuscation and Figure 5.8(b) the correspondingde-obfuscation attempt made by an adversary. Areas A, B, C, and D are, respectively, thelocation measurement, the intermediate obfuscated area produced by the R operator, the


final obfuscated area produced by the S operator, and the de-obfuscated area produced byenlarging the radius of area C. As a result, enlarging the radius of area C to the radius ofarea D increases the overlapping with area A (see in Figure 5.8(b) the overlapping of areaC and area D with area A). Then, considering the scalar factor used in Equation (5.10),it results that (A∩D)·(A∩D)

A·D > (A∩C)·(A∩C)A·C . The direct consequence is that the relevance

RFinal associated with area D is greater than the relevance associated with area C, and thede-obfuscation attempt succeeds in reducing user’s location privacy. Same considerationholds for RS and R obfuscations too.

Summarizing, for R-family obfuscations, an adversary is likely to reduce user’s privacyby enlarging the radius of the observed location. Figure 5.9 shows the diagrams represent-ing the variation of relevance (Y axis) as a function of the radius (X axis). De-obfuscationresult is intuitively showed at the bottom of diagrams in Figure 5.9, with label “+” stat-ing a successful de-obfuscation, and label “-” stating a failed de-obfuscation. Importantradius values are:

• radius r′. It is the radius of the obfuscated area associated with relevance RFinal . Itrepresents the starting point for a de-obfuscation attempt;

• radius rmax. It is the radius that produces the best relevance RMax. It representsthe best de-obfuscation that an adversary can achieve;

• radius rBP . It is the radius that produces the same relevance RFinal as radius r′.It represents the breakpoint value for the enlargement after which the adversaryproduces a de-obfuscated area of lesser relevance than RFinal .

Given these reference values for the radius and starting from r′, the adversary mayencounter an obfuscated area produced by either operator R, combination RS (inclusion andpartial overlapping) or SR, which have different behaviors. In particular, if the obfuscatedarea was produced by operator R, the de-obfuscation permits to increase relevance fromr′ to rmax with the quadratic function (5.7) of R operator’s definition (see Figure 5.9(a)).Radius rmax represents radius rmeas of the original location area, which is associated withrelevance RMax=RInit . If the adversary exceeds radius rmax, then the relevance decreasesin the same vein of an obfuscation produced by enlarging the radius. The relevance loss,in fact, follows the same quadratic function (5.4) of E operator. Figure 5.9(a) shows thediagram for R operator.

A different behavior is exhibited by RS (partial overlapping) and SR combinationsbecause the equation that models the relevance function is based on the partial overlappingproduced by the shifting. Recalling the S operator, Equation (5.10) expresses the resultingrelevance as a function of the overlapping of the areas. For combinations RS (partialoverlapping) and SR, de-obfuscation succeeds between r′ and rmax. Radius rmax, whererelevance RMax is retrieved is smaller than radius rmeas of original location area plusdistance d between centers. For values greater than rmax, the relevance decreases. In


Figure 5.9: Adversary gains in de-obfuscation attempts against R-family obfuscation: (a)R, (b) RS(partial overlapping)/SR, (c) RS(inclusion).


particular, for values greater than rmeas + d, the relevance loss follows the same quadraticfunction (5.4) of E operator. Radius rBP is equal to rmeas

√RInitRFinal

for both combinationsRS (partial overlapping) and SR. Figure 5.9(b) shows the diagram for combinations RS(partial overlapping) and SR.

Finally, RS (inclusion) combination shows same behavior of RS (partial overlapping)and SR. The only difference, which does not affect the previous discussion, is that the slopeof the curve (see Figure 5.9(c)) changes at the beginning, following the quadratic function(5.7) of R operator.

From the analysis of the R-family obfuscation techniques, it can be easily observedthat, starting from radius r′, an adversary always successfully de-obfuscates the observedarea unless the enlargement exceeds radius rBP . Therefore, a radius enlargement is thestrategy to de-obfuscate R-family obfuscation techniques. For this reason, the R-familyexhibits a weak robustness, meaning that in the worst case, when an adversary is able toguess the obfuscation family, it does not fully enforce the user’s privacy level.

5.6.3 E-family de-obfuscation

Similarly to the R-family case, we assume, as the worst case, an adversary able to inferthat an obfuscated area has been generated by a technique belonging to the E-family (i.e.,E, ES, SE). Intuitively, the adversary should reduce the radius of the obfuscated area tode-obfuscate.

Differently from the R-family, however, the E-family does not expose any strategy forde-obfuscation. To show this, two cases must be discussed separately:

• i) de-obfuscation attempts against E and ES (when the obfuscated area includes theoriginal one);

• ii) de-obfuscation attempts against SE and ES (when the obfuscated area just partiallyincludes the original one).

Figure 5.10 shows two de-obfuscation examples corresponding to ES (inclusion) (Figure5.10(a)) and SE (Figure 5.10(b)) obfuscations. Similarly to the previous example, AreasA, C, and D are, respectively, the location measurement, the final obfuscated area, and thede-obfuscated area produced by manipulating the radius of area C.6 With respect to thefirst example of Figure 5.10(a), the adversary can actually recover an area having betterrelevance by reducing the radius of the observed obfuscated area. Considering equation(5.4), it can be seen that r2

A/r2D > r2

A/r2C , meaning that the relevance associated with

area D is greater than the relevance RFinal associated with area C, and then locationprivacy decreases. By contrast, in the second example of Figure 5.10(b), which shows aSE combination, the adversary can recover an area with a better relevance by enlarging,

6For simplicity, Area B, the intermediate obfuscated area, has been omitted.


rather than reducing, the radius of the obfuscated area. Considering equation (5.10), wehave that (A∩D)·(A∩D)

A·D > (A∩C)·(A∩C)A·C , meaning that the relevance associated with area D

is greater than the relevance RFinal associated with area C, and again location privacydecreases.

The strong robustness can be observed by considering how the relevance varies withrespect to a manipulation of the radius of the obfuscated area, for all techniques of theE-family.

For obfuscated areas produced by operator E, Figure 5.11(a) presents the diagram thatshows how de-obfuscation succeeds between rmax and r′. The gain obtained by reducingthe radius is modeled by the quadratic function (5.4) of E operator’s definition. Radiusrmax represents radius rmeas of original location area, where relevance RMax=RInit isretrieved. If the adversary reduces until a radius lesser than rmax, then the relevance de-creases in the same vein of an obfuscation produced by reducing the radius. The relevanceloss, in fact, follows the same quadratic function (5.7) of R operator.

A similar behavior is exhibited by ES (inclusion), as showed in Figure 5.11(b). Inparticular, de-obfuscation succeeds between rmax and r′. Radius rmax, where relevanceRMax <RInit is obtained,7 is smaller than the sum of radius rmeas of original locationarea plus distance d between centers. For values lesser than rmax, the relevance loss isa function of the overlapping of the areas (see equation (5.10)). Radius rBP is equal to

rmeas

√RFinalRInit

for both E and ES (inclusion).

In summary, in both cases of E and ES (inclusion), a radius reduction permits toincrease the associated relevance unless the reduction exceeds rBP .

Conversely, combinations SE and ES (partial overlapping) exhibit an opposite behavior.Diagram for the relevance function is showed in Figure 5.11(c). Between r′ and rmax, theslope is modeled by equation (5.10), which calculates the partial overlapping produced bythe S operator. Relevance RMax <RInit is obtained for radius rmax that is smaller thanthe sum of radius rmeas of original location area plus distance d between centers. Forvalues greater than rmeas +d, the relevance loss is quadratic as for operator E. Radius rBP

is equal to rmeas

√RInitRFinal

for both SE and ES (partial overlapping).

Therefore, differently from E and ES (inclusion), in both cases of SE and ES (partialoverlapping), a radius enlargement permits to increase the associated relevance until rBP .

Combining the behaviors of the four obfuscation techniques that belong to the E-family, as showed in Figure 5.12, no preferred de-obfuscation strategy between enlargingor reducing can be recognized. This means that an adversary is forced to act blindly byrandomly choosing a reduction or an enlargement with no information about the outcome.For this reason, we define the E-family as strongly robust, meaning that even in the worstcase the user’s privacy level is fully enforced.

7This because to reach RInit , the S operator of the ES combination must be de-obfuscated too, not justthe E one.


Figure 5.10: De-obfuscation of E-family obfuscations: (a) ES (inclusion), (b) SE

5.6.4 S-family and *-family de-obfuscation

Having analyzed the two most important cases of R- and E-family, for completeness, othertwo possibilities must be considered. They represent an adversary that cannot distinguishbetween R- or E-family. In this case, we first consider that the adversary could assumethat the S operator has been applied, and then the case of no assumption at all.

For the first case, the subset of suitable obfuscations can be restricted toS, SE, ES, SR, RS and we call such a subset S-family. Intuitively, the adversary focusesits de-obfuscation efforts on reversing the obfuscation effects through a shifting of thecenter, rather than scaling the radius. However, by definition, a S operator introduces arandom parameter (i.e., the rotation angle θ) that an adversary cannot evaluate. The con-sequence is that if an adversary makes a random guess it is not able to estimate whetherthe recovered area has better relevance than the obfuscated one. For this reason a strategyfocusing on a de-obfuscation by shifting the center needs more specific contextual infor-mation like, for example, map constraints or information about user’s habits, rather thanthose we have assumed as the worst case to distinguish between R- or E-family. As a con-sequence, also in case of S-family, we consider an adversary that tries to de-obfuscated theobserved area by enlarging or reducing the radius of the obfuscated area. In particular, aspreviously discussed, SE, ES (partial overlapping), SR, and RS obfuscation techniques canbe de-obfuscated by enlarging the radius of the observed area, while ES (inclusion) can bede-obfuscated by reducing the radius of the area. Concerning S obfuscation, it representsa particular case of SR or SE obfuscation and then it can be de-obfuscated by a radiusenlargement as well. The consequence is that there is a preferred de-obfuscation strategy,the radius enlargement.

In the second case, the adversary makes no assumption and the whole set of availabletechniques (i.e., E, R, S, SE, ES, SR, RS) is considered. We call such a set *-family. In thiscase, S, SE, ES (partial overlapping), R, SR, and RS obfuscation techniques can be de-


Figure 5.11: Adversary gains in de-obfuscation attempts against E-family obfuscation: (a)E, (b) ES (inclusion), (c) SE and ES (partial overlapping)


Figure 5.12: Adversary gain in de-obfuscation attempt against E-family obfuscation

obfuscated by enlarging the radius of the observed area, while ES (inclusion) and E can bede-obfuscated by reducing the radius of the area. The same diagrams showed for E-familyand R-family holds for *-family. Again, the consequence is that the radius enlargement isthe preferred de-obfuscation strategy.

5.6.5 Using entropy to evaluate the degree of robustness

To measure the degree of robustness provided by obfuscation techniques, the uncertaintywith regard to the effect of a de-obfuscation attempt is key for an adversary. Our definitionfor the degree of robustness is based on probabilities: after observing the system, anadversary will assign to each de-obfuscation process (i.e., an enlargement or a reductionin our case) a probability of being successful. One typical means to measure the degree ofuncertainty is provided by the concept of information entropy, which provides a measureof the uncertainty associated with a random variable.

Let X be the discrete random variable with probability mass function pi = P (X = xi),where xi ∈ X represents a possible de-obfuscation process that an adversary may take.Let pi be the probability assigned to de-obfuscation process xi by an adversary, afterobserving the system and making assumptions about the context. The entropy H(X) ofthe system, after the de-obfuscation has taken place, is calculated as follow.

H(X) =n∑

i=1

P (xi)log1

P (xi)(5.11)

Specifically, in this work, since X is a discrete binary random variable, we rely on theentropy of a binary source (see Figure 5.13).


Figure 5.13: Entropy

In the following, we evaluate the degree of uncertainty associated with a de-obfuscationattempt according to all possible families previously considered: R-family, E-family, S-family, and *-family. Moreover, the set X of possible de-obfuscation processes is X =x1, x2 where x1 = enlarge and x2 = reduce.

R-family. As showed in Figure 5.9, a de-obfuscation by enlarging the radius succeeds foreach R-family technique. In particular, a de-obfuscation attack could improve relevanceof the obfuscated area by applying an enlargement that does not exceed the rBP value.The probabilities of successful de-obfuscation are P (X = x1) = p = 1, and P (X = x2) =1− p = 0. The level of uncertainty as represented by the entropy is then:

H(X) = p log1p

+ (1− p) log1

1− p= 1 ∗ log 1 + 0 ∗ log 1 = 0 (5.12)

This result confirms that the process is completely predictable.

E-family. As showed in Figure 5.12, a de-obfuscation by enlarging the radius succeedswhen a SE/ES (partial overlapping) has been used to obfuscate the original area, while ade-obfuscation by reducing the radius succeeds when a E/ES (inclusion) has been adopted.However, this information alone could be misleading. Again, the adversary needs a mea-sure of the uncertainty associated with the result. In this case, the probabilities areP(X=x1)=p=0.5, and P(X=x2)=1-p=0.5. The level of uncertainty is then:

H(X) = p log1p

+ (1− p) log1

1− p= 0.5 ∗ log 2 + 0.5 ∗ log 2 = 1 (5.13)

This result suggests that the uncertainty is maximum, meaning that the adversary couldnever distinguish a successful de-obfuscation from a failed one.


S-family. A de-obfuscation by enlarging the radius succeeds for each S-family techniqueexcept for ES (inclusion). Therefore, an adversary able to understand that an obfus-cated area has been generated through a S-family obfuscation process, is more likely toretrieve a better area by enlarging the observed radius. In particular, given the fact thateach of the five S-family obfuscation techniques has the same probability 1/5 of being se-lected, de-obfuscation attacks against S-family could improve relevance of the obfuscatedarea in the 9/10 of the cases by applying a suitable enlargement, and in the 1/10 of thecases by applying a suitable reduction (i.e., ES (inclusion) and ES (partial overlapping)have probability 1/10 of being selected). The entropy is calculated based on probabilitiesP(X=x1)=p=9/10, and P(X=x2)=1-p=1/10.

H(X) = p log1p

+ (1− p) log1

1− p=

910∗ log

19/10

+110∗ log

11/10

= 0.14 + 0.33 = 0.47

(5.14)This result confirms that an adversary can reverse the obfuscation effect, but the resultstill maintains a certain level of uncertainty.

*-family. When no one of the previous cases has been assumed by the adversary, *-family, which contains the whole set of obfuscation techniques, is considered. In thisscenario, only E and ES (inclusion) can be de-obfuscated by reducing the radius. There-fore, an adversary is more likely to retrieve a better area by enlarging the observed radius,thus providing a decrease of users privacy estimated by RFinal . In particular, since eachobfuscation technique has probability 1/7 of being selected, de-obfuscation attacks couldimprove relevance of the obfuscated area in the 11/14 of the cases by applying a suitableenlargement, and in the 3/14 of the cases by applying a suitable reduction (i.e., ES (in-clusion) and ES (partial overlapping) have probability 1/14 of being selected). Entropy isthen calculated based on probabilities P(X=x1)=p=11/14, and P(X=x2)=1-p=3/14.

H(X) = p log1p

+ (1− p) log1

1− p=

1114∗ log

111/14

+314∗ log

13/14

= 0.27 + 0.48 = 0.75

(5.15)Quantitatively, this result shows that an adversary can reverse the obfuscation effects, butthe result maintains an important level of uncertainty greater than the S-family one.

In summary, among the families of techniques analyzed, on one side, E-family providesthe best degree of privacy protection outperforming even the privacy protection providedby *-family. On the other side, R-family provides the weakest privacy protection, since anadversary is always able to select the suitable de-obfuscation process.

5.7 A privacy-aware LBAC system

The location privacy issue has driven the design of privacy-aware location-based services.In this section, our privacy solution based on obfuscation techniques is validated in the

5.7. A privacy-aware LBAC system 125

Figure 5.14: Privacy-Aware LBAC Architecture

context of our location-based access control system. In particular, we focus on the defini-tion of a privacy-aware LBAC system [15] that integrates our privacy-aware access controlsystem (defined in Chapter 3) and our LBAC system (defined in Chapter 4) with ourprivacy-enhanced techniques based on privacy preference of users [10, 11, 13]. Finally, adiscussion on how the definition of a privacy-aware LBAC system changes location-basedpredicates evaluation is provided.

5.7.1 A privacy-aware LBAC architecture

The definition of LBAC systems poses some architectural and functional issues that werenever studied before in the context of traditional access control systems. Among theseissues, the problem of protecting location privacy of users stands out and the need of aprivacy-aware LBAC system arises. A privacy-aware LBAC architecture, based on in-frastructure showed in Figure 4.1, must be designed integrating components logically tiedwith the applications that need location-based access control enforcement and componentsproviding privacy-aware location services. One typical approach in the design of LBACarchitectures is to provide a location middleware acting as a trusted gateway between theLBAC system and the location service. Such a component is in charge of managing allinteractions with sensing technologies, and enforces users privacy preferences. The logical


components of a privacy-aware LBAC architecture are showed in Figure 5.14 and can besummarized as follows.

• User . It is the subject that submits an access request, and it can be located throughher mobile device during the interaction with the Business Application. The Userdefines her privacy preference at the Location Middleware and interacts with theAccess Control Engine to gain the access to the Business Application as discussedin Chapter 3 and 4.

• Business application. Customer-oriented application that offers resources protectedby our privacy-aware access control policies supporting location-based conditions. Itrelies on the Access Control Engine for evaluating policies based on users location.

• Access Control Engine (ACE). It implements the privacy-aware access control systemdescribed in Chapter 3. It also allows the definition and evaluation of location-basedconditions as described in Chapter 4. For the enforcement, it requests locationservices and information about the positions of the User involved in the access controldecision process to the Location Middleware.

• Location Providers (LPs). Components that manage sensing technologies to providelocation measurement of the User to the Location Middleware.

• Location Middleware (LM). The entity that implements Location Service interfacesand interacts with different LPs to provide location services to the ACE. It managesthe low-level communications with the Location Providers and enforces both theprivacy preferences of the User and the need of location accuracy requested by theAccess Control Engine.

Communications among logical components are performed via request/response mes-sage exchanges. The interaction flow can be logically partitioned in seven macro-operations: i) initialization, when user preferences and LBAC policies are defined; ii)access request and information negotiation, when a User submits an access request to theBusiness Application, and a negotiation process resulting in a bidirectional identificationbetween the parties takes place (see Chapter 3); iii) location service access and SLA negoti-ation, when an Access Control Engine requires location service to a Location Middleware.A Service Level Agreement (SLA) could be specified to agree upon QoS attributes; iv)location information retrieval, when the Location Middleware collects user location infor-mation through a communication process with multiples Location Providers; v) locationprivacy protection, when obfuscation techniques are used to comply with both user pref-erence and LBAC accuracy. At this point a response to the location service request (step11) is returned to Access Control Engine; vi) Policies evaluation, when LBAC policies areevaluated; and vii) access decision, when the access request is granted or denied. Notethat operations iii), iv), v) are optional, since they are required only in the case in whichaccess control policies contain location-based conditions.


5.7.2 LBAC predicates evaluation: REval calculation

A major design issue for our privacy-aware LBAC architecture is related to the componentin charge of evaluating LBAC predicates. Two choices are possible, which deeply affecthow privacy is guaranteed.

• ACE evaluation: ACE asks users locations to LM without disclosing LBAC pred-icates (i.e., range queries in Chapter 4). Locations are returned together with arelevance value RFinal .

• LM evaluation: ACE sends to LM a LBAC predicate for evaluation and receives aboolean answer and a relevance value REval (i.e., boolean queries in Chapter 4).

Both choices are viable and well-suited for different set of requirements. On one side,ACE evaluation enforces a clear separation between applications and location services be-cause the location service infrastructure (i.e., LM and LPs) never deals with application-dependent location-based predicates. On the other side, LM evaluation avoids the ex-change of user locations, although obfuscated, with applications. This second choice isalso more flexible in business terms. For instance, an ACE can subscribe to a location ser-vice for a specific set of location predicates, and select different QoS according to differentneeds (e.g., different accuracy levels). The LM could then differentiate prices accordingto service quality.

In this thesis, we rely on LM evaluation. Before discussing the rationale supportingour choice, we concentrate the discussion on LBAC predicates evaluation when our privacysolution is used. In Chapter 4, we assumed that results returned by LM have the form[bool value,REval ,timeout ], where relevance REval was generated by Location Provider.Here, REval is calculated by the LM according to location measurements provided by LP,relevances RInit and RFinal , and classes of location conditions defined in Chapter 4, i.e.,position-based, movement-based, and interaction-based. It is important to highlight thatmovement and interaction predicates are intrinsically different from position predicatessince, i) they do not release users location bound to identities, and ii) their evaluationinvolves more than the location measurement of a user and the area specified in the locationpredicate. This results in different REval calculation processes, which are discussed in thefollowing.

Position predicates. Suppose that a location measurement Area(rmeas, xc, yc)(AreaInit below) with relevance RInit has been obfuscated producing an area AreaFinal

with relevance RFinal . Relevance REval is derived from RFinal by considering both theobfuscated area and the area specified in the LBAC predicate. LM calculates REval ofpredicate evaluation as follows:

REval =AreaFinal∩LBAC

AreaFinal· RFinal (5.16)


where the scalar factor depends on the intersection, denoted AreaFinal∩LBAC , betweenthe obfuscated area and the area specified by the LBAC predicate. In the case in whichno obfuscation is applied to the location measurement, AreaInit is used rather AreaFinal.Therefore, REval is calculated as follows:

REval =AreaInit∩LBAC

AreaInit· RInit (5.17)

where the scalar factor depends on the intersection, denoted AreaInit∩LBAC , betweenthe location measurement and the area specified by the LBAC predicate. Relevance RInit

allows to take in consideration the measurement error introduced by each location process.Therefore, let inarea(John, Room1 ) be the predicate that the ACE component sends

to the LM component, which asks whether the user John is in room Room1. If John’sposition has an overlap greater than zero with Room1, the predicate evaluation returns[true,REval ,timeout ]. Otherwise, for all positions disjoint with Room1, the evaluationreturns [true,REval→0,timeout ].

Movement predicates. We have defined velocity predicate as the only movement pred-icate. Predicate velocity is evaluated by first measuring two user positions at differenttimes, and then by calculating user velocity. Relevance REval cannot be generated as forthe previous case. Rather, it is generated by considering the mean value of relevancesRInit associated with the positions used to calculate user velocity.

REval =RInit1 +RInit2

2(5.18)

Although an estimation of user velocity does not release information about user loca-tion, the user can choose to obfuscate velocity result. In this case, REval is calculated asthe mean of relevances RFinal associated with the obfuscated positions used to calculatethe velocity of the user.

REval =RFinal1 +RFinal2

2(5.19)

Then, let velocity(John, 70 , 90 ) be the predicate that the ACE component sends tothe LM component, which asks whether velocity of user John is in [70,90]. If John’s velocityis in the interval, the predicate evaluation returns [true,REval ,timeout ]. Otherwise, theevaluation returns [true,REval→0,timeout ].


Interaction predicates. Relevance REval is calculated by using location measurementsof all users locations intersecting AreaLBAC , where AreaLBAC is a generic area for densitypredicate, or an area surrounding the subject of the predicate for local density one. REval

is calculated from equation (5.17) as follows:

REval =

∑ni=1

Areai,Init∩LBAC

Areai,Init· RInit i

n∀Areai,Init : Areai,Init∩LBAC 6= 0 (5.20)

where Areai,Init∩LBAC represents the intersection between the i -th location measure-ment Areai,Init and the area identified by the LBAC predicate,RInit i is the initial relevanceof the i -th location measurement, and n is the number of users involved in the predicateevaluation. Whether obfuscated areas are considered, i.e., all the areas generated by loca-tion measurements of users that have an intersection with AreaLBAC , REval is calculatedstarting from equation (5.16) as follow:

REval =

∑ni=1

Areai,F inal∩LBAC

Areai,F inal· RFinal i

n(5.21)

To conclude, let density(Room1 , 0 , 3 ) be the predicate that the ACE componentsends to the LM component, which asks whether the number of users in Room1 is be-tween 0 and 3. If the number of users is in the interval, the predicate evaluation returns[true,REval ,timeout ]. Otherwise, the evaluation returns [true,REval→0,timeout ].

The definition of a privacy solution based on relevances RInit and RFinal , to manage theuncertainty of each location measurement and users privacy, respectively, changes theLBAC evaluation infrastructure we introduced in Chapter 4. In Chapter 4, we implicitlyassumed that each location measurement gathered by the Location Provider was the op-timal one, i.e., RInit=1, and that a response returning a boolean value v with a relevanceREval of α was equivalent to a response returning ¬v with a relevance REval of 1−α. Also,we introduced the ETT table (see Table 4.3) used by ACE to integrate relevance-based eval-uations with traditional boolean evaluations. The above assumptions do not hold anymoreand the evaluation process based on ETT table changes. First, it is important to highlightthat a response returning a boolean value v with a relevance REval of α is not anymoreequivalent to a response returning ¬v with a relevance REval of 1 − α. This is due tothe fact that each location measurement is affected by a measurement error, such thatusually RInit<1. As a consequence, the result of a LM predicate evaluation changes from[bool value,REval ,timeout ] to [true,REval ,timeout ],8 where REval estimates the reliabilityof the statement contained in the predicate under evaluation. Finally, although the evalu-ation process is still based on the definition of a minimum acceptable relevance RLBAC , to

8For sake of conciseness in the following timeout parameter is not considered.


Figure 5.15: An example of LM evaluation (a), and ACE evaluation (b)

be compared with evaluation relevance REval , the process of generating a truth value froma relevance one changes. In particular, if REval≥ RLBAC the predicate is verified (i.e.,true result is returned), otherwise the predicate is re-evaluated until MaxTries is achieved.If after MaxTries re-evaluations of the predicate, REval< RLBAC , the evaluation processends and the final response is Unknown.

LM vs ACE evaluation

To further analyze the differences between the adoption of ACE or LM evaluation, wefocus on a scenario where an obfuscation by shifting the center is applied and a positionpredicate is evaluated.9 In this case, the ACE vs LM choice has a significant impact.Consider the examples in Figure 5.15(a) and Figure 5.15(b) that show the evaluationof predicate inarea(John, Room1 ) in case of LM evaluation and of ACE evaluation,respectively. When obfuscation by shifting the center is applied, there are infinite valuesof angle θ that could be chosen, all equivalent with respect to the relevance value RFinal .Here, Area1 and Area2 are two possible obfuscated areas.

If LM evaluation is performed, LM computes REval , as previously seen, and is able toestablish an ordering among obfuscated areas according to the different values of REval .In our example, it is easy to see that relevance REval (Area1 ) resulting from Area1 is

9Same discussion holds for movement and interaction predicates.


greater than relevance REval (Area2 ) resulting from Area2 . This information is importantfor the provision of the location service, because when returned to ACE, the value REval

is matched with RLBAC , the minimum relevance required by ACE for LBAC evaluation.The best strategy for LM is therefore to select the angle θ that produces the obfuscatedarea that, given RFinal , maximizes REval .10

If ACE evaluation is in place, LM does not calculate any REval (i.e., REval is just equalto RFinal ), and it can only select randomly one value for θ among all those that producean obfuscated area with same RFinal . In this way, random selection of the obfuscatedarea (in our example, Area1 or Area2 ) may cause an unpredictable result during ACEevaluation, ranging from relevance equal to zero (e.g., when Area1 in Figure 5.15(b) isreturned) to relevance equal to RFinal (e.g., when Area2 in Figure 5.15(b) is returned).As a consequence, also the matching with the condition over RLBAC results in randomrejection or acceptance of the predicate evaluation. Therefore, obfuscation by shifting thecenter is incompatible with ACE evaluation. This result supports architectures includinglocation middleware capable of autonomously evaluating LBAC predicates.

Finally, there is a subtlety to consider when obfuscation by shifting the center isapplied. When a LBAC predicate is evaluated the choice of θ is relevant, because accordingto the position of the obfuscated area, the value of REval may change. Therefore LMcould try to select the θ angle that maximizes REval . Figure 5.16 shows an example withthree obfuscated areas, namely Area1, Area2, and Area3, which provide the same RFinal

value and different REval values, denoted REval (Area1 ), REval (Area2 ), and REval (Area3 ),respectively. It is easy to see that REval (Area1 ) is greater than REval (Area2 ) (i.e., theoverlap between Area1 and Milan is larger than the overlap between Area2 and Milan)and, correspondingly, the value of angle θ that LM should take into consideration is theone that produces Area1.

A problem could arises with Area3, which has clearly the greatest overlap with Milan.Area3 could provide a REval greater than the one that would have provided the originalarea AreaInit. This would lead to an inconsistent LBAC predicate evaluation. The reasonis that LM would have an incentive to configure obfuscation as a way to artificially increasethe odds of satisfying the RLBAC threshold. To avoid such a side effect, we introduce thefollowing additional constraint: relevance REval derived from the obfuscated area withrelevance RFinal must be lesser than or equal to the one provided by the original area withrelevance RInit , i.e., REval(AreaFinal)≤REval(AreaInit). In other terms, areas must notbe manipulated with obfuscation techniques just to increase the odds of satisfying LBACquality requirements. Our constraint ensures that, given an infinite set Θ of angles, a setΘf ⊆ Θ is generated, containing all the valid angles θ1 . . . θn that produce a relevanceREval at most equals to the relevance produced by considering the original area.

In the example of inarea evaluation in Figure 5.16, the following restriction is intro-

10In addition to the strategy that selects the θ angle that maximizes REval , different strategies can beexploited for θ selection, as for instance, the random strategy.


Figure 5.16: Area selection

duced,

REval (AreaFinal) ≤AreaInit∩LBAC

AreaInit· RInit (5.22)

and then Area3, which does not satisfy this constraint, is discarded in favour of Area1.

5.7.3 The privacy-aware middleware

Currently available middleware components are mostly in charge of managing interactionsbetween applications and location providers, and managing communication and negotia-tion protocols aimed at maximizing the QoS [72, 95, 97, 98, 110]. In a privacy-aware LBAC,a middleware component is also responsible for balancing users privacy and location-basedservices accuracy. To this end, our LM provides functionalities for both the obfuscationof users locations and the location-based predicates evaluation. As shown in Figure 5.17,LM is functionally divided into the following five logical components.

• Communication Layer. It manages the communication process with LPs. It hideslow-level communication details to other components.

• Negotiation Manager. It acts as an interface with ACE for negotiating QoS at-tributes [8].


Figure 5.17: Location Middleware

• Access Control Preference Manager. It manages location service attributes by inter-acting with the Location Obfuscation component.

• Location Obfuscation. It applies obfuscation techniques for users privacy.

• Privacy Manager. It manages privacy preferences and location-based predicate eval-uation.

It is important to highlight that the architecture of our location middleware can beextended to include the important case of users setting multiple privacy preferences ac-cording to different contexts. For instance, there could be users wishing to set: i) noprivacy preferences for location services dedicated to the social network of their relativesand close friends; ii) a certain level of privacy for business location services aimed at help-ing to find point of interests (e.g., shops, or monuments), and for location services whosegoal is to find their position while at work; and iii) strong privacy requirements in highsensitive contexts.

To conclude, we provide two examples of LBAC predicates evaluationbased on two location predicates: inarea and distance [9]. Specifically,inarea(user term,area term) evaluates whether user term is located within area term,and distance(user,entity,dmin,dmax) evaluates whether the distance between user andentity is within the interval [dmin,dmax].

Example 5.7.1. Suppose that ACE requires users ( John in this example) to be located inMilan with a relevance RLBAC=0.5 to access a service. Also, suppose that John’s privacypreference requires a relevance RFinal=0.8. To enforce John’s access request, the ACEasks the LM to evaluate the predicate inarea( John, Milan), where John represents thelocated user. Finally, let the location measurement of John be AreaInit with RInit=1.Figure 5.18 shows graphically an example of REval computation when the obfuscation byenlarging the radius is applied. Since the intersection between the obfuscated area AreaFinal

and Milan is equal to three fourth of AreaFinal, the scalar factor AreaFinal∩LBACAreaFinal

is equal to


Figure 5.18: LM inarea predicate evaluation

0.75. From (5.16), we can produce the final relevance REval associated with the predicateevaluation: REval=0.75 ·RFinal=0.6. The predicate evaluation process is concluded and theresult (True, 0.6) is returned to the ACE. Finally, the ACE compares REval with RLBAC .Since RLBAC < REval , the quality of the evaluation satisfies the ACE requirements, andJohn gains the access.

Example 5.7.2. Suppose that the ACE requires users (again John in this example)to stay at least 1000m away from a restricted area (i.e., Dangerous in Figure 5.19)used for stocking dangerous material with a relevance RLBAC=0.8 to access a ser-vice. Then, suppose that John’s privacy preference requires a relevance RFinal=0.2.Whenever John submits an access request, the ACE asks the LM to evaluate the pred-icate distance( John,Dangerous,dmin,dmax), where John represents the located user,dmin=1000m, and dmax = +∞. The predicate distance identifies an area AreaLBAC

(see grey area in Figure 5.19), around the Dangerous area, which contains all the pointsoutside the Dangerous area that have a distance between dmin and dmax. Let the loca-tion measurement of John be AreaInit with RInit=0.9. Figure 5.19 shows graphicallyan example of REval computation when the obfuscation by shifting the center is ap-plied. Since the intersection between the obfuscated area AreaFinal and AreaLBAC isequal to half of the AreaFinal, the scalar factor AreaFinal∩LBAC

AreaFinalis equal to 0.5. From

(5.16), we calculate the final relevance REval associated with the predicate evaluation:

5.8. Chapter summary 135

Figure 5.19: LM distance predicate evaluation

REval=AreaFinal∩LBACAreaFinal

· RFinal=0.1. The predicate evaluation process is concluded and theresult (True, 0.1) is returned to the ACE meaning that John is far from the Dangerousarea of at least dmin with a relevance of 0.1. Finally, since RLBAC > REval , the ACEdenies John’s request.

5.8 Chapter summary

We have examined the problem of protecting location privacy of the users in pervasiveenvironments where users identification is required. We proposed an approach providinga simple and intuitive mechanism for the definition of privacy preferences of users, anda set of obfuscation-based techniques (possibly combined) to degrade accuracy of eachlocation measurement and then to preserve privacy of users. Our privacy solution is basedon relevance metric to balance need of privacy of users and need of accuracy of LBSs.Also, in contrast to previous proposals investigating location privacy problem, it gives aformal estimation of the real degree of privacy guaranteed to the users, by analyzing de-obfuscation attempts made by adversaries. Finally, our solution has been integrated andvalidated in the context of our privacy-aware access control system supporting location-based conditions, to provide a privacy-aware LBAC system.

6Conclusions

In this thesis we have investigated privacy topics in the context of pervasive and distributedenvironments. In particular, after a brief introduction, and related work (Chapters 1-2),Chapter 3 concerned privacy-aware access control aspects whereas Chapter 4-5 concernedlocation-based access control aspects and location privacy issues. In this last chapter, weshortly summarize the contribution of this thesis and we outline some topics left to futurework.

6.1 Summary of the contributions

The contributions of this thesis are twofold.

Privacy-aware access control. We introduced the concept of privacy-aware accesscontrol for Web-based transactions. We proposed an infrastructure that provides the basefor the definition of a powerful and expressive access control system regulating access toservice provider resources and providing a solution for managing release of private usersdata. Access control system has then been extended by supporting the definition of datahandling policies that allow users to pose restrictions on secondary use of their privatedata [14], after their release to external parties. Data handling policies can be specifiedat different levels of the data hierarchy and are tagged to the data they protect. Finally,an architecture that integrates access control mechanisms with data handling policiesdefinition, evaluation, and enforcement has been developed.

Location-based access control and location privacy. Recent improvements of sens-ing technologies make available fine-grained context information including location ofusers. This information could facilitate and empower the definition of a location-basedaccess control model and language regulating access to and fruition of resources. However,only few access control solutions consider location information as a possible added valuewhen an access decision must be taken. We extended traditional access control systemby defining a location-based access control model and language allowing the specification,

138 6. Conclusions

evaluation, and enforcement of location-based predicates and conditions. In this scenario,the need of a solution for protecting location privacy of users arises, since lack of locationprivacy protection results in severe consequences for the users that become potential tar-gets of fraudulent attacks. We defined a location privacy solution based on obfuscationtechniques [10, 11, 13], which protects users privacy still preserving the degree of accuracyneeded by location-based applications for a successful service provisioning. We finally val-idated this privacy solution in the context of a privacy-aware location-based access controlsystem, where the infrastructure aimed at evaluating and enforcing LBAC predicates andconditions has been refined.

6.2 Future work

The research described in this thesis can be extended along several directions.

6.2.1 Privacy-aware access control

Variables support. Our model allows the definition of policies based on two place-holders, i.e., user and object, identifying subject and object of a policy, respectively.However, we feel that it may be interesting to modify our models and languages by pro-viding support for variables definition inside the policies. This is motivated by the factthat relying on two placeholders, only, makes difficult to refer to properties of entitiesrelated to the subject of a policy, e.g., the age of a subject’s child. Also, the solution basedon two placeholders does not provide a simple mechanism to manage properties that canassume multiple values, e.g., credit card information. Integration of variables definitioninside privacy-aware access control languages overcomes the above limitations and makesthe languages more expressive and powerful. To make the discussion clear, variables inte-gration would provide the definition of restrictions as for instance “the user must have achild whose name is John and whose age is greater than 18” (see Figure 6.1).

assign(X,user.child)greaterThan(X.name,‘John’)greaterThan(X.age,18)

Figure 6.1: Variable-based restrictions

In the above example, we assume that user and child have been defined as ontologyconcept person and that there exists an ontology relation between them (i.e., user is aperson, child is a person, user has child).

Cryptographic credentials and private certificates. Our model permits to evaluateconditions based on zero-knowledge proofs. We plan to extend our approach by providing a

6.2. Future work 139

mean to define requests for cryptographic credentials and private certificates. Our solutionwill then be able to ask for encrypted properties and for disjoint set of encrypted credentialsthat proof to fulfill a given condition without disclosing the real attributes.

Data handling policies management. Data handling policies definition provides afirst solution to the problem of protecting sensitive data after their release to externalparties. However, we believe that it may be necessary to improve the management in-frastructure to make data handling policy effectiveness stronger. Future work includes: i)definition of a negotiation protocol that provides an automatic negotiation of data han-dling preferences as much as possible transparent for the involved entities; ii) definitionof enhanced techniques for dissemination of data handling policies between parties; iii)composition of data handling policies defined at different levels of PII abstraction; and iv)enhanced data handling policies life-cycle management. In particular, the latter shouldprovide to the users functionalities for managing chains of releases and for modifying mul-tiple instances of their data/policies released to several external parties. Article 12 andArticle 32/2 of Directive 95/46/EC of the European Parliament and of the Council of24 October 1995 [50], in fact, state that users have the right to rectify, erase, or blockdata which are incomplete, inaccurate or stored in a way incompatible with the legitimatepurposes pursued by the controller.

6.2.2 Location-based access control and location privacy

Location Middleware prototype. As discussed in Chapter 5, we design a privacy-aware LBAC that integrates our privacy-aware access control system in Chapter 3, ourLBAC system in Chapter 4, and our location privacy solution in Chapter 5. The privacy-aware LBAC system requires a location middleware acting as a trusted gateway betweenthe LBAC system and the location service, which provides functionalities for both theobfuscation of users locations and the location-based predicates evaluation. The locationmiddleware component is under development.

Temporal obfuscation. Our location privacy solution, based on obfuscation tech-niques, preserves privacy of users by degrading spatial accuracy of their location mea-surements. However, there exists cases in which privacy preferences of users and needof accuracy of the location-based services cannot be matched. In those cases, it may beinteresting to provide an additional technique that protects privacy of users by degradingthe temporal accuracy of their location measurements. Work to be investigated includesalso the integration of spatial and temporal obfuscation techniques.

Gaussian-like distributions and complex shapes. As discussed in Chapter 5 ourprivacy solution relies on two assumptions: i) the area returned by a location measurementis circular, which is the actual shape resulting from many location technologies, and ii)

140 6. Conclusions

the probability that the real user position belongs to a neighborhood of a random pointis uniformly distributed over the whole location measurement. In future work, it may beinteresting to relax the above assumptions. In particular, we plan to consider differentlocation measurement shapes (e.g., ellipses) that model mobility parameters of users (e.g.,movement trajectory and velocity), and to extend our techniques to consider locationmeasurements with complex probability distributions.

Map constraints. Our approach to location privacy protection does not still fully con-sider map constraints when obfuscated areas are calculated. This represents a limitation,since topological information could help adversaries in reducing location privacy by guess-ing identity of users and by producing more accurate location information. An interestingresearch direction is then to integrate our obfuscation techniques with Geographical In-formation System (GIS) maps, providing a solution that takes advantage from map infor-mation. This may allow the definition of obfuscation solutions that fully address privacypreferences of users.

Path protection. We provided a location privacy solution whose main goal is to perturbsingle location to protect the position of individual users. Future work should extendcurrent solution to better protect privacy of users that are monitored during a certainperiod of time. This research area is particularly relevant given the ever-increasing interestin offering applications for tracking users. Data about users moving in a particular areaare collected by external services that use them to provide their services effectively. Insuch a scenario, the need for privacy techniques aimed at protecting path privacy becomesurgent.

6.3 Closing remarks

This work has appeared in varying forms, in the form of journals and conference papers (seeappendix D). In particular, our privacy-aware access control system has been describedin [7, 14, 17, 18]. Our location-based access control system has been illustrated in [9]. Ageneral discussion about the problem of protecting location privacy of the users has beenprovided in [12]. Our location privacy solution based on obfuscation techniques has beendescribed in [13]. Finally, our approach to a privacy-aware evaluation and enforcement oflocation-based conditions has been illustrated in [10, 11, 15].

Bibliography

[1] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. An xpath based preference languagefor P3P. In Proc. of the 12th International World Wide Web Conference, Budapest,Hungary, May 2003.

[2] G-J. Ahn and J. Lam. Managing privacy preferences in federated identity manage-ment. In Proc. of the ACM Workshop on Digital Identity Management (In conjuctionwith 12th ACM Conference on Computer and Communications Security), Fairfax,VA, USA, November 2005.

[3] E. Aivaloglou, S. Gritzalis, and C. Skianis. Requirements and challenges in thedesign of privacy-aware sensor networks. In Proc. of the 49th IEEE GLOBECOMConference - World Class Solutions: Networking the Globe Technical Symposium,San Francisco, USA, November 2006.

[4] I.F. Akyildiz and J.S.M. Ho. Dynamic mobile user location update for wireless pcsnetworks. Wireless Networks, 1(2):187–196, 1995.

[5] M. Anisetti, C.A. Ardagna, V. Bellandi, E. Damiani, and S. Reale. Method, system,network and computer program product for positioning in a mobile communicationsnetwork. In European Patent No. EP1765031, Published in date 21 March 2007.

[6] M. Anisetti, V.Bellandi, E. Damiani, and S. Reale. Localization and tracking ofmobile antennas in urban environment. In Proc. of the International Symposium onTelecommunications (IST 2005), Shiraz, Iran, September 2005.

[7] C.A. Ardagna, M. Cremonini, E. Damiani, S. De Capitani di Vimercati, andP. Samarati. The architecture of a privacy-aware access control decision compo-nent. In Proc. of International Conference in Construction and Analysis of Safe,Secure and Interoperable Smart devices (CASSIS), Nice, France, March 2005.

[8] C.A. Ardagna, M. Cremonini, E. Damiani, S. De Capitani di Vimercati, andP. Samarati. Location-based metadata and negotiation protocols for LBAC in aone-to-many scenario. In Proc. of the Workshop on Security and Privacy in Mobileand Wireless Networking (SecPri MobiWi 2006), Coimbra, Portugal, May 2006.

[9] C.A. Ardagna, M. Cremonini, E. Damiani, S. De Capitani di Vimercati, andP. Samarati. Supporting location-based conditions in access control policies. InProc. of the ACM Symposium on Information, Computer and Communications Se-curity (ASIACCS’06), Taipei, Taiwan, March 2006.

142 6. Bibliography

[10] C.A. Ardagna, M. Cremonini, E. Damiani, S. De Capitani di Vimercati, andP. Samarati. Managing privacy in LBAC systems. In Proc. of the Second IEEEInternational Symposium on Pervasive Computing and Ad Hoc Communications(PCAC-07), Niagara Falls, Canada, May 2007.

[11] C.A. Ardagna, M. Cremonini, E. Damiani, S. De Capitani di Vimercati, andP. Samarati. A middleware architecture for integrating privacy preferences and loca-tion accuracy. In Proc. of the 22nd IFIP TC-11 International Information SecutiryConference (IFIP SEC2007), Sandton, South Africa, May 2007.

[12] C.A. Ardagna, M. Cremonini, E. Damiani, S. De Capitani di Vimercati, andP. Samarati. Privacy-enhanced Location Services. Digital Privacy: Theory, Tech-nologies and Practices. Taylor and Francis, 2007.

[13] C.A. Ardagna, M. Cremonini, E. Damiani, S. De Capitani di Vimercati, and S. Sama-rati. Location privacy protection through obfuscation-based techniques. In Proc. ofthe 21st Annual IFIP WG 11.3 Working Conference on Data and Applications Se-curity, Redondo Beach, CA, USA, July 2007.

[14] C.A. Ardagna, M. Cremonini, S. De Capitani di Vimercati, and P. Samarati. Aprivacy-aware access control system. Journal of Computer Security (JCS). (toappear).

[15] C.A. Ardagna, M. Cremonini, S. De Capitani di Vimercati, and P. Samarati.Privacy-enhanced Location-based Access Control. Handbook of Database Security.Springer, 2007. (to appear).

[16] C.A. Ardagna, E. Damiani, S. De Capitani di Vimercati, C. Fugazza, and P. Sama-rati. Offline expansion of XACML policies based on P3P metadata. In Proc of the5th International Conference on Web Engineering (ICWE 2005), Sydney, Australia,July 2005.

[17] C.A. Ardagna, E. Damiani, S. De Capitani di Vimercati, and P. Samarati. TowardsPrivacy-Enhanced Authorization Policies and Languages. In Proc. of the 19th IFIPWG11.3 Working Conference on Data and Application Security, Nathan Hale Inn,University of Connecticut, Storrs, USA, August 2005.

[18] C.A. Ardagna, S. De Capitani di Vimercati, and P. Samarati. Enhancing user privacythrough data handling policies. In Proc. of the 20th Annual IFIP WG 11.3 WorkingConference on Data and Applications Security, SAP Labs, Sophia Antipolis, France,July-August 2006.

[19] A. Arsenault and S. Turner. Internet x.509 public key infrastructure: Roadmap.Internet Draft, Internet Engineering Task Force, 2002.

6.3. Bibliography 143

[20] P. Ashley, S. Hada, G. Karjoth, C. Powers, and M. Schunter. Enterprise privacyauthorization language (epal 1.1). 2003. http://www.zurich.ibm.com/security/enterprise-privacy/epal.

[21] P. Ashley, S. Hada, G. Karjoth, and M. Schunter. E-P3P privacy policies and privacyauthorization. In Proc. of the ACM workshop on Privacy in the Electronic Society(WPES 2002), Washington, DC, USA, November 2002.

[22] V. Atluri and H. Shin. Efficient enforcement of security policies based on trackingof mobile users. In Proc. of the 20th Annual IFIP WG 11.3 Working Conference onData and Applications Security, Sophia Antipolis, France, July-August 2006.

[23] L. Barkhuus and A. Dey. Location-based services for mobile telephony: a study ofuser’s privacy concerns. In Proc. of the 9th IFIP TC13 International Conference onHuman-Computer Interaction (INTERACT 2003), Zurich, Switzerland, September2003.

[24] P. Bellavista, A. Corradi, and C. Giannelli. Efficiently managing location informationwith privacy requirements in wi-fi networks: a middleware approach. In Proc. of theInternational Symposium on Wireless Communication Systems (ISWCS’05), Siena,Italy, September 2005.

[25] A.R. Beresford and F. Stajano. Location privacy in pervasive computing. IEEEPervasive Computing, 2(1):46–55, 2003.

[26] A.R. Beresford and F. Stajano. Mix zones: User privacy in location-aware ser-vices. In Proc. of the 2nd IEEE Annual Conference on Pervasive Computing andCommunications Workshops (PERCOMW04), Orlando, FL, USA, March 2004.

[27] C. Bettini, S. Jajodia, X. Sean Wang, and D. Wijesekera. Provisions and obligationsin policy management and security applications. In Proc. 28th Conference Very LargeData Bases (VLDB’02), Hong Kong, China, August 2002.

[28] C. Bettini, X.S. Wang, and S. Jajodia. Protecting privacy against location-basedpersonal identification. In Proc. of the 2nd VLDB Workshop on Secure Data Man-agement (SDM’05), Trondheim, Norway, September 2005.

[29] M. Blaze, J. Feigenbaum, J. Ioannidis, and A.D. Keromytis. The role of trustmanagement in distributed systems security. Secure Internet Programming: Issuesin Distributed and Mobile Object Systems, 1998.

[30] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized trust management. In Proc.of 1996 IEEE Symposium on Security and Privacy, Oakland, CA, USA, May 1996.

http://www.zurich.ibm.com/security/enterprise-privacy/epal

http://www.zurich.ibm.com/security/enterprise-privacy/epal

144 6. Bibliography

[31] P. Bonatti, E. Damiani, S. De Capitani di Vimercati, and P. Samarati. A component-based architecture for secure data publication. In Proc. of the 17th Annual ComputerSecurity Applications Conference (ACSAC 2001), New Orleans, Louisiana, Decem-ber 2001.

[32] P. Bonatti and P. Samarati. A unified framework for regulating access and informa-tion release on the web. Journal of Computer Security, 10(3):241–272, 2002.

[33] J. Borkowski, J. Niemela, and J. Lempiainen. Performance of cell ID+RTT hybridpositioning method for UMTS radio networks. In Proc. of the 5th European WirelessConference, Barcelona, Spain, February 2004.

[34] J. Camenisch and A. Lysyanskaya. An efficient system for non-transferable anony-mous credentials with optional anonymity revocation. In Proc. of the Advancesin Cryptology - EUROCRYPT 2001, International Conference on the Theory andApplication of Cryptographic Techniques, Innsbruck, Austria, May 2001.

[35] J. Camenisch and E. Van Herreweghen. Design and implementation of the idemixanonymous credential system. In Proc. of the 9th ACM Conference on Computerand Communications Security (CCS 2002), Washingtion, DC, USA, November 2002.

[36] M. Casassa Mont. Dealing with privacy obligations: Important aspects and tech-nical approaches. In Proc. of the 1st International Conference on Trust, Privacyand Security in Digital Business 2004 (TrustBus 2004), Zaragoza, Spain, August -September 2004.

[37] M. Casassa Mont and F. Beato. On parametric obligation policies: Enabling privacy-aware information lifecycle management in enterprises. In Proc. of the 8th IEEEWorkshop on Policies for Distributed Systems and Networks (Policy 2007), Bologna,Italy, June 2007.

[38] M. Casassa Mont, S. Crosta, T. Kriegelstein, and D. Sommer. Architecture V2,March 2007. https://www.prime-project.eu/prime_products/reports/arch/pub_del_D14.2.b_ec_WP14.2_v2_final.pdf.

[39] M. Casassa Mont and R. Thyne. A systemic approach to automate privacy policyenforcement in enterprises. In Proc. of the 6th Workshop on Privacy EnhancingTechnologies 2006 (PET 2006), Cambridge, United Kingdom, June 2006.

[40] R. Chandramouli. Privacy protection of enterprise information through inferenceanalysis. In Proc. of IEEE 6th International Workshop on Policies for DistributedSystems and Networks (POLICY 2005), Stockholm, Sweden, June 2005.

[41] Chicago Tribune. Rental firm uses GPS in speeding fine. July 2nd, p9. AssociatedPress: Chicago, IL, 2001.

https://www.prime-project.eu/prime_products/reports/arch/pub_del_D14.2.b_ec_WP14.2_v2_final.pdf

https://www.prime-project.eu/prime_products/reports/arch/pub_del_D14.2.b_ec_WP14.2_v2_final.pdf


[42] Y-H. Chu, J. Feigenbaum, B. LaMacchia, P. Resnick, and M. Strauss. Referee:Trust management for web applications. Computer Networks and ISDN Systems,29(8–13):953–964, 1997.

[43] V. Ciriani, S. De Capitani di Vimercati, S. Foresti, and P. Samarati. Security inDecentralized Data Management. K-Anonymity. Springer, 2007.

[44] L. Cong and W. Zhuang. Hybrid TDOA/AOA mobile user location for widebandCDMA cellular systems. IEEE Transactions on Wireless Communications, 1:439–447, July 2002.

[45] J. Coutaz, J.L. Crowley, S. Dobson, and D. Garlan. Context is key. Communicationsof the ACM (CACM), 48(3):49–53, March 2005.

[46] L.F. Cranor. Web Privacy with P3P. O’Reilly & Associates, 2002.

[47] E. Damiani, M. Anisetti, and V. Bellandi. Toward exploiting location-based andvideo information in negotiated access control policies. In Proc. of the 1st Interna-tional Conference on Information Systems Security (ICISS 2005), Kolkata, India,December 2005.

[48] E. Damiani, S. De Capitani di Vimercati, C. Fugazza, and P. Samarati. Extendingpolicy languages to the semantic web. In Proc. of the International Conference onWeb Engineering (ICWE 2004), Munich, Germany, July 2004.

[49] E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, and P. Samarati. Managingand sharing servents’ reputations in p2p systems. IEEE Transactions on Knowledgeand Data Engineering, 15(4):840–854, July/August 2003.

[50] Directive 95/46/ec of the european parliament and of the council of 24 october 1995on the protection of individuals with regard to the processing of personal data andon the free movement of such data. Official Journal L 281, pages 31–50, 23/11/1995.

[51] T. D’Roza and G. Bilchev. An overview of location-based services. BT TechnologyJournal, 21(1):20–27, January 2003.

[52] M. Duckham and L. Kulik. A formal model of obfuscation and negotiation for loca-tion privacy. In Proc. of the 3rd International Conference on Pervasive Computing(PERVASIVE 2005), Munich, Germany, May 2005.

[53] M. Duckham and L. Kulik. Simulation of obfuscation and negotiation for locationprivacy. In Proc. of Conference On Spatial Information Theory (COSIT 2005),Ellicottville, New York, USA, September 2005.

146 6. Bibliography

[54] M. Duckham and L. Kulik. Dynamic & Mobile GIS: Investigating Change in Spaceand Time, pages 34–51. Location privacy and location-aware computing. Taylor &Francis, 2006.

[55] C. Ellison. Spki requirements. Request For Comments 2692, Internet EngineeringTask Force, 1999.

[56] eXtensible Access Control Markup Language (XACML) Version 2.0, Febru-ary 2005. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf.

[57] D. Faria and D. Cheriton. No long-term secrets: Location-based security in over-provisioned wireless LANs. In Proc. of the 3rd ACM Workshop on Hot Topics inNetworks (HotNets-III), San Diego, CA, USA, November 2004.

[58] S. Farrell and R. Housley. An Internet Attribute Certificate for Authorization. Re-quest For Comments 3281, 2002. Internet Engineering Task Force.

[59] S. Garg, M. Kappes, and M. Mani. Wireless access server for quality of serviceand location based access control in 802.11 networks. In Proc. of the 7th IEEESymposium on Computers and Communications (ISCC 2002), Taormina/GiardiniNaxos, Italy, July 2002.

[60] R. Gavriloaie, W. Nejdl, D. Olmedilla, K. Seamons, and M. Winslett. No registrationneeded: How to use declarative policies and negotiation to access sensitive resourceson the semantic web. In Proc. of the 1st First European Semantic Web Symposium,Heraklion, Greece, May 2004.

[61] B. Gedik and L. Liu. Location privacy in mobile systems: A personalized anonymiza-tion model. In Proc. of the 25th International Conference on Distributed ComputingSystems (IEEE ICDCS 2005), Columbus, Ohio, June 2005.

[62] Geographic Location/Privacy (geopriv). September 2006. http://www.ietf.org/html.charters/geopriv-charter.html.

[63] I. Getting, editor. The global positioning system. IEEE Spectrum, December 1993.

[64] B. Gladman, C. Ellison, and N. Bohm. Digital signatures, certificates and electroniccommerce. http://www.clark.net/pub/cme/html/spki.html.

[65] M. Gruteser, J. Bredin, and D. Grunwald. Path privacy in location-aware computing.In Proc. of the Second International Conference on Mobile Systems, Application andServices (MobiSys2004), Boston, Massachussetts, USA, June 2004.

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf

http://www.ietf.org/html.charters/geopriv-charter.html

http://www.ietf.org/html.charters/geopriv-charter.html

http://www.clark.net/pub/cme/html/spki.html


[66] M. Gruteser and D. Grunwald. Anonymous usage of location-based services throughspatial and temporal cloaking. In Proc. of the 1st International Conference on MobileSystems, Applications, and Services (MobiSys), San Francisco, CA, USA, May 2003.

[67] M. Gruteser and Xuan Liu. Protecting privacy in continuous location-tracking ap-plications. IEEE Security & Privacy Magazine, 2(2):28–34, March-April 2004.

[68] F. Gustafsson and F. Gunnarsson. Mobile positioning using wireless networks: Pos-sibilities and fundamental limitations based on available wireless network measure-ments. IEEE Signal Processing Magazine, pages 41–53, July 2005.

[69] C. Hauser and M. Kabatnik. Towards Privacy Support in a Global LocationService. In Proc. of the IFIP Workshop on IP and ATM Traffic Management(WATM/EUNICE 2001), Paris, France, March 2001.

[70] U. Hengartner and P. Steenkiste. Protecting access to people location information.In Proc. of First International Conference on Security in Pervasive Computing,Boppard, Germany, March 2003.

[71] B. Ho and M. Gruteser. Protecting location privacy through path confusion. In Proc.of IEEE/CreateNet International Conference on Security and Privacy for EmergingAreas in Communication Networks (SecureComm), Athens, Greece, September 2005.

[72] D. Hong, M. Yuan, and V. Y. Shen. Dynamic privacy management: a plug-in ser-vice for the middleware in pervasive computing. In Proc. of the 7th InternationalConference on Human Computer Interaction with Mobile Devices & Services (Mo-bileHCI’05), Salzburg, Austria, September 2005.

[73] J.I. Hong and J.A. Landay. An architecture for privacy-sensitive ubiquitous comput-ing. In Proc. of the 2nd International Conference on Mobile Systems, Applications,and Services (MobiSys 2004), Boston, Massachusetts, USA, 2004.

[74] S. Horsmanheimo, H. Jormakka, and J. Lahteenmaki. Location-aided planning inmobile network - trial results. Wireless Personal Communications: An InternationalJournal, 30(2-4), September 2004.

[75] IBM/Microsoft. Security in a web services world: A proposed architecture androadmap, 2002. http://www.ibm.com/developerworks/webservices/library/ws-secmap/.

[76] IDEntity MIXer (IDEMIX). http://www.zurich.ibm.com/security/idemix/.

[77] International security, trust, and privacy alliance (istpa). http://www.istpa.org/.

http://www.ibm.com/developerworks/webservices/library/ws-secmap/

http://www.ibm.com/developerworks/webservices/library/ws-secmap/

http://www.zurich.ibm.com/security/idemix/

http://www.istpa.org/

148 6. Bibliography

[78] K. Irwin and T. Yu. Preventing attribute information leakage in automated trust ne-gotiation. In Proc. of the 12th ACM Conference on Computer and CommunicationsSecurity (CCS 2005), Alexandria, VA, USA, November 2005.

[79] ITU Telecommunication Standardization Sector (ITU-T). Information Technology -Open Systems Interconnection - The Directory: Authentication Framework. Recom-mendation X.509 (03/00), 2000. International Telecommunication Union.

[80] S. Jajodia, P. Samarati, M.L. Sapino, and V.S. Subrahmanian. Flexible support formultiple access control policies. ACM Transactions on Database Systems, 26(2):214–260, June 2001.

[81] G. Karjoth and M. Schunter. Privacy policy model for enterprises. In Proc. of the15th IEEE Computer Security Foundations Workshop, Cape Breton, Nova Scotia,Canada, June 2002.

[82] G. Karjoth, M. Schunter, and M. Waidner. Privacy-enabled services for enterprises.In Proc. of the 13th International Conference on Database and Expert Systems Ap-plications (DEXA’02), Aix-en-Provence, France, September 2002.

[83] S. Katsikas, J. Lopez, and G. Pernul. Security, trust and privacy in digital business.International Journal of Computer Systems, Science & Engineering, CRL Publish-ing, November 2005.

[84] M. Langheinrich. Privacy by design-principles of privacy-aware ubiquitous systems.In Proc. of the 3rd international conference on Ubiquitous Computing (Ubicomp2001), Atlanta, Georgia, USA, September-October 2001.

[85] M. Langheinrich. A privacy awareness system for ubiquitous computing environ-ments. In Proc. of the 4th International Conference on Ubiquitous Computing (Ubi-comp 2002), Goteborg, Sweden, September-October 2002.

[86] J-W. Lee. Location-tracing sparks privacy concerns. Korea Times. http://times.hankooki.com, 16 November 2004. Accessed 22 December 2006.

[87] U. Leonhardt and J. Magee. Towards a general location service for mobile environ-ments. In Proc. of the 3rd IEEE Workshop on Services in Distributed and NetworkedEnvironments (SDNE ’96), Macau, France, June 1996.

[88] N. Li, B.N. Grosof, and J. Feigenbaum. A practically implementable and tractabledelegation logic. In Proc. of the IEEE Symposium on Security and Privacy, Oakland,CA, USA, June 2000.

[89] N. Li, J.C. Mitchell, and W.H. Winsborough. Beyond proof-of-compliance: Securityanalysis in trust management. Journal of the ACM, 52(3):474–514, 2005.

http://times.hankooki.com

http://times.hankooki.com


[90] Liberty 2.0 specification. http://www.projectliberty.org/resource_center/specifications.

[91] Liberty alliance project. http://www.projectliberty.org/.

[92] Liberty architecture framework for supporting privacy preference expression lan-guages, 2003. http://www.projectliberty.org/liberty/resource_center/papers/privacy_preference_expression_languages_whitepaper_pdf.

[93] N. Marsit, A. Hameurlain, Z. Mammeri, and F. Morvan. Query processing in mobileenvironments: a survey and open problems. In Proc. of the 1st International Confer-ence on Distributed Framework for Multimedia Applications (DFMA’05), Besancon,France, February 2005.

[94] M.F. Mokbel, C-Y. Chow, and W.G. Aref. The new casper: Query processing forlocation services without compromising privacy. In Proc. of the 32nd InternationalConference on Very Large Data Bases (VLDB 2006), Seoul, Korea, September 2006.

[95] G. Myles, A. Friday, and N. Davies. Preserving privacy in environments withlocation-based applications. IEEE Pervasive Computing, 2(1):56–64, 2003.

[96] J. Myllymaki and S. Edlund. Location aggregation from multiple sources. In Proc.of the 3rd IEEE International Conference on Mobile Data Management (MDM 02),Singapore, January 2002.

[97] H. Naguib, G. Coulouris, and S. Mitchell. Middleware support for context-awaremultimedia applications. In Proc. of the IFIP TC6 / WG6.1 3rd InternationalWorking Conference on New Developments in Distributed Applications and Interop-erable Systems, Deventer, The Netherlands, September 2001.

[98] K. Nahrstedt, D. Xu, D. Wichadakul, and B. Li. QoS-aware middleware for ubiq-uitous and heterogeneous environments. IEEE Communications Magazine, pages140–148, November 2001.

[99] J. Ni, N. Li, and W.H. Winsborough. Automated trust negotiation using crypto-graphic credentials. In Proc. of the 12th ACM Conference on Computer and Com-munications Security (CCS 2005), Alexandria, VA, USA, November 2005.

[100] J. Nord, K. Synnes, and P. Parnes. An architecture for location aware applications.In Proc. of the 35th Hawaii International Conference on System Sciences, Hawaii,USA, January 2002.

[101] OASIS. Security Assertion Markup Language (SAML) V1.1, 2003. http://www.oasis-open.org/committees/security/.

http://www.projectliberty.org/resource_center/specifications

http://www.projectliberty.org/resource_center/specifications

http://www.projectliberty.org/

http://www.projectliberty.org/liberty/resource_center/papers/privacy_preference_expression_languages_whitepaper_pdf

http://www.projectliberty.org/liberty/resource_center/papers/privacy_preference_expression_languages_whitepaper_pdf

http://www.oasis-open.org/committees/security/

http://www.oasis-open.org/committees/security/

150 6. Bibliography

[102] Object Management Group. The CORBA Security Service Specification.ftp://ftp.omg.org/pub/docs/ptc.

[103] P. Olofsson. Probability, Statistics and Stochastic Processes. John Wiley & Sons,Inc., 2005.

[104] Openwave. Openwave Location Manager, 2006. http://www.openwave.com/.

[105] Organization for Economic Co-operation and Development. OECD guide-lines on the protection of privacy and transborder flows of personal data,1980. http://www.oecd.org/document/18/0,2340,en_2649_34255_1815186_119820_1_1_1,00.html.

[106] B. Parkinson et al. Global Positioning System: Theory and Application, volume 163.Volume II, Progress in Austronautics and Aerounautics Series, V-164, AmericanInstitute of Astronautics and Aeronautics (AIAA), Reston, Virginia, USA, 1996.

[107] J. Peterson. A Presence-based GEOPRIV Location Object Format, December 2005.Request for comments (RFC) 4119. http://www.rfc-editor.org/rfc/rfc4119.txt.

[108] Privacy and Identity Management for Europe (PRIME). http://www.prime-project.eu.org/.

[109] Privacy Rights Clearinghouse/UCAN. A Chronology of Data Breaches, 2006. http://www.privacyrights.org/ar/ChronDataBreaches.htm.

[110] A. Ranganathan, J. Al-Muhtadi, S. Chetan, R. H. Campbell, and M. D. Mickunas.Middlewhere: A middleware for location awareness in ubiquitous computing applica-tions. In Proc. of the ACM/IFIP/USENIX 5th International Middleware Conference(Middleware 2004), Toronto, Ontario, Canada, October 2004.

[111] Reasoning on the web (rewerse). http://www.pms.ifi.lmu.de/rewerse-wga1/index.html.

[112] T. Ryutov, L. Zhou, C. Neuman, T. Leithead, and K.E. Seamons. Adaptive trustnegotiation and access control. In Proc. of the 10th ACM Symposium on AccessControl Models and Technologies, Stockholm, Sweden, June 2005.

[113] P. Samarati. Protecting respondents’ identities in microdata release. IEEE Trans-actions on Knowledge and Data Engineering, 13(6):1010–1027, 2001.

[114] P. Samarati and S. De Capitani di Vimercati. Access control: Policies, models,and mechanisms. In R. Focardi and R. Gorrieri, editors, Foundations of SecurityAnalysis and Design, LNCS 2171. Springer-Verlag, 2001.

http://www.openwave.com/

http://www.oecd.org/document/18/0,2340,en_2649_34255_1815186_119820_1_1_1,00.html

http://www.oecd.org/document/18/0,2340,en_2649_34255_1815186_119820_1_1_1,00.html

http://www.rfc-editor.org/rfc/rfc4119.txt

http://www.rfc-editor.org/rfc/rfc4119.txt

http://www.prime-project.eu.org/

http://www.prime-project.eu.org/

http://www.privacyrights.org/ar/ChronDataBreaches.htm

http://www.privacyrights.org/ar/ChronDataBreaches.htm

http://www.pms.ifi.lmu.de/rewerse-wga1/index.html

http://www.pms.ifi.lmu.de/rewerse-wga1/index.html


[115] R. Sandhu, D. Ferraiolo, and R. Kuhn. The NIST Model for Role-Based AccessControl: Towards a Unified Standard. In Proc. of the 5th ACM Workshop on Role-Based Access Control, Berlin, Germany, July 2000.

[116] N. Sastry, U. Shankar, and S. Wagner. Secure verification of location claims. InProc. of the ACM Workshop on Wireless Security (WiSe 2003), San Diego, CA,USA, September 2003.

[117] B. Schlit. Ubiquitous location-aware computing and the place lab initiative. InProc. of the First ACM International Workshop on Wireless Mobile Applicationsand Services on WLANHotspots, San Diego, CA, September 2003.

[118] K. Seamons, M. Winslett, and T. Yu. Limiting the disclosure of access controlpolicies during automated trust negotiation. In Proc. of the Network and DistributedSystem Security Symposium (NDSS 2001), San Diego, CA, USA, April 2001.

[119] K. E. Seamons, W. Winsborough, and M. Winslett. Internet credential acceptancepolicies. In Proc. of the Workshop on Logic Programming for Internet Applications,Leuven, Belgium, July 1997.

[120] C. E. Shannon. A mathematical theory of communication. Bell System TechnicalJournal, 27(379–423):623–656, July-October 1948.

[121] D. Sommer. Architecture V1, August 2005. https://www.prime-project.eu/prime_products/reports/arch/pub_del_D14.2.c_ec_WP14.2_v1_Final.pdf.

[122] V.S. Subrahmanian, S. Adali, A. Brink, J.J. Lu, A. Rajput, T.J. Rogers, R. Ross,and C. Ward. A heterogeneous reasoning and mediator system. http://www.cs.umd.edu/projects/hermes.

[123] G. Sun, J. Chen, W. Guo, and K.J. Ray Liu. Signal processing techniques in network-aided positioning: A survey of state-of-the-art positioning designs. IEEE SignalProcessing Magazine, pages 12–23, July 2005.

[124] B. Thuraisingham. Privacy constraint processing in a privacy-enhanced databasemanagement system. Data & Knowledge Engineering, 55(2):159–188, November2005.

[125] Truste. http://www.truste.org/about/index.php.

[126] T.W. van der Horst, T. Sundelin, K.E. Seamons, and C.D. Knutson. Mobile trustnegotiation: Authentication and authorization in dynamic mobile networks. In Proc.of the Eight IFIP Conference on Communications and Multimedia Security, LakeWindermere, England, September 2004.

https://www.prime-project.eu/prime_products/reports/arch/pub_del_D14.2.c_ec_WP14.2_v1_Final.pdf

https://www.prime-project.eu/prime_products/reports/arch/pub_del_D14.2.c_ec_WP14.2_v1_Final.pdf

http://www.cs.umd.edu/projects/hermes

http://www.cs.umd.edu/projects/hermes

http://www.truste.org/about/index.php

152 6. Bibliography

[127] U. Varshney. Location management for mobile commerce applications in wirelessinternet environment. ACM Transactions on Internet Technology, 3(3):236–255,August 2003.

[128] W3C. Platform for privacy preferences (P3P) project, April 2002. http://www.w3.org/TR/P3P/.

[129] Web services policy framework. http://www.ibm.com/developerworks/webservices/library/specification/ws-polfram/?S_TACT=105AGX04&S_CMP=LP, March 2006.

[130] Windows cardspace. http://cardspace.netfx3.com/.

[131] W. Winsborough, K. E. Seamons, and V. Jones. Automated trust negotiation. InProc. of the DARPA Information Survivability Conference & Exposition (DISCEX2000), Hilton Head Island, South Carolina, USA, January 2000.

[132] M. Winslett, N. Ching, V. Jones, and I. Slepchin. Assuring security and privacy fordigital library transactions on the web: Client and server security policies. In Proc.of the 4th International Forum on Research and Technology Advances in DigitalLibraries (ADL ’97), Washington, DC, USA, May 1997.

[133] World Wide Web Consortium. A P3P Preference Exchange Language 1.0 (AP-PEL1.0), April 2002. http://www.w3.org/TR/P3P-preferences/.

[134] Ws-federation. http://www-106.ibm.com/developerworks/webservices/library/ws-fed/.

[135] M. Youssef, V. Atluri, and N.R. Adam. Preserving mobile customer privacy: Anaccess control system for moving objects and customer profiles. In Proc. of the 6thInternational Conference on Mobile Data Management (MDM 2005), Ayia Napa,Cyprus, May 2005.

[136] T. Yu, X. Ma, and M. Winslett. An efficient complete strategy for automated trustnegotiation over the internet. In Proc. of the 7th ACM Conference on Computerand Communication Security (CCS 2000), Athens, Greece, November 2000.

[137] T. Yu and M. Winslett. A unified scheme for resource protection in automated trustnegotiation. In Proc. of the IEEE Symposium on Security and Privacy, Berkeley,California, USA, May 2003.

[138] T. Yu, M. Winslett, and K.E. Seamons. Interoperable strategies in automated trustnegotiation. In Proc. of the 8th ACM Conference on Computer and CommunicationsSecurity (CCS 2001), Philadelphia, Pennsylvania, USA, November 2001.

http://www.w3.org/TR/P3P/

http://www.w3.org/TR/P3P/

http://www.ibm.com/developerworks/webservices/library/specification/ws-polfram/?S_TACT=105AGX04&S_CMP=LP



http://cardspace.netfx3.com/

http://www.w3.org/TR/P3P-preferences/

http://www-106.ibm.com/developerworks/webservices/library/ws-fed/

http://www-106.ibm.com/developerworks/webservices/library/ws-fed/


[139] T. Yu, M. Winslett, and K.E. Seamons. Supporting structured credentials and sensi-tive policies trough interoperable strategies for automated trust. ACM Transactionson Information and System Security (TISSEC), 6(1):1–42, February 2003.

[140] G. Zhang and M. Parashar. Dynamic context-aware access control for grid applica-tions. In Proc. of the 4th International Workshop on Grid Computing (Grid 2003),Phoenix, Arizona, November 2003.

154 6. Bibliography

AAccess control and release language:

XML Schema

<?xml version="1.0" encoding="UTF-8" ?>

<xs:schema xmlns:Q1="http://www.prime-project.eu/policies/"

xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="unqualified"

elementFormDefault="qualified" targetNamespace="http://www.prime-project.eu/policies/"

xmlns:Q2="https://www.prime-project.eu/ont/XSD-Claim"

xmlns:request="https://www.prime-project.eu/ont/XSD-ClaimRequest">

<xs:import namespace="https://www.prime-project.eu/ont/XSD-ClaimRequest"

schemaLocation="ClaimRequest.xsd" />

<xs:element name="policy" type="Q1:policyType">

<xs:annotation>

<xs:documentation>One policy.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:complexType name="policyType">

<xs:sequence>

<xs:element maxOccurs="1" minOccurs="1" name="description" type="Q1:descriptionType" />

<xs:element name="object" type="xs:anyURI">

<xs:annotation>

<xs:documentation>What to access.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="objectExprs" type="Q1:conditionListType" />

<xs:element name="actions" type="Q1:actionListType">

<xs:annotation>

<xs:documentation>Allowed actions.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="rules" type="Q1:ruleListType" />

</xs:sequence>

<xs:attribute name="id" type="xs:ID">

<xs:annotation>

<xs:documentation>Id of the policy.</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="type">

<xs:annotation>

<xs:documentation>

A policy either guarding the disclose of or access to data.

</xs:documentation>

156 A. Access control and release language: XML Schema

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:anyURI">

<xs:enumeration value="http://www.prime-project.eu/policies/access" />

<xs:enumeration value="http://www.prime-project.eu/policies/release" />

<xs:enumeration value="http://www.prime-project.eu/policies/datahandling" />

</xs:restriction>

</xs:simpleType>

</xs:attribute>

<xs:attribute name="authors" type="xs:string" />

</xs:complexType>

<xs:complexType name="ruleListType">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="0" name="rule" type="Q1:ruleType" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="ruleType">

<xs:sequence>

<xs:element name="subject" type="xs:anyURI" />

<xs:element name="actions" type="Q1:actionListType" />

<xs:element name="purposes" type="Q1:purposesListType" />

<xs:element name="conditions" type="Q1:expressionsType" />

</xs:sequence>

<xs:attribute name="id" type="xs:ID" use="required" />

</xs:complexType>

<xs:complexType name="groupListType">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="0" name="group" type="Q1:group" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="expressionsType">

<xs:sequence>

<xs:element name="subjectExprs" type="Q1:groupListType" />

<xs:element name="genericExprs" type="Q1:conditionListType" />

<xs:element name="trustExprs" type="Q1:conditionListType" />

<xs:element name="lbsExprs" type="Q1:conditionListType" />

<xs:element name="stateExprs" type="Q1:groupListType" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="conditionType">

<xs:complexContent>

<xs:extension base="Q1:predicateType">

<xs:attribute default="true" name="sanitization" type="xs:boolean" />

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="group">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="1" name="condition" type="Q1:conditionType" />

<xs:element maxOccurs="1" minOccurs="1" name="evidence"

type="request:claimrequest.option.group.evidenceListType" />

</xs:sequence>

<xs:attribute name="name" type="xs:anyURI" use="required" />

</xs:complexType>

<xs:complexType name="annotationType">

<xs:simpleContent>

<xs:extension base="xs:anySimpleType">

<xs:attribute name="name" type="xs:anyURI" />

157

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:complexType name="descriptionType">

<xs:sequence>

<xs:element maxOccurs="1" minOccurs="1" name="long" type="xs:string" />

<xs:element name="annotation" type="Q1:annotationType" />

</xs:sequence>

<xs:attribute name="short" type="xs:string" />

</xs:complexType>

<xs:complexType name="conditionListType">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="0" name="condition" type="Q1:conditionType" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="actionListType">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="1" name="action" type="xs:anyURI" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="predicateType">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="0" name="argument" type="Q1:argumentType" />

</xs:sequence>

<xs:attribute name="name" type="xs:anyURI" />

</xs:complexType>

<xs:complexType name="certificationType">

<xs:sequence>

<xs:any maxOccurs="unbounded" minOccurs="0" namespace="##any" processContents="lax" />

</xs:sequence>

<xs:attribute name="type" type="xs:anyURI" />

</xs:complexType>

<xs:complexType name="argumentType">

<xs:complexContent>

<xs:extension base="xs:anyType">

<xs:attribute name="isLiteral" type="xs:boolean" use="required" />

</xs:extension>


</xs:complexType>

<xs:complexType name="purposesListType">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="1" name="purpose" type="xs:anyURI" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="recipientsListType">

<xs:sequence>

<xs:element name="recipient" type="xs:anyURI" />

</xs:sequence>

</xs:complexType>

</xs:schema>

158 A. Access control and release language: XML Schema

BData handling language: XML

Schema

<?xml version="1.0" encoding="utf-8" ?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:complexType name="condition">

<xs:sequence>

<xs:element name="argument" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:complexContent>

<xs:extension base="xs:anyType">

<xs:attribute name="isLiteral" type="xs:boolean" />

</xs:extension>


</xs:complexType>

</xs:element>

</xs:sequence>


</xs:complexType>

<xs:element name="DHP">

<xs:complexType>

<xs:sequence>

<xs:element name="annotation">

<xs:complexType>

<xs:sequence>

<xs:element name="description" />

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Description">

<xs:complexType>

<xs:sequence>

<xs:element name="Long" type="xs:string" />

<xs:element name="Short" type="xs:string" />

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="PII" type="xs:anyURI" />

<xs:element name="actions">

<xs:complexType>

<xs:sequence>

160 B. Data handling language: XML Schema

<xs:element name="action" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="purposes">

<xs:complexType>

<xs:sequence>

<xs:element name="purpose" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:simpleContent>

<xs:extension base="xs:string">


<xs:attribute name="type" use="optional" default="optional">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="required" />

<xs:enumeration value="optional" />

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="recipients">

<xs:complexType>

<xs:sequence>

<xs:element name="recipient" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="condition" type="condition" minOccurs="0"

maxOccurs="unbounded" />

</xs:sequence>

<xs:attribute name="subject" type="xs:anyURI" />

<xs:attribute name="type" use="optional" default="optional">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="required" />

<xs:enumeration value="optional" />

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="obligations">

<xs:complexType>

<xs:sequence>



</xs:sequence>

</xs:complexType>

</xs:element>

161

<xs:element name="provisions">

<xs:complexType>

<xs:sequence>



</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="gen_conditions">

<xs:complexType>

<xs:sequence>



</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="disputes">

<xs:complexType>

<xs:sequence>

<xs:element name="dispute" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="remedies" type="xs:string" />

<xs:element name="description" type="xs:string" />

</xs:sequence>

<xs:attribute name="thirdParty" type="xs:anyURI" />

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name="id" type="xs:string" />

</xs:complexType>

</xs:element>

</xs:schema>

162 B. Data handling language: XML Schema

CDistance between centers of circular

areas given the overlap

Given two circular areas A and B with radii r and R, the shifting angle θ, and δ as thepure number representing the ratio between the square intersection of the two areas andthe two areas A and B, we provide the flow that results in the distance d between thecenters of the two areas (see Figure C.1).

Figure C.1: Parameters to calculate the distance between centers

INPUT: r, R, θ, δ = (AT

B)·(AT

B)A·B = (A

TB)·(A

TB)

π2r2R2

OUTPUT: d

From the input data, we find the area of the asymmetric “lens” in which the circle intersect(i.e., A

⋂B), by calculating the two circular segments (i.e., one for each half of the lens),

the first time with radius r and chord c the second with radius R and chord c.

(AT

B)·(AT

B)A·B = δ (C.1)

(AT

B) · (AT

B) = δ(πr2)(πR2)

(AT

B) =√

δπrRhσ2π

πr2 − r cos σ2r sin σ

2

i+

hγ2π

πR2 −R cos γ2R sin γ

2

i=√

δπrR

Given the formula sin 2α = 2 sin α cos α the above formula becomes:

164 C. Distance between centers of circular areas given the overlap

hσ

2r2 − r2

2sin σ

i+

hγ

2R2 − R2

2sin γ

i=√

δπrR

Given the equations of the distance between the centers, i.e., d = r cos σ2 + R cos γ

2 , andthe equation that binds the two angles σ and γ, i.e r sin σ

2 = R sin γ2 , the calculation of the

distance d between the centers consists of analytical resolution of the following system ofequations:

8>><>>:h

σ2r2 − r2

2sin σ

i+

hγ2R2 − R2

2sin γ

i=√

δπrR

d = r cos σ2

+ R cos γ2

r sin σ2

= R sin γ2

(C.2)

The limiting case of the above system is when d = r + R and then δπR2 = 0, resulting inδ = 0 (i.e., full privacy), and when the radius of Area A and Area B are the same (i.e.,R=r). In particular, for the latter case the system of equations that must to be solved tocalculate the distance d is:

8>><>>:h

σ2r2 − r2

2sin σ

˜+

ˆγ2r2 − r2

2sin γ

˜=√

δπr2

d = r cos σ2

+ r cos γ2

r sin σ2

= r sin γ2

From the third equation results that σ = γ and then the system could be simplified asfollow:

(σ − sin σ =

√δπ

d = 2r cos σ2

(C.3)

DPublications

(1) A Privacy-Aware Access Control System.

(co-authors: M. Cremonini, S. De Capitani di Vimercati, P. Samarati)

Journal of Computer Security (JCS) (to appear)

Abstract: The protection of privacy is an increasing concern in our networkedsociety because of the growing amount of personal information that is collected bya number of commercial and public services. One of the most important privacyprotection principles states that personal information collected for one purpose maynot be used for any other purpose without the explicit informed consent of theperson to which information refers. Despite this principle is well known and widelyaccepted, its application is often limited and unclear. In this paper, we introducea new type of privacy policy, called data handling policy , which allows users tospecify and communicate to other parties the policy that should be enforced to dealwith their data. We also discuss how data handling policies can be integrated withtraditional access control systems and present an architecture in charge of managing,integrating, and evaluating access control, and data handling policies.

(2) Privacy-enhanced Location-based Access Control.

(co-authors: M. Cremonini, S. De Capitani di Vimercati, P. Samarati)

Handbook of Database Security, Springer (to appear)

Abstract: Advancements in location technologies reliability and precision are fos-tering the development of location-based services that make use of the location infor-mation of users. An increasingly important category of such services is representedby Location-based Access Control (LBAC) systems that integrate traditional accesscontrol mechanisms with access conditions based on the physical position of usersand other attributes related to the users location. Since privacy is extremely impor-tant for users, protection of their location information is paramount to the success ofsuch emerging location-based services. In this chapter, we first present an overviewof Location-based Access Control systems and then characterize the location privacy

166 D. Publications

protection problem. We then discuss the main techniques that have been proposedto protect location information, focusing on the obfuscation-based techniques. Weconclude the chapter by showing a privacy-aware LBAC architecture and describinghow a location-based access control policy can be evaluated.

(3) Location Privacy Protection Through Obfuscation-based Techniques.

(co-authors: M. Cremonini, E. Damiani, S. De Capitani di Vimercati, P. Samarati)

21st Annual IFIP WG 11.3 Working Conference on Data and Applications Security(DBSEC 2007)

Abstract: The widespread adoption of mobile communication devices combinedwith technical improvements of location technologies are fostering the developmentof a new wave of applications that manage physical positions of individuals to offerlocation-based services for business, social or informational purposes. As an effect ofsuch innovative services, however, privacy concerns are increasing, calling for moresophisticated solutions for providing users with different and manageable levels ofprivacy. In this work, we propose a way to express users privacy preferences onlocation information in a straightforward and intuitive way. Then, based on suchlocation privacy preferences, we discuss a new solution, based on obfuscation tech-niques, which permits us to achieve, and quantitatively estimate through a metric,different degrees of location privacy.

(4) Method, System, Network and Computer Program Product for Position-ing in a Mobile Communications Network

(co-authors: M. Anisetti, V. Bellandi, E. Damiani, S. Reale)

European Patent No. EP1765031, Published in date 21 March 2007

(5) Secure Authentication Process for High Sensitive Data e-Services: aRoadmap

(co-authors: E. Damiani, F. Frati, S. Reale)

Information Security and Ethics: Concepts, Methodologies, Tools, and Applications,Information Science reference, pages 130-143, Hershey, New York, 2007, alreadypublished in Journal of Cases on Information Technology (JCIT), 9(1):20-35, 2007

Abstract: The widespread diffusion of on-line services provided by public and pri-vate organizations, firstly driven by e-Commerce and more recently by e-Governmentapplications, has stressed the need of secure ways to authenticate users who need toaccess on-line resources. The huge number of resources accessible on the web leadsto different authentication mechanisms implementations that often require multiplelog-on actions also in intra-domain multi-services scenario. In case of high sensitiveservices, users’ authentication plays a role of paramount importance. In this article

167

is presented a case study that gives a roadmap of authentication mechanisms im-plemented at different levels of services’ software structure. The discussion startsby illustrating different authentication solutions implemented at operating system,application server or components level to conclude with Single Sign-On approach.For each solution, pros and cons are discussed. The SSO system, called CAS++,developed as an extension to Yale University’s CAS, is then presented.

(6) Privacy-enhanced Location Services


Digital Privacy: Theory, Technologies and Practices, Taylor and Francis, 2007

(7) Privacy in the Electronic Society: Emerging Problems and Solutions.


ISI Platinum Jubilee Monograph Series, World Scientific Press, 2007 (to appear)

Abstract: As the global information infrastructure is becoming more ubiquitous,digital business transactions are increasingly performed using a variety of mobiledevices and across multiple communication channels. This new service-orientedparadigm is making the protection of privacy an increasing concern, as it relieson rich context representations (e.g., of location and purpose) and requires users toprovide a vast amount of information about themselves and their behavior. This in-formation is likely to be protected by a privacy policy, but restrictions to be enforcedmay come from different input requirements, possibly under the control of differentauthorities. In addition, users retain little control over their personal informationonce it has been disclosed to third parties. Secondary usage regulations are thereforeincreasingly demanding attention. In this paper, we present the emerging trends inthe data protection field to address the new needs and desiderata of today’s systems.

(8) OpenAmbient: a Pervasive Access Control Architecture

(co-authors: M. Anisetti, V. Bellandi, E. Damiani)

Long-Term and Dynamical Aspects of Information Security: Emerging Trends inInformation and Communication Security, Nova Science Publisher, Inc., 2007

(9) XML Security

(co-authors: E. Damiani, S. De Capitani di Vimercati, P. Samarati)

Security, Privacy and Trust in Modern Data Management, Springer, 2007

Abstract: The extensible markup language (XML) is a markup language promotedby the World Wide Web consortium (W3C). XML overcomes the limitations of hy-pertext markup language (HTML) and represents an important opportunity to solvethe problem of protecting information distributed on the Web, with the definition

168 D. Publications

of access restrictions directly on the structure and content of the document. Thischapter summarizes the key XML security technologies and provides an overview ofhow they fit together and with XML. It should serve as a roadmap for future re-search and basis for further exploration of relevant scientific literature and standardspecifications.

(10) Trust Management

(co-authors: E. Damiani, S. De Capitani di Vimercati, S. Foresti, P. Samarati)

Security, Privacy and Trust in Modern Data Management, Springer, 2007

Abstract: The amount of data available electronically to a multitude of users hasbeen increasing dramatically over the last few years. The size and dynamics of theuser community set requirements that cannot be easily solved by traditional accesscontrol solutions. A promising approach for supporting access control in open en-vironments is trust management . This chapter provides an overview of the mostsignificant approaches for managing and negotiating trust between parties. We startby introducing the basic concepts on which trust management systems are built, de-scribing their relationships with access control. We then illustrate credential-basedaccess control languages together with a description of different trust negotiationstrategies. We conclude the chapter with a brief overview of reputation-based sys-tems.

(11) Privacy-Enhanced Identity Management for e-Services

(co-authors: M. Cremonini, E. Damiani, S. De Capitani di Vimercati, F. Frati, P.Samarati)

Book on Secure eGovernment Web Services, Idea Group INC., 162-179, 2007

Abstract: This chapter introduces the concept of privacy-enhanced identity man-agement for e-services supporting the users needs to protect their privacy and sen-sitive information. Business activities are increasingly based on the use of remoteresources and e-services as well as on the interaction between different, remotely-located, parties. In this context, the electronic execution of private and/or sensitivetransactions must fully preserve information privacy by managing in a trustworthyand responsible way all identity and profile information that is released to remoteparties. In this chapter, we investigate the main problems concerning identity man-agement for e-services and outline the features that the next-generation of identitymanagement systems should provide for. State-of-the-art technology in the field ofprivacy-enhanced identity management systems is also compared with traditionalPublic Key Infrastructure (PKI) solutions. The analysis of the benefits of thesemodern identity management systems is presented and discussed with referencesalso to the results of some experiences in the area of e-government, whose objectiveis the development of public administration privacy-aware e-services.

169

(12) L-VCONF: A Location-Aware Infrastructure for Videoconferences inCritical Environments

(co-authors: E. Damiani, M. Anisetti, V. Bellandi)

IEEE International Conference On Virtual Environments, Human-Computer Inter-face, and Measurement Systems (VECIMS 2007)

Abstract: Audio and videoconference technologies make complex coordination pro-cesses easier, especially when mobile participants need to synchronize their action incritical environments. The need for an infrastructure providing such a functionalitymay arise in complex scenarios where an IP network is not available, as for instancein battlefield or other critical environments. This paper describes L-VCONF, an archi-tecture for geo-located conferencing based on a mobile/cellular network (i.e. GPRS,UMTS, WiMax technologies), quick-and-dirty mobile/cellular geolocation, SIP pro-tocol and presence server. Our architecture supports IP audio/videoconferences en-riched with geo-located coordination functionalities in complex environments. Theapproach described in the paper is robust w.r.t. uncertainty while handling locationupdate notification for SIP presence server.

(13) FOCSE: A Formal Evaluation Framework for OS Adoption in CriticalEnvironments

(co-authors: E. Damiani, F. Frati)

Third IFIP International Conference on Open Source Systems (IFIP OSS 2007)

Abstract: While the vast majority of European and US companies increasingly useopen source software for non-key applications, a much smaller number of companieshave deployed it in critical areas such as security and access control. This is partlydue to residual difficulties in performing and documenting the selection process ofopen source solutions. In this paper we describe the FOCSE metrics framework,supporting a specific selection process for security-related open source code. FOCSEis based on a set of general purpose metrics suitable for evaluating open sourceframeworks in general; however, it includes some specific metrics expressing securitysolutions’ capability of responding to continuous change in threats. We show FOCSEat work in two use cases about selecting two different types of security-related opensource solutions, i.e. Single Sign-On and Secure Shell applications.

(14) Managing Privacy in LBAC Systems

(co-authors: M. Cremonini, E. Damiani, S. De Capitani di Vimercati, S. Samarati)

Second IEEE International Symposium on Pervasive Computing and Ad Hoc Com-munications (PCAC 2007)

Abstract: One of the main challenges for privacy-aware location-based systems isto strike a balance between privacy preferences set by users and location accuracy

170 D. Publications

needed by Location-Based Services (LBSs). To this end, two key requirements mustbe satisfied: the availability of techniques providing for different degrees of user lo-cation privacy and the possibility of quantifying such privacy degrees. To addressthe first requirement, we describe two obfuscation techniques. For the second re-quirement, we introduce the notion of relevance as the estimator for the degree oflocation obfuscation. This way, location obfuscation can be adjusted to comply withboth user preferences and LBS accuracy requirements.

(15) A middleware architecture for integrating privacy preferences and loca-tion accuracy


22nd IFIP TC 11 International Information Security Conference (IFIP SEC 2007)

Abstract: Location-Based Access Control (LBAC) systems support the evaluationof conditions on locations in the enforcement of access control policies. The abilityto evaluate conditions on a set of authorized locations has a number of well-knownadvantages, including enriching access control expressiveness. However, when loca-tions are used in combination with personal identities, users privacy must be con-sidered. In this paper, we describe a solution to integrate a LBAC system withprivacy-enhanced techniques based on location obfuscation. Our solution is basedon a privacy-aware middleware component that explicitly addresses the trade-off be-tween users privacy and location accuracy by satisfying preferences set by users andmaximizing the quality of location information released to LBAC systems.

(16) Anomalies Detection in Mobile Network Management Data (short paper)

(co-authors: E. Damiani, M. Anisetti, V. Bellandi, E. Bernardoni, S. Reale)

12th International Conference on Database System for Advanced Applications (DAS-FAA 2007)

Abstract: Third generation (3G) mobile networks rely on distributed architectureswhere Operation and Maintenance Centers handle a large amount of informationabout network behavior. Such data can be processed to extract higher-level knowl-edge, useful for network management and optimization. In this paper we applyreduction techniques, such as Principal Component Analysis, to identify orthogonalsubspaces representing the more interesting data contributing to overall variance andto split them up in “normal” and “anomalous” subspaces. Patterns within anoma-lous subspaces allow for early detection of network anomalies, improving mobilenetworks management and reducing the risk of malfunctioning.

171

(17) Negotiation Protocols for LBAC Systems


1st International Conference on Information Security and Computer Forensics (ISCF2006)

Abstract: Location-based Access Control (LBAC) systems are based on applica-tions whose access control policies include location predicates. The enforcementof location predicates is performed by an Access Control Engine (ACE) and re-quires complex location services integrating sensing technologies able to gather users’physical location and components that process this information according to LBACspecifications. A specialized Location Middleware (LM) provides such location ser-vices. In this paper, we consider that the quality of such particular location servicescould be adjusted according to different Service Level Agreements (SLAs) expressedthrough the exchange of specific metadata. To this end, we address the issue of ne-gotiating location service attributes between an ACE and a LM and introduce someprotocols to carry out this coordination process. We start from a basic negotiationprotocol that shows the core aspects of our proposal, to introduce an enhanced pro-tocol that takes into account a cost/benefit analysis and some service requirements.Finally, we present an extension to the enhanced protocol to consider possible timevalidity constraints on access control decisions.

(18) Open Source in Web-based Applications: A Case Study on Single Sign-On

(co-authors: F. Frati, G. Gianini)

Special Issue on Web-based, Community Driven Open Source Systems in the Interna-tional Journal of Information Technology and Web Engineering (IJITWE), 1(3):81-94, 2006

Abstract: Business and recreational activities on the global communication infras-tructure are increasingly based on the use of remote resources and services, and onthe interaction between different, remotely located parties. In such a context, Sin-gle Sign-On technologies simplify the log-on process allowing automatic access tosecondary domains through a unique log-on operation to the primary domain. Inthis article, we evaluate different Single Sign-On implementations focusing on thecentral role of Open Source in the development of Web-based systems. We outlinerequirements for Single Sign-On systems and evaluate four existing Open Sourceimplementations in terms of degree of fulfillment of those requirements. Finallywe compare those Open Source systems with respect to some specific Open Sourcecommunity patterns.

172 D. Publications

(19) Enhancing User Privacy Through Data Handling Policies

(co-authors: S. De Capitani di Vimercati, P. Samarati)

20th Annual IFIP WG 11.3 Working Conference on Data and Applications Security(DBSEC 2006)

Abstract: The protection of privacy is an increasing concern in today’s globalinfrastructure. One of the most important privacy protection principles states thatpersonal information collected for one purpose may not be used for any other purposewithout the specific informed consent of the person it concerns. Although usersprovide personal information for use in one specific context, they often have no ideaon how such a personal information may be used subsequently. In this paper, weintroduce a new type of privacy policy, called data handling policy, which defines howthe personal information release will be (or should be) dealt with at the receivingparty. A data handling policy allows users to define simple and appropriate levels ofcontrol over who sees what information about them and under which circumstances.

(20) Adopting Open Source for Mission-Critical Applications: A Case Studyon Single Sign-On

(co-authors: E. Damiani, F. Frati, S. Reale)

Second IFIP International Conference on Open Source Systems (IFIP OSS 2006)

Abstract: In this paper, we put forward the idea of a specific selection processfor security-related open source code, based on a methodology aimed at evaluatingopen source security frameworks in general and (Single-Sign-On) SSO systems inparticular. Major evaluation criteria for open source SSO include the timeliness ofreaction against newly discovered vulnerabilities or incidents.

(21) CAS++: an Open Source Single Sign-On Solution for Secure e-Services

21st IFIP TC-11 International Information Security Conference (SEC 2006)

(co-authors: E. Damiani, S. De Capitani di Vimercati, F. Frati, P. Samarati)

Abstract: Business and recreational activities on the global communication infras-tructure are increasingly based on the use of remote resources and services, and onthe interaction between different, remotely located parties. On corporate networksas well as on the open Web, the huge number of resources and services often requiresto multiple log-ons leading to credential proliferation and, potentially, to securityleaks. An increasingly widespread approach to simplify and secure the log-on pro-cess is Single Sign-On (SSO) that allows automatic access to secondary domainsthrough a single log-on operation to a primary domain. In this paper, we describethe basic concepts of SSO architecture focusing on the central role of open sourceimplementations. We outline three major SSO trust models and the different require-ments to be addressed. We then illustrate CAS++, our open source implementation

173

of a Single Sign-On service. Finally, we illustrate the application of CAS++ to areal case study concerning the development of a multi-service network managementsystem. The motivation for our work has been raised in response to the requirementsof such case study within the Pitagora project.

(22) Location-based Metadata and Negotiation Protocols for LBAC in a One-to-Many Scenario


Workshop On Security and Privacy in Mobile and Wireless Networking(SecPri MobiWi 2006)

Abstract: Location-based Access Control (LBAC) techniques allow the definitionof users’ access rights based on location predicates that exploit the users’ physicallocation. However, evaluating the physical location of a user is a specialized activitythat is unlikely to be performed by the same entity (e.g., organization or system) incharge of the access control decision. For this reason, location evaluation is usuallyassumed to be provided by specific Location Services (LSs) possibly coexisting in asame area and competing one with the others. In this paper, we address the issuesrelated to the communication and negotiation between an Access Control Engine(ACE) enforcing access rules that include location-based predicates and multiple,functionally equivalent, LSs. We introduce metadata for the exchange of servicelevel agreement attributes between the ACE and the LSs. Based on such metadatawe develop different negotiation protocols, from a basic negotiation protocol thatshows the core aspects of our proposal to an enhanced protocol that enriches theinteraction by taking into account a cost/benefit analysis and some service require-ments. Finally, we present an extension to the enhanced protocol to consider possibletime validity constraints on access control decisions.

(23) Supporting Location-Based Conditions in Access Control Policies


ACM Symposium on InformAtion, Computer and Communications Security (ASI-ACCS 2006)

Abstract: Location-based Access Control (LBAC) techniques allow taking users’physical location into account when determining their access privileges. In this pa-per, we present an approach to LBAC aimed at integrating location-based conditionsalong with a generic access control model, so that a requestor can be granted or de-nied access by checking her location as well as her credentials. Our LBAC modelincludes a novel way of taking into account the limitations of the technology used toascertain the location of the requester. Namely, we describe how location verifica-tion can be encapsulated as a service, representing location technologies underlyingit in terms of two semantically uniform service level agreement (SLA) parameters

174 D. Publications

called confidence and timeout. Based on these parameters, we present the formaldefinition of a number of location-based predicates, their management, evaluation,and enforcement. The challenges that such an extension to traditional access controlpolicies inevitably carries are discussed also with reference to detailed examples ofLBAC policies.

(24) Open Source Solution to Secure e-Government Services

(co-authors: E. Damiani, F. Frati, M. Madravio)

Encyclopedia of Digital Government, Idea Group INC., 2006

(25) Towards Privacy-Enhanced Authorization Policies and Languages


19th IFIP WG11.3 Working Conference on Data and Application Security (DBSEC2005)

Abstract: The protection of privacy in today’s global infrastructure requires thecombined application solution from technology (technical measures), legislation (lawand public policy), and organizational and individual policies and practices. Emerg-ing scenarios of user-service interactions in the digital world are also pushing towardthe development of powerful and flexible privacy-enhanced models and languages.This paper aims at introducing concepts and features that should be investigated tofulfill this demand. In particular, the content of this paper is a result of our ongoingactivity in the framework of the PRIME project (Privacy and Identity Managementfor Europe), funded by the European Commission, whose objective is the develop-ment of privacy-aware solutions for enforcing security.

(26) Offline Expansion of XACML Policies Based on P3P Metadata

(co-authors: E. Damiani, S. De Capitani di Vimercati, C. Fugazza, P. Samarati)

5th International Conference on Web Engineering (ICWE 2005)

Abstract: In the last few years XML-based access control languages like XACMLhave been increasingly used for specifying complex policies regulating access to net-work resources. Today, growing interest in semantic-Web style metadata for de-scribing resources and users is stimulating research on how to express access controlpolicies based on advanced descriptions rather than on single attributes. In this pa-per, we discuss how standard XACML policies can handle ontology-based resourceand subject descriptions based on the standard P3P base data schema. We showthat XACML conditions can be transparently expanded according to ontology-basedmodels representing semantics. Our expansion technique greatly reduces the need foronline reasoning and decreases the system administrator’s effort for producing con-sistent rules when users’ descriptions comprise multiple credentials with redundantattributes.

175

(27) Using Open Source Middleware for Securing e-Gov Applications

(co-authors: E. Damiani, F. Frati, M. Montel)

First International Conference on Open Source Systems (OSS 2005)

Abstract: Nowadays, a global information infrastructure connects remote partiesthrough the use of large scale networks, and many companies focus on developinge-services based on remote resources and on interaction between remote parties. Insuch a context, e-Government (e-Gov) systems became of paramount importance forthe Public Administration, and many ongoing development projects are targeted ontheir implementation and release. For open source software to play an importantrole in this scenario, two main technological requirements must be fulfilled: (i) theidentification and optimization of de facto standards for building e-Gov open sourcesoftware components and (ii) a standard integration strategy of these componentsinto an open source middleware layer, capable of conveying a completely open-sourcee-Gov solution. In this paper, we argue that e-Gov systems should be constructedon a open source middleware layer, providing full public responsibility in its devel-opment. We discuss the role of open source middleware for secure e-Gov servicesdeployment, focusing on implementing a security environment without custom pro-gramming. We give an analysis of two most important open source ApplicationServer (JBoss and JOnAS) and we provide a complete description of security solu-tion adopted in our open source implementation of e-Gov services, introducing singlesign-on authentication based on certificates.

(28) The Architecture of a Privacy-aware Access Control Decision Component


International Conference in Construction and Analysis of Safe, Secure and Interop-erable Smart devices (CASSIS 2005)

Abstract: Today many interactions are carried out online through Web sites ande-services and often private and/or sensitive information is required by serviceproviders. A growing concern related to this widespread diffusion of on-line ap-plications that collect personal information is that users’ privacy is often poorlymanaged and sometimes abused. For instance, it is well known how personal in-formation is often disclosed to third parties without the consent of legitimate dataowners or that there are professional services specialized on gathering and correlatingdata from heterogeneous repositories, which permit to build user profiles and pos-sibly to disclose sensitive information not voluntarily released by their owners. Forthese reasons, it has gained great importance to design systems able to fully preserveinformation privacy by managing in a trustworthy and responsible way all identityand profile information. In this paper, we investigate some problems concerningidentity management for e-services and present the architecture of the Access Con-

176 D. Publications

trol Decision Function, a software component in charge of managing access requestin a privacy-aware fashion. The content of this paper is a result of our ongoing activ-ity in the framework of the PRIME project (Privacy and Identity Management forEurope), funded by the European Commission, whose objective is the developmentof privacy-aware solutions for enforcing security.

(29) Towards Identity Management for E-Services (poster session)


TED Conference on e-Government Electronic democracy: The challenge ahead (TC-GOV 2005)

Abstract: Nowadays, business and recreational activities are increasingly based onthe use of remote resources and e-services, and on the interaction between different,remotely located parties. In such a context, it is of paramount importance that elec-tronic execution of private and/or sensitive transactions fully preserves informationprivacy, managing in a trustworthy and responsible way all identity and profile infor-mation to be released to remote parties. In this paper, we investigate some problemsconcerning identity management for e-services and outline the next-generation iden-tity management systems comparing them with today’s Public Key Infrastructure(PKI) solutions.

(30) A Web Service Architecture for Enforcing Access Control Policies


Electronic Notes in Theoretical Computer Science, First International Workshop onViews on Designing Complex Architectures (VODCA 2004)

Abstract: Web services represent a challenge and an opportunity for organizationswishing to expose product and services offerings through the Internet. The Web ser-vice technology provides an environment in which service providers and consumerscan discover each other and conduct business transactions through the exchange ofXML-based documents. However, any organization using XML and Web Servicesmust ensure that only the right users, sending the appropriate XML content, canaccess their Web Services. Access control policy specification for controlling accessto Web services is then becoming an emergent research area due to the rapid devel-opment of Web services in modern economy. This paper is an effort to understandthe basic concepts for securing Web services and the requirements for implementingsecure Web services. We describe the design and implementation of a Web ser-vice architecture for enforcing access control policies, the overall rationale and somespecific choices of our design are discussed.

177

(31) XML-based Access Control Languages


Information Security Technical Report, Elsevier Science, 9(3):35-46, 2004

Abstract: One of the most challenging problems in managing large, distributed,and heterogeneous networked systems is specifying and enforcing security policiesregulating interactions between parties and access to services and resources. Recentproposals for specifying and exchanging access control policies adopt XML-basedlanguages. XML appears in fact a natural choice as the basis for the commonsecurity-policy language, due to the ease with which its syntax and semantics can beextended and the widespread support that it enjoys from all the main platform andtool vendors. In this chapter, we first investigate the basic concepts behind accesscontrol design and enforcement, and point out different security requirements thatmay need to be taken into consideration in designing an access control language forInternet information systems. We then focus on XML-based access control languagesand, in particular, on the eXtensible Access Control Markup Language (XACML),a recent OASIS standardization effort. XACML is designed to express authorizationpolicies in XML against objects that are themselves identified in XML. The languagecan represent the functionalities of most policy representation mechanisms.

(32) A Comparison of Modeling Strategies in Defining XML-Based AccessControl Language

(co-author: S. De Capitani di Vimercati)

Computer Systems Science & Engineering Journal, 19(3):141-149, 2004

Abstract: One of the most important features of XML-based Web services is thatthey can be easily accessed over the Internet, but this makes them vulnerable to aseries of security threats. What makes security for web services so challenging istheir distributed and heterogeneous nature. Access control policy specification forcontrolling access to Web services is then becoming an emergent research area dueto the rapid development of Web services in modern economy. Two relevant accesscontrol languages using XML are WS-Policy and XACML. The main conceptualdifference between these two languages is that while XACML is based on a well-defined model that provides a formal representation of the access control securitypolicy and its working, WS-Policy has been developed without taking into consider-ation this modeling phase. In this paper, we critique WS-Policy pointing out someof its shortcomings. We then describe the architecture we implemented and thatoffers an interface for controlling access to Web services.

DOTTORATO DI RICERCA IN I XX CICLO SETTORE...

Documents

Transcript of DOTTORATO DI RICERCA IN I XX CICLO SETTORE...