Are blockchain and EU-GDPR compatible? This presentation from 2020, from Dennis Hillemann (Podcast: The Blockchain lawyer), explains the most important legal challenges. The presentation explains: - What are basic principles of GDPR? - What are basic functionalities of the blockchain technology? - What main issues are there between GDPR and blockchain technology? - What is personal data in a blockchain scenario? - Personal data & encryption and & hashing - Salting and Peppering - Data processor and controller in a blockchain scneario - Right to rectification and right to erasure - Transfer to third countries - National and internatinal activities to bring Blockchain and GDPR together.

1. Blockchain And Data Protection
Incompatible Or An Ideal Combination?
Hamburg, 24 February 2020
Dennis Hillemann, The Blockchain Lawyers Network

2. CV
Dennis Hillemann
Lawyer
CERTIFICATIONS — Lawyer (Admission 2006)
— Specialist lawyer for administrative law (2010)
BRANCH-SPECIFIC
EXPERIENCE
— 13 Jahre of relevant professional experience in the public sector (administrative law, constitutional law, EU law)
— As head of KPMG solution „Legal Advice on complex administrative procedures“ main contact person for ministries,
public authorities and public-sector companies especially with respect to developing new approaches to cooperations and
their funding
— Involvement in the field of blockchain and law; collaboration on designing DIN-SPEC 4997: “privacy by blockchain design“
(Deutsches Institut für Normierung e.V.)
— Speaker at various events regarding blockchain technology (e.g. OECD Global Blockchain Policy Forum, EDV-
Gerichtstag).
— Private podcast on blockchain-related issues: “The Blockchain Lawyer“, available on Apple Podcasts, Google Podcasts
and Spotify
— Founder of “The Blockchain Lawyers Network“, www.blockchainlawyersnetwork.com
RECENT WORK Federal Ministry:
— Continuous judicial representation before administrative courts, dealing especially with constitutional matters
Research facilities und universities:
— Continuous legal advice on all legal matters relating to science (especially on governance, IT, university legislation,
appointments, technology transfer, cooperation agreement), counsel concerning subsidy law
LANGUAGES — German (first language)
— Englisch (very good knowledge)
— French (good knowledge)
KPMG Law, Hamburg
T +49 40 360994-5045
F +49 1802 11991-1670
M +49 151 50638412
dhillemann@kpmg-law.com
2

3. 3

4. 4

5. Agenda
01 The principles of the GDPR
02 GDPR and blockchain – four open (legal)questions
03 Initiatives to reconcile blockchain technology and privacy
5

6. The principles of the GDPR
6

7. General Data Protection Regulation
- Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April
2016 on the protection of natural persons with regard to the processing of personal
data and on the free movement of such data, and repealing Directive 95/46/EC
(General Data Protection Regulation)
- Binding in its entirety and directly applicable in all Member states(Art. 288 Abs. 2
AEUV) as of 25. Mai 2018 – conflicting law had to be repealed
- Contains clarification clauses to allow Member States to adopt accompanying
regulations (e.g. in Germany, the “Bundesdatenschutzgesetz” (BDSG) was recast)
EU fundamental right to data protection according to Art. 8 (1) CFR, Art. 16 (1) TFEU
“Everyone has the right to the protection of personal data concerning them.”
7

8. Objectives of the regulation
Unifying the legal situation in the Member States
 Comprehensive harmonisation has been the aim of EU data protection regulation
since the adoption of the 1995 Data Protection Directive (DPD)
 Regulatory competence of the EU under Art. 16 (2) TFEU
 The Member States generally may not change the GDPR‘s level of protection
 Exemption: Member States may in certain cases suspend the possibility to
consent (Art. 9 (2) lit. a GDPR)
Protection of personal data
 Realisation of EU fundamental rights according to Art. 7, 8 CFR, Art. 16 (1) TFEU
 Lex loci solutionis: controllers and processors outside the EU can also be
obligated under the GDPR
Creating a level playing field for data processors
 Removing obstacles to the free movement of personal data within the Union
8

