Techniques for attesting data processing systems

This application is a National Stage of International Application No. PCT/EP2011/066329 (which has a priority date of Nov. 18, 2010), entitled “A METHOD FOR ATTESTING A PLURALITY OF DATA PROCESSING SYSTEMS,” filed Sep. 20, 2011, the disclosure of which is hereby incorporated herein by reference in its entirety for all purposes.

BACKGROUND

The disclosure generally relates to data processing systems and, more specifically, to techniques for attesting data processing systems.

Trusted boot is a process for booting and establishing a chain of trust in a computing system. With reference to data processing environment <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref>, for example, a system administrator takes delivery of a server (e.g., managed system <b>120</b>) and proceeds to install system software. Managed system <b>120</b> includes a secure device <b>125</b>, e.g. a Trusted Platform Module (TPM). Once managed system <b>120</b> is configured and booted, each component (hardware and/or software) of managed system <b>120</b> cryptographically measures another component and can “extend” (but not directly write to) a measurement value in a platform configuration register (PCR) of TPM <b>125</b>.

Each component is also operable to access an event log in order to write data associated with the measurement of a component into an entry associated with the event log. The measurements can be remotely attested by a managing system <b>105</b> which has a database <b>115</b> to store expected attestation values for components of each managed system. The values are typically stored along with some metadata describing what the values mean. Managing system <b>105</b> includes a TPM emulator <b>110</b> that, for example, compares the measurements with the values. If there is no match between the measurements and the values, typically, managing system <b>105</b> has to further compare the measurements against a (large) list (e.g., a reference manifest) of measurement values provided by manufacturers of components. Typically, a reference manifest includes a large number of measurement values associated with each component of managed system <b>120</b> and these measurement values can be taken to be ‘trusted’.

The remote attestation process may be initiated by either a managing or managed system. Changes to managed system <b>120</b> can be detected by subsequent trusted boot and remote attestation processes. The above processes are described, for example, in section 4 of the Trusted Computing Group (TCG) Specification Architecture Overview; Specification; Revision 1.4; 2nd Aug. 2007 and section 2 of the TCG Infrastructure Working Group Architecture Part II—Integrity Management; Specification Version 1.0; Revision 1.0; 17th Nov. 2006.

As described above, attestation is currently concerned with verifying a single machine, be it a physical machine with a real TPM or a virtual machine (VM) with a virtual TPM. Verifying individual machines is a reasonable approach for owners of individual machines. However, end-users or corporations may deal in a granularity much larger than a single machine. For example, a large corporation may wish to attest each of its VMs on a particular physical machine, each of its VMs within a particular machine pool, or each of its physical machines at a particular site. Similarly, datacenter owners may care about the integrity of their entire datacenter (and possibly sub-clusters within the entire datacenter). Instead of single machines, an entity may be concerned with tens, hundreds or even thousands of machines.

SUMMARY

A technique for attesting a plurality of data processing systems includes generating a logical grouping for a data processing system. The logical grouping is associated with a rule that describes a condition that must be met in order for the data processing system to be considered trusted. A list of one or more children associated with the logical grouping is retrieved. The one or more children are attested to determine whether each of the one or more children is trusted. In response to the attesting, the rule is applied to determine whether the condition has been met in order for the data processing system to be considered trusted. A plurality of logical groupings is associated to determine whether an associated plurality of data processing systems can be considered trusted.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and is not intended to be limited by the accompanying figures, in which like references indicate similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a data processing environment configured to carry out trusted boot and remote attestation processes;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram showing components of a managed system;

<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of a data processing environment for carrying out trusted boot and remote attestation processes;

<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart of a remote attestation process;

<figref idref="DRAWINGS">FIG. 5A</figref> is a block diagram showing a physical organization of machines within a typical datacenter, according to one embodiment of the present disclosure;

<figref idref="DRAWINGS">FIG. 5B</figref> is a block diagram showing a logical hierarchy of the physical organization of the machines of <figref idref="DRAWINGS">FIG. 5A</figref> according to one embodiment of the present disclosure;

<figref idref="DRAWINGS">FIGS. 5C and 5D</figref> are block diagrams showing functional dependencies associated with components of the datacenter of <figref idref="DRAWINGS">FIG. 5A</figref>; and

<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart showing an attestation process according to the one embodiment of the present disclosure.

DETAILED DESCRIPTION

As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as a method, system, device, or computer program product. Accordingly, the present invention may take the form of an embodiment including hardware, an embodiment including software (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a circuit, module, or system. The present invention may, for example, take the form of a computer program product on a computer-usable storage medium having computer-usable program code, e.g., in the form of one or more design files, embodied in the medium.

Any suitable computer-usable or computer-readable storage medium may be utilized. The computer-usable or computer-readable storage medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable storage medium include: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM) or flash memory, a portable compact disc read-only memory (CD-ROM), an optical storage device, or a magnetic storage device. As used herein, the term “coupled” includes a direct electrical connection between elements or blocks and an indirect electrical connection between elements or blocks achieved using one or more intervening elements or blocks.

According to a first aspect of the present disclosure, a method for attesting a plurality of data processing systems includes generating a logical grouping for a data processing system. The logical grouping is associated with a rule that describes a condition that must be met in order for the data processing system to be considered trusted. The method also includes retrieving a list of one or more children associated with the logical grouping and attesting the one or more children in order to determine whether each of the one or more children are trusted. In response to the attesting, the rule is applied in order to determine whether the condition has been met for the data processing system to be considered trusted. Finally, the method includes associating a plurality of logical groupings to determine whether an associated plurality of data processing systems can be considered trusted.

According to a second aspect of the present disclosure, an apparatus for attesting a plurality of data processing systems includes logic for generating a logical grouping for a data processing system. The logical grouping is associated with a rule that describes a condition that must be met in order for the data processing system to be considered trusted. The apparatus also includes logic for retrieving a list of one or more children associated with the logical grouping and logic for attesting the one or more children in order to determine whether each of the one or more children are trusted. The apparatus further includes logic for applying the rule in order to determine whether the condition has been met for the data processing system to be considered trusted. Finally, the apparatus includes logic for associating a plurality of logical groupings to determine whether an associated plurality of data processing systems can be considered trusted.

According to a third aspect of the present disclosure, a computer program includes computer program code stored on a computer readable medium to, when loaded into a computer system and executed thereon, cause the computer system to perform the method described above with respect to the first aspect of the present disclosure.

With reference to <figref idref="DRAWINGS">FIG. 2</figref>, a managed system <b>200</b> is illustrated. During a trusted boot process, each component of managed system <b>200</b> cryptographically measures (e.g., using secure hash algorithm (SHA) to create a hash of information such as a software file, a model, make, serial number of a component, etc. in order to create a measurement value) another boot component. As one example, a core root of trust for measurement (CRTM) component <b>220</b>, e.g., a BIOS, is the first piece of code which is given control during boot and must be implicitly trusted as it is immutable. CRTM <b>220</b> cryptographically measures the next component in the boot process (e.g., firmware <b>215</b>). Subsequently, firmware <b>215</b> measures the next component in the boot process (e.g., operating system (OS) <b>210</b>) and OS <b>210</b> then measures any user space programs <b>205</b> before control is transferred to any of user space programs <b>205</b>. Each component can “extend” (but not directly write to) a measurement value in a platform configuration register (PCR) <b>230</b> of TPM <b>225</b> before control is transferred to the measured component.

An extend operation includes a cryptographic combination of a current value of the PCR <b>230</b> and a measurement value (signed with a public/private key pair of the managed system <b>200</b> with the private key being known only to TPM <b>225</b>. Each component is also operable to access an event log <b>235</b> in order to write data associated with the measurement of a component (e.g., metadata (such as a component identifier and an event) and an associated measurement value) into an entry associated with event log <b>235</b>. It should be noted that CRTM component <b>220</b> executes in a restricted environment where it cannot typically access event log <b>235</b>. It should also be noted that although user space program <b>205</b> is operable to use TPM <b>225</b> and event log <b>235</b>, it is optional as to whether it does so since user space program <b>205</b> does not tend to load other software components itself. Once managed system <b>200</b> is running, data associated with a “chain of trust” can be extracted for inspection by a remote managing system <b>305</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) using a remote attestation procedure, e.g., direct anonymous attestation (DAA) as is further described below.

With reference to <figref idref="DRAWINGS">FIG. 3</figref>, managing system <b>300</b> and managed system <b>200</b>, which includes associated components TPM <b>225</b>, PCRs <b>230</b>, and event log <b>235</b> (which includes one or more measurement values and associated metadata), are illustrated. An attestation process typically involves managed system <b>200</b> sending current PCRs <b>230</b> for measured components together with event log <b>235</b> to managing system <b>305</b>. A simplified example of an attestation process performed on the managing system <b>305</b> is described with reference to <figref idref="DRAWINGS">FIG. 4</figref>.

