JP2009518762A - A method for verifying the integrity of a component on a trusted platform using an integrity database service - Google Patents

Abstract

The client platform is validated by validating individual hardware or software components on the client platform before allowing access to resources or services on the network. Digests are generated for multiple components of the client platform. These digests are collected into an integrity report. The authenticator entity receives this integrity report and compares these digests with the digests stored in either or both the local signature database or the global signature database in the integrity authority. Alternatively, the digest can be collected and stored in a portable digest collector dongle as another method. If these digests are valid or invalid, an overall integrity / trust score is generated. The overall integrity / trust score is used to determine whether access to resources on the client platform's network should be allowed using policies.
[Selection] Figure 1

Description

  The present invention relates to the use of trusted computers and network security, and more particularly to the integrity of multiple components of the client platform prior to permission from the client platform to access resources or services on the network. ) To decide.

  The world has changed with the growth and growth of the Internet. In the late 1970s and early 1980s, the Internet was just born and was part of an interconnected computer dedicated to the Ministry of Defense and several academic disciplines. In the early 1990s, the Internet became known to the public. The easier the public has access to the Internet, the larger and more complex the Internet is. As a result, the Internet has grown fragmented. In particular, software and hardware developers have developed a wide variety of devices that can be connected to the Internet. The development of these devices continues to evolve, and as a result, there are a wide variety of devices that can be connected to the Internet today. In general, PC clients, servers, PDAs (Personal Digital Assistants), mobile phones, routers, and other devices that can be connected to other networks are all interconnected via the Internet. In the area of security and authentication, these interconnectable devices are changing on a regional and global scale.

  In many undeveloped areas of the Internet, undesired trends are occurring. Malicious people illegally sell fake hardware and software components to the illegal market. Pirated software, viruses, worms, and other dangerous things are also a threat. These threats threaten the safe and healthy Internet, its users, and their data. Business owners who rely on the Internet to promote commerce find that they must face these endlessly growing threats when business survival is a top priority. Similarly, individual Internet users are concerned about the integrity and safety of data containing personal information such as their personal financial transaction information. Endpoint integrity on the network has become a major concern for businesses and the network industry.

  Anti-virus software, spam filters, and other software products that exist today identify, block, and remove computer viruses, other malicious software (malware, malware) and other user attempts Addresses some of the above problems. However, blocking the virus itself does not solve the problem of ensuring the integrity of the software and hardware components of the client platform. In particular, the software products described above cannot verify whether the hardware or software is a genuine component that relies on a known reliable standard. For example, anti-virus software does not prevent the computer system from logging into the network, even if the problematic computer system has malicious software, and checks the integrity of the hardware components There is nothing. Anti-virus software also does not take any precautions if the client platform may have illegal components.

  Despite the efforts of anti-virus software manufacturers, more and more malware is being introduced into corporate networks through “tainted” machines. For example, such “pollution” can occur when an employee carries a laptop computer on a business trip and connects to a network such as the Internet outside the corporate network. As a result, the machine is “contaminated” by some sort of malware. The “contaminated” machine can then be returned to the internal network, threatening the integrity of the entire internal network. Recent legislation such as the Sarbanes-Oxley Act, which makes the Chief Information Officer (CIO) responsible for the safety, accuracy and reliability of systems that manage and report financial data In light of this, machine integrity is particularly important.

  Banks are a good example of an industry that is particularly vulnerable to client platforms with malware and illegal components. Originally, banks kept financial information that should be treated with caution and, of course, are trying to ensure that the information is secure. Today, known client platforms that are requesting access to a bank's network have the overall integrity required to conduct a transaction, and to the extent that they do not pose a serious threat to the network, Yes, but the bank is not able to grasp it.

  Therefore, there remains a need for a method for identifying and validating valid components of client platform hardware and software components that may be in an improper state before being granted access to network services and resources. ing. The present invention solves the above problems and other problems associated with the prior art.

  The present invention authenticates a client platform, generates an integrity report of at least one component of the client platform, signs integrity, and is stored in a database of integrity reports and integrity authorities. The present invention relates to a method and apparatus for permitting access to resources and services on a network by comparing the integrity / trust record of the network.

  The foregoing features, objects, and advantages of the present invention, as well as other features, objects, and advantages will be apparent from the following detailed description taken in conjunction with the accompanying drawings.

