Blockchain for embedded systems
BlogMay 30, 2018
Perhaps best known for cryptocurrency, blockchain technology can also be a powerful tool for embedded systems. Put aside Bitcoin for a moment and consider what blockchain provides: A verified, immutable record of actions across distributed systems with robust security capabilities. If desired, the actual contents of a blockchain can be encrypted – providing secrecy as well as integrity.
These capabilities can be used in many ways. They can range from robust methods to gather sensor data to building more secure command and control systems that work even in the presence of system failure, degraded communications, and compromised or hostile nodes inside your perimeter.
While a blockchain can be implemented with standardized frameworks, such as Hyperledger or Ethereum, it can also be implemented with custom systems to meet specific needs. Embedded systems are likely to use custom blockchain implementations to meet the power, performance, and functional requirements of these systems.
The block and chain
At the most basic level, a blockchain is made of two components: the block, which is a set of data, and the chain, which is a hash of the data in the previous block and which is used to establish the link between blocks. Any attempts to modify a block will change the hash of that block, producing a validation failure when compared with the recorded hash in the next block. You can trace the entire history of a blockchain by reading each block and validating it against the next block.
While a block can contain a single piece of data, for efficiency several pieces of data are commonly placed in a single block. In addition to holding data, a special strength of a blockchain is that it can handle transactions – changes in the state of data. Blockchains provide an elegant method for handling transactions in a distributed environment – even in untrusted environments and across unsecure transports.
A blockchain system consists of several components. It includes systems that are designed to create and submit data or transactions; serialization servers that process transactions in order; validation servers that verify the transactions and create the official blocks to be added to the blockchain; and a distribution mechanism for the validated blocks.
Blockchain in action
Consider an example of a contaminated site, such as the former military bases on Cape Cod. Here, decades of fuel spills and munitions testing have contaminated the soil and groundwater that is undergoing remediation.
In a generalized case, groundwater and air might be monitored by 100 sensors and there might be a filtering system whose flow rate can be changed once per minute. The landowner (who created the contamination), an environmental group, a government monitoring agency, and the company doing the remediation are all watching closely. All parties want access to the data, a permanent record of the data, and proof of the validity of the data. Since these groups have opposing viewpoints, there is a strong interest in being able to prove that records haven’t been tampered with. Let’s assume that the 100 sensors are all network connected and report once per minute. There is a monitoring gateway that collects and concatenates sensor data, and commands to the filtering system flow through the gateway.
Each sensor takes the current value, a sensor identifier, and a timestamp, concatenates them and hashes them using a sensor private key, and sends these four data elements to the gateway using a protocol such as MQTT [Message Queuing Telemetry Transport]. Each sensor needs to have a unique identity and a private key; these can be hardcoded during manufacturing, flashed into firmware, or assigned as each sensor is being provisioned into the system.
The gateway combines the sensor data from multiple sensors into a block, timestamps the block, hashes the block with its private key, and sends this combined block to a backend system, perhaps running in the cloud. Robust communications can be implemented with more advanced messaging systems such as AMQP [Advanced Message Queuing Protocol], which integrates into sophisticated applications running on the backend systems.
At this point the validation server will validate the raw blockchain data, perhaps using custom code for the specific application. The validation server can verify that the data has not been modified in transit and can apply additional checks.
A single validation server or multiple validation servers can be used. You may want to have two validation servers, perhaps at the remediation company and the government agency, and require both servers to validate a block before it is released. The validation servers sign the block using cryptographic hashes and their private keys.
Once a block of data is validated copies are sent to all parties involved. The result is that each entity has their own copy of the data and they can independently verify the source of the data and that none of the records have been modified or tampered with.
Cryptography concerns
One concern about using cryptography is the computational requirements. The cryptography used can be matched to the needs. For example, the sensors could use a simple hash algorithm such as SHA-1. While SHA-1 is considered insecure it might still be appropriate for this use case. The gateway would use a more secure algorithm such as SHA-256. The validation servers might also use SHA-256, but perform the signing operation in a dedicated HSM (Hardware Security Module).
At this point we have a blockchain containing validated sensor data from the remediation site – but that is only the beginning. In the next article, we will look at how commands to the filtration system can be implemented using blockchain transactions.
