D4.6 Final CITADEL security toolkit · D4.6 – Final CITADEL security toolkit Version 1.0 –...

D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019

Project Title: CITADEL Contract No. GA 726755

www.citadel-h2020.eu of 67

Empowering Citizens to Transform European Public Administrations

Deliverable D4.6

Final CITADEL security toolkit

Editor(s): Domenico Rotondi, Diomede Illuzzi, Marco Saltarella

Responsible Partner: Fincons

Status-Version: V1.0

Date: 31/03/2019

Distribution level (CO, PU): PU

http://www.citadel-h2020.eu/




Project Number: GA 726755

Project Title: CITADEL

Title of Deliverable: Initial CITADEL Security toolkit

Due Date of Delivery to the EC: 31/03/2019

Workpackage responsible for the Deliverable:

WP4 – ICT Enablers to transform

Editor(s): Diomede Illuzzi (FINCONS) Domenico Rotondi (FINCONS) Marco Saltarella (FINCONS)

Contributor(s): Marisa Escalante (TECNALIA)

Reviewer(s): Gorka Benguria (TECNALIA)

Approved by: All Partners

Recommended/mandatory readers:

WP5

Abstract: This toolkit will include the final development of the service that contains engines for privacy policy computation and data anonymization, privacy watchdog, access rights enforcement and anonymized big data analytics.

Keyword List: Security, Privacy, Blockchain

Licensing information: Anonymization components are released under Apache 2 Licence and 3

Access and Encryption Manager are released under GPL2.

The document itself is delivered as a description for the European Commission about the released software, so it is not public.

Disclaimer This document reflects only the author’s views and neither Agency nor the Commission are responsible for any use that may be made of the information contained therein





Document Description

Document Revision History

Version Date Modifications Introduced

Modification Reason Modified by

v0.1 01/12/2018 First TOC and sections assignment. FINCONS

v0.2 19/01/2019 Access and Encryption Manager description first update

FINCONS

V0.3 20/02/2019 Access and Encryption Manager description final update

FINCONS

V0.4 22/03/2019 Internal review of the document FINCONS

V0.5 27/03/2019 Review of the document TECNALIA

V0.6 30/03/2019 Implementation of modifications required by the internal reviewer

FINCONS

V1.0 31/03/2019 Ready for submission TECNALIA





Table of Contents

Table of Contents .......................................................................................................................... 4

List of Figures ................................................................................................................................ 5

List of Tables .................................................................................................................................. 6

Terms and abbreviations ............................................................................................................... 7

Executive Summary ....................................................................................................................... 8

1 Introduction .......................................................................................................................... 9

1.1 About this deliverable ................................................................................................... 9

1.2 Fitting into overall CITADEL Architecture ...................................................................... 9

1.3 Document structure ...................................................................................................... 9

2 Anonymization component ................................................................................................. 10

2.1 Implementation ........................................................................................................... 10

2.1.1 Functional description ......................................................................................... 10

2.1.2 Technical description .......................................................................................... 11

2.1.2.1 Prototype architecture .................................................................................... 11

2.1.2.2 Technical specifications ................................................................................... 13

2.2 Delivery and usage ...................................................................................................... 14

2.2.1 Package information ........................................................................................... 14

2.2.2 Installation instructions ....................................................................................... 17

2.2.2.1 Pre-Requirements ........................................................................................... 18

2.2.3 User Manual ........................................................................................................ 18

2.2.4 Licensing information .......................................................................................... 23

2.2.5 Download ............................................................................................................ 23

3 Access and Encryption Manager ......................................................................................... 25

3.1 Implementation ........................................................................................................... 25

3.1.1 Functional description ......................................................................................... 25

3.1.2 Design constraints ............................................................................................... 26

3.1.3 Technical description .......................................................................................... 31

3.1.3.1 System Architecture ........................................................................................ 34

3.1.3.2 Municipality of Bari pilot specification ............................................................ 36

3.1.3.3 Technical specifications ................................................................................... 40

3.2 Delivery and usage ...................................................................................................... 40

3.2.1 Package information ........................................................................................... 40

3.2.1.1 Package extensions to support the Smart Working validation scenario ........ 41

3.2.2 Installation instructions ....................................................................................... 42

3.2.2.1 Pre-Requirements ........................................................................................... 42

3.2.2.2 OpenLDAP configuration and startup ............................................................. 42





3.2.2.3 OrientDB configuration and startup ................................................................ 44

3.2.2.4 General configuration ..................................................................................... 44

3.2.2.5 Web applications deployment and configuration ........................................... 45

3.2.2.6 HTTPS configuration ........................................................................................ 47

3.2.2.7 Parity configuration and synchronization ....................................................... 49

3.2.2.8 Oracles deployment and configuration ........................................................... 49

3.2.3 User Manual ........................................................................................................ 50

3.2.3.1 Smart Working App User Manual ................................................................... 53

3.2.4 Licensing information .......................................................................................... 55

3.2.5 Download ............................................................................................................ 55

4 Conclusions ......................................................................................................................... 56

References ................................................................................................................................... 57

Annex 1: AuthZ/AuthN and Encryption client libraries .............................................................. 59

Annex 2: Anonymization API ...................................................................................................... 66

List of Figures

FIGURE 1. ACCESS AND ENCRYPTION MANAGER WITHIN THE CITADEL ECOSYSTEM ..................................... 9 FIGURE 2. GENERAL ARCHITECTURE OF ANONYMIZATION COMPONENT. ................................................... 12 FIGURE 3. ANONYMIZATION COMPONENT M15 PROTOTYPE HIGH LEVEL ARCHITECTURE ............................ 12 FIGURE 4. UML DIAGRAM OF THE MOST IMPORTANT CLASSES IN THE PUBLIC API [3] ................................. 13 FIGURE 5. EXAMPLE OF K-ANONYMITY, WHERE K=2 AND QUASI IDENTIFIER = {RACE, BIRTH, GENDER, ZIP} ... 14 FIGURE 6. SOURCE FOLDER STRUCTURE OF ANONYMIZATION COMPONENT IN M15 (ARX LIBRARIES) ........... 15 FIGURE 7. CLASSES INSIDE ORG.DEIDENTIFIER.ARX.IO PACKAGE. .............................................................. 16 FIGURE 8. CLASSES INSIDE ORG.DEIDENTIFIER.ARX.AGGREGATES PACKAGE ................................................ 16 FIGURE 9. CLASSES INSIDE ORG.DEIDENTIFIER.ARX.CRITERIA PACKAGE ...................................................... 17 FIGURE 10. K-ANONYMITY CLASS SOURCE CODE. .................................................................................. 17 FIGURE 11. LAUNCHING ARX ............................................................................................................ 19 FIGURE 12. OPENING AN EXISTING PROJECT ......................................................................................... 19 FIGURE 13. LOADING AN EXISTING CITADEL PROJECT ............................................................................. 20 FIGURE 14. IMPORTING SOURCE DATA TO BE ANONYMIZED .................................................................... 20 FIGURE 15. SOURCE DATA LOADED. .................................................................................................... 21 FIGURE 16. DE-IDENTIFICATION PROCESS CONFIGURATION PART 1: DATA TYPE AND TRANSFORMATION TYPE. . 21 FIGURE 17. DE-IDENTIFICATION PROCESS CONFIGURATION PART 2: PRIVACY MODEL CONFIGURATION ........... 22 FIGURE 18. SOURCE DATA VS. ANONYMIZED DATA ................................................................................ 22 FIGURE 19. EXPORTING ANONYMIZED DATA ......................................................................................... 23 FIGURE 20. SAVING ANONYMIZED DATA. ............................................................................................. 23 FIGURE 21. OVERALL DIRECTORY SERVICE STRUCTURE .......................................................................... 32 FIGURE 22. ACCESS AND ENCRYPTION MANAGER ARCHITECTURE ............................................................ 34 FIGURE 23. ARCHITECTURE OF THE VALIDATION SCENARIO SUPPORTING SMART WORKING .......................... 36 FIGURE 24. CREATE SMART WORKER PROFILE SEQUENCE DIAGRAM ......................................................... 37 FIGURE 25. ENROL SMART WORKER SEQUENCE DIAGRAM ..................................................................... 38 FIGURE 26. SMART WORKING DLT TRANSACTION SEQUENCE DIAGRAM ................................................... 39 FIGURE 27: ACCESS AND ENCRYPTION MANAGER SOURCE CODE FOLDERS STRUCTURE ................................ 40





FIGURE 28. REGISTRATION PAGE ........................................................................................................ 51 FIGURE 29. CREATE POLICY TOOL ...................................................................................................... 52 FIGURE 30. VIEW POLICY PAGE .......................................................................................................... 52 FIGURE 31. UPLOAD DOCUMENT PAGE ............................................................................................... 53 FIGURE 32.DOWNLOAD DOCUMENT PAGE ........................................................................................... 53 FIGURE 33. SMART WORKING APP FIRST ACCESS ................................................................................. 54 FIGURE 34. SMART WORKING APP ..................................................................................................... 55 FIGURE 35. GENERALIZATION LEVELS EXAMPLE ..................................................................................... 67

List of Tables

TABLE 1. FUNCTIONALITY COVERED BY THE M15 ANONYMIZATION COMPONENT PROTOTYPE. ..................... 10 TABLE 2. GDPR PRINCIPLES AND PROCEDURES FOR COMPLIANCE ............................................................ 27 TABLE 3. RIGHTS OF THE INTERESTED PARTY ENVISAGED BY THE GDPR AND METHODS OF EXERCISE .............. 28 TABLE 4. EXAMPLE OF ROLES AND RELATED PERMISSIONS CONFIGURED IN THE COMPONENT ........................ 33 TABLE 5.ACCESS AND ENCRYPTION MANAGER TECHNOLOGICAL STACK ..................................................... 40 TABLE 6. CONTENTS OF THE FOLDERS INCLUDED INTO THE DELIVERED PACKAGE ......................................... 40 TABLE 7. CONTENTS OF THE FOLDERS OF THE SMART WORKING EXPERIMENTATION INCLUDED INTO THE DELIVERY

PACKAGE ................................................................................................................................ 41





Terms and abbreviations

ACL Access Control List

AES Advanced Encryption Standard

AN Anonymization Component

API Application Programming Interface

CP-ABE Ciphertext Policy Attribute Based Encryption

EC European Commission

ECC Elliptic Curve Cryptography

ECDH Elliptic Curve Diffie–Hellman

GUI Graphical User Interface

JWT Json Web Token

LDAP Lightweight Directory Access Protocol

PA Public Administration

PII Personal Identifying information





Executive Summary

The objective of the document is to provide the information about the two components, Anonymization and Access and Encryption Manager forming the final version of the CITADEL security kit.

The Anonymization component will remove personally identifiable information (PII) from user data or masquerading (i.e. through encryption mechanisms) identifying information (pseudo-anonymization) of user data prior to be used by other CITADEL components or by a PA. The Access and Encryption Manager component will provide a scalable security layer pluggable into the CITADEL ecosystem.

The document presents the missions, scopes, functional descriptions, technical approaches, download & installation instructions and user manuals of these components comprising the CITADEL security toolkit.





1 Introduction

1.1 About this deliverable

This document is the complement to the Final CITADEL security toolkit software delivered as prototype for the Deliverable D4.5 in December 2017.

1.2 Fitting into overall CITADEL Architecture

The Security Toolkit was envisioned as the component responsible to provide the access management mechanisms for the entire ecosystem (and the components and tools) as well as anonymization, encryption and other security functionalities to preserve sensitive data in the ecosystem.

Figure 1. Access and Encryption Manager within the CITADEL ecosystem

1.3 Document structure

The following sections describe the subsystems part of the CITADEL security toolkit.

Section 2 Anonymization

This section introduces the functional (section 2.1.1) and technical (section 2.1.2) description of the Anonymization component while sub-section 2.2 provides a description of the delivery and usage of it, including installation and downloading instructions.

Section 3 Access and Encryption Manager