Detailed Description of the Preferred Embodiment

  Embodiments of the present invention verify the integrity of supplicant (also referred to as client platform) software and hardware modules and components (hereinafter collectively referred to simply as “components”). It is. The client platform collects information on components to be verified (hereinafter also referred to as “digest” and “signature”). The digest is compiled as a client integrity report (referred to as an “integrity report”). The integrity report can be sent to a server such as an authentication server or other authenticator entity. The digest is then compared to the component integrity / trust record (also referred to as “integrity / trust record”). The integrity / trust record was previously collected by the integrity authority described below. As a result of the comparison, the reliability of the client platform is verified.

  The integrity authority has a database containing integrity / trust records. In one embodiment, a global signature database (GSDB) provides an integrity / trust record that contains information about a myriad of software and hardware components. This information has been collected in advance from software and hardware manufacturers, has been refined, and has been assigned an individual integrity / trust score. In another embodiment, a local signature database (LSDB) provides integrity / trust records. The LSDB can be configured to be updated periodically or synchronized with the GSDB.

  In one embodiment, the digest can be obtained from a commercial product and can be obtained by collecting records from a purchased version. In another embodiment, the digest can be collected by uploading from the manufacturer or by obtaining information by direct means. The latter method generally takes into account certainty about the component's “Chain-of-Custody”. This is because there are fewer intermediaries (eg, owners) that can tamper with the components of a product in an attempt to circumvent technical defenses. In general, if the number of intermediaries in the distribution process history is small, it is difficult to tamper with product components. Nonetheless, if tampering occurs, those skilled in the art will recognize that it is not a genuine “rule”. Those skilled in the art will also appreciate that there are methods for collecting digests other than those obtained directly from commercial products or manufacturers.

  The authenticator entity can use the information in the database to assess the level of trust of the client platform. Client platform reliability levels are evaluated by comparing the integrity / trust records in the database with the individual components stored in the integrity report received from the client platform to calculate the overall integrity / trust score for the client platform. Is done. The overall integrity / trust score can be affected by several factors. For example, the distribution history of a component whose digest is stored in an integrity report can affect the individual integrity / trust score assigned to the component in the integrity / trust record, and ultimately the client It can affect the overall integrity / trust score determined for the platform. As noted above, digests collected directly from manufacturers appear to be more reliable than those collected as digests from commercial products. And if the digest is more reliable, the digest can lead the client platform to be significantly more “reliable”. Another factor for verifying the “trust” of the client platform is the authentication method used to sign the integrity report. Once the overall integrity / trust score is verified, the score is used for further decision making and allows or disallows the client platform to access resources or services on the network according to predefined policies It is used for the determination.

  FIG. 1 shows a system 105 that includes various client platforms 110 such as a personal computer 115, a network element 120, a mobile phone 125, and a personal digital assistant 130. Those skilled in the art will also recognize that there are other types of clients that can be used in the system 105 such as notebook computers, kiosks, digital cameras, and the like. Each client platform 110 can be connected to a network 135. Network 135 is any network that can interconnect devices. For example, the network includes a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), and a global network such as the Internet. In addition, the network can use any connection type, for example, a wired connection such as the IEEE 802.3 standard (Ethernet), a wireless connection of any of the IEEE 802.11 standards, and any combination of wired and wireless connections. Can be used.

  Also, integrity authority 140 and authenticator entity 145 are shown as being connected to network 135. As described below with respect to FIG. 2, the authenticator entity 145 may include one or more servers, such as an authentication server, a verification server, and a policy server, in accordance with various embodiments of the invention. Can have. Similarly, the integrity authority 145 may have one or more servers that perform the functions described below. Although FIG. 1 shows the integrity authority 140 and the authenticator entity 145 separately, those skilled in the art will recognize that the functions of the integrity authority 140 and the authenticator entity 145 are the same physical machine or the same physical It will be appreciated that a plurality of virtual machines (virtualization will be described later) can be integrated and operated by a single machine. For example, if both the integrity authority 140 and the authenticator entity 145 are controlled by a single enterprise, it makes sense to have a single server that performs the functions of both machines. The integrity authority 140 and the authenticator entity 145 work in conjunction when enabling the client platform or making a decision whether to allow access to the resource 150. Resource 150 can be a variety of services, among others, a web service or its application, server, network (such as a network within an organization where access control is provided), printer, flash memory disk, or others Solid state memory devices, one or more storage devices, and an output or display.

  The integrity authority 140 stores data for both the hardware and software components described above. This data can be provided to other components on the network 135 (eg, the authenticator entity 145). The integrity authority 140 will be described in the description of FIGS.

  The image file 155 may be installed on a client platform such as the client platform 110. Various methods and embodiments for installing the image file 155 are described below. The various components shown in FIG. 1 have a receiving device and a transmitting device for receiving / transmitting various data between machines of the system 105. These operations will be described later.

  As described above, the integrity authority 140 and the authenticator entity 145 are composed of multiple servers. You will understand that In addition, each of the following machines can be instantiated as a plurality of virtual machines running on one or more computers. One or a plurality of computers may have any configuration. Furthermore, all machines used to verify platform integrity can be instantiated as multiple virtual machines running on a single piece of hardware. In this case, a plurality of virtual machines exchange information as if they are all different hardware. Also, the integrity authority 140 and authenticator entity 145 can be instantiated as virtual machines running on the client platform 110 under the protected domain. Those skilled in the art will appreciate other possible configurations of virtual machines. Machine virtualization on hardware can also be applied to all of the following machines, whether or not they can be explicitly enumerated.

  FIG. 2 shows an embodiment of an authenticator entity 145 comprising a verification server 205, an authentication server 210 and a policy server 215. In FIG. 2, the authenticator entity 145 is installed in one place, and the verification server 205, the authentication server 210, and the policy server 215 are installed in the same place. It will be understood that it may be installed in a location. In another embodiment, the authenticator entity 145 includes a verification server 205 and a policy server 215, and the functionality of the authentication server 210 is achieved by the verification server 205. In yet another embodiment, the authenticator entity 145 comprises one server, and the functions of the authentication server 210 and policy server 215 are achieved by the validation server 205. One skilled in the art will appreciate that there are other combinations of functions for the validation server 205, authentication server 210, and policy server 215. In other words, in light of some embodiments of the present invention, any function performed by several server entities shown in FIG. 2 can be performed by one or more servers. The policy server 215 is called a policy decision point (PDP), and the authentication server 210 is called a policy enforcement point (PEP).

  The verification server 205 is configured to verify the integrity status of the client platform 110. Each client platform (eg, 115, 120, 125, 130 shown in FIG. 1) collects information about the component 160 of each client platform. This information is also referred to as “digest” or “signature”. These pieces of information are collected from a platform configuration register (PCR) in the Trusted Platform Module (TPM) chip. The TPM chip is a security-hardware chip that has been standardized and recommended by an organization of the Trusted Computing Group (TCG). The security features of the TPM chip are distinct from security technologies that use other hardware such as smart cards. For example, the TPM chip has functions for measuring integrity, collecting metrics, and reporting. The metrics digest is then stored in the PCR. The TPM chip also supports “shield location”. A shielded location provides a secure portion of memory where sensitive operations can be performed without risking data loss and without exposing to unauthorized instructions. In addition, TPM chips support “protected capabilities”. Protected capabilities are a set of commands that are prohibited from accessing shielded locations. The above and other features make the TMP chip ideal for a reliable computing environment.

  Digests can also be generated from other parts and features specific to the platform. The above features are, for example, registers not associated with the TPM, applications, processes, services, threads, and the like, and provide reliable information from trusted sources about the component 160 of the client platform 110. It may be a thing. When generating the digest of the application software, the digest can be generated from several files that are part of the application, and each such file is a component. For example, if the software suite includes a word processor, spreadsheet, and email package, the digest is generated from each executable and each associated library file that is part of the suite, although other possibilities are possible. can do. In some embodiments, all files that are part of a software application can be considered components, and in other embodiments, components are more selectively identified. Those skilled in the art will understand how other software application components can be identified.

  The digest may include a hash of component 160. The component hash can be generated using a one-way cryptographic hash function. One-way cryptographic hash functions include MD5, SHA-1, SHA-256, etc., and those skilled in the art will understand other one-way cryptographic hash functions that can be used. The integrity report generator 165 collects all of the digests, including hashes and other generated information, and generates an integrity report 170. As will be described later in the description of FIG. 6, the integrity report 170 can be digitally signed to verify the identity of the client platform that transmitted the integrity report 170.

  The client platform 110 performs a platform integrity verification handshake with the authentication server 210. In certain embodiments, the platform integrity verification handshake may include multiple interactions between the client platform 110 and the authentication server 210 during the platform authentication session. The platform authentication session begins with an initial access request to the resource 150 from the client platform 110 and ends with a decision to allow or deny access to the resource 150 on the client platform 110. In other embodiments, the authentication server 210 can use the trust report 220 as part of the authentication of the client platform 110. If the client platform 110 is denied access, a final acknowledgment and session termination occurs. If the client platform 110 is granted access, the final acknowledgment and session termination will occur later. One skilled in the art will understand that the final acknowledgment and session termination is postponed and may not occur at all. During platform integrity verification, verification server 205 evaluates the digest of component 160 included in integrity report 170 generated by integrity report generator 165.

  In one embodiment, the validation server 205 performs an evaluation to calculate the client platform 110 trust level. The verification server 205 also generates a trust report 220. The trust report 220 includes an overall integrity / trust score 225 according to the assessment for the client platform 110. The authentication server 210 provides the overall integrity / trust score 225 to the policy server 215. The policy server 215 determines whether or not to permit access to the resource 150 of the client platform 110. When the policy server 215 denies access to the resource 150 of the client platform 110, the client platform 110 may be notified of the denial. For example, if the component 160 of the client platform 110 is “drifted” (if it has changed from the recognized digest of the component 160) such that the client platform 110 is no longer reliable, the required modification is The client platform 110 is reimaged using the image file 155, or it is redone. Alternatively, the modification may involve re-installing or removing “drifted” components before allowing access to resource 150. Alternatively, the client platform 110 may be allowed access to the resource 150, but that access may be at a lower level until the client platform 110 addresses "drift". One skilled in the art will appreciate that there are other possible ways to handle component “drift”.

  In other embodiments, the authenticator entity 145 can provide the trust report 220 to the client platform 110. This allows the client platform 110 to use the trust report 220 as a kind of “trust ticket” for accessing other network resources and services. Such other network resources and services may also have an authenticator entity for checking the validity of the trust report 220. One skilled in the art will appreciate that a myriad of resources and services are accessible from the client platform 110 using the trust report 220.

  Trust report 220 includes an indication of which machine was functioning as authenticator entity 145 and integrity authority 140, apart from trust score 225. This information can be used to verify the reliability of the trust score 225. The third party can use this information to determine which machine was responsible for generating the trust score 225. As a special example, if the authenticator entity 145 and / or the integrity authority 140 is a virtual machine, this information may include an indication of the physical machine on which the virtual machine is instantiated. Thus, for example, if the authenticator entity 145 and the integrity authority 140 are both instantiated on the client platform 110, then the third party can verify that the virtual machine in question is the same physical hardware that has been analyzed for reliability. You will notice that it was instantiated on the hardware platform.

  The verification server 205 can store the client platform information 230 in the profile database 235. The client platform information 230 can include a variety of things, among others, can include a trust report 220 having an integrity report 170 and an overall integrity / trust score 225. In addition, the client platform information 230 may include date and time of evaluation, client platform configuration information, integrity profile (also referred to herein as “scan policy”), user information, and machine-specific information. The verification server 205 can use the information stored in the profile database 235 to execute the scan policy. For example, an organization may require certain users, such as those in the finance department, to have a set of components on the client platform 110, while other “normal” users It may be required to have a different set of components. In addition, the sub-policy can require that certain persons in the finance department, such as the chief financial officer, have additional predetermined components. A scan policy can not only verify which components are present, but also to what extent and how a certain client was scanned. In the example described above, the scan policy was implemented with two sets of requirements, but those skilled in the art will understand that a myriad of requirements and scan policy tiers can be implemented.

  Policy server 215 can implement a policy customized for a given institution. For example, consider a bank. When a bank customer wants to access their bank account via the client platform 110, the policy server 215 provides step-by-step access to the bank account information according to the overall integrity / trust score 225. You can choose to give For example, if the overall integrity / trust score 225 exceeds an initial threshold, access is granted to account information, such as account balances, account details, or a portion of account resources. If the overall integrity / trust score 225 exceeds a higher second threshold, access is granted to a higher level of account information and account resources that can be transferred electronically. In the above example, the policy used two trust score thresholds to access the two sets of resources, but those skilled in the art will understand that the myriad thresholds and stages of access can be implemented. You will understand.

  FIG. 3 illustrates an integrity authority 140 according to an embodiment of the present invention. The integrity authority 140 collects raw information 305 from a plurality of components 310, verifies and refines the information 315 (including the component digest), and uses the global signature database as the integrity / trust record 320. Store in (GSDB) 325. More specifically, the integrity authority 140 collects raw information 305 about these components 310 from their suppliers (eg, manufacturers, software vendors, hardware vendors, etc.). As described above, the digest can be obtained by collecting records from commercially available products. The digest can also be obtained by uploading directly from the manufacturer, by obtaining information through direct means, or by using other means. In collecting the components, it is preferable to use a technique that gives the highest level of overall trust. For example, it is preferable to use a technology that makes component “distribution process management” as safe as possible. The authenticator entity 145 (see FIG. 1) can use the information in the GSDB 325 to assess the level of reliability of the client platform 110. This level of confidence is evaluated by comparing the GSDB 325 integrity / trust record 320 with the individual components listed in the integrity report 170 (FIG. 1) received from the client platform 110 (FIG. 1). This is done by assigning an overall integrity / trust score 225 (FIG. 2) to 110 (FIG. 1).

  After collecting the information, the integrity authority 140 verifies the accuracy of the information using predetermined heuristics. In one embodiment, heuristics are applied via automatic means by a computer application or program. In another embodiment, the manual is verified by an authorized individual. In another embodiment, information is collected and stored in a standardized format (purification information) 315. For example, the verification of the raw information 305 may be made so that the raw information can be refined into refined information 315 and stored in the form of an integrity / trust record 320. In addition, the integrity / trust record 320 may be further verified by sending it back to the original manufacturer to verify the collected information. This can be referred to as “closing the loop” in the collected data.

  The integrity / trust record 320 can be used for search operations, in which case the validation server attempts to validate the integrity of the client platform using the client platform integrity report, as described above in FIG. it can. In one embodiment, the search operation is initiated by the validation server 205 of FIG. 2 via a web service interface. Search operations can be performed continuously on a component-by-component basis. Alternatively, the search operation may be a single message or a batch process that includes multiple search requests. In addition, search operations can be performed on sets and categories with information and digest constraints added to the GSDB 325. This is done to limit the scope of the search and improve the performance of GSDB 325. Those skilled in the art will appreciate that limiting the scope of a search is accomplished by using pattern matching, set theory, and the like. Those skilled in the art will also appreciate that there are ways in which search operations are performed, for example, via a direct connection, an interface other than a web service, or other network means.

