TW201234173A - A method for attesting a plurality of data processing systems - Google Patents

Abstract

A method for attesting a plurality of data processing systems, comprising the steps of: generating a logical grouping for a data processing system, wherein 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; retrieving a list of one or more children associated with the logical grouping; attesting the or each child in order to determine whether the or each child is trusted; in response to the attesting step, applying the rule in order to determine whether the condition has been met in order for the data processing system to be considered trusted; and associating a plurality of logical groupings such that it can be determined whether an associated plurality of data processing systems can be considered trusted.

Description

201234173 * VI. DESCRIPTION OF THE INVENTION: TECHNICAL FIELD OF THE INVENTION The present invention relates to a method for verifying a plurality of data processing systems. [Prior Art] Trusted boot is a handler for launching and establishing a chain of trust in a computing system. Referring to the environment (100) of Figure 1, for example, the system administrator can extract the server (managed system (120)) and proceed to install the system software. The managed system (120) includes a security device (125), such as a Trusted Platform Module (TPM). Once the system (120) is configured and started, each component (hardware and/or software) of the managed system (12〇) measures another component in a cryptographically compiled manner and can "expand" the measured value ( Instead of writing directly to the TpM (i25) platform configuration scratchpad II (PCR). Each component can also operate to access an event log file to write data associated with the component's measurements to the project associated with the event log file. The measurements can be verified remotely by the management system (105), and the management system (1) has a repository (1) 5) that stores the expected verification values for each of the components of the managed system. Usually, the value of the material, together with the description of the material value, is intended to be stored. The management system (10) includes, for example, a comparison of the measurements with the equivalent of the τρΜ simulator (1)〇). If there is no match between the measurements and the values, then typically the management system (1〇5) must enter a list of _(large) measurements provided by the manufacturer of group # (eg, reference list usually, The reference list contains a large number of measurements associated with each component of the managed system and these measurements can be considered "party trusted." 159868.doc 201234173 can be initiated by the management system or managed system The end verification handler itself. The subsequent changes to the managed system (120) can be detected by subsequent trusted boot and remote authentication handlers. The above described procedures are described, for example, in the following documents: August 2, 2007 TTrusted Computing Group (TCG) Specification Architecture Overview; Specification; Chapter 4 of Revision 1.4, and TCG Infrastructure Working Group Architecture No. 17 of November 17, 2006 Part II (TCG Infrastructure Working Group Architecture Part II) - Integrity Management; Specification Version 1.0; Chapter 2 of Revision 1.0. As described above, verification currently involves collating a single machine, A machine is a physical machine with a real TPM or a virtual machine (VM) with a virtual TPM. This is a reasonable practice for the owner of an individual machine, but usually the end user or company may be more subtle than a single machine. For example, a large company may wish to verify each of its VMs on a particular physical machine or each of its VMs within a particular machine set or in its physical machine at a particular site. Similarly, data center owners may be concerned with the integrity of their entire data center (and possibly sub-clusters within the data center). Unlike a single machine, an entity may involve dozens, hundreds, or There are even thousands of machines. Therefore, there is a need in the art to solve the aforementioned problems. According to a first aspect, a method for verifying a plurality of data processing systems 159868.doc 201234173 is provided, and the method includes The following steps: generating a logical knife group for a data processing system, wherein the logical grouping is associated with a rule, the rule is described in order to The condition that must be satisfied for the purpose of the data processing system as a trusted one is taken from the logical grouping- or multiple orders, and the child or each child is examined to determine the child. Or each child is trusted in the text; in response to the verification step, the rule is applied to determine whether the condition for achieving the purpose of the data processing system is deemed to be fulfilled; and the plurality of logical groups are grouped The association is such that the MS can treat the associated plurality of data processing systems as trusted. According to one aspect, there is provided an apparatus for verifying a plurality of data processing systems, comprising: means for generating a logical grouping for a data processing system, wherein the towel cluster is associated with a helper, The rule describes a condition that must be met in order to achieve the purpose of the data processing system being trusted; a means for extracting a list of one or more children associated with the logical group; for verifying the child Generation or per-child to determine whether the child or per-child is (4) a trusted component; the rule is applied in response to the verification component to determine whether it has been met in order to achieve the data processing system a component of the condition for the purpose of trust; and a third aspect for correlating the plurality of logical groups to determine whether the associated plurality of data processing systems can be considered trusted Providing a computer program comprising a computer program code stored on a computer readable (4) for loading into a computer system or executing on the computer system Having the computer system 159868.doc 201234173, all of the steps of the above method are performed. [Embodiment] The present invention will now be described by way of example only with reference to the preferred embodiments of the invention as illustrated in the following drawings . A more detailed explanation of known trusted startup and remote verification handlers will now be given. Referring to Figure 2 (which should be read in conjunction with Figures 3 and 4), the managed system (120, 200) is shown in more detail. During the trusted boot process, each component of the managed system (120, 200) is cryptographically compiled (eg, using Secure Hash Algorithm (SHA) to build - information hashes (such as software files; models) ; Manufacturing · 'component serial number, etc.) in order to establish a measured value) another starting component. In an example, the Trusted Measurement Root (CRTM) component (22) (eg, BIOS) is a first code segment that is controlled during startup and due to the first code The fragment is immutable, so the first code fragment must be implicitly trusted. Crtm (22〇) measures the next component in the startup handler (for example, firmware (215)) in cryptographic compilation; subsequently, the firmware (215) measures the next component in the startup handler (for example, the job) System (210)); and then, the operating system (21) measures the user space programs (205) prior to transmitting control to any user space program (205). Each component can "expand" (rather than directly write) a measured value to the platform configuration register (PCR) of the TPM (125, 225) (230) before transferring control to the measured component. in. The extended operation includes the combination of the current value of the PCR (230) and the cipher compilation combination of the 159868.doc 201234173 measurement value - signed by the public/private record of the operating system and the management system (120, 200). Heart a ingenuity ° Xuan Xiongxiong, the key is only known as tpm (125, 225). Each component can also operate to access an event record floor (235) to associate data associated with the measurement of the component (eg, % of components, such as component identifiers and post-event settings; and associated measurements) Write to the project associated with the event record (235). It should be appreciated that CRTM (220) is implemented in a restricted environment where it is generally inaccessible to event logging (235). It should also be noted that the user space program (2〇5) is operable to use the TPM (i 25, 225) and the event log file (235), but it is still optional as to whether it is so, due to user space. The program (205) does not tend to load other software components by itself. As will be described herein, once the managed system (12〇, 2〇〇) is in execution, the data associated with the “k-chain” can be extracted for use by the remote system (105, 305). The slogan (for example, direct anonymous verification (daa)) is used for verification. Referring to the system (300) of FIG. 3, the managed system (12〇, 2〇〇) and associated TPM (125, 225); PCR (230); and including one or more measurements and associated Set the event log file for the data (235). The verification process typically involves the managed system (1, 200, 200) sending the current PCR (230) for the measured component to the management system (105, 305) along with the event log file (235). Referring now to Figure 4, a simplified example of the verification process performed by Sumida on the official system (1〇5 '305). 159868.doc 201234173 At step 400, the received current PCR (230) is fetched along with the event record 235 (235). At the step, the self-database (325) fetches the expected verification values associated with the components of the management system (120, 2GG). At step 410, the simulator (1) of the management system (1〇5, 3〇5) compares the value of the received PCR (230) with the expected verification values. It should be understood that several other components of the management system (105, 305) may perform the comparison logic. Right for a match for each PCR value, the managed system 〇2〇, 200) is considered trusted (step 415) and no further work is required. Right for each - PCR value does not appear a match, then the management system (10) $ ' 3 05) parsing (step 420) event record 棺 (235), thereby sequentially testing each item to determine and measure the measured Whether the measured value(s) contained in the item associated with the component is valid. - If each event log file (235) item is presented as valid (affirmative result of step 425), then the managed system (12〇, 2〇〇) is considered trusted (step 415) and no further action is required jobs. The right event log file item is not rendered valid (negative result of step 425) 'The managed system (120, 200) is not considered trusted (step 430). Preferably, when moving to "system not A security alert is raised before the Trusted exit status. Example embodiments of the above described processing procedures will now be described. Typically, the manufacturer of the components of the civil service system (12〇, 200) provides a list of (large) measurements associated with the component (eg, reference list) _ such measurements can be considered "trusted" "." In addition, in general, the trusted launch handler is highly deterministic and the associated event presented in the event log file (235) follows a strict pattern. In the CRTM (220) measurement firmware (215) (firmware (215) and measurement operating system (210)), the event log file (235) typically contains two events, namely: "Terminal warp Measurement" and "Operation System Measurement". Even if the firmware (215) and/or operating system (210) are changed (e.g., updated), the same two events will occur in the same order and only the associated measurements will be different during the future startup process. In one example, 'each measurement is associated with the same PCR. In this example, the management system (305) maintains a record indicating the last time the managed system (启动2〇, 2〇〇) was started, using, for example, a version having the version with the M1 measurement and (for example An operating system having a version γ of the M2 measurement, wherein M1 and M2 are the sum of the firmware starter component and the operating system starter component respectively. The two events together with the measured values (ie, "firm body warp" Measurement·· SHA(M1) and “Operation System Measurement: SHA(M2)” together give a pcr value “Z” when extended to PCR. The PCR value "Z" is recorded in the database (325) of the management system (3) as the expected verification value for the firmware (215) and the operating system (210). During a subsequent verification process, the management system (305) retrieves the received current PCR (230) along with the event log file (23 5) (step 400) and retrieves it from the database (325) (steps) 4〇5) These expected verification values. At step 410, the simulator (31〇) compares the value of the received Pcr with the expected verification value. If a match occurs, it is determined (step 4丨5) that the managed system (120, 200) is using the expected firmware (215) and the operating system (21〇). If no match occurs (i.e., the received PCR value is not "Z"), then the management system (305) parses (step 420) the event log file (235) for the associated item 159868.doc 10 201234173. The management system (3G5) compares the first event and the measured value (the dynamic body measured · SHA(M1)J ) with a specific trusted (four) list of _, and compares the second event with the measured value (ie = The system is measured: SHA(M2)") and a list of trusted values provided by the operating system. If the component has a measurement value that is not listed by the manufacturer as a "trusted" value, then it is assumed (step 430) that the managed system (12〇, 2〇〇) is cracked. The right two components have measured values listed by the manufacturer as "trusted" values, assuming (step 415) that the managed systems (120, 200) are trusted and can make the measurements Below the management system (120, 200) - one (or more) new expected verification values used during the verification process are associated. A preferred embodiment of the present invention will now be described with reference to Figures 5 and 6. Figure 5A is a block diagram showing the physical machine organization within a typical data center (5〇〇). In the example of FIG. 5A, the data center (5〇〇) includes a plurality of machine pools (542 and 544), each of the plurality of machine pools comprising a plurality of machines (502, 512, and 522, respectively). 532). Each machine (5〇2, 512, 522, and 532) contains a plurality of virtual machines (VMs) (5〇6 and 510, 516 and 520, 526, and 530, 536, and 540, respectively). Each virtual machine (506, 510, 516, 520, 526, 530, 536, and 540) contains a plurality of PCRs (504, 508, 514, 518, 524, 528, 534, and 538, respectively). Preferably, the means for generating a "validation set" containing a logical grouping of components associated with the data center (from the perspective of the management system (305)) is provided. It should be noted that each component can be, for example, the entire 159868.doc 201234173 system or machine and each component represents a managed system. The verification set can be established automatically or manually. A set can be automatically created by, for example, software associated with a data center. Assuming that the components of the data center have been organized into a hierarchy with post-data, the software can identify a component (eg, 'make (4) data) and associate the component with its children (eg, use post-data) (for example, associating an object with a validation set containing the PCR) to establish a collection. Alternatively, the collection can be manually established by a test of the hierarchy of the data center. This test method allows for maximum flexibility and does not depend on the existence of software for automating the collection. Preferably, the details associated with the collection are maintained by the management system. For example, the software on the management system can read the text slot containing the set description used in the example below or take the text slot as a round person and convert the set description into a wait: carry-over Internal representation on the disk. The validation set can contain other "child" validation sets or individual PCRs of, for example, components. As will be described herein, advantageously, a plurality of components of a data center can be verified by using a validation set. Preferably, the component can be queried for the verification status of any component of the hierarchy of the data center (500), as will be described herein with reference to Figure 5A. The machine pool is packaged at 542) a machine benefit 1 (5 〇 2) and machine yeah (7). Machine U502) executes VM-A (5〇6) owned by RecLCompany and Machine 1 (5〇2) is also executed by

VM_B (51〇) owned by Blue_C〇mPany. In addition, machine 2 (512) executes I59868.doc • 12· 201234173 VM_C (516) owned by Red_Company and machine 2 (512) also executes VM_D (520) owned by Blue_Company. The following example demonstrates how different component clusters can be used by different objects: Example 1: A data center owner may wish to validate each VM in a machine pool to produce, for example, VM_A, VM-B, VM_C& VM_D Associated verification set; Example 2: The system administrator may wish to validate each VM on a particular physical machine to generate an associated validation set containing, for example, VM_A, VM_B on Machine 1; Example 3: Company may It is desirable to verify each of its VMs regardless of which physical machine the VMs reside on, thereby generating an associated verification set containing, for example, VM_B&VM_D. Other examples of component grouping include: One or more machine pools. Preferably, the verification set contains a list of records associated with a particular component of the data center (for example): (i) PCR; (ii) VM; (iii) machine; or (iv) machine pool. For example, the following shows Attestation 861; _ is: { PCRs 0-15.VM-A.Machinel.Machine Pool 1 PCRs 2-6.VM-C.Machine2.Machine Pool 1 } Preferably, it can be set Preset values for components of the data center (eg, preset PCR sets) to account for the convenience of establishing a validation set. For example, if each VM in the data center has 16 PCRs (only the even number of PCRs of 159868.doc -13-201234173 is important) and thousands of VMs exist in the data center, The following description of the validation set for each VM can become cumbersome:

Attestation_Set_VM_n= {

Childl=PCRs 0,2,4,6,8,10,12,14; VM_n } Preferably, a preset description about the set of verifications can be generated as follows: default_PCRs=0, 2, 4, 6, 8, 10, 12

Attestation_Set_VM_n= {

Childl = default_PCRs: VM_n } Preferably, each validation set has an associated rule that describes how to determine if the collection is trusted. Preferably, if the verification set does not contain an associated rule, a preset rule is applied. In one example, the rules govern whether the collection is trusted based on the state of the children of a set. For example, all children of a collection must be considered trusted before considering a parent collection as trusted. In another example, 50% of the children must be considered trusted or must have the highest priority child considered trusted before considering a parent collection as trusted. In another example, the rules are based on whether the set is allowed to be trusted, for example, by the time value that the child is untrusted during the known maintenance period. 159868.doc • 14- 201234173. For example, if the current time value is between 0400 and 0430, the child can be considered trusted, otherwise the child is considered untrusted (until otherwise) (eg, by using a verification handler) ) to prove it). In yet another example, the 'regular control collection is always trusted or always untrusted, for example, the "always trusted" rule can be used to temporarily stop the occurrence of an alert known to be erroneous on the machine; The Always Untrusted rule is available to test if the security alert mechanism is working correctly. Other examples of validation sets and associated rules are described below with reference to Example 1, Example 2, and Example 3 above. Example 4 (associated with Example 1 above):

