Hardening High-Assurance Systems:
MILS as Software Design for Avionics
Kevin Mueller
Airbus Operations
Hamburg, Germany
Kevin.Mueller@airbus.com
Abstract—The aviation industry needs to assure the reliable
operation of aircrafts. While this reliability has many aspects,
this talk focused on the aspect of information technology for the
electronic on- and off-board equipment. Modern architectures of
avionics, the aircraft's electronic systems, are driven by denser
integration into embedded platforms and the interconnection of
these systems to each other. In addition, the aircraft's ecosystem
demands new connectivity solutions for several stakeholders, e.g.
passengers, airlines or air traffic management. This trend of
transferring the previously closed, federated systems into
interconnected Integrated Modular Avionics offering additional
services introduces the potential risk of threads and increased
attack surfaces allowing intruders to harm the operation of the
aircraft. To counter these threats is challenge for the aviation
industry that needs new system design approaches.
The concept of Multiple Independent Levels of Security
(MILS) can provide such a system design for equipment
operating in high-assurance environments. Due to its properties
of separation and controlled information flow, MILS is a
promising design approach for the secure integration of several
systems into one hardware platform. While this idea has been
part of research for the last decades, MILS can also be used as
software design concept for one embedded system. This approach
divides the system under development into several sub-functions
that can be implemented and executed inside isolated runtime
compartments. Information flows between these compartments
are mediated by the MILS platform. This divide-and-conquer
approach decouples critical code from less critical code, limits the
perimeters of the internal software dependencies and allows a
localized verification of sub-functions.
This paper presents the general security environment to
develop and operate avionics, explains the introduced MILS
software design approach in more detail, provides the identified
advantages and disadvantages using this concept, and discusses
the results of a feasibility study using a common avionic high-
assurance system to control the information exchange on security
domain borders.
Keywords—High-assurance, MILS
I. INTRODUCTION
High-assurance systems deployed in industries such as
aviation, automotive or transportation systems, medication or
power grid need to handle a growing demand on system
functionality and complexity with appropriate means to assure
their reliable operation. Historically reliable operation was
assurance by the absence of unacceptable risks factors reasoned
by the physical conditions of the operational environment.
However, the landscape of IT infrastructures has been
changing, among others also due to increased connectivity of
systems. This demands additional efforts to protect high-
assurance systems against criminal attempts to temper with the
systems. This security protection implies the need on a
changing mindset and new technologies as the common safety
models that rely on static, probabilistic failure conditions are
only limited applicable to security.
In safety, a failure condition with a certain, very low
likelihood (e.g. 10-9 failures per defined operational hours) can
be acceptable over the full life time of a product. Compared in
security, the threat environment changes as new vulnerabilities
can appear depending on the attacker’s available resources and
time. Also as soon as a vulnerability is exploitable with certain
efforts, it usually needs immediate attention to fix. Hence,
goals for developing secure systems are the reduction of the
possibilities to introduce vulnerabilities in the code and
hardened system designs with means on self-protection to
avoid propagations of already compromised parts.
This paper presents the IT security environment in the field
of avionics. It further studies on the design concept of Multiple
Independent Levels of Security (MILS) that according to
literature allows secure system designs. The study implemented
a typical avionic use case, a security gateway for information
flow control, using the MILS design principles. One goal in
this study was to validate whether MILS as software
architecture to implement such a use case is generally possible
and achieves the desired effects to allow evaluable software.
Furthermore, we evaluated on positive effects and challenges
induced by applying MILS.
Section II provides related work on the subject of this
paper. Section III describes the environment of security in
avionics briefly. Section IV introduces the design concept of
Multiple Independent Level of Security (MILS). Section V
describes the exemplary use case of the avionic gateway.
Section VI concludes this paper.
www.embedded-world.eu
 II. RELATED WORK
