In the prior post, I explored how blockchain stores personal information on an immutable ledger and cannot be modified or erased to meet GDPR requirements. In this post, I'll discuss strategies available to blockchain operators to help manage risks posed by GDPR.

Forking. It is technically possible to rewrite the data held on a blockchain, but only if most of the nodes collectively agree to create a new version of the blockchain (a "fork") that includes the changes and continue using that version instead of the original one.

That’s seismic and hardly possible to do on a public blockchain, but relatively easy on a private blockchain (a closed "permissioned" system).

If the nodes agree to delete personal data relating to a certain individual from the preceding block, they can simply update the links by re-hashing the blocks. However, if nodes can change the data on the blockchain, its integrity can no longer be independently verified. This defeats the whole point of using blockchain in the first place. More importantly, not all nodes but most of the nodes are enough for a successful fork to happen. There is always a risk that some of them will not delete the personal data in the end, therefore, GDPR compliance cannot be guaranteed.

Encryption. Each entry on the blockchain gets encrypted with its own key pair. In this way, only the encrypted cipher text will be stored on the chain. Instead of deleting this text, only the associated key is deleted when it is requested by the data subject.

However, this technique doesn’t solve the GDPR challenge. Under the Article 4, both the encrypted text and the key(s) qualify as personal data.

As the cipher text remains on the blockchain and is simply rendered inaccessible by destroying the key, this does not qualify as having been deleted. Moreover, this approach bears extra risks associated with the key: what if it is compromised in a security breach before the request for deletion comes in?

Hybrid off-chain solutions. Some commentators claim to solve GDPR-blockchain paradox by separating the personal data from the chain. In this case, the personal data is stored in a traditional database where it can be erased and access restricted, and the owner of the database remains the data controller.

The primary technique to achieve this is called "hashing." The data in and of itself is not stored on the blockchain -- instead, a cryptographic hash is derived from the data and is then uploaded. When the personal data gets deleted from the off-chain storage, there is only a hash left on the blockchain. Meanwhile, hashing can be used to verify that data on a chain has, or has not, been modified or erased -- because any altered data would result in a different hash.

It would be possible to figure out that the original data still exists by comparing the hashes. In this sense, a hash would qualify as personal data under Article 4, as long as it could be linked to an individual and traced across a distributed system, even if the original data is rendered inaccessible. Anyone who has the input data could run it through the same hash function and associate the hash remaining on the blockchain with the underlying individual.

To solve this problem and complicate things even further, some commentators suggest a cryptographic solution called "peppering" when randomly generated secret (a "pepper") is added to the input data prior to being hashed with a hash function. Because of the additional computational effort, a pepper would make it harder to link the on-chain hash to the individual. However, it would still be possible. The point stays -- "peppered" hashes would still qualify as personal data.

___

This is a non-exhaustive list of methods companies resort to in order to mitigate the risk of GDPR violations. They continue to appear under different names, however, the underlying techniques stay the same.

In terms of the data storage, these methods primarily rely on encryption and hashing which, however, do not entail data anonymity but only pseudonymity. Under Article 4(5), "pseudonymization" means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organizational measures to ensure that the personal data are not attributed to an identified or identifiable natural person. In other words, the personal data stored on a blockchain, whether in plain text, encrypted form or after having undergone a hashing process, as well as public keys qualify as personal data under the GDPR.

Apparently, the current solutions to the GDPR-blockchain paradox have major drawbacks.

First, although they claim to solve it, in fact, they don’t. The personal data is not being deleted, it is obfuscated. Instead of rendering the data inaccessible a far better approach would be to understand that in certain situations the right to erasure can be waived. Indeed, under Article 17(3) and Article 23, there are cases including KYC and AML compliance when keeping the records of transactions is required and, therefore, the right to erasure does not apply.

Second, they increase complexity, costs and invite many compatibility issues. Replacing the former clarity of data storage and processing with a tangle of often obscure, complex, competing systems doesn’t sound like a good idea.

This complexity may become a deterrent to regulatory audits and investigations, making fraud and misbehavior not easier, but harder to detect. This is a critical issue that requires attention from regulators, especially in the financial services industry.

Finally, the GDPR-compliance strategies developed so far go against all the principles that blockchain originally stood for -- decentralization, transparency, and immutability. If blockchain cannot guarantee decentralization and immutability, does it still have any value?

____

Vera Cherepanova, FCCA, CIA, MSc (pictured above), has more than 10 years' experience as a compliance officer. She's the founder of Studio Etica, a boutique consultancy that provides advice on corporate ethics and compliance programs to companies around the world. She speaks English, French, Italian, and Russian. She can be contacted here.

Article originally appeared on The FCPA Blog (http://www.fcpablog.com/).