Secure Mobile Applications – an Oxymoron?

By Marcus Perryman
Software Design Engineer, Microsoft Corporation

See other Viewpoint articles.

“Security” and “mobile application development” rarely appear in the same sentence. I recently talked to a number of developer audiences from around the United Kingdom about mobile application development. When I asked how many were interested in any aspect of security, approximately 2 percent said yes. That was just 3 people out of 140!

If you are among that 2 percent, keep up the good work. But why are the majority of mobile developers so apathetic towards security? Is it true to say that “secure mobile application” is an oxymoron?

Some reasons for this apathy can be found by considering the development teams that build mobile applications; a large majority of applications come from small teams composed of two or three people who often create business start-ups in order to bring a niche product to market on a small budget. Occasionally, mobile development is a side project of an enterprise IT department that is looking to put a tick in the “mobile option” box for a larger desktop project.

In both cases, there is often little time or money available for the featureless, drab, and un-cool consideration of security. Security considerations are left to lurk unseen in the shadows of high impact features and exciting user interfaces that bring coos and gasps from the chief technology officer, prompting a reach for the check-book and pen.

In other situations security is perceived as a barrier to usability; users know that mobile devices and software are all about the convenience of data at your fingertips, and the complaints come flooding in about having to enter a password just to check the status of an order.

These are just two objections from a long list, and there is no denying a core of validity to these arguments: spending time on security is likely to remove more features than it will add; it is likely to lengthen initial project time and cost estimates; and privacy versus usability is always a trade off.

So is this anything new? The same battle has been fought in the desktop and server space for many years. And, it continues on. There are a plethora of experiences, failures, and successes that can give guidance in the emerging mobile space. We don’t need to make the same mistakes again just because we’ve shifted the platform from a desktop beast to something that sits in your shirt pocket – they are both, after all, just computers, right? The rules of Trustworthy Computing still apply: Security, Privacy, Reliability and Business Practices.

Building Secure Mobile Applications

Maybe we should turn the question around: why should every mobile developer care about security?

Trustworthy Computing applies regardless of the hardware: the user expectations for a robust solution still exist; information supplied in confidence is expected to be kept in confidence; and a mobile worker doesn’t want his or her cell phone to become the source of unwanted code entering the corporate network.

When it comes to security, Mobile application development should march to the same beat as desktop development. Early in the design process it’s important to build a clear picture of the assets involved in the solution and understand the threats and potential vulnerabilities, to help reveal risks and their potential impact. Integrate security into the software development lifecycle using techniques such as threat modeling by running through the STRIDE steps of Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Armed with new levels of clarity and understanding its then possible to make design choices and direct developer attention to mitigate or completely avoid risk revealed through these processes.

There are a number of techniques and a huge amount of information available that address how to integrate security in the development lifecycle and threat modeling is just one of the more commonly used processes. The choice of which process or framework to use will depend very much on what’s appropriate for your specific development team dynamics, but what’s most important is that a strategy is chosen and implemented. If you are looking for somewhere to start, consider the patterns & practices Security Engineering paper or The Security Development Lifecycle book by Michael Howard and Steve Lipner.

Considerations Specific to Mobile Solutions

While it is true that the basics of security for mobile platforms are the same as those for desktops, the security risks and security considerations vary somewhat because of the nature of mobile users and mobile hardware. For example the likelihood of leaving your cell phone powered on and unlocked in the back of a taxi are considerably higher than leaving your laptop in the same state. Therefore it is important to understand your applications assets and the business impact of a lost or stolen device.

Here are just a few of the considerations relevant to mobile applications (see Application Security, Deployment and Management MSDN article for more mobile security information):

Data Entry Considerations

User interface design is very tricky for the restricted screen real-estate and the limited input of a numeric keypad. It’s important to get the balance right between the amount of information displayed and the number of key presses needed to access data. Passwords are an integral part of this challenge. Making users enter a 10 digit alpha numeric password every 30 seconds might mean the corporate security officer gets a good night of sleep, but it’s likely to make users simply switch the device off and use pen and paper. Plus there is always the risk of users taping the password to the back of the device (I’ve seen it happen!).

In these circumstances, the trade off might consist of removing some restricted data from the mobile application in order to allow for a shorter password. Or, consider a two stage lock in which the user is required to enter the full password at less frequent intervals and a short PIN number to confirm the user identity at more frequent intervals. Biometrics are available for some devices, and other two factor solutions such as a smart card or card swipe can also simplify user input.

Cryptography

Windows Mobile includes an implementation of the Cryptography Application Programming Interface (CAPI) and supports a good range of features including symmetrical and asymmetrical encryption algorithms. In addition, the Microsoft .NET Compact Framework 2.0 has managed classes that are in line with the desktop framework classes and provide simple access to the crypto library. This is all good, and appropriate use of these features to provide data privacy is encouraged. However some care needs to be taken for mobile solutions.