Paulitsch et al. [1] provide an extensive overview on
challenges in safety and security for mixed-criticality
embedded systems, in particular, by investigating on
challenges in avionics and railway systems. The analysis
covers the important design regularities in both industries but
also software and hardware challenges, especially when being
in the need to use modern hardware.
The architecture of MILS dates back to Rushby who
presented the concept first in 1981 [2]; however, the probably
most famous document is his MILS constitution from 2008 [3].
In this document, Rushby explains MILS as two-step approach
of 1) logically decomposing the system into components and 2)
defining the required resources for these components, which
then can be either dedicatedly assigned to one component or
shared among them. The dedicated assignment of resources
implies the aspect of separation, while sharing resources aims
the aspect of controlled information flow (see Section IV).
In a European Project’s report [6], the authors provide their
terminology and interpretation of a modern MILS architecture.
This paper uses this terminology. The here discussed gateway
use case enhances the features of a previous publication [2] on
the gateway function. Another paper [5] analyses hardware
requirements to perform I/O operations securely in MILS-
based systems. This document provides generic hardware
requirements on novel I/O hardware capable to self-
virtualization.
III. SECURITY IN AVIONICS
Compared to the long tradition regarding safety, considering
security is newer to avionic (computer) systems. The trend of
e-enabling aircrafts by providing enhanced connectivity
solutions to passengers, operators and controllers demands
system engineers to secure their implementation. While safety
remains the major goal for the development, security supports
the safe operation by preventing harmful and intended attacks
against the systems. Hence, the aviation industry mentions
often “security for safety” as term. For the purpose of security,
the aviation industry has been developing specific guidelines
to support the secure development side by side with the
available safety standards. Of particular interest are security
standards such as ARINC-664 [7] and ARINC-811 [8], both
speaking about security domains on-board of aircrafts (see
Fig. 1). The standards of ED-202 [9], ED-203 [10], and ED-
204 [11] provide guidance for the full life cycle of an aircraft;
among others covering the steps of development, production,
operation, until disposable of the aircraft.
Fig. 1: Aircraft security domains according to ARINC 664 [7] and ARINC
811 [8]
IV. MULTIPLE INDEPENDENT LEVELS OF SECURITY (MILS)
The system design concept of Multiple Independent Level
of Security (MILS) allows the deployment of sub-systems
processing different security levels into one system. This
integration allows to better utilize the available processing
power of modern hardware. MILS uses the properties of
Separation of Resources and Controlled Information Flow. For
resource separation, the concept needs to deal with two
dimensions:
1. Spatial Separation divides the available processing
resources of a system at one certain time into separated runtime
environments, so called resource partitions. Such resources are
processors and processing cores, address spaces and memory,
or I/O devices. Depending on the design of the control unit
assuring these resource separation, some borders between
resources remain static; however, some resources such as
processing cores needs to be shared during operation.
2. Temporal Separation solves the sharing of resources in
the dimension of time. For this, the control unit assures a
defined schedule of the integrated sub-systems to allow each
sub-system to process regardless of the behavior of the other
sub-systems. Temporal separation introduces the notion of time
slices, being periodic temporal slots with a certain duration
allowing to process one or more defined sub-systems (or more
generically tasks).
A common known control unit is a software called
Separation Kernel (cf. Fig. 2) assuring both dimensions of
separation: spatial and temporal.
Fig. 2: MILS architecture with a Separation Kernel
to separate the available resources into partitions.
As such special kernels need to be small in order to support
verification, they attempt to use a static separation between
resources; hence, usually an assignment of memory and
devices remains static. Dynamic resource allocation and
relocation, e.g. on memory, require much more code
complexity. However, scheduling of processes on cores
remains a dynamic element and needs to be assured by
Separation Kernels.
V. USE CASE: AVIONIC GATEWAY
While investigations on MILS as design concept to
integrate several sub-systems have been part of research in
recent years, this paper uses the MILS idea as software
architecture to divide-and-conquer the software complexity. To
allow a secure data exchange between avionic domains (see
Fig. 1) gateways controlling data that enters or leaves a domain
are of special interest. As aviation performs “security for
safety” particularly integrity protection of data entering a
domain with higher demands on safety (and thus, security and
assurance) is of interest (cf. data flow from Domain B to
Domain A in Fig. 3).
Fig. 3: Gateway to Control Data Flows
A. Gateway Architecture
In this study, the gateway (cf. Fig. 3) was implemented
using the MILS concept as software architecture. To achieve
this, the gateway function on exanimating and filtering data
flow was decomposed into different sub-functions (cf. Fig. 4),
e.g. such as on handling I/O operations and interaction with
hardware (NIC), decoding received network packets (Receiver
Component), handling supported protocols (TFTP or HTTP
Chains), or sending network packets (Transmitter Component).
Context Managers operate as connectors between related parts
inside of each flow direction in order to exchange information
on the network flow, e.g. the status of communication sessions.
A sub-function having a receiving functionality only performs
the recording of audit entries generated by other sub-functions.
As all sub-functions run inside resource partitions, each sub-
function can be developed independently fulfilling its agreed
interfaces. Also, each sub-function has to provide local security
protection against other sub-functions, e.g. to avoid mitigation
of attacks from already compromised sub-functions; hence,
input validation is one mean necessary to be applied.
Fig. 4: Avionic Gateway using MILS as Software Architecture
MILS further allows to design the sub-function on an internal,
unidirectional flow. This eases the code complexity of the sub-
functions as they have well-defined ingress and egress
interfaces and do not need to protect themselves on side-effects
by other sub-functions. In this gateway example, the code size
to implement a sub-function did not exceed 2,500 lines of
code; most of them are around 800-1,500 lines of code. Among
other advantages, such small code footprints allow to run code
proofers efficiently, e.g. to detect code flaws by static analysis
[13], to perform Modified Condition/Decision Coverages for
certification purposes [15], or to assure correct information
flows inside the code [12].
For still achieving bi-directionality, the unidirectional
implementation of a sub-function is instantiated twice inside
the MILS platform (the Separation Kernel) as Fig. 4 shows.
The flows between these encapsulated sub-functions are fully
under control of this Separation Kernel. This again shows the
power of MILS, allowing to design a layered system by
decomposing a complex function into coarse information flow
assurance by the Separation Kernel and fine-grained data flow
analysis inside the sub-functions.
B. Gateway Performance
As hardware platform, the gateway uses a high-performance
processing platform with eight cores. Hence, the separation
kernel can also spatially separate the cores among the sub-
functions of the gateway. Assuming the hardware’s
interconnect to transfer data between cores and memory is
implemented securely, the sub-functions can operate in
parallel with a spatial security border in between.
Fig. 5 shows the internal organization of the Separation
Kernel running the described gateway function. Essentially,
each sub-function of the gateway is represented as a task in the
Separation Kernel. Each task hosts a number of threads.
Threads are the elements to be scheduled and executed by the
kernel. Tasks and, hence, all related threads operate on the
resources defined by the configuration of the spatial
separation. On the temporal dimension, each task is related to
a time partition. However, one time partition can have
multiple tasks, which share the assigned duration. The
duration of a time partition is provided by a time slice. A
schedule finally has multiple sequential time slices, which
again related to time partitions. However, the same time
partition can occurs multiple times in the same schedule but in
different time slices (with different durations). To reduce
configuration complexity, time slices switch concurrently on
all cores of the system.
Fig. 5: Scheduling model of the separation kernel. Note, the
variable n can represent a different value on each relation.
For the gateway measurements, the Separation Kernel
configures two different schedules. The first schedule (Fig. 6)
executes two time slices with time partitions T1 and T2 having
the same execution time of t. The second schedule (Fig. 7)
executes three time partitions in four time slices (T1, T2, T3
and T2 again) with all having the same fixed execution time.
As soon as one time slice exhausts, all threads related to the
time partition running inside the time slice get intercepted.
The operation continues as soon as the time partition gets
reactivated by an additional time slice.
Fig. 6: Schedule with two time partitions assigned to two time slices.
Fig. 7: Schedule with three time partitions assigned to four time slices.
The performance measurement investigates on various
configurations performing a TFTP transfer of 5 MB. Note,
TFTP uses in default operation a transfer block size of 512 kB
and demands an acknowledgment of each data block before
www.embedded-world.eu
transmitted the next block [14]. To perform the gateway’s gateway function connecting one security domain
filter policy, the file gets reassembled inside the TFTP chain. runs in time partition T1. The filter chains run in T2.
As soon as the entire file is allowed to pass, the file gets As the performance measure is on TFTP traffic only,
segmented again and is transferred to the target domain the HTTP chain remains sleeping and does not
according to the specification of the TFTP. interfere with the measurement. The sub-functions of
the gateway connecting the second security domain
Remember, the used hardware offers multiple processing
operate in T3. The sub-function on auditing is
cores, and hence, allows spatial separation on cores. The
exclusively allowed to run all the time when data
performance analysis uses the following setups:
becomes available. This setup uses a single-core
1. This special configuration operates the gateway in only; hence, omit the light-blue cores configuration
three-core configuration without special time shown in Fig.10.
partitioning enabled (cf. Fig. 8). The sub-functions
connecting the left domain run on one core. The filter
chains run on the second core. The sub-functions
connecting the right domain run on the third core. All
sub-functions implement a cooperative scheduling,
i.e. they process only when data is available and yield
processing time to others when all data has been
consumed.