9. Fundamental principles of the GDPR
Principles to relating to processing of personal data, Art. 5 (1) GDPR
- Lawfulness, fairness and transparency
- Purpose limitation
- Data minimisation
- Accuracy
- Storage limitation
- Integrity and confidentiality
Lawfulness of processing
- Consent
- Contract
- Compliance with a legal obligation
- Legitimate interests pursued by the controller or a third party
9

10. Essential rights of the data subjects
 Right of access by the data subject
 Right to be provided with a copy of
personal data undergoing
processing
 Right to rectification
 Right to erasure (also known as:
Right to be forgotten)
 Right to restriction of processing
 Right to notification obligation
regarding rectification or erasure of
personal data or restriction of
processing
 Right to data portability
10

11. Realisation of the data subjects‘ rights
Art. 25 (1) GDPR – “Privacy by Design“
“Taking into account the state of the art, the
cost of implementation and the nature, scope,
context and purposes of processing as well as
the risks of varying likelihood and severity for
rights and freedoms of natural persons posed
by the processing, the controller shall, both at
the time of the determination of the means for
processing and at the time of the processing
itself, implement appropriate technical and
organisational measures, such as
pseudonymisation, which are designed to
implement data-protection principles, such as
data minimisation, in an effective manner and to
integrate the necessary safeguards into the
processing in order to meet the requirements of
this Regulation and protect the rights of data
subjects.”
Art. 25 (2) GDPR – “Privacy by Default“
“The controller shall implement appropriate
technical and organisational measures for
ensuring that, by default, only personal data
which are necessary for each specific purpose
of the processing are processed. That
obligation applies to the amount of personal
data collected, the extent of their processing,
the period of their storage and their
accessibility. In particular, such measures shall
ensure that by default personal data are not
made accessible without the individual‘s
intervention to an indefinite number of natural
persons.”
11

12. GDPR and blockchain – four open (legal)questions
 Personal data processing on
blockchains
 Data controllers and data
processors on blockchains
 Implementations of the data
subjects‘ rights of rectification
and erasure
 Data transfer to third
countries using blockchain
technology
12

13. From centralised to decentralised networks
A core idea of blockchain technology
— Central authority tells the other participants which
transactions are valid
— (Only) privileged users may view the list of previous
transactions or confirm new transactions
— Central server is in danger of being manipulated
Centralised Network
— No instructions from a central authority
— Every user may view the list of previous
transactions or confirm new transactions
— Manipulation of central servers is impossible
Decentralised Network
Note: The GDPR assumes a centralised network – this gives rise to legal questions regarding
its application to the decentralised blockchains!
13

14. A blockchain‘s logic
Transactions
Block 1
Transactions
Block 2
Transactions
Block n
Block 1
(Genesis Block)
Block 2 Block n
Hash:
0000009857vvv
Hash:
000000zzxvzx5
Hash:
00000090b41bx
Hash Block 1:
0000009857vvv
Hash Block n-1:
000000432qra1
Hash
Block 2 … n-2
Transactions
Block 3 … n-1
Block 3 … n-1
Hash:
…
Connecting the blocks
14

15. 43
21
Summary
How blockchain technology outperforms traditional digital data management
Particularly Secure
Attacks on a participant‘s computer cannot damage or
even destroy the blockchain as a whole.
For comparison, consider the cases of encryption of
central municipal or hospital administrations by
blackmail software: Repairs can take weeks.
Immutable
Blockchain networks generate a high evidential value
with regard to the stored transactions; due to the
chronological storage (hence the term „chain“) and the
decentralised character, subsequent changes are
possible only theoretically, but not practically.
Transparent
Blockchain networks keep the stored transactions
transparent: All participants can view them –
pseudonymised if necessary. What‘s important is that
only the transactions are pseudonymised and
transparent. The transferred data itself is not visible, so
that, for example, the names of both a transfer‘s
sender and recipient remain unknown.
Decentralised
Blockchains do not store transactions on a server or a
central cloud. Instead, the blockchain is stored on a
network of computers – so-called nodes. This means
that there is no centralised means of attack for third
parties. This is why blockchain technology is known for
being particularly secure.
15