FIG. 4 is an enlarged view of the integrity / trust record 320 according to an embodiment of the present invention. The integrity authority 140 generates the integrity / trust record 320 by the method described above with reference to FIG. Each integrity / trust record 320 can include a hash 405. Each integrity / trust record 320 can also include information 410 identifying the integrity authority 140. The component information 415 can include a component identity, a description of the component, a component manufacturer, a model number, a version release, a patch version, a manufacturing date, a manufacturing location (eg, country name, location), and the like. In addition, the integrity / trust record 320 of the integrity authority 140 may include other information 420 as described below.
Record information
Record serial number
Start date of validity period of current integrity / trust record
End date of validity period of current integrity / trust record
Record issuer Collected information
Harvester identity
Collection method
Collection date and time
Assigned integrity / trust score
Hash value reference
Integrity / trust record reference for other subcomponents
Reference to original raw manufacturer data
Reference of standard specifications Information of signer
The identity of the signer (integrity authority)
Integrity Authority Certificate Reference Integrity Authority Digital Signature

  FIG. 5 is an enlarged view of the verification server 205 according to the embodiment of the present invention. Also, an enlarged view of the trust report 220 is shown. The trust report 220 may include an overall integrity / trust score 225, a client platform identity 505 (eg, a physical serial number), a TPM certificate reference 510 for the validation server 205, and a validation server identity 515. TPM certificates (and certificates associated with TPM) are typically stored on tamper resistant hardware and provide proof of the source of the content of the associated report. The trust report 220 may also include other information 520, which may include one or more references to the client platform 110 TPM certificate, the date and time of the evaluation, the electronic signature of the verification server 205, the client A reference to a database against which digests collected from the platform were compared can be included. (Normally, the digests stored in each database should be the same, but the database used to verify the reliability of the client platform because of synchronization delays and database policy management is a potential In addition, the other information 520 can include a list of one or more components 160, in which case the component is And a reference to the integrity / trust record 320 corresponding to each component 160 in the GSDB 325 (see FIG. 3). The verification server 205 generates a trust report 220 according to the evaluation for the client platform 110.

  Comparator 525 is used to compare the digest in integrity report 170 with the integrity / trust record 320 in GSDB 325 of FIG. By comparing the digest in the integrity report 170 with the integrity / trust record 320, the validation server 205 can determine the level of trustworthiness of the client platform 110. This level of confidence is represented in the trust report 220 as an overall integrity / trust score 225.

  The type and amount of digests can affect the overall integrity / trust score 225. For example, a digest for an operating system may be more important than a digest for game software. The overall integrity / trust score 225 is affected not only by factors related to the digest collected from the client platform 110 but also by factors related to the reliability of the integrity record 320. As described above, the distribution history of the component stored in the integrity record 320 affects the individual integrity / trust score 425 (see FIG. 4) assigned to the component described in each integrity / trust record 320. The integrity / trust record 320 can ultimately affect the overall integrity / trust score 225 determined for the client platform 110. Other factors such as the type of certificate that signs the integrity report 170 and the total number of digests collected from the client platform 110 compared to the total number of digests stored in the GSDB 325 also contribute to the overall integrity / trust score 225. To affect. In addition, by constraining the number of matched digests for the defined category or set, you can see how many components are in and out of the set, and which components are completely missing.

  U.S. Patent Application Serial No. 11/288/820, assigned to the present applicant, details how the integrity / trust score 225 can be determined. The integrity / trust score is an indicator of the overall integrity of the computer system or whether the computer system can be considered reliable. Integrity / trust scores can be generated in many different ways. In one embodiment, the integrity / trust score is the ratio of the number of enabled components on the computer system to the total number of components of the computer system (whether or not enabled). In another embodiment, the integrity / trust score is evaluated as a number between 0 and 1000. Here, 0 indicates a computer system that cannot be trusted at all, and 1000 indicates a computer system that can be completely trusted. Furthermore, in other embodiments, critical components can be weighted more than other components. Thus, a computer system having more significant components that are validated can obtain a higher score than a computer system having fewer significant components that are validated. (The definition of “important” is not intended to indicate to all potential users the components that are “necessary” in all situations. Rather, it identifies them as important to the organization in question This is intended to show the components that are being managed, so some organizations may consider operating system files to be “important”, while others may have specifically developed components ( May be considered “important” (for any purpose), one component may be “necessary” and “important”, but one property suggests the other Not.)

  There are other ways in which the integrity / trust score 225 can be calculated. In other embodiments, the location of various enabled components within the signature database can be used as a factor. For example, the components listed earlier in the signature database can be considered more important than components that occur later in the signature database. Similarly, when the integrity report generator 165 (Figure 1) indicates which components are more important to the overall integrity of the client platform and collects a digest of the components (for example, in the integrity report 170, in order of importance) If listing digests), that information can also be incorporated into the integrity / trust score 225. In other embodiments, the integrity / trust score 225 may be incorporated into the component identifier. Components manufactured by one manufacturer may be more important than components manufactured by other manufacturers. For example, consider a component that works in conjunction with an application. Components manufactured by application manufacturers can be considered more important than components manufactured by third parties.

  Further, in other embodiments, the component version and / or patch level can be used as a factor in performing the integrity / trust score calculation. For example, assuming that a component has several versions, the more recent version can be considered more important than the older version. If a validated component expires, the resulting integrity / trust score can be lower than other identical computer systems that have the more recent version of the same component. On the other hand, if there is a reason to suspect the reliability of a new component (eg if the component is known to be defective), having the new version of the component has a lower integrity / trust score. It may be.

  In the above comparison operation, the verification server 205 analyzes the integrity report 170 and performs a search operation on the GSDB 325 of the integrity authority 140 (FIG. 3) for each digest of the integrity report 170. This search operation can be performed continuously in component units. Alternatively, the search operation may be one or more messages each including a plurality of search requests. The search operation may also narrow the scope to a category or set of information in order to provide more fine-grained results and improve the overall performance of GSDB 325.

  In some embodiments, the verification server 205 can verify the integrity of the client platform 110 before the client platform 110 is granted access to the resources 150 of the network 135. In another embodiment, the comparator 525 can perform the comparison operation periodically for a certain period of time, but may perform the comparison operation only after the first access is granted. For example, a home computer user may attempt to gain access to network 135 while instructing to evaluate component 160. However, broadband connections, which are always connected, are becoming common among home computer users. A broadband connection can reduce the number of times a user logs into the network. This also applies to corporate and corporate computer users. As a result, the comparator 525 can perform the comparison operation some time later, not at the same time as the initial connection attempt of the client platform 110 to the network 135.

  FIG. 6 is an enlarged view of the integrity report 170 according to the embodiment of the present invention. The client platform 110 typically generates the integrity report 170 in a standard format or language such as XML. However, those skilled in the art will appreciate that non-standard formats and languages can also be used. The integrity report 170 is digitally signed 605 using the TPM certificate 610. A person skilled in the art can use any certificate including a TPM chip, so the TPM certificate 610 can be an Endorsement Key (EK) certificate, an Attestation Identity Keys (AIK) certificate, or a Subject Key. You will understand that it can be an Attestation Evidence (SKAE) certificate. Furthermore, those skilled in the art can sign the integrity report 170 with a certificate derived from a certificate specified in the TPM, but not necessarily with a TPM certificate. You will understand that you can.

  As described above, the integrity report 170 can include multiple digests of multiple components at the client platform. In one embodiment, these digests are computed as hashes 615 of their components 160. In other examples, these digests can be compared to digests associated with components stored in integrity / trust record 320 of GSDB 325 (FIG. 3). In another embodiment, the digest is compared to a subset of digests associated with components stored in a local signature database (LSDB) integrity / trust record described below in FIG. And if it is not found in it, the GSDB 325 can be referred to for a digest that was not verified in the local database. Furthermore, in other embodiments, the local database may be completely synchronized (exactly matched) with the global database digest, eliminating the need to reference GSDB 325 in some cases.

  FIG. 7 illustrates a system 705 according to an embodiment of the present invention that includes a client platform 110 connected to an authenticator entity 145 of an enterprise network 710. The authenticator entity 145 can interact with the integrity authority 140. The corporate network 710 can be connected to the integrity authority 140 via the Internet 715 or any other network as described above. As shown in FIG. 7, the client platform 110 is wirelessly connected to the authenticator entity 145 via a corporate wireless access point 720. However, those skilled in the art will understand that the client platform 110 can be in any format, such as a wired connection such as the IEEE 802.3 standard (Ethernet), a wireless connection such as the IEEE 802.11 standard, or any wired or wireless network combination. It will be understood that it is possible to connect to the corporate network 710 using

  As described above, the authenticator entity 145 evaluates the client platform 110. This evaluation is performed when the client platform 110 seeks access to the corporate network 710. That is, the evaluation is part of authenticating the client platform 110 and before the client platform requests access to a particular resource. The authenticator entity 145 can evaluate the client platform 110 at other time periods. For example, the authenticator entity 145 may re-evaluate the client platform 110 periodically, in some cases, in accordance with corporate policy. In one embodiment, the authenticator entity 145 can evaluate the component 160 of the client platform 110 by requesting an integrity report 170 from the client platform 110. Client platform 110 uses integrity report generator 165 to generate integrity report 170. For each digest representing the component 160 in the integrity report 170, the authenticator entity 145 identifies an integrity / trust record 725 corresponding to the digest from the LSDB 720 described in detail below. In order to assess the level of trustworthiness of the client platform 110, the integrity / trust record 725 is compared to the hash of the component 160.

  In other embodiments, the authenticator entity 145 can remotely evaluate the client platform 110, for example by a suitable server tunneling to the client, and therefore does not require an integrity report 170 from the client platform 110. Instead, the authenticator entity 145 generates an integrity report 170 based on the remote assessment. This remote evaluation can be performed using various mechanisms. For example, “Intel vPro” technology can be used (“Intel vPro” is a registered trademark of Intel Corporation and its subsidiaries in the United States and other countries). One skilled in the art will appreciate that other mechanisms can be used.

  The integrity / trust record 725 in the LSDB 720 is periodically updated and synchronized with the integrity / trust record 320 in the GSDB 325. This is to ensure that the LSDB 720 can use the latest integrity / trust records. In one embodiment, only the integrity / trust record 320 associated with the evaluation operation in the enterprise network 710 is transferred to the LSDB 720. By storing a part of the GSDB 325, network traffic can be reduced, and the size of the LSDB 720 can be minimized. If a particular integrity / trust record in LSDB 720 becomes obsolete or no longer needed for other reasons, that record is deleted from LSDB 720 and will be needed in the future or in the future If so, the record is later retrieved from GSDB 325. For example, if a company policy stipulates that only the latest version of the virtual private network ("VPN") used by the company is allowed, the integrity / trust record associated with the old VPN is Deleted from LSDB 720. GSDB 325 and LSDB 720 can also be virtualized. For example, each database can be installed in a different virtual machine on the same or different physical machine. Virtual machines can also be installed on the client platform 110.

  Synchronization or update between the GSDB 325 and the LSDB 720 can be done through a secure and authenticated channel and at the right time as indicated by the company policy. For example, if company policy indicates that LSDB 720 should always contain the most recent relevant records, GSDB 325 can supply those records as they become available (eg, LSDB Supplied by telling 720 that there is a new record and is waiting for collection, or by pushing the record to LSDB 720). On the other hand, if the company policy dictates that the LSDB 720 should be updated when a sufficient number of records can be retrieved from the GSDB 325, or if the company policy dictates that there should be as little inconvenience to the company employer In this case, the update / synchronization is performed at an appropriate timing instructed by the administrator of the network or information technology (“IT”). These may be manuals, scheduled, or automatic.

  With the LSDB 720 update, new integrity / trust records can be added to the LSDB 720 without replacing the integrity / trust records present in the LSDB 720. Similarly, the GSDB 325 can be updated as new information is collected and new integrity / trust records 725 are generated. The new integrity / trust record 725 in GSDB 325 does not necessarily need to replace the old one, and can be added to an existing record in GSDB 325.

  In another embodiment, an authorized network administrator can add to the LSDB 720 an integrity / trust record 725 that is specific to the corporate network 710 and is only relevant locally. In this case, LSDB 720 contains records that have nothing similar to GSDB 325. For example, files that are generated and used only within the corporate network 710 (configuration files, other corporate system data, etc.) and other corporate system data are, for example, network administrators of the corporate network 710, etc. It may have an integrity / trust record 725 that has been authenticated by a legal operator. This ensures that the authenticator entity 145 has access to all necessary integrity / trust records 725, including those specific to the corporate network 710, to evaluate the client platform 110. is there.

  For LSDB 720, some integrity / trust records 725 stored locally within the corporate network 710 are stored in the integrity report 170 of the client platform 110 after installation of the image file 155 of FIG. The hash can be used to check the correlation. In comparison (correlation check), if the hash of one or more components in the client platform 110 is different from the hash stored in the LSDB 720, the user re-images the client platform 110 with the image file 155 Can be required. Alternatively, it may be corrected by reinstalling or removing components with different hashes. Alternatively, the client platform 110 may be allowed access to the resource 150, but will probably have a lower level of access until the client platform 110 solves the problem. One skilled in the art will appreciate that other modifications can be used. If the number of unmatched hashes is not important, the authenticator entity 145 (FIG. 1) can grant access to the resource 150 (FIG. 1). Here, “not important” means that a sufficient number of hashes in the integrity report 170 are matched corresponding to the hashes stored in the integrity / trust record 725. Additional use cases with image file 155 will be described in detail later.

Other embodiments may include an enterprise network 710 that is specially designed to protect financial data. For example, federal laws such as the Sarbanes-Oxley Act
Requires the Chief Information Officer (CIO) to be responsible for the safety, accuracy, and reliability of computer networks (especially for the storage of important financial data). By adopting system 705, CIOs can be trusted and secured by denying access to the corporate network 710 of the client platform 110 if the assessment performed by the authenticator entity 145 working with the LSDB 720 fails. You can maintain the network. In addition, different levels of security can be set for different client platforms. For example, the CIO client platform is required to encrypt all data on the hard drive, whereas the regular employee client platform does not require such features.

  Further, in other embodiments, the modules that generate the integrity report 170 and control access to resources by the client platform 110 are not embedded in the client platform 110 and are external to the client platform 110. FIG. 8 shows a portable digest collector dongle 805 with the client platform 110 of FIG. 1 and the authenticator entity 145 of FIG. The various components shown in FIG. 8 have various receivers and transmitters for transmitting and receiving various data between machines, which are described in other embodiments. Dongle 805 is not particularly limited, and can take any form such as USB memory drive 810, smart card, token, memory stick, external hard drive, peripheral device, and the like. One skilled in the art will appreciate other available equipment. The dongle 805 can be tamper resistant by adding security. If the dongle 805 is tamper resistant, any attempt to disassemble the dongle 805 will result in the dongle 805 becoming inoperable. One advantage of using the dongle 805 instead of having the various components used to validate the client platform on the client platform is that the dongle 805 is human friendly and the physical presence of the user. And the authentication of the client platform 110 more closely. For example, the user is not limited to a single computer, but can apply the dongle 805 to any computer, such as a computer in a public library. Even if the client does not belong to another machine or network, the dongle 805 can be attached to the client platform 110 and can verify the integrity of its own platform. This embodiment is detailed in FIG. 9 below.

  The dongle 805 can have a digest collector 815, a trust engine 820, a secure storage 825, a credential 830, and a secure interface 835. The digest collector 815 can interact with the digest collector proxy 840 in the client platform 110 via the secure interface 835. The digest collector proxy 840 may be a component of a standard virtual machine ("VM") on the client platform 110, such as Microsoft Corporation's System Health Agent ("SHA"). it can. Digest collector proxy 840 may also be a proprietary rather than a standard VM component transferred from dongle 805 to client platform 110 prior to initiating platform integrity verification. The trust engine 820 provides one or more executables or routines that allow the software in the dongle 805 to be executed reliably. Secure Storage 825 provides a tamper-resistant location for storing sensitive data such as private key 845 by exposing only a limited set of commands and physical contact points To do. Further, the dongle 805 may have a space that is not secure storage (not shown). User credential 830 may include one or more certificates 850. Certificate 850 can follow the X509 format. The X509 format is an agreement that indicates a field in a certificate. Examples of certificates include secure IDs and TPM certificates, and others, but these assist in authenticating the user to the authenticator entity 145. The certificate 850 includes a private key 845, which will be described in detail later.

  In one embodiment, digest collector 815 uses private key 845 before sending integrity report 170 to digest evaluator plug-in 855 of authenticator entity 145 via digest collector proxy 840 of client platform 110. By encrypting the integrity report 170, the user credential 830 can be used. The use of user credentials 830 can add an additional layer of protection (protection hierarchy) during transmission of the integrity report 170. That is, when the user credential 830 includes the certificate 850, the private key 845 corresponding to the certificate 850 is used for the digital signature of the integrity report 170. One skilled in the art will appreciate that the digest evaluator plug-in 855 may be a standard software component of the operating system. In addition, the digest evaluator plug-in 855 may be a software component that is a proprietary product instead of a standard product.

In another embodiment, the public key 860 of the certificate 865 in the authenticator entity 145
The digest collector 815 can encrypt the integrity report 170 using the public key 860. This provides more confidentiality when sending the integrity report 170 to the digest evaluator plug-in 855 of the authenticator entity 145. Further, in another embodiment, if user credential 830 and authenticator entity 145 share a private key, digest collector 815 may encrypt integrity report 170 with the shared private key. it can.

  Furthermore, in other embodiments, the dongle 805 may construct a secure tunnel (eg, secure inner tunnel 870, secure outer tunnel 875) to send the integrity report 170 (FIG. 1) to the authenticator entity 145. Can do. The secure inner tunnel 870 and secure outer tunnel 875 are the physical communication means underlying the secure line from the dongle 805 to the authenticator entity 145 (eg IEEE 802.3 Ethernet, IEEE 802.11 WiFi, etc.) ) Can be constructed regardless of. A secure outer tunnel 875 may be established between the client platform 110 and the authenticator entity 145, preferably to connect the integrity agent 880 and the integrity server / broker 885. Integrity agent 880 and integrity server / broker 885 can be endpoints of standard trusted network connections ("TNC"). TNC can send IP packets in a secure and reliable manner using separate public / private encryption keys.

