Getting Started with Android Wear Security I: Introduction
The first Android Wear devices shipped this week and we were excited for our new toys to arrive.
For Wear to be useful, you need to pair it with a phone or a tablet via Bluetooth, and your device needs to be running Android 4.3 or above. On your handheld, you have to install the Android Wear app. Neither the Gear nor the G have Wi-Fi or NFC, making Bluetooth your primary way of accessing data.
Wear applications have a companion app on the paired device. To install an app on Wear, you install it through Google Play on your mobile device. An APK is installed on both your handheld and Wear. When you create an application with Android Studio, you can now select the form factors you want your application built for, including phone/tablet, TV, Wear, or Glass.
When you install an app with a Wear component, the Wear APK is automatically pushed to your watch.
The Wear app and companion app can be signed separately but should use the same package names as each other. They are essentially independent applications running in isolation and connected via Wear’s APIs for exchanging data. These APIs include:
Setting Up a Test Environment
If you are using a physical watch for testing instead of an emulator, the first thing you’ll want to do is root your device. If you have an LG G, here is a tutorial on getting your bootloader unlocked and loading the boot image, giving you access to superuser privileges.
One thing to note is that you can set up debugging for your watch either via Bluetooth or via USB. If you want to walk around with your watch or move around freely, then Bluetooth is your best bet. To set up debugging via Bluetooth, follow the instructions found here. You’ll need to configure both your watch and handheld to enable debugging.
Compared to traditional mobile apps, Wear apps are pretty lightweight. Most of the heavy lifting is supposed to be performed on your handheld, with notifications and messages sent between the devices. Wear apps communicate with their counterparts on the handheld, which makes all calls to remote services on behalf of the Wear app.
There are no WebViews on Wear currently. This means that issues like Cross Site Scripting (XSS) or Cross Site Request Forgery (CSRF) are less of a factor within the Wear app itself, but still have to be considered if your handheld app implements WebView functionality.
Adding the Wear component extends the trust boundaries for existing applications. This includes handling untrusted data received from Wear as well as securely storing data that’s replicated to the watch. Encryption schemes may need to be extended to account for distributed storage and the need for real-time replication.
Intents and IPC are still utilized by Wear, allowing other applications to inject malicious data or to gain privileged access to an exposed component. If you receive data from the Wear app and use it to issue authenticated requests to a web service, you should ensure that these workflows are sufficiently protected from unauthorized apps.
What if I lose it?
Good question. Out of the box, both the LG G and Samsung Gear Live don’t expose the ability to lock your watch or protect it with a passcode, swipe sequence, or biometric data. As a result, it’s pretty trivial to compromise a lost or stolen device using the instructions given above for rooting.
In the next post on Wear, we will dive into some code examples illustrating ways that we foresee developers introducing security issues into their wearable apps. So, come back soon!