Will Zero Vulnerability Computing (ZVC) Ever Be Possible? Testing the Hypothesis

Abstract

Life without computers is unimaginable. However, computers remain vulnerable to cybercrimes, a USD 6 trillion industry that the world has come to accept as a “necessary evil”. Third-party permissions resulting in an attack surface (AS) and in-computer storage that computers mandate are key design elements that hackers exploit, formerly by remote malware installation and later by stealing personal data using authentication faking techniques. In legacy computers, the AS cannot be completely eliminated, nor can a connected device retain data offline, rendering fool-proof cybersecurity impossible. Although the architects of legacy computers made perfectly reasonable engineering trade-offs for their world, our world is very different. Zero vulnerability computing (ZVC) challenges the impossible with in-computer offline storage (ICOS) and Supra OS (SOS), to deliver comprehensive protection against vulnerabilities. The feasibility of ZVC is demonstrated in a tiny permanently computer-mounted hardware wallet, providing the first evidence of the complete obliteration of the AS. Malware cannot infect the ZVC device on account of lacking an AS, nor can personal data be hacked as they mostly remain offline, except for sporadic processing. Further research should explore whether ZVC can fully secure computers in more complex real-world scenarios and open a new epoch in the evolution of computers and the Internet.

1. Introduction

Cybercrime inflicts damages totaling USD 6 trillion annually and is predicted to grow to over USD 10.5 trillion industry by 2025 [1]. A hack attack occurs every 39 s, and approximately 300,000 new malware programs are created daily [2]. Today, over 4.5 billion connected devices remain at risk of cyber-attack [3]. With the exponential proliferation of IoT devices [4] and the ever-growing vulnerabilities of connected devices, the cybercrime industry is poised for unstoppable growth [5].

Advances in computer science and IoT computing have been running at ultrahigh speeds. We are looking at the future in which everything will become a connected computing device [6]. Toys, clothes, cars, door locks, contact lenses, clothes, toasters, refrigerators, washing machines, light bulbs, toothbrushes, glasses, helmets, etc., are getting “smart”. Everything has become a branch of computer science.

“Everything is now a computer. The digital nightmare is about to get much worse”, claims Bruce Schneier in his latest book Click Here to Kill Everybody [7].

A Brief History of Computers & the Origin of Their Vulnerabilities

Back in the 1940s, Thomas Watson, boss of the giant IBM Corporation, made probably the worst prediction in history, “the world would need no more than about five computers [8]. Eight decades later, experts are predicting 50 billion Internet-connected devices by 2030 [9].

The first computers were gigantic calculating machines, and all they ever really did was “crunch numbers”: solve lengthy, difficult, or tedious mathematical problems. There was no software industry; no operating systems and programs were custom written for each computer individually until IBM launched its first personal computer in 1981 with an operating system that granted third-party permissions to developers of software applications. Since then, it became standard practice to produce computers with third-party permissions. In the 1990s, with the advent of the Internet, bad actors started exploiting these permissions to write malicious programs and install them on victim computers remotely. Such attack vectors created an attack surface that introduced vulnerabilities, feeding a thriving multitrillion cybercrime industry. In the state-of-the-art, it is impossible to build a computer without third-party permissions and consequently free of vulnerabilities. Essentially, legacy computers cannot prevent malware from exploiting the inherent permissions that are available for all third-party programs. However, the network efficiencies have reached a level that even the most resource-intensive applications can now run remotely without the need for local installation [10]. This introduces the possibility of doing away with third-party permissions entirely and, consequently, eliminating the attack surface to achieve zero vulnerability. Our research on zero vulnerability computing exploits these possibilities for rendering computing devices immune to cyber-attacks.

2. Problem Statement

Experts unanimously agree that fool-proof cybersecurity is “practically impossible”. This is essentially because of the following two mandatory design attributes that legacy computers must comply with to render them usable:

• Permissions that third-party applications need to run, but bad actors often exploit to introduce vulnerabilities, resulting in attack surfaces that can be exploited by malware [11].
• In-computer data storage, in absence of which, using, processing, or saving data is impossible. However, because most computers remain connected, stored data are continuously exposed to hackers. Hence, any data stored in a networked computing device are considered a priori at risk.

Both necessary evils are the core enablers of cybersecurity breaches. State-of-the-art cybersecurity techniques are predominantly focused on strategies that reduce the attack surface and encrypt the data stored in online devices to counter these evils. However, these approaches have known limitations and are often complex, making cybersecurity experts conclude that fool-proof cybersecurity is impossible. Gene Spafford, a National Cybersecurity Hall of Famer asserts:

“The only truly secure system is one that is powered off, cast in a lock of concrete and sealed in a lead-lined room with armed guards—and even then, I have my doubts.”

[12]

