Blockchain vs. GDPR

Bad news: there are fundamental conflicts between blockchain, at least in its original form, and data privacy regulations like GDPR. Good news: these conflicts provide a good opportunity to learn about what is actually contained in both.

The core property of blockchain that is novel and has been important for non-scam applications is immutability. If you have a network that is working properly, a bit of information you put on the blockchain will stay there unchanged. You will not be able to take it back, and no one else will be able to tamper with it either. This was important for the prototypical blockchain application, cryptocurrency, as it was necessary to hold people’s feet to the fire regarding their transactions - if I can change or retract what I put on the blockchain, I can undo my spending after I have run off with the goods and then double-spend my coins.

A few newer brands of blockchain (EOS comes to mind) have methods for retracting transactions, but these are controversial. For human and technical reasons, take-backsies on blockchain transactions may always range from slow and difficult to impossible.

On the GDPR side, a key privacy provision is the right to be forgotten - you can write to Google or Facebook and tell them to delete all the information they have about you. This clause has proven influential and has been incorporated into newer laws like California’s CCPA, and it will likely be imitated again in the future. From a concrete information technology standpoint, forgetting someone means going into your database to delete all the records related to them and their relationship with your business. A blockchain is really just an immutable database, so if you are using a blockchain in your technology stack right to be forgotten vs. immutability is a real headache. Immutability is explicitly a “real pain-in-the-ass to delete things” property, and this is a problem if you are legally required to delete things on request.

There are some things that can be done to mitigate these problems but at the end of the day it is actually the essential, novel property of blockchains that is the problem.

What is(n't) blockchain to infosec? Part One: Blockchain is Immutability

The central, novel property of blockchain is immutability.  This means that records can not be changed once they are accepted, and implicit here also is that records receive a timestamp that can not be changed once it is agreed.  Immutability was key to the success of the Bitcoin network as it guaranteed there would be no tampering with the older sections of the ledger.  Immutability is also the property by which blockchain can offer something genuinely new to information security, but to see clearly how this works we should first examine some basic concepts in cryptography and blockchain architecture.

The mysticism around blockchain imagines it as being everywhere and nowhere, but a blockchain is tangibly a group of databases on a number of different computers, commonly called nodes, communicating constantly via a cryptographic protocol in order to make sure they are all keeping records in the same way.  This protocol isn't really an innovation in cryptography in the pure sense, but really a bunch of old ingredients linked together including a very common ingredient called a cryptographic hash function.  Informally, the important properties of these hash functions are that 1) they are easy to compute, but very difficult to invert, 2) their output depends chaotically on every little bit of input, and 3) they (hopefully almost) never produce the same output given two inputs.  If I give you an output from a hash function, you are going to have a hell of a time finding an input that produces this output unless I give you mine.

So thus far we have databases sharing cryptographic information to try and stay on the same page.  This could be a big headache if we are working with a lot of data, and this is where the blocks, their arrangement in a chain, and our hash function get put to work.  All the data goes into blocks as we get it, and we put the data of the n-1 -th block into a hash function and include this output in the n -th block.  Because of property 2) listed above, this means that any change in a block will radically change all the hashes appearing in all later blocks, while properties 1) and 3) make it extremely difficult to cheat and come up with new, fake blocks that prevent these radical changes.  Thus, the efforts of our many databases to stay on the same page need focus on the most recent block as any violation of prior consensus will upset the hash appearing in this most recent block.  This resistance to changes in prior consensus, which we previously called immutability, is what makes the whole enterprise workable, both computationally and on level of human trust.  

Immutability is useful in information security because it guarantees tamper resistance.  We might want to ensure that malicious actors are not doctoring our records towards their own ends, and the transmission of hashes from one block to the next ensures that this is very difficult or impossible.  But...in the blockchain context immutability depends on the  collaboration of the nodes of our network and their consensus process.  The role played by this consensus process, and how the consensus process determines what blockchain can and can't do for information security, will be the topic of the next post in this series.