-
Notifications
You must be signed in to change notification settings - Fork 40
Home
USB is the universal peripheral interface for personal computers. For over 15 years USB has provided an easy-to-use interface compatible with a wide variety of hardware devices. But this long legacy and wide compatibility also bring security risks, which are now coming to be understood.
To achieve its wide compatibility, USB employs a complex layered protocol. This requires every USB device to incorporate a microprocessor (embedded CPU) to send & receive commands and data. And naturally, these microprocessors need to run firmware.
In simpler times the host computer and the USB device trusted each other, and so USB implementations historically placed little emphasis on security issues. But what if malicious firmware were loaded into a device? How much damage could it do?
Any USB device can be 'turned bad' by loading malicious firmware into its microprocessor, either during the manufacturing process or out in the field. There are three classes of attack a BadUSB device can perform against a host computer.
-
Stack exploit attacks: A device can supply maliciously malformed data to USB host software running on the computer. This can exploit bugs in the USB host driver, or any of the hundreds of USB device drivers found on a typical OS. These device drivers run with system priveliges, are often developed by third parties, and are rarely tested against unexpected or malformed input.
-
Hidden-functionality attacks: What appears to be a single USB device can actually hide more than one function inside itself. The hidden function can perform any action allowed by the USB standard. For example a hidden keyboard can run any command the user is authorised to perform, or a hidden network interface could attempt to intercept the user's network traffic. Only 100% legitimate USB commands are used, and the possibilities are limited only by the attacker's imagination.
-
Intended-functionality attacks: This is where a USB device performs only the functions you expect, but still manages to be evil. Perhaps the best example is a Bad mass storage device, which has access to all your data and can maliciously alter storage blocks on-the-fly. Like the hidden-functionality attacks above, only legitimate USB commands are used and concerned users have no way of defending themselves. That is, until now.
The USG was created to solve the problem of BadUSB. It is a device that you insert between your computer and your untrusted USB device, and it ensures that no malicious commands or data can pass between them.
The USG operates on the principle of 'security by isolation'. It uses two USB-enabled microprocessors: one connects to your untrusted device while the other emulates your device to the host computer. These microprocessors exchange data through a simple protocol running over a simple serial interface - SPI.
This inter-microprocessor interface protocol has a much smaller attack surface than a USB software stack, so it is simple enough for us to guarantee security by correctness. So even in the worst-case-scenario of a BadUSB compromising the firmware in one microprocessor we can guarantee that the second microprocessor cannot be compromised, and thus your host computer is safe.
This security-by-isolation approach protects primarily against stack exploits (type 1 above). To protect against hidden-functionality attacks (type 2) we can add some rules into our USG firmware to ensure devices don't try to misbehave.
-
Only one device attached at a time: This limitation of the embedded USB firmware and hardware is also a feature. By supporting only one attached device, we eliminate attacks that use a hidden hub and additional device to perform unexpected actions.
-
No run-time device class changes: Once a USB device is enumerated through the USG, it cannot re-enumerate itself as a different device class until power is removed and reapplied to the USG. This blocks attacks where a device unexpectedly changes its functionality to perform malicious actions.
And to protect against intended-functionality attacks (type 3), we can add class-specific rules. For example, the mass storage class could encrypt blocks before they reach the USB device, rendering man-in-the-middle attempts futile. Or the human interface device (HID) class might block keystrokes arriving faster than a reasonable human typing speed.
The USG is currently in beta, so calibrate your expectations accordingly!
The first generation of USG hardware supports full-speed USB only, i.e. 12Mbps. If it proves sufficiently popular a high-speed 480Mbps version may be developed later.
Custom hardware is under development, but is not yet in production. If you want to get your hands on one now you will have to build one yourself out of development boards. See the DIY Hardware page for details.
The USG firmware currently supports mass storage devices only. HID support is planned for the near future, in between hardware development efforts.