Protecting computer systems from malicious USB devices via a USB firewall

BACKGROUND

0001This invention relates generally to serial buses and, more specifically, relates to protecting computer systems from USB devices.

0002This section is intended to provide a background or context to the invention disclosed below. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived, implemented or described. Therefore, unless otherwise explicitly indicated herein, what is described in this section is not prior art to the description in this application and is not admitted to be prior art by inclusion in this section. Abbreviations and acronyms used in this document and/or the drawings are defined below, prior to the claims.

0003Universal serial bus (USB) connections and devices have become ubiquitous, and for good reason: these allow users to connect many different devices through a common connection and interface. For instance, a user can connect peripherals such as pointing devices (e.g., trackballs or mice), audio cards or digital-to-analog converters, keyboards, memories such as memory sticks or hard drives, cameras, cellular phones, and the like to hosts such as computers, all with a single physical interface.

0004The pervasive availability of USB connectivity throughout computer and mobile peripherals, however, makes USB an increasingly appealing attack vector. In particular, USB devices, upon their activation when connected (plugged in) to a host machine, run a piece of software (e.g., firmware) that is responsible with interacting with the host machine using the USB protocol over the bus. USB devices (or the firmware installed on the devices) may be subverted, which enables a variety of threats. For example, (1) a secondary USE device may announce itself in parallel to the actual primary device, or (2) the USB firmware may attempt to exploit vulnerabilities in the software stack interacting with the USB bus (such as lower- and upper-level drivers in the kernel, and applications using the device). Recently successful examples of such exploits have been demonstrated in practice.

0005One successful example is referred to as a schizophrenic USB device. A schizophrenic USB device registers as an additional input device, like a keyboard, alongside its expected functionality. The mimicked keyboard would then commence sending keystrokes to the host machine to spawn a shell and open, e.g., a network connection to a remote server to exfiltrate data or provide advanced remote command and control over the host. Such attacks are facilitated by dedicated, programmable devices like the Rubber Ducky (a device which resembles a regular USB flash drive). Using Rubber Ducky, it is possible to load a “trusted” root certificate into a victim's machine to launch a MitM attack, e.g., decrypting SSL traffic. In a MitM attack, an attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. In this example, the MitM attack is between the Rubber Ducky and the victim's machine.

0006Other successful examples are USB delivered exploits. This refers to USB devices that exploit parts of the operating system, for example bugs in the USB driver stack. These bugs can be found by fuzzing the USB driver stack or applications that handle USB “traffic”. One example is the “USB Stick of Death” that exploits a vulnerability in the Windows NTFS driver.

0007Consequently, while USB devices are undoubtedly beneficial, they have also become more dangerous. It is currently difficult to prevent or ameliorate attacks by misbehaving USB devices.

BRIEF SUMMARY

0008This section is intended to include examples and is not intended to be limiting.

0009In an exemplary embodiment, a method comprises intercepting universal serial bus (USB) traffic between a USB device and a computer system, and determining whether the USB device has previously had a policy associated with it as to whether USB traffic from the device should be blocked, allowed, or sanitized. The method further comprises, in response to not having a previous policy for the USB device, requesting that a user be prompted to provide a policy of one of block, allow, or sanitize for the USB device. The method additionally comprises, in response to a user-provided policy, performing one of blocking the traffic, allowing the traffic, or sanitizing the traffic between the USB device and the computer system.

0010In another exemplary embodiment, an apparatus comprises: one or more memories comprising computer readable code stored thereon; one or more processors, the one or more processors configured, in response to retrieval and execution of at least a portion of the computer readable code, to cause the apparatus to perform operations comprising: intercepting universal serial bus (USB) traffic between a USB device and a computer system; determining whether the USB device has previously had a policy associated with it as to whether USB traffic from the device should be blocked, allowed, or sanitized; in response to not having a previous policy for the USB device, requesting that a user be prompted to provide a policy of one of block, allow, or sanitize for the USB device; and in response to a user-provided policy, performing one of blocking the traffic, allowing the traffic, or sanitizing the traffic between the USB device and the computer system.

0011In a further exemplary embodiment, a computer program product comprises a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a device to cause the device to perform operations comprising: intercepting universal serial bus (USB) traffic between a USB device and a computer system; determining whether the USB device has previously had a policy associated with it as to whether USB traffic from the device should be blocked, allowed, or sanitized; in response to not having a previous policy for the USB device, requesting that a user be prompted to provide a policy of one of block, allow, or sanitize for the USB device; and in response to a user-provided policy, performing one of blocking the traffic, allowing the traffic, or sanitizing the traffic between the USB device and the computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

0012In the attached Drawing Figures:

0013<figref idref="DRAWINGS">FIG. <b>1</b></figref>, which includes <figref idref="DRAWINGS">FIGS. <b>1</b>A and <b>1</b>B</figref>, contains block diagrams of a possible and non-limiting exemplary embodiment (e.g., “embodiment 1”), where <figref idref="DRAWINGS">FIG. <b>1</b>A</figref> presents a logical setup for a system including a low-level USB firewall software component as part of a user PC (host), and <figref idref="DRAWINGS">FIG. <b>1</b>B</figref> illustrates possible internal configuration of the elements of the system in <figref idref="DRAWINGS">FIG. <b>1</b>A</figref>;

