Chapter 13: Blockchain Ledger Solution Affirming Physical, Operational, and Functional Changes in an IoT System

CHARIOT aims to introduce a novel methodology for maintaining security throughout all endpoints of an IoT network. To achieve this, a blockchain-based adaptation of the traditional Public Key Infrastructure (PKI) protocols have been formulated to satisfy the needs of industrial IoT and enhance it as necessary to simultaneously be as abstractive as possible in its design and fulfill the requirements set forth by the enactors of the CHARIOT technology stack. The current technological landscape of identity security in the context of IoT lacks in several areas, even more so when analyzed under the pretense of low-resource devices. The most common solution applied in these scenarios is the use and deployment of a PKI. However, it fails to address the core issues of identity security in high-value low-resource distributed environments since PKI has its shortcomings in certain security aspects by design.

The first and foremost shortcoming is that of the single point of failure [1], a trait shared among any software design implementation that relies on a oneto-many server-to-client interaction. By introducing a single source of truth for cross-verification of identities, it enables an attacker to devote his resources into compromising that single source instead of relying on other more complex attack strategies. Additionally, should a network-wide disruption occur, it is relatively easier to spoof a single entity rather than a distributed system and validate malicious identities. As more trust and value, informational or otherwise, is placed in IoT networks, these types of attacks will become much more widespread as the beneficial yield would outweigh the resources required to take such a network down.

To address this, the abstraction of the PKI stack is proposed to a distributed layout with the aid of blockchain technology [2]. In PKIs, Certificate Authorities (CA) act as the validation oracles for any identities in the network by issuing identity certificates and subsequently validating them cryptographically. These authorities possess a single cryptographic keypair that, if compromised, can result in devastating consequences as the possessor of the keypair would be able to issue, adapt, and revoke an unlimited number of identities, thus resulting in the compromisation of the whole network.

CHARIOT decided to break down the components that make up the issuance and verification process of a CA, simplifying them where possible and finally reimplement them using blockchain-based smart contracts. As an initial step, the bare necessities of a PKI network were defined in association with a cryptographic identity, thus an identifier, with a set of metadata that could either reside in onchain data or simply act as a validator of off-chain data, such as a cryptographically secure hash. To enhance the basic indications of a PKI identity, which are “valid,” “expired,” or “revoked,” an additional field is added to signal the status of the identity. This field takes the form of an unsigned integer, which is utilized in CHARIOT solution as a binary abelian group code. This code can be used to represent an arbitrary amount of statuses and, being a simple representation of ones and zeroes, depends on the software implementation for assigning a binary group to a status code. This results in a modular system that can easily be expanded in scope.

By using smart contracts, we ensure that all on-chain computations will be relayed across the network and ensure that any alterations to the underlying database will be available to queriors of the blockchain instance from any blockchain node on the network. This allows the network to remain operational even if a percentage of the network is compromised. Although in the CHARIOT implementation, the IoT gateways were utilized as nodes in the blockchain network, as the forthcoming technological advancement in the IoT’s computational capabilities will enable them to become blockchain nodes themselves, empowering verification of identities in a bilateral format (both gateway and sensor identities verified) rather than a unilateral format (only sensor identities verified).

With regard to the actual invocation process of a contract’s identity issuance, revocation, and adaptation method, a multi-signature protocol has been implemented rather than a single-signature one. As the acceptance policy is preconfigured during the setup of the CHARIOT solution, it is possible to construct an n-out-of-m scheme that would satisfy even the most rigorous security policies.

For instance, for the installation of a sensor, the four-eye principle could be applied by requiring signatures by both the installer of the sensor and the manager of the site in which the sensor is installed.

In parallel, a custom-built cryptographic protocol was utilized rather than a readily made one as that allowed greater freedom in the implementation approach as well to ensure that it would be able to be adapted if it is necessary in the future. To construct cryptographic signatures that would be accepted by the CHARIOT blockchain system, one needs to sign a payload that matches the CHARIOT blockchain requirements. These requirements are as follows:

The aforementioned specs lead to the creation of a pseudo-language, also known as a Domain-specific Language (DSL), that is machine-readable and easily convertible to a human-readable format. Additionally, the nonce-based scheme heightens the security of the overall solution as it provides protection against a wide variety of attacks, inclusive of replay attacks as well as race conditions, two issues that exist inherently in any cryptographic signature-based scheme.

