Concluding whether to trust or distrust an attesting system is based on testing each measurement list entry independently, comparing its measurement value with a list of trusted measurement values. More sophisticated validation models can relate multiple measurements to reach an evaluation result. Testing measurement entries is logically the same regardless of whether the entry is code or data. The idea is that the entry matches some predefined value that has known integrity semantics. Unknown fingerprints can result from new program versions, unknown programs, or otherwise manipulated code. As such, fingerprints of program updates can be measured by the challenging party and added to the database; in turn, old program versions with known vulnerabilities [15] might be reclassified to distrusted.
The challenging party must have a policy in place that states how to classify the fingerprints and how to proceed with unknown or distrusted fingerprints. Usually, a distrusted fingerprint leads to distrusting the integrity of the whole attesting system if no additional policy enforcement mechanisms guarantee isolation of the distrusted executable. Alternatively, trustworthy fingerprints can be signed by trusted third parties, e.g., regarding their suitability to enforce certain security targets (Common Criteria Evaluation) related to their purpose.
Transaction Integrity Usually, the integrity of the attesting system is of interest when it processes a transaction that is important to a challenging party. To verify the integrity of a transaction that is taking place between the challenging and the attesting party (e.g., a Web request), the challenging party can challenge the integrity of the attesting system before and after the transaction was processed, e.g., before sending the Web request and after receiving the Web response. Then, the attestation and the transaction can be bound to the same system by securely linking the certificate used to validate the TPM quote and the certificate used to authenticate the server during the SSL connection setup as part of the Web request. If the attesting system is trusted both times, then- so it seems -the transaction can be trusted, too.
This is, however, not entirely true because it assumes that both measurements have taken place in the same epoch (validity period), i.e., that any system change throughout the transaction would have been recorded in the second measurement. However, the attesting system could have been compromised just after the first challenge and before the transaction took place. Then, the attesting system could have rebooted before the second challenge took place. Thus, though trusted at two points in time, the reboot covered the distrusted attesting system state against the challenger. Even if the possibility seems small, systems can reboot very fast and actually come up into an exactly pre-defined state (thus exhibiting the same measurement list as in earlier measurements) 1.
Fortunately, there is a way to discover if an epoch changes, i.e., whether the system rebooted between two attestations. For this purpose, we can use so-called TPM counters. As opposed to the PCRs, these counters are never cleared or decreased but can only increase throughout the lifetime of a TPM. Increases of one of these counters could be triggered by the BIOS each time the system reboots. The BIOS is also responsible to disable the TPM as soon as the counter has reached its maximum value. Typical TPM have multiple counters that can be combined and thus are sufficient for normal platform lifetimes 2. Thus, a trusted kernel including such a counter into the measurement list ensures that the prefixes of two measurement lists differ at least in this single counter measurement once the system is rebooted.
Consequently, in this enhanced version, transaction integrity can be validated by ensuring that the measurement list validated at the first challenge before the transaction is a prefix of the measurement list validated at the second challenge after the transaction. Then, the system did not reboot and thus (given our assumptions) any distrusted system component potentially impacting the transaction on the attesting system, would show in the measurement list of the second challenge. In effect, our architecture does not offer predictable security as long as it is non-intrusive, yet it can offer retrospective assurance of the integrity state of a system.