0014<figref idref="DRAWINGS">FIG. <b>2</b></figref>, which includes <figref idref="DRAWINGS">FIGS. <b>2</b>A and <b>2</b>B</figref>, contains block diagrams of another possible and non-limiting exemplary embodiment (e.g., “embodiment 2”), where <figref idref="DRAWINGS">FIG. <b>2</b>A</figref> presents a logical setup for a system including a USB device separate from a user PC (host), and <figref idref="DRAWINGS">FIG. <b>2</b>B</figref> illustrates possible internal configuration of the elements of the system in <figref idref="DRAWINGS">FIG. <b>2</b>A</figref>;

0015<figref idref="DRAWINGS">FIG. <b>3</b></figref> is a logic flow diagram for protecting computer systems from malicious USB devices via a USB firewall, and illustrates the operation of an exemplary method, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments; and

0016<figref idref="DRAWINGS">FIG. <b>4</b></figref>, which includes <figref idref="DRAWINGS">FIGS. <b>4</b>A and <b>4</b>B</figref>, contains block diagrams of a possible and non-limiting exemplary embodiment, where <figref idref="DRAWINGS">FIG. <b>4</b>A</figref> presents USB traffic rerouting in a system from a user PC (host) into a sandbox, and <figref idref="DRAWINGS">FIG. <b>4</b>B</figref> illustrates routing USB traffic in the system from <figref idref="DRAWINGS">FIG. <b>4</b>A</figref> from the sandbox into the user PC.

DETAILED DESCRIPTION OF THE DRAWINGS

0017The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. All of the embodiments described in this Detailed Description are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention which is defined by the claims.

0018Systems and methods are described to construct a software-based or hardware-based middle layer (referred to as a USB firewall) that has the ability to intercept and inspect connecting/connected USB device traffic on a USB bus, reroute the traffic (e.g., to a sandbox system), drop the traffic, or allow the traffic. The disclosed systems and methods prevent unauthorized devices (and corresponding firmware) from interacting directly with the host machine; rather traffic is quarantined and only upon successful verification and approval is the traffic directed to the host machine. Moreover, the described systems and methods may, in certain exemplary embodiments, enable end-users to inspect the USB devices on the bus, and selectively allow or disallow interaction with the host machine.

0019There are two primary exemplary embodiments described herein: 1. A low-level USB firewall software-based component; and 2. A separate device. In exemplary embodiment 1, USB bus traffic is intercepted at a low level and a firewall functionality is established on the host system. In exemplary embodiment 2, a separate dedicated device with USB connectors is implemented that offers the functionality of a firewall. All USB devices would typically be connected to this dedicated device.

0020A fundamental advantage of the systems and methods disclosed herein is an increased layer of protection and practicality of these solutions compared with existing methods and systems. Moreover, the techniques presented herein allow for a number of extensions beyond simple “allow and deny”, such as rerouting of USB traffic into a sanitizer system first, USB traffic behavior analysis, selective filtering, and the like. Lastly, the techniques presented herein are not limited to a specific type of USB device (such as not being only limited to mass storage devices).

0021As far as transparency of the firewall is concerned, the firewall will operate transparently to the devices (i.e., connected devices are unable to tell whether they are connected to a host system directly or a USB firewall device is located in-between). The firewall is however not transparent to the host system, i.e., the host system knows that a firewall is connected (e.g., due to a control channel established). The firewall also may not be transparent to a user of a computing system to which the user has attached a USB device.

0022<figref idref="DRAWINGS">FIGS. <b>1</b> and <b>2</b></figref> compare the two embodiments: a software-based USB firewall (“embodiment 1”, illustrated in <figref idref="DRAWINGS">FIG. <b>1</b></figref>) and hardware USB firewall (“embodiment 2”, illustrated in <figref idref="DRAWINGS">FIG. <b>2</b></figref>). <figref idref="DRAWINGS">FIG. <b>1</b></figref> illustrates a software-based USB firewall <b>200</b>, USB firewall <b>200</b>-<b>1</b>, while <figref idref="DRAWINGS">FIG. <b>2</b></figref> illustrates a physically separate device of a USB firewall device <b>200</b>-<b>2</b> for USB firewall <b>200</b>.

0023Referring now to <figref idref="DRAWINGS">FIG. <b>1</b></figref>, which includes <figref idref="DRAWINGS">FIGS. <b>1</b>A and <b>1</b>B</figref>, this figure contains block diagrams of a possible and non-limiting exemplary embodiment (e.g., “embodiment 1”). Specifically, <figref idref="DRAWINGS">FIG. <b>1</b>A</figref> presents a logical setup for a system <b>100</b> including a low-level USB firewall software component as part of a user PC (host), and <figref idref="DRAWINGS">FIG. <b>1</b>B</figref> illustrates possible internal configuration of the elements of the system in <figref idref="DRAWINGS">FIG. <b>1</b>A</figref>.

0024In <figref idref="DRAWINGS">FIG. <b>1</b>A</figref>, a user has attached a user USB device (D) <b>195</b> to the user PC <b>105</b>-<b>1</b>, typically referred to as a host (e.g., of the USB bus). The elements in <figref idref="DRAWINGS">FIG. <b>1</b>A</figref> are logical and represent software and data flow. The software will be executed by hardware to cause the user PC <b>105</b>-<b>1</b> to perform operations described herein for protecting computer systems from malicious USB devices via a USB firewall. The user USB device (D) <b>195</b> is going to communicate with application <b>141</b>, which may be any application on the computer system. The user USB device (D) <b>195</b> may have a USB port <b>108</b> and the user PC <b>105</b>-<b>1</b> may have a corresponding USB port <b>109</b>. For instance, the USB port <b>108</b> could be a physical male USB connector and the USB port <b>109</b> could be a physical female USB connector, and the data path <b>280</b>-<b>1</b> would be formed over the two USB ports <b>108</b>, <b>109</b>. In another example, the USB port <b>108</b> is a female USB connector and the data path <b>280</b>-<b>1</b> is formed in part using a USB cable between the two USB ports <b>108</b>, <b>109</b>. Other configurations are also possible.

