Unlocking Blockchain: 3 Considerations To Minimize Cybersecurity Risk In Smart Contracts

Sound cybersecurity practices cannot be taken for granted when implementing or using this technology.

This may come as a shock to some, but it seems that the chorus of voices singing the praises of blockchain and how blockchain technology is essentially “unhackable” are, well, wrong.  As reported in a recent article in MIT Technology Review, a security team for the cryptocurrecy exchange Coinbase uncovered an attack on the Etheruem Clasic blockchain (although no currency was reportedly taken from its accounts).  That said, this is a troubling (albeit not unforeseeable) development.  For those who have followed my writing on this topic (see here and here), this should come as no surprise.  Blockchain technology (also referred to as distributed ledger technology, or DLT) may prove itself to be transformative, but like anything else involving computers, it is anything but “unhackable.”

Here’s a quick refresher: At its core, DLT uses a decentralized computer system to create secure, verifiable, and permanent records of transactions. Each block contains data not only about the transaction, but other data that “links” it to the previous block in the chain. As a result, the system creates a log of transactions (blocks) linked together (chain) in an encrypted ledger without a centralized administrator, replicated and authenticated across a computer network by computer “nodes” and synchronized so that they all reflect the information as it is updated.  Decentralized, digital currencies use blockchain technology to verify and record the exchange of currency directly between two parties, all without the involvement of a centralized banking structure (no wonder why JPM Chase is creating its own JPM Coin on a private blockchain and and Fidelity Investments wants in on the action). Ingenious?  Yes.  Powerful?  Absolutely.  But “unhackable”?  Nope.

No matter how enticing the capabilities of blockchain, the bottom line is that it is a computer-based technology.  Like any such technology, it is only as good as its design.  At first glance, the DLT/blockchain architecture is robustly designed to validate legitimate transactions and, as a result, thwart the ability to add fake transactions to the blockchain. That said, the more complicated the architecture, the greater the possibility for vulnerabilities, and blockchain is no exception.  As more and more adoption and development has been taking place, these vulnerabilities have become evident.  One such vulnerability has known as the “51 percent attack”, where a hacker gains control of a majority of the nodes on the blockchain network and, therefore, can create a “fork” of the blockchain with alternate blocks that allows the hacker to “double spend” the cryptocurrency.  Now if that sounds like something that is not all that easy to do, you would be correct (even though it has happened) — the greater likelihood lies not with 51 percent attacks, but rather, with the other elements that lie beyond the protocol and interact with the blockchain, such as smart contracts.

If your client (or company) is developing to the public blockchain, developing a private blockchain, or otherwise interested in interacting with business partners who are doing so, you should keep these three considerations in mind when doing so:

Pay Attention to the Smart Contract Client.  A smart contract is really just a computer program that implements specific rules to interact with DLT/blockchain at a certain time or upon the occurrence of a specific event — unlike a traditional contract, this code actually executes the transaction between both parties and logs the entries on the blockchain (and even exchaniging cryptocurrency in the process). Any interaction with DLT/blockchain via a smart contract requires the use of a software client, and if history has taught us anything, software clients are vulnerable.  Your development team needs to take the time to understand the client-side architecture so that any client-side risk from implementation of a smart contract can be minimized. If not, you run the risk of not only a lapse in data security but “mistakes” in the execution of the contract.

Pay Attention to What the Smart Contract Is Doing.   Any smart contract does not end after development and launch — its operation and maintenance require adherence to basic cybersecurity practices.  By their very nature, smart contracts rely on external factors in their operation (namely, the architectural requirements of the blockchain upon which they are working).  You must ensure that the development and technical support teams (as well as client-side users within the company) engage in good “cyber hygiene” — at a minimum, the implementation of reasonable and necessary data security practices (i.e., software update and security vulnerability patch protocols, password and security access best practices, etc.) as well as ongoing operational intelligence on the actual DLT/blockchain to avoid potential vulnerabilities.

Smart Contracts Are Not Really Smart.  Like a former computer science professor of mine said, software is only as good as its design and “garbage in means garbage out.” Unlike traditional software “bugs,” implementing a bug fix is not an easy task with DLT/blockchain because the blockchain entries are indelible and can’t be reversed per se.  If anything, an updated (i.e., repaired) smart contract may need to be launched to “fix” the transactions and ultimately repair the “bug” (although that may not ultimately return lost goods or cryptocurrency to those affected by it, depending upon the circumstances of the hack) .  Further, traditional software testing is not sufficient — any development will need to account for the complexities of the blockchain before launch, and upgrade procedures following launch.

Sponsored

As you can see, smart contracts hold tremendous promise for secured transactions, but are not without some inherent challenges, not the least of which is data security.  Sound cybersecurity practices cannot be taken for granted when implementing or using this technology.  If anything, your company (or client) will need to be even more vigilant with this evolving technology to guard against data security threats. If not, then you are risking the keys to your smart contracts and allowing hackers to unlock them in the process.


Tom Kulik is an Intellectual Property & Information Technology Partner at the Dallas-based law firm of Scheef & Stone, LLP. In private practice for over 20 years, Tom is a sought-after technology lawyer who uses his industry experience as a former computer systems engineer to creatively counsel and help his clients navigate the complexities of law and technology in their business. News outlets reach out to Tom for his insight, and he has been quoted by national media organizations. Get in touch with Tom on Twitter (@LegalIntangibls) or Facebook (www.facebook.com/technologylawyer), or contact him directly at tom.kulik@solidcounsel.com.

Sponsored

CRM Banner