RTOS, secure virtualization technology for real-time systems, DO-178B and hypervisor for the most demanding embedded operating system applications...

Real-Time Secure Operating System an RTOS white paper

September 2003

Real-Time Secure Operating System
contents
  1. The Need for Secure Real-Time Operating Systems
  2. History
  3. The Design
  4. Secure RTOS and DO-178B
  5. Conclusion
  6. References

The purpose of this document is to present an overview of:
a) the need for a secure operating system and
b) the high-level design of a secure operating system that can be built and evaluated to the highest assurance levels.

The need for secure real-time operating systems

The need for a secure system is often associated with a government project. The project may be for Department of Defense (DoD), the National Security Agency (NSA) or some other agency providing information that is of a very sensitive nature. And when there was a need for an embedded product for one of these secure systems, the entire system would have to be evaluated for security.

This evaluation of an entire system could be cost-prohibitive, so in many instances, the system would be allowed to run with other systems in what is referred to as system high mode. Basically this would push the responsibility of security and information assurance off to other systems or it would be implemented via physical protection (e.g. a soldier would stand guard with an M-16 to keep the bad guys out).

This is now starting to become cost-prohibitive due to the need for the guard as well as the need for all users to obtain security clearances in order to use the product. One such example exists within the Land Warrior program. The first systems shipped will run system high and as a result an entire brigade will have to obtain a DoD secret clearance to work with the equipment. This is not the direction DoD wishes to go forward with.

In addition to the U.S. Government agencies, private sector companies will be forced to look into their systems and products that may be part of the country's critical infrastructure. This includes Internet backbone, financial institutions, power companies, etc. The recent virus attacks also show the need for secure systems that cannot be "hacked". The costs of such penetrations are in the 100s of millions if not billions of dollars. Since the formation of the Department of Homeland Security, it will not be long before regulations are put in place to ensure that systems are secure and that companies will have to look at the level of security in their embedded products in order to ensure they do not provide a means of penetration.

History

Why has no one built an operating system that is secure?

The answer to that question depends on the level of security needed. Currently the commercial and non-DoD world typically use the Common Criteria specification to define the level of security a product provides[4]. Common Criteria defines seven different levels called Evaluated Assurance Level (EAL). These levels are numbered from 1 to 7 with one being the lowest level and 7 being the highest. For the reader familiar with the DoD Orange Book (TCSEC 5200.28), EAL 7 is equivalent to an A system, 6 is B3, etc. (While Common Criteria does not require the use of EALs, they are generally accepted as the best means for defining the security level of target of evaluation (TOE). A TOE can be an OS, a firewall device, etc.)

There have been attempts to provide a generic, readily available secure OS that will evaluate to the highest assurance levels used by the U.S. Government: ISA/AMPE, BLACKER and CANEWARE[1]. DoD sponsored these programs to the tune of almost half a billion dollars and none of them succeeded. After these failures, the NSA gathered twenty experts to examine the failures and determine what needed to be done to fix the problem. This panel found that the OS attempted to take on too much work and as a result, the OS became too large to evaluate. The basic tenets put forth for any OS to be secure are:

  • Non-bypassable
  • Evaluatable
  • Always invoked
  • Tamper-proof

In the case of the three projects, the second tenet was broken due to the inability to mathematically evaluate the design of the OS. In addition the panel also concluded that part of the responsibility of the security lies with the applications. However, if a secure OS is not available then a secure application is not secure.

To facilitate the building and evaluating of a secure OS, the NSA panel examined the paradigm of a separation kernel.

The design

The separation kernel looked at by the panel as meeting the tenets laid out in the previous section was originally proposed back in the 1980s by John Rushby, Ph.D[1]. This paradigm restricts the kernel to two main functions: Information Flow and Data Isolation. Information Flow allows applications to communicate only when allowed and Data Isolation ensures that no data can infiltrate or exfiltrate an application either intentionally or by accident.

If the kernel is limited to these functions it will be relatively small. Given the small amount of code in the kernel, the 4 tenets are achievable and a secure operating system can be built.

The other work that is generally done by the kernel is moved to application space. Since applications must always use the kernel for communication outside their own partition, the security policies are always invoked and are non-bypassable.


Figure 1: Separation Kernel

Figure 1 shows a high-level diagram of the separation kernel.

The system services shown in Figure 1 in red (the right-most of the three system-services blocks) are a subset allowing them to be evaluated at the highest level. In this way, it is possible for the system to support applications of mixed security levels since the security policies are at the highest level in the system and can allow or deny communication between differing levels of security. This is referred to as Multi Level Security and is recognized as being needed by DoD for their future systems.

MLS will allow the DoD the ability to have soldiers in the field use systems that are capable of running very sensitive information and ensure that data will not accidentally be shared with personnel who are not cleared to the appropriate level. This eliminates the need for all the embedded computers in a system to run system high.

The reader who has worked in the aviation industry might recognize some of these concepts as being similar to DO-178B Level A systems.

Secure RTOS and DO-178B