0025The user PC <b>105</b>-<b>1</b> is represented as having a kernel space <b>101</b> and a user space <b>102</b>. The kernel space <b>101</b> includes the kernel (not shown), which is the central module of an operating system (OS). The kernel is the part of the operating system that loads first, and the kernel typically remains in main memory. The kernel space is part of the kernel. The software-based USB firewall <b>200</b>-<b>1</b> runs in the kernel space <b>101</b> and thus runs at a low level, e.g., with privileged access to system resources and in protected memory. The kernel space <b>101</b> also includes a generic USB driver <b>136</b>. The software-based USB firewall <b>200</b>-<b>1</b> comprises a USB firewall driver <b>210</b> and controller <b>255</b>, a USB packet filter <b>215</b>, and a USB sanitizer <b>220</b>.

0026The user space <b>102</b> comprises a USB firewall UI <b>205</b> and an application <b>141</b>. The user space <b>102</b> is a memory area where application software and some drivers execute. An OS separates the kernel space <b>101</b> and user space <b>102</b>. The generic USB driver <b>136</b> interfaces with the application <b>141</b>, which does not “know” there is a firewall <b>200</b>-<b>1</b>. The generic USB driver <b>136</b> has the proper programming to interface with the user USB device <b>195</b>. That is, the generic USB driver <b>136</b> is a driver that is used to understand a given device's operations (e.g., when one connects a storage device or a web cam, separate drivers are loaded that enable communication of applications with the device over a proprietary channel). For instance, the generic USB driver <b>136</b> can act as an interface between the application <b>141</b> and any USB device, such as a keyboard, webcam, digital-to-analog converter, smartphone, storage device, and the like.

0027In this example, the USB firewall UI <b>205</b> and the USB firewall <b>200</b>-<b>1</b> are additions to a user PC. The data path <b>280</b>-<b>1</b> (between the user USB device (D) <b>195</b> and the USB packet filter <b>215</b>) and the data path <b>280</b>-<b>2</b> (between the USB packet filter <b>215</b> and the USB sanitizer <b>220</b>) contain untrusted USB traffic. The data path <b>285</b>-<b>1</b> (between the USB packet filter <b>215</b> and the generic USB driver <b>136</b>) and data path <b>285</b>-<b>2</b> (between the USB sanitizer <b>220</b> and the generic USB driver <b>136</b>) contain filtered USB traffic. The path <b>290</b>-<b>1</b> between the USB firewall driver <b>210</b>/controller <b>255</b> and the USB firewall UI <b>205</b> is a control channel. The path <b>290</b>-<b>2</b> between the USB packet filter <b>215</b> and the USB firewall driver <b>210</b>/controller <b>255</b> is also a control channel. The path <b>295</b> between the generic USB driver <b>136</b> and the application <b>141</b> includes both data and command.

0028The USB firewall driver <b>210</b> implements low-level drivers enabling the USB firewall <b>200</b>-<b>1</b> to communicate with the user USB device <b>195</b>, and the controller <b>255</b> controls the overall operation of the USB firewall <b>200</b>-<b>1</b>. The USB packet filter <b>215</b> filters packets between the user USB device <b>195</b> and the generic USB driver <b>136</b>, such as forwarding packets between the two devices <b>195</b>, <b>136</b>, not forwarding (e.g., dropping) packets between the two devices <b>195</b>, <b>136</b>, or sending packets to the USB sanitizer <b>220</b> for sanitization. The USB packet filter <b>215</b> uses rules <b>151</b> for determining what should be filtered or sanitized. There could be multiple sets of rules <b>151</b>, e.g., one set of rules <b>151</b> per user USB device <b>195</b>. For instance, there could be one set of rules <b>151</b> for a keyboard, one set of rules <b>151</b> or a webcam, one set of rules for a storage device, and the like. If a packet is or packets are to be sanitized, the USB packet filter <b>215</b> sends the packet or packets to the USB sanitizer <b>220</b>.

0029The USB sanitizer <b>220</b> then performs sanitization of the packet or packets based. on an additional set of rules <b>152</b>, which again may have multiple sets of rules <b>152</b> based on the user USB device <b>195</b>. The sanitization could involve changing or translating certain commands or requests that are known to be problematic into other commands or requests that are known to be good, or stripping out certain commands or requests, or other actions as are known.

0030The functions of the USB packet filter <b>215</b> and the USB sanitizer <b>220</b> may be combined if desired, and in addition or alternatively, the rules <b>151</b> and <b>152</b> may be combined. In an example, each of the rules <b>151</b>, <b>152</b> may be stored as part of the corresponding USB packet filter <b>215</b> or USB sanitizer <b>220</b>, or may be stored as part of a single database <b>163</b>, e.g., accessible by both the USB packet filter <b>215</b> or USB sanitizer <b>220</b>. The database in <figref idref="DRAWINGS">FIGS. <b>1</b>A and <b>1</b>B</figref> is illustrated as being part of the memory <b>145</b>, which may be a cache memory and may be volatile or non-volatile, depending on implementation. The rules <b>151</b>, <b>152</b> may be downloaded, e.g., from a computer system on the cloud or the Internet, provided with the USB firewall <b>200</b>-<b>1</b>, and the like. It is further noted that these are characterized as “rules”, but these may also be characterized as “policies” or “verdicts”, and the term used may vary by which company implements these. In this document, the term “rules” is meant to encompass instructions for one or both of filtering and sanitizing USB traffic.

