Sponsored By

Bluetooth Devices Leaking Tracking Data

Researchers from Boston University found that the current version of Bluetooth Low Energy, as implemented by Apple iOS and Windows 10, leaked identifiers that allowed tracking of the device that was using BLE.

Larry Loeb

July 19, 2019

3 Min Read

In a paper presented Wednesday at the 19th Privacy Enhancing Technologies Symposium, researchers from Boston University found that the current version of Bluetooth Low Energy (BLE), as implemented by Apple iOS and Windows 10, leaked identifiers that allowed tracking of the device that was using BLE.

Android was not found by the researchers to have this problem. BLE devices broadcast what are called "advertisements" on unencrypted, public channels (located at 2402 MHz, 2426 MHz and 2480 MHz) in order to signal their presence to other BLE devices. Windows and Apple devices perform privacy protecting measures like address randomization to hide the device's permanent MAC addresses in these broadcasts.

The problem originates when a BLE device also uses dynamic identifying tokens, which are unique to a device. They can remain static long enough to be used as secondary identifiers to the random addresses.

Due to the manufacturer's implementation of the standard, identifying tokens and the random addresses used for public identification may not change in sync on some devices.

The researchers came up with a proof of concept method that listened to the public advertising channels and tried to match a captured identifying token to a newly changed advertising address.

It didn't always work.

"The algorithm succeeds consistently on Windows 10 and sometimes on Apple operating systems," the report said. "In both cases, the respective identifying tokens change out of sync with the advertising address. In the Windows 10 case, there is no evidence of any synchronization by design. In the Apple case, it seems that there exist mechanisms to synchronize updates of identifying tokens with address randomization, but they occasionally fail."

The authors do have some specific recommendations that they propose. First is to synchronize payload changes with address randomizations. If the advertising message payload contains any type of data that could be used as an identifying token, the payload should change in sync with the address to prevent extended tracking.

Implement address randomization for low-powered devices. For some devices, especially wearables and other battery-powered sensor devices, frequently randomizing the address may be at conflict with energy constraints. The researchers think that device states which are not concerned by these constraints should be leveraged to change the address. Examples of this could include charging the battery or when a power cycle or other maintenance activity is performed.

Implement reconnection addresses for certain types of BLE peripherals. The report says that "BLE allows devices to exchange Identity Resolving Keys (IRK) which enable them to use resolvable random private addresses of each other. This allows for secure directed advertisement and connection initiation that does not leak permanent identifiers to the public. Devices which currently use an advertising approach involving static addresses (such as the Microsoft Surface Pen) should consider integrating this protocol feature into their software architecture."

For Windows 10, the paper recommends a simple workaround. They advocate one specific method, saying that " it is still possible to break address-carryover tracking on the user side by completely disabling the Bluetooth device through theWindows Device Manager and re-enabling it again. Contrary to the Windows 10 Settings page, disabling the Bluetooth device in this manner will reset both the advertising address and the payload, thereby breaking the chain." Things are simpler for iOS. Switching Bluetooth off and on in the System Settings (or in the Menu Bar on macOS) will randomize the address and change the payload.

Though the problems with Microsoft and Apple software were disclosed to the companies in November 2018, no patches have yet been issued.

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Read more about:

Security Now

About the Author(s)

Larry Loeb

Blogger, Informationweek

Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He has written a book on the Secure Electronic Transaction Internet protocol. His latest book has the commercially obligatory title of Hack Proofing XML. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. His first Mac had 128 KB of memory, which was a big step up from his first 1130, which had 4 KB, as did his first 1401. You can e-mail him at [email protected].

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights