Friday, May 11, 2018

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.

Friday, January 5, 2018

Blockchain: What Are the Fundamentals?

I enjoyed reading the article: “2018's Resolution? Revisit Blockchain's Fundamentals” by William Mougayar on Coindesk.
The author warns us that when a new technology comes along, we are often too eager to quickly implement some of the pieces we need, without a vision and an understanding of the full potential of the technology.
We have seen this happen in part with the Internet. It was quickly adopted, even though many designers at the time could already see the lack of those security features that had to be added almost as an afterthought. The whole world still suffers the consequences of the lack of a well designed security architecture for the Internet.
We are now facing similar design choices with the blockchain technology.
As a coach warning us to “stick to the fundamentals”, the author lists some of what he considers the blockchain fundamental innovations, or “fundamental outcomes”.
But are we sure we understand what the blockchain fundamental blocks are?
For example, the first fundamental in his list is “replacing intermediaries”. This objective is definitely important, for applications running on unpermissioned (or public) crypto-networks.
I agree with the author. But the designers and investors of Ripple and Hypercom could argue otherwise. It depends on what the target applications are.
We do not really know what problems future applications will need to solve.
Looking at the following “fundamentals” in the author’s list, his suggestions seem to be somehow limited to the current state of the art.
By looking at what we currently understand as innovations, we risk, as the author says “copying what we already see instead of inventing what we don’t discern yet”, that is, we may miss the full potential of blockchain technology.
For example, we cannot limit our thinking to today’s smart contracts running on today’s crypto-networks as the only engine to run blockchain applications.
If we do so, we may miss 97% of future general distributed applications that will use the blockchain, but will run on different engines, off-the-blockchain.
If we want to create an environment able to support the distributed application of the future, without knowing what they will be, we may need not just a better engine, but a multitude of better engines.
The ability for general distributed applications to use the blockchain functionality without having to run a smart contract on-the-blockchain is a top requirement on my list.
Millions of concurrent distributed applications will need to process and securely exchange many terabytes of information per second among identifiable, unique parties.
Current crypto-networks do not begin to solve the problem. Public crypto-networks do not even contemplate the problem of identifying who the users are: people, IoT objects, vehicles, autonomous robots or something else.
We could describe many characteristics of the blockchain and things that we will be able to do using the blockchain, but we would never finish: any imaginable distributed application should be able to use the blockchain, just as today any App on a cell phone can use the cell phone communication ability.
So what are the fundamentals?
Is the ability of the blockchain to support communication between a person and IoT objects a fundamental?
Is the ability of the blockchain to support Virtual Private Blockchains a fundamental?
Is the ability for autonomous robots to trade assets using their personal accounts a fundamental?
The fundamentals are not what future blockchain applications will do, but what these applications will not do.
We can use the following analogy: An iOS allows the development of Apps without these having to solve the problems of memory management, or using storage commitment techniques, or even be dependent on the CPU instruction set.
In a similar way, a Distributed Operating Environment (DOE) for the blockchain will allow the development of General Distributed Applications (GApps) without these having to solve the basic problems of communication, addressability and unique identification, replication of data, and security.
These seem to be the main requiements of any distributed application. How much easier would it be, for example, to design an airline reservation system if the DOE already solved for us the problems of system security, verification of the passenger identity, and ticket purchase transaction? How faster would the check-in and boarding processes be for the public?
The blockchain technology has been rightfully compared to the introduction of communication technology. Mostly this is because they complement each other.
With the Internet we have solved the problem of communication among any two parties. Now, with first-generation crypto-networks, how close are we to a DOE for general distributed applications?
Which fundamental blocks are still missing?


Our efforts should concentrate in establishing at least these fundamental blocks by developing second-generation crypto-networks, that will create a DOE for future distributed applications.
The longer term goal for application designers is to solve any OTHER imaginable problem, easily and transparently.
A DOE that proves those fundamental blocks will truly add value to what started as a distributed ledger for financial transactions.
Future generation crypto-networks will go even further in doing what future applications will not need to do.



Giuseppe Gori is the designer and CEO of Gorbyte, a new-generation crypto-network that uses a cooperative consensus mechanism replacing miners/verifiers. He has over thirty years experience in the design and development of computer networks.