16. The concept of personal data
“For the purposes of this Regulations
‘personal data’ means any information relating to an identified or identifiable natural
person (‘data subject’); an identifiable natural person is one who can be identified, directly
or indirectly, in particular by reference to an identifier such as a name, an identification
number, location data, an online identifier or to one or more factors specific to the
physical, physiological, genetic, mental, economic, cultural or social identity of that
natural person.“
Who must be able to establish the personal reference in order to personal data being
created?
Definition according to Art. 4 No. 7 GDPR
- Any person („absolute theory“)
- The controller or processor („relative theory“, in line with ECJ
case law)
16

17. How to identify natural persons
Identification of natural persons on the basis of data on blockchains is facilitated by the following
factors:
 The combination of transparent data on the one hand and transparent metadata on the other
 The immutability of the data stored on blockchains
 The current and future potential of data analysis
 Data stored outside the blockchain (external data)
Recital 26 Sentences 3, 4 GDPR
“To determine whether a natural person is identifiable, account should be taken of all the
means reasonably likely to be used, such as singling out, either by the controller or by
another person to identify the natural person directly or indirectly. To ascertain whether
means are reasonably likely to be used to identify the natural person, account should be
taken of all objective factors, such as the costs of and the amount of time required for
identification, taking into consideration the available technology at the time of the
processing and technological developments.”
17

18. Processing of personal data on blockchains
Personal data = information + identifier
 Transaction data (data used on blockchains that is no public key) can refer to natural
persons
 Public keys may refer to natural persons
 Hash values can refer to natural persons
 Counter example: Climate data does not refer to natural persons
 Counter example: Transfers between banks regarding their own accounts do not
refer to natural persons
18
A person is identified if there is an immediate inference, while she is identifiable if it is possible
to link a data to it by intermediate steps.
Concerning the question, whose knowledge needs to be considered to which degree in
identifying the data with natural persons, the GDPR takes a stance in its recital 26: Account
should be taken of all means that the controller or another person may reasonably likely use.
However, a means is only reasonable likely to be used when there is a possibility that the data
and the means to identify the data can be brought together.

19. Are public keys personal data?
- Transaction lists on blockchains contain public keys
- Pseudonymisation pursuant to Art. 4 No. 5 GDPR is achieved, but no
anonymisation: The identity of a natural person is only concealed behind an
individual string of characters, provided that no additional information is available that
would allow identification
- Identification of natural persons proves successful in practice: analysis tools can
decipher the pseudonym with reasonable effort; supplementary information on the
holder of the public key may be accessible as a result of contractual or legal
obligations (e.g. Know-Your-Customer principle, Money Laundering legislation)
- Making identification more difficult, e.g. through keys that can only be used once or
through Zero-Knowledge-Proofs (ZKPs)
Example: A orders a new smartphone on the Internet and pays by Bitcoin. The
transaction is stored under A‘s public key. Is this key now personal data?
19

20. Zero-Knowledge-Proofs
20
• “Zcash”, a cryptocurrency, uses ZKPs to prove the validity of individual transactions
without revealing the content or parties to a transaction
• Proof of majority without indicating one‘s concrete age
Technical procedure for proving a certain fact
without having to disclose more than what needs
to be proved
Third parties can only see that a valid
transaction has taken place, but not which
users have participated or the content of
the transaction (e.g. the amount of a
transfer)
Examples

21. Are encrypted data personal data?
21
With regard to encrypted data in blockchains,
the availability of the private key is crucial, as
the following examples show:
1. The private key is securely deleted.
Then the data is not considered personal
data anymore, because there is no
practicable way to decrypt and take
notice of the data.
2. The private key is only known to the
data subject. Here, it is not clear
whether the encrypted data is
considered personal data. Even if not,
the data subject might give away or
loose the key, leading to the data being
considered personal data.
3. The private key is known to other
people. The data then is considered
personal data.

22. Are hash values personal data? (I)
Hash values stored in blockchains can be considered personal data under certain
circumstances:
- The data has low entropy. This makes it possible to derive the original data from the hash
value. Bitcoin-miners are extremely fast and can reverse hashes by trying all possible
values of the original object. There should be at least more than 1030 possible values for the
original objects.
- Part of the data is known; the rest of the data has low entropy. Here again, reversing
the hash value is possible.
- The hash is used as a pseudonym to connect it to other data stored alongside the
hash on the blockchain. In this case, the original object can be connected to this other
data. The same is true when the additional information is revealed through the context of
the hash value on the blockchain. This will enable to connect the data in the hashed object
with additional data.
22
Hash functions: mathematical functions that can only be calculated easily to moderate
difficult in one direction, but extremely difficult or not at all in the other, e.g. prime
factorisation of natural numbers
Cryptographic hash functions are generally collision resistant: only one specific
object can produce one specific hash value

23. Are hash values personal data? (II)
23
- If the above factors (high entropy; no parts of data known to others; hash not used as
a pseudonym; no additional context stored on blockchain that allows re-identification)
are met and the hashed object is securely deleted (without remaining copies
anywhere), the hash does not reveal any information about the data subject.
- Only those who have access to the hashed object itself can make sense of the
information behind the hash. In this case, however, the information about a natural
person that can be found out by re-connecting the hash value to the hashed object is
already contained in the hashed object. In other words.: for those who already have
access to the hashed document, the hash then does not reveal any additional
information (again – only if the above factors are met, especially if the context of the
stored data on a blockchain does it is yet unclear if data protection regulation would
consider the hash personal data).
 For those using hash values as a technical vehicle to store (a reference to) personal
data on a blockchain, this DIN SPEC requires to only use data with high entropy.
Special attention must also be paid to where and by whom the hashed object (e.g. a
scanned document) can be processed and in which context the hash is stored on a
blockchain.

24. Hash values – increasing safety by increasing entropy
24
Entropy
Measure of the variability of a digital object in terms of the number and variety of
characters – an object, for example, can be supplemented by an additional random value
before hashing to increase entropy (salted hash); this additional hash value can also be
used as a password (peppered Hash).
Salting
Salts are random strings that are added to passwords before hashing, enabling one
password to look unique to an attacker seeing the password hash, even if two users
share the same password.
Peppering
Uses a random value which is not stored in the same place as the hash value. Pepper
increases entropy of the combined object and works like a password.

25. Hash values – anonymisation and pseudonymisation
A) No personal reference can currently be derived from the hash value = no personal
data (= anonymised)
B) Personal references could be derived from hash only with disproportionate
expenditure = no personal data (= anonymised)
C) A personal reference can be derived from the hash with relatively little effort (e.g. due
to low entropy) = personal data (= pseudonymised)
Recital 26 Sentences 3, 4 GDPR
“To determine whether a natural person is identifiable, account should be taken of all the
means reasonably likely to be used, such as singling out, either by the controller or by
another person to identify the natural person directly or indirectly. To ascertain whether
means are reasonably likely to be used to identify the natural person, account should be
taken of all objective factors, such as the costs of and the amount of time required for
identification, taking into consideration the available technology at the time of the
processing and technological developments.”
25

26. Responsibility pursuant to the GDPR
Controller according to Art. 4 No. 7 GDPR means
“the natural or legal person, public authority, agency or other body which, alone or jointly
with others, determines the purposes and means of the processing of personal data;
where the purposes and means of such processing are determined by Union or Member
State law, the controller or the specific criteria for its nomination may be provided for by
Union or Member state law…“
Joint Controllers according to Art. 26 (1) Sentence 1 GDPR:
“Where two or more controllers jointly determine the purposes and means of processing,
they shall be joint controllers.”
Obligations arise according to Art. 24ff. GDPR
Basic obligation pursuant to Art. 24 (1) Sentence 1 GDPR:
“Taking into account the nature, scope, context and purposes of processing as well as the
risks of varying likelihood and severity for the rights and freedoms of natural persons, the
controller shall implement appropriate technical and organisational measures to ensure
and to be able to demonstrate that processing is performed in accordance with this
Regulation.”
26