Attestation Set_l = {

Childl=PCRs[0-15].VM[A].Machine[l]

Child2=PCRs[0-15].VM[B].Machine[l]

Child3=PCRs[0-15].VM[C].Machine[2]

Child4=PCRs[0-15].VM[D].Machine[2]

Rule=if(all children are trusted) then TRUSTED else UNTRUSTED; } In the above rule, all children of a collection must be considered trusted before considering a parent collection as trusted. Example 5 (associated with Example 2 above):

Attestation Set_2= {

Child 1 =PCRs [0-15]. VM[A] .Machine [ 1] 159868.doc -15- 201234173

Child2=PCRs[0-15].VM[B].Machine[l]

Rule=if(>25% all children are trusted) then TRUSTED else UNTRUSTED; } In the above rule, more than 25% of the children of a set must be considered trusted before considering a parent collection as trusted. of. Example 6 (associated with Example 3 above):

Attestation Set_3= {

Childl=PCRs[0-15].VM[B].Machine[l]

Child2=PCRs[0-15].VM[D].Machine[2]

Rule=if( (Childl is trusted)=(Chlid2 is trusted)) then TRUSTED else UNTRUSTED } In the above rule, when the child of the parent set has the same trusted state, the parent set is considered trusted (ie, Both children must be considered trusted or both children must be considered untrusted). The above rules can be used, for example, in the following cases: Child 1 and Child 2 are configured to always have software updates for parallel applications. If any child is updated and another child is not updated, one child will fail validation and the other child will pass validation. This situation means that the parent collection will be considered untrusted (thus making ( For example) an alert can be raised to an administrator). In the above example, each validation set specifies the particular component of interest. However, the above verification set does not necessarily reflect the functional dependencies of the hierarchy or data center associated with the physical hierarchy of the data center configuration - these verification sets are described below. Referring to Figure 5B, a verification set can be associated with a logical hierarchy that maps the physical hierarchy of the data center (500) configuration. For example, an authentication set for each VM (e.g., VM (506)) can be established:

