blockchain

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.

The slow, alienated death of blockchain

As a preface to this, there are good people doing great things with blockchain in good faith and this is not an essay targeting these people but a polemic in their defense. There are too many people, though, lost in fog about what blockchain is and not enough people telling the truth about what it is not.

It would be crazy to say you won’t hear about blockchain again, and perhaps the worst blockchain fatigue is ahead of us. Rather, we have arrived at an inflection point where the emerging viral big idea is that blockchain has lost its way, been applied to problems for which it has no utility, carelessly dropped as a buzzword with no meaning, incorporated into all manner of scams, not only over-hyped but radically mis-hyped, and warped by these trends into something that will now struggle to fulfill its original real potential.

The amazing power of blockchain has been its power purely as a word - a word about which one can say anything, arbitrarily disingenuous or poorly informed, and profit from the statement presuming the claim is sufficiently grandiose, intimidating, and FOMO-inducing. There is apparently vast power for “disruption” in using blockchain to record supply chain information where a centralized server would be demonstrably superior. Apparently, blockchain has a unique relationship with quantum computing despite being composed of very conventional classical cryptography. Apparently, blockchain can save your business by “decentralizing” when your business was really an effort at centralization by its very nature and no one can even explain in plain English what decentralization means and why it is good business. Apparently, blockchain can hugely improve your information security by reproducing your sensitive data across many servers each with the same vulnerabilities as any other centralized server. By etymology, to say something is apparent suggests it has appeared, but we are still waiting and we will continue to wait forever because these claims range from optimistic distortions to outright lies.

There are a great many lies that have become so pervasive that they have been widely repeated by honest people. This is a real tragedy, and this essay is not a polemic targeting these people but a polemic in their defense.

Blockchain came into the world in step with “decentralization” and if we actually maintain discipline about what these words mean, this is absolutely sensible and correct. The problem is much of the wealth and power in our society is centralized and the power of blockchain as a word is too useful a tool in chasing it. Corporations are centralized organizations - decentralization is what the Department of Justice does to your firm if it decides you don’t have enough competition to treat consumers decently. Governments are centralized organizations - decentralization is what happens when people decide they’ve had enough and find ways to be governed less and more locally. Venture capital firms are centralized organizations - if you take the money of a group of wealthy investors and centralize it one place to invest all at once, you’re on the way to founding a venture capital firm. One can’t say that blockchain will never have anything to offer these groups, but many promises made could never have been anything but empty because decentralization is contrary to the nature of these organizations. And neither centralization nor decentralization is intrinsically good or bad.

Too many organizations have been presented with blockchain the magical spell, the voodoo word for inciting fear of falling behind the times and missing out. Blockchain has been presented to many in bad faith not as information technology but as psychological manipulation. It is well attested the companies that have merely added blockchain to their name have seen their stock price soar, in some cases criminally (in the literal sense) absent any effort to implement any version of the real technology at all. Any application you might pitch to an investor that involves a database might as well involve a blockchain, and such is the power of the word that many can’t resist. But why did your application need to be on the blockchain? It didn’t, and it may have been a poor architecture decision that it was.

Experimentation in blockchain architecture continues, and while much of it is interesting and valuable, there is a sector that strongly resembles efforts to find a centralized server that resembles a blockchain enough to avoid lawsuits. Why be bothered to work with the challenging, real technology when one can work with the awesome persuasive power of the word alone?

Blockchain is not dying in the sense that it will disappear tomorrow. It is dying in the sense that it is mutating carelessly towards no constructive end, wasting time and money and human intellect and human emotion as it does. The real tragedy is that it is dying not because it has no potential but because no one can resist the potential it does not have.

