|Acquisition Program: ||PEO Missiles and Space|
| ||The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), which controls the export and import of defense-related material and services. Offerors must disclose any proposed use of foreign nationals, their country of origin, and what tasks each would accomplish in the statement of work in accordance with section 3.5.b.(7) of the solicitation.|| Objective: ||The objective of this effort is to develop a compact USB firewall that can be used to protect government computer systems from Cyber Warfare attacks using common USB devices. The device should enforce the USB standards for devices attached to a computer system, and prevent the devices from performing malicious acts.
|| Description: ||USB is a widely-used interface mechanism in the modern computer industry for peripheral devices (USB can also be used to directly inter-connect computers). While widely used, it is often not understood both by the developer and the security expert. In its basic form, USB forms an extension of the computer’s internal hardware structure/memory to the outside world.
To begin to understand the complexity of USB, one must first define what USB is and how it interconnects computers and the external hardware devices. One of the simplest ways of abstracting the interconnect methodology is to view each separate device as an independent entity/computer that is interconnected in a client-server fashion to the central host. Each node on this quasi-network has its own firewall (the USB hardware layer), and under the USB specifications, each node is assumed to follow the documented procedures.
The network analogy goes very deep inside the core of how both USB and Firewire are designed. Under USB, each device has its own distinct address assigned by the host computer as per USB specification. This is highly analogous to the IP address used in modern networking. In addition, each USB device can have up to 9 endpoints, which are similar in function to the port on a networked computer. Two of these endpoints are designed in a specific way. Endpoint 0 is a bi-directional endpoint that is used exclusively for control of the USB device. It is used by the host to set basic features and other host client signaling. Endpoint 1 is also a bi-directional endpoint with a data buffer of a fixed size. Both of these endpoints are always defined. The other endpoints are mono-directional and of variable size and may not exist.
The specifications of the interface force this kind of structure, and what each controls varies between manufacturers. What is important to note is that unlike older peripheral interfaces (such as RS-232C), a significant amount of USB functionality is embedded in specialized hardware that is not easily accessible or directly controlled by typical equipment manufacturers.
This creates an environment where the device, that is a trusted agent, comes from an untrusted source. There are a number of potential vulnerabilities due to malicious USB devices. These include:
1. Malicious code on storage
2. Storage bait-and-switch
3. Monitoring devices
4. Data leaks across device boundaries
5. Keyboard/mouse emulation
6. Remote control
7. Electronic Attack devices
Required for this initiative is the development and construction of an inexpensive “USB Firewall” which would act as an intermediary between the on board USB bus and the device to be connected. This device would act as a trusted filter to detect/mitigate malicious activity and hard electronic attack.
|| ||PHASE I: Conduct analytical and experimental efforts to demonstrate feasibility of designing a USB firewall which can detect and defend against malicious activity. Proof-of-principle experiments with a brass board device would be encouraged to determine the feasibility of such a device.
|| ||PHASE II: Based on the results and findings of Phase I, demonstrate the technology by fabricating and testing a prototype in a laboratory environment. Assemble a proof-of-principle device and demonstrate the proposed technology and its ability to signal an attack warning, identify its characteristics, and defend against the attack. Identify and address technological hurdles. The proposed development and demonstration should be limited to what is required to demonstrate TRL level 4 or level 5 and should identify the means necessary to transition the technology.
|| ||PHASE III: This technology could be used in a broad range of military and commercial applications. The final embodiment of this device would be a standalone hardware module where un trusted USB devices could be inserted to minimize damage/virus injection possibilities. The final device should result in a standalone self updatable unit that can be self installed by any user. It should warn the user of possible threat via either on screen message or status lights and require minimal configuration and maintenance.
|| References: ||
2. On-the-Go Supplement to the USB 2.0 Specification, Revision 1.0a, June 24, 2003
3. USB Specification, Revision 2.0, April 27, 2000
4. Axelson, Jan, USB Complete, 3rd ed., Lakeview Research, 2005
5. Wheeler et al. Prototyping Trusted Path on Virtual Machine Architectures. 2006. IDA paper P-4110.|
|Keywords: ||USB, Cyber warfare, Firewall|
Questions and Answers:
Q: Firewire is referenced in the topic, which operates almost entirely different than USB: Is it necessary to include Firewire in our response?
A: No, firewire is not required to be considered.
Q: Is the final cost of our solution a major or critical factor?
Should lower cost solutions be considered more responsive than more capable solutions? (More capable may include: hardware based, more hardening, anti-tamper, higher speed, more devices in a tracking database, etc.)
A: Cost is not a major factor, we are more interested in performance and security. A nominal price point, in bulk mass production, would be $100.00 per hardware/software combination.
Q: It seems that a hardware solution is indicated in the topic. Since hardware is expensive and is typically controlled by software/firmware anyway, would a software solution (possibly based within an operating system) be considered responsive?
A: A hardware or hardware/software solution would probably be required in this case, however if a pure software solution could be shown to work then it would be considered.
Q: Detection of USB enabled malicious logic is clearly the primary focus of the topic: But what about response measures? The topic includes a statement about "detect and defend", although it is not clear what defensive steps are considered important.
Would simple USB device disabling and user/admin notification be considered acceptable?
A: Simple disabling and notification are acceptable. Disabling in this case means chopping of all supplied power to the device.
Q: Is it acceptable to prioritize our Phase I proposal to focus on COTS desktop computers running a mainstream Windows and Linux OS?
In other words, is it responsive to focus on x86 type computers and OS variants as opposed to embedded computers?
A: The focus is the desktop/laptop enterprise computing environment.
Q: In the topic description, a number of the details regarding the USB specification were not necessarily accurate. This is understandable considering there are several variants and flavors (USB 1.0/1.1, USB 2.0 and the emerging USB 3.0 – not to mention low speed/full speed/high speed/super speed, wired vs. wireless USB, etc.)
1. What USB specifications and speeds are considered important for a Phase I proposal? 2. Can a proposal limit the feasibility study to a subset of USB variants and be considered responsive?
A: The primary concern is wired USB 2.0 and below.