PRivacy Enabled Capability InCo-Operative Systems and Safety

Applications

Deliverable 16

Research contribution to V2X privacy and roadmaps

Project: PRECIOSAProject Number: IST-224201Deliverable: D16Title: Research contribution to V2X

privacy and roadmapsVersion: 1.0Confidentiality: PublicEditor: Lukas Dölle Part of the Seventh Framework ProgramCont. Authors: S. Dietzel, L. Dölle, J.-C. Freytag,

C. Jouvray, F. Kargl, M. Kost, Z. Ma,F. Schaub, B. Wiedersheim

Funded by the EC-DG INFSO

Date: 11.11.2010

Document History

Version Date Main author Summary of changes0.1 22.03.2010 Lukas Dölle (UBER) Initial version0.2 03.06.2010 Lukas Dölle (UBER) Restructure of document0.3 18.06.2010 Lukas Dölle (UBER) Added Chapter 2.4

26.07.2010 Lukas Dölle (UBER) Added parts of Chapter 2.50.4 23.08.2010 Florian Schaub (UULM) Added Chapter 2.6 and 3.6

29.08.2010 Lukas Dölle (UBER) Revised Chapter 2.4, addedChapter 3.4

30.08.2010 Zhendong Ma (UULM) Added Chapters 2.2, 3.2, and4.2

07.09.2010 Florian Schaub (UULM) Added parts of Chapter 3.70.5 15.09.2010 Lukas Dölle (UBER) Added Chapter 1

23.09.2010 Björn Wiedersheim (UULM) Added parts of Chapter 3.20.6 27.09.2010 Stefan Dietzel (UULM) Added Chapter 2.7

30.09.2010 Florian Schaub (UULM) Added parts of Chapter 3.701.10.2010 Stefan Dietzel (UULM) Added Chapter 3.7.201.10.2010 Stefan Dietzel (UULM) Added Chapter 4.7.101.10.2010 Florian Schaub (UULM) Added parts of Chapter 4.711.10.2010 Björn Wiedersheim (UULM) Revised Chapter 4.2, added

Chapter 4.6.130.10.2010 Martin Kost (UBER) Revised Sections 2.1, 2.3, 3.1,

3.3; Added Sections 2.1.2,2.3.2

0.7 31.10.2010 Johann-Christoph Freytag(UBER)

Revised Section 2.5, addedcontent to section 3.5 and 4.5

01.11.2010 Martin Kost (UBER) Revised Sections 2.3, AddedSection 3.1.2

0.8 04.11.2010 Martin Kost (UBER) Revised Sections 2.3.2, 3.1,3.3, 4.4; Added Sections 3.3.1,3.5, 4.1.2, 4.3.1

0.9 08.11.2010 Frank Kargl (UULM) Reviewed and conclusion1.0 11.11.2010 Lukas Dölle (UBER) Final version

i

Deliverable 16 1.0

ApprovalName Date

Prepared All Project Partners 08.11.2010Reviewed All Project Partners 10.11.2010Authorized Antonio Kung 11.11.2010CirculationRecipient Date of submissionProject Partners 11.11.2010European Commission 11.11.2010

11.11.2010 IST-224201 ii

Contents

1. Introduction 11.1. Motivation and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Overview of the PRECIOSA project . . . . . . . . . . . . . . . . . . . . . . 21.3. Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Current State-of-the-Art 62.1. Privacy Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1. Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2. Model Driven Engineering . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Privacy Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1. Metrics for location privacy . . . . . . . . . . . . . . . . . . . . . . . 102.2.2. Privacy metrics for data storage . . . . . . . . . . . . . . . . . . . . 11

2.3. Privacy-aware Analysis and Software Design . . . . . . . . . . . . . . . . . 112.3.1. Privacy analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.2. Privacy by Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4. Privacy-enhanced Policy Languages . . . . . . . . . . . . . . . . . . . . . . 172.4.1. Platform for Privacy Preferences (P3P) and A P3P Preference Ex-

change Language (APPEL) . . . . . . . . . . . . . . . . . . . . . . . 172.4.2. Extensible Access Control Markup Language (XACML) . . . . . . . 182.4.3. PRIME Policy Language . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.4. Drawbacks of existing languages . . . . . . . . . . . . . . . . . . . . 22

2.5. Privacy-aware Request Processing . . . . . . . . . . . . . . . . . . . . . . . 222.5.1. Storage Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.2. Query Processing on Location Data . . . . . . . . . . . . . . . . . . 272.5.3. Policy driven processing . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6. Privacy-aware Communication . . . . . . . . . . . . . . . . . . . . . . . . . 322.6.1. Pseudonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6.2. Symmetric key approaches . . . . . . . . . . . . . . . . . . . . . . . 342.6.3. Group signature approaches . . . . . . . . . . . . . . . . . . . . . . 352.6.4. IBC approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.7. Privacy-aware Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.7.1. Data Avoidance and Minimization . . . . . . . . . . . . . . . . . . . . 372.7.2. Restriction of Data Usage . . . . . . . . . . . . . . . . . . . . . . . . 382.7.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3. PRECIOSA Contributions 413.1. Privacy Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.1. PRECIOSA Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . 41

iii

Deliverable 16 1.0

3.1.2. Enforcing Privacy by a MDE Approach . . . . . . . . . . . . . . . . . 493.2. Privacy Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.1. Fundamentals of trip-based location privacy metric . . . . . . . . . . 513.2.2. Measuring long-term location privacy . . . . . . . . . . . . . . . . . 533.2.3. Vehicle tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3. Privacy-aware Analysis and Software Design . . . . . . . . . . . . . . . . . 573.3.1. Privacy Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.3.2. Privacy by Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.4. PRECIOSA Privacy Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.1. PRECIOSA Privacy Policy Language (P3L) . . . . . . . . . . . . . . 62

3.5. Privacy-aware Request Processing . . . . . . . . . . . . . . . . . . . . . . . 673.5.1. PRECIOSA Privacy-aware Query Language (PPQL) . . . . . . . . . 693.5.2. Policy driven processing . . . . . . . . . . . . . . . . . . . . . . . . . 713.5.3. SQL-Light - DBMS Technology for Privacy-aware Query Processing 72

3.6. Privacy-aware Communication . . . . . . . . . . . . . . . . . . . . . . . . . 733.6.1. Requirements for Pseudonym Systems . . . . . . . . . . . . . . . . 733.6.2. Enhanced Conditional Pseudonymity . . . . . . . . . . . . . . . . . . 76

3.7. PRECIOSA Privacy-aware Architecture . . . . . . . . . . . . . . . . . . . . 773.7.1. Policy Enforcement Perimeter (PEP) . . . . . . . . . . . . . . . . . . 783.7.2. Enforcing Privacy for Individual Applications . . . . . . . . . . . . . . 813.7.3. Mandatory Privacy Control (MPC) . . . . . . . . . . . . . . . . . . . 833.7.4. MPC Integrity Protection (MIP) . . . . . . . . . . . . . . . . . . . . . 83

4. Open Issues and New Challenges 854.1. Privacy Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.1.1. Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.1.2. MDE-based Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.2. Privacy Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.3. Privacy-aware Analysis and Software Design . . . . . . . . . . . . . . . . . 88

4.3.1. Privacy analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.3.2. Privacy by Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.4. Privacy-enhanced Policy Languages . . . . . . . . . . . . . . . . . . . . . . 914.5. Privacy-aware Request Processing . . . . . . . . . . . . . . . . . . . . . . . 924.6. Privacy-aware Communication . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.6.1. Pseudonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.6.2. Communication aspects of policy enforcement . . . . . . . . . . . . 96

4.7. Privacy-aware Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.7.1. Controlled application execution . . . . . . . . . . . . . . . . . . . . 974.7.2. Trusted computing and encryption . . . . . . . . . . . . . . . . . . . 984.7.3. Holistic privacy architectures . . . . . . . . . . . . . . . . . . . . . . 99

5. Conclusion 100

A. Appendix 102A.1. Privacy-aware Request Processing . . . . . . . . . . . . . . . . . . . . . . . 102

A.1.1. PRECIOSA Privacy-aware Query Language (PPQL) . . . . . . . . . 102

11.11.2010 IST-224201 iv

Deliverable 16 1.0

A.1.2. Policy driven processing . . . . . . . . . . . . . . . . . . . . . . . . . 107A.1.3. SQL-Light - DBMS Technology for Privacy-aware Query Processing 111

Bibliography 113

11.11.2010 IST-224201 v

List of Figures

2.1. XACML architecture (simplified) . . . . . . . . . . . . . . . . . . . . . . . . . 192.2. On-top and Inside Evaluation of Privacy Policies . . . . . . . . . . . . . . . 32

3.1. Domains of PRECIOSA 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2. Partial ontologies - imports of the PRECIOSA ontology . . . . . . . . . . . . 473.3. Partial ontologies - ICT privacy protection ontology . . . . . . . . . . . . . . 483.4. Snapshot information modeled in weighted tripartite graph . . . . . . . . . . 523.5. Extracted probability distribution as hub-and-spoke . . . . . . . . . . . . . . 523.6. Multiple snapshots of i in timely-ordered sequence . . . . . . . . . . . . . . 543.7. Effect of pseudonym change interval (1 - 10 seconds) on tracking results. . 563.8. Privacy recognition cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.9. Requirement Engineering in ICT . . . . . . . . . . . . . . . . . . . . . . . . 593.10.Privacy analysis - define & evaluate indicators . . . . . . . . . . . . . . . . . 603.11.Privacy Engineering Process . . . . . . . . . . . . . . . . . . . . . . . . . . 623.12.Extended query execution environments according privacy requirements. . 683.13.Executing PPQL requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.14.Partial ontologies - part of PPQL ontology . . . . . . . . . . . . . . . . . . . 703.15.Constraining (red-solid) and supporting (green-dotted) interrelations of pri-

vacy requirements in vehicular communication systems. . . . . . . . . . . . 753.16.Enhanced pseudonym issuance. . . . . . . . . . . . . . . . . . . . . . . . . 773.17.PRECIOSA PeRA Protection Chain. . . . . . . . . . . . . . . . . . . . . . . 783.18.Local policy enforcement with PeRA. . . . . . . . . . . . . . . . . . . . . . . 803.19.Distributed policy enforcement with PeRA. . . . . . . . . . . . . . . . . . . . 81

4.1. Example of horizontal separation in MDE process . . . . . . . . . . . . . . 86

A.1. Partial ontologies - PPQL ontology 1/5 . . . . . . . . . . . . . . . . . . . . . 102A.2. Partial ontologies - PPQL ontology 2/5 . . . . . . . . . . . . . . . . . . . . . 103A.3. Partial ontologies - PPQL ontology 3/5 . . . . . . . . . . . . . . . . . . . . . 104A.4. Partial ontologies - PPQL ontology 4/5 . . . . . . . . . . . . . . . . . . . . . 105A.5. Partial ontologies - PPQL ontology 5/5 . . . . . . . . . . . . . . . . . . . . . 106A.6. Partial ontologies - part of the PeRA ontology . . . . . . . . . . . . . . . . . 107A.7. Partial ontologies - P3L ontology 1/3 . . . . . . . . . . . . . . . . . . . . . . 109A.8. Partial ontologies - P3L ontology 2/3 . . . . . . . . . . . . . . . . . . . . . . 110A.9. Partial ontologies - P3L ontology 3/3 . . . . . . . . . . . . . . . . . . . . . . 111

vi

List of Tables

1.1. PRECIOSA objectives and their verification . . . . . . . . . . . . . . . . . . 3

2.1. Running example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2. 3-anonymous table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1. Data base table “Positions” . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.2. SQL-Light examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

vii

1. Introduction

This deliverable (D16) gives a summary of our PRECIOSA project from a research per-spective. We present the achievements and results of the project and identify new chal-lenges.

This chapter summarizes all PRECIOSA objectives and their realization. It gives anoverview of all deliverables and shows relations between them. The structure of the restof this document is given in the end of this chapter.

1.1. Motivation and Objectives

Co-operative systems consist of mobile entities (vehicles) which create, process and shareinformation. Communication is V2X, between vehicles (V2V) or between vehicles andthe infrastructure (V2I). In the V2I case, information will flow via roadside units (RSU)of cellular networks to backend systems. Vehicles, RSUs and backend systems processand potentially store large quantities of information, including location oriented informationsuch as position, heading, speed or intended destination.

PRECIOSA focuses on privacy problems created by the availability of location orientedinformation (other data that will be distributed in application messages, for example, statusof car systems, music lists of vehicle owner, etc. are not considered in the focus of theproject). The goal is to demonstrate that co-operative systems can comply with privacyregulations and be realized in a privacy-friendly way by demonstrating that an exampleapplication can be endowed with technologies for suitable privacy protection of locationrelated data.

The objectives are the following:

• define an approach for evaluation of co-operative systems, in terms of communica-tion privacy and data storage privacy,

• define a privacy aware architecture for co-operative systems, involving suitable trustmodels and ontologies, a V2V privacy verifiable architecture and a V2I privacy verifi-able architecture. The architecture includes components for protection, infringementdetection and auditing,

• define and validate guidelines for privacy aware co-operative systems,

• investigate specific challenges for privacy.

1

Deliverable 16 1.0

We explain this objectives in are more detailed way when taking about our results in termsof deliverables in the next section.

1.2. Overview of the PRECIOSA project

Over the last 30 month we worked on the objectives and generated 18 deliverables whichare the following:

• D0 Project handbook

• D1 V2X privacy issues analysis

• D2 V2X measurement approach

• D3 Dissemination material

• D4 Challenges for V2X privacy: issues

• D5 Year 1 management report

• D6 Models and privacy ontology for V2X

• D7 V2X privacy verifiable architecture

• D8 V2X application specification and validation requirements

• D9 PUD Y1

• D10 Mechanisms for V2X privacy

• D11 Guidelines for privacy aware cooperative application

• D12 Year 2 management report

• D13 V2X privacy mechanisms and verification support tools

• D14 V2X privacy verifiable cooperative application

• D15 PUD Y2

• D16 Research contribution to V2X privacy and roadmaps

• D17 Year 3 management report

Deliverables D0, D3, D5, D9, D12, D15, and D17 are administrative or dissemination work.Table 1.1 summarizes PRECIOSA objectives and the way these objectives are verified inthe other deliverables.

We start to deal with the first PRECIOSA objective (define an approach for privacy evalu-ation of co-operative systems) with Deliverable 1 [1] which provides an analysis of privacyissues. We analyzed privacy in terms of concepts from a legal perspective, a techni-cal perspective, and in terms of trends for co-operative systems. Furthermore, we gavea number of use cases from an application and a technology platform viewpoint which

11.11.2010 IST-224201 2

Deliverable 16 1.0

Objective Description DeliverablesApproach for privacyevaluation of co-operativesystems

Measurement approach forprivacy

D1, D2, D4

Privacy-aware architecturefor co-operative systems

Trust models and ontologiesfor privacy

D6

Privacy verifiable architecture D7Guidelines for privacy-awareco-operative systems

Example privacy verifiableco-operative application

D8, D11, D14

Validated guidelines forprivacy verifiableco-operative systems

D11, D14

Challenges for privacy Advance on privacyawareness co-operativesystems

D10, D13, D16

Table 1.1.: PRECIOSA objectives and their verification

results in privacy requirements for PRECIOSA. Deliverable 2 [2] aims to identify and pro-pose measurement approaches, which can be applied to evaluate and verify cITS1 pri-vacy at the communication level, at the data storage level, and at the system level. Somepreliminary investigations have been done in Deliverable 4 [3], which identifies and dis-cusses the challenges and the state-of-the-art of measurement approaches for cITS. D2continues the discussions in D4 with the focus on the development of concrete privacymeasurement approaches and their application to actual systems.

The second objective of PRECIOSA is to define a privacy-aware architecture for co-operative systems. The architecture work takes into account the specific issues of ve-hicular environments. It also involves the definition of trust models and ontologies forprivacy of location oriented data in co-operative systems which are described in Deliver-able 6 [4]. Such models identify elements (i.e., user stakeholders, computing subsystems)involved in the operations related to sensitive data (i.e., location oriented information), italso specifies the roles and access rights of such elements. Compliance of these mod-els with regulations are also verified. A section of D6 concretizes a privacy ontology forco-operative systems and safety applications. It defines the terms and concepts behindthe models. One main contribution of PRECIOSA is the development of the PRECIOSAPrivacy Policy Language (P3L), a language for expressing privacy requirements of driversand other parties involved in cITS. Deliverable 7 [5] presents a “privacy-verifiable archi-tecture” termed Privacy-enforcing Runtime Architecture or PeRA. This architecture canguarantee certain privacy properties and these properties can be verified by some exter-nal entity, for example, a user or trusted third party. Our approach starts from the privacyrequirements of the data subject, that is the user. The user uses a specific policy lan-guage (e.g., P3L) or other tools that generate this language to express the purpose heprovides his data for and what limits he puts to its use. Our architecture then provides

1co-operative Intelligent Transportation System

11.11.2010 IST-224201 3

Deliverable 16 1.0

a cryptographically secured path from the data subject to a specific application and thisapplication is required and enforced to contain an access control mechanism that onlyallows data access in a policy compliant way. Access control must be mandatory and itmust not be possible to circumvent it.

The other major objective of PRECIOSA is to define and validate guidelines for privacy-aware co-operative systems. Deliverable 8 [6] describes our selected application to beextended with privacy friendly features. This application is the basis for our PRECIOSAdemonstrator which is presented in detail in Deliverable 14 [7]. Following the requirementswork of D1, the ontology definition in D6 (to ensure that the same terms are used), thearchitecture design work in D7, and the use case definition work in D8 Deliverable 11 [8]provides definitions of privacy guidelines for V2X applications. The starting point is theexample application, but the guidelines are generalized so that the wide range of co-operative systems and safety applications can be covered. The result could then beadopted by future applications so that they would meet the protection requirements setout by data protection agencies. One major topic of D11 is Privacy by Design which refersto the philosophy and approach of embedding privacy into the design specifications ofvarious technologies.

The last PRECIOSA objective are specific challenges for privacy. Deliverable 10 [9] pro-vides a detailed specification of the PRECIOSA Privacy-enforcing Runtime Architecture(PeRA) and its individual components and mechanisms. While D7 takes a conceptualview on the architecture and gives a principal description, D10 describes mechanisms,components, and interfaces as a basis for architecture instantiation and future deploy-ment of privacy-aware co-operative ITS. One important PRECIOSA contribution is thedefinition of the PRECIOSA Privacy-aware Query Language (PPQL). Deliverable 13 [10]describes privacy verification tool support during design-time and run-time and integrationwith the architecture. This deliverable (D16) contributes to advanced research challengesat the level of privacy measurement and privacy of access. It summarizes all PRECIOSAresearch contributions and reveals new challenges. Therefore, we identified the followingtopics of our main contributions:

• Privacy Modeling

• Privacy Metrics

• Privacy-aware Analysis and Software Design

• Privacy-enhanced Policy Language

• Privacy-aware Request Processing

• Privacy-aware Communication

• Privacy-aware Architecture

In each of this topics we summarize the current state of research, introduce our PRE-CIOSA contributions, and show open issues and new challenges.

11.11.2010 IST-224201 4

Deliverable 16 1.0

1.3. Document Organization

The remainder of this document is structured as follows. Chapter 2 provides a view onthe current state-of-the-art. Chapter 3 describes our PRECIOSA contributions and Chap-ter 4 identifies open issues and new challenges. Each of these chapters is divided intoseven section according to the main topics of PRECIOSA (Privacy Modeling, Privacy Met-rics, Privacy-aware Analysis and Software Design, Privacy-enhanced Policy Language,Privacy-aware Request Processing, Privacy-aware Communication, and Privacy-awareArchitecture). Chapter 5 concludes the deliverable with a summary and outlook.

11.11.2010 IST-224201 5

2. Current State-of-the-Art

In the PRECIOSA project we dealt with a lot of ITS and privacy topics, created new ideas,and revealed open issues and new challenges. Chapter 3 summarizes all of our researchcontributions and is separated into seven relevant topics: Privacy Modeling, Privacy Met-rics, Privacy-aware Analysis and Software Design, Privacy-enhanced Policy Language,Privacy-aware Request Processing, Privacy-aware Communication, and Privacy-awareArchitecture. This chapter presents an overview of the state-of-the-art of these topicswhich was the input of our research work. In several sections we reference to other de-liverables where we have already presented current research and only show an updatedview with new results.

2.1. Privacy Modeling

Engineering Software for distributed systems is a very complex process. One has toconsider many different use cases, functionalities, and quality aspects. Engineers usetechniques of Model Driven Engineering (MDE) to handle the complexity. Therefore, theycreate models for abstracting from details, separating logical units (modularization andencapsulation), and documenting the (decisions of the) design. As a result, the modelsmay help to ease the organization of the development.

During the development of privacy aware applications and systems, it is necessary toidentify privacy aspects and to specify the required privacy criteria. Designer specify pri-vacy criteria as privacy policies or privacy requirements which have to be addressed inthe implementation phase. In order to identify and specify privacy criteria, one may useseveral mechanisms provided by Requirements Engineering (RE) [11] which is often partof Model Driven Engineering (MDE) methodologies. While the requirement engineeringphase we apply additional technologies as best practices, design pattern, standard mod-els, metamodels, and ontologies to reuse existing solutions, to adapt general (i.e. domainindependent) solutions, to provide a conceptualization, and to explicitly define assump-tions and requirements. The following list summarizes the major benefits when using aconceptualization in form of models, metamodels, and ontologies

• Defining terms and their meaning for privacy criteria/requirements, privacy mechanisms,privacy measurement, and auditing regarding privacy;

• Translating user privacy to technical privacy;

• Bridging the gap between high level requirements as legal requirements and technical solu-tions;

6

Deliverable 16 1.0

• Describing the behavior of active computing elements (involved in the operations of an ap-plication);

• Detecting privacy leakages;

• Describing requirements for privacy protection;

• Providing the vocabulary for defining appropriate privacy policies (formulating the stakehold-ers privacy requirements) for applications and application domains;

• Evaluation whether the requested/required privacy protection matches with the provided pri-vacy protection;

• Providing the basis for the specification and ((semi) automatic) verification regarding thecompliance to guidelines and principles of

– components,

– the composition of components (system privacy),

– systems,

– applications;

• Describing possibilities to derive (personal) information and defining rules for preventingthose inferences;

• Addressing privacy attacks that utilize semantic technologies, background knowledge, ordata mining techniques.

In the following we describe how ontology technologies are currently embedded into soft-ware design processes and we introduce an existing privacy ontology. Afterwards, wedescribe model driven engineering approaches which focus on privacy related aspects assecurity and access control.

2.1.1. Ontologies

In complex applications we must manage a variety of terms and concepts. Very soon sucha set of terms and their relationships becomes complex. There exist different approachesto deal with such complexity. For instance, we formulate precise and unambiguous de-scription based on logic; we abstract and filter out details to focus on one aspect as aspecific problem we want to solve, we present the same content in different ways andmore. A comprehensive approach has to consider the need for a clear conceptualiza-tion of the domains and their assumptions. We use ontologies to explicitly describe theconceptualization of a domain (more details can be found Deliverable D6 [4]). There-fore, those descriptions contain (a) concepts, (b) properties, (c) attributes of concepts, (d)constraints on properties and attributes, and (e) individuals (often, but not always). Anontology defines a common vocabulary and the basis for a shared understanding of adomain.

We already mentioned to use techniques of Model Driven Engineering (MDE) to handlethe complexity of systems. Model languages as the UML provide useful abstraction lay-ers and different viewpoint to analyse systems. Thereby, besides functional and other

11.11.2010 IST-224201 7

Deliverable 16 1.0

non-functional application requirements as quality, performance and security we considerprivacy requirements as well. Describing privacy requirements at different levels of ab-straction ease the step by step process to translate high level requirements into technicalrequirements. High level requirements might be principals, legal requirements, require-ments derived from project management aspects, or even user preferences. Technicalsolutions implement/enforce the resulting technical privacy requirements. At the technicallevel we can analyse and evaluate the solutions/implementations using technical ((semi)automated) techniques and tools.

We apply such analysis for model driven software/system engineering to evaluate howthe design and the implementation implement the stakeholders requirements. In researchauthors already combined disciplines of software engineering with ontologies (see chap-ter V.1 [12]). In [13] the authors present a framework which supports ontology basedrequirements engineering to predict, control and evolve systems behavior. Thereby, theyintegrate various RE modeling techniques with complementary semantics in a unifyingontological engineering process. In [14] the authors show how to integrate some ontol-ogy based analysis into a software design process. Thereby, the authors translate UMLsystem models into an OWL representation, take user specified requirements and reasonabout some software ontologies to calculate a solution which implements the specifiedrequirements.

In [15] the authors design a privacy ontology for e-Commerce which is based on the prin-ciple to control information related to a data subject according to his/her own interest.Another privacy principle states that personal information related to the data subject shallbe protected by appropriate security measures against unauthorized use or use in conflictwith the consent of the data subject. Therefore, [15] apply security protection mechanismsto grant or revoke other entities the privilege of accessing data subject’s data. Derivedfrom the principles the model of classical authentication and authorization as described in[15] is a good starting point to create a privacy ontology. Security ontologies are anothergood starting point because security ontologies are highly abstract and based on secu-rity patterns as in [16]. Privacy ontologies should integrate such security principles andmechanisms to keep information under the control of the data’s subject. For instance, wemay use security mechanisms to authenticate individual to authorize him/her to access acertain resource.

2.1.2. Model Driven Engineering

Privacy requires the involvement of various aspects throughout the system life cycle. Forinstance, skills could concern specifications related to security, to the hardware platformdevelopment or to the maintenance of access rights.

During the application life cycle, the developers will analyse requirements, develop, andtest the system. Security has to be considered from the beginning of the applicationspecification states. In order to manage all privacy issues, model driven engineering(MDE) seems to be a good candidate. The MDE approach provides the following benefits:[17]

11.11.2010 IST-224201 8

Deliverable 16 1.0

• Abstraction. Currently, systems are very complex. The model driven approachprovides an abstract view of the system and presents a business vision view to anactor. The user can highlight relevant elements in a model. Same, it is possible toignore unnecessary details.

• Traceability. All stakeholders can use a same and unique model but with adaptedviews. This allows the propagation of requirements throughout the life cycle.

• Consistency. During the entire life cycle, consistency is ensured by using a com-mon model which can be checked by verification tools.

• Process guidance. It is possible to provide context sensitive help during the en-tire life cycle. Moreover, code generation and model transformation correspond topowerful tools which limit the design fault risk.

In this study, the state of the art survey will focus on model-based solutions with securityfeatures.

In [18], the authors specify a metamodel for an unified access control mechanism. Indeed,access control could be done through several standard mechanisms like RBAC (RoleBased Access Control) [19, 20], ORBAC (ORganization-Based Access Control) [21], orXACML (eXtensible Access Control Markup Language) [22]. The model presented hereis generic and could be mapped into all of these existing models. Then, it is possibleto declare software components and specify access control policies. This approach isindependent of the platform (PIM – Platform Independent Model) and, during the codegeneration, three targets (PSM – Platform Specific Model) are proposed. This solution isspecialized in only one dimension of trust.

The SecureUML profile [23] is another profile for access control. All concepts manipulatedin the profile are first defined in a metamodel. This profile is based on the RBAC modelwhich is hampered by the non-support of system condition rule definition. This is resolvedthanks to the definition of OCL (Object Constraint Language) [24] constraints.

Models can be used for specifying threats, vulnerabilities, and security risks. A UML profilefor security assessment, called SecurityAssessmentUML, is proposed in [25]. Comparedto the model-based framework proposed by the European IST CORAS project [26], thisprofile is supplemented by guidelines.

Finally, the UMLSec profile [27] is a main contribution for model-based security. UMLSecis an extension to UML and supports security as a non-functional property. Through sev-eral UML diagrams like use case, class and interaction, it is possible to specify securityrequirements.

Taking all these contributions into account, the state of the art proves that a model drivenapproach is a good way to specify security mechanisms. However, the mechanisms pro-posed in the state of the art cover only a small part of privacy. Access control mechanismsare not sufficient. For example, it is necessary to provide solutions to specify complexrules (i.e., retention time, context, etc.). The use of a data-centric approach seems bettersuited for privacy issues. In PRECIOSA, those modeling approaches (through MDE orontology) are adapted for privacy concern.

11.11.2010 IST-224201 9

Deliverable 16 1.0

2.2. Privacy Metrics

2.2.1. Metrics for location privacy

Metrics for location privacy aim to capture and reflect the levels of location privacy in cITSin a quantitative way. The ability to take the fuzzy concept of location privacy into rigorousmeasurement can help us to evaluate and verify cITS privacy at various levels. Moreimportantly, the progress in location privacy metrics can have significant contributions tothe privacy research community, because metrics for location privacy serve as

• a way of understanding the cause of the privacy problems

• methods of assessment of trustworthy systems with respect to privacy preservation

• tools for identification and analysis of privacy risks, threat, and vulnerabilities.

The same opinion is also shared by other experts in the community. For example, in arecent survey on location privacy, Krumm [28] pointed out that the progress in locationprivacy depends on the ability to quantify location privacy. However, there is neither astandard, nor a consensus between any two different research projects on the method ofquantification.

A review of location privacy and the related research issues appeared in our previous workin D4 [3]. Furthermore, in D2 [2], we have surveyed the related work on privacy metricsbefore we proposed our own work to address the issue. In the following, we provide aconcise summary of the related work in location privacy metrics.

The existing work on location privacy metrics can be roughly categorized into

• Anonymity set-based metrics. Anonymity and (un)linkability are two common ap-proaches to express user privacy in communication systems. A definition of thesetwo terms is given in [29] and unlinkability is further refined in [30]. The size of theanonymity set is a popular metric of anonymity. The authors of [31, 32] point out thatthe size of the anonymity set does not reflect different probabilities of the membersin an anonymity set, and propose to use entropy as the metric for anonymity.

• Mix zone-based metrics. Beresford et al. [33] point out that anonymity set fails tocapture user movements in wireless scenarios, and propose to use mix zones tomodel user mobility and apply entropy to quantify the information obtained by anadversary on the user movements through mix zones. Applying the same principle,the authors in [34] and [35] use the entropy provided by the mix zones to evaluatethe level of location privacy achieved by the vehicles in vehicular ad hoc networks(VANET).

• Tracking-based metrics. Tracking, which learns a vehicle’s movement by linking aseries of messages from that vehicle, is another common approach to measure lo-cation privacy. Gruteser et al. [36] propose to use tracking algorithms to characterizethe level of location privacy. Sampigethaya et al. [37] use maximum tracking timeto evaluate the location privacy of vehicles in VANET. Hoh et al. [38] use the mean

11.11.2010 IST-224201 10

Deliverable 16 1.0

time to confusion to measure the privacy level of vehicles sending GPS traces in atraffic monitoring system.

However, existing metrics are neither appropriate nor sufficient to capture and measurelocation privacy in cITS, because they are either designed and targeted for very differ-ent systems or only partially capture the whole picture. Therefore, new approaches andmethods are needed to address the issue.

2.2.2. Privacy metrics for data storage

Metrics for data storage try to quantify the amount of privacy in database releases. Es-pecially, when personal information is published, it is important to regard privacy issues.In Deliverable 4 [3] we investigated several privacy issues and presented related work. InDeliverable 2 [2] we introduced metrics which can be used in the data storage domain.

The most work in this field based on anonymity sets and especially on k-anonymity intro-duced by Sweeney [39]. Following her a database release satisfies k-anonymity if eachtuple cannot be distinguished from at least k−1 other tuples with respect to certain quasi-identifying attributes. A higher value of k results in a higher protection and is thereforea measure for privacy. Enhanced models like l-diversity [40], t-closeness [41], or (ε,m)-anonymity [42] measure also the distribution of personal data in the table. Other authorspropose entropy-based measurements like the loss of privacy [43].

2.3. Privacy-aware Analysis and Software Design

Privacy analysis should allow for the evaluation of privacy protection properties at designtime. Several different stakeholders perform privacy analysis. Consequently, every typeof stakeholder has its own perspective, purposes, and privacy criteria. The purposes ofthe privacy analysis may include setting up privacy requirements to define privacy con-formance system behaviour, evaluating systems to detect privacy leakages and to calcu-late metric values which serve as indicators for describing the privacy risk of using suchsystems, and checking whether an entity’s behaviour conforms to a given set of privacyrequirements (as verifying system conformance).

According to the Privacy Impact Assessment (PIA), the purpose of the privacy analysisprocess is to create privacy-aware design specifications. The PIA process takes the per-spective of legal authorities and project managers. The results of PIA are privacy require-ments that take into account privacy regulations, privacy laws, and project requirementsadapted to the application domain. These results are described at a conceptual levelwhich does not reflect technical interdependencies.

Formal methods for privacy analysis are mostly based on languages which describe tech-nical systems. The purpose is to provide a formal defined vocabulary to avoid ambiguity,to make domain assumptions explicit, to prove properties of a solution, and to explorethe design space. Different languages (mostly logic based) and mechanisms (e.g. model

11.11.2010 IST-224201 11

Deliverable 16 1.0

checking or system simulations) exist which can be used to provide (semi) automatic eval-uation and verification of systems. Technical privacy requirements involve system-specificproperties but often fail to integrate high-level privacy requirements that include privacyregulations or stakeholders’ interests. Further, systems are often to complex to verify itsconformance to given constraints on a detailed level.

In the following we present existing approaches of technical analysis based on formallanguages and afterwards we describe in more detail the Privacy Impact Assessment.

2.3.1. Privacy analysis

In this section we present an extract of Deliverable D13 [10] which describes existingapproaches of technical privacy analysis based on formal languages. The purpose of theanalysis are

• to specify the appropriate privacy requirements; e.g. formal privacy criteria in formof logical constraints or technical policy statements

• to check the conformance of systems regarding a set of privacy requirements; e.g.to verify systems by model checking

• to evaluate a system regarding privacy properties; e.g. to calculate the privacy riskor to detect privacy breaches of a system/application

In section 2.1 we introduced approaches to describe system behavior and requirementswith different perspectives at different levels of abstraction. Standard modeling languagesas UML and OWL have a formally defined semantics which defines how to interpret thelanguage statements. Thus, we can analyse the models based on logics. We applysuch analysis for model driven software/system engineering to evaluate how the designand the following implementation implement the stakeholders requirements. One com-plementary technology of MDE is Requirements Engineering (RE). Designers of sys-tems/applications apply requirement engineering technologies to adequately determineand define the needs and constraints of the envisioned system. One result of combin-ing model driven engineering and requirements engineering is a set of well defined re-quirements which tools can (semi)automatically analyse for evaluating or verifying systemrequirements.

Risk analysis

Privacy analysis may also adapt mechanisms of related research fields as security andrisk analysis. In the design phase of critical systems as safety systems risk analysis isconsidered during the whole system’s lifecycle. System designer identify and specify risksby considering technical aspects as failures of a system or vulnerabilities. Thereby, thedesigner reconsider the system requirements.

Risk analysis (as stated in [44]) uses and adapts mechanisms of Requirement Engineer-ing, Secure and Dependable Engineering, and others. In [44] the authors propose a

11.11.2010 IST-224201 12

Deliverable 16 1.0

goal-oriented approach for analyzing risks during the requirements analysis phase. [44]analyse risks along with stakeholder interests, and afterwards identify countermeasuresand introduce them as part of system’s requirements. The work of [44] relates and usesexisting work of Requirement Engineering, and Secure and Dependable Engineering.

Privacy requirements engineering

Besides functional and other non-functional application requirements as quality, perfor-mance and security we want to consider privacy requirements as well. Describing privacyrequirements at different levels of abstraction ease the step by step process to translatehigh level requirements into technical requirements. High level requirements might beprincipals, legal requirements, requirements derived from project management aspects,or even user preferences. Technical solutions implement/enforce the resulting techni-cal privacy requirements. At the technical level we can analyse and evaluate the solu-tions/implementations by using technical ((semi) automated) techniques and tools.

In [11] the authors describe some important concepts which we integrate in the designof the ontologies and languages (PPQL, P3L) of PRECIOSA. [11] presents a frameworkfor modeling privacy requirements in role engineering. Despite the fact that the approachof [11] is restricted to the application of Role Based Access Control (RBAC) the authorsdescribe a foundation which can be adapted to other privacy protection mechanisms aswell. To enforce security and privacy it’s essential to apply the specification of privacyrequirements in early stages of system development as the initial system design [45] [46][47]. Privacy policies are usually defined as high-level natural language descriptions byan organization’s privacy group which a Chief Privacy Officer (CPO) might chair.

Privacy policies describe organizations’ privacy practice for operating on personal infor-mation. Thereby, organizations need to ensure that the expressed commitment in theirprivacy policies reflects their actual business practices. Requirement engineers have tounderstand the privacy policies to know the privacy practices with which the software mustcomply. The expressed commitments of the privacy policies have to be incorporated intothe software requirements to build policy compliant software. To adequately integrate theprivacy requirements the engineers must incorporate privacy policy analysis into their re-quirements activities.

In [11] the authors use a role engineering process to bridge the gap between high-levelprivacy requirements and low-level access control policies. Goal-driven Requirements En-gineering [48] [49] employs goals (enhanced with descriptions of scenarios and purposes)to elicit, specify, analyse, and validate requirements. In [49] the authors identify seven im-portant goal-oriented methods. Before systems can technically enforce the required pri-vacy criteria in [11] we have to formalize the high-level privacy policies and requirementsinto authorization rules. Therefore, we identify the privacy protection elements and wemodel the technical privacy policies by applying the engineering process of [11]. Majorconcepts which refine the privacy protection elements are purpose, condition, obligation,and context. In the framework of [11] context definitions of policies are defined by object

11.11.2010 IST-224201 13

Deliverable 16 1.0

attributes. Thereby, context constraints define restrictions on the data purpose and privacypreferences as the recipient of data or the retention period of data.

Privacy attack analysis

Attack analysis is mostly used as part of the risk analysis. Thereby, we create a modelwhich describes the intentions and abilities of an attacker/adversary. Further, we use thismodel to calculate the probability of the execution of an attack and its success. Attacktrees [50][51] are an established method for modeling security threats. They have alreadybeen successfully utilized for the modeling of attacks on inter vehicle communication sys-tems [52]. The main idea of attack tree analysis is to choose an aim or motivation of anadversary and to identify potential attacks that can be mounted to achieve that goal, andfurther assess the likelihood of these attacks.

We use attack trees in Deliverable D7 [5] to analyze modeled architecture designs forpotential privacy breaches. Subsequently, the resulting attack trees are used to identifyappropriate points of control and observation (PCOs) which can be used for measurementand evaluation to assess the privacy level provided by a given architecture.

Formal privacy verification

The term privacy verification often describes the application of organizational measures toestablish privacy. Thereby, to verify privacy policies involves to test the people, processes,technology and control mechanisms to ensure that a company follows its stated privacypolicies. These organizational measures are performed on a conceptual level which doesnot reflect technical interdependencies. Thus, organizational measures does not providea reliable guarantee regarding the privacy conforming behaviour of systems.

The technical verification of systems can be performed by formal conformance verificationwhich provide an automated privacy policy verification. We can verify whole systems orparts of a system as its information flow and probabilistic system properties. Mechanismsas model checking [53] provide the formal conformance verification of systems. Modelchecking mechanisms process a model of a system and test automatically whether thismodel meets a given specification.

In Chapter 5 Opportunities and Challenges for Formal Methods of [54] the authors givea comprehensive overview about formal methods to model and evaluate privacy aspects.Therefore, we can use existing formal logics and formal languages

• to state different aspects of privacy

• to state desired properties of these systems

• to state privacy policies

• to reason about when a model satisfies a property or policy

• to detect inconsistencies between different privacy policies

11.11.2010 IST-224201 14

Deliverable 16 1.0

As mentioned before automated analysis and tools enable us to scale the applicabilityof these foundational models and logics to realistic systems. The authors argue thatprivacy does pose new challenges which require possibly new models, logics, languages,analysis, and tools. In Chapter 5 Opportunities and Challenges for Formal Methods of [54]the authors describe the following different aspects of formal methods: Models, Logics,Formal Policy Languages, Abstraction and Refinement, Policy Composition, Code-levelAnalysis, and Automated Tools. Furthermore, the authors describe the following privacyspecific needs: Statistical/Quantitative Reasoning and Trustworthy Computing: ConflictingRequirements.

In Deliverable D13 [10] we describe some research work to sketch the state of the art informal privacy analysis. We address the topics

• logic based framework to formally specify and reason about the implementation ofprivacy protection [55];

• formal framework for expressing privacy expectations and privacy practices [56];

• formal framework to deliver the individuals consent regarding the processing of itspersonal information [57];

• graph-transformation based framework to check whether an internal business pro-cess adheres to the organizations privacy policies [58];

• privacy notions, untraceability and forward privacy [59].

Ontology driven privacy analysis

In general formal verification mechanisms use a temporal logic to specify the verified con-straints. Such constraints are mostly not based on standardized concepts. Also theprocess to adequately create such constraints from high-level privacy policies is poorlyknown. Further, privacy protection mechanisms works best if they are configured/adaptedto the application domain. Therefore, the optimal privacy protection criteria has to bespecified domain specific. Also, we can provide solutions with a better balance betweenquality of service (e.g. may be influenced by preciseness of information) and degree ofprivacy (e.g. generalization of values). We may use techniques as described in Section2.1 to introduce a conceptualization which provides required features as

• to create models for different perspectives and domains,

• to create and integrate models which describe whole systems or parts of a system,

• to provide standardized vocabularies for defining appropriate privacy policies whichwe can reason about,

• to provide standardized vocabularies to describe system behaviour, side effects, andenvironments

11.11.2010 IST-224201 15

Deliverable 16 1.0

• to provide different degree of granularity to describe privacy policies (e.g. to specifya situation/system specific privacy policy or to specify a general privacy policy topermit the processing of information for a class of applications),

• to translate user privacy to technical privacy (formal language description) in a de-clarative manner based on logical concepts and axioms,

• to abstract from system specific properties while specifying formal privacy policies;

• to describe possibilities to derive (personal) information (to detect privacy leakagesor privacy violations) and to define rules for preventing those inferences,

• to address privacy attacks that utilize semantic technologies, background knowl-edge, or data mining techniques.

Therefore, we have to introduce a conceptualization in form of models, metamodels,and/or ontologies of the privacy domain and its application domains.

In research authors already combined disciplines of software engineering with ontologies(see chapter V.1 [12]). In [13] the authors present a framework which supports ontologybased requirements engineering to predict, control and evolve systems behavior. Thereby,they integrate various RE modeling techniques with complementary semantics in a uni-fying ontological engineering process. In [14] the authors show how to integrate someontology based analysis into a software design process. Thereby, the authors translateUML system models into an OWL representation, take user specified requirements andreason about some software ontologies to calculate a solution which implements the spec-ified requirements.

2.3.2. Privacy by Design

Ann Cavoukian is the pionneer of privacy by design (PbD). She has written a white pa-per defining the ideas and principles of PbD12. In the white book, she also explains theconcept of PETs (Privacy-Enhancing Technologies). A PET refers to a coherent informa-tion system which protects individual’s private life. For this, it is necessary to follow theseprinciples:

• Minimizes the unnecessary disclosure, collection, retention and use of personaldata.

• Empowers individuals to participate in the management of their own personal data.

• Enhances the security of personal data, wherever collected and used.

• Promotes public confidence and trust in data governance structures.

• Helps to promote and facilitate widespread adoption of the technology.

1http://www.privacybydesign.ca2http://www.ipc.on.ca/english/Home-Page

11.11.2010 IST-224201 16

Deliverable 16 1.0

The initiative is interesting, but the approach is informal and is only at the requirementlevel. It seems essential to provide a methodology taking into account the overall applica-tion lifecycle. In D11, PRECIOSA provides first steps working on this issue.

2.4. Privacy-enhanced Policy Languages

An important service for helping users to keep the control over their personal informationis represented by access control solutions enriched with the ability of supporting privacyrequirements. In general, such access control policies specify the following elements:

• Who – user identities or roles

• What – resources or data

• How – actions

• Why – purpose and context

• Conditions – under which allowed or denied

• Obligations – if allowed or denied

In Deliverable 6 [4] we introduce several privacy policy languages. In this section we sum-marize their most important features and show some of their drawbacks. In PRECIOSAwe developed our own policy language which is called PRECIOSA Privacy Policy Lan-guage (P3L) and is presented in Section 3.4.1. An overview of a lot of policy languageswith their current status can be found at W3C on http://www.w3.org/Policy/pling/

wiki/PolicyLangReview.

2.4.1. Platform for Privacy Preferences (P3P) and A P3P PreferenceExchange Language (APPEL)

The Platform for Privacy Preferences (P3P) Project [60] enables Websites to express theirprivacy practices in a standard format that can be retrieved automatically and interpretedeasily by user agents. P3P user agents will allow users to be informed of site practices (inboth machine- and human-readable formats) and to automate decision-making based onthese practices when appropriate. Thus, users need not read the privacy policies at everysite they visit. But P3P does not provide a technical mechanism for making sure that sitesact according to their policies.

With the help of A P3P Preference Exchange Language (APPEL) [61] users can describecollections of preferences regarding P3P policies between P3P agents. Then, user agentscompare privacy preferences of users with P3P policies of a service and decide automat-ically whether to use a service or not.

Ashley [62] and Agrawal et al. [63] provided implementations of enforcement of P3Ppolicies which is introduced in Chapter 2.5.3.

11.11.2010 IST-224201 17

Deliverable 16 1.0

2.4.2. Extensible Access Control Markup Language (XACML)

Extensible Access Control Markup Language (XACML) [22], which is the result of OASISstandardization effort, proposes an XML-based language to express and interchange ac-cess control policies. In addition to the language, XACML defines both architecture for theevaluation of policies and a communication protocol for message exchange.

Scenario

In a typically scenario a user wants to perform some action on a resource. Therefore, heissues a request to the device protecting the resource which is called Policy EnforcementPoint (PEP). The PEP creates a request which consists of four attributes.

• Subjects (or users) making the request

• Resource being accessed

• Action to be performed on the resource

• Environment which is additional information related to the request

The PEP sends this request to the Policy Decision Point (PDP) which processes the re-quest by looking for some policy that applies. It sends the answer back to the PEP whichpermits or denies access to the user.

Architecture

XACML defines four layers to access policy control.

• Policy Administration Point (PAP): creates security policies and stores these policiesin the appropriate repository

• Policy Enforcement Point (PEP): performs access control by making decision re-quests and enforcing authorization decisions

• Policy Information Point (PIP): serves as the source of attribute values, or the datarequired for policy evaluation

• Policy Decision Point (PDP): evaluates the applicable policy and renders an autho-rization decision

11.11.2010 IST-224201 18

Deliverable 16 1.0XACMLArchitecture (2)Architecture (2)

PEPPolicy Enforcement Point Obligation Service

1. Access Request

7 Permits or denies access

7. Obligations

2. XACML Request 6. Return response context

7. Permits or denies access

User

qwith attributes

3 Request attributes

p(authorization decision)

0. Make policies available3. Request attributes

4. Return Attributes5. Evaluate Policies

PDPPolicy Decision Point

PIPPolicy Information Point

PAPPolicy Access Point

ResourceS bj t

14

SubjectEnvironment

Figure 2.1.: XACML architecture (simplified)

Elements of the policy

Elements of XACML are policies or policy sets, combining algorithms, obligations, targets,rules, attributes, attribute values, functions, and effects. An XACML policy represents asingle access control policy, expressed through a set of rules. It contains a single target,0 or more rules, 0 or more obligations, and a rule combining algorithm.

Each combining algorithm represents a different way of combining multiple decisions intoa single decision in case of different access control decisions through multiple policies orrules. There are seven standard algorithms, for examples the deny overrides algorithmwhich effects that if any evaluation of a rule returns deny, then the final result is also deny.Users can develop own algorithms.

Obligations will be passed back in the response from the PDP. There are additional op-erations which the PEP should perform when enforcing the authorization decision (e.g.,provide notification to a customer after a wire-transfer operation has been performed bythe bank).

A Target is a set of conditions that must be met for a policy or rule to apply to a givenrequest. There are conditions for a subject, a resource, and an action.

11.11.2010 IST-224201 19

Deliverable 16 1.0

If a policy were found, which applies to a request, rules are evaluated. Each of them mayhave one condition. If this condition evaluates to true, then the rule’s effect is returned(permit or deny).

Attributes are properties of the subject, resource, action, or environment in which theaccess request is made. Attributes in request will be compared to attribute values in apolicy to make an access decisions.

Making an access decision, when a set of attribute values needs to be compared to ex-pected values, is a complex task that needs a powerful system of functions. Functionsmay work on any combination of attribute values, and may return any kind of attributevalue supported in the system.

Privacy Profile

Since version 2.0 there has been the possibility to use profiles which are kinds of guide-lines for the formulation of policies and specify the use of XACML in specific scenarios.The goal is the use standard elements, attributes, and functions, and therefore to preventerrors, because all aspects of the scenario are regarded. One predefined profile is theprivacy policy profile. It adds two values for the specification of a purpose for which thedata was collected and for which an access to the data is requested.

2.4.3. PRIME Policy Language

Overview

The PRIME project [64] is a large-scale research effort aimed at developing an identitymanagement system able to protect user personal information and to provide a frame-work that can be smoothly integrated with current architectures and online services. Inthis context an important service for helping users to keep control over their personal in-formation is represented by access control solutions enriched with the ability to supportprivacy requirements. To fully address the requirements posed by a privacy-aware accesscontrol system, the following different types of privacy policies have been defined in thecontext of PRIME.

• Access policies define authorization rules concerning access to data or services.

• Release policies govern release of properties, credentials, or personally identifiableinformation (PII) of the party and specify under which conditions they can be re-leased.

• Data handling policies (DHP) regulate how personally identifiable information (PII)will be handled at the receiving parties. Users can define restrictions on the sec-ondary use of their personal information which will be attached to the PII or datathey protect.

11.11.2010 IST-224201 20

Deliverable 16 1.0

All of the policies mentioned before allow the definition of powerful and expressive accesscontrol languages, but they do not regulate the use of personal information in secondaryapplications. A first approach to solve this problem is the notion of PRIME data handlingpolicies (DHP), which impacted the development of PRECIOSA policy language. In thenext sections we present the concept of DHP in a more detailed way.

Requirements

The data handling policy follows the data when they are manipulated by different applica-tions and transferred between different systems. A data handling policy should be simpleand expressive enough to support the following privacy requirements [65].

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

• Consent. Users should be able to give their explicit consent on how to use theirpersonal data.

• Correction. Users should be able to access their personal information to modify itwhen needed.

• Security. Adequate security mechanisms have to be applied, according to the sen-sitivity of the data collected.

Elements of the data handling policy

A data handling policy regulate which subject can execute which actions on which re-sources under which conditions. Because of being tagged to a resource, the PRIME datahandling policy consists of three elements: recipient, action, restriction [65].

• Recipient. That is the third party to which personal information can be disclosed. Itcan be defined by an identity, a category or attributes.

• Action. The term action is used to denote privacy-relevant operations that recipientscan require on personal data (e.g., read, disclose, modify).

• Restrictions. A privacy statement specifies restrictions that have to be satisfied be-fore access to data is granted. Restriction can be divided into the purpose, for whichthe data will be used, and conditions. We distinguish between three kinds of con-ditions: provisions, obligations, and generic conditions. Provisions are actions thathave to be performed before access can be granted. Obligations represent actionsthat have to be performed after access has been granted. In addition, generic con-ditions can be satisfied at run-time when the request is processed.

11.11.2010 IST-224201 21

Deliverable 16 1.0

Syntax

The PRIME data handling policy has the following form:

<recipients>

CAN <actions> FOR <purposes> ON <PII>

[IF <gen_conditions>]

[PROVIDED <provisions>]

[FOLLOW <obligations>]

A data handling policy specifies that recipients can execute actions on PII for the pur-pose provided that the provisions are satisfied, gen_conditions (generic conditions) aresatisfied, and with obligations.

2.4.4. Drawbacks of existing languages

Although there are important contributions made by P3P, XACML, PRIME, and other ap-proaches, they have some drawbacks or they lack features. One of the most essentialfeatures of the PRECIOSA approach is the concept of data handling policies which followthe data when it is released. Therefore, the starting point policy for our approach was thePRIME policy. Drawbacks of the PRIME approach and other languages are the following[66]:

• Matching. PRIME data handling solution does not provide an automatic mechanismto match preferences of the user and privacy policies of the server.

• Secondary use. PRIME provides a simple solution to secondary use, where datahandling policies are attached to the data and follow them for the entire lifecycle. Nofurther customizations based on the chain of releases are possible.

• Aggregation and anonymization. Policy languages permit or deny access on data. Afundamental property in the field of privacy is that revealing data can violate privacybut revealing an anonymized or aggregated form of this data does not. That coursesthe need for a mechanism to specify the access in more detailed way, for example,allow to access an anonymized version of data.

2.5. Privacy-aware Request Processing

The sources for breaches of privacy are manifold. In particular, besides having access tothe original data which might contain personal data that must be protected we must alsofocus on how data is processed when answering (ordinary) queries and how data couldbe related (combined) in such a way that inferences become possible to leak personalinformation. Furthermore, there are many examples and cases where mining techniques

11.11.2010 IST-224201 22

Deliverable 16 1.0

Name Zipcode Age Location SpeedAllen 11000 21 Amsterdam 30Ben 11000 22 Berlin 30Clark 13000 22 Chicago 35Debra 14000 24 Dublin 50Elaine 14000 25 Edmonton 40Fiona 16000 26 Florence 30Gary 17000 26 Geneva 50Henry 19000 28 Hong Kong 50Ian 19000 29 Innsbruck 60

Table 2.1.: Running example

allow adversaries to recover information that was protected either with certainty or with aprobability of being certain.

Furthermore, several approaches have been developed to detect intrusions into a systemor the violation of privacy “after the fact” (i.e. at a later point in time) by examining (mining)log or auditing data that was collected during the access of data of the execution of pro-grams. The approach in PRECIOSA, however, is to prevent privacy leakage and privacyintrusion “from the very beginning”. That is the focusa of PRECIOSA is the developmentof concepts and techniques that do not allow such leakages or intrusions to happen atall.

In the following, we first discuss different approaches to protect privacy by anonymizingdata in various ways. Most of those approaches on storage privacy have been developin the database context. Similarly, there has been a wide range of work in the geospatialcommunity on how to protect location privacy. We survey some of that work as well.For the PRECIOSA project it became clear very early during the project that individualparticipants, such as car drivers or car passengers, should be able to influence the way thedata that describe individual personal aspects should be handled. That is, these personsshould be able to express their privacy preferences in a clear and powerful manner. Wetherefore analyze some of the policy languages of Chapter 2.4 in terms of processing.

2.5.1. Storage Privacy

Privacy preservation has received a high attention from the database community in thepast few year. Organizations often need to publish datasets, for example, medical dataor location data, for research and other purposes. The data holders itself are responsiblethat the released information does not affect privacy. Not releasing some information atall may reduce the need for the data, while on the other hand, failing to provide properprotection within a release may harm the privacy of others.

In this subsection we use a running example presented in Table 2.1 which shows a set ofindividuals given by their names, zipcode, ages, and some privacy related information like

11.11.2010 IST-224201 23

Deliverable 16 1.0

Zipcode Age Location Speed11–13000 21–22 Amsterdam 3011–13000 21–22 Berlin 3011–13000 21–22 Chicago 3514–16000 24–26 Dublin 5014–16000 24–26 Edmonton 4014–16000 24–26 Florence 3017–19000 26–29 Geneva 5017–19000 26–29 Hong Kong 5017–19000 26–29 Innsbruck 60

Table 2.2.: 3-anonymous table

their current location and speed. Adversaries may not draw conclusions between peopleand their location or speed. So, the anonymity of these individuals should be preserved.

The first approach in order to protect published data was to remove all identifying attributesin the release. But Sweeney [39] showed that with the help of external data some individ-uals still can be identified. The problem was that a set of other attributes could be usedto identify individuals of the original data table. We call these attributes quasi-identifier(QI). In Table 2.1 attribute “Name” is identifying and attributes “Zipcode” and “Age” are thequasi-identifier.

There are different anonymization principles in the literature like k-anonymity, l-diversity,t-closeness and different variants. A short overview can be found in [42] and [67]. In thenext subsection we briefly introduce the main important concepts. The first three principleswere already introduced in Deliverable [3], so we only show a compact form here. Thelater principles represents newer research results.

k-Anonymity

The first anonymization principle in the literature was introduced by Sweeney [39]. Herintension was to solve the identity disclosure problem, that is, individuals should not belinked to particular records in a released table. Therefore, tuples cannot be identifieduniquely. A table satisfies k-anonymity if for every tuple there exist at least k−1 other tupleswhich share the same values in all quasi-identifiers. Even if an observer knows the QIattributes of an individual, it is indistinguishable from at least k−1 tuples which decreasesthe matching probability to 1/k. Such a set of tuples is called QI-group. Many algorithmsare developed that compute k-anonymous release tables to a given k [68, 69, 70, 71].

In order to achieve an anonymization, attribute values of QI are generalized, that is, theyare replaced with a less specific but semantically consistent value (e.g., a set or a rangeof values). Table 2.2 shows a 3-anomyous release version of Table 2.1. More detailson k-anonymity, generalization methods, and theoretical observations can be found inDeliverable 4 [3].

11.11.2010 IST-224201 24

Deliverable 16 1.0

l-Diversity

Although k-anonymity protects against identity disclosure, it does not prevent sensitiveattribute disclosure because it does not place any constraint on the sensitive attribute val-ues. For instance, if all tuples in a QI-group share the same sensitive value, an adversarywho can conclude that a tuple of a certain individual is in this group learns his sensitivevalue. This lack of diversity in the sensitive attribute values of a QI-group led to the prin-ciple of l-diversity proposed by Machanavajjhala et al. [40]. A table satisfies l-diversity ifevery QI-group has at least l “well-represented” values for the sensitive attribute.

But this do not state what “well-represented” means. The simplest understanding of whatthis means is called distinct l-diversity and demands that there are at least l distinct valuesfor the sensitive attribute in each QI-group. According to this, Table 2.2 is 2-divers withrespect to attribute “Speed” because in the first and last QI-group there are 2 distinctvalues. This table is 3-divers regarding attribute “Location” because in each QI-groupthere are exactly 3 distinct values. Machanavajjhala et al. gave more interpretations of l-diversity like entropy-l-diversity which restricts the entropy of the sensitive attribute valuesand recursive (c, l)-diversity which limits the occurrence of the most frequent sensitivevalue [40]. More details are presented in Deliverable 4 [3].

There are other similar approaches in the literature, which solve the limitations of k-anonymity. Truta and Vinay [72] proposed p-sensitive k-anonymity which demands inaddition to k-anonymity that the the number of distinct values for each sensitive attributeis at least p in each QI-group (rf. distinct l-diversity). Another principle, called (α, k)-anonymity, was developed by Wong et al. [73]. Combining k-anonymity and l-diversity,(α, k)-anonymity dictates that, in every QI-group, there are at least k-tuples, and at mostα-percent of the tuples carry an identical SA value. On the other hand, m-invariance [74]introduced by Xiao and Tao is a principle originally proposed for re-publication of the mi-crodata, after it has been updated with insertions and deletions. It is a stringent version ofl-diversity. Specifically, it requires that each QI-group should have at least m tuples, all ofwhich must have different SA-values.

t-Closeness

l-Diversity presents a significant method beyond k-anonymity in protecting against at-tribute disclosure. But it also has some shortcomings. For instance, if a QI-group hasdistinct but numerical or semantical similar values potential adversaries can draw privacyviolating conclusion. In the first QI-group of Table 2.2 there are two distinct values forattribute “Speed” 30 and 35. An adversary who knows Ben’s Zipcode and Age can con-clude that one tuple in the first QI-group corresponds to him and therefore his speed isvery low (related to other speed values). This information gain is caused by the differencebetween the distribution of sensitive values in a QI-group and the distribution of valuesin the hole release Table 2.2. To solve this problem, Li et al. [41] proposed t-closenesswhich bound this difference. A table is said to have t-closeness if for each QI-group thedistance between the distribution of a sensitive attribute in this group and the distribution

11.11.2010 IST-224201 25

Deliverable 16 1.0

of the attribute in the whole table is no more than a threshold t. This distance is measuredusing the Earth Mover’s Distance (EMD) [75]. Because of being very technical we refer to[41] and Deliverable 4 [3] for detailed information.

(k, e)-Anonymity

A simple anonymization principle for numeric sensitive values is (k, e)-anonymity proposedby Zhang et al. [76]. They consider the range of numerical values of each QI-group. Atable satisfies (k, e)-anonymity if each QI-group has at least k different senstive attributevalues (distinct l-diversity) and the range of sensitive attribute values is not less that e. Fol-lowing this definition Table 2.2 satisfies (2, 5)-anonymity with respect to attribute “Speed”because in the first QI-group there a two different values with the range of 35 − 30 = 5.Problems of this approach occur if a QI-group of size k with k− 1 tuples have nearly iden-tical sensitive values, and the remaining tuples carries a faraway sensitive value to satisfythe requirement posed by e. In this example, adversaries can conclude the approximatevalue for any of the first k − 1 tuples with a high probability.

(ε,m)-Anonymity

Li et al. [42] consider a new attack called proximity breach. That is a privacy threatspecific to numerical sensitive attributes. It occurs when an adversary concludes withhigh confidence that the sensitive value of a victim individual must fall in a short interval.The goal of (ε,m)-anonymity is to eliminate the proximity breach. The idea is that in eachQI-group G and each sensitive value s at most 1/m of all tuples in G can have sensitivevalues “similar” to s. This “similarity” is quantified by the parameter ε. The authors gavetwo interpretations. Absolute (ε,m)-anonymity defines that two values x and y are similar,if their absolute difference is at most ε, that is, |y − x| ≤ ε. Relative (ε,m)-anonymity saysthat y is similar to x, if |y − x| ≤ ε · x. For instance, the first QI-group of Table 2.2 is(4.9, 2/3)-anonymous regarding sensitive attribute “Speed” because for the value 30 thereis only one other value 30 in the absolute range [30 − 4.9; 30 + 4.9] = [25.1; 34.9] andtherefore the portion of similar values is 2/3. For the value 35 there is no other similarvalue in its corresponding range (portion 1/3 ≤ 2/3).

Computing an absolute or relative (ε,m)-anonymous release table is quite difficult and canbe found in [42].

(αi, βi)-Closeness

(αi, βi)-Closeness is a combination of (α, k)-anonymity [73] and t-closeness [41]. Frikkenand Zhang [67] motivated their approach with some shortcomings of t-closeness. Theygave several example to show that the value of t can have different meanings in differentcontexts. Thus, it is non-trivial to determine what value t needs to be to prevent certaintypes of disclosures.

11.11.2010 IST-224201 26

Deliverable 16 1.0

The main idea of (αi, βi)-closeness is as follows: each sensitive value si in the domain ofthe sensitive attribute is associated with a range [αi, βi]. A particular QI-group is accept-able if the proportion of tuples in the QI-groups with sensitive value si (i.e., the number oftuples with si in the QI-group divided by the number of tuples in QI-group) is in the range[αi, βi]. A table satisfies (αi, βi)-closeness if for all QI-groups and all sensitive values sithis condition is fulfilled.

2.5.2. Query Processing on Location Data

Since the publication of k-anonymity there has been lots of efforts to develop various pri-vacy protecting measures and to include those into systems. One major field of interest ofthe PRECIOSA project are location-aware systems. A short overview of existing literatureof such systems can be found in [77] and will be presented in this section.

For the purpose of ICT, we emphasize that new concepts and implementations for protect-ing privacy have rapidly emerged in the areas of communication by using Chaum Mixes[78] or Onion Routing [79], and by using refined definitions of k-anonymity in databasesystems [39] [40] [41].

For the current context we focus on concepts and systems that appear in the context oflocation-aware systems. Many research efforts have focused on spatial-temporal queryprocessing in (extended) relational database systems and the handling of moving objectsby appropriate storage methods, query extensions and query processing frameworks, re-spectively. In both areas there is a large body of literature, all of which is relevant forlocation based systems.

Early approaches of handling privacy in location-aware systems were based on the idea ofk-anonymization. Based on the user or system preference for the value of k the location-aware system would return an area (mostly a square like area) as the user’s locationwhich (s)he shares with k-1 other users (i.e. contains the location of k-1 other users). Theadvantage of this approach is its easy implementation using existing spatial data struc-tures or indexes like the quad tree. The idea of cloaking by grouping one’s own locationwith those of others has been used by several authors, i.e. for example by Gruteser andGrunwald [80], Chow, Mokebel, and Liu [81] and others [82]; it raises the important ques-tion how to manage the trade-off between preciseness of location information and thenecessary level of anonymization to protect the user’s privacy. Obviously, the precise-ness of the user’s location information is dependent on the number of other users aroundhim/her thus impacting the usefulness of the location information for many location-awaresystems. For example, when using a recommender system for restaurants or interestingplaces to visit, the user might be willing to tolerate some “fuzziness” in the result to protecthis/her precise location (and therefore his privacy) as it might not impact the quality of therecommendations. However, for handling accidents involving cars or users the precise lo-cation information is important for providing immediate help to injured individuals possiblydeciding about their lives or their deaths.

However, while the previous examples protect the data, it is equally important to protectthe query – or better the user sending a query – from privacy breaches as well. For

11.11.2010 IST-224201 27

Deliverable 16 1.0

example when using a recommender system, it is important to know the user’s currentlocation; therefore it is often essential to send exact location information to the servertogether with the request for computing and returning a correct result. Besides knowingwho sent the request (even this information might be necessary to disguise) we might usethe same approach as described before. Instead of sending the exact location the usermight send to the service an “approximate” location by sending some areal informationthat contains the user’s location.

Although this approach might potentially suffer a loss of accuracy regarding the result,Mokbel, Chow, and Aref show in their New Casper system, that the right level of coopera-tion between the client and the server generates exact (location based) results for the userdespite areal (i.e. anonymized location) information sent to the server to protect his/herlocation privacy [83]. That is, fuzzy local information does not automatically imply a lossof quality on the result. Their approach is to implement a privacy-aware query processorthat generates an approximate result set containing all valid answers for a user submittedquery. Based on the exact location information which is only known on the client system,a post-processing step (implemented either on the user device or by some middlewarerunning at some trust site) filters out those result items that were returned due to the im-precise local information and thus do not belong to the answer for the user. For example,if the user asks for the nearest gas station, the server returns a set of potential gas sta-tions based on the areal information; the post-processing step then selects the correctone among all returned results based on the exact user location.

The New Caspar system uses geometric properties to handle private queries over publicdata, public queries over private data, and private queries over private data thus generat-ing same results as without privacy measures. At the same time, the New Caspar systemtakes into account privacy profiles specified by the user [83]. The authors developed theirsystem further resulting in the TinyCaspar which serves as a platform for generating alarmevents based on individuals’ location information without revealing those [84].

Other alternative approaches to protect the user’s location privacy are based on hidingthe user’s identity [85] [33], by adding dummy location (i.e. location values for non-existingusers) [86] [87] [88], or by transforming location data into an alternative space by a one-way function and answering queries in the transformed space [89].

Based on these different basic approaches several more complete systems have emergedwhose goal is to implement a more complete and a more comprehensive solution to theproblem of privacy in location-aware systems. The PAM system by Hu, Xu, and Lee allowsto track as set of moving objects efficiently and precisely at the same time respectingthe privacy requirements for those moving objects (if those represent people) [90]. Thesystem requires knowing the queries in advance to allow the computation of so called safeareas. As long as the moving objects do not leave safe areas, the system does not have torecompute the answer to any of the (pre-registered) queries thus reducing the executioneffort without compromising the quality of the answer.

11.11.2010 IST-224201 28

Deliverable 16 1.0

2.5.3. Policy driven processing