This section introduces the functional (section 3.1.1) and technical (section 3.1.2) description of the Access and Encryption Manager component while sub-section 3.2 provides a description of the delivery and usage of it, including installation and downloading instructions.

To finalize the deliverable, a section with the main conclusions is presented.





2 Anonymization component

2.1 Implementation

2.1.1 Functional description

The Anonymization Component (AN) is responsible to remove personally identifiable information (PII) from user data or masquerading (i.e. through encryption mechanisms) identifying information (pseudo-anonymization) of user data prior to be used by other CITADEL components or by a PA.

The Anonymization Component uses privacy ontologies, in order to implement a more generalized logic to match PII with the anonymization or pseudo-anonymization requirements (rules).

The main functionalities of the Anonymization component are:

F1. Information gathering data from different data sources to be anonymized. The gathering of the information will be supported through different interfaces: graphical interface for the PAs and programmatic interfaces for other components of the CITADEL ecosystem.

F2. Data anonymization process configuration based on the nature of the data and the anonymization requirements needs, including, specification of the data source, selection of the data, selection of the algorithm to be applied.

F3. Data anonymization based on the specific configuration selected, through the application of the selected privacy model.

F4. Creation of the anonymized set of data and provision in the same format as the data source.

Anonymization component was implemented following an incremental approach adding features in the different releases of the CITADEL security toolkit (D4.6 in M33). In this first release the following functionalities are partially implemented: F1, F2, F3 and F4.

The Table 1 details the relationship between the functional requirements indicated in deliverable D4.3 [1] and the implemented functionalities, with a description of the coverage for each functionality.

Requirements covered by the prototype:

Table 1. Functionality covered by the M15 Anonymization component prototype.

Functionality Req. ID Coverage

F1 AN.01 The current version of the prototype supports the gathering of the data in these formats: files containing character separated values (CSV), MS Excel spreadsheets and relational database systems, such as MS SQL, DB2, MySQL or PostgreSQL.

The current prototype offers a GUI for importing the data (when the user is a PA) and a Java based API (when the user a component inside CITADEL ecosystem).

F2 AN.01 The current prototype allows configuring the data de-identification process by the selection of the privacy model and the classification of the attributes types inside the data





Functionality Req. ID Coverage

(identifying attribute, quasi-identifying attribute, sensitive attribute and insensitive attribute).

Several privacy models are supported by the anonymization component, but in CITADEL we have focused in K-anonymity [2] (see next section for details) especially recommended against identity disclosure.

Generalization hierarchies can be also configured. These will be applied to the different attributes on the data source depending on the selected privacy model.

F3 AN.01 The current prototype includes the needed algorithm for applying the selected privacy model (in this case K-anonymity) in the selected data set.

F4 AN.02 The current prototype creates the anonymized data, based on the privacy model chosen, and exports the anonymized data to files containing character separated values (CSV).

Functionality that this prototype offers:

The delivered prototype is the first version of the Anonymization Component and contains the following functionality:

• Gathering external data to be anonymized.

• Configuration of the anonymization process (including privacy model selection)

• Creation of the anonymized data.

2.1.2 Technical description

This section describes the technical details of the implemented software for the current prototype (M15) of Anonymization Component.

2.1.2.1 Prototype architecture

In the following picture, the general architecture of the Anonymization Component components is shown, for detailed description check D4.3 [1]:





Figure 2. General architecture of Anonymization Component.

As far as the current prototype (M15) of Anonymization Component architecture is concerned, it consists of two tiers, as shown in Figure 3:

Figure 3. Anonymization Component M15 prototype High level architecture

Beyond the Anonymization engine, responsible for the actual execution of the anonymization task, the component also provides a graphical user interface so that the target users (PAs’ representatives) are enabled to directly use the component.

The Anonymization Component provides the AnonymizationConnector interface (which exposes the Anonymization API) through which the other CITADEL components can post the anonymization requests and the necessary parameters (source data, anonymization process configuration information, etc.). The Anonymization Component will also use the Authentication interface to perform the authentication process when needed.

The current prototype includes 2 of the 3 components envisioned for the Anonymization Component [1].

• AN UI: This sub-component includes all the functionalities to support the graphical interface of the anonymization component. It provides graphical interface to import the data, configure the de-identification process (generalization hierarchies, metadata definition, etc.).

• AN engine: This sub-component includes all the functionalities to support the actual de-identification of the data based on a pre-stablished configuration.

• Anonymization API: Provides the means to request and perform the anonymization of the data programmatically. Different functions are provided through the API, grouped into 3 main categories (or functional blocks):





o Package 1 including the functions for the configuration of the anonymization process.

o Package 2 including the functions for the actual anonymization of the data. o Package 3 including the functions for getting the results of the anonymization

process.

2.1.2.2 Technical specifications

For this first version the Anonymization Component prototype is based on the ARX framework [3]. This open source framework was included in the benchmarking analysis reported in WD4.1 [4].

ARX is an open-source framework that supports data anonymization tasks through an algorithm covering a broad spectrum of privacy problems. It supports several privacy methods, k-anonymity, all variants of ℓ-diversity, two variants of t-closeness, and δ-presence [3].

AN UI and AN engine subcomponents of the Anonymization Component in M15 were provided through the ARX tool and its user interface, while the AN API, is provided through the ARX API [5].

The stand-alone part of the ARX tool is targeting non-ICT users which want to anonymize data through generalization (replacing the value with a less specific but semantically consistent value) and suppression of data (deleting the value), while the provided Java library is intended to be used by the other CITADEL components, to programmatically perform the anonymization process.

Figure 4. UML diagram of the most important classes in the public API [3]

For the purpose of CITADEL, Anonymization Component will use the k-Anonymity generalization algorithm. K-anonymity privacy model [2] aims at protecting datasets from identity disclosure following the prosecutor attacker model. A dataset is k-anonymous if, regarding the quasi-identifiers, each data item cannot be distinguished from at least k − 1 other data items. The tuples with identical values for all quasi-identifiers form an equivalence class.

Sweeney reported in [6] that, for example, 87% (216 million of 248 million) of the population in the United States had reported characteristics that enabled to make them unique on the basis of only 3 attributes (5-digit ZIP, gender, date of birth). Clearly, data released containing such information about these individuals should not be considered anonymous.

The next example of K-anonymity model is provided by Sweeney in [2]:





Figure 5. Example of k-anonymity, where k=2 and Quasi Identifier = {Race, Birth, Gender, ZIP}

Figure 5 provides an example of a table (T) that adheres to k-anonymity. The quasi-identifiers1 for the table are Quasi Identifier = {Race, Birth, Gender, ZIP} and k=2. Therefore, for each of the tuples contained in the table T, the values of the tuple that comprises the quasi-identifier appear at least twice in T. That is, for each sequence of values in T [Q IT] there are at least 2 occurrences of those values in T [QIT]. In particular, t1[QIT]= t2[QIT], t3[QIT]=t4[QIT], t5[QIT]=t6[QIT], etc. It can be trivially proven that if the released data RT satisfies k-anonymity with respect to the quasi-identifier QI, then the combination of the released data RT and the external sources on which QI was based, cannot link on QI or a subset of its attributes to match fewer than k individuals.

This property does not guarantee individuals cannot be identified in T; there may exist other inference attacks that could reveal the identities of the individuals contained in the data. However, the property does protect T against inference from linking (by direct matching) to known external sources; and in this context, the solution can provide an effective guard against re-identifying individuals.

For the purpose of CITADEL, PAs and other CITADEL ecosystem components may use citizen’s data for customizing the offer of public services, creating KPIs on the usage of public digital services, providing recommendations, etc. These data may be needed to be anonymized (under request).

2.2 Delivery and usage

2.2.1 Package information

The packages delivered within the present release of the Anonymization component can be categorized as:

• Core packages: Comprising the sets of packages and the related java classes, interfaces and methods to perform the acquirement and anonymization of the data, through the AN engine sub-component.

1 Quasi-identifiers are pieces of information that are not by themselves unique identifiers, but are sufficiently well correlated with an entity that they can be combined with other quasi-identifiers to create a unique identifier.





• UI packages: Comprising the packages and the related java classes, interfaces and methods needed for the graphical interface, through the AN UI sub-component.

Delivered package are structured according to the folder structure reported below.

Figure 6. Source folder structure of Anonymization Component in M15 (ARX libraries)

All these packages are documented in [7]. Each package contains the different java classes to perform the different anonymization functionalities. These packages with the ARX libraries have been imported into the CITADEL development environment, composing the first version of the Anonymization Component in the CITADEL security toolkit.

Relevant packages/classes are:

• Package org.deidentifier.arx.io: This package provides basic input/output functionality.





Figure 7. Classes inside org.deidentifier.arx.io package.

• Package org.deidentifier.arx.aggregates.: This package provides methods to aggregate data.

Figure 8. Classes inside org.deidentifier.arx.aggregates package

• Package org.deidentifier.arx.criteria: This package implements different variants of class-based privacy criteria, such as k-anonymity, l-diversity, t-closeness and d-presence.





Figure 9. Classes inside org.deidentifier.arx.criteria package

For CITADEL, KAnonymity class is relevant:

Figure 10. k-Anonymity class source code.

2.2.2 Installation instructions

For the Anonymization Component GUI, executable jar files and self-contained binary installers are provided by ARX.





To install them download the installers from ARX2 and follow the instructions.

The ARX API libraries can be downloaded from ARX3.

2.2.2.1 Pre-Requirements

For the runnable Jar files current Oracle or OpenJDK Java Runtime Environment is needed.

For the binary installers the proper Operating System is needed (available versions for Windows 32/64 bits are provided by ARX).

For the usage of the API, the libraries need to be included in the project and the classes imported so that they can be invoked (see Annex 2).

2.2.3 User Manual

Anonymization Component:

In this user manual we will focus only on the functions from ARX which are relevant for CITADEL Anonymization component. ARX framework supports other functionalities which will not be explained in this user manual.

After the installation process the application can be launched from the operating system:

2 http://arx.deidentifier.org/downloads/ 3 http://arx.deidentifier.org/?ddownload=1924


http://arx.deidentifier.org/downloads/

http://arx.deidentifier.org/?ddownload=1924




Figure 11. Launching ARX

Once the framework is launched, a new project can be created or opened. In this example, a pre-created project is opened and loaded (citadel example):

Figure 12. Opening an existing project





Figure 13. Loading an existing citadel project

The loaded project, already provides input data. If new data need to be included, it can be done through the edit menu:

Figure 14. Importing source data to be anonymized





Figure 15. Source data loaded.

Once the data is loaded the de-identifying process can be configured setting the different parameters:

• Data type depending on the nature of each data: Insensitive, sensitive, quasi identifying, identifying.

• Transformation configuration: Selection of the transformation (Generalization, micro-aggregation) and the possible values for the generalization.

• Privacy model: Selection and configuration of the privacy model.

Figure 16. De-identification process configuration part 1: data type and transformation type.





Figure 17. De-identification process configuration part 2: privacy model configuration

After the transformation process has been configured, the output data can be analyzed, checked and exported.

Figure 18. Source data vs. anonymized data





Figure 19. Exporting anonymized data

Figure 20. Saving anonymized data.

2.2.4 Licensing information

The ARX framework and anonymization tool are licensed under Apache License, Version 2.0.

2.2.5 Download

The source code is available in the EC portal for deliverables, included in the zip file for D4.5.





The first release is available in the CITADEL open git repository, more precisely at the following address:

https://git.code.tecnalia.com/DECIDE_Public/DECIDE_Components/tree/master/ADAPT/Monitoring https://git.code.tecnalia.com/CITADEL_Public/CITADEL_Components/tree/M15/Security/Anonymization





3 Access and Encryption Manager

3.1 Implementation

3.1.1 Functional description

The Access and Encryption Manager component provides a scalable security layer pluggable into the CITADEL ecosystem.

The component, in fact, has been designed according to the Security-by-Design, Privacy-by-Design and Security-by-Default and Privacy-by-Default principles.

