- E-mile: support@alocyber.com
- 1603 Capitol Ave, Suite 310, PMB #A419, Cheyenne, WY, 82001, USA
- +1 (830) 584-1142
The content of this post is solely the responsibility of the author. AT&T does not adopt or endorse any of the views, positions, or information provided by the author in this article.
Blockchain has been outlined as a digital, decentralized ledger that keeps a record of all transactions that present itself across a peer-to-peer network. It permits the secure transfer of assets while not being an associate mediator. It conjointly provides a record of transactions that’s absolutely clear and displayed in time period for the good thing about participants.
GDPR is a law that protects data/Information security, promotes a lot of management over a person’s individual data and information on digital platforms. Blockchain, on the opposite hand, is a technology that develops unvarying rransaction ledgers.
The interaction between GDPR’s data privacy rights and therefore the idea of blockchain serving as a decentralized, incorrupt digital junction have led to varied takes on classic philosophical conflicts.
GDPR is a General information Protection Regulation that was adopted as a law in the EU. The purpose of the law is to cater to the requirements of information privacy of an individual.
The law offers rights to the users, that include:
The governance parties can decide with certain conditions that the specific transaction will occur in blockchain or not.
In order to fully understand the blockchain & data privacy (GDPR), one needs to understand the difference between CRUD & CRAB. Many tech professionals call the process CRAB (An alternative of the term CRUD) – CRUD (For traditional databases) stands for Create, Read, Update & Delete.
The term CRAB stands for Create, Retrieve, Append & Burn. The burn is the method of deleting encryption keys.
Keeping private data/information “off the chain, instead of on the chain” is the one obvious solution. As the blockchain info is “on the chain”, deleting & redaction info is sort of not possible.
Developing a closed blockchain is another solution. In a closed (permission-based) blockchain, information is stored on local devices or rented cloud storage. So it is relatively easier to delete personal data on an individual’s request using the process called forking.
Now, because there is no definition in GDPR of “erasure of data” at this point for blockchain, you probably need to interpret this as meaning that throwing away your encryption keys for blockchain technology, isn’t acceptable as ‘erasure of data’ in line with GDPR.
Storing private data on a blockchain is not an option per GDPR policies. A good option to get around this issue is a really simple one: You store the private data off-chain & store the reference to this data (along with a hash of this information and alternative data like claims and permissions regarding this data) on the blockchain.
This workaround will increase the complexity of fetching and storing information on a blockchain. Now, let’s cover the pro’s and con’s of this approach.
The pros:
The approach described above is a 100% GDPR compliant solution, which makes it possible to completely erase data in the off-chain storage. Therefore, rendering the links & hashes on the blockchain is utterly useless.
In this situation, you use the blockchain primarily as an ‘access control’ medium, wherever claims are publicly verifiable. This would be able to provide somebody the suggestions to prove that some node mustn’t store the information once an opt-out is chosen. This benefit may also be present if private data was kept on a blockchain.
The cons:
Transparency with blockchain is reduced. By storing your information off-chain, you have got no method of knowing who has accessed your information, and who has access to your information. Once any company has the link to retrieve the info, they’re not bound to access anything.
Data ownership with blockchain is also reduced. Once your information has been kept off-chain, who owns it? The information owner has all the encryption keys to administer his data.
It would be desirable to have a point-to-point integration between all the collaborating parties. When obtaining the link from the blockchain, you wish to share information from A Company to B company. For each new party supplemental to the system, you may have to be compelled to add new point-to-point integrations with every existing member as provision of a secure PKI.
This may mean more attack vectors. Every company has their own infrastructure and application landscape. By spreading private information over these totally different corporations, the risk will increase for a possible breach where information can be stolen.
But here is the conflict: The goal of GDPR is to “give users back the management of their personal information, while imposing strict rules on those hosting and ‘processing’ this data, anyplace within the world.” Also, GDPR states is that data “should be erasable”. Since abandoning your cryptography keys isn’t identical to ‘erasure of data’, GDPR prohibits the world from storing personal data on a blockchain level.
This removes the power to reinforce management over your personal data. Now, I know that sounded harsh. And in defence of GDPR, you could optimize the proposed solution above to counter some disadvantages. Or select a very totally different resolution than the one represented to tackle the issue of close immutability of transactions. However, no matter the resolution you’re going with, more complexity can still be a significant disadvantage.
With blockchain technologies being used in many ways, we’ve got new ways to strengthen data ownership, transparency, and trust between entities (to name a few). The way GDPR is written, we have a tendency to not store personal data directly on the blockchain since in GDPR terms ‘it isn’t erasable’. This prohibits the world from using this technology to its full potential, therefore we want to think about ‘older’ systems for storing data that simply will not guarantee the same advantages as most blockchain technologies: who owns (the data|the information) in your off-chain storage? Is the off-chain data even encrypted? Who can access this data? Wherever is it stored? Is it already copied to alternative systems?