0031With reference to <figref idref="DRAWINGS">FIG. <b>1</b>B</figref>, the computer system <b>105</b>-<b>1</b>, in this example, comprises one or more memories <b>145</b>, one or more processors <b>110</b>, USB circuitry <b>131</b>, display circuitry <b>175</b>, and one or more user input interface(s) (I/Fs), all interconnected through one or more buses <b>146</b>. The buses <b>146</b> may be address, data, and/or control buses and may be implemented using many different techniques, such as traces on a board, metallization in a semiconductor, and the like. The one or more memories <b>145</b> comprise computer readable code <b>185</b> comprising the kernel space <b>101</b> and the user space <b>102</b>. The kernel space <b>101</b> comprises a driver stack <b>171</b>, which includes the generic USB driver <b>136</b>, and the USB firewall <b>200</b>-<b>1</b>. The computer system <b>105</b> may also be connected to one or more displays <b>176</b>, driven by the display circuitry <b>175</b>. The computing system <b>105</b> may include a display <b>176</b>, such as if the computer system <b>105</b> is a smartphone or tablet. The one or more user input interfaces <b>177</b> comprise circuitry to allow a user to provide input to the computer system <b>105</b>-<b>1</b>, such as via a wireless interface (e.g., Bluetooth, which is a short range wireless connectivity standard) or a wired interface to input devices (not shown) such as a mouse, keyboard, and the like.

0032The user space <b>102</b> comprises an application layer <b>140</b> (e.g., including the application <b>141</b> and possibly other applications) and USB firewall <b>205</b>, which is represented as USB firewall UI program <b>205</b>-<b>1</b> and a USB firewall UI <b>205</b>-<b>2</b> on the display(s) <b>176</b>. The USB firewall UI program <b>205</b>-<b>1</b> causes the USB firewall UI <b>205</b>-<b>2</b> to be presented on the display <b>176</b>, as illustrated in part by reference <b>196</b>.

0033The one or more processors <b>110</b> can be any processors suitable to the technical environment, such as single or multiple core processors, low power processors such as Advanced RISC Machine (ARM) processors, digital signal processors, special-purpose processors, and the like. The term “processor” is also meant to encompass any circuitry that can perform processing functions, such as a very large scale integrated circuit, programmable logic devices, and the like. The one or more processors <b>110</b>, in response to executing the computer readable code <b>185</b>, cause the computer system <b>105</b> to perform the operations described herein. In another example, part or all of the computer readable code <b>185</b> could be implemented in hardware, such as in circuitry <b>115</b>. The circuitry <b>115</b> could be implemented as part of an integrated circuit, as part of a programmable gate array, as part of a USB hub, as part of USB circuitry such as a USB controller, and the like. In this example, the circuitry <b>115</b> is considered to contain the one or more processors <b>110</b> and the one or more memories <b>145</b>, but only part of this functionality may be implemented by the circuitry <b>115</b>, and other functionality implemented by a separate processor <b>110</b> and memory <b>145</b>.

0034The one or more memories <b>145</b> may comprise any suitable memory, such as non-volatile memory comprising one or more of (e.g., programmable) read-only memory, flash memory, various types of magnetic computer storage devices (e.g., hard disk drives), optical discs, and the like. The one or more memories <b>145</b> may additionally comprise volatile memory such as random access memory (RAM), e.g., static RAM and/or dynamic RAM.

0035The USB device <b>195</b> comprises firmware <b>196</b> and data <b>107</b> and is connected via the USB bus <b>197</b> to the USB circuitry <b>131</b>. The USB circuitry <b>131</b> could include, e.g., USB controllers and corresponding USB hubs that are internal to the host <b>105</b>-<b>1</b>. The USB circuitry <b>131</b> performs known USB techniques, such as providing power for USB devices, and sending and receiving packets. The firmware <b>196</b> is used by the USB device <b>195</b> to perform actions to interface with a USB bus <b>197</b> and a host <b>105</b>. The data <b>107</b> may be stored data, such as non-volatile data on a memory stick or hard drive, or such as volatile data generated and briefly stored for sending to the host, like keyboard strokes, mouse actions, and similar events. That is, the data <b>107</b> depend on the type for the USB device <b>195</b>. The data <b>107</b> may also include packets that are used to communicate via the USB bus <b>197</b> and that package the stored data for communications.

0036The USB firewall driver <b>210</b> provides an interface between the USB packet filter <b>215</b> and the USB firewall UI <b>205</b>. The USB firewall driver <b>210</b> and the controller <b>255</b> of the firewall may be based in firmware that is executed by hardware. The USB packet filter <b>215</b> enforces a policy, such as blocking or allowing traffic. The USB sanitizer <b>220</b> sanitizes USB traffic using techniques described above. As previously described, the generic USB driver <b>136</b> is a driver that is used to understand a given device's operations (e.g., when one connects a storage device or a web cam, separate drivers are loaded that enable communication of applications with the device over a proprietary channel).

