Comments
Security

Security for Blockchains and Distributed Ledgers

Brian Scriber
Vice President, Security Technologies

Jan 10, 2019

Empirical evidence reveals an inimical belief that blockchains and distributed ledger technologies (DLTs) are inherently secure because they use cryptography, employ hashing algorithms and have public/private keypairs—in short, a belief that the data in these systems is extremely unlikely to become exposed. After evaluating requirements and deciding to utilize a blockchain solution, security is important to consider from the start.

Over the past several years, the Security Technologies arm of CableLabs’ Research and Development organization has been tracking blockchain attacks and compromises. From this work, several hazard groupings have been identified. The following list is intended to act as an aid to architecture, design and implementation efforts surrounding enterprise projects that use these technologies.

Smart Contract Injection

The Smart Contract engine is an interpreter for a (sometimes novel) programming language and a parser of data related to the decisions the engine needs to make. The hazard in this situation is when executable code appears inside smart contracts in an effort to subvert the contract language or data. Implementers need to consider sanitizing inputs to smart contracts, proper parsing and error handling.

Replay Attacks

Not only is there a threat in transaction processing and validation, but also in node behavior, authentication, and the securing of confidential messaging. Adding nonces to check against prior transactions is critical.

History Revision Attacks

Blockchains that rely on fault-tolerant consensus models do well when there are many participating nodes processing, competing and collaborating on the next block. When the number of nodes drops, or if there is predictably cyclic behavior, lulls can be leveraged in a history revision attack where a new branch is created, effectively deleting a previously accepted transaction. Designers should consider how to best guarantee minimum support and the diversity of nodes.

Permanence Poisoning

Due to the permanence of blockchains and the cost to fork, it’s possible to sabotage a chain with even claims of illegal content to draw the ire of regulators and law enforcement.

Confidential Information Leaks

Permanence increases the risk of data being exfiltrated out of the chain. Even encrypted data is at risk for future threats against those algorithms or brute-force attacks. Designers need to make sure that they understand the data being stored, how it is protected, who owns it and how it could be re-associated with any pseudonymized users.

Participant Authentication Failure

Are transaction creators cryptographically signing their transactions? Is that signature verified by the protocol? Is transaction receipt confirmed (non-repudiation)? Are sessions managed? Architects need to consider the proof of possession of private keys in the verification and authentication of participants.

Node Spoofing

Nodes are the entities that create and agree on the next new blocks in a chain. Nodes should be authenticated like any other user or system, and authentication must be verified, with multiple votes prohibited. Designers who fail to look for voting irregularities open their implementation to risk.

Node Misbehavior

Nodes that behave incorrectly, intentionally circumventing fault-tolerance mechanisms, or trojan nodes (nodes in public chains that follow the standard protocol but have non-standard implementations) are problematic. Transaction propagation non-compliance is another concern—where nodes don’t convey transactions quickly to other nodes, nodes consistently act in opposition to other nodes, or verifications align consistently within small fiefdoms. In addition, architects need to consider what happens to the chain operations when the chain, the nodes or a subset of the nodes is subject to a denial of service attack.

Untrustworthy Node-Chain Seam

The cryptographic difference between what was intended by the participant, what happens in the node, and what happens on the chain must all be consistent. Architects should enforce a design such that the node is unable to modify a transaction (signing and hash verification), skip a transaction (non-repudiation) or add new transactions (source verification).

General Security Hazards

The hazards fall into this meta-category of general security concerns that have specific implications in the blockchain/DLT realm. Architects, designers and implementers all need to take heed of these practices and work to ensure a complete solution:

  • Unproven Cryptography: Look for best practices and proven cryptography in cipher suites, hash algorithms, key lengths, elliptical curves used, etc.
  • Non-Extensible Cryptography: Should a foundational algorithm aspect of the chain become compromised, can the chain easily migrate to another suite/hash/key pair? Is there a mechanism and process among node operators to agree and deploy this quickly?
  • Security Misconfiguration: Be aware of all code libraries used, stay abreast of the latest security information about deployment technologies such as Docker, and ensure that defaults present in test systems are not available in production systems. Ask if there are any components with known vulnerabilities, determine whether any open ports or file-system permissions may be at risk, and understand protection mechanics for private keys.
  • Insufficient Logging and Alerts: If something goes wrong, are there sufficient methods in place to capture actions that occurred (voting, smart contracts, authentication, authorization)? Project managers must ensure that alerts have been added to the code, that the correct recipients have been added at deployment time, and that procedures for constant monitoring and updating of those recipients take place.
  • Weak Boundary Defense: Development teams need to be aware of, and shore up, defenses so that there are no exploitable holes in client code or node software, smart contract engines, mobile applications, web applications, chain viewers or administrative tools.

