Securing safety-critical software for avionics and other mission-critical systems

PALM HARBOR, Fla. – Safety-critical systems go through a rigorous development, testing, and verification process before getting certified for use. For avionics software and other airborne systems, the de-facto standard for software development is RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification (also published in Europe as EUROCAE ED-12C). Achieving certification for safety-critical airborne software is costly and time consuming. Once certification is achieved, the deployed software cannot be modified without recertification.

Nov 28th, 2018
ByRichard Jaenicke
ByRichard Jaenicke

PALM HARBOR, Fla. –Safety-critical systems go through a rigorous development, testing, and verification process before getting certified for use. For avionics software and other airborne systems, the de-facto standard for software development is RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification (also published in Europe as EUROCAE ED-12C).

Achieving certification for safety-critical airborne software is costly and time consuming. Once certification is achieved, the deployed software cannot be modified without recertification.

Unauthorized modification of the certified software presents a significant risk to safe operation, and today’s safety-critical systems face a variety of threats from unintentional and malicious actors. If the software is changed maliciously or even unintentionally from the certified configuration, it is no longer safe. Bottom-line: a system that is not secure puts safety at risk.

A real-time operating system (RTOS) has a central role in safety and security. While there are several operating systems that have completed safety certification as part of an overall safety-critical system, there are very few designed for security-critical applications and fewer still that have achieved any official security certification.

It is not sufficient to have separate RTOS products with one being safe and another being secure, because the primary RTOS or hypervisor needs to be safe, as well as secure. The only way to meet this requirement is to build safety and security into the same RTOS.

Related: Safety-critical software for mission-critical applications to get boost with release of DO-178C

When several applications exist within the same system, those applications often handle tasks of varying importance -- often called different criticality levels. Integrated modular avionics (IMA), for example, combines many avionics processing functions onto a set of shared processing resources.

For flight safety, those different criticality levels are called design assurance levels (DAL), ranging from DAL A, where a failure would be catastrophic, to DAL E, where a failure would have no safety impact. The safety-critical RTOS is responsible for providing the memory, time, and resource partitioning to protect each application from being affected by all other applications; it must protect higher criticality applications from negative or unintended affects of lower criticality applications.

Safety-critical applications

Similarly, different applications running on the same system can be at different security levels. To ensure that those applications access only the information for which they are authorized, the system needs to implement a multiple independent levels of security (MILS) operating environment.

A MILS operating system isolates applications and their data into different security domains, and provides mechanisms for permitting authorized communication across different domains. A MILS operating system should support hosting multi-level secure (MLS) applications, which typically are cross-domain solutions (CDS) that filter specific information flow from higher security levels to lower security levels.

Related: Safety- and security-critical avionics software

One proven approach for a MILS operating system is to build it as a separation kernel, which isolates several partitions and controls the information flows between applications, partitions, and external resources.

In part, that includes protecting all resources from unauthorized access, isolating partitions except for explicitly allowed information flows, and a set of audit services. The result is a separation kernel that provides high-assurance partitioning and information flow control that satisfy the non-bypassable, evaluatable, always invoked, and tamper-proof (NEAT) security policy attributes.

In 2007, the Information Assurance Directorate of the U.S. National Security Agency (NSA) published the Separation Kernel Protection Profile (SKPP) -- a security document that defines functional and assurance requirements for separation kernels in the most hostile threat environments.

Similarities exist between partitioning for safety and separation for security. In practice there also is significant overlap. Safety partitioning and security separation share the needs for data integrity and availability. Security separation has the additional requirement of confidentiality, but that often relies on similar implementation mechanisms to provide data integrity and memory partitioning, like the memory management unit or MMU.

Related: Software tools for safety-critical aerospace and defense applications introduced by LDRA

Furthermore, the sources of covert timing channels necessary for many types of security attacks often are the same sources of interference with respect to availability concerns. Therefore, an RTOS that meets the security assurance requirements, as defined in the SKPP’s MILS separation kernel requirements, also enhances the safety attributes. Conversely, an RTOS that provides safety, but cannot meet the SKPP’s MILS separation kernel requirements for security, is more than likely to have high code complexity and potential vulnerabilities to common sources that also could influence safety properties.

In 2008, the INTEGRITY-178 RTOS from Green Hills Software was certified against the SKPP while simultaneously complying with the requirements defined in RTCA/DO-178B Level A. That certification against the SKPP was to the highest evaluation Assurance Level (EAL 6+) for general software products.

Green Hills Software’s latest RTOS version for multicore processors, INTEGRITY-178 tuMP, continues to meet the SKPP’s functional and assurance requirements. It provides certified APIs for MLS applications within a secure partition, which include support for multithreading, concurrent execution on several cores, and flexible core assignments at the configuration file level. INTEGRITY-178 tuMP can thwart denial-of-service attacks from compromised partitions and applications resulting from the unintended or malicious use of the multicore processor’s shared resources.

Richard Jaenicke is the director of marketing for safety- and security-critical products at Green Hills Software in Palm Harbor, Fla. His email address is richj@ghs.com.

Ready to make a purchase? Search the Military & Aerospace Electronics Buyer's Guide for companies, new products, press releases, and videos

More in Computers