In Deliverable D6 [4] we discussed aspects of policies and policy languages from a mod-eling point of view as well as a classification point of view. We extend the discussion byfirst introducing various classification schemes before focus on various areas were policylanguages are defined and where policies are used. We then provide a brief overviewon policy processing in general before focusing on privacy policies. We conclude that theidea of coupling data access and policy evaluation for privacy protection is novel as it willbe described in the following chapter.

We first focus on various classification aspects of policy languages regarding the rela-tionship between the user and the entities to be protected, the granularity of protection,and the expressiveness of the language. Regarding the relationship between users andentities we distinguish at least three different classes according to Latham [91]:

• A Discretionary Access Control (DAC) model distinguishes between users and(named) objects. Additionally, there exists a mechanism that allows users to propa-gate access rights on objects to other users or user groups with the ability to restrictthe propagation rights for further propagation. Users who do not own access rightsto an object cannot access it. The granularity of the access rights in general is deter-mined by the object domain. However it should be possible to refine access rights,i.e. to restrict the access to finer grain (sub-) objects. Only users who own accessrights can propagate those to other users. An example for a DAC is the accessmodel of the UNIX file system.

• A Mandatory Access Control (MAC) model describes every object and every userby some assigned access guidelines possibly including a (hierarchical) classificationsystem with respect to different security levels. Those levels determine which useris allowed to access which objects. Only users on the same or higher classificationlevel than the classification of the object are allowed to access the object. Usersmust be uniquely identified by the (access control) system to ensure that a user isassociated with the correct access privileges. They cannot propagate rights to otherusers; only an administrator can changes the access privileges of the access levelof an object in order to change access rights.

• Compared to the previous two classes a Role-Based Access Control (RBAC)model does not distinguish between users, rather the concept of a role determinesthe access rights to objects. Users are assigned roles; those might change overtime (and therefore the right to access objects might change). In many case, a role(rather than a user) as a more natural approach for attaching access rights. Accessrights are exclusively determined by the role and not by the user. In many ways theRBAC model is a simplified form of the MAC model that usually does not dependon hierarchies of rights or privileges. However, composing roles or deriving roles forexisting ones might be possible [92].

An orthogonal classification of policies is related to the granularity for access control orprotection. Using the Relational Model as the basis for comparison we might distinguishthe following levels of granularity:

11.11.2010 IST-224201 29

Deliverable 16 1.0

• The smallest granule for defining access or protection rights is an individual (at-tribute) value of a tuple. The fine grain specification gives the highest flexibility, butit is doubtful that such a fine grain specification scales to billions of values.

• Using a tuple as the smallest entity for defining policies still provides a fine grainaccess or protection mechanism. Still, in a context of billions of tuples it might bea challenge to store and process such a large number of accesses or protectionspecifications.

• An attribute based access or protection mechanism controls all values of a (table)attribute (column) thus making it much more amenable to scalability, at the sametime loosing fine grain control when compared to the previous two alternatives.

• Similarly, an individual tuple could also be the smallest (atomic) unit for specifyingaccess or protection privileges. This granule again represents a trade-off betweensize and scalability.

• A schema based granule allows the user to group attributes to provide access con-trol or protection specifications for all of those attributes.

• Similarly, a table based granule allows to provide access control or protection spec-ifications to the set of all tuples. If flexible enough, conditions could identify subsetsof tuples to which those access control or protection specifications should apply.

For scalability reasons the last two alternatives seems to be most amenable for providingaccess control or protection on a scalable basis. However, it also requires sophisticatedmechanisms to detect contradictions for overlapping set of tuples - if complex enoughsuch decision might be quite expensive from a computational complexity point of view.

In [93] De Coi and Olmedilla list important criteria that any policy language got trust man-agement, security, and privacy should satisfy. They require

• a well-defined semantics for the language,

• language monotonicity in the sense of logic: the result set decreases in size ratherthan increases by adding new policies,

• condition expressiveness: allowing specifying conditions under which the request ofthe user should be accomplished,

• a well defined formal bases: such a formal bases should allow the user or system tomake inferences over (a set of) policies reliably and independently of any user.

This minimal set of requirements has been important to design the policy language inPRECIOSA. Furthermore, the article by Anton, Bertino, Li, and Yu on the “A Roadmap forcomprehensive Online Privacy Policy Management” provides a comprehensive architec-tural framework that supports the privacy policy life cycle [94]. The paper provides somegeneral guidelines than have been included into our approach; however the approachtaken in PRECIOSA goes far beyond the vision and recommendations of that paper.

The literature provides limited descriptions and evaluation on how to enforce privacy poli-cies in general. One of the few exception is the work by Agrawal, Kiernan, Srikant, and

11.11.2010 IST-224201 30

Deliverable 16 1.0

Xu who describe their implementation for evaluating P3P policies in detail [63] using adatabase oriented approach. Ashley provides a more pragmatic description of the prod-uct architecture for enforcing P3P privacy statements within the IBM TIVOLI managementsystem [95]. In the following we give a more comprehensive description of their approachbased on [63].

As already described in Deliverable D6 [4], the P3P protocol has two parts:

• the P3P Privacy Policies language that allows a web site to encode its data-collectionand data-use practices in an XML format;

• the APPEL Privacy Preferences language which allows a user to express his/herpreferences that can be programmatically compared against privacy policies at agiven web site.

The authors propose a “server-centric architecture” for deploying and checking P3P pri-vacy statement against user preferences. All three different alternatives for implementa-tion convert P3P policies into data stored in the database (either in relational tables oras XML documents) while the user’s privacy preferences expressed in APPEL are trans-formed into queries – either SQL queries or XQuery queries. Such an approach puts theburden on determining a match on the DBMS by returning the P3P privacy policy state-ments for a give APPEL privacy preference. They design a specific database schemafor storing P3P statements and a transformation algorithm for transforming individual pri-vacy preferences into specific SQL/XQuery queries (over the given schema). Variousexperiments on a small set of P3P policy sets and privacy preferences confirm that policystatements and preference statements can be matched in reasonable time. However, dueto the publication year of the paper and the small size of preferences and polices it isunclear how well this approach scales to today’s data sets.

The work by Agrawal, Kiernan, Srikant, and Xu solely focuses on policy matching. In theoverall architecture the evaluation of policies and preferences is completely decoupledfrom the access to the data. The work does not take into account any malicious behaviorby an intruder or any attacks to circumvent the existing privacy protection mechanisms,nor does it pay attention how to treat data and its metadata as one unit as far as privacyis concerned. On the other hand, the approach described was the basis to implement anappropriate component into the IBM TIVOLI management system [95].

If we assume that queries and privacy policies should be evaluated together there existtwo major architectural approaches. The first one – as suggested and implemented byAgrawal, Kiernan, Srikant, and Xu – adds a policy evaluation component “on-top” to anexisting Database Management System ensuring that data is access and returned accord-ing to specified policies only (see left figure in Figure 2.2). The architecture as describedin [63] follows this approach.

Such “on-top” extension of an existing DBMS provides an easy solution since the databaseengine is not changed at all. The policy evaluation engine play the role of a “gate keeper”allowing only those data items to be returned that do not violate the given policies. How-ever, it might be necessary to synchronize the data returned by the query and the data

11.11.2010 IST-224201 31

Deliverable 16 1.0

DBMS(Query evaluation)

SecureStorage

PolicyEvaluation

Component

Query & Policies

Query

SecureStorage

QueryEvaluation

Component

Query & Policies

Query

PolicyEvaluation

Component

Policies

Figure 2.2.: On-top and Inside Evaluation of Privacy Policies

needed to evaluate policies which increases the complexity of evaluating queries and poli-cies in a synchronous manner.

Alternatively, a tighter integration and synchronizytion between query evaluation and pol-icy evaluation could simplify the overall execution. That is, by extending the query pro-cessing engine of a DBMS by a policy evaluation component inside the DBMS it shouldbe possible to evaulate both queries and policies in a stepwise and synchronous mannerfiltering out data elements or transforming data elements according to specified policies.The right figure in Figure 2.2 shows the alternative approach which we follow in the PRE-CIOSA work.

In general, the second approach requires access to the internals of a database systemwhich may be impossible for some commercial database products. Even if database ven-dors implement such an approach it might be necessary to verify and to certify such asystem to guarantee its correct processing and behavior.

2.6. Privacy-aware Communication

In recent years many privacy approaches for inter-vehicular networks and cITS havebeen proposed. In the following Sections we discuss salient solutions from different cate-gories:

• Pseudonyms

11.11.2010 IST-224201 32

Deliverable 16 1.0

• Symmetric encryption

• Group signatures

• Identity-based crytography

2.6.1. Pseudonyms

In the context of vehicular networks, pseudonyms refer to pseudonymous public key cer-tificates. These certificates do not contain any identifiable information and cannot belinked to a particular user or to another pseudonymous certificate. Vehicles are equippedwith pseudonyms and their corresponding secret keys. When sending a message, a ve-hicle signs it with its secret key and attaches the signature and the pseudonym certificateto the message so that receivers can verify the signature. Vehicles also have to changepseudonyms often to make it hard for an attacker to link different messages from the samesender.

In the SeVeCom project [96, 97] pseudonyms are employed to provide security and pri-vacy. A hierarchical CA structure is proposed, in which CAs manage and issue long-termidentities to vehicles. Pseudonyms are issued by pseudonym providers (PP) and are onlyvalid for a short period of time. When issuing pseudonyms, a PP authenticates a vehicleby its long-term identity. The vehicle receives a set of pseudonym certificates and storesthe corresponding secret keys in a Hardware Security Module (HSM), which is tamper-resistant to restrict the parallel usage of pseudonyms.

If accountability is desired, a PP can retain pseudonyms-to-identity mapping upon pseu-donym issuance and pseudonym resolution authorites could access these. We discussa mechanism to improve privacy protection in the case of conditional pseudonymity inSection 3.6.2. The lifetime of pseudonyms is supposed to be short in oder to minimizethe need for certificate revocation. Basically, only a vehicle’s long-term identity is revokedto prevent it from acquiring new pseudonyms from a PP. Consequently, CAs only needto distribute certificate revocation lists (CRLs) to PPs, which are part of the infrastructurenetwork.

While the SeVeCom pseudonym approach can be considered a baseline solution, severalapproaches have been proposed that either improve or enhance specific aspects of thebasic approach.

PKI+ [98] is based on bilinear mappings on elliptic curves. A user obtains a master key andcertificate from a CA after it proves its identity and knowledge of a user secret x to the CA.The user can then self-generate pseudonyms by computing a public key from the mastercertificate, the secret x, and a random value. A certificate is computed as a signatureof knowledge proof s over the public key and the master public key. The certificate alsoincludes the version number Ver of the CA public key for revocation purposes. The usersigns a message m by computing the signature of knowledge proof ms on m. A receiverof m can verify the message with the public key in the pseudonym. When revoking a user,the CA publishes a new version information Ver ′, which has to be used by all users to

11.11.2010 IST-224201 33

Deliverable 16 1.0

update their keys. Ver ′ is chosen so that it is incompatible with the master key and mastercertificate of the revoked user. As an advantage, vehicles do not need to contact a CA orpseudonym provider to obtain new pseudonyms. Drawbacks are that Sybil attacks basedon unlinkable pseudonyms are hard to detect and that the CA has no means to control theamount of self-generated pseudonyms. The proposed revocation mechanism also doesnot scale well with a large user base.

Fischer et al. [99] employ blind signatures and secret sharing in the pseudonym issuanceprotocol to enforce distributed pseudonym resolution. In the pseudonym issuance pro-cess, a user blinds the public key to be signed and presents shares of it to a numberof CAs. Each CA holds a partial secret of the secret key shared by all CAs in a secretsharing scheme. Each CA signs the presented blinded key part with its partial secret key,returns it to the user, and stores a corresponding partial resolution tag in its database.The user can unblind and combine the received results, yielding a certificate which canbe verified with a public key common to all CAs. The certificate is only valid if k of nCAs participated in the issuance process, because otherwise the threshold of the secretsharing scheme is not reached, thus resulting in an incomplete signature. To resolve apseudonym, more than t CAs have to cooperate in a second secret sharing scheme tocompute a joint resolution tag for the presented pseudonym and compare it to all tags inthe database. The scheme effectively prevents misuse of resolution authority, but incursconsiderable overhead by requiring a number of authorities to take part in the certificationof a single pseudonym. Furthermore, pseudonym resolution requires comparisons with alltags stored in the revocation database, and therefore, does not scale well with the numberof users.

2.6.2. Symmetric key approaches

Symmetric cryptography schemes require less computational effort than asymmetric op-erations, thus they are more efficient for time-critical applications. However, symmetricencryption has to somehow emulate asymmetric properties to achieve authentication.

Hu et al. [100] propose a symmetric scheme based on the TESLA broadcast authentica-tion protocol. TESLA utilizes time to create asymmetric properties similar to public keycryptography, assuming that network nodes are loosely synchronized. A user computesa key chain and releases keys subsequently in fixed time intervals. Each message isauthenticated with a key that has not been released yet, and receivers have to buffermessages until the corresponding key is released and the message can be verified. Theauthenticity of a message can be verified with any key higher up in the chain. The advan-tage is that TESLA keys are much shorter in length than public keys. To enhance trust,each vehicle also has a set of pseudonyms signed by a CA. Pseudonyms are only usedto sign anchors of the key chains. When two vehicles enter each others reception range,they first exchange certificates to obtain each others TESLA anchors. Subsequently, theyonly use symmetric TESLA keys to authenticate messages. Keys belonging to the samekey chain as the presented anchor can be traced back to it and thus verified. This schemeprovides efficient authentication while reducing certificate exchanges to a minimum. How-ever, the delay in authentication can create problems for time-critical safety applications.

11.11.2010 IST-224201 34

Deliverable 16 1.0

Additionally, TESLA keys are unsuitable for multi-hop forwarding because the keys expiretoo quickly and actual receivers might not receive disclosed keys.

In the secure anonymous broadcasting scheme [101] vehicles are issued a unique identi-fier IDi by their home CA, together with a secret key SKi shared between CA and vehicle.Local CAs further manage shared network authorization keys AKl which are used in localregions to authenticate messages. A vehicle entering a new local region has to contactthe local CA to obtain the current authorization key. In the key request message and allfollowing messages the identifier of the vehicle’s home CA is included together with an en-cryption of the vehicle’s identifier IDi and a message hash under the key SKi. Thus, thelocal CA can present the encrypted part to the specified home CA in order to verify thatthe vehicle is still allowed to communicate. Once the current key AKl is obtained, vehiclesuse it to compute HMACs with it, which can be verified by all other vehicles in the sameregion. Local authorization keys have to be renewed in certain time intervals to ensurethat revoked vehicles cannot create valid HMACs anymore. The approach relies on anin-car TPM to encrypt the identifier, otherwise users could obtain AKl with an encryptionof a valid ID, and afterwards include wrong identifiers in all other messages to effectivelyevade identity resolution.

2.6.3. Group signature approaches

Group signatures are a signature scheme to provide conditional anonymity to members ofa group. Each group member can create signatures which can be verified with a commongroup public key. Only the group manager is able to determine the identity of a signer,because it assigns either individual secret keys or membership certificates to the groupmembers.

Calandriello et al. [102] use group signatures to reduce the overhead of key and pseu-donym management. Vehicles are members of a group and possess individual secretkeys. Each vehicle generates random public/secret key pairs to be used for pseudony-mous communications. The public keys are signed with the group secret key, yielding apseudonym certificate that can be verified with the group public key. When communicat-ing, vehicles sign the outgoing messages with the secret key of the pseudonym and attachthe pseudonym to the message. A receiver of such a message can verify with the grouppublic key that the pseudonym was created by a legitimate group member. The groupmanager, however, is able to open group signatures and retrieve the signer’s identity, ifnecessary. The scheme obviates the need to acquire new pseudonyms periodically, butrevocation of group membership is a scalability issue nevertheless.

The GSIS approach [103] is based on short group signatures. In the approach, a CA actsas the group manager. The CA computes a group public key and group secret keys foreach vehicle in the group from their unique identifiers. With the identifier and a part of thesecret key, a CA is able to determine the identity of a group member. Thus accountabilitycan be achieved while at the same time impersonation attacks are prevented. A vehiclesigns messages with its own secret key and receivers can verify them with the grouppublic key. Revocation is achieved by distributing revocation lists. One difference to other

11.11.2010 IST-224201 35

Deliverable 16 1.0

schemes is that revocation lists are only allowed to grow to a threshold t to avoid increasingverification times. When t vehicles have been revoked, the group key and individual secretkeys are updated. However, the issue of distributing revocation information persists.

2.6.4. IBC approaches

Identity-based cryptography (IBC) derives public keys from the identity of a user. Pre-sented with a signature, a verifier can check its validity merely by knowing the sender’sidentity. As a drawback, secret keys have to be generated and assigned by a central-ized trusted authority to prevent that anyone with knowledge of an identifier can derive acorresponding private key.

The ECPP approach [104] utilizes both IBC and group signatures. A trusted authority TAsets up an IBC scheme and publishes its system parameters. Vehicles have a uniqueidentity, which is used to authenticate with the TA to obtain a pseudonym. TA generatesa pseudonym, or pseudo-identifier, by encrypting the vehicle identifier with its public keyand extracting a corresponding private key from it. The vehicle can use the resulting keypair as a pseudonym in authentication processes with RSUs under control of TA. Thesetransactions are anonymous but linkable, because only one pseudonym is issued pervehicle. When a vehicle enters the vicinity of a RSU, it requests a short-time anonymouskey certificate to take part in a local group signature scheme. The group identifier isthereby also used as the group public key. The RSU checks that the presented pseudonymis not listed on a CRL, and issues a group membership certificate, valid only for a shortperiod of time. The RSU further retains a mapping between group membership certificateand pseudonym. Afterwards, the vehicle can perform group signatures on messages byproving possession of a membership certificate, and therefore communicate anonymouslywith other vehicles. Identity resolution is realized by the TA opening the group signatureof a message, and retrieving the identifier of the RSU that issued the group membershipcertificate. The RSU can then be contacted and returns the pseudonym corresponding tothe presented membership certificate. In the last step, the TA decrypts the pseudonymwith the symmetric key, used for encryption in the beginning, yielding the real vehicleidentifier.

Similar schemes based on IBC have been proposed by others [105, 106, 107].

2.7. Privacy-aware Architectures

At a recent panel discussion [108], Andreas Pfitzmann claimed that, due to the fact thatdata retention is difficult to implement in distributed systems, any privacy-preserving ar-chitecture should follow the following objectives:

1. Data avoidance: Avoid that personal data can be gathered by others at all.

2. Data minimization: Minimize the amount of personal data and their sensitivity oth-ers can/do gather.

11.11.2010 IST-224201 36

Deliverable 16 1.0

3. Unlinkability: Chunks of personal data should be unlinkable to other chunks.

4. Minimal spread: The set of entities which ever get to know a chunk of personaldata should be minimal.

5. Minimal linkability: The set of entities which ever can link different chunks of per-sonal data should be minimal.

6. Policies how long to retain and how to use personal data should be agreed, and ifpossible, enforced.

That is, the highest goal should be to avoid that data is collected, if that is not possible,one should minimize the amount of if, and so forth. In coarser terms, we can regroup thedifferent approaches in two categories: Data avoidance and minimization, and restrictionof data use. In the recent years, there has been a lot of research on technical means toaccomplish these goals. In the following, different approaches will be presented accordingto the category they belong to. First, we will discuss specialized approaches that aim toavoid or minimize data, and then we will focus on approaches aiming to restrict, shape,and govern the allowed usage of data.

2.7.1. Data Avoidance and Minimization

PriPAYD: Privacy Friendly Pay-As-You-Drive Insurance

PriPAYD [109] is a privacy-aware approach tailored for pay-as-you-drive insurance sys-tems. The goal of the PriPAYD system is to avoid collection of detailed user data in back-end systems whenever possible. Thus, users collect detailed traces of their whereaboutsonly locally and keep them in their possession without sending them to the insurancecompany. However, they do send aggregated data to the backend, namely, the calculatedinsurance premium. Moreover, a cryptographic commitment to the atomic values. Such acommitment can be created by calculating a hash over all atomic input values and signingthat hash, attesting that the hash resembles the correct atomic values. Therefore, in caseof a dispute, exact data can still be provided to a judge and cannot be faked by the usersdue to the prior commitment. PriPAYD is a good example for a system that is specificallytailored to one use case, thereby leveraging on the exact requirements and semantics ofinformation that are known. This knowledge can be used to achieve a system that mini-mizes the amount of data that is transferred. Thereby, the need for trust in remote systemsis reduced. However, the correct operation of the in-car black box responsible for calcu-lation of the insurance premium and the commitment still needs to be verified. Moreover,this unit needs to be trusted by the end user to not send more data than necessary, andby the insurance company to perform the calculations correctly.

11.11.2010 IST-224201 37

Deliverable 16 1.0

PrETP: Privacy-Preserving Electronic Toll Pricing

Similar to PriPAYD, PrETP is another special purpose privacy-enabled protocol [110]. Thegoal is to provide a solution for electronic toll pricing that fulfills all necessary requirements.That is, the users’ privacy needs to be kept, but on the other hand toll operators need apossibility to verify that no roads were used without paying the corresponding charge.Already existing solutions for electronic toll pricing often achieved the latter by submittingdetailed driving patterns to the providers, thus evidently not providing privacy for the users.In contrast to that, the authors present the so-called optimistic payment protocol. Locationtraces are only collected locally. Moreover, these traces are divided into several segmentsand the fee for each segment is then calculated. The toll collector only receives the finalfee summed over all segment fees, together with a commitment to the calculation process.To check whether the on board units calculate fees correctly, additional spot checks areused. For instance, license plate recognition cameras can be used to detect vehiclesdriving along a certain road segment. Then, the vehicle can be challenged to provide thecorresponding location traces to see if they were actually part of the total collection. Thus,it is not made impossible for vehicles to cheat, but due to spot checks and correspondingsanctions, cheating can be detected with high probability.

VPriv: Protecting Privacy in Location-Based Vehicular Services

In their system VPriv, Popa et al.[111] take a very similar approach to different use casesfor location based services as the previous two protocols. Zero knowledge proofs areused to enable applications like road tolling or pay-as-you-drive insurance to run in aprivacy friendly manner. In addition to transmitting only aggregated data, spot checks areemployed to ensure that users do not cheat. Also, the authors provide an open sourceimplementation of their protocol for download.

2.7.2. Restriction of Data Usage

While they can achieve near-to-optimal protection of user privacy, one drawback of data-minimization-based approaches is that they are tailored towards specific use cases, orclasses of use cases at best. Moreover, some applications, like mobile hotel bookingservices, are too complicated to allow a design of well scalable zero knowledge proto-cols. In general, many ITS projects envision flexible data dissemination and managementmiddleware systems like a Local Dynamic Map that will be used by many applications formany different purposes. These middleware systems try to provide a generic API for dataaccess. Not knowing the applications in advance, it is not possible to apply data minimiza-tion while designing the middleware. Therefore, PRECIOSA puts a focus on looking morebroadly on generic privacy architectures.

11.11.2010 IST-224201 38

Deliverable 16 1.0

Trusted Virtual Domains

Trust in systems, especially remote systems, is a central problem in vehicular networks.Griffin [112] specifically targets at building “bridges of trust” between systems that eachhave been equipped with trusted computing components. First, several systems that areeach equipped with trusted computing hardware attest trust to the configuration of eachsystem. Then, building on the trusted hardware, a separated computing domain is in-stantiated, for instance, a Xen or VMware virtual machine, or a Java sandbox. Severalsuch domains can be combined to a trusted virtual domain that bridges multiple phys-ical machines. Inside these separated domains, so-called execution environments canthen be used to execute specific tasks. Multiple execution environments can be in thesame trusted virtual domain, depending on application needs. For each trusted virtual do-main, several attestations can be made that allow applications to run in a privacy friendlymanner. For instance, the identity of institutions that operate physical machines can beassured, but also certain auditing components being present or data being handled in aspecific way. Moreover, Catuogno et al. [113] extend the idea of virtual trusted domains tobe able to cope with mobile storage devices, such as USB storage.

Prime and PrimeLife: Privacy and Identity Management

PrimeLife, the successor of the Prime project, aims to provide privacy enhancing tech-nologies for emerging internet services. Started in March 2008, Primelife is a 36 monthsintegrated project funded by the 7th framework programme. Rather than providing a cen-tralized architecture for privacy protection, PrimeLife focuses on several different aspectsand provides specific privacy enhancing technologies for them. One such example isa privacy-enhanced access control policy language. Deliverable 2.3.1 [114] gives anoverview over the mechanisms the project has proposed so far. Details on the privacypolicy language employed by the PrimeLife project can be found in Section 2.4.3.

Discreet: Discreet Service Provision in Smart Environments

The goal of the EU-FP6-funded Discreet project is to provide a distributed middleware forprivacy protection in mobile computing scenarios. The overall system design of Discreetis a three layer approach [115]. The first layer, layer 0 – environment enhancements,provides privacy enhancement solutions for base technologies, such as RFID and SensorNetworks. Layer 1 provides enhancements of privacy in networking, such as privacypreserving information flows through the network. On top of that, layer 2 provides supportfor identity management and pseudonymization, two important services necessary forproviding secure and privacy preserving services in mobile networks. Finally, layer 3defines a privacy preserving middleware implementation, the so called D-core, that is ableto evaluate policies with all data access. In addition to the layered architecture, severalmechanisms to help adaptation of existing services to use the proposed middleware aredescribed.

11.11.2010 IST-224201 39

Deliverable 16 1.0

PRISM: Privacy-aware Secure Monitoring

Similar to Discreet, PRISM, part of the EU-funded FP7 programme, aims to provide aprivacy-aware middleware. However, the use case is different and more targeted. ThePRISM architecture aims at providing privacy awareness for network monitoring tasks[116]. That is, network providers should have a means for monitoring the load and usageof their networks without jeopardizing the data of users that use their services. The pro-posed architecture is divided in two parts. The first part provides privacy directly at thepoints where traffic measurements are performed. For instance, aggregation and fuzzifi-cation mechanisms can be applied here to minimize the amount of data actually transmit-ted to the backend servers. Second, a backend architecture will further make sure thatprivacy requirements are fulfilled even when data is collected in the backend.

2.7.3. Conclusion

There exist a number of interesting approaches tailored towards data minimization in ITS,however they are all explicitly designed and optimized towards a specific use case. In gen-eral, we see a trade-off between the amount of data minimization that can be achievedand the generic applicability of a system. Therefore, there are a number of generic archi-tectures that, by introducing the requirement of remote trust attestation, aim to guaranteeprivacy policy compliance of data usage throughout a system. Moreover, such genericsystems enable the users to use services that need a high number of personal data foroperation, e.g., tailored hotel search and booking. Nonetheless, users can rest assuredthat only those operations on the data that the user agreed to can be performed. However,there are currently no privacy-enforcing architectures that are suitable for the distributedand high-mobility setting of vehicle-to-vehicle networks or other ITS services where vehi-cles communicate with backend services.

11.11.2010 IST-224201 40

3. PRECIOSA Contributions

This chapter presents our research contributions and is separated into seven topics: Pri-vacy Modeling, Privacy Metrics, Privacy-aware Analysis and Software Design, Privacy-enhanced Policy Language, Privacy-aware Request Processing, Privacy-aware Commu-nication, and Privacy-aware Architecture. Prerequirements were given in Chapter 2 whichhas the same separation like this chapter. Open Issues and new challenges are given inthe corresponding sections in Chapter 4.

3.1. Privacy Modeling

One major aspect of privacy protection is to specify the privacy requirements. Differententities and stakeholders specify their privacy criteria in form of privacy policies. Theseentities may be users (data subjects), service providers, providers for privacy aware com-ponents and systems, public authorities, law makers, data controllers, and others. Mea-suring the utilization of systems, components, and applications regarding privacy are al-ways based on specified privacy requirements/constraints. Thus, the description of thesystem or of parts of a system and the privacy requirements have to be unambiguous.Therefore, the use of well defined (standardized) metamodels and models is necessary.In PRECIOSA we use an MDE approach combined with ontologies. Ontologies might alsobe used to check for inconsistencies and contradictions to support the creation and evalu-ation/verification of such model based descriptions (see also the list of benefits in Sections2.3.1 and 2.1). Furthermore, standardized vocabulary description languages like the WebOntology Language (OWL) are powerful enough to express a large variety of terms andconditions.

3.1.1. PRECIOSA Ontologies

In PRECIOSA we use ontologies to support the provision of privacy, to provide a vocab-ulary for describing information flows and privacy protection requirements, and to specifyindicators which we evaluate for privacy analysis. In the following we summarize our con-tribution regarding ontologies which are explained in Deliverable D6 [4].

We use ontologies for different purposes:

1. improve the translation of high level privacy requirements into technical privacy re-quirements,

41

Deliverable 16 1.0

2. provide vocabularies for describing technical privacy requirements as permittedstates of a system/application while processing personal information,

3. evaluate the implementation of privacy requirements (e.g. as system/applicationdesign) at the conceptual level,

4. evaluate the influences of technical solutions regarding high level privacy require-ments (derive indicators from technical parameters which we can translate back intohigh level privacy effects).

Definition of terminology

The definition of terminology is one purpose of using ontologies in PRECIOSA to developa sound basis

• to ensure a clear understanding of the different concepts (terms) used in the pri-vacy domain that avoid ambiguities or diverging understanding of concepts by dif-ferent users. Such an ontology should also include the definition of meaningful re-lation(ships) among those concepts that characterizes the participating conceptsfurther;

• to establish a sound and unambiguous basis for (semi-) automatically reasoning byprograms about concepts in the domain. For example, it might be desirable to detectprivacy leakages automatically even when such a detection mechanism generatesfalse positives;

• to provide a basis for defining a privacy policy language that uses the concepts ofthe defined ontology. Then the ontology also provides the sound basis for reasoningand understanding;

• to translate non technical aspects of privacy that are initially defined in legal terms,into technical terms that provide meaning in IT(S) systems;

• to define a consistent basis for the implementation of privacy aware systems. Suchontology will allow the developer to understand when personal information is oper-ated on and where it is used in software systems. The ontology might also help todevelop methods and tools to find privacy leakages in such systems in a clear andsystematic manner.

When defining such an ontology it might be necessary to define several variations that re-flect differences due to the laws and understanding in different countries - again a way toget a better understanding of the differences in the privacy domain in different countries,agencies, or (governmental or industrial) organizations. Furthermore, it might be neces-sary to define different ontologies using different granularity levels or relating concepts ofspecial domains to ones in the privacy domain. Such an initial separation might require anapproach to integrate different ontologies at some point of the development process. Theintegration might be quite challenging; it includes mappings between concepts in differentontologies thus leading to one integrated framework possibly in a particular applicationdomain.

11.11.2010 IST-224201 42

Deliverable 16 1.0

Support of different perspectives and application domains

Applications and services involve different stakeholders; for instance users, data subjects,data processors, data controller, manufactures, and legal agencies. Every stakeholderimplies a different background resulting from the area of expertise, origin (country), inter-ests, and more. Most of the stakeholders have a domain of interest which they representin decision making processes. Regarding privacy we have to identify the most impor-tant domains and to model the required part of the domain to include the concerns of allrelevant stakeholders. Those definitions address different purposes.

In [4] we identify the relevant domains of PRECIOSA and describe their relationships.Context/domain dependent concepts can not be automatically mapped between differentdomains. Therefore, we model every relevant domain (the required parts of the domain)independent and (explicitly) map similar concepts to guaranty consistency for our ontolo-gies. Every domain model is described using a partial ontology.

The cITS domain is part of the ICT domain and further contains the vehicle domain, theaccess domain, and the backend domain. The domains of data storage and communica-tion are part of the ICT domain and partly overlap with the other domains. Additionally,in Figure 3.1 also the legal and the privacy domain has been included. The PRECIOSAontologies comprise parts of all these domains.

legal domain

vehicle domain

privacy domain

PRECIOSAvehicle domain

access domain

backend domain

PRECIOSAontologies

cITS domain

data storagedomain

communicationdomainICT domain domain domainICT domain

Figure 3.1.: Domains of PRECIOSA 3

Support of privacy analysis

We perform privacy analysis on systems and applications to get/investigate and evalu-ate important privacy properties. Thus, we can evaluate if the developers implementedthe specified privacy requirements appropriately. The main purpose for using ontologiesin the context of privacy analysis (see Section 3.3) is to support (semi-) automatic ap-proaches to detect privacy violations or privacy leakages. We therefore model the privacydomain by introducing and defining fundamental concepts and their relationships. The def-inition of terms and the meaning of privacy, privacy leakages, the requirements, protection

11.11.2010 IST-224201 43

Deliverable 16 1.0

mechanisms, and the necessity of auditing require a careful analysis of those terms bydetermining their different relationships with respect to privacy. A particular challenge is totransform privacy definitions as defined by law into privacy concepts that reflect the techni-cal aspects they are embedded in. These aspects of technical privacy become especiallyimportant when a system performs operations on data or information which describe thedata subject (from different perspectives). Thus, privacy ontologies provide the basis todiscover potential privacy leakages, to create corresponding privacy policies which definethe protection requirements regarding the privacy of data subjects. Privacy policies (asP3L policies see Section 3.4) together with privacy ontologies allow us to design (semi-)automatic procedures for verifying the conformance of the data processing unit (DPU) withthe defined policies. A Data processing unit (DPUs) itself might be of a single componentthe overall system - for examples a road side unit (RSU) -, a composition of componentslike a network of RSUs, systems like the infrastructure of a traffic monitoring center, orapplications like a hotel booking application all of which must respect the privacy of thedata subject as defined by (privacy policies).

With the PRECIOSA ontologies we introduce a conceptualization to support ontologydriven privacy analysis. Thus, as mentioned in Section 2.3.1 we provide features as

• to create models for different perspectives and domains,

• to create and integrate models which describe whole systems or parts of a system,

• to provide standardized vocabularies for defining appropriate privacy policies whichwe can reason about,

• to provide standardized vocabularies to describe system behaviour, side effects, andenvironments

• to provide different degree of granularity to describe privacy policies (e.g. to specifya situation/system specific privacy policy or to specify a general privacy policy topermit the processing of information for a class of applications),

