LWN.net Logo

Advertisement

GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.

Advertise here

CyanogenMod Account: Remotely track or wipe phones

By Jake Edge
August 21, 2013

Being able to remotely track or delete the personal data (i.e. "wipe") from a lost or stolen phone can be rather useful features. Unfortunately, most of the solutions for doing so come with strings attached. Generally, the app provider, a random attacker, or an employer can trigger the tracking or wiping, which is likely not what the phone owner had in mind. CyanogenMod, an alternative Android distribution, is taking another approach to the problem, one that will only allow the owner of the device to remotely track or wipe it.

Phones and other devices are frequently misplaced, and sometimes stolen. In the former case, tracking the phone down, either by its GPS location or by simply ringing it, is helpful. For stolen phones, the location may be of use to law enforcement, but being able to delete all of the personal information stored on the device is an important, possibly even critical, feature.

On August 19, the project announced CyanogenMod Account, which is an optional service to provide these features. As one might expect from a project like CyanogenMod, all of the code is open source, and the project is encouraging both potential users and security researchers to scrutinize it.

The idea, as outlined in the announcement, is to preserve the privacy of users and to protect them from the service being abused. "We cannot track you or wipe your device. We designed the protocol in such a way that makes it impossible for anyone but you to do that." That stands in direct contrast to Android Device Manager, for example, which stores location information on Google's servers. In addition, that code is closed, so it will be difficult for anyone to verify what, exactly, it does. There are other Android solutions, of course, but seemingly none that are open source—or focused on user privacy.

The new feature has not yet been added to the CyanogenMod nightlies, but can be found on GitHub for those interested in testing. Some more details about the implementation, and its privacy protection, can be found in a Google+ post. There are three pieces to the puzzle: an app running on the phone, code on the CyanogenMod servers, and a JavaScript client running in a browser. To communicate, the browser and device set up a secure channel, mediated by (but not visible to) the server.

In order to set up that channel, the browser generates a public/private key pair and prompts the user for their password. The password is cryptographically hashed (using an HMAC, hash-based message authentication code) with the public key and sent to the server, which forwards it to the device. The device can extract the public key by reversing the hash operation using the password (which it must also have). It then creates a symmetric session key that it encrypts with the transmitted public key and sends it to the browser. The server cannot decrypt this session key because it doesn't have the private key, but the browser can, so a secure channel is established.

At that point, the browser can request location information or ask the device to wipe the personal data stored on it. It could also request the device to ring, which could be handy if it is simply lost under the sofa cushion. Other actions (e.g. remotely taking pictures) are obviously possible as well.

So far, the main criticism of the feature is its web-based nature. A man-in-the-middle attacker could potentially feed dodgy JavaScript to the user's browser, which could, in turn, send password information onward. That problem should mostly be mitigated by using HTTPS to connect to the CyanogenMod server—but what if that server itself has been compromised? Based on recent events, it is not just "traditional" attackers that are being considered here, but also shadowy government "security" agencies with secret orders to force the project to serve malware. That is an unfortunate failure mode for all web services these days (and, sadly, probably long in the past as well), but the code is open, so one can at least run their own server—and await a (presumably unlikely) visit from said shadowy entities.

The announcement also mentions plans for further services to be added to CyanogenMod Account. One of those is a "Secure SMS" system that Moxie Marlinspike is currently working on, presumably along the lines of his TextSecure application. In the meantime, the track and wipe feature will eventually make its way into the nightlies and then into a release. Before too long, CyanogenMod users will have a superior solution to the lost phone problem.


(Log in to post comments)

CyanogenMod Account: Remotely track or wipe phones

Posted Aug 22, 2013 12:34 UTC (Thu) by MKesper (subscriber, #38539) [Link]

I always wonder how useful that really is. Just copy all useful data from the phone via FROST (spies) or immediately reflash and sell it (ordinary burglar).

CyanogenMod Account: Remotely track or wipe phones

Posted Aug 23, 2013 0:32 UTC (Fri) by davecb (subscriber, #1574) [Link]

I'd like a public-key-based operation that invalidates/smashes the local session key used to encrypt all my personal stuff on a work phone, or all my work stuff on a personal phone.

Whoever owns data can invalidate it, but no-one else. That keeps an employer from deleting my stuff before I can back it up (;-))

--dave

CyanogenMod Account: Remotely track or wipe phones

Posted Aug 27, 2013 0:18 UTC (Tue) by idupree (subscriber, #71169) [Link]

So, if I use this, anyone who can guess my password can spy on me using my phone? Sounds high risk... perhaps this is a job for a long randomly-generated password (dice or /dev/random)?

CyanogenMod Account: Remotely track or wipe phones

Posted Aug 27, 2013 20:38 UTC (Tue) by kleptog (subscriber, #1183) [Link]

The password is cryptographically hashed (using an HMAC, hash-based message authentication code) with the public key and sent to the server, which forwards it to the device. The device can extract the public key by reversing the hash operation using the password (which it must also have).
This is wrong. If I read the G+ post properly, what happens is that the public key is signed using an HMAC using the password as key. The device can then verify the public key is the real one by testing the MAC using the password it has. So the key is authenticated, but not hidden in any way.

The words "reversing the hash operation" are a bit of a red flag, since the whole point of a cryptographic hash is to not be reversable.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds