Distributed ledger technology and European Union General Data Protection Regulation compliance in a flexible working context

Compliance of distributed ledger technology (DLT) based solutions with the European Union General Data Protection Regulation (EU GDPR) is currently a hot topic both from a technical point of view, as well as from a legal and normative one. Flexible working is a new working model where employees can perform their work activity without specific time and space constraints. In this context privacy and information trustworthiness are relevant and, therefore, on the one hand it can gain benefit from using DLT based solutions, on the other hand it must comply with the GDPR. This paper describes a solution that combines DLTs and the new Ciphertext‐Policy Attribute Based Encryption cryptographic techniques to support compliance with the EU GDPR in the context of flexible working. The devised solution is being concretely experimented, in the context of the EU H2020 CITADEL project, by the Municipality of Bari (Italy).

maintained by nodes. However, a collusion of the network majority could cause records tampering), (e) transparency (each transaction on the network is publicly available). It is trivial to highlight how most of these properties conflict with the principles of GDPR, so without proper actions GDPR compliance cannot be ensured when using blockchains to handle personal data.
This paper proposes a solution that exploits CP-ABE, 6 a novel encryption technique, in combination with advanced encryption standard (AES) to handle data on a permissionless DLT (eg, Ethereum) in a GDPR compliant way, to support a pilot experimentation of flexible working by employees of the Bari Municipality (Italy).
In detail, CP-ABE is a novel asymmetric encryption scheme in which each user has its own private key which is associated with a set of attributes that are usually part of user's profile. When encrypting a message, the data owner provides an access policy that specifies which attributes and conditions must be owned and met to positively decrypt the message. Access policies are used to encrypt messages. Therefore, only users having their keys satisfying the policy will succeed in decrypting the data.
The paper is organized as follows: Section 2 outlines related activities, Section 3 provides details on our proposal, while Section 4 presents the use case in which our solution is adopted and Section 5 summarizes the main outcomes and future plans.

RELATED WORK
Currently DLT technologies are being widely investigated. Agbo et al 7 have presented a survey on blockchain applications in healthcare, highlighting their pros and cons, and that further research is required to address all challenges especially regarding security and privacy. Similar studies are provided by the European Union Blockchain Observatory & Forum on DLT and GDPR compatibility, 8 as well as DLT opportunities in government and public services. 9 Rantos et al 10 have proposed a blockchain-based IoT framework to help processing personal data in a GDPR-compliant way. Kosba et al 11 have presented a privacy-preserving smart contract system that provides on-chain privacy and contractual security. Dorri et al 12 have proposed a blockchain-based architecture to enhance privacy and security in an automotive ecosystem. Muma et al 13 have provided useful guidelines for designing GDPR-compliant blockchain solutions. This paper describes a GDPR's fully compliant solution focused on the flexible working context, addressing the challenges of personal data handling through disruptive technologies such as attribute based encryption and DLT.

