Contract Delivery Date Actual Delivery Date Deliverable Type

Document Title
D3.2.2 Privacy Preservation Framework 2

Project Number
FP7-2011-7-287661

Contract Delivery Date
M22

Project Acronym
GAMBAS

Document Version
0.5

Project Title
Generic Adaptive Middleware for Behavior-driven
Autonomous Services

Actual Delivery Date
05.12.2013


Document Author or Reviewer
Wolfgang Apolinarski
Marcus Handte
Josiane Xavier Parreira

Deliverable Type
P (Prototype)

Organization
UDE
UDE
NUIG

Deliverable Access
CO (Confidential)

Work Package
WP3
WP3

WP3

Abstract
This document describes the second prototype of the privacy preservation framework developed by
the GAMBAS project. Again, this document itself does only accompany the prototype and it is not an
actual deliverable. The actual deliverable, i.e., the code of the prototype, can be accessed via the
shared code repository hosted by UDE. The contents of the documents are the changes that were
applied to the privacy preservation framework to obtain the second prototype. Similar to the first
prototype, we start presenting the features of the second prototype in this document. Thereafter, it
presents the high-level architecture with pointers to sub-modules and classes that implement the
different features. Finally, the document reports on laboratory tests that have been performed in
order to test the implementation.

Revision
0.1
0.2
0.3
0.4
0.5


Organization
UDE
UDE
UDE
NUIG
UDE

Description
Created initial template, added Introduction and Coverage.
Added the Prototype Structure.
Added the Prototype Testing, Conclusion.
Document review
Internal review

FP7-2011-7-287661

Table of Contents
1

2


3

Introduction ..................................................................................................................................... 1
1.1

Purpose.................................................................................................................................... 1

1.2

Scope ....................................................................................................................................... 1

1.3

Structure .................................................................................................................................. 2

Prototype Coverage......................................................................................................................... 3
2.1

Prototype 1 .............................................................................................................................. 4


2.2

Prototype 2 .............................................................................................................................. 4

Prototype Structure......................................................................................................................... 6
3.1

Security Mechanisms............................................................................................................... 6

3.1.1
3.2

4

Key Exchange ................................................................................................................... 6

Privacy Policy ........................................................................................................................... 7

3.2.1


Policy Interface and RDF representation......................................................................... 7

3.2.2

Policy GUI ........................................................................................................................ 8

Prototype Testing ............................................................................................................................ 9
4.1

Privacy Preservation Framework Overhead ............................................................................ 9

4.1.1

Smartphone-Service Interaction ..................................................................................... 9

4.1.2

Smartphone-Smartphone Interaction ........................................................................... 10


5

Conclusion ..................................................................................................................................... 11

6

Bibliography................................................................................................................................... 12

GAMBAS STREP

I

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

List of Figures
Figure 1 – Architectural overview ........................................................................................................... 3
Figure 2 – Manual key creation in the GAMBAS privacy UI .................................................................... 6
Figure 3 – Exchanging a key via NFC, description in the IdentityActivity ................................................ 7

Figure 4 – Privacy Policy GUI ................................................................................................................... 8
Figure 5 – Smartphone-Weather Service Interaction Diagram ............................................................... 9
Figure 6 – Smartphone-Smartphone Interaction Diagram.................................................................... 10

GAMBAS STREP

II

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

1 Introduction
This report documents the developments on the second prototype of the privacy preservation
framework developed by the GAMBAS project. The goal of the privacy preservation framework is to
support the privacy preserving sharing of context information gathered by the adaptive data
acquisition framework in WP2. In this deliverable, the focus lies on the changes to the security
mechanisms with regard to the first prototype (focusing on the secure key-exchange) and the
development of the privacy policies. To achieve both goals, the GAMBAS project has updated the
automated privacy preservation framework in D3.1.2, the privacy preservation specification version