Security/Privacy-by-Design means that a system has been designed taking into account the security and confidential data management needs, so the security and privacy (i.e., proper management of confidential or personal data) is an essential element of the system. Security/Privacy-by-Default means that the security design and default configuration of the system already assure a minimum level (which means an acceptable level which can be increased only) of security and privacy that: (1) cannot be lowered, (2) is configured by default.

Indeed, one of the most relevant features of this component is the end-to-end protection of confidential data achieved using new cryptographic techniques like CP-ABE (Ciphertext Policy Attribute Based Encryption, [8]). From the security point of view, in addition to the CP-ABE encryption techniques, the component makes use of the new W3C Web Crypto API [9], Elliptic Curve Cryptography (ECC), Elliptic Curve Diffie–Hellman (ECDH, [10]) and JWT [11]. To increase system’s security every operation requires a specific Authorization Token that is dynamically generated based on the user’s profile and the requested operation.

In addition to the functionalities provided with the first prototype, the final CITADEL Security toolkit includes Distributed Ledger Technology (DLT, [12]) to increase security of transactions carrying personal data and to provide a more transparent way of handling records because the information is shared, and thereby witnessed across a network, which also makes a successful cyberattack much more unlikely.

The component provides the following features:

• User profile management, registration, authentication and authorization;

• Creation of CP-ABE policies to specify who can have access to information encrypted (with that policy);

• Combination of CP-ABE asymmetric encryption technique and AES (see [13]) symmetric one to lower resource usage;

• Encryption and decryption of information available in different formats;

• Upload and encryption of files;

• Download and decryption of the encrypted files;

• Support for data confidentiality and compliance with the legislation in this regard (GDPR in particular);

• Support for secure transactions through DLT.

In order to validate the above listed functionalities of the CITADEL Security Toolkit, FINCONS has implemented a solution, based on the use of Ethereum DLT, for supporting the Bari Municipality strategy in terms of “Smart Working” in compliance with the law of 22th May 2017 n. 81 “Measures for the protection of non-entrepreneurial self-employment and measures to encourage flexible articulation in the time and place of subordinate work”.





The solution, in practice, provides the tools necessary for the management of the smart working activity at the Municipality of Bari. In this respect, two roles have been assumed as involved in the scenario depicted:

• the smart worker representing the employee who performs his activity within the smart working programme,

• the supervisor (o hierarchical responsible) with the task to control the smart worker activity.

It is assumed, furthermore, with reference to the working days spent in smart working mode, that any smart worker has defined and agreed the following elements:

• tasks,

• objectives, usually linked to the workloads defined in the scope of the ordinary working activity,

• time frames (typically from 6:00 to 22:00), number of daily working hours (from 6,5 to 10), availability periods and performance expected for the day(s) spent in smart working.

On the other hand, the supervisor:

• is aware of tasks, objectives and timing of the smart worker that he supervises,

• is enabled to access data related to the activities carried out by the smart worker for verification purposes.

The management of the smart working activities makes necessary:

• a personal device (smart phone / tablet) available to each smart worker and a specific app through which the smart worker can report and check the information about the "presence" (i.e. being active as a smart worker) during the day,

• an application service available to the supervisor through which he can monitor the activity performed by smart workers who report to him and certify the activity carried out.

3.1.2 Design constraints

The system has been designed to comply with the provisions of the GDPR as well as the rulings of the Guarantor for the Protection of Personal Data [14] [15] [16], and the Directive 3/2017 [17].

In light of these considerations it is clear that the system must comply with the guidelines of privacy-by-design and privacy-by-default [18] [19] [20] as required by the GDPR. Specifically, the privacy-by-design principle requires that from the design stage the system envisages adequate measures to safeguard the confidentiality of information that can be classified as personal or confidential. The privacy-by-default principle requires that the default values of the system guarantee an adequate level of protection of personal or confidential data. In addition, these two principles require that the minimum level of protection of personal or confidential data guaranteed by the system is anyhow adequate and that this level cannot be reduced below the minimum required. Indirectly this implies that the measures envisaged are, for the elements manageable by the user, comprehensible and correctly used (usable security [21] [22]).

With specific reference to the provisions of the GDPR, the system must guarantee compliance with the principles established by Art. 5 and guarantee the rights of the interested party as





defined in Articles 15, 16, 17, 18, 20, 21 and 22. Table 2 describes the procedures for compliance with the principles established by the GDPR, with reference to the validation scenario described.

Table 2. GDPR principles and procedures for compliance

GDPR Principle Principle description Procedure for compliance

Legitimacy, fairness and transparency

personal data must be "processed lawfully, fairly and transparently", which implies that the controller must have legitimate reasons for collecting the information, it must be transparent which data are collected and for what purpose and it must be ensured that there are no illicit uses

The responsible for the treatment is the Municipal Administration of Bari which has legitimacy in the collection and use of the aforesaid data as they relate to its employees who voluntarily and freely participate in the Smart Working program

Purpose limitation

personal data must be "collected for specific, explicit and legitimate purposes" and used exclusively for the purposes indicated. Art. 89 of the GDPR does not consider incompatible with this principle the use of data collected for archiving purposes in the public interest or for scientific or historical research and for statistical purposes

The data collected are limited to those strictly necessary for the verification of the requirements for the smart working activities and are used for this purpose or for regulatory requirements.

Data in aggregate form can also be used for statistical analysis or for scientific publication

Data reduction

the personal data collected should be "adequate, relevant and limited to what is necessary" for the stated purposes

The collected data are exclusively related to the beginning and end of the activities in smart working mode, as well as to the physical location of the smart worker.

The aforementioned data are collected only on specific action of the smart worker, who therefore always has control over the data provided and full power to not supply them

Precision

personal data gathered must be "precise and, if necessary, updated". The data subject has the right to request that the inaccurate data held are corrected or deleted

The smart worker in the phase of submitting the data collected looks at the data provided and sends them explicitly.

The smart worker, moreover, always has the faculty to view the data acquired by the system and, in case of discrepancy, activate the procedures provided by the Administration





GDPR Principle Principle description Procedure for compliance

for the correction of the data related to the presence

Limitation on archiving

personal data must be "stored in a form that allows identification of data subjects for no longer than necessary" for the stated purposes. It is safeguarded the right of the controller to store data in the public interest and for scientific or statistical purposes

The data collected relating to the smart worker activities are solely aimed at managing its activities in smart working and maintained by the municipal administration solely for the purposes related to the work performance of the employee

Integrity and confidentiality

Personal data must be "processed in such a way as to guarantee adequate security"

The prototype system, as documented below, uses specific cryptographic techniques to guarantee the maximum protection and integrity of data and that their access in clear text is reserved exclusively to subjects explicitly authorized.

The data collected by the prototype system are transferred into the information systems of the municipal administration connected to the management of the activities of the employees for whom the security measures provided by the Administration are active

From the principles summarized in the previous table, a series of rights for data subjects and obligations for data controllers that are explained in the GDPR derive. Table 3 describes the ways in which the system allows you to exercise the rights provided by the GDPR.

Table 3. Rights of the interested party envisaged by the GDPR and methods of exercise

Right as envisaged by

the GDPR Right description Methods of exercise

Right of access by the data subject (Art. 15)

The data subjects has "the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being

The smart workers will be explicitly informed about: what information is acquired, how it is acquired, stored and processed and how it is possible







processed" and to receive details on how this is done and where

to verify its correctness and, if necessary, request its correction.

The purposes of data acquisition are exclusively those required for carrying out the activities according to the Administration’s Smart Working plan are detailed therein. Each smart worker explicitly and formally asks to be able to carry out part of his work with this new mode

Right to rectification (Art. 16)

The data subject has " right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement. "

The information acquired by the system, moreover explicitly provided by the smart worker, relates to the start-up or termination of work activities and the location in which these are performed.

The correction of any incorrect data relating to working hours will be managed through the usual Administration procedures related to the correction or integration of presence data

Right to erasure (Art. 17)

the data subject has " the right to obtain from the controller the erasure of personal data concerning him or her without undue delay" if these are no longer necessary or there are other impediments (e.g. for the fulfilment of a legal obligation)

The data provided by the smart worker are conveyed through a DLT system (Ethereum in the specific) and transferred to the information systems of the municipal administration.

With respect to the management via DLT, since data acquired in the distributed ledger cannot be removed, this right is complied with by using appropriate encryption techniques and by destroying the decryption keys relating to the information to be removed.







For the data transferred into the information systems of the Administration, the procedures established by the Administration are applied, if necessary

Right to restriction of processing (Art. 18)

the data subject has " to obtain from the controller restriction of processing" when certain hypotheses specified in Art. 18 occur

The information acquired is solely aimed at managing the work of the smart worker and is therefore managed and processed according to the provisions of the law and contracts.

The prototype system does not perform any form of data processing being its activity limited to acquiring data and transferring them to the information systems of the Administration. The acquired data is appropriately protected with advanced encryption mechanisms from the moment of acquisition to the time of its transcription into the information systems of the Administration

Right to data portability (Art. 20)

The data subject has " to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format”

The data collected are related to the verification of the performance of the contractually established work activities.

The smart worker is enabled to acquire these data for the uses provided by law

Right to object (Art. 21)

The data subject has " the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions"

The exercise of this right is limited because the data controller has legitimate reasons to proceed with the processing of data related to the performance of work







Rights related to automated individual decision-making (Art. 22)

The data subject has " the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her "

The aforementioned legislation (Article 14 of Law 124/2015) on smart working explicitly excludes penalties for the purposes of recognition of professionalism and career progression

3.1.3 Technical description

The Access and Encryption Manager component comprises a set of back-office services and client libraries whose integration within the CITADEL ecosystem enables other CITADEL components, in particular those treating personal data, to benefit from the security features the component provides.

The client libraries, available for both desktop and web applications, from the one hand enable the interaction with the back-office services, from the other hand provide security features on their own.

The component architecture integrates different protocols and security mechanisms to secure data exchange that preserve privacy. The algorithm selected to protect data is CP-ABE, due to its high flexibility and expressiveness, in combination with AES to reduce resource usage and speed up the encryption and decryption activities.

The CP-ABE encryption scheme, in fact, allows encrypting information based on user-defined access policies – which can be considered as actually encoded in, and an integral part of, the encrypted information - that specify the conditions a subject has to meet to succeed in the decryption of the information. In ABE systems, each subject has a personal key that is generated from a set of personal attributes (e.g. its profile). The subject’s personal key will be able to successfully decrypt the information only if the subject’s attributes are in line with the access rules in the access policy associated to the target information. However, ABE algorithms are not so efficient as symmetric encryption ones. To overcome CP-ABE limitations in speed and resource requirements, the component implements a novel approach that combines the efficiency of AES symmetric cryptography and the flexibility and fine granularity of attribute-based cryptography. Indeed, data sources encrypt the information they provide by using AES with symmetric keys, which in turn are CP-ABE encrypted by using data owner’s provided access policies. To retrieve such encrypted data, a consumer entity has to recover first the symmetric key using the CP-ABE algorithm and its CP-ABE private key and, only in case such CP-ABE key meets the access policy specified by the data owner, the obtained symmetric key will be successful in decrypting the AES encrypted data.

The security-by-design and privacy-by-design guidelines have guided the structuring of the system, as well as the design of the authentication and authorization features, and the selection of the related technologies as better highlighted below. The privacy-by-design guidelines essentially help in addressing issues related to the management of confidential and personal information (for example assuring end-to-end data protection). This ensures to the CITADEL users and operators that potentially confidential or sensitive information will never be accessed





by people not explicitly authorized, independently from where and how the information is stored and managed (e.g., backup systems).

The user’s authentication is actually performed using a proof of ownership instead of traditional authentication mechanisms (e.g., challenge/response), in order to avoid having to store on the service side security sensitive data like passwords.

In the case of integration within a web environment, on the basis of the information provided in the login form (username) the system queries the LDAP Service looking for a user entry matching the provided information and, in case of success, picks up from the LDAP user’s profile a kind of certificate holding the user’s (properly encrypted) private and public keys. This certificate, with some additional information is passed to the browser where the user, providing his/her password to specific JavaScript code running locally in the browser, generates a proof of ownership of the public key stored in the user’s LDAP profile.

