Agencia española de protección de datos (AEPD) and the European Data Protection Supervisor (EDPS)

Introduction to the hash function as a personal data pseudonymisation technique
Joint paper of the Spanish data protection authority, Agencia española de protección de datos (AEPD), and the European Data Protection Supervisor (EDPS) on hash techniques in data processing activities as a safeguard for personal data.

On deletion and anonymisation (German)
In a case that did not concern a blockchain, the Austrian data protection authority Datenschutzbehörde held that anonymisation does not have to be proven to be perfect forever. It is sufficient that currently there is no way to reverse it. Speculations on future technological developments do not have to be taken into account. This anonymisation then equals deletion.
This is a positive move for the use of blockchains where privacy enhancing techniques like hashing, zero knowledge proofs or encryption is used.

CNIL (France)

Premiers éléments d’analyse de la CNIL (French), an English version
Here is an abstract and comment on it in English. The CNIL creates some clarity, leaves a lot of questions open and creates some confusion with their opinion that smart contract developers can be processors.

NAIH (Hungary)

The Opinion of the Hungarian National Authority for Data Protection and Freedom of Information on Blockchain Technology in the Context of Data Protection (English translation)
The text is very confusing. I guess this is due to a bad translation.

WP 29 (predecessor of the European Data Protection Board (EDPB)

Opinion 05/2014 on Anonymisation Techniques
A very broad interpretation of personal data prior to the GDPR. Its interpretation in the literature is often even broader. Ironically, this opinion has become an obstacle for privacy enhancing technologies.

Opinion 01/2010 on the concepts of "controller" and "processor"
It gives a background and examples what "controller" means. However, it does not address peer-to-peer technology, where a user can be controller, processor and data-subject at the same time.

Jörn Erbguth, EDPL

Five Ways to GDPR-Compliant use of Blockchains EDPL 3/2019 p. 427 (€)

Jörn Erbguth, MMR

Datenschutzkonforme Verwendung von Hashwerten auf Blockchains - Wann sind kryptografische Hashwerte von personenbezogenen Daten selbst wieder personenbezogene Daten?MMR 2019, 654 (€)

Jörn Erbguth, Informatik 2019

Smart Contracts und die DSGVO DOI: 10.18420/inf2019_59

ITU Focus Group on DLT

Distributed ledger technology regulatory framework Technical Report FG DLT D4.1

Michèle Finck, European Parliamentary Research Service

Blockchain and the General Data Protection Regulation PE 634.445

Michèle Finck, Max Planck Institute

Smart Contracts as a Form of Solely Automated Processing Under the GDPR Max Planck Institute for Innovation & Competition Research Paper No. 19-01

Geneva Macro Labs / Impact Lab 2019

Short high level presentation on privacy and the right to be forgotten on public blockchains

A guide to blockchain and data protection by Winston Maxwell and John Salmon
Overall a good and easy to read summary of the current state. I would differentiate a bit more when it comes to hashes and distinguish different use-cases. Personally, I would also add a more positive vision: There are use-cases where blockchain is used to provide superior data-sovereignty to data-subjects by cutting out the intermediaries. I do not think that DPAs will ban these applications that provide better privacy in the name of GDPR.
The description of "smart contracts" in the context of public blockchains is misleading. An Ethereum smart contract cannot send data to external storage. Nor can an Ethereum smart contract be used to make any data on the Ethereum blockchain invisible to some or all users.

Hogan Lovells

A guide to blockchain and data protection by Winston Maxwell and John Salmon
Overall a good and easy to read summary of the current state. I would differentiate a bit more when it comes to hashes and distinguish different use-cases. Personally, I would also add a more positive vision: There are use-cases where blockchain is used to provide superior data-sovereignty to data-subjects by cutting out the intermediaries. I do not think that DPAs will ban these applications that provide better privacy in the name of GDPR.
The description of "smart contracts" in the context of public blockchains is misleading. An Ethereum smart contract cannot send data to external storage. Nor can an Ethereum smart contract be used to make any data on the Ethereum blockchain invisible to some or all users.

European Union Blockchain Observatory and Forum

Blockchain and the GDPR
"GDPR compliance is not about the technology, it is about how the technology is used."

Max Planck Institute for Innovation and Competition Research

Blockchains and Data Protection in the EU by Michèle Finck

Zeitschrift für Datenschutz (ZD 2017, 560)

Who is the controller of a Bitcoin transaction? (German) by Jörn Erbguth, Galileo Fasching

University of Southampton

On Blockchains and the General Data Protection Regulation by Luis-Daniel Ibáñez, Kieron O’Hara and Elena Simperl

101 Blockchains

Blockchain GDPR Paradox: Is it a Rising Conflict Between Law and Technology? by Hasib Anwar This is a good illustration of basic points. Some points are oversimplified and it should be complemented by some additional points.

Peppering and Salting Hashes

When you hash personal data and write the hash to a blockchain. How should you do it? First, let's take a look at the fundamentals:

Hashing has three possible ways of leaking data:

1. Because of lack of entropy, it is possible to guess the data. The hash will then verify whether the guess was correct. In this situation the hash will lead to the reconstruction of the original data.
2. The hashing algorithm might be broken in the future which might lead to the reconstruction of all or parts of the original data. This risk is very low. Even with a hashing algorithm like md5 that is deemed not to be secure anymore, this is currently not the case. Using this unsecure algorithm might only render it possible to create a second object that has the same hash value.
3. Somebody having a potentially original object is able to verify this object using the hash value on the blockchain. This is usually the intended purpose of the hash value. If no additional information is stored on the blockchain and guessing is impossible, this does not reveal any additional data than is already contained in the document, but confirms that the document has not been altered. Does the hash therefore constitute personal data or not? Even if it does, in most cases there should be legitimate interest that those who have received the digital object will be able to verify that it has not been altered.

First, let's look at the fundamentals:

Adding keys (salt, pepper) is a technique used in the contexts of passwords. Passwords need to be stored on computers. However, storage on most computers is not very secure. So the goal was to be able to store some information about a password that will be enough to verify the correct password but that cannot be used to calculate or derive the password. Due to the low entropy of passwords, using a hash-function is not sufficient:

1. Adding a random key (salt). A random key is added to each password before being hashed. Salting a hash is done to avoid parallel or rainbow-table attacks on passwords. The parallel-attack calculates the hash for one password and then compares it to the whole table of hashed password entries. The rainbow-table attack uses a long list of precomputed hashes to identify users that have used the same passwords. When adding an individual random salt to every entry, parallel and rainbow-table attacks will not work anymore. The salt can be stored together with the hash-value. Another advantage of using a salt is that two users with the same password will not have the same hash-value.
2. Adding a secret key (pepper). A constant but secret key is added to each password before being hashed. Using pepper requires to store the pepper at a secure place. The pepper blocks rainbow-table attacks and renders brute force attacks much harder.

However, there are some differences between hash-values of passwords and hash-values of objects to be stored for verification on a blockchain. First, some object might need to be verifiable by the public or a bigger group. Trying to keep a pepper-value secret within a bigger group is not a good idea. Second, many objects will have enough entropy.

Result:

1. If the object already contains enough entropy, there is no need for salt or pepper being added.
2. If the object does not contain enough entropy, it should be supplemented by random data - if possible.
3. If the object does not contain enough entropy and supplementing the object would render it invalid, a seperate random key (salt) should be used.
4. If the object should only be verifiable by a small group of people, some secret pepper can be added in addition to the other measures above .

Don't add data to the hash on-chain!

Be aware that combining the hash with additional data on the blockchain will create further problems. Since the original object contains information relating to an identifiable natural person, the hash can serve to relate the person with all other information stored with the hash on the blockchain. To avoid that, a record relating to a data-subject must be completely stored off-chain. Hashing only the sensitive parts of the record will leave the possibility to identify the rest of the record with the data-subject.

Chameleon Hashes

Don't Dismiss Accenture's Blockchain Redaction Solution — You May Need It One Day by Martha Bennett, Pascal Matzke, Jost Hoppermann, Ian McPherson

Medium

Medicalchain — A blockchain for electronic health records by Crypt Bytes Tech

Enigma

Decentralizing Privacy: Using Blockchain to Protect Personal Data by Guy Zysking, Oz Nathan, Alex 'Sandy' Pentland

About

This page is part of the Homepage of Jörn Erbguth.

The purpose of this page is to raise awareness about GDPR in the blockchain community. Please send error messages, suggestions, complaints etc. to consulting@erbguth.ch.

Jörn Erbguth, Chemin du Champ d'Anier 15, 1209 Geneva, Switzerland

Privacy Policy

This website does not use cookies. IP-addresses are stored by the provider Strato AG, Berlin only in anonymized form. The access log is used to analyse errors and to measure the traffic. No profiles are generated. Google Analytics or other third party tools are not used. The interactive QuickCheck is hosted on the US-platform formsite under a different privacy policy.

According to the Swiss DSG, the European GDPR or other applicable law, you have the right that certain information will be provided to you, that errornous entries will be corrected and that personal data where processing is no longer justified is deleted. You also have the right to address yourself to the the Swiss DPA (Eidgenössische Datenschutzbeauftragter) or your local Data Protection Authority.