How to build a better smartphone: Architecting with mobile virtualization for secure military communications

Story

April 29, 2011

Military personnel and national security operatives are probably the most mobile workers in public service today, and depend on specialized and secure communications equipment to fulfill their missions at the office and in the field.

In the past, such secure communications devices – digital field radios, police/fire radio transceivers, and so on – emerged from highly proprietary design and acquisition cycles, resulting in systems that were hard to build, expensive to acquire, difficult to maintain, and impossible to upgrade. And they were yet another device for personnel to carry in addition to handsets and notebook computers.

Today, in lockstep with initiatives previously launched by the U.S. government, federal agency IT management and mobile device integrators and contractors are leaving behind the world of proprietary legacy systems and looking for COTS mobile solutions similar to those used by Jack Bauer on Fox TV’s “24” or the “ObamaBerry.”

The following sections explore using COTS hardware and software to create secure mobile communications devices. In particular, they focus on mobile security threats, lay out requirements for secure mobile devices, and present architectural options for integrating standard commercial smartphone device hardware with open source software and mobile virtualization. An Android proof-of-concept is also introduced.

Threats to mobile security

As mobile devices become increasingly similar to desktop and also data center computers, they suffer from the same maladies that plague corporate and government IT:

Vulnerabilities: Devices are subject to viruses, spyware, Trojan horses, and other malware. Application code bases and the middleware that supports them are large – tens of millions of line of code – and by definition untrustworthy and non-certifiable.

Buggy software: Mobile OSs and the software that runs on them are unavoidably buggy and thus are subject to a constant stream of zero-day attacks, which are exploits of application vulnerabilities unknown to the software developer. Open OSs supporting standard application development (such as RimOS and WindowsPhone) and open source OSs (such as Android or Linux) and applications that run on them emerge from commercial and community development of greatly varying quality and sensibilities – especially where security is concerned.

Brute force attacks: Mobile applications running on smartphones, including communications clients, are subject to Denial of Service (DoS) attacks on a per-process and system-wide level, for example. Of particular concern to government and other public entities are exploits that expose voice, text messaging, and other data streams to eavesdropping or other unauthorized third-party scrutiny. Another worry is the ability of unauthorized parties to interrupt mission-critical communications and spoof or forge participant identities and content.

A secure mobile communications device

Ideally, a secure mobile communications device such as a smartphone would be constructed from commercially available handsets and tablets that deploy off-the-shelf software platforms and applications running Android or Linux, for example. Devices need to support regular communications (voice, texting, social networking, and so on) and applications for “normal” conversations, but also enable secure exchanges (encrypted voice and secure texting/video transmission) among similarly equipped devices and/or infrastructure.

Ultimately, the scenarios of interest boil down to straightforward but difficult-to-meet requirements criteria. One requirement is that of secure communications, which refers to conventional applications including 3G voice, VoIP, Short and Multimedia Messaging Services (SMS/MMS), video, and so on, where clients run in secure contexts with options for encrypting data streams.

Open networks are also required. Using COTS hardware and software also predicates leveraging ubiquitous 3G, WiFi, and other public networks for private and secure communications. While GPRS, CDMA, 802.11, and so forth offer their own security regimes, those measures alone are insufficient to support secure and certified systems needs – they have been repeatedly demonstrated to be vulnerable to sniffing, spoofing, and other exploit techniques.

The requirement for off-the-shelf devices can also be difficult to meet. The vision for secure communications described herein builds on COTS hardware, but not necessarily mass-market handsets sourced through conventional operator and retail channels. Rather, secure communications devices represent collaboration of OEM handset manufacturers and third-party integrators and/or government contractors. Suppliers of aftermarket hardware encryption devices must also collaborate, such as vendors providing SD cards and/or encryption software running independently or leveraging existing capabilities in mobile chipsets. A concurrent requirement is that integration of these technologies still offers reasonable options for maintenance and upgrades, avoiding the expensive lock-in presented by legacy custom-built hardware and software.

Open software is also imperative. Smartphones and other devices suitable for the secure communications mission increasingly run open and/or open source OSs like Android, Linux, and so forth. As mentioned, a secure communications mobile device developer would be well advised to not replace those software platforms, but rather to augment or encapsulate them with secure and certifiable software.

Architectural options: Considering the candidates

Although this discussion emphasizes a COTS approach to secure mobile communications, it must also address the secure communications challenge holistically by considering several candidate architectures such as the following:

Point solutions

