Services
Let’s talk about Blockchain. I think many people in the security world are already appropriately skeptical of all of the “let’s use blockchain for this” trends, but in this post we wanted to dig into it a bit and talk about why not to use blockchain.
Blockchain isn’t just one thing really, it is a combination of things that come together in a neat way to make something like bitcoin possible. Bitcoin, by the way, is a great use of blockchain technology. Here is the original paper, which describes a lot of this in original detail - and I think in a surprisingly readable way.
So what is involved? Well, blockchain is kind of fundamentally based on some of the following concepts (again see the paper above for more complete coverage).
First, we need an identity which is defined with cryptographic keys (public and private, think a wallet). Anyone can make one. This allows us to participate. Assume that the keys will be used in different interactions with the blockchain in ways that cryptographically ensure a key owner is a key owner.
Next we need a network to participate in. This is comprised of a number of nodes that handle the actual chain. You could think of them as servers but that’s not really what they are. They’re just workers. They include the idea of a time server, which ensures that transactions are chained properly. The proof of work idea (think mining) is done continuously and as transactions happen, the nodes integrate them into their historical ledger - or tracker. Many people like the idea of the distributed network because it decentralizes the operation of the blockchain. Just like with having a wallet, anyone can participate as a node.
The chain idea comes from the fact that the order of transactions can’t be subverted or broken. One transaction can only happen after another and if it tries to present itself to the network out of order it will be rejected. The network collectively understands how to use proof of work to ensure the integrity of both the next transaction and all of the history leading up to the next transaction.
We often associate privacy with blockchain, but that is only because we don’t always know who a particular key (wallet) owner is. We don’t need to know for the system to work. However, the actual content of the ledger is not private at all. The balance and transaction history for a given key (wallet) is visible to all participants.
The conclusion I draw from the above analysis, is that blockchain fits as a solution where:
Most misuses of blockchain arise because people focus in on #8 and just want to take the part about not being able to fake a transaction without the other context about what it means to be in a distributed ledger system etc.
But blockchain does not fit just because some of these might be true. It certainly does not fit just because we have a data integrity problem to solve. There are plenty of existing technical solutions to keep track of history of data and to mark its integrity, which is usually what people want when they say blockchain.
The most obvious reason that blockchain is a bad fit for voting is that our votes are private.
But beyond that, time is not a relevant factor in voting and while a vote might seem like a transaction, you can’t really see it as related to other votes or something that would require a ledger to track the flow of votes or parts of votes between arbitrary parties.
Finally, there is no need for (or existing plausibly trustable) distributed data backbone.
Basically, when I see voting with blockchain I assume there is snake oil or sales magic happening. Among the folks I think know a lot about this and are worth consulting with further are Matt Blaze Emergency Voting and this Consensus Report on Securing the Vote.
In a medical context, it may be tempting to think about different providers as different users updating a ledger of health care records, but there are a bunch of reasons why that falls down in practice. Medical records are also private so we can’t just put them on a blockchain. The players are not really open, but contractually bound participants in a predetermined process and an existing network.
We can think about provenence and history of the record in this case, but there are much simpler ways to keep track of the integrity of a series of medical history updates.
Basically, even if we just do the following, we’ve met the same key objectives we would have with blockchain and it is something a programmer could just do without having to learn or explore blockchain:
It would also be neat to have a better way to distribute medical records safely. So that I can show up and my digital archive is available to whoever needs it. But nothing about blockchain makes that easier. It also doesn’t have any mechanism for who can see my data, which is an important factor in medical applications - including the idea of an emergency override so that a life and death situation doesn’t escalate too far because of technology.
Note that blockchain doesn’t provide any mechanism to protect the data in the transaction. It doesn’t specify encryption techniques, key management protocols, etc. It is only designed to allow participants, each with their own key (identity) to participate in a public way.
We’ve seen companies that want to use blockchain for logistics - to ensure handoff and tracking of packages or pallets are properly handled across several different logistics providers. The idea would be the state of the shipment could only progress along a timeline (using the time factor) and be changed in known ways by traceable participants in the process. Each change looks a bit like a transaction and now you can have a series of integrity checks that allows the parties to all see how the shipment is progressing. The fact that there are different parties involved participating in and watching the transaction kind of fits the blockchain model.
But again, unless the shipment data is intended to be public, the ledger has to itself be private. It could be then distributed among a network of participants - but now you’re talking about building a network again and specifying how the participants interact to particpate. Further, you could have just built a simple API with similar controls as outlined for medical (authentication, versioning, hashing) and been done with it.
This article advocating for the use of Blockchain in Smart Cities falls into the same traps. It presents the reason for adopting blockchain as cybersecurity, but in a context of “connected urban objects”. Where the cybersecurity comes from is unclear. What it is protecting and from whom is not clear either.
If we make each “urban object” into a participant in blockchain, then presumably they all become targets. If we go the path of “info tokens” from all of the “streetlights, meters, parking lots, waste bins, Wi-Fi hotspots, video surveillance cameras” etc., on the blockchain as advocated, are the controls in all of those distributed objects somehow secured? Automagically? Obviously, not. How having blockchain on these devices is going to help prevent ransomware is laughably void of meaning.
Since blockchain … you remember right … doesn’t say anything about privacy of the data on the ledger the data will all be accessible to any device in the blockchain network. The existance of a network that all of those devices even participate in seems wild.
Is the streetlight going to buy something from a parking meter that then someone else can’t buy? The whole point of blockchain is to secure a series of transactions that are related and contrained like an account. That doesn’t seem to apply at all here.
One of the cool ideas that comes along with blockchain is the disruption of industries to allow for less friction in transactions.
Consider when you buy a home. Several parts of that process rely on a Title Insurance company, who’s job it is to basically ensure that the person selling the property actually owns it and that the person buying it has the funds to do so. Ownership of land is public record. Land can be split and assembled and described in very fine technical detail.
So in this case, the data on the blockchain is public, the identities are required, the transactions basically make sense. Forging a transaction would be a huge problem. So it should be a good fit right? Mostly.
For blockchain to really work here, there has to be an incentive for people to participate in the system as a part of the network. Otherwise, you lose the distributed ledger and decentralization. With bitcoin, the incentive to participate was a digital currency which could be traded for hard cash. With a real estate scenario, I don’t think anyone would be willing to set aside increasing portions of land as part of the incentive structures for nodes / miners. Maybe that could be solved with cryptocurrency. One way or another, we would need a network to exist for this idea to work and if a company does it, then a lot of the “good things™” about blockchain get eroded.
Maybe the hype about blockchain does capture a real need for a clearer standard around data sharing and data provenance. It is likely any solution for that will include strong identities (keys, wallets) similar to those we see with blockchain. It could be possible to build a simple wrapper for a database that would allow appending, signing and storing data encrypted. It would also have to be able to provide queries to get the effective record at any given point in time. Making this more of an accessible technology option might do a lot to help achieve some of the goals of those advocating for blockchain.
The idea that blockchain is the easiest or best way to handle identity and integrity in common use cases is simply not true.
Use blockchain for cryptocurrency. Otherwise, it is probably not a fit.
