The challenges of applying data privacy regime to blockchain

Sept. 23, 2019

Image via iStock.com

This is part three of a series analyzing privacy laws and blockchain. Click here for part one and here for part two.

Regulators are still considering how blockchain implementations can comply with data privacy laws. One of the first to address this issue in a material way is the French data protection authority Commission Nationale Informatique & Liberté. We will discuss the CNIL's recommendations and views on a number of compliance issues below.

Determining who is the controller and who is the processor

One of the biggest challenges for privacy regulators is determining who is the controller in the case of blockchain and distributed ledgers. In these cases, there is typically no one person or entity that fits the definition and can readily exercise the obligations of a controller since many persons or entity may contribute and/or control the personal data that is added to the chain or ledger. The ease of identifying one or more controllers that can ensure privacy compliance will vary depending on the type of blockchain or ledger that is used.

Private blockchains: This is a form of blockchain in which a participant can join a private network only through an authentic and verified invitation, and validation is necessary either by the network operator(s) or by a clearly defined protocol implemented by the network. In these blockchains, although there is no definitive guidance from the regulators yet, the network operator(s) would be the logical choice to serve as the controller(s) for privacy matters.

Permission-based blockchains: This is a form of network in which anyone can join the permissioned network after suitable verification of his or her identity, but users are given limited permissions and can perform only certain activities on the network. Since these networks are often established by several different parties, CNIL has recommended that blockchain consortiums identify controllers or joint controllers as early as possible in the life of the project.

Public, permissionless blockchains: This form of network is completely open and anyone can join, leave, read, write, and audit the ongoing activities on the public blockchain network, which helps a public blockchain maintain its self-governed nature. The challenge, however, is identifying who to consider a controller with respect to personal data maintained on the network. Some have suggested the protocol developers serve as controller, but there are concerns that such developers do not really prescribe how the network is used or the data that is uploaded.  A better case can be made for  managing validation nodes being data controllers in that through the act of downloading and running the software, the nodes are determining the purpose and means of processing.

Smart contracts: These are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network. There is an ongoing debate whether the operator of the software that allows for smart contracts or the network’s users that access the software and enter the contracts should be the controller.

As the discussion above shows, there is still a need for further direction and clarification from regulators on the proper determination of controllers and processors in these networks.  In the meantime, developers and operators should consider developing an agreed upon framework for handling data privacy.

Determining the scope and legal basis of personal data on the blockchain

As noted above, GDPR requires a lawful basis for processing personal data.  In the case of a private or permissioned-based network, the designers and operators of such networks can prescribe rules for participation, including the types of data to be collected and the purpose for collecting the data. This will ensure notice and transparency at the outset. In addition, if participants are required to agree to terms and conditions, then the contract could serve as a basis for processing personal data.  Legitimate interest could also serve as a basis, but that typically requires identifying the controller and the interests that the controller is serving in processing personal data and weighing those interests against the rights and freedoms of data subjects. If the identity of the controller is not clear, it would be difficult to apply this analysis in the blockchain context.

Public networks create a bigger challenge because it is not always easy to identify the controller.  Consent might be a logical basis for the processing of data because each contributor presumably intends to have their data on the blockchain network. However, it is unclear to whom the user is giving consent, unless the networks clearly identify another party as the recipient of the data. In addition, GDPR requires that consent be specific and unambiguous, not implied. Blockchains would have to be set up to obtain the consent upfront and not rely on implied consent to support the processing of data. This is an area that would benefit from either establishing governance rules at the outset or further regulatory guidance.

Handling data subject requests

This is the most difficult area for blockchain to comply with data protection laws, as the principles of those laws seem incompatible with the immutable and decentralized structure of these networks. These requests also required an identified controller to contact, which as noted above, may not always be clear. The following are some of the specific challenges posed by certain requests.