In <figref idref="DRAWINGS">FIG. 4</figref>, at block <b>400</b>, current PCRs <b>230</b> and event log <b>235</b> are retrieved. At block <b>405</b>, expected attestation values associated with components of the managed system <b>200</b> are retrieved from event log <b>235</b>, e.g., stored in a database. At block <b>410</b>, emulator <b>310</b> of the managing system <b>305</b> compares the values of received PCRs <b>230</b> with the expected attestation values. It should be understood that a number of other components of the managing system <b>305</b> could execute the comparison logic. If a match occurs for each PCR value, managed system <b>200</b> is considered to be trusted (block <b>415</b>) and no further work is done. If a match does not occur for each PCR value, managing system <b>305</b> parses (block <b>420</b>) event log <b>235</b>, inspecting each entry in turn to decide whether or not measurement value(s) contained in an entry associated with a measured component in question is valid.

If each entry of event log <b>235</b> appears to be valid (positive result in block <b>425</b>), managed system <b>200</b> is considered to be trusted (block <b>415</b>) and no further work is done. If the event log entry appears not to be valid (negative result in block <b>425</b>), managed system <b>200</b> is not considered to be trusted (block <b>430</b>), at which point a security alert may be raised before moving to a “System untrusted” exit state. Typically, manufacturers of components of managed system <b>200</b> provide a (large) list (e.g., a reference manifest) of measurement values associated with a component that can be taken to be ‘trusted’. The trusted boot process is highly deterministic and associated events which appear in event log <b>235</b> typically follow a strict pattern. In an example where CRTM <b>220</b> measures firmware <b>215</b> (which in turn measures operating system <b>210</b>), event log <b>235</b> typically comprises two events, namely, ‘firmware measured’ and ‘operating system measured’. Even if firmware <b>215</b> and/or OS <b>210</b> are changed (e.g., updated) during a future boot process, the same two events will occur in the same order and only the associated measurement values will differ.

Each measurement value may be associated with the same PCR. In this case, managing system <b>305</b> may maintain a record indicating that the last time managed system <b>200</b> booted, it was using firmware version X with a measurement of M1 and an OS version Y with a measurement of M2, where M1 and M2 are SHA digests of the firmware boot component and OS boot component, respectively. The two events together with the measurement values, namely, “firmware measured: SHA(M1)” and “operating system measured: SHA(M2)”, when extended into a PCR, give a PCR value of ‘Z’. The PCR value of ‘Z’ is recorded as an expected attestation value for firmware <b>215</b> and OS <b>210</b> in database <b>325</b> of managing system <b>305</b>.

During a subsequent attestation process, managing system <b>305</b> retrieves (block <b>400</b>) current PCRs <b>230</b> together with event log <b>235</b> and retrieves (block <b>405</b>) the expected attestation values from database <b>325</b>. At block <b>410</b>, emulator <b>310</b> compares the values of the received PCRs with the expected attestation values. If a match occurs, it is determined (block <b>415</b>) that managed system <b>200</b> is using expected firmware <b>215</b> and OS <b>210</b>. If a match does not occur, (i.e., the received PCR value is not ‘Z’), managing system <b>305</b> parses (block <b>420</b>) event log <b>235</b> to find associated entries. Managing system <b>305</b> compares the first event and measurement value, namely, “firmware measured: SHA(M1)” with a list of trusted values provided by the particular manufacturer of the firmware and compares the second event and measurement value, namely, “operating system measured: SHA(M2)” with a list of trusted values provided by the particular manufacturer of the OS. If either component has a measurement value which the manufacturer has not listed as “trusted”, managed system <b>200</b> is assumed (block <b>430</b>) to be compromised. If both components have a measurement value which the manufacturer has listed as “trusted”, managed system <b>200</b> is assumed (block <b>415</b>) to be trusted and the measurement values can be associated with a new expected attestation value(s) that is used during the next attestation process of managed system <b>200</b>.

<figref idref="DRAWINGS">FIG. 5A</figref> is a block diagram showing a physical organization of machines within a datacenter <b>500</b>. Datacenter <b>500</b> includes a plurality of machine pools <b>542</b> and <b>544</b>, each of which include a plurality of machines <b>502</b> and <b>512</b>, and <b>522</b> and <b>532</b>, respectively. Each machine <b>502</b>, <b>512</b>, <b>522</b> and <b>532</b> includes a plurality of virtual machines (VMs) <b>506</b> and <b>510</b>, <b>516</b> and <b>520</b>, <b>526</b> and <b>530</b>, <b>536</b> and <b>540</b>, respectively. Each virtual machine <b>506</b>, <b>510</b>, <b>516</b>, <b>520</b>, <b>526</b>, <b>530</b>, <b>536</b>, and <b>540</b> includes a plurality of PCRs <b>504</b>, <b>508</b>, <b>514</b>, <b>518</b>, <b>524</b>, <b>528</b>, <b>534</b>, and <b>538</b>, respectively.