27. Public blockchains and data protection responsibility
- Disputed matter, further research required
- As miners or during validation, nodes store and distribute information, but cannot
determine the purpose and means of data processing
- The sender of a transaction, on the other hand, causes the distribution of information
to all other nodes and thus determines the purpose and means of processing
- Software developers enable the use, but do not define its specific purpose and do not
commission transactions – therefore they are not controllers
Decentralised networks pose the problem of responsibility: Does the data protection
responsibility within DLT systems have to be clarified?
Contra: Technical properties of public blockchains make it considerably more difficult to
allocate responsibility
Pro: GDPR to implement the EU fundamental right to data protection from Art. 8 CFR,
Art. 16 (1) TFEU
27

28. Private blockchains and data protection responsibility
- Assigning responsibility seems easier with private than with public blockchains
- Central entity (natural or legal person) determines the purpose and means of data
processing by holding, managing and verifying certificates that allow nodes to identify
themselves as subscribers
- Sender of transactions are either processors of the central instance or joint controllers
together with the central entity (if the blockchain is used for their own purposes as
well, e.g. in a consortium whose individual companies use the same DLT system)
- CNIL proposes: designation of a controller in a group operating a DLT infrastructure;
but according to the functional approach of the GDPR, such a designation could not
shift responsibility from the group members when they act as controllers (i.e. also
determining the purposes and means of data processing)
28

29. Excursus: blockchain and household exemption (I) - Terminology
Art. 2 (2) lit. c GDPR:
“This Regulation does not apply to the processing of personal data by a natural person in
the course of a purely personal or household activity.”
29
Recital 18 Sentence 2 GDPR:
“Personal or household activities could include correspondence and the holding of
addresses, or social networking and online activity undertaken within the context of such
activities.”
Criteria for further interpretation
- spatial (private area of the controller/public space)
- social (relationship processor – data subject)
- purpose (personal-family/professional-economic)

30. Excursus: blockchain and household exemption (II) – Application to
blockchains
30
French data protection authority CNIL: Yes, because if only the sender of transaction is
considered to be the controller, he or she can carry out a transaction exclusively for the
exercise of personal activities (e.g. when purchasing a Bitcoin for private purposes).
Can data processing on blockchains fall under the household exemption?
EPRS study: No, because personal data is always made available to a very if not
indefinitely wide circle of people in the context of a DLT transaction. This excludes the
exercise of a purely personal activity.

31. Data processors on blockchains
Processor (Art. 4 No. 8 GDPR) means
„a natural or legal person, public authority, agency or other body which processes
personal data on behalf of the controller.“
- Miners and validating nodes
- Data processing on behalf of a transaction‘s sender
- Does a contract have to be concluded in order to constitute processorship?
Validating nodes process personal data on behalf of the central entity
Example: external provider of a DLT infrastructure as contractor of a company/authority
Note: the processor is also liable for violations of the GDPR (Art. 82 (1) GDPR)
Processors on public blockchains
Processors on private blockchains
31

32. Implementation of the right to rectification on blockchains
Art. 16 GDPR
“The data subject shall have the right to obtain from the controller without undue delay
the rectification of inaccurate personal data concerning him or her. Taking into account
the purposes of the processing, the data subject shall have the right to have incomplete
personal data completed, including by means of providing a supplementary statement.”
- Tension between the immutability of blockchain entries and the need for mutability to
rectify data
- Public blockchains require the consensus of a sufficient number of participants to
modify transactions (difficult to achieve between several thousand nodes)
Issues with blockchains
- Rectification on private blockchains on behalf of the central entity is technically
possible by re-hashing of individual blocks
- Pruning (partial removal of individual transactions from blocks)
Possible solutions
32

33. Realisation of the right to erasure (right to be forgotten) on blockchains
Art. 17 Abs. 1 GDPR
“The data subject shall have the right to obtain from the controller the erasure of personal
data concerning him or her without undue delay and the controller shall have the
obligation to erase personal data without undue delay where one of the following grounds
applies…”
- Storage of only those data to which the right to erasure does not apply (exemptions of
Art. 17 GDPR)
- Convenient interpretation of the term “erasure“, so that destruction of the hardware,
anonymisation of the data or destruction of the private key could be sufficient as
measures technically possible
Issues with blockchains
- Blockchains are decentralised
- immutability of blockchains
- Extent of erasure on public blockchains: Does the controller or processor have to
enforce erasure against all nodes?
Possible solutions
33

