Bitdefender Research Exposes Security Risks of Android Wearable Devices

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:

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:

Mitigation
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.

Implications
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.