Attestation_Set_VM_A= {

Childl=PCRs[0-15].VM[A] } In another example, a verification set can be established for each machine, whereby the verification status of a machine (eg, machine 1 (502)) is A union of the verification states of each of the verification sets of the VMs of the machine (eg,

Attestation_Set_VM_A& Attestation_Set_VM_B):

AttestationSetMachine 1 = {

Child 1 = Attestation_Set_VM_A Child2 = Attestation_Set_VM_B } In another example, a verification set for each machine pool may be established, whereby the verification status of a machine pool (eg, machine pool 1 (542)) is The union of the validation states of each of the validation collections of machines in the machine pool (eg, Attestation_Set_Machinel and Attestation_Set_ Machine2):

Attesatation Set Pooll = 159868.doc -17· 201234173

Child l=Attestation_Set_Machinel Child2=Attestation_Set_Machine2 } In another example, a verification set for one of each data center can be established. By means of a data center (for example, the data center (500)), the verification status is the machine of the data center. A union of the validation states of each of the collections of the collections (eg 'Attesatation Set Pooll and Attesatation — __

Set_Pool2):

Attestation_Set_Datacenter= {

Child 1 = Attesatation_Set_Pool 1 Child2 = Attesatation_Set_Pool2 } Referring to Figures 5C and 5D, a verification set can be associated with the functional dependencies of the data center rather than the physical level. Referring to the example depicted in Figure 5C, VM_A (506), VM_B (510), and VM_C (5 16) operate together to provide a web service' thereby also displaying associated PCRs (504, 5 08, and 514, respectively).乂1^_(: Master the main web server (550), the main web server (550) and the master website 6 whenever the specific web page on the website is requested, the main web server (550) uses the secondary Web server (548) (eg, hosted on \^1^_6). The secondary web server (548) uses the database (546) hosted on VM_A to retrieve the web page needed to display In this way, each VM is functionally dependent on each other. 0 159868.doc • 18 · 201234173 Referring to Figure 5D, another depiction of functional dependencies is shown, thereby associating a VM with its PCR and another VM: For example, associate VM_C (516) with its PCR (514) and VM_B (510); associate VM_B (510) with its PCR (508) and VM_A (506); and correlate VM_A (506) with its PCR (504) The following shows an example of how the validation set can be associated with the functional dependencies depicted in Figure 5D:

