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.
