July 30, 2018 | Posted in Blue Teams by Mike Pinch

 

Smart Contracts are a phrase and concept coined by Nick Szabo (one of the critical early bitcoin developers) that initially were described as “a set of promises, specified in digital form, including protocols within which the parties perform on the other promises.”   This was in the 1990s…. fast forward to 2018 and blockchain technology has become a mechanism to store and execute these contracts in a distributed and decentralized fashion.  While Bitcoin’s blockchain operates as a distributed ledger of which the sole application is transferring wealth, several cryptocurrencies have emerged that allow a compiled (bytecode) computer program (a.k.a. Smart Contract) to be placed on the blockchain and accessed from the general public.  The killer feature in them is the ability to program in transfers of the cryptocurrency in exchange for access to functionality in the program.  The most popular example of that technology currently is Ethereum, which holds a $50 billion-dollar market cap at the time of writing, second only to Bitcoin.  Cryptocurrencies that currently offer smart contract capabilities include Ethereum, Cardano, Qtum, and Eos (though more exist and continue to emerge). Each currency has slightly different implementations of smart contracts, though they all offer similar capabilities.  For this article, we are going to design with Ethereum in mind, but the concepts within would work with most any blockchain-based smart contract system.

Ethereum smart contracts are computer programs written in a language called “Solidity.”  They make up the Ethereum blockchain, and those running blockchain nodes (akin to bitcoin miners) run the Solidity Virtual Machine (similar in concept to the Java Virtual Machine that runs Java bytecode ubiquitously) to execute these smart contracts.  Ethereum smart contracts can store information, process information, and respond to requests.  They cannot initiate outbound traffic, and all processing must start with an inbound request.  They cannot run automatically on a schedule, and so some third-party services (like https://www.oraclize.it/) have popped up that can push data into a contract or execute it autonomously.

Smart contracts work very well for things in which speed is not important, but record-keeping and transparency is.  Supply chain management is purported to be one of the first killer-uses of blockchain and smart contracts, allowing decentralized record keeping of product tracking and sources.  Some in the food and shipping industries think it may revolutionize the way products are tracked and assurance and provenance are shared with customers.

An interesting use of this type of technology is in Internet of Things (IOT) security, widely considered one of the most significant and unsolved security risks today.  A new standard has been proposed called  ‘Manufacturers Usage Description’ (MUD – https://tools.ietf.org/html/draft-ietf-opsawg-mud-20#section-1.1 ). It describes a method to make IOT devices programmatically “declare” what network resources, ports, protocols, and services they will need while on the network. I like to call this a ‘network manifest’, it sounds better than MUD.  In concept, when a device is put on the network, this network manifest is ingested by network security tools (like your Network Access Control), and a set of dynamic firewalls can be established to enforce least privilege network access to the device (wouldn’t this be nice? Someday – network vendors are working on this).  The fundamental weakness with this approach is that the IOT device gets to declare to the network security tools what access it should have.  An attacker could potentially gain access to the IOT device and modify the network manifest, so the device can get excessive network access.

What if we had a verifiable and immutable repository to store these network manifests?  Smart contracts to the rescue!  An IOT device could then broadcast a smart contract address to the network they are joining, such as during the 802.1x onboarding process.  This smart contract address could then be accessed freely by network security tools to download this network manifest.  How do we guarantee the device itself isn’t just pointing at a fake smart contract planted by an attacker?  The network manifest itself should be signed and verifiable with a public key by the device manufacturer, or even better an industry authority (I’m looking at you, FDA, for medical device security!).  This three-party system would be highly secure and provide a huge improvement for overall IOT security, allowing manufacturer described least privileges for network security.

A diagram giving an overview of such a process is below, in rough order of operations numbered 1-6.

While this example has not yet been realized, the technologies that would enable it all exist today at varying degrees of maturity.  It gives a good overview of a potential utility for blockchain, and should allow others to understand and build upon it.

There are likely improvements and enhancements that can be made to the above model, and we would love to hear them – email me through info@securityriskadvisors.com.  In our next Blockchain blog post, we are going to look at software development security tools for Ethereum smart contracts.  Stay tuned.