Mobile Application Security: Options For Keeping Your Data Safe
Mobile data security is possible with a little planning during the development stage. Eric Giguere discusses the pros and cons of various techniques.
Mobile applications are inherently less secure than their desktop equivalents by the very nature of the devices on which they run. Mobile devices are easily lost or stolen, which puts the data on them at risk. Just as important is the security of network communications with wireless devices, which normally use public wireless networks that do little to ensure data security.
Let's take a look at the different approaches you can take as a software developer in order to secure your mobile applications.
Using Built-In Security
Mobile devices often include built-in security features that the software developer should exploit whenever possible due to their stability and reliability. Four common features that may be supported are:
Secure data storage via strong encryption. Palm devices (starting with Palm OS 5) and BlackBerry handhelds (starting with BlackBerry 3.8) support automatic application-level data encryption.
Secure communications via SSL/HTTPS. Most mobile devices on the market today support network-level encryption. (Note that HTTPS support does not imply the availability of SSL to applications. In these cases, HTTPS can be used as a tunneling method for secure communication.)
Cryptography APIs. BlackBerry devices have long exposed their built-in cryptographic routines to application developers.
User-controlled security measures. Most devices include basic password lockout facilities, sometimes in conjunction with automatic encryption of persistent data. These facilities can even wipe the device in case of failed login attempts or in response to other events.
Impediments to Built-In Security
Unfortunately, not every device has the built-in security features that an application developer might need. Even if they do, those features may be limited or impeded in various ways. Here are some common scenarios that developers may face:
Restricted access. A device may include built-in security features, but access to those features may be limited to certain types of applications. On the BlackBerry, for example, most of the cryptographic APIs can only be used by applications that have themselves been signed using special keys obtained by the developer from RIM. Similarly, many J2ME devices provide access to advanced functionality, including security features, only to applications signed with a certificate obtained or approved by the device vendor and/or the wireless carrier.
Limited configurability. Assuming the necessary security features are present, it may not be possible to configure them appropriately. For example, installing a client certificate for HTTPS on the device is often not possible. If it is possible, it may be hard to deploy to individual devices.
Network limitations. On wireless devices it's not uncommon for carriers to control what ports and protocols a device can use for network communications or to only make them available to devices with a special data plan. Blocking of UDP messages is common, as is limiting HTTP access to well-known ports. Further complications can arise when network traffic is routed through a WAP gateway instead of a normal Internet gateway.
There's very little you can do about most of these scenarios, and instead you have to figure out how to work around them.
5 Top Federal Initiatives For 2015As InformationWeek Government readers were busy firming up their fiscal year 2015 budgets, we asked them to rate more than 30 IT initiatives in terms of importance and current leadership focus. No surprise, among more than 30 options, security is No. 1. After that, things get less predictable.