Fig.10: Configuration for setup 4 and 5 with three time partitions

5. This configuration uses the previous setup but applies

also spatial separation using a dual-core
configuration. In this, the upper part processing data
from left to right uses core 1. The lower part,
processing data from right to left uses core 5. Note
again, this configuration enables spatial separation on
cores AND temporal separation on cores.
Fig. 8: Configuration without temporal separation but using a three core
setup for spatial separation. Fig. 11 shows the measured values transferring the 5 MB via
TFTP for each configuration with the following parameters:
2. This configuration separated the sub-functions
connecting to the security domains to the left and
right from the filter chains using temporal separation.
This setup uses a single core configuration; hence,
the light-blue lines in Fig. 9 shall be ignored.

Fig. 9: Configuration for setup 2 and 3 with two time partitions

3. Uses the same temporal separation as in the previous

setup but also applies spatial separation on cores. In
this dual-core setup, the upper channel runs on core
1, while the lower channel runs on core 5 (cf. blue
hex-mask indicating the used cores). Note, this
configuration enables spatial separation on cores
AND temporal separation on cores.
4. Fig.10 shows the assignment of sub-functions to the
time partitions T1, T2 and T3. The left part of the
Fig. 11: Overview on performance measurements
 An_Cs_#3_Sn: Setup 1 without temporal separation
 An_Cs_#1_Sy2_4: Setup 2 with time slices of 400 µs
 An_Cs_#1_Sy3_4: Setup 4 with time slices of 400 µs
 An_Cs_#2_Sy2_4: Setup 3 with time slices of 400 µs
 An_Cs_#2_Sy3_4: Setup 5 with time slices of 400 µs
  An_Cs_#1_Sy2_5: Setup 2 with time slices of 500 µs
 An_Cs_#1_Sy3_5: Setup 4 with time slices of 500 µs
 An_Cs_#2_Sy2_5: Setup 3 with time slices of 500 µs
 An_Cs_#2_Sy3_5: Setup 5 with time slices of 500 µs
