D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 1 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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 WP4 – ICT Enablers to transform the Deliverable: Diomede Illuzzi (FINCONS) Editor(s): Domenico Rotondi (FINCONS) Marco Saltarella (FINCONS)
Contributor(s): Marisa Escalante (TECNALIA)
Reviewer(s): Gorka Benguria (TECNALIA)
Approved by: All Partners
Recommended/mandatory WP5 readers:
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 2 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
Document Description Document Revision History
Modifications Introduced Version Date Modification Reason Modified by v0.1 01/12/2018 First TOC and sections assignment. FINCONS
v0.2 19/01/2019 Access and Encryption Manager FINCONS description first update V0.3 20/02/2019 Access and Encryption Manager FINCONS description final update 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 FINCONS required by the internal reviewer V1.0 31/03/2019 Ready for submission TECNALIA
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 3 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 4 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 5 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 6 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 7 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 8 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 9 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 10 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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]:
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 11 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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):
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 12 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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]:
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 13 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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. Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 14 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
• 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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 15 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 16 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 17 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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 Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 18 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 19 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 20 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 21 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 22 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 23 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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/mas ter/ADAPT/Monitoring https://git.code.tecnalia.com/CITADEL_Public/CITADEL_Components/tree/M 15/Security/Anonymization
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 24 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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”.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 25 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 26 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019 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
personal data must be "processed The responsible for the lawfully, fairly and transparently", treatment is the Municipal which implies that the controller must Administration of Bari which Legitimacy, have legitimate reasons for collecting has legitimacy in the collection fairness and the information, it must be transparent and use of the aforesaid data as transparency which data are collected and for what they relate to its employees purpose and it must be ensured that who voluntarily and freely there are no illicit uses participate in the Smart Working program
personal data must be "collected for The data collected are limited to specific, explicit and legitimate those strictly necessary for the purposes" and used exclusively for the verification of the requirements purposes indicated. Art. 89 of the GDPR for the smart working activities Purpose does not consider incompatible with and are used for this purpose or limitation this principle the use of data collected for regulatory requirements. for archiving purposes in the public interest or for scientific or historical Data in aggregate form can also research and for statistical purposes be used for statistical analysis or for scientific publication
the personal data collected should be The collected data are "adequate, relevant and limited to what exclusively related to the is necessary" for the stated purposes beginning and end of the activities in smart working mode, as well as to the physical location of the smart worker. Data reduction 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
personal data gathered must be "precise The smart worker in the phase and, if necessary, updated". The data of submitting the data collected subject has the right to request that the looks at the data provided and inaccurate data held are corrected or sends them explicitly. deleted Precision 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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 27 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
GDPR Principle Principle description Procedure for compliance
for the correction of the data related to the presence
personal data must be "stored in a form The data collected relating to that allows identification of data the smart worker activities are subjects for no longer than necessary" solely aimed at managing its Limitation on for the stated purposes. It is activities in smart working and archiving safeguarded the right of the controller maintained by the municipal to store data in the public interest and administration solely for the for scientific or statistical purposes purposes related to the work performance of the employee
Personal data must be "processed in The prototype system, as such a way as to guarantee adequate documented below, uses security" 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. Integrity and confidentiality 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 Right description Methods of exercise the GDPR
Right of access The data subjects has "the right to The smart workers will be by the data obtain from the controller confirmation explicitly informed about: what subject (Art. as to whether or not personal data information is acquired, how it 15) concerning him or her are being is acquired, stored and processed and how it is possible
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 28 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
Right as envisaged by Right description Methods of exercise the GDPR
processed" and to receive details on to verify its correctness and, if how this is done and where 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
The data subject has " right to obtain The information acquired by from the controller without undue delay the system, moreover explicitly the rectification of inaccurate personal provided by the smart worker, data concerning him or her. Taking into relates to the start-up or account the purposes of the processing, termination of work activities the data subject shall have the right to and the location in which these Right to have incomplete personal data are performed. rectification completed, including by means of (Art. 16) providing a supplementary statement. " 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
the data subject has " the right to obtain The data provided by the smart from the controller the erasure of worker are conveyed through a personal data concerning him or her DLT system (Ethereum in the without undue delay" if these are no specific) and transferred to the longer necessary or there are other information systems of the impediments (e.g. for the fulfilment of a municipal administration. legal obligation) Right to With respect to the erasure (Art. management via DLT, since data 17) 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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 29 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
Right as envisaged by Right description Methods of exercise the GDPR
For the data transferred into the information systems of the Administration, the procedures established by the Administration are applied, if necessary
the data subject has " to obtain from the The information acquired is controller restriction of processing" solely aimed at managing the when certain hypotheses specified in work of the smart worker and is Art. 18 occur therefore managed and processed according to the provisions of the law and contracts.
The prototype system does not Right to perform any form of data restriction of processing being its activity processing (Art. limited to acquiring data and 18) 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
The data subject has " to receive the The data collected are related personal data concerning him or her, to the verification of the which he or she has provided to a performance of the Right to data controller, in a structured, commonly contractually established work portability (Art. used and machine-readable format” activities. 20) The smart worker is enabled to acquire these data for the uses provided by law
The data subject has " the right to The exercise of this right is object, on grounds relating to his or her limited because the data particular situation, at any time to controller has legitimate Right to object processing of personal data concerning reasons to proceed with the (Art. 21) him or her which is based on point (e) or processing of data related to (f) of Article 6(1), including profiling the performance of work based on those provisions"
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 30 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
Right as envisaged by Right description Methods of exercise the GDPR
The data subject has " the right not to be The aforementioned legislation Rights related subject to a decision based solely on (Article 14 of Law 124/2015) on to automated automated processing, including smart working explicitly individual profiling, which produces legal effects excludes penalties for the decision- concerning him or her or similarly purposes of recognition of making (Art. significantly affects him or her " professionalism and career 22) 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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 31 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019 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).
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 32 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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 No Create View No Access No Access No Access Interviewer Access
Use Case A View / No View No Access No Access No Access Analyst Create Access
View / Use Case A View / No Create / No Access No Access View Create Access Privacy Officer Drop
View View View Ethical Board View / View / View / based on based on based on Member policy Create policy Create policy Create
No Administrator No Access No Access No Access No Access No Access 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 Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 33 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 34 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 35 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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. Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 36 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 37 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
Double click to open the image
Figure 25. Enrol Smart Worker sequence diagram
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 38 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 39 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 40 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Folder name Content description
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”
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 41 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
Folder name Content description
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
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
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 42 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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}
# 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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 43 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
suffix "dc=SmartWorking" rootdn "cn=Manager,dc=SmartWorking" rootpw {SSHA}
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
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:
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 44 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
• 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 (
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 (
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 45 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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=
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 (
4. Open with a text editor the configuration file of the Policies_Storage_Service.war archive (
#OrientDB info DB_name = OrientDB DB_user =
#OrientDB info DB_name = OrientDB DB_user =
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 46 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
DB_adress =localhost 6. Open with a text editor the configuration file of the SW_Token_Service.war archive (
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- INF\classes\log4j.properties log4j.appender.file.File==C:/citadel/logs/policy_storage_service.log In C:\Tomcat\apache-tomcat\webapps\StorageService\WEB- INF\classes\log4j.properties log4j.appender.file.File==C:/citadel/logs/storage_service.log In C:\Tomcat\apache-tomcat\webapps\File_Service_Web\WEB- INF\classes\log4j.properties log4j.appender.file.File= C:/citadel/logs/file_service_web.log In C:\Tomcat\apache-tomcat\webapps\SW_Token_Service\WEB- INF\classes\log4j.properties 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://
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):
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 47 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
openssl pkcs12 -export -name
keytool" -importkeystore -destkeystore
"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:
At this point, if you browse the URL http://
• 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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 48 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
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 LdapPSW=
parity_protocol=http parity_IP=localhost
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 49 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
parity_port=8545 WalletPath =
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 =
SC02Address =
CPABE_PUBLIC_KEY_PATH =
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. Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 50 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 51 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 52 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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:
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 53 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
• 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).
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 54 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 55 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 56 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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].
[1 NIST, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete 0] Logarithm Cryptography,” May 2013. [Online]. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf. [Accessed 4 December 2017].
[1 IETF, “Json Web Token,” May 2015. [Online]. Available: https://tools.ietf.org/html/rfc7519. 1] [Accessed 4 December 2017].
[1 U. G. O. f. Science, “Distributed ledger technology: beyond block chain,” gov.uk , 19 01 2] 2016. [Online]. Available: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachmen t_data/file/492972/gs-16-1-distributed-ledger-technology.pdf. [Accessed 19 3 2019].
[1 N. I. o. S. a. Technology, “Advanced Encryption Standard (AES),” FIPS Pub, p. 197, 26 11 3] 2001.
[1 Garante per La Protezione dei Dati Personali, Le linee guida del Garante per posta 4] elettronica e internet, G.U. n. 58 del 10 marzo 2007.
[1 Garante per La Protezione dei Dati Personali, Trattamento di dati personali effettuato 5] attraverso la localizzazione di dispositivi smartphone, provvedimento n. 226 del 18 maggio 2016.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 57 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
[1 Garante per La Protezione dei Dati Personali, Verifica preliminare. Trattamento di dati 6] personali mediante un sistema di localizzazione geografica dei dispositivi aziendali, provvedimento n. 232 del 18 aprile 2018.
[1 Presidenza del Consiglio dei Ministri, Indirizzi per l'attuazione dei commi 1 e 2 dell'articolo 7] 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.
[1 A. Cavoukian and J. Jonas, “Privacy by design in the age of big data,” Information and Privacy 8] Commissioner of Ontario, Canada, 2012.
[1 A. Cavoukian and M. Chanliau, “Privacy and security by design: a convergence of 9] paradigms,” Office of the Privacy Commissioner Ontario, Canada, 2013.
[2 R. Ross, M. McEvilley and J. Oren, “Systems security engineering: Considerations for a 0] multidisciplinary approach in the engineering of trustworthy secure systems,” National Institute of Standards and Technology, 2016.
[2 D. D. Caputo, S. L. Pfleeger, M. A. Sasse and P. Amma, “Barriers to Usable Security? Three 1] Organizational Case Studies,” IEEE Security & Privacy, vol. 14, no. 5, pp. 22-32, 2016.
[2 B. Schneier, “Stop Trying to Fix the User,” IEEE Security & Privacy, vol. 14, no. 5, 2016. 2]
[2 Agenzia per l'Italia Digitale, “Linee guida di design per i servizi digitali della PA,” 14 Ottobre 3] 2018. [Online]. Available: https://media.readthedocs.org/pdf/design-docs- francescozaia/revisione-capitolo-ui/design-docs-francescozaia.pdf.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 58 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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 Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 59 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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 */
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 60 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 61 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 62 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
* @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 * @required * @required * ---- javascript class used for conversion ---- * @required * @required * ---- 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,
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 63 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
* } * 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 * @param urlTokenService URL of the token service to query * @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
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 64 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
* @param urlTokenService URL of the token service to query * @returns response HTTP response to check the request status */ 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 * @returns response HTTP response to check the request status */ function executeService(sJWT, deferedRequest, input){
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 65 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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.
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 66 of 67 D4.6 – Final CITADEL security toolkit Version 1.0 – Final. Date: 31.03.2019
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);
Project Title: CITADEL Contract No. GA 726755 www.citadel-h2020.eu Page 67 of 67