Measurement Mechanism

Our measurements mechanism consists of a base measurement when a new executable is loaded and the ability to measure other executable content and sensitive data files. The idea is that BIOS and bootloader measure the initial kernel code and then enable the kernel to measure changes to itself (e.g., module loads) and the creation of user-level processes. The kernel uses the same approach with respect to user-level processes, where it measures the executable code loaded into processes (e.g., dynamic loader and httpd loaded via mmap). Then, this code can measure subsequent security sensitive inputs it loads (e.g., configuration files or scripts measured by httpd). The challenger's trust is dependent on its trust in the measured code to measure its security sensitive inputs, protect itself from unmeasured inputs, and protect data it is dependent upon across reboots. The operating system can provide further protection of applications through mandatory access control policy which can limit the sources of malicious, unmeasured inputs and protect data from modification. However, the use of such policy is future work.

In this section, we discuss how measurements are made. The application of these measurements to a complete measurement system is described in Section 5.

To uniquely identify any particular executable content, we compute a SHA1 hash over the complete contents of the file. The resulting 160bit hash value unambiguously identifies the file's contents. Different file types, versions, and extensions can be distinguished by their unique fingerprints.

The individual hashes are collected into a measurement list that represents the integrity history of the attesting system. Modifications to the measurement list are not permissible as that would enable an attacker to hide integrity-relevant actions. As our architecture is non-intrusive, it does not prevent systems from being corrupted, nor does it prevent the measurement list from being tampered with afterwards. However, to prevent such malicious behavior from going unnoticed (preventing corrupted systems from cheating), we use a hardware extension on the attesting system, known as Trusted Platform Module, to make modifications of the measurement list visible to challenging parties.

The TPM [11] provides some protected data registers, called Platform Configuration Registers, which can be changed only by two functions: The first function is rebooting the platform, which clears all PCRs (value 0). The second function is the $TPM\_extend$ function, which takes one 160bit number $n$ and the number $i$ of a PCR register as arguments and then aggregates $n$ and the current contents of PCR[$i$] by computing a SHA1(PCR[$i$] $\vert\vert$ n). This new value is stored in PCR[$i$]. There is no other way for the system to change the value of any PCR register, based on our assumptions that the TPM hardware behaves according to the TCG specification and no direct physical attacks occur.

We use the Platform Configuration Registers to maintain an integrity verification value over all measurements taken by our architecture. Any measurement that is taken is also aggregated into a TPM PCR (using $TPM\_extend$) before the measured component can affect and potentially corrupt the system. Thus, any measured software is recorded before taking control directly (executable) or indirectly (static data file of the configuration). For example, if $i$ measurements $m_1..m_i$ have been taken, the aggregate in the chosen PCR contains $SHA1(..SHA1(SHA1(0 \vert\vert m_1) \vert\vert m_2).. \vert\vert m_i$). The protected storage of the TPM prevents modification by devices or system software. While it can be extended with other chosen values by a corrupted system, the way that the extension is computed (properties of SHA1) prevents a malicious system from adjusting the aggregate in the PCR to represent a prescribed system. Once a malicious component gains control, it is too late to hide this component's existence and fingerprint from attesting parties.

Thus, corrupted systems can manipulate the measurement list, but this is detected by re-computing the aggregate of the list and comparing it with the aggregate stored securely inside the TPM.