Distributed Ledger Technologies and GDPR’s right to be forgotten: Can they get along?

The right to be forgotten represents one of the most important GDPR provisions for data subjects to (re)acquire control over their data. However, numerous concerns have been raised on the feasibility of its enforcement in the context of Distributed Ledger Technologies. Is it possible to reconcile the technology with the law?

The right to be forgotten

First acknowledged by the Court of Justice of the European Union in its well-known Google Spain judgement, the right to erasure, also better remembered as the ‘right to be forgotten’, has formally been recognized by the GDPR. According to the GDPR’s Article 17, natural persons have the right to obtain from the controller the erasure of their personal data, where (at least) one of the circumstances foreseen therein applies (for instance, the data are no longer necessary for the purpose for which they were processed or the data subject withdraws her consent).

The right to be forgotten is one of eight rights provided by the GDPR to protect data subjects and allow them to acquire control over the processing of their own data. Nevertheless, its enforceability in the context of Distributed Ledger Technologies (‘DLTs’) is commonly disputed. Let’s see why.

DLTs, in brief

DLTs are generally defined as technologies that enable the storage and record of validated information, through a network of synchronized nodes. When the information is stored into blocks that, once filled, are chained together in chronological order, the DLT is commonly addressed with the more known name of ‘blockchain’. Therefore, DLTs can be programmed as blockchains, but the latter have not to be considered as a synonym of DLTs themselves.

The increasing rise of DLTs applications depends mostly on the fact they are designed to be tamper resistant and append-only: in a nutshell, DLTs are (almost) immutable. The information recorded in the ledger cannot, indeed, be altered without the cooperation of more than half of the nodes; process which would require an enormous computational power.

Is personal data actually stored in DLTs?

In line with the relevant literature, it is possible to distinguish two different sets of data usually stored in DLTs, which can potentially be GDPR-relevant: transactional data and public keys.

DLTs are nothing less than databases. While they can virtually store a wide range of information, DLTs are commonly used for recording data related to transactions: hence, the phrase ‘transactional data’. However, whether the content of the database revolves around purchases, financial transfers or medical data, it is clear how the data stored may often contain personal information, such as names, date of birth, addresses or credit card details. Therefore, transactional data may easily qualify as personal data, within the meaning of Article of 4 of the GDPR.

Transactional data in DLTs are not stored in plain text, they are rather encrypted for security reasons. DLTs rely specifically on asymmetric encryption, a cryptography technique which uses a pair of mathematically linked strings of letters and numbers (alias, keys) to encrypt and decrypt data. While private keys must – as by definition – remain private, public keys can be shared publicly for establishing secure communications. As already observed in this blogpost, when public keys are connected to a natural person, they are to be considered personal data under the GDPR, even if they cannot directly identify the user. In line with this, the Article 29 Working Party has, indeed, clearly stated how encrypted data fall within the category of pseudonymized data, as the current technology allows the data subject to be indirectly identified through the means of additional information.

At a first glance, considering DLTs’ characteristics, and especially their immutability, the clash with the GDPR’s right to erasure is more than apparent. Then, the main question here becomes: is it possible to reconcile the technology with the law?

Possible ways of ensuring compliance with the right to be forgotten

First, it is useful to recall here that the right to be forgotten, as defined by Article 17 GDPR, is not an absolute right. In light of its second paragraph, it can be argued that Article 17(1) GDPR could be interpreted by taking into account the available technology and the cost of its implementation. As a consequence, alternative technical solutions could be preferred to the outright erasure of the data.

On the one hand, as for transactional data, ensuring compliance with Article 17 GDPR is rather easy. First, as also recommended by the French Data Protection Authority (CNIL), personal data could be processed and stored in a modifiable off-chain database and, then, linked to the DLTs through the means of a hash pointer. In this way, the data can be deleted and the DLT would only report the information that certain content was existing at a certain point in time. Alternatively, the nodes of the DLT containing old transactions could be pruned after a predefined amount of time, whereas the hashed version of the removed node is maintained, so to ensure the integrity and security of the ledger.

On the other hand, ensuring compliance with the right to be forgotten in the case of public keys is more burdensome. As they are essential to ensure the validation of the DLT, public keys cannot be stored off-chain. The most compliant solution seems to be that of the implementation of anonymization techniques. According to the Article 29 Working Party, the technique of noise addition could be considered acceptable, if implemented along with additional safeguards, such as the removal of obvious attributes. With the addition of noise, several transaction are grouped together, so that it becomes impossible to identify who are the sender and the receiver of a certain transaction and, therefore, the holders of the public keys.

Is that it?

Well, not really. Even assuming that by implementing the aforementioned technical measures the data subjects’ right to be forgotten could be complied with, there are many more points of tension between DLTs and GDPR provisions. Particularly, it still seems hard to reconcile the technology with the principle of data minimization, the right to rectification and the right to access and, more generally, with the concepts of data protection by design and default. Further interdisciplinary research is then still needed to allow DLTs to properly function in a data protection-friendly scenario.

ENSURESEC has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 883242.