Communication between the client platform 110 and the authenticator entity 145
It can be assisted by a network access requester 890 on the client side and a network access authority 895 on the server side. Network Access Requester 890 and Network Access Authority 895 both have physical packet-level media such as IEEE 802.3 (Ethernet) and wireless (wireless / radio) such as IEEE 802.11. Communication is performed via The secure outer tunnel 875 can use a standard protocol such as Extensible Authentication Protocol ("EAP"), Radius, or TLS (Transport Layer Security). One skilled in the art will appreciate that other protocols can be used, including non-standard protocols. After the secure outer tunnel 875 is constructed, a secure inner tunnel 870 is constructed between the dongle 805 and the authenticator entity 145. The secure inner tunnel 870 preferably connects the digest collector 815 and the digest evaluator plug-in 855. The secure inner tunnel 870 is between the dongle 805 and the client platform 110 or the authenticator entity 145 so that it does not have to delegate security to other components (even if it includes a potentially present secure outer tunnel 875). Or between any software components on any machine. The construction of the secure inner tunnel 870 will be described in detail below with reference to FIG.

  FIG. 9 shows the system of FIG. 8 in which a GSDB 325 is included in a portable digest collector dongle (dongle) 805. In this example, the dongle 805 can verify the integrity of the client platform 110 without reference to the authenticator entity 145. The dongle 805 can be connected to the client platform 110 even if the client is not connected to another machine or network. The dongle 805 can then verify the integrity of the self-contained platform. All or part of the information in GSDB 325 can be stored in either secure storage 825 or non-secure storage (not shown). The tunnel 870 operates substantially in the same manner as the secure inner tunnel 870 described above with reference to FIG. On the other hand, in the configuration of FIG. 9, the tunnel 870 is different from the configuration of FIG. 9 in that the dongle 805 is connected to the client platform 110 without passing through the outer tunnel (in the configuration of FIG. 8). , Dongle 805 is not connected to authenticator entity 145). Thus, having the GSDB 325 integrity / trust record 320 accessible by the local dongle 805 allows the platform integrity verification process to be read in a self-contained manner substantially like the other embodiments described above. Is activated. In other words, the client platform 110 is not required to be connected to a network or other machine for verification to take place. This is particularly convenient and efficient for IT administrators who want to verify a large number of machines that are not yet connected to any network.

  FIG. 10 shows a flow chart of a procedure for performing integrity verification of components 160 of the client platform 110 during the process of deploying the client platform 110 (FIG. 1). An IT administrator or other appropriately authorized person may wish to verify the components and configuration of the client platform 110 in the context of providing a new platform within the corporate domain. In step 1005, the IT administrator receives a client platform 110 to deploy. That is, a client platform 110 (eg, PC client, server, router, switch, PDA, mobile phone, etc.) is received from a supplier, manufacturer, original equipment manufacturer (OEM), or other source.

  In step 1010, the IT administrator installs at least one component from the image file 155 to the client platform 110. One skilled in the art will appreciate that a component can be installed without using the image file 155. For example, an IT administrator can install a component using a tool supplied by the component manufacturer or another proprietary configuration management tool. In step 1015, after the component 160 is installed on the client platform 110 (which may be from the image file 155), the integrity report generator 165 on the client platform 110 generates an integrity report 170 (FIG. 1). In step 1020, a trust report 220 is generated that includes the overall integrity / trust score 225 (FIG. 2). In step 1025, it is determined whether the integrity report 170 has at least one component 160 to be verified. Finally, in step 1030, if there is at least one component 160 to be verified, component 160 is verified as described above. This is done by sending a search request for integrity authority 140 (FIG. 3) corresponding to component 160 (software and hardware) of client platform 110 to GSDB 325, as shown in FIG.

  FIG. 11 shows a flowchart of the procedure used to send a search request to the signature database of FIG. In step 1105, the authenticator entity 145 (FIG. 1) may receive an integrity report 170 (FIG. 1) from the client platform 110 (FIG. 1). In step 1110, it is checked whether each digest in the integrity report 170 has an integrity / trust record 725 corresponding to the LSDB 720. If the corresponding integrity / trust record is not found, in step 1115 a reference to GSDB 325 (FIGS. 3 and 7) is made. If necessary, in step 1120, LSDB 720 can be updated / synchronized with GSDB 325. Other embodiments of the update / synchronization procedure can be described in particular in connection with FIG. Regardless of whether the corresponding integrity / trust record 725 was found in either the LSDB 720 or the GSDB 325, in step 1125, the corresponding integrity / trust record 725 is the component 160 (Figure 1) of the integrity report 170 (Figure 1). Compared with each digest representing 1). In step 1130, the level of trust of the client platform 110 is determined by evaluating the overall integrity / trust score 225 (FIG. 2).

  FIG. 12 shows a flowchart of another procedure used to verify the integrity of the components of the image file 155 before installing the image file in the process where the user platform is deployed for initial use. First, in step 1205, the client platform 110 (FIG. 1) is received for provisioning and deployment. In step 1210, an IT administrator or a person with appropriate authority may decide to verify at least one component of the image file 155 (FIG. 1) before installing the image file 155 on the client platform 110. it can. The difference between this method and the processing described in FIG. 10 is the timing difference. The IT administrator can verify the components after the installation of the image file 155 as described in FIG. 10 or before the installation of the image file 155 (step 1215) as described in FIG. You can decide whether to validate the component.

  FIG. 13 shows a flowchart of the procedure for verifying the integrity of the component 160 on the client platform 110 from the perspective of the authenticator entity 145 of FIG. In step 1305, the client platform 110 is authenticated. In step 1310, an integrity report 170 is received from the client platform 110. In step 1315, the component 160 in the integrity report 170 is verified by the integrity authority 140. As described above, the verification is performed using the verification server 205. In step 1320, a trust report 220 containing the overall integrity / trust score 225 is generated using the integrity / trust record 320 in the integrity authority GSDB 325 (FIG. 3). In step 1325, a check can be made to see if the overall integrity / trust score 225 has exceeded a predetermined threshold.

  If the overall integrity / trust score 225 exceeds a predetermined threshold, the client platform 110 is allowed access to the resource 150 on the network 135 (FIG. 1). If the overall integrity / trust score 225 does not exceed the predetermined threshold, the client platform 110 is denied access to the resource 150 on the network 135 (FIG. 1). Alternatively, the client platform 110 is notified that a modification is required. For example, if the component 160 of the client platform 110 is “drifting” so that the client platform 110 is no longer entirely reliable, the required modifications are re-imaged using the image file 155 by the client platform 110. What to do, or try again. Alternatively, it may be modified by reinstalling or removing “drifted” components before allowing access to resource 150. Alternatively, the client platform 110 may be allowed access to the resource 150, but that access may be at a lower level until the client platform 110 addresses "drift". Those skilled in the art will appreciate other possible ways to handle component “drift”.

  FIG. 14 shows a flow chart of the procedure used to allow the client platform 110 (FIG. 1) multiple access stages according to the first, second and third thresholds. In FIG. 14, three stages of access are proposed, but those skilled in the art will appreciate that any number of thresholds and stages can be used. In step 1405, a check is made as to whether the overall integrity / trust score 225 (FIG. 2) exceeds a first threshold. If the first threshold is exceeded, access at a higher level is granted to the client platform 110 (step 1410). For example, in the bank scenario described above, this can be an electronic transfer to an external account, and other tasks as described below for other second and third thresholds (discussed below). That means you can do it. In step 1415, a second check is made whether the overall integrity / trust score 225 exceeds a second threshold. If the second threshold is exceeded, access at a medium level is granted to the client platform 110 (step 1420). For example, this means that assets can be viewed and transferred between internal accounts, but electronic transfers cannot be made to external accounts. In step 1425, a third check is made whether the overall integrity / trust score 225 exceeds a third threshold. If the third threshold is exceeded, access at a lower stage is permitted to the client platform 110 (step 1430). This means, for example, that the balance of the account can be viewed, but the funds cannot be transferred to an internal account or an external account. In FIG. 14, client platforms that are granted higher-level access are shown to be allowed lower-level access, which is usually the case, but those skilled in the art will be able to access It will be understood that the stages need not be nested. That is, different stages may provide different levels of access, and if two different access stages are given, neither stage may be part of the other stage. One skilled in the art will appreciate that access authorization tiered based on the overall integrity / trust score 225 can be applied to other cases other than the bank example described above. For example, a corporate network, a file sharing network, an online database, etc. can be mentioned.

  FIGS. 15 and 16 are flowcharts showing the operational flow of the procedure used to verify the integrity of the component 160 on the client platform 110 (FIG. 1). In step 1505, the client platform 110 initiates a handshake with the authenticator entity 145 of the authentication server 210 shown in FIG. 2 by requesting access to the resource 150. In step 1510, the authentication server 210 responds to the client platform 110 request by initiating platform integrity verification for the client platform 110. In step 1515, a secure channel is established between the client platform 110 and the authentication server 210 as necessary. This is accomplished by using a known framework (eg, 802.1X / EAP) with a standard protocol (eg, SSL, IKE) that uses appropriate credentials (eg, SSL authentication). In one embodiment, both the client platform 110 and the authentication server 210 have a trusted platform module (TPM) chip, and both are TPM certificates (or EK certificates, AIK certificates, SKAE certificates, or other Similar certificate). These certificates are used to build a secure channel. In another embodiment, one of the machines has a TPM chip, but the other machine does not. It is also possible to establish a secure channel between the client platform 110 and the authentication server 210 by using common points of different protocols.

  Step 1520 is shown in both FIG. 15 and FIG. 16, and step 1520 in these figures shows a similar step of transferring the integrity report 170 to the authentication server 210 (FIG. 2). In step 1605 of FIG. 16, the integrity report 170 is forwarded to the verification server 205 and the client platform 110 is evaluated using the integrity report 170 obtained from the client platform 110 (FIG. 1). In one embodiment, a one round trip question-and-answer interaction is performed between the verification server 205 and the client platform 110. In another embodiment, the question-and-answer dialogue is multiple round trips. During the question-and-answer dialogue, the authentication server 210 mediates for the verification server 205 (FIG. 2). The authentication server 210 provides a messaging function between the client platform 110 and the authentication server 210.

  Step 1525 is shown in both FIG. 15 and FIG. 16, and step 1525 in these figures is the component of client platform 110 to GSDB 325 (or LSDB 720) of integrity authority 140 (FIGS. 3 and 7). Similar steps are shown for performing a search operation for 160. The search operation may be performed continuously in units of components (for example, using multi-round messages) or a single message including a plurality of search operations. May be.

  Step 1530 shown in FIG. 15 describes the operation of obtaining component integrity / trust records 320 from GSDB 325 (FIG. 3). If the integrity / trust record 320 is found after the search, the integrity authority 140 returns the relevant integrity / trust record 320 to the validation server in step 1535, as shown in both FIG. 15 and FIG. .

  In step 1610 of FIG. 16, comparator 525 (FIG. 5) compares the digest of integrity report 170 (FIG. 2) with integrity / trust record 320 returned from GSDB 325 (FIG. 3). By comparing the digest of the integrity report 170 with the integrity / trust record 320 returned from the GSDB 325, the verification server 205 determines the level of reliability of the client platform 110 (FIG. 2). The level of reliability is embodied as a trust report 220 that includes the overall integrity / trust score 225 (FIG. 2). In step 1615, the verification server 205 provides a trust report 220 that includes the overall integrity / trust score 225 to the authentication server 210 (FIG. 2). Thereafter, the verification server 205 stores the trust report 220 together with information such as the date and time of evaluation in the profile database 235 (FIG. 2). In step 1620, after receiving the overall integrity / trust score 225, the authentication server 210 forwards it to the policy server 215 (FIG. 2). In step 1625, the policy server 215 compares the overall integrity / trust score 225 with a predetermined policy or threshold and determines whether to allow or deny access to the resource 150 (FIG. 2) of the client platform 110. If the client platform 110 does not have a sufficiently high integrity / trust score, the client platform 110 may be notified that modification is required after access is granted. In step 1630, the policy server 215 forwards the permit / deny result to the authentication server 210. The authentication server 210 then forwards the result to the client platform 110 in step 1540 described in FIGS. Finally, in step 1545 (described in both FIG. 15 and FIG. 16), the client platform 110 acknowledges receipt of the grant / deny result and terminates the platform authentication session. . Alternatively, the authentication server 210 may execute a session of a timeout mechanism (time-out mechanism) for terminating the authentication session when the client platform 110 fails to terminate the session after a certain period of time has elapsed. .

  The following is a brief general description of a suitable machine that implements certain aspects of the invention. Typically, a machine is a system bus to which a processor, memory (eg, random access memory (RAM), read-only memory (ROM), or other state storage medium), storage device, video interface, output / input interface port, and the like are attached. including. The machine is controlled, at least in part, by input from a conventional input device such as a keyboard or mouse and instructions received from another machine, virtual reality (VR) environment, biofeedback or other information exchange with input signals Is possible. As used herein, the term machine is intended to broadly encompass a single machine, a virtual machine, or a machine operating together, a communication system coupled to a virtual machine or device. Typical machines include computer devices such as personal computers, workstations, servers, portable computers, mobile terminals, phones, tablets, as well as transportation means such as personal or public transportation such as cars, trains, taxis, etc. .

  The machine may also include a built-in controller such as a programmable or non-programmable theoretical device or array, an application specific integrated circuit (ASIC), a built-in computer, a smart card, or the like. The machine may also utilize one or more connections to one or more remote machines via a network interface, modem or other communication coupling. Further, the machines may be interconnected through physical and / or logical networks such as an intranet, the Internet, a local area network, a wide area network, and so on. For those skilled in the art, network communication is available in a variety of wired / wireless and / or wireless, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 545.11, Bluetooth, optics, infrared, cable, laser, etc. It will be appreciated that a short range or long range carrier and protocol can be used.

  The present invention can be described with reference to or in conjunction with related data including functions, procedures, data structures, application programs, and the like. These related data, when accessed by a machine, will cause the machine to perform a task or define an abstract data type or low-level hardware context. Related data includes, for example, volatile and / or nonvolatile memory such as RAM, ROM, or hard drives, floppy disks, optical storage devices, tapes, flash memory, memory sticks, digital video disks, biological storage devices, etc. It can be stored in other storage devices, including their associated storage media. Related data is transmitted in the form of packets, serial data, parallel data, propagated signals, etc., in a transmission environment including physical and / or logical networks, and can be used in a compressed or encrypted form. Also, relevant data can be used in a distributed environment and stored locally and / or remotely for machine access.

  Although the principles of the present invention have been described and illustrated based on the illustrated embodiments, the illustrated embodiments may be modified in configuration and detail without departing from such principles and in any desired manner. It should be understood that these may be combined. And while the above description has focused on specific embodiments, other configurations are possible. In particular, the expression “according to one embodiment of the invention” or similar expressions are used herein, but these terms generally mean that they can serve as reference examples, and the invention is not limited to specific examples. It is not intended to be limited to this configuration. As used herein, these terms may represent the same or different embodiments that can be combined with other embodiments.

  In conclusion, the detailed description and the accompanying drawings are intended to be exemplary only and should not be construed as limiting the scope of the invention in light of the wide variety of possible substitutions to the embodiments described herein. Absent. Accordingly, all that is claimed by the present invention includes all modifications that do not depart from the scope and spirit of the claims and their equivalents.

FIG. 2 illustrates a system including various client platforms whose integrity has been verified using client platform validation according to an embodiment of the present invention. Fig. 2 shows details of the authenticator entity of Fig. 1; FIG. 2 shows that the integrity authority of FIG. 1 collects raw information from components. FIG. 4 shows details of the integrity / trust record of FIG. 3 shows details of the verification server of FIG. The details of the integrity report of FIG. 1 are shown. 1 illustrates a system including global and local signature databases according to an embodiment of the present invention. 1 illustrates a system including a portable digest collector dongle according to an embodiment of the present invention. FIG. 9 illustrates the system of FIG. 8 including a portable digest collector dongle with a global signature database, but without an authenticator entity. FIG. 2 shows a flowchart of a procedure used to verify the integrity of the components of the client platform of FIG. Fig. 8 shows a flow chart of the procedure used to send a search request to the signature database of Fig. 7; Fig. 5 shows a flowchart of the procedure used to verify the integrity of the components of the image file before installing the image file. FIG. 3 shows a flow chart of a procedure used to verify the integrity of a component on the client platform as seen from the authenticator entity side of FIG. Fig. 5 shows a flowchart of a procedure used to grant access to multiple hierarchies according to first, second and third thresholds. 2 shows a flowchart of the operational flow of a procedure used to verify the integrity of the components of the client platform of FIG. Fig. 2 shows a flowchart of the operational flow of the procedure used to verify the integrity of the components of the client platform of Fig. 1;

