• TREND MICRO
  • ABOUT
Search:
  • Latest Posts
  • Categories
    • Android
    • AWS
    • Azure
    • Cloud
    • Compliance
    • Critical Infrastructure
    • Cybercrime
    • Encryption
    • Financial Services
    • Government
    • Hacks
    • Healthcare
    • Internet of Everything
    • Malware
    • Microsoft
    • Mobile Security
    • Network
    • Privacy
    • Ransomware
    • Security
    • Social Media
    • Small Business
    • Targeted Attacks
    • Trend Spotlight
    • Virtualization
    • Vulnerabilities
    • Web Security
    • Zero Day Initiative
    • Industry News
  • Our Experts
    • Ed Cabrera
    • Rik Ferguson
    • Greg Young
    • Mark Nunnikhoven
    • Jon Clay
    • William “Bill” Malik
  • Research
Home   »   GDPR   »   GDPR vs Blockchain: Technology vs the Law

GDPR vs Blockchain: Technology vs the Law

  • Posted on:March 22, 2018
  • Posted in:GDPR, Policy, Security
  • Posted by:
    William "Bill" Malik (CISA VP Infrastructure Strategies)
0

One of the biggest impacts that GDPR will have for consumers (citizens of countries that comply with GDPR, at least) is the right to be forgotten. A person can request that they be removed from a record. What if the record is part of a blockchain? This poses a challenge for blockchain implementations. Blockchains are designed to last forever. Each block has a hash based on its contents, and carries the hash of its predecessor. So when you look at a block on a blockchain, you can trace the block back through its predecessors to the founding block. Changing the contents of a block changes the block’s hash. If a block’s hash changes, the successor blocks will no longer reference it. They point to the original, valid, block. Rebuilding the chain with the replacement block means the hash for each successive block will have to be recalculated, which is an enormous computational task. In Figure 1, we see part of a blockchain showing three blocks. Block 36 contains the hash for block 35, some data (DATA yyyyy) and its own brand new hash (HASH 36). Note that some of the data may include the identity of the creator of that data – the miner who computed the hash. If the data changes, the value of HASH 36 will change.

Subsequent blocks will not point to it.

Figure 1: Three blocks in a blockchain

For a distributed blockchain, the problem of modifying the chain becomes vastly more difficult. Not only will the hash for the changed block and all successive blocks have to be recalculated, but each copy of the blockchain will have to be replaced, on each machine it resides. Anyone who has ever sent an erroneous email to a group knows how hard it is to recall all those copies. Since blockchains are effectively indelible, any record containing personal information about an individual cannot be altered. Further, any individual who creates a block on a blockchain is affiliated with that block for the duration of the blockchain. In systems like bitcoin, miners use a pseudonym (usually generated using public key cryptography) to validate their authorship without revealing their identity. If that person is doxed, that is, if their real identity is revealed, that relationship is exposed for all transactions they participated in. Simply put, both the contents of a block, and the authorship of a block, are permanent.

Under GDPR, an organization that constructs a blockchain may have to remove a block or modify some data to comply with a request to forget someone. How would that work? To illustrate this problem, consider this bit of history. The popular mainframe database DB2 supported security around the use of ā€œviews,ā€ maps of the data used by applications. Each view requires an owner – a user on the system. Often this would be a particular individual’s user ID, with special permission granted to allow them to create or modify a view. Over time, the individual might move into a different job or leave the company. If that person’s ID were removed from the system, the view would no longer work. Businesses had to preserve these ā€œorphaned IDsā€ as long as the application using the view remained in production. This posed a problem for auditors in light of Sarbanes Oxley – each ID should have a known, authenticated user. When organizations deployed their Identity Management (IdM) tools, these orphaned IDs would flag as ā€œinvalid.ā€ The answer is to use synthetic identities. That is, instead of using an individual’s identity, create an indirect identity and maintain the association between that pseudo-ID and the real data subject separately and securely. Mining would be handled by ā€œCorp-ID Miner 031.ā€ If that individual wished to be forgotten, the organization would assign that pseudo-ID to another technical professional for mining.