0037The USB firewall UI <b>205</b>, as a program <b>205</b>-<b>1</b> and a UI <b>205</b>-<b>2</b> created by the program <b>205</b>-<b>1</b>, allows the USB firewall <b>200</b>-<b>1</b> to interact with a user, e.g., using the display <b>176</b>. For instance, the USB firewall <b>200</b>-<b>1</b> may be configured in whole or part by the user using the UI <b>205</b>-<b>2</b>. As another example, the USB firewall program <b>205</b>-<b>1</b> may create (as part of UT <b>205</b>-<b>2</b> on display <b>176</b>) a message <b>262</b> to the user that a new USB device has been found and request the user choose whether to allow, deny or sanitize the USB device. The user could select one of the buttons on the display of Allow <b>263</b>, Deny <b>264</b> or Sanitize <b>265</b>. The user could perform the selections using any available input, such as touch using a touchscreen or a device (including a user USB device <b>195</b>) such as a keyboard, mouse, trackball, or the like. The actions taken by the USB firewall <b>200</b> in response to selection of one of these buttons are described below. Note that the buttons are merely one example and many other techniques may be used, such as pulldown menus, swiping, and the like.

0038Turning to <figref idref="DRAWINGS">FIG. <b>2</b></figref>, which includes <figref idref="DRAWINGS">FIGS. <b>2</b>A and <b>2</b>B</figref>, this figure contains block diagrams of another possible and non-limiting exemplary embodiment (e.g., “embodiment 2”). <figref idref="DRAWINGS">FIG. <b>2</b>A</figref> presents a logical setup for a system including a USB device separate from a user PC (host), and <figref idref="DRAWINGS">FIG. <b>2</b>B</figref> illustrates possible internal configuration of the elements of the system in <figref idref="DRAWINGS">FIG. <b>2</b>A</figref>. The example of <figref idref="DRAWINGS">FIG. <b>2</b></figref> uses many of the same elements in <figref idref="DRAWINGS">FIG. <b>1</b></figref>, and only the differences are described here.

0039In <figref idref="DRAWINGS">FIG. <b>2</b>A</figref>, the USB firewall <b>200</b> is illustrated as a USB firewall device <b>200</b>-<b>2</b>. The USB firewall device <b>200</b>-<b>2</b> contains similar elements to those elements in the software-based USB firewall <b>200</b>-<b>1</b>, but is physically separate from the user PC <b>105</b>-<b>2</b>. The USB firewall device <b>200</b>-<b>2</b> is between the user USB device (D) <b>195</b> and the user PC <b>105</b>-<b>2</b>. The USB firewall device <b>200</b>-<b>2</b> could have a female USB connector as port <b>111</b>, and the user USB device <b>195</b> could have a mating female USB connector as port <b>108</b>, and the user PC <b>105</b>-<b>2</b> could have a female USB connector as USB port <b>109</b>, into which a male USB connector as USB port <b>112</b> would fit. Other configurations are possible, such as having data path <b>280</b>-<b>1</b> being on one USB cable between ports <b>108</b> and <b>111</b>, and the paths <b>290</b>-<b>1</b>, <b>285</b>-<b>1</b> and <b>285</b>-<b>2</b> being carried on another USB cable between ports <b>112</b> and <b>109</b>. That is, there typically would be one USB cable (not shown) between ports <b>112</b> and <b>109</b> and carrying paths <b>290</b>-<b>1</b>, <b>285</b>-<b>1</b> and <b>285</b>-<b>2</b>. The USB firewall device <b>200</b>-<b>2</b> could be powered by the USB bus or by an external power supply. The path <b>290</b>-<b>3</b> is a control channel.

0040In this example, the separate USB firewall device <b>200</b>-<b>2</b> has controller (e.g., comprised of firmware) <b>255</b>, which provides control (once executed) of the USB firewall device <b>200</b>-<b>2</b>. The USB firewall driver <b>210</b> is in the kernel space <b>101</b> of the user PC <b>105</b>-<b>2</b>. Compared to <figref idref="DRAWINGS">FIG. <b>1</b>A</figref>, where the USB firewall driver <b>210</b> and the controller <b>255</b> are in the USB firewall <b>200</b>-<b>1</b>, in USB firewall device <b>200</b>-<b>2</b> of <figref idref="DRAWINGS">FIG. <b>2</b>A</figref>, these are split: the controller <b>255</b> is part of the USB firewall device <b>200</b>-<b>2</b> and the USB firewall driver <b>210</b> is in the user PC <b>105</b>-<b>2</b>. The database <b>163</b> is located in the example of <figref idref="DRAWINGS">FIG. <b>2</b>A</figref> in a memory <b>145</b>-<b>1</b>, which could be a volatile or non-volatile cache memory as an example.

0041In <figref idref="DRAWINGS">FIG. <b>2</b>B</figref>, this figure illustrates possible internal configuration of the elements of the system in <figref idref="DRAWINGS">FIG. <b>2</b>A</figref>. The host <b>105</b>-<b>2</b> in this example has, in the computer-readable code (CRC) <b>185</b>-<b>1</b>, the USB firewall UI <b>205</b> and the USB firewall driver <b>210</b>. The USB firewall device <b>200</b>-<b>2</b> comprises one or more memories <b>145</b>-<b>1</b>, one or more processors <b>110</b>-<b>1</b>, and one or more network (NW) interfaces (I/F(s)) <b>130</b>-<b>1</b>, all interconnected through one or more buses <b>146</b>-<b>1</b>. The buses <b>146</b>-<b>1</b> may be address, data, and/or control buses and may be implemented using many different techniques, such as traces on a board, metallization in a semiconductor, and the like. The one or more memories <b>145</b>-<b>1</b> comprise computer readable code <b>185</b>-<b>2</b> comprising the controller firmware <b>255</b>, the USB packet filter <b>215</b>, and the USB sanitizer <b>220</b>. The network interface(s) may comprise USB circuitry <b>131</b>-<b>1</b>. The one or more processors <b>110</b>-<b>1</b>, in response to executing the computer readable code <b>185</b>-<b>2</b>, cause the USB firewall device <b>200</b>-<b>2</b> to perform the operations described herein. In another example, part or all of the computer readable code <b>185</b>-<b>2</b> could be implemented in hardware, such as in circuitry <b>115</b>-<b>1</b>.