The system checks the correctness of the proof of ownership and, if successful, generates a session token through which access to the system functionalities can be requested.

The user’s password is, therefore, only managed locally and never transmitted to, or shared with, other systems. Of course, if users forget their passwords they will not be able to access the system and there is no possibility to “email” user’s passwords. In this case the user has to ask for reset his/her registration.

The users’ profiles are managed using an LDAP Directory Service, so that we can connect to Users Management legacy systems (e.g., Windows Active Directory). Figure 21provides an overview of a possible overall directory organization.

Figure 21. Overall Directory Service Structure

The role associated to each user of the system can be selected among a predefined set as exemplified in the table below, which indicates the permissions assigned to each role, related to the possibility to view and / or to create a document and or an access policy (the permissions in general are limited to documents and policies defined in the frame of a specific use case, but users with Ethical Board Member role may have access to items linked to different use cases).





Table 4. Example of roles and related permissions configured in the component

Use Case A Use Case B …

Role File Policy File Policy File Policy

Use Case A

Interviewer Create View No Access No Access No Access

No Access

Use Case A

Analyst View

View /

Create No Access No Access No Access

No Access

Use Case A

Privacy Officer

View / Create /

Drop

View / Create

No Access No Access View No

Access

Ethical Board Member

View based on

policy

View /

Create

View based on

policy

View /

Create

View based on

policy

View /

Create

Administrator No Access No Access No Access No Access No Access No

Access

As mentioned, the technology selected for the DLT is Ethereum4, this choice is justified by being a DLT platform that supports a language almost Turing-completed5 for the implementation of decentralised applications6 and smart contracts. Ethereum is, thus, one of the most used platforms for this kind of solutions.

Furthermore, Ethereum is available and publicly accessible (permissionless blockchain7), so that it does not need additional HW and SW installations and provides networks for testing and experimentation.

The smart worker’s mobile device is typically an Android smart phone. Being needed specific encryption solutions, furthermore, the app is a native Android app developed with the Java language. The app UI follows AgID guidelines [23] and, in particular, uses elements defined in the Web Toolkit8. As far as the web application is concerned, the SW components on the client (browser) side are developed with Javascript, HTML and CSS according to the AgID provisions [23] and rely on the Web Toolkit components. The server components, instead, is implemented as Java Servlets and will operate within an Apache Tomcat open source servlet container.

The data structures exchanged among the different components of the architecture, with exception of those interfacing existing services (Presence Registration Service and CIPEL / ODE Service), are all compliant with the JSON9 standard so to minimize the amount of data transferred and speed up transmissions.

4 https://www.ethereum.org/ 5 https://en.wikipedia.org/wiki/Turing_completeness 6 https://en.wikipedia.org/wiki/Decentralized_application 7 https://en.wikipedia.org/wiki/Blockchain#Types_of_blockchains 8 https://designers.italia.it/kit/web-toolkit/ 9 https://en.wikipedia.org/wiki/JSON





3.1.3.1 System Architecture

The figure below provides the high-level architectural view of the component.

Figure 22. Access and Encryption Manager architecture

The system is made up of the following components (see Figure 22):

• the LDAP (Directory) Service: this service, based on the X.500 standard and the LDAP (Lightweight Directory Access Protocol) protocol, is used to manage customers’ and authorized users’ profiles. With reference to the authentication issues, the LDAP Service is not actually used to authenticate the user, but only to store user’s related information (i.e., user’s profile and certificate) necessary in the authentication and authorization (i.e., user’s role) process. This to assure, in line with the security-by-design approach, that sensitive information cannot be grabbed;

• the ABE Proxy is the component responsible to perform the heavy CP-ABE encryption operations.

• the ABE Key Generation Service is the entity responsible for generating CP-ABE private keys based on the attributes associated to the data consumer’s profile. The ABE Key Generation Service at 1st start-up generates two keys: the KGS public key used to encrypt information in conjunction with an access policy, and a KGS master key used, in combination with the user’s profile retrieved from the LDAP service, to generate the user’s private key necessary.

• the Access Token Service is devoted to manage authorization providing specific access tickets. Being the system distributed, there is the need to ensure that a specific request submitted by the user (or potentially by other components) is among the ones the user is authorized to perform (e.g., upload a file). Instead of having ACLs or other access control mechanisms on each service component, the system envisages a specific service that, based on the user’s profile stored in the LDAP Service, grants an access ticket;

• the Policy Storage Service is devoted to support the management (i.e., storage and retrieval) of the access policies that a given organisation can define to be used to encrypt the uploaded files as described in the next bullet. The functionalities supplied by this service are essentially to provide a storage area for each of the user belonging to the organisations registered within the system where they can store, or from which they can retrieve, the access policies they plan to use for encrypting their information. The access control to this service is managed via access tickets provided by the Access Token Service. From an operational point of view, when





submitting a policy storage or policy retrieval request this request has to provide an access ticket that provides evidence the request is authorized. The access ticket is validated by the service before performing the requested operation;

• the Storage Service is devoted to support the management (i.e., storage and retrieval) of encrypted data. The functionalities supplied by this service are essentially focused on providing a storage area for each of the users registered within the system where they can store, or from which they can retrieve, the files. Access to the stored files are managed via access tickets as described for the previous service;

• the Desktop /Web Client provides the web or desktop GUI supposed to integrate the libraries through which end-users, after login, can access the functionalities of the system; the libraries on the top of which the client has to be developed (available both in Java and JavaScript version, see Annex 1: AuthZ/AuthN and Encryption client libraries for API references) are:

o TokenServiceClientLib (Java) o FileProtectorServiceLib (Java) o abeClient (JavaScript) o AuthN-AuthZ (JavaScript)

Figure 23 depicts the system architecture supporting the Smart Working experimentation of Municipality of Bari.

In the architecture the following services are highlighted:

• AuthN Service: the service that manages, relying on the Directory Service, users’ profiles and users’ authentication in PoK mode,

• Directory Service: it is an LDAP service to manage users’ information in compliance with the DIT X.500 standard,

• Supervisor Application Service: it is the service that allows supervisors to acquire information about activities performed in smart working by smart workers for whom they are responsible,

• Presence Registry Service: this is the existing service of the Administration that manages data on employee attendance,

• CIPEL / ODE Service: existing service that manage the practices carried out by the employees (typically in the Accountancy and General Secretariat). Information is acquired from these services to assess whether the activity carried out in smart working is compliant with the foregoing.





Figure 23. Architecture of the validation scenario supporting Smart Working

3.1.3.2 Municipality of Bari pilot specification

The management of some activities through the DLT is carried out using specific programs (smart contracts) executed within the Ethereum Virtual machine (EVM). Having to guarantee the confidentiality of the data processed in the DLT transactions, the functionalities implemented by some of the smart contracts are minimal indeed.

Beyond the services mentioned in the previous section, at architectural level some additional components are foreseen; they are listed below along with the smart contracts and respective oracles10 envisaged:

• Smart Worker App: it is the Android app through which the smart worker submits, via the DLT, information on the start / pause / end events of its smart working activity,

• Supervisor Web Application: it is the web application that enables the supervisor to verify the activity of smart workers under his control and to generate reports about their activity,

• Presence Registry DLT oracle: it is a component used to transfer presence data from the DLT environment to the Presence Registry Service, to enable reporting the events of start/pause/end activity in the Administration information system,

• AuthN DLT oracle: it is the component that enables information exchange between DLT and AuthN Service to manage the smart workers’ activation phase,

• SmartContract01: it is a program totally executed within the DLT that is recalled every time it is necessary to complete the activation of one smart worker,

• SmartContract02: this is also a fully executed program within the DLT that is called to complete the activity registration transactions.

The system also offers the possibility to store the data related to smart working on SWARM, a distributed storage platform and content distribution service based on the Ethereum web3 stack, to cope with the expensive storage cost on the Ethereum DLT itself.

10 An oracle, in the context of blockchains and smart contracts, is an agent that finds and verifies real-world occurrences and submits this information to a blockchain to be used by smart contracts.





The following sequence diagrams detail the operations envisaged for the different DLT interactions:

3.1.3.2.1 Create smart worker profile

Figure 24 shows the details of the operations envisaged for the registration of both smart workers and supervisors, to be enabled to use the system. An entry for each user is created inside the Directory Service which includes, for supervisors, their employee number and for smart workers, in addition to their employee number, their smartphone’s IMEI and mobile number, the information related to their week planning and the CP-ABE access policies to be used to protect the smart working data in the context of the DLT transactions.

Figure 24. Create Smart Worker profile sequence diagram

3.1.3.2.2 Smart Worker Enrolment

The diagram in Figure 25 details the actions envisaged for the enrolment phase of a smart worker. The app on the mobile device executes these steps every time it checks that there is no local configuration for the smart worker, or the configuration is not correct.

The data related to the smart worker (for example: addresses of the services to be used, upon completion of activation, the methods for carrying out the activity in smart working, public / private keys, activities performed) are stored locally in an encrypted form and the password used from the smart work during activation it is used to generate the encryption key of this data.

Therefore, as data are stored locally on the mobile device, they are only accessible to the owner of the device.

After the generation of the ECDSA public and private key to be used on the DLT, an authentication SMS from the Smart Worker App is sent to the AuthN Service to authenticate the smart worker and to provide him/her the required Ether to send DLT transactions.

The smart worker can now request his/her profile which is sent by means of the AuthN Oracle through the smartContract01.





Double click to open the image

Figure 25. Enrol Smart Worker sequence diagram





3.1.3.2.3 Smart Working transactions Figure 26 shows the steps followed to register activities during smart working.

Double click to open the image

Figure 26. Smart Working DLT transaction sequence diagram

When starting up, the Android app checks the local configuration (decrypting it with a key obtained from the password provided by the smart worker). At the request of the smart worker to start or stop the activity, the Android app detects date, time and geographical coordinates of the user, asks for confirmation whether to proceed with operations and, if necessary, locally checks the compatibility of the action with the profile of the user. It then generates a Type = C01 transaction on the DLT containing the activity data protected with CP-ABE.

These transactions are received by RilevPresenze oracle by means of the smartContract02 which verifies whether the received start / stop data is compatible with the user's smart working profile and, in the case, pours the received data into the Presence Registry Service of the Municipality of Bari.





Also, for this type of activity, in order to avoid forcing the user to wait for the outcome of the transaction, it is envisaged that the smartContract02 generates a specific transaction Type = C03 to conclude, in positive or negative way, the recording of the activity.

The Android app records the outcome of the transaction locally in order to provide the user with a history of his activities without having to consult remote services.

3.1.3.3 Technical specifications

The table below provides details about programming languages, libraries and frameworks required for the implementation of the prototype.

Table 5.Access and Encryption Manager technological stack

Item Value

System requirements Java SE 8 or later installed, Android 5.0 Lollipop or later

Programming Language Java, JavaScript

Build Tool Maven, Gradle

Additional Libraries Web Crypto API, CryptoJS, RESTlet, cpabe, JSRSASign, jPBC, BouncyCastle, Blockly, Web3j, Gson

Web Container Tomcat 8

3.2 Delivery and usage

3.2.1 Package information

Figure 27describes the structure of the delivered package, which comprises a set of Java projects, each one including a pom.xml file to be used to build the corresponding .war archive (or .jar archive in the case of the client libraries), as described in 3.2.2.

Figure 27: Access and Encryption Manager source code folders structure

The following table describes the contents of each folder as well as relevant subfolders, providing indication of the output of the build process.

Table 6. Contents of the folders included into the delivered package


https://github.com/junwei-wang/cpabe




Folder name Content description

File_Service_Web Source code of the File Service web application, which acts as an example of client web application, enabled to interact with the surrounding web services, through the integration of the JavaScript client libraries (see Annex 1: AuthZ/AuthN and Encryption client libraries for instructions about how to use them), included in the resources/scripts path as subfolders, namely: -abeClient - AuthN-AuthZ The resources folder includes also the citadel subfolder which contains file and directories necessary for the installation, as explained in 3.2.2.

