• Tidak ada hasil yang ditemukan

Contract Delivery Date Actual Delivery Date Deliverable Type

N/A
N/A
Protected

Academic year: 2018

Membagikan "Contract Delivery Date Actual Delivery Date Deliverable Type"

Copied!
16
0
0

Teks penuh

(1)

Document Title Document Version D3.2.2 Privacy Preservation Framework 2 0.5

Project Number Project Acronym Project Title

FP7-2011-7-287661 GAMBAS Generic Adaptive Middleware for Behavior-driven Autonomous Services

Contract Delivery Date Actual Delivery Date Deliverable Type Deliverable Access

M22 05.12.2013 P (Prototype) CO (Confidential)

Document Author or Reviewer Organization Work Package

Wolfgang Apolinarski UDE WP3

Marcus Handte UDE WP3

Josiane Xavier Parreira NUIG WP3

Abstract

(2)

0.2 UDE Added the Prototype Structure.

0.3 UDE Added the Prototype Testing, Conclusion.

0.4 NUIG Document review

(3)

Table of Contents

1 Introduction ... 1

1.1 Purpose ... 1

1.2 Scope ... 1

1.3 Structure ... 2

2 Prototype Coverage ... 3

2.1 Prototype 1 ... 4

2.2 Prototype 2 ... 4

3 Prototype Structure ... 6

3.1 Security Mechanisms ... 6

3.1.1 Key Exchange ... 6

3.2 Privacy Policy ... 7

3.2.1 Policy Interface and RDF representation ... 7

3.2.2 Policy GUI ... 8

4 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

(4)

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

(5)

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

(6)

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.

(7)

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

(8)

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 (keyed-hash 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

(9)
(10)

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

(11)

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 privacy-preserved sharing of context information to the GAMBAS prototype.

3.2.1 Policy Interface and RDF representation

(12)

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.

(13)

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

(14)

The results of the measurements are shown in Table 1. The overhead of the use of the privacy

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

Non-Table 2 – Measurements of the Interaction between two Smartphones

(15)

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.

(16)

6

Bibliography

[BASE] BASE Project, Project Homepage, November, 2013, online at http://code.google.com/p/pppc-base/

Gambar

Figure 1 – Architectural overview
Figure 2 – Manual key creation in the GAMBAS privacy UI
Figure 3.
Figure 4 – Privacy Policy GUI
+3

Referensi

Dokumen terkait

Peluang munculnya angka lebih besar dari 4 pada dadu atau gambar pada uang adalah.... Di dalam setiap kotak pada gambar terdapat angka

menerapkan dari karakter atau ciri- ciri dari setiap gaya dalam merancang sebuah karya desain komunikasi visual, sehingga4. karya yang dihasilkan

Teknik pengumpulan data adalah studi kepustakaan, studi lapangan (observasi dan wawancara) dan dokumentasi. Penulis mengunakan teknik analisis data kualitatif melalui

Jika garis pada satu himpunan dengan himpunan lainnya tidak ada yang sejajar dan tidak ada 3 garis berpotongan di titik yang sama, maka jumlah titik perpotongan yang

Penelitian ini dilatarbelakangi oleh rendahnya produktivitas kerja, kurangnya kualitas pelayanan, rendahnya akuntabilitas perangkat desa dalam memberikan pelayanan,

Dua bangun atau lebih dikatakan kongruen jika bangun-bangun tersebut memiliki bentuk dan ukuran yang sama serta sudut-sudut yang bersesuaian sama besar.. Kongruen disebut juga

• Berdasarkan struktur huruf dapat di bagi beberapa macam meliputi jenis, bentuk dan keluarga huruf • Berikut ini uraiannyaeriku... 9.2

Jika dua sudut yang bersesuaian dari dua segitiga sama besar dan sisi yang berada di antaranya sama panjang (sd.s.sd) maka kedua segitiga itu kongruen.. Setiap pasang