2, which contains the definition of all parts of the privacy preservation framework that are going to
be implemented. The secure mechanisms will focus on simple key exchange mechanisms that will be
used in the GAMBAS prototype, especially with regard to ease the development and testing of new
applications. Additionally, the privacy policy is used to comply with the individual privacy needs of
each user. The second version of the framework prototype implements the policy by providing policy
hooks for the query processor, represents them as RDF triples and implements a simple GUI to allow
editing them. The following describes the purpose, scope and structure of this report. Thereafter, the
document describes the second version of the privacy preservation prototype in more detail.

1.1 Purpose
This document describes the scope and implementation of the second prototype of the privacy
preservation framework, which is a fundamental part of the GAMBAS middleware. This document,
however, is not an actual deliverable. Instead, it merely describes the scope and structure of the
associated code, which represents the actual deliverable. Consequently, this document can be seen
as an introduction to the structure of the prototype or a management summary of the
implementation – depending on the audience. However, the document does not aim at describing all
concepts in full detail. For a complete and in-depth understanding, we refer to the actual deliverable,
i.e., the prototype implementation, which is available through the shared code repository to all
members of the GAMBAS consortium.


1.2 Scope
As described in the GAMBAS description of work, the different building blocks of the GAMBAS
middleware are developed iteratively in two iterations. This holds also true for the privacy
preservation framework which defines all components of the GAMBAS prototype that are
responsible to preserve security and privacy. The first prototype focused not only on the privacy of
context information, but also on the creation of secure communication channels between two
entities. While this work is now already integrated into the GAMBAS prototype, the second
prototype integrates with the data from WP2 and WP4, especially with regard to the query
processor. Additionally, it adds a functionality which allows the developer to test applications which
are based on the GAMBAS middleware and using secure communication in an easy way. This
document covers the second prototype. Thereby, it provides an overview of the functionality that
has been targeted and realized in the second iteration. Furthermore, it describes the results of a
number of laboratory tests that have been performed with the framework, especially with regard to
the overhead that is added by the privacy preservation framework to applications that are built for
the GAMBAS middleware. These tests indicate that the privacy preservation framework prototype 2
performs as planned. The tests are also included into the evaluation report showing that the privacy
preservation framework fulfills the privacy requirements.
GAMBAS STREP

1


D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

1.3 Structure
The structure of the remainder of this document is as follows. In Section 2, we describe the coverage
of the application prototype with respect to the overall functionality and structure detailed in the
Privacy Preservation Specification 2. In Section 3, we describe the overall structure of the prototype
and its implementation. Thereby, we provide pointers to relevant parts of the prototype code that
realize the different concepts. In Section 4, we describe a small number of laboratory tests that have
been performed with the prototype implementation in order to test its functions. A more thorough
study of the prototype features by means of laboratory tests is contained in the first version of the
evaluation report that is created simultaneously to this second prototype of the privacy preservation
framework. Finally, in Section 5, we conclude the document with a short summary and an outlook on
the next code deliverable in WP3, D3.3, the privacy policy generator.

GAMBAS STREP

2

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

2 Prototype Coverage
Similar to the document that accompanied the first privacy preservation framework prototype, we
now present a short introduction to the privacy preservation framework. First, we outline the
intended prototype coverage for the first and second prototype using the descriptions contained in
the privacy preservation specification. As described in D3.1.2 Privacy Preservation Specification 2, the
privacy preservation framework envisioned by the GAMBAS project consists of two main building
blocks: the security mechanisms and the privacy policy. Additionally, the interfaces between the
different frameworks and components that are developed in other work packages of the GAMBAS
project are described. The security mechanisms enable the authentication of devices in the GAMBAS
scenarios and the secure exchange of a secret key which can then be used for secure communication
(i.e., encryption). This allows the secure transfer of context information between different devices or
users. Additionally, the access control mechanism constraints the access to context information that
is stored on a device. The privacy policy component of the privacy preservation framework is used to
define a privacy policy that is individual for each user. In the first specification, a policy language was
created that will be used throughout the GAMBAS project. In the GAMBAS project, different data
sources are used to generate one privacy policy that is using this policy language. Additionally, the
policy is displayed to the user using a policy UI that enables the user to easily edit the policy without
knowing the details of the used policy language.