GDPR PRINCIPLES AND COMPLIANCE PROCEDURES
The devised solution uses the DLT as a mean to exchange data related to flexible working activities from the employee to the employer ICT systems, assuring trustworthiness, integrity, immutability and GDPR compliance (even if limited to the application context). As requested by the GDPR, any system that processes personal data must follow the paradigms of privacy-by-default and privacy-by-design. 14,15 Specifically, the privacy-by-design principle requires that the system envisages adequate measures to safeguard the confidentiality of personal and sensitive information since the design stage. The privacy-by-default principle, instead, requires that the default settings of the system guarantee an adequate level of protection of personal/sensitive data, and, at the same time, that there is a minimal level of data protection that cannot be reduced.
As highlighted in Section 1, given the immutability property of DLT, it is not possible to immediately and directly comply with rights stated in Art. 16 and 17 of the GDPR (right to rectification and right to erasure respectively). This suggests to not store data directly on the DLT but, instead, keep only the hash code of such data as a reference in transactions, and store the encrypted data off-chain. In this way, it can take advantage of the property of data trustworthiness provided by the DLT, as it can still verify data integrity and origin thanks to the hash value stored on the DLT. This also contributes to keep transaction costs low, as transaction's fees are directly proportional to the amount of data.
GDPR Art. 5 mandates that the data controller/processor must have legitimate reasons for collecting the data and be transparent about which data are collected and for what purpose and ensure that: (1) there are no illicit uses (Lawfully, fairly and in a transparent manner), (2) data are collected for specific, explicit and legitimate purposes (Purpose limitation), § (3) are limited to those strictly necessary for the use case ¶ (Data reduction), (4) are accurate and up to date (Precision), (5) retained for no longer than it is necessary (Limitation on archiving) and, finally, (6) "processed in a manner that ensures appropriate security" (Integrity and confidentiality).
Specific cryptographic techniques should be used to guarantee protection and integrity of data and that their access is restricted to subjects explicitly authorized (eg, database administrators should not be able to access plain-text users' data).
As evident, very few of GDPR requirements are automatically met by DLT technologies. Therefore, specific privacy measures must be deployed in order to satisfy these mandates.
In addition to deploying specific security measures, the flexible working context can leverage on the existence of a contractual relationship between the worker and his/her employer. Indeed, the employment relationship implies the existence of legitimate reasons to collect employee's data and of well defined procedures to manage those data (eg, wrong office entrance/exit badge stamping rectification) that can help in assuring compliance with the GDPR when using a DLT in this context. In our flexible working system, GDPR rights have been fulfilled as described below: transmits incorrect data, he/she can ask to rectify or erase them and, if necessary, submit a new transaction with the updated data hash. • Right to erasure (Art. 17): any, even potentially, personal data stored off-chain is encrypted twice. A first AES encryption is applied using an ephemeral key generated on the worker's device. This AES key is then encrypted using a specific CP-ABE policy. By destroying the encrypted AES key, the personal data cannot be accessed anymore.

VALIDATION USE CASE
Our use case supports the Municipality of Bari flexible working pilot and its main objective is to certify the timing and location of flexible working activities, being these elements critical to assure compliance with contractual and insurance constraints, including assurance of the right to disconnect. Specifically, our system gives to flexible workers the possibility to virtually timestamp their "office entrance/exit." The flexible working program devised by the Bari Municipality, indeed, gives the opportunity to any requesting employee to perform its office activities in flexible working mode for 1 or 2 days/week, starting from 6:00 to 22:00, with an arbitrary number of breaks, with the only constraints to guarantee a preagreed 2 hours Availability Period, and to total the number of working hours envisaged by their contract. The system has been designed following the privacy-by-design and privacy-by-default paradigms. Therefore, on one hand collected and managed data are minimized, on the other hand information is never transferred or stored in clear. Indeed, the data to be managed in a trustworthy way can be summarized as: activity/break start/end time, employee ID and its location when he/she generates a start/end event. An Android App has been developed to support picking up this information on employee request and generate a suitable DLT transaction using the mentioned encryption techniques to transfer these data to the Administration ICT systems.
Ethereum is the DLT technology adopted as it supports a Turing-complete language to develop DApps and smart contracts. Being a permissionless DLT all transactions are public, and therefore the identified encryption measures are critical to assure confidentiality and GDPR compliance. Figure 1 depicts the system architecture for the Bari's pilot.

F I G U R E 3 Android app asking for user's consent
The Lightweight Directory Access Protocol (LDAP) Directory Service manages user profiles in compliance with the DIT X.500 standard, the AuthN Service manages users' authentication in Proof-of-Knowledge mode, the Supervisor Application Service supports supervisors in producing reports about flexible workers activities they are responsible for, the Attendance Registry Service is the Municipality's service that manages the attendance registry, and the CIPEL Service is the Bari Municipality's ICT systems employees involved in the pilot use for their daily work.
In Figure 1 there are four additional components: the Flexible Worker App which is installed on the worker's Android device and used to acquire and transmit via DLT's transactions the worker's data, the Supervisor Web Application used by supervisors to analyze employees' activities and flexible working impacts on the PA performances, the Attendance Registry DLT Oracle that interfaces the Ethereum DLT with the Attendance Registry Service of the Municipality, and the AuthN DLT Oracle that interfaces the DLT with the AuthN Service.
Each flexible worker in the Enrollment Phase § § provides his/her employee ID, ¶ ¶ assigned by the Municipality, and freely chose a password, that is used only locally to derive a symmetric key to encrypt data stored on the worker's device. The Android app then generates a public/private key pair using Elliptic Curve Digital Signature Algorithm (ECDSA) and the secp256k1 curve, as well as the worker's Ethereum address, derived from his/her ECDSA public key.
Supervisors, instead, use their employee ID, assigned by the Municipality, freely chose their password, ∥∥ and, have their public/private key pair, generated with the same aforementioned modality, for the web application login.
Finally DLT Oracles have their ECDSA public/private key pair, used to secure communication on the DLT, and their Ethereum address, derived from the ECDSA public key. Figure 2 depicts the overall data flow highlighting the data and infrastructures (ie, DLT and off-chain storage) involved with the user's activities. Since workers' geolocation data is subject to specific restrictions by the Italian law, the Android app encrypts this information with a specific CP-ABE access policy, so that this data in clear can be accessed only by specifically authorized subjects.
Each event transmitted by the Android app is actually sent via the DLT only after the worker has explicitly provided his/her consent (Figure 3).

CONCLUSION
The previous sections have described our solution that makes use of the Ethereum DLT to exchange and "certify" flexible working related information. Thanks to the CP-ABE encryption technique it is possible to protect confidential and personal information and assure GDPR compliance granting access to these data only to the subjects that meet the CP-ABE access policies. Our system stores hash values of the information on the DLT, while real data are encrypted and stored off-chain. To enhance compliance with the GDPR, information that could be subject to rectification or erasure is doubly encrypted: the actual data with an AES ephemeral key, and the ephemeral key with CP-ABE. *** The Bari Municipality pilot will run from Spring 2019 till end of September 2019 (end of the H2020 CITADEL project). The system will be assessed and refined during the pilot execution. It is planned to extend the system functionalities and to apply it to wider Flexible Working contexts in the near future.