0042The database <b>163</b> may be in the memory <b>154</b>-<b>1</b> of the USB firewall device <b>200</b>-<b>2</b>, as databased <b>163</b>-<b>1</b>. Alternatively or in addition, some or all of the database <b>163</b> may reside in the host <b>105</b>-<b>2</b>. For instance, the USB firewall UT <b>205</b> could download a large database <b>163</b>-<b>2</b>, and then provide only a portion of the database, as database <b>163</b>-<b>1</b>, that corresponds to the current USB device <b>195</b>.

0043While the computer systems <b>105</b> described herein are mainly described as personal computers, these computer systems <b>105</b> may be personal computer systems, laptops, servers, smartphones, tablets, notebooks, televisions, home theater receivers, or any other device with USB capabilities.

0044Referring to <figref idref="DRAWINGS">FIG. <b>3</b></figref>, this figure is a logic flow diagram for protecting computer systems from malicious USB devices via a USB firewall. Furthermore, this figure illustrates the operation of an exemplary method, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments. The figure distinguishes activities of the user <b>305</b> (left column), hardware-based or software-based USB firewall <b>200</b> (middle column), and host system <b>105</b> (right column). Note, however, that blocks after block <b>360</b> are not performed by the user or the host but instead by the USB firewall <b>200</b>. This figure can be considered as providing a system overview.

0045Block <b>305</b> corresponds to embodiment 1, as illustrated by <figref idref="DRAWINGS">FIG. <b>1</b></figref>. In this embodiment, the user <b>305</b> installs software in block <b>307</b>, and the installed software creates the USE firewall <b>200</b>-<b>1</b> (e.g., and the USB firewall UI <b>205</b>). For instance, in the installation, the kernel module is loaded to sink all USB communication to itself. This can occur through an installation process, such as through an application installation, e.g., including an “app” such as found in stores for wireless mobile devices.

0046Blocks <b>310</b> and <b>315</b>, meanwhile, correspond to embodiment 2, as illustrated by <figref idref="DRAWINGS">FIG. <b>2</b></figref>. In block <b>310</b>, the user connects the USB firewall device <b>200</b>-<b>2</b> to the host system. In the case of the separate USB firewall device <b>200</b>-<b>2</b>, the user <b>305</b> would connect the USB firewall <b>200</b>-<b>2</b> to the host <b>105</b>. Upon connection, the firewall <b>200</b>-<b>2</b> registers (block <b>315</b>) itself at the system level. This can entail installation of the USB firewall US <b>105</b> and the USB firewall driver <b>210</b>.

0047For both embodiments, the corresponding drivers and services are loaded and enabled and the service is initialized (block <b>320</b>). The user would like to use a USB device D <b>195</b>. He or she connects the device D <b>195</b> to the USB firewall in block <b>325</b>, which for the software-based USB firewall <b>200</b>-<b>1</b> means the user <b>305</b> connects the device <b>195</b> to the system and for the hardware-based USB firewall <b>200</b>-<b>2</b>, the user <b>305</b> connects the device <b>195</b> to the USB firewall <b>200</b>-<b>2</b>. Upon connection, the USB firewall <b>200</b> acts as an interim host (e.g., host controller) and communicates with device D <b>195</b>. The device D <b>195</b> will provide its device identifier, interface, and class. This occurs in block <b>330</b>, where there is an initial communication and the USB firewall <b>200</b> identifies the device.

0048In an exemplary embodiment, for a new end-point device D <b>195</b> seen by the USB firewall <b>200</b>, a query is sent (block <b>335</b>) over the control channel (path <b>290</b>) to a host driver (e.g., USB firewall driver <b>210</b>). The host driver is the driver of the firewall <b>210</b> on the host (i.e., the endpoint on the host <b>105</b>-<b>2</b> of the established management channel between the firewall controller and host/user). The USB firewall driver <b>210</b> provides connection to the USB firewall device <b>200</b>-<b>2</b>. The host service (e.g., the USB firewall UI <b>205</b>) checks whether the present device D <b>195</b> has or has not been seen in the past such that a historical policy is or is not known (respectively) for device D <b>195</b> (block <b>340</b>). A historical policy is a decision that has been or is made, governing a future observation, and a policy defines enforcement action(s) performed by the firewall <b>200</b>.

0049In one possible technique, the first time a new device D <b>195</b> (or a device that is not in the local cache, e.g., memory <b>145</b> of the software firewall <b>200</b>-<b>1</b> or hardware-based firewall <b>200</b>-<b>2</b>) is connected, the controller <b>255</b> will make a lookup and ask the USB firewall driver <b>210</b> (e.g., internally to the USB firewall <b>200</b>-<b>1</b> or over the control channel <b>290</b>-<b>1</b> for USB firewall device <b>200</b>-<b>2</b>) whether the USB device <b>195</b> has been seen before. See the path <b>336</b> for a new device. The reason is that the rules <b>151</b>/<b>152</b> can be held in volatile “cache” memory on the firewall device <b>200</b>-<b>2</b>, e.g., it may be that only the host device <b>105</b>-<b>2</b> has non-volatile memory where rules are persisted. After the volatile (in this example) cache has been updated, the firewall controller <b>255</b> (and packet filter <b>215</b> and/or sanitizer <b>220</b>) can work off the cache directly without querying the host <b>105</b>. That is, if the device D <b>195</b> is a known device for block <b>335</b>, the path <b>337</b> for the known device is traversed to block <b>350</b>.