In general, the processing power of a mobile device is about two to three years behind today’s desktop equipment, so the CPU strain sometimes has to be considered when designing a mobile solution. Asymmetric algorithms can take a significant amount of CPU effort to process and can slow the device noticeably. When using asymmetric encryption, it’s wise to restrict the safeguarded data to the critical components and to decrypt only when it’s required for display or program use - often it’s enough to use a symmetric key for the bulk of the data then encrypt the symmetric key with asymmetric encryption, so relieving the CPU load and having a positive impact on the battery life of the device.

Key Management

When using cryptography there always has to be a master key of some description and that introduces key management. Key management brings its own challenges regardless of platform, but mobile device key management can become an acute problem. Windows Mobile doesn’t offer a machine or user protected store for key management in the same way as the Windows XP or Windows Vista operating systems do, so storage of keys on the Windows Mobile powered device is tricky. Storing the master key in code or on a file on the store is rarely an acceptable solution because Windows Mobile does not implement object level security; therefore files cannot be individually restricted from external access by other processes or via a technology like Active Sync. By far the easiest and safest way to deal with a master key is to give it to the user and remove the problem from the device – that means deriving your master key from a user password at the perimeter of the device or at the perimeter of your application. One other solution that can be satisfactory in some cases is to use one of the unique IDs available to a mobile device such as the International Mobile Subscriber Identity number (IMSI) for phone based devices or the unique device ID that each Windows Mobile powered device contains. However, care should be taken when using this type of data because if the key data is available to your application, then it will be available to other applications or in the case of the IMSI it might be possible to retrieve it interactively through the keypad of an unlocked device.

Windows Mobile also provides the Data Protection Application Programming Interface (DPAPI) functions such as CryptProtectData, which make use of a device specific key in order to protect data from off device attacks. Using these APIs in conjunction with device application security set to limit only signed trusted applications from execution, an application can create files or data stores on the device that are only readable by the device on which the store is created. For more information about configuring device security policy click here and for DPAPI click here.

Buffer Overruns

The traditional buffer overrun that changes a function return address by overrunning a local stack variable has been very problematic on Intel X86 powered computers, but it relies on a stack architecture that grows downwards from a high memory address with the return pointer stored above local variables. Mobile devices use a different CPU architecture and instruction set making these types of attacks dramatically harder to achieve and viruses that use these techniques much less common on mobile devices today.

Additionally a device’s Internet Protocol (IP) address changes often as the device moves between wireless base stations, and there are few applications listening for inbound communication. In fact the reduced functionality of the device means there is less code available to be attacked.

These are not excuses to become complacent! Always-connected devices are what the industry is driving towards and often these devices are used for Internet browsing and corporate network connections. With the number of devices in circulation it’s just a matter of time before a usable attack is documented and shared.

Buffer overruns have the potential to be damaging in many ways and are not limited to just attacking the return address of a function, and mobile applications, regardless of CPU architecture, are just as vulnerable to these types of attack. Using managed code for your application such as C# or VB.NET in addition to a sensible development process with code reviews and security reviews provides good mitigation for these risks.

Protecting Windows Mobile

Windows Mobile offers many infrastructure features and developer tools that can be used to create a security strategy to protect the device and the applications that it hosts.

First, a perimeter security policy can be set by the user to require a PIN or password and provide a first level of defense to access the device. This mechanism is implemented through the Local Authentication Sub System (LASS) and can be augmented through custom Local Authentication Plug-ins (LAPs) – a way of supplying a custom user interface and authentication. For the enterprise mobile application this can be a very useful tool for capturing a master key from the user and propagating it to applications running on the device. Click here for more information about LASS and LAP architecture.

Another primary protection mechanism is implemented via code signing. Windows Mobile checks each and every executable module such as Dynamic Link Libraries (.dll) and executable (.exe) files as they are loaded to validate that the code is signed, the signature is valid, and the signature matches with a recognized certificate installed on the device. Windows Mobile can be configured to block execution of code that doesn’t match these criteria thus protecting the device from malicious code. Software installation through CAB files is also protected by this process with its own certificate store, and a revocation store is available on the device to block execution and installation of rogue applications. In addition to code signing Windows Mobile uses security roles associated with certificates in the store to restrict access to files, registry keys and other assets within the system. Click here for more details about code signing security on Windows Mobile.

For relational data there are a number of solutions for storing information on mobile devices. Microsoft SQL Compact not only provides a rich and versatile relational store on the device, it also includes options for data encryption and password protection. Click here for more information about Microsoft SQL Compact.

There are many other areas I haven’t covered here such as secure communication, server authentication, device management (i.e. remote wipe) and virus checking. For more information on these and many other security considerations for mobile devices, head over to the Security, Deployment and Management pages of the Windows Mobile Development Center.

Summary

Security is not an insurmountable challenge, and it definitely applies to mobile applications. There are tools and resources available to help you build trustworthy mobile applications. Doing nothing might feel like the cheapest and easiest option, but that is a very short term view. If you want to gain the trust of your customers, whether they are internal enterprise users or the general public, you need to write software that does what it’s supposed to: safeguards the data that the user cares about and does not become the point of entry for malicious code on their devices. If you haven’t thought about security for your mobile project, now is the time to start.

“Secure mobile application” is not an oxymoron but it’s up to each individual developer to take on the challenge and apply security throughout the development lifecycle.