How to Be Secure in a Digital World

Bohdan Wojciechowski
5 min readMar 8, 2024

B.W. Wojciechowski, March 2024

Caution and Distrust are the Essence of Security.

The World is vitally dependent on digital technology. The resulting vulnerabilities hover like a cloud of doom over every one of us. Power transmission, navigation, and banking systems are among the vital services that depend on a reliable digital network, each specific to the application and susceptible to intrusion. Into this mix, we have now added a new and menacing vulnerability, AI, or, as I prefer to call it, Inorganic Intelligence, I2. The I2 identifier suggests that artificial or not, this new intelligence merits recognition too as a potential competitor for decision-making. It could be a serious threat.

As happens with all progress, initial applications are problem-specific. As time goes on, standardization takes place and the interchangeability of parts and whole systems takes place. It was so with gears, dimensional standards, specialized materials, and configurations of equipment. As the applications became common their properties were defined by standards. Today much of design depends on simply fulfilling the requirements of standards, with ingenuity used to comply with requirements in novel situations.

The digital world has developed similarly. Code was initially created by individual “programmers,” the artisans of yore, who wrote code that at first followed methods used in on-paper calculations. Soon it became clear that some of the procedures were more robust and faster than other versions. I was there at the time and can attest to the rapid evolution of both coding and the electronics used in processing the ever-improving codes. It was a wild and wooly world of competing systems.

Then came the time of “Modules,” efficient code that could be plugged into larger programs using a minimum of interfacing. This was soon followed by “higher level” languages. FORTRAN stands out but several other specialized languages such as COBOL for accountants and ALGOL 60, for mathematical problems in general, are memorable. But in all of this development, we were careless. All those programs could be easily infiltrated by malware.

This was the route that finally got us where we are at present. Our programs may use more advanced versions of these earlier languages and operating systems but are too vulnerable to malware. Much damage can be done by hostile activity in the digital realm. Several hostile “hacking” incidents are on record, notably the fearful Stuxnet episode which laid low the nuclear program of Iran. That was arguably the first and most famous use of computer malware by government agencies to destroy a dangerous industrial operation. Digital interactions and applications are international and highly integrated. Critical aspects of all this need to be more secure.

A possible answer to such vulnerability is the diligent application of “encoding.” All operating systems and private data could be encoded and re-encoded periodically. Robust codes and regular refreshers may be the best, possibly the only, reliable protection against intruders and malware. With the advent of quantum computers, all this should be more complicated but also easier to do.

I will leave the mode of encoding up for debate. One could encode the whole software program or require access to be restricted by encoded “nodes” in various random parts of the program. These would check the validity of various parts of the software. For now, I leave this issue since I do not know of a consensus.

Today most commercial software is protected by “passwords.” These infernal keys are simple to discover in the form applied by most users. Most passwords consist of 8 or so characters, a “secret” that can be revealed by modest means. Passwords are necessary, but an inconvenience to most of us. My list of passwords is several pages long and I need a printed directory to access many rarely used features. Using eye scans or facial recognition would help but it would simplify hacking by those who manage to get a picture of such a “code.”

What we need is a way to have the original operating system securely encoded and yet readable by the intended hardware or user to allow execution. That way we could have an operating system that is highly resistant against the insertion of malware. However, since even encoded software can be penetrated with enough effort, all these programs would have to be subject to periodic re-encoding. Such an approach will take time to develop and become secure and robust.

A Possible Scenario of Digital Defense

The salient points brought up so far are:

· All vulnerable programs and operating systems need to be encoded.

· The encoding will need to be changed at unspecified times.

· Applications will operate using the encoded versions of the software.

· The interface between the encoded software and the instructions carried out in the application will involve a hardware/software “interpreter” which will need to be changed when a new encoded OS is installed.

· Operating systems should be isolated one from another by encoded “transfer nodes” maintaining the opportunity for interaction while reducing the vulnerability of the net overall.

· There must be no interruption of service when new software is installed.

As it happens there is a model of the operations to do this. Large-scale farming of grains and other crops requires periodic use of equipment that is available for rent from companies that own the necessary machines but themselves do not farm. No need for a farmer to own machines that sit idle most of the year if he can rent the necessary services from an operator who can service numerous customers with the required equipment that he owns, saving the farmer the need for expensive investments in equipment he would rarely use.

In the proposed security world each enterprise would have a central computing facility. This would operate various parts of the system including any secondary centers. All the operating software would be encoded, and implementation of the code would be performed at the point of application by a hardware/software “box” which would issue and receive information from the encoded OS and translate it into a format the local equipment can understand. Call it the “translator” unit.

When a refresher of the OS concerned is needed one or more trailers containing the required hardware would be brought on site by a REPRO company that would install the new software. The hardware on the REPRO trucks would seamlessly take over the operating system of the enterprise using the old code. This would allow other REPRO hardware on the trucks to reprogram the company hardware to a new standard. Before disconnecting the REPRO units the new software would be tested and verified. All local “translator boxes” would be replaced at the same time. The REPRO convoy would move on to the next customer. Unlike the equivalent agricultural operation, the REPRO business could operate at full capacity year-round.

How Doable is This Kind of System?

· Minor changes in the OS could be inserted at any time.

· Major changes would be scheduled when the encoding of the OS is changed.

· The translator boxes may provide added security in protecting the customer from hackers and malware inserters. Each box would only operate on a small segment of the overall code and would do so via both software and hardware components. A hacker could access the output of the translator but only in the form of executable instructions for that segment of the operation. That reduces the danger of intrusion but does not eliminate it.

· The encoding could be strong enough that even with quantum computer code-breaking methods the time estimated to be necessary to break a given encoding would be longer than the period between normal encoding changes.

My message to those who understand the above ruminations,

Expect the Worst

Anon

--

--