In one or more embodiments logic for generating an “attestation set” includes, from the perspective of managing system, a logical grouping of components associated with a datacenter. Each component can be, for example, an entire system or a machine that represents a managed system. An attestation set can be created automatically or manually. A set can be created automatically by, for example, software associated with the datacenter. Assuming that the components of the datacenter have been organized into a hierarchy having metadata, the software can create sets by identifying a component (e.g., using the metadata) and associating the component with its children (e.g., using the metadata) e.g., a VM is associated with an attestation set containing PCRs of the VM. Alternatively, a set can be created manually by inspection of the hierarchy of the datacenter. Manual inspection allows for the greatest flexibility and does not rely on the presence of software for automating set creation. Details associated with sets may be maintained by a managing system. For example, software on a managing system can read a text file containing set descriptions or receive a text file as input and convert set descriptions into internal representations to be stored in binary on a disk. An attestation set can include ‘child’ attestation sets or individual PCRs of a component.

Advantageously, through the use of attestation sets a plurality of components of a datacenter can be attested according to the present disclosure. In one or more embodiments, any component in the hierarchy of datacenter <b>500</b> can be queried for its attestation status. With reference again to <figref idref="DRAWINGS">FIG. 5A</figref>, machine pool <b>542</b> includes Machine1 <b>502</b> and Machine2 <b>512</b>. Machine1 <b>502</b> runs VM_A <b>506</b> (which is, for example, owned by Red_Company) and Machine1 <b>502</b> also runs VM_B <b>510</b> (which is, for example, owned by Blue_Company). Machine2 <b>512</b> runs VM_C <b>516</b> (which is, for example, owned by Red_Company) and Machine2 <b>512</b> also runs VM_D <b>520</b> (which is, for example, owned by Blue_Company). The examples that follow demonstrate how different groupings of components can be used by different audiences.

In a first example (Example 1), a datacenter owner may wish to attest each VM in a machine pool, which results in an associated attestation set, e.g., VM_A, VM_B, VM_C, and VM_D. In a second example, (Example 2), a systems administrator may wish to attest each VM on a particular physical machine resulting in an associated attestation set, e.g., VM_A and VM_B on Machine1. In a third example (Example 3), a company may wish to attest each of their VMs regardless of the physical machine on which they reside resulting in an associated attestation set, e.g., VM_B and VM_D. Other examples of groupings of components may include one or more machine pools. In at least one embodiment, an attestation set includes a list of records associated with particular components of a datacenter (e.g., a PCR, a VM, a machine, or a machine pool). As one example, Attestation Set_A is given below:

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row><row><entry /><entry>PCRs 0-15.VM-A.Machine1.Machine Pool 1</entry></row><row><entry /><entry>PCRs 2-6.VM-C.Machine2.Machine Pool 1</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In one or more embodiments, default values for components of a datacenter can be set (e.g., a default set of PCRs) to allows for convenience in the creation of attestation sets. For example, if each VM in a datacenter has 16 PCRs (of which only the even-numbered ones are important) and thousands of VMs are present in the datacenter, it can become cumbersome to generate an attestation set for each VM. For example, an attestation set for each VM may be generated as follows:

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_VM_n =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs 0,2,4,6,8,10,12,14; VM_n</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

A default description of an attestation set can be generated as follows:

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>default_PCRs = 0,2,4,6,8,10,12</entry></row><row><entry /><entry>Attestation_Set_VM_n =</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>Child1 = default_PCRs: VM_n</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Each attestation set may have an associated rule to describe how to decide whether the set is trusted. If an attestation set does not comprise an associated rule, a default rule maybe applied. As one example, a rule may govern that a set is trusted based on the status of its children. For example, all children of a set must be deemed trusted before a parent set is deemed trusted. As another example of a rule, either 50% of the children must be deemed trusted or a highest priority child must be deemed trusted before a parent set is deemed trusted. As yet another example, a rule may govern that a set is trusted based on a time value to allow, for example, a child to be untrusted during a known maintenance period. For example, a child can be deemed trusted if a current time value is between 0400 and 0430 otherwise it is deemed untrusted (until proven otherwise e.g., by using an attestation process). In yet another example, a rule may govern that a set is always trusted or always untrusted. For example, an “always trusted” rule can be used to temporarily stop the raising of an alarm on a machine which is known to be faulty and an “always untrusted” rule can be used to test that a security alarm mechanism works correctly.

