GDPR and its impact on your blockchain project — a case study

In April 2016 the EU Parliament and Council agreed upon the General Data Protection Regulation (GDPR), which is set to take effect on May 25, 2018. The new GDPR will replace the existing data protection framework under the EU Data Protection Directive.

The new regulation brings the following changes:

1. Personal Privacy Rights — users have the right to change/update their personal data to ensure its accuracy. At any time, a user has the right to request that his/her personal data be removed from the system. The removal of data means that all personal data needs to be physically deleted and the user must be “forgotten”.

2. International transfer of EU citizen personal data outside EU — in the event that the personal data of an EU citizen is transferred outside the EU, special safeguards need to be applied to protect this transferred data.

3. Using Customer Consent — the vendor is required to clearly communicate and obtain consent from the user to store his/her personal data.

4. Communication — under GDPR, additional information must be provided to individuals before any data is processed. This communication needs to include the legal bases for processing the data, the retention period, and the right of complaint in cases where customers are dissatisfied with the company’s implementation of this regulation. The GDPR also requires that the information be provided in concise, easy to understand and clear language.

5. Mandatory Data Breach Reporting — in the event of a security breach where customer data is exposed to an unauthorized third-party, the vendor is responsible for reporting the data breach to the Data Protection Commissioner by no later than 72 hours after the breach unless the data concerned is anonymized, encrypted or otherwise unlikely to result in a risk to the rights and freedoms of natural persons.

6. Becoming Accountable — companies will need to make an inventory of the data they hold and examine why it is being held, how it was obtained, why it is required, how long should it retained for, etc. This is just the first step towards compliance. They will also need to track whether they are sharing data with any third party.

In many ways, distributed ledger technology (DLT) and the GDPR have several goals in common. Unlike a traditional centralized database, DLT promises individuals more control over disclosure of their personal data in the sense that they can freely decide the scope of the data disclosed and its recipients. DLT also mitigates many security risks regarding the sharing of personal information (e.g. identity theft).

Although the GDPR and blockchain have several common characteristics, there are certain areas which have had a huge impact on how we have built our solutions. Here is the list of most significant features:

Public nature of the blockchain — the very nature of a public blockchain means that transactions taking place are published and linked to a public key that represents a particular user. This is how the authors of any given transaction will be singled out to ensure transactions are correctly attributed. A visible public key enables the data subject to be identified, either because it is held by the service provider or because someone else can connect the public key to an individual or organization. If the public key and the hashed transaction data can be linked to an individual person, they both qualify as personal data and fall under the scope of the GDPR.

Immutability — the most important characteristic of blockchain is the immutability of the data it stores — once data is on the blockchain, it cannot be removed or changed. This approach contrasts with the rights that data subjects now have under the GDPR (the right to be forgotten, to rectify, to object etc.). The right to be forgotten provides the data subject with the option to request the erasure of personal data and to prevent the processing of personal information in specific circumstances. A potential solution for this is the full migration of the blockchain to remove the required record. Unfortunately, this would take too much time and effort.

The data controller and transfers of data to countries outside the EU — the GDPR is built on the idea of a central data controller; on the public blockchain, however, each node (usually) contains a complete copy of the entire ledger and can therefore be deemed a controller of personal data under the meaning of the GDPR. This problem arises because nodes are, in essence, unable to comply with its requirements and can be located anywhere in the world.

Anonymisation and pseudonymisation — for all the above reasons it is recommended to either avoid storing personal data on the blockchain or keep the personal data completely anonymised. However according to Opinion 05/2014 of the Article 29 Working Party[1], the threshold for data anonymisation (in such cases, this data is no longer categorized as personal) is very high. Encryption, hashing and tokenisation normally do not provide anonymisation, only pseudonymisation. Encrypted data can often still be traced back to a person if sufficient effort is invested in the task by experts or someone who holds the key to decryption. Although a hash cannot be reverse-engineered to discover the original document, the Article 29 Working Party considers hashing to be a technique of pseudonymisation, not anonymisation. The working group speaks of “linkability” — for a piece of information to constitute personal data — and hashing permits different records to be linked. The same applies to tokenisation. To determine whether a person can be identified from pseudonymised data, GDPR demands that “all means reasonably likely to be used”[2] must be considered[3].

Hive Project design with GDPR compliance in mind

Having considered all of the regulatory items listed in the previous section, we have designed our system from the ground up with compliance in mind. We were driven by the Privacy by Design principle in order to achieve our GDPR compliance solution, which includes Off-Chain encrypted Personal Information storage where the encryption key is stored on a separate server, with “salted” hash and personal data encryption.

The following section goes into more detail on the design and steps that are taken to protect personal data.

1.0 The personal data is collected and transferred through a secure channel.

2.0 The personal data is encrypted using a securely stored encryption key .

3.0 The “Salt” number is generated and added to the dataset.

4.0 The data set is added to the database

5.0 By using hash function cryptography, a user_hash is generated from the persona information dataset and added to the database

6.0 Any related user information that is stored on the blockchain will now be referenced with the user_hash generated in step 5. This ensures that only pseudonymized data is stored on the blockchain.

[1] Article 29 Working Party provides the European Commission with independent advice on data protection matters and helps develop of harmonized policies for data protection in the EU Member States. The Working Party comprises all the representatives of the national supervisory authorities in EU Member States.

[2] Recital 26 GDPR.

[3] The Article 29 Working Party evaluates anonymisation techniques based on the following criteria: possibility of singling out, likability and inference.