• to translate user privacy to technical privacy (formal language description) in a de-clarative manner based on logical concepts and axioms,

• to abstract from system specific properties while specifying formal privacy policies;

• to describe possibilities to derive (personal) information (to detect privacy leakagesor privacy violations) and to define rules for preventing those inferences,

• to address privacy attacks that utilize semantic technologies, background knowl-edge, or data mining techniques.

Privacy aware query execution

The execution of queries in Privacy Aware Applications (PAA) needs additional considera-tions when compared with those in other (traditional) applications. Beside the processingof data and the evaluation of queries on the data we must respect specific privacy require-ments. Therefore, we take into account (and evaluate) information on the application data

11.11.2010 IST-224201 44

Deliverable 16 1.0

regarding privacy and information about the context of executing a query. Such informa-tion is always represented as metadata and coupled both with the application data andwith the request (query). The PRECIOSA ontologies provide a vocabulary to define re-quests (PPQL see Section 3.5) which we can formally evaluate regarding privacy aspectsand a vocabulary to defines privacy criteria (P3L see Section 3.4) which have to be fulfilledbefore, while, and after the processing of such requests.

Privacy Metadata

In order to follow the privacy requirements as defined by a stakeholder, a privacy awaresystem evaluates information describing the requested data regarding privacy aspectsand information about the context of the query execution. Such information has always tobe coupled as metadata with the managed data and the requests.

In our prototype PeRA we consider different types of metadata while processing a request(see Figure 3.12). First, we consider the metadata of the requested data. Before a re-quest on data can be performed the privacy control monitor checks if the stakeholders ofthe requested data permit the system to perform the request. Such privacy criteria thatrestricts the performance of requests on data is attached as metadata (e.g. P3L poli-cies). The second type of metadata that is attached on the requested data is informationwhich describes data quality aspects. For some applications it is necessary to know thepreciseness of data or they have requirements on the preciseness of results.

For example, the quality of a service might depend on the precision of the processed data.Some high quality services need very precise data. In contrast, most Privacy EnhancingTechnologies (PETs) obfuscate data to protect users against privacy violations. Therefore,it is important to find the necessary balance between the degree of privacy protectionand the provided quality of service. As a result we have to consider the two opposeddimensions of a) privacy requirements and b) data quality requirements:

• Dimension 1: privacy criteria - privacy measure e.g. obfuscation to reduce the infor-mation content (rising the entropy)

• Dimension 2: data quality requirement - one aspect of data quality e.g. preciseness

The third type of metadata the PeRA system has to consider is information describingthe context of the request. The privacy criteria defined by the stakeholders permit theperformance of requests for a set of contexts that are defined by constraints. The PeRAsystem provides the metadata that describes the context. The fourth type of metadata isattached with the request. This metadata describes the supported privacy dimension (e.g.supported range of P3L policies) of the requesting data processor and the requirementsof the requester regarding data quality. i.e. preciseness. Thus, it is possible to check if thesupported privacy dimension of a data processor conforms to the specified privacy criteriaof the requested data. Such analysis can be done at design time and at runtime.

Regarding the feasibility of our approach for processing the different types of metadata weneed to use a standard language(s) to specify metadata. Stakeholders have to agree oncommon languages; for instance, to express their privacy criteria.

11.11.2010 IST-224201 45

Deliverable 16 1.0

The PRECIOSA ontologies

We started to investigate the identified PRECIOSA domains to design the PRECIOSAontologies and introduced all necessary concepts into corresponding partial ontologies.Thereby, we focus on the concepts that are required to implement the defined purposes(as stated at the beginning of the section) and only introduce additional concepts whichare necessary to define the introduced concepts in an unambiguous ways. Thus, wedo not define the whole domains. We define base ontologies which can be refined andextended as required. In Deliverable D6 [4] we use this base ontologies to define complexand comprehensive ITS privacy ontologies.

In Deliverable D7 [5] we describe some privacy principles of PRECIOSA. Thereby, dataprocessors need a permission to execute operations on personal information. In anotherprinciple we state to create such privacy statements based on the consent of the datasubject. In [15] the authors design a privacy ontology for e-Commerce which is based ona similar principle. This principle intends to control information related to a data subjectaccording to his/her own interest. Another principle in PRECIOSA states that personal in-formation related to the data subject shall be protected by appropriate security measuresagainst unauthorized use or use in conflict with the consent of the data subject. There-fore, we and [15] apply security protection mechanisms to grant or revoke other entitiesthe privilege of accessing data subject’s data. Derived from the principles the model ofclassical authentication and authorization as described in [15] is a good starting point tocreate a privacy ontology. Security ontologies are another good starting point becausesecurity ontologies are highly abstract and based on security patterns as in [16]. Privacyontologies should integrate such security principles and mechanisms to keep informationunder the control of the data’s subject. For instance, we may use security mechanisms toauthenticate individual to authorize him/her to access a certain resource.

Further input for creating privacy ontologies is knowledge which has been extracted fromspecific privacy domains as privacy protection for data storage or communication (seeDeliverable D4 [3]), or the legal perspective which already include perspectives of differentstakeholders as data subjects, manufacturers, authorities, and more. Among others weconsider input of some Opinions of the European Data Protection Supervisor regardingprivacy in ITS, the Directive 95/46/EC of the European Parliament and of the Council of24 October 1995 on the protection of individuals with regard to the processing of personaldata and on the free movement of such data [117], and preliminary communications fromthe commission regarding the Directive 2010/40/EU of the European Parliament and ofthe Council of 7 July 2010 on the framework for the deployment of Intelligent TransportSystems in the field of road transport and for interfaces with other modes of transport[118], and its proposal from 16 December 2008. One can find the used definitions of thedefined concepts from the literature in version 2 (partially in version 1) of the ontologydefinitions.

We started to define the required terms and their meaning at a general level (the ICTdomain). Accordingly, we refine the terms step by step (integrating domain knowledgeof different sources). Thereby, we specialize the context for which we want to model

11.11.2010 IST-224201 46

Deliverable 16 1.0

importslegal perspective importsPeRA ontologylegal perspective

ontology

policy (base) ontology

PPQL ontology P3L ontology

cITS privacy

ICT privacy ontologyICT privacy

t ti t lICT privacy

t ti t l

protection ontology

p y gyprotection ontologyprotection ontology

data storageICT (base) ontology security (base) ontology

data storage

privacy protectionontology

(base) ontology

communication(base) ontology

communicationprivacy protection

l(base) ontology

ontology

Figure 3.2.: Partial ontologies - imports of the PRECIOSA ontology

privacy relevant aspects as privacy leakages, privacy requirements, privacy protectionmechanisms, privacy measurement, and more.

Figure 3.2 illustrate the partial ontologies of PRECIOSA and their mutual inclusion. TheICT base ontology contains the description of fundamental concepts as information, data,system etc. for the domain of ICT (Information and Communications Technology). Thepolicy base ontology contains the description of fundamental policy concepts as policy,policy statement, context, entity, permission, condition, and more. The mentioned ontolo-gies independently define fundamental domain concepts. With the ICT privacy ontologywe combine the ICT base and the policy ontology and expand the set of definition bysome privacy concepts as data controller, data processor, data subject, personal informa-tion, and more. In Figure 3.2 one can see how the ICT privacy ontology imports the otherontologies. The security base ontology contains the description of fundamental privacyconcepts regarding the security domain.

We already mentioned most of the base ontologies which initially specialize the privacycontext by the ICT privacy ontology. We specialize in more detail the PRECIOSA domainregarding privacy protection in the ontologies about ICT privacy protection, PPQL, andP3L. Thereby, we provide the fundamental vocabulary to describe information flows andprivacy criteria. Additionally, we define complementary domains as data storage, commu-nication, and cITS, and include the complementary domain concepts to extend the funda-mental (PPQL and P3L) vocabulary. In Figure 3.2 one can see how the ontologies aboutICT privacy protection, PPQL, and P3L import each other. The cITS ontology importsthe ICT base ontology and defines fundamental concepts of cITS as location, localization,location tracking, vehicle, RSU, and more. The purpose of expanding the base ontologies

11.11.2010 IST-224201 47

Deliverable 16 1.0

by cITS concepts is to provide a vocabulary which we may use to formulate adequate re-quests and (privacy) requirements in the context of cITS. In general one provides the bestand most flexible privacy protection solutions having exact domain description/knowledge.For a well described problem statement we can find and configure solutions which are op-timized to the problem domain. The PeRA ontology integrates all previously describedontologies and provides the vocabulary to express P3L and PPQL statements which aresupported by PeRA. We take the fundamental vocabularies of PPQL and P3L and expandit based on concepts of the cITS ontologies. In PRECIOSA we also address the legalperspective regarding privacy.

Ontologies:ICT (base) ontologyICT privacy ontologyICT i i l

ThreatPrivacyisA

ICT privacy protection ontology

Mechanism Componentimplements

Threat

detects preventsd Of

Threat

Information isA

Mechanism

ProtectionM

isA

Component

ProtectionC

isA

IncedenceOf

isA

Mechanism

Privacy

Component

Privacy

isAisAIdentifier

PseudonymProtectionMechanism

ProtectionComponent

isAcreates

≡ ProtectionMechanismand preventsIncedenceOf

some PrivacyThreat

≡ ProtectionComponentand implements some

Pseudonymization Anonymization AccessControl

and implements some PrivacyProtectionMechanism

anonymizes

Figure 3.3.: Partial ontologies - ICT privacy protection ontology

As one example we describe parts of the ICT privacy protection ontology (see Figure3.3) which contains the description of fundamental concepts regarding privacy protection.Figure 3.3 illustrates some concepts of the ICT base ontology, the ICT privacy ontol-ogy, and the ICT privacy protection ontology. Concepts as Threat, Information, Identi-fier, Mechanism, ProtectionMechanism, Component, and ProtectionComponent and theirrelationships are defined in the ICT base ontology. The ICT privacy ontology definesnew concepts, relationships, axioms on base of the ICT base ontology. The ICT pri-vacy protection ontology does the same on base of the ICT base ontology and the ICTprivacy ontology. Figure 3.3 illustrates the definition of the concept privacy threat. In Fig-ure 3.3 the ICT protection ontology defines concepts as Pseudonym, Pseudonymization,

11.11.2010 IST-224201 48

Deliverable 16 1.0

Anonymization, AccessControl, PrivacyProtectionMechanism, PrivacyProtectionCompo-nent, and their relationships. Privacy protection components implement some privacyprotection mechanism. Privacy protection mechanisms prevents the incidence of someprivacy threats. Pseudonymization, anonymization, and access control are privacy protec-tion mechanisms. Pseudonymization creates pseudonyms. Anonymization anonymizessome information.

3.1.2. Enforcing Privacy by a MDE Approach

The OMG (Object Managment Group) has defined several layers in MDE:

• M0: the instance level.

• M1: the model level.

• M2: the meta-model. This level corresponds to the specification of a language fordeveloping a model. For instance, UML and eCORE are some examples of meta-models.

• M3: the metameta-model, which defines a language for specifing a meta-model.The meta-meta-model defined by the OMG is called MOF (Meta-Object Facility).

In PRECIOSA, we have defined several solutions at the M1 and M2 level which are de-scribed in the next subsections. This work is detailed in the PRECIOSA deliverable D6.[4]

The PRECIOSA Meta-model

Before explaining the interest of the PRECIOSA metamodel, we will define in more detailthe concept of metamodel. Jean Bézivin has defined in [119]: “A meta-model is a for-mal specification of an abstraction, usually consensual and normative . . . The meta-modelprovides the concepts and their relations that will be used to filter the relevant entities of agiven system in order to extract the model.”

This means that the main goal of a metamodel is to provide common understanding bydefining concepts and the relationships. In other words, a metamodel defines an abstractsyntax on a domain.

Basically, the PRECIOSA metamodel defines the concept of privacy as protecting per-sonal data by privacy policies. A privacy policy enumerates some rules which authorize ornot an operation on personal data. It is possible to associate some constraints with a rulesuch as time retention, context, etc. More details are given in the deliverable D6.

Thanks to this metamodel, all partners have a common understanding and can developtools which conform to this metamodel.

11.11.2010 IST-224201 49

Deliverable 16 1.0

The PRECIOSA platform and Access Control Model

In the PRECIOSA project, we have defined a privacy enforcement architecture. This archi-tecture has been modelled in UML. For this, we have used a component-based approach.Each part of the PRECIOSA architecture is represented by a software component.

In an MDE process, it is usual to have a PIM (Platform Independent Model) and a PSM(Platform Specific Model). When we transform the PIM into a PSM, we need to havedetails of the platform. In a PRECIOSA context, the final user will use this model andspecify the links between this platform model and the application model. At the end, it ispossible to generate some code runnable on this architecture.

Same, we have defined some usual access control mechanism such as RBAC [19]. Thismodel can be used in order to define roles and high-level access controls. Then, theseroles are used during the definition of privacy rules.

UML-based Representation

The PRECIOSA metamodel provides an abstract syntax. It is possible to use the meta-model as a new language. However, it is usual to define a DSL (Domain Specific Lan-guage) or a UML-based representation. In PRECIOSA, we have decided to use the sec-ond solution which offers an unified environment for any domains (i.e., it is possible to addalso an ITS domain).

In order to use UML for privacy issues, it is necessary to define a UML profile. ThePRECIOSA profile defines some stereotypes in order to personalise UML. This UML-profile is conformed to the concepts defined by the PRECIOSA metamodel.

To define privacy policies, we have also defined a DSL called PRECIOSA Privacy PolicyLanguage (P3L). Thanks to the usage of a common metamodel, we can extract informa-tion from the UML model and generates P3L code. For this, we used a model transforma-tion.

3.2. Privacy Metrics

In a recent published report on the roadmap for cybersecurity research [120], the De-partment of Homeland Security Cybersecurity Research and Development Center listsenterprise-level security metrics as one of the 11 hard problem areas in cybersecurity.As the report points out, “we cannot manage what we cannot measure.” In the similarway, the issue of privacy metrics is also a hard research problem. It must be addressedbecause privacy metrics are of significant importance to the design and development ofprivacy-preserving ICT systems.

11.11.2010 IST-224201 50

Deliverable 16 1.0

Within the PRECIOSA project, we have addressed the issue on several fronts. Specifically,with regard to location privacy, our contributions have addressed the following researchquestions:

• How to measure location privacy and quantify the privacy values in a meaningfulway?

• How to capture and reflect the unique characteristics of users in cITS and the corre-sponding privacy implications?

• How to measure the long-term impact of cITS on users’ location privacy?

• How to use privacy metrics to evaluate the effectiveness of existing PETs?

In addressing these questions, we have designed and evaluated a comprehensive metricfor measuring location privacy in ITS which we will present next.

3.2.1. Fundamentals of trip-based location privacy metric

In cITS communication systems, each time a vehicle sends a message, it gives out itslocation information to the system. Although there are different levels of granularities,the location information in cITS systems can be categorized into three types, i.e., singlelocations, tracks, and trips. Location information only becomes privacy-relevant if it canbe linked to identifiable individuals. Since for privacy concerns vehicles are very likely touse pseudonyms in communications, information on single locations and tracks are lessprivacy-sensitive than the information on trips, which can be used to infer an individual’sidentity and activities. The first step to measure privacy is to capture the information ontrips and individuals in an arbitrary defined area and time period. Hence the metric virtuallytakes a “snapshot” of the dynamic cITS systems.

The information captured in the snapshot is then modeled in a weighted tripartite graph,shown in Fig. 3.4. The graph contains three distinct sets of vertices, i.e., I, O, and D,which represent Individuals, Origins and Destinations of the trips. An adversary’s knowl-edge on the linkabilitiy of an individual to a set of trips is expressed in probability distribu-tions. The probabilities are used as the weights on the directed edges. For example, pjkis a weight on an edge (vj , vk) between the vertices vj and vk.

For an individual to make a trip (e.g., o1 −→ d1), he or she must start from one of theorigins, e.g., i1 from o1. If the trip from o1 ends at one of the destinations, it must bepossible to link i1 to d1 as well. Due to the uncertainty in the information, there can bemany of such possible linkings among the vertices. A closed walk or a cycle starting froma vertex is and passing vertices {oj , dk} in the graph has the semantics of is’s probabilitypjk to make a trip with origin oj and destination dk. By collecting all cycles connected to aparticular individual in the graph, we can extract the probability distribution of the linkabilityof that individual to a set of trips. The probability distribution can be graphically expressedas a hub-and-spoke structure, shown in Fig. 3.5. The last spoke with probability pc in theclock-wise order denotes the probability of an individual not making any trips, i.e., “stayingat home”.

11.11.2010 IST-224201 51

Deliverable 16 1.0

i1 i2 i3 …  in

o1

o2

o3

om

… 

d1

d2

d3

dm … 

€

pi s o j ∈ 0,1[ ]po j dk ∈ 0,1[ ]pdkis ∈ 0,1[ ]

Figure 3.4.: Snapshot information modeled in weighted tripartite graph

p11 

is 

p12 

p13 

p1m 

p21 p22 p23 

… 

… 

p2m 

… 

pc 

Figure 3.5.: Extracted probability distribution as hub-and-spoke

The normalized probabilities on each of the spokes are calculated as

pjk =p(is, oj)p(oj , dk)p(dk, is)

m∑j=1

m∑k=1

p(is, oj)p(oj , dk)p(dk, is) + pc

pc = 1−m∑j=1

p(is, oj)

with probabilities taken from the graph in Fig. 3.4. Applying Shannon’s entropy [121], wequantify the uncertainty in the information about is in entropy as

H(is) = −(

m∑j=1

m∑k=1

pjklog(pjk) + pclog(pc))

where the logarithm is taken to base 2 to have a unit of bit. H(is) is used as a quantitativemeasure of is’s level of location privacy. The privacy level is directly proportional to thevalue of entropy, i.e., the higher the entropy, the higher the privacy level, and vice versa.Entropy reaches its maximum if all trips are equally probable. For a snapshot with m2 O/Dpairs, the maximum entropy for each individuals in the snapshot is

Hmax = log(m2 + 1)

11.11.2010 IST-224201 52

Deliverable 16 1.0

with 1 accounting for not making any trips. Notice that the above research results haveappeared in [122].

3.2.2. Measuring long-term location privacy

The cITS is a continuous system. Once deployed, the system is supposed to run for anextended period of time, e.g., for the next fifty years. Therefore, the long-term impacton users’ location privacy caused by cITS is an serious issue. However, to the best ofour knowledge, no existing work on privacy metrics has directly addressed this issue.Obviously, there is gap in the method and impact of privacy values in the long run incurrent research.

In PRECIOSA, we have addressed the issue of long-term location privacy in the contextof cITS. In our work in [123, 124], we assume that an adversary will collect as muchinformation as possible over a long period of time to work for its advantage. Intuitively,information accumulated over time should help to reveal more facts about the individualsand their vehicle movements. Our research contributions can be summarized as:

• We developed methods to model accumulated information,

• We designed approaches and algorithms to process, propagate, and reflect the ac-cumulated information in location privacy measurements,

• We devised approaches to evaluate the feasibility and correctness of our approachesby various case studies and extensive simulations.

Extending our previous work in [122], we model the accumulated information as a set oftimely ordered snapshots. Thus the metric yields measurements on “multiple snapshots”.In a single snapshot, the information needed for measuring each individual can be repre-sented by a hub-and-spoke structure shown in Fig. 3.5. When more snapshots are addedto the metric, we can imagine that the information related to an individual i becomes asequence of hub-and-spoke structures ordered in time as shown in Fig. 3.6. Notice thatonly one individual is shown in Fig. 3.6. But we can imagine that for each of the individualscaptured in the snapshots, we can extract the information and build a similar sequenceof hub-and-spoke structures. For simplicity in formulations, we will only consider one in-dividual i here. The same formulas and procedures are applicable to any of the otherindividuals captured in the snapshots.

To process, propagate, and utilize the accumulated information captured in the multi-snapshots model, we use the Bayesian method to detect repeated trip patterns and inferinformation from the historical data.

In principle, Bayesian method uses evidence to update a set of hypotheses expressednumerically in probabilities. The core of Bayesian method is the Bayes’ theorem. Let hk

11.11.2010 IST-224201 53

Deliverable 16 1.0

!me 

i in  1st Snapshot 

i in 2nd Snapshot 

i in 3rd Snapshot 

Figure 3.6.: Multiple snapshots of i in timely-ordered sequence

be the kth hypothesis of a complete set of hypotheses H1, the Bayes’ theorem can bewritten as a function of hk as

P (hk|E) =P (E|hk)P (hk)∑k

P (E|hk)P (hk)(3.1)

in which E is the evidence. P (hk|E) is the posterior probability of hk because it is theconditional probability of hk given the evidence E. P (E|hk) is the conditional probabilityof observing the evidence E if the hypothesis hk is true. P (hk) is the prior probability ofhk because it is the probability of hk before it is updated by E. The denominator in (3.1) isthe sum of probabilities of observing the evidence E under all possible hypotheses.

To apply the Bayesian method to our specific problem, we developed two algorithms.Notice that we will leave out the details of the two algorithms and refer interested readersto our publications [123, 124]. In a nutshell, a common principle used in both algorithmsis that for a given snapshot at time t, the algorithm calculates the modified probabilitydistribution for this snapshot using the Bayesian method.

In our first algorithm, the past snapshots in the time series are stored in a table B up to thetime a new snapshot Si is recorded. The algorithm first consults B for the latest posteriorhypotheses with the same trip constellation as Si. If found, the posterior hypotheses H+

j

will be used as the prior hypotheses H−i for the current snapshot Si. If not found, thealgorithm assigns H−i with equally distributed probabilities. Then H−i is updated by Sito generate H+

i . Afterwards, H+i is added to B. For efficiency reason, B only needs to

keep the latest H+ with a unique trip constellation. Finally, H+t replaces the probability

distribution in St to have St. St reflects the current beliefs expressed in probabilities,which have been continuously updated by new evidence, on each of the trips in the tripconstellation in St. In the same way as in [122], location privacy is calculated as theentropy of the updated probability distribution St. Our simulations shown that due to the

1Notice that the notation H is conventionally used for both entropy and hypotheses. We keep the conventionand assume that the meaning should be clear from the context.

11.11.2010 IST-224201 54

Deliverable 16 1.0

repeated trip patterns in vehicle mobility, accumulated information has a significant impacton a user’s location privacy.

The first algorithm functions well on snapshots containing regular trip patterns, in whichsnapshots with same trip constellations appear frequently. Imagine if an individual can belinked to different sets of trips in each of the snapshots, the first algorithm will likely waitfor a very long period of time until it has the same trip constellation again. To have a morerobust way to process and reflect accumulated information in the privacy measurements,we developed a heuristic algorithm as an important extension to the first algorithm.

Our second algorithm tackles the trip dynamics in a heuristic way. The basic idea isthat if the beliefs are propagated between two snapshots with the most similarities, thedistortions during the belief propagation will be kept at a minimum. In fact, because twoidentical trip constellations are the most “similar” ones, a search for the most similar willreturn the identical trip constellation, if it exists.

In our second algorithm, to quantitively express the concept of “similarity”, we representthe occurrence of trips in a snapshot by a binary string. The degree of similarity of anytwo snapshots are calculated as the hamming distance of the two corresponding binarystrings. Instead of looking for a snapshot with the exactly the same trip constellation, thesecond algorithm looks for a snapshot in B with the most “similarity”, i.e., the smallesthamming distance. Afterwards, a process called “constellation fitting” is used to pass theposterior probability distribution in the past snapshot to the prior probability distribution inthe new snapshot. The constellation fitting process is carefully designed to ensure thatthe belief propagation between two snapshots causes only the minimum distortions. Inthe next step, the second algorithm applies the Bayesian method as used in the first algo-rithm to calculate the posterior probability distribution. In the end, the updated probabilitydistribution is used to calculate the entropy as the measurement of location privacy.

In summary, to measure long-term location privacy in cITS, we developed approaches andalgorithms to model, process, propagate, and reflect the impact of accumulated informa-tion in privacy measurements. We developed two algorithms to apply the Bayesian methodto process and propagate accumulated information among multiple snapshots along thetimeline. Our findings provide valuable insights into location privacy, which contribute tothe development of future-proof, privacy-preserving cITS.

3.2.3. Vehicle tracking

One aspect of the privacy metric is the probability to successfully reconstruct trips. Tobe able to provide this probability for typical ITS and V2X scenarios, we also worked onvehicle tracking based on anonymous position samples.

When vehicles which are equipped with radio interfaces, they continuously produce mes-sages containing personal information and spread this messages in the surrounding envi-ronment. As in dynamic ad-hoc network, for the distributed network management, beaconmessages have to be sent out periodically, which contain several types of personal infor-mation. On the one hand, they contain different kind of identifiers (MAC addresses, IP

11.11.2010 IST-224201 55

Deliverable 16 1.0

addresses, application layer specific ids) that could be linked to real identities (i.e. of thedriver), on the other hand these messages contain precise location information. A com-bination of these two information sources might lead to heavy losses of privacy, if both– identifiers for network communication and position information – an eavesdropper mayeasily collect sensitive private information.

One of the most common mechanism to avoid the linking of information from the bea-con messages with real persons is to introduce short time identifiers called pseudonyms.Pseudonyms are retrieved from a pseudonym provider. One pseudonym is used just for afixed or even dynamic period of time. The range leads from using a new pseudonym foreach transmitted packet to just using a new pseudonym on each start of the engine.

However, we show that even with a very high pseudonym change interval a powerfulattacker can connect the traces before and after a pseudonym change by using sophisti-cated tracking algorithms.

By using the Multi-Hypotheses-Tracking algorithm proposed by Reid, it is possible to suc-cessfully track vehicles in average between 600 and 900 seconds of a 1000 second sim-ulation, even when vehicles use a new pseudonym for every transmitted packet. Whenpseudonym change intervals are increased, tracking success also increases and reaches100% tracking success at about 10 seconds pseudonym change interval (see figure 3.7).The influence of other parameters, like vehicle equipment rate, spatial random noise, bea-coning interval was also analyzed, more details can be found in [125].

0

200

400

600

800

1000

50 100 150 200 250

Mea

n tr

acki

ng d

urat

ion

(s)

Vehicles

Variation of pseudonym change intervals

1 s2 s3 s4 s6 s

10 s

Figure 3.7.: Effect of pseudonym change interval (1 - 10 seconds) on tracking results.

These results lead to the conclusion, that simple pseudonym change is not sufficient inevery case to prevent an attacker from gathering personal information sent via vehicu-lar communication. The attacker model is quite strong. See the section 4.2 for furtherresearch activities on this topic.

11.11.2010 IST-224201 56

Deliverable 16 1.0

3.3. Privacy-aware Analysis and Software Design

Current research activities focus on improving existing mechanisms of privacy analysis,and some of them try to integrate the different perspectives into a holistic approach. Suchapproaches try to create a privacy recognition cycle which in one direction injects pri-vacy criteria into a system, while the opposite direction evaluates system behaviour andproperties to calculate privacy indicators, as seen in Figure 3.8.

d idesignincluding privacy criteria as user preferences, privacy regulations, hi h l l i ihigh level privacy requirements

inject privacy criteria into a system

evaluatesystem behaviour

and properties to calculate privacy

system specificationincluding technicalprivacy requirements

indicators

Figure 3.8.: Privacy recognition cycle

To adequately implement privacy criteria of different stakeholders, high level privacy crite-ria (described in the language of stakeholders as data subject and data controller) must betranslated into technical requirements which can be analysed and implemented by formalmethods and tools such as PETs. Currently, the process of translating high level require-ments (such as the results of a Privacy Impact Assessment) into technical requirements ispoorly known. There exist several challenges to translate descriptions from one languageinto another because the languages address different purposes and thus have differenttechniques of expression and focus on different aspects. Thus, while performing the trans-lation process, some details of the original description are often lost. Such effects must betaken into consideration with the guarantee that they do not affect the intended purposes.To address these challenges, promising approaches create a shared understanding of theprivacy domain by creating standard definitions in form of models and ontologies. We mayuse these standards to extend the existing analyses by integrating requirement engineer-ing mechanisms, best practices, design pattern, and other well-experienced techniques.

In PRECIOSA we use ontologies to support the provision of privacy, to provide a vocab-ulary for describing information flows and privacy protection requirements, and to specifyindicators which we evaluate for privacy analysis. In the following we describe the ap-proach to perform some privacy analysis based on privacy ontologies to evaluate systemsregarding privacy properties. Afterwards we sketch how to integrate such a privacy anal-ysis into a Model Driven Engineering methodology which uses UML.

11.11.2010 IST-224201 57

Deliverable 16 1.0

3.3.1. Privacy Analysis

We perform privacy analysis on systems and applications to get/investigate and evaluateimportant privacy properties. Thus, we can evaluate if the developers implemented thespecified privacy requirements appropriately. Applications and systems have some prop-erties/behavior regarding privacy that directly result from design decisions. There existdifferent methodologies to design and develop cITS systems. Some of the methodologiesexplicitly state the assumptions and decision made in the design process. It’s not alwaysobvious how design decision influence privacy aspects. Therefore, we analyze the systemmodel at design time and monitor the system at runtime. This approach makes it possi-ble to evaluate the system for computing its privacy related properties, to detect potentialprivacy leakages, to describe its supported privacy range, and to formulate the systemsrequirements regarding privacy and data quality.

We analyze a system regarding privacy based on its formal description. The results ofsuch analysis influence the system design and the behaviour of running systems. Fromthe detection of privacy leakages while analyzing the processing of information we candefine appropriate P3L policies that can be enforced using our PeRA system.

In Deliverable D6 [4] we provide

• how to enhance existing model driven design processes with privacy aspects;

• a conceptualization approach using ontologies;

• a demonstration how to apply the approaches regarding a cITS scenario;

• different stages to perform privacy analysis in system’s life cycle;

• the general idea of design processes and how to adapt design process for privacy;

• how to detect violations of privacy constraints;

• how to calculate privacy indicators.

In the current state of the art there exists a gap between the definition of high level privacyrequirements and technical privacy requirements. Application designers have to bridgethis gap of translating high level privacy requirements into technical and vice versa. There-fore, they can apply requirements engineering techniques (see Figure 3.9). In followingiterations they can identify technical requirements which they derive from the combinationof functional and non-functional requirements, design decision, and other evolving sys-tem properties. Thus, a translation is always influenced by functional and non-functionalproperties as usability, safety aspects, security aspects, and others.

The purpose of the privacy analysis is to detect violations of privacy constraints. Thereby,the system designer has not to be aware of all privacy principles and regulations. Suchprivacy constraints have to be described by models as the PRECIOSA ontologies. Thus,we can check for domain independent and domain dependent constraint which domainexperts model independent of applications. The privacy analysis provides hints for poten-tial privacy threats and may suggest fitting PETs (e.g. as done by [14] for compositionconstraints of components).

11.11.2010 IST-224201 58

Deliverable 16 1.0

technical

specification of

requirements

high level

requirements

Stakeholders Engineers & Domain Experts

functional and non-functional

properties

performance…

translation process

perform analysis (model checking, simulation)

implementapplication

Figure 3.9.: Requirement Engineering in ICT

Figure 3.10 illustrates the process of the privacy analysis in PRECIOSA. We take as in-put a description of the system especially of the information flow (e.g. in PPQL) andevaluate the description to calculate indicators. Indicators may be privacy leakages asunrestricted/unpermitted operations on personal informations, guaranteed privacy crite-ria (e.g. data properties as values of privacy metrics, limited retention, applied accesscontrol), applied security mechanisms as encryption, data minimalization (identificationof unnecessary computation of information, e.g. which exceed specified purposes), andmore. The application of PETs (as the enforcement of P3L policies or the application ofanonymization mechanisms) can guarantee data properties as the degree of anonymiza-tion. To analyse the system we apply semantic technologies as ontologies in combinationwith reasoner to infer new information and detect the violation of constraints. We can usethe calculated indicators to find an optimal or an appropriate PET to address a detectedprivacy leakage, to evaluate the appropriate addressing of privacy leakages, to calculatethe privacy risk (or privacy implications as nudges [126]) for using the system/application,and more.

Still their exist some restrictions to apply such an analysis. To identify personal informa-tion, its composition, its identification, and to calculate indicators we have to create somestandard ontologies (as the partial domain ontologies of PRECIOSA) which define axiomshow to reason about the system description (information flow). Next the designer has tomap his data structures to the concepts of the standard ontologies. Companies alreadyapply such mechanisms in creating standards for information exchange and processing.

The design provides some more advantages as to arrange non functional application re-quirements with privacy requirements (e.g. to balance service quality and the privacyprotection level). Every operation on information may have some effect regarding privacyand data quality as preciseness which influences the service quality. Furthermore, the

11.11.2010 IST-224201 59

Deliverable 16 1.0

identifyoperation on

personal information

combine/inference new personal information

identify personal information

identify personal (quasi) identifiers

calculateanonymity of

data set

calculateprivacy effect

of an operation

identify (potential) privacy leakages

evaluate privacy risk

System model

...analyze system modelto calculate indicators

Metric(s) to

evaluate

indicators

privacy

protection

level

quality of

service

high low

high low

Figure 3.10.: Privacy analysis - define & evaluate indicators

privacy analysis may be used as basis for designing and ((semi) automatic) verifying theconformity of data processing units (DPU) regarding specified privacy criteria. PossibleDPUs are single components as a road side unit (RSU), compositions of components asa network of RSUs, systems as the infrastructure of a traffic monitoring center, or applica-tions the intersection collision warning.

In PeRA we use the privacy analysis to identify points of control and observation (PCOs)as operations on personal information (see Deliverable D7 [5]), to search for privacythreats/issues and test whether every information is attached with appropriate policies(see Deliverable D10 [9]).

Privacy Analysis of Information Flows

One mechanism we apply while the privacy analysis is the identification of potential privacyleakages. When modeling an ITS one may identify points of control and observation(PCOs). PCOs are specific points in the information flow of a certain application use casewhere the level of privacy provided by the system should be measured and verified.

In general, privacy effects should be analyzed when information is being processed as wellas when information is flowing from one entity to another and especially when information

