Blockchain for embedded systems (Part 2)
BlogSeptember 04, 2018
Part 1 of this blog on blockchain for embedded systems (see July/August 2018 issue) explored one way of using blockchain technology for sensor data, especially where the integrity and provenance of the data must be verified. Blockchain is also useful for the other part of embedded systems: command and control.
In many cases, the “control” part of an embedded system is a series of commands to directly attached actuators. Some of these systems, such as flight controls, may be performance-sensitive – actually, latency-sensitive. Other cases, such as something like setting the chemical injection rate for groundwater remediation, might be changed on an hourly or daily basis. A common requirement for a controller is to be able to verify and validate commands as well as maintain a verifiable history of commands.
Consider the case of an autonomous drone. Critical commands issued to the drone would include a destination and whether or not to release a payload when it reaches the destination. The payload could be instrumentation or other high value items.
To make sure the drone is on a valid mission, there should be multiple authorizations. Parties authorizing a mission might include a science group, a funding or governance group, and an operations group. In a situation like this, there would be a system where all three of these groups have to approve and authorize a location before the drone accepts it. The system would need to be fake-proof or spoof-proof and ideally maintain a secure history of all commands.
Blockchain can provide this reassurance through validation, including validation servers and validation policies. Validation servers work by cryptographically signing a proposed transaction. In the autonomous drone example, a command to send a drone on a specific mission would be considered a transaction.
The simplest case is a single validation server that signs every transaction. Validation policies can create more complex authorizations, as in the example that would call for three validation servers with each server signing (approving) the transaction before it is valid. More complex situations are also possible: For example, a resilient system might have 20 validation servers and require signing by a majority (11 servers) or in a different case the same 20 validation servers require signing only by five for a valid transaction. A different system could have one primary validation server that must sign, plus any two out of five secondary servers signing.
A validation policy called Byzantine Fault Tolerance works even in the presence of failure of validation servers and the presence of compromised or hostile validation servers. Compromising a system using Byzantine Fault Tolerance requires compromising more than half of the validation servers, making this approach robust even in the presence of failure and hostile compromise of systems. The details of Byzantine Fault Tolerance are a bit too arcane to discuss here, but it is nonetheless an example of the power and flexibility of blockchain.
Validation servers work by cryptographically signing a transaction. This is done using a private-key/public-key pair, one that is different on each validation server. This crypto signing can be done in software, taking advantage of the performance of the host system. It can also be done using a Hardware Security Module (HSM), a specially hardened module that is dedicated to the security operations. An HSM can be a high-performance/high-cost module or a lower-performance/lower-cost unit such as a Trusted Platform Module (TPM) or even a smart card.
When using software signing, the private key is present on the system and can be compromised. Using an HSM, the private key is contained inside the hardware module and can’t be compromised. (While this statement isn’t completely true, modern HSMs are considered secure against anything short of a state-level actor.)
The beauty of blockchain in the drone example is that the drone verifies the validity of the commands it receives, verifies that the commands have been issued and validated by approved authorities, and confirm that they have been received in the proper order. These steps avoid the risks associated with modifying the commands in transit or even having the commands changed by the person entering them into the drone. In addition to the drone, everyone else in the blockchain ecosystem can verify the sequence of commands and who authorized and approved them.
Note that the actual command content need not be visible to everyone. The blockchain payload can be encrypted so that only authorized entities can actually read the contents. This action produces a very robust system where everyone can verify the sequence and authority of all commands, but only the entities needing to implement a specific command can determine what that command is.
One major concern about command and control systems is the ability to function in the presence of disrupted and degraded communications systems. A key strength of blockchain is that it is extremely tolerant of retransmission: A user can send (and receive) a block a thousand times and end up with a single command or transaction, not a thousand of them. There can be multiple partial transmissions of a block that then get reconstructed into a single verifiable block; blocks can come in out of order, as the blockchain enables the blocks to get assembled in the proper order no matter what order you receive them in.
This combination of properties makes blockchain a powerful tool for building robust, secure, high-trust systems. In addition to supporting low-performance applications, like the drone target destination in the previous example, blockchain can also support high-performance applications. The key to all of this? Enough computing power, ample network bandwidth, and sufficiently low latency to support the required performance.
Is blockchain the perfect technology for building invulnerable systems? Yes and no … If you follow the media, you know that cryptocurrency systems using blockchain are regularly compromised. If you dig into the failures, however, you discover that these failures are due to human error and faulty implementation. The actual blockchain algorithms and protocols are surprisingly robust. This is much like other applications of crypto: The algorithms are robust, but the people, software, and systems using them aren’t necessarily robust.
These examples show how blockchain technology can be used to build more robust and secure distributed systems, including those that deliver a verifiable history of changes. Cryptography is a powerful tool with many real-world applications.