DO-178B is a standard used by the FAA to certify systems for flight[2]. (The FAA typically does not certify individual components of a system. However, an OS can be certified as a Reusable Software Component [RSC] within a certifiable system.) There are 5 levels ranging from Level E to Level A. One can think of the levels as how much the system is impacted in case of failure. For example, level E basically states that no safety-of-flight issues exist. Level A systems that fail are catastrophic and will more than likely result in loss of life and aircraft. Level A systems are typically flight controls, engine controls, primary flight displays, etc.

The University of Idaho in 2001 and 2002 performed a study comparing DO-178B and Common Criteria. The conclusion of the study is that software developed to DO-178B Level A standards will map closely to either an EAL 4 or 5 with some additional work[3]. The additional work is to satisfy objectives generally not covered by DO-178B but they may be covered via good engineering practices. Examples include delivery mechanisms and vulnerability assessments.

A DO-178B kernel's space partitioning generally will solve most of the problems related to information flow since there is no sharing of memory between partitions. This is generally done to protect partitions from one another. In addition, the time partitioning used in DO-178B kernels will prevent system resources from being monopolized by a single partition—often a concern for secure systems. These two features provide most of what will be needed in a secure kernel.

EAL levels of 5-7 will require additional work, however the majority of the work is in the semi-formal and formal design analysis required. The additional software development will be mostly in the areas of providing for information flow between partitions and ensuring data is isolated at the same time.

Conclusion

If users have at their disposal a DO-178B Level A certifiable system, most of the work for a high-assurance OS is already done. The NSA and embedded-OS industry consensus is that most of the work will be in formal methods necessary to achieve an EAL 7 rating, provided that the kernel is kept small and only provides the minimal functionality to support information flow and data isolation.

LynuxWorks' own research has show that a working prototype system with the separation kernel to demonstrate functionality. An external agency will be used to achieve formal methods certification to EAL 7.

LynuxWorks is pioneering in this technology. Currently, LynuxWorks offers an RTOS that is certified by the FAA to the DO-178B Level A standard. As mentioned above, this product (LynxOS-178) can be easily certified to the Common Criteria EAL [4]. LynuxWorks is building on this technology to be able to deliver a real-time operating system certifiable to the Common Criteria EAL 7.

References

  1. W. Mark Vanfleet, "MASK Mathematically Assured Separation Kernel, Separation Kernel Paradigm", NSA
  2. RTCA. DO-178B/ED-12B. Software Considerations in Airborne Systems and Equipment Certification. RTCA, 1992
  3. J. Alves-Foss, C. Taylor, and B. Rinker. "Merging Safety and Assurance: The Process of Dual Certification for Software", 2002, http://www.csds.uidaho.edu/papers/Taylor02d.pdf.
  4. NIST. Common Criteria for Information Security Evaluation. Parts 1, 2, 3, 1999.
