Paul Parkinson, Senior Systems Architect
at Wind River,
considers how the diverse mission operations of unmanned
air vehicles (UAV) has exposed information- and
communication-security concerns that are not easily addressed in
currently deployed integrated modular avionics (IMA)
systems. Here, the MILS (multiple independent levels of
security) software architecture is discussed in relation to how it
can fulfil disparate UAV system design requirements.
In recent years, there has been very rapid growth in the
development and deployment of UAVs. 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.
Figure 1: Unmanned combat air vehicle
(UCAV)
UAVs do not need to be encumbered by life-support systems for a
human operator, often enabling the design to be physically smaller
and lighter than a manned vehicle. In the case of military UAVs,
this can contribute toward a reduced radar cross-section (RCS)
resulting in a lower probability of intercept (LPI) by hostile
forces. This can also reduce the need to use stealth, supersonic,
or hypersonic capabilities currently used for high-altitude spy
planes (such as the U-2, SR-71, and successor aircraft).
UAVs are also capable of performing much longer, extended
missions than those restricted by the limits of an individual human
operator. This is because they provide the ability to coordinate
operation through a number of remote operators working in shifts.
This capability provides military planners with the ability to have
increased loiter time on target, which can be invaluable for a
changing situation on the ground.
There is also the additional benefit that military UAVs can be
used in theatres that present a higher risk of intercept than would
be acceptable for manned aircraft, including airborne
reconnaissance to provide invaluable battlefield intelligence. They
can even be used as active decoys, penetrating deep into enemy
territory in offensive air operations1. Armed combat variants are
now being deployed (usually referred to as unmanned combat air
vehicles or UCAVs) (Figure 1).
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 7 million SLOC.
The increasing complexity of these systems has required an
increase in system performance and therefore the physical footprint
in terms of 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 IMA.
This architecture comprises common computing platforms that can
host multiple applications concurrently (Figure 2). This approach
saves space, power, and weight. If an open standards-based 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.
Figure 2: Avionics architectures
The ARINC 653 software architecture2 is an example of an open
standards-based approach and has become preeminent 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 standardization 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-178B3/EUROCAE ED-12B4 has also involved
an iterative cycle, with experience from real programs and new
requirements feeding back into the standardization process. This
has led to a role-based development approach to facilitate the
certification process being defined in the common guidance
documents DO-2975 and ED-1246 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
sensor systems. These use firewalls and encryption for the secure
transmission and reception of information between networks, without
transforming the information during its transport. This is known as
communications security (ComSec). There is likely to be data
communication between the 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
reenter 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 utilize 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).
Figure 3: UAV mission
Multiple Independent Levels of Security
In recent years, the Common Criteria (ISO-15048)7 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 architecture8 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.
Figure 4: MILS architecture
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 utilization 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.
References
1. Capt. Brian P. Tice, U.S. Air Force,
"
Unmanned Air Vehicles: The Force Multiplier of the 1990s," Air
Power Journal, Spring 1991, .
2. "
ARINC Specification 653P1-2," .
3.
"Software Considerations
in Airborne Systems and Equipment Certification," DO-178B,
RTCA, December 1992, .
4. "Software Considerations in Airborne Systems and Equipment
Certification," ED-12B, EUROCAE.
5.
"Integrated Modular
Avionics (IMA) Development Guidance and Certification
Considerations," DO-297, RTCA.
6. "Integrated Modular Avionics (IMA) Development Guidance and
Certification Considerations," ED-124, EUROCAE.
7.
"
Information Technology - Security Techniques - Evaluation Criteria
for IT Security," ISO-15408, .
8. M. Vanfleet, U.S. National Security Agency, "MILS Architecture,"
Open Group Security Forum, July 2002.
Paul Parkinson is a senior systems architect with Wind
River, working with customers in the aerospace and defence sectors
in the United Kingdom and Nordic countries. His professional
interests include Integrated Modular Avionics (IMA) and
Intelligence Surveillance Target Acquisition Reconnaissance (ISTAR)
systems. He blogs on A&D industry issues on the Wind River
website athttp://blogs.windriver.com/parkinson
.