Open-source sore point: No Android for your agency

Android-based smart phones are all the rage these days -- unless, of course, you work at a federal agency.

Google and the Open Handset Alliance’s version of a mobile operating system has been exploding in the consumer market for the last year, to the point where it may actually dethrone Apple’s iPhone while further distancing itself from BlackBerry in terms of smart phone market share. The problem with Android, though, is that it is difficult to implement into existing security protocols for federal agencies.

Related stories:

The wait goes on for BlackBerry's tablet PC

iPhone users get government search, 'snitch' apps

It seems like it should be a relatively straightforward concept: bake Federal Information Processing Standards 140-2 (FIPS) right into the phone and give enterprises and agencies the ability to configure security as needed.

Yet this is not common practice for device-makers. BlackBerry has been doing this for years, but the other major smart phone players – Apple, Google and Microsoft – are behind in their efforts to cater to the federal space and security-minded enterprises. According to the National Institute of Standards and Technology (NIST), which controls the labs that test FIPS security algorithms through the Cryptographic Module Validation Program (CMVP), Apple does have a couple FIPS security features in testing for the iPhone and iPad, as well as a general cryptographic module that is likely for desktops and notebooks. Microsoft has had its Windows Mobile CE (versions 6.0 and 6.5) certified, but Windows Mobile 7 hasn't been yet.

Then there is Android.

There are multiple ways to get a device FIPS-certified. It can be like BlackBerry and bake encryption algorithms and other security functions straight into the phone. The phone carriers – AT&T, Verizon, T-Mobile and Sprint – can implement FIPS capabilities on top of the mobile operating system, or third-party security software can be implemented.

“It could be a number of ways, such as a third-party application with a cryptographic toolkit,” Randy Easter, director of the CMVP at NIST, said. “Others [manufacturers and developers] could use that as a model.”

The open-source nature of Android makes it difficult to determine the way to go about certifying the devices. Since the code is open, putting security algorithms straight into the source code would defeat the purpose, since any hacker could look it up to exploit it. Developers at Google bake up the program code for the operating system and then, more or less, unleash it into the wild for application developers and device-makers to do with as they please.

That means that, unlike Apple or BlackBerry, Google rarely is involved in the vertical integration of the making of devices that use its OS (with the standard-bearers Nexus One and Nexus S as exceptions). Android device-makers – Motorola, Samsung and HTC are the major ones – decide what hardware and software specifications their Android devices ship with, and the carriers also have a say in which applications are integrated into phones. So, Google, by its definition of being an open-source OS supplier, cannot rightly bake encryption straight into the kernel code of the Android OS and expect the varying players to adhere to it. When it comes to the consumer market, FIPS-level security is not a major concern.

“Device OEMs building on Android follow the same paths as their competitors -- Apple, RIM et al,” said Bill Weinberg, senior executive and mobile practice manager with The Olliance Group. “Depending on the government tender or other opportunity, they work with the requesting agency a listed government contractor and in many cases a third-party integrator as well.”

Easter said he is not aware of any Android-specific tests coming through the FIPS queue at NIST but that it is often hard to determine exactly what some of the algorithms that CMVP tests are to be used for. Cryptographic toolkits do not have to be device-specific.

“Unless they call it the ‘Android cryptographic module,’ we are not going to find it,” Easter said. “In the hardware world, it is easier to see what is validated; that is what you purchase. In software it is usually embedded into a larger product which makes it harder to identify.”

There are a few programs available to developers who want to try to FIPS-certify Android phones. Mocana Corp. has a software developer FIPS toolkit it calls NanoCrypto that has been certified by NIST (called the Mocana Cryptographic Suite B Module in the NIST database). It is software for developers so reasonably an agency’s IT department could use it to FIPS certify devices. Manufacturers could also use it to bake a cryptographic module straight into devices. The current Android kernel, which is based on Java and Linux platforms, is Linux Version 2.6. The only FIPS validations in the NIST module database for 2010 that support that kernel are from Mocana.

Virtualization platforms, such as what can be found from Open Kernel labs, can help with FIPS certification programs. It can either help integrate third-party packages like Mocana’s or create a separate, isolated series of code in the device as a virtual machine that runs security.

“Mobile virtualization platforms like OK Labs OKL4 Microvisor can ease FIPS certification by both simplifying integration of pre-certified packages like Mocana's and by isolation cryptographic code in a separate virtual machine, creating a more secure and smaller FIPS base that serves open OSes like Android but is not physically a part of such an OS,” Weinberg said.

Open Kernel offers its product to original equipment manufacturers, device-makers, contractors, integrators and agencies themselves to create FIPS level certification on devices across all the major mobile operating systems.

Yet, since it is just a software kit, Mocana can only be FIPS-certified at Level 1, which does not call for physical security implementations and will not be enough for many agencies' security needs.

"The role of virtualization is to make it possible to achieve different levels of certification for different software subsystems which share the same hardware," said Rob McCammon, vice president of product management at Open Kernel. "Getting a high level of FIPS certification of a complete Android environment would be very difficult because of its complexity and its openness. With OKL4 provided virtualization, however, a separate service, running in a separate virtual machine, can be much more easily certified to a higher level of security. The isolation provided between the Android VM and the 'secure service' VM makes it possible to exclude Android from the scope of what is being certified, as if it was running on physically separate hardware."

For instance, the Treasury Department does not support Android phones and only covers BlackBerrys.

“Employees with an Android-based phone can still access e-mail, but they have to use a secure portal," Treasury spokesman Matthew Anderson said. "E-mail accessed through a secure portal is not downloaded to the phone.”

“Unlike the BlackBerry, Android does not yet support encryption," Anderson said. "It is our security policy that a mobile device can only access Treasury resources if it encrypts all data and can be wiped clean remotely by issuing a ‘kill command.’ Android supports the kill command, but not encryption."

NIST CIO Del Brockett gave almost the same statement when contacted. He said NIST supports only FIPS 140-2 devices – and only BlackBerrys – on its network, but employees can access e-mail through other non-RIM phones.

The Defense Information Systems Agency has been working on device security on its own and has an application called Go Mobile that secures smart phones. Android functionality should be ready by late spring. Yet, this is an example of an agency being proactive in securing phones it knows its employees are going to want to use. Such preemptive action in IT security does not tend to be a trait that most federal agencies share with the Defense Department.

The problem that federal agencies face is that top job candidates want top technology and they want to be able to use it to its full capabilities. Restricting functionality on devices is no longer an option because employees will figure out ways around the restrictions or just not use the devices at all. Security is an end-user issue – only as strong as its weakest link, which often turns out to be users  – and the goal for any device manufacturer would be to make the phone FIPS-certifiable so that it also works to its full capacity.

“We have seen a growing demand for smart phones, and we are exploring how we may broaden our support in the future to include other operating systems,” Brockett said.

This aim becomes difficult with smart phones that are increasingly not just message-based platforms – voice, text, e-mail – which are relatively easy to secure. Smart phones now are integrated with Global Positioning System software, near field communications, media functionalities and a multitude of different applications available through markets that could be sources for information leaks from supposedly secure phones. Add the open-source nature of Android and the security headache is palpable.

Ultimately, it will come down to the original equipment and device manufacturers. Google is not in a position to make its phones FIPS-certified and the responsibility is not a traditional role of the carriers. Until the manufacturers start making FIPS-certifiable phones, it looks like federal employees are going to have to go sans-Android.