Blockchain in the Age of the GDPR and Data Protection

Blockchain and GDPR have become very hot topics in the technology community in recent years. Privacy issues in Blockchain are of great importance, so this article will discuss the main challenges of their interaction.

This article was prepared in reaction to the published reports of the French Personal Data Protection Authority (CNIL) and EU Blockchain Observatory & Forum.

In this article, we will not go deeply into legal details, but three key terms still need to be recalled:

• Personal data — Any information that directly or indirectly identifies a natural person. Depending on the situation, it may be, for example, name, address, job details, email, or IP address. Worth noting that even a public key can be personal data according to the GDPR, provided that it is used to identify the natural person together with other information.

• Data subject — Any natural person within the EU and whose personal data are processed.

• Personal data processing — Any activity involving personal data, including data collection, use, and transfer.

When Does the GDPR Apply?

If the company resides in the EU, it must comply with the requirements of the GDPR when processing personal data, regardless of where the personal data are actually processed.

In the case of companies registered outside the EU, the GDPR applies to them only if they process the personal data of subjects in the European Union, provided that such companies offer their goods/services or monitor data subjects’ behaviour in the EU.

The same rules apply to natural persons (simply people), but the processing of personal data is related to professional or commercial activities (i.e. is not carried out exclusively for personal purposes).

It should be stressed that the above is a summary of the general rules, without taking into account the nuances and exceptions that may be available for a particular project.

Who Is a Responsible Person in Blockchain?

In handling personal data, the GDPR defines two key roles — controllers and processors of personal data.

From the Blockchain perspective, a user who enters personal data into Blockchain can be considered a controller. Such a user has independently chosen Blockchain as a means of data processing and thus is a data controller.

Within the Blockchain, a processor can be considered a miner, which validates transactions with personal data, as well as the owner of a smart contract, processing personal data.

Data Subjects’ Rights

The GDPR provides data subjects with an extensive set of rights, some of which can be easily implemented within the Blockchain — for example, rights to access and data portability. Unfortunately, the fulfilment of the rest of the data subjects’ rights in the Blockchain is not so simple.

For example, a data subject has the right to demand that personal data related to them must be deleted or modified. This is certainly contrary to the principles of the Blockchain. Sometimes, the demand even becomes technically impossible if the personal data in question is entered into a public Blockchain — for example, in the Bitcoin network.

Smart Contracts

The GDPR grants data subjects the right to obtain human intervention in the processing of personal data, if a controller performs certain automated decision-making with respect to such personal data — for example, when, in the data subject’s opinion, the algorithms work incorrectly with their personal data. In addition, the data subject has the right to express their own point of view and to challenge such automated decisions.

Smart contracts, which are an integral part of some Blockchains (the most famous being Ethereum Blockchain), may violate these rights since full automation excludes the possibility of human intervention in smart contracts or changes in the data entered.

Data Transfers Outside the EU

Personal data is only allowed to be transferred outside the European Union to countries with an adequate level of personal data protection. In order to transfer data to other countries, it is necessary to use additional protection measures in relation to each recipient of personal data (e.g. to conclude a data processing agreement with Standard Contractual Clauses).

In the case of a public Blockchain, it is likely impossible to meet these requirements. In the case of a private Blockchain, the easiest solution may be to restrict access to the network for persons that are not located in the EU, or in countries with an “adequate level of data protection”. Otherwise, an entry of personal data in such a Blockchain is likely to violate the GDPR requirements.

“Attack 51”

A so-called “attack 51” issue (meaning a takeover by those in control of more than a half of the blockchain network) is quite obvious, but we should point out that all possible measures should be taken to avoid a potential “attack 51”, as in this case personal data could be changed or deleted by the malicious users.

Data Retention Period

According to the principle of data minimisation, personal data should not be stored for longer than is actually necessary for the purpose of processing. That is to say, personal data should not be stored without a purpose. For example, if certain personal data was collected in order to perform a contract, such personal data must be deleted or anonymised after the contract has been terminated or the minimum storage period specified in the law has expired.

Therefore, when personal data is processed using Blockchain technology, it is recommended that there is a real possibility to delete or anonymise personal data.

Legal Basis for Personal Data Processing

Any processing of personal data must have a legal basis. Processing personal data without a legal basis is prohibited. The most common grounds for personal data processing in Blockchain are (i) consent of a data subject, (ii) performance of a contract, and (iii) legitimate interest of the controller. The latter legal basis allows the controller to process personal data without the data subject’s consent if they believe that their legitimate interests for processing outweigh the fundamental rights and freedoms of the data subject (this basis requires a preliminary analysis).

Recommendations

As always, a company has to define its own list of measures related to the GDPR compliance. First of all, it is necessary to work through all potential risks with data protection specialists. AURUM Law Firm will be glad to assist you in this regard.

The main recommendation is not to enter any personal data in a public Blockchain. While a private Blockchain still may comply with the requirements of the GDPR, a public Blockchain would technically be unable to meet those requirements. The EU supervisory authorities also agree with this position.

Unless it is really necessary, it is not recommended to enter personal data into a Blockchain (at least in “pure” form). For instance, you can use one of the following solutions:

• “Commitment scheme” — Personal data is entered into a Blockchain as “commit”, which cannot be viewed without the key.

• Hashing — Personal data is hashed, and only the hash confirming the correctness of the data and its existence is entered into the Blockchain.

• Encryption — Data is written to the Blockchain in encrypted form and cannot be read without the key.

• Anonymization of data — The GDPR does not apply to anonymized data, so it can be an excellent solution for certain Blockchain projects. It should be noted that the GDPR sets a relevantly high bar with respect to the anonymization.

In the case of hashing, it would be sufficient to remove the external data source, without which the hash becomes useless. In the case of commitment and encryption, deleting the key is equivalent to deleting the data.

When developing a smart contract that processes personal data, it is recommended to foresee the possibility of human involvement (at least in cases of processing personal data).

In addition, to minimize the risks of processing personal data, you can use “zero-knowledge proof” and “secure multi-party computation” protocols, which allow you to check the correctness of the data without providing access to the data itself.