Securing IoT devices and databases

Introduction

This tutorial explains step by step how to extend the Ardor functionality for allowing the integration of centralized databases within the public Ardor blockchain. Although it is focused on sensor data, it can be extrapolated to a vast extension of similar use cases.

Smart sensors and other IoT devices are set to play a crucial role in transforming business workflows as the cost-saving advantages of automation expand into more aspects of our everyday lives. The global smart sensor market alone is set to nearly triple in size by 2024, growing from $30.8 bn in 2018 to $85.9 bn in just 6 years.

With more of these devices deployed in crucial aspects of service delivery, the challenge of securing the historical data produced by these devices is mounting. That's where the blockchain comes in.

Jelurida's Blockchain Anywhere project allows the Ardor platform to function at full capacity on any device running the Android 8 operating system or later. This development brings an unprecedented level of security to your data through an advanced timestamping and querying system permissioned to your specific userbase and backed up by a truly immutable, decentralized public blockchain network. In addition to the security strengths of a private blockchain, this hybrid approach provides added benefits including the ability to instantly tokenize value, execute conditional payments, and exchange data across an ecosystem of company-specific ledgers. Any device running on Linux with Java 8 or later can utilize the full Ardor package to get access to these exact same powerful features.

Architecture of the solution

The schema that describes how this solution works is as follows:

The basic concept is to combine a normal database for storing sensor data with unique reference identifiers on the public blockchain. When the centralized database receives new inputs, a pre-programmed condition triggers that batch of data to be hashed and published on the Ardor blockchain as an account property of the master IoT account. Each batch is represented as a group ID.

Afterwards, a common SCALA-like system queries all necessary data directly as an API operation with no need to have direct communication with the centralized database. As the security is highly important, SSL must be activated in the node as for instance it is explained in the tutorial Configuring HTTPS on a standalone Ardor installation

Finally, all data can be audited for whether the hash on the public blockchain matches the hash on the file in the centralized database - providing clear evidence of data-tampering.

For a sense of what this might look like in practice, read overviews of potential use cases in utility delivery, supply chains, and more.

H2 database

In this example the table that stores the sensors data might be as the following:

CREATE TABLE sensor(dt BIGINT PRIMARY KEY, value VARCHAR NOT NULL, sensor_id INT NOT NULL, group_id UUID)

It is important to define a primary key. In this case the 'dt' column is the primary key. Once the data is getting into the data group ids are created as defined in the code:

Add-on for extending the Ardor's node functionality

As shown on the architecture diagram, the add-ons functionality of the Ardor software enables the possibility of creating new APIs.

Proof of concept

The add-on is developed for initiating the database, inserting and querying data in the H2 centralized database through an API, and checking the correctness of the data of the table.

An example of how to develop this add-on is as follows

Class for managing the add-on

It can take care of the personal bundler for sending zero fees when setting up the hashes as account properties, as well as managing the properties and setting up the add-on operations

Class for the centralized database operations

This class would have the methods for interacting with the centralized sensor data

Class for the managing the centralized database

This class would create the table for the sensor data in case it was not created previously.

This secure process is facilitated thanks to new functionalities introduced specifically for Android IoT devices on the Ardor platform, including the following APIs:

Class for inserting sensors' data

This class can contain all the code related to the insert of the sensor data.

Class for the query of the sensors data

It can contain all the code related to the query of the sensors data.

Class for checking the hashes

It can contain all the operations needed to check that the hashed data of the database is the same that the hash that was previously calculated and stored on the blockchain.

Add-on nxt.properties configuration

Being an add-on, it is recommended to store some parameters in the nxt.properties such as:

nxt.addOns=com.jelurida.ardor.iotdatabase.IotDatabase

iot.hashBatchSize=3

iot.secretPhrase=I won't tell you

Where iot.hashBatchSize can be the number of inserts that triggers the hash data consolidation on the blockchain. The higher the value, the more secure is the hashing as it will be more hard to predict. It has to be adjusted to a value where the hashing occurs frequently and provides a highly unpredictable hashes.

iot.secretPhrase can be the secret phrase of the master account that stores the hashes.

nxt.addOns=com.jelurida.ardor.iotdatabase.IotDatabase
 in this example it is needed for activating the add-on

How the solution works

In this section it is explained how to test this solution. Once the node is up&running with the add-on configured, the sensor table is created. Accessing to the add-ons page you will be able to send, query and check data:

Sending sensor data as a JSON message

The operation insertIotDatabase is used for sending sensor data. For instance the following JSON message can be used:

[{"dt":1,"sensorId":1,"value":1.12325}]

The output is as follows:

Once the insert triggers a hashing, the output is different as shown in the following image:

Querying the database

In order to query data, the operation queryIotDatabase has to be used, using either the sensorid or the groupId or both as parameters:

Checking the public blockchain hashes

In order to check that the data has not been tampered, the operation checkHashIotDatabase has to be used. As parameter the groupId selects the batch of data and it outputs a message as follows:

The computedHash must match with the blockchainHash, if it does not then it means that the data has been tampered and we can't trust it.

For instance, manually modifying the data would cause that the hashes mismatch as it can be seen in the following image:

Conclusion

Hybrid models that combine the blockchain's data security with centralized systems are being demanded by the market. This approach allows businesses to maintain internal ledgers while benefitting from the tamperproof record keeping and peer to peer value exchanges offered by public blockchains, all while scaling similarly to purely centralized solutions.

This proof of concept can be extended with Lightweight Contracts for automation, operational decision management, execution of rules and usage of the data.

Granting access for the H2 sensor data can also be secured using blockchain capabilities, for instance by using Tokens.