A medical record would refer to ā€œCorp-ID Client 192734.ā€ If that person wished to be forgotten, the organization would re-assign that pseudo-ID to a null ID, eradicating the link from the person to the data. This example may help clarify this proposal. During the 1980s, I was custodian for some planning documents with IBM’s software development center in Poughkeepsie, NY. People in this job typically stayed for a year or two. Many other departments and labs across IBM needed information about elements of the plan, but constantly updating each potential correspondent with the email address of the new occupant of the role was tedious and unreliable. Rather, we had an email ID like ā€œMVS Lab Planā€ that was owned by whomever held that role, and their backup. Any inquiry about the plan would be directed to that ID, and whomever responded would provide the requested information (after authenticating the requestor). Just as today, when you want the police, you don’t look up the chief’s number, you dial 911 and the phone gets handled by a call center.

GDPR does not prohibit blockchain, but it does put some procedural requirements around blockchain’s use in commercial enterprises. For individuals who opt into a blockchain, there is no authority to amend or correct a block once it is incorporated into the chain. For them, caveat emptor. For organizations, make sure you have a mechanism that will allow you to disassociate an individual with their blockchain contributions, either as a miner or as a data subject. For a discussion of how blockchains work, see https://bitsonblocks.net/2016/02/29/a-gentle-introduction-to-immutability-of-blockchains/ and http://blockchain.mit.edu/how-blockchain-works/ Let me know what you think! Post your comments below, or follow me on Twitter: @WilliamMalikTM.

Related posts:

  1. What financial service providers should know about blockchain: Opportunities and threats
  2. State-of-the-art Security: The role of technology in the journey to GDPR compliance
  3. Mapping the Journey to GDPR Compliance: Who’s got the wheel?
  4. The GDPR is Coming: We Shed Light on What’s Still Not Working

Security Intelligence Blog

  • Our New Blog
  • How Unsecure gRPC Implementations Can Compromise APIs, Applications
  • XCSSET Mac Malware: Infects Xcode Projects, Performs UXSS Attack on Safari, Other Browsers, Leverages Zero-day Exploits

Featured Authors

Ed Cabrera (Chief Cybersecurity Officer)
Ed Cabrera (Chief Cybersecurity Officer)
  • Ransomware is Still a Blight on Business
Greg Young (Vice President for Cybersecurity)
Greg Young (Vice President for Cybersecurity)
  • Not Just Good Security Products, But a Good Partner
Jon Clay (Global Threat Communications)
Jon Clay (Global Threat Communications)
  • This Week in Security News: Ransomware Gang is Raking in Tens of Millions of Dollars and Microsoft Patch Tuesday Update Fixes 17 Critical Bugs
Mark Nunnikhoven (Vice President, Cloud Research)
Mark Nunnikhoven (Vice President, Cloud Research)
  • Twitter Hacked in Bitcoin Scam
Rik Ferguson (VP, Security Research)
Rik Ferguson (VP, Security Research)
  • The Sky Has Already Fallen (you just haven’t seen the alert yet)
William
William "Bill" Malik (CISA VP Infrastructure Strategies)
  • Black Hat Trip Report – Trend Micro

Follow Us

Trend Micro In The News

  • Trend Micro Transforms Channel Program to Advance Cloud Security and Services
  • Exceptional Attack Protection Proven in Rigorous MITRE Engenuity ATT&CKĀ® Evaluations
  • Trend Micro Offerings Are FedRAMP Authorized and Available on AWS
  • Fujitsu and Trend Micro Demonstrate Solution To Secure Private 5G
  • Trend Micro Receives 5-Star Rating in 2021 CRNĀ® Partner Program Guide
  • Home and Home Office
  • |
  • For Business
  • |
  • Security Intelligence
  • |
  • About Trend Micro
  • Asia Pacific Region (APAC): Australia / New Zealand, 中国, ę—„ęœ¬, ėŒ€ķ•œėÆ¼źµ­, å°ē£
  • Latin America Region (LAR): Brasil, MĆ©xico
  • North America Region (NABU): United States, Canada
  • Europe, Middle East, & Africa Region (EMEA): France, Deutschland / Ɩsterreich / Schweiz, Italia, Š Š¾ŃŃŠøŃ, EspaƱa, United Kingdom / Ireland
  • Privacy Statement
  • Legal Policies
  • Copyright © 2017 Trend Micro Incorporated. All rights reserved.