KeyGeneratorService Source code of the Key Generator Service web application

Policies_Storage_Service Source code of the Policy Storage Service web application

Storage_Service Source code of the Storage Service web application

Storage_Service_DBManagement Source code of the library used by storage services to use a database as storage location

Token_Service Source code of the Token Service web application

FileProtectorServiceLib Source code of the FileProtectorServiceLib.jar Java library providing encryption features for the client applications that use it (as explained in Annex 1: AuthZ/AuthN and Encryption client libraries)

TokenServiceClientLib Source code of the TokenServiceClientLib.jar Java library providing AuthN/AuthZ features for the client applications that use it (as explained in Annex 1: AuthZ/AuthN and Encryption client libraries)

ABEProxy Source code of the ABE Proxy web application

3.2.1.1 Package extensions to support the Smart Working validation scenario

Regarding the Smart Working experimentation of Municipality of Bari, the following contents are included into the delivery package:

Table 7. Contents of the folders of the smart working experimentation included into the delivery package


AuthNOracle Source code of the Authentication Oracle, which is responsible for interacting with the Ethereum Smart Contract to authenticate users and to perform their enrollment into the system. It includes the source code of the related smart contract “smartContract01”






RilevPresenzeOracle Source code of the Oracle responsible for decrypting users’ actions during smart working. It includes the source code of the related smart contract “smartContract02”

SmartWorkingApp Source code of the Android App workers use to register their actions during smart working

Doutdes Source code of the Android App responsible for authenticating users’ SMS and providing them the required cryptocurrency (Ether) to send DLT transactions

SW_Token_Service Source code of the module providing AuthN / AuthZ features for supervisors. It is modified version of the Token_Service (see description above) based on session cookies instead of JWT.

3.2.2 Installation instructions

3.2.2.1 Pre-Requirements

Before proceeding with the component installation, check that the installation environment fulfils the following pre-requirements:

• OpenLDAP 2.4.42 or later installed;

• Java SE 8 or later with JCE extension installed;

• Apache Tomcat 8.x installed;

• OrientDB community edition 2.2.x installed;

• Apache Maven available in the installation environment;

• Parity Ethereum v2.2.9 or later installed.

The runtime execution requires that the underlying JRE is extended with inclusion of the

Unlimited Strength Java(TM) Cryptography Extension Policy Files for the Java(TM) Platform,

Standard Edition Runtime Environment 8. In order to install this extension, follow the steps listed

hereinafter:

1. Download JCE archive from the Oracle portal; 2. Uncompress and extract the downloaded file; 3. Copy the extracted files in the path <java-home>/lib/security part of your Java SE 8

installation.

It is necessary also to copy the library com_fincons_device_entity-0.0.1-SNAPSHOT.jar into the

maven repository of the host where the build process will be done, in the path

<path_to_local_maven_repository>\.m2\repository\com\fincons\device_entity\com_fincons_d

evice_entity\0.0.1-SNAPSHOT\.

3.2.2.2 OpenLDAP configuration and startup

Once OpenLDAP is installed, in order to properly configure it do the following:

1. In the installation folder (e.g. “C:/OpenLDAP”) is located the main configuration file called

“slapd.conf” in which the information associated with a particular database instance is

configured. It is necessary to add here the configuration of the database responsible for





managing CITADEL users and related attributes. Open this file with a text editor and append

the following section:

database bdb

suffix "dc=citadel"

rootdn "cn=Manager,dc=citadel"

# Cleartext passwords, especially for the rootdn, should

# be avoid. See slappasswd(8) and slapd.conf(5) for details.

# Use of strong authentication encouraged.

rootpw {SSHA}<PASSWORD HASH>

# The database directory MUST exist prior to running slapd AND

# should only be accessible by the slapd and slap tools.

# Mode 700 recommended.

directory ./Citadeldata

dirtyread

searchstack 20

# Indices to maintain

index mail pres,eq

index objectclass pres

index default eq,sub

index sn eq,sub,subinitial

index telephonenumber

index cn

You can define your rootpw assigning its value in plain text, it will be encrypted as soon as you

launch the OpenLDAP daemon.

2. in the OpenLDAP installation directory create a subdirectory with the same name configured

in the slapd.conf file in association to the directory parameter (citadeldata ); all the database

files related to the LDAP instance will be created here.

3. Move in the subdirectory schema, located in the OpenLDAP installation directory, the citadel

schema available in the installation archive (File_Service_Web/resource/citadel directory).

4. Add in the head of the file slapd.conf this line:

include ./schema/FINCONS-Commons.schema

include ./schema/citadel.schema

that allows LDAP to use the both the FINCONS and CITADEL schema extensions including the

required attributes.

5. Launch the OpenLDAP service by running the slapd daemon available in OpenLDAP

installation directory (slapd.exe for a MS Windows installation).

6. Use your favourite LDAP browser to import the citadel.ldif file available in the installation

archive.

Regarding the Smart Working experimentation for the Municipality of Bari the LDAP should be

configured as follows:

1. In the installation folder (e.g. “C:/OpenLDAP”) is located the main configuration file

called “slapd.conf” in which the information associated with a particular database

instance is configured. It is necessary to add here the configuration of the database

responsible for managing smart workers and supervisors and their related attributes.

Open this file with a text editor and append the following section:

database mdb





suffix "dc=SmartWorking"

rootdn "cn=Manager,dc=SmartWorking"

rootpw {SSHA}<PASSWORD HASH>

directory ./SmartWorking

searchstack 20

# Indices to maintain

#index mail pres,eq

index objectclass pres

index default eq,sub

index sn eq,sub,subinitial

#index telephonenumber

index cn

2. in the OpenLDAP installation directory create a subdirectory with the same name

configured in the slapd.conf file in association to the directory parameter

(SmartWorking); all the database files related to the LDAP instance will be created here.

3. Move in the subdirectory schema, located in the OpenLDAP installation directory, the

citadel schema available in the installation archive

(SW_Token_Service/resource/dsconfig directory).

4. Add in the head of the file slapd.conf this line:

include ./schema/SmartWorking.schema

that allows LDAP to use the Smart Working schema extensions.

5. Launch the OpenLDAP service by running the slapd daemon available in OpenLDAP

installation directory (slapd.exe for a MS Windows installation).

3.2.2.3 OrientDB configuration and startup

Once OrientDB is installed, do the following:

1 Edit the script.osql script available in the installation archive to set the correct path of the

OrientDB.json file, also available in the installation archive

(File_Service_Web/resource/citadel directory).

2 Launch the OrientDB service by running the server daemon available in bin subdirectory

within the OrientDB installation directory (server.bat for a MS Windows installation).

3 Open your favourite browser on the host where OrientDB is installed, access the OrientDB