Cybersecurity experts unanimously agree (“this is a world in which the promise of secure digital technology turns out to be in many respects a poisoned chalice’.”) [13] that data within a connected device can never be entirely secure, because network exposure can never be risk-free [14].

Since the birth of the Internet and the cybercrime industry, the attack surface has been growing. The severity of vulnerability or common vulnerabilities and exposures (CVEs) is also increasing. The National Vulnerability Database (NVD) [15] provides qualitative severity rankings in the scale [Low-Medium-High] depending on the Common Vulnerabilities Scoring System (CVSS) as defined in the CVSS specification [16], which scores from 0–10 in an increasing order of severity. Of the top 50 products [17] reporting the total number of distinct vulnerabilities in 2020, OSs were directly or indirectly responsible for almost all reported vulnerabilities.

2.1. Perpetually Increasing Attack Surface

Recent reports forecast a surge of 12.6% in CAGR by 2027. With the proliferation of IoT devices, predicted to reach 75 billion by 2025 [18] (Figure 1), the attack surface will grow exponentially, increasing security vulnerabilities across the board. This extraordinary growth of a serious problems warrants extraordinary measures. Is our current cybersecurity strategy sufficient? Let us review them.

“Complexity is the worst enemy of security, and this is especially true for computers & the Internet.” [19]. Complexity opens the door to vulnerability. Unfortunately, advancements in computer technology have always been associated with increasing complexity. The more complex a system is, the more vulnerable it is to security threats. It is time we reversed this trend and eliminated all complexities ingrained in legacy systems. With the advent of the IoT and the proliferation of connected devices, attack surfaces and, consequently, vulnerabilities have grown exponentially. Every day, the AV-TEST Institute registers over 450,000 new malicious programs (malware) and potentially unwanted applications (PUA). Over the past decade, the number of malware cases has grown from approximately 100 million in 2012 to a whooping 1.33 billion in 2021 [20]. See Figure 2.

In the current state-of-the-art, the approach to improving the security of a computer system is to measure the attack surface [21] and minimize it using the following basic strategies:

• Reducing the amount of code running;
• Reducing entry points available to untrusted users;
• Eliminating services requested by relatively few users [22].

The zero-trust architecture by NIST also suggests a similar strategy [23]. Although attack surface reduction helps prevent many security failures, it does not mitigate the damage an attacker can inflict once a software vulnerability is found [24].

2.2. Increasing Zero-Day Vulnerabilities

Code reuse is a common practice in software development owing to its various benefits [25]. The use of both commercial and open-source components in development increases the vulnerability. However, such a practice causes large-scale security issues because one vulnerability may appear in different software because of cloned code fragments [26]. This rising trend has become a major reason for the constantly expanding attack surface in the past decade. Zhang et al. (2019) [27] recently demonstrated that many seemingly unrelated software apps share a common attack surface. In addition to the software development trends that increase the attack surface, the timeframe of vulnerability exploitation is compressed by 93%. Currently, it is only three days before a vulnerability is exploited, compared to 45 days in 2006 [28]. Cybersecurity ventures [29] predicted zero-day cyber-attacks to rise from one per week to one per day.

2.3. The Q-Day Threat

Last but not the least, two recent articles in the Nature journals emphasize the seriousness of the impending threats from quantum computers to the Internet [30] and an actual quantum attack on several cryptocurrencies that led to the latest crypto crash of 2022 [31]. Already overwhelmed with the ever-increasing scourge of computer vulnerabilities and cybercrimes, the cybersecurity of computers appears to be moving closer to the apocalyptic threats from quantum computers [32].

3. State-of-the-Art

Our problem statement identifies two “necessary evils” as the core enablers of cybersecurity breaches in legacy computing systems. We designed a zero vulnerability computing (ZVC) solution that tackles each of those design mandates that make computers usable, but paradoxically render them vulnerable. We define ZVC as a new cybersecurity paradigm that proposes a new computer architecture.

A review of the state-of-the-art therefore warrants a two-fold inquiry.

3.1. Offline Storage Technologies

In legacy systems, offline storage refers to any storage medium that must be physically inserted into a system every time a user wants to access or edit data. Offline storage can be any type of storage that can be easily removed from the computer and is not currently online, live, or connected to the computer. The data stored in offline storage remain permanently in the storage device even if it is disconnected or unplugged from the computer after the data have been stored. Offline storage is generally portable in nature and can be used on different computer systems. Known also as removable storage, examples of offline storage include floppy disks, compact disks, and USB sticks.

In computers of the prior state-of-the-art, data storage constitutes one of the key components of the computer architecture. However, there is no provision or concept of offline storage within a connected computer. In other words, when a computer connects to the Internet, the stored data, by default, also go online, exposing it to network risks. Hence, the state-of-the-art is completely blank in terms of the in-computer offline storage (ICOS) module that constitutes one of the two modules of the ZVC architecture.