In a fourth example (Example 4, which is associated with Example 1), an attestation set may be given as follows:

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation Set_1 =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[A].Machine[1]</entry></row><row><entry /><entry>Child2 = PCRs[0-15].VM[B].Machine[1]</entry></row><row><entry /><entry>Child3 = PCRs[0-15].VM[C].Machine[2]</entry></row><row><entry /><entry>Child4 = PCRs[0-15].VM[D].Machine[2]</entry></row><row><entry /><entry>Rule = if(all children are trusted) then TRUSTED else</entry></row><row><entry /><entry>UNTRUSTED;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In the above rule, all children of a set must be deemed trusted before a parent set is deemed trusted.

In a fifth example (Example 5, which is associated with Example 2), an attestation set may be given as follows:

<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation Set_2 =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[A].Machine[1]</entry></row><row><entry /><entry>Child2 = PCRs[0-15].VM[B].Machine[1]</entry></row><row><entry /><entry>Rule = if(&gt; 25% all children are trusted) then TRUSTED else</entry></row><row><entry /><entry>UNTRUSTED;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In the above rule, more than 25% of children of a set must be deemed trusted before a parent set is deemed trusted.

In a sixth example (Example 6, which is associated with Example 3), an attestation set may be given as follows:

<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Attestation Set_3 =</entry></row><row><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[B].Machine[1]</entry></row><row><entry /><entry>Child2 = PCRs[0-15].VM[D].Machine[2]</entry></row><row><entry /><entry>Rule = if( (Child1 is trusted) == (Chlid2 is trusted)) then TRUSTED</entry></row><row><entry /><entry>else UNTRUSTED</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In the above rule, a parent set is deemed trusted when the trusted state of its children are equal (i.e., both children must be deemed trusted or both children must be deemed untrusted). The above rule can be used, for example, if Child1 and Child2 are configured to always have software updates applied in parallel. If either child is updated without the other child also being updated, one child will fail attestation and the other child will pass attestation meaning that the parent set will be deemed to be untrusted (so that, for example, an alert can be raised to an administrator). In the above examples, each attestation set specifies the particular components that are of interest. However, the attestation sets above do not necessarily reflect a hierarchy associated with a physical hierarchy of a datacenter configuration or a functional dependency of a datacenter.

With reference to <figref idref="DRAWINGS">FIG. 5B</figref>, an attestation set can be associated with a logical hierarchy that mirrors a physical hierarchy of datacenter <b>500</b>. For example, an attestation set can be created for each VM (e.g., VM <b>506</b>) as follows:

<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_VM_A =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[A]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As another example, an attestation set can be created for each machine with an attestation status of a machine (e.g., Machine1 <b>502</b>) being in union with the attestation status of each of its VM's attestation sets (e.g., Attestation_Set_VM_A and Attestation_Set_VM_B) as follows:

<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_Machine1 =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = Attestation_Set_VM_A</entry></row><row><entry /><entry>Child2 = Attestation_Set_VM_B</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As yet another example, an attestation set can be created for each machine pool with an attestation status of a machine pool (e.g., Machine Pool1 <b>542</b>) being in union with the attestation status of each of its machine's attestation sets (e.g., Attestation_Set_Machine1 and Attestation_Set_Machine2) as follows:

<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_Pool1 =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = Attestation_Set_Machine1</entry></row><row><entry /><entry>Child2 = Attestation_Set_Machine2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As another example, an attestation set can be created for each datacenter with an attestation status of the datacenter (e.g., datacenter <b>500</b>) being in union with the attestation status of each of its machine pool's attestation sets (e.g., Attesatation_Set_Pool1 and Attesatation_Set_Pool2) as follows:

<tables id="TABLE-US-00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_Datacenter =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = Attesatation_Set_Pool1</entry></row><row><entry /><entry>Child2 = Attesatation_Set_Pool2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

With reference to <figref idref="DRAWINGS">FIGS. 5C and 5D</figref>, an attestation set can be associated with functional dependency of a datacenter rather than a physical hierarchy. With reference to <figref idref="DRAWINGS">FIG. 5C</figref>, VM_A <b>506</b>, VM_B <b>510</b>, and VM_C <b>516</b> cooperate to provide a web service with associated PCRs <b>504</b>, <b>508</b>, and <b>514</b>, respectively. VM_C <b>516</b> hosts a primary webserver <b>550</b>, which hosts a website. Primary webserver <b>550</b> uses a secondary webserver <b>548</b> (e.g., hosted on VM_B <b>510</b>) whenever a particular web page on the website is requested. Secondary webserver <b>548</b> uses a database <b>546</b> hosted on VM_A <b>506</b> to retrieve information needed to display the web page. In this way, each VM is functionally dependent upon another VM.