While requirements for mobile security are ubiquitous and system-wide, approaches to secure mobile communications tend toward single-function point solutions of limited scope in the software stack and communications stream. Such point solutions typically entail building and deploying secure and/or certified applications and middleware, encrypted data streams, and dedicated communications channels.

While constraining scope-of-effort is usually a good design and engineering practice, it ill serves modern mobile/wireless devices that are more like desktop computers than handheld radio sets. Unfortunately, these point solutions can still be compromised at an application level through cracking a saved or running application image, or by starving that application of compute resources (DoS).

Dedicated hardware

The most robust and secure method for isolating software is to run programs on separate pieces of hardware. Some mobile chipsets do feature unique companion processors to accelerate functions like graphics, video, audio, and in some cases, even encryption.

However, these dedicated coprocessors are configured as slave peripherals and do not provide sufficient context to run entire communications stacks and voice and messaging clients. In theory, more robust resources could be integrated on an SD card or other aftermarket interfaces, but then would lack means to transmit and receive secure data streams through an otherwise unsecured device without extensive modification to what should be a COTS OS and program stack.

Multicore architecture

High-end current-generation handsets and next-generation designs increasingly feature multicore application processors with two or more ARM processor cores. In theory, one or more cores could be dedicated to secure mobile communications, offering strong isolation from open OSs and open application environments.

In most cases, integrators or even OEMs would be hard-pressed to free up an entire CPU core for secure mobile communications processing, at least not without degrading overall device performance. (In a dual-core CPU, performance degradation could be up to 50 percent.) Moreover, even with a dedicated CPU core running secure communications loads, shared physical memory could still be subject to attack from the core(s) running an open application OS.

Virtualized architecture

A comprehensive and straightforward approach to architecting a secure mobile platform entails introducing mobile virtualization. This technology, like its data center cousin, runs over “bare metal” silicon to host an open application OS and software stack, or it could have one or more fully isolated secure cells (virtual machines) to host secure software in its own separate context. It could also have additional cells (as needed) to host selectively shared resources such as device drivers.

 

Figure 1: Secure mobile communications conceptual architecture with a microvisor

(Click graphic to zoom by 1.9x)

 

The benefits of a virtualized architecture are many:

• A very small trusted computing base (just the underlying microvisor) to ease certification and limit opportunities for exploits
• Deployment of existing off-the-shelf open OSs and software stacks in their own isolated cells
• Flexibility for integrators to instance new cells to meet the particular needs of a security regime and the technology to support it
• Capabilities-based security providing fully flexible dynamic protection management
• Defense against malware and security among cells through isolation and use of restricted intercell communications APIs – the visible open OS can become infected and fail without impacting secure communications software in other cells
• Fast Inter-Process Communication (IPC) mechanisms for high performance
• Resistance to DoS attacks through monitoring, prioritization, and load balancing among cells

Android proof-of-concept on the BeagleBoard

The mobile virtualization platform and security architecture depicted in Figure 1 builds upon a proof-of-concept announced by Open Kernel Labs last year. The OK:Android design for secure voice communications is based on Digi-Key’s community-driven BeagleBoard running a Texas Instruments OMAP3530 system-on-chip. It is detailed in a white paper available at www.ok-labs.com/products/whitepapers-abstract-page.

 

Figure 2: SecureIT Mobile proof-of-concept for secure voice using Android

(Click graphic to zoom by 1.9x)

 

The secure voice design uses OKL4 to split up phone resources among multiple mobile hypervisor (or “microvisor”) partitions, including one for OK:Android, one for secure communications, and one for shared server compartments. The latter includes shared server cells for audio, various peripherals, system functions such as clocks and power management, and a console for debugging. OKL4 can also facilitate secure video and texting in other instances.

From proof-of-concept to deployment

Previously, securing government apps, voice, and SMS required costly custom hardware and proprietary software stacks. This resulted in one-off handsets and radios, saddling government workers with yet another device to carry, locking in their employers to a single vendor, and presenting IT support staff with platforms that are difficult to maintain and impossible to upgrade. Today, several major government integrators and their partners are developing and deploying real-world secure mobile devices by building on mobile virtualization and off-the-shelf mobile hardware and software.

Rob McCammon is Vice President of Product Management at Open Kernel Labs, where he is in charge of the OKL4 product line. During part of his 25 years of embedded industry experience, Rob was also Director of Advanced Technology Planning at Wind River Systems. He holds a Master of Management from Northwestern, and an MS in Computer Engineering from USC. He can be contacted at [email protected].

Open Kernel Labs 312-924-1445 www.ok-labs.com