11.11.2010 IST-224201 60

Deliverable 16 1.0

crosses domain boundaries. Analyzing the level of privacy when information crosses do-main boundaries is important because once information reaches a different domain moreinformation may be available it could be combined with, thus reducing the provided level ofprivacy, e.g., when service operator in the backend generate large centralized databasescontaining data about large populations of users.

Backes et al. [127] demonstrate the possibilities of the analysis of information flows ona more theoretical level but restricted to the information flow of locally executed sourcecode using a line-by-line analysis. In Deliverable D7 [5], we use the following steps fora comparable privacy analysis of information flows: 1. Model system architecture usinglayered reference model (entity, deployment, logical function, information flow views). 2.Identify attacks based on the modeled views and previously created adversary model. 3.Identify PCOs based on modeled views and identified attacks. 4. Evaluate PCOs andmeasure privacy level of system design with privacy metrics. 5. Repeat steps 1 to 4with alternative system designs. 6. Use the results to either select the best candidate forimplementation or to develop more alternatives.

3.3.2. Privacy by Design

During the PRECIOSA project, in the Deliverable D11 [8], we define a high-level processfor managing privacy. As you can see in Figure 3.11, the process covers three levels:Privacy Requirements Analysis, Privacy-aware Design and Implementation, and PrivacyVerification and Certification.

During the analysis phase, designers will seek to highlight the privacy requirements. Atthe end of this phase, the goal is to have identified the minimized set of data and theassociated policies. During the implementation phase, developers will design the appli-cation and the PET. At this level, as explain during the model driven engineering section,it is possible to use a UML-base solution. The advantage is that it is possible to keep atraceability between requirements and the design. Moreover, from a model, model trans-formation authorizes to generate P3L code in order to verify by ontologies some privacyproperties.

3.4. PRECIOSA Privacy Policies

In order to govern the access and use of data we use privacy policies. In general, suchpolicies grant access to an identity under specific conditions. In PRECIOSA we calledthese condition the context of the policy. All stakeholders can describe privacy require-ments in terms of policy rules. One major aspect of our system is that data is alwayscoupled with these policies which are always enforced.

In the context of PRECIOSA stakeholders can be divided into the following categories:

1. Data subject: the person the information is about,

11.11.2010 IST-224201 61

Deliverable 16 1.0

Figure 3.11.: Privacy Engineering Process

2. Data controller: who is responsible for the privacy protection (thus, liable in case ofprivacy violation),

3. Data processor: who implements and executes the system and acts in behalf of thedata controller, and

4. Privacy agency: who advocates the legal framework for protecting privacy and setsup the privacy requirements from legal perspective.

In our system all of these stakeholders define privacy policies. Consequently, require-ments of users, service providers, and from legal perspective are regarded and enforced.For PRECIOSA we developed the PRECIOSA Privacy Policy Language (P3L) which we in-troduce in the following section. A detailed description can be found in Deliverable 6 [4].

3.4.1. PRECIOSA Privacy Policy Language (P3L)

Requirements

In general, policy statements specify Who (e.g., user identities or roles) accesses What(resources or data), How (type of operation), Why (purpose and context), under which

11.11.2010 IST-224201 62

Deliverable 16 1.0

Conditions (preconditions and postconditions), and with which Obligations (if allowed ordenied).

For our PRECIOSA policy we identified the following requirements:

• describe the privacy criteria of different stakeholders;

• express different privacy protection level from no restrictions (e.g., without enforcedprivacy protection) up to maximum privacy protection (e.g., absolute privacy protec-tion – service may be not flexible or even not executable);

• express privacy ranges (e.g., as intervals of privacy metrics);

• different generality: describe privacy criteria for single applications and specific con-texts or for groups of applications (e.g., for application types) and general contexts;

• different granularity to select information which will be effected by/coupled with de-fined policy;

• not only restrict the control on the access and release of the information – but alsocontrol the information flow (e.g., as a permitted sequence of operation executionson information) as long as possible (e.g., inside a privacy aware perimeter see De-liverable 7 [5] and 10 [9]);

• consider the context of request to define the extend of policy validity;

• consider pre- and post-conditions of operation executions to define the extend ofpolicy validity;

• the language elements should be based on the vocabulary of the PRECIOSA on-tologies;

• provide a natural language syntax for human readability;

• provide an XML syntax to process (exchange and evaluate) policies;

• provide the translation of the natural language syntax into the XML syntax;

P3L Features

Name Date Location SpeedAllen 01-01-2010 Amsterdam 30Ben 01-01-2010 Berlin 30Clark 02-01-2010 Chicago 35Allen 02-01-2010 Dublin 50

Table 3.1.: Data base table “Positions”

11.11.2010 IST-224201 63

Deliverable 16 1.0

Data granularity P3L has several features and properties which differ from other pri-vacy policy languages. As mentioned in the introduction of this chapter P3L policies arealways coupled with data whose access is restricted by them. In this sense we distinguishbetween three level of data granularity a policy can refer to:

• Instance level: for example, a single data items

• Schema level: all data of one relational database schema

• Concept level: all concepts in a given ontology which correspond to the given con-cept

At instance level we select single values. Such values can also be structured data liketuples in a relational database. At schema level we use expressions on schema elementsto select a set of values. At concept level we select a set of values that share the sameconceptualization (i.e., the same semantics).

We explain data granularity with the help of a simple example using Table 3.1. Allen candefine a P3L policy by restricting the access on her speed data. For instance, she cancreate a policy attached to her first tuple of Table 3.1 regulating the access and furtheruse of the speed value “30” in “Amsterdam”. If she wants to use the same policy for allof her speed values in this table (“30” and “50”), she can define the policy for the holeschema “Speed” in Table “Positions”. If there are other data sets with other names (e.g.,velocity or pace) which also contain speed values and should be included in the policy, shecan define the policy for the hole concept “Speed”. That of course requires a predefinedontology with relations between the concepts “Speed”, “Velocity”, and “Pace”.

Permissions P3L only allows to specify permit operations but has no deny rules. Thatmean, all access which is not regulated by policies is refused per default.

Operations One major contribution of our P3L is the definition and granting of opera-tions on data. In most other policy languages users can restrict access or secondary useof data. We extend this approach by adding operations on data before access or sec-ondary use is granted. For instance, user Allen can restrict access of her speed values ofTable 3.1. That means, parties who has access can read her values and other parties hasno access and no further information. Perhaps Allen wants to allow somebody to use herdata in an aggregated or anonymized form, which does not violate her privacy. Therefore,she can define a policy which permits the access on her speed value after performing anoperation like an aggregation (e.g., calculate the average speed of all drivers in Amster-dam) on the data. In this case her original speed value is not released. In our PRECIOSAenvironment we also grant operations like store or send.

11.11.2010 IST-224201 64

Deliverable 16 1.0

Generation of new policies Performing an operation on data can create new data. Forinstance, calculating the average of all speed values of an user results in a new data value.Like all data in our system a policy has to be attached. We provide several mechanisms forthe generation of (maybe new) policies for new data. For example, users can predefine aso called post policy in the original policy which has granted the operation performed. Thispost policy will be coupled with the generated data. Other approaches are the definitionof standard mechanisms of creating policies depending on the operation and data type.

P3L Elements

A complete introduction of P3L can be found in Deliverable 6 [4]. In this section we presentan overview and discuss the most important elements.

Every P3L policy can be divided into a definition part and a statement part. The definitionpart contains elements that describe the metadata of the policy itself. The most importantelements of the definition part are the description of namespaces, schemata, level ofgranularity, and policy (e.g., policy ID, creator of policy, textual description). The statementpart of a P3L policy contains the permissions to execute operations. These permissionsare granted in a specified context (scope of validity) and under conditions that have to befulfilled before or after performing the requested operations.

The most important elements of the statement part are:

• Context: specifies the conditions under which the given policies is valid (e.g., systemvariables, type or name of inquirer, his purpose)

• Permit statement: defines the permission to perform operations on data

• Action statement: defines an action/operation that has to be triggered (e.g., deleteafter 3 months)

• Precondition: depends on the requested data (e.g., maximum speed value which isallowed to be processed)

• Post condition: depends on the result of the operation (e.g., the result of the opera-tion has a specific level of anonymity)

• Temporary variables: enables a chain of operations

• Post policy: will be attached to the result of the performed operation

As mentioned before, the context specifies the scope of validity of a policy, that is, whohas the permission, with which purpose, and under which conditions. For instance, thepolicy creator can specify an application or identity which has permissions on his data fora given purpose if several system conditions (like current time is between 8:00 a.m. and8:00 p.m.) are hold. It is also possible to define conditions on data with the help of theprecondition element. If a policy is defined for a hole schema (s. paragraph about datagranularity in Section 3.4.1) and therefore refers to several data items, it is possible torestrict some of this data values. For example, a policy coupled to both of Allen’s speed

11.11.2010 IST-224201 65

Deliverable 16 1.0

data in Table 3.1 can have a precondition like “speed < 40” which means that this policy isnot valid for the third tuple with speed value “50”.

The permit statement defines the operations on the data before access is granted. Theseoperations are controlled and performed by the Privacy Control Monitor (PCM) (rf. PRE-CIOSA architecture in Chapter 3.7). If the data should released without performing anoperation first, we use the term “retrieve” in order to be consistent with our syntax. Otherstatements permit operations on the data but do not grant access to the data itself. Thatmeans, it is possible to define policies which permits several operations on data but donot permit the access on any kind of data. An application, for example, which collects,aggregates, and sends data to a service provider does not need to access the data itselfif the PCM provides the aggregation function and performs the sending. Of course, inthis case the service provider who receives the data has access to it. In the PRECIOSAarchitecture the PCM as trusted component will enforce the policies and therefore performthe basic operations. We emphasize that it is an important requirement to keep the setof operations of P3L extensible. For PRECIOSA we predefined a set of operations whichenables a basic functionality as follows:

• All : permission to perform any operation

• Delete: occurs in the action part of a policy and has to be trigged

• Process-data: permission to apply a specified data transformation function. Suchfunctions are provided by the PCM or as certified functions by controlled applications(rf. PRECIOSA architecture in Chapter 3.7). Predefined functions are:

– Sum: calculating the sum of a set of values

– Avg: calculating the average of a set of values

– k-anonymize: generate a k-anonymization of a set of values

– l-diverse: generate a l-diverse version of a set of values

• Process-query: permission to perform a SQL-Light query (s. Chapter 3.5.3)

• Retrieve: permission to read data

• Send: permission to send data to a given destination

• Store: permission to store data

The post condition element defines conditions based on the result of an operation. Forexample, Allen can define a policy with the permission to read (“retrieve”) her speed dataafter calculating the average speed of all drivers in “Amsterdam” (of course all drivers inthis aggregation must have defined a similar policy). Furthermore, she restrict the resultof the aggregation by revealing them only if the calculated average speed is not lower thanher speed value. This constraint is called a post condition.

Action statements are obligation that have to be performed after access has been granted.A simple example is the obligation to delete some data after a certain period of time.

11.11.2010 IST-224201 66

Deliverable 16 1.0

Temporary variables can be used to refer to intermediate results of a policy, for examplethe result of an operation on data. Thus, it is possible to define another action statement(i.e., operation) on this temporary variable in the policy and enable a chain of operations.

Results of operations can be new data (e.g., the average value of original data) whichhas to have a policy attached. To explicitly couple a certain policy to such new data it ispossible to define or refer to a policy inside another policy as post policy.

P3L Syntax

We provide two formats to build P3L statements. The first format is a human readablesyntax similar to a script language or SQL and the second format is an XML representationwith a defined XML schema to exchange P3L statements. In this section, we present asimplified version of the syntax of P3L. Especially, we omit the hole definition part. Thecomplete syntax is presented in Deliverable 6 [4].

CONTEXT [<context>] ’{’

(PERMIT <operation> | ACTION <action_statement>)

ON <data> [AS <temporary_variable>]

[WITH <precondition>]

[WITH <post_condition>]

[POSTPOLICY <post_policy>]

’}’

All of the terms used in the syntax stand for the corresponding element describe above inSection 3.4.1.

3.5. Privacy-aware Request Processing

Systems and components often define dedicated interfaces to communicate with otherentities. With query languages such as SQL, systems can interpret, control, and monitorits information flow. The execution of queries in Privacy Aware Applications (PAA) needsadditional considerations when compared with those in other (traditional) applications.Beside the processing of data and the evaluation of queries on the data we must respectspecific privacy requirements. Therefore, we consider (and evaluate) information on theapplication data regarding privacy and information about the context while executing aquery. Such information is represented as metadata and coupled both with the applicationdata and with a request (query).

Usually, (query) execution environments transform a query into an internal (logical) repre-sentation. Executing a query usually results in the execution of a sequence of operationson internal representation of the data. At the end of a query execution the result is sentback to the requester.

11.11.2010 IST-224201 67

Deliverable 16 1.0

Figure 3.12.: Extended query execution environments according privacy requirements.

A major principle of PRECIOSA is to couple data (information) always with informationthat describes the requirements of the stakeholders regarding privacy. Those require-ments may restrict the execution of operations on data. Thus, while executing queries wedo not only perform operations on data; at the same time we also evaluate the correspond-ing privacy information and compute the effect of the request on the privacy requirementsof the data – see Figure 3.12. The effect of the query execution regarding privacy has tobe considered for coupling the result of the request with its (new/updated) privacy infor-mation. We propose the extensible PRECIOSA Privacy aware Query Language (PPQL)to express requests on a system. Requests formulated with PPQL contain statementsthat request to execute an operation on data. The set of operations is extensible. Forall supported operations we can calculate the privacy effect. Thereby, a PPQL operationmay be complex. For the context of PRECIOSA we therefore support the execution of(lightweight) SQL queries.

In Section 3.4 we propose the PRECIOSA Privacy Policy Language (P3L) for describingthe privacy requirements of the stakeholders. For a detailed description of the PPQL andP3L languages we refer to Deliverable D6 [4] and Deliverable D10 [9]. While executing arequest we evaluate if the privacy requirements (e.g. formulated in P3L) of the requesteddata are compatible with the context of the request and the privacy specification requestedby the inquiring data processor. In the following we describe the main idea to providea privacy aware processing of requests. In Appendix A.1 and Deliverable D10 [9] wedescribe the privacy aware request processing in more detail.

11.11.2010 IST-224201 68

Deliverable 16 1.0

3.5.1. PRECIOSA Privacy-aware Query Language (PPQL)

In Appendix A.1 and in Deliverable D6 [4] we comprehensively describe the main conceptsof the PRECIOSA Privacy aware Query Language (PPQL). We use PPQL to express re-quests on the system that we can evaluate regarding given privacy criteria. PPQL queriesdescribe requests to execute operations on data (see Figure 3.13). The set of PPQLoperations is extensible and for every supported operations we are able to calculate theprivacy effect of their execution.

query execution environment

PPQL-Query

Access GPS-value FROM sensor.GPS AS vehicle-location

Access current-time FROM system AS vehicle-time

Store vehicle-location, vehicle-time in ds.Traffic

Send vehicle-location, vehicle-timeTO TCC

Request Response

PPQL-Result of a send Request

location, time from ds.Traffic

Traffic

GPS

sensordata store

Speed

Weather

Figure 3.13.: Executing PPQL requests.

The PPQL (PRECIOSA Privacy aware Query Language) ontology provides a vocabularyto express system requests. PPQL requests contain a sequence of PPQL operation re-quests. We can evaluate every PPQL operation regarding stakeholders requirements.Requirements on requests may be defined regarding the execution context (e.g. sys-tem environment, time, location), the input data, or the result. Privacy requirements (e.g.specified in P3L) are one type of requirements which we support to evaluate for requestedPPQL operations.

The PPQL processor performs PPQL operations. PPQL access operations are specialoperations which access information from arbitrary sources as data stores, sensors, orsystem variables and provide the results within a controlled buffer. Requestors only re-trieve information (including result items) from the PPQL processor if they set the retrieveflag of the operation request to true. Requesting entities are able to execute operations(e.g. access sensor and communicate sensor value) on information without receiving theresult itself. Thereby, we circumstance issues dealing with the masquerade of information.As long the information is not retrieved by the requestor the data processor can guaran-tee that applications do not mask information with other information. Thus, we are moreflexible to permit operation sequences on different information.

Figure 3.14 illustrates the concepts PPQL-Operation, PPQL-OperationRequest, PPQL-Request, PPQL-Session, TemporaryVariable, PPQL-Processor, PPQL-Response, PPQL-Operation-Response, DataSelection, TemporaryVariableSelection, and their relationships.

11.11.2010 IST-224201 69

Deliverable 16 1.0

Temporary variables belong to the (one) PPQL session where they were created. Tem-porary variables contain the result items of performed operation requests. Thus, if therequestor wants to access result items the requestor may set the retrieve flag to true oraccess the result items via a further operation request which selects the desired temporaryvariables. Therefore, every PPQL-OperationRequest has a data selection. Data selectioninstances contain temporary variable selections which select result items. The PPQL pro-cessor creates for every temporary variable a temporary variable selection instance (therequestor specify the access name with provideResultAs) which can be used in furtheroperation requests to select this variable.

creates

Ontologies:ICT (base) ontologyPPQL ontology

PPQL

PPQLOperation

performs operationRequested

PPQLOperationRequest

DataSelectionhas

PPQLPPQL isPerfomed

contains

TemporaryPPQL creates

SessionRequest Within

containsprocess provideResultAs

TemporaryVariableS l i

p yVariableProcessor

PPQL

creates containsselects only

SelectionPPQLResponse

Q

contains

PPQLOperationResponse

t i

ResultItem

containsonly

contains

Figure 3.14.: Partial ontologies - part of PPQL ontology

In Deliverable D10 [9] we define some requirements that must be realized by PPQL oper-ations (including the execution of query languages).

11.11.2010 IST-224201 70

Deliverable 16 1.0

3.5.2. Policy driven processing

In Section 2.5.3 we describe existing approaches of policy driven processing of informa-tion. These approaches usually propose “server-centric architectures” for deploying andchecking privacy statement against user preferences. We propose two approaches whichprovide a policy driven processing of information in distributed systems. First, we describethe Policy-enabled Linked Data Server (PeLDS) before presenting the processing of PPQLand P3L.

Policy-enabled Linked Data Server

In [128] we propose a Policy-enabled Linked Data Server (PeLDS) which obeys user-defined access policies for the stored information in the Semantic Web. We take userdefined privacy settings and translate them into PeLDS access policies which we enforceusing PeLDS.

The Semantic Web as a new generation of the World Wide Web allows its users to sharecontent over the boundaries of applications and web sites. To achieve this goal, the re-sources of the WWW are annotated using machine-readable meta data. The principles ofLinked Data [129] describe a set of conventions how this meta data should be structuredand published. So far, no access control mechanism supporting fine-grained access poli-cies is available for Linked Data, although a number of fitting scenarios are conceivable.

With small extensions to Semantic Web technologies and Linked Data concepts, a dis-tributed approach is possible, where users retain fine-grained control over their data andare still able to combine their data with users on different systems. We describe ourconcept of a Policy-enabled Linked Data Server (PeLDS) obeying user-defined accesspolicies for the stored information. PeLDS also supports configurationfree distributed au-thentication. Access policies are expressed in a newly developed compact notation forthe Semantic Web Rule Language. Authentication is performed using SSL certificatesand the FOAF+SSL verification approach. We evaluate our concept using a prototypeimplementation and a distributed address book application.

Processing of PPQL and P3L

We already mentioned the principle to always couple data with its corresponding privacycriteria. As long as this principle is implemented and the system guarantees the enforce-ment of the privacy criteria the system preserves the data subjects privacy. Different tomost of the existing approaches is that we do not only enforce policies regarding the ac-cess of information. We enforce the privacy criteria for the whole information flow in thesystem which implements the principles and languages of PRECIOSA.

In PRECIOSA policies define permissions for performing operations on data. These per-missions are only valid for specific situations – the context of the permissions. To describe

11.11.2010 IST-224201 71

Deliverable 16 1.0

such situations the permissions are combined with restrictions (constraints). These per-missions are valid if a given situation fulfills all of the constraints. Thus, constraints definethe context when a policy allows the system to perform specific operations on data. Whileexecuting a request the system checks if the context of the request matches the contextof the policy.

The P3L (PRECIOSA Privacy Policy Language) ontology provides a primary vocabularyto express privacy criteria for the execution of PPQL requests. PPQL requests contain asequence of PPQL operation requests. We can evaluate every PPQL operation regard-ing stakeholders requirements. Requirements on requests may be defined regarding theexecution context (e.g. system environment, time, location), the input data, or the result.Privacy requirements (specified in P3L) are one type of requirements which we supportand evaluate regarding requested PPQL operations. P3L policies describe permissionsto execute PPQL requests and the consequences (new privacy criteria) of executing therequested operations. They are bound/coupled on data items. Policy statements describeat different levels of granularity and abstraction (e.g. data item, attribute values, ontologyconcepts, specific requestor, type of requestor, and more) the valid contexts where thepolicy creator permits the PPQL processor to perform a requested PPQL operation.

P3L policies contain complex P3L statements which are bags, sequences, or choices.P3L action statements trigger the execution of a PPQL operation request if a specifiedcontext arises, e.g. to execute the remove operation of information after some period oftime because the policy creator defined some limited retention for this information. P3Lstatements apply only on PPQL operation requests. We define P3L contexts using onlydata independent conditions. Data independent conditions define constraints on the infor-mation to be operated on. Therefore, we do not require accessing the information beforeevaluating the policies context. Simple P3L statements may presume conditions whichdefine constraints also on input information or result items of the requested operation.Thereby, simple statements define preconditions (e.g. location = “home”) and postcondi-tions (e.g. k-anonymity > “20”) for executing operations on information.

3.5.3. SQL-Light - DBMS Technology for Privacy-aware Query Processing

Systems such as PeRA which implement the execution of PPQL and P3L provide a privacyaware information flow. As part the information flow we also support the execution ofquery languages such as SQL. Therefore, we extend the processing of these languagesto calculate the privacy effect of executing their formulated queries. PeRA supports alightweight SQL language which we describe in the following.

SQL-Light is a SQL based language to query data of a relational database. In general wecannot calculate all possible privacy effects for statements of the SQL language. Thereexist several variants to query for some specific information. To protect all variants is toocomplex for many cases. For instance, to get a value of a sensitive attribute describinga person you can retrieve this information using indirect queries; thereby you exclude allvalues that are not true for the person you have in mind. At the end you excluded all

11.11.2010 IST-224201 72

Deliverable 16 1.0

possible values except one without querying directly for the information. To avoid thiscomplexity we restrict the expressiveness of SQL.

The main reason to restrict the SQL query language is the ability to calculate the privacyeffect from executing any query. For SQL-Light as for SQL we transform a query intoa sequence of operations. In the PeRA prototype we evaluate every single SQL Lightoperation regarding their privacy effects independently. Thus, in order to calculate theprivacy effects of one operation we take as input the data the operation is performed onand the privacy information of the data. If we have previously performed other operationson input data the privacy effect of these operations is part of the privacy information of thedata.

Example 1 SELECT AVG(speed) FROM Traffic, User WHERE User.name = ’Alice’ andUser.uid = Traffic.driver-uid

Example 2 SELECT SUM(driven-distance) FROM TollDeclarations WHERE user = ’Bob’and BETWEEN (date, ’2010-03-01’, current-date) and street-type = ’highway’

Example 3 SELECT vehicle-type, location FROM Traffic

Table 3.2.: SQL-Light examples

3.6. Privacy-aware Communication

Pseudonyms are widely considered a viable approach to achieve location privacy in cITScommunication systems, as outlined in Section 2.6. In the PRECIOSA project we evalu-ated requirements for pseudonym systems in vehicular communication systems and pro-posed an enhanced approach for systems with conditional pseudonymity that stronglyrestricts when pseudonyms can be resolved to identities and by whom.

3.6.1. Requirements for Pseudonym Systems

In the context of vehicular communication systems or inter-vehicular networks, the needfor privacy preserving mechanisms is considered by many as key factor to enable deploy-ment and achieve user acceptance of such systems. Thus, privacy is often named as oneof many requirements, often in the context of security. In [130] we dissected the singleabstract requirement privacy to obtain a comprehensive set of dedicated privacy require-ments. We also studied the different forces and relationships between requirements thatinfluence privacy in inter-vehicular networks.

We distinguish three groups of privacy-related requirements: basic system requirements,security requirements, and actual privacy requirements.

11.11.2010 IST-224201 73

Deliverable 16 1.0

Basic system requirements. Requirements in this category arise from the unique char-acteristics of the communication environment in vehicular networks. Because these re-quirements have to be fulfilled to ensure system functionality, they restrict and constrainmechanisms for privacy protection.

• Real-time constraints. Especially safety applications require that the latency of com-munication and message processing is kept to a minimum.

• Robustness. Vehicular communication systems must remain operational despitehigh mobility and frequent network topology changes.

• Scalability. Applications and communication mechanisms have to scale to potentiallylarge numbers of nodes.

• VC support. Vehicular communication systems have to support specific communica-tion patterns often based on broadcast communication, e.g., beaconing and geocast(cf. [131]).

Security requirements. Securing vehicular networks against intrusions and attacks isessential to provide a robust service.

• Authentication. The authentication of senders as vehicles is essential to be able touse received information in safety-critical applications.

• Accountability. In order to prevent misuse of the system and to assign liability toperpetrators accountability is required.

• Restricted credential usage. Usage of authentication credentials should be restrict-ed in time and parallel use to prevent Sybil attacks.

• Credential revocation. It should be possible to exclude a node from the network byinvalidating its authentication credentials.

Privacy requirements. Privacy is not a single, abstract requirement, but consists ofmultiple requirements that need to be fulfilled to provide privacy protection for drivers invehicular networks.

• Minimum disclosure. The amount of information that a user reveals in communi-cation should be kept to the minimum, i.e., no more information than required fornormal functionality of VC applications.

• Anonymity. A node should be anonymous within a set of potential senders. Due tothe requirement of accountability, only conditional anonymity is possible in VCS.

• Unlinkability. Unlinkability requires that the relations between two or more items ofinterests cannot be linked. Items of interest can be identifiable persons, vehicles,pseudonyms, and authentication credentials.

11.11.2010 IST-224201 74

Deliverable 16 1.0

real-timeconstraints VC support

scalabilityrobustness

basic systemrequirements

privacy requirements

minimumdisclosure

unlinkability

anonymity

dist. resolutionauthority

perfect forwardprivacy

security requirements

credentialrevocation

accountability

authentication

restrictedcredential usage

Figure 3.15.: Constraining (red-solid) and supporting (green-dotted) interrelations of pri-vacy requirements in vehicular communication systems.

• Distributed resolution authority. If pseudonymous credentials can be resolved to realidentities, the capability of identity resolution must be distributed between authoritiesso that cooperation of a number of distinct authorities is required to link an anony-mous credential to an individual.

• Perfect forward privacy. Resolution of one credential to an identity should not revealany information that decreases unlinkability of other credentials of the same user.

It is apparent that some requirements strongly influence other requirements. In [130] wefind that constraining relations only occur between requirements of different categories,while supporting relations exist between requirements of the same category. When de-signing vehicular communication systems the inter-relations between requirements, es-pecially between contradicting requirements, have to be addressed. Figure 3.15 providesan overview of the identified inter-relations. Notably, the privacy requirements distributedresolution authority and perfect forward privacy constrain the privacy infringing effects ofsuch security requirements as accountability. Distributed resolution authority ensures thatpseudonym-identity mappings are only accessible if multiple authorities agree that iden-tity resolution is required, and perfect forward privacy ensures minimum disclosure evenin the face of identity resolution, i.e., only messages under the resolved pseudonymousidentifier are linked to the driver, while messages send by the same vehicle under dif-ferent pseudonyms remain unlinkable. Section 3.6.2 outlines a scheme for conditionalpseudonymity that supports the listed requirements.

11.11.2010 IST-224201 75

Deliverable 16 1.0

3.6.2. Enhanced Conditional Pseudonymity

In [132] we proposed a new approach for conditional pseudonymity for vehicular networksthat does not rely on pseudonym-identity mappings to be stored by any party. Instead,resolution information is embedded in pseudonyms and can only be accessed when mul-tiple authorities cooperate. The privacy-preserving pseudonym issuance protocol ensuresthat pseudonyms contain valid resolution information but prevents issuing authorities fromcreating pseudonym-identity mappings. The protocols for privacy preserving pseudonymissuance and collaborative identity resolution ensure that the privacy requirements laid outby the previous Section are met.

We give a short summary of the V-token approach, a more detailed presentation can befound in deliverable D10 [9], as part of the communication privacy mechanisms.

At the core of the new scheme lies the reconsideration of the common assumption thatauthorities can be fully trusted with managing information that could render privacy mecha-nisms ineffective, e.g., pseudonym-identity mappings. Our approach follows the principlesof minimum disclosure and separation of concerns. The V-token approach achieves ac-countability without requiring authorities to store resolution information and prevents themfrom keeping it. The scheme also benefits authorities and pseudonym providers by help-ing them comply with privacy regulations and reducing the amount of sensitive informationto be managed.

This is achieved by embedding resolution information directly in pseudonym certificatesrather than having authorities store them. A vehicle identifier idV is encrypted with thecommonly known public key of the resolution authorities. Resulting ciphertexts, we callthem V-tokens, are unlinkable. Pseudonyms with embedded V-tokens are issued in a twophase protocol, which ensures that V-token content is valid but prevents issuing authori-ties from linking pseudonyms to vehicles by employing a blind signature scheme. In theauthentication phase, vehicles first authenticate themselves with their home CA and obtainblindly signed V-tokens. Subsequently, each V-token can be used once to anonymouslyobtain a pseudonym from a pseudonym provider. The pseudonym provider thereby in-cludes the V-token in the newly created certificate.

A vehicle uses the resulting pseudonym for normal message authentication, e.g., as out-lined by the SeVeCom project, which is unaffected by the embedded V-token. Figure 3.16depicts this process.

If required, pseudonym-identity resolution has to be performed collaboratively by multipleauthorities. To enforce this, the secret key corresponding to the public key of the resolutionauthorities is split in a secret sharing scheme among n authorities. A threshold of t author-ities is required to jointly decrypt the V-token embedded in a pseudonym to retrieve thelinking information. Thus, agreement must be reached that identity resolution is justifiedin the current case. The scheme also achieves perfect forward privacy because linking ofmultiple pseudonyms and therefore linking of messages send under different pseudonymsis prevented.

11.11.2010 IST-224201 76

Deliverable 16 1.0

PseudonymIssuance

Iden.tyResolu.on

Creden.alRevoca.on

PseudonymUsage

PPCAh

12

3

Figure 3.16.: Enhanced pseudonym issuance split into authentication and acquisitionphase (1+2), resulting in a pseudonym for inter-vehicular communication (3).

3.7. PRECIOSA Privacy-aware Architecture

In cooperative systems privacy can be achieved on different levels. Applications and ap-plication developers should practice data avoidance and data minimization and follow aPrivacy by Design approach. On a communication level, anonymity of individual nodesand unlinkability of messages should be guaranteed to prevent tracking. Privacy policiesenable users to specify how their data should be treated.

In developing the PRECIOSA Privacy-enforcing Runtime Architecture for cooperative In-telligent Transportation Systems we followed two major design goals. First, a privacy-aware architecture should empower the user (the driver) to control the privacy of theirdata and personal information. The user must be able to specify through its system whatdata should be available to whom, in which context, in what granularity, and for how long.2

Privacy policies provide the means for such specifications in a machine readable, applica-tion independent form. Section 3.4 discussed the achievements of the PRECIOSA projectin that area. Privacy policies facilitate flexibility not possible with static privacy mecha-nisms. A user can specify for a single data item different usage purposes for different dataprocessors with different access granularity and distribute it once rather than having tocreate different versions of the data for different data processors.

However, the latter is only possible if policies can be effectively enforced. In current ICTsystems, privacy policies are often only stated and enforced on an organizational and con-tractual level. While privacy policies on that level are important from a legal perspective,they can be often circumvented with ease in terms of who can actually access the regu-lated data. Furthermore, the privacy policy is usually formulated by the service provider.The user, as the data subject, can only choose to accept or reject the policy, wherebyrejection is equivalent to not being able to use the desired service. But even if the useragrees to the service provider’s policy, there are no mechanisms or processes in place for

2cf. Westin’s definition of information privacy [133].

11.11.2010 IST-224201 77

Deliverable 16 1.0

MPC  Integrity  Protec/on  

Mandatory  Privacy  Control  

Policy   Personal  Data  

governs  use  enforces  policy  verifies  MPC  &  protects  data  

in  transit/storage  

Figure 3.17.: Protection chain of the PRECIOSA Privacy-enforcing Runtime Architecture(PeRA).

users to technically verify whether the service provider actually adheres to the policy thathas been stated during contract agreement.

With the PRECIOSA Privacy-enforcing Runtime Architecture (PeRA), we contribute acomprehensive systems for enforcing privacy policies on a system level. The PeRA en-sures policy compliance to user specified privacy policies whenever user data and per-sonal information are being processed. This enforcement can be technically verified.

The underlying concepts of the architecture have been outlined in deliverable D7 [5] asthe cITS runtime architecture framework. The cITS runtime reference architecture in de-liverable D7 [5] gave initial descriptions of architecture components. Deliverable D10 [9]contains comprehensive component specifications and constitutes the basis for the PRE-CIOSA reference implementation. The PeRA has also been presented internationally ininitial publications [134, 135], further papers are currently under preparation and are ex-pected to be published after the finalization of the project. The following is a high-leveldescription of the main architecture concepts and contributions. For further details werefer the reader to the aforementioned resources, especially D10, which also containsexamples on how the architecture can be applied to different application use cases. Deliv-erable D14 [7] reports on the integration of the architecture with a specific application.

3.7.1. Policy Enforcement Perimeter (PEP)

The Privacy-enforcing runtime architecture takes the step from mere organizational policyenforcement to technical policy enforcement – from faith to guarantee. The PeRA cre-ates a policy enforcement perimeter (PEP) in which privacy policies are enforced. Thatmeans when data or personal information is processed inside the PEP policy adherenceis guaranteed. Further, the PeRA ensures that only data that is allowed to leave thePEP does so and that the data is compliant with attached disclosure policies, e.g., certainanonymization requirements need to be fulfilled before the data is allowed to leave thePeRA-controlled PEP.

11.11.2010 IST-224201 78

Deliverable 16 1.0

PeRA protection chain

The policy enforcement perimeter is based on a multi-tiered protection chain (cf. Fig-ure 3.17) centered around personal data. The protection chain starts at the data source.When new data or information is created, it is securely coupled with a privacy policy, whichreflects the data subject’s privacy preferences. In the case of the PeRA, privacy policiesare specified in P3L (cf. Section 3.4.1).

These policies are enforced by Mandatory Privacy Control (MPC) mechanisms, whereverand whenever the governed data is being processed. MPC is comparable to well-knownMandatory Access Control (MAC) mechanisms that enforce security access policies ondata. Applications cannot access data directly, they can only gain access by posing queryrequests to the MPC components, which then mediate between requests and policies ofaffected data items to ensure that applications only receive policy compliant result sets.To achieve this, the MPC components act as a privacy middleware between applicationsand data that performs transformations on the data, e.g., to reach a desired anonymitylevel.

MPC Integrity Protection (MIP) has the purpose of ensuring the integrity of MPC compo-nents to guarantee that they operate as expected. Furthermore, MIP components ensuresecure local storage and confidential communication of data.

The resulting policy enforcement perimeter can provide both local and distributed privacyprotection.

Local policy enforcement

The PeRA can provide privacy control locally on a single cITS towards applications runningon that node. In the local case, the running PeRA instance defines the Policy EnforcementPerimeter. Figure 3.18 shows the PeRA and its components organized according to MPCand MIP functionality.

The application on top can pose queries for data access via the Importer and receives re-sults from the Exporter. The Privacy Control Monitor (PCM) is the main component of theMPC layer, responsible for policy compliant query processing. The Privacy Policy Man-ager handles resolution of policy URIs to actual P3L policies and manages data-policycoupling. The purpose of the Privacy Trail Manager is to record all queries and processesto provide verifiability. The Query Intrusion Detection System (Query IDS) monitors incom-ing queries to detect anomalies. For example consecutive data base probing. The DataRetention Manager handles privacy maintenance. It ensures that data items are fullydeleted when their retention period has expired. Section 3.7.3 provides further details onthese components.

The main component of the MIP layer is the Trust Manager which handles integrity mea-surement of all other components and only grants database access or the decryption ofrequests if the PeRA instance is in a trusted state. The Trust Manager interacts with aHardware Security Module to securely store key material and integrity measurements. All

11.11.2010 IST-224201 79

Deliverable 16 1.0

cITS  node  

PeRA  

Privacy  Control  Monitor  

Secure  Local  Storage  

App  

Importer/Exporter  

Trust  Manager  

Privacy  Policy  

Manager  

Reten/on  Manager  

Privacy  Trail  

Manager  

Query  IDS  MPC  

CAE  

cApp  

MIP  

Figure 3.18.: Local policy enforcement with PeRA.

data is stored in the secure data/metadata repository. Section 3.7.4 elaborates further onMPC integrity protection mechanisms.

The Controlled Application Environment (CAE) enables certain applications to gain moredirect access to data by enforcing strong restrictions on their storage and communicationcapabilities. Section 3.7.2 provides details.

Distributed policy enforcement

When multiple cITS nodes communicate with each other a distributed policy enforcementperimeter is created spanning all nodes that run a PeRA instance. In such a distributedsetup communication between PeRA nodes is confidential and senders can be sure thatreceivers adhere to their privacy policies, because these are enforced b the receiver’sPeRA instance. Again, the MPC layer ensures policy compliance, and the MIP layerensures that data can only be accessed if components are in a trusted state.

Figure 3.19 illustrates the distributed cases with an abstract example. Here, two nodes, avehicle and a server, communicate with each other. Both nodes run their individual PeRAinstance. The Importer/Exporter components on both sides act as confidential communi-cation endpoints. When the vehicle sends data to the server, the data and accompanyingprivacy policies are encrypted with the server’s public key. The Trust Manager ensures thatreceived messages can only be encrypted by the Importer if the whole PeRA is in a trustedstate. Inside this distributed PEP, policies are technically guaranteed to be immutablybound to data and adhered to by all applications processing the data. Because, Importerand Exporter abstract from the origin of a query or the destination of a result/message, noother components need to be adapted to accommodate different communication media.

11.11.2010 IST-224201 80

Deliverable 16 1.0

Vehicle  

PeRA  

Server  

PeRA  

Secure  Local  Storage  

App  

Trust  Manager  

CAE  

cApp  

Secure  Local  Storage  

Trust  Manager  

CAE  

cApp  Policy  Enforcement  Perimeter  

Privacy  Control  Monitor  

Importer/Exporter  

Privacy  Control  Monitor  

Importer/Exporter  Data  +  Policy  

Figure 3.19.: Distributed policy enforcement with PeRA.

The PeRA also enables fine-grained privacy control when both nodes run multiple appli-cations, which may communicate with each other. Privacy policies can be specified perapplication, thus policy enforcement isolates information flows of different distributed ap-plications from each other. Applications can benefit from tailored privacy mechanisms,without having to implement their own privacy enforcement mechanisms.

3.7.2. Enforcing Privacy for Individual Applications

While the PeRA architecture provides a number of horizontal services, custom applica-tion code is still needed to use the provided functionality and interact with the PeRA toachieve rich applications for the users. Depending on the type of application, the amountof user data that is necessary to fulfill application purposes can either be large or limited.Therefore, we provide two mechanisms for custom code to interact with the core architec-ture. The first are so-called uncontrolled applications and the second mechanism enablescontrolled applications. In both cases, applications never have direct access to data. Allaccess is instead mediated by the core components of the PeRA.

Uncontrolled applications have the advantage that they can be deployed with minor modifi-cations to existing code, because they run outside the PEP. They access data only throughthe query API provided by the generic core. Because all data access of external appli-cations is mediated by the PeRA components, these external applications do not needto be verified manually. All data they can access is necessarily policy compliant due tothe checks done by the PeRA. This allows for easier deployment and upgrading of ap-plications. However, access to unaggregated personal information will usually be limitedfor uncontrolled applications. This is due to the fact that data returned to uncontrolled

11.11.2010 IST-224201 81

Deliverable 16 1.0

applications leaves the PEP and further compliance to privacy policies is on a best effortlevel.

If applications need broader access to personal information, they need to be implementedas a controlled application. These Controlled Applications will then run inside the con-trolled application environment that oversees data flow to and from these applications.Controlled applications need to be provided as OSGi bundles, and they need to providemeta information about their role, purpose, and lifecycle. To be able to provide a gooddescription of the aforementioned properties, it is necessary that application developersrethink their application modularization. The goal is to break down all functionality thatneeds access to personal data into small parts with a clear role and purpose so that poli-cies can be evaluated in a meaningful way to grant or deny access. Depending on the levelof access to personal information needed, a manual certification of the whole applicationcode by a trusted third party can be necessary.

The controlled application environment then runs as a form of sandbox, which allowssome applications or application parts to run inside the PeRA with extended rights. Thecontrolled applications can only interact with the rest of the architecture via a specialinterface of the controlled application environment. Thus, the controlled application envi-ronment is able to annotate all controlled application requests with their role and purpose.Also, a defined lifecycle will be enforced on controlled applications. That is, if a statelesslifecycle is configured, applications will be reset between each invocation and, therefore,cannot accumulate long term state information or collect data. In addition, all data sentto a specific application instance is monitored. Therefore, the PCM can make worst-caseassumptions about the data available to an application instance and can make policy de-cisions accordingly. To enable a wider range of applications to work inside the controlledapplication environment, a further mechanism is provided. An application can, instead ofrequesting access to information stored in the database, declare that certain informationshould be sent out to another PeRA instance. This way, the data items themselves arenever known by the application, but the application can be sure that they will be sent tothe receiver.

Beyond the access to the controlled application environment interface, no further rights tocall outside components are granted. In particular, it is not possible for controlled appli-cations to freely access the filesystem or open network sockets. This way, we achieve asystem-wide privacy enforcement on an application, role, and purpose level. The providedmechanism still allows application providers to implement applications in a well-knownprogramming language. Thus, existing applications can be made privacy-aware with min-imized implementation effort. Of course, this mechanism cannot replace specialized al-gorithms provided by the PeRA that aim at data minimizations, but it provides applicationdevelopers a certain flexibility while still preserving user policies. Whenever there arecustom data minimization algorithms available, these should be given preference over ap-plication specific code. That is, applications should call the mechanism, which is providedby the PeRA, and only use the already minimized data.

11.11.2010 IST-224201 82

Deliverable 16 1.0

3.7.3. Mandatory Privacy Control (MPC)

The main component of the MPC layer is the Privacy Control Monitor (PCM). The PCMmediates access to the data repositories based on privacy policies. The employed con-cepts of privacy-aware request processing have been outlined in Section 3.5. The PCMemploys them to decide whether data can be accessed, and if anonymization and otherpost conditions need to be fulfilled. Query results are processed with data transformationsto meet these conditions. The PCM supports not only data retrieval, but also policy com-pliant data storage, modification, deletion, as well as the processing of send requests fromcontrolled applications and policy compliant access to in-vehicle sensors (e.g., GPS).

Thus, as the core component of the PeRA, the PCM concentrates privacy reasoning anddecision capabilities. The other components of the MPC layer support the PCM with sup-plementary functions. For example, the Privacy Policy Manager (PPM) handles all policyrelated operations, such as providing the PCM with the policies of data items affected bya query. The PPM also manages default policies for data items created in the vehicle bysensors and application output. Such policies could be set by drivers individually. Thus,the driver has control over what data leaves the car under which conditions by specifyingcorresponding privacy policies.

The PeRA further includes a privacy trail manager that provides logging capabilities for op-erations related to personal information. The resulting privacy trail facilitates verification ofprivacy policy compliant processing. Another support component, the data retention man-ager ensures that data is removed from the data repository when corresponding retentionperiods expire.

3.7.4. MPC Integrity Protection (MIP)

Drivers need to trust system components to treat their data appropriately. The PeRAprovides trust assurance for the driver – on a local level when the driver’s in-vehicle systememploys the PeRA for privacy policy enforcement and on a distributed level with PeRAenabled remote entities that process the driver’s data in the cooperative ITS. The MPCIntegrity protection layer of the PeRA is the root of trust of the aforementioned privacyprotection chain. In the distributed case, the MIP layers of PeRA enabled entities create apolicy enforcement perimeter inside the cooperative ITS.

The main component of the MIP layer is the Trust Manager which monitors the integrity ofMPC components, performs key management, and protects data with strong encryptionin transit and storage. Entities in the cooperative ITS running PeRA are equipped withHardware Security Modules (HSM). The Trust Manager performs its functions by utilizingthe HSM and trusted computing principles [134].

Each PeRA is equipped with a platform key pair. The corresponding private key is cre-ated and stored inside the HSM and sealed to a trusted state determined at deployment.Also at deployment time, a privacy authority certifies the platform public key after verifyingthat the PerA components operate properly and according to specification, and that the

11.11.2010 IST-224201 83

Deliverable 16 1.0

platform’s private key is indeed sealed to the verified state. When a PeRA instance (e.g.,in a vehicle) communicates with another PeRA enabled entity (e.g., a traffic managementserver), it encrypts outgoing messages with the remote PeRA’s platform public key. Thatpublic key certificate can either be deployed with applications that initiate this communica-tion or can be dynamically obtained. On the receiver side, the Trust Manager measuresthe integrity of the PeRA components on that node before attempting decryption. De-cryption is only successful if the current state matches the trusted state that platform’sprivate key is sealed to. Thus, the sender can trust that the sent data is only accessibleat the receiver if PeRA, and especially MPC components, work as expected, i.e., enforcethe attached privacy policies. We call this process non-interactive remote attestation, be-cause it provides implicit platform state attestation without requiring interactive messageexchange, which is preferable in an ITS scenario with intermittent connections.

Once decrypted, the data is processed by the PCM and controlled applications. If allowedby accompanying privacy policies, the data and its metadata may be stored in the localdata/metadata repository, which is fully encrypted. Similar to the platform private key,the database encryption keys are also stored and managed by the Trust Manager andits HSM. Access to the data repository is only granted if the PeRA is in a trusted statedetermined at deployment.

The PeRA has been integrated in a functioning prototype. For efficiency reasons, the in-tegrity measurement is split into static and dynamic measurement tasks. We assume atrusted boot sequence which loads our bootloader as the first PeRA component. In ourprototype implementation, the bootloader then takes consecutive integrity measurementsof the execution environment and all other PeRA components3. The resulting state mea-surement is stored inside the HSM. In our prototype, the platform configuration registers(PCR) of a TPM are used for this purpose. Then, the bootloader sets OSGi securitypolicies to regulate and restrict access to PeRA components, before loading all bundles.These settings are also measured and stored inside the HSM for integrity verification lateron. During operation, the security permissions are continuously monitored by the TrustManager to ensure valid security configurations before granting access to and decryptingthe database. Whenever any component of the PeRA or the execution environment isunloaded or an untrusted state is detected, the PeRA automatically shuts down and theTrust Manager invalidates previous integrity measurement results to prevent modificationof core bundles or bypassing of policy enforcement. Only a clean startup with the PeRAbootloader to a trusted state can restore access to key material and data.

The major contributions of the PRECIOSA PeRA described above facilitate drivers to placethe trust in remote systems that their data is only used according to their specified privacypolicies. The combination of non-interactive remote attestation, continuous integrity mea-surement of the PeRA’s state and privacy trails achieves a balance between transparencyof employed trust technology and privacy verifiability for the benefit of drivers.

3Our prototype relies on an OSGi framework with all PeRA components developed as OSGi bundles.

11.11.2010 IST-224201 84

4. Open Issues and New Challenges

In the previous sections, we have highlighted the development of the state-of-the-art andour own contributions during the project lifetime. During our work, we have also identifieda multitude of new issues and challenges that we could not fully address until PRECIOSAwas concluded. In this chapter, we provide a discussion of these challenges as a guidancefor future research.

4.1. Privacy Modeling

4.1.1. Ontologies

We already presented the advantages of using privacy ontologies at different stages inthe software/system life cycle. We also provide some base privacy ontologies. Such pri-vacy ontologies need to be standardized and refined by the different stakeholders. Asmentioned before we have to consider domain specific aspects to provide the best degreeof privacy protection. Therefore, we refine/extend the base privacy ontologies by domainspecific concepts (see also Deliverable D6 [4]). Thus, we need to standardize processes,best practices, and design pattern which guides designers and engineers to develop ap-propriate ontologies for their problem domain. The area of requirement engineering andthe area of formal privacy verification appear very promising but have to be further refinedand adapted to the identified challenges. For instance one challenge is to combine domainknowledge (as in form of ontologies) with privacy metrics for privacy analysis purposes.We also need to further explore and evaluate how to use ontology mechanisms for privacyanalysis.

4.1.2. MDE-based Approach

In this section, future challenges on MDE-based approach for privacy are detailed. Tounderstand the future challenges on this area, it is necessary to remember a key point ofMDE: horizontal separation of concerns.

Different stakeholders occur throughout the life cycle of a product. For example, youwill find software and hardware architects or privacy specialists. Each contributor willmanipulate its own artifacts. For this, they will develop specific models (see Figure 4.1).

85

Deliverable 16 1.0

Figure 4.1.: Example of horizontal separation in MDE process

Thanks to an MDE process, it is possible to verify the coherence and the consistencybetween all models. For instance, a privacy specialist could verify that encryption mecha-nisms are provided in the software architecture. Also, the software architecture can verifythe presence of a TPM (Trust Platform Module).

In PRECIOSA, we have provided a first contribution for MDE privacy-aware process. Themetamodel constitutes the backbone of a privacy process. However, it is necessary todetail and fix many issues:

• a definition of all needed artifacts. It is necessary to define all concepts and artifactsused by each stakeholder.

• a representation. If a tool doesn’t support a friendly view, it is useless. It is necessaryto adapt MDE to usual representation of the domain.

In order to propose solutions for these two issues, specialists of several businesses haveto define the notion of privacy, a generic process, representations and so one. All of thiscould conclude on a standard and can be used for MDE work.

4.2. Privacy Metrics

Although within the PRECIOSA project we have made important research progresses inthe development of a measurement and evaluation methodology for location privacy incITS, there are still research challenges to address in our future work.

Our work so far is mainly conceptual in nature. Although in our work, the correctnessand feasibility has been evaluated extensively by case studies and simulations, the actualapplication of the location privacy metrics on a real system will definitely require moreissues to be addressed. Even though the system is not there yet, we can imagine thatthe future cITS will be an extremely large and complex system. Our metrics measurethe information obtained by an imaginary attacker to reflect the level of location privacy incITS. In the real system, the challenge is to identify and list all possible information related

11.11.2010 IST-224201 86

Deliverable 16 1.0

to location privacy. Such information should be assessed to decide which information willbe publicly available and which will be “attackable”. In addition, whether our modelingapproach and calculation can withstand the scalability issue in the real system has yet tobe studied. Looking forward, we think a heuristic approach might tackle various researchquestions in the real system in the near future.

Our trip-based location privacy metric takes a pragmatic approach to capture and reflectthe level of location privacy in cITS, i.e., using the information on the individual-trip relationas the object of measurement. However, it is also possible that different users will havedifferent privacy-sensitivities in their vehicle movements. For example, some users mightregard their working places public but their home addresses private. Others might be in-sensitive to the normal vehicle movements, but wish to keep some of the one-time visitssuch as a visit to the casino private. As a result, how to take the different privacy pref-erences into consideration and define a preference-aware privacy metric, reflecting theprivacy values in a holistic approach is an interesting and challenging research issue.

Based on the current trend, it is reasonable to predict that in the near future, more andmore personal and sensitive information will be exposed and become publicly available.Due to the existence of such a “information eco-system”, privacy of the users of cITScan no longer be determined separately. Innocent information might be combined withthe information from other sources to gain extensive knowledge and profile an individual.Privacy metrics in such an information eco-system pose very challenging research prob-lems and must be addressed by a combination of expertise from a wide range of researchfields, such as privacy in social networks, privacy in Geo-information systems,privacy inhealth-care systems, etc.

For vehicle tracking , we see several approaches, how to refine the tracking and to diversifyexisting attacker models. One of the biggest issues in improving the vehicle tracking is touse all available information a tracker could use. For example map information or statisticalinformation about the traffic flow could be taken into account when deciding, which samplebelongs to which track.

The global attacker model used in our simulations is a very special case of an attacker,which under real conditions will (hopefully) occur very rarely. But it helped to understandhow powerful tracking algorithms can be. On this basis, we will refine the tracker modeland weaken its power in order to be more realistic. As only very few attempts have beenmade to run prototypes of vehicular networks and measure important parameters liketransmission range, robustness of the protocols against congestion and denial of serviceattacks, defining adversary models still requires to make lots of assumptions. We willobserve the ongoing efforts to deploy prototypes of vehicular networks in order to furtherrefine these assumptions and develop new kinds of attacker models.

11.11.2010 IST-224201 87

Deliverable 16 1.0

4.3. Privacy-aware Analysis and Software Design

4.3.1. Privacy analysis

Some challenges which we state for privacy ontologies do also apply for privacy awareanalysis. In current research privacy analysis mostly focuses to engineer privacy require-ments, to integrate/address privacy concerns/requirements into the design process, andto evaluate and verify systems regarding defined privacy requirements. Future activitiesshould also focus on other disciplines of system/software development to integrate privacyaspects and to enhance existing privacy solutions. Moreover, we have to provide a holisticapproach (such as the Privacy by Design Guidelines for ITS Applications in DeliverableD11 [8]) which better considers and integrates different disciplines.

Support engineering process We have to develop better support to ease the integra-tion of privacy concerns in existing engineering/design processes. One approach willbe to integrate technical privacy by design into the development cycle of applications.Requirement engineering mechanisms provide a promising foundation but have to be re-fined, extended, and their use has to be simplified. One of the resulting challenges is toefficiently gather the description of application or systems for privacy analysis.

Abstraction of problems and solution regarding privacy As in engineering theredoes not exist one final solution to implement privacy requirements. We have to abstractexisting solutions to create a foundation which we may use to evaluate, compare, andreuse privacy solutions. The definition of best practices, methodologies, and standardsmay help to create such a foundation.

Translation between high-level and formal privacy requirements For an appropri-ate privacy analysis we have to translate high level privacy requirements into technicalspecifications and vice versa the results from formal privacy analysis and privacy monitor-ing into high level privacy properties which stakeholder as user, data controller, and legalauthorities can handle.

High level requirements High level requirements such as privacy principles, privacyregulations, and other stakeholders privacy criteria influence the system design, the im-plementation of a system, and its configuration. We may define high level requirements asindicators which we can evaluate to detect privacy leakages. Additionally we can definecriteria for the successful application of appropriate measures for solving such identifiedleakages (as criteria/requirements for a privacy aware design). In Section 2.3.1 we alreadyidentified some challenges regarding formal privacy analysis.

11.11.2010 IST-224201 88

Deliverable 16 1.0

Extending formal languages for privacy The authors of [54] state that much workremains in extending formal languages which describe privacy criteria to handle moreforms of privacy. Given our experience in designing the P3L, we tend to agree and wouldadd that we should also aim at generalizing or combining domain specific privacy policylanguages. In the future, a person should not need to specify his privacy preferencesseparately for health, transport, or the Internet. Instead, one should be able to expressa general attitude towards privacy that is then translated for specific domains (with theoption of individual modifications where wished for).

Explore the use and extension for formal method tools Formal methods as code-level analysis combined with static analysis techniques have been successful applied atfinding correctness bugs (e.g. [136]) and security vulnerability (e.g. [137] [138]). An openissue is what kind of code-level reasoning should be applied for privacy, either to prove thata privacy policy is preserved or to discover a privacy violation. Machines can manipulateand analyse (e.g finding bugs and proving properties) formal specifications. Further workis required to explore the use and extension required for formal method tools (e.g. theoremprover, model checker) to verify privacy policies or to discover privacy violations.

Combine formal models with statistical ones Privacy has a statistical nature. There-fore, privacy raises new challenges for formal methods. Traditionally (as in security), theinformation flow is considered as black and white. We only check if a specific informa-tion flow has occurred which we classify as a violation. In privacy we consider differentquality aspects as the preciseness of information. For instance we may allow to publishanonymized/aggregated information instead of detailed/precise information. In the area offormal methods some work has been done on quantitative information flow which is inap-propriate for the statistical/probabilistic notion of privacy. Thus, we need to extend formalmethods to assure statistical guarantees rather black-and-white correctness guarantees.Therefore, we have to combine formal models with statistical ones.

Trade-offs between privacy and usability For privacy we also have to consider a newset of trade-offs/balances. For instance trustworthy computing requires to balance privacywith security, reliability, and usability. We need a formal understanding about the relation-ships of these properties. For instance we have to balance between the audit of data andthe provided degree of privacy. Further, to achieve reliability (especially availability) wereplicate data at different locations. Trade-offs between privacy and usability are similar tothe trade-offs between security and usability.

4.3.2. Privacy by Design

Privacy is a concept heavily influenced by a context of use. Indeed, according to variousparameters such as area (i.e., technical or legal) or even the country, the definition ofprivacy vary. Similarly, over time, this concept will evolve and will have an impact on

11.11.2010 IST-224201 89

Deliverable 16 1.0

privacy aware applications. For this reason, it is very difficult to design static tools or fixedmethodologies to develop applications that meet identified privacy requirements.

As has been done for common criteria for security, to develop standards and norms seemsan essential step for privacy. However, the standard will have to be flexible and able toevolve according to changing context offers privacy. The definition of protection profileslike, e.g., done in the Common Criteria framework could be a viable way to achieve this.Privacy architectures and PETs should provide sufficient flexibility to be deployed in differ-ent areas or contexts.

For this, it will be necessary to bring together all relevant actors such as privacy specialistsbut also legal stakeholders. This kind of work will require a strong consortium as Europecan offer with eSafety1 or Article 29 working group.

Currently, an initiative of bill of rights for social networks, has identified a list of require-ments2:

1. Honesty: Honor your privacy policy and terms of service.

2. Clarity: Make sure that policies, terms of service, and settings are easy to find andunderstand.

3. Freedom of speech: Do not delete or modify my data without a clear policy andjustification.

4. Empowerment : Support assisting technologies and universal accessibility.

5. Self-protection: Support privacy-enhancing technologies.

6. Data minimization: Minimize the information I am required to provide and share withothers.

7. Control: Let me control my data, and don’t facilitate sharing it unless I agree first.

8. Predictability: Obtain my prior consent before significantly changing who can seemy data.

9. Data portability: Make it easy for me to obtain a copy of my data.

10. Protection: Treat my data as securely as your own confidential data unless I chooseto share it, and notify me if it is compromised.

11. Right to know: Show me how you are using my data and allow me to see who andwhat has access to it.

12. Right to self-define: Let me create more than one identity and use pseudonyms. Donot link them without my permission.

13. Right to appeal: Allow me to appeal punitive actions.

14. Right to withdraw: Allow me to delete my account, and remove my data.

1http://ec.europa.eu/information_society/activities/esafety/index_en.htm2http://cfp.acm.org/wordpress/?p=495

11.11.2010 IST-224201 90

Deliverable 16 1.0

As presented in the requirement lists, it seems natural to estimate that ITS is not specificand an domain-independent initiative can be launched. However, technical solutions tomeet these requirements may vary depending on the application domain.

4.4. Privacy-enhanced Policy Languages

In Chapter 3.4 we introduced our first approach of a policy for expressing privacy require-ments of stakeholders. Beside an access control our PRECIOSA Privacy Policy Language(P3L) also defines a way to regulate the use of personal data in secondary applications.But there are still research challenges for future work which we address in this chapter.

Negotiation In P3L we defined policies which are enforced by the system. A request foraccess or performing an operation on a specific data item can be evaluated and permittedor denied. If it is denied the requester can query another data item or perhaps performanother operation. But there is no negotiation algorithm between the requester and theuser who creates the policy. If the user specifies a wrong context, operation, or a higheranonymity than needed he cannot use the service the requester offers. So, there is theneed for a process between a user and a service provider to reach an agreement.

Process policies Data is always coupled with policies which are also stored in a data-base. We need database techniques for an efficient realization of this linking. If an appli-cation requests for access on data the context is evaluated first. Therefore, we need a wayfor also querying and processing policies, that is, a policy query language like SQL. Thenit is possible to build an optimizer which can decide whether to access the data requestedand then check their policies or to access policies (maybe defined on a schema) and thenread the corresponding data.

Continuous releases Our PRECIOSA policies only regulate the access and handlingof one data item. Often privacy concerns occur when several pieces of data are releasedand combined. Sometimes new information can be inferred which then violates privacy. Itwould be interesting to analyzed the combination of private data of previous transactionsand how policies can be used to prevent privacy violations in such situations.

Merging of policies If an application requests a set of data it gets back the data whoserequest was permitted each with a policy attached. Our policy language regulates alsothe ability of performing an operation on the data (e.g., perform an aggregation function).Thus, new data is created which has to get a new policy attached. In our current imple-mentation all policies of all requested data are concatenated and attached. In general,this leads to much more policies than needed for one data item (e.g., calculating the sumof several data values) and might even lead to contradictions where, e.g., one item that

11.11.2010 IST-224201 91

Deliverable 16 1.0

contributes to an average value prohibits an access while another data item allows it. Achallenge is to merge given policies in order to create a single new policy which regardsall old policies.

Privacy-aware definition of policies One aspect which we do not address in PRE-CIOSA is the fact that the policy itself can also contain private information. It is a futurechallenge to consider privacy concerns of releasing policies.

Compliance of PRECIOSA principles with existing language We might also checkfor the compliance of the developed PPQL and P3L principles with other languages asexisting query and policy languages.

Intuitive user interfaces Privacy policies have to be specified and presented at differentlevels of details and abstraction. Most stakeholders are not experts for privacy or accesscontrol. Therefore, we need intuitive user interfaces to provide transparency about appliedprivacy criteria and the processing of personal information to the stakeholders. Such aninterface has to provide simple and detailed configuration mechanisms and should give afeedback to the user about the consequences of the configured privacy criteria.

4.5. Privacy-aware Request Processing

Privacy-aware request processing is one of the core capabilities of the PRECIOSA sys-tem. It provides the tight coupling between data and policies and forms one of the basicbuilding blocks for the PeRA architecture. However, before any actual application of thePRECIOSA PeRA approach is possible there are several issues that must be investigatedto provide effective, efficient, and scalable solutions. In the following, we focus on thediscussion on database and policy related issues.

Among others, we see the following issues:

1. Policy updates: the PRECIOSA project does not handle any updates of privacypolicies and their impact. In particular, further investigation is needed how poli-cies should be changed by one data subject without impacting the preferences ofother data subjects. Furthermore, it might be necessary to check the set of poli-cies defined by one data subject if those are valid as a set and do not contain anycontradictory specifications. The semantic of changing policies over time also im-plies a model that handles past, present, and future processing of policies and theirinteraction with query/request evaluation.

2. A formal semantics for the P3L: such a formal semantics could be the basis forcomparing our privacy language with other privacy languages suggested in the lit-erature. Furthermore, performing transformations on (a set of) policies – including

11.11.2010 IST-224201 92

Deliverable 16 1.0

possible optimizations – also requires a formal semantics to ensure transformationcorrectness and soundness.

3. Optimization of policies: Similar to optimizing (relational) queries, we see the po-tential of preprocessing (sets of) policies to achieve normalized forms. Those formsthen could be the basis for optimization and a better processing together with theevaluation of the query submitted. In PRECIOSA this area has not been touched atall; however for real-world applications such a scalability optimization it is an impor-tant and necessary step.

4. Synchronous processing of data and privacy preferences: In PRECIOSA wealready perform the processing of data, privacy policies, and privacy preferencessynchronously. For this reason we designed and implemented our own processingengine for a limited set of PPQL statements and a restricted set of SQL statements,called SQL-light. Under these limitations we demonstrated the feasibility of this com-bined approach, but we clearly see the necessity to better understand a combinedprocessing and tight interaction of the two processes. The latter opens the possi-bilities for query optimization similar to the interaction of queries and integrity con-straints.

5. Extend policy processing to full SQL: For the PRECIOSA project we implementedour own query/privacy policy evaluation system that handles both evaluations syn-chronously. To handle the complexity and to focus on the principle approach welimited the syntax of the SQL language to some core concepts. For real applica-tions, the engine must be extended to evaluate more expressive SQL queries. Fur-thermore, such an extension then also requires an in-depth understanding of howpolicies impact the execution of more complex queries.

6. Policy lineage: While data lineage [139] has been a topic in data warehousingresearch for a long time to better understand query results, such an approach is alsonecessary when answering queries in the presence of policies/privacy preferences.It might be important for the requestor of data to fully understand the impact of a setof policies on the query result. At the same time it might be necessary to understandhow much privacy leakage occurs when providing access to individual policies. Hereit might be necessary to better understand how much knowledge an adversary mightgain by revealing policies of a data subject.

7. Accessing and processing ecrypted or decrypted data: In PRECIOSA, the data-base is currently encrypted as a whole thus making it necessary to retrieve thecomplete content into main memory before decrypting it for processing. Such anapproach potentially allows an adversary to access the complete database whilebeing stored in main memory. Therefore, it might be important to access and to de-crypt the database on a finer granularity – such as tuples – or to access or operateon the encrypted data. The work by Evdokimov and Günther [140] and by Evdoki-mov, Fischmann, and Günther [141] already demonstrates how to execute partiallySQL queries on encrypted data. A similar approach could be incorporated into thePRECIOSA PeRA architecture.

11.11.2010 IST-224201 93

Deliverable 16 1.0

8. Domain knowledge on locality/position: Our PPQL language and the processingof data does not inherently include the concept of location as a “first class concept”.That is, PRECIOSA emphasized the privacy aware processing of requests, possiblywith positional data and privacy preferences regarding positional data location. InSection 2.5.3 we gave an overview on existing work that specifically focused on loca-tion aware privacy. The PRECIOSA project partially uses results from existing work;however we envisage embracing more of the actual (and future) results. For exam-ple, the work by Wang and Liu [142] who present a general model for privacy-awaremobile services which adopts the network-constrained mobility model (instead ofthe conventional random-waypoint model) to capture the privacy vulnerability of mo-bile users; at the same time it provides attack resilience (for mobile users), limits thequery processing cost (for service providers), and proposes important optimizationtechniques. Another approach to guarantee location privacy is based on mixes [78],called Mix Zones [143]. The concept of Mix Zones allows a system to disguise indi-vidual movements of cars, persons etc with different degrees of background knowl-edge. For example, knowing the exact roads or the destination of individual carsmight compromise their privacy.

Furthermore, there exist other approaches to guarantee location privacy based onother techniques. For example, the work by Ghinita, Kalnis, and Skiadopoulos [144]uses PIR (Privacy Information Retrieval) techniques to enforce location privacy. It isan open question how such PI base solutions and approaches could be incorporatedinto the PRECIOSA architecture. Including them would enrich the PRECIOSA sys-tem by additional protection mechanism that would implement the data minimizationprinciple.

9. Privacy leakage by sequence of requests: If a user or adversary executes a se-quence of PRECIOSA request that each conform to the respective privacy policies,it might still happen that the results of such a sequence of requests could violatethe overall policy and allows inference of (private) information. Currently, almost allsystems focus on one query/request at a time to protect privacy rather than takinginto account the results of previous request. Conceptually, each request result –even if the request is rejected and returns an empty result – increases the adver-saries background knowledge that can be combined with the results of the previousrequests. Already in 1978, work by Denning, Denning, Schlör, and Schwarz showedhow to rediscover information on individuals from aggregated data by submitting au-tomatically generated queries to the database [145, 146]. It is currently an openproblem if results of their work immediately applies when accessing k-anonymizeddata.

11.11.2010 IST-224201 94

Deliverable 16 1.0

4.6. Privacy-aware Communication