Figure 1 – Architectural overview

Figure 1 shows the architectural overview of the privacy preservation framework. The black
component shows the existing BASE [BASE] middleware that is used for device discovery and
interaction. The components of the privacy preservation framework are using a red color. Since the
privacy preservation framework is using the data representation developed in WP4 and the context
information that is detected by the data acquisition framework in WP2, the components that are
independent from other implementations were implemented in the first prototype. The second
prototype and the integrated system focus on the integration of these different implementations.
We therefore implemented the privacy preservation framework in two steps. The first step had very
few relationships between the privacy preservation framework and other components that are
developed during other work packages in the GAMBAS project. The second step builds on the
implementation created in the first step and also provides a tight integration with the adaptive data
acquisition framework and the associated data representations created in work package 2 and 4,
respectively.
GAMBAS STREP

3

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

2.1 Prototype 1
As described in the previous paragraph, the first prototype covered all components that were
independent of the work done in other work packages of the GAMBAS project. The first prototype of
the privacy preservation framework therefore contains the implementation of the following parts:
-

-

Security Mechanism: The basic security mechanisms contain i) the key store, which stores
keys shared between devices and server certificates; ii) the authentication component that
authenticates users and iii) devices and the key exchange component that establishes a
secure shared key between two entities. The access control component implemented in the
first version uses all basic security mechanisms but does not make extensive use of the
privacy policy yet.
o Communication: Based on the BASE device discovery and interaction components, in
the first prototype we created components for secure interaction and device
discovery. The secure communication component will make sure that a shared key is
used to encrypt the communication stream achieving secure communication. The
secure device lookup modifies the device registry used to discovery devices and adds
a signature on the device description. This enables the device discovery to be
secured, i.e., the identification of a trusted device.
Privacy Policy: The privacy policy component that is created in the first prototype is the
privacy policy definition. It defines the policy language that is used to constrain access to
context information depending on the device or user that is requesting access.

2.2 Prototype 2
The second prototype that is described in this document covers all components that are not
implemented in the first prototype, except for the privacy policy generator which is contained in an
independent deliverable, D3.3. The following components are updated or implemented during this
second iteration of the prototype development:
-

-

Security Mechanism: The existing basic security mechanisms were updated, in order to ease
the development of applications for the GAMBAS middleware. During the integration of the
GAMBAS Privacy Preservation Framework 1, it became clear that the focus of application
developers is not to set-up a certificate authority to test apps, but that testing should be easy
instead. Additionally, we want to enable the spontaneous exchange of (possibly private) data
and context information. Therefore, we created two new key-exchange mechanisms which
enable us to secure every communication of the GAMBAS middleware, even for applications
that are currently in the development status.
o Key-Exchange: We implemented two new key-exchange mechanisms for
spontaneous meetings. The first mechanism uses a shared string that is hashed and
then used on both devices as a manual key for encryption and data integrity (keyedhash message authentication code (HMAC)). The second mechanism allows devices
which have near-field communication (NFC) built-in to use this for the key
establishment. This allows the fast exchange of shared keys which can then directly
be used for secure communication.
Privacy Policy: The privacy policy is enhanced with an interface to the query processor. This
interface is queried after every execution of the query processor and is used to remove data
or context that might harm the user’s privacy. Additionally the privacy policy is implemented

GAMBAS STREP

4

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661
in Java, allowing the serialization and deserialization of the privacy policy in RDF tuples. This
enables the storage of the privacy policy in the semantic data storage (SDS) that is
implemented in WP4. Additionally, this step prepares the integration of the privacy policy
generator that is developed in D3.3. In the second prototype of the privacy preservation
framework, we also provide a simple GUI to show and change the privacy policy in the
GAMBAS middleware Android application.

