Endpoint

9/8/2017
10:30 AM
Duncan Jones
Duncan Jones
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

If Blockchain Is the Answer, What Is the Security Question?

Like any technology, blockchain has its strengths and weaknesses. But debunking three common myths can help you cut through the hype.

Blockchain technology has made its way into a wide range of business environments, solving problems from securing land registry records to ensuring that music royalties are paid fairly. To the casual observer, this technology enhances any business relationship, especially when parties are distributed or distrustful. However, like QR codes in the '00s or, more recently, big data, blockchains are appearing a little too frequently and sometimes with dubious business benefits. To cut through the hype, let's consider the most talked about capabilities of blockchains and examine the reality behind the claims.

Myth 1: Blockchains are a resilient, distributed database.
For many people, blockchains and Bitcoin are synonymous — thousands of computers scattered about the planet, each with a copy of an ever-growing digital ledger. For Bitcoin and other sizable public blockchains, including Ethereum, the size of the network is indeed very large and claims of resilience are fair. Each full node in the network keeps a copy of the entire ledger, and the ingenious proof-of-work consensus mechanisms ensures this is kept in sync. 

However, in many of the examples making the news lately, the structure of the network is quite different. The majority appear to be private chains, run by a handful of nodes set up specifically for the purpose of managing a business process. While this implies a degree of resilience, it doesn't compare to the robustness offered by a large public chain. Given that you have to configure and manage these nodes yourself, you might question what you gain over deploying a properly distributed database.

Which brings us to the next problem: blockchains are not databases. They are a ledger data structure, suited for appending new pieces of data and allowing an auditor to occasionally do a full-pass validation of the contents. They are not designed for supporting queries on data, or certainly not queries of any great complexity. If a business plan contains the phrase "store on the blockchain," alarm bells should be ringing. In such cases, always ask why a blockchain is superior to an actual database.

There's also the question of confidentiality. Ledgers are generally public data structures and thus unsuitable for storing private data. Sometimes this is mitigated by storing ID values or hashes in the blockchain, with the actual data living in a private shadow database elsewhere. Particularly in these situations, one must question what is gained by involving a blockchain at all.

Myth 2: Blockchains are the ideal audit tool — a perfect, immutable transaction history. 
A blockchain uses a chain of hashed data structures to record a sequence of transactions. In the case of Bitcoin, these transactions are generally transfers of funds from one address to another, but in other chains, the transactions may be nonfinancial and domain-specific.

The brilliance of blockchains is that a transaction has truly happened only when it is captured in the ledger and thus recorded forever. This means there is a one-to-one link between the action and the audit log — perfect forensics evidence. However, this perfection requires your business transaction to be modeled as a blockchain transaction (perhaps using smart contracts on Ethereum or Burrow). If you merely post an audit entry to a blockchain after your business transaction completes, that magical property is lost. There's no guarantee that every business transaction was posted to the chain, or that every element in the chain is the result of a real business transaction. If your software is merely posting audit logs to a blockchain, you should ask yourself why a blockchain is the right answer, versus a database or some other data structure.

One should also consider the claim of immutability quite carefully. All blockchains can resist a certain proportion of bad folks trying to subvert its behavior — typically somewhere between a third to a half of participants. Beyond this threshold, if sufficient nodes collude they can rewrite the past. Imagine a scenario where three banks keep a shared blockchain ledger to record transactions. Is it so hard to imagine two of the banks conspiring against the third? Probably not, yet we could equally imagine that the use of blockchain technology was championed in all three banks as a cure-all for data integrity and auditing.

One way to approach the above problem is to anchor your private chain in a public chain, such as Bitcoin. Through the wonderful properties of Merkle trees (which essentially condense an entire blockchain history into a single hash value), it's possible to notarize your chain state by including its hash in a Bitcoin transaction. You've piggy-backed on the immutability afforded by Bitcoin to protect your private chain! A number of startups have sprung up to offer this as a service.

Myth 3: In the future, all business contracts will be smart contracts on a blockchain.
Ethereum was the first blockchain designed for executing arbitrary code "on the blockchain." Its brilliant design allows users to upload small pieces of code to a blockchain address, which can be executed by sending a transaction to that address. The code is executed faithfully by all the participants of the network, and the results are committed to the blockchain. There are cunning security mechanisms and economics in place to prevent spammers from running never-ending programs and bringing down the network.

On the face of it, this seems very exciting for business. Error-prone, corruptible human processes can be replaced with autonomous scripts that are guaranteed to execute correctly and audit themselves automatically on the ledger. So, what's the problem?

One problem is the difficulty in writing flawless contract code. In 2016, this was dramatically highlighted when around $50 million was stolen from The DAO, an autonomous corporation running on the Ethereum blockchain. The theft was made possible by a bug in the contract code, which allowed the attacker to withdraw a third of the value of the corporation into anonymous accounts. Contrast this outcome with a flaw in a legal contract, where you have the opportunity to argue the matter in court and seek a reasonable judgment based on the intention of the document.

Another issue is the legal enforceability of smart contracts. For the foreseeable future, smart contracts will be secondary to a written contract that actually binds the parties together. It will be the latter document that provides the legal protection and risk mitigation, not the smart contract. Yet, in spite of the above, smart contracts are an excellent idea and will no doubt revolutionize the way business is done in some sectors. Just don't expect to be taking your lawyers off retainer just yet.

Like any technology, blockchain has its strengths and weaknesses. With the current hype surrounding the subject, it's all too easy to incorporate blockchains into projects where an alternative approach might be easier or more flexible. If your business transactions can be represented as blockchain transactions, you get a lot of powerful side effects for free. Auditing, shared state, and consensus between distrusting parties are pretty impressive secondary benefits. But you probably shouldn't be using a blockchain as your primary method to solve those problems. 

Related Content:

 

Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Click for more info and to register.

Duncan Jones leads the research and innovation team at Thales e-Security, focusing on emerging security threats and tomorrow's cyber technologies. He studied computer science at the University of Cambridge, before spending ten years working in security and payments. Duncan ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
Symantec Intros USB Scanning Tool for ICS Operators
Jai Vijayan, Freelance writer,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: I guess this answers the question: who's watching the watchers?
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-3988
PUBLISHED: 2018-12-10
Signal Messenger for Android 4.24.8 may expose private information when using "disappearing messages." If a user uses the photo feature available in the "attach file" menu, then Signal will leave the picture in its own cache directory, which is available to any application on the...
CVE-2018-10008
PUBLISHED: 2018-12-10
A code execution vulnerability exists in the Stapler web framework used by Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in stapler/core/src/main/java/org/kohsuke/stapler/MetaClass.java that allows attackers to invoke some methods on Java objects by accessing crafted URLs that were not intended...
CVE-2018-10008
PUBLISHED: 2018-12-10
An information exposure vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in DirectoryBrowserSupport.java that allows attackers with the ability to control build output to browse the file system on agents running builds beyond the duration of the build using the workspace br...
CVE-2018-10008
PUBLISHED: 2018-12-10
A data modification vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in User.java, IdStrategy.java that allows attackers to submit crafted user names that can cause an improper migration of user record storage formats, potentially preventing the victim from logging into Jen...
CVE-2018-10008
PUBLISHED: 2018-12-10
A denial of service vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in CronTab.java that allows attackers with Overall/Read permission to have a request handling thread enter an infinite loop.