Patent Application
20080134299
Protecting objects from theft is a problem for both individuals and businesses. Certain items such as computers, video projectors, printers, and the like are common theft targets due to their high value and portability. Businesses and individuals may attempt to secure items from theft using a mechanical lock and security cable. However, this type of security is easily defeated by cutting the security cable and carrying off the protected item.
Another security measure utilizes security cameras to monitor high-value items. Although the security camera may attempt to capture an image of the person stealing the item, this security approach can be overcome by disabling the security camera or disguising the appearance of the thief.
Current security approaches, including those discussed above, have a common problem: once the item is successfully carried away from the location at which the security system is located, the device functions in a normal manner. For example, if a computer is stolen by cutting a security cable attached to the computer, that computer will function normally and contain the same data after it is activated by the thief at a distant location. This problem encourages the theft of certain items because thieves know that the stolen item will have value due to its ability to continue functioning normally.
The same reference numbers are utilized in instances in the discussion to reference like structures and components.
In the following discussion, exemplary devices are described which may provide and/or utilize techniques to provide security for one or more protected devices. When a protected device is within communication range of a network or a network access point (e.g., a wireless access point, power line communication, LAN connection, or phone line connection) and able to communicate with it, the protected device operates normally. The protected device is by default disabled and can be enabled remotely via the network connection. However, moving the protected device outside the range of the network or network access point eliminates the ability of the user to enable and use the protected device. Stealing such a protected device is therefore discouraged because the stolen device will have little value without being able to enable the device. Exemplary procedures are described which may be employed by the exemplary devices, as well as by other devices without departing from the spirit and scope thereof.
Exemplary Devices
A single protected device 118 is illustrated in
Computing device 102, as illustrated in
Memory 106 may be representative of “main memory” of computing device 102, persistent storage (e.g., a hard disk drive), removable computer-readable media (e.g., a digital video disc (DVD)), and other types of computer-readable media. Likewise, although a single memory 106 is illustrated, memory 106 may be representative of multiple memory devices, such as dynamic random access memory (DRAM) and a hard disk drive. A variety of other implementations are also contemplated.
Computing device 102 includes a key generation module 110 that is capable of generating security keys and authenticating data received from one or more protected devices 118. For example, key generation module 110, when executed, generates one or more security keys to be distributed to one or more protected devices 118. In another example, key generation module 110, when executed, authenticates device identity data received from one or more protected devices 118. These keys may be centrally managed and distributed as part of a corporate- or campus-wide public key infrastructure.
Various protected device data 112 is maintained in memory 106. This protected device data 112 is used, for example, by key generation module 110 to generate security keys or authenticate data received from a protected device 118. Protected device data 112 may include information associated with one or more protected devices 118, one or more security keys, and the like.
Computing device 102 also includes a communication module 114, which allows computing device 102 to communicate with any number of devices via any number of communication links and/or communication networks. In the example of
Protected device 118 includes a communication module 120, a key storage module 122, and a device activation module 124. Communication module 120 allows protected device 118 to communicate with other devices, such as an authentication system or a key distribution system. In one embodiment, communication module 120 communicates with network 116 via a wireless communication link. In other embodiments, communication module 120 communicates with other devices via a wired, wireless, or combination of wired and wireless communication links.
Communication module 120 may be added to devices that do not otherwise utilize a network communication link. For example, a particular video projector may not contain a network interface. However, to protect the device in the manner discussed herein, an inexpensive communication module 120 is embedded in the device. This communication module 120 is coupled to key storage module 122 and device activation module 124 to activate the video projector using the techniques described herein. Authentication and enablement of devices may also be time limited such that authentication must occur periodically in order to maintain operation of the device.
Key storage module 122 stores one or more security keys used to authenticate protected device 118. Device activation module 124 performs various functions to determine whether protected device 118 should remain active or should be deactivated or disabled. Device activation module 124 includes a processor 126 that performs various functions related to the authentication, activation, and disabling of protected device 118, as discussed herein. Device activation module 124 may periodically verify that protected device 118 can access computing device 102 via network 116. If protected device 118 cannot access computing device 102 via network 116, device activation module 124 may deactivate or disable protected device 118. Protected device 118 is deactivated or disabled based on an assumption that protected device 118 has been improperly moved outside the communication range of network 116 or outside the communication range of an associated network access point.
In one embodiment of protected device 118, key storage module 122 and device activation module 124 are located in a trusted portion of the protected device's hardware that is not subject to any consumer-level reset functionality. For example, key storage module 122 and device activation module 124 can be part of a Trusted Platform Module (TPM) distributed by Intel Corporation of Santa Clara, Calif. Such configuration reduces the likelihood that a user will tamper with key storage module 122 or device activation module 124 to defeat the security provided to protected device 118.
In another embodiment, communication module 120, key storage module 122, and device activation module 124 are contained on a separate component that can be physically and electrically coupled to protected device 118. For example, the separate component may be coupled to protected device 118 using a universal serial bus (USB) connection or other interface. When the separate component is coupled to protected device 118 and is within range of a network or a network access point associated with protected device 118, the protected device operates normally. However, removal of the separate component or relocating protected device 118 outside the range of the network or network access point prevents the enabling of protected device 118.
Generally, any of the functions described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module,” “functionality,” and “logic” as used herein generally represent software, firmware, hardware, or a combination thereof. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs such as the processor 104 of
Exemplary Procedures
The following discussion describes security techniques that may be implemented utilizing the previously described systems and devices. Aspects of each of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. In portions of the following discussion, reference will be made to the environment 100 of
Initially, a protected device is activated (block 202), for example, in response to receiving a user request to activate the protected device. Device activation may include powering-up the device, resetting the device, or otherwise initializing the device for operation. As part of the activation process, the protected device attempts to establish a wireless connection to a network access point (block 204), for example by accessing a wireless access point associated with the network. If the protected device cannot establish a wireless connection with the network access point, the procedure branches from block 206 to block 208, which does not enable (or partially enables) the protected device. For example, the protected device may be powered down at block 208 or otherwise prevented from being enabled. In this situation, the protected device may be referred to as a non-enabled device. The protected device is not enabled in this situation because there is a likelihood that the protected device has been stolen (e.g., moved to a location that is not within range of a network access point coupled to the network). Thus, the protected device has little value when taken from the area in which the protected device can access the network, because the protected device will not function properly. In alternate embodiments, procedure 200 may require two or more successive failures to establish a wireless connection to the network before preventing the enabling of the protected device.
A failure to enable the protected device (or “disabling” the protected device) does not physically damage the device or otherwise affect the ability of the protected device to operate properly in the future. Thus, if the protected device is not enabled because the network (or network access point) was unavailable for a period of time, the protected device can be activated again when the network or network access point is operating properly. When this occurs, the protected device can be activated because the protected device can successfully establish a connection to the network. Even though the protected device was not enabled during a previous network access attempt, the protected device will now operate normally with no loss of functionality due to the previous failure to enable the protected device.
Referring again to
If the protected device cannot be authenticated by the authentication system, the procedure branches from block 212 to block 208, which does not enable (or partially enables) the protected device. The protected device is not enabled due to the likelihood that the protected device has been stolen or otherwise tampered with such that the authentication system cannot authenticate the identity of the protected device or user thereof. In alternate embodiments, procedure 200 may require two or more successive authentication failures over a period of time before preventing the enabling of the protected device. Some embodiments attempt to activate the non-enabled device a particular time period (e.g., 10 minutes) after the device has been prevented from being enabled. These embodiments consider the possibility that the network or network access point may have been unavailable or malfunctioning the first time the protected device was activated.
If the protected device is authenticated by the authentication system, procedure 200 enables the protected device to continue normal operation (block 214). In this situation, the protected device is within range of a network access point and is authenticated by an authentication system accessible via the network. This indicates that the protected device is still located in the proper building, campus, or other geographic area, and is not likely to have been stolen.
In particular embodiments, each protected device 118 is associated with a particular network access point. In other embodiments, each protected device 118 is associated with a particular network (e.g., a corporate LAN).
If the timer value exceeds the threshold value, procedure 300 branches from block 306 to block 310, which resets the timer value to zero. Next, the protected device attempts to establish a wireless connection to a network access point (block 312). If the protected device cannot establish a wireless connection with the network access point, the procedure branches from block 314 to block 316, which disables (or partially disables) the protected device. The protected device is disabled in this situation because there is a likelihood that the protected device has been stolen (e.g., moved to a location that is not within range of a network access point coupled to the network). In alternate embodiments, procedure 300 may require multiple successive failures to establish a wireless connection to the network before disabling the protected device. For example, a particular embodiment requires six successive failures (with ten minutes between each pair of successive failures) before the protected device is disabled. This embodiment takes into consideration possible network errors or other network communication problems that would otherwise incorrectly disable the protected device.
If the protected device successfully establishes a wireless connection with the network access point, the protected device attempts to communicate with an authentication system via the network (block 318). Additionally, the protected device requests authentication data from the authentication system. This request for authentication data may include a security key or other data identifying the protected device or the user of the protected device. If the protected device cannot be authenticated by the authentication system, the procedure branches from block 320 to block 316, which disables (or partially disables) the protected device. The protected device is disabled due to the likelihood that the protected device has been stolen or otherwise tampered with such that the authentication system cannot authenticate the identity of the protected device. In alternate embodiments, procedure 300 may require two or more successive authentication failures before disabling the protected device.
If the protected device is authenticated by the authentication system, procedure 300 enables the protected device to continue normal operation (block 322). In this situation, the protected device is within range of a network access point and is authenticated by an authentication system accessible via the network. This indicates that the protected device is still located in the proper building, campus, or other geographic area, and is not likely to have been stolen. Procedure 300 then returns to block 304 to await the next time at which the protected device is verified to be in its proper location.
Thus, if a protected device cannot access a particular network (such as a LAN associated with the building in which the protected device should be located) the protected device is disabled (or not enabled) due to the likelihood that the protected device has been stolen. The area in which the protected device should be located may include a portion of a building, an entire building, multiple buildings (e.g., a business or education campus), a town, or other geographic area. Announcing that such a security system is in operation will reduce the likelihood that these protected devices are stolen because the protected devices will not function and will have little value after they are removed from their protected building or geographic area.
Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.