In order to ensure that the specifications of the blockchain platform comply with the requirements of the testbeds the CHARIOT project has already been deployed to, feedback was gathered during the blockchain’s design from the owners of the testbeds and incorporated them to the CHARIOT blockchain when necessary in collaboration with the other components of CHARIOT. One such requirement was the increase of security at the services themselves, as the initial vision was for the CHARIOT services to run in a non-distributed server device that still suffered from certain types of vulnerabilities. The new requirement of distributed deployment was tackled by introducing the services as identities within the distributed PKI network formed by the blockchain and subjects them to the same stringent security workflows identities on the blockchain are put through. In turn, this enabled greater control and security of the services running in the CHARIOT network. As an additional enhancement, the presence of metadata was introduced within the identities in the blockchain network to indicate the cryptographic keys that would be used to encrypt data payloads in an end-to-end fashion to accommodate for the privacy requirements of the data, as is the case when the Privacy engine of CHARIOT processes data flows in the network.

To streamline interoperability integrations of the blockchain service of CHARIOT, several tools and services were developed and are included in the CHARIOT technology stack, the first being the Golang CLI CHARIOT administrator keypair manager. As the scheme that has mentioned above might be slightly complex to implement, prone to human error and difficult to carry out in a manual way, a tool was developed that allows simple command-line arguments to be parsed and generate keypairs and signatures with. Additionally, it is capable of both outputting and consuming CHARIOT keypairs as exported to the .chrt file format, a file format devised in CHARIOT that is a purely textual document structured similarly to conventional keypair files, as in the keypairs are enclosed within multiple dash delimiters with a word in between. Apart from the thorough documentation provided alongside the tool, it was also used to directly implement an externally queryable JSON-RPC 2.0 API to allow ease of integration with existing tools of the CHARIOT technology stack that reside within the main CHARIOT network. As the tool itself is stateless, it is possible to easily scale it out as necessary by spawning more processes running the same software.

Another tool that was developed for the purposes of integration with the blockchain of CHARIOT is the RESTful API coded for the Node.JS runtime environment. Interfacing with the Hyperledger Fabric blockchain instance is notoriously difficult to non-blockchain-versed developers, and as such, it is naïve to expect both users and other members of the CHARIOT consortium to integrate the blockchain easily without additional assistance [4]. To amend this, the Fastify framework was used along with Hyperledger Fabric’s own Node.JS libraries to create a bridge between the externally facing API and the internally facing blockchain interface. The Fastify server essentially transforms the RESTful requests it receives to actionable items on the blockchain instance and returns the results where applicable. While the blockchain itself contains an additional layer of traditional PKI, this was abstracted by not deploying a CA for the blockchain network and instead generating and utilizing a singleton administrator keypair when interacting with the blockchain via the API. While one may argue the storage and utilization of a single keypair for interacting with the blockchain may be vulnerable to security issues, this is not the case with the CHARIOT blockchain implementation as the validity of the transactions themselves is processed directly on the smart contract without any reliance on the blockchain’s native PKI system. This means that, even if a malicious transaction was crafted with the keypair, it would immediately be rejected by the smart contract as its code is immutable. Even if an attacker attempts to alter the codebase and create a new version of the contract, which would be possible if he had possession of the administrator keypair, he/she would still fail to compromise the network as Hyperledger Fabric’s versioning system prevents the replacement of a contract’s chaincode with another’s.

Another limitation of the Hyperledger Fabric blockchain implementation was the non-dynamic structure of the network. By default, version 1.0.6 of the Hyperledger Fabric runtime lacks the dynamic network restructuring subsequent versions inherently support. To emulate this capability, CHARIOT took advantage of some of the configuration tools of the blockchain to set new genesis transactions that would replace the initial genesis transaction of the network and thus allow dynamic addition and removal of Orderers, the nodes responsible for maintaining the blockchain network’s state synchronous and without any reconciliation issues. This case arises when the CHARIOT network needs to scale out by adding numerous more IoT gateways and generic network participants, as maintaining a single Orderer for an extensive network would prove cumbersome and ultimately unsupportable.

The underlying cryptographic implementation used for the CHARIOT keypairs and general signature protocol is based on Elliptic Curve cryptography, specifically the ecdsa package of the Golang programming language which the smart contract codebase is programmed in. An exhaustive analysis of the available state-of-the-art cryptographic suites was conducted at the time of CHARIOT’s initiation period and pinpointed that the ideal suite for the purposes was, at the time, the ecdsa package. However, this is not an inhibitor of the future relevance of the CHARIOT blockchain solution as the implementation itself is suite-agnostic provided that the relevant components are properly updated and/or altered to utilize a different cryptographic suite. For example, one could introduce a quantum-secure digital signature algorithm in the future to ensure that the blockchain solution remains secure even when put under attack by quantum computers. This extensibility capability expands to all other aspects of the implementation. The CHARIOT implementation uses certain technology stacks to carry out its vision of a distributed PKI system, namely Hyperledger Fabric, a Node.JS-based RESTful API, and a Golang CLI tool. These software restrictions are irrelevant to the logic of the overall blockchain workflow, as it can be ported to any programming language one wishes. This type of abstraction is detailed within the project and one can use a completely different blockchain implementation, e.g., Ethereum, to achieve the same results as one would with Hyperledger Fabric.

