Smart contract security: how blockchain users hold the key(s)

30 May 2017

Smart contract security: how blockchain users hold the key(s)

Smart contracts: Blockchain takes on the legal sector

With smart contracts, Blockchain has been enhanced beyond its ability to simply record transactions. One can now use Turing-complete languages such as Solidity, Serpent and Golang to write complex business logic that is deployed and runs on the chain itself. In addition, smart contracts act as state transition and persistent storage systems that manipulate data as per business requirements, and have access to environmental information e.g. block timestamp and sender balance. 

Ethereum is one example of a decentralized platform that runs smart contracts. Similar to Bitcoin, it executes contracts under an incentivized scheme which pays miner fees based on the computing power spent. For this, it uses Ether, its native cryptocurrency, which carries real-world value. The Ethereum Virtual Machine (EVM) provides a container for the smart contract to be executed as stack-based Bytecode. Being a permissionless ledger, anybody is free to join the network, perform transactions and/or access the contract’s source code. Just like a user account, the contract is assigned a Public Key, and can hold and transfer Ethers. To prevent “runaway” contracts that use too much computing power (DoS attacks), a gas limit is applied. Consequently, any transaction that reaches its gas limit of 2,300 units will automatically fail. Miners have the flexibility to accept or reject a transaction, set the block timestamp, order the transactions, and much more.

The inherent vulnerabilities of smart contracts

The paradox of smart contracts is that the attributes that give them their true power — Turing-complete languages, execution on the chain, etc. — also make them a honey pot for hackers. The numerous (Ethereum) incidents in recent times prove this: TheDarkDAO, FirePonzi, Governmental, King of Ether, Rock Paper Scissors game etc.

The root causes behind these security incidents can be classified into two broad categories:

Exploitability of a platform due to its design

Example 1: Ethereum’s vulnerability to reentrancy. In computing, a computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution, and then be safely called again (re-entered) before its previous invocations are completed. This vulnerability combined with Ethereum’s depth limit of 1,024 calls led to the DAO attack. N.B. The hard fork has since resolved the call-depth issue.

Example 2: Exception handling. When a transaction fails in Ethereum, the exception bubbles up to the caller of a smart contract function. This is the rule except if the call was made using send/call statements. Also, it is possible to transfer ethers to a contract account which may consume more than the gas limit. This led to the King of Ether attack.

Design or implementation “bugs” in the smart contract source code

(The word ‘bugs’ is in inverted commas because it is difficult to say whether they were unintentional or malicious)

Example 1: Rock Paper Scissors – data on the contract was publically visible since it wasn’t encrypted, and so the first participant to show his hand always lost.

Example 2: FirePonzi – two variables had very similar names (an underscore was the only difference) to prevent the malicious code that transferred ethers to the wrong address from being detected.

Blockchain users: the key to smart contract security

Each Blockchain user has the responsibility to help combat and prevent future security incidents. The various actions they can implement depend on their profile.

Smart Contract Developers

Regardless of the cause, previous incidents show that developers of smart contracts must be much security focused than their traditional software counterparts. They must realize that, with Blockchain, the design and programming paradigm has evolved:

  1. Unlike a centralized solution, state and source code in a public ledger is open to all. Sensitive data/source must be stored in an encrypted manner e.g. Rock Paper scissors – simply encrypt the hand of each participant and decrypt only when both participants have dealt their hands.
  2. Unlike a client-server model, smart contracts are executed repeatedly by multiple miners. Smart contracts must not be written to change the state of an external system (e.g. by using oracles), or else this will lead to an inconsistent state in the external application.
  3. Exception handling is no longer a simple matter of try/catch and bubbled-up statements. Callers must check the return value of each call to ascertain failure conditions.
  4. Smart contracts must not depend on environmental values such as block timestamp or order of transactions to implement logic (e.g. manage concurrency). Miners may manipulate these values.
  5. Unlike traditional software lifecycle, where version upgrades is the norm, smart contracts are immutable once deployed. Smart contract design must be highly modular such that changes, if any, can be isolated to a small area.
  6. Design “pull payments” as opposed to “push payments” to avoid losing control of this critical feature (money!).
  7. Unlike stable programming frameworks, Blockchain does not (yet) have time-tested libraries, tools or reusable components. The community of developers can work towards building such components, e.g. a smart contract to generate a random number, a smart contract to transfer currency in a safe manner, exception handling mechanisms, etc.

Hackathons and online security training courses will go a long way in developing this security mindset and sample implementations.

Protocol and Application Developers

  1. Blockchain communities are working hard to find and address the security loopholes in their platforms. The concern, however, is that the platforms may have to undergo hard/soft forks (e.g. Ethereum) as and when such issues are fixed. So far, Bitcoin is the only tested platform where no security vulnerabilities have been found in all these years; but the use of Bitcoin to build smart contracts is limited.
  2. The concern for security is reduced exponentially on permissioned platforms, mainly by controlling the participants in the network. In addition, platforms such as HyperLedger limit the exposure of contracts and transactions by implementing the concept of confidential transactions. This is where content of the contract is encrypted using secret keys visible only to the originator, auditor and an authorized validator.
  3. Protocol and Application layer developers must publish security guidelines. The smart contract best practices guide published by ConsenSys is a good step in this direction.

Legal Firms & Regulators

  1. They must understand that with smart contracts, code is law.
  2. Since the smart contract is immutable, it is vital that it is secured at the point of entry into the Blockchain. As Blockchain becomes more universal, regulators and legal firms (lawyers and support staff) will need to develop skills on auditing smart contracts and reviewing source code.
  3. Laws and guidelines will need to be introduced for upgrading smart contracts and managing broken contracts.

Security Testers

  1. Just like developers, testers of smart contract security will need to understand the new paradigm of distributed trust computing and how the test cases may differentiate.
  2. It is more difficult than traditional software solutions to set up test environments and simulate security violations – e.g. malicious miner, timestamp difference etc. Robust testing frameworks and tools will therefore be critical in supporting testers. Zeppelin and Oyente are excellent initiatives in this regard.

What’s next for smart contracts

Smart contract security is a critical issue preventing the widespread adoption of Blockchain technology. Recent attacks on smart contracts have shone a spotlight on the concern, and also helped identify vulnerabilities and potential solutions.

Though work in the field has already begun, the existence of a one-size-fits-all solution is highly unlikely. Such a complex and vital problem will require a layered approach involving many different profiles of Blockchain users. Nevertheless, of all the actions needed to secure smart contracts, those taken at the point of entry onto the Blockchain are by far the most critical.

Leave a comment

Your email address will not be published. Required fields are marked *