GAMBAS STREP

5

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

3 Prototype Structure
Similarly to the first prototype of the privacy preservation framework, the privacy preservation
framework prototype 2 structure complies with the structure that is used throughout the GAMBAS
project. In this structure, every part of the code is divided in logical units. Each unit is modeled as a
Java project. For the privacy preservation framework, the most important projects are the project
eu.gambas.system.security and eu.gambas.system.privacy, although some contributions of this
framework are also integrated into other, pre-existing project (like the communication or the
application app project). In this chapter we give an overview about the implemented components of
the second version of the privacy preservation project and their respective packages.

3.1 Security Mechanisms
In the following, we describe the different security components that were modified in the second
prototype of the privacy preservation framework. These components ease the process of providing
security to the GAMBAS prototype, especially with regard to example applications.
3.1.1 Key Exchange
During the integration and the implementation of the first application prototype, developers could
only use security by either using PIKE [PIKE] (and setting up Facebook-Accounts) or by setting up a
certificate authority. Since using both mechanics can be relatively complicated if the only purpose is
to test an application developed, we added two easy key-exchange methods, manual key creation
and NFC supported key creation. While the manual key creation is mainly targeted on developers,
the NFC key creation can also be executed by users, if they meet spontaneously on the street and are
not yet using PIKE. This enables them to use the secure communication developed in the first
prototype of the privacy preservation framework to transmit (private) data and context encrypted.

Figure 2 – Manual key creation in the GAMBAS privacy UI

3.1.1.1 Manual Key
Exchanging a key between two devices is normally done completely automatic, by either using PIKE
or a service which supports a certificate. In the first case, PIKE exchanges a key over a connection to a
social network such as Facebook, in the latter case, the key is exchanged during the connection
establishment phase by the GAMBAS middleware. If, for testing, it is necessary to exchange a key
GAMBAS STREP

6

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661
between two devices manually, the GAMBASKeyStore which can be found in the
eu.gambas.system.security package is now supporting a method that hashes a manual key, applying
a key-derivation function at the shared secret and then deriving the encryption and the HMAC key
from it. The user interface, which allows the manual key creation, is shown in Figure 2.
3.1.1.2 NFC
The manual key derivation has a disadvantage over the other key exchange mechanisms applied by
the privacy preservation framework, since it allows the user to type in non-random, guessable text
that is prone to dictionary attacks. To avoid this, while still providing a good user experience, the
second version of the privacy preservation framework introduces a key exchange via NFC. All
smartphones which support the NFC technology (e.g., all Google Nexus smartphones since the Nexus
S) can then exchange a key easily by holding the back of two devices together and touching on the
screen. The implementation of this functionality can be found in eu.gambas.application.app. It is
only useable on Android mobile phones and integrated into the IdentityActivity as can be seen in
Figure 3.

Figure 3 – Exchanging a key via NFC, description in the IdentityActivity

3.2 Privacy Policy
Here, we describe the privacy policy components of the privacy preservation framework that were
implemented in the second version of the prototype. These components will provide the privacypreserved sharing of context information to the GAMBAS prototype.
3.2.1 Policy Interface and RDF representation
The privacy preservation specification 2, D3.1.2, describes how the policy triples may be represented
in the GAMBAS middleware. The semantic data storage, which is developed in WP4, supports the
storing of the policy in the semantic data storage (SDS). The model of the privacy policy can be found
in the eu.gambas.sdk.api.generic sub-structure where other generic models like the User and
Pseudonym concepts are also located. After the creation of the privacy policy generator, this
structure might be moved to the privacy package, since it will then be used as part of the privacy
policy generator.
GAMBAS STREP