3.2. Technologies for Secure Execution Environments

To cope up with the ever-increasing demand in hardware and provide solutions to the exploitation of vulnerabilities in program execution, libraries, and the operating system APIs, different kinds of architectures such as sandboxes, virtual machines, and containerized application systems have emerged (Figure 3).

Sandboxing was the first practice to establish the concept of running code in a safe, isolated environment that mimics end-user OS APIs. Sandboxes run as software in the application layer of existing OSs and execute potentially dangerous system calls inside a controlled environment. Sandboxes are inefficient in deploying complicated security policies, do not scale, and cannot protect the OS from various existing monitor-bypassing attacks.

Virtual machines (VMs) are the typical building blocks for cloud infrastructures to gain higher hardware resource utilization while preserving execution isolation among different computing instances [33]. A host OS is isolated through a hypervisor engine, and guest OSs are run in a protected environment. Execution within a guest OS only affects the guest OS API and its underlying software without ever reaching the host OS and its infrastructure. Still, from an execution perspective, having a dedicated OS for each VM and the full set of underlying software suggests that the attack surface and relevant security aspects for the VMs themselves do not differ from that of physical machines [34]. On top of that, various attacks exist that can escape the isolated environment and attack the host OS by leveraging the abundant resources found within the guest OS of a VM [35].

Containerized applications, such as Docker and Linux Containers (LXC), emerged as an alternative to VMs by providing a convenient way to deploy and isolate applications without installing a guest OS and relevant auxiliary software necessary in a VM. Since there is no guest OS virtualization in a container, the attack surface bound to each guest OS and its software services cannot be exploited. However, as containers share the same underlying host kernel, access to containers is not easily secured, and even though Docker isolates parts of the underlying host OS API from containerized software, this can be an issue for multi-tenant security [36].

Air gapping: Although sandboxing, VMs, and containerization provide a high level of protection, if the local area network is connected to the Internet, a motivated adversary will find a way to breach the network, evade security mechanisms, access sensitive data, and transfer them outside to the attacker [37]. In order to provide protection from such breaches, organizations often store their sensitive data on air-gapped networks. In this approach, any type of physical or logical connection between the local network and the Internet is strictly banned [38]. Air-gapped networks are widely used in military and defense systems [39], critical infrastructure, the finance sector, and other industries [38]. Two famous examples of air-gapped networks are the NSANet and the Joint Worldwide Intelligence Communications System (JWICS), classified (top secret) networks belonging to the United States’ Defense Intelligence Agency. Even air-gapped computers caged within an all-metal Faraday cage can be breached as demonstrated by Guri et al. deploying ODINI malware that uses magnetic waves for data transfer [40]. Besides these major cybersecurity approaches, there are several authentication-focused piecemeal protocols such as secure elements, secure tokens, hardware security, trusted platform modules, etc., but none of them has the potential to achieve zero vulnerability whether by completely obliterating the attack surface or creating in-computer offline storage.

3.3. Conclusions

“Complexity is the worst enemy of security, and this is especially true for computers & the Internet.” [19]. Complexity opens the door to vulnerabilities. Unfortunately, advancement in computers has always been associated with an increase in complexity. The more complex a system, the more vulnerable it becomes to security threats. It is time we reversed the trend and got rid of all the complexities ingrained in the legacy systems.

4. Research Purpose and Related Works

The principal objective of this research is to explore the feasibility of a conceptual computer architecture framework that revisits the conventional computer design (i.e., the Harvard-like design of microcontrollers and embedded systems or the von Neumann architecture of mainstream computers) that introduces vulnerabilities at all levels of any computing environment. Our primordial efforts to achieve zero vulnerability computing date back two decades, when we first attempted to circumvent operating system vulnerabilities by running a fully quarantined transaction using a CD-ROM device as a real online card key (ROCK) [41]. Although it circumvented the host OS vulnerabilities (spy programs), ROCK was not scalable, limited to specific transactions, and lacked acceptable user experience. This was essentially because web technologies to minimize reliance on native applications were not adequately developed at the time. However, ROCK disclosure provided foundational data to evolve and relate the zero vulnerability computing (ZVC) hypotheses to a computer’s attack surface and subsequently to in-computer offline storage (ICOS). Therefore, we formulated two ZVC hypotheses and tested them in experiments that this paper discloses in the following sections: Section 5 provides the rationale of the hypotheses and their verbiage and explanation (A) and defines the innovation (B). Section 6 presents the objectives and details of the experimental setup for supporting and testing the hypotheses. Section 7 discusses the results and conclusions;. Section 8 discusses the work limitations, and Section 9 discusses the future of ZVC.