With reference to <figref idref="DRAWINGS">FIG. 5D</figref>, a further depiction of the functional dependency is shown with a VM being associated with its PCRs and another VM. For example, VM_C <b>516</b> is associated with its PCRs <b>514</b> and VM_B <b>510</b>, VM_B <b>510</b> is associated with its PCRs <b>508</b> and VM_A <b>506</b>, and VM_A <b>506</b> is associated with its PCRs <b>504</b>. Examples of how attestation sets can be associated with the functional dependency depicted in <figref idref="DRAWINGS">FIG. 5D</figref> are given below:

<tables id="TABLE-US-00011" num="00011"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_VM_A =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCR[0-15].VM[A]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>Attestation_Set_VM_B =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCR[0-15].VM[B]</entry></row><row><entry /><entry>Child2 = Attestation_Set_VM_A</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>Attestation_Set_VM_C =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCR[0-15].VM[C]</entry></row><row><entry /><entry>Child2 = Attestation_Set_VM_B</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

An attestation set (to be attested) may be associated with a subset of the logical hierarchy illustrated in <figref idref="DRAWINGS">FIG. 5B</figref> (where datacenter <b>500</b> represents managed system <b>200</b>). A managing system <b>305</b> may, for example, wish to attest the attestation set Attesatation_Set_Pool1 set forth below:

<tables id="TABLE-US-00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attesatation_Set_Pool1 =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = Attestation_Set_Machine1</entry></row><row><entry /><entry>Child2 = Attestation_Set_Machine2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>where,</entry></row><row><entry /><entry>Attestation_Set_Machine1 =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = Attestation_Set_VM_A</entry></row><row><entry /><entry>Child2 = Attestation_Set_VM_B</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>Attestation_Set_VM_A =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[A]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>Attestation_Set_VM_B =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[B]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>Attestation_Set_Machine2 =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = Attestation_Set_VM_C</entry></row><row><entry /><entry>Child2 = Attestation_Set_VM_D</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>Attestation_Set_VM_C =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[C]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>Attestation_Set_VM_D =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[D]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

With reference to the process of <figref idref="DRAWINGS">FIG. 6</figref>, at block <b>600</b>, for the attestation set Attestation_Set_Pool1, a list of the set's children is retrieved, e.g., List 1: Machine1 and Machine2. At block <b>605</b>, a determination is made as to whether any of the children of the set (List 1) are yet to be attested. In the example, as neither Machine1 nor Machine2 have been attested, the process passes to block <b>610</b> where details of an unattested child are retrieved (in this example, Machine1). A process to attest Machine1 begins and a pointer to Machine2 is saved. At block <b>615</b>, it is determined whether the unattested child is also an attestation set. For example, managing system <b>305</b> parses the set description in order to determine the value that follows the parameter ‘Childx’. If the value begins with ‘PCRs’, managing system <b>305</b> determines that the child is not an attestation set. If the value begins with a value that is not “PCRs”, managing system <b>305</b> determines that the child is also an attestation set.

Managing system <b>305</b> may store a flag alongside each child indicating whether or not the child is an attestation set. As an example, child set ‘Machine1’ may also be an attestation set as set forth below:

<tables id="TABLE-US-00013" num="00013"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_Machine1 =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = Attestation_Set_VM_A</entry></row><row><entry /><entry>Child2 = Attestation_Set_VM_B</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The process returns to block <b>600</b>, where a list of the set's children is retrieved, e.g., List 2: VM_A and VM_B, for the attestation set Attestation_Set_Machine1. At block <b>605</b>, a determination is made as to whether any of the children of the set ‘Attestation_Set_Machine1’ are yet to be attested. In the example, as neither VM_A nor VM_B have been attested, the process passes to block <b>610</b> where details of an unattested child (in this example, VM_A) are retrieved. A process to attest VM_A begins and a pointer to VM_B is saved. It should be noted that the state of Machine1 at level ‘N’ is saved and control is passed to recursion level N+1 (associated with VM_A and VM_B). At block <b>615</b>, it is determined whether the unattested child is also an attestation set. VM_A may also be an attestation set as is illustrated below:

<tables id="TABLE-US-00014" num="00014"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_VM_A =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[A]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The process returns to block <b>600</b> where, for the attestation set Attestation_Set_VM_A, a list of the set's children is retrieved e.g., List 3: PCRs[0-15]. At block <b>605</b>, a determination is made as to whether any of the children of the set Attestation_Set_VM_A are yet to be attested. In the example, as PCRs[0-15] have not been attested, the process passes to block <b>610</b> where details of unattested children (in this example, PCRs[0-15]) are retrieved. At block <b>615</b>, it is determined whether the unattested child is also an attestation set. In the example, PCRs[0-15] is not an attestation set and the process passes to block <b>625</b>. Managing system <b>305</b> performs an attestation in order to determine either a trusted state or an untrusted state for PCRs[0-15] by contacting VM_A to retrieve PCRs[0-15] together with event log <b>235</b>. Managing system <b>305</b> then retrieves expected attestation values associated with the retrieved PCRs in order to compare the expected attestation values with the retrieved PCRs. If a match occurs for each PCR value, VM_A is considered to be trusted and no further work is done.

If a match does not occur for each PCR value, managing system <b>305</b> parses event log <b>235</b>, inspecting each entry in turn to decide whether or not a measurement value(s) contained in an entry associated with the PCRs in question is valid (in accordance with a list of trusted values provided by a particular manufacturer). If each event log entry appears to be valid, VM_A is considered to be trusted and no further work is done. If the event log entry appears not to be valid, VM_A is not considered to be trusted. In the example, following the process of <figref idref="DRAWINGS">FIG. 6</figref>, the PCRs[0-15] of VM_A are deemed to be trusted. The process passes to block <b>605</b>, where it is determined whether any of the children are yet to be attested. As there are no further children to be attested, the process passes to block <b>630</b>, where a rule (e.g., Rule 1=if(&gt;25% all children are trusted) then TRUSTED else UNTRUSTED) associated with the current attestation set, namely, Attestation_Set_VM_A, is retrieved.

At block <b>635</b>, if the rule is satisfied, Attestation_Set_VM_A is deemed trusted and if the rule is not satisfied, Attestation_Set_VM_A is deemed not trusted. In the example, as PCRs[0-15] (&gt;25% of all children) of VM_A are deemed to be trusted, Attestation_Set_VM_A is deemed trusted. The process passes to block <b>605</b> and recurses up one level (to N) where it is determined whether any of the children of the set (Attestation_Set_Machine1) are yet to be attested. With reference to the saved pointer, as VM_B is yet to be attested, the process passes to block <b>610</b> where details of the unattested child are retrieved. A process to attest VM_B begins. At block <b>615</b>, it is determined whether the unattested child is also an attestation set. In the example, VM_B is also an attestation set as set forth below:

<tables id="TABLE-US-00015" num="00015"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Attestation_Set_VM_B =</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = PCRs[0-15].VM[B]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The process returns to block <b>600</b> where, for the attestation set Attestation_Set_VM_B, a list of the set's children is retrieved, e.g., List 4: PCRs[0-15]. At block <b>605</b>, a determination is made as to whether any of the children of the set (Attestation_Set_VM_B) are yet to be attested. In the example, as PCRs[0-15] have not been attested, the process passes to block <b>610</b> where details of any unattested children (in this example, PCRs[0-15]) are retrieved. At block <b>615</b>, it is determined whether the unattested child is also an attestation set. In the example, PCRs[0-15] is not an attestation set and the process passes to block <b>625</b>. With reference to the process of <figref idref="DRAWINGS">FIG. 4</figref>, managing system <b>305</b> performs an attestation in order to determine either a trusted state or an untrusted state for PCRs[0-15] by contacting VM_B to retrieve PCRs[0-15] together with event log <b>235</b>. Assuming the PCRs[0-15] of VM_B are deemed to be trusted, the process passes to block <b>605</b>, where it is determined whether any of the children are yet to be attested.

As there are no further children to be attested, the process passes to block <b>630</b>, wherein a rule (e.g., Rule 2=if(all children are trusted) then TRUSTED else UNTRUSTED) associated with the current attestation set, namely, Attestation_Set_VM_B, is retrieved. At block <b>635</b>, if the rule is satisfied, Attestation_Set_VM_B is deemed trusted and if the rule is not satisfied, Attestation_Set_VM_B is deemed not trusted. In the example, as PCRs[0-15] (all children) of VM_B are deemed to be trusted, Attestation_Set_VM_B is deemed trusted. The process passes to block <b>605</b> and recurses up one level (to N) where it is determined whether any of the children of the set (Attestation_Set_Machine1)) are yet to be attested. As there are no further children to be attested, the process passes to block <b>630</b>, wherein a rule (e.g., Rule 3=if(all children are trusted) then TRUSTED else UNTRUSTED) associated with the current attestation set, namely, Attestation_Set_Machine1, is retrieved. At block <b>635</b>, if the rule is satisfied, Attestation_Set_Machine1 is deemed trusted and if the rule is not satisfied, Attestation_Set_Machine1 is deemed not trusted. In the example, as VM_A and VM_B (all children) are deemed to be trusted, Attestation_Set_Machine1 is deemed trusted.