0050In other examples, rules <b>151</b>/<b>152</b> may also be downloaded upon the moment the firewall device <b>200</b>-<b>2</b> is connected to the host or the USB firewall <b>200</b>-<b>1</b> is started/installed and the firewall controller <b>250</b> initializes. Nevertheless, if a previously unseen device D <b>195</b> appears (for which no set of rules <b>151</b>/<b>152</b> has ever been persisted), then the host <b>105</b> will be queried, which, in turn, will also query the USB Firewall UI <b>205</b> to ask the user for input.

0051Additionally, rules <b>151</b>/<b>152</b> may be persisted both [a] on the host (most likely the case in practice) or [b] the firewall (as an alternative) (or possibly both [a] and [b]). For option [a], rules <b>151</b>/<b>152</b> are downloaded to the firewall either upon initialization of the firewall or upon need. In both cases [a] and [b], the user is interrogated about his or her policy for any new device D not existing in the persisted set.

0052It is further noted that a device D <b>195</b> may only broadcast information indicating a device class (e.g., VID/PID) or information identifying a specific device (e.g., serial number, if it is provided by a given USB device) or possibly both. What this means, in reality, is that a system might not be able to determine that a specific device is unseen but only that the device is an unseen device class. As an example, if a user connects two identical keyboards, i.e., with the same VID/PID, a system cannot distinguish them necessarily, unless a serial number or other specific ID is provided. Regardless, the device class (e.g., based on the VID/PID) may be used by the system to control access between the device D <b>195</b> and the host <b>105</b>.

0053Such broadcasted information may be stored, e.g., for use in a subsequent attachment of the USB device <b>195</b>. For instance, see block <b>352</b> in <figref idref="DRAWINGS">FIG. <b>3</b></figref>.

0054If the historical policy is known for the device D (reference <b>342</b>), the policy (e.g., one of allow or deny or sanitize) is returned to the USB firewall <b>200</b> in block <b>355</b>. If the historical policy is not known for the device D (reference <b>344</b>), the USB firewall UI <b>205</b> will inform the user <b>305</b> that a new device has been discovered at the firewall and prompt (block <b>345</b>) the user <b>305</b> for a policy (e.g., allow/deny/sanitize as illustrated in UI <b>261</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>). The user reviews the information, e.g., the “New USB device found. Allow, Deny, Sanitize?” message in the UI <b>261</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>, and makes a decision (block <b>350</b> of <figref idref="DRAWINGS">FIG. <b>3</b></figref>). Making the decision includes informing the host <b>105</b> of a policy. The user-provided policy (e.g., one of accept, deny, or sanitize, depending on which button <b>263</b>, <b>264</b>, <b>265</b> is selected, see <figref idref="DRAWINGS">FIG. <b>1</b></figref>) is stored (block <b>352</b>) generally by the host first then sent over to the firewall controller <b>205</b> (e.g., to keep the sequence correct), as the USB firewall UI <b>205</b> is on the host <b>105</b>. The policy may be stored with enough information (ID info) regarding the USB device <b>195</b> to be able to identify uniquely the USB device <b>195</b> in the future. Concerning these IDs, not all USB devices may have a unique ID, but they have VID and PID (vendor and product IDs) to uniquely identify the same type of device (model/make of keyboard, camera, etc.). However, some USB devices may also deliver a unique serial number, which can be utilized by the policy enforcer (e.g., packet filter <b>215</b>) in addition for more fine-grained filtering (such as either by class of device or by specific serial number).

0055Blocks <b>340</b> and <b>345</b>/<b>350</b> of <figref idref="DRAWINGS">FIG. <b>3</b></figref> proceed through respective paths <b>342</b> and <b>351</b> to block <b>355</b>, where the policy is determined by the host <b>105</b>. For the first time a device (or device class) D connects/sends a packet to the USB firewall <b>200</b>, block <b>355</b> is performed by the host <b>105</b>. For every subsequent packet/communication, this policy may be cached by the USB firewall such that only block <b>360</b> applies. For all subsequent communication, the policy is cached in the USB firewall packet filter <b>215</b> and applied without involving the host. The USB packet filter <b>215</b> enforces (block <b>360</b>) the policy, e.g., by routing the packets according to the policy. Note that this enforcement can use the rules <b>151</b>. If the policy is Deny <b>361</b>, no packets will be routed by the USB packet filter <b>215</b> (e.g., all communications between the user USB device <b>195</b> and the application <b>141</b>/host <b>105</b> are blocked). See block <b>365</b>. By contrast, if the policy is Allow <b>362</b>, then packets will be freely routed by the USB packet filter <b>215</b> between the user USB device <b>195</b> and the host <b>105</b> (and, e.g., the application <b>141</b>). See block <b>370</b>. It is noted the USB filter <b>215</b> would perform the blocking or allowing of packets, e.g., using rules <b>151</b>.

0056If the policy is Sanitize <b>363</b>, USB traffic (e.g., packets) from the user USB device <b>195</b> toward the application <b>141</b> is rerouted to a sanitizer. See block <b>375</b>. Typically, the USB packet filter <b>215</b>, e.g., using the rules <b>151</b> sends certain packets to the sanitizer <b>220</b> of <figref idref="DRAWINGS">FIGS. <b>1</b> and <b>2</b></figref>. The sanitizer <b>220</b> sanitizes the traffic in block <b>377</b> and then the USB firewall <b>200</b> allows the sanitized traffic to proceed toward the application <b>141</b> in block <b>377</b>. The sanitizer <b>220</b> would use the rules <b>152</b> in its sanitization.

0057In other embodiments, it is possible for the USB firewall to use an external device referred to as a sandbox. This is describe in reference to <figref idref="DRAWINGS">FIG. <b>4</b></figref>, but briefly, the sandbox may sanitize the USB traffic in block <b>377</b> and that sanitized USB traffic of the user USB device <b>195</b> is received in block <b>380</b> and then the USB traffic is allowed in block <b>370</b>. In another example, the USB firewall <b>200</b> will receive from the sandbox an abstract representation of the sanitizer <b>220</b>. See block <b>385</b>. This abstract representation is implemented in block <b>390</b>, and the implemented sanitizer then performs the sanitization in block <b>377</b> and the USB firewall <b>200</b> allows the USB traffic in block <b>370</b>. These are described in more detail in reference to <figref idref="DRAWINGS">FIG. <b>4</b></figref>.

0058Turning to <figref idref="DRAWINGS">FIG. <b>4</b></figref>, which includes <figref idref="DRAWINGS">FIGS. <b>4</b>A and <b>4</b>B</figref>, this figure contains block diagrams of a possible and non-limiting exemplary embodiment. <figref idref="DRAWINGS">FIG. <b>4</b>A</figref> presents USB traffic rerouting in a system from a user PC (host) into a sandbox <b>460</b>, and <figref idref="DRAWINGS">FIG. <b>4</b>B</figref> illustrates routing USB traffic or other information in the system of <figref idref="DRAWINGS">FIG. <b>4</b>A</figref> from the sandbox into the user PC. In more detail, <figref idref="DRAWINGS">FIG. <b>4</b>A</figref> provides a diagram illustrating how USB traffic is forwarded (e.g., on top of the IP, Internet Protocol, protocol) to a cloud-based USB sanitizer (called a “sandbox”) for closer inspection of packets from the user USB device and therefore the user USB device itself. Meanwhile, <figref idref="DRAWINGS">FIG. <b>4</b>B</figref> illustrates a return channel for the sanitizer: after acting as a cleansing tool, the sanitizer may return sanitized USB traffic or an abstract representation of the device (e.g., proxied access to files on a mass storage device, driver sanitized access). That is, the USB traffic represents an abstract version of the device; i.e., the sanitizer translates the commands into a sanitized version of commands with the same semantic meaning for the device class.

0059In <figref idref="DRAWINGS">FIG. <b>4</b>A</figref>, the user USB device <b>195</b> is connected to the USB firewall <b>200</b> via data path <b>280</b>-<b>1</b>. Untrusted USB packets <b>410</b> are sent over the data path <b>280</b>-<b>1</b>, from the user USB device <b>195</b> toward the user PC <b>105</b> (and its application <b>141</b>, not shown in this figure). The user PC <b>105</b> in this example comprises the USB core driver <b>430</b>, and may or may not comprise the USB firewall <b>200</b> as described above. Between the USB firewall <b>200</b> and the USB core driver <b>430</b>, there is a control channel <b>425</b>, used to communicate control information, and a data channel <b>415</b>, over which at least the untrusted USB packets <b>410</b> travel.

0060The USB core driver <b>430</b> can package the untrusted USB packets <b>410</b> over IP (see USB over IP block <b>435</b>) using IP packets <b>471</b> and these IP packets <b>471</b> are communicated via path <b>437</b>, which could be wired or wireless or both. The untrusted USB packets <b>410</b> are received over IP at the sandbox <b>460</b>. See block <b>440</b> (USB over IP). Reference <b>470</b> is used to indicate the Internet, the cloud, and/or other wired or wireless networks. The sandbox <b>460</b> is a computer system that analyzes the USB packets <b>410</b> using the USB core driver <b>445</b>. The USB core driver <b>445</b> converts the IP packets <b>471</b> back to untrusted USB packets <b>410</b> and also performs analysis of the packets <b>410</b>, e.g., using an abstract representation of a sanitizer corresponding to a USB device. The sanitizer can use rules such as those in rules <b>152</b>.

0061In <figref idref="DRAWINGS">FIG. <b>4</b>B</figref>, for USB packets <b>410</b> that are sanitized, these sanitized USB packets <b>491</b> may be repackaged into IP packets <b>472</b>, as performed by USB over IP block <b>440</b>. The IP packets <b>472</b> are communicated over a path <b>437</b>, e.g., using the IP protocol.

0062In another example, the sandbox <b>460</b> analyzes the untrusted USB packets <b>410</b> and provides an abstract representation <b>492</b> of the user USB device <b>195</b>, which therefore provides class and its generic commands for the USB device, which is packaged by the sandbox into IP packets <b>471</b> and communicated over the path <b>437</b> to the user PC <b>105</b>.

0063The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

0064The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

0065Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

0066Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

0067Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

0068These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

0069The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

0070The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

0071The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:

0072CRC computer-readable code

0073ID identification or identifier

0074I/F interface

0075IP Internet protocol

0076I/O input/output

0077MIDI musical instrument digital interface

0078MitM man-in-the-middle

0079NTFS new technology file system

0080NW network

0081OS operating system

0082PC personal computer

0083PID product ID

0084SSL secure sockets layer

0085UI user interface

0086USB universal serial bus

0087VID vendor ID