5. ZVC Hypotheses: New World, New Rules

The architects of legacy computer systems have made perfectly reasonable engineering trade-offs for their world, but our world is very different. The rules governing the computers of their world may no longer be defensible in the hyperconnected world that we are currently living in, at least not considering the pace at which cybersecurity continues to worsen. Therefore, we decided to take a fresh look at the architecture of computers, as it has evolved over time, and start from ground zero. Foundationally, computers were designed oblivious of the serious consequences of the permissions and privileges they afford third-parties, which can potentially make computers vulnerable to threats from bad actors. Such incognizance introduced two mandatory design attributes into the computer architecture:

• Third-party permissions;
• In-computer data storage.

These are foundational elements of the computer architecture, without which prior state-of-the-art computers could not be built. These designs not only introduce complexities, but bad actors also often exploit privileges to create vulnerability. As exploitation techniques improve, the complexities of defense also increase, resulting in a cybersecurity race that has become unwinnable. To explore the possibilities of achieving zero vulnerability computing (ZVC) and winning the race, we conceptualized two radical approaches in redesigning the computer architecture, and to explore the possibilities, we formulated the following hypotheses:

5.1. The ZVC Hypotheses

Hypothesis 1:

Can Supra OS (SOS) completely obliterate the primary attack surface by denying third-party permissions to all non-native applications?

Hypothesis 2:

Can a hardware module isolate critical data that require sporadic access to offer in-computer offline storage (ICOS) within the connected device itself without compromising its functionality?

As stated earlier, it is impossible to build a computer without third-party permissions. Permissions create vulnerabilities, allowing attack surfaces that attack vectors use to breach computers. An “attack surface” is essentially the entire externally facing area of a computing environment. It contains all the vulnerabilities or attack vectors that a hacker can use to gain access to a computing system. The attack surface is simply the total digital resource exposed to threats across the enterprise. There is no legacy hardware or software that does not come without third-party permissions by default. As illustrated in Figure 4a–d, third-party permissions may be exploited at the hardware, firmware, or OS level (primary attack surface) or even via the application layer (secondary attack surface). The magnitude of the attack surface is directly proportional to the density of vulnerabilities [42]. The attack surface (represented in Figure 4 by dents or pits and permissions by represented by bumps) is mandatorily created in legacy computers because of the assumption that third-party applications must run locally; therefore, permissions are mandatory. As such, banning all permissions and completely obliterating the attack surface of a computing device are de facto impossibilities in cybersecurity research. However, in the era of 5G communication and ultrafast data transmission speeds, the assumption that the application must be executed locally is outdated and misplaced. Currently, there is no conceivable applications that cannot run on a remote server.

While banning all third-party permissions to reduce the attack surface to zero may be quite a stretch to conceive of in the pre-5G era, it is quite surprising to note that the state-of-the-art at no point in the evolution of computers made it impossible to integrate a switchable in-computer offline storage (ICOS) memory to complement the computer’s standard hard drive. Yet, our legacy computers lack such a mechanism to keep sensitive data offline at users’ behest, while the users’ computers remain online.

5.2. The Innovation

Considering these realities of the prior state-of-the-art, our SOS hypothesis challenges the very foundation of legacy computer design by banning all permissions for native installation/execution of third-party applications, while allowing only remotely served applications, as illustrated in Figure 4b,d and Figure 5, via a built-in web interface that does not in any way depend on nor communicate with the host computer’s operating system. In other words, the ZVC ecosystem runs on its own: it is self-sustaining, running on its own minimalist operating system and has no dependencies on the host operating system.

In legacy systems, it is normal to expect any software application to create its own attack surface because of the permissions it avails from the OS, firmware, or hardware and inadvertently passes it on as an indirect permission (zero-day vulnerability) to the adversary. Since ZVC allows only Internet-delivered applications, there is no need for running native applications or a need for third-party permissions that create an attack surface.

A case in point is the infamous Pegasus hack of WhatsApp accounts of some high-profile individuals wherein Pegasus exploited an OS zero-day vulnerability [43]. However, that cannot be the case with an SOS, as the permissions are barred at all levels for all third-party applications, so there is neither a question of zero-day vulnerability, nor any indirect permission being passed on to create a secondary attack surface on the SOS software.

Although originally conceived of as a middleware in the context of mainstream computers (Figure 4b), the SOS was implemented as firmware in the present IoT (hardware wallet) experiments, as illustrated in Figure 5, comparing it with the anatomy of the attack surface in legacy IoT systems. While the residual attack surface cannot be eliminated in the legacy system, there is no residual or secondary attack left after implementing the SOS on a computing device. In absence of any attack surface, no executable program can install or run on the computing device.

