Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
The Problem with Proprietary Testing: NSS Labs vs. CrowdStrike
Brian Monkman, Executive Director at NetSecOPEN,  7/19/2019
RDP Bug Takes New Approach to Host Compromise
Kelly Sheridan, Staff Editor, Dark Reading,  7/18/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-14248
PUBLISHED: 2019-07-24
In libnasm.a in Netwide Assembler (NASM) 2.14.xx, asm/pragma.c allows a NULL pointer dereference in process_pragma, search_pragma_list, and nasm_set_limit when "%pragma limit" is mishandled.
CVE-2019-14249
PUBLISHED: 2019-07-24
dwarf_elf_load_headers.c in libdwarf before 2019-07-05 allows attackers to cause a denial of service (division by zero) via an ELF file with a zero-size section group (SHT_GROUP), as demonstrated by dwarfdump.
CVE-2019-14250
PUBLISHED: 2019-07-24
An issue was discovered in GNU libiberty, as distributed in GNU Binutils 2.32. simple_object_elf_match in simple-object-elf.c does not check for a zero shstrndx value, leading to an integer overflow and resultant heap-based buffer overflow.
CVE-2019-14247
PUBLISHED: 2019-07-24
The scan() function in mad.c in mpg321 0.3.2 allows remote attackers to trigger an out-of-bounds write via a zero bitrate in an MP3 file.
CVE-2019-2873
PUBLISHED: 2019-07-23
Vulnerability in the Oracle VM VirtualBox component of Oracle Virtualization (subcomponent: Core). Supported versions that are affected are Prior to 5.2.32 and prior to 6.0.10. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox...