Trusted Computing and the Enterprise Software Ecosystem: Part 2 (of 7)

1.1 Trusted Computing Group

The problem of trust in computing platforms has been directly addressed by the Trusted Computing Group (TCG)[2], an industry consortium formed in 2003 to create standards “with the aim of enhancing the security of the computing environment in disparate computer platforms.”[3]

TCG defines the notion of trust as “the expectation that a device will behave in a particular manner for the specific purpose”.[4] For example, it is the expectation that our kitchen refrigerator will cool its contents to the level specified by its thermostat, no more (interfering with the contents placed within, spying on users opening the door, borrowing electricity to transmit wireless messages) and no less (failing to cool during early morning hours, changing the thermostat settings unpredictably). With reference to the malware discussion above, it is the assurance that only and exactly the software one expects to be running on their computer is, in fact, running, and in unmodified form. In other words, what we assume of our software is only and precisely what is the case.

But how can how can anyone guarantee the integrity of a computer’s software? Here TCG offers the powerful notions of integrity measurements and root of trust.

An integrity measurement of a computer program image (or, more generally, a block of data) is a cryptographic hash (e.g., SHA-1[5]) expressed as a fixed-length numerical value. Such hash functions have several nice properties: they are easy to compute, it is computationally infeasible to reconstruct the original data from the hash, collisions are extremely unlikely, and any change to the original data (even a single bit) will result in a significant change to the resulting hash value. In short, a cryptographic hash provides a robust fingerprinting mechanism for establishing the identity of a particular program image or block of data.

The notion of a “root of trust” needs to be understood in the context of a “chain of trust”, also known as “transitive” or “inductive” trust.[6] A complex software environment is composed of numerous independent software components, some of which are involved in the process of booting the system and establishing core operating system functionality. Suppose we could establish trust for the very first component taking control of the system by taking an integrity measurement if its image and confirming its signature or fingerprint. That component, if it passes, could then reliably be used to test the next component in the same way, thus extending trust to the next component. In this way, the software associated with launching an entire system could be systematically measured in a transitive manner, thus establishing a “chain of trust” through which we can, module by module, verify the integrity of a multi-component software environment.

A key challenge in this scheme, of course, is what to use as the initial root of trust from which all transitive trust will follow. The answer is a new piece of hardware known as the Trusted Platform Module, or TPM.

[3] TCG Specification Architecture Overview. Specification Revision 1.4, 2nd August 2007.
[4] TCG Specification Architecture Overview, p. 5.
[5] Secure Hash Standard. Federal Information Processing Standards (FIPS) Publication 180-1. April 1995.
[6] TCG Specification Architecture Overview, p. 7.