Turning on a computer and yet keeping the stored sensitive data offline inaccessible to attackers is another “impossibility” in the prior state-of-the-art that our second ZVC hypothesis challenges by creating ICOS as a tiny USB-mounted NAND Flash-based MUDP 3.0 device, as shown in Figure 4e,f and Figure 6. The device is left mounted on the host computer permanently, but remains offline by default, keeping the sensitive data safe and secure. It is switched on transiently only when executing a transaction, thus minimizing its exposure to network threats. In any case, as explained earlier, the SOS keeps any malware threat at bay (Figure 4e,f) for the tiny fraction of time the device goes online.

Both hypotheses essentially question the possibility of exploring a new cybersecurity paradigm of zero vulnerability computing. The assumption is that a combination of these two novel encryption-independent security paradigms, when properly designed in specific execution environments (Figure 7) as disclosed in our experiments, may lead to a computing environment with a very high cybersecurity assurance against very strong and capable adversaries. Therefore, the SOS and ICOS are two radically novel components of ZVC, which, when combined with well-crafted encryption mechanisms, such as homomorphic encryption, provide strong security guarantees.

As a proof-of-concept to support and test the ZVC hypotheses, we built a minimalist hardware wallet device to execute secure cryptocurrency transactions. In the simple experiments that we designed to test the efficacy of the SOS and ICOS components, the second hypothesis was easy to test and validate, but the first hypothesis warranted complexities that seemed much more challenging as the SOS hypothesis was originally framed based on mainstream computing systems rather than a minimalist IoT device. With no OS and a very limited computing environment, our original experiment design turned out to be suboptimal, more so now with the benefit of hindsight. However, serendipity has its own way of revealing marvels. The discovery of such a marvel makes these trivial experiments seminal in nature and their interpretation very preliminary, judicious, and guarded.

6. Experiment: Supporting the ZVC Hypotheses

The experiments to support and test the ZVC hypotheses were designed to be conducted remotely at a third-party IMEC laboratory and funded by the European Commission’s Horizon 2020 program’s NGI Fed4Fire+ cascaded funding (Grant Number 732638). Experiments were conducted at the IMEC’s Virtual Wall testbed facility in Ghent, Belgium. These experiments demonstrate the efficacy of the ICOS and SOS modules of ZVC in a highly restricted environment of a USB-mounted, always-connected hardware wallet setting.

6.1. Objectives of This Research

The experiments were designed to support the two hypotheses to achieve zero vulnerability computing. Hence, the following specific objectives were formulated:

(1)

Design a ZVC device based on a MUDP 3.0 chipset with a tiny form factor (~17mm length) that facilitates its permanent mounting on a host computer’s external USB port without damaging the port.

(2)

Build a multi-coin wallet application that supports bitcoins and altcoins as a hardware wallet with cold storage.

(3)

Program the ZVC device to completely obliterate its attack surface using the SOS software for Linux.

(4)

Test and validate ZVC using a mock malware application that fails to write any data to the ZVC device.

(5)

Redesign the MUDP chipset to include a connector on the MUDP PCB that controls power to the chipset.

(6)

Redesign the ZVC device housing to include an external on/off switch that controls its online/offline status.

(7)

Secure the wallet with fully homomorphic encryption (FHE), partially homomorphic encryption (PHE), and standard encryption to create cold, warm, and hot versions, respectively, and establish transition protocols between them.

(8)

Finally, validate the cybersecurity of the ZVC hardware wallet product in a real-world crypto transaction setting.

(9)

Disseminate and exploit the results of the experiments.

The goals of the experiments were planned to be achieved in two stages. The first 4 goals were targeted for the Stage 1 experiments and the remaining 5 to be achieved in the Stage 2 experiments. This report presents the results of the Stage 1 experiments.

6.2. Experiment Details

The main aim of this experiment was to support and test the two ZVC hypotheses, which strive to challenge the well-established rules of computer design. This was accomplished by designing, testing, and validating a minimalist prototype that demonstrates the feasibility of ZVC technology in the highly restricted milieu of a USB-mounted hardware wallet device. The objective of this study was also to identify the limitations and areas of improvement that would make replicating the results in mainstream computers possible. To achieve these goals, we utilized an MUDP 3.0 chip built using NAND Flash memory in a metal housing with an LED indicator to show the online/offline status of the device. Figure 8 shows a photograph of the device with its dimensions.

The device is so tiny that it virtually disappears into the contours of the computer and can therefore remain mounted on the host computer 24/7 without damaging the USB port or the chip. Five units of these devices, along with two units of conventional USB devices as control devices were shipped to a testbed facility in Ghent. The experiments were performed remotely with assistance from the staff of the Virtual Wall 2 testbed of the IMEC labs, who provided the relevant infrastructure with several nodes (Linux computers) for the experiments and also assisted in mounting the devices on the test nodes (interconnected network of Linux computers). The remaining experimental routines were handled remotely. We used the JFed experimental tool to access the nodes remotely and also used the XRDP software to gain remote access to the node (Linux computers) interfaces.

We selected two nodes (Linux computers) for this experiment and marked them as Node0 (target node) and Node1 (hacker node). A ZVC-enabled hardware wallet device and a control device as the standard hardware wallet were mounted on the adjoining USB ports of Node0 or the target node (shown in Figure 9), and the layout of their interfaces accessed using the XRDP software is depicted in Figure 10.

The two selected nodes, Node1 and Node0, were interconnected with the local LAN, and the link between the nodes can be visualized on the interface of the Jfed tool that we used to access these nodes remotely. The following Figure 11 shows the interconnection between the selected nodes.

Node1 was deployed as a hacker node by running a mock malware program designed to remotely infect computers and execute malicious scripts on the victim computer, which in this case is the hardware wallet device mounted on the Node0 computer. Additionally, a conventional USB device was mounted on the third USB port of Node0 as a reference USB device for form factor and operational comparison. The scheme of the mounted devices on Node0 is illustrated in Figure 9. Such a setting simulated a real case scenario where Node0 was a victim computer targeted by the hacker at Node1, wherein both nodes were connected to the Internet. The mock malware running on the hacker Node1 is transmitted to the target victim Node0 and executes its malicious script on all USB devices mounted on Node0 that have unprotected or exposed attack surfaces.

Figure 10. JFed layout of the user interfaces of the test device and the control device mounted on Node0 (target node).

Figure 10. JFed layout of the user interfaces of the test device and the control device mounted on Node0 (target node).

6.3. Experiment Outline

The selected testbed nodes (Linux computers) were remotely accessed using the JFed tool and XRDP software provided by IMEC’s Virtual Wall 2 testbed facilities.

Figure 11. Interconnection between Node0 and Node1.

Figure 11. Interconnection between Node0 and Node1.

The staff of the testbed mounted the experimental devices on the USB ports of the selected node. The JFed tool and XRDP software helped us conduct the experiment remotely by implementing and recording events at both experimental nodes. The mock malware was executed on Node1 or the hacker node and was specially designed to detect, infect, and steal data from any device mounted on any of the USB ports of a victim computer targeted for data breach, which in this case was Node0. A mock malware script was designed to copy the .config folder that contains sensitive user information pertaining to the hardware wallet private key of the target user’s ETH wallet application running from the hardware wallet device. The following figure (Figure 12) shows the presence of the .config file inside both the ZVC hardware wallet and the control device. The presence of the .config folder inside the ZVC hardware device is highlighted with yellow, while that of the control device is shown with blue highlight.

Access to the hardware ETH wallet is authenticated by the private key saved in the .config folder each time the user accesses the ETH wallet account. Anyone in possession of a private key would thus have access to the target user’s ETH wallet. Hence, a hacker’s obvious goal would be to steal the private key; therefore, the mock malware was designed to identify hardware wallets mounted on the USB port of the target node and run a script on the victim device to copy the .config folder containing the ETH wallet’s private key. Such copied data are sent to Node1 (hacker node). Figure 13 shows the command line interface to transfer the malware from Node1 (hacker node) to Node0 (target node) and get the sensitive data out of the USB device connected to Node0.

The ZVC-powered hardware wallet with the SOS and ICOS modules (hereinafter referred to as ZVC) was mounted on the first USB port of the target Node0, and another similar hardware wallet without a ZVC program was mounted on Node1, i.e., the target node’s second USB port. The former ZVC device served as the test device, and the latter served as a control device. A third USB port on target Node0 had mounted a conventional USB device, which served as a reference device to compare the form factor and operational integrity of the node. The mock malware application was executed on hacker Node1, which identifies target Node0 and infects any hardware device mounted on the USB ports of the target node.

The control device (Case1) and ZVC test device (Case2), mounted on the target nodes, were tested for their hardware wallet integrity using a Ropsten network (also known as “Ethereum Testnet”). Ropsten is an Ethereum test network that allows blockchain development testing before deployment on Mainnet, the main Ethereum network [44]. It is also an ideal test net for recording ERC20 transactions via the ETH wallet, as illustrated in the following scenarios:

Case1: The permanently mounted control device mounted on the target Node0 has a standard cryptocurrency wallet connected to the Internet 24/7. The wallet application was launched to log in using the private key fetched from the .config folder and perform an ETH transaction on the Ropsten Testnet. Contemporaneously, the malware script ran on the hacker Node1. The activities of both nodes were monitored and recorded to first confirm that the wallet transaction was completed at the target Node0 and, second, the mock malware script at hacker Node1 was running, as well as if the .config folder containing sensitive user information (wallet private keys) was transmitted back to the hacker Node1 from the target Node0.

