The steps to making blockchain compliant with data privacy

This is part four of a series analyzing blockchain technology and its role with modern privacy laws. Click here for part three, here for part two and here for part one.

Designers and operators of blockchain networks and technologies will need to be creative and flexible when designing such systems to ensure compliance with these data privacy requirements. While there are a number of open questions and uncertainties about the application of those laws, the following are steps that can be taken to mitigate risk and maximize compliance.

Data privacy by design

GDPR imposes an obligation of data privacy by design, which requires controllers to "implement appropriate technical and organizational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimization, 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." GDPR Art. 25, § 1. Blockchain providers should consider conducting data protection impact assessments under GDPR to assess what data is necessary to the function of the blockchain and steps that can be taken to mitigate risk to individuals.

In following these principles of data privacy by design, developers and operators of blockchain should consider the following:

• Can the blockchain be designed to accommodate and be compatible with the data protection principles of GDPR, CCPA, and other data protection laws? This is going to more easily achieved in a private permission-based system than a public permissionless blockchain.
• Consider and limit the types of data that can be uploaded to the blockchain. There are ways to structure the blockchain to minimize the data to that which is necessary to the blockchain’s function. Evidence that data minimization was considered will be important to regulators examining such systems.
• Consider anonymizing the data that is being stored. If data is anonymized, it is not subject to GDPR or CCPA (or most other data privacy laws). The challenge is ensuring that the data cannot be reasonably linked to an individual, and the process of anonymization must be irreversible.
• Another approach is pseudonymizing data: this is the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information. While pseudonymized data is still subject to GDPR, it can mitigate risk and give data controllers more flexibility. For example, pseudonymized data is recognized as a form of data privacy by design, can be used for purposes beyond the original purpose of collecting the underlying personal data, and is not subject to data subject requests.
• CNIL noted two basic types of data that are stored on blockchains: (a) the identifiers of participants and miners in the form of public and private keys, which are always visible as they are essential to the functioning of the blockchain and (b) the additional data (or payload) stored on the blockchain. CNIL recommends that the personal data registered on the blockchain be limited to a "commitment" that "freezes" the data by using a hash function with a key or some other form of encryption. One solution is to store the corresponding personal data outside of the blockchain and to store on the blockchain only the "commitment," the hash generated by the keyed hash function or ciphertext.

However, CNIL indicates that if this solution cannot be accomplished, data can be stored on the blockchain using a hash function without a key or in clear text, as long as a DPIA has been conducted that justifies the processing and shows that the residual risks to storing data in this manner are acceptable.

Establishing a governance system

Given the distributed and decentralized nature of blockchains and distributed ledgers, and the lack of clear guidance regarding the application of privacy laws to these technologies, a prudent approach is to develop a governance system at the outset that clearly defines the roles of the participants, creates GDPR-compliant agreements (including as necessary cross-border agreements with standard contractual clauses) between controllers and processors in the structure, and specifies the rules for what data can be uploaded, the purposes for processing that data, and who is responsible for data subject requests and data security breaches. This is much more easily done in a private permission-based system.

The quandary of data deletion

The one area that is not easily resolved is data deletion, given that it is seemingly inconsistent with the immutable character of blockchains and distributed ledgers. CNIL has observed that certain techniques could be considered data erasure even if technically some data remains on the blockchain: (1) removing certain elements from the commitment such that it can no longer verify which information has been committed or (2) deleting the hash function's secret key.

In both cases, the confidentiality risk could be considered sufficiently mitigated to satisfy the erasure requirement, provided that data is also deleted from other systems where it has been stored for processing. CNIL notes, however, that erasure is not possible when the cleartext or hashed data is recorded on a blockchain; for this reason, CNIL recommends that such data not be stored on the blockchain but that cryptographic solutions be used.

The need for regulatory guidance and clarification

More regulatory guidance and industry consensus is needed to ensure continued innovation and implementation of blockchain technologies while simultaneously providing adequate protection to individuals’ data privacy rights. Data privacy laws should not be static or rigid but should be flexible enough to evolve with the rapidly changing technological landscape and not stifle innovation. Regulators and industry should work together to develop solutions to address (a) proper data governance, (b) data minimization and security, and (c) data subject requests, including how to solve the data deletion quandary.