Real-Time Secure Operating System an RTOS white paper

September 2003

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.