What is(n't) blockchain to infosec? Part Three: Not quantum at all

Blockchain is often presented as a solution to the problems that quantum computing will pose for cryptography and these claims are false.  Blockchain has no particular relationship to quantum computing whatsoever.  Some very brief backstory: encryption methods are invariably built on a  math problem that is believed to be difficult and quantum computers are a sophisticated new technology that promises to make some of these math problems less difficult.  Although there is considerable propaganda out there to the contrary, blockchain is built on top of the same cryptographic techniques as everything else, it will be compromised by quantum computing like everything else, and if it gets patched up it will likely be in the same way as everything else.

As we discussed briefly in Part One, blockchain is not an innovation in cryptography per se but a distributed program built with heavy use of existing cryptography.  Notably, blockchain makes heavy use of cryptographic hash functions and asymmetric (public and private) key encryption.  Any frequent user of a cryptocurrency is implicitly familiar with the latter as it is important to keep track of one's private keys, which essentially give ownership of accounts with currency, while the corresponding public keys represent one's identity on the ledger.  The public vs. private key algorithms used in most blockchains are not unique at all but are well-tested algorithms, even down to the level of particular implementations, that are applied many other places.

It is the public vs. private key algorithms that are threatened by quantum cryptography and as blockchain is using the same algorithms it is also threatened.  It is well beyond the scope of this post to give the details of how quantum computing works, but for those readers who want to do their own Googling we will hit some of the high points.  Asymmetric key cryptography is typically built around some form of a type of math problem, the discrete logarithm problem, which involves certain computations that are efficient in one direction but very difficult to invert.  The security of the cipher is dependent on this difficulty, and the danger of quantum computing is that it allows new algorithms that make this inversion much easier.

For the moment, though, there is no danger.  The engineering difficulty around building a practical quantum computer is vast and existing (extraordinarily expensive) prototypes contain just a few quantum-analog logic gates.  Even as they improve, there will be a long period where very few actors have real access to them - they will be a sort of cryptographic nuclear weapon.  There are also new cryptographic techniques, notably lattice-based cryptography, that may prove more resistant to quantum attacks.  Blockchain's could easily be fixed by swapping in these new parts, but it would be the new components resisting quantum cryptography and not any aspect of the blockchain algorithm itself.

To recap, blockchain has nothing to do with quantum computing and won't do anything on its own to protect you from quantum attacks.  Next in Part Four, I will talk about how blockchain doesn't do anything itself to protect your data from theft and rather presents significant new liabilities.

What is(n't) blockchain to infosec? Part Two: Consensus, but maybe not what you wanted.

An important part of a blockchain is the process by which the nodes come to an agreement about what to add to the ledger - you might call this a consensus process.  This consensus process has implicitly gotten a lot of attention, both in the abstract context of the "Byzantine general's" problem and for it's application in business settings.  Unfortunately, much of this attention is not justified by the reality of the algorithm.

The core of the consensus algorithm, the part that actually makes a decision per se, is a simple, familiar majority vote.  If 51% of the nodes agree that the next block in the chain should look a particular way, that is the consensus verdict.  The 51% number gives it's name to the "51% percent attack" where a sufficiently large (51% or more) group of nodes ("miners" in the cryptocurrency context) can make the blockchain ledger anything they want, and this attack is thus often discuss in the context of centralization in cryptocurrency mining.  That there is danger in too much friendliness between nodes is a point we will visit again.

The original blockchain architecture hardens its consensus process by making suggesting a new block expensive, originally via the "proof-of-work" concept.  To submit a new block, a node must also solve a computationally expensive (and notably, totally useless otherwise) cryptographic problem.  This deters bad guys who might set up malicious nodes, as running nodes is expensive and running enough nodes to approach the 51% number is extremely expensive.

An important subtext in these last two paragraphs is that we hope our nodes distrust each other.  We hope they can't collude and that the are checking each other's "proof-of-work" homework.  Blockchain is not quite the "trustless" innovation advertised, but something powered by distrust.

Elsewhere, you can find a lot of skeptical commentary on "private" blockchains and it all relates to the distrust issue discussed above.  If you are trying to run a blockchain inside a single business, it is liability that your nodes might be run by people who all work for the same people and drink together after work.  You might be running an expensive, from a computational standpoint, architecture that really is just a simple majority vote without the distrust among nodes that makes it work.  Much of the interest in blockchain from large businesses revolves around it's functionality as a consensus process, but it is not a very good consensus process if implemented inside a single business.

Blockchain is also not the comprehensive solution to the "Byzantine general's problem" (a landmark type of problem in network communication) that it is sometimes proclaimed to be.  We have seen above that it requires a specific sort of human context to work appropriately.  It also has more subtle problems, too subtle to discuss here but embodied in debacles like the $70 million DAO hack.  The short story is this hack exploited confusion about just which nodes had what information and when, and this the essence of the problem facing the Byzantine generals.

Thus, blockchain is in part an interesting and novel consensus process, but this consensus process depends on human context and has technical limitations.  Commentary on blockchain is often hagiographic and careless with both of these. 

In Part One, we talked about what blockchain definitely offers: immutability.  Here in Part Two, we talked about what blockchain is and isn't on its own: a consensus protocol.  In the following installments, we'll start to examine the things blockchain definitely is not beginning with a discussion of how blockchain definitely does not offer any unique safe harbor from the security problems posed by quantum computing.

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. 

Blockchain and Data Privacy

There are many businesses considering putting data (supply chain data) on a blockchain but not much conversation of the liabilities this presents.  In most blockchain architectures, all the data on the blockchain is actually held by all the nodes on the network and then each of these nodes has the power to lose this data in a breach.  Given how much trouble the world is having protecting data stored on centralized servers, reproducing the data many times is likely to produce an unprecedented data privacy crisis as multiplication of opportunity produces a multitude of new breaches.