Check out the new USENIX Web site. next up previous
Next: Measurement Mechanism Up: Design of an Integrity Previous: Design of an Integrity

Assumptions

Before we describe these three components of our architecture, we establish assumptions about the attacker model because without such restrictions, there would always be attackers that are able to fool a remote client.

We use services and protection offered by the TCG standards [11] in order to: (1) enable challenging parties to establish trust into the platform configuration of the attesting system (measurement environment) and (2) ensure challengers that the measurement list compiled by the measurement environment has not been tampered with. We assume that the TPM hardware works according to the TPM specifications [11] and that the TPM is embedded correctly into the platform, ensuring the proper measurement of the BIOS, bootloader, and following system environment parts.

The TPM cannot prevent direct hardware attacks against the system, so we assume that these are not part of the threat model.

We assume that code measurements are sufficient to describe its behavior. Thus, self-changing code can be evaluated because the intended ability of code to change itself is reflected in the measurement and can be taken into account in verification. The same holds for the kernel code that is thought to be changed only through loading and unloading modules. Kernel changes based on malicious DMA transfers overwriting kernel code are not addressed; however, the code setting up the DMA is measured and thus subject to evaluation.

We also assume that the challenging party holds a valid and trusted certificate binding a public RSA identity key $AIK_{pub}$ of the attesting system's TPM. $AIK_{pub}$ will be used by the challenging party to validate the quoted register contents of the attesting system's TPM before using those registers to validate the measurement list.

We assume that there are no confidentiality requirements on measurement data that cannot be satisfied by controlling the access to the attestation service.

Finally, for the interpretation of system integrity measurements, we rely on the challenger's run-time because the validation results must be securely computed, interpreted, and acted upon. We assume that the challenger can safely decide which measurements to trust either by comparing them to a list of trusted measurements or by off-loading the decision to trusted parties that sign trusted measurements according to a common policy (i.e., common evaluation criteria).


next up previous
Next: Measurement Mechanism Up: Design of an Integrity Previous: Design of an Integrity
sailer 2004-05-18