Mobile Phone Security: Flawed Out of the Box?

phone with key on white background. Isolated 3D imageAccording to an article in the Wall Street Journal last week (subscription required), smartphone makers are receiving an increasing number of requests from U.S. law enforcement agencies for assistance in bypassing password protections on encrypted mobile devices seized from criminal suspects. Although it is heartening to hear the article’s report that companies such as Google are challenging warrants requiring them to divulge “any and all means of gaining access, including login and password information, password reset, and/or manufacturer default code” for a phone running the Android operating system, it is equally alarming to hear that smartphone makers are receiving such requests in the first place. Unless they are nothing more than trial balloons, the fact that law enforcement agencies are directing such requests at smartphone makers suggests one of two unappetizing possibilities:

  1. smartphone makers are surreptitiously maintaining databases containing the passwords of every device running their operating systems; or
  2. smartphone makers have programmed “backdoors” into their operating systems allowing them to circumvent encryption and other security measures upon request.

There is no denying that law enforcement agencies sometimes require access to smartphone data for legitimate investigative purposes, and that obtaining such data is becoming more difficult as encryption becomes more pervasive. The trouble is that this law enforcement need does not justify the kinds of measures that smartphone makers are suggested to be taking to satisfy them. Quite apart from the fact that encryption backdoors and databases of device passwords are ripe for abuse by rogue employees or overzealous government officials, both measures involve creating security flaws in mobile devices that ne’er-do-wells will only be too happy to exploit. A database containing every iPhone and Android device password stored on Apple or Google’s servers makes for a mighty appealing target for a hacker, just as we can be sure that commercial spies and foreign intelligence agencies are working hard to figure out how to exploit mobile encryption backdoors for their own purposes.

There is no easy way to balance the growing need for encryption in an age when we carry all of our information on devices that are easily stolen or misplaced, with the need to provide law enforcement with access to such devices for investigative purposes. My own view is that this balance might be better struck by interpreting the constitutional privilege against self-incrimination as not always protecting against the compelled disclosure of encryption passwords, for this is a “less bad” outcome than having to live with compromised encryption and the many cyber-risks this entails. Other reasonable people will surely disagree, which is why a broader public debate on these issues is of the essence.

In the meanwhile, mobile phone makers have a duty to disclose to their customers whether the encryption software they are including on their devices is compromised by backdoors for law enforcement or other purposes, and also whether they are engaged in collecting and storing the passwords we use to keep our data safe from prying eyes. The Wall Street Journal article reports that spokespeople for Microsoft and RIM confirmed that they do not collect or store device passwords, but representatives for the big four mobile companies (Apple, Google, Microsoft, and RIM) need to be transparent with the public on whether their products contain backdoors. Customers have a right to make informed choices about how and where they store their data, and some may well choose not to trust their digital devices with certain kinds of information if their security measures are defective right out of the box.

Tags: Categories: Privacy, Security, Technology Comments Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *


+ six = 10

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>