Brands
Discover
Events
Newsletter
More

Follow Us

twitterfacebookinstagramyoutube
Youtstory

Brands

Resources

Stories

General

In-Depth

Announcement

Reports

News

Funding

Startup Sectors

Women in tech

Sportstech

Agritech

E-Commerce

Education

Lifestyle

Entertainment

Art & Culture

Travel & Leisure

Curtain Raiser

Wine and Food

YSTV

ADVERTISEMENT
Advertise with us

Blockchain and the Personal Data Protection Bill: Technical and Compliance Perspectives

Second in an ongoing series, this article dives into the co-existence of the blockchain with the proposed Indian data privacy law.

Kartik Mandaville

Dhruv Sharma

Blockchain and the Personal Data Protection Bill: Technical and Compliance Perspectives

Tuesday October 06, 2020 , 9 min Read

Introduction and context

It has become almost customary to start a conversation on the governance of emerging technologies by highlighting a phenomenon called the ‘pacing problem’ – that innovation outpaces regulation (or legislation) – for which author Larry Downes has a succinct explanation – technology changes exponentially, but social, economic and legal systems change incrementally.


In some sense, both blockchain and PDP were conceived to let individuals exercise greater autonomy and control over their data – but from opposite ends of the spectrum. Blockchain uses advanced cryptography and consensus algorithms to obviate the need for intermediaries or centralised authorities to secure transactions.


PDP, on the other hand, relies on a framework with rights, obligations, centralised authority, and a linear understanding of data collection and management, to extend to individuals a higher degree of control over the processing of their personal data.


The contrarian argument paints the inherently tamper-proof nature of blockchain databases as antithetical and incompatible with individual rights of data protection and privacy – which is not necessarily an enlightened view.


This article attempts to deconstruct why blockchain, an innovative technology and the PDP Bill, a progressive legislative reform – ostensibly designed with similar implicit objectives – seem to be at odds with each other. And why being solution-oriented might be the best way forward.

Blockchain and PDP: Points of dissonance

So what are the challenges?


First, identifying data fiduciaries and data processors in a blockchain network.


A public permissionless blockchain network is distributed and egalitarian in that each node in the network participates equally and anonymously in a given transaction. Network governance is devoid of hierarchy as no single node acts as a central point of control or failure (Disclosure: SpringRole is a public permissionless blockchain and the basis of our view on this subject).


However, the PDP governance model is different. The compliance burden on an entity depends on its role with respect to data processing activities. In fact, the bulk of the liability rests with data fiduciaries and data processors (see the first post in this series for more information). The challenge from a compliance perspective is in seeing blockchain actors in a PDP mould – who is the data fiduciary, data processor, data principal and so on.





According to one view, nodes that have the right to append data to the blockchain, and send data to other participants for validation are data fiduciaries; participating nodes that can only assess and validate information submitted by fiduciaries are data processors. But this view is yet to be endorsed by Indian authorities.


Second, reconciling transaction immutability with individuals’ rights.


The PDP Bill grants data principals the right to access, modify, correct, and port their data. It also imposes obligations that mandate the erasure of data once the purpose of processing it has been achieved or if the data principal has withdrawn consent.


The right to confirmation and access and the right to data portability can be met – although the data itself is encrypted, each node in a public permissionless network has the authority to access it, and as the data is machine-readable, it satisfies portability.


The real challenge lies with data modification, rectification and erasure. For one thing, as mentioned above, if the PDP roles of blockchain nodes are not clear, who should individuals direct their rectification or erasure requests to? But more importantly, after being ordered and timestamped by the chain’s consensus algorithm, blockchain transactions are replicated across every node and stored permanently in a tamper-proof way.


To rectify inaccurate data or delete sensitive data, in theory, the owner of the transaction would have to rewrite and Rehash Technologiesthe block (read about hashing), then rehash the corresponding block to obtain a match. Then repeat the process over and over till the end of the chain. In practice, this could be a computational nightmare (we discuss an alternative called chameleon hashes in the next section).


Third, adhering to concepts like purpose limitation, storage limitation, and data minimisation.


The PDP Bill and other privacy laws were brought in to empower individuals to regain control of their personal data from central authorities – such authorities do not exist in a blockchain network.


In the blockchain, transaction data is replicated, stored, and verified from node-to-node. While the validator node or block creator might have a lawful basis for collecting data and appending it to the ledger, other nodes may hold on to a read-only copy after verifying a transaction for no purpose other than network participation – a technical violation of the purpose limitation principle.


Similarly, blockchain’s inherent nature of storing data permanently in a tamper-proof way runs counter to the principle of storage limitation that prohibits data retention beyond a stipulated period of time.


And while the validator node might adhere to the principle of data minimisation, the automatic replication of data across nodes (meant to reinforce immutability) can vitiate the principle shortly after data collection.

Technical solutions and workarounds

There is no denying the fact that the co-existence of blockchain and PDP throws up numerous challenges. But many of the high-level challenges have already been overcome by innovators somewhere in the world. And second-order innovation is currently underway to meet challenges that remain.