Claims (46)

A client platform having an integrity report generator that is connectable to the network and generates an integrity report;
An integrity authority that is connectable to the network and includes a database that stores a plurality of integrity records;
An authentication server that is connectable to the network and authenticates the client platform;
A verification server that is connectable to the network, receives the integrity report from the client platform, compares the integrity report with the plurality of integrity records received from the integrity authority, and provides a trust report to the authentication server The system characterized by having. Resources available on the network;
The system of claim 1, further comprising a policy server that is connectable to the network and controls access to the resource by the client platform according to an integrity / trust score.   The system of claim 1, wherein the verification server comprises a profile database that stores information about the client platform.   The system of claim 1, wherein the integrity report is digitally signed.   The system of claim 4, wherein the integrity report is digitally signed using a Trusted Platform Module (TPM) certificate.   The system of claim 1, wherein the integrity report includes a hash of at least one component of the client platform.   The system of claim 1, wherein the verification server comprises a comparator that compares the integrity report with a plurality of the integrity records to generate the trust report.   The system of claim 1, wherein the trust report includes an integrity / trust score. The trust report includes a client platform identity that identifies the client platform;
The system of claim 8, further comprising: a verification server identity that identifies the verification server.   The system of claim 9, wherein the trust report further includes a reference to a TPM certificate of the client platform.   The system of claim 10, wherein the integrity / trust score is determined in part by the TPM certificate.   The integrity authority operates to collect raw information of the component, verify the accuracy of the raw information, refine the raw information into purified information, and store the purified information. System.   The system of claim 1, wherein each of the plurality of integrity records includes at least one hash of a component.   The system of claim 1, wherein each of the plurality of integrity records includes information identifying an integrity authority.   The system of claim 1, wherein the client platform is selected from a set consisting of a mobile phone, a personal digital assistant, a network element, a router, a switch, a server, and a personal computer. A computer-implemented method for verifying the integrity of multiple components of a client platform, comprising:
Receiving the client platform for deployment;
Installing at least one component on the client platform;
Generating an integrity report for the at least one component;
Generating an integrity / trust score for verifying the at least one component from the integrity report;
A computer-implemented method, comprising:   The computer-implemented method of claim 16, wherein installing the at least one component comprises installing the at least one component on the client platform from an image file.   The computer-implemented method of claim 17, comprising validating a set of components in the image file. A computer-implemented method for verifying the integrity of multiple components of a client platform, comprising:
Authenticating the client platform;
Receiving an integrity report from the client platform;
And verifying a plurality of components described in the integrity report by the integrity authority. Generating a trust report including an integrity / trust score using the integrity record stored in the integrity authority;
20. The computer-implemented method of claim 19, further comprising allowing the client platform to access a resource when the integrity / trust score exceeds a threshold. Generating a trust report including an integrity / trust score using the integrity record stored in the integrity authority;
20. The computer-implemented method of claim 19, further comprising: denying the client platform access to a resource if the integrity / trust score does not exceed a threshold. A computer-implemented method for verifying the integrity of multiple components, comprising:
Generating an integrity report from at least one component;
Using the integrity report to generate a trust report including an integrity / trust score;
The computer-implemented method, wherein the integrity / trust score is determined in part by a trusted platform module (TPM) certificate used to sign the integrity report.   23. The computer-implemented method of claim 22, further comprising verifying at least one component of a client platform, wherein the verifying step generates the integrity report and the trust report. Authenticating the client platform;
Receiving the integrity report from the client platform;
24. The computer-implemented method of claim 23, comprising: verifying a component described in the integrity report with an integrity authority. Generating the trust report including the integrity / trust score using an integrity record stored in the integrity authority;
25. The computer-implemented method of claim 24, further comprising allowing access to the client platform resources if the integrity / trust score exceeds a threshold. Generating the trust report including the integrity / trust score using an integrity record stored in the integrity authority;
25. The computer-implemented method of claim 24, further comprising denying access to the client platform resources if the integrity / trust score does not exceed a threshold. Further comprising verifying at least one component of the image file;
23. The computer-implemented method of claim 22, wherein the verifying step generates the integrity report and the trust report. Receiving a client platform for deployment;
28. The computer-implemented method of claim 27, further comprising installing the at least one component of the image file on the client platform prior to validating the image file. Receiving a client platform for deployment;
28. The computer-implemented method of claim 27, further comprising: installing the at least one component of the image file on the client platform after validating the image file. A computer-implemented method for verifying the integrity of multiple components of a client platform, comprising:
Authenticating the client platform;
Generating an integrity report for at least one component of the client platform;
Digitally signing the integrity report;
Obtaining access to a resource in accordance with the integrity report.   31. The computer-implemented method of claim 30, wherein generating the integrity report includes adding at least one hash of the at least one component in the client platform to the integrity report. An article comprising a machine accessible medium, the medium having associated data that functions as a machine when accessed, the data comprising:
Receives a client platform for deployment,
Installing at least one component on the client platform;
Generating an integrity report for the at least one component;
The article comprising data for performing a procedure for generating an integrity / trust score from the integrity report to verify the at least one component.   The article of claim 32, wherein the data for performing the procedure for installing the at least one component is data comprising a procedure for installing the at least one component from an image file on the client platform.   34. The article of claim 33, further comprising data for performing a procedure for validating a set of components in the image file. An integrity authority that includes a database that can be connected to the network and stores multiple integrity records;
An authentication server that is connectable to the network and authenticates the client platform;
A verification server that is connectable to the network, receives an integrity report from the client platform, compares the integrity report with a plurality of the integrity records received from the integrity authority, and provides a trust report to the authentication server; The system characterized by having. Resources available on the network;
36. A system according to claim 35, comprising a policy server connectable to the network and controlling access to the resource by the client platform according to an integrity / trust score. A system having a client platform connectable to a network,
The client platform is
An integrity report generator that generates an integrity report of the at least one component, including at least one hash of at least one component of the client platform;
A digital signer to sign the integrity report;
Means for receiving access to resources of the network according to the integrity report.   38. The system of claim 37, wherein the integrity report is signed using a Trusted Platform Module (TPM) certificate. An article comprising a machine accessible medium, the medium having associated data that functions as a machine when accessed, the data comprising:
Generate an integrity report for at least one component,
Including data for performing a procedure for generating a trust report including an integrity / trust score using the integrity report;
The article, wherein the integrity / trust score is determined in part by a trusted platform module (TPM) certificate used to sign the integrity report. Further, the data includes data for performing a procedure for verifying at least a portion of the client platform;
40. The article of claim 39, wherein the step of verifying includes generating the integrity report and the trust report. The data further includes:
Authenticate the client platform,
Receiving the integrity report from the client platform;
41. The article of claim 40, comprising data for performing a procedure for verifying a component described in the integrity report with an integrity authority. The data further includes:
Generating the trust report including the integrity / trust score using a plurality of integrity records stored in the integrity authority;
42. The article of claim 41, comprising data for performing a procedure to allow access to the client platform resources if the integrity / trust score exceeds a threshold. The data further includes:
Generating the trust report including the integrity / trust score using a plurality of integrity records stored in the integrity authority;
42. The article of claim 41, comprising data for performing a procedure to deny access to resources of the client platform if the integrity / trust score does not exceed a threshold. The data further includes:
Including data for performing a procedure for validating at least one component of the image file;
40. The article of claim 39, wherein the verifying step generates the generated integrity report and the trust report. The data further includes:
Receives a client platform for deployment,
45. The article of claim 44, comprising data for performing a procedure for installing the at least one component of the image file on the client platform prior to validating the image file. The data further includes:
Receives a client platform for deployment,
45. The article of claim 44, comprising data for performing a procedure for installing the at least one component of the image file on the client platform after validating the image file.

Images