Patent Application
20080072329
A more detailed understanding of the invention may be had from the following description of a preferred embodiment, given by way of example and to be understood in conjunction with the accompanying drawings wherein:
When referred to hereafter, the terminology “node” includes but is not limited to a wireless transmit/receive unit (WTRU), a user equipment (UE), a mobile station (STA), a fixed or mobile subscriber unit, a pager, a cellular telephone, a desk-top computer, a lap-top computer, a personal data assistance (PDA), a base station, a Node-B, a site controller, an access point (AP) or any other type of device capable of communication in a wireless or wired environment.
After receiving the evaluation function 330 from the trustor node 310, the trustee node 320 performs evaluation of behavior metrics using the received evaluation function 330. The trustee node 320 then sends an evaluation result 340 to the trustor node 310.
In order for the trustee node 320 to perform security evaluation, the trustee node 320 must be deemed secure enough. Therefore, optionally, before sending the evaluation function 330 to the trustee node 320 and allowing the trustee node 320 to perform the evaluation, a limited evaluation may be performed by the trustor node 310 to determine if the trustee node 320 has already been compromised. For this initial evaluation, the trustee node 320 may optionally send limited behavior metrics 350 to the trustor node 310. After determining that the trustee node 320 is not compromised based on the limited behavior metrics 350, the trustor node 310 may send the evaluation function 330 to the trustee node 320. The limited behavior metrics 350 may be used for the TCG's remote attestation.
TCG remote attestation starts with the boot-up sequence of the trustee node 320. Each stage of boot-up records aspects of the next phase of boot-up. This may involve representing the next stage of firmware and/or software that is to run by taking a hash of it and recording related identifying information. It may be extended to record activities performed by a node after boot up that can be used to determine the degree of security existing at a node. All of this information is stored in a history log. The information recorded in the history log may be evaluated internally for desirableness. For remote attestation, this evaluation is performed by the trustor node 310. Therefore, the history of boot-up and other security related activities need to be sent to the trustor node 310.
To maintain a trusted check on the sequence of the generated history information, the information formed at each stage is hashed to a platform configuration register (PCR) on the TCG's TPM. The integrity of the value(s) in the PCR(s) is maintained by the TPM signing this value when released to the trustor node 310. The PCR value(s) allows the trustor node 310 to verify the integrity of the history log. The trustor node 310 then needs to evaluate the history log to determine if the current security state of the trustee node 320 is such that the trustor node 310 wants to engage in certain transactions with the trustee node 320. This information may be input to the trustor node's evaluation function.
Some of the information in the history log may be considered a breach of privacy if it was to be released to the trustor node 310. Therefore, during boot-up, multiple history logs may be formed. Some history logs provide limited information such as what software has run since startup, including virus scan software and the results of its scanning. Other history logs may provide more revealing information such as the addresses or IDs of nodes with which communications has been engaged by the trustee node 320. The limited history logs may be first sent to the trustor node 310 to determine if the trustee node 320 can be trusted to perform a more complete or specialized evaluation using a more complete or specialized history log.
Once the trustee node 320 becomes compromised, it is possible for all metrics, including historical metrics that are stored internally to be falsified to hide the fact that the trustee node 320 is compromised. By using the remote attestation, the behavior metrics may be signed by a trusted external party so that any tampering of the behavior metrics can be detected.
Considering the current inexpensive massive portable storage capacity, the behavior metrics may be accumulated for an indefinite period of time. However, as behavior metrics are of greater distance, (i.e., from further up the stream), and of greater age, their influence on a node's security diminishes because with greater distance and age, the greater the opportunity to detect any virus a node may be spreading. Therefore, a greater weight may be given to newer behavior metrics from closer nodes. For assigning a weight, each set of behavior metrics is given a timestamp by the node that generated the behavior metrics and as the behavior metrics travel from one node to another, a hop count for each behavior metrics is incremented. As the weight of a behavior metric falls below a predetermined threshold, the behavior metric may be discarded.
Since the accumulation of the behavior metrics is separate from the use of the behavior metrics in an evaluation function, the determination of what behavior metrics to accumulate may not be based on the needs of a particular evaluation function. Therefore, the behavior metrics that need to be generated and accumulated may be standardized.
Each set of behavior metrics may be assigned a unique identity (ID), such as a universal unique identifier (UUID). A node may assign an UUID for each set of behavior metrics generated by the node and may store the UUIDs for later reference. The node also stores UUIDs received from upstream nodes. If the node detects a virus later, the node may send the UUIDs sent to the downstream nodes to the downstream nodes to warn potential infection of the virus. The node may also send UUIDs received from upstream nodes to the upstream nodes to let the upstream nodes know that they may be infected. This assumes that each node can contact nodes that it has had past communications with. By using separate UUIDs for each set of behavior metrics, a node having a security problem may be specifically identified. Alternatively, a node may create a pseudononymous identity from the UUIDs that is effective for a limited period of time.
A node may become compromised at some point in time. Behavior metrics generated before the compromise may validly indicate a poor security state for that time and behavior metrics generated after the compromise may indicate a poor security state but may be falsified by the compromised node. Ideally, during the period of time when the compromise is occurring, the generated behavior metrics will indicate a problem. Therefore, the security state of a node is enhanced by having a node submit its behavior metrics to an intermediary periodically.
The periodic transmission of behavior metrics may be triggered by the TPM. For example, the TPM of the TCG creates a tick count. One or more count down registers may be loaded with a value that is decremented with each tick from the TPM. Upon reaching 0, a trigger signal is sent to a metrics component 812 of the node 810 to generate and gather behavior metrics so that behavior metrics are sent to the intermediary 820 at periodic intervals. The reporting period may be set to any value. The period may be reduced as a behavior metrics-related activity increases. The behavior metrics may also be sent when particular events are detected. By having the trigger signal come from the TPM, any time stamping performed by the TPM can be coordinated with the generation of the behavior metrics.
Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention. The methods or flow charts provided in the present invention may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any integrated circuit, and/or a state machine.
A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment, terminal, base station, radio network controller, or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a videocamera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a handsfree headset, a keyboard, a Bluetooth module, a frequency modulated (FM) radio unit, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any wireless local area network (WLAN) module.
This application claims the benefit of U.S. Provisional Application No. 60/825,678 filed Sep. 14, 2006, which is incorporated by reference as if fully set forth.
| Number | Date | Country | |
|---|---|---|---|
| 60825678 | Sep 2006 | US |
