iPhone Security

Here is an article on the ABA site regarding iPhone security problems.  (click here)  The authors, Sharon Nelson and John Simek, point out three basic problems with the iPhone: (a) the security features to encrypt the iPhone can be hacked via a series of steps involving SSH, (b) remote wipe can be circumvented by leaving the iPhone off the 3G network, and (c) the PIN to unlock the iPhone can be circumvented when the phone is placed in recovery mode.

For most iPhone users, the phone is used to synchronize email, calendars, and contacts.  All of these may have some confidential information in them.  As for email, most users don’t encrypt their email in the first place, so all the messages sent and received between lawyer and client are susceptible to being intercepted when they leave the walls of the law practice.  This is a problem that pre-dates the iPhone.  As to stealing an iPhone to access email – it frankly might be easier to just attack the user’s Outlook Web Access account that is published through their firm’s web site, or attack the Exchange server directly if it is available via SMTP.

Calendars are another problem.  Most attorneys do put some information into calendar events to tell them they are meeting with a client, the client’s name, and the purpose of the meeting.  Lawyers generally do not append 10 page client summary documents to calendar items, so the calendar itself, while having some information that is arguably confidential, would not be fatal if lost.  Contacts on the iPhone would also likely give a hacker some idea of who the lawyer’s clients are and how to reach them, but other than private cell phone numbers, there usually is not much more info about clients in the address book.  (Firms should probably stop and think about whether the above generalizations are true for them.  If there is a lot more confidential information in these items, you might need to consider more substantial mitigations for the risk of loss of the phone).

To me, the bigger risk would be if lawyers are using their iPhones to store confidential documents received from the client to read them on the way home, for example.  There are also other security items like usernames and passwords to access client systems that might be stored on the iPhone for the convenience of the attorney.  I would argue that these kinds of files should not be on any smartphone.  Instead, such items should not leave the firm, but should be accessed via some kind of secure web site controlled by the firm as a matter of policy.

The authors also point out that the iPhone’s remote wipe feature, which represents a mitigation for the scenario of the lost iPhone, is insufficient if the iPhone is taken off the wireless 3G network, because the device cannot be located to be wiped.  Of course, this is the way that the Blackberry remote wipe policy works for Blackberry Enterprise Server users, so, while a problem, the iPhone is in good company (the ABA conducted a survey in 2009 of smartphone usage in law firms, and the majority used Blackberrys).   The authors cite Windows Mobile as having figured this out, but, I’m pretty sure Windows Mobile is on the way out of the market.

In conclusion, the authors are right that there are some security problems with the iPhone, and attorneys should think about those issues to protect the confidentiality of their work product.  But all technology presents risks for users which must be balanced by mitigations that are reasonable for the circumstances.    To this humble author, some of those mitigations should be implemented, regardless of the smartphone being used.

Published by


Maryland technology attorney and college professor.

One thought on “iPhone Security”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.