YubiKey & BadUSB

Updated Oct. 22, 2014 to include information on Security Key

We have received a few questions with regards to “BadUSB” concept and the YubiKey, presented at BlackHat 2014. This was picked up by wired.com, where the problem domain is somewhat expanded into a claim that the “Security of USB Is Fundamentally Broken”.

Although there are a few different (and known) issues presented, the main claim here is the possibility to turn a legitimate USB device into an evil one by replacing its genuine firmware with a malign image. The author describes USB devices, but this general concept applies to almost all types of devices having the capability to upgrade the firmware in the field, a process known as Device Firmware Upgrade (DFU).

The concept of creating “hardware Trojans” is interesting (and scary) and has gained quite some attention in the early 1990s when the first field-upgradeable flash BIOSes for PCs became available. It was then shown that by replacing a legitimate BIOS with a hacked image, malign functionality could be implanted deep into the functionality of a PC, beyond reach of anti-virus software.

However, although conceptually feasible, such attacks are not that easy to execute practically and to make them widespread. There are quite a few reasons for that.

1. Many low-end USB devices do not support DFU, either because the firmware is factory-programmed in a non-alterable mask ROM, one-time-programmable ROM or simply because there is no DFU mechanism implemented. Supporting DFU adds cost and complexity and therefore makes little sense for low-cost mass-market devices, such as thumb drives, card readers, keyboards and mice.
2. To perform DFU, often some active (and usually quite awkward) sequence has to be performed by the user, such as holding a button while the device is power cycled. Then, a specific executable has to be run in the computer where the device is connected to perform the actual firmware upgrade. This is not something that is likely to happen without the user actively initiating it.
3. An attack of this kind has to be targeted on a per device model basis, and then requires extensive knowledge of the particular implementation, including reverse-engineering. An attack that works for a specific device will only work for that particular version of the device. Making a blast to a large number of users and try to fool them to upgrade with a malign image seems somewhat unlikely to get more than a marginal impact.
4. Many low-end USB devices have limited memory capabilities which cannot be upgraded with a firmware that can do anything really evil while maintaining their intended function. So, if the device is infected, it won’t be able to perform what it was designed to do. High-end devices, such as MP3-players, cameras and phones are a different story, but there the problem can be mitigated by code signing.

There are probably quite a few devices out there that do not implement basic countermeasures against what has been listed above. Probably the biggest issue with DFU is that the user accidentally bricks a device when an update fails or stalls before it has been completed. This is an implementation issue and should be seen as a design flaw by the vendor rather than a system-wide problem.

One can wonder if low-end USB devices, such as thumb drives are in fact the scariest targets for malign firmware and also why these would implement or require DFU? Phones, network routers and gateways with extensive memory and processing capabilities together with constant network and power connection seems to be more obvious and attractive in this respect. Here, the number of vendors is less and DFU is supported on a more general scale.

Seen from a different angle, one can ask if this is really a USB problem or the fact that devices (above the complexity of a thumb drive) are nowadays frequently (and very fundamentally) updated. Replacing the operating system in a tablet, firmware image in a printer, phone or a network router does not require USB – it is done directly via the network connection. The scalability and harm of such attacks is probably orders of magnitude worse than what can be accomplished on a per-device basis via USB.

The question then inevitably becomes – so how does this all affect current Yubico products, which obviously are USB devices?

With regards to the FIDO U2F Security Key by Yubico and DFU…
– There is not a DFU mechanism in the Security Key and hence it cannot be updated.

With regards to the YubiKey Standard and DFU…
– The firmware is in non-alterable ROM and hence cannot be updated.

With regards to the YubiKey NEO and DFU…
– The YubiKey NEO technically does support DFU, but requires the new firmware image to be signed by us. Yubico does not endorse nor support use of DFU for users.

With regards to the YubiHSM and DFU…
– The device does not implement DFU and hence cannot be updated.

With regards to a USB device being a carrier for malign files…
– The YubiKey or YubiHSM do not support Mass Storage Device (MSD), so they cannot carry infected files or data.