Fig. 11 shows the best performance for the configuration
without temporal separation (setup 1). In this configuration, all
sub-functions run when data is available and yield their
processing time to other sub-function when data is
unavailable. However, this configuration has the risk of
denial-of-service attacks, as a compromised sub-function can
process forever on the assigned core and, hence, starve all
other sub-functions on this core. But, given the three-core
configuration, the risk is limited by the spatial separation
among cores; hence, to make all sub-functions of the gateway
unresponsive demands to compromise at least three sub-
functions running on three different cores.
If temporal separation is needed, as either only one core is
available on the hardware (cf. setup 2 and 4), or due to
assurance requirements, it is beneficial to configure as less
time partitions as possible. However, considering setups 2 and
4, it is sufficient to attack one sub-function connecting the
security domains to stall both sides. The three-core configura-
tion solves this, but introduces a huge overhead on the transfer
time. This is in particular due to the processing behavior of
TFTP, which does not utilize well with the configured setups 3
and 5. Note, TFTP demands the acknowledgment of each data
block. Hence, first one side of the gateway processes until the
file is entirely available in the TFTP chain. Afterwards, the
other side of the gateway processes. However, the setups 3
and 5 force the system to spare processing time to the non-
required side of the gateway and, thus, “to burn” processing
time as this part does not have data to process.
Finally, using temporal separation in this example cannot
achieve appreciable performance gains by using dual-core
configurations (cf. configurations with *_#1_*. compared to
the related configurations with *_#2_*).
Note, a full temporal evaluation on the described use case
will become available with the publication of [16].
VI. CONCLUSION
This paper describes the experiences gained during the
implementation of a high-assurance avionic gateway using the
MILS principals as software architecture. MILS uses a divide-
and-conquer approach to split a complex system into
manageable sub-functions in order to achieve a correct
implementation with certain assurance guarantees on the level
of sub-function and the finally composed system. The gateway
function on exanimating and filtering network data was
decomposed into several sub-functions. These sub-functions
were implemented separately from each other using the well-
defined formulated interfaces given via the MILS idea. This
allowed reducing the complexity and code sizes of the sub-
functions. Lower complexity and reduced code footprints
allows to run further tools analyzing the code regarding
implementation flaws. The information flow between sub-
functions relies fully on the MILS control unit, usually called
Separation Kernel. The study showed that MILS used as
software architecture allows a clean design of the software and
offers further capabilities to proof the correctness of the
implementation [12].
Challenges remain as the information flow and resource
configuration in the separation kernel receives complexity.
However, tool support can limit this impact. Further challenges
are in the scheduling and temporal separation of the sub-
functions to achieve the best security protection. Of particular
interest are defense-in-depth scenarios. While the strict
resource separation among sub-functions does not allow an
easy propagation of an attack from a spatial view, a
compromised sub-function could still try to influence other
sub-functions from a temporal perspective. The discussion on
scheduling of such a system introduces a general trade-off, as a
full temporally separated setup provides best security against,
e.g. denial-of-service attacks. However, it reduces the overall
performance as strict temporal separation does not allow time
sharing among tasks or yielding processing time to other tasks
if data is unavailable. Interestingly, if multicores provide
sufficient assurance to be used reliably, they allow to configure
similar security protection against denial-of-service attacks as
temporal separation but offer better performance. However,
deploying multicores in aviation remains a research challenge
[1].
REFERENCES
[1] M. Paulitsch, O. Medina-Duarte, H. Karray, K. Müller, and Daniel
Münch, and J. Nowotsch, “Mixed-criticality embedded systems - a
balance ensuring partitioning and performance”, In Proc. of the 18th
Euromicro Conference on Digital System Design (DSD’15). IEEE,
August 2015.
[2] J. Rushby. “Design and Verification of Secure Systems”. In Proc. of the
8th ACM Symposium on Operating Systems Principles, Pacific Grove,
California, USA, December 1981. ACM.
[3] J. Rushby. Separation and Integration in MILS (The MILS
Constitution). Technical Report SRI-CSL-08-XX, SRI International,
February 2008.
[4] K. Müller, M. Paulitsch, S. Tverdyshev, H. Blasum, and R. Schwarz.
“MILS-based Information Flow Control in the Avionic Domain: A Case
Study on Compositional Architecture and Verification”. In Proc. of the
31st Digital Avionics Systems Conference (DASC 2012), October 2012
[5] K. Müller, G. Sigl, B. Triquet, and M. Paulitsch. “On MILS I/O Sharing
Targeting Avionic Systems”. In Proc. of the 10th European Dependable
Computing Conference (EDCC’14), Newcastle upon Tyne, UK, May
2014. IEEE.
[6] H. Blasum, S. Tverdyshev, B. Langenstein, J. Maebe, B. de Sutter, B.
Leconte, B. Triquet, K. Müller, M. Paulitsch, A. Södding-Freiherr von
Blomberg, and A. Tillequin. MILS Architecture. Technical report, 2014.
http://www.euromils.eu/downloads/2014-EURO-MILS-MILS-
Architecture-white-paper.pdf
[7] Aeronautical Radio Incorporated (ARINC). “ARINC 664 Aircraft Data
Network Part 5: Network Domain Characteristics and Interconnection”,
April 2005.
[8] Aeronautical Radio Incorporated (ARINC). “ARINC 811: Commercial
Aircraft Information Security Concepts of Operation and Process”
Framework, 2005.
[9] EUROCAE/RTCA. “ED-202A/DO-326A: Airworthiness Security
Process Specification”. Technical Report 2, European Organisation for
Civil Aviation Equipment/Radio Technical Commission for
Aeronautics, 2014.
[10] EUROCAE. “ED-203: Airworthiness Security Methods and
Considerations”. Technical Report 1, European Organisation for Civil
Aviation Equipment, 2012.
www.embedded-world.eu
[11] EUROCAE. “ED-204: Continuing Airworthiness Guidance for the
Security of Aircraft Information the Security of Aircraft Information”.
Technical report, European Organisation for Civil Aviation Equipment,
2013.
[12] K. Müller, S. Uhrig, F. Nielson, H. R. Nielson, X. Li, M. Paulitsch, and
G. Sigl. „Automatic Information Flow Validation for High Assurance
Systems”. International Journal On Advances in Software, 9(3&4):190-
205, December 2016.
[13] D. Kästner, S. Wilhelm, S. Nenova, P. Cousot, R. Cousot, J. Feret, A.
Miné, X. Rival, and L. Mauborgne. “Astrée: Proving the Absence of
Runtime Errors”. In Proc. of the Embedded Real Time Software and
Systems (ERTS2’10), pages 1-9, Toulouse, France, 2010
[14] Network Working Group. “RFP 1350: The TFTP Procotol”. Revision 2.
1992
[15] K. J. Hayhurst, D. S. Veerhusen, J. J. Chilenski, L. K. Rierson, “A
Pratical Tutorial on Modified Condition/Decision Coverage“.
NASA/TM-2001-210876. Technical report. 2001.
[16] K. Müller, “Security in Embedded Avionic Systems using the Concept
of Multiple Independent Levels of Security”. PhD thesis. Department of
Electrical and Computer Engineering, Technical University of Munich.
2017. (unpublished, submitted for grading)