L2 Federal Resources, LLC | Expert-led training and education for the government contracting community.
Expert-led training and education for the government contracting community.
  • Home
  • Live Webinars
  • Recorded Webinars
  • Blog
  • About Us
 
 
 
Blog Post | By Jon Levin | Sep 28, 2011 | Comments (0)

iOS v. Android – Is Either Ready for Government Primetime? Part 1

In a talk given on September 7th, the U.S. Coast Guard’s CIO, Rear Admiral Robert E. Day said:

Until Apple and Android get their operating systems (OS) locked down they will not be .mil endpoint.

That is a big statement considering that private sector workers have been harnessing the productivity and efficiency benefits of both operating systems for several years now. Government employees are only now gaining approval to use the operating systems for certain civilian jobs. The military is exploring apps for use on the battlefield. The big question that remains for pretty much every government adopter is security.

The two major mobile operating systems, Apple’s iOS and Google’s Android, handle their security differently, opening each up to different types of attacks. This makes it more difficult for the government because they are unable to issue blanket security protocols and have to customize their networks to interface securely with both operating systems.

Today, in Part 1, we’ll analyze the security of Apple’s iOS.

The Basics of Mobile Security

There are five pillars to securing a mobile operating system:

  1. Traditional Access Control – Protecting devices that have fallen into the wrong hands with methods such as passwords and locking when idle.
  2. Application Provenance – Each application on the device is stamped with unique author data, making it more difficult for hackers to alter code of existing applications for malicious purposes.
  3. Encryption – This protects data stored on the device from being decipherable should it be accessed by a hacker. Remote-wipe functionality is also included in this pillar.
  4. Isolation – Each application is basically on its own little island and they cannot interact with each other, preventing one malware infested application from spreading it’s virus to others and eventually infecting the ones that hold sensitive data.
  5. Permissions-based access control – Each application is issued a set of “permissions” for what it can and cannot access regarding the devices data.
Apple’s iOS Security

Apple’s OSX operating system that runs on their mac computers has long been held as one of the most secure consumer operating systems out there, but how does it’s mobile OS stack up?

Well, iOS is built based on a stripped down version of OSX and for the most part – when it comes to consumers – it’s fairly secure. Apple relies heavily on pillars 1-4, and leaves permissions based controls pretty much out of it’s equation.

On iOS, traditional access control is pretty standard, employing passwords and idle-timeout locking as security measures to protect the device in the event of loss or theft. These are pretty standard and Apple is about even with other OS’s on this front. Where iOS really shines though is application provenance. By creating the App Store, Apple also created a very unique way that each developer “signs” their finished product app, thereby ensuring that the listed and registered developer is the last person to have altered the code on a particular app. For corporations seeking to distribute custom developed apps to their workforces through the iOS Developer Enterprise program, Apple requires that they provide a wealth of corporate information including a DUNS number to be certified. By tying developer identity to apps, Apple has created a serious deterrent to hackers who often go to great lengths to conceal their identities. Moreover, Apple tests each and every app that they publish on their app store for security issues and while it’s possible that malware could slip through this process it seems unlikely given Apple’s track record.

iOS is also strong when it comes to isolation, because each app operates as though it’s on its own island and apps are prohibited from interacting with each other. This means that if somehow an app containing malware gets through Apples provenance protection mechanisms and through Apple’s manual check and somehow ends up on the device, it still cannot infect or commandeer other apps on the device.

Where Apple is weak however, is their encryption system. For encryption to work, the device must store a decryption key. However, iOS allows apps to run in the “background,” essentially never turning off. For these applications to operate this way, they need to store the decryption key locally to facilitate the apps access to user data stored on the device (often critical for apps to do what they’re supposed to do). The problem is, if a copy of the decryption key is being kept at hand it opens up the possibility that malware could gain access to the key and use it to access sensitive information stored on the device.

According to a Symantec report issued this summer, there are still some very real vulnerabilities to iOS’s encryption strategy that would prove very costly to troops on the ground. The report says,

In a February 2011 report, German security researchers from the Fraunhofer Institute showed that using a six minute-long automated process, they could bypass the hardware encryption protections on an up-to-date, passcode-locked iPhone (running iOS 4.2.1) and obtain passwords and login information for most of the device’s systems, including its Exchange email passwords and credentials, Wi-Fi passwords, VPN passwords and voicemail passwords.

This is the type of vulnerability that is completely unacceptable if the iPhone is to be used for any military or classified application. Now, its very possible that devices at risk of this kind of attack, those in the hands of personnel that could be captured, killed, or robbed, could be maintained devoid of any sensitive information – but it begs the question of “what if?” And as well all know, that question is enough to deter the federal government and especially the military.

Implications for Government Adoption

It is very likely that the public version of iOS will remain too insecure for widespread government adoption. But, it is possible for agencies or the military to contract directly with Apple to create a stripped down version of iOS that is more secure. The key functionality of iOS would remain unchanged – the nimble and highly adaptable touch screen capability, the crisp picture, the fantastic design and tech specs of their devices and the app based system for running software. The question is – will Apple apply their usual price-hike and will a newly cost-conscious government be receptive.

While the government and military will continue to test the “effectiveness” of Apple devices on the battlefield and for governance, signs from the private sector indicate that they will find the nearly endless capability of the devices and iOS to be better than the technology they are employing now. So really, it’s not if but when.

Update: check out Part 2 and an analysis of Google’s Android mobile OS.

The Contracting Post
Calvin Ngo
Contributor
Jon Levin
Editor
  • Facebook
  • Twitter
  • LinkedIn
  • RSS

Most Popular

  • Recent Cases Show Increasing Government Concern Over Organizational Conflict of Interest
  • The Basics of Certified Payroll (Complying with The Davis Bacon Act)
  • Five Keys to Small Business Government Contracting in 2012
  • 3 Important Changes to the FAR Prevent Abuse of Interagency Contracts
  • What is Sequestration and How Will it Impact Contractors?

Archives

  • June 2010
  • July 2010
  • September 2010
  • October 2010
  • November 2010
  • December 2010
  • February 2011
  • March 2011
  • April 2011
  • May 2011
  • June 2011
  • July 2011
  • August 2011
  • September 2011
  • October 2011
  • December 2011
  • January 2012
  • February 2012
  • March 2012
  • April 2012
  • May 2012
  • June 2012
  • July 2012
  • August 2012
  • September 2012
  • October 2012
  • November 2012
  • December 2012
  • January 2013
  • February 2013
  • March 2013
  • April 2013
  • May 2013

Sign up for webinar announcements:
L2 Federal Resources, LLC © 2012 All rights reserved. | 1724 20th Street NW, Suite 101, Washington, DC 20009 | T 202.238.9596   E info@l2federalresources.com
WordPress development by KornDev