Our architecture uses the TPM's protected storage to protect the integrity of the measurement list. Once a measurement is taken, it cannot be changed or deleted without causing the aggregate hash of the measurement list to differ from the TPM aggregate. However, the challenging party must also ensure that the attesting system has the measurement architecture correctly in place so that all necessary measurements are actually initiated and carried out. As our architectural components are measured as well when they are executed, challenging parties can determine whether the architecture is in place by inspecting these measurements.
The major portion of the measurement architecture is in the static kernel. Thus, the challenging party trusts only such kernels that implement the kernel part of our measurement architecture. Other kernels will be unacceptable to challenging parties because they can skip important measurements.
If instrumented insmod and modprobe programs measure kernel
modules before they are loaded into the kernel, then only kernel
module loaders instrumented with the measure call are
acceptable. If a fingerprint of any other program with insmod
functionality is seen, then it must not be trusted and thus the
validation fails. This does not apply in our case because we measure
kernel modules in the kernel. If we require shell programs to measure
script and source files before they are loaded or executed, then
discovering a fingerprint of a shell that is not instrumented with
measure calls must not be trusted. Known fingerprints of any
other part of the system can be trusted according to known
vulnerabilities of corresponding executables as described in
Section 4.4. Unknown fingerprints could result
from changed user level programs that are assumed to measure their
input (e.g., bash), or unacceptable input files and cannot be trusted
as their corresponding program's functionality is potentially
malicious and might violate security assumptions.