Case2: In the second experiment, the permanently mounted ZVC device on the target Node0 was switched online only when the wallet application was launched to log in using the private key fetched from the .config folder and performed an ETH transaction on the Ropsten Testnet. The ZVC device went offline immediately after the wallet transaction was executed. Contemporaneously, the malware script ran on the hacker Node1. The activities of both nodes were monitored and recorded to first confirm that the wallet transaction was completed at the target Node0; second, we ensured that the mock malware script at the hacker Node1 was running, and third, we checked if the .config folder containing sensitive user information (private keys) was transmitted back to the hacker node from the target node. A total of five transactions were recorded with the following binary key performance indicators (KPIs):

• Data offline while ZVC device is mounted on PC and wallet application not running: Yes/No;
• Data online while mounted ZVC device runs wallet application: Yes/No;
• Data always online while control device is mounted on PC: Yes/No;
• Mock malware able to copy/run malicious code on the control device: Yes/No;
• Mock malware not able to copy/run malicious code on ZVC device. Yes/No.

6.4. Experiment Result

All five KPIs returned a “Yes” outcome in all five repeats of the Case1 and Case2 implementations of the experiments. In the Case1 implementation, the mock malware script infected the control device on the target node and executed the script on the control device. This was evidenced by the transmission of a copy of the “.config” folder from the target node to the hacker node. This can be visualized in Figure 14, where the UI of both the target node and hacker node shows the presence of the .config folder on both selected nodes (marked in blue). On the other hand, in the Case2 implementation, the ZVC-powered hardware device remained uninfected by the malware script as the SOS software component of ZVC obliterates the attack surface completely by banning all third-party permissions from installing or running any program except the native wallet application. This was observed in the absence of a .config folder (highlighted yellow) on the hacker node UI.

Even after the continuous attempts to infect the ZVC hardware wallet device, the malware failed to find an attack surface to install and run malicious scripts on the ZVC hardware wallet device. Moreover, the ZVC device remained online only during the wallet transaction activity and switched offline despite being mounted on the USB port 24/7. The ability of the malicious program to copy files from the USB location of the target node to the hacker node when the control device was mounted can be attributed to the absence of the ZVC ecosystem, whereas the inability of the same mock malware program to perform any action on the ZVC device connected to the USB port of the same target node can be attributed to the unhackable environment created by the obliteration of the attack surface resulting from the denial of third-party permissions by the ZVC approach.

Thus, our experiments answered both hypothetical questions that we set out to support and test affirmatively.

Hypothesis 1:

Can Supra OS software (SOS) completely obliterate the primary attack surface by denying third-party permissions to all non-native applications? Yes

Hypothesis 2:

Can a hardware module isolate critical data that require sporadic access to offer in-computer offline storage (ICOS) within the connected device itself without compromising its functionality? Yes

7. Results’ Interpretation and Discussion

Our original disclosure of ZVC described Supra OS (SOS) [45], which obliterated a computer’s attack surface, and in-computer offline storage (ICOS) [46] as components of the ZVC framework. Such disclosures were essentially in reference to mainstream computing devices, such as laptops and desktops. However, during our experimentation at IMEC labs with the ZVC hardware wallet device, we had to implement the SOS directly on the NAND Flash firmware, as there was no OS involved. We discovered that such an implementation was more efficient and secure and that ZVC can be directly implemented on non-volatile NAND Flash memory without having to piggyback on any legacy firmware or OS. Because such an approach eliminates all the variables introduced by the complex multilayered legacy computing architecture, it is simpler and easier to control the attack surface of IoT devices with limited processing power.

Complexities and a multitude of variables create a situation similar to the pre-solid-state electronics era, wherein moving parts in electronic devices of that era made the devices fragile, bulky, energy inefficient, and vulnerable to external risks. The advent of solid-state technology in the 1960s-1970s revolutionized electronics and made portable computing devices possible today. Although some device manufacturers tend to market their computing devices as solid-state simply because their devices are built using one or more of their components using solid-state hardware components, they cannot really be called solid-state, as these devices run multi-layered legacy software systems. The multi-layered legacy software system running on any device introduces variabilities and, consequently, vulnerabilities to the devices. The more complexities and variabilities present in a software system, the more vulnerable it becomes. The layered architecture of traditional computers introduces complexities and variability. The variabilities in the layered architecture of legacy software systems are analogous to those in the moving parts of electronic devices. Because ZVC essentially bans all third-party permissions at each layer of the legacy computers, thereby merging all the layers between the hardware and human–computer interface (HCI), it creates a scenario akin to no moving parts of solid-state electronics. Hence, the direct implementation of ZVC on the nonvolatile memory chip of a computing device eliminates the need for piggybacking on the firmware of the device or the OS. This can potentially lead to the conceptualization of a radically novel concept of solid-state software-on-a-chip (3SoC) with no conventional distinguishable layers of firmware, drivers, OS, and application (all moving parts) between the hardware and the HCI. This 3SoC approach creates a compact solid-state software milieu that is ideal for IoT devices with limited resources. Moreover, because IoT devices are mostly single-purpose devices with little or no need for third-party applications to run on them, banning all third-party permissions would not adversely affect their usability.

