Any point of potential compromise within the information supply chain may invalidate all assumptions of security & confidentiality.
The software distribution supply chain should be relatively easy to protect through provenance records maintained in an immutable Blockchain, which allow consumers to validate virtual machine images that implement specific functionality within a Unikernel.
One might reasonably expect to protect the virtualisation system distribution using the same approach, although user validation of the distribution requires a trusted system, operated by a trusted person, and any installation of the distribution requires process validation.
Process validation needs to start with the assurance of the trusted system, which implies a chicken & egg problem, because the assurance evidence requirement is recursive.
However, the potential risk could be significantly mitigated by independent validation using a number of partially trusted systems, assuming the installation process could be adequately validated.
In contrast, potential vulnerabilities in the hardware and firmware require a fundamentally different approach, because there is no known mechanism for validating the inputs, so we are forced to require validated design & production of the device, and there are no known mechanisms for such validation that are believed to be viable in the real world.
The reality of this situation is that we are forced to accept that the physical hardware components may be compromised, with no possibility of positive validation.
The only viable approach in such circumstances is to assume that the hardware components are compromised and attempt to analyse the potential impacts on the security of systems that include such components.
One factor that works in our favour within such analysis is the realisation that compromise of hardware components is likely to be relatively expensive and would be rendered ineffective, if the compromise could be discovered by external observation of the component in operation.
In other words, we could design experiments to test the externally visible behaviour of the component, which could be used to validate component behaviours against those of equivalent components from other manufacturers or with different provenance characteristics.
In particular, we might reasonably compare the behaviour of processor boards manufactured in the UK, US, Germany, South Korea, Taiwan, China and Russia when running “the same” virtualisation software, which could be applied at a slightly higher level to components running different virtualisation software.
We would expect such experiments to identify variations in the observable behaviours between components, so we could reasonably assert some level of assurance from verified observations of behavioural equivalence between components.
Such experiments do not preclude the possibility that the components share untrustworthy common characteristics, so it would be reasonable & highly desirable to analyse any common derivations in the sub-component technologies for potentially compromisable elements.
However, we should also take into account the number of actors that might plausibly effect such compromise, and the socio-economic & political factors that might be expected to influence their motivation and actual deployment.
This line of reasoning leads to a plausible proposal for an effective validation system, which compares the observable behaviour of multiple “untrusted” components that have been acquired from diverse sources over an extended period of time, in order to provide assurance of behavioural equivalence.
Open source specifications for such validation systems might reasonably be maintained within an immutable blockchain, together with evidence of independence testing and security review.
This introduces the realistic possibility that independent system integrators could implement such validation systems and integrate their usage into the delivery process for validated systems.
It also introduces the realistic possibility that the operational business processes for implementing such validation could be documented, distributed and reviewed using the immutable Blockchain.
This in turn creates a new requirement for security and quality auditing of such system integrators, which could provide assurance evidence that could also be documented in the immutable Blockchain.
Hence, we are not just proposing a technical mechanism for maintaining assurance records in an immutable Blockchain, but we are also proposing a social mechanism for integrating such technical assurance within the wider supply chain ecosystem.