The rationale behind the software-dependent choices were made based on research conducted over the lifetime of the CHARIOT project coupled with hardware limitations of the CHARIOT gateway built within the project. As is the case with most industrial grade IoT gateways, the CHARIOT gateway operates in a real-time operating system environment, meaning that it does not pair well with event-driven or asynchronous software. This proved to be a strong obstacle for the blockchain implementation of CHARIOT, since it was aspired to boast a distributed network of blockchain participants inclusive of the IoT gateways. For this purpose, a System-on-Module device was integrated that would be capable of operating a conventional operating system and create it as an adapter between the real-time environment of the gateway and the asynchronous nature of the blockchain. By forming a wired bridge between the System-on-Module and the motherboard of the CHARIOT gateway using Universally Asynchronous Receivers-Transmitters, were able to relay data gathered from the blockchains’ latest state to the gateway whilst also being able to respond to actuations made by the IoT gateway and properly convey the result of these actuations, such as on-demand queries of a sensor’s identity.

The System-on-Module itself needed to satisfy the bare minimum operational requirements of a blockchain instance which meant that a powerful yet compact System-on-Module has to be attached to the gateway. Power to it was provided through direct tapping of the gateway’s power source. A new issue that arose with using a System-on-Module was the available software implementations of the blockchain in specific architectures. The software runtime of the Hyperledger Fabric project did not include the ARM family of architectures, and as such, CHARIOT had to resort to building its own implementation from the source code. This proved to be a hindrance, as no one had compiled the Hyperledger Fabric runtime for ARMv8, the 64-bit architecture of the System-on-Module. Significant alterations have to be done to the build instructions and choose a specific Hyperledger Fabric version to continue with to ensure full compatibility with the API of the blockchain. In the end, CHARIOT went forward with the 1.0.6 version as the 1.1.0 version, the latest available one at the time, appeared incompatible with the ARM architecture after attempts at compiling it inside the environment, meaning it required heavy alterations that were out of scope of the project.

While the blockchain itself is inherently scalable due to its segregated structure, the overlaying services needed to be somehow adapted to exemplarily operate under a scalability scenario. To this end, deployment scripts were coded to automate the process of spawning an instance of the software and used these scripts to create deployment pipelines that contain instructions on how to deploy the various components of the CHARIOT blockchain in the Docker environment. By storing the code of the components in virtualized containers, overlay services were set up to manage the life cycle of these containers automatically and scale the network as necessary, ensuring that the systems remain operational even under extreme network load. Additionally, load-balancing services can easily be appended on top of the architecture to properly delegate network load to the containers spawned underneath the load balancer.

The environments the CHARIOT project is and will be deployed in are extremely time-sensitive, as even a minor delay in the measurement of a critical sensor can lead to catastrophic results. To properly conduct tests on the blockchain solution and ensure that it does not become the bottleneck of the overall solution, multiple unit tests have been devised that thoroughly check the correct operation of the underlying logic. These unit tests were coded with a framework that simultaneously produced coverage reports, enabling us to identify which segments of the codebase were not thoroughly tested and required extra test suites. While these unit tests provided us with an indicator of the correct operation of the logic, they failed to provide any insight as to how the solution fares under extreme load. For this purpose, load-testing tools produced multiple HTTP requests under a multi-threaded context and tracked the resulting response times, codes, and other such metadata. The results gathered from the tests indicated that the blockchain provides a small yet non-negligible overhead, and as such, optimization techniques opted to speed up the identity validation process of the solution.

One such optimization was the introduction of an in-memory table of recently verified identities that are retrieved and retained on boot time at the gateway level. This method acts similarly to how popular cache-based data stores work such as Redis. The resulting speed was near real time, as the codebase migrated for extracting the public key of a signature payload from the System-on-Module to the gateway’s codebase in C thus decreasing the necessary execution time and allowing the gateway to self-sufficiently verify an identity provided that it exists in its cache table.

The blockchain solution of CHARIOT acts as proof of a viable blockchain integration in the context of IIoT security, and it paves the way for wider adoption of this novel technology; if utilized correctly, it can resolve certain issues faced by contemporary solutions. As future steps, we aspire to enhance the solution over the course of the CHARIOT project with the requirements from the other services of the solution stack as well as the requirements of the pilot cases themselves.

This project has received funding from the European Union’s Horizon 2020 research and innovation program (No. 780075). The authors acknowledge the research outcomes of this publication belonging to the CHARIOT consortium.