METHOD AND APPARATUS FOR CONFORMING INTEGRITY OF A CLIENT DEVICE
Field of the Invention
[0001] The present invention relates generally to the field of networks and more specifically to conforming integrity of a client device in a network.
Background
[0002] Electronic devices such as personal computers, laptops, mobile phones, and Personal Digital Assistants (PDAs) are used to exchange data within a system A system can comprise an internet protocol (IP) network and a non-internet protocol system portion (which could be a non-IP network). For example, the portion of a cellular telephone system that includes the telephones and cell site transceivers is typically a non-IP portion of the system, whereas a gateway device in the system may be bridge between an IP network of the system and a non-IP portion of the system, while other network devices may be wholly within an IP network that forms a fixed portion of the cellular telephone system. A network can be a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), or a Virtual Local Area Network (VLAN). These are typically IP networks. Unfortunately, the effective operation of a network and the devices attached to it is threatened by cyber attacks. Some attacks may come directly in the form of hostile Internet traffic, while others may come in the form of "malware" such as viruses, spyware, rootkits, etc. In the past it was possible to defend a network at its perimeter, but as the sophistication of the attacks has grown it is now essential that the defense of a network encompasses not only the network infrastructure itself (routers, switches, load balancers, etc.) but also the devices attached to it. This in turn requires that these devices implement particular security configurations and security software (such as anti-virus software). In addition, because security compromises often begin by exploiting known flaws in software, the software packages on these devices should be continually kept up to date. This required configuration is expressed in a set of security policies for network devices. The electronic devices inside the network must comply with these policies to access the data or information stored in the network.
[0003] Furthermore, an electronic device, which is not an element of the network, may need to join the network. Such an electronic device is known as a client device. In order to ensure safety and integrity of the network, a client device should be given access to the network only when it is compliant to the network security policy. In the event that the device is not compliant, it should not be given access until it has been remediated, or brought into compliance with policy. This process is known as "network access control."
[0004] Several methods for network access control are known in the art. One conventional method of providing network access control involves the client device reporting a set of integrity measurements that describe the current statuses of elements of the clients device such as the software, data, and configuration parameters when the client device attempts to obtain access, such as when the device first connects to the network and the identity of the device and its user is established (authenticated). If the device and user are not successfully authenticated, the device is denied access to the network. If the device and user are successfully authenticated, the integrity measurements are examined, and if they indicate compliance with the security policy the device is granted full network access. If the device and user are successfully authenticated but the integrity measurements indicate some variance from the network security policy, the device is granted limited access so that it can retrieve software patches and other configuration information to bring itself into compliance
[0005] However, the method just described is processor intensive and can be employed only on the client devices having high bandwidth connections and reasonable tolerance to connectivity latency. Further, the collection of measurement data on the device typically requires that the client device contain some set of software components, or agents, that collect and report the measurement data. This approach is suitable for devices such as laptops, personal computers, etc. which have large memories, fast processors, and high-bandwidth connections. However, this approach does not scale well to small devices, such as mobile phones, which exhibit more stringent constraints upon processor speed, memory, and communications bandwidth. Further, there tend to be a fairly small number of variations between types of PCs, laptops, etc., typically a few configurations for, e.g., Windows XP, Windows 2000, MacOS, Linux, etc. By contrast, there is much greater diversity between mobile phones, with multiple manufacturers and multiple product lines per manufacturer.
Brief Description of the Figures
[0006] The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate the embodiments and explain various principles and advantages, in accordance with aspects of the present invention. [0007] FIG. 1 illustrates a communication system, in accordance with some embodiments of the present invention;
[0008] FIG. 2 illustrates a block diagram of a client device, in accordance with some embodiments of the present invention;
[0009] FIG. 3 illustrates a trusted software token that is passed from the client to a server, in accordance with various embodiments of the present invention;
[0010] FIG. 4 illustrates a mapping from client device type to a security policy identifier, in accordance with various embodiments of the present invention;
[0011] FIG. 5 is a diagram illustrating the network to which the client device is attached, in accordance with various embodiments of the present invention;
[0012] FIG. 6 is a client device flow diagram illustrating a method for conforming integrity of a client device, in accordance with various embodiments of the present invention;
[0013] FIG. 7 is a client device flow diagram illustrating additional steps for conforming integrity of a client device, invoked as part of the flow diagram in FIG. 6, in accordance with an embodiment of the present invention;
[0014] FIG. 8 illustrates a server call flow diagram for conforming integrity of a client device, in accordance with an embodiment of the present invention; and
[0015] FIG. 9 is a server flow diagram illustrating additional steps for conforming integrity of a client device, invoked as part of the flow diagram in FIG 8, in accordance with an embodiment of the present invention.
[0016] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve an understanding of embodiments of the present invention.
Detailed Description
[0017] Before describing in detail embodiments that are in accordance with aspects of the present invention, it should be observed that the embodiments reside primarily in combinations of method steps and apparatus components related to conforming integrity of a client device. Accordingly, the apparatus components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent for understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those with ordinary skill in the art having the benefit of the description herein.
[0018] In this document, relational terms such as first and second, and the like, may be used solely to distinguish one entity or action, from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such a process, method, article, or apparatus. An element proceeded by "comprises ...a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element. [0019] The embodiments described herein include methods for network access control that are more suitable for devices with the characteristics of mobile handsets. In particular, rather than the client sending a complete set of integrity measurements, these embodiments define a trusted token, stored on the client, to bypass the need for communicating the complete set of measurements, wherein the token verifies that the client device had a qualified set of integrity measurement as a specific time. When seeking access to the network, rather than exchanging the entire set of integrity measurements, the client reports this token. When the token is determined not to be valid, the client device is asked to make a detailed report of its entire set of integrity measurements. The network identifies those integrity measurements which establish a need for updating elements of the client's device, and the client device pulls the necessary updates (or the network pushes them) and the client updates those elements.
[0020] Various embodiments of the present invention provide a method for conforming integrity of a client device. The method includes transmitting a trusted token during a network access attempt. The trusted token can identify an integrity state of the client device. Further, the method includes possibly entering a remediation process, such process comprising receiving a list of required integrity measurements, obtaining these measurements, transmitting these measurements, receiving a set of updates, processing these updates, receiving a new trusted token, and storing the new trusted token.
[0021] For an embodiment of the present invention, a method for conforming integrity of a client device is provided. The method includes receiving from a client device a trusted token. The trusted token can identify an integrity state of the client device. Further, the method includes determining whether the integrity state of the client device is current. Furthermore, in the case in which the integrity state of the device is not current, the method includes entering a remediation process. The remediation process includes requesting a subset of integrity measurements from the client device that are not current. Moreover, the remediation process includes determining a set of updates from the subset of integrity measurements. Furthermore, the remediation process includes pushing the set of updates to the client device. Finally, the remediation process includes sending a new trusted token to the client device. The new trusted token identifies the current integrity state of the client device.
[0022] Various embodiments of the present invention provide a client device. The client device includes a transceiver for receiving a trusted token. The trusted token can identify an integrity state of the client device. Further, the client device includes a memory module for storing the trusted token. The transceiver is also for transmitting the trusted token during a network access attempt.
[0023] FIG. 1 illustrates a communication system 100, in accordance with some embodiments of the present invention. The communication system 100 includes a network 102 and a client device 106. Further, the network 102 includes a network access server 104. Various communication devices can exchange data or information through the network 102. The network 102 can be an internet protocol (IP) network such as a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Virtual Local Area Network (VLAN), or it could be any other type of network. Further, a network administrator of the network 102 may implement various security policies on the network 102. Examples of such policies can include versions of software, versions of data files, versions of antivirus software, configuration parameters and so forth. These policies ensure safety and integrity of data or information stored in the network 102. The network access server 104 is capable of verifying compliance of the client device 106 with the security policies of the network 102, when the client device 106 tries to access the network 102. The network access server 104 ensures that the identity and security policies of the client device 106 (and possibly also the identity of the person using the device) are verified before providing access to the network 102. For one embodiment, the network access server 104 can be a distributed set of servers in the network 102. The client device 106 can be one of several types of handheld devices, such as, a mobile phone, a laptop, or a personal digital assistant (PDA). For one embodiment, the client device 106 can be a WiFi capable device. The WiFi capable device can be used to access the network 102 for data by using Voice over Internet Protocol (VoIP).
[0024] FIG. 2 illustrates a block diagram of the client device 106, in accordance with some embodiments of the present invention. The client device 106 is capable of accessing the information or data stored in the network 102. For some embodiments of the present invention, the client device 106 may also support one or more applications for performing various communications with the network 102. The client device 106 can be a handheld device, such as, a mobile phone, a laptop, or a personal digital assistant (PDA). For some embodiments of the present invention, the client device 106 can be a WiFi capable device, which may be used to access the network 102 for data by using VoIP. The client device 106 may be a wireless device and may receive or transmit a trusted token wirelessly. The client device 106 may include a transceiver 202, which is capable of sending and receiving data over the network 102. The client device 106 includes a processor 204 that executes stored programs. The client device 106 may also include a volatile memory 206 and a non-volatile memory 208 which are used by the processor 204. The client device 106 includes a user input interface 210 that may comprise elements such as a keypad, display, touch screen, and the like. The client device 106 also includes a user output device that may comprise a display screen and an audio interface 212 that may comprise elements such as a microphone, earphone, and speaker. The client device 106 also includes a component interface 214 to which additional elements may be attached, for example, a Universal Serial Bus (USB) interface. Finally, the client device 106 includes a power supply 216. [0025] FIG. 3 illustrates a trusted token 300 that can identify an integrity state of the client device 106. The trusted token 300 can be received by the transceiver 204. The integrity state can be a configuration of the client device 106 that can be altered by downloading information to the client device 106. The trusted token 300 includes a first value, the policy identifier 302, for identifying a set of integrity measurements. The set of integrity measurements includes one or more of identification parameters for identifying versions of software, versions of data files, configuration parameters, and blowable fuse settings. Further, the trusted token may include one or more of a time stamp, an identifier of the client device 106, and a second value, the device type identifier 304, for identifying a predefined class of client devices. The time stamp can be used to identify the date of issuance of the trusted token by the network. The device type identifier 304 is used to identify a class of wireless communication devices, which can include mobile phones and Personal Digital Assistants (PDA). The predefined class of client devices includes the client device 106. Further, the integrity of the trusted token can be protected by encryption, for example, by using a signed cryptographic hash. The non-volatile memory module 206 can store the trusted token for later use when the client device 106 has to access the network 102. Further, when the client device 106 accesses the network 102, the transceiver 202 can transmit the trusted token 300 to the access server 104.
[0026] FIG. 4 illustrates a policy table 400 that the access server 104 may use in some embodiments to determine whether a trusted token 300 represents a valid integrity state. Each entry in the table may comprise a device type identifier (column 402) and a current policy identifier (column 404). In some embodiments, the trusted token 300 represents a valid integrity state when there is an row in the table for which the trusted token's device type identifier 304 appears in column 402 and the token's policy identifier 302 appears in column 404 on the same row. For example, as depicted in FIG. 4, a trusted token for which the device type identifier 304 is "B" and the policy identifier 302 is "β" represents a valid integrity state because policy table 400 contains a row (B,β).
[0027] FIG. 5 illustrates a communication system for conforming integrity of the client device 106, in accordance with some embodiments of the present invention. The system includes the network 102, the access server 104, the client device 106, a compliance server 506, other network servers 508, and an access router 504. The access server 104 and compliance server 506 both have access to a policy table 400. Further, the network 102 may include a quarantine network 502. For an embodiment the access server 104 can be integrated with an authentication server, for example, a RADIUS (Remote Authentication Dial-In User Server) server. The client device 106 interacts with the access router 504 to access the network 102. In one embodiment, the access router 504 can initiate an Extensible Authentication Protocol (EAP) session to begin the process of authentication and verification of compliance to policies of the network 102 by the client device 106. In a preferred embodiment, the access router 504 can initiate EAP through a Virtual Private Network (VPN) gateway, an intranet wired access-point, or an intranet wireless access-point. For exemplary purpose, let us assume that the EAP exchange occurs over a wireless LAN interface such as one that is compliant with one of the standards promulgated by the IEEE known as 802.11. As part of the EAP authentication exchange, the client device 106 sends the client and user authentication information, along with the trusted token 300 to the intranet wireless access router 504 in the form of an EAP response. On receiving the EAP response from the client device 106, the access router 504 sends a Remote Authentication Dial-In User Server (RADIUS) access request along with the trusted token, to the access server 104. For an embodiment of the present invention, the access server 104 can authenticate the client device 106. The client device 106 is not provided access to the network 102 if the authentication fails. The authentication can fail when the client device 106 is not recognized by the access server 104. The access server 104 contains a policy table 400 that defines the current policy for each device type. After authentication of the client device 106, the access server 104 determines the integrity state of the client device 106 by searching the policy table 400 for an entry that matches the device type identifier 304 and policy identifier 302 in the trusted token. If a matching entry is found, the integrity state of the client device 106 is current. Based on the integrity state of the trusted token (current or not current), the client device 106 can be granted access either to the entire network 102 or only the quarantine network 502 by the access router 504, which is directed to provide appropriate access to the client device 106 by the access server 104. The access of the client device 106 can thus be restricted to only the quarantine network 502, for the purpose of attempting to update the client device 106 and the trusted token 300, when the trusted token 300 of the client device 106 is not current. When the trusted token 300 of the client device 106 is current, the access server 104 sends a RADIUS access- success response to the access router 504, stating that the client device 106 can be provided access to the entire network 102 and the client device 106 is considered to be operating in the full-access network 512. While restricted to accessing the quarantine network 502, the client device 106 can access only the compliance server 506, whereas when the client is operating in the full-access network 512, the client device can access database server and electronic-mail and other web applications server of the network 102.
[0028] When the access server 104 authenticates the client device 106, but the access server 104 determines that the integrity state represented by the trusted token 300 is not current, a further process is initiated to verify the integrity state of the client device 106, apply updates to bring it into policy compliance, and update the trusted token 300. For this process, the client device 106 is provided access to the quarantine network 502 as stated above. The quarantine network 502 includes a compliance server 506. The compliance server 506 can be used to request and receive integrity measurements from the client device 106 and to verify those measurements against the current policy for that type of device. Further, the compliance server 506 can determine a set of updates that are required to bring the client device 106 back into compliance with policy. Further, the compliance server 506 can send those updates to the client device 106. Finally, the compliance server 506 can be used for updating the trusted token. The compliance server 506 can construct a new trusted token 300, which is updated and current. The new trusted token can be sent to the client device 106. Further, the client device 106 can use the new trusted token for accessing the network 102. For one embodiment, communication with the client device 106 for configuration management and trusted token provisioning can be realized using OMA DM protocol.
[0029] FIG. 6 is a flow diagram of a method for conforming integrity of the client device 106, in accordance with various embodiments of the present invention. At step 602, the method for conforming integrity of the client device 106 is initiated on the device. At step 604 the device and user are authenticated. In an exemplary implementation this may occur using an EAP authentication exchange. When authentication fails, the client device 106 is allowed no network access at step 605 the client device 106 may try to authenticate again later, at step 602. When authentication succeeds, the client device 106, at step 606, examines its non-volatile memory 208 to determine if there is a trusted token 300 stored there. If there is a trusted token 300, execution passes to step 608; otherwise, execution proceeds directly to step 610. At step 608 the trusted token is transmitted by the client device 106 to the access server 104. In an exemplary implementation this may take place using EAP. At step 610 the authentication status is received at the client device 106 from the server. In an exemplary implementation this may be received as an EAP message such as EAP- success or EAP-failure. At step 612 the authentication status is further examined to determine whether the device is to be quarantined. If the device is to be quarantined, execution proceeds to step 613, where it is quarantined and wherein an extended compliance process 614 is performed as represented in detail by FIG. 7. At the completion of step 614 execution returns to step 604. If, at step 612, the device is not quarantined, the client device is permitted full access to the network at step 615, and execution passes to step 616. At step 616, the method for conforming integrity of the client device 106 is terminated.
[0030] FIG. 7 is a flow diagram of a method for conforming integrity of the client device 106, in accordance with an embodiment of the present invention. Specifically, FIG. 7 is a flow diagram for step 614 of FIG. 6. At step 702, the method is initiated, corresponding to the point at which step 614 is reached. At step 704 the client device 106 receives a list of integrity measurement requests from the compliance server 506. The list of integrity measurement requests may include parameters for identifying versions of software, versions of data files, configuration parameters, and blowable fuse settings. For one embodiment of the present invention, OMA DM can be used to transfer this list of measurement requests from the compliance server 506 to the client device 106. At step 706 the list of measurement requests is examined to determine whether it is empty. If the list of measurement requests is not empty, execution passes to step 708 and the client device 106 takes at least one of the requested measurements and sends them to the compliance server 506. For one embodiment, OMA DM can be used to transfer the measurements to the compliance server 506. After step 708, control passes back to step 704 and the client device 106 receives a new list of measurement requests from the compliance server 506. The cycle repeats until the list of measurement requests is empty. At step 706, if the list of measurement requests is empty, control passes to step 709. At step 709 the client device 106 receives and processes a set of updates from the compliance server 506. By way of example, these updates can include new software packages, new versions of existing software packages, new or updated configuration files or databases (such as a new virus signature database), and updated configuration parameters. At step 708 the client device 106 processes these updates as according to their kind; for example, new or updated software packages are installed, new or updated configuration files are written, and configuration parameters are altered to the new values, respectively. For one embodiment, OMA DM can be used to transfer the updates to the client device 106 and cause them to be processed. When the updates are complete, control passes to step 710. At step 710 the client device 106 receives and stores a new trusted token from the compliance server 506. This token represents the new integrity state of the client device as established by the updates in step 708. After the new trusted token is stored, the sub-method terminates at step 712, and control passes back to step 604 as depicted in FIG. 6.
[0031] FIG. 8 is a flow diagram of a method for conforming integrity of the client device 106, in accordance with some embodiments of the present invention. In an exemplary implementation, this is performed by the access server 104. At step 802, the method for conforming integrity of the client device 106 is initiated. At step 804, a trusted token 300 is received at the access server 104 from the client device 106. (If the client device 106 does not currently possess a trusted token, it instead sends an indication that the trusted token is missing.) When present, the trusted token 300 can identify an integrity state of the client device 106. Step 806 determines if the trusted token 300 is present. If so, execution passes to step 808. At step 808 a policy table such as policy table 400 is examined to determine whether the trusted token 300 represents a valid integrity state (i.e., is current), as previously described. If the policy table 400 contains an entry that matches the device type and current policy for contained in the trusted token 300, then the token is current. At step 810 the result of step 808 is tested. If the trusted token 300 is current, then execution passes to step 814. If, at step 806 the trusted token 300 is missing, or at step 810 the trusted token 300 is not current, execution passes to step 812 which is represented in detail by FIG. 9. At the completion of step 812 execution passes to step 814. At step 814 the method for conforming integrity of the client device 106 is terminated.
[0032] FIG. 9 is a flow diagram of a method of a method for conforming integrity of the client device 106, in accordance with an embodiment of the present invention. Specifically, FIG. 9 is a flow diagram for step 812 of FIG. 9. In an exemplary implementation, it would be implemented by the compliance server 506. At step 902 the method is initiated. At step 904 the trusted token 300 received at step 804 of FIG. 8 is examined to determine the current integrity state of the client device 106. The integrity state includes a first value, a policy identifier 302 that represents a set of integrity measurements. The set of integrity measurements includes parameters for identifying versions of software, versions of data files, configuration parameters, and blowable fuse settings. Because the trusted token 300 does not represent a current integrity state, a subset of the integrity measurements represented by the trusted token 300 are no longer current. The subset of integrity measurements that are not current can be determined by comparing the set of integrity measurements represented by the policy identifier 302 with the current set of integrity measurements for the predefined class of client devices. At step 908, the set of integrity measurements that are not current are requested from the client device 106. For one embodiment of the present invention, an Open Mobile Alliance Device Management (OMA DM) protocol can be used for requesting the client device 106 for a subset of integrity measurements that are not current. At step 910, a set of updates is determined. The set of updates can be determined from the subset of integrity measurements. At step 912 the set of updates is pushed to the client device. The set of updates can be an updating of the version of software and data files stored on the client device 106, configuration parameters, and blowable fuse settings. For one embodiment of the present invention, an OMA DM protocol can be used to push the updates. At step 914 a new trusted token 300 is created representing the new integrity state of the client device 106 and the new token is pushed to the client device 106. At step 916, the sub-method for conforming integrity of the client device 106 is terminated and execution passes to step 814 of FIG. 8, where the method is terminated.
[0033] Various embodiments of the present invention offer a number of advantages. The method and system described herein can be used for conforming integrity of lightweight client devices, such as, mobile phones and other handheld devices. A preferred embodiment of the present invention uses the framework defined by the Extensible Authentication Protocol and IEEE 802. Ix. Further, the present invention shifts the majority of processor intensive task from the client device to a fixed-end server. The client device needs to store only a trusted token created by the server. Further, the integrity of the trusted token can be protected using inscription.
[0034] It will be appreciated that embodiments of the invention described herein may comprise one or more conventional processors and unique stored program instructions that control the one or more processors to implement, in conjunction with certain non- processor circuits, some, most, or all of the functions of the embodiments of the invention described herein. The non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method for conforming integrity of a client device. Alternatively, some or all the functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of these approaches could be used. Thus, methods and means for these functions have been described herein. In those situations for which functions of the embodiments of the invention can be implemented by using a processor and stored program instructions, it will be appreciated that one means for implementing such functions is the media that stores the stored program instructions, be it magnetic storage or a signal conveying a file. Further, it is expected that one with ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such stored program instructions and ICs with minimal experimentation.
[0035] In the foregoing specification, specific embodiments of the present invention have been described. However, one with ordinary skill in the art would appreciate that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
[0036] The Abstract of the Disclosure is provided to comply with 37 CF. R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all the features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.