Bluetooth Security Challenged

Bluetooth was never designed to communicate secure data, but merely to wirelessly connect peripherals. The lack of security baked into the short-range wireless technology offers hackers an easy avenue into Bluetooth-compatible devices, according to Ohio State University (OSU) professor Zhiqiang Lin and post-doctoral researcher Yue Zhang. Their most recent research into how hackers can use Bluetooth to track a user's location was presented at the ACM Conference on Computer and Communications Security in November.

Lin explained the goal for such an attack " is to break the MAC [media access control] address randomization used by mobile Bluetooth devices including smartphones, earbuds, and even hearing aids."

The OSU researchers claim to have proven that an attack vector — which the authors call Bluetooth Address Tracking (BAT) — works on more than 50 market-available Bluetooth devices, as well as the development boards of four original equipment manufacturers (OEMs). All of the OEMs were notified of the issue, as was the Bluetooth Special Interest Group ( SIG that defines standards for the wireless technology.

The seriousness of this attack vector cannot be overemphasized, according to Bruce Young, a professor of cybersecurity and information assurance at Pennsylvania 's Harrisburg University of Science and Technology (who was not involved in the research). Said Young, "It is estimated that the number of devices impacted is in the billions. There are 11 major vendors of Bluetooth that are all impacted. Turning off Bluetooth when not using it is a good idea, as it can be easily connected to by rogue devices."

Michael Nizich, director of the Entrepreneurship and Technology Innovation Center (ETIC) at the New York Institute of Technology (also an adjunct associate professor of computer science there), says securing Bluetooth will not be easy. "You can patch Bluetooth software on a device's operating system, but this newly found flaw in the general Bluetooth protocol will not be amenable to an easy fix while maintaining backward compatibility with existing devices," said Nizich.

The BAT attack vector listens for the signal that idle Bluetooth devices send out every 20 milliseconds to make their Media Access Control (MAC) address available so other devices using Bluetooth can connect with them. Periodically randomizing the MAC address was supposed to prevent outright tracking of specific users. To strengthen security further, an "allowed listing" of known safe devices was added by the SIG standardization group, to prevent unknown devices from connecting. However, according to the OSU researchers, the process of verifying an allowed device's presence has done just the opposite, creating a "signature" that hackers can use in a side-channel attack for device tracking.

"We have validated the possibility of 'allowlist' based side-channel attacks with 43 BLE [Bluetooth Low Energy] peripheral devices, 11 computers, and four development boards, and found none of them, once configured with allow listing, are immune to BAT attacks," said Lin.

The MAC address randomization scheme is flawed, according to Li, because it is susceptible to a "replay attack" in which the hacker replays a broadcast MAC address, then listens to see whether the targeted device responds, revealing whether it is on the allowed list.

OSU has devised a simple operating system (OS) patch that adds a time-stamp to each randomized MAC address so they can be used only once—thus foiling the replay attack. Called SABLE (for Securing Addressing for Bluetooth Low Energy devices), the OS patch does not require any hardware changes, and has already been shown to work with both iOS and Android kernels, according to OSU.

SABLE patches the flaw in the software stack of a Bluetooth device with an OS patch, but since the root cause lies in the standard itself, all Bluetooth Low Energy peripherals using resolvable private addresses that are configured with allow listing remain vulnerable. Lin is confident a fix can be found at the standard level but agrees with Nizich that it remains to be seen how that can be done while maintaining backward compatibility with existing devices.

"The patch of an OS is easy and can be rolled out quickly by smartphone makers but fixing the peripheral devices will be harder. If the OS is updated but the [peripheral] device is not, then they may not be able to work together, so it has to be a standard change in both the OS and within the specific peripheral," said Lin.

George Berg, chair of the Cybersecurity Department in the College of Emergency Preparedness, Homeland Security, and Cybersecurity at the University at Albany (NY), agrees the standardization effort to fix this Bluetooth vulnerability will be problematic, especially with regard to the backward compatibility issue. Berg explained that "by their [hardwired] nature, many of the existing BLE peripherals out in the world cannot be updated; therefore, a new version of the protocol will need to take these older devices into account."

Making those devices no longer usable would not be commercially feasible, said Berg; "consumers would be decidedly unhappy if this were to happen. This leaves the alternative of a protocol that can accommodate older devices, perhaps by falling back to the old protocol if a device is unable to respond correctly to the new protocol. This, however, also has downsides of its own, namely that communication with old devices would still be vulnerable to attacks."

In addition, Berg is concerned that "a new, more complicated, backward-compatible protocol may also add significant additional overhead in terms of the computing that needs to be done, as well as potentially have a negative effect on battery life."

The OSU researchers estimate that a new standard, without a fallback protocol, will consume an extra 1% of power for the OS patch, while peripherals could see a 6.75% boost in power consumption. Performance-wise, they say a SABLE-like OS patch will require an extra 88.49 microseconds to execute without a fallback protocol, while the new peripheral device protocol will require about 94.46 microseconds additional execution time. Foiling "replay" attacks by adding timestamps to MAC addresses will require an extra 63.58 microseconds for smartphones and about 20.54 microseconds for peripherals. However, the researchers say the extra power consumption and latency of adding a fallback protocol to accommodate existing devices cannot be calculated until after a new standard is tested and ratified.

Until then, all parties agree that the only way to keep Bluetooth from being used to physically track users is to turn it off when not in use.

 

R. Colin Johnson is a Kyoto Prize Fellow who ​​has worked as a technology journalist ​for two decades.