Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

News & Commentary

12:50 PM
Liviu Arsene
Liviu Arsene
Partner Perspectives
Connect Directly

Bitdefender Research Exposes Security Risks of Android Wearable Devices

In the rush to supply early adopters with trendy technology, security has been compromised.

In the wake of the recent smartwatch and smartband boom has come a surge in phone-paired devices that broadcast or receive personal user information.

Early adopters have been prompting companies to develop interconnected devices that perform once-onerous tasks, such as constantly checking your phone for notifications or messages, to make the transition to wearable technology more seamless and intuitive.

There’s nothing wrong with simpler and easier lives. But in the rush to supply early adopters with a new trendy gadget, security has been compromised in some cases. Every developing technology being pushed to market inevitably has drawbacks. Whether it’s a fashionable colored armband or some interesting functionality that most will never use, security concerns have probably been bumped further down the priority list.

Our own security researchers from Bitdefender have been testing the theory of whether the new generation of smartwatches poses any security risk to wearers. The information you have on your phone is extremely private -- hence the need to restrict access with PIN codes or passwords.

Watch Liviu discuss his team’s findings.

The Big Question
We embarked on a search to answer a question that too few have been asking: “How safe is the actual communication between your smartphone and your smartwatch?”

The answer was both surprising and somewhat expected, as experience has taught us that every new trending technology takes time to develop the right set of mechanisms that ward off tampering fingers and prying eyes.

All communication between Android devices and smartwatches is handed via Bluetooth. That’s pretty safe, as attackers need to be close to actually sniff traffic. But it does not mean the scenario is impossible.  

The security research team at Bitdefender has been investigating the way information is passed between smartwatches and the wearable apps on your smartphones to determine whether an attacker could peek at your text messages, Facebook conversations, or Hangout chats.

The proof-of-concept involved a set of tools, not uncommon to average security geeks, along with a Samsung Gear Live and a random Android device – in this case a Google Nexus 4 with Android L Preview.

At first glance, the findings were pretty consistent with our expectations. Bluetooth communication between smartwatch and Android device involved encrypted Bluetooth communication using six-digit PINs to obfuscate the broadcast and prevent any curious newbie from seeing entire conversations in plain text with a sniffing tool. Using available tools, this six-digit PIN can easily be brute-forced and used to decrypt the conversation between smartwatch and smartphone.

Further investigation into the obfuscation algorithm used was somewhat surprising as it was not all that difficult to brute-force the six-digit PIN and de-obfuscate the Wear communication protocol, revealing all sorts of information passed between the two devices.

A non-technical reader might skip ahead to the Implications section, as the next few paragraphs may be somewhat dry.

The Technical Tidbits
Four types of messages are encapsulated in the obfuscated communication between the smartwatch and Android device in a peer-to-peer manner:

  • ID Exchange – Every device sends an ID to the other device (smartwatch to Android device and vice-versa)
  • Control – Encapsulates Remote Procedure Calls affiliated to various actions. These RPCs are commonly used in inter-process communication between two devices sharing the same network, in this case Bluetooth pairing
  • Data – The contents of each notification and affiliated metadata
  • Asset Transfer – An asset is an object that can encapsulate large data such as photos

For the purposes of this article, we won’t dwell on the first type of data packets, as they’re mostly used to establish each device’s identity. The asset-transfer packets are also of little importance, as sending photos, audio files, or movies between an Android device and a smartwatch is not as interesting as being able to read actual messages and conversations. Asset transfer is usually used for sending large amounts of data.

The interesting parts lie in the control and data packets, as their use seems to involve the actual communication between on-device applications and the smartwatch. The Wear API takes care of this communication using methods similar to “send (tag, path, object)” formatting.

Here’s a breakdown of the actual variables in the control and data packets:

  • $counter_bytes – a type of counter for the control communication
  • $header_length = 31(0x1F) – an ASCII Unit Separator used for separating fields in text; 31 is the length of the $header
  • $header = com.google.android.wearable.app – name of the Android Wear app
  • $misc_id_length = 40(0x28) – an ASCII representation for Open Parenthesis; 40 is the length of the $misc_id
  • $misc_id = a197f9212f2fed64f0ff9c2a4edf24b9c8801c8c – could be a hash function that could differ from one device to another; not exactly sure of its purpose, but we managed to discern this value in our investigation
  • $tag_length and $tag, respectively $path_length and $path – affiliated to the Wear API; these are the common variables in the communication method described above used to separate and identity RPC calls
  • $data_map_length and $data_map – contains the actual sent data (this is the juicy part)

Mitigation could involve using Near Field Communication (NFC) to send a PIN code to the smartwatch, or using a pass-phrase during pairing. The downside to NFC is that not all devices – mobile devices or smartwatches – have NFC capabilities. Using pass-phrases is also tedious, as it involves manually typing a possibly randomly generated string onto the wearable smartwatch.

Or we could supersede the entire Bluetooth encryption between Android device and smartwatch and use a secondary layer of encryption at the application level. This, however, should be implemented either by Google or OEMs, and it might have an impact on the smartwatch’s battery lifetime, as encryption involves heavy computations.

The obfuscation method of the Wear API used when communicating between smartwatch and Android device was mostly debunked, although the currently used method wasn’t fully exposed. However, we did manage to see plain-text conversations between apps, such as Facebook Messenger, Google Hangouts, and even SMS messages when sent from the Android device to the smartwatch.

We’re pretty sure that, if someone were to do more in-depth research into how the Wear obfuscation actually works, we would soon end up with some fascinating exploit packs. Weaponizing this is only a matter of how much someone would have to gain from reading your conversation, even in close proximity.

The Internet of Things is a truly marvelous concept, but only as long as we do not overlook security implications. These security risks could easily be fixed with stronger or better methods for ensuring the safety of the entire communication.

With quite a few wearables out there that rely on Bluetooth pairing to receive text messages and to engage in various forms of chatting, security issues should be treated with the utmost seriousness.

Over-the-air Bluetooth encryption is handled by the baseband co-processor built into most Android devices. Previous research has proven that this baseband co-processor can be tampered with via over-the-air updates.

Our research involved analyzing the raw traffic before it is sent over the air via the baseband co-processor. This means that relying only on baseband co-processors to handle the encryption is not a fool-proof security mechanism. It also raises the question of how easy it is for someone to update the firmware on the baseband co-processor once a vulnerability is disclosed.

Liviu Arsene is a senior e-threat analyst for Bitdefender, with a strong background in security and technology. Reporting on global trends and developments in computer security, he writes about malware outbreaks and security incidents while coordinating with technical and ... View Full Bio
Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Hacking It as a CISO: Advice for Security Leadership
Kelly Sheridan, Staff Editor, Dark Reading,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-12
The ALPS ALPINE touchpad driver before 8.2206.1717.634, as used on various Dell, HP, and Lenovo laptops, allows attackers to conduct Path Disclosure attacks via a "fake" DLL file.
PUBLISHED: 2020-08-12
Sonatype Nexus Repository Manager OSS/Pro before 3.26.0 has Incorrect Access Control.
PUBLISHED: 2020-08-12
search.php in the Nova Lite theme before 1.3.9 for WordPress allows Reflected XSS.
PUBLISHED: 2020-08-12
PHP-Fusion 9.03 allows XSS via the error_log file.
PUBLISHED: 2020-08-12
PHP-Fusion 9.03 allows XSS on the preview page.