Blockchain & GDPR – Two asymmetric or perhaps complementary concepts?

By Ioannis E. Giannakakis, Group General Counsel / Chief  Compliance & Risk Officer/Group Data Protection Officer, Avramar

The recent entry into force on 25 May 2018 of the General Data Protection Regulation (EU 679/2016), the most important piece of legislation in the field of personal data protection, has definitively changed the landscape in the global “digital” economy within and outside the borders of the European Union.

The GDPR is an innovative piece of legislation that seeks to strengthen the individual rights of data subjects, i.e. European citizens or, more accurately, natural persons residing permanently within the EU (European Residents) and establishes a clear and strict framework for the processing of personal data, i.e. any information that can directly or indirectly identify a natural person from the public or private sector legal entities “Data Controllers” and “Data Processors”. Public and private organizations, if they continue to operate as in the past, tend to collect data even before they know what to do with it, how to protect it and why they need it. GDPR contradicts this practice by specifying that Controllers should not collect data beyond what is directly useful for their direct interaction with consumers. Indeed, data collection should be “adequate, relevant and limited to the minimum necessary in relation to the purposes for which they are processed” (Article 39 GDPR).

In addition to determining what is or is not allowed, the GDPR also determines the organizational principles that Controllers will need to adopt from now on. For example, their technological architecture should include by design the option of deleting the personal data of consumers – data subjects after their use in accordance with the requirement for Privacy by Design (Article 25 of GDPR).

  1. Blockchain technology

Blockchain technology, created by Satoshi Nakamoto and his team of partners in 2009, is an innovative technology that allows the distribution of digital information, but not its copying or unauthorized reproduction and is now considered to support the backbone of a new type of Internet. Initially, it was designed to manage the cryptocurrency, known as Bitcoin, which currently has a value of USD 9 billion only in the USA, working only thanks to Blockchain technology, the main feature of which is that it allows a huge list of transactions to be recorded in digital currency without anyone being able to intervene and change this list after each new transaction.

Blockchain technology simulates an immutable digital library of financial transactions, which can be designed to record not only financial transactions but almost everything of economic value, free from any centrally controlled management. A corresponding XL file, copied millions of times to a computer network, while the information recorded in this file cannot be changed or deleted by the users of the file but is simply updated with each new transaction without losing the trace i.e. the historical continuity of the previous transactions. By combining cryptography and distribution, blockchain makes it very difficult to alter or delete information stored “on the chain” (ledger).

Thus, GDPR and blockchain start from diametrically opposed starting points on data integrity. While GDPR requires adjustability, blockchain provides unchanged continuity of transactions.

What happens when the two meet?

  1. Blockchain vs GDPR

Some argue that blockchain and GDPR are fundamentally incompatible. Should companies using blockchain to process personal data in the EU simply discontinue their services?

  1. GDPR and Personal Data

GDPR applies to anyone who processes personal data and is established in the EU. But it is not limited to companies established in the EU. It also applies to anyone outside the EU who processes the personal data of persons in the EU in the course of offering them goods or services.

Personal data is a broad term. It covers any information that can directly or indirectly be linked to an identifiable individual. This includes pseudonymized or encrypted data.

In principle, a blockchain using fully anonymous data does not seem to be covered by the provisions of GDPR. But it is difficult to offer a service when nobody knows the parties involved in the said service. Indeed, many businesses will need to identify customers under EU Know Your Customer (KYC) and Anti-Money-Laundering (AML) rules. As a result, KYC/AML compliance will also drive Blockchain transactions to be complied with GDPR.

  1. GDPR, blockchains, and design

Let’s consider a simple example. Lots of people lie in their CV. Some even falsely claim to hold a university degree. How do we detect such fraud?

A group of universities could build a blockchain for verified university degrees. Each university would have its own private key, meaning every degree it registers on the chain probably originated from that institution. Employers could then search through blockchain to check the applicants’ claims.

University degrees include personal data. So, would this blockchain be GDPR compliant? The answer depends, to a large extent, on how universities structure their blockchain. Let’s consider two options.

Firstly, universities could set up an open blockchain, also called the “public” or “empty” system.

To do this, they prepare their blockchain software and make it publicly available. Everyone can download the software and run it on their local machine. Everyone doing it, becomes what is called a “node”. The nodes keep a local copy of the blockchain and connect to other nodes in a peer-to-peer network keeping the blockchain updated.

