Requirements for a smartphone anti-theft App

Question

I recently installed Cerberus in my [personal] Android device to get some protection against theft (I'm not really interested in protecting its data, but rather in increasing the odds the device will be eventually recovered). But I'm worried that using this App (or similar others) might expose me to a greater risk of losing control of my own device, either by accident (bugs in the Cerberus system) or mallicious activity (attackers taking control of Cerberus' website).

Clarification: the question is not about how to physically protect the phone, but rather about the digital risks I'm taking when employing a computerized solution to said problem (with the constraints that this scenario impose - attacker with physical access to device, no guarantee of internet connection, etc).

Please note that I'm not requesting a shopping recommendation, but rather trying to work out all the details I should be aware of when looking for (or maybe even developing) a solution. I know compromises will be made, but I'd rather not be more lax than necessary in the digital aspects while I try to harden the physical ones. And the issues are not necessarily about Android, it should apply to any mobile device.

Details

• Feature: allows remote control of the device by sending it SMS commands.

  • Why it's necessary: it might be the only way to reach the phone if internet is disabled.
  • Concern: the password is sent in the SMS body.
  • Mitigation: change the password every time this feature is used (after the device recovery).

• Feature: allows remote control of the device by using a web-based interface (the user can enable internet access by a SMS command if necessary).

  • Why it's necessary: a server is needed to do the hard-lifting - communicate with the device, collect its info and do something with it (usually e-mail it to the legitimate owner). While simpler commands might be possible without it (ex.: enabling the GPS and sending coordinates back by SMS itself) others are not, due to the message size (ex.: taking a picture or recording a short video with the front camera while the thief is trying to operate the phone and e-mailing it to the owner).
  • Concern: if the server has enough credentials to authenticate itself with the device (otherwise it couldn't control it), then if the server is compromised the device becomes vulnerable to several attacks (locking the legitimate owner out of his device, tracking it, or wiping all its data).
  • Mitigation: a) using a server that you control, not a third-party; b) using some kind of OTP that the user must provide, so the server can't do anything if the user is not in charge; c) disabling features with damaging effects (i.e. enable finding the phone disregarding the privacy risk, disable wiping the data disregarding the data theft risk, etc).

AFAIK these two features are the only ones that could be problematic, but if anyone has more info about things I should be careful with, it will be welcome. As an additional clarification, I'm aware that someone with physical access to the device - and enough knowledge - might be able to get rid of the App (though this one in particular was designed to survive even a factory reset). But I'm assuming it's not a trivial task, if I'm mistaken - and trying to recover the stolen device is in fact pointless - I'd like to know it so I can abandon this idea altogether.

Answer 1

There are documented cases where the theft recovery tools were used against a legitimate user, so your concern is justified. In general, if I was designing such a system, I would want the password to take control of the phone to only be known by the user and not stored on the service provider's system.

I would also want the password to be used to generate time based and one time use codes to send via SMS so that the phone would never respond to a replay and would not send the password clear. Since a phone has a reliable time source (the cellular network), it should be possible for the phone to keep a good time sync with the server for this purpose.

It would still be potentially possible for the device to be hijacked, but it would require then require the user to allow their device password to be compromised.

Answer 2

Just to add to the suggestions that AJ gave which are all very good. The ability to persist the cerberus app and configuration across a factory reset is useful since after a wipe there is still the potential that the user recover the device even if a hijacker does a reset unless they were to re-flash the roms of the device. This post had some details of the change to the app that made it able to survive a reboot, but that would also imply that if you got rid of the device or phone it would need to be flashed back to a factory state or it could put a new user at risk of being monitored potentially.

Answer 3

A radical way to protect against data theft is not to store your data in the smartphone. I know this is both extreme and a substantial shift from the smartphone-as-computer model. However, when your data is stored in a server somewhere (e.g. a server your rent), then the smartphone is only an access terminal, and the theft of the smartphone does not entail the theft of the data. External storage is also, by definition, a very efficient backup strategy, always up-to-date, so this also works well against data loss.

As for the theft of the phone itself... well, regardless of the apps you install, it seems improbable that the thief will give your phone back to you. You will still be down a few hundred bucks. The only way such apps could prevent the theft of the hardware is if you had an app which could remotely kill the device without any hope of salvage -- and if you made it widely known that your phone is thus booby-trapped.

By mixing the two concepts, you get the requirements for a good anti-theft app:

• All data on the phone is encrypted with a strong password (or equivalent security code) that you agree to type regularly on the phone (the phone should "auto-lock" after some time of inactivity).
• As a second layer of defense, have a "kill switch" with a SMS; if the phone receives a SMS with a special code, it wipes out the data.

Of course you should retain copies of both codes on a paper in a safe place (e.g. at your home). There should be no server involved in the process: you don't want to give your data encryption password, and certainly not the self-destruct code, to a server that you do not completely control (and if you have a server that you completely control, then you'd better store your data there, not on the phone).