Irreversible Encryption or Hashing

Best thought of as a one-way transformation of original data to something unintelligible – such that even if a service has access to some personal data, e.g., payment information, it can no longer be attributed to an individual and hence, to the service, the data is pseudonymised. Not a foolproof or standalone solution but definitely an important tool in the toolkit.

Deletion of Encryption Keys

A lacklustre but perhaps practical method of shoring up traditional encryption is to respond to a data erasure request by deleting the encryption keys – a process that renders the hashed personal data irretrievable and unusable by reducing it to an indecipherable string. Though this method comes close to complete erasure, critics worry about malicious nodes that may have copied the data previously.

Fine-grained Access Control

Smart contracts have been explored for capability-based access control in private permissioned blockchain networks – an individual may grant or withdraw consent to specific nodes to access specific temporal fragments of data for a pre-set duration of time.

Self-sovereign Identity (SSI)

A subset of decentralised identity, SSI is deeply focused on privacy-preservation and user-centricity, and allows individuals to present ‘verifiable credentials’ as opposed to granular personal data. As an example, online purchase and delivery of liquor require an individual to prove that they are of legal drinking age.


Instead of sharing a copy of their driver’s license or passport for age verification – which would also expose their name, address and other personal details – SSI allows patrons to create and share ‘verifiable credentials’ that simply prove that they are of legal drinking age without getting into specific and ‘linkable’ details like date of birth, etc. (an illustration of the principle of data minimisation).

Chameleon Hashes:

Perhaps the most defensible counter to immutability came from within the blockchain community when Accenture published its research on Chameleon Hashes – configuring the chain in a manner that retroactive block substitution can occur if a majority of authorised network participants approve it.


The solution was originally conceived for enterprise blockchains, hence the emphasis on the word authorised. The simplest explanation is that a chameleon hash key allows the problematic block to be retrieved and amended without altering the corresponding block’s hash or breaking a link in the chain.

Zero-Knowledge Proofs (ZKPs)

First conceptualised in 1985, ZKP is a cryptographic technique that seems counterintuitive to basic blockchain tenets but can be used by two parties (a prover and verifier) to generate consensus on something without exchanging specific data or transactional information. Think about how one can get FedEx to agree to carry a package without opening it to see what is inside. Thus, ZKP maintains the privacy of users’ sensitive information while executing a blockchain transaction even without encryption.

Pruning and Forking

Pruning is a technique used in situations where historical blocks of data are deleted once they have outlived their utility, primarily as a means of creating additional local storage. Similarly, in situations where data has to be modified, a technique called forking is used to edit data, change the hash and create a new ‘fork’. Both pruning and forking can require huge amounts of computing consensus over a public blockchain.

Conclusion

When policymakers and legislators started thinking about data privacy laws worldwide, blockchain was probably not on their radar.


As ambitious and wide-scoped as privacy laws tend to be, the fact that they are meant to rein in everything from social media giants to internet search companies can be a fait accompli for emerging technologies like blockchain.


There is no doubt that certain blockchain features offer the best possible solutions to privacy concerns – cryptographic encryption and node-to-node verification of data integrity. But the non-hierarchical structure of the network and transaction immutability make it difficult to reconcile blockchain with current data privacy laws.


There are no elegant solutions and silver bullets. But there are myriad workarounds and an innovation window that is wide open. Perhaps what we need next is a sandbox. Regulators, we hope you are listening.


References and additional reading


  1. The Personal Data Protection Bill, 2019
  2. What happens when technology is faster than the law? (2016)
  3. The Tension Between GDPR and Blockchain (2019)
  4. Blockchain and Data Privacy an Indian perspective (2020)
  5. Analysis of the main consensus protocols of blockchain (2019)
  6. Solutions for a responsible use of the blockchain in the context of personal data (2018)
  7. The Blockchain - Nishith Desai Associates (2018)
  8. Analysis of Data Management in Blockchain-based Systems (2019)
  9. Blockchain Technology: Data Privacy Issues and Potential Mitigation Strategies (2019)
  10. Introduction to the Hash Function as a Data Pseudonymisation Technique (2019)
  11. Reconciling GDPR rights to Erasure and Rectification of Personal Data with Blockchain (2018)
  12. Erasing Data from Blockchain Nodes (2019)
  13. Managing Consent to Data Access Using Permissioned Blockchains (2020)
  14. Why distributed ledger technology must adapt to an imperfect world (2016)
  15. ZKPs or Zero Knowledge Proofs Are Evolving Blockchains (2019)
  16. GDPR Paper - Sovrin (2020)


Please Note: The views expressed here are for informational purposes only, and should not be relied upon as legal or business advice. You should consult your own advisors as to those matters. Certain information contained here has been obtained from third-party sources. While taken from sources believed to be reliable, Springworks makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. The content speaks only as of the date indicated. Any opinions expressed in this material are subject to change without notice and may differ or be contrary to opinions expressed by others.

(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)