4.6.1. Pseudonyms

Regarding pseudonyms in vehicular networks, several issues remain open, which have tobe answered before the deployment of the systems can take place.

One undecided issue is the need and lawfulness of pseudonym resolution. There arearguments in favour of a pseudonym provider being able to resolve the real identity of apseudonym, which is used as a short time identifier during communication which othervehicles. Resolving is necessary, if it should be possible to use recorded messages asevidence to prove a drivers guilty, for example in case of an accident. There exist severaltechniques, i.e. conditional pseudonymity approaches (see chapter 3.6.2), which dis-tribute the mapping information among several parties, avoiding the necessity to have onesingle entity knowing the connection between all pseudonyms and their real identities. Butas every vehicle is equipped with a licence plate for identification, deanonymisation mightnot be necessary for law enforcement. If the mapping could be omitted, it would allow thedrivers to use additional security applications based on vehicular networks anonymously,without the fear of risking privacy.

As European data protection directives only permit to store or process personal sensitivedata with a strict purpose binding and the consent of the data subject, today there is no le-gal basis to store the information necessary for the eventual resolving of the pseudonyms.This question, if we need laws which enforce the additional gathering of personal informa-tion in large databases at the pseudonym providers, has to be answered by researchers,but also by data protection officers and politicians.

Another topic, which has to be further investigated on is the amount of pseudonyms, avehicle is able to actively us in parallel, and for how long these pseudonyms can be useduntil they expire. On the one hand, the validity of the pseudonyms has to be restricted toavoid the need for revocation mechanisms. To make sure not to run out of pseudonymsin areas where no connection to a pseudonym provider can be established or it would beto costly to transfer the data via the local telecommunication provider (e.g. when travel-ling abroad) it should be possible to have a large pool of pseudonyms available. On theother hand, generation, retrieval and storage of pseudonyms are efforts which can not beneglected, so it would be a waste of resources, if large quantities of pseudonyms expireunused. In addition, in case of an attacker compromising the private key storage of a ve-hicle, the more pseudonyms an attacker can retrieve, the more harm it may cause withouta chance of revoking the lost pseudonyms.

A question which is directly connected to the mentioned above is in which situation andhow often a pseudonym should be changed, or for how long one pseudonym should beused. Yet current ad-hoc solutions propose only simple rules for pseudonym change.Pseudonyms should not be wasted, so a pseudonym change should be avoided in sit-uations where it does not have any privacy preserving effect or I would be trivial for anattacker to connect the traces before and after the pseudonym change. In some criticalsituations, e.g. when there is a risk of accident, a pseudonym change can even have a

11.11.2010 IST-224201 95

Deliverable 16 1.0

negative impact on the safety applications. In those cases, pseudonym changes shouldbe avoided or at least delayed. But there is no answer yet, when pseudonyms have to bechanged in order to preserve a certain level of privacy to successfully prevent tracking.With the help of the privacy metric described in Section 3.2, we will compare differentkinds of pseudonym change strategies in order to find an satisfying answer to the posedquestion.

4.6.2. Communication aspects of policy enforcement

Besides the outlined challenges in the area of pseudonymity, we also identified challengesfor future work related to communication aspects of privacy policy enforcement, as pro-posed with the PRECIOSA Privacy-enforcing Runtime Architecture (PeRA).

A secure coupling between data and policies is essential to ensure that the policies spec-ified by the data source cannot be modified or changed when being processed by otherentities. The PeRA ensures this with encrypted communication between PeRA instances.Additionally, data-metadata is coupled by digital signatures. This enables the PCM of adata processor to verify that the referenced policies were created by the data subject. Anissue with this approach is the reliance on public key certificates for verification. In orderto verify that a policy has been set by the data owner, data and certificate may need tocontain identity information. This information may be pseudonymous but some kind of linkbetween certificate and data is required for meaningful verification of the coupling. Thus,signatures (and signer certificates) as well as policies can be considered personal iden-tifiable information (PII). The PeRA addresses this issue by storing received policies andcouplings in the encrypted metadata repository. Advanced mechanisms and protocols arerequired that enable the verification of data-policy couplings without that information beingprivacy-sensitive in itself. Thus, mechanisms are required that enable data processors toverify that a policy has really been attached to data by the data owner, while providingbetter privacy protection than certificate based signatures.

Another challenge is policy enforcement in broadcast scenarios. The outlined mecha-nisms for distributed policy enforcement with a policy enforcement perimeter work wellin scenarios where receivers are known. Unicast communication is readily supported.Group or multicast communication with known peers can be realized with additional effort,e.g., by establishing group session keys. However, trusted communication in broadcastcommunication scenarios remains an open challenge. Especially when only a subset ofpotential receivers is known at sending time. The recent idea of position based cryp-tography [147] could provide an interesting approach for this issue in vehicle-to-vehiclecommunication. While only a theoretical model at the moment, position based cryptogra-phy could theoretically bind decryption keys to locations rather than node identities. Thiswould require a shift of trust from individual nodes to certain areas, with consequences onunderlying trust models and privacy-aware application design. However, position basedcryptography is only a very recent topic. Viable encryption schemes need to be developedfirst and prove their merit. Major challenges in this area are secure positioning, efficiency,and the question how to protect against adversaries in the designated area.

11.11.2010 IST-224201 96

Deliverable 16 1.0

4.7. Privacy-aware Architectures

In the PRECIOSA project, we proposed the Privacy-enforcing Runtime Architecture(PeRA) as a privacy-aware architecture for cooperative ITS that utilizes the flexibility ofprivacy policy enforcement to support many different architectures. In the course of ourwork we uncovered many challenges and open issues that could not be solved in thisproject’s time frame. In the following, we discuss open issues and challenges in the fol-lowing categories: controlling execution of applications, trusted computing and encryption,as well as the promise of holistic privacy architectures.

4.7.1. Controlled application execution

Essentially, the controlled application environment currently provides custom applicationswith a means to express their role and purpose in a certified way, as well as to enforcea certain lifecycle of applications. Furthermore, outside access is limited to one singleinterface of the controlled application environment. Even if the application code itself isnot manually verified line by line, this still provides a good privacy protection for manysimple application use cases. For instance, an application that periodically sends out adata record can be coupled with a specific role and purpose and can be enforced to bestateless. So the application will not be able to collect larger sets of data but can onlysend out one single record at a time, if policies are set accordingly. It will also not be ableto assume a different role or purpose.

Beyond what is implemented, the future vision for the controlled application environment isto provide a wide range of information flow controls while minimizing, or even eliminating,the need for manual code review. The currently implemented flow control mechanismsare relatively simple, yet effective, and provide insight on further possibilities. Ideally, allapplication code could be automatically analyzed and reasoned about in the future. Onepossibility is to try and analyze all information flow to and from applications. However,the possibilities to hide sensitive information in other supposedly non-privacy-relevantitems are endless. Therefore, an alternative is to restrict controlled applications to beexpressed only in the form of a series of PPQL statements. If no further custom program-ming language code is present, then all actions of the applications can be automaticallyanalyzed.

Another important aspect of controlled applications is their interaction with the user inter-face. Generally, the user interface is a bi-directional communication channel to the outsideworld. Information presented to the user therefore leaves the privacy enforcement perime-ter. Also, users can enter arbitrary data without the system being able to process natureand type of the data. Thus, the possibility for a variety of covert channels exists in bothdirections. One possibility would be to treat all applications that present information to theuser as uncontrolled applications. However, this is not sufficient for some types of applica-tions. Imagine, for example, an application that allows the user to update profile settings,like the current postal address. Thus, there needs to be a way to handle data streams toand from user interfaces. Ideally, this mechanism should go beyond accepting that digital

11.11.2010 IST-224201 97

Deliverable 16 1.0

data protection stops at the boundary to the analog world. It is, however, unclear, if sucha goal is achievable, and to what extent it is so.

4.7.2. Trusted computing and encryption

The PRECIOSA PeRA employs trusted computing principles to ensure integrity of remoteinstances. Encryption is used to store and communicate data securely. For future work,many topics in this area deserve further attention.

The trust establishment and maintenance between entities in a distributed system, suchas a cooperative ITS, is rather static nowadays with hierarchically organized Public KeyInfrastructures (PKIs) being a common approach. However, the model of certifying anode at one point in time with the option of revoking that “trust” later on is not flexible andfine-grained enough to reflect and adapt to actual changes in trust levels and perceivedtrustworthiness. Future work should assess if current structures are appropriate to conveytrust and what is needed to improve them. Especially the implications of transitive trust onprivacy need to be scrutinized.

As another issue, work on hardware security modules is required. Hardware securitymodules need to be hardened against physical tampering and should provide crypto ac-celeration. While such devices are available today as cryptographic co-processors, theyare also prohibitively expensive for large scale deployment in vehicles. Current commod-ity solutions such as TPMs provide the general functionality of hardware security mod-ules, but do not support the characteristics stated above. In PRECIOSA, we advocateda systems approach to privacy. In the future, more capable commodity trust hardwareis needed to scale systems from mobile platforms and vehicular on-board units to serverenvironments.

Integrity protection and measurement of applications at runtime is also an interesting chal-lenge. Most integrity measurement solutions only provide integrity assurance at load-time.Running software also needs to be protected at runtime against malicious tampering likecode injection attacks in order to assert integrity. Promising approaches are starting to ap-pear in the area of dynamic integrity measurement, e.g., based on dynamic tracing [148].Further work should focus on extend these endeavor to arrive at flexible and robust dy-namic integrity measurement mechanisms.

Encryption plays an important role in protecting private information from preying eyes. Fulldatabase encryption works reasonably well as shown in our PeRA but when decryption isperformed much more data is being made available than required for most tasks. To en-hance privacy as well as efficiency advanced and adaptive encryption schemes could beused that employ encryption on multiple levels. Depending on read and write frequency ofspecific data, different keys could be used per database, table, row, or even for single datafields. Adaptive schemes could group related data items. Another interesting researchdirection that could enhance data privacy is searchable encryption. Here, search opera-tions are performed on the encrypted data rather than on the plain text data items. Therecent construction of a fully homomorphic encryption scheme [149] showed that it is the-oretically possible to perform arbitrary functions on encrypted data and obtain meaningfull

11.11.2010 IST-224201 98

Deliverable 16 1.0

(encrypted) results. The development of practical schemes that utilizes theses results isworth investigating. Operating on encrypted data could also reduce the reliance on trustedcomputing in distributed settings.

4.7.3. Holistic privacy architectures

A diverse range of Privacy Enhancing Technologies (PETs) exists for many purposes,like minimizing the spread of personal information (data avoidance and minimization),minimizing linkability between data and individuals (unlinkability and untraceability), andprivacy policies. Often PETs are used in combination to achieve privacy in a specificscenario.

The process of Privacy by Design fosters the development of privacy-aware applicationsthat either utilize existing PETs or require the development of new privacy mechanisms.Such mechanisms can be optimal for a given application, e.g., in terms of data minimiza-tion, but it may not be straightforward to adapt them to other applications with slightlydifferent requirement. Furthermore, the complexity of privacy mechanisms increases withthe complexity of applications. The use of multiple applications in parallel can also leakinformation. In future cooperative ITS a vehicle will most likely support and participate innumerous applications. While specialized PETs can protect privacy of single applicationsvery well, protecting privacy in the combination of applications is challenging.

The PRECIOSA PeRA could be a potential approach for cross application privacy. By pro-viding application independent privacy policy enforcement, such architectures can supportdifferent types of applications and arbitrate between application quality of service and userprivacy. Diverse applications can be made privacy aware with user-defined privacy poli-cies for such applications and privacy policy compliant processing of application data canbe ensured. A policy enforcement architecture does not take away the need for a privacyby design approach in software engineering but rather supports it. While legacy appli-cations can be privacy enhanced to some degree by integrating them into a PeRA likesystem, application requirements and privacy requirements can only be addressed prop-erly in a privacy-aware software design, which results in tailored privacy mechanisms perapplication.

Privacy aware applications and an application independent privacy policy enforcementarchitecture can either exist in parallel or be integrated. In the latter case, a PeRA likesystem can enforce the use of specialized data minimization PETs for specific applica-tions by policies. Privacy policies can also be attached to the output of privacy-awareapplications to ensure only purpose compliant use by other entities. For example, in aprivacy enhanced road tolling system, spotchecks and summary messages could be an-notated with privacy policies to ensure that the data is only used for billing purposes andnot marketing. How application specific and generic privacy mechanisms can be com-bined to achieve consistent privacy across applications is a notable challenge for futurework.

11.11.2010 IST-224201 99

5. Conclusion

This deliverable contributes to advanced research challenges at the level of privacy mea-surement and privacy of access. It puts into perspective the contributions of PRECIOSAto current research. We start this deliverable by presenting an updated view on the state-of-the-art in ITS privacy protection. Beyond what was presented in D4, we have identifiedmany more fields that became relevant during our work on PRECIOSA. In other fields,there was a big progress compared to what was presented two years ago which alsojustifies an update.

One of the observations from this literature review is that many researchers approachprivacy protection of specific ITS applications like pay-as-you-drive insurance or eTollingby designing protocols and systems that avoid processing or communication of personaldata wherever possible. This data minimization approach proved to be very successfuland results are convincing. However, during our work and discussion with both the ITSand the data protection community, we realized a significant problem. System and com-munication engineers strive for complex generic middleware systems, as the CVIS COMOand Local Dynamic Map approach illustrates. Not being build for any specific application,these systems aim at providing as much data as possible to a broad range of differentapplications. Such an approach has clear engineering and scalability advantages and willlikely not be ceased only due to data protection concerns. At the same time, not knowingwhat data applications really need later on, it is not possible to design tailored minimizedprotocols and architectures.

In realizing this gap, PRECIOSA took a different direction and focused on PETs for en-forcement of privacy policies. The result is the PeRA and its related technologies P3L andPPQL that are described herein and in more detail in Deliverables 6, 7, and 10. Based onthe concept of privacy policies that are tightly coupled with personal data and the idea of amandatory enforcement of these policies in a distributed system, PeRA should not be seenas a rivaling architecture to data minimization approaches but rather as a complementaryapproach that can be applied in cases where processing, storage, and dissemination ofpersonal data cannot be prevented by a minimization approach. The PeRA approach mayalso be useful when designing generic data middleware platforms that store and processpersonal data like vehicle position data in a generic way for use by a larger number ofdifferent applications for different purposes. Finally, it should always be used in a largercontext of a Privacy by Design process that also targets at data minimization whereverand whenever possible.

This leads over to our activities related to privacy modeling, privacy metrics, and privacy-aware analysis and software design. While details are given in other deliverables (D6,D11), we illustrate the need for a more technical approach to Privacy by Design and a

100

Deliverable 16 1.0

better embedding of it into technical software and system engineering. One of the ap-proaches we worked on in PRECIOSA tries to fuse the Model Driven Engineering (MDE)approach with privacy protection.

Given the broad range of activities and related technologies, it is evidently not possible tosolve all issues within a project of only 2.5 years duration. While we worked towards theaim of privacy-aware software engineering and mandatory enforcement of privacy poli-cies, any solved problem often created just more challenges. While providing a completearchitecture and prototypical implementation that demonstrates its feasibility, we thereforeconclude the project also with an extensive set of future challenges to be worked on in theupcoming years.

We consider both the privacy-aware software engineering and the mandatory enforcementof privacy policies to be generic approaches not tight to ITS and would advocate lookingat these mechanisms in a broader and more generic scope than this was possible inPRECIOSA, which always kept the focus to ITS.

11.11.2010 IST-224201 101

A. Appendix

A.1. Privacy-aware Request Processing

In Section 3.5 we describe the principles of PRECIOSA’s privacy aware request process-ing. In this Section we give additional information about the different topics for the inter-ested reader.

A.1.1. PRECIOSA Privacy-aware Query Language (PPQL)

We now describe the main concepts of the PRECIOSA Privacy aware Query Language(PPQL). We use PPQL to express requests on the system that we can evaluate regardinggiven privacy criteria. PPQL queries describe requests to execute operations on data (seeFigure 3.13). The set of PPQL operations is extensible and for every supported operationswe are able to calculate the privacy effect of their execution.

The PPQL (PRECIOSA Privacy aware Query Language) ontology provides a vocabularyto express system requests. PPQL requests contain a sequence of PPQL operation re-quests. We can evaluate every PPQL operation regarding stakeholders requirements.Requirements on requests may be defined regarding the execution context (e.g. sys-tem environment, time, location), the input data, or the result. Privacy requirements (e.g.specified in P3L) are one type of requirements which we support to evaluate for requestedPPQL operations.

Ontologies:ICT (base) ontology

OperationComponent ≡ Operation and t O

( ) gyPPQL ontology

PPQLProcessor

Access

operatesOn some (Data or

Information)isA

PPQLOperation

isAisA

performs

p

PPQLAccess

isA isA

Figure A.1.: Partial ontologies - PPQL ontology 1/5

102

Deliverable 16 1.0

Figure A.1 illustrates the concepts PPQL-Processor, PPQL-Operation, PPQL-Access, Re-trieve, and their relationships. The PPQL processor performs PPQL operations. PPQLaccess operations are special operations which access information from arbitrary sourcesas data stores, sensors, or system variables and provide the results within a controlledbuffer. Requestors only retrieve information (including result items) from the PPQL pro-cessor if they set the retrieve flag of the operation request to true. Requesting entities areable to execute operations (e.g. access sensor and communicate sensor value) on infor-mation without receiving the information itself. Thereby, we circumstance issues dealingwith the masquerade of information. As long the information is not retrieved by the re-questor the data processor can guarantee that applications do not mask information withother information. Thus, we are more flexible to permit operation sequences on differentinformation.

Figure A.2 illustrates the concepts Retrieve, PPQL-OperationRequest, PPQL-Request,PPQL-Response, PPQL-OperationResponse, and their relationships. Requestors mayspecify to retrieve the result items which the requested operation provides. Thereby, theoperation request becomes a retrieve request. PPQL requests contain only PPQL opera-tions. PPQL operations are not composed of other operations. Every PPQL request mayhave a corresponding PPQL respopnse. PPQL responses contain only PPQL responses.PPQL responses are not composed of other responses.

Ontologies:ICT (base) ontologyPPQL ontology

Request

contains i AisA

ResponsecorrespondingResponse

containsisA

gy

OperationRequest

contains isA

PPQLRequest

isA

OperationResponse

contains

t i

PPQLResponse

containsPPQL

OperationRequest

isA containsPPQL

OperationResponse

contains

Retrieve

contains onlycontains only≡ OperationRequest andoperationRequested some(Access or operationCreatessome ResultItem) and

retrieveResults value true

Figure A.2.: Partial ontologies - PPQL ontology 2/5

A request may have to perform a sequence of operations. The input of a subsequentoperation may require the output of a preceding operation. Thus, we need a mechanismto hold and access temporary results. We implement temporary results by the keywordAS. The schema is “OP on Data AS TemporaryResult”. In our example statement shown inFigure 3.13 we access data from different sources, combine the data, store the result in adata store, and send the result to a traffic control center. While performing these requests,the temporary variables are coupled with the appropriate privacy criteria. All temporaryvariables will be deleted after the request has been performed. Intermediate results and

11.11.2010 IST-224201 103

Deliverable 16 1.0

temporary data can be stored and accessed using a datastore. Thus, PPQL supports torealize a session based computation of data that contains several requests. ControlledApplications can be utilized if the access time to the data store is not acceptable or if thedata processor does not have the permission to store the temporary data.

Figure A.3 illustrates the concepts PPQL-Request, PPQL-Session, DurableSession, Tem-poraryVariable, PPQL-Processor, and their relationships. The PPQL processor processesPPQL requests within PPQL sessions. PPQL sessions are durable if the requestor set theflag createsDurableSession to true. The Processor might process multiple PPQL requests(as specified by the requestor with the openExistingSession parameter) within the samedurable session. PPQL sessions contain temporary variables. The lifetimes of the tem-porary variables end with the comprising session. Therefore, one can use temporaryvariables only in the session which contains the variable. PPQL sessions are bound to therequestor. Thus, only the owner of the session can access its temporary variables.

Ontologies:ICT (base) ontology

PPQL isA opens

ICT (base) ontologyPPQL ontology

Request

isPerfomedWithin

creates

PPQLRequest

isA opens

Session

isPerfomed

isA

Requestorowns

process

PPQLSession

DurableSession

isPerfomedWithin only

contains

TemporaryVariable

PPQLProcessor

creates ≡ Sessionand inv(createsSession) some (Requestand createsDurableSession value true)

Figure A.3.: Partial ontologies - PPQL ontology 3/5

Figure A.4 illustrates the concepts PPQL-Operation, PPQL-OperationRequest, PPQL-Request, PPQL-Session, TemporaryVariable, PPQL-Processor, PPQL-Response, PPQL-Operation-Response, DataSelection, TemporaryVariableSelection, and their relationships.As previously described for Figure A.3 temporary variables belong to the (one) PPQL ses-sion where they were created. Temporary variables contain the result items of performedoperation requests. Thus, if the requestor wants to access result items the requestor mayset the retrieve flag to true or access the result items via a further operation request whichselects the desired temporary variables. Therefore, every PPQL-OperationRequest has adata selection. Data selection instances contain temporary variable selections which se-lect result items. The PPQL processor creates for every temporary variable a temporary

11.11.2010 IST-224201 104

Deliverable 16 1.0

variable selection instance (the requestor specify the access name with provideResultAs)which can be used in further operation requests to select this variable.

creates

Ontologies:ICT (base) ontologyPPQL ontology

PPQL

PPQLOperation

performs operationRequested

PPQLOperationRequest

DataSelectionhas

PPQLPPQL isPerfomed

contains

TemporaryPPQL creates

SessionRequest Within

containsprocess provideResultAs

TemporaryVariableS l i

p yVariableProcessor

PPQL

creates containsselects only

SelectionPPQLResponse

Q

contains

PPQLOperationResponse

t i

ResultItem

containsonly

contains

Figure A.4.: Partial ontologies - PPQL ontology 4/5

Figure A.5 illustrates the concepts PPQL-Request, PPQL-Session, Variable, Temporary-Variable, PPQL-Processor, PPQL-OperationRequest, DataSelection, DataSelectionEle-ment, VariableSelection, TemporaryVariableSelection, and their relationships. Variablesin general contain information as system information. Temporary variables contain the re-sult items of performed operation requests. Thus, if the requestor wants to access resultitems the requestor may set the retrieve flag to true or access the result items via a furtheroperation request which selects the desired temporary variables. Therefore, every PPQL-OperationRequest has a data selection. Data selections contain data selection elementsof different types. Variable selections are data selection elements which select values ofvariables. Temporary variable selections are special variable selections which only selecttemporary variables. Hence, temporary variable selections select result items which thePPQL processor created beforehand. The PPQL processor creates for every temporaryvariable a temporary variable selection instance (the requestor specify the access name

11.11.2010 IST-224201 105

Deliverable 16 1.0

with provideResultAs) which can be used in further operation requests to select this vari-able.

Ontologies:ICT (base) ontology

contains only

ICT (base) ontologyPPQL ontology

PPQL

PPQLRequest

isPerfomedWithin onlyprocess

contains only

PPQLO iD S l i

has

PPQLSession

y

containscontains

Variable

isA

OperationRequest

DataSelectionInformation

contains

ResultItem

isAcontains

DataSelectionElement

V i bl

TemporaryVariable

isAPPQLProcessor

creates

selects

ResultItem only

VariableSelection

TemporaryisA

selects

provideResultAsselects only p yVariableSelection

pselects only

Figure A.5.: Partial ontologies - PPQL ontology 5/5

In Deliverable D10 [9] we define some requirements that must be realized by PPQL oper-ations (including the execution of query languages).

Figure A.6 illustrates the operations which we support as PPQL operations in our refer-ence Architecture PeRA (see Deliverable D10 [9] for more details on the PPQL opera-tions). This basic set of operations realize the previously mentioned requirements andenable some core functionality for a privacy aware processing of data. PeRA supportedPPQL operations are gather sensor value, anonymize table content, clear a whole datastore (especially single tables), store information, send information, and perform SQL-Litequery. The SQL-Lite language is a subset of SQL which has the property that we cancompute the privacy effect of executing a SQL-Lite statement.

11.11.2010 IST-224201 106

Deliverable 16 1.0

Ontologies:ICT (base) ontologydata storage ontologycommunication ontologydata storage privacy protection

Operation

isAPPQL

isA

i A

cITS ontologyPPQL ontologyPeRA ontology

Access

isAisA

Operation

PPQL

isAisA

i A

isAisA Communicate

isA

isA

Process

Store

Perform Update

isA

PPQLAccess

isA

isA GatherSensorValue

Send

PerformQuery

UpdateDataStore

isAPerform

TableAnonymization isA

ClearDataStore

PerformSQL-LiteQuery

Figure A.6.: Partial ontologies - part of the PeRA ontology

A.1.2. Policy driven processing

Processing of PPQL and P3L

In Section 3.5.2 we describe the principles of PRECIOSA’s policy driven processing. Inthis section we give additional information, thereby comprehensively describing how weprocess PPQL requests while enforcing P3L policies.

We already described the principle to always couple data with its corresponding privacycriteria. Policy couplings refer to the policy of the information as well as its state of execu-tion (data property sequenceNumber ). Data couplings and data item coupling are specialpolicy couplings. A data item coupling is the concept which we use to couple single dataelements with its policies. Data item couplings contain a data mapping. Data mappingsmap the materialized information provided by the PPQL processor with the informationdescriptions (policy elements) the policy statements are about; for instance we map thevalue “08:35:52” of the temporary variable creationTime with the policy element describedas result item pred:timestamp of the PPQL request Access-Sensor (“GPS-sensor”) On lo-cation:latitude, location:longitude, pred:timestamp As vehicle-lat, vehicle-long, timestamp.We use this data mapping for evaluating operation permissions regarding following PPQLrequests on the information. It is not possible to change existing policy couplings. Thus,we prevent that entities different from the data subject changes privacy criteria. The onlyway to alter policy couplings is to delete the data and hence the corresponding policy

11.11.2010 IST-224201 107

Deliverable 16 1.0

coupling. We introduce the concept of coupling instructions to define the creation of pol-icy couplings while importing or creating data. Coupling instructions can be changed bystakeholders regarding their stakeholder type. For instance only the data subject canchange its coupling instruction.

The following list describes the actions to process a PPQL request:

1. Provide context information of request

2. Get the right session for the request; a) create a new one, b) open a requested one

3. Get the history of the requestor

4. For each requested operation

• If possible (e.g. for a send operation) get the history of the reciever

• Preprocess the request: if possible extract information as the requested data(source) and operation to determine corresponding data coupling

• Fetch data coupling which corresponds to the requested data (before executingthe requested operation)

• Check if the privacy criteria of the request in combination with the current con-text is coherent with the privacy policies contained in the fetched data coupling

• For some operation as send and store provide/compute the privacy effect of theoperation (before its execution) as post policies and couple the resulting datacoupling with the data input of the requested operation

• Execute the requested operation

– Some privacy criteria (policies) might be just available performing the op-eration partially (e.g. performing the select, where, join operations of a sql-light query to filter/select requested data). Thus you have to check again ifthe request is compliant to the privacy criteria of the data

• If possible (not for operations as send and store) check the postconditions ofthe policies, i.e. whether the privacy criteria of the requested data (alloweddegree of privacy; e.g. allowed range of privacy properties like values of privacymetrics as k-anonymity) is coherent with the actual degree of privacy (e.g. valueof anonymity) of the result

– Yes: no problem

– No

a) Just provide the data items as result that confirm to its privacy criteria

b) Transform all requested data items to their most restrictive policies andprovide the adapted result

c) Reject the request with optional explanation

11.11.2010 IST-224201 108

Deliverable 16 1.0

• For some operation as data transformation functions provide/compute the pri-vacy effect of the operation (after its execution) as post policies and couple theresulting data coupling with the resulting data of the executed operation

• If possible (e.g. for a send operation) update the history of the reciever

• Update the history of the requestor

• Provide response (which may contain the result)

Conditionh P C diti

hasPostConditionOntologies:

DataDependentCondition

DataIndependentCondition

hasPreCondition policy ontologyP3L ontology

isA

Policy

PrivacyPolicy

isAStatement

isA

contains

Context

isDefinedBy onlyisValidFor

PrivacyPolicy

P3L-Policy

isAcontains Complex

StatementSimple

Statement

isAnextElementmax 1

contains only

Permission

isA

Bag Sequence Choice

isA

Action

isAy

PPQLOperationRequest

triggers only permits only

Request

Figure A.7.: Partial ontologies - P3L ontology 1/3

Figure A.7 illustrates the concepts DataDependentCondition, DataIndependentCondition,Action, Bag, Sequence, Choice, and their relationships. P3L policies contain only com-plex P3L statements which are bags, sequences, or choices. To support the definition ofa permitted sequence of PPQL operations we require to organize simple statements in alist (object property nextElement). In P3L simple statements are actions or permissions.P3L action statements trigger the execution of a PPQL operation request if a specifiedcontext arises, e.g. to execute the remove operation of information after some period oftime because the policy creator defined some limited retention for this information. P3Lstatements apply only on PPQL operation requests. We define P3L contexts using onlydata independent conditions. Data independent condition means here that the conditionsdoes not define constraints on the information to be operated on. Therefore, we do notrequire to access the information before evaluating the policies context. Simple P3L state-ments may presume conditions which define constraints also on input information or resultitems of the requested operation. Thereby, simple statements define preconditions (e.g.location = “home”) and postconditions (e.g. k-anonymity > “20”) for executing operationson information.

11.11.2010 IST-224201 109

Deliverable 16 1.0

coupled Ontologies:

PolicyCoupling Policy

isA

Policy

sequenceNumberinteger

isA

Ontologies:policy ontologyICT (base) ontologyPPQL ontologyP3L ontology

PrivacyPolicy

isA

isADataItemCoupling DataCoupling

isA

contains exactly 1 containscontains

t i l

P3L ontology

P3L-Policy

DataMappingpolicyElementdataElement

activeContext

contains exactly 1 contains

ComplexStatement

contains only

Information

DataSelectionElement

DataSelection

containsselects

p yda a e e

DataSelectionElement

creates PPQLOperationResultItem

PPQLOperation

operationRequested

Information

isAhas

containscouples

TemporaryVariable

RequestOperation

PPQLOperationResponse contains

Figure A.8.: Partial ontologies - P3L ontology 2/3

Figure A.8 illustrates the concepts PolicyCoupling, DataCoupling, DataItemCoupling,DataMapping, and their relationships. One important principle of P3L is that we alwayscouple information with its corresponding policies. Policy couplings refer to the policy ofthe information as well as its state of execution (data property sequenceNumber ). Westore the state of execution in case the PPQL processor has started to execute a se-quence permission of the policy. A data item coupling is the concept which we use tocouple single data elements with its policies. Data item couplings contain a data mapping.Data mappings map the materialized information provided by the PPQL processor with theinformation descriptions (policy elements) the policy statements are about; for instance wemap the value “08:35:52” of the temporary variable creationTime with the policy elementdescribed as result item pred:timestamp of the PPQL request Access-Sensor (“GPS-sensor”) On location:latitude, location:longitude, pred:timestamp As vehicle-lat, vehicle-long, timestamp. We use this data mapping for evaluating operation permissions regard-ing following PPQL requests on the information. Upon we finish the execution of opera-tions which create result items we loose the context of its creation. The PPQL-Processorcannot relocate the corresponding policy element without additional information. Datacouplings are policy couplings which couple multiple data items (e.g. structured data astuples) with policies. We may couple all data items with the same policy. Therefore, a datacoupling may contain a data mapping for each coupled data item (or attribute for a setof tuples). We may also couple each data item with different policies. Therefore, a datacoupling may contain a data item coupling for each coupled data item.

Annotated requests are requests which additionally contain trusted meta information aboutthe request as the requestor identifier, the purpose, the requesting stakeholder, and more.This meta information is part of the information we use to evaluate the execution permis-

11.11.2010 IST-224201 110

Deliverable 16 1.0

sions for recieved PPQL requests. Only trusted components create and process trustedmeta information.

Figure A.9 illustrates the concepts MetaInformationOfOperationResponse, MetaInfor-mationOfResponse, DataCoupling, AnnotatedResponse, AnnotatedOperationResponse,and their relationships. Analogue to requests annotated responses are responses whichadditionally contain trusted meta information about the response as the receiver id, re-questor id, timestamp of the PPQL request execution, and the policy coupling (data cou-pling which contains at least one data item coupling or one policy reference with the cor-responding data mapping). The meta information of the response will be used to evaluatefollowing PPQL requests (e.g. to calculate the operation execution interval or to determinewhich information has already been recieved by a given entity).

Ontologies:ICT (base) ontology

Information

i A

dateTime

ICT (base) ontologyP3L ontology

MetaInformation

isA

MetaInformationreciever

timestampOfExecution

OfResponse

Response

describedBy

OfOperationResponse

Entityrequestor

OperationResponse

containsisA

AnnotatedResponse

isA

DataCoupling

consistsOf

Response Response

Annotated

≡ Response anddescribedBy some MetaInformationOfResponse

isAisA

describedBy Annotated

OperationResponse

≡ OperationResponse anddescribedBy some MetaInformationOfOperationResponse

By

MetaInformationOfOperationResponse

Figure A.9.: Partial ontologies - P3L ontology 3/3

A.1.3. SQL-Light - DBMS Technology for Privacy-aware Query Processing

In Section 3.5.3 we already proposed our approach of SQL-Light. In this section we givesome more information about the expressiveness of SQL-Light and future challenges.

One future research challenge is to investigate if the execution of a sequence of operationshas side effects that cannot be calculated by just considering a single operation. We stilltake into account the privacy effects of previously executed operations, but we do notconsider the operations itself nor future operations. We restrict the set of SQL operations

11.11.2010 IST-224201 111

Deliverable 16 1.0

and support the following operations: a) select, b) project, c) join, d) group by, e) aggregatefunctions.