Attestation_Set_VM_A= {

Childl=PCR[0-15].VM[A] }

Attestation_Set_VM_B= {

Childl=PCR[0-15].VM[B]

Child2=Attestation_Set_VM_A }

Attestation_Set_VM_C= {

Childl=PCR[0-15].VM[C]

Child2 = Attestation_Set_VM_B } The processing procedure of the preferred embodiment will now be described with reference to FIG. In a working example, a verification set to be verified is associated with a subset of the logical hierarchy of FIG. 5B (where the data center (500) represents a managed system 159868.doc • 19- 201234173 (120, 200) ). In the example herein, the management system (105, 305) wishes to verify the validation set Attesatation_Set_Pooll, one of which is shown below: Attesatation_Set_Pooll = {

Child 1 =Attestation_Set_Machine 1 Child2=Attestation_Set_Machine2 } With this:

Attestation_Set_Machinel = {

Child 1 =Attestation_Set_VM_A Child2=Attestation_Set_VM_B }

Attestation_Set_VM_A= {

Childl=PCRs[0-15].VM[A] }

Attestation_Set_VM_B= {

Childl=PCRs[0-15].VM[B] }

Attestation Set Machine2= 159868.doc -20· 201234173

Child 1 =Attestation_Set_VM_C Child2=Attestation_Set_VM_D }

