Bringing Android to military communications devices
StoryJuly 16, 2010
David Kleidermacher
Green Hills Software, Inc.
With the advent of multicore and hypervisor-enabled mobile SoCs, military mobile devices such as Type-1 PDAs and Software-Defined Radio (SDR) can now keep pace with the latest commercial mobile software initiatives such as Google Android while reducing costs and meeting the most stringent security requirements. In addition to the hardware advances, this goal is made possible with software technologies and architectures that include a layered approach to virtualization using a Multiple Independent Levels of Security (MILS) separation kernel and its high-assurance partitioning policies.
Communications devices that process classified data are typically architected with a standard red-black separation in which a red-side processor is responsible for cryptographic functions, and the black-side processor is responsible for communication stacks and drivers. On egress, classified information originated in the red side is encrypted and sent over some interconnect to the black side for transmission. On ingress, information received by black-side drivers is passed across the interconnect for decryption and any other red-side processing, such as guards and authentication. This general architecture is shown in Figure 1.
Figure 1: Communications device red-black architecture
(Click graphic to zoom by 1.9x)
|
|
Note that the logical red-side crypto component may include an attached special-purpose hardware device, such as an FPGA, for cryptographic algorithm execution, key storage, and physical redundancy.
Any software running within the cryptographic boundary falls under the intense scrutiny of the National Security Agency (NSA) during Type-1 certification. This naturally imposes a strict assurance demand and complexity limit upon the red-side software.
Software-Defined Radio
Now let's take a look at the red-black architecture in more detail, using the example of a Software-Defined Radio (SDR). More specifically, let's consider devices that employ the Software Communications Architecture (SCA), an open framework used to develop SDRs. The SCA provides standardized APIs for managing waveforms and other radio-relevant resources. The SCA lives on top of an SCA-compliant operating system. In an SDR, the SCA may be used in both the red and black sides. The black side will typically include components required to manage radio communications, including the waveforms themselves. Therefore, a Real-Time Operating System (RTOS) is often essential.
The red side may use less of the SCA's functionality. At a minimum, SCA-standardized message passing and component management functions would be included. Of critical note, however, is the role of the red side in managing plaintext. Human-Computer Interface (HCI) components, such as keyboard drivers, voice codecs, and touch-screen management software, will be included in the red-side processing. For example, a handheld radio operator may speak voice data that must be collected by the red side for cryptographic processing before it can be sent across to the black side for transmission.
As with any Type-1 communications device, minimizing the certification-relevant software content in the red side is a strategic goal of both SDR developers as well as the certifying agency. Because of its real-time and security-critical requirements, a trusted RTOS is a natural fit. An example architecture showing the major red- and black-side SDR components is shown in Figure 2.
Figure 2: Example SDR red-black architecture
(Click graphic to zoom by 1.9x)
|
|
Enter Android
While an analog voice radio has a relatively simple HCI, smartphones and multipurpose digital voice/data radios are but two examples of devices that may incorporate a far more sophisticated HCI. Android has quickly become one of the most popular HCI frameworks used in consumer electronics. Android, however, is built upon Linux, a monolithic operating system that does not meet high-assurance certification requirements and is not appropriate for low-latency, hard real-time tasks.
To incorporate Android into the red-side HCI of military communications devices without bringing its entire multimillion-line source code base into the cryptographic boundary, an obvious choice is to incorporate a second applications processor dedicated to Android. Adding a second processor, however, increases footprint, power, production cost, and system complexity. This is especially problematic in resource-constrained devices, such as battery-powered radios.
When they have been incorporated using secondary red-side processors, general-purpose operating systems are typically only used for unclassified communications. Classified communications require custom HCI interfaces to achieve high assurance of the integrity and availability of sensitive data and commands.
The Holy Grail, of course, is to incorporate Android into the original red processor without sacrificing real-time performance, jeopardizing security, or increasing certification overhead. Furthermore, we want to use Android for classified as well as unclassified interfaces, enabling the warfighter to fully realize the rich productivity benefits of Android. This goal is made possible using a specialized form of system virtualization, called Multiple Independent Levels of Security (MILS) virtualization. MILS virtualization requires a MILS separation kernel.
MILS separation kernel
MILS is a security architecture based on the concepts of high-assurance components and the strict isolation and controlled information flow between those components. At the lowest level, MILS policies are enforced by a separation kernel, a specialized RTOS designed to meet the highest levels of assurance while providing a powerful environment for hosting both general-purpose and security-critical applications.
Assessment of software-security assurance is performed using the international standard for information technology security product evaluation: Common Criteria (ISO/IEC 15408). Common Criteria Evaluated Assurance Levels (EAL) range from 1 to 7. Most general-purpose products, such as Windows, Linux, VMware, Web servers, firewalls, and so on are certified to level 4 or lower. Level 6+ corresponds to high assurance. In 2008, Green Hills Software's INTEGRITY separation kernel became the first software technology to achieve a high-assurance Common Criteria certification. Assurance must-haves at this level include numerous rigorous development process controls, formal mathematical proof of security policy, and NSA penetration testing with full access to source code. The same RTOS technology is widely used in NSA Type-1 certified communications devices.
EAL6+ represents the U.S. government's mapping of "high robustness" to the Common Criteria. High robustness is the level of security recommended when a communications device is managing high-value information in a high-threat environment. If either the information value or the threat environment is low, then a medium robustness (EAL 4) solution may be sufficient.
MILS virtualization
As described earlier, the power of a MILS separation kernel lies in its ability to enable coexistence of security-critical applications with general-purpose applications. In some cases, these general-purpose subsystems are full "guest" operating systems, running in a virtual machine under control of the MILS separation kernel. Unlike traditional hypervisors, the separation kernel can host native applications as well as guests. The separation kernel's strict resource scheduling and protection mechanisms ensure that the virtual machine and its constituent applications are unable to impact the execution of critical applications.
The separation kernel is the only software that runs in the processor's most privileged mode. The mechanism of system virtualization depends on the processor's specific hardware capabilities. Increasingly, modern embedded processors are incorporating hardware virtualization acceleration, which enables virtual machine management to be as simple and efficient as possible.
The separation kernel can provide a strictly controlled Interprocess Communication (IPC) path between the Android HCI and other red-side applications as needed. For example, Internet Protocol data originating from the Android network subsystem can be transmitted over the IPC pipe to the crypto subsystem for encryption and transmission. Application of the MILS virtualization concept to the SDR example is shown in Figure 3.
Figure 3: MILS virtualization SDR architecture
(Click graphic to zoom by 1.9x)
|
|
The difficulty of using Android for managing classified communications, however, remains. For example, consider the warfighter using an Android touch-screen widget to enter the sensitive command, "Zeroize all cryptographic keys now." Mission success may depend on the command information passing correctly through Android to the crypto component. Yet the low assurance of Android makes it impossible to make the necessary integrity and availability guarantees.
Again, MILS virtualization provides a solution. In the MILS virtualization architecture, the physical graphics device is controlled exclusively by a trusted application running on the MILS separation kernel; Android has access only to virtualized devices. Thus, when a command is entered through Android and across the virtualized interface, a trusted application can check the command. The command is only committed if the warfighter is satisfied that Android has faithfully transmitted his/her intent. This verification stage provides a MILS-enforced trusted path from warfighter to high-assurance components; Android is completely out of the loop.
Multi-domain MILS virtualization
Some military communications devices, such as radios, smartphones, and network interface cards, must manage information at varying classification levels. Default policy requires that information at different levels be kept physically isolated. Typically, this is accomplished in one of two ways. One method is to require a cold restart, in which writable hardware resources are zeroized, to safely switch the device between security levels. This approach is not only unfriendly to users, but the reboot could delay communications and impact mission effectiveness. The second approach is to incorporate a discrete red-side processor for each security level and only require a secure switch of the human interface devices (for example, a display or keyboard). Once again, the extra processing elements will increase the footprint, production cost, and system complexity of the device.
MILS virtualization solves the multidomain problem as well. Separate instances of any required subsystems, including virtual machines and SCA frameworks, can be strictly isolated and scheduled by the MILS separation kernel. In addition, the separation kernel's ability to host native applications can solve the shared human interface device problem: A trusted Multi-Level Secure (MLS) HCI application can run directly on the separation kernel, multiplexing multidomain I/O based on user-derived focus input captured directly by the MLS component. The multi-domain MILS virtualization architecture for an SDR is shown in Figure 4.
Figure 4: Multidomain MILS virtualization
(Click graphic to zoom by 1.9x)
|
|
While the architectures described in figures 3 and 4 can be implemented using a single-core processor, the advent of multicore embedded processors can make them more practical. As shown by these examples, the sophisticated red-side processing includes numerous components, many of which can execute concurrently on multiple cores, under supervision of a multicore-aware separation kernel. This extra horsepower enables good performance for virtual machines while ensuring real-time behavior for critical applications.
Military 'Droid
The rich functionality of the latest multimedia software packages, such as Android, can now be incorporated into even the most demanding real-time, secure military communications devices without increasing hardware footprint, cost, or certification burden. The key innovation is MILS virtualization, which exploits the resource management capabilities, native applications environment, and assurance pedigree of a trusted separation kernel and modern hypervisor techniques to effectively consolidate general-purpose and critical subsystems.
David Kleidermacher is Chief Technology Officer at Green Hills Software, where he is responsible for technology strategy, platform planning, solutions design, and technical evangelism. He is a leading authority in systems software and security, including secure operating systems and virtualization technology. David earned his Bachelor of Science in Computer Science from Cornell University and is an active writer and speaker on technology subjects. He has been with Green Hills Software since 1991. He can be contacted at davek@ghs.com.
Green Hills Software, Inc. 805-965-6044 www.ghs.com
