Presentation Material
Abstract
Communication protocols have evolved from the traditional Serial and LAN ports to complex and lightweight protocols of today, such as Bluetooth Low Energy (BLE), ANT+ and ZigBee. Bluetooth Low Energy (BLE) is a popular protocol of choice for wearables which are low energy, low performance computing systems. The BLE standard specification provides for a variety of security mechanisms for channel encryption to protect data against snooping and man-in-the-middle style attacks.
In this presentation, we talk about the security assumptions made by popular mobile operating systems when they adopt the BLE specification and how this impacts their communication with wearable devices. We include vulnerability case studies to discuss how rogue mobile applications can use the same set of BLE encryption keys as the legitimate companion application, and get access to personal information or cause denial of service conditions on the wearables. We will discuss the insufficiencies of the protocols and the need for extra measures if the use cases demand confidentiality and integrity of data in transit.
We present high level flows to correctly design secure communication channels between a phone application and the wearable device.
AI Generated Summary
This research examined security weaknesses in Bluetooth Low Energy (BLE) communication between wearable devices (e.g., fitness trackers) and their companion smartphone applications. While the BLE specification provides link-layer encryption using a long-term key (LTK) to protect data in transit, the study identified a critical architectural flaw: the smartphone’s Bluetooth stack and services are shared system resources accessible to any installed application with Bluetooth permissions. Consequently, a malicious application can connect to a paired wearable and subscribe to its Generic Attribute Profile (GATT) characteristics, receiving the same unencrypted biometric data (heart rate, steps, location) as the legitimate companion app. Furthermore, for devices that only authenticate during initial pairing, a malware app can inject commands (e.g., factory reset, reboot) after a legitimate app establishes a valid encrypted session, effectively piggybacking on the existing secure channel.
Testing across three classes of wearables revealed varying susceptibility: one class leaked all data to any subscribing app, a second class using direct Wi-Fi cloud communication was secure, and a third class implemented initial authentication but remained vulnerable to post-pairing command injection. The core finding is that BLE’s encryption protects against network eavesdroppers but not against other local applications. The proposed mitigation involves establishing a separate, application-specific secure channel between the wearable and each legitimate companion app, using a unique application key to cryptographically bind commands and data to that specific app, thereby enforcing integrity and confidentiality even in a shared-stack environment.