Data access and portability requests: These are the subject’s rights to find out what information the controller has and to obtain a copy of that data in a commonly used and machine-readable format.  CNIL takes the position that these rights are compatible with the blockchain’s technical properties.  However, this right cannot be readily invoked unless there is a clearly identified controller, such as in a private or permission-based network that has access to all the data on the network.  If a network has multiple nodes, with each node having access to only a subset of personal data, it may be necessary to set up a mechanism where requests can be circulated to all required nodes for response.

Right to erasure and rectification: As noted above, blockchains are generally designed so that data, once entered, cannot be changed. This immutability directly conflicts with GDPR and CCPA provisions allowing data subjects to request that their data be corrected or deleted. One initial question is whether there might be an exception to the data deletion that could be invoked:

CCPA provides a number of exceptions that might apply.  For example, retention of the data is permitted where "reasonably anticipated within the context of a business’s ongoing business relationship with the consumer, or otherwise perform a contract between the business and the consumer" or "to enable solely internal uses that are reasonably aligned with the expectations of the consumer based on the consumer’s relationship with the business." (See Cal. Civ. Code §§ 1798.105(d)(1), (7)). Since the user understands that blockchain is supposed to maintain an immutable record of a transaction, one could argue that they should reasonably expect it to be maintained indefinitely.

GDPR does not have the same exceptions but does limit the right to demand deletion to certain grounds. For example, a data subject can request deletion where the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed or where there are no legitimate grounds for the processing. However, if data is part of an immutable chain of transactions that would be destroyed by its deletion, can one claim that deletion is not required because either (a) the data remains necessary for the purposes for which it was collected or (b) the blockchain’s and its participant’s legitimate interest in preserving the chain overrides the individual data subject’s right to deletion?

In connection with rectification, it is impossible to correct the data in a block, but a data controller could start a new block with the corrected data.  There needs to be careful consideration of how this can be implemented to ensure that the validation and verification of the original block carry over to the new block.

Automated processing

Under GDPR an individual has to be informed that automated processing is taking place and they have the right to human intervention or to challenge a decision.  An example is a situation where a program processes personal data to make an underwriting decision about a loan or insurance. Some commentators believe this right could impact how people use smart contracts if regulators believe that such contracts use automated processing in making decisions about individuals. However, this right does not apply if the processing is necessary for entering into, or performance of, a contract between the data subject and a data controller or is based on the data subject’s explicit consent. Developers of smart contract systems could build in mechanisms to ensure that these exceptions apply.

Handling data security and breaches

Blockchain technology is touted as a secure way of storing information through decentralization, cryptography, and consensus. One of the key elements of security is the use of hash cryptography, which is impossible to reverse engineer. The concept of public keys and private keys is core to security because you cannot take a public key and deduce the private one and without both you cannot access the underlying data. In addition, a fraudster cannot easily change input values because that creates an entirely new hash value and invalidates the whole block.

Yet, despite the inherently secure features of blockchains, they are not necessarily 100% secure. There is always a risk of a hacker trying to obtain control of more than 50% of the nodes (a 51% attack), although such attacks are difficult to mount and have not often succeeded. A bigger risk is how the blockchain interacts with other software or networks. For example, smart contracts rely on software code to automate the contracting process; if the software has a security flaw, hackers could infiltrate the smart contract and steal, alter, or divert wealth (or information).  If there is a centralized repository of data operated by a particular entity, such as a centralized exchange, hackers could try to exploit vulnerabilities or a single point of failure to gain access to significant digital assets.

Handling cross-border data transfers

GDPR provides that personal data can only be transferred to third countries that are deemed adequate by having the protections that are essentially equivalent to those in the European Union. (See GDPR Art. 45). Blockchain implementations due to their decentralized nature may result in personal data being transferred outside of the EU to jurisdictions that are not deemed adequate. In such a case, the controller must ensure that it has a legal basis to cover the cross-border data. That can include obtaining the consent of the data subject when they enter the data or establishing binding corporate rules or standard data protection clauses to cover transfers between different entities involved in the blockchain, such as the validators and miners, to ensure adequate protection for the personal data.

Stay tuned for part four, which will explain the steps to create a blockchain system that is complaint with data privacy laws.