limits to verifiability

[ahojlm at 0w.se]

Hello everyone,

It looks like reproducibility is not only a means of protection against
supply chain attacks, but also an important prerequisite for producing
trustable binaries in general.

It is crucial e.g. when the amount of a priori trust in computer systems
is to be reduced by use of open-source pre-boot software, when building
that software. Without reproducibility and a consensus on the contents
of the artifacts, certainty about their integrity is inherently limited.

These observations do not seem to be widely mentioned, I hope
that such a discussion is relevant for this forum.

--------------------------------------------------------------------
Reflections on limits to verifiability of software integrity and on
the role of reproducibility

Summary
-------

This discourse explores the absolute and/or practical limits to
assurance of software integrity. **Reproducibility** appears to be
crucial to be able to strongly assert integrity of artifacts. The
analysis emphasizes that human consensus plays a fundamental role in
application of reproducibility.

Moreover, combined with checking of consensus between *diverse
installations*, reproducibility allows to assert the artifact integrity
even in the absence of knowledge about the integrity not only of the
software but also of the *hardware* used to generate the artifacts. This
allows generation of a **known-good starting-point toolchain**, where
“toolchain” is explicitly defined to include all post-boot software
needed for source-to-binary translation, i.e. kernel, general purpose
utilities etc.

Under assumption that less than majority of the used installations are
corrupted specifically to execute an attack against the checking, a
majority consensus provides complete integrity assurance. Diversity of
the initial toolchains makes it plausible that the majority could not be
able to collude in an attack.

Known approaches which do not specifically imply *both* reproducibility
*and* comparison between independent builds, provide a level of
integrity assurance of the resulting artifacts limited by the integrity
of the a priori trusted prerequisites for *running* of programs, which,
at the very minimum, includes hardware. As an example, binary-seed-based
solutions can not exceed the *lowest* of the integrity levels of the
binary seed, of the pre-boot software and of the hardware being used.
--------------------------------------------------------------------

Feedback and pointers to similar analyses will be appreciated.

Regards,
 an
-------------- next part --------------
A non-text attachment was scrubbed...
Name: limits_to_verifiability.md
Type: text/markdown
Size: 22270 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20231123/7a322b70/attachment.md>