7

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661
The interface with the query processor that is developed in WP4 is located in the eu.gambas.sdk.spi
package since it is part of the service programming interface. The actual implementation of this
interface is located in the eu.gambas.system.privacy package. This simple interface just shows a list
of possible context classes and the privacy preservation framework will then decide, if the access to
these classes is granted or not. Additionally, the privacy preservation framework gets information
about the type of connection that is established with the remote entity, which includes device ID,
pseudonym and connection status (e.g., encryption enabled). The access to private data and context
is constrained depending on this information.
3.2.2 Policy GUI
A simple policy GUI is implemented in the eu.gambas.application.app package. This allows the user
to modify the privacy policy for either single users or for every user. The user may add or delete
context from a given lists of context (that are for example registered by a GAMBAS application) and
can therefore fine-tune his personal needs. The privacy policy that is auto-generated by the privacy
policy generator will also be using this GUI, when it is finished. The GUI can be seen in Figure 4.

Figure 4 – Privacy Policy GUI

GAMBAS STREP

8

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

4 Prototype Testing
In order to demonstrate the maturity and the applicability of the implementation, we have
performed a number of tests. The first set of tests shows the overhead of the privacy preservation
framework with regard to the secure communication and access control. This covers the security
mechanisms as well as the privacy policy described in Section 3.

4.1 Privacy Preservation Framework Overhead
For testing the overhead of the privacy preservation framework, we performed two experiments.
The general setup is: Two devices (Samsung Galaxy Nexus (2x1.2 GHz ARM CPU, 1 GB RAM) mobile
phones) and one service (running on an X230 Lenovo ThinkPad) are connected via a network and
registered at the GAMBAS registry such that they may interact with each other. One of the devices
issues queries to both the other device and a service. The measurements are taken with encryption
and access control enabled and disabled to estimate the overhead induced by the mechanisms of the
privacy preservation framework. The first experiment involves one smartphone and one service
interacting with each other, the second experiment involves only two smartphones interacting.
4.1.1 Smartphone-Service Interaction
Here, we were using the Weather Service example. The service in this example retrieves the current
weather via the API from wetter.com and stores it in its semantic data storage (SDS). A smartphone
can then query this service’s SDS and retrieve the current weather. The weather is then displayed to
the user. The service uses a well-known certificate that is used to exchange a key and establish a
secure client-server connection.

Figure 5 – Smartphone-Weather Service Interaction Diagram

For our measurements, we measured the complete query for the weather of the German city
Bremen. As can be seen in Figure 5, this query first retrieves the city code and then the complete
object City including the references (i.e., the three weather predictions). In total, this executes 6
queries. Since they are partly executed in parallel (i.e., the three predictions queries are executed in
parallel), this measurement includes at least three times the round-trip time (RTT). We performed
100 measurements each, for the secure and non-secure query.
GAMBAS STREP

9

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661
The results of the measurements are shown in Table 1. The overhead of the use of the privacy
preservation framework is in this case 39%.
Mode

Secure

NonSecure

Mean
12803
9187
(in ms)
Standard
Deviation
1777
645
(in ms)
Table 1 – Measurements of the Interaction between Smartphone and Weather Service

4.1.2 Smartphone-Smartphone Interaction
In this test, a smartphone queries a second smartphone for its User object in the SDS. The object is
then completely resolved (similar to the City object in the first experiment). In this case, this
executes 2 queries, one for the user’s name and the other one to resolve the object, also shown in
Figure 6. These measurements therefore include two times the RTT.

Figure 6 – Smartphone-Smartphone Interaction Diagram

Again, we performed 100 measurements for each case. For the secure case, we were using a shared
key that was exchanged before using NFC. The results of the measurements are shown in Table 2.
The overhead of the use of the privacy preservation framework in this case is again 39%.
Mode

Secure

NonSecure

Mean
3756
2710
(in ms)
Standard
Deviation
448
392
(in ms)
Table 2 – Measurements of the Interaction between two Smartphones

Both measurements show that the security which is provided by the privacy preservation framework
does not come for free, but that its execution is still feasible on resource-poor devices. The privacy
preservation framework is therefore lightweight and can be run on resource-constrained devices
such as smartphones.