Attestation_Set_VM_C= {

Childl=PCRs[0-15].VM[C] }

Attestation_Set_VM_D= {

Childl=PCRs[0-15].VM[D] } Referring to the processing procedure of FIG. 6, at step 600, for the verification set Attestation_Set_Pooll, a list of children of the collection is retrieved, such as Listing 1: Machine 1 and Machine 2. At step 605, a determination is made as to whether any of the children of the set (Listing 1) are still pending verification. In this example, because either of machine 1 or machine 2 is not verified, the process proceeds to step 610 where the details of the unverified child are retrieved (in this example) For the machine 1). Used to verify that the processing of machine 1 begins and saves the indicator pointing to machine 2. At step 615, it is determined if the unverified child is also a verification set. For example, the management system (305) parses the set description to determine the value of the parameter "Childx" - if the value begins with "PCRs", the management system (305) determines that the child is not a validation set and if the value is Non-159868.doc -21 · 201234173 The value of "PCRs" begins, and the management system (305) determines that the child is also a validation set. The management system (305) can store a flag coexisting with each child, the flag indicating whether the child is a verification set. In this example, the child collection machine 1 is also a validation set:

Attestation Set Machinel = — —· {

Child l=Attestation_Set_VM_A

Child2=Attestation_Set_VM_B } The handler returns to step 600, whereby a list of children of the set is retrieved for the validation set Attesatation_Set_ Machinel, such as Listing 2: VM_A and VM_B. At step 605, a determination is made as to whether any of the children of the set (Attestation_Set_ Machine 1) are still to be verified. In this example, since either of VM_A or VM_B is not verified, the process proceeds to step 610, where the details of the unverified child are retrieved (in this example) Medium, for VM_A). The handler to verify VM_A starts and saves the indicator pointing to VM_B. It should be noted that the state of machine 1 at level N is saved and control is passed to recursive level N+1 (associated with 乂]\4_8 and VM_B). At step 615, it is determined if the unverified child is also an authentication set. In this example, a validation set:

Attestation Set VM A= 159868.doc -22- 201234173

Childl=PCRs[0-15].VM[A] } The process returns to step 600 whereby a list of children of the set is retrieved for the validation set Attestation_Set_VM_A, such as Listing 3: PCRs [0-15]. At step 605, a determination is made as to whether any of the children of the set (Attestation_Set_VM_A) are still pending verification. In this example, since the PCRs [0-15] are not verified, the process proceeds to step 610 where the details of the unverified progeny are retrieved (in this example, PCRs[0 -15]). At step 615, it is determined if the unverified child is also an authentication set. In this example, PCRs [0-15] are not a validation set and the process proceeds to step 625. The management system (105, 305) performs a verification to determine the trusted or untrusted status for PCRs [0-15] by contacting VM_A to retrieve PCRs [0-15] along with the event log (235). . The management system (305) retrieves the expected verification values associated with the captured PCRs to compare the expected verification values with the PCRs retrieved. If a match occurs for each PCR value, then VM_A is considered trusted and no further work is required. If no match occurs for each PCR value, the management system (305) parses the event log file, examining each item in turn to determine one (or more) contained in the item associated with the PCR in question. Whether the measured value is valid (based on a list of trusted values provided by a specific manufacturer). If each event log file item is valid, VM_A is considered trusted and no further work is required. 159868.doc -23· 201234173 Further work is required. If the event log file item does not appear to be valid, it will not be trusted. In this example, following the process of Figure 4, VM_A2PCRs [0-15] are considered trusted. The process then passes to step 605 where it is determined if any of the children is still to be verified. Since there are no other children to be verified, the process proceeds to step 630 where the rules associated with the current validation set (ie, Attestation_Set_VM_A) are retrieved (eg, rule l= If(>25% all children are trusted) then TRUSTED else UNTRUSTED)» At step 635, Attestation_Set_VM_A is considered trusted if the rule is satisfied and Attestation_Set_VM_A is considered untrusted if the rule is not met Any. In this example, Attestation_Set_VM_A is considered trusted because VM_AiPCRs[0-15] (> 25% of all children) are considered trusted. The process proceeds to step 605 and proceeds back one level (to N)'. In step 605, it is determined whether any of the children of the set (Attestation_Set_Machinel) are still to be verified. Referring to the saved indicator 'because VM-B is still to be verified, the process goes to step 610' where in step 610 the details of the unverified child are retrieved. The process to verify VM-B begins. At step 615, it is determined whether the unverified progeny is also a test 159868.doc • 24· 201234173 certificate set. In this example, VM_B is also a validation set:

