How the Blockchain Can Ensure Virus-free Devices

One of the advantages of the blockchain concept is the capability to register objects on the blockchain, through smart contracts on Ethereum, or entity registration objects on Gorbyte.

Such ability allows for a novel approach to guarantee a virus-free, malware-free software environment on a user device running blockchain applications.

The objects or entities we are talking about can be software programs, or applications, or components of applications, or parts of an operating system environment.

These software entities can be registered and signed on the blockchain by the company that developed the software using a unique identifier. Known companies, who have a reputation to defend, would guarantee that their software registered on the blockchain is virus-free, just as currently happens when we buy and download a software application from a reputable source.

In addition to the unique identifier, and the developing company’s signature, these entities will also contain a hash of the object code.

This hash can then be used to verify a software component loaded in the memory of a device. The hash in memory can be checked against the hash registered on the blockchain for that component.

Because we can trust the blockchain as being secure, and unchangeable, we can then guarantee a virus-free environment on a device using a new approach: We can check for the integrity of the software components running on the device, instead of using the classic anti-virus approach of testing for every possible virus that can penetrate the device. Our object code integrity checker (OCIC) would be faster and require only information about the software we intend to run.

More importantly, the classic anti-virus approach requires a database of virus signatures and can never guarantee that all possible viruses signatures are included in the database.

Our approach instead would guarantee a virus-free environment, at least with the same level of confidence as we trust the original companies we buy our system and applications from.

The conditions for this approach to work are:

• Software development companies must develop a version of their software for the specific operating system of the target blockchain devices;
• Software development companies must register and sign their software on the blockchain, providing the hash of the object code for their software module;
• The target device must include specific firmware and run software, including the OCIC, designed specifically for the device;
• The target device must run the client code and be a full node of the crypto-network sustaining the blockchain.

Implementation Details

If our system contained a virus, our OCIC code itself could be compromised.

How can our code integrity checker itself run securely in a hostile environment, such as an operating environment of a generic device? How can we make sure that a virus cannot infiltrate the system even before the OCIC code is loaded? How can we make sure that an attacker will not change our loading tables, the OCIC relies on?

The blockchain comes again to our help, when our device is a node of the crypto-network (i.e.: it contains a blockchain replica).

Gorbyte, for example, will release wearable devices that will participate in sustaining a blockchain replica on every user device.

In this case, our OCIC can rely on registration object information because this information is in the device itself as part of the device’s verifiable blockchain replica, before any communication with the outside world is initiated.

Having a positive and secure way to test the integrity of software components, we can apply the test to every component in the system from the time the device is switched on. Note that the blockchain itself, up to the last verified block, has a unique verifiable hash, just like any registered component.

When a device is switched on, the first running code is a bootstrap loader in firmware. This firmware loader can do a first verification of the initial software components when it loads them in memory. It will include a small loading table in firmware with the unique version numbers and hashes of the initial software components, namely:

• A software bootstrap loader, taking over the bootstrap loading procedure from the firmware loader.
• The last verified version of the component loading table (saved in storage before the device was switched off), or an initial registered software loading table provided by the device manufacturer, when the device is new.
• Our Object Code Integrity Checker (OCIC).

The software bootstrap loader will then take over, using the verified loading table. It will load each of the following modules, and run our OCIC to verify them:

• The required basic communication modules (e.g., for Wi-Fi and internet access).
• The blockchain, up to the block before the device was previously switched off, or the address of the reliable source of the blockchain genesis block, when the device is new.
• The client code of the crypto-network (e.g., Ethereum or Gorbyte),
  or the address of a reliable source where to find this code, when the device is new.

From then on, any new component needed in the system can be verified by OCIC at the time the new component is first loaded.

Our device will then go through the normal initialization procedures: loading and initializing system components, requesting the blocks it is missing on its blockchain replica, etc. until the desired running environment is established.

At this point, only trusted verified software will run in our system (RAM).

This does not exclude that malware software could find its way into the device storage, but it would be discovered and prevented from being loaded in RAM by the (verified) loader.

No other loader can be used, to load software in RAM.

For further insurance, our OCIC could remain running in the background, verifying the loaded components at regular intervals, to guarantee that all the components running in the system have not changed due to unpredictable events. At the same time it can also scan the device storage to detect and flag any object code that is not in the loading table.