GAMBAS STREP

10

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

5 Conclusion
This document described the second prototype of the privacy preservation framework developed by
the GAMBAS project. To clarify the scope of the second version of the prototype, this document first
discussed the features that have been targeted and showed what was already implemented in the
first version. Thereafter, it outlined the architecture with pointers to sub-modules and classes that
implement the different features. Finally, the document reported on an initial set of laboratory tests
that have been performed in order to demonstrate the maturity and the features of the
implementation.
Again, it is important to stress that this document itself only accompanies the prototype and it is not
an actual deliverable. The actual deliverable, i.e., the code of the prototype, can be accessed via the
shared code repository hosted by UDE. Intuitively, the code of this prototype will evolve during the
second integration with the remaining systems of the GAMBAS middleware and the planned privacy
policy generator (D3.3). As shown in the first integration and the development of the first version of
the application prototype as well as the tests that are contained in this document, the privacy
preservation framework is very mature and is used during the development of other GAMBAS
applications as a reliable component of the GAMBAS middleware.

GAMBAS STREP

11

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

FP7-2011-7-287661

6 Bibliography
[BASE] BASE Project, Project Homepage, November, 2013, online at http://code.google.com/p/pppc-base/
[PIKE] Apolinarski, Wolfgang; Handte, M.; Iqbal, M.U.; Marrón, P.J., "PIKE: Enabling Secure Interaction with
PIggybacked Key-Exchange," in Pervasive Computing and Communications (PerCom), 2013 IEEE
International Conference on, March 19-21

GAMBAS STREP

12

D3.2.2 PRIVACY PRESERVATION FRAMEWORK 2

Dokumen yang terkait

Perencanaan Proses Pembuatan Cetakan Casing Handphone Nokia Type 3330 Melalui Program Mastercam V.9 dengan Menggunakan Mesin Frais CNC

0 11 1

Perancangan Pompa Hidram Type Double Waste Valve Dengan Head Pompa 20 m

1 22 1

Faktor yang Berhubungan dengan Tingkat Kecemasan Penderita Diabetes Mellitus Tipe 2 di Rumah Sakit Nusantara Medika Utama (Factors Associated With Anxiety Type 2 Diabetes Mellitus Patients at Nusantara Medika Utama Hospital )

0 3 7

Hubungan Tingkat Kecemasan pada Pasien Multigravida dalam Persalinan Normal dengan Lama Persalinan di RSD dr.Soebandi Kabupaten Jember (The Relationship between Anxiety Level in Multigravida on Facing Normal Delivery and Length of Delivery at dr.Soebandi

2 46 4

The Ways In Which Information Given Related To The Type Of Visitor (A Description on Guiding Technique at the Room of History of Life in Bandung Museum of Geology)

0 16 48

Cover kaset Actual

0 3 24

PENGARUH ARUS PENGELASAN TERHADAP KEKUATAN TARIK PADA PENGELASAN BIMETAL (STAINLESS STEEL A 240 Type 304 DAN CARBON STEEL A 516 Grade 70) DENGAN ELEKTRODA E 309-16

10 133 86

Analisis Pengaruh Pengumuman Dividen Terhadap Harga Saham Disekitar Tanggal Ex-Dividen Date

0 8 56

Efek Pemberian Asam Alfa Lipoat terhadap Kadar MDA dan Gambaran Histologi pada Hati Tikus Model Diabetes Melitus Tipe 1 Effect of Alpha Lipoic Acid Administration on MDA Levelsa and Liver Histology of Type 1 Diabetes Mellitus Mice Model

0 0 7

Efek Asam Alfa Lipoat pada Kadar MDA dan Histologi Ginjal Tikus Wistar Diabetes Melitus Tipe1 Effect of Alpha Lipoic Acid on MDA Levels and Histology of Wistar Rats' Kidney Type 1 Diabetes Mellitus

0 0 5