As illustrated in Figure 15, the multilayered legacy computing system is built on granting third-party permissions at each layer, thus allowing an attack surface at each layer to simulate a situation analogous to the moving parts scenario of old-generation electronic devices. Thus, the proposed ZVC ecosystem can merge all the layered components in the legacy software by banning all third-party permissions, thus obliterating the attack surface and rendering it free of vulnerabilities.

Although our ZVC hardware wallet experiments supported and tested the two ZVC hypotheses and met the objectives of the study, the results must be interpreted with caution, warranting further rigorous validation of the concept beyond the limited environment of these experiments. If we had the advantage of hindsight, our experimental design, which revolved around the mainstream computing architecture, would have been more relevant to the tested hardware wallet IoT device. In our current experiments, the ZVC software was installed on the NAND chip firmware with the following caveats:

First, the obliteration of the attack, although adequate for the device tested, may not be complete, as the hardware supplier’s firmware may remain a source of third-party permissions, and therefore vulnerable.

Second, the restricted environment and limited processing power of a hardware wallet IoT device limit the extrapolation of the results to more complex mainstream computers.

Third, although zeroing of the attack surface and maintaining sensitive data offline in a connected device may address most cyber-attacks, this cannot rule out the possibility of side-channel attacks if the connected device remains physically accessible to a hardware hacker and remains operational during the attack.

Fourthly, although the experimental results led to the formulation of two new hypotheses (Section 6), the device we developed technically neither qualifies as quantum-resistant, nor as solid-state software-on-a-chip (3SoC) as the 3SoC hypothesis we formulated for future research defined in Section 9.

Finally, the results of this research helped us fine-tune the definition of ZVC:

ZVC is a cybersecurity paradigm that proposes a new zero attack surface computer architecture that restricts all third-party applications exclusively to a web interface only, declining permissions for any utilization of computing resources by any non-native program and creates a switchable in-computer offline storage for securing sensitive data at the user’s behest.

8. Work Limitations

With the advantage of hindsight, we realize that our experiment design was not as rigorous and meticulous as such a far-reaching concept deserves. This is essentially because our original approach was designed as the Supra OS (SOS), which obliterates the attack surface of a computer’s operating system to provide one more tool to the cybersecurity arsenal. We had absolutely no apprehension that the concept would evolve to challenge the very architecture of computing systems and propose a radical paradigm shift in designing future computers. The fact that all legacy hardware and all software were inherently designed to grant third-party permissions was not on our radar screen when we designed the experiments. Third-party permissions can be exploited at the hardware and firmware level besides the OS and the application layer. Broadening the scope of the SOS beyond the OS had sweeping consequences. Moreover, the experiments were designed to support the hypothesis and not to prove the hypothesis. For these reasons, therefore, the results should be interpreted with great care and caution. More rigorous validation is warranted before extrapolating the results in real-world scenarios.

9. Future Prospects and New Hypotheses

ZVC is a radically novel concept that needs to be extensively researched to explore its possible implementation beyond the limited use of a hardware wallet. Our experiments tested the technological feasibility of the ICOS and SOS modules of the ZVC in a highly restricted environment of a USB-mounted always-connected device setting. The ICOS module keeps the data secure offline, except when required for processing. The SOS module completely obliterates the attack surface on the hardware wallet by banning third-party permissions. While these findings are preliminary, demonstrating the potential feasibility of the ZVC concept, further validation in more challenging mainstream computing environments is urgently required. Moreover, the results of this study also suggest exploring the ZVC approach in two distinct areas of concern in computer research, which can be defined by formulating two new hypotheses as follows:

• Because ZVC security is encryption-independent, will it be quantum-resistant by design?
• As the ZVC architecture lacks layering, rendering it conceptually analogous to the zero moving parts nature of solid-state electronics, will it deliver the same advantages to computers as solid-state electronics did to revolutionize the electronics industry in the 1960s–1970s?

Given the robustness, energy efficiency, portability, and resilience that solid-state electronics introduce to any product, there is an urgent need to test and validate these hypotheses. If the 3SoC concept is established, it has the potential to emulate the same level of revolutionary success as the solid-state concept achieved in the electronics industry, which made modern-day gadgets possible. Testing and validating these hypotheses will have an unfathomable impact on the design of future computers and will revolutionize cybersecurity.