Attestation_Set_VM_B= {

Childl=PCRs[0-15].VM[B] } The process returns to step 600, whereby a list of children of the set is retrieved for the validation set Attesatation_Set_VM_B, for example Listing 4: PCRs [0-15]. At step 605, a determination is made as to whether any of the children of the set (Attesatation_Set_VM_B) are still pending verification. In this example, since the PCRs [0-15] are not verified, the process proceeds to step 610 where the details of any unverified progeny are retrieved (in this example, PCRs [ 0-15]). At step 61 5, it is determined whether the unverified child is also an authentication set. In this example, PCRs [0-15] are not a validation set and the process proceeds to step 625. Referring to the processing procedure of FIG. 4, the management system (105, 305) performs a verification to determine the trustedness for PCRs [0-15] by contacting VM_B to retrieve PCRs [0-15] along with the event log file (235). Any state or untrusted state. In this example, following the process of Figure 4, VM_BiPCRs [0-15] are considered trusted. The process then passes to step 605 where it is determined if any of the children is still to be verified. Since there are no other 159868.doc -25 - 201234173 children to be verified, the process proceeds to step 630 where the rules associated with the current validation set (ie, Attesatation_Set_VM_B) are retrieved ( For example, rule 2 = if (all children are trusted) then TRUSTED else UNTRUSTED). At step 635, if the rule is met, then Attesatation_Set_VM_B is considered trusted and if the rule is not met, Attesatation_Set_VM_B is considered untrusted. In this example, PCRs [0-15] (all children) of VM_B will be trusted because they are considered trusted. The process proceeds to step 605 and proceeds back one level (to N), and in step 605, it is determined whether any of the children of the set (Attestation_Set_Machinel) are still to be verified. Since there are no other children to be verified, the process proceeds to step 630 where the rules associated with the current validation set (ie, Attestation_Set_Machinel) are retrieved (eg, rule 3 = if() All children are trusted) then TRUSTED else UNTRUSTED). At step 635, Attestation_Set_ Machinel is considered trusted if the rule is satisfied and Attestation_Set_Machinel is considered untrusted if the rule is not met. In this example, Attestation_Set_Machinel is considered trusted because VM_A&VM_B (all children) is considered trusted. It should be noted that in the examples herein, the PCR of Machine 1 does not form part of the verification check. However, alternatively, if a component has a TPM (125), then 159868.doc -26- 201234173 may also have its PCR verification. For example, the following set of validations for machine 1 can be used, where child 3 represents the PCR of machine 1: Attestation_Set_Machine 1 = {

Child 1 = Attestation_Set_VM 1 Child2 = Attestation_Set_VM2 Child3 = PCRs [0-16]. Machinel } When the processing for verifying the completion of the machine 1 is completed, the processing proceeds to step 605, in which the set is determined (Attesatation_Set_ Pool 1) Whether any of the remaining children are still to be verified. Referring to the saved indicator, it is determined that the machine 2 is still to be verified, and the process goes to step 610 where the details of the unverified child (machine 2) are retrieved. It should be understood that the above described processing procedure has been repeated for machine 2 as shown for machine 1, resulting in a state (trusted state or untrusted state) associated with the child of machine 2 (i.e., Attestation_Set_VM_C& Attestation_Set_VM_D). In the example in this article, the state associated with Attestation_Set_VM_C^g is trusted and the state associated with Attestation_Set_VM_D is trusted. In this example, Attestation_Set-Machine2 is also considered trusted according to the rules of Attestation_Set_Machine2 (not shown). After the verification of the machine 2, the process proceeds to step 605, where it is determined whether any of the remaining children of the set Attesatation_Set_Pooll is still pending verification in 159868.doc -27-201234173. Since there are no other children to be verified, the process proceeds to step 630 where the rules associated with the current validation set (ie, AttesatationSetPooll) are retrieved (eg, rule 4 = if ( All children are trusted) then TRUSTED else UNTRUSTED). At step 635, if the rule is met, Attesatation_Set_ Pooll is considered trusted and if the rule is not met, Attesatation_Set_Pooll is considered untrusted. In this example, because Machine 1 and Machine 2 (all children) are considered trusted, it should be noted that Attesatation_Set_Pooll is trusted. If the verification fails at any point in the hierarchy, the user can check The failure is below the level to check the cause (until the final identification of individual PCRs with errors). For example, if each VM Attesatation_Set_Pooll other than VM A is considered trusted, Attestation_Set_VM_A will have an associated untrusted state. because

The child of Attestation_Set_Machinel is 1, so given the rule 3, the state of Attestation_Set_Machinel will be untrusted (even if the state of child 2 of Attestation_Set_Machine 1 is trusted). Also, since Attestation_Set_Machinel is a child of Attesatation_Set_Pooll, the state of Attesatation_Set_PooIl will be untrusted given rule 4. Thus, if the management system requests verification of Attesatation_Set_Pooll, an untrusted result will be returned. Preferably, a user interface 159868.doc • 28- 201234173 is used to indicate the reason for the failure. For example, at a first level, a report can be displayed indicating that Attesatation_Set_Pooll is untrusted' because the child 1 (Attestation_Set_Machinel) is untrusted. Preferably, the user can query the report to determine that Attestation_Set - Machinel is considered untrusted, etc., until the underlying cause of the failure of the user is informed that VM_A is deemed untrusted. The user can then, for example, contact a system administrator to determine exactly where the failure occurred in VM-A. The present invention provides a mechanism in which the status of individual data center components can be obtained and combined such that, for example, verification results associated with a plurality of managed systems can be provided. Advantageously, given a set to be verified The management system (105, 305) can determine the status of each of the children associated with the set. : The above description 'every-child generation can itself be a verification set. In more complex implementations, - or multiple progeny may have been validated because the progeny are presented in multiple collections. There is a target definition_validation set to meet the needs of, for example, the following: f-center owner 4 administrators and end customers. The following will be apparent to those skilled in the art: 2 All or part of the method of the preferred embodiment may be suitably and applicable to a logical device or a plurality of logical devices, the logical device comprising: Logic elements that have performed the steps of the method; and such logic elements can include hardware components, components, or combinations of such components. For those of ordinary skill in the art, the following is also apparent 159868.doc • 29-201234173. All or part of the logic configuration in accordance with a preferred embodiment of the present invention may suitably be embodied in a logic device, the logic device Logic elements are included to perform the steps of the method, and such logic elements can include components such as, for example, a logical array in a programmable logic array or a special application integrated circuit. This logic configuration can be further embodied in an enabling component for temporarily or permanently establishing a logical structure in the array or circuit using, for example, a virtual hardware descriptor language, the virtual hardware description The language can be stored and transmitted using fixed or transportable carrier media. It should be appreciated that the methods and configurations described above may also be suitably performed, in whole or in part, in software (not shown) executed on one or more processors, and may be carried on any suitable data carrier. The software is provided in the form of one or more computer program components (not shown in the figures) (such as a magnetic disk or a compact disc or the like). Channels for the transmission of data may equally include all of the described storage media as well as carrier signal media (such as wired or wireless carrier signal media). The invention may be further suitably embodied as a computer program product for use with a computer system. This embodiment may comprise a series of computer readable instructions, either affixed to a tangible medium, such as a computer readable medium (eg, 'disc, CD-ROM, ROM or hard drive), or via data The machine or other interface device is transferred to the computer system via tangible media (including but not limited to optical or analog communication lines) or invisibly using wireless technology including, but not limited to, microwave, infrared or other transmission technology. The series of computer readable instructions embody all or part of the functionality previously described herein. 159868.doc •30- 201234173 :, s This technology should be aware that it can be used to write such computer commands in a number of programming languages with many computer architectures or applications. In addition, 'any current or future memory technology can be used to store such software.' Memory technologies include, but are not limited to, semiconductors, magnetics, or any communication technology that is used or used in the future to transmit this. Etc. 'Communication technology includes, but is not limited to, optical, infrared or microwave. It is expected that the computer program product can be distributed as a removable medium (for example, a ready-to-use software) with accompanying printed or electronic documents, and the ready-to-use software is preloaded with the computer system (for example) system R〇M. Or on a fixed disk; or distribute the computer program product via a network (such as 'Internet or World Wide Web') from the (4) or electronic bulletin board. In an alternative, a preferred embodiment of the present invention may be implemented in the form of a computer implemented method of deploying services of the following steps: deploying a computer code operable to be deployed in a computer infrastructure or in a computer Execution on the infrastructure causes the computer system to perform all the steps of the described method. It will be apparent to those skilled in the art that many modifications and changes can be made to the foregoing exemplary embodiments without departing from the scope of the invention. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram showing a known system for performing a trusted boot and remote authentication processing program according to the prior art, and a preferred embodiment of the present invention can be implemented in the known system 2 is a block diagram showing components of a known managed system according to the prior art, and a preferred embodiment of the present invention may be implemented in the managed system; 159868.doc 201234173 FIG. 3 is a diagram showing use according to the prior art. A block diagram of a more detailed view of a known system for performing a trusted boot and remote verification process, and a preferred embodiment of the present invention can be implemented in the known system; FIG. 4 is a view showing the prior art. FIG. 5A is a block diagram showing the organization of a physical machine in a typical data center in accordance with a preferred embodiment of the present invention; FIG. 5B is a view showing a comparison of physical machine organization in a typical data center according to the preferred embodiment of the present invention; A block diagram of the logical hierarchy of the physical organization of Figure 5a of the preferred embodiment; Figures 5C and 5D are diagrams associated with the components of the data center of Figure 5A, in accordance with a preferred embodiment of the present invention. A block diagram of the functional dependencies; and a flowchart showing the operational steps involved in the verification process in accordance with a preferred embodiment of the present invention. [Main Component Symbol Description] 100 Environment 105 Remote Management System 110 Trusted Platform Module (ΤΡΜ) Simulator 115 Database 120 Managed System 125 Trusted Platform Module (ΤΡΜ) / Security Device 200 Managed System 205 User Space program 210 operating system 215 firmware 159868.doc -32-201234173 220 225 230 235 300 305 310 325 500 502 504 506 508 512 514 516 518 520 522 524 526 528 530 Trusted Measurement Root (CRTM) Trusted Platform Module (TPM) Platform Configuration Register (PCR) Event Log File System Remote Management System Simulator Database Data Center Machine Platform Configuration Register (PCR) Virtual Machine (VM) Platform Configuration Register (PCR) Virtual Machine (VM) Machine Platform Configuration Register (PCR) Virtual Machine (VM) Platform Configuration Register (PCR) Virtual Machine (VM) Machine Platform Configuration Register (PCR) Virtual Machine ( VM) Platform Configuration Register (PCR) Virtual Machine (VM) 159868.doc • 33· Machine Platform Configuration Register (PCR) Virtual Machine (VM) Platform Configuration Register (PCR) Virtual Machine (VM) Machine Machine pool area secondary database web server main web server -34-

Claims (1)

201234173 VII. Patent application scope: 1. A method for verifying a plurality of data processing systems, comprising the steps of: generating a logical grouping for one of the data processing systems, wherein the logical grouping is associated with a rule, the rule Describe a condition that must be met in order to achieve the purpose of the material processing system as being trusted; to retrieve a list of one or more of the children associated with the logical grouping; to verify the child or each child Determining whether the child or each-child is trusted; in response to the verifying step, applying the rule to determine whether the condition for achieving the purpose of trusting the data processing system is satisfied; and making the plural The logical clusters are associated such that it can be determined whether the associated plurality of data processing systems can be considered trusted. 2. The method of claim 1, wherein the logical grouping is associated with at least one of: a physical hierarchy; and a functional dependency. 3. The method of claim 1 or claim 2, wherein one of the progeny is associated with a platform controlled temporary benefit (PCR) or another logical grouping; or "the intermediate step further comprises: authenticating according to an expectation The value or a value determined by the L value is for a trusted (10) state or an untrusted state of _ pcR. If the method of the month 3 item 3 'where if the child is associated with another logical group' then repeats the 撷Take steps until you find one of the 159868.doc 201234173 children associated with a PCR. 5. As requested by the requestor or the method of item 2, the data associated with the logical grouping; The following steps are performed by the processing system: the certification step; the use of + ^. the retrieval step; the inspection &quot; application step; and the associated step. 6. If the request item or request -r-^ ^ Each of the data processing systems is not subject to the official system; or is associated with: the logical sub-trusted state; and a state in which the rule and the following order are at least _ the group of such progeny; Value; untrusted state. The method of claim 6, wherein the rule is associated with a predetermined percentage of a child; or wherein the right is responsive to the verifying step and the predetermined percentage of the child is deemed to be trusted, the data is processed in response to the applying step The system is considered to be trusted. 8. A device for verifying a plurality of data processing systems, comprising: means for generating a logical grouping for a data processing system, wherein the logical grouping is associated with a rule The rule describes a condition that must be met in order to achieve the purpose of the data processing system being trusted; for excavating one of the one or more children associated with the logical knife group 159868.doc • 2 - 201234173 a component of a single; a component for verifying the child or each child to determine whether the child or each child is a trusted component; for applying the rule in response to the verification component to determine whether Means for achieving the condition that the material processing system is deemed to be trusted for the purpose; and for associating the plurality of logical groups to make Whether the associated plurality of data processing systems can be considered as a trusted component. 9. The device of claim 8, wherein the logical grouping is associated with at least one of: a physical class and a Functional Dependency 10. The device of claim 8 or claim 9, wherein one of the children is associated with a platform control register (PCR) or another logical group; or if one child and another logical group </ RTI> </ RTI> </ RTI> </ RTI> </ RTI> </ RTI> </ RTI> </ RTI> </ RTI> </ RTI> </ RTI> </ RTI> <RTIgt; A verification value or a trusted value determines a component that is trusted or untrusted for one of the PCRs. 12. The device of any one of claims 8 to 9, wherein a management system is operative to maintain data associated with the logical grouping; or one of the management systems is operative to perform the following component: the capturing component the verification a member; the application member; and the associated member. 13. The device of any of claims 8-9, wherein each data processing system 159868.doc 201234173 represents a managed system; or wherein the rule is associated with at least one of: the logical grouping The state of the child; a time value; a trusted state; and an untrusted state. M. The device of claim 13, wherein the rule is associated with a predetermined percentage of the child; or the predetermined percentage of the child is responded to the information, and the information is deemed to be trusted if the verification component is responsive The application component processing system is considered trusted. 15. A computer program, its package code, the computer code is I:. Electricity: the computer on the readable medium is executed on the computer system, and the computer system is executed in any one of the methods All of these steps, such as requesting items 1 through u. 159868.doc