It should be noted that in the example, Machine1's PCRs do not form part of the attestation checks. However, alternatively, if a component has a TPM <b>125</b>, attestation of its PCRs can also occur. For example, an attestation set for Machine1 can be used, wherein Child3 denotes Machine1's PCRs as follows:

<tables id="TABLE-US-00016" num="00016"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="196pt" align="left" /><colspec colname="2" colwidth="21pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Attestation_Set_Machine1</entry><entry>=</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Child1 = Attestation_Set_VM1</entry></row><row><entry /><entry>Child2 = Attestation_Set_VM2</entry></row><row><entry /><entry>Child3=PCRs[0-16].Machine1</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As the process to attest Machine1 has completed, the process passes to block <b>605</b>, where it is determined whether any of the remaining children of the set (Attesatation_Set_Pool1) are yet to be attested. With reference to the saved pointer, it is determined that Machine2 is yet to be attested and the process passes to block <b>610</b> where details of the unattested child (Machine2) are retrieved. It should be understood that the above process is repeated for Machine2 as has been shown for Machine1, resulting in states (trusted or untrusted) associated with Machine2's children (namely, Attestation_Set_VM_C and Attestation_Set_VM_D). In the example herein, the state associated with Attestation_Set_VM_C is trusted and the state associated with Attestation_Set_VM_D is trusted. In the example, Attestation_Set_Machine2 is also deemed trusted in accordance with its rule (not shown). Following attestation of Machine2, the process passes to block <b>605</b>, where it is determined whether any of the remaining children of the set Attesatation_Set_Pool1 are yet to be attested. As there are no further children to be attested, the process passes to block <b>630</b>, wherein a rule (e.g., Rule 4=if(all children are trusted) then TRUSTED else UNTRUSTED) associated with the current attestation set, namely, Attesatation_Set_Pool1, is retrieved.

At block <b>635</b>, if the rule is satisfied, Attesatation_Set_Pool1 is deemed trusted and if the rule is not satisfied, Attesatation_Set_Pool1 is deemed not trusted. In the example, as Machine1 and Machine2 (all children) are deemed to be trusted, Attesatation_Set_Pool1 is deemed trusted. It should be noted that if attestation fails at any point in the hierarchy a user is able to examine the level below the failure to examine the cause (until eventually the individual faulting PCRs are identified). For example, if each VM Attesatation_Set_Pool1 is deemed trusted apart from VM A, Attestation_Set_VM_A will have an associated state of untrusted. As Attestation_Set_VM_A is Child1 of Attestation_Set_Machine1, given Rule 3, the state of Attestation_Set_Machine1 will be untrusted (even though the state of Child2 of Attestation_Set_Machine1 is trusted). In turn, as Attestation_Set_Machine1 is Child1 of Attestation_Set_Pool1, given Rule 4, the state of Attestation_Set_Pool1 will be untrusted.

As such, if a managing system requests attestation of Attestation_Set_Pool1, an untrusted result will be returned. The reason(s) for the failure may be displayed using a user interface. For example, at a first level, a report can be displayed, indicating that Attestation_Set_Pool1 is untrusted because Child1 (Attestation_Set_Machine1) is untrusted. In one or more embodiments, a user can query the report to determine the reason Attestation_Set_Machine1 has been deemed untrusted and so on until the user is informed that the underlying cause of the failure is that VM-A was deemed untrusted. Subsequently, the user may, for example, contact a systems administrator to determine what exactly failed in VM_A.

The present disclosure provides a mechanism in which the status of individual datacenter components can be obtained and coalesced such that an attestation result associated with a plurality of managed systems can be provided. Advantageously, given a set to attest, a managing system can determine the state of each of the children associated with the set. Each child may be an attestation set itself. In various implementations, one or more children may have already been attested because they appear in multiple sets. Advantageously, it is possible to define an attestation set to meet the needs of, for example, a datacenter owner, a system administrator, and/or an end customer.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” (and similar terms, such as includes, including, has, having, etc.) are open-ended when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Having thus described the invention of the present application in detail and by reference to preferred embodiments thereof, it will be apparent that modifications and variations are possible without departing from the scope of the invention defined in the appended claims.