A LynuxWorks embedded OS is featured in this embedded system application:
Who else uses a LynuxWorks embedded operating system?
Security white papers
Separation Kernels Enable Rapid Development of Trustworthy Systems
By using separation kernel technology and a security abstraction design approach, military system developers can use off-the-shelf components and tools to rapidly build and maintain high security systems. (March 2014)
Coming Together of Safety and (Cyber) Security Changes Demands in RTOS Market
Separation kernels and secure hypervisors will be evermore in demand as safety and certification will be required in more and more applications. Governments are already working on infrastructures deploying this type of technology. (October 2012)
Building in RTOS Support for Safety- & Security-Critical Systems
LynuxWorks explains the differences between safety-critical and security-critical applications and how to meet their demanding requirements with the LynxOS-178 RTOS and the LynxSecure hypervisor. (EE Times Design, August 2011)
Enhancing Application Performance on Multicore Systems
Tips on optimizing a multicore real-time system, including virtualization, avoiding synchronization and concurrency while maximizing application parallelism. (Military Embedded Systems, February 2011)
Hardware Virtualization puts a new spin on Secure Systems
Real-time determinism and military security don't have to be separate realities. A combination of a secure separation kernel and an embedded hypervisor enables whole new levels of system security. (COTS Journal, October 2010)
Using a Separation Kernel to add Military-Grade Security to Legacy Systems
A challenge for the software designer is how to integrate modern military-grade software programs into legacy software designed long before security standards were predominant in system requirements. (VME Critical Systems, Summer 2010)
Virtualization: Keeping Embedded Software safe and Secure in an Unsafe World
A new, secure methodology is needed to separate systems of different security levels which run on shared resources—without compromising the performance of legacy systems. (EE Times, June 2010)
Secure Virtualization Combines Traditional Desktop OSs and Embedded RTOSes in Military Embedded Systems
Advances in software and hardware technologies now make it feasible to use both embedded and desktop operating systems in a secure military system. (Military Embedded Systems, May 2010)
DO-178B Provides Certification Safety net
Developers of commercial avionics software must demonstrate compliance with DO-178 guidelines. The FAA has issued additional guidance for so-called DO-178B Reusable Software Components (RSCs as defined in AC20-148), which allow for reuse of certifications. (COTS Journal, November 2009)
Designing Safety-critical Avionics Software Using open Standards
Safety-critical avionics systems have continually grown more complex and software-intensive. Regulatory authorities and avionics manufacturers have responded with guidance such as DO-178B and RSC to ensure that software performs safely, with controlled development cost. (Boards and Solutions, September 2009)
Two Different Realms: RTOS Support for Safety-critical vs. Security-critical Systems
Safety- and security-critical system functions are evolving simultaneously, with different yet similar requirements. Modern RTOSes are stepping up to meet these needs. (VME and Critical Systems, June 2009)
Virtualization Makes Better use of Open-source OSes and apps
With the introduction of the embedded hypervisor, embedded systems can avoid certain performance or licensing issues inherent to open-source OSes and applications. (EE Times, March 23, 2009)
Secure Virtualization Technology can Extend the life of Legacy Systems
By combining the concept of virtualization and security, one can consolidate multiple legacy systems running on heterogeneous operating systems onto a single host system with high-assurance security. (Military Embedded Systems, January/February 2009)
Virtual Machines: Intel's CPU Extensions Transform Virtualization
Virtualization has traditionally presented its share of design challenges in information-assurance-based systems. But now, Intel's VT-x and VT-d CPU extensions are changing the game and showing potential to become the de facto path to virtualization. (Military Embedded Systems, January 2009)
Separation Kernel for a Secure Real-time Operating System
The technical foundation adopted for the so-called MILS architecture is a separation kernel like LynxSecure, which permits multiple functions to be realised on a common set of physical resources without unwanted mutual interference. (Boards and Solutions Magazine, February 2008)
Advances in Virtualization aid Information Assurance
Advances in the newest Intel® processors are making virtualization much easier to implement in security applications than ever before. (Embedded Computing Design, January 2008)
Protecting our most Vital Systems
Some significant defence programmes are already committed to a new approach to high-threat, high-asset-value systems. Rance DeLong explains MILS. (Components in Electronics, April 2007)
Perspectives: Security and the Separation Kernel
Today's avionics systems are designed to support more than one application, using a partitioned operating system and memory management units to ensure applications have adequate separation. (Avionics Magazine, April 2007)
MILS: An Architecture for Security, Safety, and Real Time
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Technology Magazine, November 2006)
Partitioning Operating Systems Versus Process-based Operating Systems
Partitioning operating systems are the latest buzz, while processes, by contrast, have been around for over 30 years. Both provide memory protection, however, the intent behind them is very different.
DO-178B and the Common Criteria: Future Security Levels
Although there are similarities between the airborne safety-critical requirements in RTCA/DO-178B and the Common Criteria, ISO 14508, compliance with the higher levels of security in the Common Criteria demands meeting additional security requirements. (COTS Journal, April 2006)
Reusing Safety-Critical Software Components
Safety-critical systems often operate together as a single "system-of-systems," making it important that they meet the most stringent and rigorous requirements for safety-criticality. The failure of one module in a system could create other failures or vulnerabilities, or worse yet, failure of the system as a whole. (COTS Journal, August 2005)
Using the Microprocessor MMU for Software Protection in Real-Time Systems
With minimal impact to overall system performance, user tasks and the kernel can be protected from accidental corruption by using multiple protected address spaces.
Improving code Migration and Reuse
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Computing Design, August 2006)
FCS Program Rolls Forward in Formation
A wireless data network, with advanced communications and technologies, links soldiers with 18 new, lightweight manned and unmanned ground vehicles, unmanned aircraft, sensors and weapons—and it's all in one program. (COTS Journal, June 2005)
Secure Operating Systems for Deeply Embedded Devices
As we add more intelligence to our embedded devices, we find that they are becoming increasingly integrated into our information technology infrastructure. Though system security is not a new concept, security-in-depth is a new paradigm developers are now starting to address. (RTC Magazine, September 2004)
LynxSecure Separation Kernel and Embedded Hypervisor LynxOS-SE Embedded RTOS Luminosity Eclipse-based IDE
LynxOS Embedded RTOS RTOS: LynxOS-178 for software certification

 

SpyKer Embedded-System Trace Tool

Industry Solutions

Migration

Industry Standards

Embedded Systems Technology

RTOS Training for Embedded Systems

Training at LynuxWorks

LynuxWorks Support

Embedded Systems

LynxOS RTOS Support

Embedded System Consulting

Contact Us

About LynuxWorks

Press Room

Newsletter and Announcements

Careers

Partners

Site Map

Board Support Packages (BSPs)

BSP Device Drivers

BSP Targets by Operating System

BSP Targets by Form Factor

Third-party I/O Devices and Hardware

SynergyWorks: LynuxWorks partners


What is SynergyWorks?

Third-party add-ons for LynuxWorks operating systems

Copyright © LynuxWorks™, Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of LynuxWorks is prohibited.