Security challenges in UAV development

18 December 2008

The growth in military uses of unmanned air vehicles has lead to concerns of software security issues

In recent years, there has been very rapid growth in the development and deployment of unmanned air vehicles (UAV). These unmanned systems are being used in a very diverse range of roles, from urban
reconnaissance to High-Altitude, Long-Endurance (HALE) operations. In many cases, program developments have been driven primarily by operational requirements to deploy systems in environments deemed to be too hazardous or too hostile for human operators. However, the development of these unmanned systems has not overcome the technical challenges to fulfil these operational requirements along with producing additional tangible benefits.

Modular avionics in the extreme
Aircraft systems are becoming more and more complex in order to implement more and more advanced functionality. As a result, the software content in these systems continues to grow at an astonishing rate. For
example, in the 1980s, the software content in the avionics systems of military fast jets was around 100,000 source lines of code (SLOC), and this has increased significantly in recent years. It has been estimated that
the F-35 Lightning II will have around seven million SLOC.

The increasing complexity of these systems has required an increase in system performance and therefore the physical footprint in terms of space, weight, and power (SwaP). However, there are pressing requirements to reduce the physical footprint of systems within aircraft and especially within UAVs due to their physical size constraints. So a significant increase in processing density is essential.

This problem is being addressed through the adoption of Integrated Modular Avionics (IMA) systems. This architecture comprises common computing platforms that can host multiple applications concurrently (figure 2). This approach saves SWaP. If an open standardsbased software architecture is used instead of a closed proprietary software implementation, which can be the case even with some COTS implementations, it can provide additional benefits in terms of improved modularity, interoperability, and software portability.

The ARINC 653 software architecture is an example of an open standards-based approach and has become pre-eminent in recent years. It provides a specification for an application executive for IMA systems and is based upon the principles of robust temporal and spatial partitioning. These are fundamental requirements to enable multiple applications with differing levels of safety criticality to run concurrently on the same processor. This is very desirable because previously a system with mixed criticality would need to have all of the software safety certified to the level of the most critical application, which would have a significant impact on certification efforts and costs.

ARINC 653 defines an application executive, or APEX, that provides an Application Programming Interface (API) of 51 routines to enable the development of portable applications on an IMA platform, supporting temporal and spatial partitioning along with communication between applications in different partitions through well-defined ports. ARINC 653 also defines a health management framework, which can be used to provide a hierarchical framework for error detection and recovery. This framework provides an increased level of fault tolerance, which can be used to achieve improved operational availability.

The ARINC 653 standard has been refined in recent years through an iterative cycle of standardisation and development experience gained through the safety-critical IMA programs where it’s been used. The efforts
to produce guidance for safety certification of IMA systems under RTCA DO- 178B/EUROCAE ED-12B has also involved an iterative cycle, with experience from real programs and new requirements feeding back into the standardisation process. This has led to a role-based development approach to facilitate the certification
process being defined in the common guidance documents DO-297 and ED-124 produced through the collaborative efforts of joint RTCA and EUROCAE working groups. This role-based development approach,
involving platform provider, system integrator, and application developers, can be supported in ARINC 653
implementations.

Implications of secret mission operation on unmanned systems UAVs contain a number of systems that
perform different functions. These include avionics systems, mission systems, and avionics systems and mission systems that passes positioning information, bearing, altitude, and so on, for example. However,
information may also need to be transformed securely between applications, subsystems, or networks. This is known as information security (InfoSec) and may be required in addition to ComSec.

Let’s consider a hypothetical scenario involving a UAV that is tasked with a top secret reconnaissance mission (figure 3). The UAV mission systems may contain secret or top secret data, including the mission flight plan, and there is a risk that they could disclose classified secret or top secret information to the unclassified civil air traffic control (ATC) system. This is a very real concern because the ComSec
implementation is not concerned with the type of data that is exchanged between networks, only whether the networks and applications can communicate.

The UAV could take off within controlled airspace and have to interact with civil ATC over unencrypted links, operating ‘in the black’. The UAV remote pilot could then request a vector out of controlled space from ATC in order to perform its reconnaissance mission and, after this point, all flight information will be top secret or ‘in the red’, including all communication that will be over links with strong encryption.

Upon completion of the reconnaissance mission, the UAV could re-enter controlled airspace and interact with civil ATC again. The transition back from red to black is particularly challenging because it involves
systems containing top secret data communicating over unencrypted links to an unclassified ATC. The
flight plan and logged data for the red part of the mission must be retained for analysis/debrief but must not ‘leak out’ during return to base.

The UAV mission systems are likely to utilise IMA platforms due to the constraints of space, weight, power, and heat, as outlined earlier. In this environment, it is likely that it is not practical to have separate systems to
provide physical isolation between black and red data. This threat must instead be addressed through an InfoSec implementation that is multilevel secure (MLS).

Multiple independent levels of security
In recent years, the Common Criteria (ISO-15048) has become widely accepted, following the pioneering collaborative efforts in information security by the United States, Canada, the United Kingdom, France,
Germany, and the Netherlands in the 1990s. This standard defines the criteria and assurances required for different types of systems and threats, including MLS systems holding information at multiple levels of
security classifications. In the scenario described earlier, when the UAV is returning from its reconnaissance mission, it will have retained its top secret flight plan and mission log. It will be communicating over unencrypted links to an unclassified ATC, resulting in unclassified and top secret data
being present on the same system with an Evaluation Assurance Level (EAL) 7 requirement.

The MILS architecture was developed to overcome the prohibitive security certification costs and effort associated with previous, monolithic implementations. It does this by dramatically reducing the amount of security-critical code and dramatically increasing the scrutiny of it. The MILS architecture (figure 4) comprises a MILS separation kernel that is able to host multiple applications of different security classifications in separate partitions.

In the MILS architecture, the separation kernel is responsible for enforcing the separation of applications in individual partitions and ensuring that only permitted flows between applications occur. In this architecture, the permitted data flows are defined in a security policy database that is used by a reference monitor to enforce policies and detect attempted violations. An implementation of the MILS architecture should also ensure that no implicit communication could occur through covert channels. The temporal and spatial portioning prevents covert channel communication that would occur through variations in timing and resource availability, and additional techniques should be used to prevent covert communication channels through utilisation of the processor’s cache. These capabilities would ensure that the UAV in our example keeps top secret mission data isolated securely from the unclassified application communicating with the civil ATC.

The future
The use of unmanned systems, both UAVs and UCAVs, is continuing to increase rapidly and the knowledge and experience gained through their deployment is being used in ever more challenging missions. It is
likely that unmanned systems will be used in the future for highly sensitive reconnaissance missions and will contain classified data. These systems could have information security requirements with a high EAL imposed later in the development cycle. This would be difficult to layer on top of some existing software architectures, but given the similarities between the respective architectures, there should be a low-risk migration path from ARINC 653 to MILS.

PAUL PARKINSON is a senior systems architect with Wind River


Contact Details and Archive...

Print this page | E-mail this page