We do not support language elements such as negation, union, intersection or nestedqueries. The schema of the human readable notation of SQL-Light is “SELECT expressionFROM table-reference WHERE search-condition GROUP BY attribute-list”. The expres-sion of the select clause consists of a list of attributes (e.g. location, name, speed) or ag-gregation functions (AVG, SUM, COUNT). The table-reference of the from clause consistsof a list of tables (e.g. User, Vehicle). The search-condition of the where clause consistsof simple constraints (e.g. contain a relational operator). Thus, inner joins are possible.While processing SQL-Light queries we also calculate privacy properties (as part of theoperations privacy effect) as values of privacy metrics (e.g. the value k-anonymity) andprovide this information as meta information of the result.

11.11.2010 IST-224201 112

Bibliography

[1] PRECIOSA Consortium, “Deliverable 1: V2X privacy issue analysis,” 2009.[Online]. Available: http://www.preciosa-project.org/

[2] ——, “Deliverable 2: V2X measurement approach,” 2009. [Online]. Available:http://www.preciosa-project.org/

[3] ——, “Deliverable 4: Challenges for V2X privacy: issues,” 2008. [Online]. Available:http://www.preciosa-project.org/

[4] ——, “Deliverable 6: Models and privacy ontology for V2X,” 2009. [Online].Available: http://www.preciosa-project.org/

[5] ——, “Deliverable 7: V2X privacy verifiable architecture,” 2009. [Online]. Available:http://www.preciosa-project.org/

[6] ——, “Deliverable 8: V2X application specification and validation requirements,”2009. [Online]. Available: http://www.preciosa-project.org/

[7] ——, “Deliverable 14: V2x privacy verifiable cooperative application,” 2010.[Online]. Available: http://www.preciosa-project.org/

[8] ——, “Deliverable 11: Guidelines for privacy aware cooperative application,” 2010.[Online]. Available: http://www.preciosa-project.org/

[9] ——, “Deliverable 10: Mechanisms for v2x privacy,” 2010. [Online]. Available:http://www.preciosa-project.org/

[10] ——, “Deliverable 13: V2x privacy mechanisms and verification support tools,”2010. [Online]. Available: http://www.preciosa-project.org/

[11] Q. He and A. I. Anton, “A framework for modeling privacy requirements in role en-gineering,” Proceedings of the 9th International Workshop on Requirements Engi-neering: Foundation for Software Quality (REFSQ’03), 2003.

[12] S. Staab and R. Studer, Handbook on Ontologies. Springer Publishing Company,Incorporated, 2009.

[13] S. W. Lee and R. A. Gandhi, “Ontology-based active requirements engineeringframework,” Asia-Pacific Software Engineering Conference, vol. 0, pp. 481–490,2005.

[14] J.-C. F. Olaf Hartig, Martin Kost, “Automatic component selection with semantictechnologies,” Proceedings of the 4th International Workshop on Semantic WebEnabled Software Engineering (SWESE) at ISWC, 2008.

113

Deliverable 16 1.0

[15] E. C. Michael Hecker, Tharam S. Dillon, “Privacy ontology support for e-commerce,”IEEE Internet Computing, vol. 12, pp. 54–61, 2008.

[16] M. Schumacher, “Security engineering with patterns: Toward a security core ontol-ogy,” Springer-Verlag, vol. LNCS 2754, pp. 87–96, 2003.

[17] D. Schmidt, “Model-driven engineering,” IEEE Computer, pp. Vol. 39(2), pp. 41–47.,2006.

[18] C. C. Burt, B. R. Bryant, R. R. Raje, A. Olson, and M. Auguston, “Model driven secu-rity: Unification of authorization models for fine-grain access control,” Proceedingsof the Seventh IEEE International Enterprise Distributed Object Computing Confer-ence (EDOC’03), p. pp. 159, 2003.

[19] R. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-based accesscontrol models,” IEEE Computer, no. 2, pp. Vol. 29, No. 2, pp. 38–47, February1996.

[20] R. Sandhu, , and Q. Munawer, “How to do discretionary access control using roles,”3rd ACM Workshop on Role-BasedAccess Control, pp. pp. 47–54, 1998.

[21] N. Cuppens, F. Cuppens, D. Abi Haidar, and H. Debar, “Negotiation of prohibition:an approach based on policy Rewriting,” SEC’08 : 23rd International InformationSecurity Conference, september 8-10, Milan, Italie, pp. pp. 173–187, 2008.

[22] “Extensible Access Control Markup Language (XACML),” http://xml.coverpages.org/xacml.html.

[23] T. Lodderstedt, D. Basin, and J. Doser, “Secureuml: A uml-based modeling lan-guage for model-driven security,” UML 2002 - The Unified Modeling Language, pp.Volume 2460/2002, pp. 426–441, 2002.

[24] OMG, “Object constraint language,” formal/06-05-01, May 2006.

[25] S. H. Houmb and K. K. Hansen, “Towards a uml profile for security assessment,”UML 2003, Workshop on Critical Systems Development with UML, pp. 815–829.

[26] S. H. Houmb, F. den Braber, M. S. Lund, and K. Stolen., “Towards a uml profile formodel-based risk assessment,” Critical systems development with UML. Proceedingof the UML’02 workshop, pp. 79–91, 2002.

[27] J. Jürjens, “Towards development of secure systems using umlsec,” 4th InternationalConference on Fundamental Approaches to Software Enineering, pp. pp. 32–42,2001.

[28] J. Krumm, “A survey of computational location privacy,” Personal and UbiquitousComputing, vol. 13, no. 6, pp. 391–399, 2009.

[29] A. Pfitzmann and M. Hansen, “Anonymity, unlinkability, undetectability, unob-servability, pseudonymity, and identity management – a consolidated proposalfor terminology,” TU Dresden, Tech. Rep., Feb. 2008, v0.31. [Online]. Available:http://dud.inf.tu-dresden.de/Anon_Terminology.shtml

11.11.2010 IST-224201 114

Deliverable 16 1.0

[30] S. Steinbrecher and S. Köpsell, “Modelling unlinkability.” in Workshop on PrivacyEnhancing Technologies, 2003, pp. 32–47.

[31] A. Serjantov and G. Danezis, “Towards an information theoretic metric for ano-nymity,” in Workshop on Privacy Enhancing Technologies, 2002.

[32] C. Diaz, S. Seys, J. Claessens, and B. Preneel, “Towards measuring anonymity,” inWorkshop on Privacy Enhancing Technologies, 2002.

[33] A. R. Beresford and F. Stajano, “Location privacy in pervasive computing,” IEEEPervasive Computing, vol. 2, no. 1, pp. 46–55, 2003.

[34] L. Buttyan, T. Holczer, and I. Vajda, “On the effectiveness of changing pseudonymsto provide location privacy in VANETs,” in ESAS 2007, July 2007.

[35] J. Freudiger, M. Raya, M. Felegyhazi, P. Papadimitratos, and J.-P. Hubaux, “Mix-zones for location privacy in vehicular networks,” in WiN-ITS, 2007.

[36] M. Gruteser and B. Hoh, “On the anonymity of periodic location samples.” in Securityin Pervasive Computing 2005, Boppard, Germany, vol. 3450, 2005, pp. 179–192.

[37] K. Sampigethaya, M. Li, L. Huang, and R. Poovendran, “Amoeba: Robust locationprivacy scheme for vanet,” IEEE Journal on Selected Areas in Communications,vol. 25, no. 8, pp. 1569 – 1589, Oct. 2007.

[38] B. Hoh, M. Gruteser, H. Xiong, and A. Alrabady, “Preserving privacy in GPS tracesvia density-aware path cloaking,” in ACM Conference on Computer and Communi-cations Security (CCS), 2007.

[39] L. Sweeney, “k-anonymity: A model for protecting privacy,” International Journal onUncertainty, Fuzziness and Knowledge-based Systems, vol. 10, no. 5, pp. 557–570,2002.

[40] A. Machanavajjhala, J. Gehrke, D. Kifer, and M. Venkitasubramaniam, “l-diversity:Privacy beyond k-anonymity,” in ICDE ’06: Proceedings of the 22nd IEEE Interna-tional Conference on Data Engineering. IEEE Computer Society, 2006.

[41] N. Li, T. Li, and S. Venkatasubramanian, “t-closeness: Privacy beyond k-anonymityand l-diversity,” in ICDE ’07: In Proceedings of the 23rd IEEE International Confer-ence on Data Engineering, 2007, pp. 106–115.

[42] J. Li, Y. Tao, and X. Xiao, “Preservation of proximity privacy in publishing numericalsensitive data,” in SIGMOD ’08: Proceedings of the 2008 ACM SIGMOD interna-tional conference on Management of data. New York, NY, USA: ACM, 2008, pp.473–486.

[43] D. Agrawal and C. C. Aggarwal, “On the design and quantification of privacy pre-serving data mining algorithms,” in Proceedings of the 20th ACM SIGMOD-SIGACT-SIGART symposium on Principles of Database Systems. New York, NY, USA:ACM, 2001, pp. 247–255.

11.11.2010 IST-224201 115

Deliverable 16 1.0

[44] Y. Asnar, P. Giorgini, and J. Mylopoulos, “Goal-driven risk assessment in require-ments engineering,” Requirements Engineering, pp. 1–16, 2010, 10.1007/s00766-010-0112-x. [Online]. Available: http://dx.doi.org/10.1007/s00766-010-0112-x

[45] A. I. Anton and J. B. Earp, “Strategies for developing policies and requirements forsecure electronic commerce systems,” Raleigh, NC, USA, Tech. Rep., 2000.

[46] A. I. Antón, J. B. Earp, T. A. Alspaugh, and C. Potts, “The role of policy and stake-holder privacy values in requirements engineering,” in Proceedings of the Fifth IEEEInternational Symposium on Requirements Engineering, ser. RE ’01. Washington,DC, USA: IEEE Computer Society, 2001, pp. 138–.

[47] A. I. Antón, J. B. Earp, and R. A. Carter, “Precluding incongruous behavior by align-ing software requirements with security and privacy policies,” Information and Soft-ware Technology, vol. 45, no. 14, pp. 967 – 977, 2003, eighth International Work-shop on Requirements Engineering: Foundation for Software Quality.

[48] A. Van Lamsweerde, “Goal-oriented requirements engineering: A guided tour,” inRE ’01: Proceedings of the Fifth IEEE International Symposium on RequirementsEngineering. Washington, DC, USA: IEEE Computer Society, 2001, p. 249.

[49] E. Kavakli, “Goal oriented requirements engineering: a unifying framework,” Re-quirements Engineering Journal, Springer-Verlag London, vol. 6, pp. 237–251,2002.

[50] B. Schneier, “Attack trees,” Dr. Dobb’s Journal of Software Tools, vol. 24, no. 12,Dec. 1999.

[51] S. Mauw and M. Oostdijk, “Foundations of attack trees,” in ICISC, ser. LectureNotes in Computer Science, D. Won and S. Kim, Eds., vol. 3935. Springer, 2005,pp. 186–198. [Online]. Available: http://dx.doi.org/10.1007/11734727_17

[52] A. Aijaz, B. Bochow, F. Dötzer, A. Festag, M. Gerlach, R. Kroh, and T. Leinmüller,“Attacks on inter-vehicle communication systems - an analysis,” in 3rd InternationalWorkshop on Intelligent Transportation (WIT 2006), March 2006.

[53] E. M. Clarke and E. A. Emerson, “Synthesis of synchronization skeletons for branch-ing time temporal logic,” in In Logic of Programs: Workshop. Springer-Verlag, 1981.

[54] M. Tschantz and J. Wing, “Formal methods for privacy,” in FM 2009: Formal Meth-ods, ser. Lecture Notes in Computer Science, A. Cavalcanti and D. Dams, Eds.Springer Berlin / Heidelberg, 2009, vol. 5850, pp. 1–15.

[55] X. Fu, “Conformance verification of privacy policies,” (To appear) in Proceedings of7th International Workshop on Web Services and Formal Methods Formal aspectsof service oriented and cloud computing (WS-FM’10), 2010.

[56] A. Barth, A. Datta, J. C. Mitchell, and H. Nissenbaum, “Privacy and contextual in-tegrity: Framework and applications,” in Proceedings of the 2006 IEEE Symposiumon Security and Privacy. Washington, DC, USA: IEEE Computer Society, 2006,pp. 184–198.

11.11.2010 IST-224201 116

Deliverable 16 1.0

[57] D. Métayer, “Formal aspects in security and trust,” P. Degano, J. Guttman, andF. Martinelli, Eds. Berlin, Heidelberg: Springer-Verlag, 2009, ch. A Formal Pri-vacy Management Framework, pp. 162–176.

[58] Y. H. Li, H.-Y. Paik, and B. Benatallah, “Formal consistency verification between bpelprocess and privacy policy,” in Proceedings of the 2006 International Conferenceon Privacy, Security and Trust: Bridge the Gap Between PST Technologies andBusiness Services, ser. PST ’06. New York, NY, USA: ACM, 2006, pp. 26:1–26:10.

[59] M. Bruso, K. Chatzikokolakis, and J. den Hartog, “Formal verification of privacy forrfid systems,” Computer Security Foundations Symposium, IEEE, vol. 0, pp. 75–88,2010.

[60] “Platform for Privacy Preferences (P3P) Project,” http://www.w3.org/P3P.

[61] “A P3P Preference Exchange Language (APPEL),” http://www.w3.org/TR/P3P-preferences.

[62] P. Ashley, “Enforcement of a p3p privacy policy,” in AISM, 2004, pp. 11–26.

[63] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu, “Implementing p3p using databasetechnology,” Data Engineering, International Conference on, vol. 0, p. 595, 2003.

[64] “PRIME – Privacy and Identity Management for Europe,” https://www.prime-project.eu.

[65] C. A. Ardagna, S. D. C. di Vimercati, and P. Samarati, “Enhancing user privacythrough data handling policies,” in DBSec, 2006, pp. 224–236.

[66] C. Bournez and G. Neven, “Final requirements and state-of-the-art for next genera-tion policies,” PrimeLife, Tech. Rep., 2009.

[67] K. B. Frikken and Y. Zhang, “Yet another privacy metric for publishing micro-data,”in WPES ’08: Proceedings of the 7th ACM workshop on Privacy in the electronicsociety. New York, NY, USA: ACM, 2008, pp. 117–122.

[68] L. Sweeney, “Achieving k-anonymity privacy protection using generalization andsuppression,” International Journal on Uncertainty, Fuzziness and Knowledge-based Systems, vol. 10, no. 5, pp. 571–588, 2002.

[69] R. J. Bayardo and R. Agrawal, “Data privacy through optimal k-anonymization,” inICDE ’05: Proceedings of the 21st International Conference on Data Engineering.Washington, DC, USA: IEEE Computer Society, 2005, pp. 217–228.

[70] K. LeFevre, D. J. DeWitt, and R. Ramakrishnan, “Incognito: Efficient full-domain k-anonymity,” in SIGMOD ’05: Proceedings of the 2005 ACM SIGMOD internationalconference on Management of data. New York, NY, USA: ACM, 2005, pp. 49–60.

[71] ——, “Mondrian multidimensional k-anonymity,” in ICDE ’06: Proceedings of the22nd International Conference on Data Engineering. IEEE Computer Society,2006, pp. 25–35.

11.11.2010 IST-224201 117

Deliverable 16 1.0

[72] T. M. Truta and B. Vinay, “Privacy protection: p-sensitive k-anonymity property,” inICDEW ’06: Proceedings of the 22nd International Conference on Data EngineeringWorkshops. Washington, DC, USA: IEEE Computer Society, 2006, p. 94.

[73] R. C.-W. Wong, J. Li, A. W.-C. Fu, and K. Wang, “(α, k)-Anonymity: An Enhanced k-Anoymity Model for Privacy-Preserving Data Publishing,” in KDD ’06: Proceedingsof the 12th ACM SIGKDD international conference on Knowledge discovery anddata mining. New York, NY, USA: ACM, 2006, pp. 754–759.

[74] X. Xiao and Y. Tao, “m-Invariance: Towards Privacy Preserving Re-publication ofDynamic Datasets,” in SIGMOD ’07: Proceedings of the 2007 ACM SIGMOD inter-national conference on Management of data. New York, NY, USA: ACM, 2007, pp.689–700.

[75] Y. Rubner, C. Tomasi, and L. J. Guibas, “The earth mover’s distance as a metric forimage retrieval,” International Journal of Computer Vision, vol. 40, no. 2, pp. 99–121,November 2000.

[76] Q. Zhang, N. Koudas, D. Srivastava, and T. Yu, “Aggregate query answering onanonymized tables,” in ICDE ’07: Proceedings of the 23rd International Conferenceon Data Engineering, vol. 0. Los Alamitos, CA, USA: IEEE Computer Society,2007, pp. 116–125.

[77] J. C. Freytag, “Context quality and privacy – friends or rivals?” in QuaCon, 2009,pp. 25–40.

[78] D. L. Chaum, “Untraceable electronic mail, return addresses, and digital pseudo-nyms,” Commun. ACM, vol. 24, no. 2, pp. 84–90, 1981.

[79] D. M. Goldschlag, M. G. Reed, and P. F. Syverson, “Hiding routing information,” inInformation Hiding, 1996, pp. 137–150.

[80] M. Gruteser and D. Grunwald, “Anonymous usage of location-based servicesthrough spatial and temporal cloaking,” in MobiSys ’03: Proceedings of the 1st in-ternational conference on Mobile systems, applications and services. New York,NY, USA: ACM, 2003, pp. 31–42.

[81] C.-Y. Chow, M. F. Mokbel, and X. Liu, “A peer-to-peer spatial cloaking algorithmfor anonymous location-based service,” in GIS ’06: Proceedings of the 14th an-nual ACM international symposium on Advances in geographic information systems.New York, NY, USA: ACM, 2006, pp. 171–178.

[82] P. Kalnis, G. Ghinita, K. Mouratidis, and D. Papadias, “Preventing location-basedidentity inference in anonymous spatial queries,” IEEE Transactions on Knowledgeand Data Engineering, vol. 19, no. 12, pp. 1719–1733, 2007.

[83] M. F. Mokbel, C.-Y. Chow, and W. G. Aref, “The new casper: Query processing forlocation services without compromising privacy,” in In VLDB, 2006, pp. 763–774.

[84] C.-Y. Chow, M. F. Mokbel, and T. He, “Tinycasper: a privacy-preserving aggregatelocation monitoring system in wireless sensor networks,” in SIGMOD Conference.New York, NY, USA: ACM, 2008, pp. 1307–1310.

11.11.2010 IST-224201 118

Deliverable 16 1.0

[85] G. Myles, A. Friday, and N. Davies, “Preserving privacy in environments withlocation-based applications,” IEEE Pervasive Computing, vol. 2, no. 1, pp. 56–64,2003.

[86] H. Kido, Y. Yanagisawa, and T. Satoh, “An anonymous communication techniqueusing dummies for location-based services,” International Conference on PervasiveServices, vol. 0, pp. 88–97, 2005.

[87] T.-H. You, W.-C. Peng, and W.-C. Lee, “Protecting moving trajectories with dum-mies,” IEEE International Conference on Mobile Data Management, vol. 0, pp. 278–282, 2007.

[88] M. L. Yiu, C. S. Jensen, X. Huang, and H. Lu, “Spacetwist: Managing the trade-offsamong location privacy, query performance, and query accuracy in mobile services,”International Conference on Data Engineering, vol. 0, pp. 366–375, 2008.

[89] A. Khoshgozaran and C. Shahabi, “Blind evaluation of nearest neighbor queriesusing space transformation to preserve location privacy,” in SSTD, 2007, pp. 239–257.

[90] H. Hu, J. Xu, and D. L. Lee, “Pam: An efficient and privacy-aware monitoring frame-work for continuously moving objects,” IEEE Transactions on Knowledge and DataEngineering, vol. 22, no. 3, pp. 404–419, 2010.

[91] D. C. Latham, “Trusted computer system evaluation criteria (orange book),” Decem-ber 1985.

[92] D. F. Ferraiolo and D. R. Kuhn, “Future directions in role-based access control,” inACM Workshop on Role-Based Access Control, 1995.

[93] J. L. D. Coi and D. Olmedilla, “A review of trust management, securityand privacy policy languages,” in International Conference on Security andCryptography (SECRYPT 2008). INSTICC Press, July 2008. [Online]. Available:2008/2008-SECRYPT-comparison.pdf

[94] A. I. Antón, E. Bertino, N. Li, and T. Yu, “A roadmap for comprehensive online privacypolicy management,” Commun. ACM, vol. 50, no. 7, pp. 109–116, 2007.

[95] I. I. T. S. Organization, “Ibm tivoli privacy manager,”http://www.redbooks.ibm.com/redbooks/pdfs/sg246999.pdf, 2003.

[96] P. Papadimitratos, L. Buttyan, T. Holczer, E. Schoch, J. Freudiger, M. Raya, Z. Ma,F. Kargl, A. Kung, and J.-P. Hubaux, “Secure vehicular communication systems:design and architecture,” IEEE Communications Magazine, vol. 46, no. 11, pp.100–109, Nov. 2008. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4689252

[97] F. Kargl, P. Papadimitratos, L. Buttyan, M. Müter, E. Schoch, B. Wiedersheim,T.-V. Thong, G. Calandriello, A. Held, A. Kung, and J.-P. Hubaux, “Securevehicular communication systems: implementation, performance, and researchchallenges,” IEEE Communications Magazine, vol. 46, no. 11, pp. 110–118,

11.11.2010 IST-224201 119

Deliverable 16 1.0

Nov. 2008. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4689253

[98] F. Armknecht, A. Festag, D. Westhoff, and K. Zeng, “Cross-layer privacy enhance-ment and non-repudiation in vehicular communication,” in WMAN ’07: 4th Workshopon Mobile Ad-Hoc Networks, Bern, Switzerland, March 2007.

[99] L. Fischer, A. Aiijaz, C. Eckert, and D. Vogt, “Secure revocable anonymous authen-ticated inter-vehicle communication (SRAAC),” in Proceedings ESCAR ’06, 2006.

[100] Y.-C. Hu and K. P. Laberteaux, “Strong VANET security on a budget,” in Proceedingsof Workshop on Embedded Security in Cars (ESCAR), 2006.

[101] C. Laurendeau and M. Barbeau, “Secure anonymous broadcasting in vehicular net-works,” Local Computer Networks, 2007. LCN 2007. 32nd IEEE Conference on, pp.661–668, Oct. 2007.

[102] G. Calandriello, P. Papadimitratos, J.-P. Hubaux, and A. Lioy, “Efficient and robustpseudonymous authentication in VANET,” in VANET ’07: Proceedings of the fourthACM international workshop on Vehicular ad hoc networks. New York, NY, USA:ACM, 2007, pp. 19–28.

[103] X. Lin, X. Sun, P.-H. Ho, and X. Shen, “Gsis: A secure and privacy-preservingprotocol for vehicular communications,” Vehicular Technology, IEEE Transactionson, vol. volume 56, no. 6, pp. pages 3442–3456, Nov. 2007.

[104] R. Lu, X. Lin, H. Zhu, P.-H. Ho, and X. Shen, “Ecpp: Efficient conditional privacypreservation protocol for secure vehicular communications,” INFOCOM 2008 The27th Conference on Computer Communications, pp. 1229–1237, April 2008.

[105] P. Kamat, A. Baliga, and W. Trappe, “An identity-based security framework forVANETs,” in VANET ’06: Proceedings of the 3rd international workshop on Vehicu-lar ad hoc networks. New York, NY, USA: ACM, 2006, pp. 94–95.

[106] J. Sun, C. Zhang, and Y. Fang, “An id-based framework achieving privacy and non-repudiation in vehicular ad hoc networks,” IEEE Military Communications Confer-ence MILCOM 2007, pp. 1–7, Oct. 2007.

[107] B. H. Kim, K. Y. Choi, J. H. Lee, and D. H. Lee, “Anonymous and traceable communi-cation using tamper-proof device for vehicular ad hoc networks,” International Con-ference on Convergence Information Technology 2007, pp. 681–686, Nov. 2007.

[108] A. Pfitzmann, “Since the bad guys will retain all data they can get anyway, thegood guys probably are better off if they retain data as well (panel),” Intern. Conf.Computers, Privacy & Data Protection (CPDP), 2010.

[109] C. Troncoso, G. Danezis, E. Kosta, and B. Preneel, “Pripayd: privacy friendlypay-as-you-drive insurance,” in WPES ’07: Proceedings of the 2007 ACM workshopon Privacy in electronic society. New York, NY, USA: ACM, 2007, pp. 99–107. [Online]. Available: http://portal.acm.org/ft_gateway.cfm?id=1314353&type=pdf&coll=&dl=GUIDE&CFID=101463002&CFTOKEN=36394032

11.11.2010 IST-224201 120

Deliverable 16 1.0

[110] J. Balasch, A. Rial, C. Troncoso, C. Geuens, B. Preneel, and I. Verbauwhede, “Pretp:Privacy-preserving electronic toll pricing,” in USENIX Security Symposium, 2010.

[111] R. A. Popa, H. Balakrishnan, and A. Blumberg, “VPriv: Protecting Privacy inLocation-Based Vehicular Services,” in 18th USENIX Security Symposium, Mon-treal, Canada, August 2009.

[112] J. L. Griffin, T. Jaeger, R. Perez, R. Sailer, L. van Doorn, and R. Caceres, “Trustedvirtual domains: Toward secure distributed services,” IBM T.J. Watson ResearchCenter, Research Report RC23595 (W0504-136), Apr. 2005, presented at FirstWorkshop on Hot Topics in Systems Dependability; Yokohama, Japan; June 2005.

[113] L. Catuogno, H. Löhr, M. Manulis, A.-R. Sadeghi, and M. Winandy, “TransparentMobile Storage Protection in Trusted Virtual Domains,” in 23rd USENIX Large In-stallation Systems Administration Conference (LISA 2009). USENIX Association,2009, pp. 159–172.

[114] PrimeLife, “Second report on mechanisms,” Deliverable, February 2010.

[115] Discreet, “System architecture specification,” Deliverable, October 2006.

[116] G. V. Lioudakis, F. Gogoulos, A. Antonakopoulou, D. I. Kaklamani, and I. S. Venieris,“Privacy protection in passive network monitoring: An access control approach,” Ad-vanced Information Networking and Applications Workshops, International Confer-ence on, vol. 0, pp. 109–116, 2009.

[117] E. Parliament and of the Council of 24 October 1995, “Directive 95/46/ecof the european parliament and of the council of 24 october 1995 onthe protection of individuals with regard to the processing of personal dataand on the free movement of such data, online (access july 31, 2009),”http://www.cdt.org/privacy/eudirective/EU_Directive_html#HD_NM_28, 1995.

[118] T. E. PARLIAMENT and T. C. O. T. E. UNION, “Directive 2010/40/eu of the europeanparliament and of the council,” Official Journal of the European Union, vol. L 207/1,2010.

[119] J. Bézivin, “On the unification power of models,” Software and System Modeling(SoSym), vol. 4(2), pp. 171–188, 2005.

[120] Department of Homeland Security Cyber Security R&D Center, “A roadmapfor cybersecurity research,” Tech. Rep., 2009. [Online]. Available: http://www.cyber.st.dhs.gov/docs/DHS-Cybersecurity-Roadmap.pdf

[121] C. E. Shannon, “A mathematical theory of communication,” Bell system technicaljournal, vol. 27, pp. 379–423, 623–656, July, October 1948.

[122] Z. Ma, F. Kargl, and M. Weber, “A location privacy metric for v2x communicationsystems,” in IEEE Sarnoff Symposium, Princeton, NJ, USA, March 2009.

[123] ——, “Measuring location privacy in V2X communication systems with accumulatedinformation,” in IEEE MASS’09, Macau, China, October 2009.

11.11.2010 IST-224201 121

Deliverable 16 1.0

[124] ——, “Measuring long-term location privacy in vehicular communication sys-tems,” Elsevier Computer Communications, vol. 33, no. 12, 07 2010. [On-line]. Available: http://www.sciencedirect.com/science/article/B6TYP-4YJ4NCG-3/2/472e15a4653ec3a4f04a390cfab9f776

[125] B. Wiedersheim, F. Kargl, Z. Ma, and P. Panagiotis, “Privacy in inter-vehicular net-works: Why simple pseudonym change is not enough,” in The Seventh InternationalConference on Wireless On-demand Network Systems and Services (WONS 2010),Kranjska Gora, Slovenia, February 2010.

[126] “Carnegie mellon cylab - project nudging users towards privacy,” http://www.cylab.cmu.edu/index.html.

[127] M. Backes, B. Köpf, and A. Rybalchenko, “Automatic Discovery and Quantificationof Information Leaks,” in Proc. 30th IEEE Symposium on Security and Privacy (S&P ’09), to appear, 2009.

[128] M. K. Hannes Mühleisen and J.-C. Freytag, “Swrl-based access policies for linkeddata,” Proceedings of the 2nd Workshop on Trust and Privacy on the Social andSemantic Web (SPOT2010), vol. 576, 2010.

[129] T. Berners-Lee, “Linked data,” http://www.w3.org/DesignIssues/LinkedData.html,2006.

[130] F. Schaub, Z. Ma, and F. Kargl, “Privacy requirements in vehicular communicationsystems,” in International Symposium on Secure Computing (SecureCom09), IEEEPASSAT09, Vancouver, Canada, August 2009.

[131] E. Schoch, F. Kargl, and M. Weber, “Communication patterns in VANETs,”IEEE Communications Magazine, vol. 46, no. 11, pp. 119–125, Nov.2008. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4689254

[132] F. Schaub, F. Kargl, Z. Ma, and M. Weber, “V-tokens for Conditional Pseudonymityin VANETs,” in IEEE Wireless Communications & Networking Conference (WCNC2010). Sydney: IEEE, 2010.

[133] A. F. Westin, Privacy and Freedom. New York: Atheneum, 1967.

[134] F. Kargl, F. Schaub, and S. Dietzel, “Mandatory Enforcement of Privacy Policiesusing Trusted Computing Principles,” in Intelligent Information Privacy MaangementSymposium (Privacy 2010), AAAI Spring Symposium Series. Stanford: AAAI,2010.

[135] F. Kargl, S. Dietzel, F. Schaub, and J.-C. Freytag, “Enforcing privacy policies in coop-erative intelligent transportation systems (poster),” in ACM 15th Annual InternationalConference on Mobile Computing and Networking (MobiCom 2009), Bejing, China,September 2009.

11.11.2010 IST-224201 122

Deliverable 16 1.0

[136] T. Ball and S. K. Rajamani, “Automatically validating temporal safety properties ofinterfaces,” in Proceedings of the 8th international SPIN workshop on Model check-ing of software, ser. SPIN ’01. New York, NY, USA: Springer-Verlag New York, Inc.,2001, pp. 103–122.

[137] C. Cowan, P. Wagle, C. Pu, S. Beattie, and J. Walpole, “Buffer overflows: Attacksand defenses for the vulnerability of the decade,” DARPA Information SurvivabilityConference and Exposition,, vol. 2, p. 1119, 2000.

[138] J. Newsome and D. Song, “Dynamic Taint Analysis for Automatic Detection, Analy-sis, and Signature Generation of Exploits on Commodity Software,” in Proceedingsof the Network and Distributed System Security Symposium (NDSS 2005), 2005.

[139] Y. Cui, J. Widom, and J. L. Wiener, “Tracing the lineage of view data in a warehous-ing environment,” ACM Trans. Database Syst., vol. 25, no. 2, pp. 179–227, 2000.

[140] S. Evdokimov and O. Günther, “Encryption techniques for secure databaseoutsourcing,” in Computer Security - ESORICS 2007, ser. Lecture Notes inComputer Science, J. Biskup and J. López, Eds. Springer Berlin / Heidelberg,2007, vol. 4734, pp. 327–342, 10.1007/978-3-540-74835-9_22. [Online]. Available:http://dx.doi.org/10.1007/978-3-540-74835-9_22

[141] S. Evdokimov, M. Fischmann, and O. Günther, “Provable security for outsourcingdatabase operations,” Data Engineering, International Conference on, vol. 0, p. 117,2006.

[142] T. Wang and L. Liu, “Privacy-aware mobile services over road networks,”Proc. VLDB Endow., vol. 2, pp. 1042–1053, August 2009. [Online]. Available:http://portal.acm.org/citation.cfm?id=1687627.1687745

[143] A. R. Beresford and F. Stajano, “Mix zones: User privacy in location-aware ser-vices,” Pervasive Computing and Communications Workshops, IEEE InternationalConference on, vol. 0, p. 127, 2004.

[144] G. Ghinita, P. Kalnis, and S. Skiadopoulos, “Prive: anonymous location-basedqueries in distributed mobile systems,” in Proceedings of the 16th internationalconference on World Wide Web, ser. WWW ’07. New York, NY, USA: ACM, 2007,pp. 371–380. [Online]. Available: http://doi.acm.org/10.1145/1242572.1242623

[145] D. E. Denning and J. Schlörer, “A fast procedure for finding a tracker in a statisticaldatabase,” ACM Trans. Database Syst., vol. 5, no. 1, pp. 88–102, 1980.

[146] D. E. Denning, P. J. Denning, and M. D. Schwartz, “The tracker: A threat to statisticaldatabase security,” ACM Trans. Database Syst., vol. 4, no. 1, pp. 76–96, 1979.

[147] N. Chandran, V. Goyal, R. Moriarty, and R. Ostrovsky, “Position based cryptogra-phy,” in Advances in Cryptology - CRYPTO 2009, ser. Lecture Notes in ComputerScience, S. Halevi, Ed. Springer Berlin / Heidelberg, 2009, vol. 5677, pp. 391–407.

11.11.2010 IST-224201 123

Deliverable 16 1.0

[148] L. Davi, A.-R. Sadeghi, and M. Winandy, “Dynamic integrity measurement and at-testation: towards defense against return-oriented programming attacks,” in STC’09: Proceedings of the 2009 ACM workshop on Scalable trusted computing. NewYork, NY, USA: ACM, 2009, pp. 49–54.

[149] C. Gentry, “Computing on encrypted data,” in CANS ’09: Proceedings of the 8thInternational Conference on Cryptology and Network Security. Berlin, Heidelberg:Springer-Verlag, 2009, pp. 477–477.

11.11.2010 IST-224201 124