The result could be hundreds – or even thousands – of nodes. This is a very resilient system – but it is also very complicated in light of GDPR requirements.

Firstly, let’s consider accountability. Although universities designed the application, they do not necessarily process their personal data through blockchain. The nodes do it. But the nodes have no control over how the system works.

In this model, universities aren’t really like a chef in charge of a kitchen. Instead, it’s more like they published a recipe book that anyone can cook at home. So, who’s a controller and who’s a processor? And how all parties should conclude data processing agreements between the Controller and the Executor.

Secondly, let’s look at data subject rights. Suppose I no longer want my degree stored on the blockchain. How will universities comply with my request for deletion?

To comply, they have to persuade each node to remove my data from their local copy. And even if the nodes agree, blockchain technology presents a problem. Removing the data changes the cryptographic hash of a block. Universities could instead create a closed block, also called a “private” or “authorized system”.

To do this, they simply run the blockchain software themselves. They either use their local machines or rent space “in the cloud”. Every university then becomes a node in a closed, private network.

From a GDPR perspective, this is a much simpler set-up. In terms of accountability, universities set up and operate the system together. As a result, they can be qualified as controllers. The cloud service provider is probably a processor, since it processes data on behalf of universities. Universities and the cloud provider have to sign controller-processor agreements.

What about data subjects rights? Couldn’t it still break the chain to process or remove data from previous blocks? Well, this is where we’ll need to design smart solutions. According to GDPR, blockchain applications should permit three main actions:

  1. Search for all personal data cases associated with a Personal Data Subject.
  2. Extract this data and provide it to the person in a portable format.
  3. Process or remove the data on request.

Let’s focus on the hardest part: processing and removing data from a blockchain.

  1. How do we delete the data from the blockchain?

Blockchain data is not really unchanged – it is difficult to change it. Collectively, the nodes control all copies of the blockchain. They can change the data stored on the chain by transitioning to a new version, called “forking”.

So, if in the previous example universities agree, they can delete data about a specific person from a previous block. It is certain that one could argue that this exceeds the point of use of blockchain. If universities can change the data on the chain, then outisders can no longer independently verify the integrity of the blockchain.

Whether this matters will differ depending on the application. In some cases, it should be enough that the nodes can verify and guarantee the integrity of the blockchain.

  1. Privacy by design: Allowing deleting while preserving integrity

It sounds like a paradox: how do you allow deletion of personal data, on the one hand, while maintaining the integrity of the blockchain, on the other? However, there are promising solutions that achieve this, mainly by separating (intelligible) personal data from the chain.

A first technique uses encryption. In the example above, universities could encrypt each entry to the blockchain with their own key pair and store only the encrypted encryption text on the chain. Instead of deleting the encryption text, the university will simply delete the relevant public key.

Although the encryption text remains on the chain, it can no longer be decrypted. This could be considered to have been deleted, at least in the UK.

Admittedly, there are risks to this approach. In the short term, the public key could be compromised in the event of a security breach before deletion. In the long run, the encryption mechanism may eventually be broken, for example through quantum calculations.

A second, safer technique uses off-chain storage. In the above example, universities could get a cryptographic hash of the degree they wish to verify by inputting the degree into a hash mode. However, theoretically, the hash remaining on the chain could still be characterized as personal data under GDPR. Anyone who has the input data can run it through the same hash function and then associate the hash with the data subject.

A solution could be to add a “nonce” (random data set) to the personal data. This is known as “peppering” the hash, and makes it much more difficult for an outsider to connect the hash on the chain to the individual.

  1. Building GDPR-compliant blockchain solutions

The above examples illustrate the kind of creative thinking required to design and operate private blockchains in a GDPR compliant manner. Some suggested using “binding network rules” to assign responsibility and research in this area is ongoing.

Let’s work together to design creative solutions to overcome the legal blockchain’s legal challenges. Imagine if a year from now, a blockchain-as-a-service provider could offer a GDPR ready blockchain to anyone in the EU who wants to process personal data. Then we can really unleash the power of this disruptive technology, while respecting data protection rights.

issue 126/2018

LEAVE A REPLY

Please enter your comment!
Please enter your name here