Clearly, this list doesn’t contain everything that must be reviewed in a blockchain or DLT application, but the objective is to provide a few key areas to focus on and provide insight to dive deeper where it makes sense in your own applications. Blockchains can help bridge trust gaps in an ecosystem, but security is foundational to that trust.

Want to learn more about security for blockchain and distributed ledgers in the future? Subscribe to our blog by clicking below. 


SUBSCRIBE TO OUR BLOG

Comments
Consumer

Blockchains and the Cable Industry

Steve Goeringer
Distinguished Technologist, Security

Mar 1, 2016

Blockchain is the fundamental technology underlying digital currencies and new transaction processing solutions. Some technologists are generalizing the concept now and using the term distributed ledger technology, or DLT. Blockchain technology uses cipher-chaining to cryptographically link blocks of transactions. The most famous implementation of this approach is Bitcoin. Over the last couple years new trends and markets have emerged outside of the crypto-currency space. There are now several hundred start-up companies, open source projects, and collaborative industry efforts, each focused on different applications of this technology to a wide range of industries.

The cable industry’s interest in these technologies and solutions is increasing. This interest is being encouraged by highly public events across multiple industries, including:

  • R3 CEV is a group working on applying blockchain technology to the banking industry. Streamlining transaction processing between banks promises up to $20B in annual savings. R3 CEV recently completed a blockchain connectivity experiment linking 11 banks.
  • Nasdaq has packaged distributed ledger technology into an offering they are developing called Nasdaq Linq. Linq will be used to complete and record private securities transactions. Chain, a firm providing a development platform for working with blockchains, recently executed the first trades on Linq.
  • Microsoft is supporting blockchain solutions using Azure. Starting in early November 2015, several blockchain projects began using Azure. This includes R3 CEV based on an Ethereum model. More recent partners include MultiChain, Emercoin, Eris, CoinPrism, and BitPay. Azure’s support to date is optimized for development and testing which allows partners to focus on their solutions rather than virtualization support.
  • The Linux Foundation has started a new project called Hyperledger. This effort is well supported by companies and organizations across multiple industries seeking to advance blockchain solutions beyond common current implementations through a “cross-industry open standard for distributed ledgers.” Robert Mcmillan of the Wall Street Journal reports that IBM will be contributing code to the Hyperledger project soon.

These mainstream activities show that blockchain is rapidly evolving beyond Bitcoin.

Applicability to cable industry

The core concepts of blockchain are simple. Using cryptographic techniques, blockchains allow the creation of distributed transaction ledgers. In computer science terms, the ledger is an ordered linked-list that is cryptographically linked to previous entries on the ledger. Consequently, the ledger is secure in that it is extremely difficult to change or remove a transaction that has been added to the blockchain. Moreover, the older the transaction, the more difficult it is to change the transaction.

CableLabs believes blockchain solutions are widely applicable to the cable industry. Generally, applications fall into three categories:

  • Digital currency and payment systems
  • Transaction processing and records management
  • Augmenting security practices

Blockchains may be transformative in developing new customer experiences, reducing cost of media distribution, and securing the burgeoning device ecosystems our industry enables.

CableLabs activities

CableLabs has been tracking development of distributed ledger solutions closely. We continue to identify and investigate emerging technologies in this area and monitor over $1.3B invested in Bitcoin and blockchain companies (in 2014 and 2015). There are hundreds of new companies, open source projects, and various industry groups developing innovative capabilities that we monitor.

In addition, our security technologies experts are tracking the core technology elements themselves. This is essential to allow evaluation of innovative solutions based on blockchains and also to determine how best to architect and integrate these solutions into our industry.

Finally, we consider blockchain developments and concepts in our innovation efforts. In some cases, blockchain may allow or enable new capabilities and revenue opportunities that otherwise cannot be achieved. In other cases, blockchain complements an existing capability by reducing costs or enabling new features.

Recommendations

Blockchain technology is still emerging and not ready for off-the-shelf implementations, but it’s not too early to start considering how it may strategically benefit cable operators. Product managers should start tracking industry news and discussion groups for ideas on how they may benefit from blockchain solutions. Technology leaders particularly should do the same, but also start understanding how blockchain technology works. This will provide insight on how blockchain technology may improve security, provisioning, and device on-boarding processes.

CableLabs has also prepared presentations to help technologists understand Bitcoin, blockchain technologies, and ongoing industry initiatives. These are available to members upon request.

Steve Goeringer is a Principal Security Architect at CableLabs.

Comments