admin tool (available at the URL http://localhost:2480/studio/index.html ), and create a

new database instance named OrientDB with the icon (assign a password to the

root user, owner of the database).

4 Launch the OrientDB console by running the console executable available in bin

subdirectory within the OrientDB installation directory (console.bat for a MS Windows

installation).

5 Run the command connect remote:localhost/OrientDB root; LOAD SCRIPT <path of

script.osql>/script.osql in the console window to create the schema needed.

6 Access the OrientDB admin tool and create a new user (the one used by the files and policies

storage services) with the icon.

3.2.2.4 General configuration

Move on a file system accessible by the Tomcat process the directory named citadel, available

in the installation archive, (e.g. C:/citadel), which includes the following subdirectories:


http://localhost:2480/studio/index.html




• Config: here the configuration is stored

• Keygen: used to store publicKey and masterkey used by the TokenService

• logs: here the application log files are located

• Policy: here the policies definitions are stored

• File: here the encrypted files are stored

In the Policy and File directories create a subdirectory for each customer, using the same names

used as value for the LDAP objects associated to the organization objectClass.

For instance, if you have an entry like

dn: o=Fincons,c=IT,dc=citadel

objectClass: organization

objectClass: top

o: Fincons

you have to create a directory named Fincons in the two indicated directories.

3.2.2.5 Web applications deployment and configuration

Use maven (with install as target; remove any version / snapshot indication from the resulting

archive, if present) to build the KeyGeneratorService.war, Policies_Storage_Service.war,

Storage_Service.war, Token_Service.war, ABEProxy.war and File_Service_Web.war files

available in the installation archive in the Tomcat environment.

Launch Tomcat so that the web archives are expanded and then stop it.

1. Open with a text editor the configuration file of the Token_Service.war archive (<Tomcat-

install-dir>\webapps\Token_Service\WEB-INF\classes\config\config.properties) and set the

values of the parameters responsible for the LDAP interaction in accordance with your

OpenLDAP server specific deployment and the related configuration defined in the slapd.conf

file, as in the example shown below: #OpenLdap

LdapUrl=ldap://89.207.106.74:389

LdapUser=cn=Manager,dc=citadel

LdapPSW=<LDAP PASSWORD>

LdapRoot=dc=citadel

Please note that the same configuration file includes the definition of the base authorization

policy applied to the different roles: a given user is enabled to perform a specific action

according to what is defined in this section; regarding the possibility to download and decrypt

a file, of course, the fact that a role is configured to GET video files for a given Use Case (i.e.

File:{GET:UseCase}) is not enough; it is just granted if the user profiles matches the policy

with which the file has been encrypted. Then, should you decide to customize your

installation defining different roles, be aware that you have to adapt this section accordingly.

CustomerSpecialist={File:{GET: UseCase, POST: UseCase}, Policy:{GET: UseCase},

Keygen:{GET:All}}

CustomerTechnical={File:{POST: UseCase}, Policy:{GET: UseCase}, Keygen:{GET:All}}

CustomerHeadOfSecurityOfficer={File:{GET:UseCase, POST:UseCase, DELETE:UseCase },

Policy:{GET:UseCase, POST:UseCase}, Keygen:{GET:All}}

Supervisor={File:{GET:All, POST:All}, Policy:{GET:All,

POST:All},Keygen:{GET:All}}

Administrator={Keygen:{GET:All}}

2. Open with a text editor the configuration file of the KeyGeneratorService.war archive

(<Tomcat-install-dir>\webapps\KeyGeneratorService\WEB-

INF\classes\config\config.properties) and set the values of the parameters responsible for





the LDAP interaction in accordance with your OpenLDAP server specific deployment and the

related configuration defined in the slapd.conf file, as in the example shown below: #OpenLdap

LdapUrl=ldap://89.207.106.74:389



LdapRoot=dc=citadel

Check also that path and file names for the master key and public key are correctly configured

(see example below):

cpabeKeyPathName=C:/citadel/Keygen/

cpabeMasterKeyFileName=master_key

cpabePublicKeyFileName=public_key

3. Open with a text editor the configuration file of the File_Service_Web.war archive (<Tomcat-

install-dir>\webapps\File_Service_Web\WEB-INF\classes\config\config.properties) and set

the values of the parameters responsible for the LDAP interaction in accordance with your

OpenLDAP server specific deployment and the related configuration defined in the slapd.conf

file, as in the example shown below:

#OpenLdap

LdapUrl=ldap://89.207.106.74:389



LdapRoot=dc=citadel

Set, then, IP addresses and ports configured in the file to the values referred to the Tomcat

instance where the web applications are deployed.

4. Open with a text editor the configuration file of the Policies_Storage_Service.war archive

(<Tomcat-install-dir>\webapps\PolicySService\WEB-INF\classes\config\config.properties)

and check that the path of the directory where policy definitions are stored is correctly

configured (see example below):

pathFile=C:/citadel/Policy

Adapt also the parameters for the connection towards the OrientDB database to your

instance as in the example shown below:

#OrientDB info

DB_name = OrientDB

DB_user = <OrientDB user>

DB_password = <OrientDB user’s password>

DB_rootName = PolicyRoot

DB_adress =localhost

5. Open with a text editor the configuration file of the StorageService.war archive (<Tomcat-

install-dir>\webapps\StorageService\WEB-INF\classes\config\config.properties) and check

that the path and file names are correctly configured for the directory where encrypted files

are stored (see example below):

pathFile=C:/citadel/file

Adapt also the parameters for the connection towards the OrientDB database to your

instance, as in the example shown below:

#OrientDB info

DB_name = OrientDB

DB_user = <OrientDB user>

DB_password = <OrientDB user’s password>

DB_rootName = FileRoot





DB_adress =localhost

6. Open with a text editor the configuration file of the SW_Token_Service.war archive

(<Tomcat-install-dir>\webapps\SW_Token_Service\WEB-

INF\classes\config\config.properties) and set the values of the parameters responsible for

the LDAP interaction in accordance with your OpenLDAP server specific deployment and the

related configuration defined in the slapd.conf file, as in the example shown below: #OpenLdap

LdapUrl=ldap://[IP]:[PORT]

LdapUser=cn=Manager,dc=SmartWorking


LdapRoot=dc=SmartWorking

7. Open with a text editor the log4j configuration files of for all the web applications deployed

in the Tomcat environment and set the desired value for the different log files (see example

below):

In C:\Tomcat\apache-tomcat\webapps\Token_Service\WEB-INF\classes\log4j.properties

log4j.appender.file.File=C:/citadel/logs/access_token_service.log

In C:\Tomcat\apache-tomcat\webapps\KeyGeneratorService\WEB-

INF\classes\log4j.properties

log4j.appender.file.File= C:/citadel/logs/ key_generator.log

In C:\Tomcat\apache-tomcat\webapps\PolicySService\WEB-


log4j.appender.file.File==C:/citadel/logs/policy_storage_service.log

In C:\Tomcat\apache-tomcat\webapps\StorageService\WEB-


log4j.appender.file.File==C:/citadel/logs/storage_service.log

In C:\Tomcat\apache-tomcat\webapps\File_Service_Web\WEB-


log4j.appender.file.File= C:/citadel/logs/file_service_web.log

In C:\Tomcat\apache-tomcat\webapps\SW_Token_Service\WEB-


log4j.appender.file.File= C:/citadel/logs/sw_token_service.log

Once all the configurations listed above have been applied, move away the original war archives,

launch Tomcat again and keep it running.

In order to check that the installation was completed successfully, you can access the home page

of the example web application (available at http://<host:port>/File_Service_Web/ ) and using

it as explained in 3.2.3.

3.2.2.6 HTTPS configuration

In order to enable web browsers running at the customers’ network to connect securely, the

component services have to be bound to a secure network channel and to a digital certificate

that allows verifying the website's authenticity. The HTTPS connector of Tomcat, therefore, has

to be properly configured in association to a certificate released by a Certificate Authority.

Taking the assumption of the availability of a digital public certificate and the associated private

key (both in PEM format) released by a CA, follow next step in order to configure the Tomcat

connector:

• Create a PKCS12 file from private key and public certificate; you can use openssl command

line utility for this operation, as follows (when prompted for the password associated to the

keystore, you can assign your favourite one):





openssl pkcs12 -export -name <your-alias> -in <path-of-chained-certificate-file>

-inkey <path-of-key-file> -out <path-of-pkcs12-keystore-to-be-created>

as in the following (MS windows-based) example: "C:\openssl-1.0.2k-i386-win32\openssl" pkcs12 -export -name citadel -in

citadel_eu.chained.crt -inkey citadel_eu.key -out citadelkeystore.p12

• Convert PKCS12 keystore into a JKS keystore; you can use the keytool command line utility

available within your Java installation. For this operation operate as indicated below (you will

be prompted for the password just associated to the pkcs12 file, while you can assign your

favourite one to the jks keystore):

keytool" -importkeystore -destkeystore <path-of-jks-keystore-to-be-created> -

srckeystore <path-of-pkcs12-keystore-newly-created> -srcstoretype pkcs12 -alias

<your-alias>

as in the following (MS Windows -based) example:

"C:\Program Files\Java\jre1.8.0_111\bin\keytool" -importkeystore -destkeystore

citadelkeystore.jks -srckeystore citadelkeystore.p12 -srcstoretype pkcs12 -alias

citadel

• Add the configuration for the HTTP connector in the server.xml file of your Tomcat

installation as follows:

<Connector port="<your-HTTPS-port>"

protocol="org.apache.coyote.http11.Http11Protocol"

maxThreads="150" SSLEnabled="true" scheme="https" secure="true"

keystoreFile="<path-of-jks12-keystore-newly-created>" keystorePass="<jks-

keystore-password>” clientAuth="false" sslProtocol="TLS" />

• Make sure that the redirect port specified in the HTTP Tomcat connector addresses correctly

the port of the newly configured HTTPS connector

• Restart Tomcat

At this point, if you browse the URL http://<Tomcat service IP address>:<Tomcat service HTTP

port>/File_Service_Web/ you will be redirected to the secure service available at

https://<Tomcat service IP address>:<Tomcat service HTTPS port>/File_Service_Web/

In order to enable this redirect, all the web applications deployed in the Tomcat environment

have been configured to be served only over a secure HTTPS channel. If you want to disable this

default behaviour, edit the web.xml file of each of them and comment out the section

introduced by the comment tag <! -- Require HTTPS for everything except /img (favicon) and

/css. -->.

It is possible to perform the same configuration described above by using a self-signed

certificate, in case you either don't plan on having your certificate signed by a CA, or you wish

to test your new SSL implementation while the CA is signing your certificate. Of course, this

temporary certificate will generate an error in the client browser to the effect that the signing

certificate authority is unknown and not trusted.

Follow the steps described below in order to generate the self-signed certificate:

• Create your RSA Private Key as follows: (this key is a 1024 bit RSA key which is encrypted

using Triple-DES and stored in a PEM format so that it is readable as ASCII text)

openssl genrsa -des3 -out server.key 1024

• generate, then, a Certificate Signing Request (CSR) as follows:

openssl req -new -key server.key -out server.csr

• generate a temporary certificate which (good for 365 days in the example below), with the

following command:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt





3.2.2.7 Parity configuration and synchronization

Once parity is installed, open a command prompt and navigate to the installation folder:

cd "c:\Program Files\Parity Technologies\Parity"

• Start the blockchain client with the following command:

parity.exe --chain kovan

This command will start the synchronization to the Kovan Ethereum testnet (it will take some time).

• When the synchronization is done, parity will start importing new blocks as they get created:

2019-03-19 09:39:17 Verifier #3 INFO import Imported #XXXXXXXX 0xa1f3…2fb5 (16

txs, 4.06 Mgas, 211 ms, 17.84 KiB)

• To complete the setup create new Ethereum accounts by issuing the following command:

parity.exe account new

After configuring a password, parity will output the generated account’s address. The related wallet file can be found at:

C:\Users\[USERNAME]\AppData\Roaming\Parity\Ethereum\keys\ethereum

Testnet Ether can be requested at https://gitter.im/kovan-testnet/faucet.

If you want to use SWARM as distributed storage, follow the instruction at https://swarm-guide.readthedocs.io/en/latest/installation.html to install the SWARM client for your operative system.

Start swarm by using the following command:

swarm --bzzaccount <ETH ACCOUNT>

where <ETH ACCOUNT> is one of the account generated at the previous step.

3.2.2.8 Oracles deployment and configuration

Use maven (with install as target; remove any version / snapshot indication from the resulting archive, if present) to build the AuthNOracle and the RilevPresenzeOracle.

1. Open with a text editor the configuration file of the AuthNOracle.jar archive

config\config.properties) and set the values of the parameters responsible for the LDAP

interaction in accordance with your OpenLDAP server specific deployment and the related

configuration defined in the slapd.conf file, as in the example shown below: #OpenLdap

LdapUrl=ldap://[IP]:[PORT]

LdapUser=cn=Manager,dc=SmartWorking


LdapRoot=dc=SmartWorking

Also specify the values of the parameters regarding your parity instance and the wallet to use:

parity_protocol=http

parity_IP=localhost


https://gitter.im/kovan-testnet/faucet

https://swarm-guide.readthedocs.io/en/latest/installation.html

https://swarm-guide.readthedocs.io/en/latest/installation.html




parity_port=8545

WalletPath = <WALLET FULL PATH>

WalletPassword = <WALLET PASSWORD>

2. Invoke the Deployer class of the jar to deploy the Smart Contract on the blockchain11:

java AuthNOracle.jar –cp com.finconsgroup.AuthNOracle.Deployer

3. Set the address of the deployed contract in the config.properties configuration file:

SC01Address = <CONTRACT ADDRESS>

4. Repeat step 1-2 for the RilevPresenzeOracle and set the address of the deployed contract in the config.properties configuration file:

SC02Address = <CONTRACT ADDRESS>

Make sure to also configure the CPABE keys:

CPABE_PUBLIC_KEY_PATH = <CPABE PUBLIC KEY PATH>

CPABE_PRIVATE_KEY_PATH = <CPABE PRIVATE KEY PATH>

5. If you want to use SWARM as distributed storage also configure the following parameters:

SWARM_ENABLED = true

swarm_protocol = http

swarm_IP = localhost

swarm_port = 8500

3.2.3 User Manual

Bearing in mind the fact that the Access and Encryption Manager component is a back-office component designed to be integrated by client applications within the CITADEL ecosystem (see in “Annex 1: AuthZ/AuthN and Encryption client libraries” the documentation related to the API provided by the provided libraries), it also includes an example of a web application that provides access to the related services, and which can be used as template for the client integration. The GUIs reported in this section come from this example web application, which applies the component security features to the document management tasks.

The Access and Encryption Manager service is accessible just for registered users.

The user’s registration process is split into two phases:

• an off-line phase in which the system administrator inserts the user (identified by name, surname and email address, and associated to a defined role) into the LDAP Service under the proper organization. In order to use the system, send an email to [email protected] and we will proceed to the off-line provisioning phase for your account.

• an on-line phase where the user accesses the Web Service registration page, entering username (i.e. the same email address used in the off-line phase) and choosing a password to complete the registration as depicted below.

11 The source code of each Oracle already implements the respective smart contract’s java wrapper generated using the web3j utility tool provided with the Web3j library.





Figure 28. Registration page

In the off-line phase, the system administrator takes care of assigning to the registered user specific roles as detailed in the following section.

Once registered, the user can login to the system, by using email address and the selected password.

Hint: to move between ‘User Name’ and ‘Password’ input boxes, both in the registration and login pages, use the ‘tab’ key.

All users having the right to create policies are allowed to access the ‘Create Policies’ tab, which provides an intuitive tool to graphically defines policies: the left panel of the tool includes widgets representing the attributes that may be used as part of the policy definition (most of them work like combo-boxes) as well as logical conditions (‘AND’ and ‘OR’) used to combine them. Once the user is convinced that the policy is defined as designed (the ‘Text Policy’ box provides a textual representation of the policy graphically defined) she / he can save it through the ‘Confirm Policy’ button.





Figure 29. Create Policy Tool

All users having the right to view policies are allowed to access the ‘View Policies’ tab, which provides the possibility to browse and check the policies already defined on the system and visible for them, as shown in Figure 30.

Figure 30. View Policy page

All users having the right to view documents loaded on the system, also have the right to request their personal decryption key to the ABE Key Generation Service.

All users having the right to upload documents to the encrypted documents repository are allowed to access the ‘Upload Document’ tab, where they are enabled to select the document that they want to process with the encryption service (through the ‘Upload’ button) and to select the policy file to be used for the encryption, which will define, then, who will be authorized to decrypt the document. The ‘Start Encryption’ button triggers the encryption and upload task that, once successfully completed, displays the ‘Saved Correctly’ label on the page.





Figure 31. Upload document page

All users having the right to view documents stored into the encrypted documents repository are allowed to access the ‘Download Document’ tab (Figure 32), where they are enabled to select the document that they want to process with the decryption service. The ‘Start Decryption’ button triggers the decryption and download task. The user, of course, is allowed to view a given document just if the policy used for the document encryption matches with the user’s profile (stored on the LDAP server). Shouldn’t this be the case, the user will be displayed

the message.

Figure 32.Download document page

3.2.3.1 Smart Working App User Manual

The Smart Working app is intended for workers of the Municipality of Bari that performs part of their working activities in smart working.

The app, being reserved to the employees of the Municipality of Bari, has not been published on the on-line store; therefore, in order to install it, the related APK has to be manually transferred to an Android smartphone, where, in the settings > security screen the flag enable unknown sources has to be enabled (and then disabled once the installation is complete); then, it is necessary, with a File Manager app, to navigate to the folder where the APK is located, and tap on the APK file to launch the installation.

The app allows smart workers to:





• Start/Stop the daily smart working activity

• Start/Stop breaks

• Look at their smart working profile

• Look at their smart working activity history

After installing the app, at the first run, the user inputs his employee number and selects a password (Figure 33).

Figure 33. Smart Working App First Access

After the first login the app sends an SMS to authenticate the user. The user before proceeding with any activity must:

• Wait for the confirmation SMS of successful account activation

• Click the link received via SMS

• Input his password

From now on, in order to access the app’s services, the user needs to use this password to unlock his profile.

Note: the password is only known to the smart worker and handled locally. If the user forgets his password he will need to agree for a new enrolment.

The app main screen allows to:

• Start the daily smart working activity

• Stop the daily smart working activity (if an activity was previously started)

• Start a break

• Stop a break

• Use the menu to access the user’s profile or the activity history

The app also shows a confirmation prompt when starting/stopping an activity before sending the related DLT transaction. It will then track the time spent during the current activity (Figure 34).





Note: Location data is always collected only upon user confirmation.

The activity history screen shows on a monthly/weekly/daily basis the activity carried out in smart working and each event is represented with a different colour:

• represents a smart working activity correctly registered inside the presence registry of the Municipality.

• represents a smart working activity transmitted to the presence registry of the Municipality but with a pending confirmation.

• represent a break correctly registered inside the Municipality presence registry.

• represents a break transmitted to the presence registry of the Municipality but with a pending confirmation.

• represent the end of the smart working day.

Figure 34. Smart Working app

3.2.4 Licensing information

The licensing of the component is GPL2. The licensing of the software developed under the Smart Working experimentation is APACHE 2.0.

3.2.5 Download

The source code is available in the EC portal for deliverables, included in the zip file for D4.6.

It is also available in the CITADEL open git repository, more precisely at the following address:

https://git.code.tecnalia.com/CITADEL_Public/CITADEL_Components/tree/m

aster/Security





4 Conclusions

The present document has to be intended as a technical note produced to describe the software deliverable D4.6 Final CITADEL security toolkit, delivered at M30.

As such, for each of the two main subcomponents individuated, Anonymization and Access and Encryption Manager components, it provides, beyond a functional, technical and architectural overview, the description of the delivered packages and proper instructions about how to build, install and use the components.

Of course, being a preliminary prototype, the software will be evolved during the course of the project in order to fulfil the consolidated set of functional requirements and the customizations necessary for a satisfactory execution of the use cases.

It is important to highlight that the security toolkit provide services that the other components part of the CITADEL ecosystem, as well as client application, may use if they need to benefit from the security features. The integration of the security toolkit within the CITADEL ecosystem, therefore will be progressively refined along with the consolidation of the information flows, and the related informative contents, established within the overall platform.





References

[1] CITADEL Consortium, “D4.3 – Initial CITADEL Ecosystem Architecture,” 2017.

[2] L. Sweeney, “k-ANONYMITY: A MODEL FOR PROTECTING PRIVACY,” International Journal on Uncertainty,Fuzziness and Knowledge-based Systems, vol. 10, no. 5, pp. 557-570, 2002.

[3] F. K. R. L. K. A. K. Fabian Prasser, “ARX - A Comprehensive Tool for Anonymizing Biomedical Data,” in AMIA Symposium, 2014.

[4] CITADEL Consortium, “WD4.1 Initial set of functional and technical requirements elicitation,” 2017.

[5] ARX, “ARX,” [Online]. Available: http://arx.deidentifier.org/api/. [Accessed 12 12 2017].

[6] L. Sweeney, “Uniqueness of Simple Demographics in the U.S. Population,” Carnegie Mellon University, Laboratory for International Data Privacy, Pittsburgh, 2000.

[7] ARX, “ARX GUI documentation,” [Online]. Available: http://arx.deidentifier.org/wp-content/uploads/javadoc/current/gui/index.html. [Accessed 2017 12 12].

[8] A. S. a. B. W. J. Bethencourt, “Ciphertext-Policy Attribute-Based Encryption,” [Online]. Available: https://www.cs.utexas.edu/~bwaters/publications/papers/cp-abe.pdf. [Accessed 4 December 2017].

[9] W3C, “Web Cryptography API,” 26 JANUARY 2017. [Online]. Available: https://www.w3.org/TR/WebCryptoAPI/. [Accessed 4 December 2017].

[10]

NIST, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography,” May 2013. [Online]. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf. [Accessed 4 December 2017].

[11]

IETF, “Json Web Token,” May 2015. [Online]. Available: https://tools.ietf.org/html/rfc7519. [Accessed 4 December 2017].

[12]

U. G. O. f. Science, “Distributed ledger technology: beyond block chain,” gov.uk , 19 01 2016. [Online]. Available: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed-ledger-technology.pdf. [Accessed 19 3 2019].

[13]

N. I. o. S. a. Technology, “Advanced Encryption Standard (AES),” FIPS Pub, p. 197, 26 11 2001.

[14]

Garante per La Protezione dei Dati Personali, Le linee guida del Garante per posta elettronica e internet, G.U. n. 58 del 10 marzo 2007.

[15]

Garante per La Protezione dei Dati Personali, Trattamento di dati personali effettuato attraverso la localizzazione di dispositivi smartphone, provvedimento n. 226 del 18 maggio 2016.





[16]

Garante per La Protezione dei Dati Personali, Verifica preliminare. Trattamento di dati personali mediante un sistema di localizzazione geografica dei dispositivi aziendali, provvedimento n. 232 del 18 aprile 2018.

[17]

Presidenza del Consiglio dei Ministri, Indirizzi per l'attuazione dei commi 1 e 2 dell'articolo 14 della Legge 7 Agosto 2015, N. 124 e Linee Guida contenenti regole inerenti all'organizzazione del lavoro finalizzate a promuovere la conciliazione dei tempi di vita e di lavoro dei dipendenti, Direttiva n. 3 del 1 giugno 2017.

[18]

A. Cavoukian and J. Jonas, “Privacy by design in the age of big data,” Information and Privacy Commissioner of Ontario, Canada, 2012.

[19]

A. Cavoukian and M. Chanliau, “Privacy and security by design: a convergence of paradigms,” Office of the Privacy Commissioner Ontario, Canada, 2013.

[20]

R. Ross, M. McEvilley and J. Oren, “Systems security engineering: Considerations for a multidisciplinary approach in the engineering of trustworthy secure systems,” National Institute of Standards and Technology, 2016.

[21]

D. D. Caputo, S. L. Pfleeger, M. A. Sasse and P. Amma, “Barriers to Usable Security? Three Organizational Case Studies,” IEEE Security & Privacy, vol. 14, no. 5, pp. 22-32, 2016.

[22]

B. Schneier, “Stop Trying to Fix the User,” IEEE Security & Privacy, vol. 14, no. 5, 2016.

[23]

Agenzia per l'Italia Digitale, “Linee guida di design per i servizi digitali della PA,” 14 Ottobre 2018. [Online]. Available: https://media.readthedocs.org/pdf/design-docs-francescozaia/revisione-capitolo-ui/design-docs-francescozaia.pdf.





Annex 1: AuthZ/AuthN and Encryption client libraries

How to use TokenServiceClientLib

TokenServiceClientLib is a Java library (shipped with the file tokenServiceClientLib-x.y.z.jar) that allows a client to use AuthN/AuthZ functionalities interacting with the server components available as part of the Access Management component.

First of all, a user must be registered12 using a call like: JsonObject JsonResponse= AuthenticationServiceClient.registration(username, password,

urlTokenService);

After the registration, if the JsonResponse returned has code 200 the user was successfully

registered. After being successfully registered the user must perform the login operation

NB. a possible value for urlTokenService is “https://myhost.mydomain.com

/Token_Service"

To login, it is necessary to invoke the method AuthenticationServiceClient.login, which

returns an UserTokenService object, that contains the user information needed to create

tokens for all subsequent calls to AuthN/AuthZ service. UserTokenService userToken= AuthenticationServiceClient.login(username,

password, urlTokenService);

All calls to AuthN/AuthZ services (e.g., policy storage service, file storage service) require to

obtain authorization tokens specific for the request (RequestToken). These authorization tokens

are created with a 2 steps procedure:

• The 1st step creates a suitable instance of a token like in the following example: RequestToken rqToken = new RequestToken(userToken, expirationTime, new

Action(method, service, urlService));

where userToken is the element returned by the login operation, expirationTime is

the life time (expressed in milliseconds) for the requested token and the Action Object

requires to specify: the HTTP method (possible values: GET, PUT, POST, DELETE as a

String), a service String with the name of the target service (possible values:

KeyGeneratorService, FileSService, PolicySService) and the URL of the target

service urlService (e.g., “keygen”, Policy Storage Path Resource , File Storage Path

Resource).

• The 2nd step asks to the AuthN/AuthZ Token Service to validate the user rights and, in

such case, to provide an authorization token for the specified service. Through the

requestToken method the user checks if she/he is allowed to do the operation

requested. To call this method, the token instance created in step 1 (rqToken) is

needed, along with the URL of token service instance urlTokenService and

urlGenerateTokenService, the URL of the service whose invocation requires this

token. Possible values for urlGenerateTokenService are TokenEnumService.

DEFAULT_POLICY.getUrl(), or TokenEnumService. GENERATE_TOKEN.getUrl(), the

first one is used to generate a token to request the default Policy, the second one is used

to generate a token for the other service.

12 The method call will succeed only if the user being registered has already an instance (of type VidASUser) in the LDAP service





Token requestToken(RequestToken rqToken, String urlTokenService, String

urlGenerateTokenService).

• The 3rd step is the actual service invocation, and envisages a call like the following one: AuthorizationServiceClient.invokeService(requestToken, urlTokenService,

jsonInputData, urlService);

where requestToken is the token created in step 2, urlTokenService the URL of token

