A significant consideration in interaction between computing entities is trust—whether a foreign computing entity will behave in a reliable and predictable manner, or will be (or already is) subject to subversion. Trusted systems which contain a component at least logically protected from subversion have been developed by the companies forming the Trusted Computing Group (TCG)—this body develops specifications in this area, such are discussed in, for example, “Trusted Computing Platforms—TCPA Technology in Context”, edited by Siani Pearson, 2003, Prentice Hall PTR. The implicitly trusted components of a trusted system enable measurements of a trusted system and are then able to provide these in the form of integrity metrics to appropriate entities wishing to interact with the trusted system. The receiving entities are then able to determine from the consistency of the measured integrity metrics with known or expected values that the trusted system is operating as expected.
Integrity metrics will typically include measurements of the software used by the trusted system. These measurements may, typically in combination, be used to indicate states, or trusted states, of the trusted system. In Trusted Computing Group specifications, mechanisms are taught for “sealing” data to a particular platform state—this has the result of encrypting the sealed data into an inscrutable “opaque blob” containing a value derived at least in part from measurements of software on the platform. The measurements comprise digests of the software, because digest values will change on any modification to the software. This sealed data may only be recovered if the trusted component measures the current platform state and finds it to be represented by the same value as in the opaque blob.
It will be appreciated that any change in software will cause a number of problems, both with this specific process and more generally where measurement of software is taken as representative of the state of a computer system—however small the change to the software, effective forms of measurement (such as digests) will give different values. In the example of “sealing” above, this means that changes to software—which may be entirely desirable, for example to improve functionality or to remove bugs and weaknesses—have the disadvantage of preventing continued access to sealed data. This is only one exemplary problem, however—there is a general difficulty in having the same trust in new or replacement software as was had in original software, this general difficulty having attendant practical difficulties in maintaining functionality based on that trust.
It is desirable to find a way to update or change software that is trusted to provide continuity in trust as well as in software functionality.