# Will Zero Vulnerability Computing (ZVC) Ever Be Possible? Testing the Hypothesis
## 5 ZVC Hypotheses: New World, New Rules
### 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 Figures 4b,d and 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. Figure 4: **(a)** In the traditional computing system, the third-party permissions create primary and secondary attack surfaces that bad actors exploit to breach the computer. **(b)** Zero vulnerability computing (ZVC) completely obliterates the attack surface to achieve a zero attack surface. **(c)** Conceptual diagrammatic representation of primary and secondary attack surfaces. **(d)** Diagrammatic representation of SOS obliterating the attack surface and providing a web interface. **(e)** ICOS with a soft switch and LED indicator. **(f)** ICOS operation with a hard toggle switch. Figure 5: Comparison of architectural constructs of 3 rd party permissions and attack surface between legacy IoT systems and ZVC. 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 Figures 4e,f and 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.