service instance, urlService is the URL of the service instance (for example

“https://myhost.mydomain.com/KeyGeneratorService"), jsonInputData is a Json

object used to send the input data in JSON format to the target service.

For logout the user must invoke the method AuthenticationServiceClient.logout that

returns a Json Object with the result of the operation : AuthenticationServiceClient.logout(user, urlTokenService);

Here follows the documentation of the classes and related methods, to use for the integration.

Class AuthorizationServiceClient Method invokeService

/**

* Method use to invoke the service with the authorizationToken

*

* @param Token is the token obtained from the token service

* @param String urlTokenService is the url of the TokenService instance

* @param JsonObject inputData the input data for the service

* @param String urlServiceToInvoke is the target service instance URL

* @return JsonObject is a JSON structure that returns the HttpRequest result

(i.e., 200 – OK, or the error message)

*/

JsonObject invokeService(Token token, String urlTokenService, JsonObject inputData,

String urlServiceToInvoke)

Method requestToken /**

* Send a request toTokenService to get authorizationToken

*

* @param RequestToken

* requestToken object that contains all information used to

* request a token

* @param String

* urlTokenService is the url of the TokenService Instance

* @return Token; to get the token is needed invoke the method token.getToken();

and is advised check the token validation with the method token.idValid();

* @throws Exception

*

*/

Token requestToken(RequestToken requestToken, String urlTokenService)

Class RequestToken /**

*

* @param UserTokenService user info containing username challengeId and

userSecret

* (it is possible to generate a UserTokenService with

AuthenticationServiceClient.login)

* @param long experationTime the time duration of the token expressed in

milliseconds

* @param Action action to request the operation that contains Method Http,

Service Instance Name, and service url

*/





RequestToken(UserTokenService user, long experationTime, Action action)

Class Action /**

*

* @param String Http method to invoke the service

* @param String service name of the service instance

* @param String url path of the specific resource to invoke

*/

Action (String method, String service, String url)

Class AuthenticationServiceClient Method login

/**

* Method used to Login and generate a UserTokenService that is needed for the

TokenGeneration

* @param String username used to login

* @param String password used to login

* @param String urlTokenService

* @return a UserTokenService, needed to tokenServiceOperation

* @throws AuthenticationServiceException

*/

UserTokenService login(String username, String password, String urlTokenService)

Method logout /**

*

* @param UserTokenService user info contains username challengeId and userSecret

* (is possible generate UserTokenService with

AuthenticationServiceClient.login)

* @param String urlTokenService is the url of the TokenService Instance

* @return JsonObject is a Http Response

* @throws Exception

*/

JsonObject logout(UserTokenService user, String urlTokenService)

Method registration /**

* Method used to fill up the LDAP user’s entry with the user Certificate

* N.B.: the user’s LDAP entry must already exist and be of type AuthN/AuthZUser)

* @param String username used to login

* @param String password used to login

* @param String urlTokenService is the url of the TokenService Instance

* @return JsonObject is a Http Response

* @throws AuthenticationServiceException

*/

String registration(String username, String password, String urlTokenService)

How to use FileProtectorServiceLib

FileProtectorServiceLib is a Java library (shipped with the file fileProtectorServiceLib-x.y.z.jar) that allows a client to encrypt and decrypt a file with CP-ABE/AES.

For using the encryption is necessary to invoke the method EnryptedFile encrypetedFile = FileProtectorServiceClient.encryptFile(DecryptedFile

decryptedFile, CPABE_Policy policy, AbeProxyConfig abeProxyConfig);

Before invoking the encryption method is necessary to create three objects:

• DecryptedFile (byte[] decryptedFileData, String nameFile, String

typeFile, String uploadBy) this object contains a byte array of the file that you





want encrypt, the name of the file, the file type and the username of the user that has

to upload the file.

• CPABE_Policy (String specs, String url, ArrayList<Metadata> metadata) is

an object that contains the policy (in string format) or the URL of the policy with which

you want to encrypt the file, and all necessary metadata (it is possible get the policy in

string format through the invocation of the PolicyStorageService).

• AbeProxyConfig(String proxy_ip, String proxy_port, String proxy_id,

String proxy_instance_name) is an object that contains all the parameters needed

to use the ABE-proxy. ABE-proxy is used for the CP-ABE encryption of the shared

symmetric key. After the method execution, we obtain an EnryptedFile object that

contains: as attributes, the encrypted file in base64url encoded, the name of the

original file, the type of the original file, the username of the user who has encrypted

the file, the information about the KeyStorage service used, and the initialization vector

used to encrypt the file.

In order to decrypt a file is necessary to invoke the method DecryptedFile decryptedFile = FileProtectorServiceClient.decryptFile(EnryptedFile

encFile, String personalKeyB64u, String publicKeyB64u);

Before invoking this method is necessary to have the EnryptedFile and the personal and

public keys (it is possible to request the personal and the public keys by the invocation of the

KeyGenerationService).

Class FileProtectorServiceClient Method encryptFile

/**

* Method that encrypt the file with CPABE-AES algorithm

* @param decryptedFile object use to pass the file and the metadata file

* @param policy object that contains the String policy used to encrypt the file

* @param abeProxyConfig the config necessary to use abeProxy for encryption

* @return EnryptedFile an object that contain the metadata of the file encrypted

and the encrypted data in base64url

*/

EnryptedFile encryptFile(DecryptedFile decryptedFile, CPABE_Policy policy,

AbeProxyConfig abeProxyConfig)

Method decryptFile /**

* Method that decrypt the file with CPABE-AES algorithm

* @param encFile EnryptedFile an object that contain the metadata of the file

encrypted and the encrypted data in base64url

* @param personalKeyB64u the user personal key base64Url encoded (is possible

get the this key from keyGenerationService/keygen)

* @param publicKeyB64uv the user public key base64Url encoded (is possible get

the this key from keyGenerationService/keygen)

* @return DecryptedFile an object that contain the metadata of the file

encrypted and decrypt file in byte array

* @throws Exception

*/

DecryptedFile decryptFile(EnryptedFile encFile, String personalKeyB64u, String

publicKeyB64u)

Class EnryptedFile /**

* @param key_info object relative to key information, include the Storage where

the key is saved.





* @param nameFile the original file name

* @param typeFile the original file type

* @param encryptor the encryptor username

* @param encfile file encrypted converted in base64Url

* @param iv initializzation vectore used to encrypt file converted in base64Url

*/

EnryptedFile(Key_Id key_info, String nameFile, String typeFile, String encryptor, String

encfile, String ivB64U)

Class DecryptedFile /**

* @param decryptedFileData Byta Array of a File or a data that the user would

encrypt

* @param nameFile name of the file that the user would encrypt

* @param typeFile the type of the file that the user would encrypt

* @param uploadBy the name of the user that have uploaded the file

*/

DecryptedFile(byte[] decryptedFileData, String nameFile, String typeFile, String

uploadBy)

abeClient

AbeProxyInterface.js is the JavaScript file that exposes the methods that allow a web client to

encrypt and decrypt a file with CP-ABE/AES.

/**

* AbeProxyInterface javascript,

* @author Diego Pedone (Fincons Group)

* ---- javascript class used for emcryption and decryption in particularly for

concatKdf ----

* @required <script type="text/javascript" src="crypto/components/core.js"></script>

* @required <script type="text/javascript" src="crypto/components/sha256.js"></script>

* @required <script type="text/javascript" src="jsrsasign/crypto-1.1.js"></script>

* ---- javascript class used for conversion ----

* @required <script type="text/javascript" src="scripts/jsrsasign/base64x-

1.1.js"></script>

* @required <script type="text/javascript"

src="scripts/jsrsasign/ext/base64.js"></script>

* ---- worker use to communicate with abe proxy ----

* @required "scripts/abeClient/workerAjaxAbeClient.js", imported like worker

* @version 1.0 (problem with big File).

*/

/**

* @costructor

* @params config must have this structure:

*

* {

* worker: is the workerAjaxAbeClient path (used for connect to AbeProxy,

* key_alg: the algorithm use to create the couple of key,

* key_crv: the curve use from the key ,

* key_kty: identified the key type, key_enc: the algorithm which will be used to

encrypt the data,

* url_abeProxy: the abeProxy's url,

* username: username , key_storage_type:The key_Storage type es. database,

* key_storage_ip: the KeyStorageService's ip address or host ,

* key_storage_port:the KeyStorageService's port ,

* key_db_database:the database name used in keyStorageService,

* key_db_table:the table name used in keyStorageService,





* }

* First of all is needed the initialization by the costructor passing the config like

parameter.

* @Encryption: instruction to use the library for the encryption

* - 1 set the operation, this operation allow to have a different username for

encryption and decryption,

* needed for a correct configuration of shared symmetric key.

* - 2 invoke getSharedSecret for the generation of a shared Symmetic Key

* - 3 create a new key used for the sign the message with importHMACKey method

* - 4 import the sharedSymmetricKey in webcrypto Format with importAESCBCWebcryptoKey

method

* - 5 use the method encSharedSymmetricKey to encrypt the policy, sign the encrypted

policy

* and send it to ABE-Proxy. the Abe-Proxy return the id of

SharedSymmetricKey.

* - 6 encrypt the data with sharedSymmericKey.

* - 6.1 generate a random IV

* - 6.2 encrypt the data and return the encrypted file.

*

* @Decryption: instruction to use the library for the decryption

* - 1 set the operation, this operation allow to have a different username for

encryption and decryption,

* needed for a correct configuration of shared symmetric key.

* - 2 invoke getSharedSecret for generate SSKP , a key used to Protect the Shared

Symmetric Key used for the data encryption

* - 3 create a new key used for the sign the message with importHMACKey method

* - 4 import the SSKP in webcrypto Format with importAESCBCWebcryptoKey method

* - 5 use the method getSharedSymmetricKeyProtect to send to AbeProxy a request to get

the ShaderSymmetricKey by Id,

* the SSK(shared Symmetric Key) is protect by the SSKP ( shared Symmetric

Key protector, a key used to encrypt the SSK).

* - 5.1 verify the sign of the response

* - 5.2 decrypt the sharedSymmericKey with SSKP.

* - 5.3 import the sharedSymmetricKey in webcrypto Format with importAESCBCWebcryptoKey

method

* - 6 decrypt the data with sharedSymmericKey.

* - 6.1 get the iv from protected file

* - 6.2 decrypt the data and return the decrypted file.

*/

AuthN-AuthZ

/**

* Register a new user

* @param username

* @param password

* @param urlTokenService URL of the token service to query

* @returns response HTTP response to check the request status

*/

function register(username, password, urlTokenService){

/**

* Login

* @param username

* @param password


* @returns userTokenService JSON object with the user’s session token

*/

function login(username, password, urlTokenService){

/**

* Logout

* @param userTokenService JSON object with the user’s session token







*/

function logout(UserTokenService userTokenService, String urlTokenService)

/**

* Request an access Token to the Access Token Service that

* verifies if the user is authorized

* @param nameService name of the service to access which the authorization token is

necessary

* @param userTokenService session token got from the login operation

* @returns sJWT Json Web Token to access the service

*/

function requestToken(nameService, userTokenService){

/**

* Execute the service requested

* @param sJWT Json Web Token got from the Token Service

* @param deferedRequest Url of the target service

* @param input input data for the request to the target service


*/

function executeService(sJWT, deferedRequest, input){





Annex 2: Anonymization API

This is an example explaining how a solution that uses the public libraries provided by the ARX Anonymization framework can be developed. In this example we are using the java library corresponding to the 3.3.1 version of ARX.

ARX API offers the possibility of obtaining the data from different source types: they can be defined manually, got from a file or from a database. In this example the data are obtained from a database.

Next can be seen how the ARX Datasource class is used for doing this:

DataSource source = DataSource.createJDBCSource(props.getProperty("jdbc.url"),

props.getProperty("jdbc.username"),

props.getProperty("jdbc.password"),

"citadel_personaldata_view");

After getting the data, it is necessary to define the data types and the attribute types, so they can be processed correctly afterwards.

Next an example of how it is carried out the data types specification:

source.addColumn("NAME", DataType.STRING);

source.addColumn("SURNAME", DataType.STRING);

source.addColumn("IDENTIFICATION_NUMBER", DataType.STRING);

source.addColumn("GENDER", DataType.STRING);

And the attribute types setting:

data.getDefinition().setAttributeType("NAME", AttributeType.IDENTIFYING_ATTRIBUTE);

data.getDefinition().setAttributeType("SURNAME", AttributeType.IDENTIFYING_ATTRIBUTE);

data.getDefinition().setAttributeType("IDENTIFICATION_NUMBER",

data.getDefinition().setAttributeType("GENDER", AttributeType.INSENSITIVE_ATTRIBUTE);

Once the types are defined, it is necessary to establish a generalization hierarchy for each of them under the AttributeType.IDENTIFYING_ATTRIBUTE category, so it will possible to return generalized data instead of concrete data, making it possible to extract relevant information without revealing the personal identities.

For this example, we have a set of database tables where that generalization is established.

For example, see next table with different generalization levels related to some of the occupations a person may have.





Figure 35. Generalization levels example

With all this configuration set, it is possible to execute the anonymization algorithm by returning data sets by ensuring the principle of k-anonymity (this principle guarantees that the individuals who are the subjects of the data cannot be re-identified while the data remain practically useful).

ARXAnonymizer anonymizer = new ARXAnonymizer();

ARXConfiguration config = ARXConfiguration.create();

config.addCriterion(new KAnonymity(2));

ARXResult result = anonymizer.anonymize(data, config);


D4.6 Final CITADEL security toolkit · D4.6 – Final CITADEL security toolkit Version 1.0 –...

Documents

Transcript of D4.6 Final CITADEL security toolkit · D4.6 – Final CITADEL security toolkit Version 1.0 –...