Using a USB host controller security extension for controlling changes in and auditing USB topology
Protecting computer systems from attacks that attempt to change USB topology and for ensuring that the system's information regarding USB topology is accurate is disclosed. A software model is defined that, together with secure USB hardware, provides an ability to define policies using which USB traffic can be properly monitored and controlled. The implemented policy provides control over USB commands through a combination of software evaluation and hardware programming. Legitimate commands are evaluated and "allowed" to be sent to a USB device by a host controller. Illegitimate commands are evaluated and blocked. Additionally, the USB topology is audited to verify that the system's topology map matches the actual USB topology.
FIELD OF THE INVENTION
The invention generally relates to the field of the universal serial bus (USB) and specifically to the security of data associated with the USB.
BACKGROUND OF THE INVENTION
The manner in which USB peripherals are attached to a USB Host Controller and the manner in which USB drivers communicate with their corresponding devices make it difficult to prevent malicious software from mounting different classes of attacks that attempt to modify the USB topology. Such attacks may take various forms such as, for example, substitution attacks and snooping attacks.
A substitution attack involves substituting an illegitimate USB device for a legitimate device without the system recognizing that a substitution occurred. Each USB device is attached to a port on either a root hub or an external hub. A hub driver controls the state of its hub ports by sending certain USB commands over the hub's default pipe (endpoint 0). A malicious driver may hide a programmable USB device attached to one of the hub ports by disabling the port to which the device is connected. The driver then may be able to disable a port of a real keyboard that is attached to the same hub and enable the port of the programmable device. In addition, the malicious driver may set the USB address of its programmable device to the address that was assigned to the keyboard it disabled. The end result is that the real keyboard is spoofed by a programmable device, and the driver for the keyboard is not aware that it is talking to a different device. In sum, the system believes that input data is generated by the keyboard when the data is generated programmatically by an adversary.
Another type of attack, the snooping attack, attempts to modify USB topology by taking advantage of a process in which a device driver reads data from its device by sending it an appropriate USB command. Some data sent by a device ideally should not be read by any entity besides the applicable device driver. An example of such case is when the device has to exchange an encryption key with the driver so that the driver can use the key for decrypting data that the device is going to generate later. An adversary may obtain sensitive data by either sending an appropriate command to the device or by mounting an attack in which the adversary grabs data en route to the requesting device driver. Additionally, it is recognized that a software solution may make it more difficult for an attacker to obtain sensitive information, but software alone likely cannot provide full protection against such attacks.
Additionally, in a computer system with a USB Host Controller and USB peripherals connected to it, it is desirable for software to be able to obtain information regarding USB topology. It is currently possible for legitimate system software to obtain such information. Malicious software, however, may tamper with topology information such that legitimate software may not be able to verify that topology information it receives appropriately reflects actual USB topology. For example, an adversary may program a USB device so that it looks to the system like a different device, such as a keyboard. Because the system may need to secure certain USB input devices in order to establish a trusted path with a user, mounting this attack leads the system to "trust" a keyboard device even though it is not a really a keyboard. A malicious driver mounts the attack by sending a USB command that configures a physical programmable device. The host controller driver queries the device for its USB descriptors, and the device returns descriptors indicating that the device is a keyboard. Thus, the system loads a keyboard driver for controlling that device.
This driver then waits for input data to be generated by the device. At that point, the malicious driver can trigger the device to generate one or more keystrokes by sending an appropriate USB command to the device. When these keystrokes are generated, the keyboard driver sends the corresponding keyboard events to the operating system. The end result is that the malicious driver can inject input events into the system. This also provides the malicious driver with the ability to have the device "playback" a certain keystroke sequence at a specific time, which may create general problems and may even enable the driver to inject input into a trusted input path as if the input was generated by a trusted device.
There is a need, therefore, for systems and methods to prevent attacks on USB systems that attempt to change USB topology and to audit USB topology to ensure that the information that the system maintains regarding the attached USB devices appropriately reflects the actual USB topology. The systems and methods ideally should not be based solely in software.
SUMMARY OF THE INVENTION
The invention provides systems and methods for protecting computer systems from attacks that attempt to change USB topology and for ensuring that the system's information regarding USB topology is accurate. The invention includes defining a software model that, together with secure USB hardware, provides an ability to define policies using which USB traffic can be properly monitored and controlled. The implemented policy provides control over USB commands through a combination of software evaluation and hardware programming. Legitimate commands are evaluated and "allowed" to be sent to a USB device through the host controller. Illegitimate commands are evaluated and blocked.
The invention may be implemented to control USB topology changes. Because most topology changes involve a USB setup command sent to a relevant USB hub, trusted software may monitor such commands so that the status of USB devices connected downstream from the hub is accurate. According to the invention, data associated with a USB device, such as a setup command, is received by trusted software, and a determination is made regarding whether the data is allowed to be sent to the targeted USB device. If the data is allowed, then an instruction is sent to a host controller driver to send the data. Additionally, the trusted software may program a security extension residing on a host controller chipset to allow the data through to the USB topology and device. If the data is not allowed, then the trusted software may program the security extension to block the data from going through.
The invention includes auditing the USB topology to verify that the system's topology map matches the actual USB topology. The invention defines a model in which software and hardware are used together in order to perform the USB topology audit in a trustworthy fashion. Auditing the USB topology is valuable when certain USB devices need to be differentiated from other devices. For example, input devices may be differentiated from other USB devices because a user may generate secure input. The differentiation may provide for the establishment of a trusted input path between the user and the system application receiving the user input. The USB topology audit provides an ability to detect input devices residing in the topology in a trustworthy fashion and protects against security attacks to the system through the USB topology.
The USB audit includes receiving a USB topology map from a USB host controller driver. The map, generated by untrusted software, is verified by trusted software through a series of commands sent to the USB topology through the host controller chipset. The devices provide identifying information that is compared against the map. The identifying information received from the devices is diverted to a secure buffer in the security extension hardware and therefore trusted software is guaranteed to receive device data that hasn't been tampered with by malicious software. Before sending the aforementioned commands to the devices, the trusted software resumes all ports of the hubs in the topology in order to make sure that malicious software has not hidden a device by suspending the hub port to which the device is connected. Once the identifying information is received and scrutinized, trusted software compares the number of active hub ports with the number of devices and makes sure they are equal and that there are no hidden devices in the topology. The audit also includes identifying and securing input devices such that information generated by the input devices is diverted through a secure buffer in the security extension for evaluation within a trusted execution environment in the system.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing summary and the following detailed description of the invention are better understood when read in conjunction with the appended drawings. Embodiments of the invention are shown in the drawings, however, it is understood that the invention is not limited to the specific methods and instrumentalities depicted therein. In the drawings:
FIG. 1 is a block diagram showing an example computing environment in which aspects of the invention may be implemented;
FIG. 2 is block diagram of an example system for using a USB host controller security extension for controlling changes in and auditing USB topology according to the invention;
FIG. 3 is a flow diagram of an example method for controlling delivery of USB commands to USB devices according to the invention;
FIG. 4 is a flow diagram of an example method for controlling delivery of USB commands regarding cryptographic keys according to the invention;
FIGS. 5A-5B depict a flow diagram of an example method for auditing a USB topology according to the invention; and
FIG. 6 is a block diagram of an example system for auditing a USB topology according to the invention.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
FIG. 1 and the following discussion are intended to provide a brief general description of a suitable computing environment 100 in which an example embodiment of the invention may be implemented. As used herein, the terms "computing system," "computer system," and "computer" refer to any machine, system or device that comprises a processor capable of executing or otherwise processing program code and/or data. Examples of computing systems include, without any intended limitation, personal computers (PCs), minicomputers, mainframe computers, thin clients, network PCs, servers, workstations, laptop computers, hand-held computers, programmable consumer electronics, multimedia consoles, game consoles, satellite receivers, set-top boxes, automated teller machines, arcade games, mobile telephones, personal digital assistants (PDAs) and any other processor-based system or machine. The term "data" refers to any information of any form, including commands, transfers, or requests. The terms "program code" and "code" refer to any set of instructions that are executed or otherwise processed by a processor. The term "untrusted program code" or "untrusted code" refers to any set of instructions that are executed or otherwise processed by a processor outside of a trusted execution environment. The term "device driver" refers to any program code that at least in part controls a component of a computer system, such as a USB device, or facilitates communication of data between a component and other devices or program code of a computer system. The term "trusted execution environment" refers to an environment comprising trusted program code that is isolated from other code located outside of the trusted execution environment and to which security policies are applied to provide secure execution of the program code.
The term "universal serial bus" or "USB" refers to a cable bus that supports data exchange between a host computer and a wide range of accessible peripheral devices or functions. "USB device," "USB function," "USB peripheral" or "peripheral" refers to devices that may be attached or that are attached to a USB. USB devices, functions, or peripherals share USB bandwidth through a host-scheduled, token-based protocol. The USB allows peripherals to be attached, configured, used, and detached while the host and other peripherals are in operation.
While a general purpose computer is described below, this is merely one example. The present invention also may be operable on a thin client having network server interoperability and interaction. Thus, an example embodiment of the invention may be implemented in an environment of networked hosted services in which very little or minimal client resources are implicated, e.g., a networked environment in which the client device serves merely as a browser or interface to the World Wide Web.
Although not required, the invention can be implemented via an application programming interface (API), for use by a developer or tester, and/or included within the network browsing software which will be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers (e.g., client workstations, servers, or other devices). Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. An embodiment of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
FIG. 1 illustrates an example of a suitable computing system environment 100 in which the invention may be implemented, although as made clear above, the computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Nor should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.
With reference to FIG. 1, an example system for implementing the invention includes a general purpose computing device in the form of a computer110. Components of computer 110 may include, but are not limited to, a central processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus (also known as Mezzanine bus).
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), Electrically-Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CDROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as ROM 131 and RAM 132. A basic input/output system 133 (BIOS) containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 1 illustrates operating system 134, application programs 135, other program modules 136, and program data 137. RAM 132 may contain other data and/or program modules.
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk156, such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the example operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
The drives and their associated computer storage media discussed above and illustrated in FIG. 1 provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 1, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus 121, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).
A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to monitor 191, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 1 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
A computer 110 or other client device can be deployed as part of a computer network. In this regard, the present invention pertains to any computer system having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units or volumes. An embodiment of the present invention may apply to an environment with server computers and client computers deployed in a network environment, having remote or local storage. The present invention may also apply to a standalone computing device, having programming language functionality, interpretation and execution capabilities.
Example Embodiments
FIG. 2 is block diagram of an example system 200 for using a USB host controller security extension for controlling changes in and auditing USB topology, according to the invention. The system 200 may be the computer 110 of FIG. 1 and may generally be divided into USB related hardware 250, a trusted execution environment 220, and an area outside of the trusted execution environment 211.
The hardware 250 includes a USB host controller chipset 255 with a hardware security extension (SE) 265, and a USB topology 280. The USB host controller chipset 255 is a hardware component to which USB devices are or may be attached. The USB host controller chipset 255 includes several ports 282 that are referred to as root ports or root hub ports. USB related data sent from, for example, a USB device driver to an associated USB device in the USB topology 280 is delivered by the USB host controller chipset 255. Likewise data sent from a USB device in the USB topology 280 to its device driver is delivered by or via the USB host controller chipset 255.
The USB topology 280 includes USB devices that are connected downstream from the USB host controller chipset 255. The USB topology 280 may also be referred to as a bus topology. The USB topology 280 contains two types of USB devices, USB hubs and USB functions. USB hubs are devices that have ports to which either hubs or functions may be connected. A USB function is a device that provides certain functionality, such as a web camera or a printer. The USB topology 280 is rooted at the ports 282 on the USB host controller chipset 255. The ports 282 are grouped together and are generally referred to as a root hub.
The SE 265 is a hardware device located on the USB host controller chipset 255 or between the USB host controller chipset 255 and the USB topology280. The SE 265 monitors the communication traffic between devices in the USB topology 280 and the USB host controller chipset 255. The host controller chipset 255 may not be aware of the existence of the SE 265 and therefore, the SE 265 may block USB packets that the USB host controller chipset 255 sends to USB devices in the USB topology 280 as well as block or divert data that a USB device sends to the USB host controller chipset255.
The SE 265 may include an SE buffer 275, which is a memory region to which data coming from a USB device in the USB topology 280 can be diverted. Because the SE buffer 275 may only be accessible by trusted software executing in the trusted execution environment 220, software running outside of the trusted execution environment 220 may not be able to access USB data diverted to the SE buffer 275. Also, software running outside the trusted execution environment 220 may not be able to insert USB data into the SE buffer 275 to deceive the system into believing that data was actually generated by a trusted input device.
The SE 265 additionally may include an SE programmable interface 270. Trusted software thus may be able to control the operation of the SE 265through the programmable interface 270. Trusted software may instruct the SE 265 to dispose of data sent from or to the USB topology 280 in a particular manner. For example, trusted software may instruct the SE 265 through the SE programmable interface 270 to copy contents of a data phase of a command to the SE buffer 275 when the command is sent to a particular device address. Thus the trusted software may be able to read a device's USB descriptor and be certain that data has not been, for example, tampered with, snooped, or spoofed.
The SE programmable interface 270 includes SE allow logic 277. The SE allow logic 277 is a subset of the SE programming interface using which trusted software can control the hardware behavior with regard to an allow policy. The allow policy dictates which USB commands are and are not "allowed" to be sent through the SE 265. In this way, trusted software can use the SE allow logic 277 to adjust behavior based on certain rules described herein.
The area outside of the trusted execution environment 211 may generally include software for controlling and communicating with the USB-related hardware 250. The area outside of the trusted execution environment 211 may include a host controller driver (HCD) 210 and USB device drivers 205. The HCD 210 is a software module responsible for interfacing with the USB host controller chipset 255. The HCD 210 communicates with the USB host controller chipset 255 through a hardware interface exposed by the USB host controller chipset 255. The HCD 210 also exposes an interface that the drivers 205 running on the system 200 can utilize for communicating with their corresponding devices.
Each of the USB devices in the USB topology 280 typically is controlled by program code executed on the system 200. The program code may be grouped into software modules, and each software module may control a USB device. The software modules are the USB device drivers 205. Different USB devices are controlled by different USB device drivers. For example, a hub driver 208 is a software module controlling a USB hub. A keyboard driver 207 is a software module controlling a keyboard. For the most part, these drivers are loaded such that the driver hierarchy matches the USB topology 280. Therefore, as USB devices are added to or removed, the appropriate drivers are loaded onto the system 200 or unloaded from the system 200.
The trusted execution environment 220 may be isolated from the area outside of the trusted execution environment 211 for security related reasons. Security policies are implemented or applied to program code, memory, and any other entities within the trusted execution environment 220 to ensure that it remains isolated and secure. The isolation of software running in the trusted execution environment 220 is performed using processor support so that the trusted execution environment is protected from software attacks. Software running in the trusted execution environment 220 is generally referred to as trusted software.
One piece of trusted software within the trusted execution environment 220 is the SE driver 225. The SE Driver 225 is a software module for controlling the SE 265. The SE driver 225 runs in the trusted execution environment 220 and therefore has access to the SE programmable interface 270. The SE driver 225 in the trusted execution environment 220 obtains information about the USB topology 280 and USB traffic generated by the USB device drivers 205.
The SE driver 225 includes a trusted audit manager 230 and allow policy software 240. The trusted audit manager 230 is a software module that implements an audit of the USB topology 280. Because the trusted audit manager 230 runs in the trusted execution environment 220, it has access to the SE 265. The trusted audit manager 230 interacts with other components when auditing the USB topology 280, including the HCD 210 and a trusted UI engine 235. The trusted UI engine 235 is a module within the trusted execution environment 220 responsible for displaying UI in the trusted execution environment 220. UI elements displayed by the trusted UI engine 235 are protected from tampering by an adversary and are generally combined with the system's trusted input elements when establishing a trusted path.
Along with the trusted audit manager 230, the SE driver 225 additionally includes the allow policy software 240. The allow policy software 240 is a module that utilizes the SE allow logic 277 programmable interface. This software module runs in the trusted execution environment 220 and therefore has access to the SE 265. The HCD 210 interacts with the allow policy software 240 before sending any USB commands because the SE allow logic277 may be programmed such that specific commands are blocked unless "allowed" to go through by the allow policy software 240.
The trusted execution environment 220 additionally may include a trusted topology map 237. The purpose of the trusted audit manager 230 is to verify that a topology map obtained from the HCD 210 matches the actual USB topology 280. The trusted topology map 237 is an "audited" topology; that is, it is the topology that the trusted audit manager 230 ends up with once the audit process is completed successfully. Therefore, the trusted topology map237 matches the actual USB topology 280.
FIG. 3 is a flow diagram of an example method 300 for controlling delivery of USB commands to USB devices according to the invention. At step 310, the HCD 210 may prepare to send a command to a USB device in the USB topology 280. Because neither the host controller 260 nor the HCD 210 has control over the SE allow logic 277, the HCD 210 does not know whether the USB command it is about to send will be blocked by the SE 265. Therefore, at step 315, the HCD 210 informs the allow policy software 240 of the command about to be sent. At step 320, the allow policy software 240scrutinizes the command to decide whether to allow the command to be sent. If at step 325, the allow policy software 240 concludes that the command can go through to the applicable device in the USB topology 280 without programming the SE 265 to "allow" the command, then the allow policy software 240, at step 330, instructs the HCD 210 to send the command.
If at step 325, the allow policy software 240 determines that the SE allow logic 277 should be programmed to allow the command to go through, then at step 335, the allow policy software 240 determines if the command is allowed under the circumstances and consistent with a predetermined security policy. If the command is allowed to be sent to the device, then at step 340, the allow policy software 240 tunes the settings of the SE allow logic 277 so that the command can go through and instructs the HCD 210 to send the command. For example, the SE allow logic 277 can be programmed such that a Set_Address command going to device address 0 (which is the default address) on the host controller port number 3 can go through. If at step 335, the allow policy software 240 determines that the command is not allowed through to the device, then the SE allow logic 277 is programmed to block the command and the HCD 210 is instructed not to send the command.
It is understood that it is possible for malicious software to obtain data transferred between the allow policy software 240 and the HCD 210 in the area outside the trusted execution environment 211. An adversary could cause the HCD 210 to perform an operation that is different than the instructions of the allow policy software 240. For example, when the allow policy software 240 instructs the HCD 210 that a certain command cannot be sent to the device, malicious software can cause the HCD 210 to send the command anyway. Because the allow policy software 240 has already programmed the SE allow logic 277 to block the command, however, the hardware will prevent the command from being sent.
Substitution attacks can be mitigated if the USB topology 282 remains accurate. As described herein, a substitution attack involves substituting an illegitimate USB device for a legitimate device without the system recognizing that a substitution occurred. Keeping track of the USB topology 280 by interacting with the HCD 260 alone may not ensure trustworthiness because a malicious driver can interfere with this interaction. Using a system with an SE 265 and a trusted execution environment 220 makes it possible to maintain a topology map that matches the physical bus topology 280.
To properly track changes to the USB topology 280, the SE allow logic 277 may be programmed by the trusted software such as the SE driver 225 or the allow policy software 240 contained in the SE driver 225. This may ensure that certain rules are enforced by the SE 265. One such rule is that any USB command sent to the default address must go through the allow policy software 240 so that the hardware of the SE allow logic 277 can be programmed to "allow" the command to go through. A second rule is that a USB command sent to a hub in the USB topology 280 goes through the allow policy software 240 so that the SE allow logic 277 can be programmed to "allow" the command to go through. By applying these and any other appropriate rules, USB commands that might have an impact on the USB topology 280 are evaluated and "allowed" by the allow policy software 240.
The allow policy software 240, therefore, infers a state of the actual USB topology 280 by monitoring the relevant USB commands. In this way, the allow policy software 240 will know when there has been a physical change (i.e., when a USB device is either plugged in or out of a port) to the USB topology280.
The allow policy software 240 monitors and detects topology changes differently, depending on the type of change. For example, in one embodiment of the invention, a USB device may be attached to an external hub port. When this happens, the allow policy software 240 may look at a "Port_Reset" or similar command that the hub driver 206 sends to the hub device in the USB topology 280. Later on, when the allow policy software 240 sees a command sent to the default address (address 0), it knows that the device at the default address is connected to the hub that previously reset its port.
In an alternative embodiment of the invention, a USB device may be detached from an external hub port. The allow policy software 240 may not immediately detect this, as the hub driver 208 may not send any USB commands to its hub when it detects that a device was disconnected. When a USB command that queries the port's status, however, is sent to the hub, the allow policy software 240 can detect that the status of one of the ports changed, and it can therefore infer that whatever was connected to that port before is gone.
In yet another embodiment, a device may be attached to a root hub port. The allow policy software 240 will evaluate a USB command sent to the default address (address 0). At that point, the host controller chipset 255 is queried for its root ports' status. If one of the ports was reset, this means that the newly attached device is connected to that port. It is understood that the allow policy software 240 queries the host controller chipset 255 using the SE programmable interface 270, so the operation is trustworthy.
Likewise, when detaching a device from a root hub port, the allow policy software 240 may not immediately detect the change until a device is connected to that port, in which case the steps outlined with regard to attaching a device to the root hub are performed.
Because the USB topology 280 is dynamic, the allow policy software 240 may reprogram the SE allow logic 277 when changes in the USB topology280 require the settings to change. This generally happens when hubs are added to or removed from the USB topology 280. The SE allow logic 277 is updated with the hub addresses so that when a USB command is sent to a hub, it is blocked by the SE allow logic 277 unless it was previously "allowed."
FIG. 4 is a flow diagram of an example method 400 for controlling delivery of USB commands regarding cryptographic keys according to the invention. The method 400 is described with regard to using an allow policy for key exchange. At step 410, the SE allow logic 277 is programmed such that any USB command sent to a USB device from which a key should be read is blocked unless the command is specifically "allowed" by the allow policy software 240. Once the SE allow logic 277 is programmed, any USB commands sent to the device are evaluated by the allow policy software 240. At step 420, the allow policy software 240 scrutinizes the command after the USB command for fetching the key is sent to the USB device.
At step 430, the allow policy software 240 determines that the command is allowed and, it programs the SE allow logic 277 at 440 to allow the command through to the topology 280 and the applicable device. If the allow policy software 240 determines alternatively that the command may not be sent, then the hardware of the SE 265 (e.g., the SE allow logic 277) is not altered and, if malicious software attempts to send the command, the command will be blocked by the hardware. At step 450, the allow policy software 240 sends the command to the HCD 210 for delivery to the device. Additionally, the hardware is instructed to divert any data returned from the device to the SE buffer 275 and to send the USB host controller chipset 255substitute data so that the transaction can be completed properly. At step 460, trusted software executing in the trusted execution environment 220 can access the SE buffer 275 and read the key sent through the USB host controller chipset 255 by the device. Because the data can only be read by trusted software, malicious software running on the host 200 does not have access to it.
FIG. 5 is a flow diagram of an example method 500 for auditing a USB topology 280, according to the invention. The USB topology audit, whether completed through the example method 500 or other methods, verifies that the USB topology managed by the HCD 210 matches the actual USB topology 280. Because the HCD 210 is in the area outside the trusted execution environment 211, the topology map it manages may not be trustworthy. Through the method 500, the trusted audit manager 239 maintains a trusted topology map 237 with information such as to which hub a certain device is connected. In addition, the USB topology audit method 500 detects input devices, such as keyboards or mice, in the actual USB topology 280 and marks the input devices as trusted input devices after appropriate verification.
At step 510, the trusted audit manager 230 fetches the topology map managed by the HCD 210. After the trusted audit manager 230 obtains the map, it sends USB commands to all the devices in the actual USB topology 280 at step 520. The commands ensure that the type of each device matches information in the topology map fetched from the HCD 210. For example, when a USB hub is found in the actual USB topology 280, a USB command is sent to that hub to fetch certain USB descriptors. At step 530, descriptors or any other information sent by each device to the trusted audit manager 230are scrutinized to ensure that the descriptors match the type of device indicated on the topology map. It will be understood that, to fetch the descriptors in a trustworthy fashion, the trusted audit manager 230 programs the SE 265 so that the returned descriptors are put in the SE buffer 275. Because the SE buffer 275 is only accessible to trusted software, such as the trusted audit manager 230, the descriptors are protected from malicious software running outside the trusted execution environment 220.
If at step 540, the trusted audit manager 230 determines that the descriptor for a device does not match the type of device indicated on the topology map, then at step 550, the audit fails and appropriate notifications are made. If at step 540, the trusted audit manager 230 determines that the descriptors match, then the trusted audit manager 230 next sends a command to resume all hub ports at step 560. The trusted audit manager 230resumes suspended hub ports to ensure that the USB topology 280 has not been attacked through use of a USB device that is hidden by suspending a port on a hub to which the device is connected. At step 565, the trusted audit manager sends appropriate commands to ensure that the number of USB devices (i.e., hubs and functions) in the HCD's topology map equals the number of active hub ports in the USB topology 280. Additionally, to determine the number of active ports on the root hub of the host controller chipset 255, the trusted audit manager 230 accesses certain registers within the SE 265registers that contain this information. If, at step 570, the number of active ports of the hubs is not equal to the number of USB devices, then the HCD's topology map does not match the actual USB topology 280. Thus, the audit fails at step 575 and appropriate actions are taken.
If the number of active ports is equal to the number of USB devices, the trusted audit manager 230 next performs steps to secure appropriate input devices. The trusted audit manager secures input devices that generate input data that the SE 265 diverts to the SE buffer 275. Because the trusted audit manager 230 can differentiate between hubs and functions in the USB topology 280, at step 580, it further examines the USB descriptors of the functions to find all the input devices. The SE 265 is programmed to divert data generated by the input devices to the SE buffer 275 for scrutiny by the trusted execution environment 220. It is understood, however, that determining devices that are, for example, keyboards or mice may not be enough, as USB devices may be maliciously programmed to look like input devices.
Therefore, the trusted audit manager 230 requests a user to actually generate data from the device in question. To examine user-provided input, at step585, the trusted audit manager 230 asks the trusted UI engine 230 to display a trusted UI element on a display screen of the system 200. The trusted UI element requests the user to, for example, type a specific word or sequence of characters with the keyboard or to move the mouse to a certain location and clicking a mouse button. At step 590, the trusted audit manager 230 access the SE buffer 275 and examines data generated by the device to verify that the user generated the appropriate data. If the verification fails, then the device is no longer trusted and at step 596, the SE 265 is programmed so that input generated by the device is not diverted to the SE buffer 275. If the verification shows a match, then at step 595, the SE 265remains programmed to divert data generate by the trusted device to the SE buffer 275.
FIG. 6 is a block diagram of an example system 600 for auditing a USB topology, according to the invention. The system 600 includes the trusted audit manager 230, USB host controller chipset 255 comprising a root hub 610, described with regard to FIG. 2, USB hubs 681, 685, 686, and USB functions682, 683, 684, 687, 688. As described with regard to the method 500, after the trusted audit manager 230 fetches the HCD's topology map, the trusted audit manager 230 sends commands to the hubs 610, 681, 685, 686 and functions 682, 683, 684, 687, 688 based on their USB addresses to fetch descriptors. This is completed after the SE 265 is programmed to divert data returned from the USB devices to the SE buffer 275. The trusted audit manager 230 accesses the SE buffer 275 and obtains the descriptors of each device in order to make sure that the device type is correct. For example, when a Get_Descriptor command is sent to USB hub #1 681, the returned descriptor should indicate that the device is indeed a hub. The trusted audit manager 230 then resumes the ports on the hubs 681, 685, 686 to ensure no ports are suspended. This is done by sending the appropriate USB command to the hubs 681, 685, 686.
The trusted audit manager 230 counts the active ports on all the hubs 610, 681, 685, 686 in the topology. In the system 600, the trusted audit manager230 determines that eight ports are active, the respective ports for the three hubs 681, 685, 686 and the five functions 682, 683, 684, 687, 688. Assuming that the topology map fetched from the HCD 210 contains information indicating that eight ports are active, then the audit is successful.
Finally, the trusted audit manager 230 secures the input devices, namely a keyboard 682 and a touchpad pointed device 688. The trusted audit manager 230 programs the SE 265 to divert input data from these devices 682, 688 to the SE buffer 275. The trusted UI engine 230 is asked to display a certain UI element using which the user should generate some input data using these devices 682, 688. The trusted audit manager accesses the SE buffer 275 and examines the data generated by the devices 682, 688. If the data matches what the trusted audit manager expected, then it is concluded that a user generated input using the devices 682, 688, as opposed to a malicious device generating the input. The devices 682, 688 are properly secured using the SE 265 hardware. If there is a mismatch, then it might mean that an adversary has manipulated a programmable USB device and made it look like, for example, the keyboard 682. In this case, the trusted topology audit fails and the SE 265 will not be programmed to treat these devices 682, 688 as "trusted."