34. Data transfer to third countries using blockchain technology
- Data transfer on the basis of an adequacy decision, Art. 45 GDPR (example:
adequacy decision resulting from the EU-US data protection shield)
- Data transfer subject to appropriate guarantees by the controllers or processors, Art.
46 GDPR
- Data transfer due to exemptions for certain cases, Art. 49 GDPR (in particular the
consent of the data subject)
Admissibility of data transfer to third countries (countries outside the EU)
 How can the location of a foreign processor be determined?
 Is it appropriate at all to focus on specific locations in view of global DLT networks?
Outstanding issues
34

35. Initiatives to reconcile blockchain technology with privacy
35

36. DIN SPEC 4997
36
Implementation by…
 Legal assessment of individual rights under the GDPR
 Analysis of the technical challenges of exercising the
rights of the affected persons in different blockchain
scenarios
 Study on the fundamental principles of data protection and
their risks with regard to Privacy by Design
 Evaluation of the state of the art of jurisprudence, law
application and their approaches
Problem and preparation of DIN SPEC 4997
 Need for analysis of challenges regarding
GDPR and DLT
 Need to evaluate technical processes in the
context of GDPR
 Research on all affected persons‘ rights under
the GDPR and their impact on the variety of
blockchain scenarios
 Research on the terminology of GDPR

37. The Federal Government of Germany‘s round table on data protection
and blockchain technology
 Evaluation of the GDPR by representatives of the EU
Commission after almost two years of application; scope for
action by the Member States; cooperation between supervisory
authorities; data transfer to third countries
 Compatibility of the blockchain‘s decentralised structure with the
GDPR‘s centralised structure (central supervisory authority!)
 Tension between the immutability of the blockchain and the right
to erasure
 Data protection on blockchains in the case of data transfer to
third countries with a lower level of data protection
 Anonymisation of personal data by means of hash values (or
pseudonymisation only?)
 Arguments against overestimating the blockchain: legal
uncertainties, costly, technical effort – no “technology for
everyone“
Main subjects
37

38. INATBA
 Promoting an open, transparent and inclusive governance
model for blockchains and other DLT applications
 Establishing a permanent dialogue with regulatory authorities
 Supporting the development of interoperability guidelines,
specifications and global standards for digital services
 Development of sectoral guidelines and specifications
106 organisations founded the platform “International
Association of Trusted Blockchain Applications“ in cooperation
with the EU on 3 April 2019
Source: www.inatba.org
Objectives
Main areas of activity: Energy, finance, health, governance and
public sector
38

39. List of references
39
- DIN SPEC 4997 (unpublished)
- Commission Nationale Informatique & Libertés (CNIL), Blockchain – Solutions for a responsible
use of the blockchain in the context of personal data, September 2018 (accessible at
https://www.cnil.fr/sites/default/files/atoms/files/blockchain_en.pdf).
- Michèle Finck, Study at the request of the European Parliamentary Research Service (EPRS),
Panel for the Future of Science and Technology, Blockchain and the General Data Protection
Regulation, Can distributed ledgers be squared with European data protection law?, July 2019
(accessible at
https://www.europarl.europa.eu/RegData/etudes/STUD/2019/634445/EPRS_STU(2019)634445_EN.pdf).
- Jörn Erbguth, Datenschutzkonforme Verwendung von Hashwerten auf Blockchains – Wann sind
kryptografische Hashwerte von personenbezogenen Daten selbst wieder personenbezogene
Daten?, MMR 2019, 654ff.
- Thomas Janicki/David Saive, Privacy by Design in Blockhain-Netzwerken – Verantwortlichkeit und
datenschutzkonforme Ausgestaltung von Blockchains, ZD 2019, 251ff.
- Sophie von Schenck/Tilman Mueller-Stöfen, Die Datenschutz-Grundverordnung: Auswirkungen in
der Praxis, GWR 2017, 171 ff.
- Peter Schantz, Die Datenschutz-Grundverordnung – Beginn einer neuen Zeitrechnung im
Datenschutzrecht, NJW 2016, 1841

40. Thank you very much!
40