Blockchain: Hype or Hope for Transactional Security?

by David Archer on January 8, 2018

It has been said that time is nature’s way of making sure everything doesn’t happen at once. In practice, time is a good way to make sure that events happen in order: that payment happens before title is conveyed or that authentication happens before privileges are granted.

It has also been said (long before computers) that “paper is to write things down that we need to remember.” In an age of malleable data and malicious intent to rewrite or “unremember” important events, we still need a way to remember—but that way must be resilient to unremembering.

Blockchain technology in its diverse forms can help with writing things down and keeping their order straight in ways that are cryptographically secure and, with some work, formally provable as correct. Government organizations have taken note of these capabilities. For example, both the U.S. General Services Administration and Japan Ministry of Internal Affairs and Communications have started to evaluate the use of blockchains for improving the contract review process for IT vendors and accepting government contract bids.

Is Blockchain a Security Panacea?

However, an organization evaluating blockchain technology for an application should look deeply at what it needs from such a technology. What do you need a blockchain to do? Are there other, simpler ways to accomplish those ends? When it comes to technology, simpler (and less costly) is almost always better if it meets your requirements. With those questions in mind, let’s first examine what blockchains can do, and when they provide a significant advantage over other technologies.

What Do Blockchains Do?

While a comparison quickly would turn into a marketing argument, we see that most blockchains offer five common capabilities:

Sponsorships Available

Consensus: They allow a group of distinct and potentially untrusting entities to agree on the occurrence (or not) of an (electronic) event.
Immutability: They provide a tamper-evident record of the history and relative timing of diverse events.
Trust neutrality: They avoid the need to trust a middleman or central authority in providing the above capabilities.
Decentralization: They provide a record of event occurrences that is robust to the loss of potentially many holders of record copies.
Forward Security: They provide assurance that even if consensus is compromised, the record of events prior to that compromise is immutable and thus still trustworthy.

Using these capabilities and a few basic cryptographic techniques, blockchains can provide other guarantees useful in many applications. For example, non-repudiation is a guarantee that if an entity records a statement (a transaction, or proof of existence) on the blockchain, that entity cannot later deny that recording. Authenticated entries guarantee that if an entity records a statement, that statement could be made only by that entity and by no-one else. Finally, in some applications, it’s important to distinguish particular resources used in the transaction, to show that each one is unique (i.e., uniqueness of transaction). In currency transactions, uniqueness is typically called single-spending.

As important as what blockchains do is what they don’t do. One common misunderstanding is about privacy. Most blockchains do not keep information they store secret. zCash, along with Guardtime’s KSI, are exceptions to this rule.

So, the “protection” offered by most blockchains is an immutable, cryptographically secure attestation that an event occurred, or that an artifact existed, and that the occurrence or existence was recorded on the chain by a particular entity at a particular time, and in the (roughly) right order with respect to other things recorded in the chain. That attestation is often supported by a decentralized trust model, so that it does not depend on a single trusted authority, and is survivable even if a large minority in that trust model are compromised.

Do You Need a Blockchain?

But wait. Do you really need a blockchain? In an article examining whether an organization needs blockchain, authors Wüst and Gervais suggest some key decision points. Will multiple users contribute information to your application? If not, blockchains probably aren’t necessary. If there are multiple contributors, and you trust them all, then once again, no blockchain. If there is a trusted third party always available to arbitrate decisions, blockchains are overkill.

What Kind of Blockchain?

If you’re firm on the need for a blockchain, then the next questions you ask should be about what kind of blockchain best fits your needs. Blockchains vary:

In the kind of information that can be recorded: For example, the Proof of Existence service leverages the Bitcoin blockchain to allow proofs that a particular file on a computer with particular content existed at a particular time. Monegraph does the same for graphical images. Namecoin provides similar protection for identities and user profiles. Ethereum and others that support so-called “smart contracts” provide protection for steps of processes defined in contractual terms, such as the processes that make decisions in organizations. Bitmessage protects message interchanges among users.
In who can record that information: Must the contributor be registered in advance (as in so-called permissioned blockchains) or can anyone record a transaction (as in permissionless blockchains)?
In who can later audit and verify what was recorded: Is that information public (as for example in the BitCoin blockchain), or is it somehow restricted (as with verifying amounts of transactions in the zCash blockchain)?
In how well the blockchain scales up in number of transactions per second: For example, while BitCoin is limited to about 360,000 transactions per day, some other solutions such as Guardtime’s KSI can record many billions of transactions in that same time.
In how much storage is used, and does that fit your affordable cost?
In whether privacy of recorded information is guaranteed. Some blockchains provide privacy of recorded information, but most do not.

How Secure and Correct are Blockchains?

Do blockchains have security vulnerabilities, or do they exhibit logic defects? The short answer is almost certainly yes. A slightly longer answer is that no one knows the full story on blockchain security or correctness. Formal mathematical proofs, such as those we rely on for modern cryptography, are not available yet for practical blockchains.

Instead, most blockchain users rely on practical demonstration of correctness and the ability to correct defects as they are discovered. Unfortunately, for blockchain technologies correcting defects may not be easy; the long-lived state of the chain may have to be forked or rolled back to fix errors. Such revisions have been seen recently for example in the Ethereum blockchain ecosystem, and should rightly be a cause of caution in adopting blockchains. As far along as they have come, it is still premature to definitively declare whether blockchains are redefining security, or if they pose more cybersecurity challenges than they solve.

At the end of the day blockchain is simply an electronic ledger to which many participants can write and agree on what’s written and in what order, without the need to trust a central authority or other participants. A few rules are enforced (by mathematics, not by people) that control what constitutes a valid entry in the ledger. A few more rules prevent any user from taking control of the ledger and thus being able to cheat. Blockchains are a promising, maturing technology. However, as with other technology choices, caveat emptor.

— David Archer